My temporary PHP fix from 2014 has nearly 20M installs. Today I'm deprecating it
jakeasmith.com
jakeasmith.com
In some of the rooms, the wallplugs were connected to the switch for the ceiling lightbulb and you had to draw/rotate the switch into the correct direction, to have energy on the wallplugs.
People always complained that something must be broken in these rooms,since they do not have alectricity the whole day on all the wallplugs :-D :-D
https://www.npmjs.com/package/is-odd
https://www.npmjs.com/package/is-even
https://www.npmjs.com/package/left-pad
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.
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.
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.
Also, way more fun.
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...
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.
"Uh'oh" is more readable in my opinion and won't be mispronou in ced
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.
2 to the 55th power is obviously even, so that +1 is obviously odd, but ((2*55) +1) % 2 == 0 in JavaScript.
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)
The problems are in + and/or our expectations of +. It does not output 36028797018963969, and we must acknowledge that.
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.
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.
I don't believe any programmer is actually using these. isarray and left-pad are at least functions that didn't used to be in the standard library, to slightly excuse them.
Was doing something with OSM the other day and Opus basically started reimplementing NetTopologySuite.
> 'use strict';
> var isOdd = require('is-odd');
> module.exports = function isEven(i) {
> return !isOdd(i);
> };
Surely the author's gotta be trolling, right?
> So I had a decision to make. I could dive back into PHP after almost a decade away, hand the package to one of the people who’d offered, or let it keep sitting there.
We are in the AI era. As a maintainer of an open source project that I haven't touched for years, I would first start by asking an AI to produce a fix for the issue and check what it proposes. This definitely reduces the mental load and risk of breaking an old codebase that so many users depend on.
Deprecating the project is playing the open source game in an other dimension: tell the word that depending on this project was a bad idea in the first place and that everyone should move on. But releasing a fix on a deprecated project is fine too.
So both actions are on different dimensions, this isn't a choice between 2 options.
Deprecation is just a tag. You don't have to respect it. And if you want the project to continue, you can freely fork it.
Would you prefer it just sat there unfixed and unsupported?
And yes, if your timeline as a dependency enjoyer is "is this project going to be maintained for 15 years" and you still assumed the answer is yes, it's kind of on you adding a dependency.
Fixing the issue could set an expectation in current users of the package that it might get updates going forward, which it obviously won't from this maintainer, potentially reducing any impetus that might exist to move over to something that is a more correct solution these days. Handing over control of the project where it is has risks which are stated in TFA.
So while both fixing and deprecating could have been done, I think the right choice (just mark it as deprecated) has been made. Not fixing the existing bug(s) will not break anything that is using the package any more than it is already broken. If one of the existing issues had potential to be a security issue then I might err more towards fix+deprecate (with big red text included in any announcement of the fix to the effect that this is the last one and future issues won't get resolved upstream).
This requires re-learning the language he's out of practice with.
This is top-tier. left-pad levels of "we should just implement trivial functions in our own codebases"
(I do not mean that as a knock on the author - it solved his use case just fine. Everyone who took a dependency on it afterward though...)
Author: Ugh, this is ugly, but it fixes the specific problem I’m having so I can go on and work on other things.
Author, later: What do you mean, you’re all using this?
People at AOL realized how the brand was that of a "wow you still exist" so were pretty good at not putting it too intrusively on new or acquired products. Good for those products, bad for the chances of revitalizing the brand. One of the interesting things post-merger with Yahoo was how much Yahoo people had not adopted the same attitude about their own brand.
> This package is abandoned and no longer maintained. No replacement package was suggested.
Both adding it as a dependency using composer and installing it from a lockfile results in:
$ composer require jakeasmith/http_build_url
[…]
Package jakeasmith/http_build_url is abandoned, you should avoid using it. No replacement was suggested.
[…]
$ rm -r vendor/
$ composer install
[…]
- Installing jakeasmith/http_build_url (1.0.2): Extracting archive
Package jakeasmith/http_build_url is abandoned, you should avoid using it. No replacement was suggested.
[…]
I rarely see people use that feature yet tons of repos on Github are essentially dead.
It's still my favorite language though, since it comes closest to shell language but with C-style syntax (other than maybe Perl, which is a write-only language and hard to read, which unfortunately inspired Ruby to inherit some anti-patterns).
I often dream about writing a modern hacker language that combines the best of everything like functional programming, higher-order methods, const by default, parallelism, sync blocking rather than async nonblocking concurrency, etc. It would also undo the pass-by-reference footguns added by PHP 5+ and return to the pass-by-value copy-on-write style of arrays. That's why I really can't endorse attempts like Hack which just introduce a new standard with its own problems.
The insight being that LLMs work around the limitations of mainstream languages and frameworks, rather than challenging assumptions from first principles and building better foundations.
And then, a year later, I got invited to a PostgreSQL convention in Brazil where it was one of the tools being quasi-formally recommended to help migrate the country off of VFP.
The world can feel awfully freaking small sometimes.
This article will be very useful for people who might shift back to older PHP versions for compatibility and face it.
Im sure I could find popular projects in every language in the world which only uses old library functions and hasnt been updated. I would hazzard a guess that as node changes so frequently, there are untold amounts of projects still using old inefficient methods compared to what is available in the latest version