Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Memory leaks, NULL pointer dereferences, use-after-free

I suffered writing those for many years. I finally simply learned not to do them anymore. Sort of like there's a grain of sand on the bottom of my foot and the skin just sort of entombed it in a callous.



I've seen you make these kinds of comments before on other articles. Please stop. Not everyone is perfect and can forevermore avoid making any mistakes. I strongly suspect your opinion of your skill here is overinflated. Even if it isn't, and you really are that good, everyone cannot be in the top 0.00001% of all programmers out there, so your suggestion to "simply" learn not to make mistakes is useless.

This all just comes off incredibly arrogant, if I'm being honest.


I think a more charitable interpretation of what he said was, "after sufficient practice, I became good enough to start avoiding those pitfalls."

It's not all that different from learning any challenging task. I can't skateboard to save my life, but the fact that people can do it well is both admirable and the result of hundreds or thousands of hours of practice.

Skilled people can sometimes forget how long it took to learn their talent, and can occasionally come off as though the act is easy as a result. Don't take it too harshly.


> after sufficient practice, I became good enough to start avoiding those pitfalls.

You can only do that in code you control. You can not control the entire call stack of your functions in cooperative environments.


> You can not control the entire call stack of your functions in cooperative environments.

That's true. But I try by doing code reviews, and I try to lead the team by example and suggestion.


Examples and suggestions don't transmit your years of experience of pitfall-avoidance. You say you "try" to do code reviews, which is honorable, but also proves that there is code in your codebase that you can not and do not control, and which likely features unsafeness. This is fair enough, we can't do all the work as maintainers after all.

When I `git blame` segfaults in the D compiler repository, the aforementioned assumption -- that you can't control faults introduced by someone else -- seems to be largely true. We do use Go/Rust at work (albeit an easier flavor of it), because I don't trust my juniors.


And, given who OP is, "sufficient practice" here translates to "has been writing compilers in C++ for 4 decades".


> This all just comes off incredibly arrogant

I know, but it's the truth. Consider another case. I worked in a machine shop in college trying to make my steam engine. The man who ran the shop, was kind enough to show me how to operate the machines.

Those machines were like C, built during WW2. They had no user friendly features. The milling machine was a particular nightmare. It was festooned with levers and gears and wheels to control every aspect. There was no logic to the "user interface". Nothing was labeled. The worst one was a random lever that would reverse the operation of all the other levers. My terror was wrecking the machine by feeding the tool mount into the cutting bit.

I would make a part, and it would come out awful - things like the surface finish was a mess. If he had some time, he'd come over and help me. He'd turn a wheel, "ting" the blade on a grinding wheel, adjust the feed, and make a perfect part (all by eyeball, I might add). The man was just incredible with those machines. I was just in awe. He never made a mistake. Have you ever tried to get a part centered properly in a 4-jaw chuck? Not me. He could on the first try every time.

But he'd been doing it every day for 40 years.


He's not making a comment about everyone, it's a specific comment about how often long time C programmers make basic mistakes after a million SLOC or so.

In this instance Walter is correct - the mistakes he listed are very rarely made by experienced C programmers, just as ballet dancers rarely trip over their own feet walking down a pavement.

The problem of those errors being commonplace in those that are barely five years in to C coding and still have another five to go before hitting the ten year mark still exists, of course.

But it's a fair point that given enough practice and pain those mistakes go away.


> ballet dancers

So true. I know dancers who have been at it for decades. They "make it look easy", and it is easy for them. But try to do it yourself, and you look like a moose.

A friend of mine trains dancers for a living. He says the most effective teaching tool is the video camera. But he doesn't bring it out until his student is "hooked" on dancing, because prematurely showing them the video of them dancing just crushes them.

P.S. You can tell a ballet dancer just by the way they walk down the street. I once was at the airport and saw a lady unloading her bags. I just said Hi, you must be a ballet dancer! She replied nope, I'm an ice dancer, off to a competition. LOL.


I'd imagine the main way one reduces instances of these mistakes is to restrict resource ownership into certain patterns which have a clear place for freeing, and rules that ensure it's always reached, and only once.


There are many approaches depending on the type of program or suite of programs being built.

Always pairing the creation of free() code and functions with every malloc() is one discipline.

Another, for a class of C utilities, is to never free() at all .. "compute anticipated resource limits early, malloc and open pipes in advance, process data stream and exit when done" works for a body of cases.

In large C projects of times past it's often the case that resource management, string handling, etc are isolated and handled in dedicated sub sections that resemble the kinds of safe handling methods baked into modern 'safe' languges.


Right. Another one, small but effective, is to put an overflow check on the calculation of the size to pass to malloc().

And another - always use size_t for anything that is used as an index.


> just as ballet dancers rarely trip over their own feet walking down a pavement

What about about walking down a busy construction site? The most charitable and correct interpretation I can think of is "I'm a professional. Seatbelts and OSHA destroy my productivity."


> What about about walking down a busy construction site?

Coordinated people with some years of experience pay attention to the ground and overhead cranes and conveyor belts and survive walking through construction sites, mine sites, aviation hangers, cattle yards, musters, et al on a routine basis. I'm 60+ and have somehow navigated all those environs - including C for critical system control.

These are dangerous environments. No one denies this. It's still true that the longer you inhabit such spaces the safer your innate learned behaviour is.

C has seatbelts and OSHA - valgrind, et al tools abound for sanity checking.

Walter's GP statement is literally little more than "eventually you grow out of making the simple basic maistakes" - eventually, after some years of practice - which is a real problem with C, it takes time to not make the basic mistakes. After all that, there's always room, in C, in Rust, whatever, to make non basic non obvious mistakes.


> After all that, there's always room, in C, in Rust, whatever, to make non basic non obvious mistakes.

Correct, I guess. The number of relatively obvious mistakes should decrease with experience. And it stands to reason that eventually it settles near zero for some part of developer community.

How close to zero and which part of community? Statistic is scarce.

> C has seatbelts and OSHA - valgrind, et al tools abound for sanity checking.

Optional tools with no general enforcement. That is more like elective vaccination or travel advisories. That is, no, no seatbelts and no OSHA.


> The number of relatively obvious mistakes should decrease with experience

Yes, and the kind of mistakes I make have changed. Now they are usually a failure to understand the problem correctly, or are simply typos.

> Optional tools with no general enforcement

That's right. The tools don't work unless you use them. With D the idea is to build the tool into the language itself. I once annoyed the Coverity folks by saying D's purpose is to put Coverity out of business.


> Seatbelts and OSHA destroy my productivity

D is designed with seatbelts (like array overflow protection), and they work. I regularly show how C could add them with only minor additions.


You come off as incredibly arrogant too, you just don't realise it because you have the current mainstream opinion and the safety of a crowd.

Do you know how fucking obnoxious it is when 200 people like you come into every thread to tell 10 C or Javascript developers that they can't be trusted with the languages and environments they've been using for decades? There are MILLIONS of successful projects across those two languages, far more than Rust or Typescript. Get a fucking grip.


Nobody is telling JS developers that Rust will save them, chill.


Well, not 100% true... With Rust being the principal language that compiles to webassembly, I'm sure there is quite a lot of JS code being re-written in Rust right now.


But you'll be called things like "catastrophically unprofessional" [1] if you choose JavaScript over TypeScript, or dynamically-typed Python over MyPy.

[1] https://www.reddit.com/r/Python/comments/1iqytkf/python_type...


He's right. That is catastrophically unprofessional in a professional environment.


Surely it is better than yet another self-promoting mention of his programming language on every unrelated C, Rust or Zig post?


Every post on D attracts C, Rust, and Zig replies :-)

Feel free to downvote any and all posts I make.


This is actually quite easy to achieve, as long as you cannot realize your own mistakes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: