On Saturday, 19 January 2013 at 13:19:36 UTC, Artur Skawina wrote:
> (No (or small enough) gain) - (real (tangible) loss) < 0.
>
> If you wonder where the loss comes from, others have mentioned some sources
> in this thread already. I'm just pointing out the lack of gain and additional
> loss components.
>

Nobody demonstrated anything remotely close to that. You demonstrated a decorrelation, which is only sufficient to remove parameter from the equation (here code quality).

> Consider several developers that each stick to there own style.
> The autoformatter
> will take care of things when the upstream pulls their changes, right? Except,
> then they each need to use their own private autoformatters in order to merge all
> upstream changes, which includes re-merging their own work.
> Imagine what that does
> to the revision history. Now consider how merging work from coder A by developer B
> will work. Then merging the result back, B->A. Then pushing upstream. And merging
> back by every developer.
> It should be obvious that any sane use of an autoformatter would have to be at
> the local commit phase. But, then a *checking* tool which enforces a common style
> would be the right solution; an autoformatter would just get in the way (you'd
> have to effectively merge its changes back after every single commit).

Why do a checking tool would be the right solution ? Why do manually the work that a machine can do automatically ?

> Writing the code properly in the first place is a much better approach, the
> checking tool can catch any mistakes. If there are enough of them and you almost
> always need a mechanical tool to do the fixing, then you are doing something wrong.
>

No editor have to show you the code as it is actually foramatted in the source file. Actually, many don't, like IntelliJ. A formatter can work both directions.

> BTW, if an autoformatter helps you to perform merges, then the same logic can be
> put in the merge tool - making that argument irrelevant.
>

Which would completely dumb. The only component in the toolchain that care about formatting is the programmer. It make perfect sense to put the formatter between the programmer and everything else in the toolchain.

On 01/21/13 04:12, deadalnix wrote:
> On Saturday, 19 January 2013 at 13:19:36 UTC, Artur Skawina wrote:
>>
>> If you wonder where the loss comes from, others have mentioned some sources
> 
> Nobody demonstrated anything remotely close to that.

Ignoring an argument does not invalidate it. The fact that you don't perceive
something as a problem does not mean it's not one.

> The only component in the toolchain that care about formatting is the programmer. It make perfect sense to put the formatter between the programmer and everything else in the toolchain.

This isn't about the programmer-toolchain interface; it's the programmer-programmer one that matters.

artur

On 01/19/2013 01:01 PM, Stewart Gordon wrote:
>
> But does "plot" mean the curve or the whole diagram?

The whole diagram. I think this should be obvious. The point is the plot is defined in 2 dimensions, even if the curve is only 1, and our language reflects this.

> The program structure is not defined by this layout. It's defined by the
> curly brackets.

And the curly brackets represent structure, which has some inherent 2D properties. That programmers can universally use the 2D representation of this structure meaningfully goes beyond just some arbitrary tokens.

> But the whole essence of a picture is that it's two-dimensional. In a D
> program you can escape all line breaks within strings, cut out all
> comments (or turn all // comments into /*..*/ comments), and then remove
> all line breaks that remain, and it will still be essentially the same
> program. You can't do that with a picture.

Sure I can. Just serialize the picture into ones and zeroes, as happens all the time on a computer. The computer doesn't care that it's been serialized, and can operate on it as is. However, the user cares about the 2D visualization, just like the programmer cares about indentation and line breaks.

This is my last post on the topic.

On 21/01/2013 09:47, Jeff Nowakowski wrote:
<snip>
> Sure I can. Just serialize the picture into ones and zeroes, as happens
> all the time on a computer. The computer doesn't care that it's been
> serialized, and can operate on it as is. However, the user cares about
> the 2D visualization, just like the programmer cares about indentation
> and line breaks.

So in your mind, a 2D image is not a picture, but just a representation of one?  And if you cut that image up into 5 rows of 6 blocks, rearrange them into 3 rows of 10 blocks and glue them together, the result is the picture as much as the original is?

You can choose to believe that if you want.  But most people wouldn't.

Stewart.

On 01/21/2013 07:03 PM, Stewart Gordon wrote:
>
> So in your mind, a 2D image is not a picture, but just a representation
> of one? And if you cut that image up into 5 rows of 6 blocks, rearrange
> them into 3 rows of 10 blocks and glue them together, the result is the
> picture as much as the original is?
>
> You can choose to believe that if you want. But most people wouldn't.

OK, I did say I was done with the topic, but here you are assigning derogatory beliefs to me which I don't hold.

I never said you could rearrange the picture willy-nilly, merely that it can safely and *usefully* be serialized. Displaying a rearranged picture as you describe would be as invalid as doing the same to some code.

Now it is true that typical curly-brace languages don't require you to indent your code properly, but the fact that block-structured code leads to a natural and universal 2D representation (to an approximation, ignoring stylistic rules like tabs/spaces) has just as much validity as the 2D representation of a picture, and why I dispute the notion that block-structured code is "linear".

Now I really am done, regardless of what you write next.