An (apocryphal?) tale:[^1] when Brendan Eich unveiled the original JavaScript (nee LiveScript, nee Mocha) prototype at (then) Netscape, it was a Lisp.An (apocryphal?) tale:[^1] when Brendan Eich unveiled the original JavaScript (nee LiveScript, nee Mocha) prototype at (then) Netscape, it was a Lisp.[^2] It was only at management's insistence that the language received a C-like syntax, and even then it was mostly to have some kind of syntactic parity with Java (with which it was supposed to provide some "glue"). Now: if you think about JavaScript using this lens, then it is easy to conjure up images of as "the JavaScript that could have been".[^3]
And that is exactly what we have in Sierra and VanderHart's ClojureScript: Up and Running -- a guided quickstart to the language that JavaScript could have been. And what an interesting little language it is!
Sierra and VanderHart deliver an excellent introduction to ClojureScript, which is targeted at a sufficiently broad audience of Clojure developers, JavaScript developers, and developers of all other stripes looking to do some discovery. You don't need to know Clojure going in,[^4] but I suspect you'll want to know at least a little JavaScript. From there, they take you through installing ClojureScript, installing and working with the build tool, the core syntax, and... it goes upward from there. Just as the title suggests: there's everything that you need to get started. By the time you walk away from the book,[^5] you should be able to confidently say what ClojureScript is, what motivated its creation, and you should have enough of the basics down that you could write a trivial application with it. (Perhaps even something more "intermediate" level, if you're patient and persistent.)
Before we go any further, a few words about what the book is not:
* It is not a comprehensive language guide. * It is not a thorough introduction to Clojure. * It is not a primer on JavaScript. * It is not a nitty-gritty low-level reference.[^6]
Now, for as easy as it is to recommend ClojureScript: Up and Running, I did find myself with a few critiques.
First, as someone who likes JavaScript and enjoys writing it, there are some borderline inflammatory statements in here. There's the line about having a "cleaner syntax"; and we all know the volumes-upon-volumes of blog posts, forum threads, and flame wars that are already out there about statements like this one. Then there's that line about how "JSON is a feeble data format"; and I find myself thinking I've never felt limited by JSON... These statements read like trolling, and they distract a bit from the salient points being made. (See also: "Stop taking these things so personally.")
However, this leads me to my second critique: that (again: as someone who lives and breathes JavaScript) the ClojureScript way is not always the JavaScript way, and this seems to be taken for granted in the text. (As an aside: this is perhaps a critique more of ClojureScript than it is of the book.) There is some discussion in the text about how to "marry" these discrepancies, but as ClojureScript is "more strict", and as ClojureScript is the compiler... it's the one that "wins" when there is a disagreement. Granted, having gotten through the book, and having grasped the motivation behind the language, I also understand why things resolve in this way -- and in light of the idea that "ClojureScript is the JavaScript that could have been", it's almost nice to see things resolve this way but... To a self-identifying JavaScript professional, some of this can be a little off-putting.[^7]
And my last critique: for an introduction, they sometimes drift into almost-but-not-quite esoteric territory without adding sufficient context. Example: "In JavaScript, strings are often used for constants or identifiers in code; keywords fill the same role in ClojureScript." I read these words, and I understand them. And I believe that I understand the concepts. But I do not believe that I could explain this to someone else. I could not explain why it is important; I am missing some bit of experience or context to bring it fully into focus. There are a handful of these in the book (maybe a half-dozen or so?) but I made a note of them every time: "Come back to this passage after you've seen it in the real world."
Despite these (minor?) critiques, I would easily and heartily recommend ClojureScript: Up and Running to anyone with even a passing interest in learning the language. You may not walk away from the book with a desire to use ClojureScript, but you'll certainly understand its basics, and at least then you're forming an informed opinion of it. And this is largely attributable to Sierra and VanderHart's lucid writing -- there is something about Clojure that makes "technical writers" into "better writers". To borrow from Fogus and Houser: it could be because "Clojure changes the way you think!"[^8]
[^1]: The best source I could come up with to back up my point was on Dr. Axel Rauschmayer’s blog. But how much source material do you really need for fun little bits of apocrypha anyway?
[^2]: Or at the very least, it was “Lisp-like�.
[^3]: I wonder: if JavaScript had been a Lisp all along, would we be having the whole conversation at all?
[^4]: Though it might help to have done a couple of the .
[^5]: You could read it in a day, but I’d suggest taking your time, and really letting it sink in. Make it two days.
[^6]: That being said, I really felt like the book could have used an appendix or a quick reference for some of those core language features. Not every book out there needs to be Flanagan’s JavaScript The Definitive Guide (with its hundreds of pages of appendices and dictionaries and references�) � but it’s helpful to get a bookmarkable section like that. (Hmm� what does disj do again�?)
[^7]: Especially when you’re going to call an object (i.e., {}) an “associative array�. That’s a dangerous word in JavaScript land. (I’ve heard them called “objects� and “maps� and “hashes�, but there’s no such thing as an “associative array�.)
[^8]: I wasn’t sure how else to fit in this point, so I’m going to jam it in with this footnote: the real coup in this book, the real “magical moment� was when I got to their discussion of how ClojureScript uses as a way of deliberately and purposefully dealing with JavaScript’s otherwise clumsy notion of state as mediated through its global scope. It was like some bright light shone down from the sky and paved the road to enlightenment with parens. That alone is worth the price of admission.
----
Disclosure: I received an electronic copy I the book in exchange for writing a review....more
In Clojure Programming (Chas Emerick, Brian Carper, and Christophe Grand; O'Reilly, 2012), the preface asks Who is this book for? It's for a lot of peIn Clojure Programming (Chas Emerick, Brian Carper, and Christophe Grand; O'Reilly, 2012), the preface asks Who is this book for? It's for a lot of people: experienced JVM developers, curious Rubyists, dissatisfied Pythonistas... Developers of all stripes that are looking to get introduced to, and become proficient in, Clojure. I myself have been circling the Clojure drainpipe for a while now, very nearly getting completely sucked in on numerous occasions. I've followed no one's advice though--I have not started small, and instead keep jumping into sophisticated middle parts and getting mired. [1] I think I would have benefitted from this book a year ago; I'm certainly benefitting from it now.
At 587 pages [2], Clojure Programming is hardly a tome, but it is comprehensive, appreciably thorough, and makes a concerted effort to be accessible to the Clojure and JVM neophyte. That being said, the book is also far from short, and makes no pretenses about easing you into the language: you'll be programming a naïve REPL by the end of chapter one. But this head-first approach is one of the reasons to love this book.
Emerick et al. found an excellent format for organizing the book, logically sequencing the material, and peppering chapters and sections with the right kind of illustrative, koan-style sample problems, eschewing the alternative of walking you through some contrived and over-arching application built one concept (and thus one chapter) at a time. As such, the book is broken into five sections:
1. Functional Programming and Concurrency (the foundation); 2. Building Abstractions (the sophisticated stuff); 3. Tools, Platform, and Projects (the eco-system); 4. Practicums (Clojure in the real world); and 5. Miscellanea (other important stuff).
What's marvelous about this structure is that you can decide for yourself whether to read it cover-to-cover, or whether to cherry-pick just the chapters relevant to your immediate challenges. What's helpful is that the book cross-references itself for many key concepts. In the thick of chapter one and you don't know what this "classpath" nonsense is? Jump ahead to chapter eight! [3] Deep into chapter nine and you're lost about how Clojure protocols relate to Java's interfaces? A footnote steers you back to chapter six! The care taken to create these kinds of cross-references is tremendously valuable because it allows you to opt-in to some advanced concepts early on, getting a preview of the powerful features ahead of you.
Though Clojure Programming is overflowing with thoughtful, detailed, and well-composed information, where it really shines is the "Practicums" section. When I first started skimming the chapters in this section, the first thought that occurred to me was: "Herein lies the true esoterica." I read about Clojure's numerics and mathematics, about its intriguing use of "rationals", about unchecked operations. I read about how to idiomatically implement different design patterns in Clojure. The deeper I got into this section though, the more that I realized that this was not a bunch of "out there" riddles and puzzles whose only purpose was to show off the sparkling fringes--no, this section was to demonstrate Clojure's solutions to "real world" problems, and the kind of advantages afforded you by its functional style. [4] That being said, I appreciated how Emerick et al. were vigilant in observing when different approaches or language features would serve you well, and when you would be wise to avoid them.
A few other items that I feel compelled to point out:
� The chapter on Java and JVM interoperability is strong. Anyone looking to introduce Clojure into their (JVM-based) organization would be wise to memorize this information... � ...and then also memorize the chapter that specifically addresses how to go about introducing Clojure to your organization. � As with the other Clojure texts I've read, their is a focus on discussing "idiomaticity", and differentiating between "working" or "valid" Clojure code, and idiomatic Clojure code. Seeing this again makes me wish that more authors writing about other languages put this much emphasis on idiomatic style. � Also, I am filled with tremendous gratitude that Emerick et al., when they cite Wikipedia at all, cite particular articles as "a jumping off point" or as "a surprisingly good resource" for the subject matter. I have read several books recently that cite Wikipedia as an authoritative reference and... Well, I find that to be in bad form.
I find it easy to recommend Clojure Programming to anyone with an interest in the language. There is enough "introductory" material that smart programmers will be guided in the right directions as they get started, but there is also enough detailed coverage that the book will grow right along with you. The chapters on the Clojure eco-system will help to steer you toward the right tools and resources to organize, manage, and scale your projects--as well as how to integrate them laterally within the JVM. Lastly, the practicums give you concrete and balanced approaches to answering some of the questions that you go into the whole endeavor already asking. I will be referring to this book often as I continue my explorations into Clojure.
------
[1] Case study: the first significant chunk of time I spent with the language was with early drafts of The Joy of Clojure. JoC is definitely an "intermediate-to-advanced" book.
[2] Not counting the preface and index, which brings that up to 630.
[3] Which, I'd like to add, is currently my favorite semi-layman's explanation of the JVM's classpath.
[4] I suppose this should have been obvious from the name of the section. (What can I say? I got caught up in the details of rational numbers.)
------
Additional side notes:
1. I received a free electronic version of this text from O'Reilly in exchange for a review and a blog post.
2. At the time that I wrote this review, I had fully read chapters 1-5 and skimmed the remainder--paying particular attention to the JVM interoperability, "Introducing Clojure into Your Workplace", and the "Practicum" chapters (which I guess really is most of the rest of the book)....more
I like the idea of this book more than the book itself. Granted, Tate took on a daunting task: how do you introduce seven divergent languages with sevI like the idea of this book more than the book itself. Granted, Tate took on a daunting task: how do you introduce seven divergent languages with seven divergent styles and seven divergent intents in the space of one book? The mission is a good one at least: introduce apprentice or journeyman programmers to a diverse array of programming languages and styles to help thing break out of their comfortable little already-known toolkit.
The approach is at least a half-way decent one: introduce a language, give three days worth of lessons (plus homework) and then use that to bridge into the next language/style.
But it also comes across as very surface-level. Tate even comes right out and says in many instances that he is just barely scratching the surface of each language, that he is giving some language feature a barely cursory overview, or else leaving it out all together. So you wind up with your appetite whetted but without any satisfying take-away knowledge (e.g., my experience here with Scala and Clojure), or else you're turned off to that language all together (e.g., my experience with Io and Prolog)....more
In the realm of technical, programming-related, computer science-type books, The Joy of Clojure is a bit of an oddity. And this is a very good thing.
WIn the realm of technical, programming-related, computer science-type books, The Joy of Clojure is a bit of an oddity. And this is a very good thing.
WHAT THE BOOK IS NOT:The Joy of Clojure is not a beginner's introduction to the language. The Joy of Clojure is not a glorified appendix of methods and syntax. The Joy of Clojure is not a "cookbook" or a "how-to" or an "FAQ". The Joy of Clojure is not an explanation on how to shoe-horn your Java code into (some (graceful [parenthetical syntax:])). The Joy of Clojure is not a dry or sterile technical manual.
WHAT THE BOOK IS:The Joy of Clojure is as much a philosophical text as it is a survey of the language. The Joy of Clojure embraces the language's own flexible nature and describes itself in that way. The Joy of Clojure has a sense of humor. The Joy of Clojure expects a little work from you (but is willing to lend a hand along the way). The Joy of Clojure respects the baggage that you bring from your other programming languages, but expects you to check those bags at the door. The Joy of Clojure wants to make you a better programmer, not a Clojure programmer.
So... why 4-stars? I seldom give out 5-star reviews—I reserve those for books that completely blow my mind. While this one was a real eye-opener, my lid did not pop fully and totally off. Why not? Partly because I'm coming into Clojure as an outsider. It isn't a book for Clojure beginners—you could be a Clojure novice and get a lot out of this book, but I believe you would need a little more background in Lisp (its syntax can be a bit off-putting to outsiders and novices... and they even come out and say this in the book). How to get that 5th star...? A "chapter 0" for the complete novice? or maybe an appendix that can help that novice wade through some of the more esoteric-feeling elements of the language.�i.e., folks such as myself that are unfamiliar with Clojure (and/or Lisp in a more general sense [viz., I haven't looked at/used Lisp in probably... 10 years?:]) may find the language's syntax a bit... opaque? oblique? There's a learning curve with every language, I suppose but there are certain things in Clojure that look FUNDAMENTALLY WRONG to someone accustomed to a language like JavaScript or Java. The onus is (of course) on the reader to embrace these things (i.e., "Who is the one that opened the book and wanted to learn something new?") but it's sometimes easy to get lost in these little details.
I would absolutely recommend this to anyone I know that had an interest in Clojure and/or functional programming....more
Loading...
