This doesn't mean cramming Clojure into every possible nook and cranny. In some environments it's easy to become persona non grata by introducing ANYthing which is perceived to be relatively difficult to find support for.

I will also not back down from my opinion that any programming language biased towards immutability should not be learned in production, especially a language with parentheses in uncomfortable places. I will claim that spending time with a Clojure REPL will lead to a series of quiet a-HA! moments... just not as predictably as needed in production.

So why care? Because those lusty, quiet epiphanies are really valuable. They are quick leaps towards a broader perspective on programming. One where the paradox of a high-level low-level language is put to good use. Don't take my word on it, check out what ESR says about Lisp.

As one of the proud 429 funders of Clojure, I encourage you to get started learning Clojure. Or, if you know some already then try to become a lord of the REPL.

Many thanks to the awesome @brweber2 for presenting a quick tour of labrepl.

Unless of course NOTEPAD.EXE is your thing... and who wants to go down the path of manually adding ))))))? Let an editor manage that for you!

Agents in Clojure are a high level concept for concurrency. They are intended for independent, asynchronous data munging. They're pretty easy to use... basically a value is associated with an agent when it is created, and then when a function is applied to the agent the result becomes its new value.

Here is the definition of a banana agent:

Here is the function which produces its new value:

Here it is in action:

The debug statements are missing! Code invoked by (send) doesn't yield output to the REPL -- it went to a different buffer.

The major symptom of my pernicious problem was that my precious debug statements weren't printing anything. This was a major problem since that was the only way I had to know what was happening. At this point it's important to disclose that I am an unrepentant GNU/Emacs user. This leads to using swank-clojure since a symbiotic REPL is really, really cool.

After much confusion I finally found my precious debug statements! They were hiding in the rarely-used inferior-lisp buffer. It's awkward for me to keep this buffer open so I looked for something... cooler.

Growl is a MacOS X utility which displays notifications in self-dismissing windows. The gap between Clojure and Growl is little more than implementing java.io.Writer. Clojure actually makes it easier than it should be.

It's worth taking a close look at the proxy statement, specifically the write method. It is an abstract, overloaded method in Writer. Only one of those overloads is abstract, and it's NOT the one implemented above. The one implemented above is the only one actually called. Or, you know, quacked. That's neat! I didn't even have to implement all of the abstract methods! All I had to do is what I actually needed to do.

The last piece of the puzzle was making Clojure use the Growl bridge. The binding function made this happen with one line of code. out is the "variable" which Clojure uses for writing to standard out. A call to (binding) gives out a new value. and the old value is restored when (binding) exits. All of the compiled references to out within Clojure automatically use my binding. TOO COOL.

Ta DA!

Clojure

• I continued to mature Pokerepl. The interfaces/defprotocols were reorganized into one file. Implementations/deftypes each have their own file.
• Switched Leiningen branch from stable to master (think 1.1 alpha) and chopped out all those :gen-class warts
• Lightly adopted @cemerick's very cool string interpolation macro -- it's the #{bar} in "foo #{bar}".
• Got Nailgun working to speed up unit tests.
• But @technomancy pointed out that I could use TONS less memory and have a better experience with clojure-test-mode. It runs instantly and highlights errors:

Emacs

• I~ stopped~ backup~ files~ from~ appearing~ everywhere~ (thanks to ESK for clueing me in to backup-directory-alist)
• Stopped avoiding color-theme finally. Using the rotor and late-night themes mostly, but will probably have to write my own at some point. It will be ugly, but such are my aesthetics.
• Now using and happy with the Inconsolata typeface.
• I installed but still shy away from paredit-mode. It's my own fault for not having watched this awesome preso yet.

I'm exploring the upcoming feature in Clojure called deftype. Similar to defining a class in Java, deftype is a way of grouping related data and methods. Actually, it's quite an improvement over the old (defstruct) way. defstruct only groups related data together.

As ever, code examples are based on my side project pokerepl. This entire post focuses on the suits and values in a deck of playing cards.

Here's the old way of doing things:

Here's my first baby step down the new path:

It's longer, but it does more. We get optional type hinting for the data (seen here as #^clojure.lang.Keyword). The type being extended is listed (Object in this case). The override of Object.toString means all instances will be pretty printed automatically.

What you don't see is a "constructor". There's no need because Clojure provides reasonable defaults here; the values for "value" and "suit" are passed to new instances of Card.

Unfortunately that wasn't good enough. Fortunately Clojure is a very dynamic programming language, so I could easily replace the implicitly defined factory function with my own code. To summarize, a call to (deftype Foo [bar]) generates two factory functions (Foo [bar]) and (Foo [bar meta-map ext-map]). It's possible to overwrite these but unclear how to honor the postconditions... exactly what gets returned?

So rather than replace the factory function entirely, I decided to embrace and extend it!

So that's a bit of a mess, but the requirements were too. I needed syntactical sugar to make dealing with this code palatable. And now I have said sugar. The following is now true:

My main gripe with (deftype) is that it complicates editor support. Previously, "defn" and a relatively small list of keywords meant a list was a function definition. Functions indent differently than other types of lists. deftype means the editor is going to have to understand the source better. But, it's a small and good problem to have IMO. Also hoping for destructuring support in vector for param arguments.

In the presentation I am going to spend most of my time explaining how to build a minimal yet friendly jar file starting from scratch. Time permitting we will be able to cover more spiffy features like integration with Clojars.

The other scheduled presentation is going to be great; @Fogus is co-writing the next Clojure book and he will be presenting on features new in version 1.1.

If you are in the Washington DC metro area and have any sort of interest in Clojure, run don't walk to register -- the first meeting is Thurs Jan 14th, 2010. See you there!

EDIT: also try rake clojure:new:repl

I am looking forward to trying datatypes on Pokerepl. However, that means using the new branch of Clojure, and indirectly, more work on my part to clone/track/build/deploy the new branch.

Almost everyone would and should use Leiningen to experiment with the new branch. Simply update your project.clj something like this:

At the moment though, updating ~/.clojure was beyond the ken of any automated tool I knew of. So I wrote a Rakefile and gave it a cheesy name... juggling Clojure... hmm... howzabout Clojuggle? Well... yeah... sorry for that.

Back to the point: automating thorough (~/.m2 and ~/.clojure) updates and deployments of various versions of Clojure. Supporting common tasks (wipe, clone, build, &c.) for several branches of several repositories means a thousand tasks will bloom and make the tool hard to use.

Ruby and the Rake API make it easy to define or show tasks only when relevant. I really enjoyed writing this code. Anyways, typing rake brings you to this:

The default task provides some basic usage. Let's take a look at the initial set of tasks:

Fine, let's give it a whirl.

Three subtle points here. First, the "ci-build" line is the clue that the local Maven2 repository was updated:

Point #2: the ~/.clojure directory has a symlink pointing into the clojuggle/src/clojure-new directory.

Point #3: a few more commands have surfaced from the Rakefile (e.g. clojure:new:update)

So that's all well and good, but what if you wanted to support Technomancy's fork of Clojure? You would do two things. First this:

And then something like this:

DANGER!

Do NOT use this tool to develop on various versions of Clojure. The wipe task always deletes files, so eventually you will lose changes unintentionally. Eventually 'git status' will be used to prevent wiping changes but not yet.

Penultimately, despite all this I still don't have the new branch working with Slime/Swank. It doesn't help that the pom.xml of contrib on the new branch wants 1.1.0-alpha of Clojure. Minor nits though that can be worked out.

Finally, if anyone is still reading and cares about these sort of things, I picked Ruby, v3 of the GPL, and Mercurial/BitBucket because I have strong feelings about those things.

Please respond in some way if you have any questions!

tl;dr: Leiningen is great -- try using it with the new branch of Clojure!

The asking price was very reasonable when you compare it to any large, respectable software development book. I have many of those (well, maybe not all 10 volumes of SOA in a nutshell)... but even my favorite books cover very narrow topics in great depth. That's it, just some dead trees waiting to be used as references for types of problems I don't run into often.

Clojure covers many topics in depth with consistent pragmatism. No time to bootstrap libraries? Use the plethora of .jar files out there. No time/focus to sustain a world-class virtual machine? Use Sun's! Not interested in churning out another keyword-heavy language grammar? Use Lisp... but thanks for cleaning it up first

The rest of the time can go writing a compiler sufficiently smart to avoid head holding by implementing fine-grained local clearing... add some high level concepts for concurrency via software transactional memory? Sure!

Another tangible reason I'm happy to pay real money is the Clojure community. It has been helpful in many ways. Every major editor has some level of support... the IRC channel is great. People are even building infrastructure (looking at you Leiningen and Clojars!)

Ultimately I'm just being selfish. Swearing at the REPL until enlightenment conks you on the head is a rush... it's a minor victory with a thousand similar battles on the horizon. I like supporting good projects and I'm looking forward to spending lots more time with Clojure.

Immutable data structures seem like an odd idea, but they are on the path of least resistance in Clojure. This is not the case in languages like Java. In this post I will rewrite a snippet of Java into Clojure and explain the major differences.

The snippet of Java comes from Martin Fowler's bliki posting on Fluent Interfaces. I picked this code snippet because it is concise, reads easily, and fills a common need.

This code clearly links an existing customer to a new, rush order of three items. Consider the "skippable" method... that is probably on the Order object yet works on an OrderLine. The Order code probably finds the newest OrderLine and updates its skippable property. Modifying objects is the path of least resistance in Java, or rather creating objects in an incomplete state and updating them until complete.

Modifying objects in Clojure is not on the path of least resistance. Many Clojure methods return a new, lazy version of the input. Working with return values like this encourages creating complete objects and then using them. Here's an example -- please temporarily ignore the unfamiliar functions and low level of abstraction.

• (struct foo 123 "abc") is basically calling the constructor for the foo class with two arguments.
• (struct-map foo :num 123, :text "abc") calls the constructor with named params rather than positional params
• (let) is how you define local variables, lines and order in the above example.
• (merge old-map new-map) creates a new map by merging existing maps
• (conj) creates a new collection from its arguments
• (get) returns the value for a key in a hash map, or a default value if specified.

It's not obvious but the return value is the output from (merge). That is the last statement in the (let) block, which is the only statement in the body of the (add-order) function. Values flowing like this is in the path of least resistance in Clojure.

Besides doing things in a different order than Java, there is one more very important but subtle difference. Let's say a customer wants two orders:

Some quick code to show how it works:

The new order has been lost because the return value from the function was not captured. This is a silent runtime failure -- not a fun type of problem to chase down. One solution is to rebind "me":

I've been a little dishonest here talking about "objects" in Clojure. As seen here they are little different than hash maps.

For anyone who is interested, the entire source listing for this example follows. Thanks for reading!