I don’t know why, but my Perl programs have always seemed to lend themselves to lengthiness over brevity. That is not the fault of Perl itself. Part of my problem is [re-]learning a new language again for the first time, and keeping all the code in one place for easier debugging, and part of it is I am only just seeing what could be possible in the ability to use both array and hash references.
For example, like variables could be created in a subroutine and returned as part of a hash ref or array ref. Variables can be declared as needed, something I do not remember as part of Perl, when I used it thirteen and ten years ago, respectively.
As I write several new programs for new rate structure and quarterly water billing, the code will get cleaner.
I have purchased either in e-book or printed form most of the major books on Clojure, including both from Manning Publications, Apress, O’Reilly and The Pragmatic Bookshelf . All these books are well written; all have slightly different approaches and styles.
Some are tutorial in nature, others are more like a tutorial/reference, and others contain philosophy in addition to tutorial. In some of these references, there is a sense you have programmed in Java previously, and I sense, and it is not directly implied, that the reader has dabbled in a Lisp dialect.
My Ah Hah! moment came recently when I realized that until a couple of years ago, the last languages I used in the commercial world were C++, Java 2, and Perl. Functional Programming (FP) was an academic subject, and though I had heard of Python, there was no pressing reason for me to learn it, at least back then. These books are written by authors with mostly a different programming learning and implementation environments.
So, as I work my way through Clojure In Action and Code Lesson’s Intro to Clojure, there are additional things for me to learn, the biggest of these the differing implementation environments and curriculum from when I started programming.
Here we go, then.
The first time I touched a computer was in college. As we were graduating high school, the prevailing wisdom said don’t bother learning anything about computers. Pretty soon, they will all be programming themselves. I guess pretty soon covered a longer time span than the expected normal time span for that phrase.
My first experience was on an IBM connected teletype directly connected from the Chemistry Department in Parsons Lab at UNH to the IBM 360 computer in the Math Department in Kingsbury Hall. It was awful. You had to type perfectly, or count the number of characters as you erased backwards. A few years from that day, I used punch cards for a Fortran IV course at Northeastern University, and to me they were considerably better than a teletype. Despite enduring all this, I was spared those punched programs on paper tape.
Finally, I realized I had to have a common day higher level programming language, discrete [data] structures, and a course in someone’s assembly language — I chose IBM 370 assembler — under my belt. That allowed me a passage into software technical writing about languages and operating systems.
Those courses lead to Harvard University Extension School for something called a CAS — they have a masters program now — which included the data structures, Pascal, discrete mathematics, and computability theory, along with fleshing out operating system theory and a wonderful course called the anatomy and physiology of a computer. Before I graduated, I had already been programming for two years using PL/I.
Now, the big push is functional programming, along with a group of computer programming languages that are not so relatively new, and some, like Scala and Clojure, that are relatively new. Given Computer Science degrees were not around when I went to college it is hard to say what the curriculum changes are, but looking at typical curriculum makes me think obvious things have changed, like no longer requiring assembly language, and the math requirements have migrated to include support for functional programming.
I never heard of Lambda calculus, but having looked at the structure of more modern computer programming languages, my guess is Lambda calculus is taught a lot, if not as a separate course, then embedded in other courses. I believe I have to learn it, and I’ve started by ordering an introduction to functional programming .
I am writing this post to try to dig into why someone wants to use Clojure; who would use it to implement production grade software; and who is qualified to use Clojure. I saw a post today concerning the compatibility between Clojure releases and between the Clojure “contrib” library. One answer indicated Clojure is not for the masses; is for hackers and people who like computer science; and for those who want to work with a fun language. I saw history repeating itself with this answer.
Gordon Bell’s law about functions (classes) in computers being replaced by cheaper hardware about every decade made me think about things being reinvented, especially arguments in computer technology, most notably computer programming languages. The argument I read about who should use Clojure was like Deja Vu all over again .
What is perhaps not understood, or I cannot detect the understanding in what I am reading, is that not all computer work is fun; you do not always get to choose your language; and you have to be innovative in your work with the tools you have or can grab.
If you go to Clojure’s home page and read the first few paragraphs and also click on Rationale, Rich Hickey, Clojure’s founder, seems to be saying that Clojure was designed with balance, pragmatism, and trade-offs. This does not seem to be directed at an elite group of people.
I understand why people like Clojure and other Lisp dialects. Coming from PL/I and C and considering the other languages available in the 1980s, DEC’s Bliss-32 was like a dream. I realize most readers today might find Bliss dreadful, but it allowed me to express hardware architecture functions in a clearer way than assembly language or C ever could (C++ did not exist for commercial use in 1987.) Even PL/I has a construct that supports multiple function entry points, aka multiple function interfaces. It sounds a little like polymorphism to me.
Now back to the response to the compatibility between Clojure’s released versions: the answer itself did not bother me. History repeating itself without looking to arguments in the past seemed futile. Maybe that’s what we do every 10 or 20 years, start discussions, thinking they are new, not realizing we are restarting arguments from the past.
If Clojure winds up becoming a salon-class, elite language that will be a shame. There are aspects to Lisp dialects and Clojure specifically that I believe should become part of mainstream. I find Lisp syntax far easier to read than, say, Haskell’s.
So, my thoughts about Clojure and who should use it, if not already obvious, are use it, if it makes sense in your environment. Learn Clojure well and what drives it, specifically functional programming and environments requiring synchronization. If you can’t use it, learning will probably help you with your current language.
Those folks who follow this blog or http://octopusgrabbus.wordpress.com might come to the conclusion that I’ve abandoned Python, but that is not the case. I started learning Python in 2009 by writing some applets to perform database housekeeping, and then eventually implemented an application in 2010 for our water department. This application, which includes a Django-powered web site was written almost exclusively in Python.
I have been interested in functional programming for a few years now, and started looking at Haskell a couple of years ago. As the deadline to start designing our water department application loomed closer, I did not know Haskell well enough to use it. Also, as a language, Haskell did not appear to have the broad library support enjoyed by Python. So, I chose Python as the implementation language for this project.
Earlier this year I came across a description of The Joy of Clojure at my favorite book sellers — http://softpro.com — and started learning more about Clojure. Having never programmed in a functional programming language or a Lisp dialect, I am finding Clojure a little daunting. However, a project has presented itself, which involves a faster way of processing our billing data through address verification.
A project is like a carrot and stick; that is it provides cause to use extraordinary effort to learn something new quickly or solve a particularly difficult problem. The project will require more than a Clojure program. Some 4GL and bash scripts will be used. However, the Clojure program will be substantial enough to get me familiar with the language and will have required enough effort to start writing code.
One of the things that has attracted me to functional programming (FP) languages is the same thing that attracted me to object oriented languages when I first learned C++ in the 1990s. Learning C++ improved my overall programming skills, whether I was writing object-oriented software or not. With learning C++, my analogy was it was like rotating your mind 90 degrees. With Clojure it is that and more.
Just one of the ways that learning Clojure has made me think differently is using the various sequence functions. Most of what I want to do with billing data fits well into Clojure’s strengths. That is you can apply the same functions to all the data and sort out data easily that does not fit your needs. At the moment, I do not see a use for using Clojure in a multi-process/multi-threaded environment.
I am also appreciating providing for data at the beginning, binding in Clojure, declaring variables in imperative languages like C. Python’s strength in the the ability to declare an object anywhere is also in my opinion a weakness that can lead to sloppy style, and I know this from direct experience.
So my conclusion is this. If I never write another line of Clojure code after my current project, my time will not have been wasted. Clojure requires a different way of thinking. It never hurts to take a different point of view, especially with problem solving. However, I think more Clojure projects will be forthcoming.
If I were to write my What I Did This Summer essay this Fall — it would be how I struggled to learn the Clojure language. Since May of this year, using book review recommendations, I’ve purchased Practical Clojure (Apress) and The Joy of Clojure (Manning).
In addition, Chas Emerick is writing Clojure Programming (O’Reilly) which, along with Clojure in Action, is about to be released in early Fall.
Stuart Halloway’s Programming Clojure (Manning) was reviewed as an excellent book, but one comment said it was older and only covered Clojure 1.0. Although I value the books I’ve purchased, unfortunately I fell for the comment that Programming Clojure was an older book. As a result I initially missed out on a very well written book that helps guide those of us who are new to functional programming (FP) into the Clojure language. In other words, this is a very good book for those of us not used to Lisp or functional programming.
As it is with many books, especially some of the advanced Python books I’ve purchased, I’ll come back to the other books I’ve purchased as references or to take advantage of another viewpoint, so I am not disappointed to have purchased them.
I’m on a mission to learn well, appreciate, and eventually use Clojure in our production environment. For me this is serious enough that I’ve enrolled in a to-be-announced, instructor-led Clojure course at http:/codelesson.com .
Having programmed in many different languages, I heartily recommend Programming Clojure as a good book overall and certainly a good first book for Clojure.