I've liberated my modules
March 23, 2016 9:00 PM Subscribe
Node Package Manager (npm) is the largest ecosystem of open source libraries in the world, used as part of NodeJS to develop and serve web applications. Earlier this week, this ecosystem went kablooey when one an integral library went way.
One of the package developers, Azer Koçulu, had been approached by lawyers from the messaging application Kik, who disagreed with the name of his module
One of the modules,
This isn't the first time bundling and the naming of names has gone awry. For example, in 2014 Google had issues with companies buying up old names of extensions and silently publishing malicious updates.
Node released their post-mortem of what happened today, as did Kik's head of messenger. (sic)
One of the package developers, Azer Koçulu, had been approached by lawyers from the messaging application Kik, who disagreed with the name of his module
kik. After Node upheld the decision as part of their dispute resolution process, Koçulu responded by unpublishing all of his modules from npm and offered others the opportunity to adopt them for further maintenance. (The names were left running in the wild, though.)One of the modules,
left-pad, was/is a dependency for a great many packages, bringing some npm-managed sites to a halt when it was removed. Eventually Node took the unprecedented step of un-unpublishing the module in order to restore order.This isn't the first time bundling and the naming of names has gone awry. For example, in 2014 Google had issues with companies buying up old names of extensions and silently publishing malicious updates.
Node released their post-mortem of what happened today, as did Kik's head of messenger. (sic)
Pretty much every party involved here looks pretty bad. Azer for being an entitled, spiteful dick, npm for not having made immutability a basic design goal (and, if I understand their model correctly, the resulting gaping security hole for people using version ranges in their package.json if someone unpublished their module and a malicious actor adopted the name and published a new package with a higher version number), the community for its micro-module obsession, and JS itself for never having settled on anything close to a robust standard library. Except for Azer's behavior, these things are mostly accidents of history, but they're still pretty discouraging.
posted by invitapriore at 9:08 PM on March 23, 2016 [15 favorites]
posted by invitapriore at 9:08 PM on March 23, 2016 [15 favorites]
The Unbelievable History of the Express JavaScript Framework
posted by Artw at 9:09 PM on March 23, 2016 [9 favorites]
posted by Artw at 9:09 PM on March 23, 2016 [9 favorites]
I was following this yesterday and the only thing that would make it more amazing is evidence that Kik somehow was suddenly very obviously and painfully inconvenienced by the sudden disappearance of the modules from npm and "compliance" with their fussy trademark quest.
There is a decidedly non-zero chance that this happened somewhere at Kik when one or more devs suddenly found npm and building anything in that realm being suddenly - if I may use the scientific term, here - totally fuxxored.
Ergo, there is also a non-zero chance that dev and legal had a conversation that went something like dev saying "You did wut?" with legal saying something like "What's the big deal? It's our TM!" and I would very much like to see the transcript of this very confusing conversation.
posted by loquacious at 9:11 PM on March 23, 2016 [20 favorites]
There is a decidedly non-zero chance that this happened somewhere at Kik when one or more devs suddenly found npm and building anything in that realm being suddenly - if I may use the scientific term, here - totally fuxxored.
Ergo, there is also a non-zero chance that dev and legal had a conversation that went something like dev saying "You did wut?" with legal saying something like "What's the big deal? It's our TM!" and I would very much like to see the transcript of this very confusing conversation.
posted by loquacious at 9:11 PM on March 23, 2016 [20 favorites]
lol I came to my opinion of Azer by reading his own Medium article, but now I've read those email transcripts and...yeah.
posted by invitapriore at 9:11 PM on March 23, 2016 [4 favorites]
posted by invitapriore at 9:11 PM on March 23, 2016 [4 favorites]
loquacious: The post from Kik's head of messenger (whatever that is) says this did indeed happen:
I found out about this problem like a lot of you, when our builds
started failing because we use the extremely helpful JSCS. Through
a long chain of dependencies, JSCS relied on left-pad@0.0.3, which
was removed by the author yesterday. Our team was confused at the time as well.
posted by xiw at 9:13 PM on March 23, 2016 [15 favorites]
I found out about this problem like a lot of you, when our builds
started failing because we use the extremely helpful JSCS. Through
a long chain of dependencies, JSCS relied on left-pad@0.0.3, which
was removed by the author yesterday. Our team was confused at the time as well.
posted by xiw at 9:13 PM on March 23, 2016 [15 favorites]
ATL, STL, Win32, .Net, Swing...
no surprise the javascript cowboys don't want - and *think* they don't need - a standard library. but they do. for certain, there are design trade-offs and a degree of suck that comes along with that.
i wonder if it's more or less suck than the interminable competing framework races.
Have we forgotten how to program?
pretty much. i don't give a shit how slick your dev-ops platform is and flashy the ui tricks are. know SOLID? can you code an XmlHttpRequest without looking it up?
posted by j_curiouser at 9:15 PM on March 23, 2016 [4 favorites]
no surprise the javascript cowboys don't want - and *think* they don't need - a standard library. but they do. for certain, there are design trade-offs and a degree of suck that comes along with that.
i wonder if it's more or less suck than the interminable competing framework races.
Have we forgotten how to program?
pretty much. i don't give a shit how slick your dev-ops platform is and flashy the ui tricks are. know SOLID? can you code an XmlHttpRequest without looking it up?
posted by j_curiouser at 9:15 PM on March 23, 2016 [4 favorites]
I write enterprise software for financial institutions, and this shit is my nightmare. JS still feels like the Wild West to me. When I'm doing server-side or PC or mobile, development is a very straightforward process with stable languages and frameworks really only needed for heavy-lifting jobs like ORMs. Even Swift, a language that's only a couple of years old and underwent some big revisions from V1 to V2, feels like relatively solid ground compared to this.
But JS web app development is this turtles-all-the-way-down stack of frameworks that leaves you praying to Christ that none of them get abandoned or compromised. You can't even reliably subtract two dollar amounts in JS without a framework. In 2016.
We contracted out to get a client side app done and the result was 5K lines of application code and nine times that in framework code. JS development looks like a cargo cult most places, and I know a ton of really smart coders who won't go near it for exactly that reason.
When I hear people are doing server-side JS I have to wonder why the hell you would do that to yourself. You could literally pick a server-side language at random and have an easier time and none of the sloppy tolerances that JS just takes as normal.
posted by middleclasstool at 9:24 PM on March 23, 2016 [46 favorites]
But JS web app development is this turtles-all-the-way-down stack of frameworks that leaves you praying to Christ that none of them get abandoned or compromised. You can't even reliably subtract two dollar amounts in JS without a framework. In 2016.
We contracted out to get a client side app done and the result was 5K lines of application code and nine times that in framework code. JS development looks like a cargo cult most places, and I know a ton of really smart coders who won't go near it for exactly that reason.
When I hear people are doing server-side JS I have to wonder why the hell you would do that to yourself. You could literally pick a server-side language at random and have an easier time and none of the sloppy tolerances that JS just takes as normal.
posted by middleclasstool at 9:24 PM on March 23, 2016 [46 favorites]
The icing on this shitcake is the implementation of
posted by scose at 9:28 PM on March 23, 2016 [13 favorites]
left-pad. I understand that the Javascript string API makes this task more difficult than many other languages... but still, that O(n) loop of string concatenations practically radiates "bad code". If you're gonna make a library for something trivial, you should at least do it as well as possible, like one of these tricky solutions.posted by scose at 9:28 PM on March 23, 2016 [13 favorites]
According to Azer, npm transferred ownership of his kik module and gave ownership of the code he'd written as open source to the company Kik. If true, and npm, with zero legal documentation from KikCo, gave ownership of open source code to a corporation just because they asked for it, then...yeah, I see no problem with Azer pulling the rest of his code and publishing it somewhere that actually adheres to open source modalities.
That it breaks shit is unfortunate, but npm's decision to republish his work without permission, by wrapping themselves in the open source flag they just piddled upon to placate KikCo is rich.
posted by SecretAgentSockpuppet at 9:29 PM on March 23, 2016 [30 favorites]
That it breaks shit is unfortunate, but npm's decision to republish his work without permission, by wrapping themselves in the open source flag they just piddled upon to placate KikCo is rich.
posted by SecretAgentSockpuppet at 9:29 PM on March 23, 2016 [30 favorites]
... not that I'm on npm or kik's side. they both behaved terribly.
posted by scose at 9:31 PM on March 23, 2016
posted by scose at 9:31 PM on March 23, 2016
Azer merely didn't go out of his way to be nice. Kik acted like assholes (you're not merely making a "polite request" if the follow-up a "no" is "[we're gonna have lawyers] banging on your door and taking down your accounts"), and npm acted like idiots in the entire design of their system, and their response shows they still don't get it. Meanwhile, the entire JS community looks like fools, if nothing else for having rediculous notions of what belongs in a library.
posted by zachlipton at 9:36 PM on March 23, 2016 [12 favorites]
posted by zachlipton at 9:36 PM on March 23, 2016 [12 favorites]
When I hear people are doing server-side JS I have to wonder why the hell you would do that to yourself.
JavaScript occupies a sweet-spot of being an imperative dynamic language (familiar, with quick dev feedback and easy prototyping) with an extremely fast JIT compiling interpreter and a language-wide async programming model already in place, so with not too much effort you can write a latency-sensitive service that handles a decent number of concurrent connections. There are orgs out there for whom that feature set satisfies their needs perfectly, though I tend to think it's kind of an unstable area in that feature space, and most of those orgs either do or should end up eventually replacing Node with something else.
posted by invitapriore at 9:38 PM on March 23, 2016 [8 favorites]
JavaScript occupies a sweet-spot of being an imperative dynamic language (familiar, with quick dev feedback and easy prototyping) with an extremely fast JIT compiling interpreter and a language-wide async programming model already in place, so with not too much effort you can write a latency-sensitive service that handles a decent number of concurrent connections. There are orgs out there for whom that feature set satisfies their needs perfectly, though I tend to think it's kind of an unstable area in that feature space, and most of those orgs either do or should end up eventually replacing Node with something else.
posted by invitapriore at 9:38 PM on March 23, 2016 [8 favorites]
Thanks for including the Medium post, zamboni. I grabbed the first line for the title but forgot to include it!
(Also the last tag comes from this tweet today, which I found strangely appropriate.)
posted by fifteen schnitzengruben is my limit at 9:38 PM on March 23, 2016 [2 favorites]
(Also the last tag comes from this tweet today, which I found strangely appropriate.)
posted by fifteen schnitzengruben is my limit at 9:38 PM on March 23, 2016 [2 favorites]
On the plus side, rubbernecking this evolving situation in my various Slack groups today has netted two excellent new trash fire GIFs:
posted by migurski at 9:40 PM on March 23, 2016 [23 favorites]
rediculous notions
apparently, even advocates of weak, dynamic typing don't actually like weak, dynamic typing.
posted by j_curiouser at 9:49 PM on March 23, 2016 [4 favorites]
apparently, even advocates of weak, dynamic typing don't actually like weak, dynamic typing.
posted by j_curiouser at 9:49 PM on March 23, 2016 [4 favorites]
The problem isn't micro-modules--the arguments around composability, code reuse and the unix philosophy make a lot of sense. The problem is that the JS community, which has been in an extended pratfall for... well, they've never not been a plate-juggling act in the middle of a coughing fit... is that they've combined micro-modules with micro-sourcing: the ease with which npm allows publishing and bundling modules means you're in a wide-open circus where your micro-modules have no collective providence or coherence or larger organization because you're grabbing whatever comes up first in npm search, along with whatever anyone else randomly selected as a satisfactory lego brick when they started. npm made publishing easy by making it shallow.
The result is this sort of monstrosity detailed in the "have we forgotten how to program" link above:
The problem with left-pad isn't that it's just left-pad, it's that it's left-pad from azer and right-pad from someone else and center-pad from a third party. 100 micro-modules from 3 sources is plausibly a conscious choice; 41,000 from 1,000 different parties is just surrendering to the tide and hoping that 1 out of that number doesn't have a bad day or just a regular day of being a dick. We talk about attack surface in security as "larger is worse", but somehow the JS community is oblivious to the vulnerability surface that shallow, recursive dependency resolution entails.
Once my paintings start selling, this will totally not be my day job anymore!
posted by fatbird at 9:51 PM on March 23, 2016 [30 favorites]
The result is this sort of monstrosity detailed in the "have we forgotten how to program" link above:
A fresh install of the Babel package includes 41,000 files... A blank jspm/npm-based app template now starts with 28,000+ filesContrast this with lodash, which allows including its pieces individually, so you can literally bundle single function modules that you pick and choose, and get just those, and then all the goodness of pure functional micro-modules is yours, but with the added benefit of a provider who's been around, offers a pretty complete utility library, and has some collective credibility and maintenance responsibility for the larger package.
The problem with left-pad isn't that it's just left-pad, it's that it's left-pad from azer and right-pad from someone else and center-pad from a third party. 100 micro-modules from 3 sources is plausibly a conscious choice; 41,000 from 1,000 different parties is just surrendering to the tide and hoping that 1 out of that number doesn't have a bad day or just a regular day of being a dick. We talk about attack surface in security as "larger is worse", but somehow the JS community is oblivious to the vulnerability surface that shallow, recursive dependency resolution entails.
Once my paintings start selling, this will totally not be my day job anymore!
posted by fatbird at 9:51 PM on March 23, 2016 [30 favorites]
BTW, if this whole slow train wreck of clowns doesn't horrify you enough, here's a choice tidbit raised again to signal how basically compromised the language is: JavaScript doesn't have integers; they're really floating point numbers, with every floating point approximation issue that regular floating points do.
I just tested this in Chrome's console:
posted by fatbird at 10:00 PM on March 23, 2016 [50 favorites]
I just tested this in Chrome's console:
> 10000000000000000000000 == 10000000000000000000001This is why you can't do anything real in JS without libraries, and why the JS community was so quick to embrace micro-modules: because anything that offers just a hint of predictably is like the flotsam after an ocean liner goes down. If it floats, it works, and it'll keep you on the surface just a little longer.
<- true
posted by fatbird at 10:00 PM on March 23, 2016 [50 favorites]
Well said fatbird. The unix philosophy long ago decided that small composable modules are great, but each one shouldn't be a standalone open source project. Small utilities were bundled together in packages like coreutils (which is, in turn, a combination of several older packages of tools), so that chmod, cat, tee, and friends can all be maintained, versioned, and installed together. Linux distributions perform a similar aggregation step at a higher level.
posted by zachlipton at 10:17 PM on March 23, 2016 [6 favorites]
posted by zachlipton at 10:17 PM on March 23, 2016 [6 favorites]
So, is there any way that the underlying problems of broad, shallow dependency get fixed? Or is this just going to be one of those problems that keeps recurring?
posted by klangklangston at 10:21 PM on March 23, 2016
posted by klangklangston at 10:21 PM on March 23, 2016
Having spent the last seven weeks of my life trying to bring myself up to speed in the AngularJS flavor of the Node ecosystem, I definitely see the appeal of the overall paradigm.
Everything is on Github and open source. So if you hit a bug, patch it and submit a pull request. Much simpler and more open than I remember CPAN being with it's arcane rules and procedures. In theory it also fosters a sense of community. Although in practice it can be hard to feel safe trying to participate, as with Stack Overflow as was pointed out last week.
Easy to use tools like npm, bower, and gulp to manage the environment, install libraries, and manage the build process. It's a low drag way get started. You can go from a bare box to something that will develop, compile, run, and serve a Single Page Application hitting a document store back-end like Firebase in less than an hour.
At least part of the reason I chose the tools I have is they seem like the path of least resistance. I looked at Stackshare and saw what the big outfits were using and went from there.
I do have to admit that at least part of my thinking was that if we get to MVP and start to try and attract investment, using the tools I've made my living with in the past would seem like a liability. I worried that if we weren't using Node, etc., we'd seem like old fogeys and not get any traction with investors or potential employees. It is quite frustrating though. Just last night I likened it to trying to build a bridge with popsicle sticks instead of 2×4s to my business partner.
On the other hand, my eight-year-old Catalyst app keeps on ticking over with basically no maintenance required. I'm not sure how true that will be for Angular, etc.
P.S. Although I wish I had seen Artw's comment linking the State of the Art in JavaScript 2016 eight weeks ago, as I was making all those decisions at the beginning of February. I am aware that it wasn't published until the end of February, but by then the die was cast and I'd have to start over for the fourth time to change now.
posted by ob1quixote at 10:33 PM on March 23, 2016 [6 favorites]
Everything is on Github and open source. So if you hit a bug, patch it and submit a pull request. Much simpler and more open than I remember CPAN being with it's arcane rules and procedures. In theory it also fosters a sense of community. Although in practice it can be hard to feel safe trying to participate, as with Stack Overflow as was pointed out last week.
Easy to use tools like npm, bower, and gulp to manage the environment, install libraries, and manage the build process. It's a low drag way get started. You can go from a bare box to something that will develop, compile, run, and serve a Single Page Application hitting a document store back-end like Firebase in less than an hour.
At least part of the reason I chose the tools I have is they seem like the path of least resistance. I looked at Stackshare and saw what the big outfits were using and went from there.
I do have to admit that at least part of my thinking was that if we get to MVP and start to try and attract investment, using the tools I've made my living with in the past would seem like a liability. I worried that if we weren't using Node, etc., we'd seem like old fogeys and not get any traction with investors or potential employees. It is quite frustrating though. Just last night I likened it to trying to build a bridge with popsicle sticks instead of 2×4s to my business partner.
On the other hand, my eight-year-old Catalyst app keeps on ticking over with basically no maintenance required. I'm not sure how true that will be for Angular, etc.
P.S. Although I wish I had seen Artw's comment linking the State of the Art in JavaScript 2016 eight weeks ago, as I was making all those decisions at the beginning of February. I am aware that it wasn't published until the end of February, but by then the die was cast and I'd have to start over for the fourth time to change now.
posted by ob1quixote at 10:33 PM on March 23, 2016 [6 favorites]
"Where I am from, the point of digging is not freedom from digging"
posted by Itaxpica at 10:47 PM on March 23, 2016 [10 favorites]
posted by Itaxpica at 10:47 PM on March 23, 2016 [10 favorites]
Also:
JavaScript is dying for a real standard library.
I cannot say enough nice things about Closure
posted by Itaxpica at 10:49 PM on March 23, 2016 [5 favorites]
JavaScript is dying for a real standard library.
I cannot say enough nice things about Closure
posted by Itaxpica at 10:49 PM on March 23, 2016 [5 favorites]
"know SOLID?"
Yes
"can you code an XmlHttpRequest without looking it up?"
No. Why the hell would I waste long-term memory on that and handling it's edge cases?
I can't write any 6502 assembly from memory either; haven't been able to since shortly after I stopped programming in it regularly.
posted by lastobelus at 11:03 PM on March 23, 2016 [8 favorites]
Yes
"can you code an XmlHttpRequest without looking it up?"
No. Why the hell would I waste long-term memory on that and handling it's edge cases?
I can't write any 6502 assembly from memory either; haven't been able to since shortly after I stopped programming in it regularly.
posted by lastobelus at 11:03 PM on March 23, 2016 [8 favorites]
I don't pay too much attention to node, but I have a contract coming up later in April which I said I'd do in Express.
Do node folk in the thread advise I try and get the client to agree on something else or should this be well-sorted by then?
posted by lastobelus at 11:07 PM on March 23, 2016
Do node folk in the thread advise I try and get the client to agree on something else or should this be well-sorted by then?
posted by lastobelus at 11:07 PM on March 23, 2016
Azer merely didn't go out of his way to be nice. Kik acted like assholes (you're not merely making a "polite request" if the follow-up a "no" is "[we're gonna have lawyers] banging on your door and taking down your accounts")
Well, let's look at the WHOLE quote, huh? Kik specifically pointed out that they have to enforce the trademark or lose it, which is true. You can take it as a veiled threat, but within context they said absolutely everything they could possibly have said to explain the difficulties of their situation and to express their willingness to do what it takes to resolve the situation without the need for legal shit, including compensation.
Azer literally said "fuck you." It takes an awfully selective reading of that exchange to see it as kik being dicks. And pretty selective quoting, frankly, to portray it that way.
Well, let's look at the WHOLE quote, huh? Kik specifically pointed out that they have to enforce the trademark or lose it, which is true. You can take it as a veiled threat, but within context they said absolutely everything they could possibly have said to explain the difficulties of their situation and to express their willingness to do what it takes to resolve the situation without the need for legal shit, including compensation.
Azer literally said "fuck you." It takes an awfully selective reading of that exchange to see it as kik being dicks. And pretty selective quoting, frankly, to portray it that way.
Bob Stratton (Mar 11, 11:26)posted by shmegegge at 11:07 PM on March 23, 2016 [18 favorites]
We don’t mean to be a dick about it, but it’s a registered Trademark in most countries around the world and if you actually release an open source project called kik, our trademark lawyers are going to be banging on your door and taking down your accounts and stuff like that — and we’d have no choice but to do all that because you have to enforce trademarks or you lose them.
Can we not come to some sort of a compromise to get you to change the name without involving lawyers? Is there something we could do for you in compensation to get you to change the name?
Bob Stratton
kik Interactive
Azer (Mar 11, 12:34)
hahah, you’re actually being a dick. so, fuck you. don’t e-mail me back.
This is why you put the libraries your app depends on right in the VCS. Those modules are integral to your app.
posted by davel at 11:12 PM on March 23, 2016 [5 favorites]
posted by davel at 11:12 PM on March 23, 2016 [5 favorites]
Well they only have to defend the trademark if the name space overlaps. Kik the company is a messaging app. Kik the code library isn'twasn't.
Of course these sorts of fights almost always go to the people with the biggest legal team.
posted by Mitheral at 11:14 PM on March 23, 2016 [6 favorites]
Of course these sorts of fights almost always go to the people with the biggest legal team.
posted by Mitheral at 11:14 PM on March 23, 2016 [6 favorites]
Kik specifically pointed out that they have to enforce the trademark or lose it, which is true.
It's the phrasing from Bob to npm that follows that makes one of my skeptical eyes open wide:
OK, so it doesn’t seem to be possible to resolve this amicably. Can you guys help?
When people in a situation of (legal) power don't get what they want up-front, and then immediately go up the food chain until they get want they want, that's behaving like an entitled dick. These people poison every interaction between human beings at every level of civilized society. Fuck Entitled Bob and fuck his entitled bosses.
posted by a lungful of dragon at 11:14 PM on March 23, 2016 [15 favorites]
It's the phrasing from Bob to npm that follows that makes one of my skeptical eyes open wide:
OK, so it doesn’t seem to be possible to resolve this amicably. Can you guys help?
When people in a situation of (legal) power don't get what they want up-front, and then immediately go up the food chain until they get want they want, that's behaving like an entitled dick. These people poison every interaction between human beings at every level of civilized society. Fuck Entitled Bob and fuck his entitled bosses.
posted by a lungful of dragon at 11:14 PM on March 23, 2016 [15 favorites]
That tired good-cop bad-cop routine about having to enforce your trademark is very much kind of being a dick, especially with the "banging on your door and taking down your accounts" phrasing.
posted by Pyry at 11:15 PM on March 23, 2016 [14 favorites]
posted by Pyry at 11:15 PM on March 23, 2016 [14 favorites]
So, is there any way that the underlying problems of broad, shallow dependency get fixed? Or is this just going to be one of those problems that keeps recurring?
Like everything else, once enough people have been stung, some minimal best practices will be relearnt... until the next sexy young coding fad comes along with a great "this time it's different!" story.
npm is already addressing the immediate deficiencies that allowed this to happen, and the trend towards larger, decomposable libraries like lodash, away from a buffet of standalones, is underway. "Tree shaking" is gaining steam, where unused library code can be removed, also recommends larger, more stable libraries over micro-dependencies offering minimal weight.
I have a contract coming up later in April which I said I'd do in Express.
Talk seriously about alternatives. Express is a dead man walking: owned by IBM and with the key people making ugly departures.
posted by fatbird at 11:17 PM on March 23, 2016 [2 favorites]
Like everything else, once enough people have been stung, some minimal best practices will be relearnt... until the next sexy young coding fad comes along with a great "this time it's different!" story.
npm is already addressing the immediate deficiencies that allowed this to happen, and the trend towards larger, decomposable libraries like lodash, away from a buffet of standalones, is underway. "Tree shaking" is gaining steam, where unused library code can be removed, also recommends larger, more stable libraries over micro-dependencies offering minimal weight.
I have a contract coming up later in April which I said I'd do in Express.
Talk seriously about alternatives. Express is a dead man walking: owned by IBM and with the key people making ugly departures.
posted by fatbird at 11:17 PM on March 23, 2016 [2 favorites]
It's the phrase from Bob to npm that follows that makes one of my skeptical eyes open wide:
OK, so it doesn’t seem to be possible to resolve this amicably. Can you guys help?
When people in a situation of (legal) power don't get what they want up-front, and then immediately go up the food chain until they get want they want, that's behaving like an entitled dick.
Well if they have to enforce their trademark, what choice do they have?
posted by shmegegge at 11:19 PM on March 23, 2016
OK, so it doesn’t seem to be possible to resolve this amicably. Can you guys help?
When people in a situation of (legal) power don't get what they want up-front, and then immediately go up the food chain until they get want they want, that's behaving like an entitled dick.
Well if they have to enforce their trademark, what choice do they have?
posted by shmegegge at 11:19 PM on March 23, 2016
Also, is approaching NPM not the appropriate method of dispute resolution for node, if both sides can't agree? I don't code, so I have no idea.
posted by shmegegge at 11:21 PM on March 23, 2016
posted by shmegegge at 11:21 PM on March 23, 2016
Azer literally said "go fuck yourself." It takes an awfully selective reading of that exchange to see it as kik being dicks. And pretty selective quoting, frankly, to portray it that way.
My point is that Kik claimed they initially made a polite request, was told no reasonably politely, then threatened lawyers "banging on your door and taking down your accounts." Maybe this is an ask vs. guess culture thing, but it's not a polite request when the immediate response to "Sorry, I’m building an open source project with that name" is to threaten, perhaps hyperbolically, harm. That's the legal threat equivalent of holding the gun behind your back when you ask the bank teller for the money, only to point it at the teller when he doesn't hand you the cash quickly enough. Everybody knows Kik's intent all along was to take the name by whatever means you could, and they're just looking for brownie points by being slightly less nasty in their first email.
In any event, no, you do not have to be an asshole to the entire world to avoid losing your trademark: Trademark Law Does Not Require Companies To Tirelessly Censor the Internet. Kik has a trademark that grants certain rights. Whether those rights extend to every usage of those three letters in any form of computer-related matter is not at all a slam dunk. If Kik named its npm package 'kik-messenger' or 'kik-api' and Azer kept his package at 'kik', it would be hard to prove that professional developers would be sufficiently flummoxed by the situation so as to cause real confusion.
posted by zachlipton at 11:22 PM on March 23, 2016 [13 favorites]
My point is that Kik claimed they initially made a polite request, was told no reasonably politely, then threatened lawyers "banging on your door and taking down your accounts." Maybe this is an ask vs. guess culture thing, but it's not a polite request when the immediate response to "Sorry, I’m building an open source project with that name" is to threaten, perhaps hyperbolically, harm. That's the legal threat equivalent of holding the gun behind your back when you ask the bank teller for the money, only to point it at the teller when he doesn't hand you the cash quickly enough. Everybody knows Kik's intent all along was to take the name by whatever means you could, and they're just looking for brownie points by being slightly less nasty in their first email.
In any event, no, you do not have to be an asshole to the entire world to avoid losing your trademark: Trademark Law Does Not Require Companies To Tirelessly Censor the Internet. Kik has a trademark that grants certain rights. Whether those rights extend to every usage of those three letters in any form of computer-related matter is not at all a slam dunk. If Kik named its npm package 'kik-messenger' or 'kik-api' and Azer kept his package at 'kik', it would be hard to prove that professional developers would be sufficiently flummoxed by the situation so as to cause real confusion.
posted by zachlipton at 11:22 PM on March 23, 2016 [13 favorites]
Kik went about this all wrong, wrapping what could have been a polite request in a threat. It was tone deaf and no a trademark holder doesn't get the right to all uses of the string that is in their mark.
That Kik's actions, escalating to a takeover of the developer's namespace, resulted in a reaction that broke their software, well, I don't think it should have happened, but boy is it hard to sympathize with them.
If you make a request of someone, no is an acceptable response. If it isn't, and you escalate and seize something, then clearly the threat was there from the beginning.
posted by zippy at 11:25 PM on March 23, 2016 [14 favorites]
That Kik's actions, escalating to a takeover of the developer's namespace, resulted in a reaction that broke their software, well, I don't think it should have happened, but boy is it hard to sympathize with them.
If you make a request of someone, no is an acceptable response. If it isn't, and you escalate and seize something, then clearly the threat was there from the beginning.
posted by zippy at 11:25 PM on March 23, 2016 [14 favorites]
Well if they have to enforce their trademark, what choice do they have?
Whether or not their behavior was constrained by legal considerations, that doesn't mean they aren't a bunch of dicks. Their choice as a commercial entity was to force adverse consequences on non-commercial and commercial developers who use open-source software that had nothing to do with their legal dispute. The imbalance of power, the exercise of that imbalance of power to get what they want — strike that, the casual and cool and self-assured exercise of power without regard for others — makes them a bunch of dicks.
posted by a lungful of dragon at 11:27 PM on March 23, 2016 [5 favorites]
Whether or not their behavior was constrained by legal considerations, that doesn't mean they aren't a bunch of dicks. Their choice as a commercial entity was to force adverse consequences on non-commercial and commercial developers who use open-source software that had nothing to do with their legal dispute. The imbalance of power, the exercise of that imbalance of power to get what they want — strike that, the casual and cool and self-assured exercise of power without regard for others — makes them a bunch of dicks.
posted by a lungful of dragon at 11:27 PM on March 23, 2016 [5 favorites]
BTW, if this whole slow train wreck of clowns doesn't horrify you enough, here's a choice tidbit raised again to signal how basically compromised the language is: JavaScript doesn't have integers; they're really floating point numbers, with every floating point approximation issue that regular floating points do.
Well a double float does represent integers exactly up to... 2^53 I think - which you are exceeding because you tried to but that's not the most common failure case in the world for JS programs. Or it wasn't until people started trying to port everything in the world to JS. What's annoying though is not being able to do integer division ever except by explicitly rounding.
posted by atoxyl at 11:34 PM on March 23, 2016 [2 favorites]
Well a double float does represent integers exactly up to... 2^53 I think - which you are exceeding because you tried to but that's not the most common failure case in the world for JS programs. Or it wasn't until people started trying to port everything in the world to JS. What's annoying though is not being able to do integer division ever except by explicitly rounding.
posted by atoxyl at 11:34 PM on March 23, 2016 [2 favorites]
Two pieces of prior art come to mind.
posted by daveliepmann at 11:38 PM on March 23, 2016 [12 favorites]
There are only two hard problems in Computer Science: cache invalidation and naming things.And, from Programming Sucks [There Will Always Be Darkness]:
—Phil Karlton
The Internet Is Its Own Special HellscapeI am trying very hard to avoid programming-language-tribalism and tool-shaming, but as a developer sometimes forced to work in JavaScript (because it's how things get done on the internet), I'll be very glad when the majority of people use JS as a compile target so we can all work in more civilized environments. Itaxpica is right: Google Closure is a great step towards smoothing out JavaScript's rough patches.
On the internet, it's okay to say, "You know, this kind of works some of the time if you're using the right technology," and BAM! it's part of the internet now. Anybody with a couple of hundred dollars and a computer can snag a little bit of the internet and put up whatever awful chunks of hack code they want and then attach their little bit to a bunch of big bits and everything gets a little bit worse.
posted by daveliepmann at 11:38 PM on March 23, 2016 [12 favorites]
...the point of the second quote not being "internet programmers are awful" but the opposite: everything is broken on the internet, all of the time, there is no escape, even for the best of us, because it is in fact inherently really hard.
posted by daveliepmann at 11:40 PM on March 23, 2016 [10 favorites]
posted by daveliepmann at 11:40 PM on March 23, 2016 [10 favorites]
Really browsers should just define an incredibly sandboxed virtual machine and a set of very fast primitive drawing operations rather than this current hodge-podge of trying to trick javascript+html+css into rendering an application that a high school student could make in visual basic in an afternoon.
posted by Pyry at 11:43 PM on March 23, 2016 [14 favorites]
posted by Pyry at 11:43 PM on March 23, 2016 [14 favorites]
I hate JS and the whole ecosystem of me-too client side frameworks. It's a house of cards with a staggering number of points of failure.
posted by GallonOfAlan at 11:52 PM on March 23, 2016
posted by GallonOfAlan at 11:52 PM on March 23, 2016
Also what Pyry said. Web development in 2016 should involve less insane complexity.
posted by GallonOfAlan at 11:59 PM on March 23, 2016
posted by GallonOfAlan at 11:59 PM on March 23, 2016
What was that about compiled code? WebAssembly: a new binary format for the web.
I can sorta see why they're doing this (cramming everything into a compressable, binary blob would be great for high-latency connections like phones, for example), but it does seem somewhat against the whole "Here is the open web, copy text and images from one computer to another" web that we started out building.
posted by fifteen schnitzengruben is my limit at 12:08 AM on March 24, 2016 [2 favorites]
I can sorta see why they're doing this (cramming everything into a compressable, binary blob would be great for high-latency connections like phones, for example), but it does seem somewhat against the whole "Here is the open web, copy text and images from one computer to another" web that we started out building.
posted by fifteen schnitzengruben is my limit at 12:08 AM on March 24, 2016 [2 favorites]
I like this old talk about why the web sucks, and this more recent talk too.
Programming seems to be in an interesting time, when what seemed like a lot of best practices and ideas back in the 90s or so have resulted in getting into this hole, but everyone is too concerned with digging faster.
posted by nom de poop at 12:58 AM on March 24, 2016
Programming seems to be in an interesting time, when what seemed like a lot of best practices and ideas back in the 90s or so have resulted in getting into this hole, but everyone is too concerned with digging faster.
posted by nom de poop at 12:58 AM on March 24, 2016
Not everyone is concerned with digging faster. Those of us who've been around long enough to have been burned by our own code, years later, have this kind of inbuilt horror when we see the shambles that is modern JavaScript and NPM.
But if you're in a growing market and you're trying to hire developers, and fully 80% of them have experience in Node and, if you're lucky Rails (shudder) then it's really really hard to say "nah, I think we'll wait and slowly build a team that can write something that'll last"
Because you know what? Product doesn't care. They want the shiny, and they want it now, and they have all the money.
I spoke to an acquaintance today who's quitting the IT world to become a skydiving instructor. I can't say that I blame him.
posted by nonspecialist at 2:10 AM on March 24, 2016 [10 favorites]
But if you're in a growing market and you're trying to hire developers, and fully 80% of them have experience in Node and, if you're lucky Rails (shudder) then it's really really hard to say "nah, I think we'll wait and slowly build a team that can write something that'll last"
Because you know what? Product doesn't care. They want the shiny, and they want it now, and they have all the money.
I spoke to an acquaintance today who's quitting the IT world to become a skydiving instructor. I can't say that I blame him.
posted by nonspecialist at 2:10 AM on March 24, 2016 [10 favorites]
I have a couple of colleagues who just can't figure out why I have so little interest in React or Bacon.js or whatever. This is a pretty good demonstration of why. There is no shortage of cool stuff going on in the javascript ecosystem, but there is almost no wisdom whatsoever in it. There are no real plans for the future because it's all effectively disposable software. This can work if your app is your business and there's a larger strategic case to be made for constantly rewriting it, but if you aren't in one of those rare circumstances, using these disposable libraries basically means you have a disposable app. There are startup contexts (or startup-like, e.g. "move fast and break things") where it makes sense to develop in this way, or at least, where it can be justified as a means of shipping sooner. The thing is, most software is not developed in this context. For most software, the pressure to run the latest version of your dependencies creates a situation where every time you update one of them, you waste another chunk of time on a problem whose solution provides no value, and which may likely cascade out into other dependencies, creating more problems and taking even more time. It also creates a situation where if you build an app that for whatever reason runs unchanged in production for a long period of time, say a year or longer, and you pick it back up, you are likely looking at a substantial investment of time just to get back up to speed with the latest revision of the universe.
posted by feloniousmonk at 3:29 AM on March 24, 2016 [11 favorites]
posted by feloniousmonk at 3:29 AM on March 24, 2016 [11 favorites]
JavaScript doesn't have integers; they're really floating point numbers, with every floating point approximation issue that regular floating points do.
I've never really gotten into JavaScript--my personal language history is more or less BASIC to Pascal to C to C++ to Java to C# to Python, with a couple of stops along the way for godawful proprietary niche languages. I'll occasionally feel a pang of regret when reading job ads, but stuff like the above quote makes me feel a lot better about things.
posted by Mr. Bad Example at 3:53 AM on March 24, 2016 [3 favorites]
I've never really gotten into JavaScript--my personal language history is more or less BASIC to Pascal to C to C++ to Java to C# to Python, with a couple of stops along the way for godawful proprietary niche languages. I'll occasionally feel a pang of regret when reading job ads, but stuff like the above quote makes me feel a lot better about things.
posted by Mr. Bad Example at 3:53 AM on March 24, 2016 [3 favorites]
I'm so glad that I've gone back to being a Ruby dev so I don't have to deal with npm. Oh wait, I just spent all of Tuesday morning trying to get "bundle install" to do anything useful. Never mind.
posted by octothorpe at 4:17 AM on March 24, 2016 [2 favorites]
posted by octothorpe at 4:17 AM on March 24, 2016 [2 favorites]
I had assumed on first read that big bad Kik came along to the scrappy open source coder saying "Take this down or else!"
but on further reading that doesn't seem to be the case, like, at all!
The kik guy said:
Can we call our thing Kik, because y'know that's our name.
He said, no I'm making a thing called kik
They said, Uh... you legally can't. Obviously. But we'll give you cash for the name.
He said fuck you
they said, c'mon dude.
He said you are all dicks give me $30k
They said, reasonable irked, uh npm, cmon.
His medium post is a total misrepresentation of the facts.
NPM isn't innocent here. but Kik didn't come in all lawyers blazing.
Also, looking at the github for Azer's kik, there's barely any code, it's an idea at best.
I might just be in a curmudgeonly mood today but I have no sympathy for him, and really not much for all the people whose code broke because they imported a bizarre trivial function that they should have written themselves.
posted by Just this guy, y'know at 4:24 AM on March 24, 2016 [5 favorites]
but on further reading that doesn't seem to be the case, like, at all!
The kik guy said:
Can we call our thing Kik, because y'know that's our name.
He said, no I'm making a thing called kik
They said, Uh... you legally can't. Obviously. But we'll give you cash for the name.
He said fuck you
they said, c'mon dude.
He said you are all dicks give me $30k
They said, reasonable irked, uh npm, cmon.
His medium post is a total misrepresentation of the facts.
NPM isn't innocent here. but Kik didn't come in all lawyers blazing.
Also, looking at the github for Azer's kik, there's barely any code, it's an idea at best.
I might just be in a curmudgeonly mood today but I have no sympathy for him, and really not much for all the people whose code broke because they imported a bizarre trivial function that they should have written themselves.
posted by Just this guy, y'know at 4:24 AM on March 24, 2016 [5 favorites]
MS-DOS with Turbo Pascal 7 is looking better, and better as time goes on... it only lacked standard networking.
posted by MikeWarot at 4:26 AM on March 24, 2016 [6 favorites]
posted by MikeWarot at 4:26 AM on March 24, 2016 [6 favorites]
Atlas shrugs, and a million web apps die screaming.
posted by acb at 4:28 AM on March 24, 2016 [2 favorites]
posted by acb at 4:28 AM on March 24, 2016 [2 favorites]
Mr. Bad Example > "to Python"
Yup, you're covered there ;) https://pypi.python.org/pypi/left-pad/0.0.3
posted by Auz at 4:34 AM on March 24, 2016 [4 favorites]
Yup, you're covered there ;) https://pypi.python.org/pypi/left-pad/0.0.3
posted by Auz at 4:34 AM on March 24, 2016 [4 favorites]
The function must be for things like fixed-width text fields, which is how the mainframe Gods want their sacrifices formatted. The whole debacle is a sign that they are angry. If I were a COBOL programmer I think I'd stay inside today.
posted by thelonius at 4:36 AM on March 24, 2016 [2 favorites]
posted by thelonius at 4:36 AM on March 24, 2016 [2 favorites]
> They said, Uh... you legally can't.
Kik (the company) are wrong, then. They could have offered an agreement with Azer to mutually use the kik name in noncompetitive arenas, like Apple (the tech company) and Apple (the music publisher) had. Or they could have acknowledged that the name of a free software code snippet is not an assertion of broader intellectual property any more than the name of a goldfish is, and let the matter lie.
Either approach would have won them goodwill and cost nearly nothing.
posted by ardgedee at 4:37 AM on March 24, 2016 [13 favorites]
Kik (the company) are wrong, then. They could have offered an agreement with Azer to mutually use the kik name in noncompetitive arenas, like Apple (the tech company) and Apple (the music publisher) had. Or they could have acknowledged that the name of a free software code snippet is not an assertion of broader intellectual property any more than the name of a goldfish is, and let the matter lie.
Either approach would have won them goodwill and cost nearly nothing.
posted by ardgedee at 4:37 AM on March 24, 2016 [13 favorites]
I just took a look at 'isarray' npm module. The ratio of bumpf & boilerplate to actual code is hilarious and staggering.
It's like the JavaScript community has collectively forgotten about coding to "collectively agreed upon" interfaces - all these NPM dependencies are a result of coding to implementation.
Trying to keep on top of the dependencies in production is a task for a braver man than I.
Nasty state of affairs.
posted by parki at 4:38 AM on March 24, 2016 [1 favorite]
It's like the JavaScript community has collectively forgotten about coding to "collectively agreed upon" interfaces - all these NPM dependencies are a result of coding to implementation.
Trying to keep on top of the dependencies in production is a task for a braver man than I.
Nasty state of affairs.
posted by parki at 4:38 AM on March 24, 2016 [1 favorite]
" They could have offered an agreement with Azer to mutually use the kik name in noncompetitive arenas, like Apple (the tech company) and Apple (the music publisher) had. Or they could have acknowledged that the name of a free software code snippet is not an assertion of broader intellectual property any more than the name of a goldfish is, and let the matter lie."
Well, yeah, they could've, but why?
From what I can tell he had the module name but no substantive code.I don't see how it's any different from domain squatting.
If it was an established project that actually did anything, and had an unfortunate clash of names (he also had kik-starter, which c'mon) then yeah, maybe they would've.
I know we all love to leap to the notion that the big company is evil and the lone developer is the good guy, but I just don't see much moral high ground from this guy.
posted by Just this guy, y'know at 4:45 AM on March 24, 2016 [1 favorite]
Well, yeah, they could've, but why?
From what I can tell he had the module name but no substantive code.I don't see how it's any different from domain squatting.
If it was an established project that actually did anything, and had an unfortunate clash of names (he also had kik-starter, which c'mon) then yeah, maybe they would've.
I know we all love to leap to the notion that the big company is evil and the lone developer is the good guy, but I just don't see much moral high ground from this guy.
posted by Just this guy, y'know at 4:45 AM on March 24, 2016 [1 favorite]
Yup, you're covered there ;) https://pypi.python.org/pypi/left-pad/0.0.3
I think it's a joke...
(Unless you're the one making the joke.)
posted by hoyland at 4:46 AM on March 24, 2016
I think it's a joke...
(Unless you're the one making the joke.)
posted by hoyland at 4:46 AM on March 24, 2016
Store all dependencies locally. 100% unit test coverage for JS. All unit tests run without Internet access. You have to be incredibly disciplined, and it costs 10x as much, but it is possible to write reliable JS.
posted by miyabo at 4:54 AM on March 24, 2016 [5 favorites]
posted by miyabo at 4:54 AM on March 24, 2016 [5 favorites]
I had no idea that JS dependencies worked this way. What's to stop some malicious dev or agency from coding an exploitable memory leak into a library? Character-padding routines would be the ideal place for this; which security firm would think of auditing them?
posted by Joe in Australia at 4:56 AM on March 24, 2016 [3 favorites]
posted by Joe in Australia at 4:56 AM on March 24, 2016 [3 favorites]
Recalling the Y2K insanity - how I would have loved to write a report for legal outlining how we've audited all those third party NPM modules ha ha a-ha-ha ha ha ha hahahahaha. Pass me the smelling salts, I'm getting woozy.
posted by parki at 4:59 AM on March 24, 2016 [3 favorites]
posted by parki at 4:59 AM on March 24, 2016 [3 favorites]
The part I don't get (admittedly due to lack of knowledge) is this: what makes npm different from gem, composer, pip, etc.? Couldn't a package suddenly disappear from any of those other package managers and put everyone in a similar world of hurt when trying to re-build? I understand that Javascript has some unique issues in this area (ask me about the Gulp workflow I built that had a ridiculous dependency chain for reasons?) but the fundamental core seems like it affects other programming languages as well.
posted by chrominance at 5:22 AM on March 24, 2016 [4 favorites]
posted by chrominance at 5:22 AM on March 24, 2016 [4 favorites]
rouftop: "Have we forgotten how to program?"
I don't like the current situation with NPM, but it's still not a good idea to write your own utility functions if there's a widely-used library that does the same thing.
We haven't forgotten how to program. We've learned from our hubris, and now recognize that using someone else's battle-tested code with lots of tests is almost always preferable to writing your own one-off utility functions.
Things like left-pad (and yes, even is-positive-integer) are actually a decent argument in favor of the basic premise of NPM's package model. (The actual reality ends up being a lot worse, but micro-libraries are not necessarily a horrible thing in and of themselves, particularly if your language lacks a good standard library.)
In the end, most languages end up with a widely-used 3rd-party library to supplement the standard library, which is what JavaScript currently has with lodash. (Although I wishe that the world had stuck with Underscore. Lodash is bloating out of control, and the latest version made tons of breaking API changes for very little benefit.)
posted by schmod at 5:25 AM on March 24, 2016 [8 favorites]
I don't like the current situation with NPM, but it's still not a good idea to write your own utility functions if there's a widely-used library that does the same thing.
We haven't forgotten how to program. We've learned from our hubris, and now recognize that using someone else's battle-tested code with lots of tests is almost always preferable to writing your own one-off utility functions.
Things like left-pad (and yes, even is-positive-integer) are actually a decent argument in favor of the basic premise of NPM's package model. (The actual reality ends up being a lot worse, but micro-libraries are not necessarily a horrible thing in and of themselves, particularly if your language lacks a good standard library.)
In the end, most languages end up with a widely-used 3rd-party library to supplement the standard library, which is what JavaScript currently has with lodash. (Although I wishe that the world had stuck with Underscore. Lodash is bloating out of control, and the latest version made tons of breaking API changes for very little benefit.)
posted by schmod at 5:25 AM on March 24, 2016 [8 favorites]
middleclastool: JS development looks like a cargo cult most places, and I know a ton of really smart coders who won't go near it for exactly that reason.
I wonder who that leaves to do it, then...? Oh, right. :7(
posted by wenestvedt at 5:31 AM on March 24, 2016 [2 favorites]
I wonder who that leaves to do it, then...? Oh, right. :7(
posted by wenestvedt at 5:31 AM on March 24, 2016 [2 favorites]
> Well, yeah, they could've, but why? From what I can tell he had the module name but no substantive code. I don't see how it's any different from domain squatting.
Code quality is not a determinant of ownership. He had code, whether or not it was novel or complex. It already existed, and it was being depended on.
Fundamentally, an attempt at good faith behavior on both sides of the argument could've avoided the problem. Kik the company instigated it by making a demand (basically, "sell it to us or we take it by force"), and Azer retaliated in kind.
posted by ardgedee at 5:37 AM on March 24, 2016 [2 favorites]
Code quality is not a determinant of ownership. He had code, whether or not it was novel or complex. It already existed, and it was being depended on.
Fundamentally, an attempt at good faith behavior on both sides of the argument could've avoided the problem. Kik the company instigated it by making a demand (basically, "sell it to us or we take it by force"), and Azer retaliated in kind.
posted by ardgedee at 5:37 AM on March 24, 2016 [2 favorites]
(OK, sorry, that was kind of a cheap shot that may have unfairly hit some good developers -- but I know some devotees of T3h Klowd Über Alles that just...make me sad.)
posted by wenestvedt at 5:49 AM on March 24, 2016
posted by wenestvedt at 5:49 AM on March 24, 2016
Everyone involved wants to make this not about trademark law, that it's about JS or teenagers or rudeness. But it is, in fact, about trademark law.
So this matters: if Azer had had a team of lawyers, he would have won. Trademark law does not work the way Bob is pretending it does in his threatening email. Bob doesn't think he's threatening precisely because he is not a lawyer, and he thinks he knows the law. But he doesn't.
posted by anotherpanacea at 5:58 AM on March 24, 2016 [9 favorites]
So this matters: if Azer had had a team of lawyers, he would have won. Trademark law does not work the way Bob is pretending it does in his threatening email. Bob doesn't think he's threatening precisely because he is not a lawyer, and he thinks he knows the law. But he doesn't.
posted by anotherpanacea at 5:58 AM on March 24, 2016 [9 favorites]
If the github page is anything to go by (it may not be) there was barely more than placeholder text there.
No one was depending on it. It didn't do anything.
I believe from the correspondence that kik began in good faith. I don't think Azer did at any point.
Kik didn't actually threaten to take it by force. The mention of lawyers was specifically in reference to him launching an open source project, not over the name ownership.
I don't really think they behaved that well after that. But npm does have a dispute policy in place over names, which was invoked.
He didn't retaliate in kind, he started out obstreperous and got worse.
I'm not defending the way it all turned out (especially not npm forcing the publishing of leftpad v0.0.3), but what I am saying is that this isn't a giant corporation vs the lone coder hero.
I mean, what's to stop me going to npm, writing a page of code and sticking it in a module called Windows.
In that case surely it's reasonable for Microsoft to come along and ask me not to?
posted by Just this guy, y'know at 5:58 AM on March 24, 2016
No one was depending on it. It didn't do anything.
I believe from the correspondence that kik began in good faith. I don't think Azer did at any point.
Kik didn't actually threaten to take it by force. The mention of lawyers was specifically in reference to him launching an open source project, not over the name ownership.
I don't really think they behaved that well after that. But npm does have a dispute policy in place over names, which was invoked.
He didn't retaliate in kind, he started out obstreperous and got worse.
I'm not defending the way it all turned out (especially not npm forcing the publishing of leftpad v0.0.3), but what I am saying is that this isn't a giant corporation vs the lone coder hero.
I mean, what's to stop me going to npm, writing a page of code and sticking it in a module called Windows.
In that case surely it's reasonable for Microsoft to come along and ask me not to?
posted by Just this guy, y'know at 5:58 AM on March 24, 2016
Kik specifically pointed out that they have to enforce the trademark or lose it, which is true.
No, they have to assert the trademark or risk losing it. They could just as easily do that by giving him permission to keep doing what he was doing; see Linden Labs and the "proceed and permitted" letter.
posted by Itaxpica at 5:58 AM on March 24, 2016 [10 favorites]
No, they have to assert the trademark or risk losing it. They could just as easily do that by giving him permission to keep doing what he was doing; see Linden Labs and the "proceed and permitted" letter.
posted by Itaxpica at 5:58 AM on March 24, 2016 [10 favorites]
@hoyland
"
Or, if you want to reinvent the wheel, go ahead and try to do it with the standard library
>>> s.rjust(len(s) + 2, '+')
"
It's totally a joke.
posted by I-Write-Essays at 6:04 AM on March 24, 2016 [2 favorites]
"
Or, if you want to reinvent the wheel, go ahead and try to do it with the standard library
>>> s.rjust(len(s) + 2, '+')
"
It's totally a joke.
posted by I-Write-Essays at 6:04 AM on March 24, 2016 [2 favorites]
pip install sanity
posted by a complicated history at 6:08 AM on March 24, 2016 [2 favorites]
posted by a complicated history at 6:08 AM on March 24, 2016 [2 favorites]
Hey everybody, someone fixed the glitch!
posted by Itaxpica at 6:09 AM on March 24, 2016 [14 favorites]
posted by Itaxpica at 6:09 AM on March 24, 2016 [14 favorites]
I should state, that I'm not saying Kik had any legal rights (but then they didn't say they did, they only said that IF he published a full project called Kik then they'd have to respond) and I think they went too far and ultimately Kik and NPM behaved terribly.
But I keep seeing stuff about how he's sticking it to the man and standing up for open source coders and stuff (his own medium post talks about 'Liberating' his code) and that's just silly.
posted by Just this guy, y'know at 6:10 AM on March 24, 2016 [1 favorite]
But I keep seeing stuff about how he's sticking it to the man and standing up for open source coders and stuff (his own medium post talks about 'Liberating' his code) and that's just silly.
posted by Just this guy, y'know at 6:10 AM on March 24, 2016 [1 favorite]
Hey everybody, someone fixed the glitch!
This is the most beautiful thing since stacksort.
posted by dis_integration at 6:15 AM on March 24, 2016 [7 favorites]
This is the most beautiful thing since stacksort.
posted by dis_integration at 6:15 AM on March 24, 2016 [7 favorites]
I wonder who that leaves to do it, then...? Oh, right. :7(
Ha! I said a ton, not nearly all. But you bring up an interesting divide there in the culture. To wit:
The other day, I was having an email conversation with my boss and one of my off-site colleagues, who is a lovely woman, a good friend, and a very skilled coder who works on our host data server. At one point she made a passing comment about "programming" (meaning her team) and "the web guys" (meaning me, basically).
Now, I'm fluent in C# and Java, better than average at Swift (nobody's really fluent in Swift yet, right?), and competently conversant in JS and Angular. I even know how to code RPG for the IBM i/System i/iSeries/AS400. But I was not lumped into "programming" because 60% of what I do right now is JS web coding.
She didn't mean anything by it and was mortified when I pointed it out, so I give her endless shit about it, but that's an attitude I see a lot in developers: JS isn't a "real" programming language because of the kinds of things we're talking about here.
Which is shittily dismissive, of course, but that attitude doesn't come from nowhere. There are limitations to JS as a language that would be flat-out intolerable anywhere else in development. I'm kind of surprised there hasn't been a stronger push to either make it better or replace it with something that is.
posted by middleclasstool at 6:19 AM on March 24, 2016 [8 favorites]
Ha! I said a ton, not nearly all. But you bring up an interesting divide there in the culture. To wit:
The other day, I was having an email conversation with my boss and one of my off-site colleagues, who is a lovely woman, a good friend, and a very skilled coder who works on our host data server. At one point she made a passing comment about "programming" (meaning her team) and "the web guys" (meaning me, basically).
Now, I'm fluent in C# and Java, better than average at Swift (nobody's really fluent in Swift yet, right?), and competently conversant in JS and Angular. I even know how to code RPG for the IBM i/System i/iSeries/AS400. But I was not lumped into "programming" because 60% of what I do right now is JS web coding.
She didn't mean anything by it and was mortified when I pointed it out, so I give her endless shit about it, but that's an attitude I see a lot in developers: JS isn't a "real" programming language because of the kinds of things we're talking about here.
Which is shittily dismissive, of course, but that attitude doesn't come from nowhere. There are limitations to JS as a language that would be flat-out intolerable anywhere else in development. I'm kind of surprised there hasn't been a stronger push to either make it better or replace it with something that is.
posted by middleclasstool at 6:19 AM on March 24, 2016 [8 favorites]
The part I don't get (admittedly due to lack of knowledge) is this: what makes npm different from gem, composer, pip, etc.? Couldn't a package suddenly disappear from any of those other package managers and put everyone in a similar world of hurt when trying to re-build?Similar problems can and do happen in other contexts. npm is very similar to bundler, for example. It's a matter of degree. npm seems to have an "everybody take everything you've ever done and package it up for NPM, and always use NPM modules rather than write your own stuff" culture. And javascript has no significant standard library, and it has many different implementations, so you might have a standard isArray available in one context and no isArray available in another, so somebody might think it was a good idea to write a module to paper over the difference.
Basically npm took a lot of problems in similar projects like Bundler and Composer, and even good old CPAN, and raised them to the Nth degree.
(I have seen some serious dependency hell in CPAN modules, where one developer's choice to use a particular style of object oriented code in a date parsing module brought in DOZENS of extra modules, many of them very heavyweight. They didn't even provide any extra *functionality* for that date parsing module, I don't think, they just allowed its code to be written in an OO *style* of the developer's choice.)
posted by edheil at 6:22 AM on March 24, 2016 [1 favorite]
> pip install sanity
But, no, that apparently slows things down. Can't have that.
Blessed St. Knuth, save me from these fools.
And we wonder why we can't write secure code. What if this guy had, instead of unpublishing, shoved some nasty code into that function. How many systems would have it taken because they *required* that library? (Never mind the fact that this was considered a library.)
I'm also starting to feel that the first interview question of a javascript developer should be "what other languages do you know." Because, yeah, I get the being dismissive, except it seems to me the entire JS culture is rooted in not just bad, but incredibly stupid practice.
posted by eriko at 6:23 AM on March 24, 2016 [12 favorites]
Javascript removed.The staggering thing to me is there are that many people who think that it's perfectly acceptable to have production code reliant on the existence of outside source code -- and yes, your *development system* is production code, because you can't work without it.
But, no, that apparently slows things down. Can't have that.
Blessed St. Knuth, save me from these fools.
And we wonder why we can't write secure code. What if this guy had, instead of unpublishing, shoved some nasty code into that function. How many systems would have it taken because they *required* that library? (Never mind the fact that this was considered a library.)
I'm also starting to feel that the first interview question of a javascript developer should be "what other languages do you know." Because, yeah, I get the being dismissive, except it seems to me the entire JS culture is rooted in not just bad, but incredibly stupid practice.
posted by eriko at 6:23 AM on March 24, 2016 [12 favorites]
Oh, also, if I remember correctly, the reason node_modules directories run into the tens of thousands of files is that if three different modules A B and C all rely on the module D which itself relies on E and F, each of which relies on G, you're going to get copies of the D directory inside each of the 3 A B and C subdirectories, and E and F inside of each of the 3 D subdirectories, and G inside all 6 of the E and F subdirectories.
There's no sharing. Everything is nested, nothing is flat.
That's why the dependencies blow up.
They may have fixed this by now, I don't know, but it was true a short while ago.
posted by edheil at 6:26 AM on March 24, 2016 [1 favorite]
There's no sharing. Everything is nested, nothing is flat.
That's why the dependencies blow up.
They may have fixed this by now, I don't know, but it was true a short while ago.
posted by edheil at 6:26 AM on March 24, 2016 [1 favorite]
RPG for the IBM i/System i/iSeries/AS400
I don't have enough fingers for all the warding-off gestures I'm making. Retro me, Satanas! Anathema!
posted by Mr. Bad Example at 6:46 AM on March 24, 2016 [4 favorites]
I don't have enough fingers for all the warding-off gestures I'm making. Retro me, Satanas! Anathema!
posted by Mr. Bad Example at 6:46 AM on March 24, 2016 [4 favorites]
bitch stole my html!
posted by quonsar II: smock fishpants and the temple of foon at 6:57 AM on March 24, 2016 [2 favorites]
posted by quonsar II: smock fishpants and the temple of foon at 6:57 AM on March 24, 2016 [2 favorites]
I don't have enough fingers for all the warding-off gestures I'm making. Retro me, Satanas! Anathema!
You can try to run.
You can try to hide.
But we're everywhere.
And we're processing your mortgage and auto loans right now.
The call is coming from inside the house
posted by middleclasstool at 7:17 AM on March 24, 2016 [4 favorites]
You can try to run.
You can try to hide.
But we're everywhere.
And we're processing your mortgage and auto loans right now.
The call is coming from inside the house
posted by middleclasstool at 7:17 AM on March 24, 2016 [4 favorites]
If your second email says that you don't mean to be a dick about it, you are probably meaning to be a dick about it. Anyway it's insanely unprofessional and not very good-faithy. And their existing Node module on Github is called "kik-lib".
But any press is good press, right?
posted by RobotVoodooPower at 7:17 AM on March 24, 2016 [4 favorites]
But any press is good press, right?
posted by RobotVoodooPower at 7:17 AM on March 24, 2016 [4 favorites]
bitch stole my html!
This is the "JavaScript is terrible" thread, I think you're looking for the "flash is terrible" thread.
posted by Itaxpica at 7:19 AM on March 24, 2016 [1 favorite]
This is the "JavaScript is terrible" thread, I think you're looking for the "flash is terrible" thread.
posted by Itaxpica at 7:19 AM on March 24, 2016 [1 favorite]
Anyway, it could be worse, Oracle could buy your language.
posted by Artw at 7:24 AM on March 24, 2016 [12 favorites]
posted by Artw at 7:24 AM on March 24, 2016 [12 favorites]
I'm patiently awaiting the new era of WebAssembly, as prophesied by Gary Bernhardt. Imagine what it would be like to access the DOM from a better language than Javascript. I'm hoping Crystal will get ported to WebAssembly at some point, then I might actually get excited about web coding.
posted by A dead Quaker at 7:42 AM on March 24, 2016 [1 favorite]
posted by A dead Quaker at 7:42 AM on March 24, 2016 [1 favorite]
The part I don't get (admittedly due to lack of knowledge) is this: what makes npm different from gem, composer, pip, etc.? Couldn't a package suddenly disappear from any of those other package managers and put everyone in a similar world of hurt when trying to re-build?
RubyGems appears to enforce version-immutability for gems. So the exact same scenario is not possible, as the person who takes over the "yanked" gem would have to increment the version. Still a major flaw, though.
There's a discussion on GitHub right now about how RubyGems should solve this problem.
Ah, yes, this is how I remember why I truly hate Brendan Eich.
Well, there's also the other thing.
posted by tobascodagama at 7:45 AM on March 24, 2016 [4 favorites]
RubyGems appears to enforce version-immutability for gems. So the exact same scenario is not possible, as the person who takes over the "yanked" gem would have to increment the version. Still a major flaw, though.
There's a discussion on GitHub right now about how RubyGems should solve this problem.
Ah, yes, this is how I remember why I truly hate Brendan Eich.
Well, there's also the other thing.
posted by tobascodagama at 7:45 AM on March 24, 2016 [4 favorites]
I'm patiently awaiting the new era of WebAssembly, as prophesied by Gary Bernhardt. Imagine what it would be like to access the DOM from a better language than Javascript.*eyes Clojurescript* Hint, hint...
Kidding aside, I agree. There are actually quite a few decent languages for SPA dev, but I'm afraid that none of them are really viable without transformation/compilation to JS. On the other hand, since most serious apps have a build process for their JS anyways even if they're just writing "plain old JS", I'm not sure that's as big of a negative.
Ah, yes, this is how I remember why I truly hate Brendan Eich.You know what the sad part is? I remember reading that he initially wanted to implement a Scheme of some sort, but time constraints and marketing pressure forced him to implement Javascript instead.
Yeah. Now *that* is depressing. We were so, so very close...
posted by -1 at 7:51 AM on March 24, 2016 [2 favorites]
RubyGems appears to enforce version-immutability for gems. So the exact same scenario is not possible, as the person who takes over the "yanked" gem would have to increment the version. Still a major flaw, though.Yeah, but even that is a major help in terms of ensuring reproducible builds (on the same machine, at least.)
I can deal with (although I won't like) having to pull a specific version of a module from my team's local repo because upstream went bye bye. Or pulling it out of source control, etc. Unpleasant, but not the end of the world.
What I can't deal with is a build that worked yesterday on my machine failing on that same machine today because version 1.6.6 or whatever is no longer *actually* version 1.6.6. That's unacceptable.
posted by -1 at 7:54 AM on March 24, 2016 [7 favorites]
I'm also starting to feel that the first interview question of a javascript developer should be "what other languages do you know." Because, yeah, I get the being dismissive, except it seems to me the entire JS culture is rooted in not just bad, but incredibly stupid practice.Disappointing. eriko, I thought you were cool. Have ever talked to JavaScript developers? I know other languages, but my biggest strides in building things well happened when I started embracing concepts more prevalent in JavaScript than in C++.
I'm going to skip most of this thread. I skimmed about a third, and there's a lot of FUD here and a lot of "these other people do this" stuff going on. I'll just say this:
– This can happen in any package manager that allows unpublishing, including Ruby Gems. Some languages do not have a reliable package manager at all. Not allowing unpublishing ever is untenable, as sometimes people make mistakes. Perhaps a way to solve this is to only allow unpublishing in special circumstances, which would put NPM in a MetaFilter-like moderation situation.
– It is every developer's responsibility to weigh the trade-offs of using third-party code, whether it comes from a package manager, a big framework, GitHub, or copied and pasted from Stack Overflow. They should always ask: is this convenience right now worth the added complexity?
A lot of people handwave this. I think this is actually what we should change, not forcing people to use huge standard libraries. And I have not seen this only among JavaScript developers, but among C++ and Java developers as well. It is very rare that a developer even reads through the first level of dependencies that they are pulling in. Like JavaScript developer Max Ogden says:
my 1 step solution for javascript happiness: don't use javascript libraries that you don't understand or can't read briefly to learn 100%And MeFi's Own JavaScript developin' tmcw said:
don't paper over things you don't understand. it will only hit you harder when those abstractions fail. use abstractions for efficiency, not ignorance.- There are a lot of JavaScript developers, and they differ from each other. Some are this stereotype you guys are whipping about above. Some are ultra responsible and even overly careful. They work in all sorts of situations, including big deal enterprise massive scale ones. I have, and yes, JavaScript is just as good as anything else for those sorts of services and apps. I have worked at four companies with JavaScript developers, and I found them no more or less responsible than any other kind of developer on average.
– Huge, big deal enterprise apps in which a failed build is a big deal should be using their own NPM or checking in their dependencies. I've seen reasonable opinions to the contrary, but when I worked in an enterprise situation, we had our own NPM that was about a day behind the public NPM, and we had backups, so we could roll back to whatever NPM snapshot we wanted. Failing that, or maybe in addition to that, you should check in your dependencies. In fact, you should do this any time you are using any remote package manager for any language so you can always reproduce a past build.
posted by ignignokt at 7:59 AM on March 24, 2016 [14 favorites]
> Anyway, it could be worse, Oracle could buy your language.
[cough]
Both "Java" and "JavaScript" are trademarks or registered trademarks of Oracle in the U.S. and other countries. -- Mozilla Foundation
posted by ardgedee at 7:59 AM on March 24, 2016 [3 favorites]
[cough]
Both "Java" and "JavaScript" are trademarks or registered trademarks of Oracle in the U.S. and other countries. -- Mozilla Foundation
posted by ardgedee at 7:59 AM on March 24, 2016 [3 favorites]
Have ever talked to JavaScript developers? I know other languages, but my biggest strides in building things well happened when I started embracing concepts more prevalent in JavaScript than in C++.
My understanding is that most of these concepts were actually innovated in functional languages and imported to JS because they made sense for the problem domain. Which is not to deny JS' role in bringing those concepts to the mainstream, but I do think we should be clear about what exactly we're giving JS credit for.
posted by tobascodagama at 8:14 AM on March 24, 2016
My understanding is that most of these concepts were actually innovated in functional languages and imported to JS because they made sense for the problem domain. Which is not to deny JS' role in bringing those concepts to the mainstream, but I do think we should be clear about what exactly we're giving JS credit for.
posted by tobascodagama at 8:14 AM on March 24, 2016
> ... my biggest strides in building things well happened when I started embracing concepts more prevalent in JavaScript than in C++.
I would have liked to have you expand on that, like what are some of the concepts you're talking about. But I can understand if you decide to skip this thread; once people get into poo-flinging mode it's hard for reasoned conversation to suddenly break out.
posted by benito.strauss at 8:16 AM on March 24, 2016
I would have liked to have you expand on that, like what are some of the concepts you're talking about. But I can understand if you decide to skip this thread; once people get into poo-flinging mode it's hard for reasoned conversation to suddenly break out.
posted by benito.strauss at 8:16 AM on March 24, 2016
Soon everyone will learn and fly back into the arms of Java Swing and PHP...
posted by Artw at 8:16 AM on March 24, 2016
posted by Artw at 8:16 AM on March 24, 2016
Largely, closures, async programming by default, and abandoning objects as the center of everything.
Yes, these aren't concepts unique to JavaScript, but many worthwhile languages are built around concepts they didn't invent. Mostly, I'm trying to address the idea that JavaScript developers are a lower form of developer. They are not; and just as wise as developers that work in languages that are more commonly respected.
posted by ignignokt at 8:22 AM on March 24, 2016 [4 favorites]
Yes, these aren't concepts unique to JavaScript, but many worthwhile languages are built around concepts they didn't invent. Mostly, I'm trying to address the idea that JavaScript developers are a lower form of developer. They are not; and just as wise as developers that work in languages that are more commonly respected.
posted by ignignokt at 8:22 AM on March 24, 2016 [4 favorites]
Something something mistakes all the way down something.
posted by the painkiller at 8:25 AM on March 24, 2016
posted by the painkiller at 8:25 AM on March 24, 2016
As always, the amazing Jenn Schiffer is on the case.
posted by fifteen schnitzengruben is my limit at 8:35 AM on March 24, 2016 [4 favorites]
posted by fifteen schnitzengruben is my limit at 8:35 AM on March 24, 2016 [4 favorites]
To quote a Javascript programmer I know at Google: "there's a lovely functional, dynamic programming language here. Shame it's buried under all that Javascript".
posted by Itaxpica at 8:37 AM on March 24, 2016 [8 favorites]
posted by Itaxpica at 8:37 AM on March 24, 2016 [8 favorites]
acb: Atlas shrugs, and a million web apps die screaming experience two and a half hours of disruption before everything goes back to normal.
posted by biogeo at 8:40 AM on March 24, 2016 [2 favorites]
posted by biogeo at 8:40 AM on March 24, 2016 [2 favorites]
To quote a Javascript programmer I know at Google: "there's a lovely functional, dynamic programming language here. Shame it's buried under all that Javascript".
This joke never gets old.
But JavaScript isn't that bad. My biggest gripe is all the type coercion, and the strange notion of scope, but if you program defensively it's not that huge of a problem since both problems are well defined (and if you don't get too tired of typing === instead of ==). Prototypes are actually a really cool way to think about code reuse, and now that modern browsers share a large basic core API, it's amazing to have a programming environment where your code runs practically everywhere. Once this whole world matures a bit, or, rather, if it ever matures a bit, it will be really nice.
posted by dis_integration at 8:48 AM on March 24, 2016 [2 favorites]
This joke never gets old.
But JavaScript isn't that bad. My biggest gripe is all the type coercion, and the strange notion of scope, but if you program defensively it's not that huge of a problem since both problems are well defined (and if you don't get too tired of typing === instead of ==). Prototypes are actually a really cool way to think about code reuse, and now that modern browsers share a large basic core API, it's amazing to have a programming environment where your code runs practically everywhere. Once this whole world matures a bit, or, rather, if it ever matures a bit, it will be really nice.
posted by dis_integration at 8:48 AM on March 24, 2016 [2 favorites]
(Re: My RPG aversion--it stems from a job in the 90s where I worked at a museum. Their ticketing and reservation system was written in RPG by one guy who had since moved on. Any changes had to wait for approval of his contracting fee and for him to have some spare time.
The whole thing ran on a pair of creaky MicroVAXen in the basement that were shoved underneath a desk with a keyboard and monitor on top. GUESS WHAT CRUCIAL SWITCH IS RIGHT AT KNEE HEIGHT WHEN YOU STORE THEM LIKE THAT. I started ignoring the chair and just bending over to type stuff.)
posted by Mr. Bad Example at 9:04 AM on March 24, 2016 [1 favorite]
The whole thing ran on a pair of creaky MicroVAXen in the basement that were shoved underneath a desk with a keyboard and monitor on top. GUESS WHAT CRUCIAL SWITCH IS RIGHT AT KNEE HEIGHT WHEN YOU STORE THEM LIKE THAT. I started ignoring the chair and just bending over to type stuff.)
posted by Mr. Bad Example at 9:04 AM on March 24, 2016 [1 favorite]
I don't pay too much attention to node, but I have a contract coming up later in April which I said I'd do in Express.
Do node folk in the thread advise I try and get the client to agree on something else or should this be well-sorted by then?
Despite the tone of the thread, this is not an earth-shaking catastrophe. This has nothing to do with Express, and the packages that were affected have already been taken care of. But as a matter of professional responsibility to the client, you should probably try to do it with something you know well and actually pay attention to.
posted by ignignokt at 9:11 AM on March 24, 2016 [2 favorites]
Do node folk in the thread advise I try and get the client to agree on something else or should this be well-sorted by then?
Despite the tone of the thread, this is not an earth-shaking catastrophe. This has nothing to do with Express, and the packages that were affected have already been taken care of. But as a matter of professional responsibility to the client, you should probably try to do it with something you know well and actually pay attention to.
posted by ignignokt at 9:11 AM on March 24, 2016 [2 favorites]
If you are not Mel, you are not a real programmer, I don't care how much you hand code your XmlHttpRequest wrappers and string manipulation functions.
posted by Artw at 9:22 AM on March 24, 2016 [4 favorites]
posted by Artw at 9:22 AM on March 24, 2016 [4 favorites]
(And thank god for that.)
posted by Artw at 9:22 AM on March 24, 2016 [1 favorite]
posted by Artw at 9:22 AM on March 24, 2016 [1 favorite]
> The staggering thing to me is there are that many people who think that it's perfectly acceptable to have production code reliant on the existence of outside source code -- and yes, your *development system* is production code, because you can't work without it.
The alternative is to "vendor" all your external dependencies (as is done on the project I work on), but that's a pain in the ass for different reasons: suddenly you've got a whole bunch of shit in your source tree.
> RubyGems appears to enforce version-immutability for gems. So the exact same scenario is not possible, as the person who takes over the "yanked" gem would have to increment the version. Still a major flaw, though.
In fact, this scenario was and is not possible for NPM, either. If you take over the name of a package that was previously unpublished, you are unable to use any version number that the previous package had used. The reinstatement of left-pad version 0.0.3 is now the only time that rule has been violated, and it was violated (a) to mitigate damage, (b) because the module itself was liberally licensed and (c) because there were few enough LOC that someone could go "yep, that's the exact same code that was there previously."
For me, the major takeaway is this: package.json files allow you to specify version ranges for your dependencies, but that's almost always a very bad idea. The dream of semver is that instead of saying "I want exact version 2.0.0 of library foo," you can say "I want major version 2.x.x of library foo" and over time you'll automatically be able to get all of foo's bugfixes without any breaking changes. And, in fact, that does work as long as (a) everyone involved acts in good faith and (b) nobody accidentally breaks backward compatibility in a bugfix release. B was never true, and A is doomed to become less true over time.
(This is not to say that semver is a bad idea. But its main value is in communicating intent to other humans, not in communicating assurances to computers. You can say that the intent of your release is to fix two small bugs, but you can't ever be sure you didn't break backward-compatibility.)
Anyone who's shipping production code without saying "I want EXACTLY THESE VERSIONS of my dependencies" is doing it wrong. This is something that most Node developers understand, but in my opinion it isn't stated nearly often enough. Furthermore, if your app uses dependencies, and those dependencies use version ranges in their package.json files, that's also a problem, and I don't quite know how to get around it.
The trouble this time is that the unpublishing of left-pad punished even those developers who were correctly pinning to specific version 0.0.3. When the unpublishing happened, version 0.0.3 ceased to exist. That's the thing that NPM won't allow to happen again.
posted by savetheclocktower at 9:46 AM on March 24, 2016 [5 favorites]
The alternative is to "vendor" all your external dependencies (as is done on the project I work on), but that's a pain in the ass for different reasons: suddenly you've got a whole bunch of shit in your source tree.
> RubyGems appears to enforce version-immutability for gems. So the exact same scenario is not possible, as the person who takes over the "yanked" gem would have to increment the version. Still a major flaw, though.
In fact, this scenario was and is not possible for NPM, either. If you take over the name of a package that was previously unpublished, you are unable to use any version number that the previous package had used. The reinstatement of left-pad version 0.0.3 is now the only time that rule has been violated, and it was violated (a) to mitigate damage, (b) because the module itself was liberally licensed and (c) because there were few enough LOC that someone could go "yep, that's the exact same code that was there previously."
For me, the major takeaway is this: package.json files allow you to specify version ranges for your dependencies, but that's almost always a very bad idea. The dream of semver is that instead of saying "I want exact version 2.0.0 of library foo," you can say "I want major version 2.x.x of library foo" and over time you'll automatically be able to get all of foo's bugfixes without any breaking changes. And, in fact, that does work as long as (a) everyone involved acts in good faith and (b) nobody accidentally breaks backward compatibility in a bugfix release. B was never true, and A is doomed to become less true over time.
(This is not to say that semver is a bad idea. But its main value is in communicating intent to other humans, not in communicating assurances to computers. You can say that the intent of your release is to fix two small bugs, but you can't ever be sure you didn't break backward-compatibility.)
Anyone who's shipping production code without saying "I want EXACTLY THESE VERSIONS of my dependencies" is doing it wrong. This is something that most Node developers understand, but in my opinion it isn't stated nearly often enough. Furthermore, if your app uses dependencies, and those dependencies use version ranges in their package.json files, that's also a problem, and I don't quite know how to get around it.
The trouble this time is that the unpublishing of left-pad punished even those developers who were correctly pinning to specific version 0.0.3. When the unpublishing happened, version 0.0.3 ceased to exist. That's the thing that NPM won't allow to happen again.
posted by savetheclocktower at 9:46 AM on March 24, 2016 [5 favorites]
What's to stop some malicious dev or agency from coding an exploitable memory leak into a library?
Well - JavaScript probably won't "leak memory" - but, there is absolutely nothing preventing un-audited script from loading more unknown script from a remote location and then chatting back and forth...
This is "by design"...
Web pages can reference resources from multiple locations... This is exactly how pages pull in libraries from Content Distribution Networks (CDN), let alone dependencies via Node.
(Note - some of this might be stopped by cross-domain and single-origin restrictions - I am not a web developer and frankly cannot keep-up with this crazy madness)
posted by jkaczor at 9:51 AM on March 24, 2016 [1 favorite]
Well - JavaScript probably won't "leak memory" - but, there is absolutely nothing preventing un-audited script from loading more unknown script from a remote location and then chatting back and forth...
This is "by design"...
Web pages can reference resources from multiple locations... This is exactly how pages pull in libraries from Content Distribution Networks (CDN), let alone dependencies via Node.
(Note - some of this might be stopped by cross-domain and single-origin restrictions - I am not a web developer and frankly cannot keep-up with this crazy madness)
posted by jkaczor at 9:51 AM on March 24, 2016 [1 favorite]
I don't care how much you hand code your XmlHttpRequest wrappers and string manipulation functions.
good lord, I must be a terrible communicator...it's not that *you do it in practice*. it's that you can communicate how to do it...
I'm out.
posted by j_curiouser at 10:00 AM on March 24, 2016 [1 favorite]
good lord, I must be a terrible communicator...it's not that *you do it in practice*. it's that you can communicate how to do it...
I'm out.
posted by j_curiouser at 10:00 AM on March 24, 2016 [1 favorite]
The alternative is to "vendor" all your external dependencies (as is done on the project I work on), but that's a pain in the ass for different reasons: suddenly you've got a whole bunch of shit in your source tree.
Yeah, that's a massive anti-pattern. There are a few occasions where it makes sense, but it should never be treated as routine practice.
Setting up internal mirrors and coming up with a process for testing and then importing updated versions of packages is a reasonable compromise, where you have the resources to do so.
posted by tobascodagama at 10:08 AM on March 24, 2016
Yeah, that's a massive anti-pattern. There are a few occasions where it makes sense, but it should never be treated as routine practice.
Setting up internal mirrors and coming up with a process for testing and then importing updated versions of packages is a reasonable compromise, where you have the resources to do so.
posted by tobascodagama at 10:08 AM on March 24, 2016
There's an npm package called "ibm" that's been there for two years and doesn't have any code. Their legal team must be very remiss to have let that happen.
posted by 7segment at 11:05 AM on March 24, 2016 [2 favorites]
posted by 7segment at 11:05 AM on March 24, 2016 [2 favorites]
You know what the sad part is? I remember reading that he initially wanted to implement a Scheme of some sort, but time constraints and marketing pressure forced him to implement Javascript instead.
Which is reflected in the parts that ended up being good.
Left-pad.io
Heh. I also saw a left-pad Python package yesterday.
Honestly though I've been doing a lot of Javascript recently (having dabbled in many things in quite a few languages) and I find it pretty fun. It's the combination of hacky very-impure functional style with stupid prototypical inheritance tricks. Mixins? Oh, I'll just write a function that copies these other functions into the prototype! Takes me back to SICP and learning how to build every fancy language feature from closures and spit.
I don't think I can handle the ecosystem, though - the stuff I'm doing is already two or three years behind what's hot now.
posted by atoxyl at 11:31 AM on March 24, 2016
Which is reflected in the parts that ended up being good.
Left-pad.io
Heh. I also saw a left-pad Python package yesterday.
Honestly though I've been doing a lot of Javascript recently (having dabbled in many things in quite a few languages) and I find it pretty fun. It's the combination of hacky very-impure functional style with stupid prototypical inheritance tricks. Mixins? Oh, I'll just write a function that copies these other functions into the prototype! Takes me back to SICP and learning how to build every fancy language feature from closures and spit.
I don't think I can handle the ecosystem, though - the stuff I'm doing is already two or three years behind what's hot now.
posted by atoxyl at 11:31 AM on March 24, 2016
There are limitations to JS as a language that would be flat-out intolerable anywhere else in development. I'm kind of surprised there hasn't been a stronger push to either make it better or replace it with something that is.
I'm vaguely curious what you think those limitations are.
JavaScript has its warts, but never seemed to have a greater number of them than most other languages. ES6 fixes a lot of them (and goes moderately overboard -- I'd have been very happy if they stopped at arrow functions, block-scoping, and constants)
I'm also curious about the assertion that "JS has no standard library." Of course it does. There are holes, but it's really not bad, and most of the glaring ones were fixed in ES5. I've ripped Underscore out of most of my code, because there are equivalent builtin methods that can now do the same things.
The JS community has issues, but I'm seeing very little substance in this conversation. It's unfair IMO to dismiss JavaScript outright.
posted by schmod at 11:32 AM on March 24, 2016 [4 favorites]
I'm vaguely curious what you think those limitations are.
JavaScript has its warts, but never seemed to have a greater number of them than most other languages. ES6 fixes a lot of them (and goes moderately overboard -- I'd have been very happy if they stopped at arrow functions, block-scoping, and constants)
I'm also curious about the assertion that "JS has no standard library." Of course it does. There are holes, but it's really not bad, and most of the glaring ones were fixed in ES5. I've ripped Underscore out of most of my code, because there are equivalent builtin methods that can now do the same things.
The JS community has issues, but I'm seeing very little substance in this conversation. It's unfair IMO to dismiss JavaScript outright.
posted by schmod at 11:32 AM on March 24, 2016 [4 favorites]
Imagine what it would be like to access the DOM from a better language than Javascript.
There are DOM implementations in other languages.
The problems with the DOM have little do to with JavaScript. It's a shockingly terrible API, no matter what language you access it from.
posted by schmod at 11:36 AM on March 24, 2016 [2 favorites]
There are DOM implementations in other languages.
The problems with the DOM have little do to with JavaScript. It's a shockingly terrible API, no matter what language you access it from.
posted by schmod at 11:36 AM on March 24, 2016 [2 favorites]
It's the combination of hacky very-impure functional style with stupid prototypical inheritance tricks. Mixins? Oh, I'll just write a function that copies these other functions into the prototype!
The bummer is that most of the things that make JS fun aren't usable in performance-sensitive Node services.
posted by invitapriore at 11:39 AM on March 24, 2016 [1 favorite]
The bummer is that most of the things that make JS fun aren't usable in performance-sensitive Node services.
bind is slow, fucking with prototypes will cause V8 to reconstruct the hidden classes that back them, promises are out, and most of the functional-ish convenience methods on Array just can't compare to a simple for loop as far as the optimizing compiler is concerned. Also no generators, for-in loops, arguments-leaking, functions over 600 characters including comments...not everyone needs to do all those tricks, but once you get to that point you're basically writing garbage collected C with no integer type, and it all starts to feel a little futile.posted by invitapriore at 11:39 AM on March 24, 2016 [1 favorite]
... but once you get to that point you're basically writing garbage collected C with no integer type ...
Sorry, unless you're using ArrayBuffers :)
posted by invitapriore at 11:44 AM on March 24, 2016
Sorry, unless you're using ArrayBuffers :)
posted by invitapriore at 11:44 AM on March 24, 2016
Oh, no exception handling either, the optimizing compiler simply won't touch a function with a
posted by invitapriore at 11:48 AM on March 24, 2016
try/catch block. I guess passing C-style error codes is a little more pleasant when you can pass them out-of-band of the nominal return type.posted by invitapriore at 11:48 AM on March 24, 2016
invitapriore, you are doing some really intense stuff!
For folks making kinda typical web service type stuff, `node --prof --trace-opt --trace-deopt …`before you assume you can't use that stuff. Or even just eyeball performance. We ran a cluster of four Node servers that handled a million requests in a day OK, despite using promises all over the place.
posted by ignignokt at 12:12 PM on March 24, 2016 [1 favorite]
For folks making kinda typical web service type stuff, `node --prof --trace-opt --trace-deopt …`before you assume you can't use that stuff. Or even just eyeball performance. We ran a cluster of four Node servers that handled a million requests in a day OK, despite using promises all over the place.
posted by ignignokt at 12:12 PM on March 24, 2016 [1 favorite]
Yeah by the time you reach that point shouldn't you... not be using JavaScript? I mean main scenario that comes to mind is you started out writing JS as a high-level language then you later had to rewrite things that were bottlenecks as low-level but when are you going to be doing a whole project like that (unless some bad decisions were made from the start). I'm asking a fairly serious question here I've never done node/a backend in JS.
posted by atoxyl at 12:25 PM on March 24, 2016 [2 favorites]
posted by atoxyl at 12:25 PM on March 24, 2016 [2 favorites]
Trevor Norris did a pretty good talk that went over some performance-related tradeoffs you can made in Node. This point about generating hidden classes via closures vs. via prototypes is interesting: Closures in that benchmark instantiated in 280 ns, whereas the prototype one instantiated in 7 ns. So, for that to make a total of 1 second of difference, you'd need instantiate 3,663,003 times. Which, of course, can come up.
I think it makes the case for A) being aware of the cost of fun higher level techniques but also B) measuring before you assume something matters to any particular case.
posted by ignignokt at 12:25 PM on March 24, 2016 [3 favorites]
I think it makes the case for A) being aware of the cost of fun higher level techniques but also B) measuring before you assume something matters to any particular case.
posted by ignignokt at 12:25 PM on March 24, 2016 [3 favorites]
For those wondering how support for ES6 is coming along... Table of support
WTF, desktop Safari and Android mobile? Even Microsoft is kicking your asses.
posted by Artw at 12:35 PM on March 24, 2016
WTF, desktop Safari and Android mobile? Even Microsoft is kicking your asses.
posted by Artw at 12:35 PM on March 24, 2016
Yeah by the time you reach that point shouldn't you... not be using JavaScript? I mean main scenario that comes to mind is you started out writing JS as a high-level language then you later had to rewrite things that were bottlenecks as low-level but when are you going to be doing a whole project like that (unless some bad decisions were made from the start). I'm asking a fairly serious question here I've never done node/a backend in JS.
I think we're pretty much on the same page. I think what leads people to the point where they're torturing their JavaScript that way is: you start out at a point where Node hits that perfect sweet spot of decent performance plus dynamicism plus familiarity that I mentioned above, then your performance demands increase and you need to write new systems, but all of your developers are steeped in Node and while they could use something else, it would be a slower and more error-prone process, both because probably not everyone is already up to snuff with the new stack (you might be able to "learn" a language in a week [I don't actually believe this], but you almost certainly can't write idiomatic and performance sensitive code in it by then) and because unless it's something already in use you have to wire up monitoring, alerts, logging and etc. all over again. So that's how you end up in the over-optimized JS local minimum.
posted by invitapriore at 12:49 PM on March 24, 2016 [1 favorite]
I think we're pretty much on the same page. I think what leads people to the point where they're torturing their JavaScript that way is: you start out at a point where Node hits that perfect sweet spot of decent performance plus dynamicism plus familiarity that I mentioned above, then your performance demands increase and you need to write new systems, but all of your developers are steeped in Node and while they could use something else, it would be a slower and more error-prone process, both because probably not everyone is already up to snuff with the new stack (you might be able to "learn" a language in a week [I don't actually believe this], but you almost certainly can't write idiomatic and performance sensitive code in it by then) and because unless it's something already in use you have to wire up monitoring, alerts, logging and etc. all over again. So that's how you end up in the over-optimized JS local minimum.
posted by invitapriore at 12:49 PM on March 24, 2016 [1 favorite]
> The problems with the DOM have little do to with JavaScript. It's a shockingly terrible API, no matter what language you access it from.
As are most APIs that are designed to be cross-language. The DOM API is so simplistic that all your language needs to be able to implement it are strings, booleans, integers, and the ability to call functions. (I don't think you even need OOP; pretty sure I've seen a PHP implementation of DOM where you'd just pass in the relevant node as the first argument.)
That makes the DOM portable, but without any of the syntactic sugar that actually makes APIs pleasant. So you end up with methods that take fifteen arguments.
posted by savetheclocktower at 1:05 PM on March 24, 2016 [2 favorites]
As are most APIs that are designed to be cross-language. The DOM API is so simplistic that all your language needs to be able to implement it are strings, booleans, integers, and the ability to call functions. (I don't think you even need OOP; pretty sure I've seen a PHP implementation of DOM where you'd just pass in the relevant node as the first argument.)
That makes the DOM portable, but without any of the syntactic sugar that actually makes APIs pleasant. So you end up with methods that take fifteen arguments.
posted by savetheclocktower at 1:05 PM on March 24, 2016 [2 favorites]
I'm vaguely curious what you think those limitations are.
Well, a fair bit's mentioned above. For starters: An integer that's an integer. A decimal data type so I can do reliable floating-point math, which is pretty critical for financial applications. A more robust library of string and numeric functions and list iterators that comes standard and doesn't require third-party solutions or a lot of hand coding. More broadly, anything at all to reduce my need to either stack up third-party frameworks or hand-roll a lot of utility code to do what a lot of major server-side and PC languages do out of the box.
We've got PC client application code that's way more complex than our web application and it uses three third-party toolkits I that I know of, all of which are from major developers that we have business contracts with and have some recourse with if they go south.
Our web app has well over a dozen frameworks from disparate sources, none of whom we have recourse with, and the only reason I have the time and bandwidth to write this comment right now is that none of those that we depend on to get the job done have been yoinked away without warning. Yet.
posted by middleclasstool at 1:15 PM on March 24, 2016 [1 favorite]
Well, a fair bit's mentioned above. For starters: An integer that's an integer. A decimal data type so I can do reliable floating-point math, which is pretty critical for financial applications. A more robust library of string and numeric functions and list iterators that comes standard and doesn't require third-party solutions or a lot of hand coding. More broadly, anything at all to reduce my need to either stack up third-party frameworks or hand-roll a lot of utility code to do what a lot of major server-side and PC languages do out of the box.
We've got PC client application code that's way more complex than our web application and it uses three third-party toolkits I that I know of, all of which are from major developers that we have business contracts with and have some recourse with if they go south.
Our web app has well over a dozen frameworks from disparate sources, none of whom we have recourse with, and the only reason I have the time and bandwidth to write this comment right now is that none of those that we depend on to get the job done have been yoinked away without warning. Yet.
posted by middleclasstool at 1:15 PM on March 24, 2016 [1 favorite]
...pretty sure I've seen a PHP implementation of DOM where you'd just pass in the relevant node as the first argument.
That's all that OOP is anyway: a convenient way of passing a first argument and not having to write boilerplate to do dynamic dispatch based on its type.
posted by I-Write-Essays at 1:19 PM on March 24, 2016 [3 favorites]
That's all that OOP is anyway: a convenient way of passing a first argument and not having to write boilerplate to do dynamic dispatch based on its type.
posted by I-Write-Essays at 1:19 PM on March 24, 2016 [3 favorites]
A decimal data type so I can do reliable floating-point math, which is pretty critical for financial applications.
Honestly a lot of languages don't have this as a built-in type, though the imports are generally more standardized and official than the (still workable IME) JS options.
posted by atoxyl at 1:25 PM on March 24, 2016
Honestly a lot of languages don't have this as a built-in type, though the imports are generally more standardized and official than the (still workable IME) JS options.
posted by atoxyl at 1:25 PM on March 24, 2016
Which also, incidentally, is called "fixed-point" and is completely disjoint from floating point q.v.
posted by 7segment at 1:30 PM on March 24, 2016 [1 favorite]
posted by 7segment at 1:30 PM on March 24, 2016 [1 favorite]
It's absolutely 100% about trademark law. Kik were jerks. NPM sucked too. Azer Koçulu leaving NPM seems completely reasonable.
It's too bad this didn't go worse for NPM really. It's be funnier if say left-pad were replaced by some botnet operator or something. And maybe if Azer had pushed a interesting change to all the licenses before unpublishing them, then NPM would need to think more before republishing left-pad. We can always hope this encourages more developers to avoid NPM or Node entirely at least.
Amongst my favorite erowidrecruiter tweets is:
- Afraid of the following programming languages: Node
posted by jeffburdges at 1:31 PM on March 24, 2016 [1 favorite]
It's too bad this didn't go worse for NPM really. It's be funnier if say left-pad were replaced by some botnet operator or something. And maybe if Azer had pushed a interesting change to all the licenses before unpublishing them, then NPM would need to think more before republishing left-pad. We can always hope this encourages more developers to avoid NPM or Node entirely at least.
Amongst my favorite erowidrecruiter tweets is:
- Afraid of the following programming languages: Node
posted by jeffburdges at 1:31 PM on March 24, 2016 [1 favorite]
Gotta love that a thread about JavaScript drama still devolves into Ruby hate. So MeFi.
posted by defenestration at 1:59 PM on March 24, 2016 [1 favorite]
posted by defenestration at 1:59 PM on March 24, 2016 [1 favorite]
In that we've mentioned Ruby Gens come with some very similar concepts? Not seeing it.
posted by Artw at 2:08 PM on March 24, 2016 [1 favorite]
posted by Artw at 2:08 PM on March 24, 2016 [1 favorite]
You're right. Sorry, I have fatigue from other threads and I was being overly sensitive.
posted by defenestration at 2:15 PM on March 24, 2016
posted by defenestration at 2:15 PM on March 24, 2016
> That makes the DOM portable, but without any of the syntactic sugar that actually makes APIs pleasant. So you end up with methods that take fifteen arguments.
Whatever Javascript's DOM API has going for or against it, a method that's over 16 years old and has been a deprecated language feature for at least half a decade is probably not the best illustration of the problems that Javascript currently has.
Unless you were trying to illustrate one of the root problems of writing a common client-side language implemented by any third-party entity: That it's dead easy to whack features in without thinking them through, but hell to ever remove.
posted by ardgedee at 2:37 PM on March 24, 2016 [3 favorites]
Whatever Javascript's DOM API has going for or against it, a method that's over 16 years old and has been a deprecated language feature for at least half a decade is probably not the best illustration of the problems that Javascript currently has.
Unless you were trying to illustrate one of the root problems of writing a common client-side language implemented by any third-party entity: That it's dead easy to whack features in without thinking them through, but hell to ever remove.
posted by ardgedee at 2:37 PM on March 24, 2016 [3 favorites]
It's absolutely 100% about trademark law.
Hmm. Sort of, but only in the sense that Kik could use (what looks to me like) a bogus threat of TM litigation to get what they wanted. If it had actually come down to litigation NPM would have been a defendant; it would have hired its own lawyers; and it would probably have "won". As someone said upthread, if Azer had had his own lawyers then this wouldn't have happened. But it didn't come down to litigation; they possibly could have achieved the same result by just asking NPM to enforce its rules against confusing domain names.
posted by Joe in Australia at 3:40 PM on March 24, 2016
Hmm. Sort of, but only in the sense that Kik could use (what looks to me like) a bogus threat of TM litigation to get what they wanted. If it had actually come down to litigation NPM would have been a defendant; it would have hired its own lawyers; and it would probably have "won". As someone said upthread, if Azer had had his own lawyers then this wouldn't have happened. But it didn't come down to litigation; they possibly could have achieved the same result by just asking NPM to enforce its rules against confusing domain names.
posted by Joe in Australia at 3:40 PM on March 24, 2016
GallonOfAlan: "Web development in 2016 should involve less insane complexity."
"Why webdev sucks in '16..."
"It's the JS!"
posted by symbioid at 4:15 PM on March 24, 2016 [2 favorites]
"Why webdev sucks in '16..."
"It's the JS!"
posted by symbioid at 4:15 PM on March 24, 2016 [2 favorites]
Nah, it's still the fucking browsers.
posted by Artw at 4:21 PM on March 24, 2016 [2 favorites]
posted by Artw at 4:21 PM on March 24, 2016 [2 favorites]
Artw: "WTF, desktop Safari and Android mobile? Even Microsoft is kicking your asses."
Safari is quickly becoming the new IE.
The rapid decline of software quality at Apple (across the board) is especially apparent in Safari/WebKit.
At work, we're starting to have to deal with Safari rendering bugs with surprising regularity. (Today, we had to add a line of code that periodically checks an element's height, because the element randomly disappears otherwise. The line of code is literally
This is particularly frustrating, because Safari isn't an evergreen browser (the only major player left that doesn't do continuous releases I should add), and Apple basically has no long-term support policy for it. You can't test multiple versions of Safari on a single machine, and you need to own a mac to test it at all. Even Microsoft provides developers with free IE VMs.
The Android browser has been deprecated for a while, so its inclusion on that chart isn't totally fair. Android users are encouraged to download Chrome (although Mobile Firefox has come a long way, and is a viable competitor). Both Android Chrome and Firefox track their desktop counterparts closely enough to count them together in terms of ES6 compatibility. Users of older Android devices can download Chrome/FF, and most do -- the usage numbers for the Android Browser are very low, because it's a borderline-unusable pile of crap.
posted by schmod at 5:00 PM on March 24, 2016 [4 favorites]
Safari is quickly becoming the new IE.
The rapid decline of software quality at Apple (across the board) is especially apparent in Safari/WebKit.
At work, we're starting to have to deal with Safari rendering bugs with surprising regularity. (Today, we had to add a line of code that periodically checks an element's height, because the element randomly disappears otherwise. The line of code is literally
element.innerHeight; which shouldn't even do anything. This is particularly frustrating, because Safari isn't an evergreen browser (the only major player left that doesn't do continuous releases I should add), and Apple basically has no long-term support policy for it. You can't test multiple versions of Safari on a single machine, and you need to own a mac to test it at all. Even Microsoft provides developers with free IE VMs.
The Android browser has been deprecated for a while, so its inclusion on that chart isn't totally fair. Android users are encouraged to download Chrome (although Mobile Firefox has come a long way, and is a viable competitor). Both Android Chrome and Firefox track their desktop counterparts closely enough to count them together in terms of ES6 compatibility. Users of older Android devices can download Chrome/FF, and most do -- the usage numbers for the Android Browser are very low, because it's a borderline-unusable pile of crap.
posted by schmod at 5:00 PM on March 24, 2016 [4 favorites]
Anyone wondering how to get a frame buffer and a native VM on the web should be looking at WebGL and asm.js/webasm (as a target). It's not perfect, but it clearly shows what's possible. And it's miles better than the cluster that CSS is.
posted by smidgen at 7:27 PM on March 24, 2016
posted by smidgen at 7:27 PM on March 24, 2016
Apple should invest in Mozilla's Servo. And maybe consider redesigning Darwin in Rust too. Rust is essential to securing projects like operating systems or browsers.
posted by jeffburdges at 12:29 AM on March 25, 2016
posted by jeffburdges at 12:29 AM on March 25, 2016
To be clear, there's nothing fundamentally wrong with WebKit. It was doing fine when Google were making contributions.
Meanwhile, there are a few folks working on an OS written in Rust. It's interesting and ambitious to say the least.
posted by schmod at 5:13 AM on March 25, 2016 [2 favorites]
Meanwhile, there are a few folks working on an OS written in Rust. It's interesting and ambitious to say the least.
posted by schmod at 5:13 AM on March 25, 2016 [2 favorites]
Nothing fundamentally wrong with Darwin, for that matter.
Declining code quality will happen regardless of what language something is written in, if the institution that supports the code stops caring about quality.
posted by tobascodagama at 5:31 AM on March 25, 2016 [2 favorites]
Declining code quality will happen regardless of what language something is written in, if the institution that supports the code stops caring about quality.
posted by tobascodagama at 5:31 AM on March 25, 2016 [2 favorites]
Rust is essential to securing projects like operating systems or browsers.
Isn't it a bit premature to say that? It's only been out a very short while, relative to other languages.
posted by a lungful of dragon at 4:37 PM on March 25, 2016 [2 favorites]
Isn't it a bit premature to say that? It's only been out a very short while, relative to other languages.
posted by a lungful of dragon at 4:37 PM on March 25, 2016 [2 favorites]
I think it makes the case for A) being aware of the cost of fun higher level techniques but also B) measuring before you assume something matters to any particular case.
Agreed. Those optimizations I cited were learned the hard way via extensive profiling, and were necessary because the project in question was a DHT-based service discovery and routing mesh with its own application-layer binary protocol. Written in Node (not my choice). These are the pathologies wrought by institutional inertia...
posted by invitapriore at 9:44 PM on March 25, 2016
Agreed. Those optimizations I cited were learned the hard way via extensive profiling, and were necessary because the project in question was a DHT-based service discovery and routing mesh with its own application-layer binary protocol. Written in Node (not my choice). These are the pathologies wrought by institutional inertia...
posted by invitapriore at 9:44 PM on March 25, 2016
There are actually several OS projects in Rust, schmod, but Redox is the most ambitious and most successful.
Afaik, there are no good alternatives to Rust's borrow checker, a lungful of dragon, not really.
Yes, there are efforts to fix critical C code with static analysis tools, or even valgrind, but these options require continual human effort It's easier to simply write your critical sections in Rust and expose a C API, which Rust can do because it has only a thin C-like runtime. And honestly there were already so many vulnerabilities due to small mistakes in C/C++ code that no static analysis tools can challenge the perspective that they're fundamentally unsafe.
At the other extreme, Rust's borrow checker forbids many parallelism bugs that occur mutable garbage collector (GC) based imperative languages like Go or Java. In principle, an immutable GC based functional language like Haskell, OCaML, or Erlang can beat Rust here, but that kinda limits your algorithm choices. And it's more work to prove safety of the code generated by immutable languages since their compilers play many fancy tricks like stream fusion to exploit mutability.
As an aside, it'd rock if someone altered/designed a strict immutable functional language similar to Idris to compile/through to Rust but without introducing GC. If the results were good enough, then we could see a move towards eliminating GC across the board, not sure what's possible though myself. Actually this makes a lovely PhD topic, so if that sounds interesting then talk to Edwin Brady or similar.
posted by jeffburdges at 2:46 PM on March 26, 2016 [3 favorites]
Afaik, there are no good alternatives to Rust's borrow checker, a lungful of dragon, not really.
Yes, there are efforts to fix critical C code with static analysis tools, or even valgrind, but these options require continual human effort It's easier to simply write your critical sections in Rust and expose a C API, which Rust can do because it has only a thin C-like runtime. And honestly there were already so many vulnerabilities due to small mistakes in C/C++ code that no static analysis tools can challenge the perspective that they're fundamentally unsafe.
At the other extreme, Rust's borrow checker forbids many parallelism bugs that occur mutable garbage collector (GC) based imperative languages like Go or Java. In principle, an immutable GC based functional language like Haskell, OCaML, or Erlang can beat Rust here, but that kinda limits your algorithm choices. And it's more work to prove safety of the code generated by immutable languages since their compilers play many fancy tricks like stream fusion to exploit mutability.
As an aside, it'd rock if someone altered/designed a strict immutable functional language similar to Idris to compile/through to Rust but without introducing GC. If the results were good enough, then we could see a move towards eliminating GC across the board, not sure what's possible though myself. Actually this makes a lovely PhD topic, so if that sounds interesting then talk to Edwin Brady or similar.
posted by jeffburdges at 2:46 PM on March 26, 2016 [3 favorites]
changes to npm’s unpublish policy
Seems pretty same to me.
posted by Artw at 4:44 PM on March 29, 2016 [1 favorite]
Seems pretty same to me.
posted by Artw at 4:44 PM on March 29, 2016 [1 favorite]
Introducing Safari Technology Preview
Safari Technology Preview is a standalone application that can be used side-by-side with Safari or other web browsers, making it easy to compare behaviors between them. Besides having the latest web features and bug fixes from WebKit, Safari Technology Preview includes the latest improvements to Web Inspector, which you can use to develop and debug your websites. Updates for Safari Technology Preview will be available every two weeks through the Updates pane of the Mac App Store.
posted by a lungful of dragon at 11:45 AM on March 30, 2016 [1 favorite]
Safari Technology Preview is a standalone application that can be used side-by-side with Safari or other web browsers, making it easy to compare behaviors between them. Besides having the latest web features and bug fixes from WebKit, Safari Technology Preview includes the latest improvements to Web Inspector, which you can use to develop and debug your websites. Updates for Safari Technology Preview will be available every two weeks through the Updates pane of the Mac App Store.
posted by a lungful of dragon at 11:45 AM on March 30, 2016 [1 favorite]
For the cornhub fans, here's a kernel mod for April First that provides a kernel implementation of left_pad as a Linux system call.
posted by Death and Gravity at 9:06 AM on April 1, 2016 [1 favorite]
posted by Death and Gravity at 9:06 AM on April 1, 2016 [1 favorite]
What, and incur the cost of a context switch for each call? No thanks, we'll keep doing the XMLHttpRequest to our servers in Bangalore.
posted by benito.strauss at 10:36 AM on April 1, 2016 [1 favorite]
posted by benito.strauss at 10:36 AM on April 1, 2016 [1 favorite]
hahah, you’re actually being a dick. so, fuck you. don’t e-mail me back.
This is gold
posted by bukvich at 3:51 PM on April 15, 2016
This is gold
posted by bukvich at 3:51 PM on April 15, 2016
« Older RIP Cool Moose | The Squawker Might Squeal Newer »
This thread has been archived and is closed to new comments
posted by dis_integration at 9:08 PM on March 23, 2016 [38 favorites]