1. 29
  1.  

  2. 4

    This is a great bit of computer forensics and a great article. It’s what I have lobste.rs for.

    That’s it. If you write code that is going to be run by others then make sure that it scales well enough to handle any conceivable data set – reasonable or not. Quadratic algorithms usually fail that test.

    I have a differing opinion. To write everything so that it can handle any size of input is wasteful. This is software engineering after all, not just programming. Rather it is important that a feature must not become unusable once the user goes out of bounds, and there must be a graceful failure.

    1. Design for the most likely use case and
    2. Have a failover when the user goes out of parameters

    In this case, once the number of files gets too large, or it’s taking too long to arrange the icons, fail back to a simpler solution that is not so fancy. For example, paginate: show the first 100 files followed by a clear UI concept that tells the user what is going on.

    1. 3

      I see two possible points of trouble with that approach:

      • judging what is ‘simpler’. In the example you give I think pagination is actually more complex than changing the layout algorithm to a non-quadratic one.
      • even if the alternative is ‘simpler’, it’s still am extra code path that hardly ever gets used and is likely to be ignored during testing, with the result that it is likely to have latent bugs.

      In my experience a single solution always beats (in terms of fewer bugs, fewer maintenance costs, …) two solutions for parts of the domain, especially if the single solution is basically an improved version of one of the two.

      1. 2

        In practice going from a less efficient algorithm to a more efficient one often involves additional complexity and resources. Say caching is needed, or the need to handle more edge cases. Once these additional complexities are built it is often costly to maintain them. It is often better to have a simpler algorithm with another simple failover (e.g. a simple algorithm + pagination) than one complex algorithm that has complex resource and maintenance requirements.

    2. 3

      Working with closed systems sounds like hell.

      Like, a lot of the stories on randomascii are good. They’re well-written, they’re good work, and they show off great tooling. But…

      I don’t have access to this source code but I looked through the stacks for a bit and they seemed to suggest that explorer.exe was spending more than 20 seconds doing a lot of tasks related to… arranging icon positions.

      I couldn’t live with something with that. I’m way too used to just being able to read the source code to figure out why something is doing something and why. Googling error messages and finding the exact error message string in some git repo, profiling something and googling the slow function signature and finding a github mirror where I can browse the source code, navigating to the device driver in torvalds/linux on github if some hardware is spitting out warnings. Living in a world where all you have is the machine code seems horrible.

      If I was experiencing this issue on my desktop, I would literally just browse to the icon layout code in the GNOME desktop-icons extension and look at the algorithm, and that would be that.

      And this…

      I don’t know how many people this bug affects (anyone with 200-300 icons is hitting a modest version of this, and it gets progressively worse with more) and I have no power to fix it. So, I filed a bug. I am not hopeful that it will be fixed. My last quadratic-in-Windows bug has had zero comments since it was filed a few months ago.

      What a sad world. You have spent a long time diagnosing the problem, figured out exactly what’s wrong, you have good idea of how you can fix it… but you can’t, you’re just hoping that some random intern at Microsoft triages it and gets the attention of someone with commit access.

      1. 3

        Working with closed systems sounds like hell.

        Can I ask more about what you work on?

        Although open source systems have dominated many spaces, it’s still hard to find a space where they don’t end up interacting with a closed component or service. I saw in your bio that you work on embedded systems, but note that the experiences of embedded developers and embedded users are typically very different. To a user, an embedded system is typically very closed, and if something misbehaves even the tooling to perform debugging and diagnosis is absent.

        1. 1

          I was mostly talking about the working environment, where you’re dependent on the environment working as it should. There are areas where the closedness of the system doesn’t have a huge effect, such as, say, games or appliance-like hardware with a microcontroller. That said though, there are probably users out there who would’ve enjoyed the products I work on more if they were open source and hackable.

          When it comes to my own workflow, it’s almost entirely tools I have the source code to, either because the tools are open source (such as GCC, Yocto, the st-* tools to interact with STM32s, and the desktop Linux systems I’m using these tools from) or because the tools were written by people at the company I work for.