4 ms·
I think a lot of the choices that went into common lisp were done for practicality's sake although there is some archaic elements due to design by committee and
by 4thaccount 8y ago
I think a lot of the choices that went into common lisp were done for practicality's sake although there is some archaic elements due to design by committee and trying to put something together to unite the many different lisp implementations at the time.
There's a lot to like about Racket, but Common Lisp is really fast, practical, and is portable to many different implementations like SBCL, AllegroCL, LispWorks...etc that are similar, but have different characteristics (one compiles faster, one has better performance, the commercial ones have GUI libraries...etc).
Given a choice, I would personally choose Common Lisp over Racket pretty much any day (not that Racket isn't nice btw). Performance is one reason, but the Chez Scheme migration should help out Racket a bit.
OCaml is neat too, but not really directly comparable to Common Lisp. Both are solid languages, but I wouldn't put them in the same category. If I was writing a compiler I would choose OCaml...crazy macros and code generation everywhere...lisp :)
I'd like to see someone who really uses Common Lisp regularly like LispM comment though.
- peatmoss 8y agoI wonder if the Chez Scheme port, we’ll see Racket ported to more places. A lot of moving to Chez has been writing more of Racket in Racket rather than C. While the Chez and Racket are probably more similar, I have to wonder if we’ll see Racket ported to SBCL or elsewhere. I like Racket for the cleanliness and good design, but I do covet SBCL’s performance and CL’s ubiquity.
- lispm 8y ago> archaic elements due to design by committee The 'archaic' elements are due to backwarts compatibility with Lisp. You get that raw core of Lisp from the 60s: s-expressions, cons cells, LAMBDA, LIST, CONS, CAR, CDR, APPEND, COND, EVAL, PRINT, PROG, READ, macros, dynamic binding, ... all these (and more) are still in Common Lisp. Common Lisp is an improved Lisp dialect, not a fully new language. A goal was to relatively easily port some existing software which was written in the years from 1958-1984 to Common Lisp. CL appeared in a documented form in 1984 with CLtL. Thus some code that ran in Common Lisp was a port of code written starting in the 60s, like Macsyma. People did not want to throw away hundred thousands lines of code and they wanted to use the newer language, because it was available, slightly better than the old one and was supported on more machine types. This language was mostly developed by five people: Scott Fahlman, Guy Steele, David Moon, Daniel Weinreb, and Richard P. Gabriel. > and trying to put something together to unite the many different lisp implementations at the time Common Lisp is specifically a successor to Maclisp, mostly based on Lisp Machine Lisp (another Maclisp successor), by simplifying/generalizing LML. It's even not directly compatible with LML. It's much less compatible with other Lisp dialects of the time: Interlisp, Scheme, IBM's Lisp, Standard Lisp, or even Scheme or Logo. After the initial design of Common Lisp was done, an effort was started to standardize the language: improve it and add a bunch of important features like error handling and object-oriented programming. Error handling was then based on the Symbolics 'New Error System' and the object-system CLOS was a new design based on Flavors and LOOPs - two earlier Lisp extensions. The most committee like design was actually CLOS. But even that was driven by only six people, lots of community support and a portable reference implementation (PCL). Arguably, CLOS is one of the greater designs in the Lisp language space. The third part then are implementation extensions, which got especially important, when the standards effort went out of steam/funding/interest...: concurrency, unicode support, foreign-function interfaces, standard libs, ... The design advantage Common Lisp has over Scheme is that it started as a larger integrated language. This makes features know of each other and the language is designed to use and support them. Scheme has often this feeling of a very small core language, even a too small core language, and a lot of stuff bolted on top. The result is that 'practical' implementations (practical here means implementations which are used to write software and not so much as a teaching language/implementations) often reach the size of Common Lisp and one of its implementations AND all of them are diverging in some basic ways (Chez, Chicken, Racket, Guile, ...). Take for example the object system. Since CLOS was added to Common Lisp no one bothered to propose a replacement for it in Common Lisp. Thus every implementation, small and large, is using it. > but the Chez Scheme migration should help out Racket a bit If I would want to use Scheme, I'd use Chez Scheme directly. It's a great implementation of Scheme. In provides what many Common Lisp systems (incl. SBCL) also offer: an optimizing native code AOT compiler. Chez already has what Racket now gets: an improved implementation mostly written in itself.
- 4thaccount 8y agoAs always, thanks for the well written and thoughtful reply. >If I would want to use Scheme, I'd use Chez Scheme directly I came to the same conclusion based off of a fast interpreter, AOT compiler, ability to make executables...etc. I know I've looked at the CISCO GitHub page for it before.
- mruts 8y agoGambit Scheme is also good (and fast). It’s used as the base of lambdanative, a cross platform scheme framework mostly targeted at native mobile http://www.lambdanative.org http://www.lambdanative.org
- lispm 8y agoJust use Embedded Common Lisp. Comes with a full Common Lisp incl. CLOS implementation, compiles to C, uses the usual free IDE SLIME/GNU Emacs. https://common-lisp.net/project/ecl/main.html https://common-lisp.net/project/ecl/main.html
- 4thaccount 8y agoHow good is the quality?