5 ms·

First, second, and third, suggest a very strong path dependence. We keep using C++ because we used it in the past —just like Qwerty. Fourth is also a kind of

First, second, and third, suggest a very strong path dependence. We keep using C++ because we used it in the past —just like Qwerty. Fourth is also a kind of path dependence, but… come on, reasonable programming languages are simple (Lua and 1ML come to mind). Libraries and frameworks take time to learn, but a core language needs a couple days to be picked up, maybe a couple weeks for full productivity. Assuming you knew the underlying paradigms in the first place of course —no Haskell programmer learns Forth in a day. Of course newer is not automatically better. See the mess we made of the web. Still, it is safe to say that nobody in their right mind would invent C++ today. As Rust is showing, we can do better. Even so, I'm extremely wary of this "one language to rule them all". Why does the "right tool for the job" always end up being the vanilla version of some popular language? Where are the languages specialists that can tweak your language into something uniquely suited for your particular needs? Seriously. We call in database specialists, network specialists, security specialists, OS specialists whenever the project has significant demands in those domains. Why are programming languages left out? We breathe with that stuff!

bborud 10y ago
Does anyone really believe that "one language to rule them all" is a feasible goal?
- kazinator 10y ago
  Trivially, yes; for instance, the machine language of your device's CPU actually runs all the code. It's not so far fetched to conjecture having one decent high level language to generate that machine code. I think a good many language designers actually have that as a goal. Make that feasible goal "two languages to rule them": the high level language, plus uses of the assembly language for some of the inevitable escape hatching. Feasible at least with respect to a given system, and others like it. However, nothing but one language to program a microcontroller with 512 words of memory, or a parallel cluster with terabytes of storage? Ha ... :)
  - bborud 10y ago
    Well, in theory what you say seems to make sense. In reality things do not look like this. And it isn't like I can articulate perfectly why it is so. As for programming tiny devices, no, C++ (or even C) doesn't seem to be the right language to do that because people who should know better routinely do very stupid things in those languages for embedded applications. And it isn't just because they are some cash-strapped amateur: car-manufacturers and name-brand manufacturers of appliances have been shown to not know how to do this. Which tells me that they need languages that can help them do the right thing. Or rather: force them to address typical classes of problems or help them address these. I even saw a discussion about heap-fragmentation on an embedded system where you shouldn't be allocating memory at all -- which is not only doing the wrong thing, but doing the wrong thing badly. Sure, people should know better, but they don't. I've spent much of the past two years with my nose in embedded code and if you think the average fullstack programmer produces terrible code, much embedded code is often the stuff of nightmares. If we are to limit the discussion to larger systems, the number of things where you'd need to use C++ for performance or efficiency has shrunk down a lot. In my experience, the vast majority of performance issues come from bad design, lack of measurement, sloppiness and ignorance about algorithmic complexity rather than the ability to squeeze performance out of hardware. Sure, you can, and should, write extremely performance sensitive libraries that cling to the metal where appropriate, but this still leaves a lot you really should do in languages that provide higher productivity, security and clarity.

bborud 10y ago

Does anyone really believe that "one language to rule them all" is a feasible goal?

kazinator 10y ago
Trivially, yes; for instance, the machine language of your device's CPU actually runs all the code. It's not so far fetched to conjecture having one decent high level language to generate that machine code. I think a good many language designers actually have that as a goal. Make that feasible goal "two languages to rule them": the high level language, plus uses of the assembly language for some of the inevitable escape hatching. Feasible at least with respect to a given system, and others like it. However, nothing but one language to program a microcontroller with 512 words of memory, or a parallel cluster with terabytes of storage? Ha ... :)
- bborud 10y ago
  Well, in theory what you say seems to make sense. In reality things do not look like this. And it isn't like I can articulate perfectly why it is so. As for programming tiny devices, no, C++ (or even C) doesn't seem to be the right language to do that because people who should know better routinely do very stupid things in those languages for embedded applications. And it isn't just because they are some cash-strapped amateur: car-manufacturers and name-brand manufacturers of appliances have been shown to not know how to do this. Which tells me that they need languages that can help them do the right thing. Or rather: force them to address typical classes of problems or help them address these. I even saw a discussion about heap-fragmentation on an embedded system where you shouldn't be allocating memory at all -- which is not only doing the wrong thing, but doing the wrong thing badly. Sure, people should know better, but they don't. I've spent much of the past two years with my nose in embedded code and if you think the average fullstack programmer produces terrible code, much embedded code is often the stuff of nightmares. If we are to limit the discussion to larger systems, the number of things where you'd need to use C++ for performance or efficiency has shrunk down a lot. In my experience, the vast majority of performance issues come from bad design, lack of measurement, sloppiness and ignorance about algorithmic complexity rather than the ability to squeeze performance out of hardware. Sure, you can, and should, write extremely performance sensitive libraries that cling to the metal where appropriate, but this still leaves a lot you really should do in languages that provide higher productivity, security and clarity.