1. 3

    I love bug-hunting stories like this! This reminded me of the old Raymond Chen post “In the product end game, every change carries significant risk” (https://devblogs.microsoft.com/oldnewthing/20091104-01/?p=16143). Similar to this story, an innocuous-looking change made memory shift around in a way that cascaded into a huge change in behavior.

    The lesson I take away is to not let months of changes build up between deploys.

    1. 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.