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

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.

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

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).

Granted that isn’t available when using the language outside of a web browser, but then that conflicts with trying to attract web developers.

@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