View mode: basic / threaded / horizontal-split · Log in · Help
January 21, 2013
Re: Exceptional coding style
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.
January 21, 2013
Re: Exceptional coding style
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
January 21, 2013
Re: Dimensionality of program code
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.
January 22, 2013
Re: Dimensionality of program code
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.
January 22, 2013
Re: Dimensionality of program code
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.
Next ›   Last »
16 17 18 19 20
Top | Discussion index | About this forum | D home