Most programs in languages will go outward and then inward, lisps just go outward. I quite like the "look" of python as well, except that its missing the colorful parenthesis and the expressiveness that makes lisp so powerful
It seems like a problem mostly handled by style: just because you can easily represent the whole expanded AST in one function definition, and only use simple cons/list/array/map data structures, doesn't necessarily mean you should. And sure there are plenty of (in my opinion) not so great examples out there, like it's rather unfortunate that this is the first example for the cl-sdl2 project: https://github.com/lispgames/cl-sdl2/blob/main/examples/basi... (Though on another metric, the longest line is only 96 characters; most of my lines happen to be under 80 but I don't hold myself to that limit, my screen and editor windows support wide lines by default, like >200 characters wide.) The huge nest of with-macros further impedes runtime redefinition and modification, because now sure you can change code and redefine the function, but your game loop isn't going to see any of that on further iterations. At least the other renderer.lisp example is moving in a better direction splitting the game loop up into several draw functions, and you see those have a normal pattern of going out and then back in.
Urbit docs for its language Hoon once called the phenomenon something like "attacking the right margin". I recalled this fosdem paper describing it more https://archive.fosdem.org/2018/schedule/event/urbit/attachm... especially in 6.3.2:
> There are two common syntactic problems in functional languages: closing terminator piles (eg, right parens in Lisp) and indentation creep. A complex function will have a deep AST; if every child node in that AST is indented past its parent, any interesting code tends to creep toward the right margin.
> To solve terminator piles, there are two forms of every Hoon twig: “tall” and “flat”, ie, multiline and single-line. Tall twigs can contain flat twigs, but not vice versa, mimicking the look of “statements” and “expressions” in an imperative language. Flat form is enclosed by parentheses and separated by a single space; tall form is separated by multiple spaces or a newline, and (in most cases) not enclosed at all. ...
> Right-margin creep is prevented by backstep indentation; where a classical language might write
?: test
then
else
?: test
then
else
Hoon code is rather interesting to look at (random file: https://github.com/urbit/urbit/blob/master/pkg/arvo/lib/aqua...) especially with its rune vs keyword syntax choice, but I don't think it's worth the effort.