The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
How would you like to view the presentation?
Getting Started with Stratos - an Open Source Cloud Platform
18 agile and lean practices for effective software development governance
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
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
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
3 comments
Watch Thread Reply