3 ms·

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 exp

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.

joshmanders 11y ago
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.
- jay_kyburz 11y ago
  Thats why somebody should fork Node and start building a batteries included standard library.
  - ansgri 11y ago
    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.
sago 11y ago
> 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?
- superuser2 11y ago
  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.
  - sago 11y ago
    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?
    - deleted 11y ago
      [deleted]
    - superuser2 11y ago
      >would your first thought be to go searching for a package No, because if this isn't in the standard library (or a very simple one-liner from standard library functions like "fold +") then I don't want to be working in this language. If I have to work in this language, and I'm allowed to bring in packages, I'd go look for the community's attempt at fixing the standard library, or at least a "math" package, particularly if there were lots of other basic math functions I'd have to do myself. If it's really just this, I'll probably paste a Stackoverflow answer. Could I come up with it myself? Yes, but thinking through the pitfalls of the implementations of basic math operations is not a good use of time. What would you do if your language didn't have exponentiation?
      - sago 11y ago
        [Edit: Parent comment has been rewritten, see second response, below]. That you think averaging a list of numbers qualifies as a 'feature' you might add to a codebase is rather the surprising thing about your response. I'm aware I'm coming over rather arsey, and that isn't intended, I'm just surprised to find someone actually defend the attitude, generally, that says a trivial calculation should be either a) provided, or you're not going to use the language, or b) put in a package to mean you don't have to spend 'the time' writing it, while at the same time saying you don't care what is in those implementations. I mean, it doesn't matter to me, obviously. You can choose to have whatever criteria for taking a job you like, and I can have whatever criteria I like for my hires. I'm just surprised. Sorry If I've come over argumentative or grandstanding.
- Spivak 11y 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?
  - sago 11y ago
    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?
    - superuser2 11y ago
      >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.

joshmanders 11y ago

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.

jay_kyburz 11y ago
Thats why somebody should fork Node and start building a batteries included standard library.
- ansgri 11y ago
  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.

sago 11y ago

> 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?

superuser2 11y ago
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.
- sago 11y ago
  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?
  - deleted 11y ago
    [deleted]
  - superuser2 11y ago
    >would your first thought be to go searching for a package No, because if this isn't in the standard library (or a very simple one-liner from standard library functions like "fold +") then I don't want to be working in this language. If I have to work in this language, and I'm allowed to bring in packages, I'd go look for the community's attempt at fixing the standard library, or at least a "math" package, particularly if there were lots of other basic math functions I'd have to do myself. If it's really just this, I'll probably paste a Stackoverflow answer. Could I come up with it myself? Yes, but thinking through the pitfalls of the implementations of basic math operations is not a good use of time. What would you do if your language didn't have exponentiation?
    - sago 11y ago
      [Edit: Parent comment has been rewritten, see second response, below]. That you think averaging a list of numbers qualifies as a 'feature' you might add to a codebase is rather the surprising thing about your response. I'm aware I'm coming over rather arsey, and that isn't intended, I'm just surprised to find someone actually defend the attitude, generally, that says a trivial calculation should be either a) provided, or you're not going to use the language, or b) put in a package to mean you don't have to spend 'the time' writing it, while at the same time saying you don't care what is in those implementations. I mean, it doesn't matter to me, obviously. You can choose to have whatever criteria for taking a job you like, and I can have whatever criteria I like for my hires. I'm just surprised. Sorry If I've come over argumentative or grandstanding.
Spivak 11y 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?
- sago 11y ago
  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?
  - superuser2 11y ago
    >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.