#52WeeksOfCode Week 29 – Clojure

Week: 29

Language: Clojure

IDE(s): NightCode

History (official):

(From the official Clojure home page)

Clojure is a dynamic programming language that targets the Java Virtual Machine (and the CLR, and JavaScript). It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language – it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.

I hope you find Clojure’s combination of facilities elegant, powerful, practical and fun to use.”


History (real):

That was the equivalent of a marketing release for Clojure. In other words, it’s targeted at the ‘suits’. If you want the sales page for the technical crowd, see the Rationale page.

I have no personal animus against Clojure. Today was the first time I had heard of it. But I have to say that my first thought was “What? You mean I can at last combine the terse, unreadable code of Lisp with the performance hit of running Java? Sign me up!”

Of course, the true story is more complex.

One of the strengths of the Java platform is the Java Virtual Machine (JVM). A Java program compiles to bytecode which runs on the JVM. The JVM gives Jave its portability between operating systems. Microsoft’s .NET language followed suit with the CLR (Common Language Runtime).

Another advantage of the JVM, however, is that Java bytecode is an open, documented standard. That means that you can use any programming language you want to write Java applications, as long as you can compile your language to produce bytecode. Examples include Jython and JRuby that let programmers write Java programs in Python and Ruby, respectively.

Clojure lets programmers write in Lisp and produce code that can easily integrate with Java and code that uses Microsoft’s .NET framework. It can also connect to JavaScript libraries like Node.js for Web applications.

This is a cool idea. Scripting languages do make for faster prototyping and development and bytecode compilation does improve performance a bit (but not as much as going all the way down to machine code).

But why Lisp for scripting? Let’s ask the creator of Clojure, Rich Hickey. From the Clojure Rationale page:

Why did I write yet another programming language? Basically because I wanted:


  • A Lisp
  • for Functional Programming
  • symbiotic with an established Platform
  • designed for Concurrency


I think the third feature is the important one. We already have multiple dialects of Lisp. Erlang is a functional programming language that supports concurrency. But neither of these can integrate so easily with existing code as Clojure.

I think that if I had a complaint, it would be that the scripting language was based on Lisp. But that’s my own personal discomfort and unfamiliarity with functional programming and not meant to diminish Hickey’s accomplishment in any way.


So how do I get started coding in Clojure? After a bit of research, I found that writing the code was easy enough but a real Clojure project involves keeping quite a few metaphorical plates spinning. Managing all of the files, code dependencies and project details can get hairy very quickly, particularly if you work from the command, which is the bare-bones Clojure install default.

There is an existing tool, make, which can handle code projects but it’s finicky to configure. Java has similar project management issues which are handled by a tool called ant. Fortunately some contributors to Clojure created an automation tool named leiningen. It works so well that it’s become the default tool for working with Clojure projects.

I didn’t feel like working from the command line (again) so I searched for a nice IDE for my first Clojure project. There are Clojure plug-ins for popular Java IDEs like Eclipse, NetBeans and Intellij but I wanted a program that was built specifically for Clojure.

Enter NightCode. Not only was it written for Clojure projects, but it was written in Clojure. I felt this showed admirable brand loyalty so I grabbed a copy. The interface is pretty bare-bones:

NightCode on first startup

NightCode on first startup

I only have three options: Create a new project, import an existing project or run code interactively in the little interpreter window on the lower left. This is a pretty neat feature because you can jump out of your current project, quickly test out some scrap of code to make sure it works the way you think it does and then paste it back into your main source file without leaving the IDE. Very nice:

NightCode interactive shell

NightCode interactive shell

I created a new project and after giving my project a name was presented with a list of project templates:

NightCode template selection

NightCode template selection

I like templates. They let me get on with my life.

I picked Console and selected Create Project.  In a few moments my first project was ready to code:

A simple console application project

A simple console application project

I have a few more options now. One thing I noticed were the options Run, Run with REPL, Build and Test. Since Clojure is a scripting language, it’s possible to run code without actually creating an application. Run with REPL runs your code interactively which is useful for debugging. Test checks your code for logic and syntax errors. Build, of course, creates the standalone software application. It’s still a very sparse interface, but it looks like you could do some non-trivial projects in this IDE. Not bad for free software.

On to my trivial project. The console project template is a standard “Hello World” so I use it to take both Clojure and NightCode for a spin.

Here’s the code, in case you’re curious:

Hello World in Clojure

“Hello World!” in Clojure

I’d like to test my code before running it so Test automatically inserts test code into my program, compiles and runs it:

Automatic code testing

Automatic code testing

Selecting Run gives me this:

Running my code

Running my code

Run with REPL loads the code and drops me into an interactive shell:

Running interactively with REPL

Running interactively with REPL

Now I’m ready to create my standalone application with Build:

Building a standalone application

Building a standalone application

Clojure is a unique, versatile language and NightCode gives me enough tools to handle non-trivial projects with confidence.

#Review – The Practice of Programming

In a world of enormous and intricate interfaces, constantly changing tools and languages and systems, and relentless pressure for more of everything, one can lose sight of the basic principles— simplicity, clarity, generality— that form the bedrock of good software.

Kernighan, Brian W.; Pike, Rob (1999-02-09). The Practice of Programming (Addison-Wesley Professional Computing Series) (p. ix). Pearson Education. Kindle Edition.


Programming is a craft. Some programmers refuse to acknowledge this, insisting instead that it’s a scientific or engineering discipline. There are certainly elements of that but anything that allows a human to place their own distinctive style on a made thing is a craft.

Bridges look a certain way because that’s how the physics make them look, not because the engineer was feeling whimsical that day. That’s why one bridge looks a lot like another. When a carpenter makes a bookshelf, it shares the same functionality with other bookshelves. However, there are a hundred individual decisions made by the carpenter during the design and creation process. A bookshelf is physics seasoned by art.

Two software applications may have similar functions but the underlying source code tells a different story. Anyone who reads or writes code knows that the programmer imposes their own personal style on the code in hundreds of different ways. From the use of a favorite decision loop to the design and implementation of a particular data structure, programmers have always found a way to express themselves in their work.

The Practice of Programming was written to bring programmers who are swimming in complexity back to their roots and help them regain perspective. Just to be clear, this is not a book that will teach you how to program. However, if you are learning to program or even if you’re a veteran coder, you’ll get something useful out of this text.

Despite this, Kernighan and Pike don’t romanticize the work of programming. Instead they show that by embracing (or re-embracing) the fundamental principles of coding, you can become a better, more productive programmer.

They start with a style guide, because clean, consistent code is easier to read, debug and maintain. Establishing and maintaining a consistent coding style frees up your higher brain functions for more complex decisions and problem solving.

Next we move on to algorithms and data structures. These building blocks of software should be familiar to all coders but the right algorithm choice can make the difference between a program that takes an hour versus one that takes seconds to produce the desired result.

The authors build on this foundational knowledge with discussions on design, interfaces (how to efficiently pass data), debugging, testing (which reduces debugging), performance, portability and end with a chapter on notation which includes a discussion of tools that will help you generate code automatically.

The writing is crisp and direct. Kernighan and Pike speak to you, programmer to programmer. They have decades of combined experience in the coding trenches and understand the problems you face every day, whether you’re doing an assignment for school or creating a business analytics solution for your business.

#Book Review – Code Reading

The reading of code is likely to be one of the most common activities of a computing professional, yet it is seldom taught as a subject or formally used as a method for learning how to design and program.


Aspiring writers are always told to read as much as they can if they want to become better writers. As Dave Thomas points out in his foreword to Diomidis Spinellis’ Code Reading, aspiring programmers almost never get this advice. By code, of course, I mean the program source code, the fundamental recipe for any piece of software.

Imagine that you’re taking a writing course. You get assignment after assignment – persuasive essays, memos, poetry, research papers or prose. Now imagine that you have to do every one of these assignments from scratch, without any examples. You have to work everything out yourself.

This is the traditional method of teaching programming. I know because I used to teach programming classes.

Code Reading is both refreshing and an eye-opener. Not only does Spinellis present a solid case for the habit of reading program source code, he also fills his book with code examples, complete with commentary. Though the examples are mainly from Java and C, the lessons learned can be applied to any programming language.

Just to be clear, the code presented is not from the toy examples found in programming textbooks. This is material from real, working software projects. The book covers major programming topics and even includes analysis of a complete, working program. Spinellis gives tips and techniques for the novice code reader to aid them in developing their skills.

From my own experience, reading code can be very educational, even entertaining. Every programmer tries to put their own personal stamp on their work and part of the fun is seeing the human mind behind the algorithms.

For example, I was teaching game software development and wanted to get my students some practice in reading code. We downloaded the source code for BZFlag, a tank game based on the video game BattleZone combined with Capture the Flag. It’s a fun, cross-platform game that you can play solo or over the Internet with teams.

There was one particular feature in which I was interested. During play, you can set your tank to AutoPilot mode and let it play for you. This makes a nice change from having to pause your game whenever you have to get up and take care of business.

We grovelled through the source code files for a bit and I finally found the sections having to do with AutoPilot. As I read them, I spotted some code that looked very intriguing but was never actually called by any other part of the program. It looked like someone was trying to build a heuristic system for the AutoPilot mode. In short, it was meant to have the program build a solution starting with the goal and working its way backwards. It was very clever and had a lot of potential. I could add see why it hadn’t been  implemented due to the inherent complexity of the method.

The fact that the code was just left there, unfinished, was fascinating. When I saw that code, I put myself in the mind of that programmer. I’ve also had coding ideas that got stuck in blind alleys. But here was someone like me, trying to solve a problem in an interesting way and failing that, leaving a note for the explorers to come after in hopes that they would ultimately succeed where he did not.

This book shouldn’t just be on any programmer’s reference shelf, it should also be the basis of at least one undergraduate programming class.

Spinellis, Diomidis. Code reading: the open source perspective. Addison-Wesley Professional, 2003.

#Review – The New Hacker’s Dictionary

bogosity /boh-go’s*-tee/ n.


  1. [orig. CMU, now very common] The degree to which something is bogus. Bogosity is measured with a bogometer; in a seminar, when a speaker says something bogus, a listener might raise his hand and say “My bogometer just triggered”. More extremely, “You just pinned my bogometer” means you just said or did something so outrageously bogus that it is off the scale, pinning the bogometer needle at the highest possible reading (one might also say “You just redlined my bogometer”). The agreed-upon unit of bogosity is the microLenat. 2. The potential field generated by a bogon flux; see quantum bogodynamics. See also bogon flux, bogon filter, bogus.”


I love words. I’m always looking for new phrases and jargon, the more evocative the better. After I read Steven Levy’s Hackers, one of the things that stuck with me was how this group had developed their own language.

Every field of expertise has its own jargon. For hackers, though, English is just another programming language, just with looser rules. It’s a system. Hackers explore and manipulate systems, either to achieve a specific goal, see what happens or just to have some fun.

The New Hacker’s Dictionary originated in 1975 at Stanford as a simple file maintained by Raphael Finkel, collecting hacker jargon from various branches of the community. Like any language, ‘hacker-speak’ has dialects. The file was copied around the community, each group adding their own entries to what was becoming a shared history of the hacker culture. Eventually it was collected and published by M.I.T. Press and that’s when I got my hands on a copy.

Normally you don’t read a dictionary for fun, but this one is different. It’s a snapshot of a period of time that transformed not only my own personal and professional life but that of the world.

Consider this. The year the Jargon File was created, the very first personal computer was offered for sale.

It was the MITS Altair.

It came with 256 bytes of memory (expandable to 64K), had no keyboard or monitor and a single data bus. You had to key in your programs in low-level assembler code by flipping switches on the front panel one word at a time.

It sold as a kit for $297 (the case was extra).

Oh, yeah, I almost forgot. Microsoft got their start licensing software for the MITS Altair.

The year the Jargon File was finally published, more email was sent than postal mail in the United States and an IBM computer named Deep Blue became the first machine to beat a chess grandmaster.

The book includes a pronunciation guide, a guide to hacker writing and speaking style, a section describing hacker folklore and a guide to ‘J. Random Hacker’, which serves as a sort of spotter’s guide.

The words and phrases themselves range from layered and complex to playful and the book includes cartoons by Guy L. Steele, co-author and noted computer scientist.

Reference: Raymond, Eric S. The new hacker’s dictionary. Eric S Raymond. M.I.T. Press, 1996.

#Review – The Mythical Man-Month

“There is no Silver Bullet.”

In 2008 IBM did a study of large IT projects that showed that nearly 60 percent of them fail. For the majority of these, the problem was people.

This isn’t news.

In 1975, Fred Brooks published The Mythical Man-Month based on his experience as an IBM project manager and as a world-class computer scientist and software engineer. It detailed the multiple reasons for the high failure rate of I.T. projects and proposed solutions.

I bought my copy in the early 90’s. I was working at AT&T doing I.T. support and I was volunteered for an I.T. rearchitecture. It was a large project, involving the re-design of an entire call center and included hardware and software upgrades as well as business process re-engineering. It was my first project and I wanted to know more about this process so, as I usually do, I bought a book.

The title comes from the then-standard practice of measuring the size of a job. So if I estimated a particular project at twelve man-months, that would mean that one man could do it in a year, six in half a year and if you gave me a team of twenty-four I’d finish it in two weeks.

The problem, Brooks proposed, was that while the man-month is a good estimate for project cost, it’s terrible for measuring the time and resources needed to complete the task. As he himself put it:

The bearing of a child takes nine months, no matter how many women are assigned.

Despite the complexity of the topic, The Mythical Man-Month is surprisingly readable and contains valuable insights culled from Brooks’ decades of experience. He details how to assemble a successful project team, best practices for inter-project communications and how to manage project documentation. The book was reprinted to celebrate its twentieth anniversary and, with some modifications to allow for technological change it’s still relevant today.

Reference: Brooks, Frederick P. The mythical man-month. Reading, MA: Addison-Wesley, 1975.

#Review – The Art of Unix Programming

There is a vast difference between knowledge and expertise. Knowledge lets you deduce the right thing to do; expertise makes the right thing a reflex, hardly requiring conscious thought at all.

I was introduced to Unix in 1986. I was working at AT&T as a communications technician and my operations manager had just gotten hold of three 3B2 minicomputers. I was tapped to do something useful with them. So I bought a copy of Unix System V Bible, plugged a serial terminal into one of the 3B2s and started learning.

I still have that book, by the way.

This was my introduction to Unix. It was also my introduction to the Unix culture, and the wider world of the Open Source software movement.

Eric S. Raymond is one of the most eloquent supporters of Open Source. His book The Cathedral and the Bazaar was a seminal work on the emerging information economy and the changing model of software development. As Cathedral was a work of philosophy, Raymond’s The Art of Unix Programming was about practice.

As I’ve said before, I’m not a professional programmer. I write code for fun and to build tools for other work. I teach programming. I blog about programming. I read about programming. These are just some of the reasons that Eric Raymond’s book has a permanent place on my bookshelf.

Another reason is that Raymond is a damn good writer. He’s engaging, passionate and smart without being condescending. This book is nominally about writing Unix programs but on a higher level it’s a treatise on software design. Raymond uses Unix as a jumping-off point to discuss the larger topic of writing good software.

It’s not about a particular programming language. You can write Unix programs in any language you like.

One of my favorite sections is “Basics of the Unix Philosophy” where he lays out the rules of design for good code. From the Rule of Modularity (“Write simple parts connected by clean interfaces”) to the Rule of Extensibility (“Design for the future, because it will be here sooner than you think.”), they all represent solid advice for designing code with any language on any platform. I’ve tried to incorporate these rules in my own code.

In addition to offering guidance for current and would-be programmers, there is a section on design principles, including Modularity, Textuality and Interfaces. Naturally, there are copious references to Open Source, including a discussion of software licensing and best practices.

But it’s not all sunshine and relentless boosterism. Raymond takes a clear-eyed look at the problems with Unix culture and problems in Unix design. Bonus features include a section called ‘Rootless Root’, a parody of Zen philosophy complete with Unix koans and copious examples of code demonstrating the principles that Raymond outlines the book.

The Art of Unix Programming is not just a good book for coders but for anyone who enjoys reading about the philosophy of design.



Raymond, Eric S. The Art of Unix programming. Addison-Wesley Professional, 2003.

#Review Hackers – Heroes of the Computer Revolution

Just why Peter Samson was wandering around in Building 26 in the middle of the night is a matter that he would find difficult to explain.

My first programming class was in 1977 at a local community college. What I took away from it was the idea that you could solve any problem, no matter how overwhelming, by breaking it down into smaller and smaller functional pieces, then reassembling the pieces into a solution.

The opening sentence to Steven Levy’s book Hackers: Heroes of the Computer Revolution neatly encapsulates the book’s theme. It’s about very smart people who are compelled to act in ways that are hard for them to describe to others and even sometimes to themselves. Some of them are looking for money, others for redemption,  On a higher level, it’s a book about exploration.  It’s about compulsion. It’s about obsession. It’s about passion. It’s about America.

It’s difficult to write about computers for a general audience. The problem is similar to what Hollywood faces when they use computers as a story element. Simply put, it’s hard to make typing seem interesting.

This is where Hollywood gets it wrong. Computing isn’t about the technology, it’s about the people.

A good technology writer understands this and Steven Levy is a very good technology writer. He was a senior writer for Wired magazine and chief technology writer for Newsweek. Hackers was his first book and it’s a very engaging read.

The story starts at M.I.T. in 1958 and takes us on a journey across the country and spans almost three decades. It describes a tumultuous time in our modern history, not just politically and socially but technologically. Levy takes us from the Tech Model Railroad Club at M.I.T. to the hardware hackers of the Homebrew Computer Club in Silicon Valley to the first computer game hackers and ends up back in Cambridge with the ‘Last of the True Hackers’. Along the way we see how what was once unimaginable became commonplace.

Most important to me, this book showed I wasn’t alone. I understood these people. They were flawed like everyone else but they had a passion and the skill to make the thoughts inside their heads into reality for the rest of us.



Levy, Steven. Hackers: Heroes of the computer revolution. New York: Penguin Books, 2001.