Floating Away (into a Language Fray)

Spent 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 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 code with better structure than most of the framework-oriented 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 . 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 a little more, one of the reasons there is a rising demand for 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 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 Beans.