31

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.

closed as too broad by Andres F., Thomas Owens Oct 21 '16 at 19:32

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 6
    Does emacs count as a "real world" application? gnu.org/software/emacs/emacs-lisp-intro – S.Lott Feb 23 '11 at 19:52
  • 1
    @S.Lott: Yes. If you use elisp for creating extensions for Emacs, that's fine and an application of a LISP dialect – Anto Feb 23 '11 at 19:54
  • GNU Guile is intended for exactly this purpose. – user1249 Jul 16 '12 at 20:55
  • 1
    While interesting, I don't think this question is suitable for this site anymore. Multiple reasons: 1- too broad, 2- it invites a list of answers, 3- no clear way to decide which is the "right" answer, 4- too localized in time ("haven't gained much industry support"), 5- it invites discussion and debate. – Andres F. Oct 21 '16 at 19:14

11 Answers 11

18

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.

  • 2
    From what I hear, LISP does get used in full-fledged production systems, but usually only for certain logic-processing that is easier to code in LISP than other languages. Video game AI and statistical data pre-processing were examples once cited to me. I once had a manager that had a saying "Any sufficiently complex system has a built-in half-assed LISP implementation". A similar saying was "Any sufficiently bloated system has a built-in email reader". – FrustratedWithFormsDesigner Feb 23 '11 at 20:34
  • 4
    @Frustrated: Yea, those are Greenspun's nth Law and jwz's Law. – Paul Nathan Feb 23 '11 at 20:50
  • 2
    A lot of these are solved by Clojure, simply by virtue of being specifically designed to be compatible with and a replacement for Java. But of course, there are also Scheme and CL implementations for the JVM as well (e.g. Kawa, ABCL). – Jörg W Mittag Feb 24 '11 at 0:16
  • 4
    Clojure is vaguely annoying to me because it's yet another fragmentation. – Paul Nathan Feb 24 '11 at 0:38
  • fragmentation is not a bad thing. What is really annoying in Clojure is the lack of dotted pairs. Can it be counted as a Lisp-like language without such a fundamental thing? – SK-logic Feb 24 '11 at 12:02
11

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.
8

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.

  • I agree with you that productivity is often influenced more by available tools and libraries than by the language itself (provided the language offers some basic functionality). – Giorgio Dec 12 '12 at 14:09
6

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...

  • 8
    "...Paul Graham originally wrote reddit, in lisp, on the back of a napkin while he was waiting for a coffee. it was so powerful that it had to be rewritten in python just so that ordinary computers could understand it. Because it was written in lisp it was almost no effort to rewrite the entire thing, and the rewrite was completed in-between two processor cycles. Paul Graham himself was completely written in lisp, by an earlier version of himself, also written in lisp, by an earlier version of lisp. It's lisp, paul graham, lisp, paul graham, all the way down." – John Cartwright Jun 25 '13 at 7:57
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.

  • I would extend this answer by saying why it was good for expressing the mapping between ketstrokes and actions – Anto Feb 23 '11 at 19:58
  • @Anto: In my experience, Lisp makes it really easy to create powerful abstractions that can transparently represent any action you can do in an editor in a very consistent way--after using Emacs for a bit, you can guess how almost anything is done. This makes it possible to map anything you could do in the editor to a key stroke, with each binding looking really similar to each other binding making it both easier to write and easier to maintain. – Tikhon Jelvis Jul 28 '11 at 17:09
4

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

  • Mathematica is not based on Lisp. – Rainer Joswig Mar 7 '11 at 17:07
  • 2
    AutoCAD offers AutoLISP as an API but it is written in C++ & .NET managed code. – CAD bloke Apr 20 '11 at 0:00
  • 1
    @RainerJoswig Macsyma was probably meant instead of Mathematica. – user40989 Jan 25 '14 at 19:23
2

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.

2

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.

0

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.

0

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.

-1

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.