User: Password:
Subscribe / Log in / New account

GNOME debates Javascript bindings

GNOME debates Javascript bindings

Posted May 21, 2009 8:16 UTC (Thu) by MisterIO (guest, #36192)
Parent article: GNOME debates Javascript bindings

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

(Log in to post comments)

Why not Python?

Posted May 21, 2009 8:38 UTC (Thu) by smurf (subscriber, #17840) [Link]

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

Nobody notices?

Posted May 21, 2009 10:39 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

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.

Nobody notices?

Posted May 21, 2009 13:43 UTC (Thu) by zooko (guest, #2589) [Link]

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.

Nobody notices?

Posted May 21, 2009 18:03 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

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.

Nobody notices?

Posted Jun 3, 2009 10:29 UTC (Wed) by renox (subscriber, #23785) [Link]

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

Posted May 28, 2009 16:29 UTC (Thu) by sciurus (subscriber, #58832) [Link]

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.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds