[zaphar]

Ignore the war. Just pick a lisp, any lisp, and then learn it. It's not necessary to pick a side nor does it really matter which lisp you pick. You can pick a side later if you feel the religious fervor sweeping you up. But really Lisp is sufficiently different from pretty much any language you'll have encountered that it's worth taking a look.

[at_a_remove]

No, I do not worry about feeling fervor. I tend to be intensely repelled whenever I detect that sort of thing in others.

I must select a side because I have to install something. The problem I have had with this approach is that, through the clouds of dust and smoke, through the constant shelling and the screams of the dying, I cannot seem to discern which side has that bare minimum set of properties that I want. Namely, can run on Windows without it being a ridiculous exercise in hackery, comes with a robust set of libraries that I can end up using it to solve actual problems I might eventually receive money for solving, and has enough study material to lead me through it.

None of these are negotiable to me and as far as I can tell, these objectives haven't even been considered by the various sides in this forever war. And so I will do what I always have done, which is take a peek, observe the chaos, and then wait another five years to see if anything has gotten any better.

I did the whole "enlightenment" thing once with Prolog. It ended up not having any impact on anything I wrote. The enlightenment wasn't portable. I could not use it to solve actual problems I had. I could use it to solve toy problems in a toy world, and maybe there are spots where it could have overlapped with a part of the world I wasn't in, but I wasn't going to migrate just to find a way to get paid using Prolog. At the end of the day, I was still chopping wood and carrying water.

[krapp]

>Namely, can run on Windows without it being a ridiculous exercise in hackery, comes with a robust set of libraries that I can end up using it to solve actual problems I might eventually receive money for solving, and has enough study material to lead me through it.

Racket seems to tick all of your boxes, IMO. Also maybe Clojure. I've gotten both to work without much problem on Windows, both have an ecosystem and plenty of tutorials.

[w3mmpp]

Go with Emacs + Slime + SBCL, they're very stable on windows, then install Quicklisp: https://www.quicklisp.org/beta and you're good to go.

[int_19h]

If the dialect of Lisp picked does not have full-fledged macros, then it's not really sufficiently different from many other languages.

[zaphar]

All you really need is quoting and eval to get something close enough to macros. Most Lisp dialects will have that much.

[int_19h]

If you consider that to be sufficient, then what difference is there compared to any other language with eval?

[zaphar]

It's about ergonomics. Technically if I'm willing to grab a library to parse the AST and hook into the compiler/interpreter backend then I can replicate what Lisp let's me do in any language that exists. But there is a pretty wide gap between how easy that is in say... C++ as opposed to Lisp. Some languages get a lot closer than others but I would argue that with the exception of Forth or perhaps TCL none of them make it anywhere near as easy Lisp does.

[int_19h]

The line between "language" and "library" can be very blurry - it certainly is in case of Lisp.

Suppose we take something like Python, which has a standard library module to parse ASTs, modify them, and eval them. It might look a tad more ugly than Lisp (esp. with quoting and unquoting), but I don't see why this should be considered a fundamental difference, enough so to justify its use as the sole determining factor of a "true Lisp".

And besides, what about popular languages that do have full-fledged macros? Say, Rust or D.

[zaphar]

The point is still about ergonomics though. The AST for Rust or D is still complicated enough that you typically won't do the kind of thing you might do in a lisp just due to startup cost. Lisp because of it's extremely limited syntax makes it considerably easier. The sorts of things you'll feel free and capable of doing in a lisp macro are ergonomically harder to do in a Rust or D macro.

You might argue, quite convincingly, that Rust and D have valuable ergonomic barriers to doing some of those things since macros have a non-trivial cost in your codebase regarding complexity and readaiblity. But the ergonomics of a macro is Lisp are pretty close to the optimal for ease of use.