4 ms·

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 conceptua

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.

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.