[kerkeslager]

I'm saddened by your story. Our programming communities can be more welcoming.

That said, I think these debates are necessary. Fixing problems starts with deciding what the problems actually are. The problem isn't that the debates are happening, it's that people like you are getting dragged into them.

You aren't obligated to participate in debates. Nor do you have to use the absolute best version of Lisp to get most of the benefits.

My advice is to pick up a copy of MIT Scheme (works on Windows) and then work through Structure and Interpretation of Computer Programs (SICP), and don't read anything else about Lisp until you're done, because you don't need to.

MIT Scheme isn't the best Lisp. It's just the Lisp that's used in SICP. You won't win any debates arguing that MIT Scheme is the best Lisp. You might even hear people say MIT Scheme isn't even a Lisp. I agree with some of that, but those debates are irrelevant to your learning.

Feel free to hit me up with any questions. I certainly have opinions on all the holy wars, but I won't bring them up, I'll just help you with the task you're working on. :) I'm not a Lisp expert by any means, but I've worked through most of SICP.

[at_a_remove]

I have looked over the site once a long time ago, when I had a copy of SICP in hand. I just looked now.

What I do not see is a robust set of libraries that can help me accomplish the solving of real-world problems. As mercenary as it sounds, I program to solve problems my employer has in exchange for money. I solve problems that people have, rather than problems that books abstractly propose. While Lisp or whatever dialect might be lovely, it may as well be Logo for practical tasks. I do not want to re-implement JSON. I do not want to try to write my own ODBC. I need something beyond a language that lets me solve the problems written in a book that is divorced from real-world stuff, and that has, for the past couple of decades, meant libraries.

"The Lisp Curse" is a pretty good explanation of why I won't see those libraries and the situation hasn't changed, that I can see, since I first read it.

At the end of the day, if I want to learn a language, I want to have done it for more than the sake of having said that I have climbed that particular mountain. I need something up top that is valuable. Climbing it has to have real-world applicability to me.

Can I use Lisp to interact with these GIS formats and solve real-world problems? Not without building my own libraries, and so on. This is why I have liked the war metaphor: all of these folks skirmishing when they could be building factories.

I am not asking for Lisp to be Python or Perl or whatever. But it should have a great standard library. Where is this?

[jerf]

"What I do not see is a robust set of libraries that can help me accomplish the solving of real-world problems."

I think the suggestion wasn't to give you the One True Answer to which Lisp to use. The purpose of suggesting working through the SICP book is to give you in concentrated, curated form the insights that Lisp is supposed to bring, whereupon you should turn around and bring those insights back to whatever normal programming world you inhabit. To the extent it is divorced from real world stuff, yeah, that's on purpose, and the entire point of the recommendation of SICP.

Fortunately, the world has changed since the SICP was written. At the time, there was a much larger barrier between Lisp and the "real computing world". While by no mean do all languages look like Lisp now, there has been a lot of seepage, and now there's plenty of languages where you can bring the stuff in SICP into the language you use day-to-day.

The idea is this: You could learn a new language, a couple of frameworks, half-a-dozen libraries, fight through bugs in all of the above in some immature cutting edge library, and also fight through a lot of accidental complexity because you accidentally selected some task that the weird new language is not very good at, only to arrive after all of this with some new insights about how computation works and what languages can do after a year or two. Or, this suggestion is, learn a very small new language and read a guide book, get the concentrated insights in a few months at most, and then continue using the frameworks, libraries, and experience you already have.

(Personally, I recommend SICP as the perfect companion to any self-taught programmer. It is almost laser focused on the sorts of things that the self-taught programmer will find hardest to pick up on their own. Finish it and you really will be able to code circles around most college grads, beating them both practically and theoretically.)

[at_a_remove]

I did this once with Prolog and did not come away with the benefits espoused. I was told that it would really change how I thought about things and so forth. That didn't happen. I didn't get anything out of it that I could bring elsewhere. I fear the same result after a similar investment in a similar situation.

[kerkeslager]

shrug That's the risk you take whenever you learn anything new--maybe it won't be useful.

The alternative is, of course, never trying anything new or learning anything ever again. Your call!

[kerkeslager]

Thanks for your comment, you really grokked what I as trying to say previously and said it better than I did.

[kerkeslager]

Racket and Common Lisp probably both fit the bill for what you're saying. Racket is more "batteries included", while Common Lisp has a wider variety of third-party libraries. Both have mature JSON implementations.

That said, I think you're underestimating the value of learning Lisp with no intention of using it to solve real-world problems. There are some big benefits:

1. It shows you a different way to structure programs, which I think is simpler and more powerful than OO.

2. It's a lingua franca of academia, which allows you to read a lot of papers you wouldn't otherwise be able to read.

3. For better or for worse, Lisp is a secret handshake that will get you into a lot of clubs. I've gotten more than one full stack Python/Django/JS job offer after interviews where all we talked about was the Lisp implementation on my GitHub. And while you definitely don't need Lisp experience to write full stack Python/Django/JS, there are jobs which require FP experience for good reason, even if you aren't writing in a very FP-focused language, especially if you're solving hard problems.

[snorremd]

Would Clojure fit your criteria? There are already a good chunk of Clojure libraries, but you can easily use Java libraries via interop, so all libraries on maven central is at your disposal.

It was made to be a pragmatical lisp for real world use and the syntax is somewhat modernised to make it a bit more readable and user friendly. Vectors and maps looks like they do in other languages. It also uses immutable data structures by default making concurrency and parallell execution very easy.

It also has reach running on the JVM, in the browser (ClojureScript), as native binaries (via GraalVM's native-image), and even as short lived scripts via a number of Clojure interpreters like Babashka, Joker, and others.

I've found Clojure to be a very enjoyable language. Granted I have not really worked with other lisps.

[bcrosby95]

If you're a Java shop you can sometimes use Clojure since it runs on the JVM. It has 100% access to Java classes which gives you a huge existing ecosystem despite the language being fairly niche.

From what I gathered when looking around some people don't consider it a Lisp, but it never bothered me much.

[threatofrain]

I’d advise using Racket to get up and going.

[peatmoss]

I did a lot of lisp bouncing, and am still what I’d call a mediocre novice. However the two lisps I found the most traction with were Clojure and Racket.

With Clojure, I liked the data structures, availability of libraries, and syntactic sugar. With Racket I feel like I got something almost as comfortable as Clojure, but without the baggage of the JVM (yes, I know the JVM is amazing—I still find it a pain).

The Racket documentation is pretty good. The guide, the reference, and the How to Design Programs beginning programming book all contribute something. I dabbled in How to Design Programs way back when I was learning R, and it certainly shaped the way I approached R... even infected my Python thinking a little.

[catalogia]

Agreed, specifically the the SICP #lang: https://docs.racket-lang.org/sicp-manual/SICP_Language.html