Clojure talk videos

Clojure was mentioned here before and the Boston Lisp talks from Rich Hickey are amazing: Part 1 and Part 2. Just the idea of imutable vectors, sets and maps as additional first class data structures with different kind of parentheses already makes it the best lisp for functional programming ever.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More information

Hum, I think I should elaborate since the videos are long. What really is interesting about Clojure? First it is really a new language, not a variant of Scheme or Common Lisp. It is pure functional in the same sense as Erlang (single assignment). Clojure also atacks the same problem that Erlang (concurrency and paralelism), but with a very different approach. But what really amazed me: it extends the approach of syntactical support for lists to other pure functional data structures classes like sets and maps. I use the word "class" because it seems that the implementation can be changed, for example list is actually an interface called "seq" and while there is an obvious implementation, our beloved list, you could change the implementation for something that uses the same interface but different computational complexity. This idea and other enhancements (like destructors) make the usability very atractive for me. Depending of the implementation it can be a very good contender to Haskell for pure FP (syntactical and typing preferences aside).

[Edit.] I forgot to mention, it compiles for the JVM.


Depending of the implementation it can be a very good contender to Haskell for pure FP

Both Clojure and Erlang are impure functional languages. That's not a complaint or a slam. I like both - and I happen to use several other impure functional languages (Scheme and Scala). It's just that if the word "pure" is to mean anything at all, then languages like these don't fit.

To really understand what people mean by purity in a functional language, see What is a Purely Functional Language.

The main point the paper makes is that in a purely functional language call-by-name, call-by-need (lazy), and call-by-value (strict) evaluation strategies are all equivalent modulo non-termination issues.

Both languages are impure for the way they deal with IO, among other things. If you have a function called "read-string" which gets a string from the user at the console then the equivalent of the following will have different results depending on evaluation strategy (here I use Clojure syntax, but same idea in other syntaxes).

(let [a (read-string)]
     [b (read-string)]
  (foo a b))

In call-by-need and call-by-name it's hard to say how often read-string will be called, and what variables will hold which input at which time. That's why Clojure and Erlang and, indeed, most impure languages use call-by-value.


I should have used the term "single assigment languages". Is there any way that a dynamic language with I/O can be made "pure" as you defined? The only ways to restrict I/O that I know involve static typing (monads or effect types).

Monads don't require static typing

The encoding underlying monads for IO is just continuation passing style, which you could do in a dynamic language.


A simple (re-)definition (or consequence) of pure is that all side-effects carrying code is made explicit by the type of the code. A language is either pure or impure, it cannot be both.


The question wasn't whether a language could be both pure and impure (which means "not pure", right?), but whether it could be pure and dynamic. Purity (as I believe it is commonly understood) doesn't have to do with the type system, but whether side effects occur during evaluation.


Sorry, got the question wrong. Then, yes a dynamic language can be pure. Seems to be an orthogonal feature.

Hmpf, with regarding to purity. Well, the redefinition is not entirely correct ;-), granted, but, given current understanding of 'purity', it is as good as any. But it is actually cumbersome to talk about purity. Even in, say, Haskell, where every program is pure, it's evaluation might not be; it really is a semantical mess.

Pure stuff

Thought about it a bit more. Also, given inspiration by the pure functions post.

I guess the best way to state is that you don't have "pure" programming languages, but only "pure" functions (those functions which are confluent under normal beta-reduction). Now, Haskell is pure, in the sense that all functions you write are all confluent (modulo termination), but the programs written which use the IO monad when evaluated are not.

The question is "can a pure dynamic language exist", should be read as "can we write pure dynamic functions?"

I think so, but you need a bit of a different semantics for your language where function symbols are not constants, but refer to names which are all bound in the current scope of a function. That way you can change a function (definition), pass the scope to all next calling functions, and all remains "pure".


Reading "pure language" as "language in which we can write pure functions" will put you on a different page from anyone else using the term. Haskell's rules for interpreting IO are in a completely different semantic domain from its functions, all of which (modulo unsafe*) are pure.


Well, a pure language would be a language in which (it seems?) you can _only_ write down pure functions.

God, "Haskell's rules for interpreting IO are in a completely different semantic domain from its functions" doesn't make it any better does it? Okay, say Haskell can do impure stuff, but from a entirely different semantic domain. Is that then not part of the Haskell semantic domain?

(Disclaimer, I really don't care to much about it. Maybe drop it?)

Closure Concurrency | Medal

I watched his talk on concurrency in Clojure. With his amazing innovations in concurrency, this may be by far the most useful language for sane multi-threaded programming ever.

This guy should get a medal.

if it really does pan out

cf list discussions and some actual testing which might help folks figure out what the real deal is with contention.

cf acm queue

some cold water on stm in there.