What if there's nothing wrong with its intended purpose? The wheel has been around for some time, there has been research into other axle-mounted components surely we replace the wheel then?
I don't understand the "it's old therefore bad" argument.
What if there's nothing wrong with its intended purpose? The wheel has been around for some time, there has been research into other axle-mounted components surely we replace the wheel then?
I don't understand the "it's old therefore bad" argument.
GP was just emphasizing how old and crumbling that fossil is with the 50 years old remark.
>What if there's nothing wrong with its intended purpose
And what, exactly, is its intended purpose ? It was to rewrite a 10K LOC kernel maintained by a core team of 3 developers from PDP-7 assembly, in an age before the personal computer and the internet. It was literally created as an ad hoc, bug ridden and unspecified implementation, starting with the thinnest dressing over assembly and adding the absolute bare minimum required for a human to write ~10K LOC without gouging their own eyes off.
There is plenty wrong with it.
>I don't understand the "it's old therefore bad" argument.
It's easy. Fields where there are progress invalidates and supersede their own widsom. You wouldn't go to a doctor trained 50 years ago if you could help it. You wouldn't drive a car made 50 years ago. The only fields where that's not the case is stagnating one, like building houses or making furnitures. Things where 'progress' consists of irrelevant-to-quality changes.
Programming language design is in the first category, and not the second. Especially in the period from 1975 to 2000, it learned and discovered so much that languages made before that period might as well be cave man scribbling on cave walls.
[1] https://quotepark.com/quotes/1741351-c-a-r-hoare-about-algol...
With that being said, can you recommend a modern language designed around a model of computation flexible enough to target e.g. non-flat memory models?
I'm additionally interested in targeting MCUs with no ISA-supported stack and ~2KiB of RAM.
But there is. See the long, long, so very long list of vulnerabilities caused by incorrect memory management.
It's a bad argument, and it's not the argument the person you're replying to is making.
C is bad for reasons that are mostly disconnected to its age. Better languages were written in the 1960s and 1970s, and worse languages are written today. What the GP is saying is that C has not meaningfully improved over the last half century.
So is it your position that C is the pinnacle of systems programming languages? That no significant improvement in PLs has been made... that could ever be made?
I'm a Rust fanboi, but I totally get why some people don't like it. And why many people believe that something better (in one or more different directions) is possible. Or that something else would an even better fit for Linux kernel development.
If the formally proven stuff gets more traction, I'd likely jump ship to something like that. Though a lot, lot of work needs to be done there, especially when talking about interacting with hardware... such a headache. But if our base computing infrastructure could be proven to be correct (hardware and software), that could dramatically improve the entire software ecosystem. There would still be problems, but if we can at least move them up a level or two in the software stack, we have an easier time finding and fixing them. This is the difference between the Spectre attack and leaving the permissions for a password file wide open.
I don't know what a better future is going to look like exactly, but I know that we're not going to get there with just good old C code.