The Problem with C (2020)
cor3ntin.github.io
The Problem with C (2020)
1–10 of 177 posts
Re: The Problem with C (2020)
#2Oh boy. Can't wait to see how this comment section materializes.
Re: The Problem with C (2020)
#3In case you are wondering what's this article is about, a more expressive title would be : "C++'s problem with C".
Re: The Problem with C (2020)
#4C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca.
I liked C in the 80s, 90s and 2000s. It was a neat and simple language, but that changed as compilers got more aggressive with their optimizations and exposed just how complicated and unintuitive the spec actually is (and the impossibility of avoiding UB). C was a good learning experience for language committees (as was C++), but it's time to cut our losses and move on.
I also liked C++ in the 90s, but soon grew to despise it. When they tried to revamp it and make it safer to use, I was hopeful, but that's now gone. It's too complicated, the error messaging sucks, and there are too many different ways to do the same thing (with ever changing best practices). In a way, CMake and C++ are two peas in a pod.
This is why I now pin my hopes on rust and zig. I want to write low level code, but not in C or C++. I want a build system that's not Makefiles, CMake, or (shudder) gradle.
Re: The Problem with C (2020)
#5Oh boy. Can't wait to see how this comment section materializes.
Let me grab a seat
Re: The Problem with C (2020)
#6> [C++] also had type inference very early on, but the developers of the mid-80s were not quite ready for that and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11.
Does anybody have background information on this claim? Was there actually a working compiler with it back then or was it just some proposal paper at the time?
Re: The Problem with C (2020)
#7I write a lot of code in a C++ codebase and I'd say C++ is horrific. Not just because of its roots in C, no I think it is actually a worse language than C. Notable detriments in the language include references, classes, a lot of template stuff (some of it is ok, but it makes separate compilation almost impossible).
Re: The Problem with C (2020)
#8> [C++] also had type inference very early on, but the developers of the mid-80s were not quite ready for that and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11. Does anybody have background information on this claim? Was there actually a working compiler with it back then or was it just some proposal paper at the time?
I found a post claiming it was used in B and C to specify a data type stored on the stack.
Re: The Problem with C (2020)
#9> [C++] also had type inference very early on, but the developers of the mid-80s were not quite ready for that and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11. Does anybody have background information on this claim? Was there actually a working compiler with it back then or was it just some proposal paper at the time?
I found a post claiming it was used in B and C to specify a data type stored on the stack. https://stackoverflow.com/a/8272497/7608007
That's exactly what it means.
Nobody used to use the keyword because it was the default anyway. The new meaning is not the same.
Re: The Problem with C (2020)
#10> [C++] also had type inference very early on, but the developers of the mid-80s were not quite ready for that and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11. Does anybody have background information on this claim? Was there actually a working compiler with it back then or was it just some proposal paper at the time?
The working compiler was CFront.
Look for Bjarne talks at CppCon on the subject of language evolution, he has mentioned it on a couple of them.