31–40 of 123 posts
Earlier quoted context omitted.
> Real men write in assembly, maybe C if they're a bit tired. root@boxen:~# cat > a.out
Laziness, impatience, and hubris. # zcat > /dev/kmem
> I cannot consistently write safe C/C++ code. I'm not ashamed of that; I don't know anyone else who can. With respect, two mistaken beliefs: 1: Only a few programmers can write safe code. 2: One will naturally encounter such programmers in the course of a prestigious career working for a high-profile web browser company. But mediocre programmers consistently write safe C/C++ code, every day. They do it in the contex…
I think perhaps you and the author have different interpretations of "consistently". You might also differ on whether "safe code" is safe just because it hasn't failed (or been reported!) yet under current inputs.
> They do it as part of a much larger safety process, that is designed to be robust against faults at all levels
So, since we seem to have moderately good success through voluntary adherence to strict guidelines, we shouldn't automate away the possibility of some of these errors entirely when possible? What are the benefits of that approach?
Edit:
I think you can safely ignore my original comment. It's obvious now that I was interpreting it oddly by conflating it with some other comments and positions in this thread. Your comment does a good job of explaining how it is possible to write safe C/C++ consistently (although I might quibble by saying that it is only achieved by ignoring portions of the languages, thus confining you to a dialect of those languages, which is a point in itself to be discussed).
I would delete the original portion, but I believe in acknowledging mistakes rather than hiding them, thus this correction.
Earlier quoted context omitted.
Sure. And the best "insurance" is having competent programmers.
There seems to be no major C system not infested with errors most other languages forbid by design. The question is, do those other languages introduce their own types of errors? In my experience, no. Do they fix all problems? Of course not. Neither does a hard hat.
Sure, it's possible to make a lot of stupid mistakes in C, but most of these mistakes should be found in testing, before the code is deployed. You'll probably say that "We don't even have those problems in language X." and I agree, but you should run the same tests no matter the language, because you want to find as many problems as possible, even if you write your code in language X.
If you're not aware of many of the pitfalls, you might not even be aware of the envelope you should be aware of.
The worst thing about these kinds of articles is the troves of junior programmers that never touched systems programming with a stick before but will read this on hackernews today and sit in the office tomorrow lecturing seasoned coders how they´re dumb for not having seen the light and using an unsafe language. This is how stupid cargo cult gets made, guys. It's easy to repeat some talking points that you found on t…
Fact 2, mostly safe systems programming languages exist since ESPOL (1961), 10 years older than C, and with a great linage of attempts of safe systems programming outside AT&T walls, so plenty of alternatives are available
So as someone with more than 10 years of C and C++ experience, among other programming languages, before focusing on Java and .NET, I find these kind of articles valuable because they are the proof there isn't such thing as the 10x C developer that never does mistakes.
Nice post. There are still to many C/C++ wannabes who think C is an awesome language and their are awesome hardcore programmers. If they are challenged to code something, it's highly probable that flaws will come up.
There are still to many C/C++ wannabes There are still too many people using the term C/C++ :] It never really was a thing, even in the beginning (I mean, just take e.g. destruction at scope exit: that alone makes it a very different language) and now even less with the new standards. Anyway: a language can be considered awesome by people, despite it's flaws. Always has been, never will change, as there will probably…
Yes, but we can try to develop better language. Rust is such a try. And that's good.
> Sure, but I don't belong to that fraction of programmers who think they write flawless code or develop a cult with old, error prone languages such as C.
The important thing is that we are not discussing about programmers making mistakes, but about a language which is old and which is making mistakes easy. C proofed in sufficient cases that it belongs to the museum.
The worst thing about these kinds of articles is the troves of junior programmers that never touched systems programming with a stick before but will read this on hackernews today and sit in the office tomorrow lecturing seasoned coders how they´re dumb for not having seen the light and using an unsafe language. This is how stupid cargo cult gets made, guys. It's easy to repeat some talking points that you found on t…
I think this whole "competent coders don't make mistakes" is a testament to the immaturity of the software development world. Real men write in assembly, maybe C if they're a bit tired. It would be like a construction worker saying "only noobs need a hard hat" or a surgeon refusing to wash their hands because they're careful never to touch anything contaminated. Or maybe simply refusing to wear your seatbelt because…
> or a surgeon refusing to wash their hands because they're careful never to touch anything contaminated. Fun fact, although perhaps this is specifically what you had in mind: This was pretty much the case until Ignaz Semmelweis [1] noticed that washing your hands caused patients to die less frequently. His suggestion was not well-received by the establishment: > "Some doctors, for instance, were offended at the sugg…
I remember sitting in a "software quality" workshop organised by a coder at an old employer. He was enumerating various patterns and best practices, and yet I realised that nothing he was saying was backed up by any evidence beyond appeals to emotion and anecdotes. If he had been trying to sell me on a new religion or a health product, I would have rejected his arguments out of hand, so why should the standard be lower for software development?
> I cannot consistently write safe C/C++ code. I'm not ashamed of that; I don't know anyone else who can. With respect, two mistaken beliefs: 1: Only a few programmers can write safe code. 2: One will naturally encounter such programmers in the course of a prestigious career working for a high-profile web browser company. But mediocre programmers consistently write safe C/C++ code, every day. They do it in the contex…
> Get to know them, and see how safe C/C++ code is actually written!
I know them and also know that only in the context of high integrity computing are companies willing to pay for such processes, because they are cheaper than closing down the company if humans are killed due to a memory corruption error.
Good luck imposing such process in industries where human lives aren't at risk.
If companies could be sued by bad software quality, it would be another matter.
Yet another subtle pro-Rust rant against C. Programming is hard, and writing safe code requires knowledge, not just in C, but in every single language. Even in formal-validable languages you can make mistakes: may be you'll not make errors by using sprintf, but can make others because of using a more complex language.
Good risk management is about cost vs payoff analysis. To address the risk of car accident, first you stop juggling chainsaws while driving, then you start to wear seatbelts, and then you start thinking about how the remaining inevitable driving mistakes can be mitigated through technology or practices.
Consider a component actually responsible for preventing car accidents, such as the anti-lock brake system. It will consist of input sensors, output signals, and an embedded computer running some code. All of these components have gone through an extensive qualification process. On the software side, the coding standard requires that all loops must be manifestly finite, no `continue`, no recursion, etc. This coding standard is enforced by the compiler, and the compiler itself must be certified, an extensive and difficult process on its own. Redundancy and review is applied at multiple levels, with tons of supporting tooling around requirements tracking and the like.
Do that, and prove it over many years, and you can juggle chainsaws safely - or ride an explosion under your feet across the country.
The key idea here is that things that have been proven safe, are safe. Using something unproven like Rust, it's nuts. Think about how big LLVM alone is! Rust doesn't have any of that, not the tooling, qualification, standards, or track record. It could be done, but you would need to pour tons of resources into it to bring Rust up to the level that C has in this space.