1. 69
  1.  

  2. 14

    This is why computational thinking is important. Presumably the author of that script is an intelligent and capable academic in their own field, but when one has not had a little guidance in developing the mental framework necessary to reason about computation it is very easy to shoot oneself in the foot.

    1. 8

      Minor nitpick:

      Furthermore, there is literally no way to tell whether your program will ever actually terminate without actually executing it.

      That is wrong. It is true that it is not possible to write a program that determines for any other program whether it terminates. But for a specific program, in particular for relatively simple algorithms as discussed in the post, it is often possible and not even hard to prove termination.

      1. 3

        Some domain specific languages exploit that: dtrace’s language is structured so that (without some heinous hacks) it’s impossible to not terminate, and given that code written in that language is injected into other code, that’s a pretty useful trait.

      2. 2

        I’ve seen similar scripts across my company that “work”, but can stand to be heavily optimized. I think people also don’t realize that if someone is blocked, waiting on the output of some long running script, they are wasting unnecessary company time and therefore, money.

        Sure, 30 minutes isn’t very long in a discrete event, but extrapolate that over months and/or years and you’ve got yourself quite an expensive operation. I do believe that anyone who tries can code, but it’s worth investing in the people who can do these sorts of optimizations and it’s absolutely worth paying the upfront cost of planning and developing the right algorithms.

        1. 5

          In my experience it’s not really the wasted wall-time-dollars that matter; rather it’s the related opportunities you miss. If it takes 30 minutes to run a function, you’re going to do a lot fewer iterations (if any) on the data you’re putting in or set of interesting correlations you might be capturing along the way, nor will you choose to re-use that code in anything that needs to be done often.

          1. 1

            I don’t believe a less technically inclined person would be able to quantify the loss of related opportunities. I also don’t believe they would know the optimal usage stopping point of less than performant code.

            I still think businesses shouldn’t overlook the people who take the time to analyze the entire situation, regardless of the resultant benefit.

          2. 3

            Worse, I find I’m most prone to get distracted during long build times. I’ll start working on another task if it’s even possible (if I work on the same codebase on a long build, it might break the build if the IDE saves my changes) or get bogged down in email or slack, and forget to check the progress bar.

            I’ve taken to grafting in text to speech notifications in my build and lint scripts just to remind me what I was waiting on.

            1. 1

              This too! People in JS-land put up with a lot of bad stuff just to get rapid turn-around.

          3. 2

            While the result is true I don’t like the intro or the premise. If that’s a one-off calculation 30 mins is perfectly fine, the original code is very readable and straightforward. I’m pretty sure anyone who hasn’t solved this specific problem would take longer than 30min to develop the fast, more complicated solution. And at some point (running it 5-10x) it’s worth it, absolutely. Also you don’t need a CS education to learn about O-notation and complexity, you need some programming practice.

            1. 1

              I’d argue there’s a difference between scripting experience and programming experience, and a degree, a boot camp, or even just a few Hacker rank/Euler problems will tell you what kinds of algorithms have terrible complexity. You can get pretty far writing scripts that just pipeline data from one program to another.

              I think a good cs degree is handy for introduction to the more abstract concepts around programming, which makes it easier to pick up new paradigms and more specialized or esoteric languages. I don’t regret getting one even though I don’t think I needed it to get started in the software industry.