Unlearning Lisp

Most people have managed to uninstall Lisp but many are still having trouble
unlearning it. This story is well known from programming language folklore
where it is said that "BASIC (and Lisp) pollute your mind and make you a
worse programmer".

There are many interesting examples of this on the web:

"What am I missing about types?" by DoomChild

In this thread, DoomChild presents the following F# code:

let checkType thing =
match thing with
| bool -> "a bool"
| _::_ -> "a list";;

This is clearly because he grew up in the dynamically-typed Lisp ghetto. He
is trying to do run-time type dispatch but ends up with a function that
always returns "a bool" and can only be applied to lists.

"Speed comparison: PLT Scheme, Ocaml and C++" by Ian O

Interestingly, Ian is having the opposite problem. His OCaml implementation
of the n-queens problem boxes too much and introduces the unnecessary
run-time checks so typical of Lisp:

let valid_board b =
match b with
Some (Board (_, _)) -> true
| _ -> false;;

Nice to see the pattern matching getting in there though.

"Continuations and consing" by Thomas Fischbacher

In this case, Thomas is a much better versed programmer of statically-typed
languages but he still makes the classic mistake of assuming that a Lisp
optimization carries through to OCaml (we've all done it). Even worse, he
wants to address the non-existent inefficiency using macros (as Juho
Snellman did in my ray tracer benchmark).

Specifically, he asks the reader to choose from these two implementations:

let sum_nums n =
let rec work sum todo =
if todo=0 then sum
else work (sum+todo) (todo-1)
in work 0 n

let sum_nums2 n =
let rec work (sum,todo) =
if todo=0 then sum
else work ((sum+todo),(todo-1))
in work (0,n)

when, in fact, they produce the same code.

A common theme is that these people didn't realise the cost of the
abstractions that Lisp was imposing upon them with regard to performance
and correctness. Did you?

Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal