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.
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.
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.
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.
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.
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.
I believe that was about the use of tabs in make, by stuart feldman.
That would explain why I never found a reference.
And fixing it could well have killed it.
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
plttag as well, maybe?It’s not really theory though. It’s more about language design decisions?