BT

Clojure Recipes Review and Q&A

Posted by Sergio De Simone on Jan 25, 2016 |

Addison Wesley’s Clojure Recipes, written by Julian Gamble, is a new book that aims to help developers to get deeper into Clojure, moving from a generic understanding of the language features and syntax to setting up more complex projects that integrate external libraries. As such, Clojure Recipes does not target Clojure beginners and does not provide any kind of introduction to the language itself, although all the code that is presented is thoroughly commented so even the unexperienced reader can follow along.

The book contains a collection of self-contained “weekend projects” that are meant to show developers how they can solve common problems with Clojure, including:

  • creating REST clients and servers;
  • using ClojureScript and Pedestal to create a web server;
  • creating macros to simplify logging and converting blocking code to non-blocking;
  • implementing a DSL to make Datomic, Clojure distributed database and implementation of Datalog, easier to use;
  • building an application that uses Datomic;
  • using Cascalog to build an app executing Hadoop queries;
  • using the Java Message Service (JMS) and Storm;
  • using macros to improve debugging.

As mentioned, each chapter aims to be an independent project that can be carried out in a relatively short amount of time. This means that more complex topics, such as using Cascalog and Datomic, are presented across several chapters, each focusing on one specific feature.

All the chapters in the book share a similar structure: readers are presented a case for the project at hand, then they are guided through the creation process for any required files, finally the code is succinctly explained. Given the pragmatic approach of the book, it is essential for readers to follow through and actually implement each project that they are interested in. On the other hand, it is not strictly required that chapters be read sequentially, although the first few projects are markedly more introductory in content than the rest and also cover setting up your Clojure development environment.

InfoQ has spoken with author Julian Gamble about his book and his view on the language.

InfoQ: Could you explain the motivation to write this book? Why was it necessary?

Julian Gamble: At the time of starting the project, there was no book in the ‘Recipes’ genre, which is common in programming language books. It seemed like an obvious gap, and my editor agreed. During the project the O’Reilly book delivered in a short timeframe, and grabbed this spot (but the author and I are friends, and we high-five at conferences. That’s the Clojure community for you!) What I found out later was that there are variations in this genre - the focus of Clojure Recipes was project-size (rather than snippet size) chapters with complete running examples.

The other motivation was to grow the Clojure Community and the use of functional programming, but providing lots of accessible examples. The book assumes a wide potential audience of programmers who are looking to find out about Lisp-style programming, functional programming paradigms and Clojure itself. I wanted to provide pathways for people to be able to pick up Clojure and use it in their day-to-day work, even if they worked at a big enterprise.

InfoQ: Could you shortly describe your background and your experience with Clojure? What led you to Clojure?

Julian: I had read a lot of Paul Graham’s and Steve Yegge’s essays on Software Development. Both are really good at convincing the ‘Java day-job programmer’ that there is so much out there that you miss out on if you don’t go beyond the Java language. Both have a big focus on Lisp. I started working in Racket and Common Lisp in 2007, and discovered a book called ‘The Little Lisper’ which I loved.

Then Clojure was announced in 2007 and I watched the community explode around it. I could combine my JVM background with the power of a LISP. Clojure was a joy, and the everybody was writing blog posts about what they were discovering. It was lots of fun to write code and talk to people about Clojure.

InfoQ: Your book targets developers with some experience in Clojure. What advice would you give them when reading this book? What should they expect? What should they not expect?

Julian: ‘some experience’ I would say “knows that Clojure has parenthesis and knows what a Read Eval Print Loop (REPL) is”. Clojure Recipes is a book for people who learn by doing. Clojure Recipes is the kind of book for people who say “I want to build a Clojure project this weekend. Where do I start?”

Readers should expect working projects, with explanation of how and why they work, and what the ‘moving pieces’ of the recipe are. Readers should not expect a bottom-up discussion on syntax, data structures, pure functions or the STM - you can Google that. This is a book for people who want to build things.

InfoQ: There are several books available about Clojure that address the language syntax and semantics. You take a different approach in that you try to cover a wide range of use cases, while also covering all the relevant details that the reader is required to understand. What is the major appeal of this approach, in your opinion?

Julian: major appeal of this approach is that some people have a different learning style, or different motivations for learning the language. Some people like a complete working solution that they can then tweak and learn that way. Some people prefer to jump right in and learn ecosystem foundations as they need them. Some people see programming language learning as a means to an end, not a quest for knowledge. There is a spectrum of opinions on what is most beneficial. Clojure Recipes is targeted at being ‘hands on’ with lots of help to get you there.

InfoQ: What criteria drove your selection of use cases?

Julian: The selection of use-cases was two-fold. The first question I asked was: “What is Clojure great at? what is easier in Clojure than Java?” The second question I asked was: “How can you get started with Clojure in your workplace?”

In terms of conciseness, I wanted them to be large enough to be self-contained and runnable, but small enough to focus on a particular idea. The point was to be able to tweak them to solve the readers problem – or at least a similar one – have that running, and then integrate that into a larger project.

InfoQ: Which recipe was most fun for you to implement? Which one the hardest? Were there any additional use cases that you would have liked to include but could not make into the book for whatever reason?

Julian: The most fun was the Stock Ticker on the Pedestal Framework Server. It had a mix of technologies, both server and client-side, and was most like a practical business application.

The hardest (one that required the most time on rewriting to make it better) was the series of chapters on the Datomic DSL. These chapters probably have the most depth of any in the book.

The chapter I would liked to have include, but couldn’t was a chapter that pushed the limits on code generation with Macros, to solve a similar problem to the Rails framework. I had a working demo and a written chapter showing how you could feed a table name to a running application, and it would generate the routes and actions, and display all the template generated at runtime. You could modify the template at run-time on the REPL. Despite being cool, I had feedback that said it required too much macro knowledge than the value it added. I pulled out the isolated parts of that chapter into an Appendix called ‘debugging macros’.

InfoQ: Could you describe some of the features that Clojure provides that can help programmers be more productive in to your experience?

Julian: Distinctive Clojure features include software transactional memory (STM), persistent immutable data structures, interactive programming through a read-eval-print loop (REPL), strong JVM integration by compiling to bytecode and great Java interop. Clojure will also make you a better Java programmer by challenging your assumptions about what makes great Java code.

InfoQ: What could be a relative or competitive advantage that a company could expect from adopting Clojure? And what could be the major challenges at the present time?

Julian: The primary competitive advantage is time-to-market. We had a guy at our Clojure User group exclaim how surprised he was at this contractor throwing up web services and web pages so fast, he had to come and find out what it was about. Paul Graham talks a bit about this in his essay, Beating the Averages. Also Clojure makes working on the JVM streamlined with fewer bugs.

InfoQ: Talking about Clojure’s increasing adoption for commercial projects, what are in your opinion the most relevant factors that are driving this trend?

Julian: Clojure is great for web-services, and so is at a great time with the rise of microservices. Clojure leverages the JVM, and so is an easy path to adoption in enterprises. Clojure is great for data processing, and so rides the wave of Big Data really well. Clojure is a joy to work with and is easy to pick up and get started.

About the Book Author

Julian Gamble is a software engineer who has worked in the financial services industry for more than a decade. When he’s not enabling billions of dollars to orbit the globe, he writes and presents on all things software related at juliangamble.com.

Rate this Article

Relevance
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT