Rui CarmoSpent some time getting to grips with PyObjC again and figuring out how to display a rounded floater.
Now that I have figured out the runtime mangling, it's actually pretty straightforward, even considering that I'm not using Xcode yet (just SubEthaEdit and a terminal window). It feels like a bit of a hack (and has redraw issues right now), but should do the job I need it for.
It made a nice counterpoint to Nuno and Pedro arguing about Perl.
Now, I'm not too keen on Perl myself.
In fact, I malign it regularly, mostly in the same way as I malign the pathetic attempts at coffee I'm served when I attend meetings in London. But I use it often enough to know that it's not the ungodly mess a lot of people make it out to be - and in fact, the core language and interpreter have changed so much since its inception that trying to argue (for or against it) based on its origins is downright dumb.
Perl is, however, subject to exactly the same flaws as any other programming language that is put in the hands of untrained (or sloppy, or plain bad) programmers - and statistically, those are the majority, period.
In a nutshell,
It's not the language, it's what you do with it.
I like to think of myself as fully language (and platform) agnostic, so any kind of arguments about a programming language being "better suited" to a specific purpose tend to strike me as either narrow-minded, biased, or both.
This is mostly because I've seen a lot of "professionally developed" code that stank to high heaven throughout my career. And picking up Nuno's point, yes, in business. As in "critical applications for the aforementioned", and in just about any language you care to name, from COBOL to C#. I've seen horrendous atrocities perpetrated in C++ that rival with just about any Junk::Code you can dredge out of CPAN, and I've seen Visual Basic code with better structure than most of the framework-oriented Java some companies are brewing.
The truth is that, no matter what sort of language and toolchain you adopt, putting them into the hands of incompetent programmers is a recipe for disaster. And that is as true for Perl as it is for Java. I've always taken Nuno's skilltracker with a pinch of salt because it will never measure code quality - only demand, and only a subset of that demand at that.
Picking on Java a little more, one of the reasons there is a rising demand for Java programmers these past years is the baroque complexity of current application frameworks and the overall decrease in productivity due to that same complexity. So if you have a big project, you tend to need more hands to compensate for the increased learning curve.
(Yes, this is not a flawless argument, but there are so many things one could argue about here that I'm sticking to the straight and narrow.)
And finally, just as a personal note, I have Perl applications (not just scripts) that have been running for years (one of which happens to be a set of Radiator add-ons) without a single hitch. The extremely well-paid dumbass consultant that replaced one of them with a Java reimplementation managed to crash a Solaris box twice in three weeks. And I mean the OS, not just the JVM.
I still tell his replacement they should have used jelly beans instead of JavaBeans.