Since this is the largest gathering of LISP users I have seen, I have a question. Why prefer lisp-1 over lisp-2 or vice-versa?
IMO if we look at Lisps today the question looks more like: SBCL, Chez Scheme, Racket or Clojure. Common Lisp and Racket are Lisp-2s but honestly, the namespace thing seems like a minor difference compared to all the other features that differentiate them.
A Road to Lisp: Which Lisp
61–70 of 180 posts
Re: A Road to Lisp: Which Lisp
#62The funny thing about Lisp is that writing a Lisp interpreter is significantly fewer keystrokes than correctly installing Common Lisp and its tooling. The ratio of lisps to lisp programmers may actually be above 1.
Re: A Road to Lisp: Which Lisp
#63For me the complete spec is the killer feature. You can learn Common Lisp in 1990 and write it the same now. As long as we can keep the compilers alive it will be forever. It’s funny to me that it was critiqued for being “bloated” when now it looks like a focused minimal library.
Re: A Road to Lisp: Which Lisp
#64To be specific, you can work all of the examples in Graham's On Lisp in Python except for one of the last chapters where he implements continuations that really need macros -- but this is basically the async/await facility that Python already has. The other examples use macros for performance but work fine with just plain functional programming.
React with hooks is an example of that kind of system at work -- the JSX transformation is a very simple shim you can put in front of the JS compiler and the hooks themselves are the kind of trick that On Lisp teaches you how to do.
On Lisp doesn't use the kind of tree-walking macros that really are unique to Lisp. And... the techniques in the Dragon Book for writing compilers are the real magic. If looking to Lisp as an old shiny keeps you from learning how to write compilers, it is holding you back.
I think the homoiconic thing leads people astray. There's a real tension that, for performance reasons, mainstream compilers aren't extensible, for instance you might want to write a
unless(X) {...} => if(!X) {...}
control structure in a new language and for something in Java that is really a production rule in the grammar, maybe a class to represent the unless block, and a rewriting rule that gets applied to the AST. If the compiler was designed to be easily extensible that would be less code than the POM file for the project. But it's not so it isn't.Many things hold us back.
The industry has been so traumzatized by slow compiles that trading speed for extensibility doesn't sell to the people who create languages. Also once you have the sophistication to make things like parser generators you know how to get things done with the terribly unergonomic parser generators we have and don't have a lot of empathy for all the programmers out there who might be using parser generators if any of them were built as if usability matters.
Re: A Road to Lisp: Which Lisp
#65Re: A Road to Lisp: Which Lisp
#66Does that exist somewhere ? I hope jank gets there. Or maybe roc will.
At this point, given the progress and expectations of using LLM, writing code is going to be purely a hobby concern, like carving wood furniture became a hobby once you have Ikea.
So we might as well use fun tools :)
Re: A Road to Lisp: Which Lisp
#67Re: A Road to Lisp: Which Lisp
#68Earlier quoted context omitted.
as of now neovim works great with clojure, not sure about other lisps. vs code also.
I am/was mainly interested in Common Lisp. I might give Vim another try, that would be the best if it worked. I really don't like vscode
I have not tried it, I'm an Emacs nerd.
Re: A Road to Lisp: Which Lisp
#69Since this is the largest gathering of LISP users I have seen, I have a question. Why prefer lisp-1 over lisp-2 or vice-versa?
Lisp 2 advocates typically make a few arguments. One is that having a separate namespace for functions makes it clearer when you are using a function vs another value. The second is that the evaluator has less work to do when examining the head of a list - it needs only look in the function environment, not the full environment.
On the first subject I must disagree - you can bind a function to a regular variable and then use that variable everywhere (except in the car of a list representing a function call), so for most positions in a set of expressions you don't really get information about whether the object being denoted is a function or not.
I suppose the second point is somewhat valid, though I suspect if you benchmarked interpreters and compilers it would barely matter. As a person who favors functional programming with a lot of combinators, I find Lisp 2 introduces a lot of pointless noise in the syntax for no reason. And I fundamentally just don't see functions as significantly different sorts of values, so I find the syntactic distinction bizarre.
Re: A Road to Lisp: Which Lisp
#70Since this is the largest gathering of LISP users I have seen, I have a question. Why prefer lisp-1 over lisp-2 or vice-versa?
The argument is: if you don’t have hygienic macros, a Lisp-2 is going to be less brittle than a Lisp-1. The classic example is, imagine you have a function with a local variable called “list”, common enough. Now imagine you invoke a macro inside that function which generates a call to the built-in “list” function - also common enough. In a Lisp-1 without hygiene that breaks - your local definition shadowed the built-…