3 ms·

I’ll give you one: it’s code already written and tested by > 1 person, edge cases already figured out. Saves you time. The gains are small but quickly add up.

I’ll give you one: it’s code already written and tested by > 1 person, edge cases already figured out. Saves you time. The gains are small but quickly add up. This is why lately I’ve been a fan of very extensive standard libraries (like Crystal has) - its like having a huge repository but vetoed by the same team and without any of the package management drawbacks.

spenczar5 7y ago
> The gains are small but quickly add up. There are costs to these micro-libraries that outweigh the gains. This code is trivial; there aren’t really edge cases to be worked out.
- jasonhansel 7y ago
  Also: the way the library handles those edge cases isn't necessarily the way you want. Case in point: rate-map throws exceptions in situations where you might expect it to fail more gracefully.
cannedslime 7y ago
What gains? That line wouldn't take much resources or time to figure out and test. Now you have yet another dependency that could be injected with bad code in the future...
vhakulinen 7y ago
> it’s code already written and tested by > 1 person, edge cases already figured out. It is tested? Edge cases figured out? Essentially for this code?: return start + val * (end - start); Sure, if its running in hostile environment, you might need to do those sanity checks for your parameters - but I have hard time imagining such situation. If you actually need to "Map a number in the range of 0-1 to a new value with a given range" in your own code, can't you guarantee that the variables are all numbers? Its your responsibility as a developer to know your code, and the data your code is handling. > Saves you time. There is something really wrong if finding a package to do this niche thing is faster and more optimal that just writing out that one line of code.
inimino 7y ago
[C]ode already written and tested by > 1 person, edge cases already figured out wastes time when that person was not you. This costs you time. The losses are small but they add up.
tjpnz 7y ago
>The gains are small but quickly add up. Same could also be said for build times not to mention security issues should one of your micro-dependencies be hijacked.
ben509 7y ago
> edge cases already figured out. Nope, it doesn't guarantee its invariants. This would pass all the tests and yet returns a value out of bounds: > s = 1e12 1000000000000 > e = 1e-8 1e-8 > s + 1.0 * (e - s) 0
dangoor 7y ago
> This is why lately I’ve been a fan of very extensive standard libraries (like Crystal has) - its like having a huge repository but vetoed by the same team and without any of the package management drawbacks. Having had some involvement in the early days of node, I had imagined there being something like the Python stdlib. When the npm world grew, I thought "oh, that's pretty cool. It's neat how npm can handle multiple versions of the same package." Now, I'm in absolute agreement with you. There are definitely downsides to a large standard library, but I think the upsides are worth it if that library is maintained.

spenczar5 7y ago

> The gains are small but quickly add up. There are costs to these micro-libraries that outweigh the gains. This code is trivial; there aren’t really edge cases to be worked out.

jasonhansel 7y ago
Also: the way the library handles those edge cases isn't necessarily the way you want. Case in point: rate-map throws exceptions in situations where you might expect it to fail more gracefully.

cannedslime 7y ago

What gains? That line wouldn't take much resources or time to figure out and test. Now you have yet another dependency that could be injected with bad code in the future...

vhakulinen 7y ago

> it’s code already written and tested by > 1 person, edge cases already figured out. It is tested? Edge cases figured out? Essentially for this code?: return start + val * (end - start); Sure, if its running in hostile environment, you might need to do those sanity checks for your parameters - but I have hard time imagining such situation. If you actually need to "Map a number in the range of 0-1 to a new value with a given range" in your own code, can't you guarantee that the variables are all numbers? Its your responsibility as a developer to know your code, and the data your code is handling. > Saves you time. There is something really wrong if finding a package to do this niche thing is faster and more optimal that just writing out that one line of code.

inimino 7y ago

[C]ode already written and tested by > 1 person, edge cases already figured out wastes time when that person was not you. This costs you time. The losses are small but they add up.

tjpnz 7y ago

>The gains are small but quickly add up. Same could also be said for build times not to mention security issues should one of your micro-dependencies be hijacked.

ben509 7y ago

> edge cases already figured out. Nope, it doesn't guarantee its invariants. This would pass all the tests and yet returns a value out of bounds: > s = 1e12 1000000000000 > e = 1e-8 1e-8 > s + 1.0 * (e - s) 0

dangoor 7y ago

> This is why lately I’ve been a fan of very extensive standard libraries (like Crystal has) - its like having a huge repository but vetoed by the same team and without any of the package management drawbacks. Having had some involvement in the early days of node, I had imagined there being something like the Python stdlib. When the npm world grew, I thought "oh, that's pretty cool. It's neat how npm can handle multiple versions of the same package." Now, I'm in absolute agreement with you. There are definitely downsides to a large standard library, but I think the upsides are worth it if that library is maintained.