3 ms·

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 opposit

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 10y 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 10y 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 10y 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 10y ago
  However, mainstream machine languages have defined orders of evaluation and specified results.
oxryly1 10y 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.

kazinator 10y 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 10y 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 10y 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 10y ago
However, mainstream machine languages have defined orders of evaluation and specified results.

oxryly1 10y 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.