Sublime Blog

Choosing an Extension Language

If you’re building an application, then your users will get much more out of it if you given them a plugin API. For Sublime Text, I settled on Python as the extension language. In fact, I think you’d be mad to choose anything else.

For a desktop application looking for an extension language, the two most important things to optimize for are the likelihood that your users will create plugins, and the chance they’ll actually enjoy it. This gives a few guidelines when choosing an extension language:

  • Adoption matters. There should be a reasonable chance that users already know the language, or if they don’t, learning it is at least a worthy investment.
  • Unicode matters. How much depends on the application, but if users can’t even write a script that opens a file in their home directory because of Unicode issues, you won’t be winning any friends.
  • Libraries matter. File access, date / time, socket programming, subprocesses, etc. If you’re writing a general purpose desktop application, then most plugins your users will want to write will involve using APIs other that what you’ve explicitly exposed.
  • Ease matters. Any language requiring a separate compilation step isn’t a contender.

There are also several criteria that don’t matter for a typical desktop application extension language:

  • If you’re going to depend on the scripting language having fast runtime performance, then Python may well not be for you: Lua or Scheme are both typically much faster, and have a lower memory footprint.
  • If you’re depending on the language for security, such as a web browser running untrusted code, or a server running code submitted by users, then you have an entirely different set of considerations.
  • If the application is only going to be used in house, then it doesn’t matter terribly much what percentage of users are familiar with the language, because they’re going to be forced to use it anyway.

At first glance, it appears that desktop application developers are spoiled for choice of extension languages, but caveat programmer:

Scheme, despite having reasonable libraries and Unicode support, is far from mainstream. Using Scheme or another Lisp dialect as an extension language is an effective way to make sure you won’t have any extensions. Early versions of Sublime Text used Scheme as an extension language, but it was dropped for this reason. Just because you like a language, doesn’t mean your users will.

Lua is another candidate, which has a lot of uptake in games. It has a very small code footprint, and excellent runtime speed. However, its paucity of libraries, weak Unicode support, and small-medium user base make it hard to justify as an extension language for desktop applications.

What about JavaScript? It’s an underrated, elegant language, with a huge number of people acquainted with its syntax. Its weakness is that it’s not used as a general purpose language, so there’s no selection of libraries your users will be able to build on. No libraries and no built-in standard APIs (file system access, I’m looking at you) rule JavaScript out.

We come to Python and Ruby. Which language is better really isn’t relevant, both are fine languages with pleasant syntax and semantics. In terms of ecosystems, both are popular and have a good selection of libraries. Python, however, is the bigger gorilla, with a larger user base and more libraries.

Python, however, has a secret weapon: Python has ctypes, and Ruby doesn’t (1). ctypes provides an ad-hoc way to call functions in any shared library in the system. This means that the platform’s entire native API is available with no C extensions required. Take, for example, a user who wants to launch another application, then set the input focus back to yours. With Python and ctypes on Windows, it’s only a few lines of code to call GetForegroundWindow and SetForegroundWindow. That’s pretty awesome.

Summary: Your users will be happiest if you choose Python. It’s pretty hard to argue with that.

1. Not strictly true, as pointed out in the comments, Ruby has a similar library called Ruby/DL 2. That’s pretty cool.

Jon Skinner

7 Comments

  1. Ruby has ctypes all right – Ruby/DL2.

    Comment by Tomasz Wegrzanowski — April 13, 2008 @ 3:18 am

  2. “Python has ctypes, and Ruby doesn’t. ctypes provides an ad-hoc way to call functions in any shared library in the system.”

    Maybe I am missing on something or I am simply mistaken, but doesnt Ruby have DL which allows the same that ctypes can do?

    require ‘dl/import’
    require ‘dl/struct’
    dlload “libc.so”
    LIBXAU.strlen(”abc”) # => 3
    libc = DL.dlopen(’libfuse.so’)

    etc. for example. Would be nice if someone could explain what python ctypes does more than that.

    Anyway, I agree that python is slightly ahead of ruby in certain areas such as more users or better overall docu.
    I also agree about this: “Which language is better really isn’t relevant” and I think there should be no barrier between ruby and python users. It would be great to use certain libraries (wrappers) around software in either language. For example, python bindings towards ogre3d are more likely to be up to date than ruby bindings of ogre3d.

    But I would not want to learn and use python just in order to use it with Ogre3d, and I guess for python writers the reverse is true too. Would be nice to use libraries freely, without caring in which language they are implemented.

    Comment by she — April 13, 2008 @ 3:44 am

  3. You missed Tcl in your list. It does most of the stuff Python does, offers some more security features, nicer unicode support and has better embedding in threaded environments.

    Comment by schlenk — April 13, 2008 @ 4:04 am

  4. > Using Scheme or another Lisp dialect as an extension
    > language is an effective way to make sure you won’t
    > have any extensions.
    Not sure if this is true. Think of emacs. It has lots of extensions, all of them in emacs’ own lisp dialect.

    Comment by zealot — April 13, 2008 @ 5:21 am

  5. Related to this, http://www.advogato.org/article/550.html makes an interesting point. When an app gets popular, users will prefer to script it in their own favourite language, and it is not that hard to plan ahead for this.

    Comment by Marijn — April 13, 2008 @ 7:58 am

  6. Nice to hear you about Scheme (or even Lisp), but I don’t understand why users would hate it.

    Afraid of the parenthesis ? I don’t think so, that’s in fact what has made Lisp so powerful with such a nice macros system where the language can builds itself.

    But I’m also a big fan of Python, so I won’t complain anymore :)

    Comment by kib2 — April 13, 2008 @ 9:21 am

  7. [...] One thing that I was disappointed with was that there was no version control integration with Mercurial, my version control system of choice. That is, until I started reading about the powerful plugin architecture and wrote a tool for it myself! The author of Sublime Text probably realized he can’t fill every single need out of the box, so he provided the tools for end users to improve it themselves through a complete Python environment and plugin API. Using Python as an extension language was a great choice because now users can use the huge amount of Python code publicly available, some users may already know it, and the developer can focus on developing the editor, rather than creating an extension language. The author of the software discusses the reasons he chose Python here. [...]

    Pingback by Who would have thought Sublime Text was so, well, sublime! « Rants, Rambles, and Rhinos — August 8, 2009 @ 12:07 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.