1. 13

  2. 10

    This argument glosses over a very important reason that people do stuff the “inefficient” way: leveraging giant piles of very useful pre-existing work that can’t be reused if you do things the new fast way;

    1. 8

      The other side is people do silly inefficient things just because they want to use more stuff. You don’t need Hadoop… Just because it’s prexisting and useful, it’s not a requirement that you use it.

      1. 1

        Yes, sometimes people do things inefficiently just because they’re lazy. But not always.

        1. 5

          But it’s not laziness. Or its misguided laziness. It’s more work to do these things!

          1. 1

            More work for the hardware, not the programmers.

            1. 7

              I think you’re not understanding. I could call qsort(). Or I could link with a Hadoop library and stand up a cluster. The second option is not less work for me.

              1. 3

                Intellectual laziness, where you do the thing that’s takes more work because you’re too lazy to think about how to do it a better way. I see that all the time with people.

                1. 10

                  I don’t think that’s it at all; I think one reason people opt for more complex solutions is because they think it’s somehow “better”.

                  We see a similar effect with the pricing of things. Most people will intuitively think that a $30 thingamabob will be better quality than a $10 thingamabob. Sometimes this is the case, sometimes it’s not, and sometimes the $30 may be better in one aspect whereas the $10 is better in another.

                  A second problem is that a lot of people want to be prepared to “scale” to Facebook levels, or something. Most don’t really need this, and if you run in to those kind of problems replacing your simple qsort() (or whatever) with Hadoop can still be done.

                  A third problem is that a lot of developers just want to try out Shiny New Stuff™ as it’s fun and/or looks good on their CV, not because they really need it. I have to admit that I’ve definitely been guilty of this early in my career. Arguably, it was good for my career, but probably not so good at the employer I was working for at the time as they got stuck with an overly complex solution for various problems :-(

                  1. 2


    2. 10

      It’s hard to argue with the premise that software is getting (monstrously) bloated, but this article makes the argument in such a confused, ham-fisted way, conflating and ignoring relevant distinctions, that it does its premise a complete disservice. It’s not unlike saying that both electric cars and gasoline-powered will get you from A to B in the same time, but one of those you have to wait hours to recharge, while the other refuels in seconds – so electric cars are obviously wrong. I wouldn’t want this guy arguing for my side in a debate.

      He should have just written “software is getting monstrously bloated” and left it at that. It would have been a correct statement and nobody could have found fault with it.

      1. 3

        Agreed. One of the author’s main arguments is that the web platform is bloated and “wrong” because it can’t efficiently emulate a JVM runtime language. Which…huh???

        I feel like there’s a different lesson here than the author intended: that Advent of Code -type puzzles that let you laser-focus on one metric of success are a very different kind of challenge than engineering a general-purpose platform

        1. 1

          I think their point is that what’s wrong is using a JVM runtime language emulated on the web platform in the first place in the first place.

      2. 8

        I think looking at compile and test times alone misses some possible factors. If a 10x slower compile is a 1% faster runtime, and you have seventy million servers… Or browsers…

        (For that matter, I can’t get a hello world java program to run that fast, let alone one loading the clojure jar. Hate on node, but it starts faster than that.)

        1. 6

          Often times it’s more than only 1% runtime speed. Consider C compilers for example; tcc and pcc are very fast to compile stuff; Vim is about 3 seconds with tcc vs. about 90 seconds with gcc. Great!

          But gcc and clang – which isn’t that fast these days any more – have significantly better runtime performance, even for many fairy simple programs, as tcc does almost no optimisations.

          I think it’s a matter of “the right tool for the right job”. I use tcc when developing as that gives me a quick feedback loop for silly mistakes, and clang when installing a program. Another example: when I save PNG images I just save ’em quickly in GIMP or whatever, but when I distribute them on a website I run optipng -o9 to make it them smaller (sometimes significantly so) which make take a bit for several larger images, which is okay as I only need to do it once.

          I don’t disagree with the author that the “web stack” is often times embarrassingly slow, but reducing everything to just compile speeds strikes me as too much of a simplification.

          1. 3

            The JVM just isn’t optimized for startup times, and we eventually have to accept that and move on.

          2. 5

            The whole solution, the “web stack”, is wrong. The same thing could be done faster and more efficient easily—there is just so much wasted potential. Time to admit that and start over. There are fast text editors and chat programs around, very well within capabilities of even the least powerful netbooks.

            Yet in his AoC videos, he uses VSCode. Also, his Clojure REPL takes 1.5 seconds to boot up, but doesn’t mention that the REPLs for OCaml, Python or Ruby start instantly. His argument would be much more convincing if he practiced what he preached.

            1. 1

              The whole solution, the “web stack”, is wrong. The same thing could be done faster and more efficient easily—there is just so much wasted potential.

              I say this all the time. HTML and the DOM are terrible ways to build UIs. Terrible.