Another Java-style construct: Clojure has a do form, which enables you to consecutively execute the following expressions in the list.

It seems to me a way to sneak statements into the language. Or does lisp have something like that as well?

I believe that common lisp's prog1 and progn both do this.

It's pretty realist, it even has a doseq especially for side-effects iterations. It's not that it forces you to be FP (it can't, you can always run java methods), it's that it makes the advantages obvious and lets you decide.

It is my first contact with FP, but what I find incredibly cool is the way the data structures are transparently persistent. If it's true this is a rarity in functional languages, I can't imagine using another one.

I'm curious, what do you mean by "transparently persistent"? Do you mean that you can serialize anything (and so persist it as a file or what have you)?

Uh.. I know it's been 10 days :p

Let's say you have a map, and you change a value in it. Being a functional programming language, and the map being an immutable structure, you end up with two maps: the old and the new. Now, the cool part is every data-structure in clojure is designed _not_ to do this by copying the whole thing. You'll have two maps who share everything except the changed value. Same with collections, sets, trees etc. The work under the hood must be impressive...

Another nice thing (for me at least, coming from imperative programming) is there is a better difference between a variable and a value. A variable is a placeholder, and a value is ... well, a value. In clojure you treat them separately. A better explanation: http://clojure.org/state

Persistent in this case means that if FOO has value '((2 3) 4) and someone does (CONS 1 FOO) => '(1 (2 3) 4); the value of FOO does not change, but the new list shares its structure.

If you do a cons cell diagram for this it will make perfect sense.

I believe 'do' is found in the majority of Lisp dialects.

Yes, but it looks like Clojure's do is not the same thing. Lisp's do is for iteration, while Clojure's do seems to be the same as progn in Lisp.

Ah, my mistake.

I came across this http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_a... which seems to confirm progn ~ do

I'm just surprised that (it seems) you can do statement-based code in lisp. I thought it all had to be expressions. This feels like cheating. BTW: I can see that progn/do syntactically produce expressions, but the value of all but the last one are thrown away - similar to python in that respect. This seems against the spirit of expressions.

"I thought it all had to be expressions."

This is a common misconception. You are thinking of pure functional programming, not Lisp. Certainly a lot of Lisp programmers, myself included, prefer functional programming. Scheme, especially, leans toward functional programming. Haskell, not Lisp, is rightly known for embracing functional to the exclusion of all other paradigms.

What really stands out about Lisp is support for ALL paradigms, even those that haven't yet been invented. Lisp is an extensible language, that can be changed to fit your needs. Features that would require language extensions in other programming languages can be implemented as ordinary libraries in Lisp. Lisp was the language that allowed experimentation with new paradigms like functional programming, object-oriented programming, and logic programming long before more specialized languages (Haskell, Smalltalk, Prolog) were created to provide specific support for these paradigms.

I agree except that Clojure is specifically intended to be used functional, and not as OO. Clojure is not pure FP as it does allow state changes (in a controlled way), but that's an acknowledgement that state changes are useful and purity can be, I'll say, difficult. The way Java's OO embraces state changes is not the same principle, and makes things more difficult. OO style is possible in Clojure, but that's not what the language is meant for.

This is not cheating. Nothing surprising here.

Of course you can do statement-based code, like in any language that supports I/O(Haskell included).

That's a hard fact and it isn't what functional programming is about.