'No regrets' says chap who felled JavaScript's Jenga tower – as devs ask: Have we forgotten how to code?

The programmer who sparked a brief meltdown in the JavaScript world last week says he has no regrets – and that it should be a learning experience for the community. Indeed it has been: NPM, the popular package manager at the heart of last Tuesday's kerfuffle, has changed its systems to prevent another collapse of JavaScript's …

[cbars]

eh?

Doesn't everyone have a folder they created years/months/weeks ago that contains junk functions like this? One of the first habits I fell into when I started programming was to save every function I wrote because I was under the deluded impression that what I wrote was beautiful and elegant.

Still, every time you need one you improve it until it is beautiful and elegant and you save time so you can get up on your high horse and post on theregister.

[mythicalduck]

Re: eh?

Doesn't everyone have a folder they created years/months/weeks ago that contains junk functions like this? One of the first habits I fell into when I started programming was to save every function I wrote because I was under the deluded impression that what I wrote was beautiful and elegant

Well, I never consider mine to be beautiful and elegant, I just never wanted to have to keep writing it... The ultimate irony, in my case, is that from time to time, I actually still ditch it all and rewrite it, trying to standardise things like variable names, and formatting. I then get bored, resurrect the stuff I didn't rewrite and carry on with a horrible mix... Maybe one day I'll get the time and motivation to properly tidy everything, but I doubt it.

[Roo]

Re: eh?

"The ultimate irony, in my case, is that from time to time, I actually still ditch it all and rewrite it, trying to standardise things like variable names, and formatting. I then get bored, resurrect the stuff I didn't rewrite and carry on with a horrible mix..."

That counts as "If it ain't broke, don't fix it", that's usually a good thing. :)

[Anonymous Coward]

Re: eh?

"As a result, I have very few dependencies to third party / open source libraries and rarely even need functions from the C-Runtime library."

If thats the case then the programs you write are either utterly trivial or you've pointlessly re-written tried, tested and debugged standard functions making any maintenance coders job a nightmare and your software more than likely inefficient and full of faults at all levels.

[Anonymous Coward]

Re: eh?

"assert: No way to ignore asserts at runtime either individually or across an entire function or file"

So don't use them. Simple.

"No inclusion of callstack displaying"

backtrace()

"I do still use some of the math functions, but usually through their C++ counterparts."

Which probably just call down to the C ones anyway.

"or indeed any real support for vectors, matrices, quaternions, and other more complex math types"

So use Boost then.

"String formatting is very slow in the C library"

No it isn't. Its actually pretty quick.

"string: I have a quite extensive string library that allows me to (among other things) deal with UTF8 or UTF16 strings seamlessly."

Oh come on, seriously?? You don't think there are libraries out there do to everything you mentioned with UTF and more? They've been around for decades!

In any case, you'll be calling down to standard runtimes at some point for everything you wrote unless you've written all your low level calls in assembler. As for your libraries - everything you mentioned has already been done and - no offence - probably better because they've had lots of people work on them, not just one person like your libraries have.

[Anonymous Coward]

Re: eh?

"No thanks."

Why not? Its a bit messy but it does everything you need.

"My string formatter is about seven times faster than sprintf for most things,"

Then it probably does a lot less. Any half decent programmer can write a blindingly fast 1-op function to pad or whatever. The trick is writing a blindingly fast multi purpose function.

"Ditching atof in favour of my own float parser resulted in a further 6x performance boost for a total boost of around 120x."

Oh really? Converting from a string to a number isn't exactly rocket science so I'd love to know how you achieved that 6x speedup. Perhaps no checking for pad spaces, ignore negative numbers, insist on a digit before the point or maybe a fixed length assumption?

"I'm fairly certain that there's no statistically significant correlation between the number of people working on something and the quality of said product"

True, but there is a correlation between the number of people voluntarily using a library and its stability and lack of bugs. If 10s of thousands of coders from finance to aviation use a library then its a good bet it works and works well.

But it seems pretty clear you think you're a Hero Coder - everything you write is better than anything else anyone else has done or could do. Well fair enough, you carry on with your delusions, the world will move on past you.

[Anonymous Coward]

Re: eh?

"It also doesn't waste time allocating any heap memory - something else sprintf, et al."

If you've got a freeform format string that could give an output of any length I'm not sure how you can get around allocating heap memory. You could have a huge output array and if thats going to overflow THEN allocate heap and switch to it but allocating huge stack arrays can cause sudden and terminal failures if memory is low.

"OpenSSL. ;)"

Fair enough, but hideously complex systems will always have hidden bugs. Implemeting SSL oneself however would be an order of magnitude buggier.

[J.G.Harston]

Re: eh?

EXACTLY!

This isn't 'has everybody forgotten how to program?' but 'has everybody forgotten how to maintain programming resources?'

Why the f**** are people building code replying on fetching from external repositories FOR THE F****ING BUILD? You pull in resources every now and then into your local collection of resources and build from them. Is there *REALLY* code that has lines that look like #include http://some.web.site/some/file/name ????

[Electron Shepherd]

Are these dynamic dependencies really a good idea?

I don't work in an NPM & JavaScript world, so this may be way off base, but if the system a developer is working on won't even build without this external code being available at what is, essentially, compile time, does that mean that if someone changes the hosted JavaScript, your compiled code now uses that changed JavaScript?

If so, how on earth do you test a system today, and know that it still works tomorrow when you rebuild it, knowing that you haven't changed any of your code?

I can understand taking a snapshot of third-party code, and using that instead of rolling your own - that makes perfect sense. Refreshing it periodically would also be a good idea. But why is there a need to always pull down the latest? How does that enable you to build stable and tested systems?

[Missing Semicolon]

Re: Are these dynamic dependencies really a good idea?

... and don't even mention Maven!

[Adam Azarchs]

Re: Are these dynamic dependencies really a good idea?

Point taken, but that's what version numbers are for. That's why introducing a new leftpad at version 0.4 didn't fix everyone who depended on 0.3. On the flip side, it does mean that it could take a very, very long time for updates to propagate up the dependency chain, and in the mean time you'll have multiple versions of a package in your project, pulled in as dependencies of other dependencies which haven't upgraded yet.

[Phil O'Sophical]

Re: Are these dynamic dependencies really a good idea?

Point taken, but that's what version numbers are for.

That's not the same thing. If you develop against, say, v0.3 and download a copy of that to your development environment, then anyone can put any changes, good or bad, into v0.4 and it wont affect you. You will always have your known trusted copy of v0.3 which you have tested.

The problem here seems to be that at build time your environment goes off to search for the dependencies. It doesn't matter if you ask explicitly for "v0.3" or just for "latest version", if it isn't there, you're hosed. Even if it is there, can you trust it? Say your build environemnt pulls over v0.3 as you expect,. but that v0.3 has been hacked by a miscreant and isn't the same code you tested. Too many people take the attitude "don't be silly, why would anyone do that', but the simple fact is that they do do that, and it creates security holes.

Dynamic dependencies like this are a security nightmare.

[Fatman]

Re: Are these dynamic dependencies really a good idea?

<quote>Say your build environemnt pulls over v0.3 as you expect,. but that v0.3 has been hacked by a miscreant and isn't the same code you tested. Too many people take the attitude "don't be silly, why would anyone do that', but the simple fact is that they do do that, and it creates security holes.

Dynamic dependencies like this are a security nightmare.</quote>

Which WAS a point I tried to make to manglement in the late 90's as the internet started to 'take off' (except it was in the context of web pages, and the potential for shit to be slung at unsuspecting (l)users). I tried to get manglement to understand that we could not have our (developed in house) web apps rely on someone ELSE hosting the code.But manglement knows better (until we got hacked) and then it was I TOLD YOU SO TIME!!!! I bet the katana through the belly really hurt.

[Munchausen's proxy]

Re: Are these dynamic dependencies really a good idea?

"If so, how on earth do you test a system today, and know that it still works tomorrow when you rebuild it, knowing that you haven't changed any of your code?"

In the immortal words of Tom Lehrer:

Once the rockets are up, who cares where they come down?

That's not my department, says Werner von Braun

[John 104]

Re: Are these dynamic dependencies really a good idea?

@Munchausen's proxy

Von Braun was a cockscuker. Sure, he got us to the moon, but it was on the backs of how many slave workers during the war?

[allthecoolshortnamesweretaken]

Re: Are these dynamic dependencies really a good idea?

It's a DevOps thing, you wouldn't understand...

[Qix-]

Re: Are these dynamic dependencies really a good idea?

It's a little thing called vendoring. There's also another little thing called private registries (which is why a lot of large companies were un-impacted by Azer's childish decision).

Npm isn't perfect, but the idea of versioning and micro-dependencies works fine in the javascript world. Javascript developers use very heavily the concept of semantic versioning, which solves all of your 'stability' problems unless there are bad developers.

I've also never seen such a well tested community than the Node.JS community. We're obsessive over unit tests and using micro dependencies allow us to test the absolute shit out of every little aspect of code.

[Kristian Walsh]

Re: Are these dynamic dependencies really a good idea?

The naivety of "unless there are bad developers" is both charming and worrying.

[Doctor Syntax]

Re: Are these dynamic dependencies really a good idea?

"the idea of versioning and micro-dependencies works fine in the javascript world"

Lots of thing work fine right up to the point where they hit the wall - as demonstrated here.

[Domino]

Azer's childish decision

I'd have done the same thing and don't think it is childish at all. All that was in dispute is the modules name. How that could be used to justify transferring ownership of the module is beyond me and I'd have immediately protected the rest of my code by removing it from the service too.

[Archie Woodnuts]

Re: Azer's childish decision

Pretty much this ^

[Ben Tasker]

Re: Azer's childish decision

All that was in dispute is the modules name. How that could be used to justify transferring ownership of the module is beyond me and I'd have immediately protected the rest of my code by removing it from the service too.

Agreed, it was an arbitrary decision made with no real grounding in rationality. I'd have pulled my code and then spent some time considering whether I wanted to continue being involved with NPM given the new knowledge

I can understand the logic behind their decision to not allow unpublishing after 24 hours, but on the other hand, it's my code and I now have to ask permission to withdraw it? The end result of that, presumably is going to be for a dependancy to just sit unmaintained

[The First Dave]

Re: Azer's childish decision

Surely, if the code is still my copyright, I have the legal right to "withdraw it from sale" at any time?

[Roland6]

Re: Azer's childish decision

"Surely, if the code is still my copyright, I have the legal right to "withdraw it from sale" at any time?"

I think this is an interesting point. If we take the physical world, I self-publish a book and contract a distributor (eg. Amazon) to manage the retail channel for me then I can request the distributor to cease distribution and to reclaim all copies unsold by them. Hence they can clear their warehouse and reclaim books sent to stores that were delivered on a sale-or-return basis (ie. they remain the property of the distributor until sold by the retailer). However, they would be unable to reclaim any stock owned by third-parties ie. any stock actually owned by a retailer or end customer.

What is clear in the physical world ownership is reasonably straightforward to establish, namely follow the money. With oss there is no money transaction trail and hence it is much harder to determine ownership and when ownership changes, which in turn becomes even more cloudy with digital products when the products are held by the distributor and the customer dynamically links to the products. Because does the 'sale' occur when a developer links to the code or when the code is accessed for JIT compilation/execution? It would seem NPM are now saying the sale has effectively happened after it has been hosted by them for 24 hours...

I suspect the ramifications of Azer's actions will reverberate for sometime to come and the service revisions NPM have announced are just the beginning of the changes that are going to happen in the oss code library sector.

[Christian Berger]

Dependencies are always a problem

People have to weigh the problems of dependencies against the advantages and make a sensible decision.

[bombastic bob]

Re: Are these dynamic dependencies really a good idea?

"I don't work in an NPM & JavaScript world, so this may be way off base, but if the system a developer is working on won't even build without this external code being available at what is, essentially, compile time, does that mean that if someone changes the hosted JavaScript, your compiled code now uses that changed JavaScript?"

"If so, how on earth do you test a system today, and know that it still works tomorrow when you rebuild it, knowing that you haven't changed any of your code?"

WELCOME to JAVA-SCRIPT's version of DLL HELL!!!

This is why _I_ always:

a) statically link

b) write "my own" for trivial functionality

c) avoid shared packages unless they make sense

d) host my own versions of said packages to avoid "that"

It's the same in the BINARY world as it is in the JAVASCRIPT world, apparently. You don't want "some stupid change" [one YOU did not sanction] to break YOUR code, and cause YOU to get "the midnight phone call" from angry customers/bosses.

[energystar]

Basically...

Basically like this bombastic advice :)

[Herby]

Maybe the lazy in us expects...

A function called "wipe_my_a**". Given what these simple routines do, it may even be there.

It is probably better to just "copy" these functions to your own private space, which mill load easier anyway since it is on the same server as your html code.

Sorry, I'm not a web developer, so I could be all wrong. In normal programming the dynamic libraries come from the machine, NOT the web. Who is to say that the "pad_left" function could be altered to "steal my identity" (and pad_left) and no one would be the wiser.

If you are going to use the items from the grocery shelf, please purchase them.

[Anonymous Coward]

Re: Maybe the lazy in us expects...

As far as I understand, NPM essentially automates the process of copying the code into your project. Then you use something like gulp to mash it all together into a hopefully cohesive whole, run minification (what Java or .NET coders would call obfuscation but JS programmers do because it's actually critical to making the site fast), and so on.

As for changes to the method, the packages have version numbers. As long as you trust NPM itself not to violate the implicit contract there, you'll be fine. Of course if I was designing the system I'd use hashes rather than version numbers, to be safe.

And I'd use git instead of NPM.

And I'd use C++ or Java or C# or Haskel or Python or Go or just about anything to avoid JavaScript.

[Qix-]

Re: Maybe the lazy in us expects...

Incorrect. Npm sticks modules into a directory hierarchy. Most node.js applications never "mash" code together, nor do they minify it. That's usually only ever done if you're working with the browser, in which very battle-tested systems exist (e.g. webpack). Everything is very deterministic.

[Doctor Syntax]

Re: Maybe the lazy in us expects...

"the implicit contract"

Implicit? As in not worth the paper it's not written on?

[Yet Another Anonymous coward]

Re: Maybe the lazy in us expects...

>It is probably better to just "copy" these functions to your own private space,

And when a vulnerability is found in one of them, you update all the local copies on all the machines you have ever used it on?

Within a coupe of seconds?

[Anonymous Coward]

Re: Maybe the lazy in us expects...

And if a vulnerability is introduced you wish it to spread out in a couple of seconds?

If you pin the version is not much different than making a copy, if you don't you're exposed to any bad change.

[bombastic bob]

Re: Maybe the lazy in us expects...

"> And when a vulnerability is found in one of them, you update all the local copies on all the machines you have ever used it on? within a couple of seconds?"

"And if a vulnerability is introduced you wish it to spread out in a couple of seconds?"

You'd need to scrutinize before including "your own copy", it seems. More work up front, more reliability as a result. So I think I'd rather make the copy, rely on my own ability to spot "code smells", and keep my eyes open for security patches.

And for trivial things that pad the left side of a string, I can write my own.

[Phil O'Sophical]

Re: Maybe the lazy in us expects...

And when a vulnerability is found in one of them, you update all the local copies on all the machines you have ever used it on?

Well, good practice would suggest that you pull one copy from outside to an internal location, test/verify it, and let the rest of your development folks pull a known good copy from there. Any fixes then get the same treatment.

Within a coupe of seconds?

I would hope not, even a cursory security analysis will take at least a few minutes. Why would you need it it seconds anyway?

[Truth4u]

Re: Why would you need it it seconds anyway?

At 4:59pm you might

[Anonymous Coward]

I prefer polyfilling functions so modern browser call the native version directly. It makes it easier to manage, and old browsers can be dropped easily.

[Anonymous Coward]

This is about NPM and node.js. Nothing to do with browser-side Javascript.

[Missing Semicolon]

So, theft is better than failure?

The author of the package - the only person who can decide who can use it - decides to withdraw permission for its use. So the repository steals it, and publishes it anyway?

[Anonymous Coward]

Re: So, theft is better than failure?

I'm assuming NPM's ToS gives them non-revokeable rights to anything you publish there. Which is a good reason not to publish anything there.

[Qix-]

Re: So, theft is better than failure?

You're speculating; don't do that. The author released it under a license that permits anyone to do it. I could have re-published that code under something different and would have been within legal rights.

[Anonymous Coward]

Re: So, theft is better than failure?

They are open source packages, once you release code open source you can't claim ownership over its use. That's the whole point of open source.

[Doctor Syntax]

Re: So, theft is better than failure?

"They are open source packages, once you release code open source you can't claim ownership over its use. That's the whole point of open source."

Maybe. It depends what, if any, licence is attached. A licence is permission to do something. Just because the source is published it doesn't mean a licence was granted.

Unless the ToCs of the site require the author to grant a licence or the author explicitly granted a licence then there isn't one which means there's actually no permission. Continued use then depends on the author's goodwill in not enforcing copyright and the author is entirely within his rights in withdrawing if he feels that's appropriate. So the relevant questions are was a licence granted by publication on the site and if so what were its terms?

[veti]

Re: So, theft is better than failure?

We don't have to guess, we can check out NPM's terms of service for ourselves. Here.

Nothing in this Agreement gives npm any ownership rights in intellectual property that you share with npm Services, such as your Account information or any Packages you share with npm Services (Your Content). Nothing in this Agreement gives you any ownership rights in npm intellectual property provided via npm Services, like software, documentation, trademarks, service marks, logotypes, or other distinguishing graphics.

Between you and npm, you remain solely responsible for Your Content.

Looks pretty clear-cut to me. This was theft.

I think there's a level of basic dysfunction where people try to claim "ownership" of open-source code. You can be open-source, or you can be proprietary - but when you try to combine the two, you get this kind of confuzzlement, and serve you right.

[Anonymous Coward]

Re: So, theft is better than failure?

Agreed. Further on it says NPM may re-add your content if it has an open-source license, but there's nothing to ensure that it does... unlike, say, Youtube... and even if NPM did that, they could still be forced to remove a package that infringes a trademark, for example. And there's nothing NPM can do to remedy IP problems in existing packages if the author(s), if they can even be found, are unwilling.

...as in the case of left-pad.

[Anonymous Coward]

Re: So, theft is better than failure?

Depends on what license it was published. Anyway, if it's an open source one you can usually fork it. So you can still remove it, but others can make a fork. In my opinion is an issue NPM refuses to let you remove code you're still have a 'copyright' on, IMHO the only thing it could do it is to fork it ASAP.

Also I hope they only transferred the module *name* to Kik, not the whole code...

[Nate Amsden]

doesn't fix the issue

of the lazy/broken development model. It took me probably less than 5 minutes to determine NPM was a raging pile of shit when a developer first introduced it to me what seems like 3 years ago now. The fact that the things seem to be constantly breaking and needing bleeding edge versions is bad enough, the auto dependency stuff is of course terrible as well.

My org's latest foray into npm involved having to build a new version of GCC in order to even get the newer NPM shit to even compile(new compiler needed other libs too that broke shit so we had to build a new dedicated VM with the upgraded stuff to isolate it).

[update] Meanwhile my org is also working on our first major PHP upgrade in --- four years. PHP has been very stable as well. Security updates come from Ubuntu even though "upstream" has long abandoned the version of PHP we have I believe.

At least with the most common Perl libraries(and others come to mind too) they are included in many of the larger Linux distributions by default, no need to go to 3rd parties to get many things. My Ubuntu sytsems here seem to have 2,700 perl libraries in the repos. They are pretty stable too, perl 5 is stable and mature at least.

Trying to include NPM stuff in distros is almost a wasted effort because the package is obsolete after 5 minutes.

I first encountered this broken development model about 10 years ago with my first introduction to supporting a ruby on rails app, and it really seems things have just gone downhill since that time.

It gets worse as the newer developers are raised on this culture and don't know any different.

Meanwhile the non technical marketing people have a field day inserting dozens of 3rd party javascript resources into the websites making them slow down quite a bit and even have errors. I had one guy a few years ago link a popup on the production homepage to some code running on an internal-only QA server, then he took off for a vacation within 30 minutes ("it worked in the office - because the office has a VPN to the QA environments" -- what you didn't think seeing "QA" in the hostname meant that the production front page should be pointed at it?)

I'm past the anger, past the tears, I just laugh now. And I give responsibility for this stuff to other people, less stress in my life.

(been working with/supporting developers for the past 16 years now)

[Anonymous Coward]

Re: doesn't fix the issue

We regularly see designers and marketing folks do the same things with images, linking them in from dev servers or internal SharePoint libraries.

[J.G.Harston]

Re: doesn't fix the issue

Ah, the old href=C:\My Documents problem.

[Doctor Syntax]

Which was around first, Nik the messaging app or nik wot Koçulu wrote?

[Qix-]

Kik (the messenger app) was around first.

[Alan Brown]

"Kik (the messenger app) was around first."

And if they'd called their modules kik_im or something like that, this would never have happened.

Legal asshattery has been around for a while - and this isn't the first time opensource modules or projects have been stolen under colour of legal threats - the original CDDB was one of the early casualties of such activities.

[Tom 38]

If they called it kik_im, I'd have quickly found a Russian woman to branch it off to make a new module called kik_im_inna_forks

[Anonymous Coward]

This doesn't solve the problem...

> Announced today, NPM will now no longer allow developers to automatically unpublish an open-source module if the package is older than 24 hours.

The original trigger for this was the threat of a lawsuit made by Kik. So in this new world, the developer would tell NPM: "I'm being sued. You're about to become jointly liable unless you take down everything of mine."

Ten seconds later all his code is gone and we're back where we started. (Unless, of course, you think that NPM will find enough skilled developers to thoroughly understand the intricacies of what they're being asked to remove and the implications of doing so.

[Anonymous Coward]

"Brenna" and "Sarah"

Has political correctness has taken over Javascript package maintainers' genders ?

You could not make it up.

[Kubla Cant]

Re: "Brenna" and "Sarah"

It's striking that women's names are much more common in books and articles about programming than women are in actual programming environments. A similar phenomenon is the way "ethnic" names are used in material aimed at schoolchildren far more than would be warranted by the actual proportion of the corresponding population.

The intention in both cases is to encourage an inclusive attitude to minorities, which is wholly laudable, but the actual effect can be rather patronising.

[Naselus]

Re: "Brenna" and "Sarah"

"The intention in both cases is to encourage an inclusive attitude to minorities, which is wholly laudable, but the actual effect can be rather patronising."

Or simply silly, when aimed at children who can barely read words of more than 5 letters... "Jane, Paul and Ahmadjiniaddan have three apples..."

[Shaha Alam]

Re: "Brenna" and "Sarah"

what if the child's name is "Ahmadjiniaddan", or they have a child in their class called "Ahmadjiniaddan"

kids are far more adaptable than you think. keeping their mind open to variety, diversity and complexity is the only way to keep them from bigotry, xenophobia and isolation.

[Yag]

sigh...

Re : Or simply silly, when aimed at children who can barely read words of more than 5 letters... "Jane, Paul and Ahmadjiniaddan have three apples..."

Or just write "Jane, Paul and Ali have three apples..." instead.

Re : what if the child's name is "Ahmadjiniaddan", or they have a child in their class called "Ahmadjiniaddan"

In this case, there's no point having texts with this name for keeping his mind open to variety, diversity and complexity.

Feels like we're a bit off topic.

[Sorry that handle is already taken.]

Re: "Brenna" and "Sarah"

Or simply silly, when aimed at children who can barely read words of more than 5 letters... "Jane, Paul and Ahmadjiniaddan have three apples..."

Nice straw man argument.

[bombastic bob]

Re: "Brenna" and "Sarah"

(regarding 'political correctness' in use of "ethnic" names)

"but the actual effect can be rather patronising."

EXACTLY! But this is straying off topic, so I'll stop now.

[0x407ab506]

Re: "Brenna" and "Sarah"

Women are a majority, even if few of them want to code.They do sometimes get shit thrown at them for no good reason too.

[Notas Badoff]

Wading through the upchuck

At one point recently I waded through pages and pages of 'hits' on a keyword, trying to find a package that already did a particular widgetty thing somewhere on NPM.js. I know there is one out there - there has to be - but I couldn't find it.

While searching, I got sidetracked into examining some of these 'packages'. Several were empty. More than a couple were *one* line containing the definition of a data variable. Many are separate packages each containing one file, dozens of them exploded out of some proud parent's private parts product.

NPM has become a community wall festooned with wet noodles all looking alike. "Pretty bytes"? I wonder how one is supposed to find that? Without a concerted attempt to organize this pile of ground sausage, NPM will only become more useless.

BTW: Anybody up for claiming package names for sale to highest bidders, ala domain names?

[ecofeco]

There's another reason

A really big reason. Probably the biggest:

If the real problem is a hyper-fractured, super-lazy cheap-ass, skint, ignorant client/boss/employer ecosystem, then perhaps NPM's new hardline policy on unpublishing modules will bake in some much needed glue.

There. That's it.

[Anonymous Coward]

<Cynical>can't unpublish so just change all the functions to return "help I'm locked in here" and update</Cynical>

[Justicesays]

<MoreCynical>can't unpublish so just change all the functions to return "help I'm locked in here" and update sell the password to Russian malvertising syndicate and let them update<MoreCynical>

FTFY

[oldtaku]

The 'Have we Forgotten' thing is silly.

Yes, there are far too many people who just paste together random code snippets and hope it compiles. Outsourcing is almost entirely built on this.

On the other hand, anyone lazy /and/ smart will go with known good functions like these, even if they're just 9 lines long, because the edge cases are a bitch, and you only find them if enough people pound on it.

I guarantee that if you wrote your own slash function on the fly you would get something wrong. Worse, it would mostly work (all your test cases would be fine), then break in the field because of things like the non-ascii which this slash function covers. Better to use a known field hardened component.

[xperroni]

Not lazy, just disorganized

Is it possible that we've become too lazy? Rather than write one-line functions, folks are pulling in outside code, and thus overly relying on dependencies.

I don't think that's the problem. People really shouldn't have to write their own code for base stuff like padding strings or checking object types. I think the real problem is, that code should be in a standard library, not scattered across a dozen projects that live and die at the will of individual developers.

Likewise, if projects in repositories such as NPM depend on one another, what's needed is a system to check such dependencies and prevent operations that would break them. Preventing automatic unpublishing of projects older than 24 hours is at best a makeshift solution, that fails to address the fundamental issue.

Perhaps JavaScript development should transition to a model closer to Linux distributions: a small core of basic components upon which all other projects build; a variety of online code repositories; and a degree of checks and balances regarding who curates those, as opposed to "just" contributing code.

[roeltz]

What happens if I just delete the github repo the npm package is pointing to?

That's what I thought.

[Qix-]

Nothing. Npm doesn't pull from Github.

[scarletherring]

NPM (the package repository) doesn't pull from github, but it's certainly possible to configure your project such that NPM (the commandline tool) will fetch dependencies from github.

[Anonymous Coward]

Mayhem

So any DDOS on this site would be somewhat disruptive then.

[bombastic bob]

Re: Mayhem

(regarding 'eggs in one basket' storage of NPM code on their repository, or git, or anywhere else)

"So any DDOS on this site would be somewhat disruptive then."

pretty much, yeah. 'the cloud' is highly overrated.

[Roland6]

Re: Mayhem

Plus I expect NPM's hosting arrangements are not appropriate for the QoS users are expecting.

The problem is that because systems largely work these days, people not only don't think about reliability to the same extent as in the past, but also look at the cost benefit and decide not to bother...

[thames]

Standard Library

Why doesn't Node.js just have a standard server library for all the common but trivial crap like this? Server applications often do stuff that is different from client stuff, so we shouldn't expect the existing client libraries to do everything required.

A simple approach would be to go through the documentation for the Python standard libraries and write equivalents using Javascript idioms. That would short cut the need to spend time arguing over what ought to be in the Node.js libraries. It would also provide a guide for writing the documentation for it.

The developer of Node.js was interviewed in a podcast where he said that the inspiration for Node.js was lifted from Twisted, a large and successful third party open source Python asynchronous communications framework. He wanted something like that but with a JIT. So he took the Javascript JIT from the Chrome web browser and added an async library to it to give Node.js.

He seems to have forgotten though that one of the biggest things that made Twisted so good is that you can use Python's very large and broad standard libraries with it.

Meanwhile, Pypy (a JIT for Python) now works with Twisted, but Node.js still lacks a wide-ranging standard library.

[Qix-]

This article is pretty disappointing. Not only is it blatantly clear the author of this article doesn't work with Node.js all that much, but it looks as if all of the 'supporting arguments' are either carefully chosen modules and copy-pasted material from npm's blog posts.

Seriously, Sindre has 800+ modules and has roughly 30% market share in terms of downloads. You picked some of his smallest modules. Go checkout github.com/sindresorhus/ava and tell me he doesn't know how to develop.

Programming paradigms differ from language to language. If you can't understand that, you're not a seasoned developer - and claiming otherwise is simply being a detrimental to the development community. Node.js has worked great and has been wildly successful due to its common paradigm of micro-dependencies.

What Azer did was childish. He had no legal right to the name kik and by publishing to npm he therefore agreed to the ToS of the site - which state that the use of trademarked names is subject to the removal of such packages.

Kik (the messenger app) came first. They have a registered trademark to the name Kik. Npm complied. Azer threw a hissy fit. Glorifying him as some MLK of OSS is ridiculous and unfounded.

[diodesign]

Re: Qix-

Actually, I made no comment on the authors of the individual modules. If Sindre wants to churn out and share snippets of code, then more power to him.

You make a good point that micro-dependencies can be unit tested and whathaveyou. But as someone said above, wouldn't it be nice in a standard library, not hundreds of functions masquerading as packages?

Node.js obviously works well on the whole (I didn't say it didn't) but it can't be perfect - last week demonstrated that.

C.

[tiggity]

However Kik the messenger app would not be confused (by any rational developer) with the kik .js script that Azer wrote, it's the usual scenario of trademark owner setting legal attack dogs on non infringing uses of the word. So kudos for Azers reaction - knowing he was going to be bullied by a wealthy company (kik) & another company (NPM) doing it's bidding blindly and had no power of his own, other than pulling all his code in protest - i.e. he would have expected a bit of backbone from NPM in defending its contributors.

[Alan Brown]

"What Azer did was childish. He had no legal right to the name kik and by publishing to npm he therefore agreed to the ToS of the site - which state that the use of trademarked names is subject to the removal of such packages."

You clearly don't understand how trademarks work.

"Kik" could be trademarked by a dozen different companies operating in different arenas.

Companies have to defend their trademarks or lose them, but will only ever prevail in instances where there may be confusion (it's a form of legal registration to try and prevent "passing off" torts)

A module called "kik" which does kickstart functions has nothing to do with Instant Messaging and a judge would see such claims as the overrreach that they obviously are. The problem is that such litigation is almost always a game of who has deeper pockets before it ever gets to court.

This kind of asshattery is primarily promoted by IP lawyers to keep themselves in business. They don't expect the kind of exposure and vilification this one got as normally they get away with it.

[energystar]

To all realistic ends...

"The problem is that such litigation is almost always a game of who has deeper pockets before it ever gets to court."

To all realistic ends Code Property is a Corporative thing. Individuals are not in the power, to fight back ownership -if contested-, as about many other things. Being small is being detached of ownership. If really wanting to protect your work from falling in exploitative hands, should go full GPL v3.

[Anonymous Coward]

"They have a registered trademark to the name Kik."

Dear Qix,

You appear to be wrong. I did not think Kik could be broadly trademarked and so I did a USPTO check - which takes a few seconds.

This is the description for Kik the company:

"The mark consists of the word "kik" in lowercase letters followed by a dot all inside a circular speech bubble, which is all inside a circular disc featuring dots and arcs."

All of that forms the mark. There are over two hundred different trade marks which include the word "kik" somewhere. It's pretty obvious that you cannot trademark the text "kik".

To prevent the spread of disinformation, I suggest you withdraw your post.

"A module called "kik" which does kickstart functions has nothing to do with Instant Messaging and a judge would see such claims as the overrreach that they obviously are. The problem is that such litigation is almost always a game of who has deeper pockets before it ever gets to court." (Another poster)

What you say is entirely correct but is not the issue here. Kik the Canadian company has registered their graphical trademark with a scope that would actually include kik the software module. But it is irrelevant.

If the developer had sent NPM and Kik's lawyers the extract from their own trademark, and proposed to publish the correspondence along with the USPTO entry, I suspect no more would have been heard of it because it was blatantly obviously a false claim of infringement.

[Doctor Syntax]

Well, hi there, Qix-. Are you going to comment on anything else?

[dan1980]

Hang on . . .

So, setting aside whether it's a good idea to have your project rely on such a string of (sometimes elementary) dependencies, let's just accept for the moment that that is simple the way it is and deal with the situation.

The house of cards, in this instance, came crashing down because a particular package was no longer available.

The 'lesson' NPM have taken away from this mess is that the structure is sensitive and if something happens to a package - even a small one - then there can be flow-on repercussions of quite a large scale.

Have they realised the irony where this all started by handing control of a package to a different author? Yes, yes version numbers etc . . . but it's all a little amusing to me.

[MacroRodent]

left-pad

I was quite surprised a while back when I needed a left-pad -like operation and found JavaScript did not include it in the language or built-in libraries. I mean, other languages since FORTRAN have had it in some form since forever.

Maybe this is one reson for the micro-dependencies. JavaScript itself is rather bare. Contrast this with Perl where I rarely need external modules since the language itself comes with almost everything most programs need as built-ins.

[Brewster's Angle Grinder]

Re: left-pad

A proposal is at stage 3 so I presume it's on track to be released in the new version.

[bombastic bob]

Re: left-pad

"I was quite surprised a while back when I needed a left-pad -like operation and found JavaScript did not include it in the language or built-in libraries."

there are a few ways to make this happen. some are more efficient than others. typically you'd use 'trim()' to get rid of space on the right, then substr() to extract a string 'm-n' chars long from a whitespace string (" " or whatever) then concatenate them. pretty trivial. 3 or 4 lines. big whoop.

but yeah, a built-in "right-justify string" function might've been useful.

[MacroRodent]

Re: left-pad

Actually, I wanted to left-pad a small number with leading zeros if needed, i.e. do the equivalent of C sprintf(result, "%02d", somenumber). Yes, I know how to program this, but one should not have to.

[energystar]

A lot of business logic on NPM kin.

"Yes, mine are nnn COPYRIGHTED packages, with some downloads at the 6th magnitude!"

wow [proxy ignorance always pays].

[Anonymous Coward]

Writing your own is NUTS

"Taking on dependencies for these one-liners is just nuts."

No, you cretin. The fact that Javascript's standard library doesn't have a method for left padding a string or telling if an object passed is an array or not, is nuts.

Forced between writing your own version, or including an already written, tested, edge-case considered and debugged version that someone else wrote, the latter is surely the lesser of two evils.

[Anonymous Coward]

Re: Writing your own is NUTS

No, you cretin. The fact that Javascript's standard library doesn't have a method for left padding a string or telling if an object passed is an array or not, is nuts.

I would have upvoted you, but I downvoted you instead because I don't think it is very nice to call people cretins.

cretin /ˈkrɛtɪn/ - noun

1. informal/offensive

a stupid person (used as a general term of abuse).

2. Medicine/dated

a person who is physically deformed and has learning difficulties because of congenital thyroid deficiency.

Origin: late 18th century: from French crétin, from Swiss French crestin ‘Christian’ (from Latin Christianus), here used to mean ‘human being’, apparently as a reminder that, though deformed, cretins were human and not beasts.

[Brewster's Angle Grinder]

Re: Writing your own is NUTS

Javascript has at least two ways of telling if an object is an array. The array example appears to be a polyfill for browsers (*cough* IE 8 *cough*) that lack such a function.

[captain veg]

Re: Writing your own is NUTS

Writing your own is certainly not nuts if the examples in this and related articles are representative of typical library code. Unless by "nuts" you mean "a huge improvement".

-A.

[bombastic bob]

Re: Writing your own is NUTS

"Forced between writing your own version, or including an already written, tested, edge-case considered and debugged version that someone else wrote, the latter is surely the lesser of two evils."

only when you LACK self-confidence in your own abilities. "other people" aren't (by default) BETTER than you. well, when I say 'you' I really mean 'me'. And for trivial things, I'm sure most competent programmers can do this without creating problems [and by doing so, improve overall reliability].

[VinceH]

"According to Perl granddaddy Larry Wall, there are three great virtues of a programmer: impatience, hubris, and laziness. [...] Hubris makes people write high-quality code that they can be proud of."

I'd have thought hubris would make people believe what they had written was high-quality code that they can be proud of, rather than actually make them write it.

Is not the definition of hubris something like excessive pride and arrogance?

[Steve K]

Yes - hubris means overweaning pride and arrogance.

This is more like "pietas"?

Steve

[SVV]

Perls of Wisdom

This piece of pseudo-profundity got on my nerves too, it is nonsense dressed up as sagacity.

Firstly, he defines impatience as "writes quick and dirty code that just gets the job done". This is a poor definition as in practice it encompasses the good (write code that just does the thing required, but write it well and document it) and the terrible (just hack out any old shit that seems to work and don't bother documenting it). Most Perl code I've seen seems to tend towards the latter, unfortunately.

Hubris is indeed overconfidence, usually allied to ignorance and arrogance. It was classically punished by the godess Nemesis. If Page feels that writing high quality code is hubristic , is he then for it (as it is claimed by him as a virtue) or against it (as the meaning of the word should imply)?

Laziness is defined as code reuse. I prefer the term "Efficiency". Reuse also is a nice indicator that the coder has happily not succumbed to Not Invented Here Syndrome. What real laziness results in is generally terrible code, as defined above.

How the hell did a guy gain guru status by spouting nonsense like this?

[Brewster's Angle Grinder]

Re: Perls of Wisdom

I always took "hubris" as implying we should dare to attempt tasks that a saner mind would retreat from. I mean, how many of us have thought "that would be easy" and several years later are still working on the damn thing? That's as pure a distillation as hubris as you'll encounter.

[breakfast]

Re: Perls of Wisdom

I think he gained Guru status creating and supervising Perl. I'm not saying that is entirely laudable, but it has its fans and a lot of the internet ran on it for a very long time.

[Anonymous Coward]

"...a learning experience..."

Given how naively (i.e. badly) the infamous leftpad() function was coded, I think the developer in question needs to shut the hell up about learning experiences for others and have a learning experience of his very own in how to code.

[cloth]

Libraries & Micro Services anyone

Wow - so, node.js doesn't have libs that do the standard edge-cased out stuff (as many others have said already). And... How ironic that people are also complaining about tiny packages in the potentially dawning era of Micro-services.

I've always said that micro-services are a management nightmare waiting to happen. It turns out that we already have such a version of that nightmare - screaming at us!

Ah well - I love it every time somebody tells me that the way they do it is just that little bit better than the last one. Is it any wonder that programming is still in the equivalent age of finding new metals and not the age of building bigger and better bridges from pre-made girders !

And - before anyone quips in. Yes, It's just fine (and sometimes good ) to make new shiny languages/paradigms etc. BUT - make sure they do all the best bits of the previous new shiny thing so we have just a strong as girder as we did last time but shinier and quicker.

[Anonymous Coward]

Copyright?

Am I the only one questioning whether some of these snippets are even long enough for copyright to be applicable? They are not a substansive creative work after all.

[Roland6]

Re: Copyright?

Which in turn raises a question over the copyright of oss projects where contributors don't explicitly assign IP to the project. Because some oss projects could be regarded as simply being a substantive collection of accumulated snippets.

[msknight]

""This policy is a first step towards balancing the rights of individual publishers with npm’s responsibility to maintain the social cohesion of the open source community," added Williams."

Bullshit. This policy allows NPM to screw over individuals and prevent them from exercising their rights to take their bat and ball home.

Kik's apology wasn't worth the forum it was written on. They were dicks, plain and simple, and completely unapologetic for being dicks.

[Jason Bloomberg]

Risk reduced but not gone

The problem ppears to be that a company said "take that down, infringes trademark"; the author replied "GFY". The company told NPM, "take it down, infringes trademark"; NPM obliged. Author then took everything else away.

The good fortune here was that what many relied upon wasn't a direct target of the take down request, could be reinstated.

But what happens if what is relied upon is part of the take down request?

It seems the potential for something many rely upon disappearing is still there. Reduced, but still there.

[Shaha Alam]

when knowledge left the people...

...they looked to the API's as Gods. ever present, ever ready, ever the giver of answers.

Then one day, God didn't answer. and you'll have to write the f**king isArray(String) function yourself.

[0x407ab506]

They stole his code

Even if they stole his code in spirit rather than legally.

The clusterfuck is those silly dependancy tools that rely on sites always having the best version of the code.

And server-side javascript (or PHP).

[bombastic bob]

Re: They stole his code

"And server-side javascript (or PHP)."

don't forget CLIENT-SIDE java script, and the BANDWIDTH THEFT it introduces. It sort of justifies putting it on the server instead (cached intelligently), to avoid a zillion people hitting their bandwidth caps just to download "all that script" from whatever CDNs are hosting it, EVERY! SINGLE! TIME!!

or, for those of us who are 'bandwidth challenged', same thing.

and of course, BAD CODE on a CDN will break the intarwebs, too...

[0x407ab506]

Re: They stole his code

Well said, but there are less choices on the client (even when you aren't trying to be part of the web X)

[JeffyPoooh]

Hubris makes people write high-quality code that they can be proud of.

Hubris also makes people proud of any old crap code that they happen to write.

Want a recent example?

iOS 9.3.

iPhone 5C Security.

[energystar]

Laziness, it is indeed.

Finding one liners repeated by millions on Github is mere randomness. Finding 11th liners is proof.

Even abusing the 'batteries included'. Go make your own. Work on it whenever you have the time [We deserve having the time and resources].

Libraries could be optimal, and optimally tested to their developers' needs and fields. Those are not optimized for your problem at the screen.

[razorfishsl]

Exploit time

Even more dangerous....

If one of these programmers had their account compromised and access was given to the hacker to change the source code... potentially several million instances could be infected.

[Kepler]

Actions Have Consequences

The reasons for NPM's decision and rule change are obvious and substantial. However, the people behind the decision should be mindful of a fundamental principle of economics:

Barriers to exit inevitably end up becoming barriers to entry.

This is true both in international trade and finance, and in antitrust/industrial organization/monopoly theory:

If, by churlish and niggardly enforcement of Section 7 of the Clayton Act, federal authorities (the DOJ and FTC) make it harder for unsuccessful competitors to sell their assets to rivals and exit an industry, forcing them to just eat their losses, future potential entrants will be discouraged from entering new markets in the first place, making those markets less competitive.

(What Dennis Moore said about redistributing the wealth comes to mind!)

And likewise, as the great and under-recognized economist Arnold Harberger has remarked (I'm going from memory here, so this is only a paraphrase), countries that try to keep capital in cannot do so if capital wants badly enough to leave, but they can with considerable ease, and without any intention to do so, keep capital out, by imposing restrictions on its leaving!

The lesson?

In the future, any developer who wants to retain for himself the option of withdrawing his modules if he wants to will think twice now about contributing them in the first place. This is an iron law that cannot be got 'round, and must simply be lived with.

The call made in this instance may well be the right one; I'd say it probably is. But it will have consequences in the future. That fact cannot be avoided.

[Crisp]

My counter argument to David Haney is as follows:

Have you seen what happens when your average programmer tries to roll his own date handling function? Instead of trying to reinvent the wheel, why not use something that actually works?