[VBprogrammer]

I would go as far as to say 'finding' bugs in the Compiler / Optimizer / OS / Hardware is a warning signal of a poor programmer.

Always expect you are doing it wrong. It will so rarely be the case that this expectation is wrong that you can discount it as insignificant.

[JOnAgain]

Disagree. In fact, were I to come up with a rule of thumb, I'd say the opposite is true.

Want to find bugs in Sun's Java 6 compiler for X64 Linux , use annotations (yeah, I found one in their V30 release last week). Want to find bugs in MS' C++ compiler, write your own templates (this was a few years ago, maybe it's better?). The best programmers push the limit of their tools because they know what's "supposed to happen".

Poor programmers hit something that doesn't work, and just try something else, cause, well they're just trying shit. I would go so far to say that poor programmers, in fact, are unable to find compiler, optimizer, OS, or hardware bugs because, by definition, they probably don't have a firm handle on what's "supposed to happen".

[sparsevector]

I think what VBprogrammer meant is that thinking you've found a bug in a compiler / OS / CPU is often a warning sign you're a poor programmer. Often times a beginner will have a bug in their code that is too subtle for them to identify, so they end up attributing it to some external factor. Actually finding a bug in a compiler / OS / CPU is as you suggest likely a sign you're doing something advanced or unusual and therefore are perhaps more knowledgeable than most.

[VBprogrammer]

Yeah, that's exactly what I meant. Sorry if the sarcasm didn't quite carry.

I know these things can and do happen. I've come across one or two of these strange ones before, but too often I've seen people jump to the conclusion that someone / something else was to blame. Without any other real evidence other than that they have exhausted their shallow back of talent.

[arethuza]

I think that's often called the "select isn't broken" rule:

http://pragprog.com/the-pragmatic-programmer/extracts/tips

However, I did once work with someone who did find a bug in select on SunOS... (this was '89 or so).

[Natsu]

I remember scripting on a MUD that used a customized version of the standard MPROG[1] patch for ROM-based MUDs. Whoever originally "documented" it just grabbed some docs from some other ROM-based MUD that used their own customized version.

The documentation was a completely wrong for several years before I started programming there. Once I realized that the documentation was lying to me, I started methodically examining how things actually worked by writing lots of very simple test programs and documenting the actual behavior.

The others didn't care why it was broken. Most of them were just trying to build cool areas, they weren't really programmers at all. They would just tweak things until it appeared to work or they were frustrated enough to give up.

[1] I'm sure a lot of HN knows this, but to save the non-gamers the hassle of looking it up, a MUD is a type of text-based online game and an MPROG is a script used to control the actions of the characters in the game.

[JoeAltmaier]

No, templates still buggy, came across one last week.

[ryanmolden]

Reported?

[JoeAltmaier]

Way too complicated to identify concisely, and trying to release just now; in the end the wrong object was returned by a casting operator (very, very wrong object). Added and called a named method to do the cast (very same implementation) and all was well.

[ArbitraryLimits]

Depends on the compiler. When I took my "hardware for CS students" class as an undergrad, our big project for the semester was to write a CPU simulator in c, and the campus labs had just rolled out the upgrade from gcc from 2.x to 3.x. I had a bug in my program that I just couldn't isolate, and after about eight hours of chasing it, I realized that the compiler had allocated space for an integer variable right in the middle of an already-allocated array, so the two variables were stomping on each other. I changed the name of the integer variable and my problems went away.

Apparently I wasn't the only one, because within a week all the labs were back on GCC 2.95.

[Figs]

Actually, that sounds a lot like a bug in your build system. Did you have a custom Makefile (either hand written, or provided by a teacher)? If you didn't keep track of dependencies very carefully so that you always recompile all the .c files that depended on shared .h files when the .h files change, you can wind up with situations where different object files disagree on the layout of structures -- it could cause exactly the sort of problem you describe. Changing the name of the variable could force the file to be recompiled, thus appearing to solve the problem.

[sounds]

To further support your point, the rollback to gcc 2.95 happened across many linux distributions due to incompatible changes in the language that happened at the gcc 3.0 version.

Many distributions rolled back so that the default "stable" compiler matched the one they had to use to build the packages - i.e. common sense.

Once the packages were updated to deal with the gcc 3.x language changes, the compiler and packages started appearing together.

[ArbitraryLimits]

I've seen that problem also (not pretty) but no, the two variables were from the same .c file, and were only used in that file.

[btilly]

I find the thought and your name to be ironic.

My first programming job was doing VB programming in Access 2 programs that had to run on Windows 3.1. (Yes, this was in the last millennium.) I kept on running into bugs that I could demonstrate were in Access, not in my code. It was very frustrating.

My next job was in Perl. I went several years before I found an actual bug in the language. Which then went unfixed for years because someone might be using it. Despite the fact that in every significant Perl code base that I've seen since, there are real bugs in the code that nobody has noticed which trace back to the bug that I found. Why do you ask whether I am bitter?

So your suggestion failed glaringly for me when I was using VB, but since has worked much better.

[yuhong]

Access 2 did not use VBA.

[btilly]

It did not use Visual Basic for Applications (VBA), but it did use Access Basic. Which was a dialect of Visual Basic.

Access 95 had the ability to upgrade from Access 2, and that included the ability to migrate from Access Basic to VBA. The tool was not flawless (very little from Microsoft is), but mostly worked pretty well.

[pnathan]

Nah. Finding a bug in the dev stack is a sign that you're running on the edge. I've encountered one or two myself. I sent one in and the company wrote back and said "yep, it's a bug, fixed next build".

Now, blaming without reproduction on the dev stack is a sign of a lamer. :-)

[gaius]

If that were true then there would be no need to ever release new versions of these things!

I have personally found bugs in Linux (kernel, libc), Oracle, various JVMs, etc, usually cases in which algorithms optimized for "normal" loads became pathological under extreme load. It's much more common than perhaps you'd think.

[mikeash]

"Finding" them is a warning signal of a poor programmer if and only if the scare quotes mean that they have not actually researched the problem sufficiently to prove that the problem is in one of those areas.

These legitimate bugs do exist, and some of us have a talent for finding them with annoying frequency.

Less experienced programmers often "want" to find bugs in the compiler/OS/whatever because that way it's not their fault, and they lack the skill to track down difficult problems in their own code. More experienced programmers realize that finding bugs outside of your own code is often a disaster because frequently there's nothing you can do to fix it.