6 ms·

Alternatively - you can choose to program in Common Lisp - an industrial strength language that has been demonstrated in large projects like the QPX flight sear

Alternatively - you can choose to program in Common Lisp - an industrial strength language that has been demonstrated in large projects like the QPX flight search engine (Google Flights). For anyone who doesn't know - a big difference that Common Lisp brings to the table is that it has separate namespaces for variables and functions. This may not sound like much but it makes it much easier to write macros (code that writes code) and facilitates compile-time computing. Another big difference between Scheme and Common Lisp is that the Common Lisp specification is _much_ larger and it comes with a much larger collection of standard built-in functions and macros and a standard object-oriented programming facility, among many other things. I know this because I've spent the last six years implementing Clasp (github.com/clasp-developers/clasp) - a Common Lisp that interoperates with C++ and uses LLVM as the backend. There are several excellent implementations of Common Lisp - Steel Bank Common Lisp is a great place to start.

eatonphil 8y ago
Hadn't heard of ITA (authors of QPX before being bought by Google) before. Now that I'm looking, it isn't clear to me QPX is still written in Common Lisp? Has anyone confirmed recently that it is still a big CL project?
- drmeister 8y ago
  I hired/partnered with one of their former engineers. QPX is most certainly still written in Common Lisp.
  - eatonphil 8y ago
    Thanks for the confirmation!
    - lispm 8y ago
      They also published some code: https://common-lisp.net/project/qitab/ https://common-lisp.net/project/qitab/
madhadron 8y ago
> a big difference that Common Lisp brings to the table is that it has separate namespaces for variables and functions. This may not sound like much but it makes it much easier to write macros (code that writes code) and facilitates compile-time computing. A little more detail here: it has a lot more namespaces than that. Indeed, you can attach arbitrary different namespaces of things to symbols if you want to. It turns out that when you're writing macros in Lisp, the majority of what you use from outside the macro are functions and the majority of symbols that you bind and use within the macro are variables, so if you put them in different namespaces, you get rid of the majority of cases where symbols don't do what you were expecting in a macro. Now, it's not quite all of the cases, and when it does happen, it's a pain to track down. Which is why the Scheme folks spent the effort and complexity on hygienic macros (where the system rewrites all symbols internally to make variable capture impossible). At the time of Common Lisp's creation, multiple namespaces and unhygienic macros were the obvious choice for production code, since there weren't hygienic systems available. Today you can go either way. In terms of research, hygienic is the route to go, as the work over the last couple of years on strongly typed, hygienic systems has shown.
- kbp 8y ago
  > A little more detail here: it has a lot more namespaces than that. And I don't think the function/value split is even the most important namespacing it does with regards to macro hygiene ("functions are less likely to be shadowed" always struck me as a kind of weak argument). Symbols being namespaced under packages is a much more robust solution: CL-USER> (defmacro m (x) `(car ,x)) M CL-USER> (defpackage :p) #<PACKAGE "P"> CL-USER> (in-package :p) #<COMMON-LISP:PACKAGE "P"> P> (cl:macroexpand '(cl-user::m x)) (COMMON-LISP:CAR X) CL:CAR isn't accessible in P, so (car x) by itself would signal UNDEFINED-FUNCTION, but the macro works correctly. Defining a P::CAR function wouldn't change anything. That isn't just for functions, either, eg if you do: (defmacro awhen (pred &body body) `(let ((it ,pred)) (when it ,@body))) (where you want to leak IT), and then import AWHEN but not IT, you'll get an error that YOUR-PACKAGE::IT isn't bound to anything when you try to use it; it doesn't matter that AWHEN-PACKAGE:IT is bound. I don't disagree with anything you said, I just think it made CL macros look flimsier than they are.
gpderetta 8y ago
>much easier to write macros (code that writes code) and facilitates compile-time computing Isn't this a non-issue in scheme as it has hygienic macros? Note: my only exposition to lisp is via elisp, so I might not know what I'm talking about.
- bjoli 8y ago
  Most CLers hate scheme macros since they almost uniformly believe that syntax-rules is the only macro facility. I myself have implemented defmacro using syntax-case because it is sometimes nice to have. Hygiene solves the issue of namespacing macros, but at the cost of a very complex implementation. Implementing hygiene is HARD and I don't think it can even be called a solved problem. The current systems have issues that have proven to be hard to resolve.
  - gpderetta 8y ago
    That's intersting, because the lisp 'the right thing' approach [1] calls for correctness and ease of use over simplicity of implementation. [1] as opposed to the alledged 'worse is better' of the unix world.
    - bjoli 8y ago
      It is a matter of preference. Sometimes you end up using gensym in scheme as well, especially for introducing identifiers in bulk.
  - lispm 8y ago
    > uniformly believe that syntax-rules is the only macro facility far from it. CLers know that Scheme has zillions of different macro systems. Which makes the whole topic highly confusing and intellectually interesting.
    - bjoli 8y ago
      What I meant by that is that CLers usually complain about hygiene as if it was impossible to break. I don't know how many times I have had to explain that syntax-rules is the high level macro facility and that all schemes provide their own lower level macro facility, be it explicit/implicit renaming (chicken), syntax-case (r6rs) or syntactic closures (Chibi?). I understand the complaint that this isn't portable. It isn't. R6RS tried to standardise it. Hopefully r7rs does better in that regard.
bjoli 8y ago
The function and variable namespace difference is a matter of taste to me. I prefer naming my variables lst to having to use #' and funcall, and the extra fuzz that hygienic macros bring is generally not a very big problem once macros become complex enough. What CL brings over scheme is a fantastic object system. The Scheme copies are half-assed in comparison, especially considering how well-integrated CLOS is.
WindowsFon4life 8y ago
The best CL implementations unfortunately are not opensource. There is still a large use of Lispworks by many heavy CL developers. And anyone who has used it knows what they have to offer over the opensource equivalents. Support is something well worth its cost. Plus in production things tend to just work on Allegro and Lispworks. They tend to bench well for the things we need. http://ftp.linux.org.uk/~ober/report.html http://ftp.linux.org.uk/~ober/report.html
WindowsFon4life 8y ago
CL success stories are growing a bit long in the tooth. Sort through the links yourself to get an idea. http://www.lispworks.com/success-stories/index.html http://www.lispworks.com/success-stories/index.html

eatonphil 8y ago

Hadn't heard of ITA (authors of QPX before being bought by Google) before. Now that I'm looking, it isn't clear to me QPX is still written in Common Lisp? Has anyone confirmed recently that it is still a big CL project?

drmeister 8y ago
I hired/partnered with one of their former engineers. QPX is most certainly still written in Common Lisp.
- eatonphil 8y ago
  Thanks for the confirmation!
  - lispm 8y ago
    They also published some code: https://common-lisp.net/project/qitab/ https://common-lisp.net/project/qitab/

madhadron 8y ago

> a big difference that Common Lisp brings to the table is that it has separate namespaces for variables and functions. This may not sound like much but it makes it much easier to write macros (code that writes code) and facilitates compile-time computing. A little more detail here: it has a lot more namespaces than that. Indeed, you can attach arbitrary different namespaces of things to symbols if you want to. It turns out that when you're writing macros in Lisp, the majority of what you use from outside the macro are functions and the majority of symbols that you bind and use within the macro are variables, so if you put them in different namespaces, you get rid of the majority of cases where symbols don't do what you were expecting in a macro. Now, it's not quite all of the cases, and when it does happen, it's a pain to track down. Which is why the Scheme folks spent the effort and complexity on hygienic macros (where the system rewrites all symbols internally to make variable capture impossible). At the time of Common Lisp's creation, multiple namespaces and unhygienic macros were the obvious choice for production code, since there weren't hygienic systems available. Today you can go either way. In terms of research, hygienic is the route to go, as the work over the last couple of years on strongly typed, hygienic systems has shown.

kbp 8y ago
> A little more detail here: it has a lot more namespaces than that. And I don't think the function/value split is even the most important namespacing it does with regards to macro hygiene ("functions are less likely to be shadowed" always struck me as a kind of weak argument). Symbols being namespaced under packages is a much more robust solution: CL-USER> (defmacro m (x) `(car ,x)) M CL-USER> (defpackage :p) #<PACKAGE "P"> CL-USER> (in-package :p) #<COMMON-LISP:PACKAGE "P"> P> (cl:macroexpand '(cl-user::m x)) (COMMON-LISP:CAR X) CL:CAR isn't accessible in P, so (car x) by itself would signal UNDEFINED-FUNCTION, but the macro works correctly. Defining a P::CAR function wouldn't change anything. That isn't just for functions, either, eg if you do: (defmacro awhen (pred &body body) `(let ((it ,pred)) (when it ,@body))) (where you want to leak IT), and then import AWHEN but not IT, you'll get an error that YOUR-PACKAGE::IT isn't bound to anything when you try to use it; it doesn't matter that AWHEN-PACKAGE:IT is bound. I don't disagree with anything you said, I just think it made CL macros look flimsier than they are.

gpderetta 8y ago

>much easier to write macros (code that writes code) and facilitates compile-time computing Isn't this a non-issue in scheme as it has hygienic macros? Note: my only exposition to lisp is via elisp, so I might not know what I'm talking about.

bjoli 8y ago
Most CLers hate scheme macros since they almost uniformly believe that syntax-rules is the only macro facility. I myself have implemented defmacro using syntax-case because it is sometimes nice to have. Hygiene solves the issue of namespacing macros, but at the cost of a very complex implementation. Implementing hygiene is HARD and I don't think it can even be called a solved problem. The current systems have issues that have proven to be hard to resolve.
- gpderetta 8y ago
  That's intersting, because the lisp 'the right thing' approach [1] calls for correctness and ease of use over simplicity of implementation. [1] as opposed to the alledged 'worse is better' of the unix world.
  - bjoli 8y ago
    It is a matter of preference. Sometimes you end up using gensym in scheme as well, especially for introducing identifiers in bulk.
- lispm 8y ago
  > uniformly believe that syntax-rules is the only macro facility far from it. CLers know that Scheme has zillions of different macro systems. Which makes the whole topic highly confusing and intellectually interesting.
  - bjoli 8y ago
    What I meant by that is that CLers usually complain about hygiene as if it was impossible to break. I don't know how many times I have had to explain that syntax-rules is the high level macro facility and that all schemes provide their own lower level macro facility, be it explicit/implicit renaming (chicken), syntax-case (r6rs) or syntactic closures (Chibi?). I understand the complaint that this isn't portable. It isn't. R6RS tried to standardise it. Hopefully r7rs does better in that regard.

bjoli 8y ago

The function and variable namespace difference is a matter of taste to me. I prefer naming my variables lst to having to use #' and funcall, and the extra fuzz that hygienic macros bring is generally not a very big problem once macros become complex enough. What CL brings over scheme is a fantastic object system. The Scheme copies are half-assed in comparison, especially considering how well-integrated CLOS is.

WindowsFon4life 8y ago

The best CL implementations unfortunately are not opensource. There is still a large use of Lispworks by many heavy CL developers. And anyone who has used it knows what they have to offer over the opensource equivalents. Support is something well worth its cost. Plus in production things tend to just work on Allegro and Lispworks. They tend to bench well for the things we need. http://ftp.linux.org.uk/~ober/report.html http://ftp.linux.org.uk/~ober/report.html

WindowsFon4life 8y ago

CL success stories are growing a bit long in the tooth. Sort through the links yourself to get an idea. http://www.lispworks.com/success-stories/index.html http://www.lispworks.com/success-stories/index.html