3 ms·

For me it's the one-way-ness of it, can't find a nice work to describe it. Most programs in languages will go outward and then inward, lisps just go outward. I

For me it's the one-way-ness of it, can't find a nice work to describe it. 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

Jach 4y ago
I dunno, my Lisp code comes back in pretty frequently, but I'm defining new functions, using CLOS, making use of let* or other nifty macros (uiop:nest is occasionally useful), and refactoring when a function gets too large. But compared to horrors I've frequently seen in JavaLand (especially in older code when the more modern practice of extract method/function refactoring was less common, more laborious, and not really automated), tons of Lisp code I come across from others has been pretty sane as far as indentation and spacing goes. 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/basic.lisp 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/attachments/paper/1887/export/events/attachments/urbit/paper/1887/whitepaper.pdf 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 > Hoon writes ?: test then else > Ideally the most complex twig is the else; if not, there’s an alternate form, ?., which reverses q and r. Hoon code is rather interesting to look at (random file: https://github.com/urbit/urbit/blob/master/pkg/arvo/lib/aqua-azimuth.hoon 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.

Jach 4y ago

I dunno, my Lisp code comes back in pretty frequently, but I'm defining new functions, using CLOS, making use of let* or other nifty macros (uiop:nest is occasionally useful), and refactoring when a function gets too large. But compared to horrors I've frequently seen in JavaLand (especially in older code when the more modern practice of extract method/function refactoring was less common, more laborious, and not really automated), tons of Lisp code I come across from others has been pretty sane as far as indentation and spacing goes. 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/basic.lisp 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/attachments/paper/1887/export/events/attachments/urbit/paper/1887/whitepaper.pdf 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 > Hoon writes ?: test then else > Ideally the most complex twig is the else; if not, there’s an alternate form, ?., which reverses q and r. Hoon code is rather interesting to look at (random file: https://github.com/urbit/urbit/blob/master/pkg/arvo/lib/aqua-azimuth.hoon 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.