231–240 of 280 posts
> The sort() function was using a bubble sort. (This is of course a bad choice, and I think the maintainers plan to replace it.) There are some valid use cases for Bubble Sort for small and almost sorted arrays (although Array.prototype.sort sounds like a very general solution, which I suppose is not a good idea). I've seen this in JavaScriptCore where they use Cocktail Sort (a variant of Bubble Sort) for sorting in…
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.
That was true-er when by compilers one meant GCC or some such. Now everybody and their dog write compilers and transpilers for young and/or obscurer languages (I'd include Go and Rust in there), and with the immaturity of these environments compiler bugs are a fact of life.
Earlier quoted context omitted.
> 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…
Does anybody know how can I turn this annoying superpower of mine into a job that is not basic Q/A? What would you say, if I told you that this superpower was not basic Q/A? because basic Q/A is what the compiler is passing, all the time. The part you meant with vigour was the job part right? how do you make somebody want your awesome enough to pay you a living wage? It's either apple or Intel, because they are the t…
Earlier quoted context omitted.
It's the worst option except for all the others, I think. JS arrays can contain anything, so if the default behavior was to compare elements as numbers, sorting an array containing mixed types would have unpredictable results (because of comparisons to NaN, etc). Naturally things are only weird for untyped arrays - calling sort() on e.g. an Int32Array does what you'd expect.
Python throws an exception for incomparable types. I guess that's not really practical on the web.
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…
> When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct.
I agree wholeheartedly. Saying "it is never a compiler error" doesn't preclude this; it encourages this behavior. Even thinking "it could be a compiler error" invites laziness.
I'm more shocked that bubble sort is used in production somewhere...
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 newer and has many fewer contributors and has been used much less.
My brand-new query has been executed a handful of times by me and has only been looked at by me.
The chances are overwhelmingly high that the bug is in my code. If I can't find it there, the next candidate is the Elixir library. Only after exhaustive search in those two should I consider that PostgreSQL may have a bug.
Or to include more of the stack:
my code > Elixir lib > Elixir > Erlang > PostgreSQL
Earlier quoted context omitted.
clang/llvm makes the gcc developers look like amateurs when it comes to reckless optimizations for that extra percent in the synthetic benchmark. My goto approach for when something breaks in clang but works in gcc is to disable optimization, and when I can narrow it down to a single offending function, that gets optnone slapped on it and done.
> reckless ... is in the eye of the beholder. They exploit every corner of undefined behavior to the benefit of performance. Indeed other compilers might be "safer." Keep in mind that they also provide you with UBSan to help you detect when you're doing it wrong.
The compiler writers write the compiler with the expectation that the program being compiled is correct i.e. to the specification.
Now when the program fails to be correct, optimizations can result in "weird" results, which is not really incorrect since the input was incorrect.
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…
I strongly disagree with your point of view: "it is never a compiler error" not only precludes suspicion of the lower levels—voicing your suspicion of problems in lower layers will generally result in ridicule!—but it reducing critical thinking, bars people from looking into "complicated" projects, and makes them overall less efficient and skilled developers. I also disagree that encouraging a bit of wasted time is a problem. What is a few hours, or even days "wasted" learning your lesson once and for all if it greatly improves your debugging skill and efficiency? You do not learn without mistakes.
"It is never a compiler error" is a detrimental mindset to have, in that it suggests a mentality where you shut your eyes for anything you did not author. After all, it is too complex, too well-tested, too well-designed, and implemented by much smarter people than you. Compiler, library, application, hardware, train, bridge, it doesn't matter.
Not only does this mean that you often won't find the bug you hit, as you won't start instrumenting the faulty LargePopularLibrary—after all, it obviously can't be to blame—but it also means that you won't as much as read library|compiler|kernel|etc source code, much less do development on it, as you think it is above you, despite it by no means being some magical black art.
"It could be a compiler error" invites you to consider all possibilities. Immediately blaming the compiler without reasonable evidence would, despite such a mantra, be a result of terrible debugging skills. These debugging skills should be improved through other means than intentionally teaching falsehoods, and if the subject is not an entirely lost cause, it should correct itself in much more valuable ways if a little time is "wasted" on improper debugging.
Teach proper debugging techniques instead of lying to others, or yourself.
Earlier quoted context omitted.
A negative number of changes is nonsensical, so the programmer doesn’t need to defend against it.
> 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…