Comment by at_a_remove | Hacker News Reader

Comment by at_a_remove | Hacker News Reader

Parent Full thread

I have heard for decades how Lisp is transformative, how just having learned it, even if you leave, you will never look at things the same way again. Like having served in the Armed Forces.

Every so often I get interested in Lisp, but I always run up against the same conflicts. I look for something that I can run in Windows that has a reasonable set of libraries and then immediately stumble upon the Crusades. You know, the religious wars you saw with emacs vs vi, wars that used to be fought over various Linux distros and window managers, that you will now see about different flavors of agile or whatever. I am quite sure that there are religious wars being fought in the territories of Javascript frameworks that I've never heard of. These wars so often seem to leave the territories barren, the original objectives cloudy, and the participants scarred. What was this good for, again?

Anyway, every time I encounter these things I end up asking myself if I have the knowledge to pick a side in whatever war and if joining up is going to actually provide a solution to the problems I wanted to solve using programming, decide I am neither fit nor armed, and back slowly out of the room.

I dunno, Lisp is OK. I enjoyed my time with it. The problem with it is, while it may give feelings of transcendent power to the programmer, its real world deployed results are rather lacking, compared to such boring languages as golang, java and so on; or even more obscure ones like Ada or (trolling hard now, but true) Forth. From this alone, it is abundantly obvious its advocates are overstating its utility in solving problems.

The most obvious products of the Lisp world are computer algebra systems such as Reduce, Axiom and Macsyma, and these are all very old pieces of software, rather than something new and interesting used by millions. In fact, you might say the purpose of Lisp is to write the kinds of custom interpreter/compiler expert system/symbolic manipulation systems that people used to think were going to be "AI" in the 1970s.

Sure, our host made his fortune developing in Lisp; he might have done so using some other language. The most obvious lisp projects today are people .... developing new lisp dialects. I'm sure there are plenty of profitable projects in Lisp, just as there are in Delphi, APL and other older non-mainstream languages. But if Lisp were really all that amazing for building useful things, considering the number of people with a smattering of it, it would be used more often. Or at least you'd see more real world results from the Lisp community than you do.

Anyway, pick one up; it's a lot of fun, and it does change your views as to what is possible in terms of communicating with your computer.

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.

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?

"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.)

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.

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!

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

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.

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.

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.

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

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.

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

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.

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.

>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.

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.

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

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

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

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.

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.

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.

Reply on news.ycombinator.com