Beware of the Train

brian d. foy says that you can't be an effective advocate for a language unless you can think of five things that you hate about it off the top of your head, the reason being that if you can't, then you don't know enough about the language to advocate it effectively. So, just to go one (or five) better, here are ( ten things I hate about Perl )
This is not to say that I hate Perl: far from it. I think it's a wonderful, fun language, with a great community around it, producing some insanely cool software (CPAN might be considered the world's premier laboratory for module and language-extension design). I am continually surprised that Perl has such a bad press, and gets such short shrift from the language-design community. You might expect that a language that breaks almost every accepted precept of language design would simply be a bad language, and no fun at all to use. Yet Perl does this, and has a fanatical community of users, some of them truly excellent hackers. This, it seems to me, is a datum point of enormous importance.

But anyway, I'd like to ask this question to the hackers reading this. What five things do you hate most about your favourite language?

* Unless you've set $[ to 1 - thanks, paddy3118!

[Non-coders: it shouldn't matter if you don't know about the specific technical issue that I'm discussing here. Hopefully, I've managed to convey something of what it feels like to code in different languages, which is the important thing.]

I was brought up on static languages. Admittedly, the first programming language I touched was BBC Basic, which had autovivification of variables, but it also had separate namespaces for string and numerical variables. Then I was taught programming properly on Turbo Pascal, which is all about the type system. I learned object-oriented programming on Delphi, which is what Turbo Pascal turned into, and was also heavily typeful (and, incidentally, one of the nicest development environments I've ever had the pleasure to use). When I first encountered dynamically typed languages, in the form of RSI's noxious Interactive Data Language (and later VB), I thought dynamic typing was an accident waiting to happen. Programming without static typing felt like walking a tightrope without a safety net, with the slightest wobble ready to pitch me into the abyss below. Wherever possible, I'd declare variables, turn off everything implicit, and curse if there was no way to do these things.

It wasn't until I started using Perl (and I discover with surprise that I can't remember exactly when that was - presumably around 2000-2002, when I started using Linux regularly) that this began to change. Perl offers no facilities for static typing - it's dynamic all the way. More than that, it's mutably typed - if I ask for "3" + 4, it won't die at compile-time like Haskell, or at run-time like Python, it'll simply convert the "3" to a 3 and return 7. If you ask for an array element that's out-of-bounds, it won't die with an "array subscript out of bounds" error, it'll just lengthen the array so it's big enough and autovivify the extra elements. Yes, this can be slow. But there are plenty of ways of finding out how big an array is, so obviously you did that because you wanted to.

This was presumably painful at first (I can't remember). But after a while, I started to get it. All my old fears were revealed, in the light of day, to be groundless, and even slightly ridiculous - if I wobbled, then the tightrope moved under me, to counterbalance my movement and hold me up. I could walk along the rope as easily as if it were pavement, and on the few occasions where I fell off, it turned out that the bottom of the abyss was actually covered with big trampolines. The sense of liberation was wonderful. Why should I, as a thinking human being, have to worry about the trivial difference between 3, 3.0, "3" and (3), when a machine could do it for me and leave me free to concentrate on the important stuff? I started to code in tune with the language, and as a result my code became simpler, clearer, more robust. I could Say What I Meant, and perl¹ was smart enough to Do What I Meant.

Which is why it's so jarring coming back to static typing for Haskell. After grokking dynamic typing, static typing just seems antediluvian. Every time a compilation dies because of a type error (and actually, having to compile code before running it seems pretty antediluvian too), it's like the hip young guy I thought I was talking to has suddently adopted the tone of a boarding school headmaster circa 1950 and caned me for having my shirt untucked and misusing the optative. And if you have no idea what an optative is or in what context you might wish to use one, then you have some idea of my bewilderment at most GHC error messages.

Maybe I'll grow to love static typing again, as I grew to love dynamic typing before it. Maybe (and this is what I'm hoping for), I'll be able to transcend the dichotomy, and come to a deeper understanding in which I realise there is no real opposition. But right now, it's hella frustrating.

¹ As any fule kno, Perl is the name of the language, and perl is the name of the interpreter for that language. PERL is something different :-)

Back in the days of Russell and Whitehead, there was this attempt to make mathematics totally rigorous by turning everything into manipulation of strings of symbols in formally-specified languages. The idea was that mistakes could be eliminated (in fact, I think the idea was that proofs could become machine-checkable, if not machine-generable). This attempt foundered, for two reasons:

1) Godel's theorems, which show that any such formal system powerful enough to talk about the natural numbers (0, 1, 2, etc) will always be incomplete, ie there will be truths not provable in the system;
2) The sheer, mind-destroying boredom and ghastliness of writing proofs in this style. In my first year, when I was studying formal logic, I found that the only way I could force myself to actually do my logic homework every week was to get blind drunk on Wednesday nights, and then wake up at six on a Thursday morning to do the work, which was to be handed in at nine. Only then, when I was sleep-deprived, hungover and in a deadline panic, would my brain be in the right state of zombified automatism to do the work.

Now, we can't do anything about 1). But I'm starting to wonder if we can do something about 2). The early systems were horribly low-level: they didn't have any mechanisms for adding useful abstractions. In programming terms, it was like writing everything in assembly language. Programmers (mostly) know that this is a daft thing to do: apart from hardcore graphics/numerical types, everyone now writes in languages that are more-or-less high-level, which is to say closer to the way humans think about problems, rather than how computers think about them. Intermediate programs called "compilers" and "interpreters" do the translation from the high-level language to the low-level language that the computer speaks.

As far as I know, there's only been one attempt to apply this insight to formal proofs, by Leslie Lamport: paper abstract here. It's awful. Not quite as bad as writing things in the language of Principia Mathematica, but close. Surely we can do better. It has line numbers, for God's sake. We know about all kinds of useful abstraction mechanisms and syntactic constructs, from our experience with programming languages - object/aspect orientation, function abstraction, macros/templating, block structure - maybe some of these can be applied to proof?

In case you're wondering, this line of thought was inspired by the following footnote in Paul Graham's latest article:

It's conceivable that the elegance of proofs is quantifiable, in the sense that there may be some formal measure that turns out to coincide with mathematicians' judgements. Perhaps it would be worth trying to make a formal language for proofs in which those considered more elegant consistently came out shorter (perhaps after being macroexpanded or compiled).

"Nah, never work", I thought. "Formal proofs are ghastly. But hang on... he's talking about using macroexpansion. Maybe we could use that..."

As I've mentioned a few times, I'm (re)-learning Haskell. Here are my current thoughts on the language. No doubt, when I have drunk of the Kool-aid in fullness, I shall look back on them and laugh/cringe at my naiveté. Please try not to get upset about them: if it helps, think of them as having big <at-my-current-state-of-knowledge> tags around them.
( Rant )

By the way, I've fixed the juggling program. But then I was reading Burkard Polster's The Mathematics of Juggling on Saturday, and came across a much simpler algorithm: a siteswap [a_0,...,a_n-1] is juggleable iff the function (i |-> i + a_i mod n) is a permutation of [0..n-1] (by finiteness, iff it's a surjection). In Haskell (untested),

isJuggleable ss = and (map (`elem` test) [0 .. n])
        where test = map (`mod` n) $ zipWith (+) [0 .. n-1] ss
              n    = length ss

Or in Perl:

sub is_juggleable {
        $hit{$_ + $i++ % ($#_+1)}++ foreach @_;
        return scalar(keys %hit) > $#_;
}

See what I mean about the hashes? :-) Tests: er, that has a bug in it, but my girlfriend has been wanting to go home for a while now. I'll fix it tomorrow.

¹I strongly recommend this exercise to everyone, actually - writing code helps you to absorb the ideas, and thinking about why the code's different in the two languages helps you to see the tradeoffs between their design decisions. And On Lisp is a great book, with rather more than its fair share of Keanu moments - those moments when you sit back and say "Whoa." The chapter on anaphoric macros is particularly cool.
²By "hashes", I mean associative arrays/dictionaries/etc, I'm not bothered about the implementation. Data.Map qualifies, but it's a lot less convenient than just being able to say $foo{$bar} = $fred, or $foo{bar} = $fred (barewords are treated as strings in hash indexes). Consider how ugly most Haskell code would be if there were no syntactic sugar for lists...

Programming languages and their relationship styles.