| |||||||||||||
Nobody notices?Nobody notices?Posted May 21, 2009 13:43 UTC (Thu) by zooko (subscriber, #2589)In reply to: Nobody notices? by tialaramex Parent article: GNOME debates Javascript bindings
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.
(Log in to post comments)
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).
|
|||||||||||||