Thanks, that is a great site! Will have to look at more, but looking at examples like the following, I'm not having a Lisp Aha! moment when I compare the Lisp and Julia/Python implementations, e.g.,
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.
I don't think anyone should expect to get an "Aha! moment" from looking at algorithmic code. That's going to be the same in most languages.
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.
Since there are other decent dynlangs out there, the benefits are less about the surface language aspect, and more about the process of getting to a solution. These are the system aspects of lisp that enable an incremental development workflow with a lightning-fast feedback loop. While there are important language features that support this, it's ultimately a "whole is more than the sum of its parts" effect.
I'd recommend checking out videos of people developing systems in lisp. Off the top of my head:
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.
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