4 ms·

I certainly wouldn't call C++ a good programming language (rather, I would call it the only viable option for most of its usecases, badly designed though it is)

I certainly wouldn't call C++ a good programming language (rather, I would call it the only viable option for most of its usecases, badly designed though it is). However, I will stick by the "letting the programmer fully control every knob" phrase I used. I never claimed it makes it easy and you can make a lot of good arguments regarding better defaults, but it absolutely eschews restricting programmer freedom, at a not inconsiderable price.

pjmlp 8y ago
Ada and Modula-3 are two examples of languages that also let the programmers control every knob, when needed, without exposing the traditional unsafety issues that C++ has inherited from C. But alas, one was too expensive to become mainstream and the other died when Compaq acquired DEC.
- keldaris 8y ago
  I don't know enough about optimizing Ada code to comment competently on your assertion, but part of the reason it's very hard to compete with C/C++ is simply because of the immense effort that's gone into improving the compilers. These days the only languages that are remotely comparable to C/C++ in terms of performance directly benefit from that effort - they either use the LLVM (Rust, Julia, the LDC compiler for D, etc.) or transpile to C (like Nim). The only real differentiation comes from the semantics they expose and any additional machinery they offer on top of that stack (like the Julia JIT).
  - pjmlp 8y ago
    In terms of language features they are safe by default, but do provide enough escape hatch to make it as unsafe as C and C++. The big difference is that you as developer will notice that you are doing something that might eventually blow up, because it is very explicit. For example something like doing a reinterpret_cast would be LOOPHOLE call in Modula-3 and is only allowed inside an UNSAFE MODULE implementation. As for the rest, yes C and C++ have enjoyed 30 years of compiler research, but as Fran Allen puts it, C has brought compiler optimization research back to the pre-history. If you read IBM's research papers on PL.8, the systems programming language used on the RISC project, it already had an architecture similar to what LLVM has. Where the multiple compiler phases were taking care of the optimizations. Then when they decided to go commercial, they rather adopted UNIX as platform. So maybe we would be somewhere else had AT&T been allowed to sell UNIX at the same price as VMS, z/OS and others. As for the LLVM, we aren't going to throw that code away, but as you also assert, it is possible to use safer languages while taking advantage of the optimization work that went into LLVM. That is how I see C and C++'s future, down into a thin infrastructure layer, with userspace mostly written in something else.
    - zlynx 8y ago
      reinterpret_cast in C++ should be read by the programmer as "UNSAFE CODE HERE!!!" It is prone to aliasing issues and all kinds of other problems. In C code, any cast at all, of any kind, should be viewed with the utmost suspicion. That's why unions have been chosen as the correct way to alias pointers. Because it is unlikely that a programmer accidentally used the wrong type or that code changes made a type cast obsolete.
      - pjmlp 8y ago
        In Modula-3 and other safe systems programming languages all the way back to NEWP in the 60's, something like UNSAFE MODULE is exposed in the type system, whereas in C and C++ you have no idea what a library might do. And in C all bets are open.
    - keldaris 8y ago
      Allen's point about C's impact on compiler development is certainly true, but we can't turn back history. For better or worse, the reasons why C won (in terms of adoption) have mostly been compounded further over the years, and the case against it has weakened as compilers improved. As for the future, I'm slightly ambivalent. On the one hand, common sense would lead me to agree with you that, with the exception of some numerical code (where I'm hopeful for further improvements in JIT compilation), most userspace code should be written in languages other than C/C++, retaining most of the efficiency of the underlying infrastructure. On the other hand, there are languages out there (like D, for instance) that essentially fix all the glaring issues of C and fail to get significant adoption. Weird as it may seem from the confines of the HN bubble, usage of C has actually grown over recent years and betting against C has historically turned out poorly.
      - pjmlp 8y ago
        You see it in Microsoft, Apple and Google desktop and mobile OSes roadmaps, where access to classical C and C++ code is being reduced to a funnel, with constraints what user code is still allowed to do with them. It will be impossible task to kill C on UNIX clones and embedded due to culture and existing tools. However the world of application development is much bigger than just UNIX systems programming or embedded development.
  - the_why_of_y 8y ago
    Actually GNAT builds on the very infrastructure of one of these C/C++ compilers, since it is part of the GNU Compiler Collection.

pjmlp 8y ago

Ada and Modula-3 are two examples of languages that also let the programmers control every knob, when needed, without exposing the traditional unsafety issues that C++ has inherited from C. But alas, one was too expensive to become mainstream and the other died when Compaq acquired DEC.

keldaris 8y ago
I don't know enough about optimizing Ada code to comment competently on your assertion, but part of the reason it's very hard to compete with C/C++ is simply because of the immense effort that's gone into improving the compilers. These days the only languages that are remotely comparable to C/C++ in terms of performance directly benefit from that effort - they either use the LLVM (Rust, Julia, the LDC compiler for D, etc.) or transpile to C (like Nim). The only real differentiation comes from the semantics they expose and any additional machinery they offer on top of that stack (like the Julia JIT).
- pjmlp 8y ago
  In terms of language features they are safe by default, but do provide enough escape hatch to make it as unsafe as C and C++. The big difference is that you as developer will notice that you are doing something that might eventually blow up, because it is very explicit. For example something like doing a reinterpret_cast would be LOOPHOLE call in Modula-3 and is only allowed inside an UNSAFE MODULE implementation. As for the rest, yes C and C++ have enjoyed 30 years of compiler research, but as Fran Allen puts it, C has brought compiler optimization research back to the pre-history. If you read IBM's research papers on PL.8, the systems programming language used on the RISC project, it already had an architecture similar to what LLVM has. Where the multiple compiler phases were taking care of the optimizations. Then when they decided to go commercial, they rather adopted UNIX as platform. So maybe we would be somewhere else had AT&T been allowed to sell UNIX at the same price as VMS, z/OS and others. As for the LLVM, we aren't going to throw that code away, but as you also assert, it is possible to use safer languages while taking advantage of the optimization work that went into LLVM. That is how I see C and C++'s future, down into a thin infrastructure layer, with userspace mostly written in something else.
  - zlynx 8y ago
    reinterpret_cast in C++ should be read by the programmer as "UNSAFE CODE HERE!!!" It is prone to aliasing issues and all kinds of other problems. In C code, any cast at all, of any kind, should be viewed with the utmost suspicion. That's why unions have been chosen as the correct way to alias pointers. Because it is unlikely that a programmer accidentally used the wrong type or that code changes made a type cast obsolete.
    - pjmlp 8y ago
      In Modula-3 and other safe systems programming languages all the way back to NEWP in the 60's, something like UNSAFE MODULE is exposed in the type system, whereas in C and C++ you have no idea what a library might do. And in C all bets are open.
  - keldaris 8y ago
    Allen's point about C's impact on compiler development is certainly true, but we can't turn back history. For better or worse, the reasons why C won (in terms of adoption) have mostly been compounded further over the years, and the case against it has weakened as compilers improved. As for the future, I'm slightly ambivalent. On the one hand, common sense would lead me to agree with you that, with the exception of some numerical code (where I'm hopeful for further improvements in JIT compilation), most userspace code should be written in languages other than C/C++, retaining most of the efficiency of the underlying infrastructure. On the other hand, there are languages out there (like D, for instance) that essentially fix all the glaring issues of C and fail to get significant adoption. Weird as it may seem from the confines of the HN bubble, usage of C has actually grown over recent years and betting against C has historically turned out poorly.
    - pjmlp 8y ago
      You see it in Microsoft, Apple and Google desktop and mobile OSes roadmaps, where access to classical C and C++ code is being reduced to a funnel, with constraints what user code is still allowed to do with them. It will be impossible task to kill C on UNIX clones and embedded due to culture and existing tools. However the world of application development is much bigger than just UNIX systems programming or embedded development.
- the_why_of_y 8y ago
  Actually GNAT builds on the very infrastructure of one of these C/C++ compilers, since it is part of the GNU Compiler Collection.