So many words to say: Scheme. :)
R5RS, R6RS, or R7RS?
R6RS.
A Road to Lisp: Which Lisp
71–80 of 180 posts
Re: A Road to Lisp: Which Lisp
#72I'm surprised there's no call out highlighting Common Lisp and Clojure's "liveness" compared to Racket (and Scheme). Racket is "batch compiled" wherein CL and Clojure you're editing a live image.
Re: A Road to Lisp: Which Lisp
#73There is also MLs that have the same idea, but with less implementation, as a lisp is something you hack in a weekend. An working ML not, as it takes way more effort. Lisps have many fantastic ideas, but are really hard to read. Lisp code is what we had before perl guys went "hold my beer". I know its just syntax, and it usually does not matter, untill it does. I did some clojure a long time ago, and before that some…
I find Lisp much easier to read than most other languages. It is highly explicit syntax with very little ambiguity, especially if you have a little discipline about macros.
Re: A Road to Lisp: Which Lisp
#74Since 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-…
@nathan_compton, your sibling comment to what I'm writing now is [dead] (not [flagged]) but you're not shadowbanned, newer and older comments are still alive. I vouched for it but it's still [dead], you may want to reach out to the mods.
Re: A Road to Lisp: Which Lisp
#75Racket's top dog in my book :)
Re: A Road to Lisp: Which Lisp
#76Earlier quoted context omitted.
I can also recommend clojure. For me it has the best parts of common lisp and the best of the java ecosystem. But its also quite different from common lisp and scheme. Different enough to find some unique ideas. Writing scripts using [0] Babashka is also really nice. [0] https://babashka.org/
As a former Clojure dev (now just using Clojure in my spare time) I love Babashka. Michiel Borkent really nailed it with sci (Small Clojure Interpreter) and Babashka. Running a custom Clojure interpreter in a GraalVM compiled Clojure app is quite clever. Now there are of course limitations to what you can do in terms of not supporting Java reflection or the full Clojure compiler. But I've made some nifty small script…
I love the Clojure community, it is the only one that usually talks about the host platform in a symbiotic way, not as if they would be rewriting everything into their favourite language, like in most guest languages communities.
Re: A Road to Lisp: Which Lisp
#77Choose any LISP, and the right LISP will choose you.
Re: A Road to Lisp: Which Lisp
#78I'm going to take the opposite position that there is much less special about Lisp than people think. Like I have met so many programmers that travel around like itinerant martial artists looking for true functional programming and they never find it. To 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 ma…
Except that CPython still misses on (compile .....) part, indeed holding the industry back.
Re: A Road to Lisp: Which Lisp
#79Since a few folks here recommended Common Lisp to me as the language that would "tick all my boxes", I've been doing a deep dive. Right now, I'm working through SICP again with DrRacket. The first time I worked through it with MIT Scheme MANY years ago. It's shocking how much I've forgotten. What I like about this article is that it walks through the different "camps" of Lisp. Scheme is so intriguing to me because of…
For what it's worth, Scheme was the first programming class that I took at UIUC around 1995, as I recall.
I had used C++ for several years to make shareware games, so I took a test to challenge some programming courses. I vaguely recall doing well, but my advisor encouraged me to take them anyway. I'm glad that I did, because I had little understanding of theory.
Funny story: the instructor never mentioned that we could use more than one line of code. So every single piece of homework that I handed in, and every test, was one giant line of nested logic. Which worked better than one might expect, and completely changed how I wrote code from that point forward. That's how I made the connection a decade later that functional programming is akin to a spreadsheet, as are higher-order method chains and immutable variables.
I think of Clojure as being a layer above Lisp, sort of like how Swift might be considered a layer above Objective-C/Smalltalk. However, bare Lisp has problems around not quite giving enough out of the box. It's minimalist enough that developers end up reinventing the wheel for things that should probably be provided by a layer/library similar to Scheme or Clojure.
To digress, I feel that mutable variables and even monads are a code smell in functional programming since they can cause impurity. They're more of a crutch to ease conversion of code from imperative languages. However, monads can be useful to simulate every path through a program, sort of like superposition in quantum mechanics and SAT solvers. So they aren't necessarily bad, just taught incorrectly, probably because they're so hard to grok.
I'd vote to settle on a series of layers like Common Lisp -> Scheme/Racket -> Clojure/Elisp, with the final layer providing the intersection of features available from the most widely-used Lisp variants. Note that this is specifically to form a bridge from imperative languages, so research work might need additional DSL features brought forth from the Racket layer.
Edit: I forgot to mention that Scheme is a good fit for genetic algorithms, see books by John Koza (no affiliation). My feeling is that we haven't seen anything yet regarding what problems AI can solve, since it's having to do it the "bare hands" way with LLMs and pattern matching.
Re: A Road to Lisp: Which Lisp
#80I'm going to take the opposite position that there is much less special about Lisp than people think. Like I have met so many programmers that travel around like itinerant martial artists looking for true functional programming and they never find it. To 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 ma…
Except that CPython still misses on (compile .....) part, indeed holding the industry back.
it compiles to bytecode but the bytecode engine is not that fast.
i had a phase when I was using PyPi a lot for branchy "old AI" kinds of workloads and felt it was an easy win but since then it has been either numpy or PIL or pytorch doing the heavy lifting or scripty stuff like uploading files to S3 where performance doesn't matter a lot.
I will grant that Common Lisp can be compiled to run amazingly quickly!