Homoiconicity is an ill-defined concept. If you take every subjective feature from it, all it implies is that you are able to cut your code into well defined AST structures (what all languages have, but for some it's easier than for others).

So, yeah, anything people do with Lisp could be done for any other language, it only requires more complex tooling. How much more complexity depending on the language, and it varies from "barely perceptibly more" into "that's completely not practical".

To me, "only" and "complex" shouldn't be used in the same sentence. Big part of the job of a developer is to reduce complexity, and we barely do it (depending of the system). What is "barely perceptible" now can be "completely not practical" 2 years down the road.

It's a well-defined concept in theory but in practice it is not:

https://www.expressionsofchange.org/dont-say-homoiconic/

https://news.ycombinator.com/item?id=20657798

Maybe it's not required. However, I can confidently say Clojure in emacs feels like an entirely different development experience than my daily Python work in PyCharm/VSCode and C# in VS. I recommend trying it out if you haven't already.

And I recommend trying out Smalltalk.

As a hobby I want to learn a lisp. Where should I begin? :)

MAL. AKA Make A Lisp. Instructions to write a tail recursion lisp interpreter in a weekend in almost any language. It teaches almost anything you want to know about lisp, plus some practical compiler/interpreter knowledge.

Install sbcl, slime, gnu emacs in some form.

See the book Practical Common Lisp for an intro: https://gigamonkeys.com/book/

If you want to see how Lisp environments used to be on the hey day of Lisp, check the community editions from Lisp Works and Allegro Common Lisp.

Scheme is a nice start. You can write a basic interpreter for it over the course of a few weeks

There is a significant, qualitative difference between using a language that designed for REPL use and one that isn’t.

Those boundaries you talk of are the crux of the issue. A highly dynamic, completely expression based language is going to enable a much different experience. Homoiconicity also plays an important role here, because you can ispect and parse code within the language, with the same functions and algorithms as everything else.

Indeed; I do this every day with Vim and its term command, with Julia, Python, bash, Elixir—it works with any language with a REPL of any kind.

I am not familiar with how Julia and Elixir work, but form my experience Python’s REPL is not the same at all as REPL in Clojure or other lisps.

In Clojure, you literally built your program in memory while you’re writing the source code file, updating the memory representation of your running program part-by-part without ever stopping it.

This experience is absolutely magical, and it’s very hard to go back to edit-compile-run loop in other languages after that. It is completely different from “my language has a REPL and I can execute parts of code in it”.

No, Julia and Elixir are the same as Python in that regard (Python is more annoying because of the indentation problem). I was just talking about interactive evaluation of expressions selected in the editor. Although I’ve messed with Clojure a bit, I admit I don’t fully appreciate what you’re describing. I’m a little afraid to find out, frankly, because it sounds seductive.

Julia is much closer to Clojure than to Python in this regard, which brings back the point from above that homoiconity isn't the key ingredient

How so? In julia, one problem is that you can’t redefine datatypes in the REPL. You need to restart.

Yes, that restart is painful exactly because it interrupts the "built your program in memory while you’re writing the source code file" OP talks about.

my inkling is that the more special forms the more difficult it is to repl a language. if everything is an expression not only can you eval parts of it, but that is enough to support quite a bit of extensibility sans macro.

a comment here some time ago explained nicely what most of these "unique" advantages of homoicinicity are actually about; it was essentially another step on the same spectrum of statement-languages and expression-languages.

in particular this does not mean that it is better but the same advantages of being able to put anything into anything that you find in expression languages like rust in lispy languages are also syntactically in editing source code.

since I started using shrink/grow selection in vscode I have much increased interest for simple syntax aware editing, something simple would be moving blocks of code token by token

Not only that, Smalltalk, Mesa and Mesa/Cedar workstations, all shared the same interactivity as Interlisp-D at Xerox PARC.