Archive for September, 2010

free will or not

September 13th, 2010

One of the classic topics for debate among us humans is the dilemma of free will. In a way I'm surprised that it comes up as much as it does, because I don't really think it's that interesting a question. In the sense that I don't see how we're making any progress on it.

It's as if everyone is convinced that we have free will, and yet... there is absolutely no empirical basis to think so. Never has anyone had the chance to go back in time and make a different decision. So why do we seem to think it must be so?

Here's the thing. It's my impression that much of the debate on free will is shaped by an unwillingness to really accept the premise of the question and take it to its logical conclusion.

All too often I've heard people argue things like "well if there is no free will, then people cannot be held responsible for their actions, so we should let everyone get away with it". What do you mean "let"? Here's the problem: our form of expression is basically based on the premise of free will. So to even discuss it without commiting a fallacy one has to be careful.

The whole "ethical problem" of determinism seems to me nothing more than a false dilemma. If the actor has no free will to commit a crime or not, then why are we debating the problem of "deciding" how to respond if we have no freedom of choice? If the actor has no choice, then neither do we, there is nothing to decide, there is no problem to solve. Whatever happens is purely a matter of inevitability, however much it may seem otherwise. If the crime commited was deterministic, then our post-fact discussion is deterministic and whatever action we will take is also deterministic. The only way there is a dilemma is if the other guy's actions were determined and yours somehow aren't. But that's not how the question is defined.

The free will topic also enters the religious domain often, and there too people make the same mistake. As in, if god is all powerful and all knowing, then he knows your future, thus your future is decided, thus "why are you praying to him hoping he will change his mind?" Wrong. If the future is decided then he has *already decided* that you will pray to him and that you will thank him etc, so your apparent gratitude to him is nothing else than him having decided to "program you" (if you will) to thank him.

things I hate about haskell

September 4th, 2010

As the title for this blog entry popped into my head today I realized I had been silently writing this for five years. I want to stress one word in the title and that's the word "I". It might be that what I have to say is no more insightful than people who don't like python because of the whitespace, or people who can't get over the parens in lisp. But I happen to believe that a subjective point of view is valid, because someone, somewhere had a reaction to something and it's crooked trying to pretend that "the system is immune to such faults".

My complaints have little to do with the big ideas in haskell, and those ideas can just as well be realized in another language. In fact, the way things are going, it's likely that haskell's bag of tricks will be the smörgåsbord for many a language to choose from. F# from Microsoft, clojure making waves, and lambdas that have reached even java. As James Hague wrote, functional programming went mainstream years ago.

Elitism

I don't mean elitism in the sense that you sometimes hear about lisp mailing lists, that the people are hostile to newbies with a harsh rtfm culture prevailing. I haven't met any nasty haskell people, it's the culture where the elitism is encoded.

I don't think I have to explain that if you, as a software engineer, meet with a client for whom you are building a product then you don't insist that the conversation be held in terms of concurrency primitives or state diagrams. If you want to get anything done, you have to speak the language of the customer. And that's a general principle: if you are the more expert party in the field that the conversation concerns, then it's your responsibility to bridge the gap. If you don't understand your customer, then you have a problem. And if you do understand him, but you don't care, then there's a word for that... oh yes, elitism.

What I mean by elitism in haskell is the belief that "what we have is so great that we're doing you a favor if we let you be a part of it." Trying to learn haskell is something like being a fly on the wall at a congress of high priests. There is theological jargon flying all around and if you happen to make out some of it, we'll let you live, that's how nice we are. There seems to be a tacit assumption in place that if you touch haskell then either a) you have been brought up in the faith or b) you have scrubbed your soul clean of the sins of your former life. That is to say if you're comfortable coding in lambda calculus then you'll have a smooth run, but if you code in any of the top 10 most widely used languages then good luck to you. "Enough already, do I have to spell it out for you: forget everything you know about programming and imprint these ideas on your brain."

Here, I'm pleased to mention Simon Peyton Jones who makes an effort to speak the language of his audience. And when you read his papers you get the impression that he's saying "okay, so maybe you're not a gray beard in this field, but I'll try to explain this so that you get something out of it". Alas, Simon is miles ahead of the pack.

Still, it's changing over time. There seems to be a new generation of haskell coders who don't live in that ivory tower and actually do sympathize with their fellow man. (To the mild chagrin of the high priests, one imagines.)  The first time I really knew that haskell was on the right track in the language ecosystem evolution was the appearance of Real World Haskell. It's the first book that I knew about that wasn't for the in-group, with a provocative title that seems to say "the language isn't about you crazy puritans in the programming language lab, it's about people trying to solve their everyday problems". Since then I have seen further evidence of this development, notably Learn You a Haskell, a "port" of Why's Poignant Guide to Ruby, the first book about Ruby that really took the newbie programmer seriously (and I'm pretty sure did wonders for Ruby adoption).

Math envy

One of the earliest things I ever read about haskell was "the neat thing about haskell is that functions looks almost like functions in math". I remember thinking "why is that supposed to be a selling point?" Unless you are actually implementing math in code (which is a pretty minuscule part of the programming domain), who cares? As I would discover later, it was a sign of things to come.

I read a couple of books recently about the craft of software engineering that are written in the form of interviews with famous coders. I recall that on several occasions there would be a passage more or less like this "but when I went back to look at the code I had written back then I was ashamed that I had used so many single character variable names". Exactly how many more articles and books have to get written until people stop writing code like this:

(>=>) :: Monad m => (a -> m b) -> (b -> m c) -> a -> m c
m >=> n = \x -> do { y <- m x; n y }

Is this an entry in a code obfuscation competition? (Is there some way you could obfuscate this further?) Why does reading code in haskell have to be some sort of ill conceived exercise in symbol analysis where you have to try to infer the meaning of a variable based on the position of the parameter? I'll be honest, I have no memory for these kinds of things, half way down the page I have long since forgotten what all the letters stand for. Why on earth wasn't it written like this?

(>=>) :: Monad tmon => (tx -> tmon ty) -> (ty -> tmon tz) -> tx -> tmon tz
f1 >=> f2 = \x -> do { y <- f1 x; f2 y }

Maybe that's not the optimal convention, but it's far better than the original. Almost anything is. (It's still pretty minimalistic by the standards of most languages.) Haskell prides itself on its type system. As a programmer you have that type information, so for goodness sake use it in your naming.

This kind of thing is normal in math: pick the next unused letter in the alphabet (or even better, the Greek alphabet!) and you have yourself a variable name. It's horrible there and it's horrible here.

Syntax optimized for papers

If you read about the history of haskell this is not really all that surprising. Before haskell there was a community of people doing research on topics in functional languages, but to do that they had to invent little demonstration languages all the time. So eventually they decided to work on a common language they could all use and that became haskell.

Haskell snippets look nice in papers no doubt. But how practical is this syntax?

main = do putStrLn "Who are you?"
          name <- getLine
          case M.lookup name errorsPerLine of
               Nothing -> putStrLn "I don't know you"
               Just n  -> do putStr "Errors per line: "
                             print n

Is your editor set up for haskell, does it know to indent this way? If not you're going to suffer. Haskell breaks with the ancient convention of using tabs for indentation, so if what follows a do or a case doesn't line up with a tab stop, you're out of luck. Unless your editor supports haskell specifically, that is. So all you people using some random editor: bite me.

Because of the offside rule, and haskell's obsession with pattern matching/case statements, all your code ends up in the bottom right of the screen in functions past a certain size.

And haskell is obsessed with non-letter operator names, because letters are so tiresome, right? Haskell people love to author papers in latex and generate pretty pdfs where all the operators have been turned into nice symbols (and Latin letters become Greek letters, more math envy). Sometimes when you're reading the paper you don't even know how to type it into an editor. It's almost like coding haskell is also an exercise in typesetting. "Yes, it's ascii, but just think how lovely it's gonna look in a document!"