5 ms·

> Oh, I see what you mean. I discovered Lisp after working in C++ and Java, so I avoided this pitfall in my code, but if I had a dollar for every instance of: [

> Oh, I see what you mean. I discovered Lisp after working in C++ and Java, so I avoided this pitfall in my code, but if I had a dollar for every instance of: [...] This is one of those anti-patterns I sometimes find myself falling into (I don't code Lisp or its descendants often). It's kind of discouraging, to be honest, because it feels like there ought to be some more efficient way to do this, and my inner critic comes along and complains that I'd be better of writing Python or C than learning to do it the Right Way in Lisp. Is there some kind of idiomatic way to avoid this and write cleaner code? Is the solution to simply extract the progn into another function? Does that violate some rules of function encapsulation in Lisp?

zetalyrae 5y ago
I think extracting functions is the way to go. I like it when a function's body reads like a sentence, when it's been broken down to the atoms of that conceptual level of abstraction. Forth code that achieves this can look very satisfying. The problem is that the toplevel of a module is full of functions at various levels of granularity. It might be nice if programming languages had a concept of "code sections" (you could implement this with literate programming), where modules are organized hierarchically into sections, and declarations can be public or private within a section. So you might have: section foo // Accessible from outside this section public important_function() // Only accessible from inside this section private utility_function_1() private utility_function_2() end section
- memling 5y ago
  > The problem is that the toplevel of a module is full of functions at various levels of granularity. Exactly--this is what I was hinting at with "rules of function encapsulation." I took a course on LISP in college (apropos of nothing, it featured a lab called, "Isn't this just a one credit course?") in which it seemed like the LISP Way was to use helper functions. It's always felt like something was missing in my ability to "translate" between paradigms because this rubs me the wrong way (although as I went through some examples I realized I do this with some regularity in other languages--but it doesn't "feel" as bad). In retrospect probably part of the problem was that we ALGOL-adjacent undergrads didn't have the scaffolding to understand more generic approaches like fold and cousins. It was a different way of thinking. I like the idea of literate programming as a potential solution, especially as it can be used to guide newbies through the code and identify areas where idioms are much different between one's existing paradigms and that of the codebase.
  - zetalyrae 5y ago
    In Common Lisp you can use FLET or LABELS to declare local functions. This works, but there really is no good solution: utility functions often just take up space and belong nowhere.

zetalyrae 5y ago

I think extracting functions is the way to go. I like it when a function's body reads like a sentence, when it's been broken down to the atoms of that conceptual level of abstraction. Forth code that achieves this can look very satisfying. The problem is that the toplevel of a module is full of functions at various levels of granularity. It might be nice if programming languages had a concept of "code sections" (you could implement this with literate programming), where modules are organized hierarchically into sections, and declarations can be public or private within a section. So you might have: section foo // Accessible from outside this section public important_function() // Only accessible from inside this section private utility_function_1() private utility_function_2() end section

memling 5y ago
> The problem is that the toplevel of a module is full of functions at various levels of granularity. Exactly--this is what I was hinting at with "rules of function encapsulation." I took a course on LISP in college (apropos of nothing, it featured a lab called, "Isn't this just a one credit course?") in which it seemed like the LISP Way was to use helper functions. It's always felt like something was missing in my ability to "translate" between paradigms because this rubs me the wrong way (although as I went through some examples I realized I do this with some regularity in other languages--but it doesn't "feel" as bad). In retrospect probably part of the problem was that we ALGOL-adjacent undergrads didn't have the scaffolding to understand more generic approaches like fold and cousins. It was a different way of thinking. I like the idea of literate programming as a potential solution, especially as it can be used to guide newbies through the code and identify areas where idioms are much different between one's existing paradigms and that of the codebase.
- zetalyrae 5y ago
  In Common Lisp you can use FLET or LABELS to declare local functions. This works, but there really is no good solution: utility functions often just take up space and belong nowhere.