When you say state, do you mean state that is stored in memory and accessible by multiple threads? If that is what you have, then Clojure is a good choice. But also by that definition, most web applications don’t have state. State is usually stored in an external mechanism like a SQL database. Any in memory state is thread-local, only seen by one thread as it responds to one HTTP request, therefore Clojure’s state stuff isn’t any benefit in that case.

Do you agree, or are there cases where a web application has state that Clojure can help you deal with?

I invite everyone to consider the case against Clojure: http://www.loper-os.org/?p=42

Sure, you get a shiny, exciting toy to play with now. However, peacefully compromising with bad engineering has consequences. Software will reach a state of Idiocracy within our lifetimes.

Stu,

I’m curious: Are you finding that you’re consistently choosing Clojure over Ruby just as, until fairly recently, you were choosing Ruby over Java?

Put another way: do you find that you and your team (Relevance) are more productive delivery web applications in Clojure than in Ruby?

I have been following Clojure with some interest lately. I’m still a Common Lisp guy though because Clojure is still in flux and evolving rapidly from what I see.

I also see the fact that all Clojure programs are Java programs as a plus and a minus: a plus because you get access to all the Java libraries and JITs and whatnot out there, but a minus because there can’t be any independent Clojure port. In the real world to make an interesting port of Clojure you will also have to port all of Java so applications work. It’s like if no one wrote Unix/Linux applications but only Windows and counted on Wine always being there.

With regard to state - and Paul Barry already touched on this - I recently started implementing a small app which needs some persistent state. I thought to try doing it in Clojure but found out that while Common Lisp has tools like Rucksack and Elephant and CLSQL, if I wanted it in Clojure I would need first to create all my data structures as Java objects (albeit with (. blahblah) wrappers if I wanted) then run them through some clumsy Java ORM, or deal with raw JDBC or Java Berkeley DB.

If I missed something that’s already out there and available I would love to be pointed to it, but it seems to me Clojure could benefit from a native persistence mechanism or library that takes advantage of its concurrency strengths, or at least a native API for something like Berkeley DB that can deal well with it.

I think Clojure is a tougher sell to Java folks than Ruby or Groovy was. For average coders like me, the syntax takes some getting used to and the concepts take time to sink in.

@ Stan Datskovskiv

I’m not sure how that contributes to the discussion at hand. Clojure was written and designed as a modern LISP. We wouldn’t say “bad” engineering in LISP was why Clojure was started but rather the old LISP was outdated and failed to include new and better ideas that have been discovered since CL was standardized (concurrency, multi-core, the sequence abstraction, etc). Yes, engineering does involve making hard choices and tough compromises, but for many, Clojure made the right ones.

@vsync

Look at the current efforts to write Clojure in Clojure. Also, see the CLR effort.

I’ll believe more in these new languages when they are promoted by people who don’t make a living out of them, such as consultants.

@StanDatskovskiv: Thanks, that’s helpful. I just called all my clients and told them we are suspending development until the Hurd kernel is completed.

@Paul: The irony about state is that functional languages (which superficially avoid it) are better at state than imperative languages. Most web apps I have seen are filled with accidental in-memory state that Clojure can eliminate.

@vsync: there are lots of Clojure persistent APIs. I have been playing around with redis-clojure and it rocks. There is clj-record for people familiar with ActiveRecord, and ClojureQL for getting to SQL in a Lispy way.

@VaCoder: You are right, there is more new stuff to learn (for a Java programmer) in Clojure than in Ruby or Groovy. I spent three years doing primarily Ruby before making the switch.

@Evan: I am more effective in Clojure than in Ruby, but the Rails ecosystem is more than just a language. There are some web apps that are easier in a Clojure web framework, others that are easier in a Ruby web framework. Clojure is gaining ground all the time.

Speaking of Clojure, the example in P1.0 p172 doesn’t seem to work.

user=> (def foo 10)
#'user/foo
user=> (binding [foo 42] foo)
10
user=>

@Ross: Weird, it works for me.

user> (def foo 10)
#'user/foo
user> (binding [foo 42] foo)
42

I think I’ve resolved this, my recent d/l (1.1.0-alpha-SNAPSHOT) seems to have been withdrawn, or I just picked TWT, in any case today the featured d/l is Clojure 1.0.0- and it works…

Stu, I love the langugage and thank you for doing so much for it. And Thanks a ton for providing slides. I hope the conference allows you to release other multimedia too.