Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deconstructing K&R C Is Dead (2015)

c.learncodethehardway.org

Post reply on HN
Print view View original

71–80 of 190 posts

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

#71

Post by saurabhjha »

kinkdr wrote: post #54
rhexs wrote: post #6

Low level languages are tough. Gaining a mastery of C does require knowing quite a few strange rules and quirks and it's certainly a bit harder than learning Python. The C FAQ does a good job of illustrating some of the more confusing parts. Sure, I wish I could write Go instead, but that isn't going to happen on the many embedded systems I work on. This is a rather strange and insulting article. I'm not sure why Zed…

> Low level languages are tough I disagree. Low level languages, especially C, are the easiest to master. K&R book is the only book you need to read to know everything about C. All you need after you understand the fundamentals is a bit of discipline. C++ on the other hand is extremely difficult to master. Just have a look at the rules for Rvalue references and you will see what I mean. It may be easier for a complet…

This can be summed up as: Languages like Python are easy to learn but hard to master whereas C is hard to learn but easy to master.

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

#72

Post by kinkdr »

webkike wrote: post #69

K&R C was my introduction to real programming. I treated it ever since as a book, not a reference. Does that make sense? For me it was a glance into the mind of the creator of the language. Yes, some of the ways of programming were flawed in a way that results in today in many terrible things, not the least in which is death. But I was able to outgrow K&R, to learn better things, with its succinct language reference…

> C is as dead as Latin is

I wish that was true, but you will be surprised how many things you use everyday are written in C. Even the ones you would never imagine.

Node.js for example, a large part is in C. Redis, C. Memcached, C. PHP itself is written in C.

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

#73

Post by mjevans »

xenadu02 wrote: post #36
pcwalton wrote: 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…

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

I suspect this has a -lot- to do with performance.

When C was designed, and even today, there are systems without pipelining, where it is expensive (in time) to de-reference a memory address and follow that pointer.

I do not argue that the design you suggest would be safer, and even have advantages for slicing; but that's really not the kind of program that C was intended to service writing.

Also, C is supposed to scale down to //really// simple systems. Systems that lack indirect addressing modes, caches, MMUs, etc. It is literally intended to be a thin veneer over actual assembly for those systems, and why so many operations are specified in terms of /minimum standard unit size/ (for portability of that almost machine code between systems).

What you advocate is more like what C++ actually /should/ have been; a reason to use something more than C to gain advances in safety and ease of design.

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

#74

Post by albinofrenchy »

pcwalton wrote: post #35
cydonian_monk wrote: post #33

Earlier quoted context omitted.

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?

GC languages are almost certainly not even in consideration for most embedded applications. There aren't good strategies for general garbage collection that don't insert random pauses for starters, and you also have a non-negligible impact on RAM usage on systems where RAM might be a premium.

A lot of the things rust brings to the table aren't always relevant on embedded platforms. Dynamic memory allocation on embedded is the exception, not the rule. Everything is statically allocated, so memory management is relatively simple -- everything sticks around forever.

The things that make C/C++ good for embedded are sorta what make it unfortunate for general purpose use. The things that make Rust/Go/Swift good for general purpose use make it unfortunate for embedded use.

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

#76

Post by webkike »

kinkdr wrote: post #72
webkike wrote: post #69

K&R C was my introduction to real programming. I treated it ever since as a book, not a reference. Does that make sense? For me it was a glance into the mind of the creator of the language. Yes, some of the ways of programming were flawed in a way that results in today in many terrible things, not the least in which is death. But I was able to outgrow K&R, to learn better things, with its succinct language reference…

> C is as dead as Latin is I wish that was true, but you will be surprised how many things you use everyday are written in C. Even the ones you would never imagine. Node.js for example, a large part is in C. Redis, C. Memcached, C. PHP itself is written in C.

I'm sorry this wasn't clear; I was subconsciously waxing poetic. I meant to say that C's presence is constantly fading but its influence is widespread.

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

#77

Post by kinkdr »

webkike wrote: post #76
kinkdr wrote: post #72

Earlier quoted context omitted.

> C is as dead as Latin is I wish that was true, but you will be surprised how many things you use everyday are written in C. Even the ones you would never imagine. Node.js for example, a large part is in C. Redis, C. Memcached, C. PHP itself is written in C.

I'm sorry this wasn't clear; I was subconsciously waxing poetic. I meant to say that C's presence is constantly fading but its influence is widespread.

(y) :)

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

#78

Post by mjevans »

mturmon wrote: post #37
pcwalton wrote: post #18

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

Only, it isn't knob and tube or asbestos.

It's much more like comparing crawling (machine code), walking (assembly), C (bi-cycling), and higher level languages (faster to write, more built in safety features, etc).

Each is a good fit for a given role, and sometimes you need to get through tight spaces where using one of the lower impact methods is more effective; or maybe you just can't afford something 'nicer'.

Use the correct tool for the job.

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

#79

Post by gravypod »

pcwalton wrote: post #17
gravypod wrote: post #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.

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.

Well if you can implement a kernel that does everything that Linux does, and is entirely backwards compatible, then I'll say "ok, the reign of C is over". Till then, C is going no where.

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

#80

Post by Kristine1975 »

mjevans wrote: post #73
xenadu02 wrote: post #36

Earlier quoted context omitted.

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

I suspect this has a -lot- to do with performance. When C was designed, and even today, there are systems without pipelining, where it is expensive (in time) to de-reference a memory address and follow that pointer. I do not argue that the design you suggest would be safer, and even have advantages for slicing; but that's really not the kind of program that C was intended to service writing. Also, C is supposed to sc…

>I suspect this has a -lot- to do with performance.

It's questionable whether people wanted that performance though, at least when it resulted in less security. About bounds checking in ALGOL 60: https://en.wikipedia.org/wiki/Bounds_checking

A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to—they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous.

Post reply on HN