4 ms·

It is a language in a constant changing environment. The web today has different requirements than 20 years ago. It's not right to criticize the reimplementatio

It is a language in a constant changing environment. The web today has different requirements than 20 years ago. It's not right to criticize the reimplementation of things in different systems. That has to happen... Paradigms shift, so thus do implementations

jonathankoren 10y ago
That doesn't explain the left-pad debacle, and the apologists defending that anti-pattern. That's a people problem, not a technology problem.
- zaphar 10y ago
  Left pad was both. The ultra small single function library approach prevalent in npm is caused by fundamental limitations of javascript in the browser. The political issues that surfaced it all was a people problem.
  - jonathankoren 10y ago
    While the impetus for a left-pad like function is due to a lack of a standard library, that's not what went wrong. Brushing the problem aside as merely a "political issue" shows that you don't understand what went wrong either. 1) The whole culture of bringing in a mass of external dependencies for single specialized functions is to be quite honest rather strange and problematic on it's own. Sure there's no standard library, but no one thinks about making one. Instead everyone makes "frameworks" for turning DIVs into BUTTONs for the 86th time. 2) Bringing in an literally an unknown number of external dependencies is dependency hell. How many different left-pads and left-pad-likes do you have? Do you even know? 3) The justification of trivial functions as standalone dependencies is justified as a vetting process. Somehow by pulling in everything separate will improve code quality? No. Fixing bugs improves code quality. Honestly, someone in this very forum justified left-pad as a standalone because it helped "find edge cases." What's the edge case in left pad? There's literally only two edges. -1 and (padtosize - len(num)). On one end you get an undefined, and on the other, your string is wrong. Even if you walk off the entire string, you get another undefined. It's a lesson 1 Intro to Programming problem. 4) Having a bunch of minimum functions makes choosing the right one impossible, or maybe it doesn't matter at all, in which case what's the point. Seriously. I was going to make a remark about "Why not just implement printf?", when a quick google found THREE! printfs on npm (format, sprint, and qprintf.) And then of course there's left pad if all you want is "%03d". 5) The actually source of the left-pad debacle is autoupdating external dependencies from the Internet. This is a horrifically Bad Idea. It was a Bad Idea before the left-pad debacle, and it's a horrifically Bad Idea after the left-pad debacle. And I have no doubt that the javascript community did not learn this lesson. Instead it appears all that was learned was to be scared of trademark claims. Autoupdating dependencies is a Bad Idea because it's how you get bugs. Seriously, if the javascript community simply didn't do this, and instead followed the best practices software engineering practices since literally the dawn of external libraries, then the whole left-pad debacle would have been greatly mitigated. The whole security injection clusterfuck happened because the kid that runs NPM got scared because "code was breaking", of course it's not his code, it's just random code on the Internet, because the javascript community doesn't employ widely implemented best engineering practices. NPM as exploit delivery vector was always there, and it's still there if you don't do proper versioning and vetting of your external libraries. Passing the buck, isn't acceptable. Left-pad was to the greater software engineering community like the scene at the end of Lord of Flies, when the adult finally shows up, looks around at the chaos and says, "What are you guys doing?"
    - kuschku 10y ago
      > Sure there's no standard library, but no one thinks about making one. Instead everyone makes "frameworks" for turning DIVs into BUTTONs for the 86th time. Well, I know that I brought javascript into this, but there are some stdlibs being built: underscore.js is one nice example. http://underscorejs.org/ http://underscorejs.org/
      - jonathankoren 10y ago
        Nice! Although, I did have to double check that it wasn't just setting "text_decoration: underline" on some span. ;)
    - zaphar 10y ago
      The problem is not as simple as just a missing stdlib. The problem is a standard lib that doesn't ship with the browser compounded by the fact that javascript build pipelines can't easily and in fact don't do dead code elimination. So shipping an entire stdlib 60-70% of which you don't actually use to the browser is a terrible idea. Javascript really is a special snowflake here and refusing to recognize that is problematic to say the least.
jonaf 10y ago
Abstract concepts that are necessary for software to be useful or practical are applicable despite the alleged changing environment. If they weren't, js/node wouldn't be reinventing these concepts, like package and dependency management. I think it's good to revisit occasionally to see if there's a better way, but my experience with node has always been an amalgam of cognitive arrogance and assumptions about how "those guys" (any other software ecosystem) built a needlessly complex and bloated or slow solution to a common problem. At the end, these solutions are equally complex or lack major features, such as security or stability. I'll point to one major counterpoint before anyone else does though: JSON turned out to be pretty handy. I am glad we didn't stick with XML, although that's what browsers expected in the early 2000's (Ajax/xmlhttprequest).
- TeMPOraL 10y ago
  > I'll point to one major counterpoint before anyone else does though: JSON turned out to be pretty handy. I am glad we didn't stick with XML, although that's what browsers expected in the early 2000's (Ajax/xmlhttprequest). You didn't look behind far enough. S-expressions were pretty handy and performed more-less the same task as JSON (besides being used for stuff like representing code). Using XML as a data serialization format was a mistake, and I'm glad we're finally recovering from it, even though it took the new generation to reinvent some wheels to get there.
sklogic 10y ago
It was fairly trivial to foresee the requirements. I was ranting about how stupid html is back in 1993. If things were done the Lisp way back then, we would not have seen any of this "changing environment" epic circus.
- TeMPOraL 10y ago
  Alas, "worse is better" (or so they say), and the industry decided to reinvent everything every 5 years :(.

jonathankoren 10y ago

That doesn't explain the left-pad debacle, and the apologists defending that anti-pattern. That's a people problem, not a technology problem.

zaphar 10y ago
Left pad was both. The ultra small single function library approach prevalent in npm is caused by fundamental limitations of javascript in the browser. The political issues that surfaced it all was a people problem.
- jonathankoren 10y ago
  While the impetus for a left-pad like function is due to a lack of a standard library, that's not what went wrong. Brushing the problem aside as merely a "political issue" shows that you don't understand what went wrong either. 1) The whole culture of bringing in a mass of external dependencies for single specialized functions is to be quite honest rather strange and problematic on it's own. Sure there's no standard library, but no one thinks about making one. Instead everyone makes "frameworks" for turning DIVs into BUTTONs for the 86th time. 2) Bringing in an literally an unknown number of external dependencies is dependency hell. How many different left-pads and left-pad-likes do you have? Do you even know? 3) The justification of trivial functions as standalone dependencies is justified as a vetting process. Somehow by pulling in everything separate will improve code quality? No. Fixing bugs improves code quality. Honestly, someone in this very forum justified left-pad as a standalone because it helped "find edge cases." What's the edge case in left pad? There's literally only two edges. -1 and (padtosize - len(num)). On one end you get an undefined, and on the other, your string is wrong. Even if you walk off the entire string, you get another undefined. It's a lesson 1 Intro to Programming problem. 4) Having a bunch of minimum functions makes choosing the right one impossible, or maybe it doesn't matter at all, in which case what's the point. Seriously. I was going to make a remark about "Why not just implement printf?", when a quick google found THREE! printfs on npm (format, sprint, and qprintf.) And then of course there's left pad if all you want is "%03d". 5) The actually source of the left-pad debacle is autoupdating external dependencies from the Internet. This is a horrifically Bad Idea. It was a Bad Idea before the left-pad debacle, and it's a horrifically Bad Idea after the left-pad debacle. And I have no doubt that the javascript community did not learn this lesson. Instead it appears all that was learned was to be scared of trademark claims. Autoupdating dependencies is a Bad Idea because it's how you get bugs. Seriously, if the javascript community simply didn't do this, and instead followed the best practices software engineering practices since literally the dawn of external libraries, then the whole left-pad debacle would have been greatly mitigated. The whole security injection clusterfuck happened because the kid that runs NPM got scared because "code was breaking", of course it's not his code, it's just random code on the Internet, because the javascript community doesn't employ widely implemented best engineering practices. NPM as exploit delivery vector was always there, and it's still there if you don't do proper versioning and vetting of your external libraries. Passing the buck, isn't acceptable. Left-pad was to the greater software engineering community like the scene at the end of Lord of Flies, when the adult finally shows up, looks around at the chaos and says, "What are you guys doing?"
  - kuschku 10y ago
    > Sure there's no standard library, but no one thinks about making one. Instead everyone makes "frameworks" for turning DIVs into BUTTONs for the 86th time. Well, I know that I brought javascript into this, but there are some stdlibs being built: underscore.js is one nice example. http://underscorejs.org/ http://underscorejs.org/
    - jonathankoren 10y ago
      Nice! Although, I did have to double check that it wasn't just setting "text_decoration: underline" on some span. ;)
  - zaphar 10y ago
    The problem is not as simple as just a missing stdlib. The problem is a standard lib that doesn't ship with the browser compounded by the fact that javascript build pipelines can't easily and in fact don't do dead code elimination. So shipping an entire stdlib 60-70% of which you don't actually use to the browser is a terrible idea. Javascript really is a special snowflake here and refusing to recognize that is problematic to say the least.

jonaf 10y ago

Abstract concepts that are necessary for software to be useful or practical are applicable despite the alleged changing environment. If they weren't, js/node wouldn't be reinventing these concepts, like package and dependency management. I think it's good to revisit occasionally to see if there's a better way, but my experience with node has always been an amalgam of cognitive arrogance and assumptions about how "those guys" (any other software ecosystem) built a needlessly complex and bloated or slow solution to a common problem. At the end, these solutions are equally complex or lack major features, such as security or stability. I'll point to one major counterpoint before anyone else does though: JSON turned out to be pretty handy. I am glad we didn't stick with XML, although that's what browsers expected in the early 2000's (Ajax/xmlhttprequest).

TeMPOraL 10y ago
> I'll point to one major counterpoint before anyone else does though: JSON turned out to be pretty handy. I am glad we didn't stick with XML, although that's what browsers expected in the early 2000's (Ajax/xmlhttprequest). You didn't look behind far enough. S-expressions were pretty handy and performed more-less the same task as JSON (besides being used for stuff like representing code). Using XML as a data serialization format was a mistake, and I'm glad we're finally recovering from it, even though it took the new generation to reinvent some wheels to get there.

sklogic 10y ago

It was fairly trivial to foresee the requirements. I was ranting about how stupid html is back in 1993. If things were done the Lisp way back then, we would not have seen any of this "changing environment" epic circus.

TeMPOraL 10y ago
Alas, "worse is better" (or so they say), and the industry decided to reinvent everything every 5 years :(.