Hi Sublime folks – I’m moderately concerned about the future of Sublime Text given how old most packages in Package Control are. It’s rare to come across packages that have been updated within the last couple of years. It’s clear that Visual Studio Code and Atom have gained a lot of ground, especially for web developers. There doesn’t seem to be as much energy going into ST package development.
I prefer Sublime for its speed and built-in features, but there’s currently no Sublime counterpart to the excellent Golang, Docker, Python, F#, and REST extensions available for VS Code (the first three of those come from Microsoft directly). One idea I’ve had for sparking a lot more energy toward Sublime package development is a polyglot package API. Meaning package developers could write packages in any of several programming languages, not just Python.
How feasible is this? I realize that Sublime probably has a small team of developers, and this is a big ask, but I at least want to put it out there. A smart strategy might be to identify popular languages that are not served by any existing extension or package APIs, particularly those for text editors. I think both Atom and VS Code extensions are written in JavaScript only (maybe CoffeeScript too for Atom). Ruby strikes me as one language with lots of enthusiastic developers who currently have no outlet for their skills re: text editors. Also Lua. Also Go. And C#, Java, Kotlin, Swift, Visual Basic, etc.
A different strategy would be to support the same language those other editors do: JavaScript, preferably while still supporting Python. Of course, you could execute a master stroke and implement both strategies, adding JS, Ruby, and Go support, for example.
One thing to keep in mind is that going for the most popular languages might not get you the most package development activity. After all, Python is plenty popular and yet there isn’t a lot of ST package development lately. A language with a smaller number of users, but who are extremely passionate, might produce the best results. For example, it’s possible that Haskell support would spark more activity than Ruby or C#. I’m not sure – in this scenario maybe Haskell developers would be so excited and grateful for the support that they’d build and maintain tons of packages. Or not.
You could build an API that relies on and executes a common intermediate representation (IR), but then you’d have to build compilers for the different languages to compile to that IR. Alternatively, there just so happens to be an emerging IR: WebAssembly (Wasm). The are many, many different toolchains in the works for different languages to compile to Wasm, so it might be worth checking out.
There are at least a couple of other ways to architect a polyglot package API, including having parallel, nearly equivalent APIs for different languages, using off-the-shelf interpreters or compilers, like you do for Python. (Also, maybe now’s a good time to upgrade the Python interpreter in Sublime Text to Python 3.8.x.) You could also limit support to a strict subset of a language, making it easier to implement.
Anyway, just some thoughts I had today.