I’m working on this awesome new language, let’s just call it Snakethon. Snakethon will build on a decade’s practical language design experience and incorporate some great new ideas about what a programming language really should be.
Some other successful languages, like Java, have these strange concepts called “static types”, and people seem to like them, but traditionally I don’t. However since I want to satisfy all my recent devotees, and attract even more, I’d like to add static types to Snakethon, but I can’t actually call the feature “static types” or provide a concrete implementation without offending others.
Therefore I will introduce the concept of “ASCII art annotations” to Snakethon. “ASCII art annotations” are like static types, except far more general. In fact “ASCII art annotations” are so general that you can do almost everything with them! Or nothing at all.. There is no rigorous consensus on the kinds of ASCII art these annotations support, it’s totally up to your imagination.
During the development of Snakethon the world has progressed a little, and introduced some important new concepts, such as SSL SNI. Since I’d like to encourage adoption of my new language, and the idea that it is a natural extension of my previous language, I’m going to add this feature solely to Snakethon and deny all my existing followers a usable solution desperately needed today. Since eventually they’ll be compelled to use Snakethon through its sheer awesome, this can only be a good idea in the long term.
Back when I first started learning about programming languages, I thought I understood OO, but not really. I sold a lot of people on my ideas about OO, and millions truly believed in me and succeeded by me, but what I taught was never *real* OO, so obviously I need to fix that.
Successful languages like Java have this powerful concept of “interfaces”, but that name is so un-snakeish. Snakethon will instead embody the spirit of interfaces without actually including a feature called such, since again I’d rather not offend any of my previous students by their realizing the core tenets of my language have changed. Therefore Snakethon will include Abstruse Backbone Categories, and all the core collection types will implement them, since that’s what Java does.
Oh, and on the subject of names, everyone has an opinion on those.. well, back in my forgotten days of yonder, I was a strong believer in flat namespaces, but now in my later years I realize, flatness *just doesn’t scale*, and besides, everyone knows taxonomy is the highest form of science.
Therefore in Snakethon I will rename all pre-existing things, in such a way that they appear much neater on the surface, all the while hiding a far more compelling truth: billions upon billions of lines of old code will have to be revisited, and relearned, giving my followers the chance to clear away much bitrot and fix long forgotten bugs.
As for the implementation of those pre-existing things. Well, why let a crusty old library go to waste? Yea, though I walk through the valley of the shadow of renewal I will fear no asyncore, for thou art ancient, and thy obsolescence comfort me.
Well, I have many more ideas for my new language, too much for a single post. Just before I go, I’d like to talk about how we will inevitably transition to it. Since there are so many existing users of Python, I think it’s a great idea to reapply their collective muscle memories and call my interpreter “pythonS”.
In a few short years, many of my followers will no doubt realize the error of the old ways, and begin installing Snakethon without that irksome suffix. So why bother suffixing anything else! Snakethon will also parse PYTHONSTARTUP, PYTHONPATH, and PYTHONHOME environment variables, and look for “.py” files.
If one of my unfortunate followers should encounter a conflict due to this lacking suffix, oh well: all the more reason to rewrite their code in Snakethon! It is after all such a compelling evolution, you’d be crazy to ignore it..
In the meantime while I work on Snakethon, I will endevour to occasionally throw a snapshot or two over the wall. Since incompatible (and most probably self-contradictory) changes will often crop up, I will simply assign new version numbers to each of these snapshots over a period of years. Ensuring compatibility and forward upgradeability amongst these snapshots would be pointless, for soon everyone will be using Snakethon, and we may forget our historical misdeeds for all eternity.
[Comments and snark on a postcard to @edeadlk]