If you read CF-related blogs, you've undoubtedly stumbled upon discussions of seemingly arcane subjects like continuations or closures or first-class objects or absence of side effects. It's likely bloggers have tracked down the source - some would say fount - of such concepts and you'll find them waxing eloquent. As they should.

This short article shows how you too can find the source, play with it, and maybe join the ranks of the anointed.

The source is Lisp, a functional kind of language - as opposed to a procedural, OO or logical language. One of the oldest programming languages, its theoretical basis is found in the Princeton mathematician Alonzo Church's Lambda Calculus, essentially a logic system concerned with functions. It was adapted to computing by MIT's John McCarthy in the late 1950s as Lisp, and has continued to evolve ever since alongside the successive blooming of Fortran, Cobol, Basic, Pascal, C++, and Java. Indeed, Lisp has been a mainstay for artificial intelligence research and widely known as the basis of Emacs and a number of commercial products, an illustrious enough lineage for numerous authors to write histories of the language.

This evolution has spawned many dialects and implementations. Which one to use? Judging from the number of references to them on the Web, a short list of possibilities would include Haskell, OCaml, F#, Scheme, CommonLisp, newLisp, PicoLisp, and Scala. They all have pluses and minuses, adherents and detractors. After downloading and playing with most of those just listed, I finally decided that a small footprint, decent documentation, a modern feature set, and open source were sensible criteria, so I chose newLisp. In addition, I have no plans to develop large, compiled, applications with Lisp - at least not at present.

Just as Perl has Larry Wall, Python Guido van Rossum, and Ruby Yukihiro "Matz" Matsumoto acting as benign dictators or gurus, newLisp has Lutz Mueller. It is now at version 9.1.x and has been under active development for years.

Setting up your environment to code in newLisp is easy. Go to www.newLisp.org and download the implementation for your machine; unzip the download into any directory and double-click on the executable (newlisp-tk.exe on Windows or newlisp-tk on *nix); what opens is a simple editor written in Tk. In that editor, type (mul (add 5 6) (sub 8 4)) and hit enter. You've just run three built-in functions: added 5 and 6 to get 11, subtracted 1 from 8 to get 7, and multiplied those two results to get 77. Lisp is evaluated generally from right to left, inner to outer parentheses; the result of each evaluation is passed to the next function on the left. Return to the newLisp Web site and read the excellent tutorials, examples, and other documentation.

Well, after playing with newLisp for a couple of weeks and developing a smooth workflow process with the editor, I started to rewrite a small CFML algorithm that checks whether a comma-delimited string of U.S. states and/or Canadian provinces is contiguous. It's used by a government agency as part of a process of validating applications for commercial vehicle licenses.
Because the "contiguity checker" uses many features common to all languages - looping, conditional logic, containers (arrays, lists, etc.) - it's a perfect newby learning experience; after all, the basic logic had already been worked out and humming along in production. During the rewrite, and much to my surprise, I found a way to make the algorithm more efficient. To see how the Lisp syntax differs from CFML, see Listing 1.

Then I discovered that Lutz had written a little utility included in the original download. The utility, link.lsp, packages any script you write with the newLisp interpreter to produce a standalone executable - which can then be called from a ColdFusion template using <cfexecute....>. Called from within a CF template using <cfexecute....>, the execution is about 10% slower than the straight CF version. Run from the newLisp-Tk shell, the newLisp version executes faster than the CF version, which is expected because the newLisp interpreter is written in C.

I attribute discovering a more efficient algorithm to the fact that writing Lisp really did require a subtle change in consciousness that felt, to use an adjective posted more than once elsewhere, Zen-like in its focus and clarity. It's difficult to put this internal experience into words but it was like what I experienced years before when laying a floor.

You see, while building a house and with overruns draining the wallet, I decided to forego subcontracting the job of setting the foyer's floor with irregularly shaped and variably sized natural slate, figuring I could do it some weekend. I marked off an 8-by-12-foot area on the garage floor and, with the pile of slate at hand, began arranging the slabs. After hours of labor, the arrangement still looked crappy and I stopped to rest my aching back and began to wonder if professional stonemasons had some sort of secret for laying out natural stones in a pleasing pattern.

Maybe it was the fatigue, maybe it was letting go after trying so hard for so long, but suddenly I began to view the task completely differently: I stopped looking at the slabs themselves and began to look at the spaces between them. After that, the task seemed simple; it took only about 20 minutes to create a nice arrangement. Such thought reversals are akin to those gestalt drawings where, if you stare at them, the foreground becomes background and vice versa, but in this case the mind-shift facilitated the task, presumably because paying attention to the spaces between the slabs shifted my attention to the relationships between them. It is within the relationships that a pattern became obvious.

This kind of experience seems the norm for Lisp coders and has been much written about. For instance, Eric Raymond says, "Lisp is worth learning for the profound enlightenment experience you'll have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."

Although answering the question "How does Lisp do this?" is beyond the scope of this brief article, Paul Graham, a well-known writer about Lisp, asserts that it promotes "bottom-up" design (www.paulgraham.com). In other words, you "grow" code, rather than "construct" it; it feels like an organic process because functions are also data objects. Another writer notes that Lisp is the ultimate "verb" language while contrasting it with Java, which he describes as a "noun" language. (See "Execution in the Kingdom of Nouns," http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html)

Plenty of Web sites extol the virtues of Lisp and to get you started, surf to Graham's site and then to a Google video (http://video.google.com/videoplay?docid=448441135356213813). Two other inspiring sites are www.defmacro.org/ramblings/lisp.html and www.norvig.com/. And, if you really get motivated, read Peter Seibel's book "Common Practical Lisp," which is so beautifully written that it's a pleasure to read even if you never tickle a Lisp interpreter.