Live data from Hacker News

How can C Programs be so Reliable?

tratt.net

61–70 of 105 posts

Re: How can C Programs be so Reliable?

#61
post #30

Earlier quoted context omitted.

I use Linux, but I am still surprised it is really stable. At low level it's quite messed up and shows the cons of being a pseudo-bazaar ecosystem. Lately it's changing to a cathedral with a handful of core developers acting quite dictatorial and perhaps that will clean up things a bit. I'm not advocating any of both camps, just bringing up it is far from perfect. In particular I've spent last week trying to figure o…

There is an "aesthetic" to the kernel code I now realise (after having had it explained) - whilst some of it is no doubt odd looking, most of it is done that way for a reason, and reasonably consistently. But not to everyones taste.

I'm not a style-nazi, any of the basic styles is fine for me (e.g. indent and keep the same style in all source.)

My dislikes are more pragmatic, no good comments, packing multiple complex operations in a single line, and not making clear what is what (OK this last bit is style but every single coding style for C out there defines this!)

[Again, I'm playing a bit Devil's Advocate as I'm a Linux user myself. There are many things I love from this team.]

Re: How can C Programs be so Reliable?

#62
After having read a lot of these types of language debates, the only conclusions I can safely arrive at are 1) that every language has its advocates and 2) some people are highly productive in their preferred language, much more so than the average programmer would be in their preferred language. But the real question, imho, is how do average programmers compare? How will the same app written in C++ and Java compare, when written by non-superstars? The question merits some empirical research.

Re: How can C Programs be so Reliable?

#64
post #53

This misses two points I consider important: - A whole lot of C code is old. Old, actively maintained code, tends to be more reliable than new code. - C tends to be employed in relatively predictable sub-systems. Something like a device driver has a relatively predictable set of states relative to a GUI application. There aren't that many paths. C code for GUIs, in my experience, tends to be at least a buggy as code…

You seem to forget that in embedded systems, C is still the most used language. So most of the new systems developed these days have new C code. And embedded systems are everywhere.

Also a big part of embedded systems have to be reliable for years in hostile environement without external interventions. so I wouldn't say that this is easily predictable subsystems.

Re: How can C Programs be so Reliable?

#65
post #5

People often write in higher level languages because they want lots of bad code fast. Almost all business applications are CRUD apps (create/retrieve/update/destroy) with some business logic, and they're generally written in C#. The app may crash when you click the wrong button, but the app is cheap to develop and the programmers are easily replaceable. Of course I'm generalizing, and a lot of C# programmers write gr…

Interesting perspective. I was programming a long time in C, C++ and C#, and I don't feel that programming in C# is easier in some fundamental way, or that C# programmers are easily replaceable. Yes, the mode of thinking is different in each language, but the issue that you have to think carefully is basically the same. ;-)

Re: How can C Programs be so Reliable?

#66
post #5

People often write in higher level languages because they want lots of bad code fast. Almost all business applications are CRUD apps (create/retrieve/update/destroy) with some business logic, and they're generally written in C#. The app may crash when you click the wrong button, but the app is cheap to develop and the programmers are easily replaceable. Of course I'm generalizing, and a lot of C# programmers write gr…

  People often write in higher level languages because they want lots of bad code fast. 
I assume you simply meant programmers who want to churn out something quick prefer high level languages. (Majority of them would never like to write 'bad' code intentionally)

Your second assertion is spot on. If one needs to develop a high performing solution optimized for speed and memory consumption, plus high reliability and if it also needs to be reasonably cross platform, one would gravitate towards C. Add to this the established heritage/ecosystem and the tools, and availability of a (relatively) big pool of programmers, C tends to be a good choice.

The only con is a relatively longer development cycle. (True only for mortals like me though, some people stream out C code faster than i write an email. :-) )

Re: How can C Programs be so Reliable?

#67

Earlier quoted context omitted.

But you can't ignore the ABCException, your app will crash. If you ignore the -1, then you're app will happily continue on doing something wrong.

Sure you can ignore it. You don't want to know the number of times I've seen people using the "try, catch, toss away the exception" structure in Java code.

But you have to actively decide to ignore it.

Whereas when you're dealing with return codes, the default is to ignore.

Re: How can C Programs be so Reliable?

#68
post #64
post #53

This misses two points I consider important: - A whole lot of C code is old. Old, actively maintained code, tends to be more reliable than new code. - C tends to be employed in relatively predictable sub-systems. Something like a device driver has a relatively predictable set of states relative to a GUI application. There aren't that many paths. C code for GUIs, in my experience, tends to be at least a buggy as code…

You seem to forget that in embedded systems, C is still the most used language. So most of the new systems developed these days have new C code. And embedded systems are everywhere. Also a big part of embedded systems have to be reliable for years in hostile environement without external interventions. so I wouldn't say that this is easily predictable subsystems.

I'll qualify this with the fact that I've never done any embedded programming, but my feeling is, that relative to a GUI application, that things are still fairly predictable.

Unpredictability seems to arise mostly from interuptability. GUI applications have the ability to jump from a large bank of states to another large bank of states with almost endless permutations and maintain several, not one state simultaneously.

At least in systems programming and I'd assume embedded programming (and like I said, I'm guessing -- I'd be interested in your take there) the chain of interruptability is much more structured and the logic flow inside of components is much more atomic.

Re: How can C Programs be so Reliable?

#70
post #64
post #53

This misses two points I consider important: - A whole lot of C code is old. Old, actively maintained code, tends to be more reliable than new code. - C tends to be employed in relatively predictable sub-systems. Something like a device driver has a relatively predictable set of states relative to a GUI application. There aren't that many paths. C code for GUIs, in my experience, tends to be at least a buggy as code…

You seem to forget that in embedded systems, C is still the most used language. So most of the new systems developed these days have new C code. And embedded systems are everywhere. Also a big part of embedded systems have to be reliable for years in hostile environement without external interventions. so I wouldn't say that this is easily predictable subsystems.

Hmmm, I've worked in the embedded world for the last 10 years, and I can tell you that the bulk of embedded code is far from hardened. It appalls me the number of times that mobile phones, set top boxes, etc crash. Typically, reliability is low because it is hard to run decent unit tests in an embedded environment. You're obliged to write a type of simulator that you can run on a PC, but the simulator never has the exact same behaviour as the target system, so you can never truly verify correct code behaviour.
Post reply on HN