InfoQ Homepage Presentations Clojure in the Field
Clojure in the Field
59:56
Summary
Stuart Halloway presents what makes Clojure different and, in his opinion, better than Java, plus some real-life lessons on Clojure development including BDD for functional code, wrapping Java APIs, third part libraries worth knowing, writing code without an objectual context, and the learning curve for a team new to the language.
Bio
Stuart Halloway is a co-founder of Relevance, Inc. and is the author of “Programming Clojure, Component Development for the Java Platform and Rails for Java Developers”. He regularly speaks at industry events including the No Fluff, Just Stuff Java Symposiums, the Pragmatic Studio, RubyConf, and RailsConf.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
May 14, 2010
Community comments
Interesting talk
by peter lin,
updates
by Brian Gruber,
Highlights of the presentation
by Daniel Jomphe,
Interesting talk
by peter lin,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
updates
by Brian Gruber,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Highlights of the presentation
by Daniel Jomphe,
Your message is awaiting moderation. Thank you for participating in the discussion.
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