Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“It is never a compiler error”

blog.plover.com

Post reply on HN
Print view View original

241–250 of 280 posts

Re: “It is never a compiler error”

#241

Post by JackFr »

gioele wrote: post #188
empath75 wrote: post #28

Earlier quoted context omitted.

If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. For 99% of programmers, the chances that you have discovered one is small.

> If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. I'm one of those that routinely find a bug in a library during the very first use of its API. Every "quick weekend project" turns into "let's learn the build system of this library and send a patch/bug report to the maintainer". Does anybody know how can I turn this annoying superpower of mine into a job that is n…

Your superpower is both a blessing and a curse.

It's likely that your weekend projects are things you find interesting and it seems likely that the things you find interesting are bleeding edge. It's never going to get better. On the other hand, any good dev team would value someone who can not only find the bug, but patch it.

You need to get somewhere where using the latest and greatest is encouraged..

Re: “It is never a compiler error”

#242

Post by dcminter »

I dislike the glossing over of the distinction between a compiler bug and a library bug. For me there's a definite spectrum:

* OS - I've never found an OS bug that wasn't widely known

* Compiler - I've found 2 compiler bugs in my career to date (both of which crashed the compiler, making this very clear cut)

* Standard libraries - I've found a moderate handful of bugs in standard libraries, somewhat proportionate to the code surface.

* Third party libraries - I rarely use a third party library without exposing a bug.

* Applications - I find bugs in almost all of the applications that I use.

* My own code - Most of my professional life is spent debugging my own code.

Re: “It is never a compiler error”

#243

Post by sly010 »

Cpoll wrote: post #235
arghwhat wrote: post #209

Earlier quoted context omitted.

This is just plain wrong. It's a terrible idea to assume that other humans don't make mistakes. When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct. There is no level of development that is immune. Sometimes you are to blame. Others, it might be a library. It might be the standard library, or the compiler. A faulty optimization, perhaps. Could also be…

“It is never a compiler error” means don't waste your time blaming the compiler, first assume it's your fault. For every person who genuinely ran into a compiler bug, there are orders of magnitude more who think they did, but didn't. If you start saying "it could be a compiler bug," you're encouraging them to waste their time. > When encountering a bug, start at the top, and work your way down when you conclude that…

> Even thinking "it could be a compiler error" invites laziness.

Or worse it could invite curiosity and now you are spending time wondering how could you tell if it's a compiler bug and how would you go about debugging it.

Re: “It is never a compiler error”

#244

Post by dnautics »

nathan_long wrote: post #237

This is great advice, but needs a caveat. I'd say it this way: The less battle-tested a part of the stack is, the more likely it is to contain a bug. Suppose I'm using a database library written in Elixir to run a PostgreSQL query and I get a weird result. Where is the problem? PostgreSQL has executed billions of queries in thousands of projects for tens of years and has many contributors. The Elixir library is much…

I definitely found a compiler error in an early version of Julia, luckily the solution was to upgrade to the newer release that I'd been too lazy to bump to.

Re: “It is never a compiler error”

#245

Post by nathan_long »

dnautics wrote: post #244
nathan_long wrote: post #237

This is great advice, but needs a caveat. I'd say it this way: The less battle-tested a part of the stack is, the more likely it is to contain a bug. Suppose I'm using a database library written in Elixir to run a PostgreSQL query and I get a weird result. Where is the problem? PostgreSQL has executed billions of queries in thousands of projects for tens of years and has many contributors. The Elixir library is much…

I definitely found a compiler error in an early version of Julia, luckily the solution was to upgrade to the newer release that I'd been too lazy to bump to.

Good example. "An early version of Julia" is a less-tested piece of your stack than, say, "a recent version of Java". Especially if the feature in question is something absolutely everyone uses in Java.

Re: “It is never a compiler error”

#246

Post by ecshafer »

ejolto wrote: post #218
SwellJoe wrote: post #189

Earlier quoted context omitted.

IBM has built several operating systems and programming languages and compilers over the years. Probably more than Bell Labs, actually. It's not so surprising.

Unix and C is more known, so that would be my assumption too. In fact I can't name any IBM made OSes or programming languages.

Aix and z/os are popular operating systems by ibmsl still in use, not counting things like system/36. Lime is a research pl at I'm, there is also apl which was made at Harvard and later at ibm.

Re: “It is never a compiler error”

#247

Post by pdkl95 »

krallja wrote: post #240
pdkl95 wrote: post #133

Earlier quoted context omitted.

> A negative number of changes is nonsensical Of course. As I said, I know this is defending as case that shouldn't happen. > the programmer doesn’t need to defend against it My point is that this is a dangerous attitude that can create bugs. A less-than comparison should cost the same as testing for quality, so only testing for 0 isn't faster. Why are negative values nonsensical? Is is because the variable is named…

If there are a negative number of changes in bubble sort, why is returning early any more valid than continuing with the loop? Think about how bubble sort should work. There is no correct next step to take if count is negative. A negative count of changes is nonsensical. The only option that I could agree with, if you’re going to bother coding anything in this case, is to terminate execution, because the program is i…

> why is returning early any more valid than continuing with the loop?

You could consider it an extension of the "0" condition. However...

> terminate execution, because the program is incorrect.

...this is probably better than simply terminating the loop.

Re: “It is never a compiler error”

#248

Post by iainmerrick »

nathan_long wrote: post #237

This is great advice, but needs a caveat. I'd say it this way: The less battle-tested a part of the stack is, the more likely it is to contain a bug. Suppose I'm using a database library written in Elixir to run a PostgreSQL query and I get a weird result. Where is the problem? PostgreSQL has executed billions of queries in thousands of projects for tens of years and has many contributors. The Elixir library is much…

This is a great way to put it, and very practical. Gives you a ranking of possible suspects, rather than completely ruling out any of them. You're allowed to suspect the compiler but only if other leads have been exhausted.

Re: “It is never a compiler error”

#249

Post by ksk »

arghwhat wrote: post #209
empath75 wrote: post #28

Earlier quoted context omitted.

If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. For 99% of programmers, the chances that you have discovered one is small.

This is just plain wrong. It's a terrible idea to assume that other humans don't make mistakes. When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct. There is no level of development that is immune. Sometimes you are to blame. Others, it might be a library. It might be the standard library, or the compiler. A faulty optimization, perhaps. Could also be…

You seem to be arguing against a straw-man, sir.

The OP simply said that the chances of finding a compiler bug are small. You seem to have found a few minor bugs, and that's cool, but how does that change the fact that chances an average C developer finding a compiler bug are minuscule? There are probably around a million C developers, do we even have one compiler bug per 10 developers?

Re: “It is never a compiler error”

#250

Post by JoeAltmaier »

krylon wrote: post #212

About 9-10 years ago, I worked at a company maintaining an application written in C. There were three other programmers there who had been with the company from the beginning, which at the time was ~15 years. They used the OpenWatcom compiler. A few days in, I discovered that they compiled all their code with all compiler optimizations disabled. They had done so ever since they encountered a bug in the compiler/optim…

...or the compiler had a worthless optimizer?
Post reply on HN