Comment by nnq | Hacker News Reader

Comment by nnq | Hacker News Reader

> if something is worth warning about it's worth making it an error

Why oh why do people think this way, totally conflating things?! It makes any "explorative programming" extremely painful. Really, can't I indulge in a sloppy coding style while prototyping something, have a zillion warnings pop up (or silence them with a compiler flag), have a working prototype with ugly hacks and worst practices and then move on to slowly fix the things till I get a 0 warning 0 errors "clean state".

Not all have the god-programmer mind to start with a "good design". We grow things organically, function by function, class by class. We start from a "ball of mud" and slowly mold it into the shape of our desire (now I agree that for the different style of programming that starts from a "good design" and works hard to prevent everything from turning into a ball of mud, having straight jackets" is good, but if I don't want to live in your "cathedral asylum", then don't force me to wear one!). Every line of code is and will be rewritten time and time again. And you need warnings and errors to be very different concepts to do this style of programming!

> Really, can't I indulge in a sloppy coding style while prototyping something

I sympathise with this view, but personally, as a full-time Go programmer, when I've been hacking up little piece of throw-away or explorative code, I've generally found that not-used errors have as often been helpful as annoying.

For example, the compiler might say "i not used", and I'll think "bloody compiler, let's delete the declaration", but I'll actually find that I've named a loop variable wrongly and that this would have been a hard-to-find error requiring a few edit-run iterations, and thus I've actually saved more time by doing what the compiler asked than if I'd been able to code sloppily.

If I do find myself adding and removing many print statements from within a package, I'll sometimes add a little function:

    func logf(f string, a ...interface{}) {
        log.Printf(f, a...)
    }

then as long as that function exists, I can add a logf call to any file in the package with no need to add and remove imports.

We can still start with mud, but it's good mud.

BTW we have warnings too, but they're generated by a different tool, go vet, which printf format checking and the like.

This. I can't tell you how often I've found that I accidentally shadowed a variable when I meant to use it, and this saves me from banging my head against the table to find the error.

In any sort of industrial setting, even with just two or three people, generally it is not possible to conflate errors and warnings, because there is no such thing as a warning. Either it breaks the compile, or it is simply ignored.

To which your response will inevitably be something like "Don't do that", which is a fine sentiment, but it doesn't work. I also feel "Don't do that", but I need to do something that will work, and making the compile break more often, before you have several tens of thousands of instances of this problem, is actually a great idea.

Any other apparent attempt to find middle ground is just a matter of moving around when the compile breaks. Either you break the build somewhere, or the warnings aren't fixed.

Reply on news.ycombinator.com