Probably above my pay grade, but as I see it the issue is how we typically relate to the world that causes this kind of sadness, rather than the fact itself. It's like, even though I consciously understand nothing lasts forever, I can't help being sad by it. Some deep structure of my mind won't accept it. The aim of Buddhist insight meditation is, as I understand it, to get to a deep enough level of your mind that you finally accept this at your core. This brings about freedom/liberation, as from then on you're able to just go with the flow without the slightest desire for permanence (or anything really). At least, that's the sales pitch.
"split-string" works well for this situation but for a case where there are commas inside some of the strings it would chop in the middle of those strings. So for the latter case and assuming the commas are consistently formatted, a safer approach might be starting in front of the first s-expression and then traversing to the tail of each s-expression with "forward-sexp" and check to see if a comma is there as expected and then delete the comma there (except for the last item with no comma) .
Yeah that's the classic comma in CSV problem. The solution is to indeed use a proper grammar/parser. The "forward-sexp" understands that as per major-mode rule as you say. Another more modern and declarative solution would be to take advantage of the full parse tree at your disposal thanks to tree-sitter (available in Emacs 29.1). Then you can simply do:
(let ((list (treesit-thing-at-point "list" 'nested))
(query "(list (string (string_content) @item))"))
(cl-loop for (_ . item) in (treesit-query-capture list query)
collect (treesit-node-text item t)))
Beautiful (parenthese tree), powerful, energy efficient (http://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pape...), standardized, battle-tested, and with a glorious past, Lisp reminds me of Gollum's "the precious" ring in Peter Jackson's "The Hobbit" series, and just like the ring, it can make one invisible just by using it too. Maybe it's one of those "precious" tools out there, being the best or not.
> but then you're the only one that knows your language
This only applies if the language implementation is complex, the language syntax is unlike anything in existence, and the language creator does not pick good names for functions and variables nor write any documentation, manuals, or papers to explain things nor he/she is available for any questions.
I don't think that's true. What you describe is a language that's hard to learn. But plenty of people already have a moderatly hard time when switching languages, or when using languages inside languages. One example would be SQL. SQL is a great DSL for relational databases, but many people never really embrace it or learn it "properly".
If by "this domain" you mean "strong type-checking", I guess it is because the CL's feature of on the fly introspection/debugging/modification is not as emphasized in some static type-checking languages, the lack of compile-time strong type-checking feature in CL, the ease to modify CL's compiler behavior via macros/reader-macros/compiler-macros (which facilitates implementing compile-time features like strong type-checking at compile-time); and perhaps also due to CL having been used in language research and in production for some decades.
As I understand it, macro is at a metalanguage level above the current code (eg. C macros vs C "normal" codes). In lisp, this metalanguage is in lisp forms, and thus it is parsed by ... the very same lisp parser for the code. Therefore the whole language is available to you at this meta level, and for all the meta levels above this meta level (ie. for macros that build other macros), so it's lisp all the way up.
I only know Lisp at a really basic introductory level, but knowing a different homoiconic language my understanding was that "macros" aren't even actually a meta-level thing in these - it's just the language being able to manipulate itself. Using it like this just gets called "meta-level" or "macros" to keep a cleaner separation for developers to reason about.
It feels more bolted on than in, say, REBOL, where there aren’t separate macros because functions can selectively take any or all of their arguments unevaluated, as a value but not fully evaluated, or fully evaluated.
(Which isn’t to say the Lisp way is worse; there’s strengths and weaknesses of both.)
> much of the things that made Lisp attractive before are already available in Python, Java, etc. and I see no "enlightment" in learning Lisp.
I have not found englightenment either, but I could not find another production-grade language that can model anything like a tree (eg. abstract syntax trees) and let its user extend the language itself without the language authors.
