3 ms·

Using Lisp (in the form of Racket) for many years in a production environment, I've observed: 1. People do complain about the parentheses but they generally ge

Using Lisp (in the form of Racket) for many years in a production environment, I've observed: 1. People do complain about the parentheses but they generally get to work dealing with them right away. It's the loudest complaint, but it doesn't really even slow people down. 2. This is a similar complaint, and does scare people off from jumping in if they have a real choice. 3. Racket in particular solves this one to an extent. We've used it with Redis, JSON, MySQL, Perforce, etc etc productively. More commentary below, though... 4. This one is a non-issue as far as I've seen. If you hire someone who can program, then can quickly learn and be productive in Lisp. 5. This is tied in with 4, a non-issue. 6. This is an issue with perception. The problem is more that people believe they know something about Lisp because they've heard of it, and they come in with the expectation that it'll be weird or difficult, which is a bit of a speed bump to getting to work right away. Ultimately the biggest issue we've seen is that the broader ecosystem of organizations using Lisp (or Racket) in production environments is missing. As such, there are many sharp corners that you have to file off yourself as you deploy your usage. Useful resources like Stack Overflow just don't have the answers prepackaged because it's likely you're the first to use Perforce to deploy a precompiled version of your Racket application on Windows (for example). It's easy to underestimate just how much work people have put into making ecosystems in C++, Java, and Python contain all the pieces, experience, and knowledge you'll need to solve your particular problems quickly and effectively. Another pieced missing along with that ecosystem: outside of the implementation of the language itself, no one has taken an application of significant size and age and added a major feature to it. This is something that happens in production all the time -- and it happens on a schedule with a budget. Virtually no one using a small or academically minded languages ever does this, though. And it's not until you try that do you discover all those sharp corners and missing support tools and libraries.

grey-area 9y ago
The hesitation I'd have with Lisp(s) as an outsider, which ties in to number 3, is that the language itself is compact, elegant and extensible. It's the opposite problem to C++ (the language is too large) - the language is too small and it encourages you to build other languages inside it. So it'd be very hard to share code with others because as soon as you start building abstractions your language and worldview diverges from everyone else's version of lisp - to use a library you have to learn someone else's mini-language. Maybe this is an invented concern though, did you find integrating other libraries a problem? Did you have any problems with development speed or performance in production or was that fine?
- kazinator 9y ago
  "Lisp is small" without being specific about the dialect is meaningless. ANSI Common Lisp's one and only 1994 standard is over 1000 pages long. The Scheme reports are a lot smaller, though growing. I think still under 100 pages. I developed a Lisp dialect that has a dense reference manual that is over 530 pages long with no table of contents or index.
- DigitalJack 9y ago
  I think that objection is likely true of scheme. Scheme is like the Assembly language of lisps. To build it up to the level of usefulness requires a lot of wheel re-inventing, and those wheels are likely to be not quite standard. Clojure and Common Lisp are larger languages and don't really suffer this problem.
  - shakna 9y ago
    That's not really the case for R6RS, and now R7RS Large. Both of those have huge swathes of libraries and make the language quite large.
  - kazinator 9y ago
    However, mainstream machine languages have defined orders of evaluation and specified results.
- oxryly1 9y ago
  With Racket, at least, the language encourages you to build very small pieces and assemble them into larger systems. It's fairly straightforward to connect the pieces together to share code. It does also encourage you to create mini-languages, but our approach was usually a large amount of modular Racket-y code with many fairly thin layers of syntax transformation used in each mini-language case. In that sense the problem of mutually incompatible languages didn't really arise (in fact, separate mini-languages coincided with separate usage areas quite well). Performance was an issue, and we generally needed to use the precompilation feature of Racket to be successful. The issue we ran into is that Racket's precompilation system produces fairly fragile and coupled binary files -- and is generally difficult to separate cleanly from the execution environment.

grey-area 9y ago

The hesitation I'd have with Lisp(s) as an outsider, which ties in to number 3, is that the language itself is compact, elegant and extensible. It's the opposite problem to C++ (the language is too large) - the language is too small and it encourages you to build other languages inside it. So it'd be very hard to share code with others because as soon as you start building abstractions your language and worldview diverges from everyone else's version of lisp - to use a library you have to learn someone else's mini-language. Maybe this is an invented concern though, did you find integrating other libraries a problem? Did you have any problems with development speed or performance in production or was that fine?

kazinator 9y ago
"Lisp is small" without being specific about the dialect is meaningless. ANSI Common Lisp's one and only 1994 standard is over 1000 pages long. The Scheme reports are a lot smaller, though growing. I think still under 100 pages. I developed a Lisp dialect that has a dense reference manual that is over 530 pages long with no table of contents or index.
DigitalJack 9y ago
I think that objection is likely true of scheme. Scheme is like the Assembly language of lisps. To build it up to the level of usefulness requires a lot of wheel re-inventing, and those wheels are likely to be not quite standard. Clojure and Common Lisp are larger languages and don't really suffer this problem.
- shakna 9y ago
  That's not really the case for R6RS, and now R7RS Large. Both of those have huge swathes of libraries and make the language quite large.
- kazinator 9y ago
  However, mainstream machine languages have defined orders of evaluation and specified results.
oxryly1 9y ago
With Racket, at least, the language encourages you to build very small pieces and assemble them into larger systems. It's fairly straightforward to connect the pieces together to share code. It does also encourage you to create mini-languages, but our approach was usually a large amount of modular Racket-y code with many fairly thin layers of syntax transformation used in each mini-language case. In that sense the problem of mutually incompatible languages didn't really arise (in fact, separate mini-languages coincided with separate usage areas quite well). Performance was an issue, and we generally needed to use the precompilation feature of Racket to be successful. The issue we ran into is that Racket's precompilation system produces fairly fragile and coupled binary files -- and is generally difficult to separate cleanly from the execution environment.