On 01/18/2013 08:52 AM, Graham Fawcett wrote:

>> I do not know of any editor that does not support "ctrl + scroll" to
>> change the font sizes on the fly.
>
> FWIW, Emacs doesn't out of the box. But this makes it work:
>
> (global-set-key [M-mouse-4] 'text-scale-increase)
> (global-set-key [M-mouse-5] 'text-scale-decrease)
>
> (M- for Alt, or C- for Control.)
>
> Graham

What comes out of the box with Emacs is Shift-Click on the buffer. A font menu pops up. The "increase" and "decrease" selections change the font size easily.

Ali

On 1/18/2013 3:09 AM, Russel Winder wrote:
> On Thu, 2013-01-17 at 17:59 -0800, Walter Bright wrote:
> […]
>> But in practice, I find over and over again that carefully formatted code tends
>> to go hand in hand with well designed code.
>
> Having an obsessive–compulsive side to your nature is good in these
> case.

I think such a trait does make for a good engineer!

Or you could just call it pride in one's work.

On 17/01/2013 22:01, Era Scarecrow wrote:
<snip>
>   As I recall for the compilers very early on, all comments and unneeded
> whitespace were simply removed before compiling, leaving you with one
> very long command string. The /**/ comment syntax makes perfect sense in
> this case; Later tools more memory and hardware power make it more
> manageable; but // requires 2d code to properly compile until the
> comments are stripped.

Doesn't quite follow, because as far as the computer is concerned a line break is just another character.

Though in order to know whether a newline is whitespace, the lexer needs to know whether it's lexing a // comment or not.  But this context-sensitive character classification is something we already needed in order to read strings correctly.  Unless these early languages didn't allow you to have consecutive spaces in a string literal or required a special notation for them.

> // c example, originally isprime and main don't have
> // return types, defaulting to int instead.

Does the return type of a function still default to int if unspecified in current C, either according to the ANSI standard or according to most compilers?

> int isprime(int n){int cnt=2;if(n<2)return
> 0;for(;cnt<n;cnt++)if((n%cnt)==0)return 0;return 1;}int main(){int
> cnt=2;for(;cnt<1000000;cnt++)if (isprime(cnt))printf("%d \n", cnt);}
>
>   It's one of the reasons the syntax requires a semicolon after each
> statement so it can tell obviously where something ends.

But Dennis could have easily designed it to use a newline instead of a semicolon.  Indeed, there are a number of programming languages that basically do this.

But other languages do more than this, like Python and Haskell which are indent-sensitive, and early FORTRAN with its strict rules on code layout.  Indeed, considering these, you could well ask where to draw the line between a 1D language and a 2D language.

Stewart.

On Fri, Jan 18, 2013 at 11:03:12AM -0800, Walter Bright wrote:
> On 1/18/2013 3:09 AM, Russel Winder wrote:
> >On Thu, 2013-01-17 at 17:59 -0800, Walter Bright wrote: […]
> >>But in practice, I find over and over again that carefully formatted code tends to go hand in hand with well designed code.
> >
> >Having an obsessive–compulsive side to your nature is good in these case.
> 
> I think such a trait does make for a good engineer!
> 
> Or you could just call it pride in one's work.

Which, sad to say, is rather lacking in many of today's programmers.


T

-- 
There are 10 kinds of people in the world: those who can count in binary, and those who can't.

On 01/17/2013 03:13 PM, Stewart Gordon wrote:
>
> Mathematically, a curve is considered a one-dimensional object,
> regardless of whether the space in which it is embedded has two, three
> or more dimensions. (I'm ignoring fractals here for simplicity.) If you
> consider the shape of the indented block structure to be a curve, then
> it's still one-dimensional in this respect.

I think you dismiss the embedded space too easily. We call a plot laid out in 2D is a 2D-plot. You use both dimensions to specify it.

> And in most languages, a program/module is essentially just a sequence
> of tokens, and as such is one-dimensional. We might look at it in a
> two-dimensional form, but this two-dimensional layout means nothing as
> far as the program structure and semantics are concerned.

Even a 2D picture can (and often is) represented as a series of ones and zeroes. That doesn't mean the essential 2D aspects of it don't exist. To say that the 2D layout of block structures "means nothing" is misguided. It's fundamentally there, just like the 2D picture that's been serialized.

> OTOH, because we tend to view code in a two-dimensional form, and even
> rely on line breaks and block indentation to make code readable, I can
> understand people thinking of code as 2D.

We can rely on it because the 2D aspect is there in structured code, even if the compiler doesn't force this layout.

> And there are languages in which the code structure is inherently
> two-dimensional, e.g. Befunge.

Even Befunge can be translated to a universal Turing machine, which is a linear tape.

On Friday, 18 January 2013 at 19:50:06 UTC, Stewart Gordon wrote:
> On 17/01/2013 22:01, Era Scarecrow wrote:
>> // c example, originally isprime and main don't have
>> // return types, defaulting to int instead.
>
> Does the return type of a function still default to int if unspecified in current C, either according to the ANSI standard or according to most compilers?

 For compatibility it does. Functions called without prototypes (even if they are later in the same file) default to return type int too. I can't think of any compilers that make it an error (although they should)

> But Dennis could have easily designed it to use a newline instead of a semicolon.  Indeed, there are a number of programming languages that basically do this.

 Maybe, but if you use a newline instead of a semi-colon, then you can't put multiple statements on the same line; newlines and spaces are more formatting so they were likely rejected as part of the separator; That and if you write a very long statement line (several requirements in an if statement) not being able to break it up would make for very very ugly code. The preprocessor being it's own thing used newlines as a separator, to macros you need to escape newline.

On 01/18/13 11:28, deadalnix wrote:
> On Friday, 18 January 2013 at 09:10:38 UTC, Artur Skawina wrote:
>> On 01/18/13 09:48, Walter Bright wrote:
>>> On 1/17/2013 11:58 PM, Artur Skawina wrote:
>>>> Sane, but badly formatted code is much preferable to bad, but pretty code.
>>>
>>> Offhand, I can't remember ever running across bad but pretty code.
>>
>> Which is my point. An autoformatter makes the bad code look good, but does
>> not change its quality. Hence use of such a tool as part of the std dev
>> process should be strongly discouraged, not encouraged.
>> Having it can be useful when refactoring, yes.
> 
> That is completely erratic reasoning. What you state here is that the 2 issue are orthogonal, and that code quality is an irrelevant topic when it come to pro/cons of a formatter. You didn't demonstrate in any way that it is to be avoided.

(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.

>> If /formatting/ conflicts appear during merges, then it's a sign of either a) bad code, or b) bad process. Papering over either problem with an autoformatter is not the right fix.
> 
> Using an autoformatter is a sure way to fix the process if such merging error occurs. The other way is to ask everybody to spend their time formatting in a given way. Anyone that have managed a project KNOWS that asking everybody to do something is not gonna make it, either because people don't care or because people make mistakes.

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).
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.

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

artur

On 18/01/2013 23:17, Era Scarecrow wrote:
<snip>
>   For compatibility it does. Functions called without prototypes (even
> if they are later in the same file) default to return type int too. I
> can't think of any compilers that make it an error (although they should)

I guess the reason they don't is that such a compiler wouldn't be following the C standard.

But it would be nice if we had a subset of C that omits such barbarisms as this, and compilers for this subset.  For that matter, would the intersection of C and C++ reasonably qualify as such?

>> But Dennis could have easily designed it to use a newline instead of a
>> semicolon.  Indeed, there are a number of programming languages that
>> basically do this.
>
>   Maybe, but if you use a newline instead of a semi-colon, then you
> can't put multiple statements on the same line;

A newline as an alternative to a semicolon then.

> newlines and spaces are
> more formatting so they were likely rejected as part of the separator;

Not sure what you mean by that....

> That and if you write a very long statement line (several requirements
> in an if statement) not being able to break it up would make for very
> very ugly code.
<snip>

Then invent a line-splicing notation.  It's what Visual Basic has done.

Stewart.

On 18/01/2013 21:50, Jeff Nowakowski wrote:
<snip>
> I think you dismiss the embedded space too easily. We call a plot laid
> out in 2D is a 2D-plot. You use both dimensions to specify it.

But does "plot" mean the curve or the whole diagram?

<snip>
> Even a 2D picture can (and often is) represented as a series of ones and
> zeroes. That doesn't mean the essential 2D aspects of it don't exist. To
> say that the 2D layout of block structures "means nothing" is misguided.

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

> It's fundamentally there, just like the 2D picture that's been serialized.

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.

>> OTOH, because we tend to view code in a two-dimensional form, and even
>> rely on line breaks and block indentation to make code readable, I can
>> understand people thinking of code as 2D.
>
> We can rely on it because the 2D aspect is there in structured code,
> even if the compiler doesn't force this layout.
<snip>

Structure and visual layout are two fundamentally different things.

Stewart.

On Saturday, 19 January 2013 at 17:25:58 UTC, Stewart Gordon wrote:
> On 18/01/2013 23:17, Era Scarecrow wrote:
>> Maybe, but if you use a newline instead of a semi-colon, then you can't put multiple statements on the same line;
>
> A newline as an alternative to a semicolon then.
>
>> newlines and spaces are more formatting so they were likely rejected as part of the separator;
>
> Not sure what you mean by that....

 If newline was the separator then...

  if (a == 1 && b == 2 && c == 3 && d == 4 && e == 5 && f == 6 && g == 7 && h == 8 && i == 9) //explanation of descriptions not possible, likely before 'if' statement instead
{}

  vs

  // would break, no statement following &&;
  // no matching )
  if (a == 1 && b == 2 && c == 3 &&     //explanation of conditions
          d == 4 && e == 5 && f == 6 && //
          g == 7 && h == 8 && i == 9) {}


 Just cause it can be ugly doesn't mean there was times you could avoid it. More modern compilers could optimize other statements thereby simplifying it to..

  bool t1 = a == 1 && b == 2 && c == 3;
  bool t2 = d == 4 && e == 5 && f == 6;
  bool t3 = g == 7 && h == 8 && i == 9;

  //equal to above, assuming an optimizer would condense it
  if (t1 && t2 && t3) {}

  Course if you gave them names and something useful then you might have something like:

  if (memBlock && startSector >= 0 && endSector <= memBlock->length && startSector < endSector && outBlock && outBlock->length >= (endSector-startSector)) {
    ...
  } else {
    assert(false, "memory bounds of sector xxx failed");
  }

 You could turn that into: (but not if newlines were separators)

  if (memBlock && outBlock &&
        startSector >= 0 && endSector <= memBlock->length &&
        startSector < endSector &&
        outBlock && outBlock->length >= (endSector-startSector)) {}
  else {
    assert(false, "memory bounds of sector xxx failed");
  }


  You'd be required to do this, depending on what you need to keep the code readable; Although this break-down would help you to give more exact error messages.

  assert(memBlock && outBlock);
  assert(startSector >= 0);
  assert(endSector <= memBlock.length);
  assert(startSector < endSector);
  assert(outBlock->length >= (endSector-startSector));

  //success code from here on.

 But most likely for operating system code you wouldn't assert it, you'd return error code numbers; A lazy programmer trying to just 'get it to work' wouldn't want to get into a whole lot of intricate error messages/enums until going through the code a second time after he has a basic working model, so it's either success or failure, nothing more, nothing less.

 Besides, 95% of the time error codes like errorno are completely ignored; Checking for every type of error in every case would make the functions so large bulky and annoying and hard to read it's impractical. ie:

  //write to FILE fp, 100 records of 1 byte each, from void* header
  recordsWrote = fwrite(fp, 100, 1, header);

  //recordsWrote not 0?
  //errorno checks:
  //did write correctly?
  //out of space?
  //was file even open anymore?
  //was output read-only?
  //other errors? (I don't know how many there are, some OS's could have more)
  //can retry if there was an error?

  recordsWrote = fwrite(fp, 100, 1, data);
  //repeat error checks
  //if failed, remove previous header information?

 At best I check on if any records were written, and only go back to check/work if I seem to be having issues regularly.

> Then invent a line-splicing notation.  It's what Visual Basic has done.

 Maybe. I think (but not sure) that back when space was a lot more precious (and harddrives of 300Mb were 'large'; In 1992 I had a 300Mb hard drive, on a 386 SX 33Mhz laptop); Every k counts, and a compact compiler/sources (instruction set in the x86) made sense. So tabs were likely used far more for main indenting/spacing than regular spaces (8:1 ratio, auto aligning).

 Besides, Visual Basic is younger than C and has more freedom after it came out when the hardware was a certain level. Basic/Qbasic sorta count, but that're not VB.


 Now understand I'm not saying you're wrong. I'm saying it was impractical for the time based on hardware limitations (and a young technology).