GNOME To Use JavaScript For New User Programs

[liam]

Phoronix: GNOME To Use JavaScript For New User Programs

At the GNOME Developer Experience Hackfest last week in Brussels, GNOME developers decided to recommend JavaScript as the new language for writing GNOME applications...

http://www.phoronix.com/vr.php?view=MTI5MjU

Hopefully this means they're getting away from python. JS is getting pretty damned fast and should only get faster with the next ecmascript. I know pypy is a helluva lot faster than cpy but I think it is still a good bit slower.
Global scoping is still an issue, but using the let statement and closures helps somewhat.

[elanthis]

This does however not change the fact that Youtube use Python, which is a language with dynamic typing.
I am not going to argue whether a web application is more or less trivial than MySQL.
I just think we can all agree that Youtube does not really count as a "trivial" application.

Web "applications" are made of many little request-response handlers. They are entirely different beasts than large, monolithic, long-running desktop app processes.

Not defending the original silly claims about dynamic languages being slow. That's a very different (tired) issue.

I will note that every platform that pushes HTML/JS extensively has had to back down. JS is a terrible applications language (not for speed reasons). Great for little toys, or the Web where you have no real alternatives and have to deal with JS even for large apps like Google docs.

[liam]

I'm sure many due, but I write in Javascript every day, and I can honestly say it's one of the worse, most bug-prone languages i've ever used. Granted, the version Gnome desktop is running supports better features than what you can get away with in today's browsers. Still, prototype-inheritance + dynamic objects = developer hell for large applications. They should be pushing Vala instead, or hell, use Google's Dart with Dart VM if they really want to keep around weak-typing.. at least that has sane security, decent performance, and OOP design.

IMO, Gnome should rewrite all the Javascript code they have controlling Gnome into Vala code (like Elementary did [i believe]). The only argument for Javascript here is that it's "good for extensions".. which isn't really the case, seeing as how almost every extension breaks from one version of Shell to the next. I like Gnome, but Elementary's developers seem a bit more sane (no offense).

If you are writing JS everyday I assume you are using something like coffeescript (which, BTW, is a really good idea to learn if you want to be up on the next version of ecmascript since it is taking many ideas from coffeescript). If you are, then what remaining problems make it so bug prone?
I don't know what you mean by "version" since Gnome just uses the spidermonkey interpreter from firefox so it should be not better, and frankly somewhat worse (since I believe they don't update their engine as often as FF), than "today's browsers".
BTW, you do realize that the problem with extensions breaking has nothing to do with the language and is solely due the devs not providing a robust and stable extension interface?

[bridgman]

The Qt Licensing deal stop you. Because Qt is under a dual-license they can create exceptions. One of the exceptions is if you use static-linking, you have to use a commercial license.

AFAIK this is not a QT-created exception, just a generally accepted side-effect of the LGPL license.

Going from memory here but I believe LGPL requires that someone receiving a program which uses the LGPL library be able to update the library independently of the program, which in turn requires either dynamic linking or inclusion of linkable object files for the program (allowing the user to re-link with a new library version) if static linking is used.

Using dynamic linking is generally easier than including linkable object files.

[kigurai]

Web "applications" are made of many little request-response handlers. They are entirely different beasts than large, monolithic, long-running desktop app processes.

Using a framework, you can pretty easily construct a trivial web application. That is true.
The framework itself however is not trivial.
Looking at Django, to take a popular example, you get not only request-handling but session handling, a template system, an authorization framework, a database ORM, internationalization and a debug web server (just off the top of my head).
If that counts as trivial then I think you should put all GNOME and KDE applications, regardless of language if implementation, in that group as well.

But if web applications are in some way inherently trivial (which I disagree with), you just have to look around and find the numerous other examples of Python and other dynamic languages being used for non-trivial tasks.
There is a list here http://en.wikipedia.org/wiki/List_of_Python_software

On the top of my head of applications I use regularly: Mercurial, Deluge, Spyder, SciPy/NumPy/matplotlib. Neither which I'd characterize as trivial.
If you or anyone else does, then you seriously need to define what a trivial application is.

Not defending the original silly claims about dynamic languages being slow. That's a very different (tired) issue.

So, add the silly claim that languages with dynamic typing are not usable for non-trivial systems as well.
Sure, static typing helps you catch some errors, but considering that a Python-program is usually a lot fewer LOCs than an equivalent C++-program, I'd say that the number of bugs is not going to be worse in Python.

[Delgarde]

I think that is not really a good example. GTK and Qt have a large overlap in functionality while GTK and Clutter complement each other. I don't think you want to build a GNOME application in Clutter alone.
See project reference here: http://blogs.gnome.org/clutter/about/

I think he's confusing Clutter itself with St, the Clutter-based widget library used by Shell. Clutter and Gtk are certainly complementary - a number of the Gnome games use the former for the game canvas - but St and Gtk aren't.

That said, St isn't really intended for building applications - it's a much simpler toolkit designed for the Shell itself. It's not a substitute for Gtk.