7 ms·

Doing a for loop is not equal to re-inventing the wheel. Words and phrases have lost their meaning nowadays. By the JS community's standards if I wanted code

Doing a for loop is not equal to re-inventing the wheel. Words and phrases have lost their meaning nowadays. By the JS community's standards if I wanted code to capitalize the 3rd or sometimes 4th letters of a string, they would be 2 different npm modules. Maybe they didn't forget how to program, as the article implies; maybe they never knew how to program in the first place.

nailer 11y ago
Writing your own solution, when you could use a common widely known solution, exactly matches both writing your own left pad and inventing your own wheel. > By the JS community's standards if I wanted code to capitalize the 3rd or sometimes 4th letters of a string, they would be 2 different npm modules. If there was, it would have been published and people would be depending on it. Instead, people use the stdlib first, then big lego bricks like underscore, then (when they don't want the bulk of big lego bricks) smaller lego bricks. A single capitaliseMap() might be in there but it's a much more specific case than padding.
- rantanplan 11y ago
  A 1-line of code module matches your needs exactly just for today. When you have 100 such modules which don't quite work and don't quite need after a month(quite a long time for a JS project to exist untouched), then your dependency hell shows its ugly head. If you had years of experience in a wide array of technologies and languages, you'd be aware of that which is, and has been, obvious to the rest of us for the past 2-3 decades.
  - nailer 11y ago
    > A 1-line of code module matches your needs exactly just for today. Nothing about function length determines utility. There are many one lines that match many people's needs repeatedly. > When you have 100 such modules which don't quite work This is worrying. How are you picking the modules you use? 100x popular modules from npm - with git repos, unit tests, READMEs, and hundreds of other users - beat 100x functions implemented in-house for NIH (or more likely, 100x functions copy pasted from Stack Overflow). > If you had years of experience in a wide array of technologies and languages Please don't assume things about other people. It's very rude, and it makes you look bad when you're wrong.
    - rantanplan 11y ago
      Worry not my friend. I'll take the risk of being wrong. Up to now, it seems that there's consensus on the fact that the JS/frontend world is the worst offender when it comes to engineering robust software. At least there are JS programmers that seem aware of it and agree that this has to change. So there's still hope I guess.
      - nailer 11y ago
        I think there are people who are aware of the problem, but that problem is people reinventing the wheel a thousand times, and relying on copypasta and needless work rather than package management.
      - lotsoflumens 11y ago
        > JS/frontend world is the worst offender when it comes to engineering robust software I completely agree. I still can't understand why the language that we depend on for increasingly large-scale front-end work still works like this: [1, 10, 2, 21].sort() // returns: [1, 10, 2, 21] It's 2016, software engineering is purported to be a profession, and we still have the worst tools imaginable.
        vicx 11y ago
        Yep. And very large software developers have created languages that compile to javascript ... it is madness but it solves their problems.
        nailer 11y ago
        Try .sort(sorts.numerical) Using npms 'sorts' module
        Sleaker 11y ago
        I think the only thing you highlighted is why weakly typed languages have issues with readability. Looks like it sorted it fine to me.
- askyourmother 11y ago
  But surely the really concerning part is despite their very wide usage, these dependecies turned out in some cases to be poorly coded functions indeed. Throughout this whole thread are examples where these one or two line "modules" have poor runtime performance, miss key cases in the one single thing they claim to do, and in the very worst cases, those small "modules" themselves are depending on many more "modules". Diseases turtles all the way down.
  - nailer 11y ago
    > Throughout this whole thread are examples where these one or two line "modules" have poor runtime performance, miss key cases in the one single thing they claim to do, and in the very worst cases, those small "modules" themselves are depending on many more "modules". Where? I've only seen the exact opposite: folk who don't believe in package management write their own naive 'reinvent the wheel functions' with those issues. Nobody I can see is quoting actual npm modules.

nailer 11y ago

Writing your own solution, when you could use a common widely known solution, exactly matches both writing your own left pad and inventing your own wheel. > By the JS community's standards if I wanted code to capitalize the 3rd or sometimes 4th letters of a string, they would be 2 different npm modules. If there was, it would have been published and people would be depending on it. Instead, people use the stdlib first, then big lego bricks like underscore, then (when they don't want the bulk of big lego bricks) smaller lego bricks. A single capitaliseMap() might be in there but it's a much more specific case than padding.

rantanplan 11y ago
A 1-line of code module matches your needs exactly just for today. When you have 100 such modules which don't quite work and don't quite need after a month(quite a long time for a JS project to exist untouched), then your dependency hell shows its ugly head. If you had years of experience in a wide array of technologies and languages, you'd be aware of that which is, and has been, obvious to the rest of us for the past 2-3 decades.
- nailer 11y ago
  > A 1-line of code module matches your needs exactly just for today. Nothing about function length determines utility. There are many one lines that match many people's needs repeatedly. > When you have 100 such modules which don't quite work This is worrying. How are you picking the modules you use? 100x popular modules from npm - with git repos, unit tests, READMEs, and hundreds of other users - beat 100x functions implemented in-house for NIH (or more likely, 100x functions copy pasted from Stack Overflow). > If you had years of experience in a wide array of technologies and languages Please don't assume things about other people. It's very rude, and it makes you look bad when you're wrong.
  - rantanplan 11y ago
    Worry not my friend. I'll take the risk of being wrong. Up to now, it seems that there's consensus on the fact that the JS/frontend world is the worst offender when it comes to engineering robust software. At least there are JS programmers that seem aware of it and agree that this has to change. So there's still hope I guess.
    - nailer 11y ago
      I think there are people who are aware of the problem, but that problem is people reinventing the wheel a thousand times, and relying on copypasta and needless work rather than package management.
    - lotsoflumens 11y ago
      > JS/frontend world is the worst offender when it comes to engineering robust software I completely agree. I still can't understand why the language that we depend on for increasingly large-scale front-end work still works like this: [1, 10, 2, 21].sort() // returns: [1, 10, 2, 21] It's 2016, software engineering is purported to be a profession, and we still have the worst tools imaginable.
      - vicx 11y ago
        Yep. And very large software developers have created languages that compile to javascript ... it is madness but it solves their problems.
      - nailer 11y ago
        Try .sort(sorts.numerical) Using npms 'sorts' module
      - Sleaker 11y ago
        I think the only thing you highlighted is why weakly typed languages have issues with readability. Looks like it sorted it fine to me.
askyourmother 11y ago
But surely the really concerning part is despite their very wide usage, these dependecies turned out in some cases to be poorly coded functions indeed. Throughout this whole thread are examples where these one or two line "modules" have poor runtime performance, miss key cases in the one single thing they claim to do, and in the very worst cases, those small "modules" themselves are depending on many more "modules". Diseases turtles all the way down.
- nailer 11y ago
  > Throughout this whole thread are examples where these one or two line "modules" have poor runtime performance, miss key cases in the one single thing they claim to do, and in the very worst cases, those small "modules" themselves are depending on many more "modules". Where? I've only seen the exact opposite: folk who don't believe in package management write their own naive 'reinvent the wheel functions' with those issues. Nobody I can see is quoting actual npm modules.