FYI, this rant is from January 2015. Surprised to see it showing on HN today.
If anyone is interested in what he removed, you can find it here: https://web.archive.org/web/20150101224641/http://c.learncod...
Deconstructing K&R C Is Dead (2015)
31–40 of 190 posts
Re: Deconstructing K&R C Is Dead (2015)
#32I have mixed feelings about this, but I cannot disagree with it. a. I haven't written a program in C in over 10 years. I wrote software 5 days a week for those 10 years. b. I wouldn't want to write a program in C now. c. The first "high level" programming language I learned was C, from a book (not K&R C), while travelling in Asia, without a computer. It taught me well, but I immediately went on to other languages. e.…
> b. I wouldn't want to write a program in C now.
When all else fails... come back and say this again ! But for the time being ignorance be bliss.
Re: Deconstructing K&R C Is Dead (2015)
#33Earlier quoted context omitted.
It's remarkable, though, that it's taken 40 years to make much head way in replacing C. There's still a lot of C code out there, and a lot of new C code still being written.
Lots more will be written until there is a viable replacement for C in embedded systems.
Exactly. It's beyond my authority to change the language in use, but I would love to have alternatives to argue for. C isn't a terrible option, or is perhaps the least terrible option, but it's not leaving my corner of the corporate universe until a proven alternative establishes itself.
Re: Deconstructing K&R C Is Dead (2015)
#34I am one of the many stalwarts whose bookshelf contains a prominent copy of K&R C. But over the last 10 years or so I find myself referring to it less and less often. It's a huge problem that it stopped at the second edition. The 2nd ed was great in 1999. It is not great in 2016, it is only good. > "You're right, but you're wrong that their code is bad." I cannot fathom how a group of people who are supposedly so int…
[deleted]
Re: Deconstructing K&R C Is Dead (2015)
#35Earlier quoted context omitted.
Lots more will be written until there is a viable replacement for C in embedded systems.
Exactly. It's beyond my authority to change the language in use, but I would love to have alternatives to argue for. C isn't a terrible option, or is perhaps the least terrible option, but it's not leaving my corner of the corporate universe until a proven alternative establishes itself.
What in particular makes Rust (or Go or Swift) unsuitable?
Re: Deconstructing K&R C Is Dead (2015)
#36This is obviously a bitter rant, and devolves into uncomfortably ageist territory about halfway through. I do agree that we should be moving away from C and C++, though. It's pretty simple, really: C was a pretty good language in 1978. We didn't know a lot of things in 1978 that we do now in 2016. It now makes sense to revisit those decisions in light of nearly 40 years of practice. The so-called "PL Renaissance" has…
I'm ready for the hate, so here we go... C was not a well-designed language in 1978.
The fact that C arrays decay to pointers without any bounds is single-handedly responsible for a huge chunk, possibly even the majority, of all RCEs, worms, malware, and exploits. Ever. In the history of computing.
It was a bad design.
It was a bad design in 1978.
It was known to be a bad design in 1978.
Other languages knew that checking array bounds was important, including for security. The internet made the impact of using C much more devastating but people were exploiting buffer overflows in the 80s to great effect. Some of C's predecessors/contemporaries passed a length as the first part of an array so bounds-checking was possible, though that has the downside of not being able to pass slices of an array without copying.
C could have included an arrayref type that was a length + base pointer, and let array l-values decay to an arrayref instead of a pointer. Then taking a slice of an array would not require copying elements. You could still take the address of an individual element. This would not have required much work to implement, even in 1978! Maybe the first compilers didn't insert array bounds checks, but at least the entire design wouldn't preclude them. Let's say you even spell arrayref as []. It would mean sizeof() works on arrays passed to functions.
void wat(int[] values) { for(int i = 0; i (Yes, I know this is not K&R syntax)
Maybe you can forgive C for the stupid header compilation model (why let the compiler do what you can make the programmer do by hand?). You can understand why they might not have foreseen the need for namespaces. D&R didn't invent the macro system so that's not even their fault.
What is unforgivable is the horribly stupid design of C's arrays.
I actually think it would be beneficial if the standards committee added arrayref now. It won't fix all the busted C code but at least you could start improving the #1 problem. Compilers could eventually adopt a flag to prohibit arrays from decaying directly to pointers. You'd probably have to introduce lengthof() to avoid confusion and use some other syntax to declare one, maybe array(int) or something.
Re: Deconstructing K&R C Is Dead (2015)
#37This childish rant is embarrassing. With millions and millions of lines of C code basically running the internet and of vital importance to countless devices, calling it a s *y language is beyond ridiculous.
Asbestos was also used in millions of buildings and was vitally important as insulation. It was also something that was a bad idea and something that we needed to move away from.
I agree with where you're coming from. Another analogy that comes to mind is knob-and-tube wiring (https://en.wikipedia.org/wiki/Knob-and-tube_wiring).
It's an older home wiring technology that works fine for years if undisturbed, is still present and working OK in homes all over, was invented in the early days of electrified homes, requires considerable skill to install properly, tends to be unsafe if not handled skillfully, is expensive and delicate to modify, has no hidden components, allows interesting wiring layouts because conductors are separated, ...
One could go on with the obvious parallels. (I learned on a PDP-11.)
Re: Deconstructing K&R C Is Dead (2015)
#38The specific section of his 'Learn C the Hard Way' book that he's referring to was mostly, as I recall, complaining that the C string functions defined in K&R will fail when you don't pass them valid data, and therefore, they're fundamentally broken.
Make of that what you will, but it seems to me that given all of the other ways that C can blow up due to programmer error, it seems reasonable to expect programmers to pass a valid string to a string function.
Re: Deconstructing K&R C Is Dead (2015)
#39Earlier quoted context omitted.
Asbestos was also used in millions of buildings and was vitally important as insulation. It was also something that was a bad idea and something that we needed to move away from.
I agree with where you're coming from. Another analogy that comes to mind is knob-and-tube wiring ( https://en.wikipedia.org/wiki/Knob-and-tube_wiring ). It's an older home wiring technology that works fine for years if undisturbed, is still present and working OK in homes all over, was invented in the early days of electrified homes, requires considerable skill to install properly, tends to be unsafe if not handled…
Yeah. The weird thing is that in other industries, people have no trouble admitting that the old stuff is often problematic and needs to be replaced. In the supposedly forward-looking tech industry, though, we stick with our tools from 1978 and stubbornly resist admitting that we have learned anything since then. It's strange.
Re: Deconstructing K&R C Is Dead (2015)
#40This is obviously a bitter rant, and devolves into uncomfortably ageist territory about halfway through. I do agree that we should be moving away from C and C++, though. It's pretty simple, really: C was a pretty good language in 1978. We didn't know a lot of things in 1978 that we do now in 2016. It now makes sense to revisit those decisions in light of nearly 40 years of practice. The so-called "PL Renaissance" has…
> C was a pretty good language in 1978. We didn't know a lot of things in 1978 that we do now in 2016. It now makes sense to revisit those decisions in light of nearly 40 years of practice.
We surely did know that Burroughs was selling an operating system written in ESPOL, later NEWP in 1961. Nowadays Unisys still sells them as MCP.
We did know that the Flex machine was written in ALGOL 68RS in 1980.
We did know that VME was written in S3 in 1970.
We did know that Pilot was written in Mesa in 1977.
We did know that Lillith was written in Modula-2 in 1997.
There are lots of other examples.
The main difference was that UNIX and consequently C, source code were available for free because AT&T could not sell it, while people had to pay for the other ones or they were behind research walls.