Clojure-in-Action-2nd-Edition.pdf

Many new arrivals to Clojure—including Amit Rathore, the primary author of Clojure in Action—come from the world of enterprise software. Theirs is a world of staticly typed, object-oriented, rigid languages tied to enormous ecosystems of tools, frame- works, and libraries designed to introduce looser coupling among components and ever-changing business requirements. This is the Java and C# world of dependency injection, servlet containers, XML configuration, and code generation. Because Clo- jure runs on Java it is a natural choice for people seeking to escape the complexity of their world without completely leaving the good and familiar behind. The scary and unfamiliar aspects of Clojure for enterprise software developers are its dynamic typing and first-order functions, but the appeal of Clojure is liberation from incidental com- plexity and static typing, while still being able to use their old code when they need to. I did not come to Clojure from this world: I came from the Wild West of web devel- opment. This is a crazy world of dynamically typed programming languages such as PHP , Javascript, Python, and Ruby. Some of these languages were originally created with little or no thought to their suitability for large projects and hastily evolved new features and workarounds to adapt to this use. Many of their practitioners—including myself—have no computer science training and probably started their careers by messing around with HTML to give a web presence to their day job. Their program- ming knowledge, like the languages they use, was hastily acquired as the demands on their web presence grew. Unlike in the enterprise software world, dynamic typing, automatic type coercion, and late binding are the norm, first-class functions are common, and object-orientation is not a bedrock assumption. There are still largeecosystems of frameworks and libraries, but they are not as discipline-enforcing and configuration-oriented as in enterprise software development. For web developers, the scariest thing about Clojure is the specter of enterprise software lurking behind it—in a word: Java. For enterprise developers, Clojure’s Java heritage is a feature; to web developers, it’s a bug. If you come from the web developer world, I’m here to tell you not to be afraid of Java. Much enterprise software complexity is compile-time: static types, verbose code, and lots of XML configuration. I didn’t have those problems. But web development’s complexity in popular web development languages is run-time: the weak typing and extreme dynamism and mutability that make programs difficult to reason about. This is the incidental complexity I was searching for a better answer to when I found Clojure, and I was skeptical of Java too. I heard the Java EE stories, saw the enormous class files and the FactoryFactoryInterfaces. How, I wondered, could Clojure manage software complexity better when it is built on Java, the most notoriously rigid, brittle, and com- plex software stack there is? And how am I supposed to balance all those parentheses? Clojure occupies a middle ground between the undisciplined web development world, where codebases are difficult to change safely, and the excessive ceremony in the enterprise software world, where codebases are verbose and difficult to compre- hend. Clojure encourages more discipline on my programs than when I was writing PHP , but this is a discipline with no downside: your code is still as succinct (if not more) as what you used to write; you can easily and painlessly take advantage of many niceties of the Java ecosystem, like sane package management and jar-based deploy- ment; and thanks to the JVM your application will probably run faster, too! Clojure benefited me even before I wrote it professionally. Internalizing Clojure’s philosophy of simplicity and immutability helped me recognize the root causes of the complexity I was encountering in other languages and manage that complexity better. I now write Clojure (and ClojureScript) for a living and, yes, there’s still plenty of inci- dental complexity in my software, but it’s easier to see and far more manageable, and I’m building things I would never have dreamed of building in PHP or even Python. The first edition of this book was instrumental in sending me down the Clojure path I walk today. So I am honored to have had a hand in this second edition, and I hope it can help you tame the software complexity in your life, too. And don’t be afraid of the Java, or the parentheses! They’re really quite tame. F RANCIS A VILA