access VS cmu-infix

I like https://github.com/AccelerationNet/access

I agree you can make arguments, I like your explanation for the final form further downthread. For the second form, another choice could be (.x foo) or (. foo x). Or if you're trying to write something like System.out.println("x"), Clojure's .. shows it could be written as (.. System out (println "x")). Or, if you're using CL, you can use the access library (https://github.com/AccelerationNet/access) and write things like #Dfoo.bar.bast or (with-dot () (do-thing whatever.thing another.thing)).

In trying to further steelman a case where random Lisp syntax can be more difficult to read than, say, equivalent Python, two other areas come to mind. First is the inside-outness order of operations thing, it trips people up sometimes. Like the famous "REPL" (with a bad printer) is just (loop (print (eval (read)))), but in English we want to see that as LPER. Solutions include things like the arrow macro (Clojure did good work on showcasing it and other simple macros that can resolve this issue in many places) and if you write/pull one into CL REPL becomes (-> (read) (eval) (print) (loop)), how nice to read. But even the ancient let/let* forms allow you to express a more linear version of something, and you can avoid some instances of the problem with just general programming taste on expression complexity (an issue with all languages -- https://grugbrain.dev/#grug-on-expression-complexity ).

The second area is on functions that have multiple exit points. A lot of Lispers seem to just not like return-from, and will convert things into cond expressions or similar or just say no to early-exits. The solution here I think comes from both ends, the first is a broader cultural norm spreading in other languages against functions with multiple return statements and getting used to code written that way, the other is to just not get so upset about return-from and use it when it makes the code nicer to read.

thanks. Do you know how your cl-getx differs from access? https://github.com/AccelerationNet/access It is a universal accessor with the option of nested look ups.

ps: related: how to access an element in all the lisp sequences, generically? I like access for that: https://github.com/AccelerationNet/access (and generic-cl

Fortunately doing infix math in CL has since the 90s been one small library include away: https://github.com/quil-lang/cmu-infix

The Lisp version can also be more readable with a macro (like https://github.com/quil-lang/cmu-infix): #I(a(1.0-t) + bt). Or something else that would let you write GP's preferred syntax. One of the things that makes Lisp Lisp is that if the parens are over-cumbersome, you have the tools to take them away. See also CL:LOOP.

(The list of forms are passed, unevaluated and at compile time, to nest, which rewrites them using a right fold to nest things properly.)

Somewhat similar is the arrow macro that Clojure popularized, which lets you get rid of (deep (nesting (like (this ...)))) where you have to remember evaluation order is inside-out and replace it with a flatter (-> (this ...) like nesting deep). Its implementation is also easy -- many macros are easy to write because Lisp's source code is itself a list data structure for which you can write code to process and manipulate just like any other lists.

Another cool macro that's been around since 1993 is https://github.com/quil-lang/cmu-infix which lets you write math in infix style, e.g. #I( C[i, k] += A[i, j] * B[j, k] ) where A, B, and C are all matrices represented as 2D arrays. It's a lot more complicated than the nest macro, though.

There are some other things that still make Lisp great in comparison to other languages, but they don't exactly have one-line code examples like [::-1] and so I'll just describe them qualitatively. Common Lisp has CLOS, the first standardized OOP system. It's a lot more powerful than C++'s system. It differs from many systems in that classes and methods are separate; among other things this gives you multiple dispatch (you can define polymorphic methods that don't just dispatch to different code depending on the first argument (the explicit 'self' in Python, implicit 'this' in other langs) but all arguments). One thing it can be useful for is to get rid of many laborious uses of the Builder and Visitor patterns. e.g. the need for double dispatch is a common reason to use the Visitor pattern, but in Lisp there's no need. CLOS also does "method combination", which lets you define :before, :after, and :around methods that operate implicitly before/after/around a call. This gets rid of the Observer pattern, supports design-by-contract, and jives well with multiple inheritance in that you can create "mixins" that classes can "inherit" from with the only behavior being some :before/:after methods. (e.g. logging, or cleaning up resources, or validation.)

Everything is truly dynamic -- a class can even change its type at runtime, which may be an acceptable solution to the circle-ellipse problem, or just super convenient while developing. More fundamentally, "compile" is a built-in function, not something you have to do with a separate program. "Disassemble" is built-in, too, so you can see what the compiler is doing and how optimized something is. You have full flexibility to define and redefine how your program works as it's running, no need to restart and lose state if you don't want to. Besides being killer for development (and all the differences in development experience comprise a big part of why I still think Lisp is great compared to non-Lisp), this gives you a powerful way to do production debugging and hot-fixing too -- a footgun you might not necessarily want most of the time, but you don't have to do anything special for it when you do want it. It can be very useful, e.g. if you've got a spacecraft 100 million miles from Earth https://flownet.com/gat/jpl-lisp.html I've also put some hobby stuff on a server, just deployed as a single binary, but built so that if I want to change it, I can either stop it, replace the binary, and start again, or just SSH in and with SSH forwarding connect to the live program with my editor and load the new code changes just like I would when developing locally, and thus have zero downtime.

Lastly, Lisp's solution to error handling goes beyond traditional exception handling. Again this ties into the development experience -- you have some compile-time warnings depending on the implementation (e.g. typos, undefined functions, bad types) but you'll hit runtime errors eventually, Lisp provides the condition system to help deal with them. It can be used for signaling non-errors, which has its uses, but what you'll see first are probably unhandled errors. By default one will drop you into a debugger where the error occurred, the stack isn't immediately unwound. Here you can do whatever -- inspect/change variables on different stack frame levels, recompile code if there's a way to fix things, restart computation at a specific frame... You'll also be given the option of "restarts", which might include just an "abort" that unwinds to the top level (possibly ending a thread) but can include custom actions as well that could resolve the error in different ways. For example, if you're parsing a CSV file and hit a value that is wrong somehow (empty, bad type, illegal value, bad word, whatever), your restarts might be to provide your own value or some default value (which will be used, and the computation resumes to parse the next value in the row), or skip the whole row (moving on to the next one), or skip the whole file (moving on to the next file, or finishing). Again this can be very useful while debugging, but in production you can either program in default resolutions (and a catch-all handler that logs unhandled errors, as usual) or give the choice to the user (in a friendlier way than exposing the debugger if you please).

You don't have to give up on anything, that's the beauty of Lisp. Here's a library from 1993: https://github.com/quil-lang/cmu-infix

Though personally I don't particularly find (+ 1 2 3 4 5) less readable than 1+2+3+4+5, and since most of my programs don't have math expressions much more complicated than that, even without cmu-infix I'd find the rest of the tradeoffs worth it, much like once I thought despite Python not having i++ or ++i it was still worthwhile. (In Lisp, by the way, one would use (incf i).)