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

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

Page:

  1. cbars Bronze badge

    eh?

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

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

    1. mythicalduck

      Re: eh?

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

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

      1. Roo
        Windows

        Re: eh?

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

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

    2. This post has been deleted by its author

      1. Anonymous Coward
        Anonymous Coward

        Re: eh?

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

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

        1. This post has been deleted by its author

          1. Anonymous Coward
            Anonymous Coward

            Re: eh?

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

            So don't use them. Simple.

            "No inclusion of callstack displaying"

            backtrace()

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

            Which probably just call down to the C ones anyway.

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

            So use Boost then.

            "String formatting is very slow in the C library"

            No it isn't. Its actually pretty quick.

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

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

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

            1. This post has been deleted by its author

              1. Anonymous Coward
                Anonymous Coward

                Re: eh?

                "No thanks."

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

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

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

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

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

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

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

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

                1. This post has been deleted by its author

                  1. Anonymous Coward
                    Anonymous Coward

                    Re: eh?

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

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

                    "OpenSSL. ;)"

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

                    1. This post has been deleted by its author

                2. This post has been deleted by its author

            2. This post has been deleted by its author

    3. This post has been deleted by its author

    4. J.G.Harston Silver badge

      Re: eh?

      EXACTLY!

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

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

  2. Electron Shepherd

    Are these dynamic dependencies really a good idea?

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

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

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

    1. Missing Semicolon Silver badge
      Devil

      Re: Are these dynamic dependencies really a good idea?

      ... and don't even mention Maven!

    2. Adam Azarchs

      Re: Are these dynamic dependencies really a good idea?

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

      1. Phil O'Sophical Silver badge

        Re: Are these dynamic dependencies really a good idea?

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

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

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

        Dynamic dependencies like this are a security nightmare.

        1. Fatman

          Re: Are these dynamic dependencies really a good idea?

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

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

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

    3. Munchausen's proxy
      Pint

      Re: Are these dynamic dependencies really a good idea?

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

      In the immortal words of Tom Lehrer:

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

      That's not my department, says Werner von Braun

      1. John 104

        Re: Are these dynamic dependencies really a good idea?

        @Munchausen's proxy

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

    4. allthecoolshortnamesweretaken
      Coat

      Re: Are these dynamic dependencies really a good idea?

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

    5. Qix-

      Re: Are these dynamic dependencies really a good idea?

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

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

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

      1. Kristian Walsh Silver badge

        Re: Are these dynamic dependencies really a good idea?

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

      2. Doctor Syntax Silver badge

        Re: Are these dynamic dependencies really a good idea?

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

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

      3. Domino
        Alert

        Azer's childish decision

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

        1. Archie Woodnuts

          Re: Azer's childish decision

          Pretty much this ^

        2. Ben Tasker

          Re: Azer's childish decision

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

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

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

          1. The First Dave

            Re: Azer's childish decision

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

            1. Roland6 Silver badge

              Re: Azer's childish decision

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

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

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

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

    6. Christian Berger

      Dependencies are always a problem

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

    7. This post has been deleted by its author

    8. bombastic bob Silver badge

      Re: Are these dynamic dependencies really a good idea?

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

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

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

      This is why _I_ always:

      a) statically link

      b) write "my own" for trivial functionality

      c) avoid shared packages unless they make sense

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

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

      1. energystar

        Basically...

        Basically like this bombastic advice :)

  3. Herby

    Maybe the lazy in us expects...

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

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

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

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

    1. Anonymous Coward
      Anonymous Coward

      Re: Maybe the lazy in us expects...

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

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

      And I'd use git instead of NPM.

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

      1. Qix-

        Re: Maybe the lazy in us expects...

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

      2. Doctor Syntax Silver badge

        Re: Maybe the lazy in us expects...

        "the implicit contract"

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

    2. Yet Another Anonymous coward Silver badge

      Re: Maybe the lazy in us expects...

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

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

      Within a coupe of seconds?

      1. Anonymous Coward
        Anonymous Coward

        Re: Maybe the lazy in us expects...

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

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

        1. bombastic bob Silver badge

          Re: Maybe the lazy in us expects...

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

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

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

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

      2. Phil O'Sophical Silver badge

        Re: Maybe the lazy in us expects...

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

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

        Within a coupe of seconds?

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

        1. Truth4u

          Re: Why would you need it it seconds anyway?

          At 4:59pm you might

  4. Anonymous Coward
    Anonymous Coward

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

    1. Anonymous Coward
      Anonymous Coward

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

  5. Missing Semicolon Silver badge
    Happy

    So, theft is better than failure?

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

    1. Anonymous Coward
      Anonymous Coward

      Re: So, theft is better than failure?

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

      1. Qix-

        Re: So, theft is better than failure?

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

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like