A few months ago, I had mentioned that I was planning to learn a Functional Programming language. In that blog post I listed out the different functional languages I was looking at and outlined my thought process for picking one of them. I picked Clojure.
Was that a good decision? No. It was a great decision. (Pardon the corniness.)
I have learned more while programming in Clojure than while programming in any other language since I first learned C some 12 years ago. Alan Perlis once said: “A language that doesn’t affect the way you think about programming, is not worth knowing”. Amen.
Over the last decade, I have dabbled in several programming languages including C, C++, VB, C#, Java, Perl, Python, Ruby… Now, these are all more similar than they are different. I know, you won’t truly believe that statement unless you’ve some experience with a language which is drastically different from them; ignorance is bliss. Clojure is different. Very Different. Very.
So different indeed that I have taken more time to become sort-of-comfortable with Clojure than I have ever taken to reach the same state for any other language I’ve learned. Being homoiconic, Clojure actually has very little syntax. But the problem lied in retraining my OOP-corrupted brain to think functionally and in getting comfortable working with immutable data structures.
Luckily, SICP rescued me. (SICP stands for Structure and Interpretation of Computer Programs. It is one of the most legendary books in the history of Computer Science. That many people I talk to in India have never even heard of it tells a sad story about the state of Computer Science education here.) Quite simply, it is the best programming book I’ve ever read. And I’ve only read — and worked out the exercises of — the first chapter (there are only five chapters in all.) SICP uses Scheme (a Lisp dialect) as the language of instruction, but it is quite trivial to translate the programs to Clojure. Although, SICP is not teaching a programming language, it is teaching programming. Big difference. Take a moment to think about that. I highly recommend you read at least the first chapter of SICP, whether you care to learn to program in Lisp or not. If you’re in India, you can order a copy of it from here (the book is also available as a free download from its website.)
Now I’ve reached a stage where, when I’m programming in any other language — even Ruby, the most beautiful of all the other languages I know — I feel as if I’m doing it wrong. All wrong. I’ve slowly but surely started to apply some of the concepts I’ve learned while programming Clojure when programming in other languages too. See Alan Perlis’ quote above.
I’m working on a couple of open source libraries in Clojure, which I hope to announce soon. Almost all of the weekend hacks I do these days are also in Clojure. I’m addicted!
I’m planning to blog some adventures and neat tricks I’m conjuring up using Clojure. If you are interested, you can subscribe to all my Clojure posts.
I’ll end this with a few interesting quotes from SICP:
The acts of the mind, wherein it exerts its power over simple ideas, are chiefly these three: 1. Combining several simple ideas into one compound one, and thus all complex ideas are made. 2. The second is bringing two ideas, whether simple or complex, together, and setting them by one another so as to take a view of them at once, without uniting them into one, by which it gets all its ideas of relations. 3. The third is separating them from all other ideas that accompany them in their real existence: this is called abstraction, and thus all its general ideas are made.
John Locke, An Essay Concerning Human Understanding (1690)
This is the preamble to chapter 1. “Programming is abstraction.”
We are about to study the idea of a computational process. Computational processes are abstract beings that inhabit computers. As they evolve, processes manipulate other abstract things called data. The evolution of a process is directed by a pattern of rules called a program. People create programs to direct processes. In effect, we conjure the spirits of the computer with our spells.
A computational process is indeed much like a sorcerer’s idea of a spirit. It cannot be seen or touched. It is not composed of matter at all. However, it is very real. It can perform intellectual work. It can answer questions. It can affect the world by disbursing money at a bank or by controlling a robot arm in a factory. The programs we use to conjure processes are like a sorcerer’s spells. They are carefully composed from symbolic expressions in arcane and esoteric programming languages that prescribe the tasks we want our processes to perform.
A computational process, in a correctly working computer, executes programs precisely and accurately. Thus, like the sorcerer’s apprentice, novice programmers must learn to understand and to anticipate the consequences of their conjuring. Even small errors (usually called bugs or glitches) in programs can have complex and unanticipated consequences.
These are the first three paragraphs of chapter 1. What a cool metaphor! Sadly, the use of this metaphor is limited to these paragraphs.
“I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don’t feel as if the key to successful computing is only in your hands. What’s in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.”
Alan J. Perlis (April 1, 1922-February 7, 1990)
Alan Perlis isn’t kidding (does he, ever?) — programming is fun again. Thank you, Clojure.