4

Applet Languages

At the GNOME Summit, Owen suggested the following:

When trying to decide on a language for applets/widgets, just about everyone will suggest their own favorite language along with reasons why that language is appropriate. However, one thing that needs to be considered is choosing nobody’s favorite language- Javascript.

Owen, I see your point but have to disagree. One of the key purposes of an applet/widget framework should be to allow new and inexperienced developers to easily write their first GNOME application with the smallest learning curve possible. Because of all the people familiar with it, Javascript is an appropriate language, but so are Python and C#.

Before I focus on the advantages of using multiple languages for applet development, I’d like to review a few of the key philosophies that drive GNOME Development:

  1. Software should be easy and simple to use for new users.
  2. Software shouldn’t have a large learning curve.
  3. Different pieces of software for the same platform should use consistent interface elements and share design decisions. Users shouldn’t need to learn new skills in order to use new applications.

When these same philosophies are applied to development and placed in a GNOME specific context their implications are:

  1. There should be GNOME frameworks that allow developers to easily write applications, even if they have no prior experience with GNOME.
  2. Developers shouldn’t have to learn many new skills in order to develop their first GNOME application. When possible, they should be able to use their existing knowledge from other platforms.
  3. Different pieces of software for the same platform should use the same technologies. A developer working on one GNOME application should be able to quickly jump in and contribute to a fellow GNOME developer’s application without needing to learn anything new.

The implications of 2 and 3 are problematic and contradictory. If we allow developers to jump into GNOME Development using all of their existing skills (including intimate knowledge of languages and toolkits), how can we still create a united platform that uses one set of standard and familiar GNOME technologies? More importantly, how can we create a platform with an interface that’s consistent for users?

The solution that’s been followed for the past 11 years is a simple one- Wherever giving developers extra freedom will not hurt the user experience, freedom should be given. In other words, development in multiple languages is fine, but using multiple toolkits is not fine.

This strategy has worked amazingly well. There are a wealth of applications that have been written in C, C++, Python, Mono, and a few other languages. If GNOME had begun with an ironset rule that applications may only be developed in C, we would still be in the dark ages of desktop development with all development done by a few hardcore C junkies. Heck, even if applications were allowed to be written in one “high level” language like Perl- or even the fledgling Python of 1997, for that matter- we would still never be where we are today. All of the goodness that has come out of Mono- and most likely everything that uses pygtk, as well- would have been lost in the curves and twists of a what-if history of GNOME.

The reason GNOME is so diverse and powerful today is because of it’s flexibility with regard to languages and even technologies. We’ve always embraced the new and hot, most recently with Clutter. We’ve also always allowed developers to use as many of their existing coding skills as possible. We’ve taken in developers from just about everywhere- Windows, Mac OS X, the Web, etc- and they‘re the reason that GNOME rocks so much today.

Owen, I’d love to support simplified Javascript applets/widgets, but I can’t imagine doing so without still supporting other types of widgets. There are no statistics regarding how many developers come to GNOME from other platforms, and whether most of them come from web development or desktop development. The one fact is that we do have developers from both ends of the spectrum, and our job is to get as many of them as possible involved with GNOME development. A framework that will alienate half- or even a quarter- of them is not the right answer.

  1. Irakli Gozalishvili says:

    Sound great for me !!!
    I’m working with Mozilla platform for some years already and I would say it’s wrong to say that Javascript is nobody’s favorite language. It’s really powerful and very dynamic language but there’s really few people know it. Actually it’s more and more projects are coming who chooses js as a language

  2. Owen Taylor says:

    Hey Natan,

    I don’t entirely disagree with you. Having many language bindings for the GTK+ stack has been a traditional strength of GNOME over the years. But I think there’s an inherent difference between an application – where most of the code is doing whatever the application does – and coding part of the GNOME core desktop. For the application, you really care about what code you have already, what libraries are available, and so forth. But for part of the GNOME core desktop, having a big language standard library is a disadvantage rather than an advantage. And there really has not been a lot of progress getting things written in non-C into the GNOME core over years, for reasons political and technical.

    Specifically for applets and the more general concept of “shell plugins” – there are additional reasons to favor a standardization on a single language. First, an “anything goes” approach implies out-of-process. And out-of-process is inherently harder than in-process. Second, multiple languages really hurts forming a cohesive community where people are sharing code and copying what other people are doing. I think it’s very easy to overestimate how attached people are to a particular language. A programming language is a programming language, and even more so if we can offer something familiar like Javascript as the standard choice and provide skeletons and code to copy. One of the biggest barriers to entry is if we say “first, choose a programming language. Whatever you choose, 70% of the community will dislike your choice.”

  3. Natan Yellin says:

    Owen,
    The main advantage of language flexibility is not that developers can harness existing language libraries- that’s an argument that would be appropriate if I were to advocate for one specific language in place of Javascript. However, I don’t believe that we should pick any specific language at all.

    I do agree with you that it would be nice if more parts of the GNOME shell were written in (or used plugins written in) higher level languages. Such a move to higher level languages would allow hobbyist developers to get involved in the desktop shell itself, without needing to spend time learning C or any other new language- Javascript included. Hobbyist developers and other current “outsiders” can help bring a whole new level of innovation to the desktop interface if we simply lower the entry bar and open up new areas where they can get involved.

    To rephrase your last statement, we don’t want to tell developers “Welcome to the GNOME Shell- you need to use Javascript even though there’s a 70% chance that you wont like it.” As you said, it easy to overestimate how attached people are to a given language, and that applies especially to existing developers. They can learn to deal with a variety of applets being written in different languages, but new developers- who may only know one language- can’t deal with being forced to learn a totally new language like Javascript.

    “Anything goes” does imply out of process applets and/or shell plugins, and that’s both an advantage and a disadvantage. From my own experience with Universal Applets, I can list a few of the difficulties offhand, but I can also list the solutions.

    On the flip side, out of process applets don’t just allow flexibility, but they also give us an easy alternative to running everything in one huge and shaky monolithic process. I know I don’t want my entire desktop shell freezing if one applet goes down, and out of process applets provides the easiest way of avoiding that.

    If, as a solution to the above problem, you already intend to sandbox applets and/or run them in some form of a virtual machine then why not also add on support for other high level languages? Depending on the implementation details, a large amount of the necessary code will have already been written.

    That said, specifically regarding HTML + CSS + JS applets (which is what “Dashboard-like widgets” implies), I can imagine small and specific parts of the desktop shell being plugged with webpage-like content, but wherever you need full power that’s not the solution. If we want to create clutter like interfaces, clutter is the way to go- not DOM.

  4. Compizuser01 says:

    How is the development going?