First Thoughts on Clojure
A lot of the buzz over the last year in programming languages has certainly been about Clojure. There’s a book about it that will be out soon, and as we’ve talked about over and over again, it’s got tons of fun features (and a lot of promise). However, it certainly seems to have a lot of quirks involved, so keep this in mind if you’re learning Clojure. Quirk #1: The ‘print’ function forces you to also call flush or there will be unintended consequences. For example, if you were to look at this code: You would expect to see this (for the input “foo”): But in fact, the “echo>” doesn’t get flushed out and instead, you see this: Thankfully, the kind users of Stack Overflow were able to recognize what was going on (while I completely failed to). If you use println there’s no problem, but since it prints a newline it may screw up the formatting. Thankfully, there’s an easy fix: This may end up getting added to the standard implementation of Clojure, but for now, keep it in mind if you use print. Quirk #2: This is more of a type system issue. While meddling in a game of golf, I tried to generate and sort a list of 100 random values. The first try looked like this: However, if you do this, enough of the values will be greater than Java’s max value for an integer and thus get set to Java’s max value, resulting in a very non-random result. For now, you’ll either need to use a larger data type than an Integer, or: Quirk #3: Running Clojure in the first place. It’s possible to run Clojure in two different fashions, “java -jar clojure.jar” and “java clojure.lang.Repl”. They both seem to work fine, and since the first was easier to remember, I just stuck with that. However, if you do it, it seems to screw up the classpath and it’s not possible to use the community contributed libraries (clojure-contrib). Using the second method works fine, so keep that in mind most of all! It’s a pain in the ass to have none of your libraries working just because of something dumb like that. Quirk #4: The REPL is still young, and lacks many of the features of Ruby’s REPL that I’ve come to love. You can’t hit the arrow keys to go back and forward in your typing (nor up and down to re-enter old commands), and you don’t have tab-completion. This is the only real quirk that there’s no fix for right now, but hopefully as Clojure matures the REPL will get these features. Despite these quirks, there is a pretty cool feature about Clojure’s REPL that I have yet to see in Ruby: loading methods from a file (and reloading them) on the fly. You can type some functions in a file, and use the “load-file” function to place them all in the REPL’s namespace. This is a pretty awesome testing feature and really makes the REPL stand out. So as usual, give Clojure a try if you’ve got some downtime and see how it works for you.(defn goo []
(print "echo> ")
(def resp (read-line))
(print resp))user=> (goo)
echo> foo
fooniluser=> (goo)
foo
echo> foonil(defn print-flush [string]
(print string)
(flush)
)(defn gen-rands []
(sort (take 100 (repeatedly #(rand-int 9e9)))))(defn gen-rands []
(sort (take 100 (repeatedly #(rand-int Integer/MAX_VALUE)))))
My Argument for Clojure
Clojure has a lot of buzz around it as of late, and I think it’s important to understand why. Thus, my argument for Clojure is as follows: We need a programming language with three notable features: Protocols that the web rely on such as DNS and HTTP are only implemented with such efficiency because they are essentially stateless. By default, Clojure forces statelessness upon the user’s program, although mechanisms are provided to perform side-effects (e.g., agents). Furthermore, transactions must be side-effect free (although I don’t see any obvious way that Clojure enforces this like Haskell does). A possible downside of Clojure is the complexity of STM, and we must assess whether this complexity is sufficiently greater than using locking to negate the benefits involved. I also seek to evaluate the writability of the language, as it does not immediately appear to be as writable as Ruby. How much they differ is a pressing concern since we aim to pick a language that is relatively siple to grasp as far as readability, writability, and maintainability are concerned. A slight loss in any of these is certainly warranted if the claim that Clojure “solves” the concurrency problem is valid. That being said, I’m pretty excited about Clojure. Check out the official rationale for Clojure and more interestingly, their argument about Clojure and state.
Programming Clojure, Beta
Clojure, Clojure, Clojure! All the time now I’m writing about this funny weird programming language with the interesting name! It’s a bit different than your run-of-the-mill language, both to it’s credit and against it, but shows promise thus far. So you bet that the minute the beta for Programming Clojure came out I picked it up. With that in mind, let’s see how it fares. Let’s begin by saying that this will not be the big Clojure v. Ruby v. Java post I had hoped for, since I don’t yet have enough Clojure experience to really rattle off about it in the way we did earlier with Ruby v. Java. That may be better since it gives us a better look at the book itself rather than the language. So the book is a “Beta Book”, which essentially is the book form of episodic gaming. You get the book way before it comes out to the general public but it’s got errors and stuff missing and your input has some impact on how the whole thing turns out. At the moment the book is about half done, which is fine for satiating my Clojure interest that has possessed me over the last few weeks, and the errors are relatively minor (and the errata covers it pretty well). With that in mind, append the words “thus far” to the end of every sentence, since this presumably could (but likely won’t) change radically once the book is released. The main reason I’m into Clojure is their approach to solving the concurrency problem: software transactional memory. My first exposure to STM was Haskell, but for some reason it just didn’t really catch on for me. So here’s round two with Clojure! The chapter in the book about this is relatively well fleshed out but not all the code examples are there yet, so I’m delaying my verdict on STM for later. But the book does a good job of touring Clojure’s STM thus far and hopefully it only gets better. The book also does a good job of showing you every alterative you have of doing a particular task and then telling you which way is the Clojure way. That was particularly useful to me since in Clojure, there seems to be a billion ways to do anything you feel like (syntactically and sematically). The examples are also pretty straightforward and get the point across well enough. The big thing I got excited about when I saw the table of contents was the Monte Carlo simulation for approximating pi, which was a bit of a downer when I later learned that that chapter wasn’t ready yet. It was a double downer when I got to the Concurrency chapter and it’s talking about running the simulation, for which we don’t have the code for. But again, that’s a “thus far” thing. That will be addressed and will go away with new releases of the book, and it’s cool to see it in the first place. It’s my first beta book, and I can say I like it. The only thing I could possibly recommend would be some sort of diff-like mechanism that accompanies the beta books, since when I got the Beta 2 release, I had no idea what had changed since Beta 1 and just skimmed the whole thing to see what was changed. The big changes are obvious (e.g., new chapters or subsections) but the little changes (e.g., technical errors) were things I was only aware of by following the Clojure Google Group. So I’ll keep fiddling with Clojure and hopefully in a little while we’ll have a fun comparison to whine on about. Since that’ll be a little while, I’ll try to talk non-Clojure in the meanwhile and balance things out.
Dabbling in Clojure
As previously promised, I picked up the beta edition of the upcoming Programming Clojure book and have been reading it with varying levels of excitement. For those of you too lazy to click on that link and read the selling points on Clojure (of which are very tantalizing for me), it can be summarized as the following: it runs fast and has access to all of Java’s libraries. Awesome. I originally got the idea to re-read the classic Structure and Interpretation of Computer Programs (SICP, a.k.a. the Wizard Book) using Clojure instead of Scheme, but apparently others on StackOverflow have already had this idea. Furthermore, several bloggers did this back in March. Boo hoo for my now-obvious unoriginality. However, that does give some interesting reading material for those who don’t want to jump right into Clojure just yet but want to quickly see what others have done first. If you don’t feel like reading, you always can go the video route (if you have the time). The creator of Clojure, Rich Hickey, has a few videos online that you may find good viewing as well. Check them out, but be warned, they are incredibly long (the first is 90 minutes!) Once I finish through the first beta of the Clojure book, we’ll come back and look at Clojure in more detail. We’ll see if it delievers on its promises and how it fares against current site favorite Ruby and previous champion Java. Stay tuned!
"Programming Clojure" Looks Intriguing
I’m an avid fan of the Pragmatic Programmer series of books, which is incredibly obvious to anyone who regularly reads this blog (which at this point is really just me). So they happen to have a ton of books that involve getting done what you need to get done in the least amount of time while keeping good maintainability and such. This has been the main motivation for me to get a lot of books they put out. But I stumbled across a new book entering beta soon that looks positively intriguing: Programming Clojure. Clojure is a language I ran into a while ago while looking at languages that run on the JVM. It essentially is Lisp on the JVM. And this is a sufficiently interesting combination of languages when you think about it. Contrast this with Scala, which really feels more like a natural advancement to Java. It’s lighter on the syntax and infers types pretty well most of the time and is way less verbose (my main complaint with Java). Clojure is a totally different beast. Clojure is a dynamically typed language (versus Java/Scala’s static typed) and is based on a language that has a weird long history. Lisp pioneered many language features that were really way ahead of its time (dynamic types, garbage collection, and many others) and are really only gaining traction now. But I’m hoping the Clojure book will be different from what I’ve seen before. I’ve read SICP and just didn’t really get into Scheme. For a week I was all about it, but while the book was great, it really way just too stuck in abstraction-land. Don’t get me wrong. I LOVE ABSTRACTION. It’s the core of computer science, and if you can’t abstract then you can’t do computer science. Period. But I never found out how to do useful things in Scheme. I never found out how to read from a file and write to it. I never found out real-world examples of how Scheme would make my life easier. I thought it was really cool how Scheme made you think and program but just couldn’t get work done with it. Contrast this with Ruby, where I like how it makes me think and I get an anomalously high amount of work done in it. So I have high hopes for Clojure. It seems to combine the cool abstraction powers of Lisp with the “actually gets work done” of Java. And yes, I am obviously aware that people have been getting tons of work done in Lisp for the billion years it’s been out. It’s just that the reference book of the gods on it didn’t seem to really touch on it that much and for some reason it never really clicked to me to go look it up (obviously my bad). The page on the book also claims to talk about software transactional memory, which sounds pretty interesting, and claims that Clojure is as fast as Java, which is also pretty cool. Rest assured that when the book goes into beta I’ll be one of the first to pick it up and talk about it, and hopefully it lives up to expectations.
