JavaScript in gnome
November 5th, 2009 — pborBeing away from home, bored and yet too tired to do something productive, I skimmed through the gnome-shell proposal mail thread on d-d-l and spotted the inevitable debate on the choice of javascript as a scripting language for the shell.
Personally I am not a big fan of js, quite the contrary, but lately I had to use it extensively (though not in gnome related context) and at the end of the day it is a language as any other. I am not saying it would be the one I would have chosen, but once you use it a bit and get to know its idiosyncrasies, you get what you need done and move on with life. After all any programming language sucks, each one in its own special way and some more than others, but they all suck.
Reading in the aforementioned thread the reasons why js was picked I would have been totally satisfied with valid answers like:
- “It’s my project I and pick whatever language I please”
- “Some of the more talented and experienced gnome hackers chose it. Trust them”
- “It is not C++ or perl, so do not complain”
Beside given that javascript
- has good free implementations
- is widely used (not only in general, but at this point also by various big gnome projects)
I do not have any major problems with it. After all we have clean and consistent code bases written using GObject C conventions, I do not see why we should not be able to tame js as well.
That said, some of the rationales provided for choosing it in the above mentioned d-d-l thread really really trouble me.
js has no platform libraries, so we can use our own
What kind of reason is that? First of all when you embed another scripting language you are not forced in any way to use its standard libarary as well. Second, having a good standard library (or a large set of third party libraries) is a good thing: I thought we were focusing on implementing good applications instead of reimplementing and maintaining a “gwhatever” library for every problem in the world.
using js will attract web developers
That is plainly naive. First of all I have never hacked on something because it was written in a language, at most I have learned a language because something I wanted to hack on was written in it. Second learning the syntax of a language is nothing compared to learning library API, tools, workflows etc and even if I have not used js in gnome yet, I am pretty sure they differ a lot from what web developers are used to. Last but not least, I’d prefer to attract a single good developer than a hundred people not willing to invest an afternoon in learning a language/api/tool.
November 5th, 2009 at 10:55 pm
Perhaps the best contribution to that thread so far, thanks.
November 5th, 2009 at 11:19 pm
Well written.
November 5th, 2009 at 11:21 pm
Possibly you’ve misinterpreted the issue of platform libraries. Think of Java or Mono – they come with huge platform libraries that a typical Java or C# developer will naturally use, fair enough. But those libraries duplicate functionality present in the Gtk+/Gnome platform, making two equivalent but different ways of doing things.
The justification for Javascript, then, is that lacking a substantial platform of it’s own, it makes a very convenient language for working with practically any other platform. Of course that does mean you’re correct on your second point, since JS with Gnome platform is going to be only a passing resemblance to JS with a web platform…
November 5th, 2009 at 11:56 pm
I was curious why python wasn’t chosen, it already has great bindings for practically everything (mono too, when it comes to gnome, although politically loaded, and perhaps less scripty).
November 6th, 2009 at 1:14 am
While I agree with your second point (there’s nothing that web developers can carry over from their webdev skillset), I tend to disagree with your first point.
Languages with an (extensive) standard library would have some impedance mismatch with the platform Gnome provides. Even if you mandate “don’t use anything from the standard libraries”, people would still use what they’re used to, and make assumptions when they shouldn’t. And what they’re used to probably uses different semantics then those of Gnome’s libraries.
Saying “you are not forced in any way to use its standard library as well”, means that we then might as well never deprecate old libraries (bonobo, gnome-vfs, etc), because you’re not forced to use them.
And no the point isn’t to reimplement everything in “gwhatever” libraries, but to use the same code paths as much as possible. I don’t think you’re going to use Python’s standard library from C or Vala or Mono or … so you need the gwhatever libs anyway. However, a language like python then would have several code paths (stdlibs vs gwhatever libs) to do the same things. I don’t want to think about the kind of problems we might run into if you’d mix the different libs together.
November 6th, 2009 at 1:42 am
I have to disagree with your javascript point. I’ve done some hacking on gnome-shell, and javascript made it EXTREMELY accessible for me.
It may be that the arguments put forward weren’t the best, but I have to completely back the decision to do the shell in js. It’s intensely cool. That is all.
November 6th, 2009 at 3:07 am
[…] more from the original source: Club Silencio » JavaScript in gnome SHARETHIS.addEntry({ title: "Club Silencio » JavaScript in gnome", url: […]
November 6th, 2009 at 5:17 am
Regarding, “js has no platform libraries, so we can use our own,” you must see this statement in light of the GObject introspection work. A language that has no bindings gets them all for free when it supports GOI. And, all of them with a consistent, machine-generated style. This isn’t to say that the existing Python or any other bindings are bad, per say. They are quite good. But in particular, Python bindings that were in sync with the every evolving state of Clutter were not available so someone had to write and maintain them. Instead of spending a lot of time doing that, GOI was implemented which took about the same amount of time but benefited everyone, including Vala.
So once GOI was working, yes, they could have selected PyBank but then there would be accusations of conflict with the existing Python bindings. Same for Mono. So, really, that leaves: Vala, Javascript and Lua. JavaScript won for the reasons given by Owen, already.
Bindings always suck. GOI bindings suck less because they are _always_ in sink with the libraries they support.
November 6th, 2009 at 6:51 am
Maybe the reason was that they didn’t want to favor Python or Mono and JS is the most neutral solution.
November 6th, 2009 at 7:51 am
> I thought we were focusing on implementing good
> applications instead of reimplementing and maintaining
> a “gwhatever” library for every problem in the world.
>
I liked the article (in particular the last argument), but I do think this part is wrong.
First of all the fact: We (as in GNOME developers) are not known for our great applications. In fact, GEdit and maybe Epiphany are the only real applications we do ship. The real cool applications are built on top of GNOME, but they’re not developed by “us”.
Now what do we do? I’d say we’re busy building platform libraries. We’re doing that by building our own APIs on top of the lower layers of the stack. Gdk is the GNOME version of Xlib, Webkit-gtk a the GNOME version of Webkit, etc. This means that mixing with another standard library (be it Python or C#) means we’d have to mix the GNOME way and the $language way of doing things. And unless you integrate it really deep into that languageand probably even then), it will feel foreign compared to the default library.
At least, I haven’t seen a lot of love for our language bindings in the last fe years. Or maybe people just don’t code in Python etc anymore.
November 6th, 2009 at 7:54 am
@nona: my point is that glib, gtk etc are a fine platform and I use them every day, but if you want to do something beside showing buttons on the screen and flipping windows you will need to either use other libs or implement your own…
@Josh: maybe it was not clear enough, but I am ok with the choice of js for the shell. Most importantly I think gnome-shell hackers do not need my (or anyone else’s) blessing about that.
@Jason: I know about GOI and I am really happy with it, and yes, I agree that js was a suitable GOI choice
November 6th, 2009 at 8:30 am
Another point: JavaScript in the form web developers use it does have a standard library: the DOM.
Granted that isn’t available when using the language outside of a web browser, but then that conflicts with trying to attract web developers.
November 6th, 2009 at 9:14 am
pbor: About the no-js-platform thing. Think of it like this:
You’re writing an application, its core is written in C using the gtk/gnome library stack. Then you use js as a scripting language to write the “topmost” layers in the application.
Since the scripting language accesses the lower levels of the app is very important that it can access the gnome stack so it can get at the objects etc that the app uses. So, the scripting language clearly needs a GOI binding.
Now, if the scripting language additionally has a large platform of its own this can lead to problems. Such a platform generally overlaps the gnome platform to a large degree, causing us to pull in two copies of the same functionality. But even worse, when you use that platform suddenly the scripting code is isolated from the core of the application, since its using object and types that the non-scripting parts of the application don’t support.
And saying “just don’t use the scripting language platform” is not really realistic. For instance python users are very used to importing python libraries so are likely to pull it in in by “accident”, or by e.g. copying example code. Additionally all the python standard libraries are interconnected, so once you pull in one you often pull in large parts of the stack.
For instance, if you’re doing some date calculations in python its likely that a python developer would import the datetime module (any python example would do so), but in GJs its much more natural to use the GDate type from glib which is much better when you then need to pass the date from the scripting layer to the core of the app (or when the cor gives you a date).
November 6th, 2009 at 9:16 am
@James: Web developers usually don’t use DOM directly anymore. They use AJAX toolkits and frameworks like Dojo, jQuery, Prototype, Ext, etc. They should be able to pick up other frameworks like Clutter and GIO.
November 6th, 2009 at 9:25 am
Litl: http://litl.com/ is GNOME + Javascript, and it looks like a polished product. They did add their own namespace system: http://cananian.livejournal.com/58744.html . I think JavaScript is a good choice in many aspects; it is cross-platform, JIT means that you don’t need to compile while developing the UI, and you could even have JavaScript programs move between different platforms with the same API while maintaining program state; i.e., your mail program / text editor / web browser could switch computers as you do and have the same files open.
November 6th, 2009 at 9:40 am
alex: I surely agree with that, and that’s the reason why I *do* think js was a good choice for the shell (in case it was not clear from the post)
On the other hand take gedit plugins, many of them do text processing, other spawn processes like make etc, all things that are easy to use in python and that to do in js would require significant effort either writing js code or reinventing “g” version of libraries and then accessing them from js.
Another example would be some technical computation apps that e.g. needs to do math, interface with stuff like mpi or a job balancing middleware etc, all things for which creating new “g” libraries would be a useless effort
November 6th, 2009 at 4:06 pm
I would have chosen a scheme dialect, such as guille.
Ok, that was a joke (obviously), but it makes the same sense for me that using JS.
I agree with you with the “you get what you need done and move on with life”, but it’s not true for a FOSS project you hack in your free time.
I would have chosen Python.
November 6th, 2009 at 4:42 pm
One of arguments pro-javascript was that developers from the “web platform” would be attracted. I would actually be interested in how many developers who develop desktop applications for Mac or Windows platforms (and therefore already have experience with desktop applications) know js vs. how many know python vs. how many know C# vs. how many know [some language]. I honestly do not know what would be the outcome, I am just saying that the web developers may not be the best crowd to target.
November 7th, 2009 at 7:09 pm
@pbor: “On the other hand take gedit plugins, many of them do text processing, other spawn processes like make etc, all things that are easy to use in python and that to do in js would require significant effort either writing js code or reinventing “g” version of libraries and then accessing them from js.”
I’d like to poke a little hole in this argument. Doing something like spawning make brings in some portability issues if you want your app to run on Windows too … Python handles things like that pretty poorly (in terms of argument mangling, and character set conversion and arbitrarily missing functionality) so it’s better to use the (existing) g_spawn interface anyway. (Which isn’t much better but at least we can fix it more easily).
I do see your point about the big standard libraries of eg. python being very useful (in fact the only reason I use python out of choice is so I don’t have to start by reinventing some wheels) .. but if a plugin needs to access a type of functionality, presumably the host or a different GNOME application will want that functionality somewhere too