“It is never a compiler error”
blog.plover.com
“It is never a compiler error”
1–10 of 280 posts
Re: “It is never a compiler error”
#2I'm more shocked that bubble sort is used in production somewhere...
Re: “It is never a compiler error”
#3I'm more shocked that bubble sort is used in production somewhere...
Could be a small data set
Re: “It is never a compiler error”
#4I'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.
Re: “It is never a compiler error”
#5In over a quarter century of programming, I've twice found interpreter errors. Once a function performed the inverse of the documented behaviour (returning "true" for "false" and vice versa) in a proprietary system, the second was a gawk bug of some description I don't recall but proved to be an actual bug.
The other bugs were all mine.
Re: “It is never a compiler error”
#6You gotta through a lot of those sort of expectations out of the windows when working with js. . . imho
Re: “It is never a compiler error”
#7I'm more shocked that bubble sort is used in production somewhere...
I've seen all the O(n^2) worst case algorithms that reduce to O(n) on nearly sorted lists used, for example, in sweep and prune algorithms in computational geometry.
Re: “It is never a compiler error”
#8I'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.
Re: “It is never a compiler error”
#9You 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.
Re: “It is never a compiler error”
#10List of times we've seen the loch ness monster here? Fun!
gcc's __attribute__(aligned(N))
Whenever you see it if you assume it doesn't do what you think it does from reading the docs that's probably a sound strategy.[1][2]
I'd love it if I'm wrong and there is a way of understanding what it is meant to do and successfully predicting behavior.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914 [2] https://gcc.gnu.org/ml/gcc/2014-06/msg00308.html