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

11–20 of 280 posts

Re: “It is never a compiler error”

#11

Post by joe_the_user »

Of course, there's also the point that if utterly pathological behavior is documented, then it's not a compiler error. I remember a c++ compiler that had a hard limit on the number of objects allowed in the programs it compiled. It's documented, "not an error".

The compiler actually crashes rather than returning anything? Well, that's more likely to happen when your code has lots of errors in it. "Don't look at me like that. Go fix your code and then come and complain..."

Re: “It is never a compiler error”

#13

Post by csours »

In userland, if some fraction of the user base misuses a feature, that could be considered a bug, even if it is working as designed.

Obviously things like forward and backward compatibility are much more important in the programming context, so you can't just "fix" things like weird side effects or not throwing an error on assignment in an if statement.

Re: “It is never a compiler error”

#14

Post by ufo »

nothrabannosir wrote: post #4
blt wrote: post #2

I'm more shocked that bubble sort is used in production somewhere...

For nearly sorted data, bubble sort is quite good. Simple implementation and near linear performance. Has my seal of approval.

Insertion sort is almost always better isn't it?

Re: “It is never a compiler error”

#15

Post by harry8 »

mottomotto wrote: post #9
keithnoizu wrote: post #6

You gotta through a lot of those sort of expectations out of the windows when working with js. . . imho

It is silly to kick JavaScript in this example because the bug* is in the library of a custom JavaScript interpreter not a common runtime. * https://github.com/code-dot-org/JS-Interpreter/pull/23

We should consider separate bugs in the language spec from the implementation. In JS it's insane not to K&R brace as it will try to infer missing semi-colon terminators in your code, silently, to your doom. That's surprising if you have the misfortune. It's a massive bug in the language spec but the implementation of the JS interpreter is 100% correct as it kicks you, hard.

Parent comment makes sense to me as a general comment about getting good at JS. Especially given JS has so many new and exciting libraries that get used in production. Ultimately you must fix your code, JS & libraries aren't likely to change in a timely fashion. And of course what I call a bug in the spec must have been considered a feature at one time, some may still consider it so. That's a question of taste and you can always consider yourself 100% correct on any matter of taste simultaneously with those who disagree. :-)

Re: “It is never a compiler error”

#16

Post by dajomu »

mottomotto wrote: post #9
keithnoizu wrote: post #6

You gotta through a lot of those sort of expectations out of the windows when working with js. . . imho

It is silly to kick JavaScript in this example because the bug* is in the library of a custom JavaScript interpreter not a common runtime. * https://github.com/code-dot-org/JS-Interpreter/pull/23

Although with javascript there have been a lot of different interpreters with a lot of different bugs over the years. I'm thinking mainly of browsers and their implementation bugs, there have been quite a few instances in which what I thought was my own mistake turned out to be a browser bug of some kind.

Re: “It is never a compiler error”

#18

Post by cperciva »

Sadly, I've lost count of how many compiler bugs I've tripped over through the years. Often it's compiler crashes -- those are usually easy to get fixed, especially when (as tends to be the case with LLVM) they are caused by assertions failing -- but I've also tripped over compiler hangs (there's a variable in the tarsnap code with an utterly bogus volatile specifier in order to avoid the problematic optimization on some versions of llvm) and outright miscompilations -- one of which has had several LLVM bug reports opened by different people over the years and remains unfixed.

Re: “It is never a compiler error”

#19

Post by darethas »

kccqzy wrote: post #8
blt wrote: post #2

I'm more shocked that bubble sort is used in production somewhere...

A common optimization is to use insertion sort for small arrays (less than 64) and quicksort/heapsort/introsort for larger ones. Usually because better algorithms in terms of Big O have worse constant factors.

Last time I looked at the source for Java's dual pivot quicksort implementation, it used exactly this for 7 elements or fewer
Post reply on HN