Comment by Spivak
11 years ago
Alright, take a simple function like average. How might someone naively calculate the average?
for n in list
sum += n
return sum / len(list)
Which will fail but will probably be caught in the code review. Then a cleverer developer might think to write
l = len(list)
for n in list
sum += n / l
return sum
Which will also fail but in more subtle ways, hopefully the senior dev will catch it in the code review.
Then they correct it to
l = len(list)
for n in list
sum += n / l
rem += n % l
sum += rem / l
rem = rem % l
return sum
But this could further optimized and might still be dangerous. This one might not be fixed at all in the code review.
The best algorithm might be Knuth's which is fairly non-trivial and might not even be the fastest/most efficient given certain unique JS optimizations.
Do you want to do this for every 'trivial' function or would you rather import average where (in theory) someone knowledgeable has already done this work and benchmarks for you and you get the best performing algorithm basically for free?
1. The algorithm in question does not do any of the latter 'better' approaches.
2. The pursuit of all edge-cases is a form of hubris. Your first version is fine in many cases (it is the algorithm used by the package referenced [edit:] and by both the Python and .NET standard libraries) and can be written inline.
3. At the point you are concerned with specific edge-cases, and need the 'correct' algorithm, you need to have found that algorithm, understood it, and make sure that the package you're importing implements it. It's even worse for a builtin function: there's no guarantee that a language implementation of average does so, or that it has the correct tradeoffs for your code. You'd need to test it, code review it, and so on. Do you do that for every trivial function?
4. If you're really suggesting that you can't be trusted to calculate an average correctly, then how can you have the slightest confidence in anything you do that is more complex?
>It's even worse for a builtin function... You'd need to test it, code review it, and so on
If you can't trust built-in functions to do what they say on the standard library documentation, you're either paranoid or made a wrong choice of language. (Or you have some very compelling reason to be working in a language that's still rough, like the early days of Swift, which is an entirely different game).
>If you're really suggesting that you can't be trusted to calculate an average correctly
It's not about what you can be trusted to do, but what's worth spending your time on.
Which languages do you trust to use Knuth's algorithm (or something similarly comprehensive and exhaustive) without checking?
Not going to check many, but a quick look, since I've got them handy: Python fails Spivak's criteria, as does .NET.
2 replies →
No reason to turn something trivial into rocket science.
You examples does not mention the type of variables involved. And dependent on the type and the language your first example may be (a lot more) correct compared to your third example. Ie. negative floating point numbers.
But who says that a library implementation is a lot better than what you as a programmer can come up with?
In particular with all these "micro" libraries written by random people.
Are they actually smarter than you? Do they understand the "edge" cases as you do?
Most people don't bother with looking at the library source code they are importing. And I don't blame them because things are in general a mess and not only for JavaScript.
The solution, for me at least, is to import less and be more conversative with what you import.