Why are "mid-level" languages still used today?

[Seahorse]

"Mid-level" languages like C/C++, Java are still in relevance today even though there is Kotlin, Python, which are comparably more simple and abstracted.

I still get that sometimes when doing a project that is fairly more complex, you have no choice but to use said languages. But I bet that most developers are ones developing "higher-level" software applications. Even though Python and co. are more abstracted and simple-looking, they are deceivingly powerful enough to still code things like interpreters and GUIs.

Yes, I'm rambling on a bit.

[StudlyCaps]

A lot of aspects to this question. First, I'm curious why you consider Java a mid level language? It has automatic memory management and a high level of abstraction, it just has comparatively unwieldy syntax compared to say Python.

My answer though is that different languages are better suited to different applications.

Java is better for very large enterprise applications because it has a large number of very mature APIs for database connectivity and web services. It also has very mature testing frameworks which allow large teams to create very thorough test suites, which is important if you have to provide a high level of stability while coordinating many developers. Unlike many simpler languages, it has very feature rich frameworks for things like internationalization, with a high level of customization.

C++ is almost always used when creating very performant 3D graphics applications, or driver software. Basically Windows native language is C++ so you are able to directly access the lowest level APIs that the system uses, while a higher level language must "wrap" the functionality. These wrappers are often immature and do not present the full functionality of the underlying API. Additionally C++ allows very fine grained control over memory. This is important in applications which need to be very fast, or at least very predictable in response time and memory usage.

C is good at making very small executables, and it is easy to make it work on non-standard hardware because it makes everything you do explicit in the code. This makes it better for embedded systems with slow processors, limited RAM and often, no OS. C++ can be used as well, but you must be vigilant and avoid features like generics, exceptions, large standard libraries, which cause the compiler to generate large executables, or to blow out RAM requirements at runtime.

This is a bit generic, and of course any decent language can do any of these things, but using the right language for the right task is typically faster and easier.

[nullplan]

Reason number one: legacy. I work on a 500k LOC piece of controller software that is entirely written in C. The project started in 1990, and it keeps going to this day. Changing the language would require a rewrite of epic proportions. And while I certainly see the appeal, I cannot justify shutting down the R&D department for a year or two as we get rid of the cruft of three decades. That would be a year or two during which we would not make money, but still require money to purchase pesky necessary things like food.

Reason number two: I heard it all before. Every once in a while, a new language will appear on the market, and bring forth the evangelists touting its virtues. Inevitably, it will turn out that that new language is really only good for writing simple programs, that complicated programs are complicated in most languages, and then that language's star will wane again and it will be as if it was never truly real. This is especially true if simplicity is one of the design goals. That's what C++ started with, and look where it is today. Then Java, now Kotlin. Many come and go, but only a handful are here to stay. Whoever heard of Scala recently?

[eekee]

This is especially true if simplicity is one of the design goals. That's what C++ started with, and look where it is today.

I generally agree with your post, but this surprises me. I remember reading something someone in Bell Labs wrote, or maybe said in an interview: "Bjarne went around asking people what they wanted in a language, and he put it all in. He said no to nobody." (My wording is probably inaccurate, but I think the last sentence is exact.) The point was that it was an overly complex, convoluted language from the very beginning. But I guess I'm nitpicking.

[nullplan]

I may have been misremembering the part about C++. Then again, the reason Bjarne wanted classes in C was to make it easier to model larger problems, or at least that was the claim Alan Kay made.

My point remains: Simplicity is a null statement. No-one (well, except for the esoteric programming languages like Brainfuck and Malborge) actually sets out to create a complicated language. Every language is complicated in its own way. C++, Java, Perl, LISP, etc. are complicated because the language (or runtime) is so big, and can do so much. C and assembly are complicated because the language (and runtime) is so small (or nonexistent), so you end up having to write everything yourself. So over time you see the same code appear over and over again. Writing large programs in these languages can feel like you've zoomed in too much, like you are trying to understand the Mona Lisa one pixel at a time. Writing a big program in one of the other languages can feel like you're trying to take in all of the Louvre at once.

Maybe having large programs is the main problem we ought to combat.

[eekee]

I accept your point.

I've wanted to combat the problem of large programs for my entire computing life. All the same, take something like Forth where I've seen an IDE driver in 5 short lines. I couldn't read it at all, because almost all the words in those 5 lines were unknowns and I couldn't find the definitions. Smallness didn't help. I'm getting on better with this Plain English Programming, but there are still layers and layers to get through to find stuff. It compacts like Forth, surprisingly, but I couldn't call it a mid-level language when there's no array type.

[sandras]

That's the thing with Forth, I think, that it not only tries to solve the problem simply, but tries to simplify the problem itself in the first place. Remember that most Forths don't have memory protection, use cooperative multitasking and I'm sure one could find a lot more such examples (blocks instead of files and the way text editing works come to mind).

I think we need to be not only programmers, but user experience designers. What does the user need and what can we skip to simplify the program?

To get back more on topic, I would say - as we simplify the features, a lower level language becomes more acceptable.

[eekee]

I was thinking last night, I'd forgotten my musings on simplicity. Simplifying the problem - or more exactly, rearranging the problem to simplify the solution - is important to me. Sometimes it brings other benefits. For example, I like Forth blocks, they help me organize and they're great for those little one-use scripts which are just a bit too big to enter comfortably on a command line. Sometimes not so much; I think the order of items on Forth's stack will always slow me down.

Some time in the 80s or 90s, there was a unix marketting slogan, "90% of the power for 10% of the cost." It reminded me of how looking after the little details is what pushes the cost of luxury goods up so high - or it was before manufacturing technology improved. As much as I like programs to work perfectly, I wonder if we're all doing the same with programming as a matter of course. Trying to cover every corner case seems very much like building a Rolls Royce. Maybe a Ford would do the job just as well. Sometimes, a Rolls Royce is just too stuffy and I want to crank the windows down on my 70s Ford and roar out onto the highway! I literally didn't like it when advancing manufacturing technology made it possible for every manufacturer to make their cars all plush and stuffy inside. I also didn't like the newer Ford convertible I had - if I've got the roof down, I want to be able to feel it; not be cocooned indistinguishably from a hardtop! But I've gone off on a tangent again.

On the other hand, it's just a huge pain when some things aren't right, like the Javascript compiler I was using last night which literally got both modulus and bitwise AND wrong! I suspect it's an "everything is floating point" problem. It's a simplification which I liked in BASIC in the 80s, but now I know too much about integers and appreciate them too much to live without them. I suspect most programmers feel that way about some or other features. (Here's the compiler. First time I've written any JS; learned syntax by placing those silly block things and switching to the code.) EDIT: It's not modulus or AND; it fails to count consistently whatever logic I use.

The other thing that annoys me is when the vast array of details in documentation makes hard to find a simple feature which can provide "90% of the power for 10% of the cost," where the cost is time and effort. My example of choice is Python 3.7's socket module, where it took me a lot of effort to find how to open a TCP stream - technology which was good enough for telnet, ftp, ssh, http and irc for decades. It would have gone quicker if I was more familiar with the subject, but that goes for everything. All this complexity squeezes out generalists, and I'm not the right kind of obsessional to be a serial specialist. And so many tutorials seem to make the simple things more complex while using unfamiliar language.