3 ms·

> "Real programmers know to use C, so we keep the uncultured plebes out." ... is rather the kind of attitude that should be expunged from system developers. I

> "Real programmers know to use C, so we keep the uncultured plebes out." ... is rather the kind of attitude that should be expunged from system developers. I have to disagree in this case. I think the rationale here is that a working, productive mastery of C suggests a developer of a certain caliber. For many projects you would be right, it would be good to encourage the more junior developers to join the project. But, for the Linux kernel, for the core of one of the most widely-deployed pieces of software on the planet, the foundation of countless systems, many of which are performing critical functions, I, frankly, think it's good to filter the dev team for properly competent devs at every possible juncture. If rejecting C++ keeps the noobs out, that's a good thing.

eropple 9y ago
> I think the rationale here is that a working, productive mastery of C suggests a developer of a certain caliber. Possibly, but that's still pretty silly. Like...I am a cautious programmer by nature. I can write C. I understand the language and its semantics at a fairly intuitive level. I am still cognizant that a moment's inattention means that I am going to screw up in ways that I literally can't with a language that has a scope guard (to say nothing of typing that isn't based on how wide the data structure is, that sort of thing). Not using a language more featureful than C--even to the point of literally banning every feature from the language that isn't a nonvirtual dtor--doesn't "keep the noobs out". It does, however, create classes of bugs. If anything, a "noob" is less likely to realize the danger they're in when fearlessly[0] writing code! Recognition of my own limits is most of why I don't write C, and if I absolutely must interop with C (passing through to Ruby or whatever) I write the thinnest, dumbest layer I can between it and C++. (These days, I'm trying to go towards Rust for these tasks, but I know C++ much better.) C just does not make you the hard man that many C devotees think it does, that's all. [0] - This is mostly a compliment and only a little tongue-in-cheek. Novices being willing to write code that I have to think about analytically to feel safe when writing it can, in the general case, often work well enough/long enough to get by.
- nine_k 9y ago
  I can agree that C is a poor language (as opposed to "rich"). It's a pretty thin layer over machine code, and its means of abstraction, and means of static checking that these abstractions hold, are very weak. It was designed around 1970 to work on hardware from 1960s. The problem is that in early 1990s, when Linux started, no viable alternatives existed. Pascal required a standard library; Modula-2 did not, but it was late to the scene. C++ was poorly supported, and even more full of hidden traps than C. Ada was theoretically a good choice, but accessible compilers did not exist. C had widespread use, 20 years of history, many compilers, including a free (GPL'd) GCC, wide platform support. Because the language is so compact and simple, these compilers were mostly reliable, there are no complex features that are tricky to implement. Hence the choice. Now we have a much wider choice, we have Rust, we have ATS-lang, we have good-quality C++ compilers, we have various tools to synthesize verified C code from higher-level code, etc. We can hope than in 10-15 years we could see e.g. a viable OS kernel written in Rust.

eropple 9y ago

> I think the rationale here is that a working, productive mastery of C suggests a developer of a certain caliber. Possibly, but that's still pretty silly. Like...I am a cautious programmer by nature. I can write C. I understand the language and its semantics at a fairly intuitive level. I am still cognizant that a moment's inattention means that I am going to screw up in ways that I literally can't with a language that has a scope guard (to say nothing of typing that isn't based on how wide the data structure is, that sort of thing). Not using a language more featureful than C--even to the point of literally banning every feature from the language that isn't a nonvirtual dtor--doesn't "keep the noobs out". It does, however, create classes of bugs. If anything, a "noob" is less likely to realize the danger they're in when fearlessly[0] writing code! Recognition of my own limits is most of why I don't write C, and if I absolutely must interop with C (passing through to Ruby or whatever) I write the thinnest, dumbest layer I can between it and C++. (These days, I'm trying to go towards Rust for these tasks, but I know C++ much better.) C just does not make you the hard man that many C devotees think it does, that's all. [0] - This is mostly a compliment and only a little tongue-in-cheek. Novices being willing to write code that I have to think about analytically to feel safe when writing it can, in the general case, often work well enough/long enough to get by.

nine_k 9y ago
I can agree that C is a poor language (as opposed to "rich"). It's a pretty thin layer over machine code, and its means of abstraction, and means of static checking that these abstractions hold, are very weak. It was designed around 1970 to work on hardware from 1960s. The problem is that in early 1990s, when Linux started, no viable alternatives existed. Pascal required a standard library; Modula-2 did not, but it was late to the scene. C++ was poorly supported, and even more full of hidden traps than C. Ada was theoretically a good choice, but accessible compilers did not exist. C had widespread use, 20 years of history, many compilers, including a free (GPL'd) GCC, wide platform support. Because the language is so compact and simple, these compilers were mostly reliable, there are no complex features that are tricky to implement. Hence the choice. Now we have a much wider choice, we have Rust, we have ATS-lang, we have good-quality C++ compilers, we have various tools to synthesize verified C code from higher-level code, etc. We can hope than in 10-15 years we could see e.g. a viable OS kernel written in Rust.