// μ = m // dayvan cowboy // music is math

Abstract for Haskellers:

This is a long, involved defense of purity, both in terms of what it affords us in terms of power and in how it enforces “good” programming practices.

Haskell is often defined in terms of what it cannot do: variables can’t be changed once declared, the results of IO computations can’t directly be used in functions, execution flow can’t be controlled, etc. While this characterization is strictly correct, it paints a rather ascetic, when not outright negative, outlook of the language that practitioners not only know to be misleading, but also to be the key to the great power latent in functional programming.

We discuss how and why certain “restrictive” features have become succesful in computer programming while others haven’t, and procceed to explain referential transparency and what it affords us. Finally, we conclude that adopting this particular set of “restrictive” features is useful and positive, even in contrast with the experience of non-useful “restrictions” that seem to have common characteristics.

Abstract for non-Haskellers:

This essay explains why Haskell is cool.

<

p>

Wow! I didn’t expect the spanish inquisition getting on the front-page of programming.reddit.com (I didn’t even submit my post to the site) and sparkling such a lively discussion there. I would just reply there, but I somehow feel it’s better to leave a more “permanent” record — even if for my own future reference — of my thoughts on the issues raised.

Vintermann’s interpretation of my point was this:

The issue for me is that from the syntax, you could believe

greet = do {
putStr (”You’re “++ getLine ++”years old! \n”);
putStr (”Congratulations! \n”);
}

was valid haskell, which it isn’t

This is specially true since <- as destructive update/assignment is used in many pseudocode languages in introductory books — particularly Knuth’s TAOCP, as well as some languages (like The Other Language I Use, GNU R).

Ricercar adds

(…) [M]onads are not limited to one interpretation, whereas “do notation” is strongly tied to the imperative interpretation.
This is much like “Lawyer Language” that is confusing precisely because it looks somewhat like natural language, when it really isn’t.

Well, yes, I couldn’t agree more. Maybe I’m unconsciously selecting the favorable comments — the one that further illustrate my point. But let’s examine pjdelport’s reply:

That’s hardly fair; programming language constructs don’t carry the same expectation of consistency that natural languages do. Both their syntax and semantics are wildly variable and arbitrarily incompatible, for even the most common things.

There’s two problems with this remark. In first place, ambiguity in natural language is in fact expected and discounted — often large chunks of natural language are confirmation requests and clarifications — while programming languages are mostly expected to be “logical” and consistent. In second place, that head in Beta means an iterator while in Haskell it means a cons-list “destructor” just means languages are different — much like in english “cola” evokes “soda” and in portuguese it means “glue”.

Cipitá é uma cidade do interior, dessas de novela. Cipitá fica a oeste de tudo; não há lei a oeste de Trilopinha, não há Deus a oeste de Rabidinga, e ao redor de Cipitá não existe nem água encanada.

A autoridade máxima de Cipitá é um juiz preconceituoso. Em Cipitá, ou você é cipitense, ou é um forasteiro.

data Pessoa a b = Forasteiro a | Cipitense b

O juiz preconceituoso de Cipitá tem critérios completamente diferentes para Forsteiros e Cipitenses; para um dado veredito a pronunciar seu raciocínio é o seguinte:

veredito sentença_ruim sentença_boa (Forasteiro a) = sentença_ruim a
veredito sentença_ruim sentença_boa (Cipitense a) = sentença_boa a