Live data from Hacker News

Deconstructing K&R C Is Dead (2015)

c.learncodethehardway.org

11–20 of 190 posts

Re: Deconstructing K&R C Is Dead (2015)

#11
post #8

This 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…

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.

Re: Deconstructing K&R C Is Dead (2015)

#12
post #2

I 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…

The thing is, I think you can simultaneously have all of these opinions: (a) K&R were/are top-notch computer scientists; (b) K&R was a fantastically written book; (c) C was a great language in 1978; (d) we should be moving away from C in 2016. The fact that we didn't know as much about programming languages in 1978 as we do now in no way diminishes the significance of the work.

I think that C should rapidly be moving toward obsolescence, and I hold K&R in great esteem.

Re: Deconstructing K&R C Is Dead (2015)

#14
post #8

This 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…

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.

> It's remarkable, though, that it's taken 40 years to make much head way in replacing C.

I don't agree: it's been a long process, but the trend is unmistakable. It's hard to remember now, but in the early '90s C and C++ were completely dominant. Nowadays they're much more specialized: you're as likely to build your company on Java or even Python/Ruby as you are to build it on C++. People talk about how it's hard to hire C++ engineers nowadays, while in the '90s "C++ engineer" was pretty much synonymous with "programmer". And so on.

Re: Deconstructing K&R C Is Dead (2015)

#15
I can't see how you could say C is dead when there isn't really anything that can replace it.

I'll take it as dead when the Linux kernel, or it's futuristic replacement, is written in something other then C.

If you are talking about at the user-space level, then yes I can see that. But you shouldn't assume your single use case, higher level user space apps, is the only use case.

Re: Deconstructing K&R C Is Dead (2015)

#17

I can't see how you could say C is dead when there isn't really anything that can replace it. I'll take it as dead when the Linux kernel, or it's futuristic replacement, is written in something other then C. If you are talking about at the user-space level, then yes I can see that. But you shouldn't assume your single use case, higher level user space apps, is the only use case.

In what way, specifically, is Rust unsuitable for building a kernel?

There's no argument that the Linux kernel is currently written in C. But that doesn't prove that nothing exists that can replace C.

Re: Deconstructing K&R C Is Dead (2015)

#18

This 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.

Re: Deconstructing K&R C Is Dead (2015)

#19

I 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.…

Kernel hackers will definitely keep it alive, even if you manage to avoid every other hugely prolific C codebase out there. Being an arcane skill makes it an appealing skill to learn. There's more kernel jobs then there are university graduates capable of properly writing C.

Re: Deconstructing K&R C Is Dead (2015)

#20

Maybe this made Zed feel better, but communicates almost nothing to any outside reader. Not a single actual quote from any of his detractors, for the reader to judge for him or her self if their criticisms have any validity. The categorical declaration of "I cannot help old programmers," without providing the evidence he has for this claim. Lots of name calling, though. No link to the original content, to determine f…

Maybe this made Zed feel better, but communicates almost nothing to any outside reader.

Yes. I can't figure out exactly what he's ranting about. He writes "I will make it clear that my version of C is limited and odd on purpose because it makes my code safe." Does this mean he defined a safer subset of C? (There are lots of those. I've taken a crack at that myself [1], but it's politically hopeless. Rust is the way forward.)

Why would anyone want to write K&R C today? It's awful. It didn't even check function parameter types. Struct fields were just offsets; you could use one on a pointer of the wrong type and the compiler wouldn't complain. (Considering that Pascal predated C by some years, and had a sane type system, this was kind of lame. But they were trying to compile in 64K of 16 bit words in one pass. That was an adequate excuse in the 1970s.) The first ANSI C at least had a sane type system.

[1] http://www.animats.com/papers/languages/safearraysforc43.pdf

Post reply on HN