1. 18
  1.  

  2. 7

    I notice that all of these examples have to do with a specific programming problem, namely moving from non-concurrent to concurrent execution models. This is something that most programming languages have been historically bad at because of lack of need, and modern programming languages are being built with specific features to make safely writing concurrent programs easier. So it’s possible that this issue of software rot is really more about the difficulty of managing a specific programming problem, namely introducing concurrency to an environment which previously lacked it.

    1. 3

      I feel this is a big part of it. I also think nobody currently trying to fix it is pointed in the right direction, with the possible exception of Pony.

    2. 5

      Chrome was written from scratch? It is based on WebKit, which came from KHTML, which came from khtmlw in 1998.

      Also, the Python GIL is not “an obvious and glaring defect”. It is a tradeoff and in my opinion the right one.

      1. 2

        I don’t think the title fits the content, but the content is good. Nice examples.

        I don’t think of it as “software rot”. But yes to a large extent your program architecture is fixed from the very beginning.

        Another example that is close to home is bash as an interactive tool vs. a programming language. The interactive parts seem to dominate, which does make some sense since that’s how most people use it. But it’s also used as a programming language for large and long-lived programs, and it’s pretty bad for that.

        Although it’s interesting that Bourne sh was already a programming language by the time bash was started. So the bash developers could have made a go at that problem, at least from the implementation POV if not the language design POV. But it doesn’t seem better than any of its predecessors in this regard.

        On second thought the word “rot” isn’t totally wrong for bash. It is calcified and drastic changes can no longer be made. It’s not exactly rot but it is age.

        1. 2

          I prefer ‘ossification’.

          1. 3

            I like “fossilization”.

            My prime example is TeX. It is easy to come up with extensions (ttf fonts, better scripting language, better figure placement, text flow around things, grid layout, text baseline alignment, avoid rivers, parallelized), yet backwards compatibility makes it impossible. XeTeX and LuaTeX are two attempts, but it took them many years and they are not completely backwards compatible.

            I believe that a TeX rewrite from scratch would find its niche, but it is a huge project where you have to reinvent most of TeX. Not-there-yet attempts are Lout, Patoline, SILE, Pollen, and in a wider sense DocBook, PrinceXML, and Adobe inDesign.

        2. 1

          Adapting mature software to new circumstances tends to take more time and effort than writing new software from scratch.

          We should distinguish between switching to new circumstances and extending for new circumstances. Switching means to drop the old features, then you can write from scratch. If you want to extend it and keep all the old features, writing from scratch probably takes more time because you have to reinvent all the old features.

          1. 1

            Yes but what do we do about it?

              1. 1

                You know you’ve found something cool when you start with one link and end up with 6 tabs from the links in the first. Awesome stuff you’re working on!

                1. 2

                  Thanks for the kind words! One of my premises for rewrite-friendliness is that just reading code will only teach you so much. Projects have to be easy to run and play with, get hands dirty with. So if you were to play with Mu I’d love an email or something about how it went and any issues you ran into.

                2. 1

                  Intredasting. Chur.

              2. 0

                At least in the Python case (and I suspect, but don’t know, in the Apache case) there’s a “philosophical” reason for the design. Sure it would take a lot of elbow grease to get rid of the GIL in CPython but as far as I know, no one has ever argued it’s impossible, the standard line is that there’s no particularly good reason to. Python’s answer to parallelism is that it’s an OS level problem, which is a much more reasonable answer than people seem to give it credit for. OS designers have been grappling with the problem for longer than most (any?) language designers. It’s not “rot” to draw different system boundaries than competitors.

                I can’t think of any mainstream programming language that attempts to wrest disk IO away from the OS, so I don’t get why it’s seen as a mortal flaw when Python does the same thing with multi-core utilization.

                1. 2

                  the standard line is that there’s no particularly good reason to

                  Without being rude, this is false. The problems with the GIL are well-known, and they’re not like you say. In fact there’s yet another attempt to get rid of the GIL by python-dev@ as of the last PyCon (GILectomy).

                  It’s not possible to get rid of the GIL, while

                  1. Not breaking existing C extensions. The GIL is exposed as part of the Python-C API; C extensions may rely on global state protected by the GIL, etc.
                  2. Not hurting single-threaded performance
                  3. Improving multithreaded performance

                  If you relax one of those assumptions, you can get rid of the GIL, but then there would be no point.

                  The original post is correct in the sense that an architectural decision that was made at the beginning of Python’s life that is hard to change. There have been multiple, serious attempts to get rid of the GIL over the last 25 years.