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.
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.
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.
> 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.
But there's no bug in isOdd. You're sending the number 36028797018963970 into it, which is clearly even.
Putting extra code between the parentheses of the function call doesn't make it the function's responsibility. As nice as it would be for debugging if you could stuff your entire program inside of isNaN((function(){ /* your code here */ })()) and force your browser vendor to fix all problems.
Despite what most JavaScript implementations will tell you, 2 to the 55th power is 36028797018963968, and adding one to that value is 36028797018963969. That's clearly odd.
There is no extra code between the parens. I just put them there so there wouldn't be any question as to operator precedence. I do see now that hn ate my double star, but I think you know what I mean since you told me the value that is spits out when you do the exponentiation
You have a plus and an exponentiation in there. That's code.
var n = 2**55 + 1
console.log(n)
isOdd(n)
n is 36028797018963970. isOdd(n) is giving you the right answer. Putting the +1 inside the parentheses and talking about calculators is a sleight of hand that lets you pretend isOdd gets an odd number, but it doesn't. No odd numbers are around by the time isOdd actually does anything.
The problems are in + and/or our expectations of +. It does not output 36028797018963969, and we must acknowledge that.
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.
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?"
There’s a bit more nuance as to why. It’s not fair to say that the average JS dev is reaching for a package like is-odd/is-even.
Years ago when npm was just getting started there was a lot of experimentation and land grabbing for packages. A few “prolific” developers were pushing these tiny utilities and then using them in their own projects which ended up being required as deps in other projects and then snowballed into is-odd being included in webpack at some point (I think I have that timeline roughly correct).
It’s still a crappy problem for sure but it’s not fair to paint most JS devs with a brush so broad.
Everything that touches JavaScript in the corporate world feels broken.
Look at any full stack job post. It’s a mess of tech stack nonsense on the backend for people who are terrified of JavaScript and a layering of framework madness on the frontend for people who are still terrified of JavaScript. So it should be no surprise to see packages like those in common use when people aren’t really writing, or even reading, the real code anyways.
That is just the coding aspect of it. There are many additional challenges to working with a bunch of cowards whose primary job is to pretend to be something they clearly aren’t.
There’s not much evidence these are being used, only that they are dependencies for something else; that’s why the download numbers are so high.
I wouldn’t say it’s broken, I’d say there are tradeoffs, and devs have known this and discussed it since the start of npm or any package manager. You automatically get some bloat when you use other people’s software. That’s the downside. The upside is you don’t have to write the code yourself and you can create things more quickly by not solving problems that others have already solved.
It’s worth noting that AI has some of the same tradeoffs. The quality of what you get is still proportional to your prompting & reviewing effort, and spending low amounts of effort often results in similar amount of bloat.
The real underlying issue is the economic pressure - much worse in East Germany than in West Germany. People have problems, but the real problems are not immigration or green politics.
What the numbers say is that Germany is deindustrializing. It's not just the car industry, it's a problem in pretty much every sector. It's not what I say, it's what the numbers are saying. https://www.reuters.com/business/german-industrial-output-fa...
I'll introduce subscriptions soon, we're currently still in invite-only beta, but the subscriptions will be very much like GitHub/GitLabs with individual and team pricing.
motan | Software Developer C#/.NET (4 openings) | Isny im Allgäu, Germany | ONSITE (partial home office) | Full-time | NO VISA (EU work authorisation required)
motan builds the equipment that feeds plastics processing - drying, mixing and conveying material into injection molding and extrusion machines. Our equipment runs in manufacturing worldwide.
IMO we are reaching the point where AI models are simply a commodity. Opus (since ~4.6) is sufficient for everything I tried coding wise. I use it to write features (but I review and understand every line it spits out) and to review code.
For code review I also still review everything myself, but use Opus to catch stuff I missed and to judge if a PR is even ready for me to review.
After just updating Claude Code to the latest version I thought about picking Fable (the bigger model) instead of Opus.
But I have no reason to. Opus does everything I want it to do. It could do it faster - that would be an improvement. But for the normal stuff we reached the point where better models are not worth it IMO.
There still might be cases where you want to throw Fable at it.
> Opus (since ~4.6) is sufficient for everything I tried coding wise.
I don't know what that means. It seems like a lack of motivation or something. Like, if it's possible that in one day will be absolutely incredibly intelligent, surely you want to create
- Your own browser (maybe chrome - mv3 + reading list search etc.
- An emacs clone which has evil baked in, completely vim compatible + threaded elisp - that weird window sizing bug which only occurs on my laptop
- An extension which completely restyles amazon.com to make it usable
It just feels impossible to ever get that, but I wouldn't say "what we have is sufficient"
zot is a coding agent harness. not a data vault, not a pacemaker, and not a life-support device in any medical sense.
Ive been coding for almost 20 years, and for the past few with Go. Nobody would believe that a project of this scale or even a much smaller one could be pulled off, halfway stable, over a couple of days. Not even with a blueprint or two in hand. Thats why it matters, and its totally fair, to point out when something is largely vibe-coded. "Vibe slopped" is meant more as a joke. The essential parts of the code I actually understand. Some of them I modified and overhauled myself.
zot is a learning project not production logic with peoples sensible data or lives depending on it. ;-)
If it helps, I did totally get the joke and love when there are these bits of humanity and sarcasm, somehow lost in today's landscape, it used to be more frequent in the past. And I also get what you've described in the previous paragraph from just reading it. Might be that some people get it, some don't. Do what you feel best!
reply