1. 21
  1.  

  2. 10

    Reminded of Rob Pike’s 2000 Systems Software Research is Irrelevant, not because they espouse the same viewpoint, but because both fill me with a sense of potential and wonder. Things could be so different if only we could lift ourselves out of our current quagmire of thought.

    1. 4

      Things could be so different if only we could lift ourselves out of our current quagmire of thought.

      To overcome the current thinking, you must design a programming environment that is small, extensible, and reasonably performant. It must speak to a different needs than most industrial languages, favoring individual power over institutional concerns.

      This has all been done before: Lisp, Smalltalk, Rebol, Forth, Wirth, etc. The only missing ingredient in most hacker’s minds is the imagination required to see that their computing substrate should not require millions of dollars of investment to operate.

      That, unfortunately, is a much harder problem to solve.

      1. 1

        None of the environments you mention above require millions of dollars of investment to operate.

        OP explains why building alternatives can accelerate the problem rather than fixing it. This is probably unavoidable: Lisp, Smalltalk, Rebol, and Forth have not become the ‘new normal’ because they have not become widely taught the way C, C++, and Java have, and they haven’t become widely taught because teaching programming is treated as a way to produce new professional software engineers rather than as a way to produce well-rounded people. Unless you have the power to force a thousand universities to change their curricula against the will of professors and administrators, the best you can do is combine a demonstration with a manifesto and keep plugging it.

      2. 2

        The reason most of us are in a quagmire of thought is that it’s how we earn our paychecks. Improvements in software change just what it is that we’re working on in the quagmire. I call it the aggravation conservation law.

      3. 3

        Is this available as a talk somewhere?

        1. 1

          I’ve not been able to find anything. You could try to contact the author or the seminar at which it was presented. It doesn’t look promising, though.

        2. 2

          I don’t understand the author’s war on performance. Until we have 100% renewable power, inefficiency in software (very closely related, if not identical, to performance) comes at the cost of greater power consumption and therefore contributes to climate change. The more a piece of software is used, the larger the effect.

          Even ignoring environmental effects, inefficient software wastes user time, decreases efficiency (slow software in an interactive “hot loop”, such as an image editor, makes it more difficult for the user to focus), reduces the effective lifetime of mobile devices, generates waste heat (which oftentimes must be offset by air conditioning, which consumes more power), accelerates the obsolescence of hardware, and more.

          Finally, many optimizations can be performed transparently to the programmer, e.g. by baking them into the compiler or hiding them in a library.

          Can someone help me understand the author’s perspective?

          1. 4

            I don’t understand the author’s war on performance

            Can someone help me understand the author’s perspective?

            I think his problem isn’t with performance per se, but more the overall thinking of “performance at all costs”. For example, C compilers bend over backwards trying to exploit undefined behaviour to eek out more performance at the cost of being able to reason sanely about code (e.g., see the example at page 31). And the fact that all these gains are summarily “soaked up” by features, so the net win is zero (or even negative).

            Performance optimisations also make it much harder to figure out the mapping of the high level language to the underlying machine code, which makes the overall system more complex.