Friday, May 9, 2008

Parrot, Forgotten Bird

If you need to do client-side programming in web browsers, you have to learn JavaScript. Google's App Engine requires Python (at least for the moment). To benefit from the encyclopedic CPAN, you need to know Perl. Wikipedia relies on PHP, the Rails framework is written in Ruby.

Those, among many others, are dynamic languages: agile and well-suited for rapid development. Such language diversity is a good thing to have.

What is not so great is that you are forced to use different languages in different environments. We already suffer from information overload - and many times we can't afford to ignore the latest fads. The duplication and wasted time involved are simply too much.

Ideally, we should be able to stick to our preferred language in a project. Having to remember the details of several languages, and context-switch between them, is an unwelcome distraction. Also, the choice of a language shouldn't become a restriction later on.

Those are problems that could be solved by Parrot, at least in theory. Parrot is a language agnostic virtual machine, especially designed for dynamic languages. This is in contrast to the Java VM, which can be quite unforgiving to non-static languages, as I am led to believe.

Beautiful plumage

Decoupling the language from the VM makes a lot of sense. Systems can embed the VM and be amazingly flexible, programmers can use their language of choice and have a plethora of libraries available, language designers can focus on the language proper and use the nice compiler tools provided.

Pushing up the daisies

Despite all those advantages, I see almost no mention of Parrot outside its community. I wonder why. The project has been long in coming, but so were other successful Free Software projects. Perhaps people think its goals aren't technically feasible? The NIH syndrome, language chauvinism?

Does it talk?

Parrot and Perl 6 development seem to be gaining steam, and perhaps we shall see alpha releases by the year's end.

What could it bring in the future? Anything scriptable (eg browsers) using the same stable, optimized VM. A further push against proprietary formats (Flash, Silverlight et al). World peace? :-)

Anyway, here's hoping that Parrot becomes hugely successful.

Saturday, May 3, 2008

Halting Taboo

There are limits people are comfortable with. No one would suggest that you could go faster than light, or that ignoring the second law of thermodynamics may be a good idea.

Unfortunately, when it comes to problems a computer can't solve, undecidability can prove to be a misunderstood, if not downright unpopular, limit.

For instance, it is impossible to write a program that receives an arbitrary program as input and determines if it stops in a finite amount of time. This is known as the Halting Problem; in the 1930's Alan Turing proved that it isn't decidable. [1]

If you can't programatically decide if a program stops, automated tests can't prove that it has no bugs. Surprisingly, say it aloud,

You can't prove that a program is correct.

and the conversation can turn sour. "Of course it can be done, you test every state, even if it takes months or years. We are talking about real machines!"

How do you know if a program isn't stuck in an infinite loop? Besides, even if the number of states is finite, it can be huge. Testing every possible state is not feasible.

"Ok, but you're forgetting about formal methods."

Formal methods are applied to individual algorithms, written in pseudo-code. The running program is a different beast. I think it is no coincidence that Knuth once said:

Beware of bugs in the above code; I have only proved it correct, not tried it.

Software is hard. There are lots of descriptions of things going wrong. It is not like catastrophic failures are unheard of. Why the state of denial?


[1] Incidentally, Turing used a diagonalization argument to construct his proof by contradiction. This technique was previously used by Cantor to show that the set of the Reals is uncountable (there are many different infinites). Gödel used it to prove his famous incompleteness theorem.

Tuesday, January 15, 2008

Haskell Impressions, Part I

If religion is the opium of the people and marxism the opium of intellectuals, the search for more expressive languages must be the opium of programmers.

In this regard, Haskell is very alluring. The home page used to describe it as:

Haskell is a general purpose, purely functional programming language featuring static typing, higher order functions, polymorphism, type classes, and monadic effects.

Now a more friendly, less ivory towerish tone has been adopted:

Haskell is an advanced purely functional programming language. The product of more than twenty years of cutting edge research, it allows rapid development of robust, concise, correct software.

If part of the Haskell community has decided to market it to a wider audience, it only stands to gain by creating a positive feedback cycle. If it really is a pragmatic tool, programmers in general will benefit too. One initiative to keep an eye on is the Real World Haskell book, which is currently being written and will be available under a Creative Commons licence.

The concepts behind Haskell seem to be very elegant, a powerful abstraction indeed. But how does the language fare in a real world project? Does it make the “easy things easy and the hard things possible”? I have no idea; I only had a brief contact with the language when I read Graham Hutton's Programming in Haskell some months ago.

The book is a very good introduction to functional concepts in general, and very entertaining. But its purpose isn't to teach you day-to-day Haskell; some areas are covered very briefly, others not at all, as you quickly become aware after lurking a bit on haskell-cafe.

If you happen to read the book, don't skip the exercises: it is easy to think you understood something when you really didn't. The two last chapters, “Lazy evaluation” and “Reasoning about programs,” are especially good, worth the price of the book, as they say.

Monday, January 7, 2008

Programmers & Doctors

When I look at a list of top programming books, I am happy when I find Programming Pearls, by Jon Bentley.

I read it in my freshman year (many years ago, time flies), after a teacher recommended it. The book is brilliant, that I can remember. If you are new to algorithms & problem solving, read it.

Or maybe you're just a little bit rusty (I know I am embarrassingly so). Can you still write a correct binary search? Are your “back of the envelope” estimates accurate enough?

“And what is the best book on debugging you have read,” Bentley mentions being asked. The answer directs us to another great book, The Medical Detectives.

Laymen often don't have the chance to foray into investigative medicine, as anyone who has tried to learn more from his doctor about a diagnosis knows all too well.

This collection of articles Berton Roueché wrote to The New Yorker is nothing short of amazing. The engaging, true stories display insightful reasoning you don't come across every day. As Holmes used to say, “once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.”

Sunday, January 6, 2008

Mumbo-Jumbo World

I'd like to re-read Francis Wheen's How Mumbo-Jumbo Conquered the World. Alas, I don't have it anymore: I lent it to someone from whom I usually hear lots of mumbo-jumbo arguments. The temptation was simply too strong to resist.

This excellent book paints a remarkably accurate portrait of the delusional state we have reached. Strange cults, voodoo economics, creationism, religious fanaticism, mysticism, alien abductions, anti-evolutionism, post-modernism and general superstition are firmly established among us.

While we may have heard about a handful of notorious statistics or examples of shocking beliefs held by world's rulers, the collection presented in the book is eye-opening, if disheartening.

So what is happening? Wheen believes the values of the Enlightenment, the Age of Reason, are lost to us. The inspiring “Dare to Know” has been twisted into a menacing “Don't dare to think.”

He is right, just look around.

Tuesday, July 17, 2007

Master of the Short Story meets Mérovée

When, in a night during WWI, H. H. Munro told a fellow English soldier to “put out the bloody cigarette,” it was too late. The light signaled the target for a German sniper.

Saki (Munro's pen name) wrote brilliant short stories, witty, full of humour and mischief. His style was succinct, precise and elegant. Those who like quality lit and haven't read Saki are in for a treat.

One of his most prominent characters is the iconoclastic Clovis Sangrail. In one story, Clovis decides to write a letter and sign it as Clothilde. This choice of names intrigued me a bit the first time I encountered them.

Prior to picking Saki, I had just read Holy Blood, Holy Grail, a book full of conspiracy theories, secret societies and wishful thinking. It puts forward the ludicrous theory that the “Saint Grail” actually referred to a bloodline that included the Merovingian dynasty and continued to this day and age. Not to be taken seriously, but a readable whodunit nonetheless.

I couldn't help remembering that Clovis I was the Merovingian king that united the Frankish tribes and converted to Roman Catholicism. It is said that the conversion was spurred by his wife, Clotilda.

Coincidences aside, the pleasure of reading Saki is only undermined when you realize you have read (and re-read) it all, and there's no more to be had.