3 ms·

I feel like I have to remind people of this quite often, but the history is such that npm was lightweight at one point, bundling wasn't a thing, and while `isod

by junon 9d ago

I feel like I have to remind people of this quite often, but the history is such that npm was lightweight at one point, bundling wasn't a thing, and while `isodd`/`iseven` are of course silly, things like `isarray` were not functions that existed back then (we didn't have Array.isArray). `typeof [] === 'object'` in JS, so e.g. my package `is-arrayish` checked for a similar structure to an array (whereas Id guess `isarray` checked for the prototype). `isarray` failed for the `arguments` keyword, which was needed for variadics before argument spreads were added to the language I believe in ES5. So of course they don't make sense now. But they were created for a reason. Before even Markov chains were a fad - let alone LLMs - we were trying to be as efficient as possible and maximize code reuse I stead of writing the same helper functions over and over again. That's what you're seeing.

b112 9d ago
[flagged]
- junon 9d ago
  I think a lot of things end up that way, just at different timescales. Best we can do is learn from them and start again, IMO - however that looks.
- toyg 9d ago
  "The road to Hell is paved with good intentions". Still true, probably thousands of years after the sentence was coined.
zarzavat 9d ago
Yes and the critical issue was tree shaking. Nowadays we have tree shaking so it doesn't matter as much but in the past people preferred small single function packages because they had less impact on the download size.
ChiperSoft 9d ago
Additional Context: for about two years functional programming was REALLY popular in the Node community. It was a fad to chain tons of tiny functions together, and thus lots of people wrote tons of tiny functions. This is why lodash/fp exists.
wat10000 9d ago
I don’t think it ever made sense. Code reuse improves efficiency when the code can be shared in memory, or when it needs to be updated and you only have to change it in one place. JS packages don’t give you sharing beyond what you’d get from copying the code. And these little things don’t need to be updated, and in fact you probably don’t want them to be. It’s a case of doing something without understanding why it’s done. Packages are good, code sharing is good, so use it for everything. But it misses why they’re good.
- junon 9d ago
  This is all very easy to say in hindsight. It's missing the context of having been there, I think. Things were just different. Also, way more fun.
  - wat10000 9d ago
    I was definitely saying it at the time. But I wasn't embedded in the ecosystem, it was very much "those JavaScript guys are nuts, why would they do this?"
IncreasePosts 9d ago
You want to implement your own is-odd in your code - simple, right? isOdd = (x) => x % 2 == 1 Ut oh, your code is broken for negative numbers now since % isn't a true modulo operator... Fine then, isOdd = (x) => x % 2 != 0 Ut oh, your code is broken because isOdd("hi") returns true now... Fine then, isOdd = (x) => if(!isNumber(x)) throw... else return x%2 != 0 Ut oh, your code is now broken because isOdd(2^55+1) returns true now...
- rtkwe 9d ago
  Ut oh? I've never seen that, is it variant on uh oh or something else?
  - IncreasePosts 9d ago
    It's something I'm fighting for in my own little way. Everyone does a glottal stop between the "uh" and "oh", so I'm trying to align the spelling Unlike the guy on him who writes all years with 5 digits like 02026, I have good reasons for my idiosyncracies.
    - luplex 9d ago
      Hm, I would not spell it with a "t" then, but maybe with an apostrophe instead. "Uh'oh" is more readable in my opinion and won't be mispronou in ced
- Dylan16807 9d ago
  > Ut oh, your code is now broken because isOdd(2^55+1) returns true now... I think you messed up this example. Whether I literally use "2^55" with XOR or replace it with "2*55", that version of isOdd returns false. False for isOdd(58) is obviously correct. (Also thanks C for permanently screwing up the precedence of bitwise operations because you didn't want to break some existing programs in 1972.) False for isOdd(36028797018963970) is also correct, and if you expected to send in a different number the bug is in the "+1" not the isOdd.
  - 9d ago
bigstrat2003 9d ago
IsOdd and IsEven never made sense. They were a badge of shame that said "I have no idea how to program".

by junon 9d ago

b112 9d ago

[flagged]

junon 9d ago
I think a lot of things end up that way, just at different timescales. Best we can do is learn from them and start again, IMO - however that looks.
toyg 9d ago
"The road to Hell is paved with good intentions". Still true, probably thousands of years after the sentence was coined.

zarzavat 9d ago

Yes and the critical issue was tree shaking. Nowadays we have tree shaking so it doesn't matter as much but in the past people preferred small single function packages because they had less impact on the download size.

ChiperSoft 9d ago

Additional Context: for about two years functional programming was REALLY popular in the Node community. It was a fad to chain tons of tiny functions together, and thus lots of people wrote tons of tiny functions. This is why lodash/fp exists.

wat10000 9d ago

I don’t think it ever made sense. Code reuse improves efficiency when the code can be shared in memory, or when it needs to be updated and you only have to change it in one place. JS packages don’t give you sharing beyond what you’d get from copying the code. And these little things don’t need to be updated, and in fact you probably don’t want them to be. It’s a case of doing something without understanding why it’s done. Packages are good, code sharing is good, so use it for everything. But it misses why they’re good.

junon 9d ago
This is all very easy to say in hindsight. It's missing the context of having been there, I think. Things were just different. Also, way more fun.
- wat10000 9d ago
  I was definitely saying it at the time. But I wasn't embedded in the ecosystem, it was very much "those JavaScript guys are nuts, why would they do this?"

IncreasePosts 9d ago

You want to implement your own is-odd in your code - simple, right? isOdd = (x) => x % 2 == 1 Ut oh, your code is broken for negative numbers now since % isn't a true modulo operator... Fine then, isOdd = (x) => x % 2 != 0 Ut oh, your code is broken because isOdd("hi") returns true now... Fine then, isOdd = (x) => if(!isNumber(x)) throw... else return x%2 != 0 Ut oh, your code is now broken because isOdd(2^55+1) returns true now...

rtkwe 9d ago
Ut oh? I've never seen that, is it variant on uh oh or something else?
- IncreasePosts 9d ago
  It's something I'm fighting for in my own little way. Everyone does a glottal stop between the "uh" and "oh", so I'm trying to align the spelling Unlike the guy on him who writes all years with 5 digits like 02026, I have good reasons for my idiosyncracies.
  - luplex 9d ago
    Hm, I would not spell it with a "t" then, but maybe with an apostrophe instead. "Uh'oh" is more readable in my opinion and won't be mispronou in ced
Dylan16807 9d ago
> Ut oh, your code is now broken because isOdd(2^55+1) returns true now... I think you messed up this example. Whether I literally use "2^55" with XOR or replace it with "2*55", that version of isOdd returns false. False for isOdd(58) is obviously correct. (Also thanks C for permanently screwing up the precedence of bitwise operations because you didn't want to break some existing programs in 1972.) False for isOdd(36028797018963970) is also correct, and if you expected to send in a different number the bug is in the "+1" not the isOdd.
- 9d ago

bigstrat2003 9d ago

IsOdd and IsEven never made sense. They were a badge of shame that said "I have no idea how to program".