Cleary you have your thought’s on this and I am not trying to change your mind, but if you investigate Rust/Go you will find that they are very complete languages, with a large set of optional extension libraries, particularly in the case of Go.
They are not being picked by management, but by serious developers for serious tasks that are often very low level in operation.
I read the article posted by @killdozer posted and it strongly resonates with what I listen to week after week on the security podcasts, and too and the often elementary mistakes made by developers of non memory safe languages.
When Linus is open to having Linux drivers written in Rust due to the number of memory bugs in the Linux kernel, you know that means something.
There is still a long way for these languages to expand, but they have landed well and are picking up more and more exposure.
They are great for younger programmers as they stop the silly mistakes often created by C/C++ programmers, and I made enough of them when I started out (only reason I make less now is that I have so little time for programming)
I use C. My major ‘product’ is about 30K lines of code and compiles to around 450KB - all command line, no GUI at all. Much of what I do involves re-using code which I’ve written over the years.
I wouldn’t use C++ if you paid me for it - grossly overcomplicated by idiot multiple inheritance stuff.
There will, hopefully, be better languages coming down the pike sometime. Both Rust and go have appealing aspects.
4 Likes
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
86
Rust is exceptionally well-designed. Includes support frameworks for integration with modern programming practices like continuous integration and documentation.
My favorite is still CommonLisp with CLOS, the Common Lisp Object System. Truly brilliant design with CLOS. CL itself is overly large, complicated with too many different ways to do things, but it has hands-down the best and most powerful macro system, and it really does consider everything, as Lisp was the only language available on some of the 70’s and 80’s platforms for it.
Many “boutique” high-level languages are designed by very intelligent people for use by very intelligent people (themselves), and are simply not accessible to the majority of programmers. So they’ll never take off. But it’s encouraging to see the popularity of relatively novel high-level languages like Clojure (runs on the Java virtual machine) and Julia (compiles to fast code, but bootstrapped off the Python ecology of libraries). Go… meh.
No it’s still going as part of the DotNet environment using the CLR (Common Runtime Language).
I have not done anything with it for more than 10 years, but it was looking pretty good at that point and I imagine it has continued to improve (but maybe someone else can chirp in).
It would not surprise me if large parts of Roon were not written in C# (but this would be a guess at best).
It shares much with many of the other modern languages, but I never found it that performant for quick routines that might have needed to iterate over larger data sets. So I moved on to other languages that were better suited to my needs.
If you don’t like multiple inheritance, don’t use it. I guess C# designers took some of that criticism into account when they banned multiple class inheritance, but they allowed multiple interface implementations, which saves the day.
I mostly do Go programming now, but in more than two decades of C++ programming at places filled with C++ experts, I saw multiple inheritance used maybe three times. At some places, they even have rules against using it.
Since C++ doesn’t make a distinction between a class/struct and an interface, you will have to use multiple inheritance if you break down your functionality into abstract pieces. COM is the obvious example. And while STL generally avoids it through use of templates, iostream is a notable exception. I personally think that imposing feature rules on responsible adults who also happen to be experts is counterproductive. The only rules I favor are styling rules. Oh, and not throwing exceptions in destructors.
This is counter-productive, whether muitiple inheriance is needed or not depends on the design. A programming language (e.g. C/C++, Go, etc.) is just nothing but a tool to solve some real world programming problem.
Um, no. You can do this with single inheritance and good design. Have you read the very influential book Design Patterns? Lots of ways to tackle these problems
It can be, but imagine you work with 2,000 other C++ programmers of varying skill levels. You might decide that the most important thing about you design is maintainability over elegance.
I think that is a reasonable point of view, but I’m talking about a company’s employees working collaboratively on large complex systems. It is not a question of not respecting them as “responsible adults.” People leave or change teams all the time. So it is about building software that is not over engineered, difficult to understand, and hard for others to bug fix.
There is more than one way to do it. I believe in best practices, but I don’t see a reason to bend over backwards just to accommodate some rules that are, at the end of the day, arbitrary.
Well, individual teams are never that large. Then, imposing rules won’t magically solve quality issues. It’s not easy to automatically enforce them, and there are always ways to abuse what’s allowed. If you want to crack down completely, you end up using C. Having strict code review rules on the other hand is much more effective.
I’m not sure if that particular rule was a good one, but I do think good rules are related to quality. For example, we have a rule where I work now that no commit can reduce test coverage by more than a certain percent. Since writing test cases is everyone’s least favorite activity, that rule is valuable.
A superior design & architecture will fix both maintainability and elegance. IMO, most software issues, and bugs are the result of bad design.
Software issues and bugs can be mitigated right from the beginning before you write a single line of code, from the requirements, design, architecture, and modelling.
You need to know exactly where you are going, and how you plan to get there before you start the journey, right?
Bad design is certainly a big issue, but lots of bugs are down to careless implementation oversights. I suspect the second type get picked up more quickly and are easier to fix. The further you push on with a bad design the harder it is to engineer your way out.
This is the bit I’m less sure about. I’ve seen plenty of elaborate, well considered designs break down when the rubber hits the road. Rather than an exact location, I prefer to set off in what I believe is the right direction. Small iterations with thoughtful refactoring can yield a good architecture without the need for grand, detailed designs. I’m not saying design and architecture is unimportant, but “analysis paralysis” isn’t pretty…
C# is an excellent language and is still heavily used in the Windows world and in the portable .NET core framework. I use it on a regular basis for Windows development. It is regularly updated by Microsoft with new features. Version 11 is currently in preview
It has evolved a lot over the years, is very powerful with most of the OO benefits of C++ with very few of the pitfalls. By default it builds to an intermediate language (CIL) which is compiled just-in-time at runtime. CIL is common for all of the .NET languages. It is also possible to compile C# assemblies to native executable code at install time or on first run, which allows them to be optimised for performance on the target OS/hardware.
Id agree that is likely that large portions of Roon are written in C#. Not to mention lots of Microsoft’s first party applications too.
