3 ms·
"It's made more horrible by the fact that a lot of substandard programmers use it" Indeed. It often boils down to the quality of the programmer rather than th
by thras 17y ago
"It's made more horrible by the fact that a lot
of substandard programmers use it"
Indeed. It often boils down to the quality of the programmer rather than the quality of the language. Community is everything.
"Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C."
Even as a C++ fan myself, I can't argue with that.
"anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny"
Not in my experience. But the Linux kernel has stability and portability demands far beyond nearly anything else out there. So he's probably right. For his domain of experience: the kernel.
"inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app."
He's not arguing against C++, he's arguing against abstraction. It's the silliest part of his essay.
"So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage."
Good god. He sees C as appropriate for something like git? Sure, I'd use it too if my programming team was expert in C and nothing else. That doesn't say anything about the appropriateness of the language.
"If you want a VCS that is written in C++, go play with Monotone. Really. They use a "real database". They use "nice object-oriented libraries". They use "nice C++ abstractions". And quite frankly, as a result of all
these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess."
He's probably right. There's something about the real language fanatics that often limits their rational planning facilities. They make poor project implementors, even though their language expertise makes them good programmers in the trenches. My guess (not ever having heard of Monotone) is that this is what went wrong with the project.
Then again, as a git user, I have one critique of Torvalds' C project: doesn't anyone working on the project have any conception of usability? Git is way too easy to use improperly and often hard to use correctly. It feels like it was coded by a bunch of C-language kernel-hackers. Which it was.
- nearestneighbor 17y ago> "anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny" Ironically, STL and Boost are much more portable than Git.
- biotech 17y agoI should hope so! The portability of a software project like Git is [practically] upper-bound by the tools used to build it.
- gruseom 17y agoHe's not arguing against C++, he's arguing against abstraction. It's the silliest part of his essay. No; as the snippet you quoted already makes clear, he's arguing against inefficient abstraction, which I take to mean abstraction that introduces bottlenecks into a program and is hard to change without rewriting the program. That is a very real problem and not silly at all.
- thras 17y agoRe-read it, he says that you only discover the inefficiency 2 years in. Yes, I'm sure that he's for perfect abstraction, as is everybody else. But he seems to be arguing against real-world abstraction which is what we've got. All abstraction introduces inefficiencies. There is no magic bullet.
- lallysingh 17y agoFor all its faults, efficient abstraction is one of C++'s strongest suites. A small subset of the STL written for the kernel would do wonders (e.g. vector and list).
- gamache 17y agoGood god. He sees C as appropriate for something like git? Sure, I'd use it too if my programming team was expert in C and nothing else. That doesn't say anything about the appropriateness of the language. Considering one of the primary goals of Git was to be faster than greased Jesus with a tailwind, yeah, C's an appropriate choice. Trading more expert programmer hours for fewer CPU cycles is something C does very well.