[squeak-dev] collect:thenDo: woes

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Sep 14 13:35:02 UTC 2019


Hi Chris,


thanks for the <cmd>Space tip, this is great! (Btw, I would find it quite useful to press this combination again and again to select each time the parent expression up to the root -- similar to shift + blue button on morphs.)


I see your argument of hierarchic expressions, and I would not use something like zöglfrex in common Smalltalk code. However, I would find it irritating to read long SQL queries in a triangle layout, so finally I think it remains a domain dependent question. :)


Best,

Christoph

________________________________
Von: Chris Muller <ma.chris.m at gmail.com>
Gesendet: Donnerstag, 12. September 2019 05:15:49
An: Thiede, Christoph
Cc: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] collect:thenDo: woes

Hi Christoph,

Parentheses are not bad at all, but when your code becomes really lispy, I think the parentheses concept has reached its limits.

What I think has actually reached its limits is passive reading of textual code, instead of active reading of tile-based code like Scratch.  By active, I mean using the interface to delineate the nodes in the hierarchy of expressions, as you read and digest the method.

As it turns out, there is a particular combination of settings in Squeak (I really need to document them as a set...) that enables fairly rich expression-editing in the standard Squeak editor.  It involves a couple of trade-offs with the conventions of other text editors, but the payoff is huge.  In this environment the parentheses actually assist the active reading of the code.  Everyone knows about selecting expressions by clicking just inside the parentheses.  Another is Command+[space].  Still another assist is that the first 8 or so levels of parentheses can each be set to a unique color.  One last trick is to place the text cursor in front of a particular closing bracket, to know its corresponding opening, simply press that closing bracket key to highlight its corresponding opening bracket.  Just an alternative way to delineate the expression.

Consider SQL or LINQ which do not indent each line to another level.
I do not find it easy to read this expression:

((((foo
    collect: [:x|x barf])
    select: [:y|y isKnorz])
    inject: Kiffle into: [:clomb :blui | clomb baz: blui])
    reduce: [:z :w | z plong: w])
    sum

Yes, you can use indentations, but the readability is still suboptimal:

((((foo collect: [:x|x barf])
    select: [:y|y isKnorz])
        inject: Kiffle into: [:clomb :blui | clomb baz: blui])
            reduce: [:z :w | z plong: w])
                sum

Imho brackets are the one concept and pipelines/queries are another one.


If you would like to concatenate really many expressions, brackets turn out not to be "sustainable" any longer, as each additional expression costs a new pair of brackets and a new indentation. So the parenthesis costs two dimensions of space where pipelines only need one, what makes it really hard to insert another dimension into the bracket monster:

((((foo collect: [:x|x barf])
    select: [:y|y isKnorz])
        inject: Kiffle into: [:clomb :blui |
            (clomb baz: [:deng | deng ploof: blui in: Roz])
                with: blui collect: [:zi :rad | zi pol: rad]])
                    reduce: [:z :w | z plong: w])
                        sum

(Where is the inner expression??)
In contrast:

foo asZöglfrex
    collect: [:x|x barf];
    select: [:y|y isKnorz];
    inject: Kiffle into: [:clomb :blui |
        clomb asZöglfrex
            baz: [:deng | deng ploof: blui in: Roz];
            with: blui collect: [:zi :rad | zi pol: rad]];
    reduce: [:z :w | z plong: w];
    sum

Active reading improves the bandwidth of my understanding of code better than passive reading of the code as a stream of formatted text -- even when that stream of code is sweetened in some way to try to hide the precedence.  I think a hierarchy of expressions is easier to see and understand than a sequence of outputs piped to inputs.  The former mirrors the structure of the language.  The latter can only be fully understood by reading the entire sequence.

Best,
  Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190914/4b3066df/attachment.html>


More information about the Squeak-dev mailing list