On Wed, Mar 3, 2010 at 9:53 AM, Yanni Chiu <yanni@rogers.com> wrote:

Isn't readability a matter of taste...?

Not according to the pattern description; did you read it? It says, the "tendency of the eye to distinguish and interpolate vertical and horizontal lines. The square brackets used to signify blocks lead the eye to create the illusion of a whole rectangle even though one isn't there." For me, it's absolutely true.

IIRC, the arguments for productivity had to do with everyone just accepting one standard - not that one standard was "better" than another, just that there be *one* team standard (in the interest of productivity).

No, universal conformity is not one of the arguments made, nor have I ever felt "consistency for consistency's sake" was ever very useful. Again, I invite you to read the patterns and their basis.

I prefer the "hanging left bracket" because it allows the subsequent lines to have the same tabbing. That makes me faster, without requiring an automatic formatter.

I'm not sure what "hanging left bracket" is. In Rectangular Block, subsequent lines have the "same tabbing" so it may be the same thing. I don't know how anything related to formatting could be faster than having the machine doing it. But if you are not using automatic-formatting, then you won't really be affected by these proposed pretty-print changes..

On Wed, Mar 3, 2010 at 1:50 PM, Yanni Chiu <yanni@rogers.com> wrote:

Chris Muller wrote:

...

On Wed, Mar 3, 2010 at 9:53 AM, Yanni Chiu <yanni@rogers.com> wrote:

...

Isn't readability a matter of taste...?

Not according to the pattern description; did you read it? It says, the "tendency of the eye to distinguish and interpolate vertical and horizontal lines. The square brackets used to signify blocks lead the eye to create the illusion of a whole rectangle even though one isn't there." For me, it's absolutely true.

I was going from memory of Beck'isms, but I've read it just now. Now I remember that I didn't like this rule the last time I read it. I still think it's handwaving, without studies done with Smalltalk code, but let's go along with the argument for now: the eye can distinguish rectangles easily, so to have better readability, arrange '[' and ']' to create a rectangular illusion.

I assure you that for a good many of us (me included) it works very well.

In the first example:

ifTrue: [self recomputeAngle]

I see a rectangle formed by the '[' and ']' on the same line. So, I buy the argument.

In the second example given:

ifTrue: [self clearCaches. self recomputeAngle]

The rectangle is getting harder for me to spot, and the argument is starting to feel sketchy to me.

What happens with more lines:

ifTrue: [self clearCaches. self current soleInstance yada yada blah blah self recomputeAngle]

Where's the rectangle now? Compare this with the highly disturbing fact (to me, anyways) that the first line should have the same level of indent as the rest of the lines in the block, but it's tabbed differently.

I see it immediately and it looks elegant and comprehensible. It doesn't for you. We're all wired differently. I suspect that if you're a visual thinker Beck's rule is for you, and if you're not you'll hate it.

...

I'm not sure what "hanging left bracket" is. In Rectangular Block, subsequent lines have the "same tabbing" so it may be the same thing.

I just made up the term because some other poster had mentioned they'd never seen code where the '[' was left dangling at the end of a line. I should have give an example:

ifTrue: [ line1 yo. line2 eh ]

Horrible, horrible, horrible ;) Poor block. The block is an object, not braces in some pathetic C derivative. It needs love and respect. Its beginning doesn't belong to the ifTrue:, its entirety is an argument to ifTrue:. The rectangular rule emphasises this (for those that can see it ;) ).

...

I don't know how anything related to formatting could be faster than having the machine doing it.

When the automated formatting does a poor job, and you have do undo it manually. Or, you refactor your code just so the automated formatting does a good job.

...

But if you are not using automatic-formatting, then you won't really be affected by these proposed pretty-print changes..

This thread started out talking about how the core Pharo code base should be formatted. Maybe the Squeak thread was only about pretty-printing.

I think the conclusion has to be (and I can confirm that the VisualWorks team was equally divided) that no one formatting regime will make every one happy and that all regimes will make a substantial minority unhappy. So perhaps we should step up to having code formatted automatically according to tailorable preferences. My only concern is comment formatting but the way to deal with that is to use automatic formatting and deal with comment problems as they arise. I always used to be concerned about e.g. comments spanning multiple lines. But without day to day exposure I don't think one can know how much of an issue it is. One upside will be less effort reformatting when indent levels change. Have you noticed that Smalltalk tends to be more difficult to reformat than C syntax languages, I guess because of keywords? Not having to worry about this could be great. Of course, what format gets written to a source file could still be a source of conflict ;) We may all want our syntax to be the format of record :) best Eliot P.S. and don't get me started on the trailing period (putrid excressence), or the space between ^ and the return expression (vomitous mass).

-- Yanni

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi, I do not understand the arguments that go in the direction of: because a block is an object, it should have no spaces inside and it should not have the code starting on a new line. This is a bit like saying that a method should not be indented and the code should start on the same line as the definition. Or in the same line, it is like saying that because all statements belong to a block, they should all be written on the same line. Visual thinking was mentioned as a defense for these arguments, but the first role of any visual notation is to make you identify structure fast. The comments of Yanni go in the correct, in my opinion, direction. So, when you have something like: ifTrue: [self clearCaches. self current soleInstance yada yada blah blah self recomputeAngle] you break visual alignment and it is more difficult to see that the first "self..." is in the same context as the second "self...". Of course, practice can solve everything and in time you can get used to this, but that does not make it natural. Another visual problem with "[" and "]" is that they are but one character, and if you place them together with something else, like "[self", they lose their visual identity (btw, we read words in chunks not by characters) and get harder to spot. It's true that some fonts and extra coloring could solve this problem, but whitespace is always the best and least invasive design weapon. Another problem with having no space between the [ and the rest is that you basically render useless the nice feature of Smalltalk environments to double click and select everything inside. The reason is that I have to go to great pain to get the mouse exactly in the right place. An indentation like below solves the above visual problems. boolean ifTrue: [ self clearCaches. self current soleInstance yada yada blah blah self recomputeAngle ] The lines are clearly belonging together, [ is clearly observed and clicking anywhere on the first line after [ will select the whole block. Yet another thing it solves is the consistency between block and method. They both define behavior, and thus it would be great if they would be treated similarly. This is better seen in the context of a block with parameter: aCollection do: [ :each | self something. self somethingElse. ] Just like a method has the top line with the signature and the parameters, a block should be the same. In this case, each is a parameter and it is clearly distinct from everything else. When there is no parameter, this is information made very clear, too (because of the absence of anything following [ ). An argument against this convention was that it looks like C and that blocks are not dumb {. While I understand the built-in adversity, we are talking about a visual notation that makes sense for Smalltalk and not one that make it different from everything else around us. Another option would be to have: boolean ifTrue: [ self clearCaches. self current soleInstance yada yada blah blah self recomputeAngle ] with everything inside the block being aligned. However, this has the problem of wasting space. One space can also be used, but only when the font is monospaced, so it would not work in general. Furthermore, it would be inconsistent or even more space wasting when it comes to blocks with parameters. Cheers, Doru On 4 Mar 2010, at 03:38, Chris Muller wrote:

...

...

ifTrue: [ line1 yo. line2 eh ]

Horrible, horrible, horrible ;) Poor block. The block is an object...

Exactly what I was thinking; and how some of the new editor features since 3.9, that seem to reify "statements". For example, clicking inside parens or square-brackets selects that statement(s). I also really enjoyed the ability to "surround", thereby creating additional statement-levels.

The whole interaction becomes much more liked working with tiled code rather than a text-editor.

...

I think the conclusion has to be (and I can confirm that the VisualWorks team was equally divided) that no one formatting regime will make every one happy and that all regimes will make a substantial minority unhappy. So perhaps we should step up to having code formatted automatically according to tailorable preferences.

...

My only concern is comment formatting but the way to deal with that is to use automatic formatting and deal with comment problems as they arise. I always used to be concerned about e.g. comments spanning multiple lines. But without day to day exposure I don't think one can know how much of an issue it is.

As someone who's logged 5-digits of hours in Squeak these last few years, I think the best thing is to just not. Let 'em wrap! Use shout to turn them light gray, so they don't really intrude on the code, but are there if you want focus on the extra prose.

Unfortunately, the real problem with comments within BlockNodes is how they duplicate themselves within the parse-tree.. ouch! I hope that is what you and Nicolas were talking about or that you'll have a fix for that..

...

One upside will be less effort reformatting when indent levels change. Have you noticed that Smalltalk tends to be more difficult to reformat than C syntax languages, I guess because of keywords? Not having to worry about this could be great.

Very cool, I hope there'll be enough additional consensus to adopt these Beckian formats for Squeaks pretty-print refinement.

...

Of course, what format gets written to a source file could still be a source of conflict ;) We may all want our syntax to be the format of record :)

Absolutely. To not, would be the machine dictating to the user. Invoking automatic formatting is always the users choice. browseWithPrettyPrint allows readers to have it formatted dynamically if they wish..

Cheers..

...

P.S. and don't get me started on the trailing period (putrid excressence), or the space between ^ and the return expression (vomitous mass).

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- www.tudorgirba.com "Live like you mean it."

Strange to see how subjective it is... My brain is well trained to rectangle blocks and I arrive to the opposite conclusions on each point.

I agree 100% with all that Doru wrote. These patterns have been successfully used for almost a decade in open-source projects like Seaside, Moose, Magritte, Mondrian, Pier, Glamour, PetitParser, Grease, OmniBrowser, SqueakSource, ... Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Another visual problem with "[" and "]" is that they are but one character, and if you place them together with something else, like "[self", they lose their visual identity (btw, we read words in chunks not by characters) and get harder to spot. It's true that some fonts and extra coloring could solve this problem, but whitespace is always the best and least invasive design weapon.

Tudor, for what its worth, the white-space surrounding the blocks is not really at issue or discussion here. It's about formatting blocked code into rectangular shapes. In fact, I agree with you about your point about the whitespace. IOW, I prefer: someVar = someValue ifTrue: [ self doOneThing ] ifFalse: [ self doOtherThing ; doYetAnotherThing. anotherObject doSomething ] Not: someVar = someValue ifTrue: [self doOneThing] ifFalse: [self doOtherThing ; doYetAnotherThing. anotherObject doSomething] Perhaps if you looked at a longer method example, with nested blocks, you might be able to "see", visually, the blocks more obviously. Perhaps not, I don't know. Regards, Chris

The lines are clearly belonging together, [ is clearly observed and clicking anywhere on the first line after [ will select the whole block.

Yet another thing it solves is the consistency between block and method. They both define behavior, and thus  it would be great if they would be treated similarly. This is better seen in the context of a block with parameter:

aCollection do: [ :each |                self something.                self somethingElse. ]

Just like a method has the top line with the signature and the parameters, a block should be the same. In this case, each is a parameter and it is clearly distinct from everything else. When there is no parameter, this is information made very clear, too (because of the absence of anything following [ ).

An argument against this convention was that it looks like C and that blocks are not dumb {. While I understand the built-in adversity, we are talking about a visual notation that makes sense for Smalltalk and not one that make it different from everything else around us.

Another option would be to have: boolean ifTrue:        [       self clearCaches.                self current soleInstance yada yada blah blah                self recomputeAngle ]

with everything inside the block being aligned. However, this has the problem of wasting space. One space can also be used, but only when the font is monospaced, so it would not work in general. Furthermore, it would be inconsistent or even more space wasting when it comes to blocks with parameters.

Cheers, Doru

On 4 Mar 2010, at 03:38, Chris Muller wrote:

...

...

...

    ifTrue: [         line1 yo.         line2 eh ]

Horrible, horrible, horrible ;)  Poor block.  The block is an object...

Exactly what I was thinking; and how some of the new editor features since 3.9, that seem to reify "statements".  For example, clicking inside parens or square-brackets selects that statement(s).  I also really enjoyed the ability to "surround", thereby creating additional statement-levels.

The whole interaction becomes much more liked working with tiled code rather than a text-editor.

...

I think the conclusion has to be (and I can confirm that the VisualWorks team was equally divided) that no one formatting regime will make every one happy and that all regimes will make a substantial minority unhappy.  So perhaps we should step up to having code formatted automatically according to tailorable preferences.

...

My only concern is comment formatting but the way to deal with that is to use automatic formatting and deal with comment problems as they arise.  I always used to be concerned about e.g. comments spanning multiple lines.  But without day to day exposure I don't think one can know how much of an issue it is.

As someone who's logged 5-digits of hours in Squeak these last few years, I think the best thing is to just not.  Let 'em wrap!  Use shout to turn them light gray, so they don't really intrude on the code, but are there if you want focus on the extra prose.

Unfortunately, the real problem with comments within BlockNodes is how they duplicate themselves within the parse-tree.. ouch!  I hope that is what you and Nicolas were talking about or that you'll have a fix for that..

...

One upside will be less effort reformatting when indent levels change.  Have you noticed that Smalltalk tends to be more difficult to reformat than C syntax languages, I guess because of keywords?  Not having to worry about this could be great.

Very cool, I hope there'll be enough additional consensus to adopt these Beckian formats for Squeaks pretty-print refinement.

...

Of course, what format gets written to a source file could still be a source of conflict ;)  We may all want our syntax to be the   format of record :)

Absolutely.  To not, would be the machine dictating to the user. Invoking automatic formatting is always the users choice. browseWithPrettyPrint allows readers to have it formatted dynamically if they wish..

Cheers..

...

P.S.  and don't get me started on the trailing period (putrid excressence), or the space between ^ and the return expression (vomitous mass).

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- www.tudorgirba.com

"Live like you mean it."

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

+ 1 And I know that you read kent patterns. We got all brainwashed with them.... I;m still hoping that his book will be out of print :) For now rebuying one for the team here since some guys messed up my nice and clean version. Stef

On Mar 3, 2010, at 16:53 , Yanni Chiu wrote:

...

Isn't readability a matter of taste, or were experiments done?

Indeed. As long as we don't carry out usability studies, we don't know what is better and we have to resort to personal taste. When I said "I don't like x" I also meant "I find it is less readable". Yanni gives a good argument below.

In any case, I don't want to start an endless discussion about formatting, but I think it is interesting to get the different opinions to be able to come up with a formatter that works for as many people as possible.

What we probably all agree on is that a common convention (or automatic formatter) for code in PharoCore would improve readability in comparison to the current situation in which we have all sorts of formatting.

Cheers, Adrian

...

IIRC, the arguments for productivity had to do with everyone just accepting one standard - not that one standard was "better" than another, just that there be *one* team standard (in the interest of productivity).

I prefer the "hanging left bracket" because it allows the subsequent lines to have the same tabbing. That makes me faster, without requiring an automatic formatter.

-- Yanni

Chris Muller wrote:

...

Well, Kent makes a well-reasoned argument for Rectangular Block, readability and productivity. "I don't like it" is just a statement of someone's personal taste, a non-starter in terms of a useful discussion about formatting.

My goal is to make the system more productive and, by my experience, that's what these formatting patterns accomplish.

- Chris

On Wed, Mar 3, 2010 at 3:51 AM, Torsten Bergmann <astares@gmx.de> wrote:

...

...

what do you mean by now used? Did they change that recently? According to http://planetmisc.squeak.org/ a new package Compiler-cmm.131.mcz is now in Squeak inbox and may find its way into trunk ...

...

I don't like Beck's rule "3. Rectangular Block" vs. So for me personally, Beck's rule 3 is the one that looks better. And there we have them: discussions on what looks better :)

Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project