Comment by superuser2
11 years ago
This sounds like a symptom of an inadequate standard library. I do expect to be able to call "average" on a list of numbers without writing it myself, but I expect that to be part of the language not a 3rd party package.
> I do expect to be able to call "average" on a list of numbers without writing it myself
Just out of interest, what kinds of functions would you expect to have to write yourself, if you're not happy about calculating the average of a list of numbers?
Alright, take a simple function like average. How might someone naively calculate the average?
Which will fail but will probably be caught in the code review. Then a cleverer developer might think to write
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
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?
4 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.
Those that are unique to the problem I'm actually trying to solve, and not already in the standard libraries or well-maintained packages of mainstream languages.
Okay, but how long would you think it sensible to look for, test and assess a package for being 'well-maintained' before you'd consider it a better use of your time to average a list of numbers?
If you had to, say, add a list of numbers together, without averaging them, would your first thought be to go searching for a package, given that you know some languages have a 'sum' function? Some languages have an 'add' function (separate from the operator) - would you go looking for a package to supply an add function if you (say) needed to pass it to reduce?
5 replies →
It should, but the ECMAScript spec doesn't have it, and Node.js team prefers to keep the core libraries to a minimum and definitely do not want to modify prototypes. Thus we depend on userland to provide those features for us.
Thats why somebody should fork Node and start building a batteries included standard library.
It seems C++ approach is quite good: you have a very stable (if a bit too stale) standard library, and you have Boost, which is a cutting-edge batteries-included extension to stdlib curated by much the same people as in the standardization committee. It serves as a great _inclusive_ counterpart to the _exclusive_ stdlib and a sandbox for stdlib extension proposals.