1. 28
  1.  

  2. 6

    I think this also demonstrates the importance of iterating on your language design early – which Swift did in an aggressive way in version 2 and 3, to the point that the 1.0 language looks more like Kotlin or something. I think it also points out that backward compatibility in every aspect can’t be sacred.

    There is an anecdote by the famous K or R, about how one of C’s warts was apparent to them in the mid-seventies, “but by then, the compiler was used on over a dozen sites, and we couldn’t distribute a breaking change”. Instead, such warts spread to millions of sites over the course of decades.

    1. 4

      Yeah, to me the takeaway is that if you’re going to make a “popular” language, you will need an automatic code rewriting tool for the early versions, or else you’ll be stuck with a lot of junk when you do stabilize.

      1. 4

        There is an anecdote by the famous K or R, about how one of C’s warts was apparent to them in the mid-seventies, “but by then, the compiler was used on over a dozen sites, and we couldn’t distribute a breaking change”. Instead, such warts spread to millions of sites over the course of decades.

        I believe that was about the use of tabs in make, by stuart feldman.

        1. 2

          That would explain why I never found a reference.

          1. 1

            And fixing it could well have killed it.

        2. 5

          Excellent and fascinating series! It’s far too seldom you get to see people seriously involved with a large programming language’s design do this sort of retrospective. It’s also somewhat enlightening how many of these are warts for compatibility with C/ObjC API design, for example this one.

          Suggest plt tag as well, maybe?

          1. 1

            It’s not really theory though. It’s more about language design decisions?