Clojure in the Field

Recorded at:

Though I am a fan of LISP, I think the learning curve issue is the biggest challenge. LISP has been around for a long time, but it's never really had wide acceptance in the developer community. In the AI field, it's still popular.

When I try to teach others about LISP and how to use it, I find that many people simply can't think in LISP. The whole declarative S-Expression approach of LISP makes it very hard for most developers. Since Clojure is LISP, many developers will get frustrated at first. My advice is to stick with it. It will eventually pay off.

The talk was interesting.

It's worth nothing that in the ~6 months between when this talk was given and when it was posted here, some of the information has become out of date.

Specifically, what Stuart says about Emacs is no longer really true. Setting up emacs within your own setup is fairly simple using ELPA. Throwing out your old setup is not really necessary. Using SLIME and swank is very easy if you use either Maven or Leiningen to manage your project. In fact, I think that if you're using emacs using swank is now easier than not using swank. Leiningen itself is mentioned in this talk as "just announced"; it is now fairly widely used in the Clojure world.

1:00 - History
2003 Starting up the business with Spring Hibernate Java
2005 RoR's hard turn
2008 Clojure's turn (already more than 20% of the projects)

1:30 - Using Clojure for
1. Rule-based systems
2. Social networking systems: competing with Rails' sweet spot!
3. Scalable web services
4. Near real-time simulators

2:00 - Why Clojure
1. lisp (2:30) metaprogramming
2. Java (3:30)
2.a "Clojure moves you away from Assembly Language for the JVM (Java!)"
2.b "Clojure needs less parentheses than Java"! (4:00)
3. functional (5:00)
3.a shorter, nicer style
3.b fewer datatypes (7:15)
3.c persistent data structures
4. the problem solved is not concurrency, it's state! (10:30)
4.a typical OO state (11:00)
4.b a sane model for dealing with state (12:00)

16:30 - Questions
Q1 - How do you use Java objects in Clojure?
Q2 - Why not Scala? (18:00)
Q2.a - "I can't imagine what I would write Java for. I would instead use Scala for those few things."

20:00 - Pain points
1. "We struggled to be effective with the testing framework for a while." (22:45)
2. "Ruby kicks everybody else's ass with its testing tools" (23:30)
3. To wrap or not to wrap (24:00)
3.a "Mocking in a lisp is beautiful." (25:15)
3.b "What to do when you want to mock out some Java stuff?" (26:00)
4. The learning curve (26:45)
4.a "There's more to learn that's new than to another dynamic language." (28:00)
4.b "Switching over to a functional style isn't trivial."
4.c "The model for dealing with state is arguably revolutionary."
4.d "We mitigate the learning curve this way." (28:30)
4.e "Knowing where to find something. You often write it yourself before learning that it's already there for you somewhere."

30:00 - Libraries
1. Those you need!
2. Other libraries we've used (32:45)
2.a Clojure frees you from dealing with in-process state (34:30)
2.b Survey: "About 1 line in 1000 lines of Clojure code instantiates some mutable reference."
3. Java libraries (36:00)
3.a "We don't use Compojure's html template mechanism - we use StringTemplate for that." (37:15)
3.b "A lot of Java libraries are not well aligned with Clojure." (38:15)
3.c "Hibernate is an extraordinary bad fit for Clojure." (38:45)
3.d "The libraries' stuff has generally been very satisfying." (39:00)

39:15 - Cohesion
1. "OO systems drift away from cohesiveness."
2. "Functional systems don't drift away from cohesiveness."
3. Although there's a namespace thing yet to be sorted out. (41:00)

43:00 - Shipping It
1. "The other thing for which Ruby kicks everybody else's butt is at tools for automating deployment."
2. "We use the Ruby tools to manage our Clojure deployments."
3. "I hate Maven. Some use it." (44:00)
4. "All JVM-based languages are crap for operating differently with each operating system."
4.a Still, some people are building stuff for this in Clojure! (45:30)

46:30 - Other pain points
1. Convention over configuration: right now Clojure projects copy conventions from other languages, which are not adapted to Clojure's own idioms, which are not yet all discovered.
2. "Error messages are horrible on all the advanced JVM languages (Clojure, Jruby, Scala, Groovy)." (47:30)
2.a Mitigated if you do TDD.
3. "Some people don't like living without objects, but I'm fine with it." (48:00)
3.a "Let your data be your contract." (48:30)
3.b Anyway, it's how it always works as soon as it gets out-of-process. Get over it.
4. Editor support (50:00)
4.a "Paredit is very important. I wasn't using it. Rich Hickey wasn't either. We were out in the darkness."

52:45 - Pleasure points
1. Libraries
2. Readability - "Better than Ruby's readability!" (53:00)
3. Destructuring
4. Metadata - Contrasted to Java's poor man, high ceremony annotations (53:30)
5. Multimethods - "We use them all the time. It's a powerful abstraction."
6. Macros
7. Reference types - "Has been incredibly easy to all our developers. The signature feature of 8. Clojure." (54:15)
9. Data conversion - "Makes Design Patterns fall away." (54:45)
10. Repl
11. Paredit
12. Namespaces - "Really cool. Ruby sucks on this." (55:00)
13. Composability - "À la carte programming." (56:00)
14. Java interop

56:45 - The risk of using Clojure
1. "Our clients requested us to stop considering Clojure as a risk."
2. "It's been greenlighted. There's no significant issues to using Clojure."

57:45 - The real sweet or weak spots of Clojure
1. Sweet - "Any application that deals with out-of-process state."
1.a "With Clojure the in-process state is not in your face anymore."
2. Weak - "Anywhere there's a strong convention over configuration solution on another platform." (58:00)

59:15 - More info