Hacker News Reader

Comment by FrankWilhoit | Hacker News Reader

This is one way to go; but the only "problem" with C is management's expectation that production software can be written by people who have only half learned the language, and that is a problem irrespective of which language we are talking about.

View on HN

>the only "problem" with C is management's expectation that production software can be written by people who have only half learned the language, and that is a problem irrespective of which language we are talking about.

Obviously that's not "the only problem", else there wouldn't be huge style guides forbidding tons of practices to make programs safe for NASA and other such uses, aimed at the expert C programmers hired there.

Also obviously that is not "a problem irrespective of which language we are talking about", unless half-knowing the language has the same impact and the language have the same footguns, which is nowhere near true for other languages versus C. You can "half know" Java and not ever get a buffer overflow. You can know C quite well and still get all kinds of dangerous bugs into the code.

I don't think knowledge of the language is the issue with C, it's the fact that it requires a huge amount of diligence to not have security issues. Knowing the nooks and crannies of the language doesn't really help with that.

Made worse by the fact that most people don't work with it or get taught it as much as 25 years ago. A dev who has come up in the last decade or more, the typical C experience they have is writing it poorly for college. They're not typically battle-hardened on it, few people learn the best practices anymore. But when existing code doesn't suit a need they still might be tasked with maintaining something or fixing bugs.

Outside of tiny languages though, pretty much nobody knows the "whole" language. Almost every production language has a ton of quirks that can surprise people who have been using a language for years.

And frankly large numbers of features in languages aren't needed by most devs. Marshalling in C#, for example, isn't needed unless you're calling into native code. Making raw syscalls in Rust isn't needed unless you're working on optimizing some low level systems code.

Expression trees in C# is also an example of this.

I have 10+ years experience (and consider myself highly proficient) in C#, but my interaction with expression trees is mere hours where I've only once or twice needed to solve a very specific small problem which I could do with a small tweak to code copied from Stack Overflow.

I don't think it is the only problem. Even if you learn the language and know it well, if you start contributing on a big project, it's going to be hard to understand exactly what happens and to be sure that you didn't make mistakes. At this point it makes sense to delegate some checking to the computer.

There’s also engineers’ belief that they have learned the language despite only half-knowing it at best.

I think this is actually one of the selling points of C over other languages. Certainly it's easy to fool yourself into thinking you know any language better than you do, but C genuinely is relatively tiny, and I think it's reasonable to expect to become familiar with almost everything in the language in a month or so of full-time work. After a decade of day job C++ coding, I'd not say the same for myself there.

Rust and C++ lately have been particularly quickly moving targets to keep up with, where C is still pretty much the same as C99. The compilers are better, their warnings are better, sanitizer modes are incredible, but the things you type into your text editor to express your program structure are still pretty much the same thing.

> but C genuinely is relatively tiny,

Relatively tiny and with a disproportionate number of footguns.

Not really that much In my experience. Most of the unsafety is very obvious and most of the memory safety really come from errors from this obviously unsafe parts, e.g. the most common memory safety bug is pointer arithmetic gone wrong. The others are temporal memory safety and signed integer overflows. None of this is really subtle or what I would really call a footgun. Nowadays, programmers do not seem to understand integer conversion rules of C anymore (although they are simply IMHO), but then this is something which can be mitigated via sanitizers.

I could have been more precise when I said it's easy to fool yourself into thinking you know _any_ language better than you do... both rustc and ghc have made it abundantly and repeatedly clear that I don't know Rust and Haskell well, and the "if it compiles, it's probably correct" trust that develops from that frustration is a great asset to both those languages.

But those are exceptions: I've definitely felt like I've known more than I really did about at least C, C++, Java, Scheme, Python, Go, bash, Javascript, cron, and several assembly variants, and those platforms did little to stop me from learning about my inexperience in difficult, sometimes embarrassing, sometimes expensive ways.

I'm a big fan of more compile time analysis any way it can be done, and whatever can't at runtime. More types, more proofs, more fuzzing, more sanitizers, and also where possible, more restricted execution models than Turing-complete. Any code that can't prove itself correct is a serious liability. I just also like C... it's got many footguns, yes indeed, it's practically constructed out of only footguns, but there are only like 8 of them, and they're all right there waiting for you to get to know them. It's like having a few good sharp knives in your kitchen. You get to know each well, using them one at a time---and if any is missing from the block you pause everything and look around very carefully.

I doubt that a month of so of full work will get someone fully proficient on e.g. the finer details of integer promotions and how they can break things in non-obvious ways (think of situations such as combining signed and unsigned operands of different widths). The fundamental problem is that sane production code written in C will generally deliberately avoid some aspects of the language precisely because they are so footgun-prone, which means that if you learn solely by experience, you may never even become aware of the footgun behind the pattern.

I think one of the problems with C today, which you're touching on but I think not quite capturing, is that it's not taught and used nearly as much anymore. So when people are found in the position of writing, or more likely altering existing C, they usually don't know popular styles, conventions, coping mechanisms; eg. you can use coding style to make memory leaks less likely [one example: a rule forbidding early return out of a function, designating cleanup blocks], but few people are learning or teaching it.

I fully agree than most of problems of C can be mitigated with good training. It it of course far easier to blame the language than admit that there is a skill issue. The story that this a language full of footguns that even experienced programmers can not deal with is a lot of nonsense in my opinion and does not match my experience (both as a C programmer, a manager of C programmers, and user of many rock-solid C programs). At the same time, does it help to complain about insufficient training? It is just reality that many programmers are not experienced in C and it is also true that there are a lot of serious problems in C code. This is not a contradiction. If you have C coders without sufficient training and/or experience you will get memory safety issues in C code and you will not even notice in time. If you have unexperienced Rust coders, you will still get memory safe code - at least if you have a rule against using "unsafe" or some oversight. (the code might be buggy in others ways, or programmers may be less efficient, but you still get memory safety ensured by the language). I think this is the real great advantage that Rust has and why we should also have a memory-safe subset of C.

It's not usually that someone only half knows the language but rather that different people in a team can carry different assumptions about how something was done...

it takes literal years for someone to get to a point where they can ship proper c code and the process of getting good requires shipping c code when you don't know everything yet. having a system that automates and enforces years of collective knowledge on juniors is great and lets them contribute while they acquire experience.

Reply on news.ycombinator.com