Why not Python?
Posted May 21, 2009 8:38 UTC (Thu) by smurf (subscriber, #17840)
Posted May 21, 2009 10:39 UTC (Thu) by tialaramex (subscriber, #21167)
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.
Posted May 21, 2009 13:43 UTC (Thu) by zooko (guest, #2589)
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.
Posted May 21, 2009 18:03 UTC (Thu) by tialaramex (subscriber, #21167)
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.
Posted Jun 3, 2009 10:29 UTC (Wed) by renox (subscriber, #23785)
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.
Posted May 28, 2009 16:29 UTC (Thu) by sciurus (subscriber, #58832)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds