IMO

Even though other scripting languages like Python and Ruby (and even Erlang) seem to be getting a lot more press recently, Perl5 is still very much a real workhorse in use all over the place. So the release of Perl 5.10 is very good and welcome news! Congrats to the perl5-porters team!

As mentioned previously, one core fundamental of the ASF which is often misunderstood is the idea of "community over code". Some people take this to mean is that as long as the community is healthy, then it doesn't matter whether the code is good or not. This is, of course, total crud. The phrase does not mean that at all, nor is that the intent of the ASF as well. Instead, the slogan refers to a basic truth that has long been proven, time and time again within the ASF (and elsewhere); That a healthy community creates world-class code. It also implies the necessary corollary: That unhealthy communities do not create sustainable world-class code. The key word is "sustainable". There are, IMO, 2 main variants of unhealthy communities: one with poisonous people, and others which lack diversity and/or collaboration. My good friends Ben and Fitz explain the impacts of Poisonous People in Open Source, so I won't go into a lot of further detail about that. I will say that the impacts of poisonous people depends greatly on whether they are committers on a codebase or whether just nasty skunks on a list. The former is much more dangerous since the end result is driving away other developers within that codebase, as well as preventing other developers from even considering joining ("That project is a zoo... I can't stand that guy..."). So you devolve the project into the 2nd variant: no diversity and/or no real collaboration. The only people left in a project are either those who don't care or are simple "Yes men" to the poisonous person. But I can hear people asking "Well, except for the purist aspects, why is that bad? The guy is a coding machine! The code he's producing is really good! So what is the big deal?" The big deal is that there will come a time, sooner or later (and most of the time it is sooner) that the person burns out, is forced out or changes jobs or whatever that causes him to leave the project. It happens... it happens a lot. And when it does, you are left with a codebase which is basically now left fallow. There are no people left around to "fill in". The codebase suffers, the development community (what is left of it) suffers and the user community suffers. The ASF sees all that as an event to be avoided. The ASF wants to see code survive and even prosper with the changeover of developers, even super studly ones. The ASF wants to see code as a long-term resource, one that continues to attract users and developers. And by creating an environment where merit is rewarded, the expectation is that talented developers will be drawn to those projects that interest them, and will share their talents by helping that project along. And all this with the end result of a much better codebase. The code and the project are more important than the whims of a single developer... A healthy community is the antidote against poison and antagonism. A healthy community fosters and creates good, viable, sustainable code. Ergo: community over code.

So yesterday I arrived in Atlanta for a week (well, almost a week) attending ApacheCon... It was actually a not-bad flight and it was nice, for a change, to fly somewhere and not have to worry about timezone changes. By the time I got in, there was little time for coding at the hackathon, but, as always, sufficient time for socializing... As I type this, I'm sitting at a hackathon table with Henri, Justin, Garrett, Sander and David. The room itself is about 2/3s full... Not bad for 10:40 in the AM!

Today we released version 1.2.0 of Telaen, a very simple but powerful PHP-based webmail system. The reason why I like it is that it requires a very bare-bones PHP installation and is really designed to be as straightforward as possible. If you've read my previous posts about Telaen, you know that it is an offshoot of Uebimiau. We've been contacted by several organizations and projects (including web-host control panels) that will be dropping UM for Telaen.

I've been following for quite some time now the various blogs and articles regarding Erlang. In general, the ones by David Welton I've found the most enjoyable. But one thing I've noticed whenever new languages are discussed are that one tends to bring out of the woodwork language bigots instead of language aficionados. The bigots are those who refuse to see anything good in any language other than "theirs"; that their language is suitable for any and all projects; that it is both general and yet specialized. I much prefer listening to the aficiandos, since they can inform me about the reality of their language. When programming, I tend to worry about the reality of programming languages. As anyone who knows me, or regularly reads this blog knows, I have an affinity for scripting languages. Some mistakenly interpret that as being "anti-Java" when nothing could be further than the truth. The reality is, of course, that Java does not need my help in the least in making a name for itself. The huge marketing forces behind Java have done their job incredibly well, almost too well, since now there is this misconception that Java is the only language that matters, especially in enterprise application development. And that is something that I do hope to clear up. In fact, I'm actually co-presenting with Rod Cope a webinar on this very topic. I think that languages always have a basic design premise behind them; there is one area which they want to shine. The trick is, of course, whether that is a focus of the language or the focus. Consider FORTRAN; its focus was on engineering and mathmatical calculations. That focus was so intense, however, that it made it extremely unsuited for almost any other application. Now compare that with C that was designed from the onset to be a "general purpose" language, but ideally suited to systems programming. In this case, the specialization did not destroy the generality. Which brings us back to Erlang... for me, the measure of success for a language is how well it does what it was designed to do; And Erlang appears to do that very well. The fact that it doesn't do such a good job on things it wasn't really designed for does not strike me as a fault or failure at all. After all, would I complain that I can't use my hammer to saw wood well? Or that my saw sucks at driving nails? Of course, if I had some fancy hammer-saw in my toolbox, and it does an awful job at both sawing and hammering, then the generalization is useless no matter what. Languages, all languages, have warts; As a programmer, I want to know, heck, I need to know, what they are. But only if they are real, honest and true warts. PS: Regarding the webinar mentioned above. A few days ago someone emailed us back saying:

Haha what a joke this is. No one wants to use a scripting language over java for web applications. This is a sad old Unix guy's last attempt to save perl or something. Give me a break.

I kind of liked the "sad old Unix guy" phrase... And I kind of feel sad for those "young Java guys" who feel so threatened... and are so out of touch.