No Andy Hunt, I will not buy your book!!!

I like to think that I am pretty open minded. I like to try new things. In my current job I often have to wade through Python. I have had minimal contact with Ruby. If given the chance I would most definitely try it. What I refuse to do is take Andy Hunt seriously after hearing him talk about language and api design.

Andy somehow equates a Duke University study that shows exposure to the apple logo makes people more creative, to language, and api design needing to be Aesthetic pleasing:

"In another study researchers at Duke university noticed that brief exposure to the apple logo made subjects more creative. It's a stereotypical image that is associated with creativity and inventiveness; And your brain sort of sees that and plays along. In my mind this is a huge scientific discovery. this means that issues user interface design and language design and api design aren't just about efficiency or standard naming conventions. It's about aesthetics is it well designed is it pleasing to the eye is it fun. These aspects aren't just niceties or pleasantries they have a direct bearing on cognitive efficiency. In other words a programming language that makes you happy will measurably and scientifically make you a better programmer"

So he is trying to tell me that because a few people got inspired when they touched a macintosh poster, I am to believe that I will be a better programmer if my programming language looks nicer? Beauty is far too objective to be a deciding factor in whether or not I am good at using my tools. If making a torque wrench in the shape of a turd made it twice as effective, then I am sure all mechanics would prefer a turd shaped torque wrench over any other ( but would it smell as sweet?)

He then starts blaming braces for programmatic inefficiency:

"Remember we are limited to about 160 bits of information per second input speed. So you don't want to waste a lot of input bandwidth with syntactic noise such as semi-colons and curly braces and spurious parenthesis. Ruby of course honors that and keeps the syntax relatively noise free. Many other modern languages don't show us that same courtesy"

Yes, semi-colons, curly braces, and parenthesis have an innate ability to grab your attention. This is a feature not a bug. There are plenty of editors around that will color code, and show matching braces and parenthesis, so what's the problem? Besides, who cares about writing code faster? I would rather write code better.

The reason I prefer Perl is that TIMTOWTDI. Perl gives you the freedom and power to write the most useful ugly and unmaintainable code imaginable.
However, with great responsibility one can also chose to write in Perl with a purpose; constantly checking to see the reasoning behind your code. Or as Damian Conway puts it in Perl Best Practices: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."

Parrot, Rakudo and Perl 6

This week I downloaded parrot and subsequently Perl 6. For those of you that don't know. Parrot is a runtime environment for dynamic languages. You can use parrot to write a compiler. Parrot was dreamed up by the same people that were writing Perl 6. Rakudo, which is the perl6 compiler written in Parrot is interesting but not yet production ready.

I tried using rakudo to work through a Perl 6 tutorial that I found but when I tried to get it to accept standard input rakudo puked up a stack trace. So either I am doing something wrong, rakudo isn't ready, or the tutorial is crap.

Anyway, I am excited about Perl 6. Start here to check it out. Perl 6 was conceived by specification. That means that that there can be multiple implementations of Perl 6. As long as it passes a spec test, a Perl 6 compiler will run code correctly. In fact, there is another implementation of Perl 6 started by Audrey Tang.

Perl 6 is about 8 years in the making. It looks like it is in its final development stages. The search for documentation is on . . .