Strangely Consistent

Theory, practice, and languages, braided together

November 22, 2008 — there's more than one way to write it

80 years ago today, Boléro, composer Maurice Ravel's most famous work, premiered in Paris. Wikipedia on its nascence:

While on vacation at St Jean-de-Luz, Ravel went to the piano and played a melody with one finger to his friend Gustave Samazeuilh, saying "Don't you think this theme has an insistent quality? I'm going to try and repeat it a number of times without any development, gradually increasing the orchestra as best I can." This piece was initially called Fandango, but its title was soon changed to "Boléro".

There's a critic cited in the Wikipedia article who thinks that Bolero has such a wide appeal among the general public because "its rhythm is the same as that of sexual intercourse".

Today, submerged in my studies again, I've been thinking about languages, programming languages as well as spoken languages. I guess that's a world-view that comes natural for someone being active in the Perl community.

Both programming languages and spoken languages can be used to communicate intent. But the former, even with DWIMminess taken into consideration, has an unforgiving exactness about it that the latter lacks. Of course, the goal is different; we don't go around programming other people. (Although it sounds like a fun idea.)

Despite the fundamental differences, programming languages and spoken languages have a lot in common. Especially — and here's today's metaphor, because that's all I have blog time for today — especially translating between two languages. Porting.

In theory, porting might seem like a totally mechanical procedure. And much of it indeed is mechanical. In the same way automatic translation gets a lot of basic sentences right. But it's with the interesting parts that they run into trouble: allusions, metaphors, partial patterns, puns... often the very things that give a particular language its flavour. The things that are not just built up from primitives.

The introduction to "Effective Java" contains something along the lines of that sentiment, too: that something can be perfectly grammatical and still feel stilted. A successful port of a program will of course make use of the unique features of the target language. The phrase "you can write FORTRAN in any language" carries with it the implicit warning that it might not be a very good idea to actually write FORTRAN in any language. It's often more effective to wrap your head around the language, and let its features form your programs.

Same with spoken languages. I'm currently learning Mandarin, and have been for two years now. Not only would I do myself a disservice by coming up with a sentence in English that I'd like to transform word-for-word into Mandarin, in most cases I'd probably fail badly. Much better to start from the primitives of the language, some sort of abstract toolbox of words, patterns and phrases that I know work, and build something from that.

The nice thing is that the brain can do this, and in real time if you practice. There's a certain rush connected to uttering a sentence in a foreign language, and realizing that it actually came out right and conveyed what you wanted it to.

The same thing goes for Perl 6. I'm learning it day by day, finding new idioms and structuring principles, sharing tips and discussing techniques with my co-developers, and being slightly amazed every time new vistas open up due either to a new feature suddenly working, or an old feature being uncovered that had been there for a long time. (pmichaud++'s revelation of the {*} feature is an example of the latter.)

All in all, it's great fun. We're learning to speak fluent Perl 6. And when Rakudo 1.0 is released, we'll already have a wiki app running on top of it, written in idiomatic Perl 6.