Got a link to fairly simple examples comparing Lisp solutions to those in another more 'mainstream' language (e.g., C, Python, BASIC, Java) that illustrate the benefits of using Lisp over another language for a 'practical' application? Thanks!
It depends on what you're trying to get out of it. For example, you can grab a simple code of some React components with JSX and ask ChatGPT to write it in Hiccup (Clojure). That would show you how s-expressions can reduce the syntax boilerplate and make it smaller. You can do the same thing with Lua and Fennel - Fennel code would be much shorter and cleaner.
However, without proper understanding and using structural editing and connected REPL, you probably won't see any benefits right away. Lisp code is not the best to be read off the "dead medium" - paper or screen. It's better when you have a connected REPL because it allows you to evaluate every single expression on the fly. Instead of trying to understand what (foo x y z) means, you can evaluate it and immediately see the results. With a connected REPL, you can evaluate them separately (individually), or together. Good talk of relevance: "Stop Writing Dead Programs by Jack Rusher" https://www.youtube.com/watch?v=8Ab3ArE8W3s
Next step in understanding the benefits of Lisp code is learning structural editing. Because everything is a symbolic expression, you can easily move, transpose, change, and replace parts of your program. Instead of rewriting a function of seemingly arbitrary syntax constructs, you'll be dealing with well-structured forms that you can easily move around. No, it not the same, better or worse than using refactoring features of your IDE with other (non-lispy) languages. It's just different.
These two aspects - REPL and structural editing - are really difficult to explain; one has to experience them in person to see if that way of writing software feels appealing to them. And yet, without grokking the basics of these two essential things, IMO, the Lisp experience will not be the same, and you may not get why some people get really excited about Lisps.
And If you're truly looking for a brain-bender, check out https://github.com/hyperfiddle/electric. Dive into the concepts, play with the example demos, and see where it takes you. But be warned: it's an incredibly dense project and definitely not for the uninitiated. If you haven't written in Clojure before, chances are you won't fall in love with its ideas overnight. But it's a good example of "practical applications" that are difficult to achieve unless you're using a Lisp.
https://rosettacode.org/wiki/Category:Common_Lisp
This has a lot of problems solved in multiple languages.
Cheryl's birthday https://rosettacode.org/wiki/Cheryl%27s_birthday
Seems like part of the problem is that Lisp is often demonstrated with examples that your average programmer can turn to 'black box' pre-built functions/packages/software for. That Lisp can help one extend a programming language to add a CASE statement, for example, is not going to win the hearts and minds of those who are already using a programming language with a built-in CASE statement. It may be neat from an intellectual standpoint, but not from a practical one.
And the merits of the example linked to below of how Lisp can be used to implement an in-memory database will surely be completely lost on anyone with access to in-memory database software like DuckDB.
Practical Common Lisp: An MP3 Database https://gigamonkeys.com/book/practical-an-mp3-database
DuckDB: SQL Introduction https://duckdb.org/docs/archive/0.8/sql/introduction.html
If you want a "Lisp Aha! moment" you'd probably be better off looking at something that's actually Lisp-centric like Paradigms of AI Programming by Norvig (https://github.com/norvig/paip-lisp). You eventually build up to a Prolog to CL compiler written in CL.
You have to write code and experience it.
I mean, of course it has same cool constructs, but, at least for me, its the experience of writing code with it that makes it shine. And that kind of thing is intangible.
The iterative development experience is part of it. But, at least, the code I write has a rhythm to it, and I don't write other languages the way I write Lisp. Even at the 10,000 foot level, it's mot the same. For example, I tend to write more, smaller functions. Like Forth, its very easy to refactor Lisp. Being iterative and interactive, it supports and encourages that kind of thing.
Write a little thing, test it. Write another little thing, building on all the other little things, test those. (Note, not "write tests for them", just...test them. In the listener. "Good! Moving on!")
Find something that interests you, preferably something that's not "let's glue all of these other libraries together". Something that's going take 500-1000 lines. And, just write. Learn as you go, don't worry about being idiomatic.
See if anything pops from that.
I'd recommend checking out videos of people developing systems in lisp. Off the top of my head:
- https://www.youtube.com/@CBaggers/playlists
- https://www.youtube.com/playlist?list=PLTA6M4yZF0MzsMlNL0N67...