LWN: Comments on "GNOME debates Javascript bindings"

Nobody notices?

renox — Wed, 03 Jun 2009 10:29:05 +0000

>>A good GUI application (in any language) should use event-based concurrency<<

I disagree: the most responsive applications/OS, I've ever used was BeOS which used threads (and this was on a monoCPU).
And multicore CPU are now commons, so you'll loose performance with events.

GNOME debates Javascript bindings

sciurus — Thu, 28 May 2009 16:29:42 +0000

Based on this this and this, it sounds like the direction GNOME is heading is "C/C++ core plus embeddable language". Python isn't a good embeddable language from their perspective because it comes with its own expansive set of libraries, whereas they want the embedded language to use GNOME libraries through GObject Introspection. Javascript, Guile, Lua, and Tcl are all mentioned as potentially good embeddable languages.

GNOME debates Javascript bindings

tdz — Thu, 28 May 2009 09:20:34 +0000

I write a little graphics renderer as a hobbyist project. Its design is quite similar to Emacs. It is build around a core binary and use JavaScript for scripting.

The fact that there are several independent implementations of JavaScript was one of the reasons I choose it in the first place. So that if one implementation is ever becoming obsolete, I could switch easily; or at least without rewriting all scripts in another language.

As someone else wrote, SpiderMonkey's API is really no beauty. But it is well documented and a lot of people know JavaScript. So getting JS-related knowledge from experienced programmers isn't that hard.

Lua failed in these regards. When I was looking for scripting language, it was on the table but I dismissed it because of the small documentation (compared to JS) and the missing "backup implementation".

Best regards, Thomas

GNOME debates Javascript bindings

nix — Thu, 28 May 2009 06:49:24 +0000

Wishful thinking? :)

GNOME debates Javascript bindings

deunan_knute — Thu, 28 May 2009 03:05:08 +0000

> Also, to be honest, these days Lua probably has *more* people who know how
> to use it (to some degree) than JavaScript, thanks to Lua's use in major
> game platforms like WoW.

I won't argue Lua's inherent fitness for embedding, but what makes you think Lua has a greater userbase than JavaScript? A quick search for 'javascript programming' at amazon yields 2498 book results, whereas a search for 'lua programming' returns 138. the same search terms on google return 36,200,000 for javascript, 266,000 for lua.

GNOME debates Javascript bindings

kov — Mon, 25 May 2009 17:29:20 +0000

V8 is comparable to SquirrelFish - the execution engine, or VM. The execution engine is just a part of
the JavaScript infrastructure provided by JSC, but I indeed do not know to which extent the Chrome
guys replaced that infrastructure. But even if we consider Safari/MacOSX only, my point stands.

GNOME debates Javascript bindings

samlh — Mon, 25 May 2009 13:57:06 +0000

I thought Chrome used V8?

GNOME debates Javascript bindings

kov — Sun, 24 May 2009 03:41:46 +0000

Saying that JavaScriptCore is 'untried' sounds weird to me. It's been a public "system framework" on Mac OSX for a very long time now, and it's what both Epiphany/Webkit, Safari and even Chrome use under the hood, so I wouldn't say it's untried.

GNOME debates Javascript bindings

gerv — Thu, 21 May 2009 20:27:09 +0000

More and more parts are being rewritten in JavaScript, for all the obvious reasons (high-level language, no buffer issues etc.) I don't have the time to run a full code line counter, but:

gerv@otter:mozilla$ find . -name "*.cpp" -exec cat {} \; | wc -l
2211031
gerv@otter:mozilla$ find . -name "*.js" -exec cat {} \; | wc -l
1065187
gerv@otter:mozilla$

Seems to be about 65:35 at the moment. Hardly just "the glue".

Lua and Javascript alternative: Squirrel

atai — Thu, 21 May 2009 19:31:55 +0000

People may also be interested in Squirrel, a script language currently used in games and other applications with internals like Lua (especially the embedding API) and a C/C++ like syntax which would make people familiar with C, C++ and Java (and Javascript) feel at home.

http://www.squirrel-lang.org/

GNOME debates Javascript bindings

tialaramex — Thu, 21 May 2009 18:47:32 +0000

Come on gerv, I've hacked on Mozilla. Am I going to find that Mozilla's AES implementation is now in Javascript? No. The image renderer? No. There are all these big complex systems in C++, and then there's glue holding the thing together, and that glue's where Javascript is (mostly) found.

I recall (I am an old codger) fairly well the work to implement PAC in Mozilla, and basically 95% of the heavy lifting was C++ hacking, and then it needed some glue to connect it up and handle prefs and so on, and that was in Javascript.

And to get to the point where Javascript plays this role, Mozilla had to create XPCOM. So Javascript without XPCOM would be even less suited to writing a whole application.

Nobody notices?

tialaramex — Thu, 21 May 2009 18:03:52 +0000

Yes, Turing equivalency means it's nearly always possible for a sufficiently skilled programmer to find a way to do something with language X that another can do in language Y. But if the language (+ runtime, library etc.) makes it difficult enough, no-one will.

I actually think that Red Hat's decision to have this code in a higher level language was a good idea, and if I have something against Python, it's no more than I do against Ruby, Perl, or a dozen other choices. Familiarity breeds contempt, I think they say. If there'd been a thread about how all of GNOME should be written in C this grumpy old man would probably have criticised that viewpoint too.

As to event-based concurrency. It's a nice idea (though you lose the potential perf gain on modern hardware from simultaneous multiple threads of execution) but it's not always sufficient from a practical point of view. Suppose you do a name resolution (DNS lookup). If you're lucky your language / runtime/ stock library contains an asynchronous resolve function, and you need merely design the program around not being able to do synchronous lookups. If you're not lucky, you have to write this yourself (good luck, it's really nasty). So maybe you decide not to bother, and then the poor user whose DNS server is down wonders why your program freezes.

GNOME debates Javascript bindings

gerv — Thu, 21 May 2009 15:31:10 +0000

I don't think (I am not involved in the larger debate, I just read the article) anyone is proposing to use Javascript to _write_ large applications.

<cough> Firefox <cough> (or large chunks of it, anyway)

why should they pick a javascript engine?

jdub — Thu, 21 May 2009 15:29:45 +0000

Gah, that was meant to be a reply to the comment above yours, and say "stderr" not "stdout". Thanks. :-)

why should they pick a javascript engine?

jdub — Thu, 21 May 2009 15:28:24 +0000

The article -- in fact, almost the entire point of the article -- describes why the situation is not that simple... These engines were designed to be used within the context of a web browser (embedded, single-purpose), so as Javascript becomes more relevant outside the web context, the language and runtimes will grow additional features -- thus the features provided by Mozilla's implementation which are attractive to the GNOME Shell hackers.

Here's an illustrative challenge for you: How do you write to stdout in Javascript, and if you can answer that, is your method a feature of the langauge or the runtime?

why should they pick a javascript engine?

nybble41 — Thu, 21 May 2009 14:54:10 +0000

The JavaScript code itself should be portable between the two engines, or any other they care to use. The problem is on the other end, in the interface between the JS engine and the non-JS Gnome APIs. If they don't settle on a particular implementation then they'll be forced to duplicate at least a portion of the native interface for each supported engine.

Nobody notices?

zooko — Thu, 21 May 2009 13:43:48 +0000

Those sound like decisions made by the author of the tool -- to open the output file for writing early instead of late (without backups), and to be picky instead of lenient about the content of the configuration files. If the programming language has any effect on those issues at all, it is probably that Python makes it easier for the author to do it either way, where C makes it harder to be as precise about the contents of the configuration file.

As to threading issues you mention, I take your word for it that you've observed such, but I haven't observed such problems in Python applications, although I have in C and Java applications on my Linux box. A good GUI application (in any language) should use event-based concurrency and incur lower risk of either of those two problems. Again, this probably has a lot more to do with the knowledge and choices of the authors than with the programming language.

GNOME debates Javascript bindings

djerius — Thu, 21 May 2009 13:40:50 +0000

Programming in Lua
Roberto Ierusalimschy

ISBN 85-903798-2-5

why should they pick a javascript engine?

dlang — Thu, 21 May 2009 12:39:13 +0000

they should be able to use either engine (or the google V8 javascript engine), just like you can use different C compilers to compile good, portable C applications.

GNOME debates Javascript bindings

knobunc — Thu, 21 May 2009 12:19:54 +0000

What is the name of the book? It sounds interesting. Thanks.

GNOME debates Javascript bindings

tialaramex — Thu, 21 May 2009 10:51:49 +0000

I like Javascript too, though I rarely use it in anger these days.

I don't think (I am not involved in the larger debate, I just read the article) anyone is proposing to use Javascript to _write_ large applications. Adding a few hundred lines of JS here and a few hundred there as glue is quite different from implementing say Evolution or some other large app in JS.

Javascript is well suited as glue, and I don't think any amount of work on it will make it into an excellent application development language. If that's what GNOME is really proposing, well, it won't be the first time they (or KDE) have had a crazy idea I didn't agree with. Lua would also be a good candidate for writing glue, but I don't think it's much better than JS. Javascript has a major benefit of being very widely understood, this has the effect that even if it's technically not the ideal choice it may be a pragmatic choice because you don't have the option of waiting for a crop of expert Lua programmers to volunteer to work on GNOME.

GNOME debates Javascript bindings

nix — Thu, 21 May 2009 10:40:08 +0000

Seconded. Also, to be honest, these days Lua probably has *more* people who know how to use it (to some degree) than JavaScript, thanks to Lua's use in major game platforms like WoW. And it's a pretty elegant language as these things go, like Scheme done right and usable by humans who don't think in parentheses.

lua's also got an excellently designed embedding API and FFI from Lua to the embedding host that makes JSC look baroque and SpiderMonkey look horrendous: in fact it's the first embedding API I've seen in years that I'd call pleasant to use. It was designed for embedding, and it shows.

Its only real problem is that some of its more recent features (e.g. modules) are only really documented in a dead-tree book (there's a publically-viewable reference manual, and a user guide for the previous version of lua, but a lot of Lua's power lies in nifty ways of using things, and *that* is only in the dead-tree book so far). Even here it beats JS, though, as all you have with JS is the standard, which is appallingly unreadable even by standards' standards, while the publically-available docs for lua are very well-written (as is the dead-tree book: recommended).

Nobody notices?

tialaramex — Thu, 21 May 2009 10:39:04 +0000

For a long time it was easy to spot Python GUI programs. They were the ones either uselessly spinning (because Python's signal implementation span when multi-threaded) or else frozen (because to avoid this spinning someone decided not to multi-thread the code and thus the GUI stopped updating)

In theory this is fixed in a new enough Python. If you have a new enough Python, and if your Python programs were updated to take advantage. So mostly, not yet.

It was also way too easy to spot Python programs written at Red Hat to replace older C admin tools. The C admin tool might react to unexpected contents of a configuration file by segfaulting, but more likely it would ignore the unexpected element altogether. Ignoring unexpected things in C is really easy, it's often the default outcome. In Python you'd get a stacktrace, but of course only /after/ the program had truncated your file ready to write its output. The practical result was that the tools were now much less reliable, such tools ate my NTP configuration, printer settings and other useful stuff. Nice.

Why not Python?

smurf — Thu, 21 May 2009 08:38:12 +0000

Presumably because that would be too easy, given that there already exist sensible Python bindings, and several Gnome programs which happen to be written in it (except that nobody notices. Which is good).

GNOME debates Javascript bindings

MisterIO — Thu, 21 May 2009 08:16:11 +0000

If they wanted to use an high level scripting language, why not choose Python?

why should they pick a javascript engine?

jdub — Thu, 21 May 2009 07:13:45 +0000

Your questions don't make sense... GNOME needs to choose a Javascript engine because they're not developing their own. The choice is between the two fastest (both in terms of performance and development progress) Open Source engines available: Mozilla's (which Gjs uses) and WebKit's (which Seed uses).

The bits that GNOME developers are creating are the bindings between those engines and the GNOME platform, so you can actually create GNOME software with Javascript.

why should they pick a javascript engine?

dlang — Thu, 21 May 2009 04:21:34 +0000

and especially, why should they be developing one themselves?

with all the browsers having speed wars about their next generation javascript engine, one (or more) of those would be better than something developed for GNOME.

and if javascript is a defined language, it should not matter (as anything other than short-term bugs for missing features) WHICH engine is in use. the code should be portable enough to run across all of them.

the LAST thing that should happen is to end up with app#1 written in javscript for engine A, app#2 written in javascrpt for engine B, etc.

GNOME debates Javascript bindings

elanthis — Thu, 21 May 2009 03:31:27 +0000

OK, I like JavaScript, in concept. It has some warts (what language doesn't) but they're not deal breakers for most users. It is relatively easy to understand for anything with any kind of programming background, and it's not a horrific choice for a first language, either. It's well known. It's great for what it was designed for... which is not desktop apps.

Why in $DEITY's name are they not using something like Lua, which has almost an identical feature set without the crazy 50 different implementations and non-standardized extensions on top of non-standardized bugs on top of an largely unimplemented standard?

I like JavaScript, but until a real standard (and implementations) come out that include the kinds of features necessary for large application development (e.g., the mentioned let keyword, among a few others), using it for desktop apps makes about as much sense as integrating Python 1.x as the scripting language of choice. Sure, it works, but it's crufty and the world has more to offer these days.