Good. Only thing missing in Clojure seems OOP. But I can live without that.

Hope Clojure doesn't push the FP thing too far. Pure functional languages are evil. In broad sense, pure anything in evil. Look what Java turned into trying to be a pure (or too much of an) object oriented language.

It’s multi paradigm that wins. Giving programmers freedom on how he wants to code any specific set of problem.

Clojure supports OOP in the same style as Common Lisp.

http://clojure.org/multimethods

The integration with Java is almost seamless, so of course you can also use Java-style OOP if you're feeling masochistic :-P

Clojure is definitely not pushing FP too hard. It was designed to be especially supportive of FP, but it is definitely a multi-paradigm language.

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.

Not sure what your point about Java is since it doesn't seem to be either very evil or a very pure OO language.

Everything is in a class. Everything. Even poor little printf or the main function.

Although Java puts everything in an class, not everything in Java is an object. For instance, you can't write:

    Package p = java.lang;
    Class x = p.String;
    x y = "Hello";
    Method z = y.substring;
    w = z(0, 5);

That's just the syntax failing to support such a nice way of accessing those objects. Packages, classes, and methods are objects.

Of course, primitives are not objects, but autoboxing helps.

Sure, they're represented as objects in the JVM, and you can access this via refection; but they're not treated as objects in Java's syntax. I'd argue that OOP is a property of a language's syntax, rather than how it is internally represented.