1. 34

  2. 12

    A lot of this rant is in an uncomfortable area wherein I laugh at it because it’s true, and funny … while simultaneously cringing because I’m guilty of what he’s writing about. Especially the “childlike enthusiasm for new toys” part.

    Also, when people talk about Go as “safe but boring” I think back to 2011 when a few co-workers started using it and got shit for doing work in some weirdo new language. (Ditto Java ditto 1995 — I remember ranting back then how we should rewrite everything, down to the OS, in Java. RWIIJ!!)

    I do have to call out this bit, though:

    If software engineers were allowed to capture more of the value they create, we’d have vastly fewer billionaires and more software engineers with normal upper middle class lifestyles, such as houses owned in the clear and successful reproductive lifecycles.

    The software engineers I know are doing ok. The ones who should be first in line at the value-capturing party, IMHO, are the minimum-wage warehouse and delivery workers at Amazon.

    1. 11

      They’re not called “analogies” in category theory, but allegories.

      I don’t really know if anything in here is useful. The author seems to be speaking simultaneously towards apathetic and bored laborers and also towards ineffective and craven management, focusing mostly on business practices while ignoring anything which actually touches on the nature of programming. The artificial division of programmers into “developers” and “engineers” is poorly defended.

      The highlight has to be this hilariously defective reasoning:

      Haskell is mostly a researchy/academicy language. I don’t know, but I strongly suspect its run of the mill libraries dealing with stuff like network and storage is weak and not fully debugged.

      They go on to explain how Haskell is “fancy”, and not “boring”; only “boring” languages are acceptable. However, I assure you that Haskell is just another programming language. The “fancy” category-theoretic reasoning is today balanced by a “boring” Haskell wiki page explaining the correct way to reason about Haskell code. There are both good and bad libraries uploaded to Hackage. There are folks interested in writing long-term stable APIs, just like there are folks interested in experimenting and trying new things.

      More seriously, the author’s argument doesn’t explain why Nix or OCaml or any other cousin of Haskell could exist as a “boring” language which is primarily used by its community in order to get things done at a reasonable pace. There are memetic elements to community practice and most of Haskell’s reputation comes from those memes. The author has heard too many of these memes and not put in any time or effort debunking them.

      From a hiring manager or engineer’s perspective, the choice to develop in a weird high productivity language is fraught. What happens if the thing crashes at 4 in the morning? Do you have enough spare people someone can be raised on the telephone to fix it? What if it’s something up the dependency tree written by an eccentric who is usually mountaineering in the Alps?

      I remember hearing this argument against Python over a decade ago. Our system administrator was suspicious of Python’s ability to do anything, while our lead programmer had demonstrated that Python was adequate for the task at hand. During a demonstration, the lead programmer saturated a 16-core machine with 100% load per core using Python; the system administrator could not believe it and was flabbergasted at the idea that Python could do such a thing. I think that, for some reason, the meme that “Python is slow” had transformed in their mind into some sort of idea that Python is a hobgoblin of resources, an avatar of inefficiencies, etc. But, of course, Python is just another programming language.

      Most of the time, your real problem is shitty data, so using the most accurate tool is completely useless.

      If the author wants to learn some boring linear algebra, then there are techniques for integrating noisy data. However, they’ll have to learn about sheaves and other category-theoretic constructs!

      Maybe the author should go out and learn how to do new things instead of ranting about stuff that they admittedly haven’t researched or tried to experience.

      1. 6

        I read his argument more generally, probably because I’m too far from Haskell or any of its cousins for those references to resonate quite so personally.

        I once spent 18 months rewriting a library that someone had implemented using some amazing patterns, leaning on novel C++ language features early in those features’ long, slow trip through the standards process. The design was incredibly clever, and I still like it on a certain level today, but teaching people to use it without writing gnarly bugs was hard.

        Debugging it was a black art that I eventually managed to do for my own programs but never did successfully teach to anyone who didn’t know the original author personally.

        When the standardized versions of the concepts he’d used shipped in other compilers, it needed rewriting anyway in order to work on anything other than a 2002-ish MS compiler.

        The arguments in this essay sounded like a rant against template metaprogramming in C++ that I could’ve written in 2005. And my rant wouldn’t have come from a place of fear of novelty or inability to learn new things. Mine would stem from hard earned caution about how I rely on novelty and aggravation with very smart colleagues who were not sufficiently cautious about how they used novel things.

        That’s how I read the piece, anyway. Beyond the attack on feckless management of course :)

      2. 10

        Pragmatism and purism are healthy drives that any engineer should possess simultaneously. While at work, 40% of my brain is arguing why I need to just get the job done, another 40% argues how that’ll bite us down the line, while the remaining 20% is busy typing out some code. Praising one of these above the other is pointless, it’s like saying you should always steer left while riding a bike, because people who always steered right ended up kissing the pavement.

        On a separate note, I’m really disappointed that such a low-effort and abrasive rant got popular on this site. I guess this is becoming another orange site…

        1. 4

          While the post was accurately labeled “rant”, I do feel the site’s upvote-based rankings are an imperfect way to surface the best content. I don’t have a better alternative in mind.

          But there is a mechanism for influencing the overall tone of the content and commentary, which is to invite your friends. That feature can be to your advantage, if you’re willing to invite friends to a community with a range of viewpoints. You may have to ask them to get comfortable with confrontation for the good of the community.

        2. 6

          That rant was a good read on more than one level, but the link to Joel Spolsky’s review of the JWZ interview he read was worth reading the piece all by itself.

          And why’d you have to add another book to my reading list, ya’ jerk?!

          1. 5

            jwz’s response to it is worth reading, too ;-). The gist of it:

            So I guess to the extent that he puts me up on a pedestal for merely being practical, that’s a pretty sad indictment of the state of the industry.

            1. 1

              Thank you for digging that up. I hadn’t found it yet.

              1. 1

                Eh, wasn’t hard to dig it out, I follow jwz’s blog so I remembered it pretty quickly, I just had to look it up.

          2. 5

            Probably my favorite bit:

            This is a danger in putting software developers or programmers in charge. These guys are often child-like in their enthusiasm for new and shiny things. Engineers are different: they’re trying to solve a problem. Engineers understand it’s OK to solve the problem with ephemeral, trashy, but fast-to-market solutions if the product manager is going to change it all next week. Engineers also plan for the future when the software is critical infrastructure that lives and fortunes may depend on. Engineers don’t build things that require mixed integer programming unless it’s absolutely necessary to solve a real world problem. If they juggle on unicycles, they do it on their own time; not at work.

            The utility of doing throwaway work while exploring the solution space is huge, and I’ve seen many developers who don’t understand that get super upset first when folks that do get it push for what they think is sloppy code, only to get massively demoralized when (surprise surprise!) business needs change and all their hard work gets thrown out with naught but a Trello card.

            Meta-commentary: the grumpiness from other lobsters in this thread is interesting…article may have touched a nerve, eh chummers?

            1. 3

              ephemeral, trashy, but fast-to-market solutions

              There is nothing so permanent as “temporary.”

            2. 5

              It’s a bozo spotting clowns. The best defense against this guy is to become reflective.

              I’ve become numb to being called a clown by people trying to defend their way to work. Because I’m trying Haskell in production or otherwise experimenting with things off mainstream. They fail to notice they’re promoting that you’d have a circus instead. For example his blog running Wordpress on PHP. When something fails, there’s some fool to fix it because you got a lot of buffoons that are interchangeable. But essentially it’s the same stuff, except in bigger scale.

              It’s just you attacking things that are new or non-usual. And what’s with you against fun and clowns? Of course it’s hilarious thing that you forgot you painted your face, put a suit on and that you got your own unicycle that you’re riding. And you wonder where the impostor syndrome comes from. Maybe it’s because the whole thing is a circus and you have noticed it but not ready to accept it?

              1. 7

                And what’s with you against fun and clowns?

                A pie in the face at 0200 when you’re on-call is seldom welcome, and topping it off with a spray of seltzer from unfamiliar stacktraces is equally annoying.

              2. 3

                In my view, the reason to learn “fancy” stuff like Haskell, Prolog, Idris, what have you is not to use them in production, it’s for the exposure to a new approach to system design. I think it can be very easy to get caught in a local minimum if all you focus on is pure pragmatism and getting the job done; building something in an entirely novel and perhaps quite bizarre way can be a good way to explore the landscape. Of course, there is a time and a place for all that – if you are building some safety-critical system that might kill someone or cost millions if it goes wrong then of course you stick to the tried and tested solutions, but only ever doing that I think is losing out in the long term.