I decided to have a summer job which was relevant to my studies, to use my time well. Believe it or not, there are companies out there who use Lisp as their main programming-language. I would like to illustrate what I liked about programming in Lisp, and how it relates to Web-based applications.

Lisp is generally seen as a very esoteric language. The definition of the word “esoteric”, in the American Heritage Dictionary, is “Intended for or understood by only a particular group: an esoteric cult.”. Neither is Lisp intended for one certain group of people (maybe apart from computer-programmers themselves), nor is it understood by one group which can be defined (apart from Lisp-programmers). One of the main gripes of people who do not like Lisp is that they cannot see through the parentheses. They claim that they would never be able to efficiently write programmes while there are so many parentheses to keep track of. One common rebuttal is that editors such as Emacs can do this. And that, it can. However, this is not the main reason for programmers’ reluctance to even take a look at Lisp. I think that the main reason for this reluctance is that Lisp’s syntax is just so different. I remember watching a programme about appetite, a few years ago. People were presented with red baked-beans and blue baked-beans. I think that anyone can guess which was most preferred, without my even saying. One example of how Lisp has permeated into the circle of “real-world programming-languages” is Ruby. The founder of Ruby himself has admitted to having taken many features of Lisp. But looking at Ruby-code, one can instantly see that its syntax is similar to many other popular programming-languages such as Python. This, I think, has been a great advantage to Ruby’s adoption.

The main problem in the adoption of Lisp is analogous to that of racial discrimination. By no means am I comparing their importances. I believe that the main problem in Lisp’s adoption is the perception of its presentation, with which I definitely do not have a problem, and nor is it a problem of Lisp itself. There have been attempts to change its syntax to suit the majority’s views of how it should look like in order to be accepted, but these attempts failed.

I started programming with Python at 14, and quickly went on to Lisp, encouraged by the people on #emacs on FreeNode. I was lucky in the sense that I did not use, say for instance Java, for too long a period such that I would dismiss “different” languages. I must say that I have greatly enjoyed using Lisp because of its manifold features, its autonomy from one specific method of programming and also because of my ability to define new syntax where it does not exist. There is a common conception that Common Lisp is a functional programming-language. This notion may have arisen from CL’s relation with Scheme, which is closer to a functional programming-language. Of course, Lisp does not prevent one from writing functional programmes as much as is desired; most of Lisp’s functions do not modify their input, and indicate so in their names if they do. The notion that Lisp is somehow functional sometimes prevents a potential learner of Lisp from ever knowing about Common Lisp’s extremely powerful object system (CLOS). It isn’t really like Java’s version of object-orientation, but must definitely be perused.

Over the summer, I worked on a browser-based application that in essence enables its users to create and organise adverts and view their statistics. A number of features of Lisp greatly enhanced the enjoyment of my job. Firstly, a running Lisp process is dynamic. This means that I can enter a command-line from where I can change the definitions of functions, classes, objects, variables and various other things. This is conducive to testing ideas and also to saving a live and running instance from an error without having to restart or recompile the whole file. It greatly reduces the loss which a programming error may cause. Though the ability to quickly change things without a great cost can sometimes be counterproductive. I’ve found that a lot of the time, I could have spent less time implementing something if I would have just got a piece of paper and thought about the problem, instead of the trial and error method. This same ability can quickly lead to badly-designed code. Lisp’s flexibility definitely fits in with “agile programming”. The Common Lisp Object System allowed one of my colleagues to define a “web-framework” which could easily be specialised on. In the time at my job, I took a part in porting some old code to this new framework. In CLOS, a thing called a resource was defined. This was a class. A generic rendering (something that generates html) method was defined on the resource. This was the basis on which every single part of the system, was defined. CLOS’s flexibility allowed us to define classes of resources, and define methods ever more specialised on a given resource, when wanted. CLOS’s features even allowed us to combine the results of certain methods, and ways to bypass the normal execution order. The ability to define new syntax in Lisp, enabled us to use Lisp syntax to define html-pages, and even Javascript. Yes, it is possible to write valid Javascript in pure Lisp syntax. What this allowed us to do is even again, define procedures which manipulate Lisp code which is actually Javascript code, to generate new Javascript code. For instance, this allowed us to define an object-orientation system for Javascript, in Lisp. This was greatly helpful in designing the interface of what I was working on.

There isn’t much more to comment on with regards to my job, but I hope I’ve presented a few features of Lisp which definitely have bearing in web-development’s current trend. The ability to easily change features of a running system is a great benefit to people whose lives depend on a service’s constant running. With regards to AJAX, the ability to abstract a lot of the boiler-plate javascript code enables one to much easier implement an idea, and with the assistance of an actual programming-language.