Would you use (a dialect of) LISP for a real-world application? Where and why? [closed]

Question

LISP (and dialects such as Scheme, Common LISP and Clojure) haven't gained much industry support even though they are quite decent programming languages. (At the moment though it seems like they are gaining some traction).

Now, this is not directly related to the question, which is would you use a LISP dialect for a production program? What kind of program and why? Usages of the kind of being integrated into some other code (e.g. C) are included as well, but note that it is what you mean in your answer. Broad concepts are preferred but specific applications are okey as well.

Answer 1

Would you use a LISP dialect for a production program?

Absolutely

What kind of program and why?

Lisp is a general purpose dynamic language. Today, it has the same basic difficulties as other general purpose dynamic languages that aren't published by Microsoft: Native threads, GUI integration, deterministic operation of the GC, and small memory footprints.

Native threads are achieved by LispWorks and SBCL, I believe. Possibly others? I have not investigated fully.

LispWorks and Franz Common Lisp - commercial products - integrate into the GUI to degrees of success. Not having the $$ to buy them, I don't know how well it works. I suspect they work quite well...

A deterministic GC operation can be done (it's done in Java to some level of success), but I don't know if existing Lisp systems (maintained ones) have any code to do that.

Small memory footprint I believe is achieved by some Lisps.

My basic point is, Common Lisp is technically ready to make production systems. And it does.

The vast majority of developers get freaked out by (pick one) dynamic languages, macros, parentheses, lack of favorite IDE, bad experience in college, not many jobs in it, and then don't use it.

Personally I'd jump at building a full-fledged production system in Common Lisp from the ground up in a team environment.

edit: I didn't really answer why Lisp as opposed to other languages.

In my Lisp experience - not significant, but considerably more than 'hello world' - I've found the language to be extremely usable after the first "Argh new language" pains. The majority of the language fits together in a very regular and fairly obvious fashion that I don't really find other languages to operate like. Part of this is the merging of expressions and statements. Part of this is the core list datatype. Part of this is the type system. Part of this is the macro system. Don't get me wrong, though, there are pain points. But they don't kick me in the face as much as other languages' pain points.

One simplistic example is Python's length-of-list routine. The Python approach is to call len(mysequence). But, if we think about it, a length is a property of a sequence. So, mysequence.len() is a more appropriate idea. Lisp essentially removes that syntactic distinction. (length thing) is both the function call syntax and the method syntax. Of course, some people find that frustrating and want the syntactic difference. I would rather have the regularity.

edit2: I converted the portion of my MS thesis that runs on the desktop to Common Lisp and it's been a pleasure to work with so far.

Answer 2

I personally know of people using Lisp in the form of Clojure in a couple of investment banks and startups in London. I've also chosen Clojure as the primary development language for my own startup, so I'm willing to put my money where my mouth is :-)

I've found it to be a very enlightening experience to learn Clojure over the past year (after a lot of experience with Java and C#). Main reasons for this are:

• It has quite a strong emphasis on functional programming (more so than most other Lisps). The author and BDFL Rich Hickey has frequently cited Haskell as one of his inspirations for the language design which means you get things like fully immutable data structures and lazy infinite sequences etc.
• Macro metaprogramming - the Lisp "code is data" philosophy is hard to understand unless you've actually experienced it, but it's one of the reasons Lisps are so expressive and productive. You basically have the power to extend the language to match your problem domain.
• Fantastic support for multi-core concurrency - I actually think Clojure is the best language for concurrent programming right now. See http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey for an enlightening presentation about this
• Interactive development at the REPL is a great, productive way of building applications. It gives you a real feeling of power to dynamically modify your running application code and programatically inspect live data structures.....

It also seems to be a practical choice for real production use for the following reasons:

• Running on the JVM with very easy Java interoperabilitiy gives you access to all the libraries and tools in the Java ecosystem
• You're running on the JVM which is a tried and tested platform for enterprise applications. Clojure benefits from all the nice JVM features like excellent GC and JIT compilation for free.
• It's a dynamic language by default, which makes it very convenient for development and rapid prototyping with hardly any boilerplate. However you can add static type hints to get pretty good performance where you need it.
• It's a pragmatic and helpful community - the kind of culture where people get things done and the focus is on well designed solutions that solve real problems
• There is tool support in multiple IDEs. I personally use Eclipse with Counterclockwise plugin (because I need the Java integration) but there are plenty of other options.

Answer 3

I'd use LISP if it was the best choice for the job. Just some things that influence the "best choice":

• vendor support. The LISP implementation we use - if something goes wrong and interferes with our development and thus our deadlines, will the vendor work towards a solution with us?
• library support. What libraries are available? String manipulation, math, data-access, web-servlets (or LISP-equivalents), windowing toolkit, etc... I don't want to have to write this stuff from scratch.
• tool support - How good is the IDE? Solid/stable or flaky? Good editor support? Integrated debugger? If I need to do GUI dev in LISP, is there a visual IDE or do I have to code GUI layout by hand (I hate doing that).
• developer buy-in (I really don't want to have to spend too much time teaching my team-mates a whole new language)

All of these factors are to be considered when deciding if LISP is appropriate for a project. In the corporate world, I have never experienced it.

Answer 4

Absolutely. Paul Graham explains it well.

...Back in 1995, we knew something that I don't think our competitors understood, and few understand even now: when you're writing software that only has to run on your own servers, you can use any language you want...

We chose Lisp. For one thing, it was obvious that rapid development would be important in this market. We were all starting from scratch, so a company that could get new features done before its competitors would have a big advantage. We knew Lisp was a really good language for writing software quickly, and server-based applications magnify the effect of rapid development, because you can release software the minute it's done.

If other companies didn't want to use Lisp, so much the better. It might give us a technological edge, and we needed all the help we could get...

So you could say that using Lisp was an experiment. Our hypothesis was that if we wrote our software in Lisp, we'd be able to get features done faster than our competitors, and also to do things in our software that they couldn't do. And because Lisp was so high-level, we wouldn't need a big development team, so our costs would be lower. If this were so, we could offer a better product for less money, and still make a profit. We would end up getting all the users, and our competitors would get none, and eventually go out of business. That was what we hoped would happen, anyway.

What were the results of this experiment? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours. We had a wysiwyg online store builder that ran on the server and yet felt like a desktop application. Our competitors had cgi scripts. And we were always far ahead of them in features. Sometimes, in desperation, competitors would try to introduce features that we didn't have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.

It must have seemed to our competitors that we had some kind of secret weapon-- that we were decoding their Enigma traffic or something. In fact we did have a secret weapon, but it was simpler than they realized. No one was leaking news of their features to us. We were just able to develop software faster than anyone thought possible...

Answer 5

Where: Emacs is a real-world application that uses LISP.

Why: It was a great way to express the mapping between keystroke and action. It's interpreted and it's fast and it's well-defined and it's simple.

Answer 6

Both Macsyma and Autocad are based on a dialect of Lisp. I would classify them as 'real world' as well as Emacs.

Answer 7

Absolutely I would consider it. Especially for new development work that had some parallel computing potential. That seems to be a sweet spot for these types of functional languages.

Answer 8

Lisp is one of the best choices for implementing compilers. And, as the use of DSLs and eDSLs is increasing now, Lisp is becoming more valuable. I am using a Lisp dialect for all of my DSL-related tasks.

Answer 9

Right now I'm trying to use newLisp as a replacement for Php on my personal web site via the Dragonfly framework. If I can figure out how to get Apache to play nice, I'll use it (the built in web server works very well, but I would much rather work through Apache). And once that happens, I'll use newLisp anywhere I would use Php, because I flat don't like Php and I do like newLisp.

Right now, Clojure isn't a good choice for Android apps, but I know people are working on that. So if that gets figured out, that would be another place to I would use a dialect of Lisp for real world applications... but again, this is because I just don't like Java.

But honestly, I prefer Ruby to Lisp... but this is mostly a matter of community and documentation.

Answer 10

I implemented a proprietary, commercial application in Common Lisp called Tankan that runs on Microsoft Windows as a native executable.

It's a program for training yourself to memorize Japanese kanji characters.

The program runs as a background HTTP server. The execution of this server and navigating to its pages, is coordinated by a tiny system notification area (a.k.a "Tray") icon application which I developed using Visual C++.

The tiny tray icon application starts, monitors and stops the Lisp-based server, and communicates with it using Win32 pipes tied to its standard input and output. Through a pipe, the Lisp server informs the tray icon application of the precise URL with the right port number, and that tray icon application can launch the browser via the Shell API to browse that URL. The user just double-clicks on the icon to bring up the UI.

The Lisp program maintains in its memory a fairly complex session state which contains the user's input history and various relationships among various objects. Lisp's circular object notation (enabled by the *print-circle* variable) and how it works across custom CLOS print-object methods is of a tremendous help in implementing the persistence: users can save the state to disk and resume where they left off. Everything is saved, including the state of the UI. There is a lot of shared substructure in the object graph, as well as cycles. Plus, lots of static cruft that doesn't have to be persisted, like contents of dictionary entry objects. With ANSI Common Lisp custom print object methods, you can create condensed printed representations for objects which are nevertheless machine readable, and have their circular references preserved.

Almost no JavaScript is used in the web UI. Even the controls for hiding and showing parts of the UI are done by form submission and re-rendering the HTML. Every detail of the UI state is hence in the server and persisted when the user saves. The re-generation of the HTML is very fast. It's done by a giant Lisp backquote expression which feeds a HTML generating macro. The code compiled by Clozure Common Lisp (CCL) makes this happen so fast that you're hardly aware that when you click on a [+] button on the UI to open something, you're submitting a request to a server which regenerates the entire darn page, and not simply running some local JavaScript to change the visibility of a local document element.

The program was originally developed with CLISP. Thanks to ANSI CL being a standard language, with implementations that conform well and not too many sneaky pitfalls in the language ("undefined" or "implementation-defined" behavior) it quite easily ported to CCL.

CLISP hasn't been abandoned; it is still used for powering the licensing back end, using much of the same common code base.

I developed an original licensing system for the program, using elliptic curve crypto provided by the IronClad library, which is used by the licensing server to sign licenses to certify them. (I seem to remember I might have used OpenSSL's command line program to generate the EC parameters for the server key.)

Licenses are represented as Lisp objects. It's a tribute to Lisp portability that a Windows program compiled by Clozure Common Lisp can generate an S-expression-based license, a CLISP program running on a Debian server can fill in the missing digital signature field in that object, and send it back to the Windows program which can validate the signature.

On the server, in addition to the CGI-based licensing service, I simple command line API for managing licenses. You can list licenses, find specific ones, and edit their attributes: such as for instance editing the expiry date of a temporary license to grant a user an exception. The licensing back-end also generates e-mails. I didn't use any library for the CGI handling on the server side: just hand-rolled Lisp code for dealing with the Apache environment variables and command line arguments. (Though library code is used for dealing with URL encoding and HTML generation.) No database is used for storage; the licenses are catenated into a file called licenses.lisp and that's that.

Answer 11

If someone paid me to, sure.

They'd probably be more interested in paying someone who knows the language though. I've only played with elisp and scheme a few times.