Hacker News Reader

Comment by Touche | Hacker News Reader

I think few people think that C is "inherently good".

Many of us still like C because it is inherently simple. That doesn't mean that it's good. It just means that we value simple and will take some (a lot!) of bad to keep the simple.

When others try to pawn off complex languages like Rust as alternatives because they solve C problems, they are not really listening. From my perspective the pushback is really about 2 groups having diametrically opposite values.

1 values purity and perfection, 1 values simplicity. These two groups are never going to see eye to eye.

View on HN

Modern C is full of various extensions. This makes it a fair bit more complicated than it appears. C is also missing key simplicity features - like modules and forward referencing.

Those kinds of features are wonderful and all and they don't add much complexity to having them in your language. The thing that makes languages more or less simple (and more or less complex) is the number and degree of abstractions they have. C has relatively few abstractions, which means you can spend more time thinking about what you're building. Most of the C replacements have more abstractions, which means you spend a lot of time thinking about the code itself (am I using the right abstraction here?) and less time thinking about the thing you're building.

That's one thing that has made Zig more attractive as an alternative for (a lot of) C developers, it stays close enough with only small abstractions.

I find the opposite is true. Having better abstractions makes the code easier to think about, and hence it's more productive. For example,

D: foreach (i; 0 .. 10) { body }

C: for (int i = 0; i < 10; ++i); { body }

Which one is more better? I can speak from experience that the former is much better, much easier to read, and has fewer bugs.

C doesn't allow forward referencing. What this means in practice as people lay out the code in a source file backwards, i.e. the leaf functions come first and the top level functions come last.

This is just not the ergonomic way to write code. The public functions should be first and the private leaf functions last. The code should read top to bottom.

C is not simple. Not even close.

It's the single language still in use with at least one or two orders of magnitude more quirks than features.

C is full of bobby traps. And nobody survived. Ever.

It's impossible to build reliable software in C. Even people tried for 50 years.

People died in RL not only once because of issues with the C language. I think no other language carries a real world death toll around.

C may seem "easy" because it lacks features one would need to know. But easy is not simple! Usually quite the contrary.

https://www.entropywins.wtf/blog/2017/01/02/simple-is-not-ea...

> People died in RL not only once because of issues with the C language. I think no other language carries a real world death toll around.

Can you link me info about those bugs? I'm familiar with the radiation software bugs, but they don't appear to have been written in C.

The Therac-25 used a PDP-11 computer. So I assumed the software was written in C. It wasn't?

I would also assume that most embedded software (e.g. in cars, spaceships, weapons, etc.) is written in C. But I see now it's indeed hard to come up with definitive sources.

A few failures can be found here (and it's easy to google some more):

https://embeddedartistry.com/fieldatlas/historical-software-...

But sadly no reference to the used languages anywhere there.

So I forward the question as I'm now also unsure: Has anybody definitive sources that prove the absence of C code in the known fatal accidents?

Reply on news.ycombinator.com