Comment by lispm | Hacker News Reader

Comment by lispm | Hacker News Reader

Parent Full thread

The problem is that the Lisp code structure is hierarchical. Transforming it for input/output into a sequential code structure can help, but hinders the learning of the hierarchical mode of working with trees and nested lists. In the long run the mental model of trees or nested lists is more important than the "improvements" of the sequential visible structure. Typically the sequential model is preferred by those who have learned other languages with imperative code structures (in the history that was FORTRAN, but nowadays it's often languages like Python and Java). Not unlearning and then learning a different model, limits the understanding of the underlying language and its evaluation model.

That's really interesting! I definitely could be sticking to a mental picture without realising. Curious if you're a lisper and have got used to reading that kind of heavily intended code? Or if you have other strategies for minimizing the complexity?

For me containment is important. (a (b)) -> (b) is inside a. Also that the whole form is enclosed in parentheses. If I move the mouse over a form, the whole form can be selected.

    (pipe
      (a 1 2 3)
      (b 4 5 6 7))

If I move over the second form, there is an argument, which is above it.

My mental model is more based on tree evaluation, not so much on sequential evaluation.

    (b (a 1 2 3)
       4 5 6 7)

For me it's more important to see that all arguments to b are enclosed in a single form. If I want to move it around, I can easily select the whole form (with the mouse typically by a double click on the parentheses or a middle click).

The list becomes a physical thing (-> manipulating lists), not so much a syntactical thing (dealing with the syntax of a pipe operator).

But then I'm used to Lisp environments with a higher code complexity (longer code with deeper nesting, lots of macros) and support for that.

Reply on news.ycombinator.com