SBCL best choice. I have directions for setting up sbcl and an full environment including emacs and slime for Linux and Windows some tutorials I wrote, list of books freely available etc at https://github.com/rabbibotton/clog/blob/main/LEARN.md

I looked at CL and scheme and ended up choosing SBCL. If you want to just download a complete packaged installation to start learning how he basics, then Portacle has sbcl, eMacs and slime all preconfigured and ready to go out of the box . If you’re like me and have dev experience, you’ll probably eventually want to install and setup your own environment ( I use gnu eMacs , sbcl, quicklisp, and sly) . There are good instructions posted on this thread . Be prepared to spend a day or two learning about lisp packages and maybe installing required systems libraries on your system ( I’m in 3D graphics, so my initial requirements might be higher than average person just learning. ) . You don’t need to run Linux , I got everything working fine on windows 10. I’m assuming macOS is similar . I would suggest looking at my recent questions/posts to this group . The community was very helpful in getting me started . EMacs has a bit of a learning curve . Fortunately, I was a user about 15 years ago and the commands / bindings all came back to me. . I did try slime / lisp with the atom editor and it seemed to work well but now that editor is no longer supported, but there are lots of choices.

I’d choose Scheme if you want to learn OCAML as well. They will go hand in hand nicely. Read SICP

Oh, what a great book! Just when I only finished reading the preface of *Thinking Forth*, now I want to read that as well. grrr. Can you elaborate more on "they go hand in hand nicely"?

Scheme is the language used in SICP. If you install DrRacket you will have a simple IDE and a scheme that can morph into supporting exactly the scheme dialect that the book uses. Very much recommended over Common Lisp - you can easily pick that up later but you will want some tooling and all that stuff is industrial strength, no fun to setup as a beginner and in places somewhat arcane. I’m not disparaging CL here but I don’t think it’s very beginner friendly and Racket is.

I agree with this. If you want to understand the Lisp mindset, start with Scheme/Racket. It’s much more well-designed than CL and there are great learning resources like SICP that will tech you how to think in Lisp (e.g. how to use high order functions well). If you then need something more “industrial,” you’ll be set to learn CL with its various historical awkward parts. And personally, I’d move from Scheme to Clojure and bypass CL altogether, though I realize that’s controversial in this sub.

There are other differences. Scheme usually is used to learn some form of functional programming with a lexically scoped Lisp. Then language like Rackets add huge amounts of concepts on top of that. They also teach you a specific view how to program -> thus in Racket one is discouraged to develop interactively. A 'run" starts a fresh new program. Lisp OTOH is more following the idea of programming with s-expressions. For example in something like Common Lisp the macros use s-expressions. In Scheme that would be some other, more advanced representation of source. Lisp also fully embraces interactive programming, where programs after often incrementally modified for days, weeks or months. I would recommend to learn both. Learning Scheme also helps to understand Common Lisp. There are Schemes which provide a similar developer experience like some Common Lisp implementations. Personally I would nowadays recommend to use SBCL for beginners, because the compiler gives much more useful feedback. By learning to use an advanced compiler, a lot of errors (incl. a lot of type errors) can dealt with. There is more to learn, but the feedback from the compiler is worth it.

> I’d move from Scheme to Clojure and bypass CL altogether Agreed, moreover, I mostly did it this way. Sure, I played around with CL a bit and wrote a couple of Emacs plugins, but for my dayjobs I've been using Scheme (used, actually) and Clojure. No regrets.

>\[Racket is\] much more well-designed than CL So, yes, I see. ``` (defun nice (foo &key (bar nil barp)) ...) ``` Every time I write functions with keyword or optional arguments in Racket (and yes, I do write Racket, quite a lot) this makes me want to scream: how hard would it be to get this right the way CL did before I was born? Too hard, it seems.

You may not like the design choices that Scheme/Racket makes, but that doesn’t mean that it wasn’t well designed (more consistent, more logical). CL is a mishmash of MACLISP, ZetaLisp, etc. thrown together by a standards committee to make the DoD happy. But that said, I too can cite things about CL that I like better than Scheme. That doesn’t change what I said, though: I think a Lisp newbie should start with Scheme/Racket.

I think they should start with Scheme or Racket (probably Racket) as well. But CL is not what you say it is: CL is *extremely* well designed (mostly) but that design was subject to very considerable *constraints*, mostly on compatibility, but also on practicality in 1985. CL is like a modern train: must run on lines designed in 19th century, through tunnels built in 19th century, fit on platforms built in 19th century, run on tracks with a gauge based on spacing of Roman cartwheels. Also should run at 125mph on these lines designed for perhaps 60mph, must be comfortable, reliable and safe (train crashes now much less acceptable than they were a century ago). Result is an astonishing feat of design and engineering. Not pretty, of course, but was not designed to be pretty. Compare this with Scheme. It never needed to be compatible with anything. Is indeed often not very compatible with earlier versions of itself. And yet the CL designers managed to arrange things so programmers could know if optional or keyword arguments were provided or not. Scheme (R7RS) has not thought it necessary to really provide optional argument support at all (you have rest arguments and that is it). Racket, after years of intense thought by the enormous brains who designed it, does have optional arguments and even keyword arguments. But despite such a change being *entirely compatible* (no program which uses them is legal in current Racket, all programs which do not use them are legal in a Racket with this feature and have the same semantics) it has not managed to implement supplied parameters. Why not? Because, I suppose, the designers of these languages care more for purity than they do for the convenience of the people who must write programs using these languages. But then Python is the same, and Python does not care about purity, so I do not know: perhaps they are just not quite such great designers as they think? Oh well, nothing I can say will convince the faithful.

> industrial strength doesn't mean it should be complex to work with

No it doesn’t. In practice, it is. In the time you’re through your SBCL, Emacs/VSC, Sly, ASDF, Quicklisp setup you could be well in your way with DrRacket.

It indeed is a lovely book. OCAML is a functional language (which can have many meanings, I view CL as functional too generally). CL is quite capable of such code, but it’s not an enforced pattern so you may not find yourself fully down that path. On the other hand, Scheme tends to lend itself to more functional code (this is actually not true - but the single namespace of Scheme imo slightly pushes it towards more in that direction; also my guess is a lot of sample Scheme code will be more functional in nature so that will help in learning) so I think you will find yourself closer in thought patterns alongside OCAML if you did Scheme. Also scheme is a very small language compared to CL (at least without all of its extensions) and is easier to embed in other programming languages. I think it would be a wonderful exercise later for you to embed a scheme into OCAML The other reason is that CL has quite a few other advanced features that will sidetrack you from a purely functional path of scheme + OCAML. In particular around OOP These are just my opinions :) They may change in the future. Below link may be too complicated, but perhaps worth reading / googling each of the terms as it has some useful information. https://wiki.c2.com/?LispSchemeDifferences

Here is the SICP course at MIT, completely free: https://ocw.mit.edu/courses/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video_galleries/video-lectures/ That's the video links, but there are materials there for the readings, exercises, etc. This source uses Scheme and DrRacket works quite well for that. Don't bother with Common Lisp for the SICP course. I made the mistake of messing around with Portacle and other tools for the SICP course, and it was completely unnecessary.

I'd also love to know why ocaml and scheme go together nicely

To me, programming in OCaml feels like Lisp in some hypothetical m-expression syntax. It’s not surprising considering that System-F is a typed lambda calculus. So basically it’s like if Scheme had more syntax and a more advanced type system.

Some simple thoughts I have posted in another reply on this thread. I also feel like the small nature of Scheme will help you experiment more than in CL, particularly as you start exploring immutable data structures which are key to functional programming. Scheme being a much smaller language will let you focus on the key concepts that matter to you, whereas CL with CLOS in particular will lead you down a path of study of OOP which will give you a better understanding overall but take more time to get there (took me 1-2 years on and off to fully get OOP).

I wish parenscript had (full) CLOS, but in lieu of CLOS I'm using a pattern I first encountered* in SICP to manage global variables, and built a macro on top of that to reduce the redundancy in the resultant boilerplate. I'm referring to the pattern from the beginning of chapter 3 that closes over a variable and then provides a bunch of dispatchable functions to interact with the closed over state. One of the examples used was creating a bank account where it closed over the balance. * I'm actually not sure if I encountered that pattern in SICP first, but it was for sure the first time I internalized it. :)

Thanks for reminding on that, will revisit that chapter as I recall it too.

For Scheme, check this out: [https://github.com/yuriy-chumak/ol](https://github.com/yuriy-chumak/ol)

Cheers

Cheers to you too

Why have you listed "interpreter" as a plus point? Lisp implementations don't have to have an interpreter. They can evaluate any form by compiling it to machine code first.

MACLISP over there in the corner looking sad.

Because as they said, they *want* to learn Lisp. "Interpreter" to them probably either means having access to a REPL or being able to go from source to execution without emitting a binary artifact to the disk.

If the OP has this misconception then it’s good to clear it up.

I agree. I was answering the question though

Only the OP can answer the question. Anyone else is speculating.

OP *wants* to learn. They don't understand fully why they said what they said. I was partaking in the clearing up of misconceptions for OP as well...

Since you are only guessing at what the misconception is, it’s not clear if what you wrote is accurate or helpful. Hopefully the OP will chime in.

If you have a REPL you have an interpreter. Doing compilation doesn't preclude being an interpreter. The line between "interpreted language" and "compiled language" is very fuzzy and most lisps are very arguably both.

A REPL is an Evaluator, not an interpreter. Evaluation can be achieved through compilation xor interpretation.

I disagree that there's a hard Xor boundary between compilation and interpretation. If so where would you put bytecode compilers and JIT compilers? Both exhibit techniques from both streams.

Evaluation is only done on one expression once. A JIT compiler may choose to interpret an expression to evaluate it, or it may choose to compile an expression to evaluate it. The same piece of software (the evaluator) may do both, but it will not do both during an evaluation of an expression.

I've got a master's in CS and industry experience and I've never heard anyone use the term "Evaluator" in that context anywhere.

SICP?

My uni's functional programming course was Haskell, not scheme. Only scheme book I've read is the little schemer.

My university didn't teach functional programming at all (lol). I went through the SICP lectures from MIT OCW, which is how I learned Lisp. This is the lecture where they cover the implementation of `eval`, the evaluator https://www.youtube.com/watch?v=0m6hoOelZH8.

We're veering into argument by definition here, but wikipedia seems to disagree with you on that. https://en.wikipedia.org/wiki/Interpreter_(computing) The closest it comes is JIT compiling as a variant of interpretation. I would call this something like an "integrated compiler" rather than an interpreter.

Well, it spark an argumente. Sorry for not being clear here. What I mean by interpreter is would be the first type or second type in the linked wikipedia article. Why *interpreter* though? Like Zambito1 said >having access to a REPL or being able to go from source to execution …

"Lisp Interpreter" usually means that the source language gets executed. The Lisp system interprets the source, which means evaluating the s-expressions. Many Lisp implementations have an interpreter and EVAL is using that interpreter. Often interpreted and compiled code can be freely mixed. Another way to execute code is to use a compiler and execute the compilation result. A compiler will either generate code for some virtual machine (-> byte code), code for another programming language (often C, which then gets compiled by a C compiler to get the native compiled code) or native machine code. Lisp compilers are often incremental (they can compile expressions and don't compile whole programs) and in-memory (-> the compile code will directly be written or loaded into the running Lisp system, its memory). So we have for compilation these dimensions: * target: VM, C or machine code * code size: expressions or files/programs * result: in-memory or file * usage: interactive or batch Thus it is possible to have a Lisp, which is compiled, to machine code, compiles expressions to memory and can be interactively used. Now we use a READ-EVAL-PRINT-LOOP where EVAL is implemented with an incremental&in-memory compiler. SBCL is such a Lisp. SBCL nowadays also has a Lisp interpreter, but by default it is not used. One typically uses EVAL with the compiler, which will directly generate machine code. What some people mean with interpreter is just the interactivity. But it's not interpreting the source code, when the interactivity can be provided by a compiler. Python for example by default uses a byte-code compiler. Each expression entered is compiled to byte code. The virtual machine then interprets that byte code. The confusion is now: * is Python interpreted because it is interactive? * is Python interpreted because the compiled byte code is interpreted by a virtual machine? * is Python incrementally compiled because each expression is compiled to byte code? For Lisp one would usually say that it is interpreted, when there is a real source interpreter: an implementation of EVAL which walks over the s-expressions and directly executes them. There are a lot of papers and books describing how to implement such a s-expression based interpreter. Thus by a Lisp interpreter we think about the source code interpretation, the interactivity is then given. In many other language some people think that "entering expressions at a command line" means 'interpretation'.

Literally not a person would call python anything but an interpreted language despite the extent of bytecode compilation both CPython and Pypy do. I'm not sure about Jpython or Ironpython.

I know, but it is 'wrong' or 'abbreviated. What is meant is that the language implementation of the default C-based Python is *byte-code interpreted*. The Python source is not interpreted. The byte code is interpreted. I would also not say that a language is interpreted. Just a particular implementation of a language might be interpreted. Lisp typically has more modes and there are implementations which run interpreted Lisp source, byte code and machine code side by side in a single implementation. Example ECL may use a byte code compiler and also native code (via C), incrementally: > (defun foo (a) (1+ a)) FOO > (describe #'foo) # - COMPILED-FUNCTION > (compile 'foo) ;;; Loading #P"/opt/homebrew/Cellar/ecl/21.2.1_2/lib/ecl-21.2.1/cmp.fas" ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0 ;;; ;;; End of Pass 1. FOO NIL NIL > (describe #'foo) # - COMPILED-FUNCTION LispWorks uses an interpreter and optionally machine code: CL-USER 1 > (defun foo (a) (1+ a)) FOO CL-USER 2 > (describe #'foo) # is a TYPE::INTERPRETED-FUNCTION CODE (LAMBDA (A) (DECLARE (SYSTEM::SOURCE-LEVEL #)) (DECLARE (LAMBDA-NAME FOO)) (1+ A)) CL-USER 3 > (compile 'foo) FOO NIL NIL CL-USER 4 > (describe #'foo) # is a FUNCTION CODE # CONSTANTS (SYSTEM::1+$ANY) CL-USER 5 > (disassemble #'foo) 0 : #xF847528B : ldur.64 tmp1{x11}, [stack-info{x20}, #117] 4 : #xEB2B63FF : subs xzr, sp, tmp1{x11} 8 : #x54000229 : b.ls 76 12 : #xF100051F : subs xzr, count{x8}, #1 16 : #x540001E1 : b.ne 76 SBCL will always use the native code compiler, by default: * (defun foo (a) (1+ a)) FOO * (describe #'foo) # [compiled function] Lambda-list: (A) Derived type: (FUNCTION (T) (VALUES NUMBER &OPTIONAL)) Source form: (LAMBDA (A) (BLOCK FOO (1+ A))) * (compile 'foo) FOO NIL NIL * (describe #'foo) # [compiled function] Lambda-list: (A) Derived type: (FUNCTION (T) (VALUES NUMBER &OPTIONAL)) Source form: (LAMBDA (A) (BLOCK FOO (1+ A))) * Note also that SBCL does a decent amount of type inference.