Getting started with lisp is no easy task. Tools like clbuild and Lispbox make it easier than a few years ago, but there are still obstacles (some quite reasonable) to using lisp in your work environment. After conversing about the subject a little with Alberto Riva (another local lisper!) and seeing trichey mention it, I figured I’d write up the successful approach I employed. Everyone’s workplace is different, and these may not work for you. YMMV.
First off, here are some questions any manager worth their salt will have, that you will need to address:
- How much is supporting another language going to cost me? (buying the software, upgrading the software, running and updating servers, training staff, etc)
- Will our customers be OK with using this esoteric language?
- How will I hire anyone who knows lisp?
In my workplace, we’re a small consulting shop, and I am both programmer and manager. People come to us asking for a website that does X. We then figure out they want X to solve problem P, and suggest a website Y to solve P. These are mostly simple CRUD applications.  There’s a bunch of data and a handful of things they want done with it, but mostly they just want to look at it. We used ASP.NET with C#, and were having a hell of a time abstracting common functionality between projects.  After writing the same code over and over, we knew there had to be a better way, which brings us to the manager’s first concern: cost.
The pro-lisp argument boils down to: we can save money by adding lisp to our toolbox and using it where appropriate.
1) Establish and demonstrate inefficiencies with the current toolset
In our case, we were dealing with ASP.NET version 1, C# version 1, and .NET Framework 1.1. This combination was vastly superior to the vbscript ASP we had been running before, but there were still things we simply couldn’t abstract. We used code generators (provided by Microsoft and written in-house) to write tons of boilerplate C# code, and spent a lot of time frustrated. To be fair, Microsoft tried to help by releasing more versions of ASP.NET, C#, and the .NET Framework, and it was possible to generate our C# at runtime using C#, but the syntax is ridiculous (see listing 6 on Late Binding and On-the-Fly Code Generation Using Reflection in C#). On the flip side, all those new versions of ASP.NET, C#, and the .NET Framework require a lot of work to keep up with, and it is difficult to explain to non-technical customers why they need to spend money to get something totally invisible to them. Another big factor in our displeasure with ASP.NET was how hard it was to have a shared user control library.
The goal of this step is to convince the manager that your current toolset is not a silver bullet, and he could be saving money by introducing other tools. Of course, be honest. If the current toolset is really well suited for the work, then you have no reason to switch.
2) Use open source development tools
If your workplace doesn’t already, start. Some managers might be accustomed to paying costly fees for everything under the sun, and is rightfully skeptical about increasing his tool costs. Some managers might be confused about the maturity and quality of open-source offerings, and applying the “you get what you pay for” adage. Either way, the cost argument can largely disappear when using open-source lisp tools and implementations. Ideally get emacs into your workplace. I’d say a good 10% of my costs with running lisp working were spent learning how to use emacs effectively. In our MS environment, we started with NAnt, Subversion, and TortoiseSVN. Those projects convinced me that open source is inevitably going to corner the developer tools market.
The goal of this step is to convince the manager that there is no great risk to trying out new open-source projects, and OSS can be cost-saving measures.
3) Find a small project you where you can use lisp as a infrequent manual step in an existing project
By limiting the scope (particularly by excluding a runtime component), you minimize the manager’s risk if lisp isn’t up to the job, and side-step any costs with running lisp as a server, or keeping your lisp implementation updated. In our case, we were writing a XUL application, and needed to generate tons of XML. XUL is a neat environment, but verbose as all hell and the standard abstraction mechanisms (XSLT, XBL) left us wanting. We introduced lisp to generate this XML, and found all the abstraction we were looking for. Lisp was natural fit for XML generation, as the tree of code tended to mirror the resulting XML tree. This step will take time because you’ll need to get slime/emacs/lisp configured. This may test your manager’s patience if you’re inexperienced with lisp.
The goal of this step is to demonstrate to the manager the efficacy of lisp without requiring a major investment, and show how lisp can quickly add value to existing projects.
4) More manual lisp processes, more people
Here you apply lisp to more one-off problems, or expand on the previous project. In our case, we started generating javascript with our XUL, wrote a pricing calculator for an existing product, and a script to check the status of many internal subdomains. This will involve getting more people involved with lisp. Pair program a lot here on people who don’t know lisp. Watch SICP lectures. In my case, my co-workers were all excited about lisp, and picked it up very easily. We weren’t doing anything advanced, and the context of XML generation made it all pretty easy to think about. If your co-workers do not take to lisp, then you’re probably SOL.
The goal of this step is to demonstrate to the manager that the whole team can benefit from lisp, and get them thinking about what else lisp can offer.
5) Pick a medium-sized internal project and run lisp in production environment, in cooperation with an existing project
This is where the manager needs to stick their neck out a bit and convince his powers-that-be to try something new and different. This might involve working with your systems department to setup a new server, and will likely have pretty high visibility even if the project itself is low priority. This project should be something used internally so we don’t have to tackle the “what would our clients think of lisp” question yet. Here is where you really need to deliver for your manager. In our case, we had a 10 year old C++ app running some core invoicing logic. The thing was riddled with bugs, and the source wasn’t even in version control. The staff had just figured out how to work around it. This was ripe for the pickings, and we made a website that talked to the same database, so they could be used in tandem. In our case, just about anything was better than the C++, and lisp brought a new era of flexibility. To ease deployment, we generated lisp executables (using sb-ext:save-lisp-and-die) on the dev machines, copied them to the production server, and run them behind proxy servers. This eliminates the costs associated with updating lisp implementations on production servers.
The goal of this step is demonstrate lisp’s stability and effectiveness in a production environment. If you’ve achieved this, you have demonstrated the cost-effectiveness of lisp, and can use it on any internal projects.
Gosh, that ended up a bit more verbose than I intended, I’ll try to make the next one more concise.
12 Comments