www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Exceptional coding style

reply Walter Bright <newshound2 digitalmars.com> writes:
Quite a nice read on the coding style used in Doom.

http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
Jan 14 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/14/2013 11:24 AM, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


Here begins another epic thread. :)

I haven't read the article but came across this: "I personally enforce 
the rule that all method names should begin with a verb unless they 
can't." The author adds that he prefers getLength() to length().

That rule is misguided because not every member function represents an 
action; there are also attributes. Attribute methods should be nouns, in 
D or in C++. In our C++ code we simply say length() (and setLength() if 
needed).

Ali
Jan 14 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/14/2013 11:52 AM, Ali Çehreli wrote:

 On 01/14/2013 11:24 AM, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


 Here begins another epic thread. :)

 I haven't read the article but came across this: "I personally enforce the rule
 that all method names should begin with a verb unless they can't." The author
 adds that he prefers getLength() to length().

 That rule is misguided because not every member function represents an action;
 there are also attributes. Attribute methods should be nouns, in D or in C++.
In
 our C++ code we simply say length() (and setLength() if needed).


Well, not everyone will agree with everything he says. But it is interesting, 
and a number of the conventions in there are D features.

I also found it interesting how some of the conventions used defies generally 
accepted C++ best practices.
Jan 14 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 14 January 2013 at 20:36:51 UTC, Walter Bright wrote:

 On 1/14/2013 11:52 AM, Ali Çehreli wrote:

 On 01/14/2013 11:24 AM, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


 Here begins another epic thread. :)

 I haven't read the article but came across this: "I personally 
 enforce the rule
 that all method names should begin with a verb unless they 
 can't." The author
 adds that he prefers getLength() to length().

 That rule is misguided because not every member function 
 represents an action;
 there are also attributes. Attribute methods should be nouns, 
 in D or in C++. In
 our C++ code we simply say length() (and setLength() if 
 needed).


 Well, not everyone will agree with everything he says. But it 
 is interesting, and a number of the conventions in there are D 
 features.

 I also found it interesting how some of the conventions used 
 defies generally accepted C++ best practices.


Apart from a few *style* issues, the only thing the article 
contains was mostly hate for the stl.

I understand one might dislikes the stream operators due to the 
syntax (myself included), but once you've used them more than 
once, and know how to use them, they aren't a problem. The strong 
typing they provide is simply unmatched in C++. The article even 
mentions that NOT using stream operators was one of their biggest 
source of bugs. And Carmack himself replies stating that in 
retrospect: StrongTyping > WeirdCode.

There's also hate for stl's containers, stating they are *too 
generic*, stating that it is better to use *Only* a HashTable of 
<int, int> or <char*, int>. Nobody is stopping you from doing it 
with the stl. Not being overly generic is one thing. Not using 
something specific because it *spawned* from something generic is 
another.

The argument is *always* the same "the syntax is ugly and hard to 
use and outside of my comfort zone".
Jan 14 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 14, 2013 at 09:57:25PM +0100, monarch_dodra wrote:
[...]

On 01/14/2013 11:24 AM, Walter Bright wrote:

Quite a nice read on the coding style used in Doom.

http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550








[...]

 Apart from a few *style* issues, the only thing the article contains
 was mostly hate for the stl.
 
 I understand one might dislikes the stream operators due to the
 syntax (myself included), but once you've used them more than once,
 and know how to use them, they aren't a problem. The strong typing
 they provide is simply unmatched in C++. The article even mentions
 that NOT using stream operators was one of their biggest source of
 bugs. And Carmack himself replies stating that in retrospect:
 StrongTyping > WeirdCode.


Stream operators are teh eviil. Overloading << and >> for I/O was a
horrible design decision. Operator overloading should be reserved for
numeric types. But then again, Stroustrup didn't have the benefit of
hindsight back then, and certainly, on the surface, overloading <<
and >> seemed like a cool thing to do. And C++ didn't (still doesn't?)
have typesafe handling of variadics, so the desire to not have to write
"cout.put(x); cout.put(y); cout.put(z); cout.put(w); ..." is
understandable.

But none of that changes the fact that overloading << and >> for I/O was
a horrible idea.



 There's also hate for stl's containers, stating they are *too
 generic*, stating that it is better to use *Only* a HashTable of
 <int, int> or <char*, int>. Nobody is stopping you from doing it
 with the stl. Not being overly generic is one thing. Not using
 something specific because it *spawned* from something generic is
 another.


I don't think it's so much as a complaint about genericity, as the lousy
C++ template syntax.



 The argument is *always* the same "the syntax is ugly and hard to
 use and outside of my comfort zone".


Which is why D's template syntax is such a big plus.

The prevalent hatred for templates is mostly the fault of poorly-chosen
syntax on C++'s part. Overloading < and > to delimit template arguments
was just such a horribly bad idea. It makes C++ impossible to lex before
it's parsed, and gives templates an undeservedly frightening appearance.
Unfortunately, the best of us coders are prone to judge by appearances,
especially when dealing with an unfamiliar new language feature (which
was the case when C++ templates first appeared on the scene). Sometimes,
syntax matters.

I think people learning about templates for the first time in D syntax
would be much less liable to developing an aversion to it. In fact, TDPL
was written in such a way that the word 'template' isn't even used until
the reader has already gotten used to the concept of "compile-time
parameters". When understood in this way, templates are far more
approachable than is the case in most introductions to C++ templates.

D templates can still stand some improvement, though. Maybe not so much
at the language level, but template-related errors in DMD are still a
frightening sight to behold for the uninitiated. Phobos also can stand a
lot of improvement in providing human-readable errors in a catch-all
default template, so that a failed instantiation doesn't produce 27
pages of errors, most of which involve details of internal Phobos
implementation structures that no outside user should need to know
about.  Improvement this area will help a lot towards newbie acceptance
of the concept of templates.


T

-- 
One disk to rule them all, One disk to find them. One disk to bring them
all and in the darkness grind them. In the Land of Redmond where the
shadows lie. -- The Silicon Valley Tarot
Jan 14 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-14 22:40, H. S. Teoh wrote:


 Stream operators are teh eviil. Overloading << and >> for I/O was a
 horrible design decision. Operator overloading should be reserved for
 numeric types. But then again, Stroustrup didn't have the benefit of
 hindsight back then, and certainly, on the surface, overloading <<
 and >> seemed like a cool thing to do. And C++ didn't (still doesn't?)
 have typesafe handling of variadics, so the desire to not have to write
 "cout.put(x); cout.put(y); cout.put(z); cout.put(w); ..." is
 understandable.


C++11 has variadic templates.

-- 
/Jacob Carlborg
Jan 14 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 15 January 2013 at 07:38:01 UTC, Jacob Carlborg wrote:

 On 2013-01-14 22:40, H. S. Teoh wrote:


 Stream operators are teh eviil. Overloading << and >> for I/O 
 was a
 horrible design decision. Operator overloading should be 
 reserved for
 numeric types. But then again, Stroustrup didn't have the 
 benefit of
 hindsight back then, and certainly, on the surface, 
 overloading <<
 and >> seemed like a cool thing to do. And C++ didn't (still 
 doesn't?)
 have typesafe handling of variadics, so the desire to not have 
 to write
 "cout.put(x); cout.put(y); cout.put(z); cout.put(w); ..." is
 understandable.


 C++11 has variadic templates.


Let's not forget variadic templates are bleeding edge here.

C++ streams are 20 years old. They are inconvenient, ugly, and 
hard to use, *but* they are strongly typed *and* safe, both for 
read and wright. And they work. Just because there is something 
better today doesn't mean they were a mistake.

*Sure*, today, they can use "writeln(T...)", but not 20 years 
ago. On the subject of safety, I still prefer "writeln" over 
"writefln". While writefln is safe, you can still botch the 
amount of args, and or flag types, in which case writefln will 
throw. Writeln never throws (due to a code error).
Jan 15 2013
next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 15 January 2013 at 08:29:59 UTC, monarch_dodra wrote:

 Just because there is something better today doesn't mean they 
 were a mistake.



I'm not sure if they /were/ but they certainly /are/...

no?

Okay, how many of these streambuf methods are you familiar with?

For me that's probably between 0-2.

Now do you /really/ expect to be able to implement your own 
stream in a reasonable amount of time with a streambuf interface 
like this? That's what's wrong with streams in C++.

eback
egptr
epptr
gbump
getloc
gptr
imbue
in_avail
overflow
pbackfail
pbase
pbump
pptr
pubimbue
pubseekoff
pubseekpos
pubsetbuf
pubsync
sbumpc
seekoff
seekpos
setbuf
setg
setp
sgetc
sgetn
showmanyc
snextc
sputbackc
sputc
sputn
stossc
sungetc
sync
uflow
underflow
xsgetn
xsputn
Jan 15 2013
prev sibling parent reply FG <home fgda.pl> writes:
On 2013-01-15 09:29, monarch_dodra wrote:

 I still prefer "writeln" over "writefln". While writefln issafe, you
 can still botch the amount of args, and or flag types, in which case
 writefln will throw. Writeln never throws (due to a code error).


What about the argument that a format string makes translation easier?
Jan 15 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 11:23:40AM +0100, FG wrote:

 On 2013-01-15 09:29, monarch_dodra wrote:

I still prefer "writeln" over "writefln". While writefln issafe, you
can still botch the amount of args, and or flag types, in which case
writefln will throw. Writeln never throws (due to a code error).


 
 What about the argument that a format string makes translation easier?


Current format string syntax still has a ways to go before it can make
translation easier. Consider this example:

	writeln("%s is found in %s", file.name, dir.name);

Sounds ideal for translation, right? Except that it's not. First,
reading the format string alone says nothing about what meaning is
intended. What is found in a what? Also, it doesn't let you vary the
word order correctly. Nor does it let you perform inflection correctly.

For true ease of translation, you need:

1) Logical naming of format arguments, e.g.:

	"%{filename} is found in %{dirname}"

and of course, some way to associate logical names with actual
arguments.

2) Some way to indicate the function of each word so that inflection can
be cone correctly, e.g.:

	"%{filename.nominative} is found in %{dirname.locative}"

or something like that, in languages where words change form depending
on function. There will, of course, need to be requisite mechanisms for
interpreting these word function identifiers.

3) Some way to indicate multiplicity:

	"1 file was found" vs. "2 files were found"

would require the quantity of files to be passed to the formatting
function so that the appropriate translation can be selected. Keep in
mind the different languages have different rules as to how to map
quantity to word forms; just because English has only two forms
(singular, plural) doesn't mean that that's enough. Russian, for
example, requires 3 distinct forms: one for singular, one for numbers
2-4, a third for 5 onwards (with the second form recurring for selected
subranges of the latter).

Current format strings are far from making translation truly easier.


T

-- 
Philosophy: how to make a career out of daydreaming.
Jan 15 2013
parent reply FG <home fgda.pl> writes:
On 2013-01-15 17:00, H. S. Teoh wrote:

 reading the format string alone says nothing about what meaning is
 intended. What is found in a what? Also, it doesn't let you vary the
 word order correctly. Nor does it let you perform inflection correctly.

 For true ease of translation, you need:

 1) Logical naming of format arguments, e.g.:

 	"%{filename} is found in %{dirname}"



I agree that named arguments are best -- then you don't require extra comments.
As for argument positioning, it already can be specified, for example "%1$s".




 2) Some way to indicate the function of each word so that inflection can
 be cone correctly, e.g.:

 	"%{filename.nominative} is found in %{dirname.locative}"

 or something like that, in languages where words change form depending
 on function. There will, of course, need to be requisite mechanisms for
 interpreting these word function identifiers.



Filename and dirname don't look like good examples - they don't change.
Well, this is a problem much deeper than providing simple translation, so let's 
drop this for now.




 3) Some way to indicate multiplicity:

 	"1 file was found" vs. "2 files were found"



This is already taken care of in every gettext system I know.
The code would look something like this:

writefln(ngettext("%1$d file found in %2$s", "%1$d files found in %2$s", 2),
     2, "folder X");

where ngettext takes 3 arguments: eng_singular, eng_plural, count.
Jan 15 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 09:23:22PM +0100, FG wrote:

 On 2013-01-15 17:00, H. S. Teoh wrote:

reading the format string alone says nothing about what meaning is
intended. What is found in a what? Also, it doesn't let you vary the
word order correctly. Nor does it let you perform inflection
correctly.

For true ease of translation, you need:

1) Logical naming of format arguments, e.g.:

	"%{filename} is found in %{dirname}"


 
 
 I agree that named arguments are best -- then you don't require extra
 comments.  As for argument positioning, it already can be specified,
 for example "%1$s".


Yes, but argument positioning is easy to mix up when the format string
has a lot of arguments. Named arguments are the best. Self-documenting,
and also avoids careless mistakes (like mistyping %1$s when you mean
%2$s).



2) Some way to indicate the function of each word so that inflection
can be cone correctly, e.g.:

	"%{filename.nominative} is found in %{dirname.locative}"

or something like that, in languages where words change form
depending on function. There will, of course, need to be requisite
mechanisms for interpreting these word function identifiers.


 
 Filename and dirname don't look like good examples - they don't
 change.  Well, this is a problem much deeper than providing simple
 translation, so let's drop this for now.


Yeah filename and dirname are not good examples.  A better example (for
Indo-European languages at least) is with verbs:

	writeln("The cat %s the dog.", verb);

In some languages, the form of "cat" and "dog" may need to change
depending on what the verb is. But then these cases are probably too
complex to capture in a format string in the first place, so perhaps the
point is moot.



3) Some way to indicate multiplicity:

	"1 file was found" vs. "2 files were found"


 
 This is already taken care of in every gettext system I know.
 The code would look something like this:
 
 writefln(ngettext("%1$d file found in %2$s", "%1$d files found in %2$s", 2),
     2, "folder X");
 
 where ngettext takes 3 arguments: eng_singular, eng_plural, count.


What if there are two (or more) items in the string that have counts?


T

-- 
"Uhh, I'm still not here." -- KD, while "away" on ICQ.
Jan 15 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-14 21:57, monarch_dodra wrote:


 Apart from a few *style* issues, the only thing the article contains was
 mostly hate for the stl.

 I understand one might dislikes the stream operators due to the syntax
 (myself included), but once you've used them more than once, and know
 how to use them, they aren't a problem. The strong typing they provide
 is simply unmatched in C++. The article even mentions that NOT using
 stream operators was one of their biggest source of bugs. And Carmack
 himself replies stating that in retrospect: StrongTyping > WeirdCode.


With variadic templates introduced in C++11 can't you implement a type 
safe writeln or similar just like Phobos has?

-- 
/Jacob Carlborg
Jan 14 2013
prev sibling next sibling parent reply "mist" <none none.none> writes:
On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


That guy has rather weird sense of beauty... My eyes started 
bleeding at the "Spacing" section.
Jan 14 2013
next sibling parent reply FG <home fgda.pl> writes:
On 2013-01-14 22:31, mist wrote:

 That guy has rather weird sense of beauty... My eyes started bleeding at the
 "Spacing" section.



I sympathize. He posted the worse code excerpt to prove his point. :)

I used to also do "column alignment" in the C code I wrote in the past, but 
using spaces and not tabs. Used it for initializing arrays of structs, for 
defining a series of bit masks (I bet you have nothing against this use), but 
also for a series of function pointer typedefs, for comments and sometimes for 
cases in a switch statement.

I think it adds readability when you compare similar lines and you don't even 
need syntax highlighting -- as long as the columns are kept narrow (but wide 
enough, so that you don't have to push all things whenever you add a line).

The columns idea is mentioned in the file CodeStyleConventions.doc used by 
idSoftware, which he links on that page. Here are some of the conventions:



 Use real tabs that equal 4 spaces.


Huh? No tabs, ever!. They usually mess up code posted on webpages.


 Pad parenthesized expressions with spaces:
 if ( x ) {}  Instead of  if (x) {}  And
 x = ( y * 0.5f );  Instead of  x = (y * 0.5f);


I agree that it's readable, even more so with functions:
someFunction( parameter1, parameter2 ).method( something );


 Function names start with an upper case:
 void Function( void );


Say what?!


 Typedef names use the same naming convention as variables,
 however they always end with "_t".
 typedef int fileHandle_t;


Now, this is completely reversed...


 Use ‘const’ as much as possible.


Yes, generally good.



 Indent the names of class variables and class methods to make nice columns.
 The variable type or method return type is in the first column and the
 variable name or method name is in the second column.

 class idVec3 {
     float           x;
     float           y;
     float           z;
     float           Length( void ) const;
     const float *   ToFloatPtr( void ) const;
 }

 The * of the pointer is in the first column because it improves readability
 when considered part of the type.


Generally yes, but I can't agree with * being with the type, unless there's 
always just one variable per line or we're writing in D, for example.
Jan 14 2013
next sibling parent "DythroposTheImposter" <barf barf.com> writes:
  Funny I remember looking at the Doom 3 Source a few years ago 
and having the opposite reaction. Looked awful. Still does. It is 
basically C with classes.
Jan 14 2013
prev sibling parent reply "mist" <none none.none> writes:
On Monday, 14 January 2013 at 22:53:05 UTC, FG wrote:

 On 2013-01-14 22:31, mist wrote:

 That guy has rather weird sense of beauty... My eyes started 
 bleeding at the
 "Spacing" section.



 I sympathize. He posted the worse code excerpt to prove his 
 point. :)


I am most unpleasant with vertical space point. Times when screen 
space was that important are long gone - I generally can 
understand less at once than can possibly fit with 9th font size 
on 24 inch screen. And extra vertical spaces are like semantic 
formatting tools for plain text - can group related blocks 
perfectly and speed up reading.
Jan 14 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
mist:


 I am most unpleasant with vertical space point. Times when 
 screen space was that important are long gone - I generally can 
 understand less at once than can possibly fit with 9th font 
 size on 24 inch screen.


I prefer a larger font and less wasted lines.

understanding.



 And extra vertical spaces are like semantic formatting tools 
 for plain text - can group related blocks perfectly and speed 
 up reading.


The idea of not wasting lines doesn't go against the idea of 
adding blank lines to create code paragraphs. When you are adding 
a line to divide chunks, you are not wasting vertical space, it's 
a well used line :-)

Bye,
bearophile
Jan 14 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 12:48:13AM +0100, bearophile wrote:

 mist:
 

I am most unpleasant with vertical space point. Times when screen
space was that important are long gone - I generally can
understand less at once than can possibly fit with 9th font size
on 24 inch screen.


 
 I prefer a larger font and less wasted lines.



+1.

Larger font makes it easier on my eyes. I always maximize any code
window and increase the font size until its roughly 80 columns.



And extra vertical spaces are like semantic formatting tools for
plain text - can group related blocks perfectly and speed up
reading.


 
 The idea of not wasting lines doesn't go against the idea of adding
 blank lines to create code paragraphs. When you are adding a line to
 divide chunks, you are not wasting vertical space, it's a well used
 line :-)


[...]

+1.


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL
Jan 14 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote:

 mist:


 I am most unpleasant with vertical space point. Times when 
 screen space was that important are long gone - I generally 
 can understand less at once than can possibly fit with 9th 
 font size on 24 inch screen.


 I prefer a larger font and less wasted lines.

 understanding.



 And extra vertical spaces are like semantic formatting tools 
 for plain text - can group related blocks perfectly and speed 
 up reading.


 The idea of not wasting lines doesn't go against the idea of 
 adding blank lines to create code paragraphs. When you are 
 adding a line to divide chunks, you are not wasting vertical 
 space, it's a well used line :-)


I could explain it better.

Plus, in some languages, (yes javascript, I'm looking at you) 
semicolon are inserted in places that can create very nasty bugs 
when changing line like that. I know it isn't really an argument 
that apply for C/C++/D but it does matter for a programmer that 
use both C/C++/D and such a language (as I do).
Jan 14 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 15 January 2013 at 04:45:02 UTC, deadalnix wrote:

 On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote:

 mist:


 I am most unpleasant with vertical space point. Times when 
 screen space was that important are long gone - I generally 
 can understand less at once than can possibly fit with 9th 
 font size on 24 inch screen.


 I prefer a larger font and less wasted lines.

 understanding.



 And extra vertical spaces are like semantic formatting tools 
 for plain text - can group related blocks perfectly and speed 
 up reading.


 The idea of not wasting lines doesn't go against the idea of 
 adding blank lines to create code paragraphs. When you are 
 adding a line to divide chunks, you are not wasting vertical 
 space, it's a well used line :-)


 I could explain it better.


s/could/couldn't/


 Plus, in some languages, (yes javascript, I'm looking at you) 
 semicolon are inserted in places that can create very nasty 
 bugs when changing line like that. I know it isn't really an 
 argument that apply for C/C++/D but it does matter for a 
 programmer that use both C/C++/D and such a language (as I do).
Jan 14 2013
prev sibling parent reply "mist" <none none.none> writes:
On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote:

 And extra vertical spaces are like semantic formatting tools 
 for plain text - can group related blocks perfectly and speed 
 up reading.


 The idea of not wasting lines doesn't go against the idea of 
 adding blank lines to create code paragraphs. When you are 
 adding a line to divide chunks, you are not wasting vertical 
 space, it's a well used line :-)

 Bye,
 bearophile


Well, I would not rant about this if not his actual example in 
"Spacing" block. This very example of "bad" code has every empty 
line added right where it fits. And "good" one is a mess that 
hurts my eyes when I try to concentrate on some distinct parts.
Jan 15 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 15 January 2013 at 10:47:19 UTC, mist wrote:

 On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote:

 And extra vertical spaces are like semantic formatting tools 
 for plain text - can group related blocks perfectly and speed 
 up reading.


 The idea of not wasting lines doesn't go against the idea of 
 adding blank lines to create code paragraphs. When you are 
 adding a line to divide chunks, you are not wasting vertical 
 space, it's a well used line :-)

 Bye,
 bearophile


 Well, I would not rant about this if not his actual example in 
 "Spacing" block. This very example of "bad" code has every 
 empty line added right where it fits. And "good" one is a mess 
 that hurts my eyes when I try to concentrate on some distinct 
 parts.


The spacing section is exactly the coding style I use, and 
omitting the curly braces will rather sooner than later lead to 
more work. Also, "a function should only do one thing" has proven 
to work for me. Although there might be a slight performance 
penalty if you have more function calls, code maintenance is by 
far easier.
Jan 15 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 12:01:46PM +0100, Chris wrote:
[...]

 The spacing section is exactly the coding style I use, and omitting
 the curly braces will rather sooner than later lead to more work.
 Also, "a function should only do one thing" has proven to work for
 me. Although there might be a slight performance penalty if you have
 more function calls, code maintenance is by far easier.


+1. Premature optimization is the bane of aspiring programmers. Code
maintainability should be foremost; merging functions for "performance"
should only be done after extensive profiling has proven that having too
many function calls is the bottleneck.

Too many projects waste too much time "optimizing" the code, with no
proof whatsoever that said "optimizations" are actually helping
performance, with the result that the code is fragile and hard to
maintain, thus costing much more time & effort than it should.  What
programmers habitually blame for performance bottlenecks are usually red
herrings; the real bottlenecks are rarely where people imagine they are.
You don't know until you actually profile the code.  (I learnt this the
hard way.)


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.
Jan 15 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/15/2013 12:26 AM, mist wrote:

 On Monday, 14 January 2013 at 22:53:05 UTC, FG wrote:

 On 2013-01-14 22:31, mist wrote:

 That guy has rather weird sense of beauty... My eyes started bleeding
 at the
 "Spacing" section.



 I sympathize. He posted the worse code excerpt to prove his point. :)


 I am most unpleasant with vertical space point.


I think it is one of the more sensible ones. Completely unrelated to 
code beauty though.


 Times when screen space was that important are long gone


This generally comes up as an argument in these discussions, but I don't 
buy it. Not all development is done on a desktop with a huge screen. And 
even then, there is always something to put on it. What window manager 
are you using?


 - I generally can understand less at
 once than can possibly fit with 9th font size on 24 inch screen.


In my experience, the screen is always too small. I prefer font size 12 
though.


 And extra vertical spaces are like semantic formatting tools for plain text
 - can group related blocks perfectly and speed up reading.


Sure, I do that too when appropriate. That is not an excuse for wasting 
space gratuitously, making them harder to spot.

Ultimately, it is entirely a matter of habituation. (So you might as 
well just prefer the format that is more efficient.)
Jan 14 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 12:57:17AM +0100, Timon Gehr wrote:

 On 01/15/2013 12:26 AM, mist wrote:


[...]

- I generally can understand less at once than can possibly fit with
9th font size on 24 inch screen.


 
 In my experience, the screen is always too small. I prefer font size
 12 though.


[...]

I use font size at least 15. :-P Well, it depends on what resolution I'm
running at.  For 1280x1024, I use about 15. For my home PC running at
1600x1200, I use 18 or 20. I find anything less than 14 straining on my
eyes, and anything below 12 painful.

I'm a stickler for 80 column text terminals. I find that anything much
larger than that tends to be unwieldy because your eyes have to scan too
far a horizontal distance per line. And I like the 80 columns to fill
the entire width of the screen. (I have stopped believing in tiling or
overlapping windows. Maximize everything FTW.)

But then again, I don't expect anyone else to share my peculiar
configuration.  :-P


T

-- 
MS Windows: 64-bit overhaul of 32-bit extensions and a graphical shell
for a 16-bit patch to an 8-bit operating system originally coded for a
4-bit microprocessor, written by a 2-bit company that can't stand 1-bit
of competition.
Jan 14 2013
parent 1100110 <0b1100110 gmail.com> writes:
On 01/14/2013 06:13 PM, H. S. Teoh wrote:

 On Tue, Jan 15, 2013 at 12:57:17AM +0100, Timon Gehr wrote:

 On 01/15/2013 12:26 AM, mist wrote:


 [...]

 - I generally can understand less at once than can possibly fit with
 9th font size on 24 inch screen.


 In my experience, the screen is always too small. I prefer font size
 12 though.


 [...]

 I use font size at least 15. :-P Well, it depends on what resolution I'm
 running at.  For 1280x1024, I use about 15. For my home PC running at
 1600x1200, I use 18 or 20. I find anything less than 14 straining on my
 eyes, and anything below 12 painful.

 I'm a stickler for 80 column text terminals. I find that anything much
 larger than that tends to be unwieldy because your eyes have to scan too
 far a horizontal distance per line. And I like the 80 columns to fill
 the entire width of the screen. (I have stopped believing in tiling or
 overlapping windows. Maximize everything FTW.)

 But then again, I don't expect anyone else to share my peculiar
 configuration.  :-P


 T


You know, that's almost exactly how I like my stuff.

It still seems weird.  =P
Jan 15 2013
prev sibling parent reply "mist" <none none.none> writes:
On Monday, 14 January 2013 at 23:57:18 UTC, Timon Gehr wrote:

 This generally comes up as an argument in these discussions, 
 but I don't buy it. Not all development is done on a desktop 
 with a huge screen. And even then, there is always something to 
 put on it. What window manager are you using?


Well, I hardly can imagine rationale behind using netbook for 
serious development aside from being on trip. Even being forced 
to work in ssh to some legacy shell ( I have that unpleasant 
experience :( ) usually limits your term width, not height.

I am using Gnome Shell, but working mostly in full-screen 
undecorated terminal. It is approximately 75 to 85 lines of 
vertical space in my setup.
Jan 15 2013
next sibling parent reply "mist" <none none.none> writes:
Well, probably I am playing "good vision nazi" here, as 12 font 
size seems HUGE to me, far beyond the comfort zone.
Jan 15 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/15/2013 11:57 AM, mist wrote:

 Well, probably I am playing "good vision nazi" here, as 12 font size
 seems HUGE to me, far beyond the comfort zone.


It's just preference. I do not have any problems with font size 9.
Jan 15 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 15 January 2013 at 13:55:53 UTC, Timon Gehr wrote:

 On 01/15/2013 11:57 AM, mist wrote:

 Well, probably I am playing "good vision nazi" here, as 12 
 font size
 seems HUGE to me, far beyond the comfort zone.


 It's just preference. I do not have any problems with font size 
 9.


I do not know of any editor that does not support "ctrl + scroll" 
to change the font sizes on the fly.

I always change the font size of my editor, depending on how 
concentrated I am, my position in my seat, or by how complicated 
the current algorithm is. Or simply if somebody is looking over 
my shoulder.

Your editor's font size should not be statically dictated by a 
single number.
Jan 15 2013
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2013-01-15 at 15:07 +0100, monarch_dodra wrote:
[=E2=80=A6]

=20
 I do not know of any editor that does not support "ctrl + scroll"=20
 to change the font sizes on the fly.


Emacs, VIM,=E2=80=A6

[=E2=80=A6]

 Your editor's font size should not be statically dictated by a=20
 single number.


It depends on whether you want all the text to be a single size in which
case yes just one number to set the font size ;-)
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 15 2013
parent reply "mist" <none none.none> writes:
On Tuesday, 15 January 2013 at 15:49:34 UTC, Russel Winder wrote:

 On Tue, 2013-01-15 at 15:07 +0100, monarch_dodra wrote:
 […]

 
 I do not know of any editor that does not support "ctrl + 
 scroll" to change the font sizes on the fly.


 Emacs, VIM,…

 […]

 Your editor's font size should not be statically dictated by a 
 single number.


 It depends on whether you want all the text to be a single size 
 in which
 case yes just one number to set the font size ;-)


monospaced fonts everywhere to rule them all! :)
Jan 15 2013
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2013-01-15 at 17:02 +0100, mist wrote:
[=E2=80=A6]

 monospaced fonts everywhere to rule them all! :)


Monospace fonts are an aberration of the typewriter era.

All text, including code, should be displayed in proportional fonts, in
my case Ocean Sans Std on my machines.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 15 2013
parent reply "mist" <none none.none> writes:
On Tuesday, 15 January 2013 at 16:31:05 UTC, Russel Winder wrote:

 On Tue, 2013-01-15 at 17:02 +0100, mist wrote:
 […]

 monospaced fonts everywhere to rule them all! :)


 Monospace fonts are an aberration of the typewriter era.

 All text, including code, should be displayed in proportional 
 fonts, in
 my case Ocean Sans Std on my machines.


:O You are probably the very first programmer I have encountered 
so far that prefers proportional fonts for code. I need some time 
to even try to imagine how this may look.
Jan 15 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/15/13 11:33 AM, mist wrote:

 On Tuesday, 15 January 2013 at 16:31:05 UTC, Russel Winder wrote:

 On Tue, 2013-01-15 at 17:02 +0100, mist wrote:
 […]

 monospaced fonts everywhere to rule them all! :)


 Monospace fonts are an aberration of the typewriter era.

 All text, including code, should be displayed in proportional fonts, in
 my case Ocean Sans Std on my machines.


 :O You are probably the very first programmer I have encountered so far
 that prefers proportional fonts for code. I need some time to even try
 to imagine how this may look.


I, too, prefer proportional fonts in code and tried hard to use them in 
TDPL. I couldn't find a reasonable way to make them work in 
LaTeX/listings (indentation and vertical align are pervasive issues) and 
besides there are really elaborate monospace fonts to be had nowadays, 
so I chose Bitstream Vera which is beautiful. (Took me a week to decide 
on TDPL fonts alone but it was time well spent.)

Same deal in Emacs - there's just no good editor support for 
proportional fonts in code yet. Russel, what editor do you use?


Andrei
Jan 15 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2013-01-15 at 11:49 -0500, Andrei Alexandrescu wrote:
[=E2=80=A6]

 I, too, prefer proportional fonts in code and tried hard to use them in=


=20

 TDPL. I couldn't find a reasonable way to make them work in=20
 LaTeX/listings (indentation and vertical align are pervasive issues) and=


=20

 besides there are really elaborate monospace fonts to be had nowadays,=


=20

 so I chose Bitstream Vera which is beautiful. (Took me a week to decide=


=20

 on TDPL fonts alone but it was time well spent.)


LaTeX and listings works fine with proportional fonts for me. What
problem were you having.

I'll bear Bitstream Vera in mind for the book I am just starting.


 Same deal in Emacs - there's just no good editor support for=20
 proportional fonts in code yet. Russel, what editor do you use?


I use the one true kitchen sink, Emacs, mostly. Using Ocean Sans Std.
Eclipse, PyCharm, IntelliJ IDEA, NetBeans, GEdit, all using Ocean Sans
Std.

XTerms are a problem, command line tools assume monospace fonts and so
terminal have to use monospace fonts, which makes VIM use really awful.

gVIM is no help. It allows you to choose a proportional font and then
uses it in monospace mode.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 15 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/15/13 11:59 AM, Russel Winder wrote:

 LaTeX and listings works fine with proportional fonts for me. What
 problem were you having.


In book code samples you need frequently to align things vertically 
(e.g. comments):

int a = 42;   // the meaning of everything
a += 0.1;     // error! cannot assign double to int


 I'll bear Bitstream Vera in mind for the book I am just starting.


Hope it's a book on D :o).


 I use the one true kitchen sink, Emacs, mostly. Using Ocean Sans Std.
 Eclipse, PyCharm, IntelliJ IDEA, NetBeans, GEdit, all using Ocean Sans
 Std.


Guess I'll just try it!!!


Andrei
Jan 15 2013
next sibling parent Russel Winder <russel winder.org.uk> writes:
Andrei,

On Tue, 2013-01-15 at 12:09 -0500, Andrei Alexandrescu wrote:
[=E2=80=A6]

 In book code samples you need frequently to align things vertically=20
 (e.g. comments):
=20
 int a =3D 42;   // the meaning of everything
 a +=3D 0.1;     // error! cannot assign double to int


That sort of alignment is nigh on impossible in a proportional font
using listing or minted. Of course there is no association between the
comments so no reason why they should align.  Tab alignments definitely
a bad idea for import by reference material.


 I'll bear Bitstream Vera in mind for the book I am just starting.


=20
 Hope it's a book on D :o).


No it isn't. But it would be good if there were more books on D in the
market.


 I use the one true kitchen sink, Emacs, mostly. Using Ocean Sans Std.
 Eclipse, PyCharm, IntelliJ IDEA, NetBeans, GEdit, all using Ocean Sans
 Std.


=20
 Guess I'll just try it!!!


Definitely give it a go.

You can set things using the menu system and writing the default fonts
out, or you can edit ~/.emacs.d/custom.el manually. This latter is the
properly hardcore programmer approach, but does require knowing a little
e-lisp.

(custom-set-variable
	=E2=80=A6
 '(default-frame-alist (quote ((height . 40) (width . 120) (foreground-colo=
r . "black") (background-color . "#d0c4b0") (cursor-color . "red") (pointer=
-color . "red") (vertical-scroll-bars . right) (font . "-monotype-Ocean San=
s MT-medium-r-normal--*-100-*-*-*-*-iso10646-1"))))
 '(initial-frame-alist (quote ((height . 40) (width . 120) (foreground-colo=
r . "black") (background-color . "#d0c4b0") (cursor-color . "red") (pointer=
-color . "red") (vertical-scroll-bars . right) (font . "-monotype-Ocean San=
s MT-medium-r-normal--*-100-*-*-*-*-iso10646-1"))))
	=E2=80=A6
)

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 15 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 06:11:46PM +0000, Russel Winder wrote:
[...]

 On Tue, 2013-01-15 at 12:09 -0500, Andrei Alexandrescu wrote:
 […]

 In book code samples you need frequently to align things vertically 
 (e.g. comments):
 
 int a = 42;   // the meaning of everything
 a += 0.1;     // error! cannot assign double to int


 
 That sort of alignment is nigh on impossible in a proportional font
 using listing or minted. Of course there is no association between the
 comments so no reason why they should align.  Tab alignments
 definitely a bad idea for import by reference material.


[...]

This is exactly the sort of thing where I find proportional fonts
unusable for code.

It's not inherently so, though. I've oft dreamed of a new way of
displaying code, in which same-line comments are displayed in a separate
pane in the editor (rather than intermixed with the code in the same
pane). This comment pane can be adjustable in size and position, and
comments can even be made collapsible (and the code pane would adjust
the amount of space between lines to keep all comments aligned with
their respective lines of code). Why should the textual representation
of the code be conflated with the way it is displayed anyway? Let the
code editor do all the formatting and layout, including alignment of
same-line comments across lines. The actual source file can be free of
all unnecessary whitespace (the compiler doesn't care anyway).

In fact, this allows for very long lines of code (say a complicated
if-condition) to be formatted alongside a long comment block, something
like this:

	if ((cond1 && !cond2) ||	// Check if the complicated
	    (!cond3 && cond4) ||	// conditions described earlier
	    (value1 < value2*16) ||	// are fulfilled.
	    (value1 >= minVal))
	{
		...
	}

You never have to manually wrap the code and comment lines yourself
(which would be very painful if you want to keep everything aligned).
The source file could very well represent this thus:

	if ((cond1 && !cond2) || (!cond3 && cond4) || (value1 < value2*16) || (value1
>= minVal)) // Check if the complicated conditions described earlier are
fulfilled.
	{
		...
	}

and the code editor does the pretty layout for you.


T

-- 
Spaghetti code may be tangly, but lasagna code is just cheesy.
Jan 15 2013
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2013-01-15 at 17:33 +0100, mist wrote:
[=E2=80=A6]

 :O You are probably the very first programmer I have encountered=20
 so far that prefers proportional fonts for code. I need some time=20
 to even try to imagine how this may look.


Use an editor like GEdit and change the font to a proportional one and
admire how much nicer the code looks!=20

(There are some aspects of some coding styles that work well with
monospace fonts, that make code look dreadful in proportional fonts, and
vice versa. For a fair comparison make sure a style that is reasonable
for both monospace and proportional is used.)

I really cannot understand the obsession computing people have with
using monospace fonts, I just assume it is a hang over from the line
printer era which created a mindset that most people do not challange.
As soon as computers moved from 80x24 terminals to editors with pixel
based accuracy and nice fonts I ditched all use of monospace fonts.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 15 2013
next sibling parent "mist" <none none.none> writes:
On Tuesday, 15 January 2013 at 16:51:34 UTC, Russel Winder wrote:

 On Tue, 2013-01-15 at 17:33 +0100, mist wrote:
 […]

 :O You are probably the very first programmer I have 
 encountered so far that prefers proportional fonts for code. I 
 need some time to even try to imagine how this may look.


 Use an editor like GEdit and change the font to a proportional 
 one and
 admire how much nicer the code looks!


GEdit is rather weak :( I am using VIM and Eclipse for coding and 
changed Eclipse font to monospaced Terminus font from default 
proportional. Problem I have with proportional fonts - they are 
not random-access ranges but sequential ones :) My brain is not 
capable of computing required offset for 30-40 proportional 
symbols in no observable time, contrary to monospaced.

I still prefer proportional for books and web, of course, because 
it looks better and normal reading is indeed sequential.
Jan 15 2013
prev sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 15 January 2013 at 16:51:34 UTC, Russel Winder wrote:

 I really cannot understand the obsession computing people have 
 with
 using monospace fonts, I just assume it is a hang over from the 
 line
 printer era which created a mindset that most people do not 
 challange.
 As soon as computers moved from 80x24 terminals to editors with 
 pixel
 based accuracy and nice fonts I ditched all use of monospace 
 fonts.


It's not strictly a computing thing; I've known a few editors who 
won't work on manuscripts with a proportional font either. 
(Though I suspect you're familiar with the classic manuscript 
style guidelines.)  Personally, I find monospace makes it much 
easier to make glyph distinctions and spot errors.
Jan 15 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, January 15, 2013 17:33:08 mist wrote:

 so far that prefers proportional fonts for code. I need some time
 to even try to imagine how this may look.


I've had _one_ coworker that I know of who liked using. I still don't 
understand how he could read code that way. Proportional fonts make perfect 
sense for normal text, but they're horrible for code. Nothing lines up right. 
That's why I hate writing code in e-mails. Not only is it hard to get right 
with a proportional font, you don't even know if it's going to look the same 
for the person reading it.

- Jonathan M Davis
Jan 15 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 15 January 2013 at 22:35:04 UTC, Jonathan M Davis 
wrote:

 I've had _one_ coworker that I know of who liked using. I still 
 don't understand how he could read code that way. Proportional 
 fonts make perfect sense for normal text, but they're horrible 
 for code. Nothing lines up right. That's why I hate writing 
 code in e-mails. Not only is it hard to get right with a 
 proportional font, you don't even know if it's going to look 
 the same for the person reading it.


  I remember being taught Java and helping everyone else debug 
their code. One girl had changed her fonts to this really fancy 
cursive font with purple & pink color. Why, I have no clue. Being 
too hard to read I refused to help her.
Jan 15 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 16, 2013 at 02:06:59AM +0100, Era Scarecrow wrote:

 On Tuesday, 15 January 2013 at 22:35:04 UTC, Jonathan M Davis wrote:

I've had _one_ coworker that I know of who liked using. I still
don't understand how he could read code that way. Proportional
fonts make perfect sense for normal text, but they're horrible for
code. Nothing lines up right. That's why I hate writing code in
e-mails. Not only is it hard to get right with a proportional
font, you don't even know if it's going to look the same for the
person reading it.


 
  I remember being taught Java and helping everyone else debug their
 code. One girl had changed her fonts to this really fancy cursive
 font with purple & pink color. Why, I have no clue. Being too hard
 to read I refused to help her.


Maybe I should invent a programming language in which color has semantic
value. And fonts. :-P

In fact, that might be a solution to the creeping modifierism that
modern functions seem to have contracted: first it's just return type,
function name, arguments, then there's const, then pure, then  safe,
then nothrow, and all that jazz. If we could map  safe->green,
pure->blue, and nothrow->red (or lack thereof), then a pure nothrow
fuction would be blue, a pure throwing function magenta, a  safe pure
function cyan, and a  safe, pure, throwing function would be white.

Then const can rendered in italics, non-const in upright, immutable in
Fraktur, ref in serif. This way, we can get rid of all those annoying
verbose modifiers and return to the pure joy of return type, function
name, and arguments. Fixing const issues in Phobos would be as simple as
selecting the entire source code and changing the font to italics. :-P


T

-- 
The easy way is the wrong way, and the hard way is the stupid way. Pick one.
Jan 15 2013
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 16/01/2013 01:39, H. S. Teoh wrote:
<snip>

 Maybe I should invent a programming language in which color has semantic
 value. And fonts. :-P


<snip>

There are languages where source takes the form of an image, a musical 
score or some other kind of binary file.
http://esolangs.org/wiki/Category:Non-textual

But I haven't seen one before where it's a word-processor document. 
What document format(s) do you plan to support?  (I guess this would be 
defined at the language level, just like D files being in Unicode is at 
the moment.)

Stewart.
Jan 15 2013
prev sibling next sibling parent "Peter Sommerfeld" <noreply rubrica.at> writes:
H. S. Teoh wrote:

 Maybe I should invent a programming language in which color has semantic
 value. And fonts. :-P


ColorForth by Chuck Moore ....

http://www.colorforth.com/cf.htm

Peter
Jan 16 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/15/2013 5:39 PM, H. S. Teoh wrote:

 Maybe I should invent a programming language in which color has semantic
 value.


That works until your first color blind user.
Jan 16 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 16, 2013 at 04:40:07PM -0800, Walter Bright wrote:

 On 1/15/2013 5:39 PM, H. S. Teoh wrote:

Maybe I should invent a programming language in which color has semantic
value.


 
 That works until your first color blind user.


I wasn't being serious. :)


T

-- 
Food and laptops don't mix.
Jan 16 2013
prev sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 17 January 2013 at 00:40:06 UTC, Walter Bright wrote:

 On 1/15/2013 5:39 PM, H. S. Teoh wrote:

 Maybe I should invent a programming language in which color 
 has semantic value.


 That works until your first color blind user.


  I have a perfect solution! Have a special monitor that can 
transmit the images directly into your brain! No more sense 
dependence issues!

  Okay maybe impractical until technology increases...
Jan 16 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 17, 2013 03:09:35 Era Scarecrow wrote:

   I have a perfect solution! Have a special monitor that can
 transmit the images directly into your brain! No more sense
 dependence issues!


And then you get to worry about people hacking your brain with bad soure code! 
:)

- Jonathan M Davis
Jan 16 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 17 January 2013 at 03:29:46 UTC, Jonathan M Davis 
wrote:

 On Thursday, January 17, 2013 03:09:35 Era Scarecrow wrote:

 I have a perfect solution! Have a special monitor that can 
 transmit the images directly into your brain! No more sense 
 dependence issues!


 And then you get to worry about people hacking your brain with 
 bad source code!
 :)


  Not going to happen, everyone's brain stores and processes 
things in different locations (Not that there aren't enough dumb 
people around). However the transmitter would likely be DRM laden 
and/or hacked (or programmed intentionally) so it would send a 
constant barrage of AD's: (Need Viagra? How about a smoking aid? 
Wheelchair? Prostate cancer tester? New games for your xxx 
console for $xx or less! Gambling at xxx) etc.

  Corporate greed and commercial brainwashing. They go hand in 
hand.
Jan 16 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-17 05:00, Era Scarecrow wrote:


   Not going to happen, everyone's brain stores and processes things in
 different locations (Not that there aren't enough dumb people around).
 However the transmitter would likely be DRM laden and/or hacked (or
 programmed intentionally) so it would send a constant barrage of AD's:
 (Need Viagra? How about a smoking aid? Wheelchair? Prostate cancer
 tester? New games for your xxx console for $xx or less! Gambling at xxx)
 etc.

   Corporate greed and commercial brainwashing. They go hand in hand.


"Brain storm" gets a whole new definition.

-- 
/Jacob Carlborg
Jan 17 2013
prev sibling parent "Mike James" <foo bar.com> writes:
 Maybe I should invent a programming language in which color has semantic
 value. And fonts. :-P


Sort of :-)

http://www.colorforth.com/primer.htm

-=mike=-
Jan 18 2013
prev sibling parent FG <home fgda.pl> writes:
 Maybe I should invent a programming language in which color has semantic
 value. And fonts. :-P


Why stop here? Go paint your programs in Piet. ;)



 Fixing const issues in Phobos would be as simple as
 selecting the entire source code and changing the font to italics. :-P


I suggest a special font designed just for D. ;)
Bold for const, Black for immutable, UltraLight for volatile, keywords 
written in Small Caps, comments in Script (must look handwritten)...

Colours, as you mention would replace safe, pure, nothrow.
Of course a special obligatory colour palette will be created.

And as we're at it, it's time to go one step further in creating code 
friendlier to read, and get those APL keyboards back from the attic, so 
they can be useful once again. :D
Jan 17 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 04:30:55PM +0000, Russel Winder wrote:

 On Tue, 2013-01-15 at 17:02 +0100, mist wrote:
 […]

 monospaced fonts everywhere to rule them all! :)


 
 Monospace fonts are an aberration of the typewriter era.
 
 All text, including code, should be displayed in proportional fonts,
 in my case Ocean Sans Std on my machines.


[...]

Eeek! That would make it impossible to indent code correctly, especially
when there are wrapped lines. I much prefer my grid-based typewriter
display, I have to say.


T

-- 
Guns don't kill people. Bullets do.
Jan 15 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 03:07:08PM +0100, monarch_dodra wrote:

 On Tuesday, 15 January 2013 at 13:55:53 UTC, Timon Gehr wrote:

On 01/15/2013 11:57 AM, mist wrote:

Well, probably I am playing "good vision nazi" here, as 12 font size
seems HUGE to me, far beyond the comfort zone.


It's just preference. I do not have any problems with font size 9.


 
 I do not know of any editor that does not support "ctrl + scroll" to
 change the font sizes on the fly.


I'm a vim nazi. :-P



 I always change the font size of my editor, depending on how
 concentrated I am, my position in my seat, or by how complicated the
 current algorithm is. Or simply if somebody is looking over my
 shoulder.


Huh. I'm glad I don't have the latter problem. Well, good ole ctrl-Z to
return to the shell, or just ctrl-T ctrl-T (I use ratpoison) to switch
to another window, etc., works for me. But then I don't work in a
situation where people I don't want looking at my code can simply walk
by and look over my shoulders. Office security, man! ;-)



 Your editor's font size should not be statically dictated by a
 single number.


I rather prefer to stick to a single font size. It's easier on the brain
to always see the same layout of a particular piece of code. It's like
navigating by landmarks -- you get familiar with where things are laid
out, and it's easier to find things. It just costs too much effort to
keep changing things around.


T

-- 
People demand freedom of speech to make up for the freedom of thought
which they avoid. -- Soren Aabye Kierkegaard (1813-1855)
Jan 15 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 15 January 2013 at 16:17:27 UTC, H. S. Teoh wrote:

 On Tue, Jan 15, 2013 at 03:07:08PM +0100, monarch_dodra wrote:

 On Tuesday, 15 January 2013 at 13:55:53 UTC, Timon Gehr wrote:

On 01/15/2013 11:57 AM, mist wrote:

Well, probably I am playing "good vision nazi" here, as 12 
font size
seems HUGE to me, far beyond the comfort zone.


It's just preference. I do not have any problems with font 
size 9.


 
 I do not know of any editor that does not support "ctrl + 
 scroll" to
 change the font sizes on the fly.


 I'm a vim nazi. :-P



 I always change the font size of my editor, depending on how
 concentrated I am, my position in my seat, or by how 
 complicated the
 current algorithm is. Or simply if somebody is looking over my
 shoulder.


 Huh. I'm glad I don't have the latter problem. Well, good ole 
 ctrl-Z to
 return to the shell, or just ctrl-T ctrl-T (I use ratpoison) to 
 switch
 to another window, etc., works for me. But then I don't work in 
 a
 situation where people I don't want looking at my code can 
 simply walk
 by and look over my shoulders. Office security, man! ;-)


ROFL, I meant when a colleague is helping me debug. Things are 
easier if I bump up the font size by a couple of points, so they 
don't have to bend down to my level or sit next to me just to see 
my code.
Jan 15 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 05:30:34PM +0100, monarch_dodra wrote:

 On Tuesday, 15 January 2013 at 16:17:27 UTC, H. S. Teoh wrote:

On Tue, Jan 15, 2013 at 03:07:08PM +0100, monarch_dodra wrote:




[...]

I always change the font size of my editor, depending on how
concentrated I am, my position in my seat, or by how complicated the
current algorithm is. Or simply if somebody is looking over my
shoulder.


Huh. I'm glad I don't have the latter problem. Well, good ole ctrl-Z
to return to the shell, or just ctrl-T ctrl-T (I use ratpoison) to
switch to another window, etc., works for me. But then I don't work
in a situation where people I don't want looking at my code can
simply walk by and look over my shoulders. Office security, man! ;-)


 
 ROFL, I meant when a colleague is helping me debug. Things are easier
 if I bump up the font size by a couple of points, so they don't have
 to bend down to my level or sit next to me just to see my code.


LOL... talk about lost in translation^W I mean, transmission.

OTOH, that's why I prefer using very large fonts (18pt on 1600x1200, or
15pt on 1280x1024), period. It's easier on my eyes, and also easy for my
colleagues to read from behind my shoulders.


T

-- 
MSDOS = MicroSoft's Denial Of Service
Jan 15 2013
prev sibling parent reply "Graham Fawcett" <fawcett uwindsor.ca> writes:
On Tuesday, 15 January 2013 at 14:07:11 UTC, monarch_dodra wrote:

 On Tuesday, 15 January 2013 at 13:55:53 UTC, Timon Gehr wrote:

 On 01/15/2013 11:57 AM, mist wrote:

 Well, probably I am playing "good vision nazi" here, as 12 
 font size
 seems HUGE to me, far beyond the comfort zone.


 It's just preference. I do not have any problems with font 
 size 9.


 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
Jan 18 2013
next sibling parent Russel Winder <russel winder.org.uk> writes:
On Fri, 2013-01-18 at 17:52 +0100, Graham Fawcett wrote:
[=E2=80=A6]

 FWIW, Emacs doesn't out of the box. But this makes it work:
=20
 (global-set-key [M-mouse-4] 'text-scale-increase)
 (global-set-key [M-mouse-5] 'text-scale-decrease)
=20
 (M- for Alt, or C- for Control.)


Graham,

I am going to count the above as four things I learnt today. Splendid,
no more need to use GEdit. Excellent.

Thanks.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 18 2013
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Jan 18 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 11:56:34AM +0100, mist wrote:

 On Monday, 14 January 2013 at 23:57:18 UTC, Timon Gehr wrote:

This generally comes up as an argument in these discussions, but I
don't buy it. Not all development is done on a desktop with a huge
screen. And even then, there is always something to put on it.
What window manager are you using?


 
 Well, I hardly can imagine rationale behind using netbook for
 serious development aside from being on trip. Even being forced to
 work in ssh to some legacy shell ( I have that unpleasant experience
 :( ) usually limits your term width, not height.


Heh. On the contrary, I find ssh to be a pleasant experience. Most
GUI-heavy editors are so painfully inefficient to use that I find VT100
emulators far more pleasant to work with.



 I am using Gnome Shell, but working mostly in full-screen
 undecorated terminal. It is approximately 75 to 85 lines of vertical
 space in my setup.


I have a 1600x1200 screen, and an 18-point font, which gives me 93*41
terminal size. I find that just about right. (Like I said, I maximize
everything, and anything significantly smaller than 18-point font, I
find quite unreadable.)


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
Jan 15 2013
parent reply "mist" <none none.none> writes:
On Tuesday, 15 January 2013 at 16:22:19 UTC, H. S. Teoh wrote:

 On Tue, Jan 15, 2013 at 11:56:34AM +0100, mist wrote:

 On Monday, 14 January 2013 at 23:57:18 UTC, Timon Gehr wrote:

This generally comes up as an argument in these discussions, 
but I
don't buy it. Not all development is done on a desktop with a 
huge
screen. And even then, there is always something to put on it.
What window manager are you using?


 
 Well, I hardly can imagine rationale behind using netbook for
 serious development aside from being on trip. Even being 
 forced to
 work in ssh to some legacy shell ( I have that unpleasant 
 experience
 :( ) usually limits your term width, not height.


 Heh. On the contrary, I find ssh to be a pleasant experience. 
 Most
 GUI-heavy editors are so painfully inefficient to use that I 
 find VT100
 emulators far more pleasant to work with.


I am vim user myself, but some legacy shells did not support more 
than 80 symbol width, thus the pain and according code style 
guidelines for us poor programmers on that project :)


 I am using Gnome Shell, but working mostly in full-screen
 undecorated terminal. It is approximately 75 to 85 lines of 
 vertical
 space in my setup.


 I have a 1600x1200 screen, and an 18-point font, which gives me 
 93*41
 terminal size. I find that just about right. (Like I said, I 
 maximize
 everything, and anything significantly smaller than 18-point 
 font, I
 find quite unreadable.)


Well this is probably the main reason of different spacing 
tastes. I have literally twice as much vertical space fitting ( 
1920x1080   9pt ), can imagine how it makes you favor more 
compact style.
Jan 15 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 05:31:04PM +0100, mist wrote:

 On Tuesday, 15 January 2013 at 16:22:19 UTC, H. S. Teoh wrote:


[...]

Heh. On the contrary, I find ssh to be a pleasant experience. Most
GUI-heavy editors are so painfully inefficient to use that I find
VT100 emulators far more pleasant to work with.


 
 I am vim user myself, but some legacy shells did not support more
 than 80 symbol width, thus the pain and according code style
 guidelines for us poor programmers on that project :)


I'm perfectly fine with 80 column max, actually. I find that overly long
lines are very difficult to scan. But then if the coding style requires
8-space tabs and you're writing XML, then, well, I can understand why
that would be painful. ;-)

On a tangential note, I used to write Perl code with 2-space
indentation, with code blocks nested 8-10 levels deep. The cascade of
}'s that often occurred at the end of functions was quite a sight to
behold.  :-P


[...]

I have a 1600x1200 screen, and an 18-point font, which gives me 93*41
terminal size. I find that just about right. (Like I said, I maximize
everything, and anything significantly smaller than 18-point font, I
find quite unreadable.)


 
 Well this is probably the main reason of different spacing tastes. I
 have literally twice as much vertical space fitting ( 1920x1080   9pt
 ), can imagine how it makes you favor more compact style.


Probably. And it's probably the reason I dislike today's trend of
half-height^W^W I mean, half-width, monitors: I always work with
maximized windows, and I don't like overly long lines, so resizing the
font to approximately 80 columns at 1920x1080 would literally be
half-height for me, even worse than 80x24.


T

-- 
Indifference will certainly be the downfall of mankind, but who cares? --
Miquel van Smoorenburg
Jan 15 2013
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/15/13 18:52, H. S. Teoh wrote:

 Probably. And it's probably the reason I dislike today's trend of
 half-height^W^W I mean, half-width, monitors: I always work with
 maximized windows, and I don't like overly long lines, so resizing the
 font to approximately 80 columns at 1920x1080 would literally be
 half-height for me, even worse than 80x24.


xrandr  --output DVI-0 --rotate left

:^)

artur
Jan 15 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 07:06:05PM +0100, Artur Skawina wrote:

 On 01/15/13 18:52, H. S. Teoh wrote:

 Probably. And it's probably the reason I dislike today's trend of
 half-height^W^W I mean, half-width, monitors: I always work with
 maximized windows, and I don't like overly long lines, so resizing the
 font to approximately 80 columns at 1920x1080 would literally be
 half-height for me, even worse than 80x24.


 
 xrandr  --output DVI-0 --rotate left
 
 :^)


[...]

That's actually not a bad idea!! Y'know what, I might actually do that
for my next monitor (I think 4:3 monitors are going out of fashion so
fast that in 5 years, they would probably be nowhere to be found). I
shall start a new trend of ultra-high monitors!


T

-- 
This sentence is false.
Jan 15 2013
parent "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 15 January 2013 at 18:10:00 UTC, H. S. Teoh wrote:

 I shall start a new trend of ultra-high monitors!


About time more people showed up to this party... ;)

Make sure you're getting a panel with VESA mount; many monitors 
even at the fairly-high end of the spectrum have cheap stands 
that don't give rotation and height adjustment. My current layout 
is with the vertical monitor on the left, but I think I prefer it 
on the right, more.
Jan 15 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-14 22:31, mist wrote:


 That guy has rather weird sense of beauty... My eyes started bleeding at
 the "Spacing" section.


I have to agree.

-- 
/Jacob Carlborg
Jan 14 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, January 14, 2013 22:31:23 mist wrote:

 On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.
 
 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?po
 st=56177550


 That guy has rather weird sense of beauty... My eyes started
 bleeding at the "Spacing" section.


Agreed. That code was hideous. I think that the section on comments may be
the only thing in that article that I actually agreed with.

- Jonathan M Davis
Jan 15 2013
prev sibling next sibling parent "Xinok" <xinok live.com> writes:
On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


I think more important than any aspect of a particular coding 
style is that style guidelines ensure that code is written in a 
consistent manner. The advantage is that, even if it's a "bad" 
style, you can learn to read and write code in that style which 
makes things predictable. You learn conventions which tell you 
how to use classes and functions without the need to refer to 
documentation. When convention isn't enough, you learn where to 
find the information you need (can it be inferred from the code? 
is it clearly stated in a comment or documentation?). If nothing 
else, you simply learn to read and interpret code written in a 
certain style.

It's certainly to the benefit of developers to have a good coding 
style. But the only thing worse than a bad coding style is a mix 
of styles which makes code inconsistent and unpredictable. There 
needs to be a consensus among the developers on a style guideline.
Jan 14 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/14/2013 11:24 AM, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


Looks like it made reddit:

http://www.reddit.com/r/programming/comments/16k7hm/the_exceptional_beauty_of_doom_3s_source_code/
Jan 14 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/14/2013 2:26 PM, Walter Bright wrote:

 On 1/14/2013 11:24 AM, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


 Looks like it made reddit:

 http://www.reddit.com/r/programming/comments/16k7hm/the_exceptional_beauty_of_doom_3s_source_code/


And slashdot:

http://games.slashdot.org/story/13/01/15/1732216/doom-3-source-code-beautiful
Jan 15 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/14/2013 08:24 PM, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


It is funny how statements about beauty of code tend to overemphasize 
the importance of trivial formatting rules. This is completely 
irrational. Formatting is a part of the process that could be trivially 
automated. It is not what the substance is.
Jan 14 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/14/2013 3:19 PM, Timon Gehr wrote:

 It is funny how statements about beauty of code tend to overemphasize the
 importance of trivial formatting rules. This is completely irrational.
 Formatting is a part of the process that could be trivially automated. It is
not
 what the substance is.


Pedantically, you are correct.

But in practice, I find over and over again that carefully formatted code tends 
to go hand in hand with well designed code.

It's like internet postings. If you see a posting in ALL CAPS, or all lower 
case, or sloppy grammar/spelling, or long runon sentences, or no paragraph 
breaks, etc., it's almost certainly devoid of interesting content. If you see
an 
electronics board with a rat's nest of wires and sloppy construction, odds are 
high it won't work. If you see a neatly laid out board, odds are it works.

And so on for just about every engineering/construction work.
Jan 17 2013
next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 18 January 2013 at 01:59:18 UTC, Walter Bright wrote:

 On 1/14/2013 3:19 PM, Timon Gehr wrote:

 It is funny how statements about beauty of code tend to 
 overemphasize the
 importance of trivial formatting rules. This is completely 
 irrational.
 Formatting is a part of the process that could be trivially 
 automated. It is not
 what the substance is.


 Pedantically, you are correct.

 But in practice, I find over and over again that carefully 
 formatted code tends to go hand in hand with well designed code.

 It's like internet postings.



Also like spam vs. not spam email
Jan 17 2013
prev sibling next sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 01/18/13 02:59, Walter Bright wrote:

 On 1/14/2013 3:19 PM, Timon Gehr wrote:

 It is funny how statements about beauty of code tend to overemphasize the
 importance of trivial formatting rules. This is completely irrational.
 Formatting is a part of the process that could be trivially automated. It is
not
 what the substance is.


 
 Pedantically, you are correct.
 
 But in practice, I find over and over again that carefully formatted code
tends to go hand in hand with well designed code.
 
 It's like internet postings. If you see a posting in ALL CAPS, or all lower
case, or sloppy grammar/spelling, or long runon sentences, or no paragraph
breaks, etc., it's almost certainly devoid of interesting content. If you see
an electronics board with a rat's nest of wires and sloppy construction, odds
are high it won't work. If you see a neatly laid out board, odds are it works.
 
 And so on for just about every engineering/construction work.


This is one of the reasons why automatic code formatting is such a bad idea.

artur
Jan 17 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:

 This is one of the reasons why automatic code formatting is 
 such a bad idea.

 artur
Jan 17 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 18, 2013 07:45:34 Mehrdad wrote:

 On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:

 This is one of the reasons why automatic code formatting is
 such a bad idea.
 
 artur


 



In _any_ language. Inevitably, the formatter ends up totally mangling at least 
some of the lines. In my experience, any attempt to be super strict with the 
formatting rules (as an automatic code formatter must be) results in ugly 
code. A basic set of formatting rules helps the code be consistent and look 
good, but there are always corner cases where the rules must be bent or broken 
in order to make the code appropriately legible. And it requires having a 
human do the formatting to get that kind of flexibility.

- Jonathan M Davis
Jan 17 2013
next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 18 January 2013 at 07:19:16 UTC, Jonathan M Davis 
wrote:

 On Friday, January 18, 2013 07:45:34 Mehrdad wrote:

 On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina 
 wrote:

 This is one of the reasons why automatic code formatting is
 such a bad idea.
 
 artur


 



 In _any_ language. Inevitably, the formatter ends up totally 
 mangling at least some of the lines.
Jan 18 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-18 08:18, Jonathan M Davis wrote:


 In _any_ language. Inevitably, the formatter ends up totally mangling at least
 some of the lines. In my experience, any attempt to be super strict with the
 formatting rules (as an automatic code formatter must be) results in ugly
 code. A basic set of formatting rules helps the code be consistent and look
 good, but there are always corner cases where the rules must be bent or broken
 in order to make the code appropriately legible. And it requires having a
 human do the formatting to get that kind of flexibility.


Eclipse has a pretty darn good code formatter. It formatted the code 
exactly like I wanted to, except in one or two cases but that's usually 
because I broke my own rules.

Example, this is usually how I format a switch statement:

switch (value)
{
     case 1:
         // code
     break;

     case 2:
         // code
     break;
}

But on occasion, when I have only a short single line expression and 
many cases I usually format it like this:

switch (value)
{
     case 1: a = 2; break;
     case 2: a = 3; break;
     case 3: a = 4; break;
}

The formatter will break that.

-- 
/Jacob Carlborg
Jan 18 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 18, 2013 09:47:31 Jacob Carlborg wrote:

 On 2013-01-18 08:18, Jonathan M Davis wrote:

 In _any_ language. Inevitably, the formatter ends up totally mangling at
 least some of the lines. In my experience, any attempt to be super strict
 with the formatting rules (as an automatic code formatter must be)
 results in ugly code. A basic set of formatting rules helps the code be
 consistent and look good, but there are always corner cases where the
 rules must be bent or broken in order to make the code appropriately
 legible. And it requires having a human do the formatting to get that
 kind of flexibility.


 
 Eclipse has a pretty darn good code formatter. It formatted the code
 exactly like I wanted to, except in one or two cases but that's usually
 because I broke my own rules.
 
 Example, this is usually how I format a switch statement:
 
 switch (value)
 {
      case 1:
          // code
      break;
 
      case 2:
          // code
      break;
 }
 
 But on occasion, when I have only a short single line expression and
 many cases I usually format it like this:
 
 switch (value)
 {
      case 1: a = 2; break;
      case 2: a = 3; break;
      case 3: a = 4; break;
 }
 
 The formatter will break that.


But my point is precisely that there are times that you need to break the 
formatting rules in order to make the code look code and be appropriately 
legible. The formatter will probably do a fantastic job of being consistent, 
but that's the problem. _Most_ of the time, it will do the right thing, but 
there are times when you need to break the formatting rules, and that just 
doesn't work when a program is formatting the code for you.

I had to use eclipse's formatter at one of the places that I worked, because 
all commits had to follow, and I hated it. Code formatters are not the ticket 
to good looking code. Quite the opposite, in fact.

- Jonathan M Davis
Jan 18 2013
prev sibling next sibling parent reply "simendsjo" <simendsjo gmail.com> writes:
On Friday, 18 January 2013 at 06:45:37 UTC, Mehrdad wrote:

 On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:

 This is one of the reasons why automatic code formatting is 
 such a bad idea.

 artur







Well.. :)
enum E
{
   S      = 0x01,
   Longer = 0x10,
}

After:
enum E
{
   S = 0x01,
   Longer = 0x10,
}

Any manual formatting like lining up arguments is always lost. 
Following the recommended style guide for a language by hand 
isn't that big a feat, and allows to break it where you feel your 
own style is superior.
Jan 17 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-18 08:21, simendsjo wrote:


 Well.. :)
 enum E
 {
    S      = 0x01,
    Longer = 0x10,
 }

 After:
 enum E
 {
    S = 0x01,
    Longer = 0x10,
 }

 Any manual formatting like lining up arguments is always lost. Following
 the recommended style guide for a language by hand isn't that big a
 feat, and allows to break it where you feel your own style is superior.


I'm pretty sure Eclipse even has an option to align assignments like these.

-- 
/Jacob Carlborg
Jan 17 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 18 January 2013 at 07:21:48 UTC, simendsjo wrote:

 On Friday, 18 January 2013 at 06:45:37 UTC, Mehrdad wrote:

 On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina 
 wrote:

 This is one of the reasons why automatic code formatting is 
 such a bad idea.

 artur







 Well.. :)
 enum E
 {
   S      = 0x01,
   Longer = 0x10,
 }

 After:
 enum E
 {
   S = 0x01,
   Longer = 0x10,
 }

 Any manual formatting like lining up arguments is always lost. 
 Following the recommended style guide for a language by hand 
 isn't that big a feat, and allows to break it where you feel 
 your own style is superior.


That is completely wrong.
Jan 17 2013
prev sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 01/18/13 07:45, Mehrdad wrote:

 On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina wrote:

 This is one of the reasons why automatic code formatting is such a bad idea.


 



Every language. Not only does it mean that the heuristics mentioned by Walter
can't be used (which isn't the main problem, as the error rate is way too high),
but skipping of the manual (re-)formatting-and-verifications-phase actively
reduces code quality by removing opportunities for extra review, discovery of
refactoring possibilities and reflection.
Sane, but badly formatted code is much preferable to bad, but pretty code. The
former can be easily fixed. Ugly code, that also happens to be bad, will be
found and fixed as part of that process.
Auto formatting loses information which makes spotting the truly bad code
harder.

artur
Jan 17 2013
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 18 January 2013 at 07:58:57 UTC, Artur Skawina wrote:

 On 01/18/13 07:45, Mehrdad wrote:

 On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina 
 wrote:

 This is one of the reasons why automatic code formatting is 
 such a bad idea.


 



 Every language. Not only does it mean that the heuristics 
 mentioned by Walter
 can't be used (which isn't the main problem, as the error rate 
 is way too high),
 but skipping of the manual 
 (re-)formatting-and-verifications-phase actively
 reduces code quality by removing opportunities for extra 
 review, discovery of
 refactoring possibilities and reflection.
 Sane, but badly formatted code is much preferable to bad, but 
 pretty code. The
 former can be easily fixed. Ugly code, that also happens to be 
 bad, will be
 found and fixed as part of that process.
 Auto formatting loses information which makes spotting the 
 truly bad code harder.

 artur







not like C++ where everything is ambiguous.


I suggest you give it a try and let the auto-formatter format 
your code to see what I mean.
Jan 18 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 18, 2013 09:12:26 Mehrdad wrote:


 

 not like C++ where everything is ambiguous.
 
 I suggest you give it a try and let the auto-formatter format
 your code to see what I mean.


Heuristics aren't the issue. The problem is that formatters inevitably have a 
strict set of rules about how code is supposed to be laid out, and they don't 
allow you to break them. There are times when it's just plain ugly to follow 
the formatting rules exactly, and the rules need to be bent or broken in order 
to make the code clean and legible. I have never seen a code formatter which 
could do anything like that. Certainly, the more powerful and flexible the code 
formatter is in terms of the rules that you can give it, the fewer such 
problems you run into, but I'd never expect a formatter to be able to avoid 
the problem entirely.

- Jonathan M Davis
Jan 18 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 18 January 2013 at 07:58:57 UTC, Artur Skawina wrote:

 On 01/18/13 07:45, Mehrdad wrote:

 On Friday, 18 January 2013 at 05:41:00 UTC, Artur Skawina 
 wrote:

 This is one of the reasons why automatic code formatting is 
 such a bad idea.


 



 Every language. Not only does it mean that the heuristics 
 mentioned by Walter
 can't be used (which isn't the main problem, as the error rate 
 is way too high),
 but skipping of the manual 
 (re-)formatting-and-verifications-phase actively
 reduces code quality by removing opportunities for extra 
 review, discovery of
 refactoring possibilities and reflection.
 Sane, but badly formatted code is much preferable to bad, but 
 pretty code. The
 former can be easily fixed. Ugly code, that also happens to be 
 bad, will be
 found and fixed as part of that process.
 Auto formatting loses information which makes spotting the 
 truly bad code harder.


Believing that one code formatting will inherently be better than 
what a formatted can do is very similar to the assertion often 
heard that code generated by the compiler is worse than hand 
written assembly or many other recurring similar topic coming 
again and again in dev discussion.

It has been shown more than once that you can beat the compiler 
on some carefully selected piece of code, but generally speaking, 
you have not even a small chance to beat it at a program scale or 
when certain optimizations kicks in. Same goes for the formatter.

As a matter of fact, the time you spend formatting can be better 
spent elsewhere, and the consistency you win in the process has 
many benefits : cleaner diffs and easiers merges because you have 
no formatting conflict. The codebase is consistent, and the tool 
can even help you by reformatting confusing stuff is clearer ones.

Not to mention that all refactoring tools suffer badly if you 
don't have a proper formatter : you spent as much time 
reformatting the code than you would have needed to do the 
refactoring itself.
Jan 18 2013
parent "Rob T" <alanb ucora.com> writes:
On Friday, 18 January 2013 at 08:13:48 UTC, deadalnix wrote:

 Believing that one code formatting will inherently be better 
 than what a formatted can do is very similar to the assertion 
 often heard that code generated by the compiler is worse than 
 hand written assembly or many other recurring similar topic 
 coming again and again in dev discussion.

 It has been shown more than once that you can beat the compiler 
 on some carefully selected piece of code, but generally 
 speaking, you have not even a small chance to beat it at a 
 program scale or when certain optimizations kicks in. Same goes 
 for the formatter.

 As a matter of fact, the time you spend formatting can be 
 better spent elsewhere, and the consistency you win in the 
 process has many benefits : cleaner diffs and easiers merges 
 because you have no formatting conflict. The codebase is 
 consistent, and the tool can even help you by reformatting 
 confusing stuff is clearer ones.

 Not to mention that all refactoring tools suffer badly if you 
 don't have a proper formatter : you spent as much time 
 reformatting the code than you would have needed to do the 
 refactoring itself.


When reading your post, I thought of replacing the concept of an 
automatic source code formatter with an automatic garbage 
collector. We've seen this kind of debate before, with the same 
sort of arguments in favor and against.

It could very well be that so long as the implementation is good, 
the idea of a standardized enforced format may be better than the 
current alternative. It's like the difference between machine 
tooling vs what you get from an anvil and hammer approach. 
Consistency vs inconsistency.

--rt
Jan 18 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 18 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/18/2013 09:48 AM, 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.


Some of the worst code I have seen has been consistently formatted.
Jan 18 2013
next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/18/13 09:58, Timon Gehr wrote:

 On 01/18/2013 09:48 AM, 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.


 
 Some of the worst code I have seen has been consistently formatted.


Mechanically? ;)

artur
Jan 18 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2013 12:58 AM, Timon Gehr wrote:

 On 01/18/2013 09:48 AM, 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.


 Some of the worst code I have seen has been consistently formatted.


pretty is not iff consistently formatted
Jan 18 2013
prev sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
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.

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.

artur
Jan 18 2013
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 18.01.2013 10:10, schrieb Artur Skawina:

 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.


bad code can't look good by pretty-printing - its the semantic not the 
style...

so you can concentrate your analysis completely on the semantic if an a 
fulltime 100% working autoformatter would be always active

and if something like this would become a standard it wouldn't be that 
hard for me as a freelancer to switch codeing-style from company to 
company, department to department - all the while 10 TIMES a year :)

and that would reduce all this sensless dicussion about coding style 
down to an (sometimes not all loved) standard

in the end the semantic of the code is all that counts: style a, b or c 
isn't what keeps the world go round - unixstyle,Qt-style,mfc-style,etc. 
they all are ~good but different
Jan 18 2013
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 18.01.2013 10:20, schrieb dennis luehring:

 so you can concentrate your analysis completely on the semantic if an a
 fulltime 100% working autoformatter would be always active


another nice effect of an autoformatter would be the newcomer-style - 
only the semantic is normaly total shit in the very beginning but the 
style is correct and the semantic is getting better over time, why to 
work on both sides: code semantic AND coding-style - isn't the first 
enough for an whole programmers life to learn?
Jan 18 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 18, 2013 10:20:58 dennis luehring wrote:

 Am 18.01.2013 10:10, schrieb Artur Skawina:

 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.


 
 bad code can't look good by pretty-printing - its the semantic not the
 style...
 
 so you can concentrate your analysis completely on the semantic if an a
 fulltime 100% working autoformatter would be always active
 
 and if something like this would become a standard it wouldn't be that
 hard for me as a freelancer to switch codeing-style from company to
 company, department to department - all the while 10 TIMES a year :)
 
 and that would reduce all this sensless dicussion about coding style
 down to an (sometimes not all loved) standard
 
 in the end the semantic of the code is all that counts: style a, b or c
 isn't what keeps the world go round - unixstyle,Qt-style,mfc-style,etc.
 they all are ~good but different


Formatting can have a huge effect on code legibility. There are plenty of cases 
where slight formatting changes don't make that big a difference, but some 
really can (e.g. where the braces go), and many small differences can add up. 
For instance, I've known folks who used lots and lots of parens (generally not 
relying on operator precedence at all), and that made the code _much_ harder 
to read. Or having too much or too little whitespace can have a large effect on 
how the code looks and how easy it is to read. It's a _highly_ subjective 
issue, but I think that it's misguided to think that code formatting doesn't 
matter. True, the semantics matter more (if nothing else, semantics matter to 
the compiler, whereas formatting doesn't), but it still matters quite a bit.

- Jonathan M Davis
Jan 18 2013
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 18.01.2013 10:29, schrieb Jonathan M Davis:

 Formatting can have a huge effect on code legibility. There are plenty of cases
 where slight formatting changes don't make that big a difference, but some
 really can (e.g. where the braces go), and many small differences can add up.
 For instance, I've known folks who used lots and lots of parens (generally not
 relying on operator precedence at all), and that made the code_much_  harder
 to read. Or having too much or too little whitespace can have a large effect on
 how the code looks and how easy it is to read. It's a_highly_  subjective
 issue, but I think that it's misguided to think that code formatting doesn't
 matter. True, the semantics matter more (if nothing else, semantics matter to
 the compiler, whereas formatting doesn't), but it still matters quite a bit.


don't get me wrong - coding style is very very important

but without an forced formatting standard you got following problems:

-many different coding styles in each company, sometimes even on 
deparment-level, every project
->hard for project jumpers, always a need for everyone to define a standard

coding style itself: _highly_ subjective emotional thing mostly hard to 
discuss in any way
->a forced standard could de-emotionalize the them a little bit

-permanent reformatting when integrating foreign code

a forced coding style could help to define a better base standard that 
many will just use because of its existence

etc...
Jan 18 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 18, 2013 10:45:46 dennis luehring wrote:

 Am 18.01.2013 10:29, schrieb Jonathan M Davis:

 Formatting can have a huge effect on code legibility. There are plenty of
 cases where slight formatting changes don't make that big a difference,
 but some really can (e.g. where the braces go), and many small
 differences can add up. For instance, I've known folks who used lots and
 lots of parens (generally not relying on operator precedence at all), and
 that made the code_much_  harder to read. Or having too much or too
 little whitespace can have a large effect on how the code looks and how
 easy it is to read. It's a_highly_  subjective issue, but I think that
 it's misguided to think that code formatting doesn't matter. True, the
 semantics matter more (if nothing else, semantics matter to the compiler,
 whereas formatting doesn't), but it still matters quite a bit.


 don't get me wrong - coding style is very very important
 
 but without an forced formatting standard you got following problems:
 
 -many different coding styles in each company, sometimes even on
 deparment-level, every project
 ->hard for project jumpers, always a need for everyone to define a standard
 
 coding style itself: _highly_ subjective emotional thing mostly hard to
 discuss in any way
 ->a forced standard could de-emotionalize the them a little bit
 
 -permanent reformatting when integrating foreign code
 
 a forced coding style could help to define a better base standard that
 many will just use because of its existence
 
 etc...


I've worked at places with strict coding standards which included formatting 
rules (in some cases, having to use autoformatters), and I've worked at places 
where strict coding standards were not used, and I've always found the places 
without strict coding standards to be far more pleasant. Things like APIs 
should have standards (e.g. functions are always camelCased, and types are 
PascalCased), but in general, I'm against formatting standards. For the most 
part, keeping files reasonably internally consistent should be enough. About 
the only formatting rules that I think should be strictly adhered to in 
general are bracing rules and spaces vs tabs, and I'm _very_ opinionated about 
those, but it's just plain more pleasant to leave the others to the individual 
developers with the caveat that code within a file should be reasonably 
consistent. And for the most part, that's what we've been doing with Phobos.

- Jonathan M Davis
Jan 18 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 18 January 2013 at 09:30:51 UTC, Jonathan M Davis 
wrote:

 On Friday, January 18, 2013 10:20:58 dennis luehring wrote:

 Am 18.01.2013 10:10, schrieb Artur Skawina:

 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.


 
 bad code can't look good by pretty-printing - its the semantic 
 not the
 style...
 
 so you can concentrate your analysis completely on the 
 semantic if an a
 fulltime 100% working autoformatter would be always active
 
 and if something like this would become a standard it wouldn't 
 be that
 hard for me as a freelancer to switch codeing-style from 
 company to
 company, department to department - all the while 10 TIMES a 
 year :)
 
 and that would reduce all this sensless dicussion about coding 
 style
 down to an (sometimes not all loved) standard
 
 in the end the semantic of the code is all that counts: style 
 a, b or c
 isn't what keeps the world go round - 
 unixstyle,Qt-style,mfc-style,etc.
 they all are ~good but different


 Formatting can have a huge effect on code legibility. There are 
 plenty of cases
 where slight formatting changes don't make that big a 
 difference, but some
 really can (e.g. where the braces go), and many small 
 differences can add up.
 For instance, I've known folks who used lots and lots of parens 
 (generally not
 relying on operator precedence at all), and that made the code 
 _much_ harder
 to read. Or having too much or too little whitespace can have a 
 large effect on
 how the code looks and how easy it is to read. It's a _highly_ 
 subjective
 issue, but I think that it's misguided to think that code 
 formatting doesn't
 matter. True, the semantics matter more (if nothing else, 
 semantics matter to
 the compiler, whereas formatting doesn't), but it still matters 
 quite a bit.


If you believe you know operator precedence, you are probably 
wrong. And even if you are right, most other programmer don't.
Jan 18 2013
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 18 January 2013 at 10:30:33 UTC, deadalnix wrote:

 If you believe you know operator precedence, you are probably 
 wrong. And even if you are right, most other programmer don't.



They're not /that/ bad...

+ - * / %  are like in math
<< >>      are harder, but all you need is to recall that cout << 
x + 2;
            works as written
|  &       are just like in math (or is addition, and is 
multiplication)
^          is in between | and &
|| &&      are just like in math (or is addition, and is 
multiplication)
Jan 18 2013
parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 18 January 2013 at 10:40:50 UTC, Mehrdad wrote:

 On Friday, 18 January 2013 at 10:30:33 UTC, deadalnix wrote:

 If you believe you know operator precedence, you are probably 
 wrong. And even if you are right, most other programmer don't.



 They're not /that/ bad...

 + - * / %  are like in math
 << >>      are harder, but all you need is to recall that cout 
 << x + 2;
            works as written
 |  &       are just like in math (or is addition, and is 
 multiplication)
 ^          is in between | and &
 || &&      are just like in math (or is addition, and is 
 multiplication)



that takes care of helping you remember all the 'sane' cases so 
you don't need parentheses.

If you're doing something obscure like    x = x | y || w & z && 5 
| 6 || 7;
then yeah, you should seriously put parentheses.
Jan 18 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, January 18, 2013 11:30:32 deadalnix wrote:

 If you believe you know operator precedence, you are probably
 wrong. And even if you are right, most other programmer don't.


You really should know the precedence of at least the common operators. For 
instance, I don't think that there's much excuse for code like

if((a == b) && (c != d))

The parens just clutter the code, and any programmer worth their salt should 
know that the comparison operators has higher precedence than the logical 
operators. And programmers should definitley know the precedence of the 
arithmetic operators, such that if they're putting parens around ever 
expression using + or *, then there's a problem.

On the other hand, I can totally understand if someone is nervous about doing 
stuff like

if(++*var == a)

I fully expect that your average programmer won't fully know the operator 
precedence table. _I_ don't know it perfectly. But for the more common 
operators, you should know it, and using extra parens in those cases just 
makes the code harder to read.

- Jonathan M Davis
Jan 18 2013
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 18 January 2013 at 10:49:52 UTC, Jonathan M Davis 
wrote:

 On Friday, January 18, 2013 11:30:32 deadalnix wrote:

 If you believe you know operator precedence, you are probably
 wrong. And even if you are right, most other programmer don't.


 You really should know the precedence of at least the common 
 operators. For
 instance, I don't think that there's much excuse for code like

 if((a == b) && (c != d))

 The parens just clutter the code, and any programmer worth 
 their salt should
 know that the comparison operators has higher precedence than 
 the logical
 operators. And programmers should definitley know the 
 precedence of the
 arithmetic operators, such that if they're putting parens 
 around ever
 expression using + or *, then there's a problem.

 On the other hand, I can totally understand if someone is 
 nervous about doing
 stuff like

 if(++*var == a)

 I fully expect that your average programmer won't fully know 
 the operator
 precedence table. _I_ don't know it perfectly. But for the more 
 common
 operators, you should know it, and using extra parens in those 
 cases just
 makes the code harder to read.

 - Jonathan M Davis


Keep in mind that us, as enthusiasts, have a warped view on the 
matter.

A lot of my "programmer" colleagues don't really give a damn, 
and, for them, precedence stops at arithmetic operators. I'm not 
saying they are bad programmers, but they just can't be arsed 
with that kind of stuff: They just don't care.

*Personally*, I prefer
     if ((a == b) && (c != d))
over
     if (a == b && c != d)

I *know* the precedence here, but I still find it clearer with 
grouping.

HOWEVER, I 100% agree that in such code, the format chosen is 
very very important. Place spaces in the wrong spots:
     if ( ( a == b ) && ( c != d ) )
And the eyes begin to bleed...

As a side note, I've taken to ALWAYS placing parenthesis with 
ternary operators. That thing has some nasty precedence rules...
Jan 18 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/18/2013 01:13 PM, monarch_dodra wrote:

 ...

 *Personally*, I prefer
      if ((a == b) && (c != d))
 over
      if (a == b && c != d)

 I *know* the precedence here, but I still find it clearer with grouping.

 HOWEVER, I 100% agree that in such code, the format chosen is very very
 important. Place spaces in the wrong spots:
      if ( ( a == b ) && ( c != d ) )
 And the eyes begin to bleed...


if(a==b && c!=d)


 As a side note, I've taken to ALWAYS placing parenthesis with ternary
 operators. That thing has some nasty precedence rules...


auto a = b && x ? c :
          d || y ? e :
          f ^ z  ? g :
                   h ;
Jan 18 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
monarch_dodra:


 As a side note, I've taken to ALWAYS placing parenthesis with 
 ternary operators. That thing has some nasty precedence rules...


Then please vote :-)

http://d.puremagic.com/issues/show_bug.cgi?id=8757

Bye,
bearophile
Jan 18 2013
prev sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Friday, 18 January 2013 at 10:49:52 UTC, Jonathan M Davis 
wrote:

 You really should know the precedence of at least the common 
 operators. For instance, I don't think that there's much excuse 
 for code like

 if((a == b) && (c != d))


  Unfortunately I've come across a few cases (and in dmd too) 
where compiles it wrong if you don't and get 
unwanted/unexpected/buggy behavior; So the code looks similar to 
that (but not by choice).

  I 'think' it was something like 'if(a + 2 > b)', but I'd have to 
dig them out to know for among hundreds of lines of code.

  The exact order of precedence has always eluded me and are a set 
of rules I'll never completely remember. However I do know that 
multiplication and division are above addition and subtraction, 
which is the only real place I've come to rely on it a few times 
to remove excess parentheses.
Jan 18 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.


 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.
Jan 18 2013
parent reply Artur Skawina <art.08.09 gmail.com> writes:
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
Jan 19 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 20 2013
parent Artur Skawina <art.08.09 gmail.com> writes:
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
Jan 21 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 17, 2013 at 05:59:13PM -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.
 
 It's like internet postings. If you see a posting in ALL CAPS, or
 all lower case, or sloppy grammar/spelling, or long runon sentences,
 or no paragraph breaks, etc., it's almost certainly devoid of
 interesting content. If you see an electronics board with a rat's
 nest of wires and sloppy construction, odds are high it won't work.
 If you see a neatly laid out board, odds are it works.
 
 And so on for just about every engineering/construction work.


This is interesting. I think it holds not just for code formatting, but
with the overall design of the code as well. When you see unfocused
module APIs, leaky abstractions, and copy-n-pasted code, you know you're
in for a world of pain, no matter how beautifully the code may be
formatted. (Although generally, such symptoms often also go along with
poor formatting. But I've seen horribly-designed code that was
superficially very prettily formatted.) When you see a function that
converts IPv6 addresses to strings and then uses string comparisons for
subnet checking, you know that the rest of the code is going to be
equally bad, if not worse.

And on and on it goes.


T

-- 
Why ask rhetorical questions? -- JC
Jan 17 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/17/2013 5:59 PM, 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.


I might add that trying to find the right way to format code is a non-trivial 
exercise I go through all the time. It matters how it's laid out.

One of my frustrations with C++ is I was never able to figure out a way to 
format its template code into an aesthetically pleasing format.
Jan 18 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2013-01-17 at 17:59 -0800, Walter Bright wrote:
[=E2=80=A6]

 But in practice, I find over and over again that carefully formatted code=


 tends=20

 to go hand in hand with well designed code.


Having an obsessive=E2=80=93compulsive side to your nature is good in these
case.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 18 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 18 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jan 18 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


 From the article:


 [Side note: John Carmack has stated that static analysis tools
 revealed that their common bug was incorrect parameter matching
 in printf(). I wonder if they've changed to stringstreams in
 Rage because of this. GCC and clang both find printf()
 parameter matching errors with -Wall, so you don't need
 expensive static analysis tools to find these errors.]


I'd like the D front-end to statically detect wrong parameter 
matching errors for the write*()/format() functions. (In D I 
don't use "%s" all the time).

----------------------

H. S. Teoh


 The prevalent hatred for templates is mostly the fault
 of poorly-chosen syntax on C++'s part.


The syntax of C++ templates is a problem, but it's not their main 
problem. The main problem is them being untyped. The Rust 
language (tries to) remove this problem copying the best parts of 
the typeclasses from Haskell, but making them efficient for a 
system language. (The redesign of the C++ concepts try to do the 
same, but as usual for C++ it will be a greatly over-engineered 
solution).

Bye,
bearophile
Jan 14 2013
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
I seem to be managing to hit the "Reply" button instead of the 
"Followup" button more often than is desirable.  (What happened to the 
days when "Reply" meant "Followup" in newsreaders?)

On 14/01/2013 19:24, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


Am I the only one who expected, on seeing the subject line, something 
about a coding style that relies heavily on exceptions?

But I agree with most of the points made.  Make code self-documenting. 
And compact, but not at the expense of readability.  Sometimes I see 
code that doesn't seem to be intended as an IO*CC entry, nor an attempt 
to "protect" the code or squash it into as little space as possible for 
release, and yet is so obfuscated that I don't know how the maintainers 
manage to maintain it (let alone decide against deobfuscating it).

I also noticed this:

"Removing a value from an std::vector is dumb too:

vec.erase(std::remove(vec.begin(), vec.end(), val), vec.end());

Gee, that's going to be typed correctly by every programmer every time!"

It seems that even the writer of that piece hasn't typed it correctly - 
from what I can make out, that code would remove everything _except_ val 
from vec.  Either that or it wouldn't work at all, since the vector 
returned by remove is no longer a plain vector iterator.

(Moreover, any clue what possessed the author of that piece to make 
every code sample an image, thereby destroying accessibility and making 
it impossible to c&p?)

And it isn't clear what he means by "real tabs"....

Stewart.
Jan 14 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/15/2013 01:55 AM, Stewart Gordon wrote:

 I seem to be managing to hit the "Reply" button instead of the
 "Followup" button more often than is desirable.  (What happened to the
 days when "Reply" meant "Followup" in newsreaders?)
 ...


I assume you are using thunderbird, because that changed its layout 
fairly recently. You can fix this by right-clicking on the button -> 
'Customize...' IIRC.
Jan 14 2013
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 15/01/2013 01:11, Timon Gehr wrote:
<snip>

 I assume you are using thunderbird, because that changed its layout
 fairly recently. You can fix this by right-clicking on the button ->
 'Customize...' IIRC.


But for some strange reason, getting rid of the Reply button gets rid of 
it when viewing email as well. :(

Stewart.
Jan 15 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/15/2013 09:57 PM, Stewart Gordon wrote:

 On 15/01/2013 01:11, Timon Gehr wrote:
 <snip>

 I assume you are using thunderbird, because that changed its layout
 fairly recently. You can fix this by right-clicking on the button ->
 'Customize...' IIRC.


 But for some strange reason, getting rid of the Reply button gets rid of
 it when viewing email as well. :(

 Stewart.


That is indeed strange. I managed to get it work just right.
Jan 15 2013
prev sibling next sibling parent reply Tavi Cacina <octavian.cacina outlook.com> writes:
Am 15.01.2013 01:55, schrieb Stewart Gordon:

 vec.erase(std::remove(vec.begin(), vec.end(), val), vec.end());

 Gee, that's going to be typed correctly by every programmer every time!"

 It seems that even the writer of that piece hasn't typed it correctly -
 from what I can make out, that code would remove everything _except_ val
 from vec.  Either that or it wouldn't work at all, since the vector
 returned by remove is no longer a plain vector iterator.


That piece of code is correct.
http://en.wikipedia.org/wiki/Erase-remove_idiom
Jan 14 2013
next sibling parent reply FG <home fgda.pl> writes:
On 2013-01-15 08:24, Tavi Cacina wrote:

 Am 15.01.2013 01:55, schrieb Stewart Gordon:

 vec.erase(std::remove(vec.begin(), vec.end(), val), vec.end());


 That piece of code is correct.
 http://en.wikipedia.org/wiki/Erase-remove_idiom


All thanks to a terrible naming decision...
It's not remove but move_to_end. Why call it remove?
Jan 15 2013
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 15/01/2013 10:20, FG wrote:
<snip>

 All thanks to a terrible naming decision...
 It's not remove but move_to_end. Why call it remove?


It doesn't necessarily move them to the end, going by
http://www.cplusplus.com/reference/algorithm/remove/
"The relative order of the elements not removed is preserved, while the 
elements past the new end of range are still valid, although with 
unspecified values."

Just looking at the sample implementation there....

     if (!(*first == value)) *result++ = *first;

places each non-removed value in its place in the final state of the 
container, but doesn't do anything particular with the value where it 
was taken from.  In a C++11 implementation, I would expect it to become

     if (!(*first == value)) *result++ = std::move(*first);

Stewart.
Jan 15 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 09:23:08PM +0000, Stewart Gordon wrote:

 On 15/01/2013 10:20, FG wrote:
 <snip>

All thanks to a terrible naming decision...
It's not remove but move_to_end. Why call it remove?


 
 It doesn't necessarily move them to the end, going by
 http://www.cplusplus.com/reference/algorithm/remove/
 "The relative order of the elements not removed is preserved, while
 the elements past the new end of range are still valid, although
 with unspecified values."


[...]
       ^^^^^^^^^^^
       Very scary, but unfortunately much too frequent in C/C++.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor
first.
Jan 15 2013
prev sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 15 January 2013 at 21:26:14 UTC, Stewart Gordon wrote:

 On 15/01/2013 10:20, FG wrote:
 <snip>

 All thanks to a terrible naming decision...
 It's not remove but move_to_end. Why call it remove?




It HAS to do this because there is a separation of iteration 
primitives and container. An iterator cannot (by itself) 
spontaneously remove a value from a container.

FWI, D has the EXACT same semantics:
1) Use std.algorithm.remove to bump the unwanted values to the 
end of the range, receiving in return a range of said elements.
2) Pass said range to std.container.remove to remove(erase) the 
elements from the container itself.

It may not be intuitive at first, but it makes perfect sense, and 
is (very) good design. It keeps orthogonal concepts orthogonal. 
the erase remove idiom always surprises the first time around, 
but quickly becomes natural. It's a tried and tested idiom.


 It doesn't necessarily move them to the end, going by
 http://www.cplusplus.com/reference/algorithm/remove/
 "The relative order of the elements not removed is preserved, 
 while the elements past the new end of range are still valid, 
 although with unspecified values."

 Just looking at the sample implementation there....

     if (!(*first == value)) *result++ = *first;

 places each non-removed value in its place in the final state 
 of the container, but doesn't do anything particular with the 
 value where it was taken from.  In a C++11 implementation, I 
 would expect it to become

     if (!(*first == value)) *result++ = std::move(*first);

 Stewart.


Note that: "The behavior of this function template is *equivalent 
to*"

In no way does this mean this is the actual implementation. 
Besides, the actual definition as decribed in n3242 is:
//----
Requires: The type of *first shall satisfy the MoveAssignable 
requirements

Effects: Eliminates all the elements referred to by iterator i in 
the range [first,last) for which the following corresponding 
conditions hold: *i == value, pred(*i) != false.

Returns: The end of the resulting range.
//----

The "MoveAssignable" implies what you just said.
Jan 15 2013
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 15/01/2013 07:24, Tavi Cacina wrote:
<snip>

 That piece of code is correct.
 http://en.wikipedia.org/wiki/Erase-remove_idiom


I must have misread the documentation on cplusplus.com.  I'd somehow 
made out that it returns an iterator that skips over the "removed" values.

So the semantics of remove are counter-intuitive, and what it actually 
does is to change something like [1, 3, 5, 5, 7, 5, 9] into [1, 3, 7, 9, 
RG, RG, RG] (RG = random garbage), and return an iterator that points to 
the first RG, and then erase is used to delete the elements from that 
point to the end of the array.  I see now.

But it goes to show that std::remove is counter-intuitve in itself, and 
that there ought to be a more intuitive way in STL of doing a 
search-and-remove operation.

Still, there's nothing to stop you from writing a function wrapper for 
this boilerplate code rather than writing it out every time.

Stewart.
Jan 15 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-15 01:55, Stewart Gordon wrote:


 Am I the only one who expected, on seeing the subject line, something
 about a coding style that relies heavily on exceptions?


Yeah, I thought so too.

-- 
/Jacob Carlborg
Jan 14 2013
prev sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 01/15/13 00:37, bearophile wrote:

 Walter Bright:
 

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


 
 From the article:
 

 [Side note: John Carmack has stated that static analysis tools
 revealed that their common bug was incorrect parameter matching
 in printf(). I wonder if they've changed to stringstreams in
 Rage because of this. GCC and clang both find printf()
 parameter matching errors with -Wall, so you don't need
 expensive static analysis tools to find these errors.]


 
 I'd like the D front-end to statically detect wrong parameter matching errors
for the write*()/format() functions. (In D I don't use "%s" all the time).


Library territory. There's no need to put this in a D compiler.

Except if you'd like to have 'printf("%.2g", d)' instead of 'printf!"%.2g"(d)'
syntax.
Which could be done via a 'printf(enum string, ...);' overload [1] - still
no need for placing the format string verification logic inside the front end.

artur

[1] 'enum' is a better fit for current D, 'static' would be better if 'static'
would be defined saner. For this case the name of the storage class does not
really matter.
Jan 15 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Artur Skawina:


 Library territory. There's no need to put this in a D compiler.


One of the threads about possible ways to allow to implement that 
in library code:

http://forum.dlang.org/thread/nxhsgwliuwdgidaoudud forum.dlang.org



 Except if you'd like to have 'printf("%.2g", d)' instead of 
 'printf!"%.2g"(d)' syntax.


In some cases I don't mind a syntax like 'printf!"%.2g"(d)'. But 
I'd like D to offer ways to remove/avoid template bloat in most 
of those cases.

Bye,
bearophile
Jan 15 2013
parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 01/15/13 12:21, bearophile wrote:

 Artur Skawina:
 

 Library territory. There's no need to put this in a D compiler.


 
 One of the threads about possible ways to allow to implement that in library
code:
 
 http://forum.dlang.org/thread/nxhsgwliuwdgidaoudud forum.dlang.org
 
 

 Except if you'd like to have 'printf("%.2g", d)' instead of 'printf!"%.2g"(d)'
syntax.


 
 In some cases I don't mind a syntax like 'printf!"%.2g"(d)'. But I'd like D to
offer ways to remove/avoid template bloat in most of those cases.


You can't both avoid template bloat *and* statically check the arguments.
Statically checking dynamic data is not possible, obviously. But it's not
always a problem, as as long as everything is properly inlined the overhead
can be /less/ than zero. Anyway, a way to do these check right now could be
something like:

   auto printf(string fmt, A...)(A a) /* inline*/ {
      static bool isFlag(char c) {
         switch (c) {

            case '\'': case 'I': // Non-std.
               return true;
            default: return false;
         }
      }
      static bool checkArgs(B...)(string fmt) {
         if (!__ctfe)
            assert(0, "This function relies on bounds checks happening at CT");
         while (fmt.length && fmt[0]!='%')
            fmt = fmt[1..$];
         if (fmt.length==0)
            return true;
         static if (B.length==0)
            return fmt.length==0;
         else {
            size_t skip = 1;
            // Flags
            while (isFlag(fmt[skip]))
               ++skip;
            // Width
            while (fmt[skip]>='0' && fmt[skip]<='9')
               ++skip;
            // Precision
               // XXX skip \.[0-9]* , \.\*, \.[0-9]+\$ 
            // Length modifier
               // XXX skip them.
            // Conversion spec
            if (
                (fmt[skip]=='d' && is(B[0]==int))
             || (fmt[skip]=='g' && is(B[0]==double))
             || (fmt[skip]=='s' && is(typeof(cast()*B[0])==char))
             /* XXX etc */
                )
               return checkArgs!(B[1..$])(fmt[skip+1..$]);
            assert(0, "printf format error: '" ~ fmt ~ "', remaining args: " ~
B.stringof);
         }
      }

      static assert(checkArgs!A(fmt), "Invalid or unsupported printf args");

      import si = std.stdio, std.string;
      return si.printf(toStringz(fmt), a);
   }

   void main() {
      printf!"Pi == %d.%d != %3d\n"(3, 14, 314);
      printf!"Pi == %d.%d == %g\n"(3, 14, 3.14);
      printf!"Pi == %d.%d == %g == %s\n"(3, 14, 3.14, "3.14".ptr);

      // correctly flagged as invalid:
      //printf!"%"(42);
   }

But ideally the syntax should be

   printf(A...)(static string s, A a)

which would be "lowered" to the equivalent of

   printf(string s, A...)(A a)

and similarly:

   printf(A...)(alias a, A a)

should behave as

   print(alias a, A...)(A a)


Having this work just for templated functions would probably be ok.

artur
Jan 15 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Artur Skawina:


 You can't both avoid template bloat *and* statically check the 
 arguments.


In a well designed statically compiled language you don't need to 
instantiate templates and let them generate binary code to 
statically verify a condition. What's needed to test compile time 
arguments is just some compile-time computation; there is no need 
for such computation to leave any trace in the resulting binary. 
Beside the idea of "ghost types" (it's not a Pokemon), see also 
this little thread:

http://forum.dlang.org/thread/nxhsgwliuwdgidaoudud forum.dlang.org

D needs ways to avoid some template bloat in the first place, not 
just to remove it later.

In some cases I'd like to write code like this, but to not let 
this generate different template instantiations (this means x is 
really a run-time value, but it's required to be known at 
compile-time):

void foo(int x)(string s) {}

Bye,
bearophile
Jan 15 2013
parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 01/15/13 14:25, bearophile wrote:

 Artur Skawina:
 

 You can't both avoid template bloat *and* statically check the arguments.


 
 In a well designed statically compiled language you don't need to instantiate
templates and let them generate binary code to statically verify a condition.
What's needed to test compile time arguments is just some compile-time
computation; there is no need for such computation to leave any trace in the
resulting binary.


You do realize that the code I posted in the previous message gave you static
verification at compile time and _zero_ runtime overhead? It's incomplete and
adds a toStringz call because it's just a POC. Actually that call can be
dropped,
assuming a template string parameter is always null-terminated (which could be
specced that way), and then:

   void main() {
      printf!"Pi == %d.%d == %g == %s\n"(3, 14, 3.14, "3.14".ptr);
   }

compiles to:

   <_Dmain>:
       55                      push   %ebp
       89 e5                   mov    %esp,%ebp
       83 ec 28                sub    $0x28,%esp
       dd 05 88 d7 06 08       fldl   0x806d788
       c7 44 24 14 64 d7 06    movl   $0x806d764,0x14(%esp)
       08 
       dd 5c 24 0c             fstpl  0xc(%esp)
       c7 44 24 08 0e 00 00    movl   $0xe,0x8(%esp)
       00 
       c7 44 24 04 03 00 00    movl   $0x3,0x4(%esp)
       00 
       c7 04 24 69 d7 06 08    movl   $0x806d769,(%esp)
       e8 4c f2 ff ff          call   8049100 <printf plt>
       31 c0                   xor    %eax,%eax
       c9                      leave  
       c3                      ret    

You can't get any less overhead than this; not even when using a "well designed
statically compiled language".

Being able to easily force evaluation at compile time and even a compile-time
mutable ephemeral storage class would be good ideas, but are not necessary for
this (they would make some things simpler, eliminate the need for recursion etc
- yes).


 Beside the idea of "ghost types" (it's not a Pokemon), see also this little
thread:
 
 http://forum.dlang.org/thread/nxhsgwliuwdgidaoudud forum.dlang.org
 
 D needs ways to avoid some template bloat in the first place, not just to
remove it later.
 
 In some cases I'd like to write code like this, but to not let this generate
different template instantiations (this means x is really a run-time value, but
it's required to be known at compile-time):
 
 void foo(int x)(string s) {}


A /run-time value known at compile-time/ is an oxymoron.

How would your above function to differ from this one
'void foo(alias x)(string s) {}' ?
Are you asking for 'void foo(alias int x)(string s) {}'?


artur
Jan 15 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Artur Skawina:


 static assert(checkArgs!A(fmt), "Invalid or unsupported printf 
 args");


A template constraint is better, I think.



You can't get any less overhead than this; not even when using a 
"well designed


statically compiled language".<

Maybe if you compile that with dmd and you look in the binary I 
think you will find some stuff related to that that's not needed.



 void foo(int x)(string s) {}


 A /run-time value known at compile-time/ is an oxymoron.

 How would your above function to differ from this one
 'void foo(alias x)(string s) {}' ?
 Are you asking for 'void foo(alias int x)(string s) {}'?


That wasn't an important request, feel free to ignore it.

What I was trying to say is not impossible. The run-time 
semantics of this:

void foo(static int x)(string s) {}

Is meant to be the same as:

void foo(int x, string s) {}

The only difference is that the compiler requires x to be 
statically known (but then you can't use specialize code on the 
value of x, because that's really not a template function).

This is also allowed, and it's similar to what we were discussing 
about:

void foo(static int x)(string s) if (predicate(x)) {}

Bye,
bearophile
Jan 15 2013
parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/15/13 16:27, bearophile wrote:

 Artur Skawina:
 

 static assert(checkArgs!A(fmt), "Invalid or unsupported printf args");


 
 A template constraint is better, I think.


Not necessarily, if you want helpful error messages.


 You can't get any less overhead than this; not even when using a "well designed


 statically compiled language".<
 
 Maybe if you compile that with dmd and you look in the binary I think you will
find some stuff related to that that's not needed.


Never used DMD.
D is designed with an sufficiently smart compiler in mind, for some realistic
and
practical definition of a SSC. Therefore failure to perform certain
optimizations,
which are reasonably required by the language (like inlining), is a mere quality
of implementation issue.

Yes, it's not the best approach, not relying completely on the optimizer would
have
been better, but the D design is as it is, and until that changes blaming the
compiler is the only option.


 void foo(int x)(string s) {}


 A /run-time value known at compile-time/ is an oxymoron.

 How would your above function to differ from this one
 'void foo(alias x)(string s) {}' ?
 Are you asking for 'void foo(alias int x)(string s) {}'?


 
 That wasn't an important request, feel free to ignore it.


I'm trying to understand what you're asking for.



 What I was trying to say is not impossible. The run-time semantics of this:
 
 void foo(static int x)(string s) {}
 
 Is meant to be the same as:
 
 void foo(int x, string s) {}
 
 The only difference is that the compiler requires x to be statically known
(but then you can't use specialize code on the value of x, because that's
really not a template function).
 
 This is also allowed, and it's similar to what we were discussing about:
 
 void foo(static int x)(string s) if (predicate(x)) {}


Define "x to be statically known".

   void foo()(int x, string s) { import std.stdio; writeln(x, s); }

   auto foo(alias X)(string s) /* inline*/ /*if (__traits(compiles, foo(X,
s)))*/ {
      return foo(X, s);
   }

   void main() {
      foo!1("one");
      foo!2("two");
      int three = 3;
      foo!three("three");
   }

   /*  The last foo!three case fails with the template constraint enabled,
       but /does/ compile w/o it, btw */

I still have no idea *why* you'd want such a thing...

artur
Jan 15 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/15/2013 11:59 AM, Artur Skawina wrote:

 ...

 Except if you'd like to have 'printf("%.2g", d)' instead of 'printf!"%.2g"(d)'
 syntax.


printf(q!"%.2g", d) works too.
Jan 15 2013
prev sibling next sibling parent "Andrey" <andr-sar yandex.ru> writes:
Well, personally I love this simple and accurate C-style look. 
I'm not a fan of syntax sugar and operator overloading and I 
would prefer:

arr.insertKey("myword", value); instead of arr["myword"] = value;

Here I emphasize that I'm inserting new key and not modifying the 
value of already present.

At the same time you have to use OOP style call 
arr.remove("word").

And I'm very happy to have nested structs, class and functions in 
D. :-)
Jan 14 2013
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2013-01-14 at 11:24 -0800, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.
=20
 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?p=


ost=3D56177550

On the other hand I don't like some parts of the style he is putting
forward as good.

Go has an extreme position on this, there is one and only one style of
code that is acceptable, the one defined in the gofmt program that is
used to format all Go code. I happen not to like some parts of it, but I
live with the enforced style.

Python is less extreme, in that there are many styles of code allowed,
but there is PEP-8 which is "Python style as Guido intended".  This is
supported by the pep8 program for enforcing elements of style. I have
disagreement with some of the choices, but I live with it, and format my
code to PEP-8 except for the line length rule =E2=80=93 which is just so 19=
80s.

C, C++, D, Fortran, Groovy, probably need to learn a lesson from one or
other of these.

The issue is that having a single global style standard for a
programming language makes it easier to read code in that language.
=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 15 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/15/2013 2:58 AM, Russel Winder wrote:

 The issue is that having a single global style standard for a
 programming language makes it easier to read code in that language.


Yup, it's better even if there are parts of it one doesn't like.
Jan 16 2013
prev sibling next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-58-15 11:01, Russel Winder <russel winder.org.uk> wrote:


 On Mon, 2013-01-14 at 11:24 -0800, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-co=




de?post=3D56177550

 On the other hand I don't like some parts of the style he is putting
 forward as good.

 Go has an extreme position on this, there is one and only one style of=



 code that is acceptable, the one defined in the gofmt program that is
 used to format all Go code. I happen not to like some parts of it, but=


 I

 live with the enforced style.

 Python is less extreme, in that there are many styles of code allowed,=



 but there is PEP-8 which is "Python style as Guido intended".  This is=



 supported by the pep8 program for enforcing elements of style. I have
 disagreement with some of the choices, but I live with it, and format =


my

 code to PEP-8 except for the line length rule =E2=80=93 which is just =


so 1980s.

 C, C++, D, Fortran, Groovy, probably need to learn a lesson from one o=


r

 other of these.

 The issue is that having a single global style standard for a
 programming language makes it easier to read code in that language.


I agree a canonical form could be nice. Even so, I am firmly of the
opinion that such should not be forced upon programmers. Prettifiers
certainly can help here.

-- =

Simen
Jan 15 2013
parent reply "renoX" <renozyx gmail.com> writes:
On Tuesday, 15 January 2013 at 11:43:20 UTC, Simen Kjaeraas wrote:

 On 2013-58-15 11:01, Russel Winder <russel winder.org.uk> wrote:


 On Mon, 2013-01-14 at 11:24 -0800, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


 On the other hand I don't like some parts of the style he is 
 putting
 forward as good.

 Go has an extreme position on this, there is one and only one 
 style of
 code that is acceptable, the one defined in the gofmt program 
 that is
 used to format all Go code. I happen not to like some parts of 
 it, but I
 live with the enforced style.

 Python is less extreme, in that there are many styles of code 
 allowed,
 but there is PEP-8 which is "Python style as Guido intended".  
 This is
 supported by the pep8 program for enforcing elements of style. 
 I have
 disagreement with some of the choices, but I live with it, and 
 format my
 code to PEP-8 except for the line length rule – which is just 
 so 1980s.

 C, C++, D, Fortran, Groovy, probably need to learn a lesson 
 from one or
 other of these.

 The issue is that having a single global style standard for a
 programming language makes it easier to read code in that 
 language.


 I agree a canonical form could be nice. Even so, I am firmly of 
 the
 opinion that such should not be forced upon programmers. 
 Prettifiers certainly can help here.


Not really; prettiffiers works for 99% of the code and mess the 
remaining 1%, that's why it is better to "force" programmers to 
use one style and not relying on a tool..
Jan 15 2013
parent dennis luehring <dl.soluz gmx.net> writes:
 Not really; prettiffiers works for 99% of the code and mess the
 remaining 1%, that's why it is better to "force" programmers to
 use one style and not relying on a tool..


ok but one can argue that having an coding standard defined by the 
community (like design and syntax of D) plus an standard (buildin) 
prettyprinter like goformat could be much better then the current known 
tools out there
Jan 15 2013
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
sorry if this has already been posted, but Phoronix did an 
article on John Carmack's words as well, and the forum discussion 
has a bit of talk about D in it (specifically how it compares to 
C++).

http://phoronix.com/forums/showthread.php?76719-John-Carmack-s-Comments-On-C-C#post306255
Jan 15 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/15/2013 9:32 AM, F i L wrote:

 sorry if this has already been posted, but Phoronix did an article on John
 Carmack's words as well, and the forum discussion has a bit of talk about D in
 it (specifically how it compares to C++).

 http://phoronix.com/forums/showthread.php?76719-John-Carmack-s-Comments-On-C-C#post306255


Thanks, it's an interesting thread.
Jan 16 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 15, 2013 at 10:58:47AM +0000, Russel Winder wrote:
[...]

 Go has an extreme position on this, there is one and only one style of
 code that is acceptable, the one defined in the gofmt program that is
 used to format all Go code. I happen not to like some parts of it, but
 I live with the enforced style.
 
 Python is less extreme, in that there are many styles of code allowed,
 but there is PEP-8 which is "Python style as Guido intended".  This is
 supported by the pep8 program for enforcing elements of style. I have
 disagreement with some of the choices, but I live with it, and format
 my code to PEP-8 except for the line length rule – which is just so
 1980s.
 
 C, C++, D, Fortran, Groovy, probably need to learn a lesson from one
 or other of these.
 
 The issue is that having a single global style standard for a
 programming language makes it easier to read code in that language.


[...]

I used to despise Python, because of its imposed indentation
conventions. But after I started using SCons, I acquired a liking to the
"whitespace thing". It's actually very nice to be able to indicate
nesting just by whitespace alone. No need to worry about pathologies
like }'s on the wrong line, leading to wrong indentation and misleading
code appearances, etc..

I used to hate being forced to code in any other style than my own, too.
But after working with my previous supervisor, who used what I
considered an overly verbose style, I started very much liking the fact
that the code is so easy to read, and identifier names so easy to guess.
There were no creative (aka inconsistent) abbreviations, shortcuts,
etc., everything followed a predictable scheme, and declarations and
wrapped lines line up correctly. You didn't even have to know much about
the code to be able to correctly guess what it does.

Compare that with the other project that I worked on, in which
everything was in terse C coding style: inconsistent abbreviations
everywhere, unhelpful local variable names, gratuitous omission of
whitespace, etc..  It was anybody's guess what a piece of code actually
does. Sometimes, when enough pointer-to-struct-of-pointers-to-structs
coupled with tables of callback function pointers (with unhelpfully
terse names) which are initialized by calling tables of function
pointers which are initialized in diverse obscure places, the exact
location of which depended upon runtime parameters, it was impossible to
understand what the code does even upon a careful reading. Needless to
say, plenty of bugs abound due to people not understanding what exactly
the code is doing.

Having a global coding style annoys most programmers (probably because
it insults their creativity), but it does a world of good when you're
working in a large collaborative project.


T

-- 
He who does not appreciate the beauty of language is not worthy to bemoan its
flaws.
Jan 15 2013
prev sibling parent reply "Rob T" <alanb ucora.com> writes:
On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


The sad part is that after all these decades, we're still 
_writing_ code, and we're doing it in essentially the exact same 
way as was done 30 years ago using a text editor.

For whatever reason, no other means of constructing software 
programs has really taken off, and I have to wonder why.

--rt
Jan 15 2013
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 15 January 2013 at 23:57:44 UTC, Rob T wrote:

 On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


 The sad part is that after all these decades, we're still 
 _writing_ code, and we're doing it in essentially the exact 
 same way as was done 30 years ago using a text editor.

 For whatever reason, no other means of constructing software 
 programs has really taken off, and I have to wonder why.

 --rt


Probably because typing with the keyboard directly is darn faster 
than anything that might involve the editor guessing what you're 
typing (or you using the mouse).
Jan 15 2013
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Wednesday, 16 January 2013 at 00:41:51 UTC, Mehrdad wrote:

 On Tuesday, 15 January 2013 at 23:57:44 UTC, Rob T wrote:

 On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright 
 wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


 The sad part is that after all these decades, we're still 
 _writing_ code, and we're doing it in essentially the exact 
 same way as was done 30 years ago using a text editor.

 For whatever reason, no other means of constructing software 
 programs has really taken off, and I have to wonder why.

 --rt


 Probably because typing with the keyboard directly is darn 
 faster than anything that might involve the editor guessing 
 what you're typing (or you using the mouse).


There's nothing stopping a more superior method from still using 
the keyboard.

What amazes me is how much language complexity is added just to 
make text editing more bearable.
Jan 15 2013
parent reply "Rob T" <alanb ucora.com> writes:
On Wednesday, 16 January 2013 at 01:03:36 UTC, Peter Alexander 
wrote:

 There's nothing stopping a more superior method from still 
 using the keyboard.

 What amazes me is how much language complexity is added just to 
 make text editing more bearable.


I agree, and consider this discussion as being a part of that 
complexity. We're accomplishing nothing of much importance really 
by aligning columns and adjusting font size, it's arcane.

I've even invented my own a naming convention to try and make 
text coding more bearable and efficient, but it had only limited 
success. I tried various IDE's but none of them seemed to make 
much difference, it's still text after all.

There are however some advantages with using text to construct 
programs, such as the extreme compactness and near universal 
compatibility with any text editor, however I highly doubt it is 
the most efficient or effective means of building software 
systems. The lack of innovation in this area is rather 
bewildering.

--rt
Jan 15 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 16 January 2013 at 01:29:24 UTC, Rob T wrote:

 On Wednesday, 16 January 2013 at 01:03:36 UTC, Peter Alexander 
 wrote:

 There's nothing stopping a more superior method from still 
 using the keyboard.

 What amazes me is how much language complexity is added just 
 to make text editing more bearable.


 I agree, and consider this discussion as being a part of that 
 complexity. We're accomplishing nothing of much importance 
 really by aligning columns and adjusting font size, it's arcane.




I actually find aligning columns to be extremely handy, assuming 
your editor has column-editing ability.

When you have a ton of similar lines of code which need to be 
edited in parallel, lining them up lets you edit all of them in 
one keystroke. Saves me quite a lot of annoying editing in the 
long run, actually.
Jan 16 2013
next sibling parent reply "mist" <none none.none> writes:
 When you have a ton of similar lines of code which need to be 
 edited in parallel, lining them up lets you edit all of them in 
 one keystroke. Saves me quite a lot of annoying editing in the 
 long run, actually.


When you have a ton of similar lines of code, you'd better start 
thinking about templates or mixins :P

Also, in regard of "new approach" to programming - is there a 
single method of interaction out there that is more efficient 
than plain text? It is kind of descriptive that we have so many 
different Desktop Environments and power users still prefer 
terminal everywhere.
Jan 16 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 16 January 2013 at 11:00:48 UTC, mist wrote:

 When you have a ton of similar lines of code which need to be 
 edited in parallel, lining them up lets you edit all of them 
 in one keystroke. Saves me quite a lot of annoying editing in 
 the long run, actually.


 When you have a ton of similar lines of code, you'd better 
 start thinking about templates or mixins :P



Easy to say in theory, but makes absolutely no sense in many 
cases. =P

Example:
boost::unordered_set<int> foo;
boost::unordered_map<int> bar;


and now I want to change 'boost' to 'std' because C++11 came out.

Templates? Mixins? wtf lol
Jan 16 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 16 January 2013 at 18:38:21 UTC, Mehrdad wrote:

 On Wednesday, 16 January 2013 at 11:00:48 UTC, mist wrote:

 When you have a ton of similar lines of code which need to be 
 edited in parallel, lining them up lets you edit all of them 
 in one keystroke. Saves me quite a lot of annoying editing in 
 the long run, actually.


 When you have a ton of similar lines of code, you'd better 
 start thinking about templates or mixins :P



 Easy to say in theory, but makes absolutely no sense in many 
 cases. =P

 Example:
 boost::unordered_set<int> foo;
 boost::unordered_map<int> bar;


 and now I want to change 'boost' to 'std' because C++11 came 
 out.

 Templates? Mixins? wtf lol


Another example:

template<class T> struct foo
{
	int x;
	int operator+(int) const { }
	int operator-(int) const { }
	int operator*(int) const { }
};

template<class T> int foo<T>::operator+(int x) const { return 
this->x + x; }
template<class T> int foo<T>::operator-(int x) const { return 
this->x - x; }
template<class T> int foo<T>::operator*(int x) const { return 
this->x * x; }



let's say now I want to add a new template parameter, class U, to 
all the functions.



If you can teach me how "templates" or "mixins" would solve my 
problem here I'd love to know.
Jan 16 2013
parent reply "mist" <none none.none> writes:
On Wednesday, 16 January 2013 at 18:42:38 UTC, Mehrdad wrote:

 On Wednesday, 16 January 2013 at 18:38:21 UTC, Mehrdad wrote:

 On Wednesday, 16 January 2013 at 11:00:48 UTC, mist wrote:

 When you have a ton of similar lines of code which need to 
 be edited in parallel, lining them up lets you edit all of 
 them in one keystroke. Saves me quite a lot of annoying 
 editing in the long run, actually.


 When you have a ton of similar lines of code, you'd better 
 start thinking about templates or mixins :P



 Easy to say in theory, but makes absolutely no sense in many 
 cases. =P

 Example:
 boost::unordered_set<int> foo;
 boost::unordered_map<int> bar;


 and now I want to change 'boost' to 'std' because C++11 came 
 out.

 Templates? Mixins? wtf lol


 Another example:

 template<class T> struct foo
 {
 	int x;
 	int operator+(int) const { }
 	int operator-(int) const { }
 	int operator*(int) const { }
 };

 template<class T> int foo<T>::operator+(int x) const { return 
 this->x + x; }
 template<class T> int foo<T>::operator-(int x) const { return 
 this->x - x; }
 template<class T> int foo<T>::operator*(int x) const { return 
 this->x * x; }



 let's say now I want to add a new template parameter, class U, 
 to all the functions.



 If you can teach me how "templates" or "mixins" would solve my 
 problem here I'd love to know.


This is a single template operator in D so it kind of solves the 
problem. First is tricky, but is exactly the reason sometimes 
types from external libs are used only via alias/typedef. I'd 
prefer something like :%s/boost::unord/std::unord/g though :) But 
well, if you are working with C++, then templates and mixins will 
hardly solve most problems of course, because C++ templates sucks 
and mixins do not even exist there.
Jan 16 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 16 January 2013 at 18:57:06 UTC, mist wrote:

 This is a single template operator in D so it kind of solves 
 the problem. First is tricky, but is exactly the reason 
 sometimes types from external libs are used only via 
 alias/typedef. I'd prefer something like 
 :%s/boost::unord/std::unord/g though :) But well, if you are 
 working with C++, then templates and mixins will hardly solve 
 most problems of course, because C++ templates sucks and mixins 
 do not even exist there.




Yeah I'm working in C++, not D.


But even if I was using D, there's no way in heck that I would 
use a _MIXIN_ for that:

mixin("I'm not sure how this is supposed too be 
readable").unordered_map!(int) a;

makes no sense to me at all, when I could just as well have said 
'boost'.



Also, the search/replace thing won't work so well for any 
real-world example (the second one is a lot closer to what I had 
in mind... you can't just replace "T" with "T, U" and expect it 
to work).


So my point is: no, it's not a simple matter of abstracting 
things away. Lined-up text really DOES make certain tasks easier 
than they would be otherwise.
Jan 16 2013
next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 16 January 2013 at 19:06:47 UTC, Mehrdad wrote:

 On Wednesday, 16 January 2013 at 18:57:06 UTC, mist wrote:

 This is a single template operator in D so it kind of solves 
 the problem. First is tricky, but is exactly the reason 
 sometimes types from external libs are used only via 
 alias/typedef. I'd prefer something like 
 :%s/boost::unord/std::unord/g though :) But well, if you are 
 working with C++, then templates and mixins will hardly solve 
 most problems of course, because C++ templates sucks and 
 mixins do not even exist there.




 Yeah I'm working in C++, not D.


 But even if I was using D, there's no way in heck that I would 
 use a _MIXIN_ for that:

 mixin("I'm not sure how this is supposed too be 
 readable").unordered_map!(int) a;

 makes no sense to me at all, when I could just as well have 
 said 'boost'.



 Also, the search/replace thing won't work so well for any 
 real-world example (the second one is a lot closer to what I 
 had in mind... you can't just replace "T" with "T, U" and 
 expect it to work).


 So my point is: no, it's not a simple matter of abstracting 
 things away. Lined-up text really DOES make certain tasks 
 easier than they would be otherwise.


++1.

Also, regular expressions ;)
Jan 16 2013
prev sibling parent reply "mist" <none none.none> writes:
On Wednesday, 16 January 2013 at 19:06:47 UTC, Mehrdad wrote:

 On Wednesday, 16 January 2013 at 18:57:06 UTC, mist wrote:

 This is a single template operator in D so it kind of solves 
 the problem. First is tricky, but is exactly the reason 
 sometimes types from external libs are used only via 
 alias/typedef. I'd prefer something like 
 :%s/boost::unord/std::unord/g though :) But well, if you are 
 working with C++, then templates and mixins will hardly solve 
 most problems of course, because C++ templates sucks and 
 mixins do not even exist there.




 Yeah I'm working in C++, not D.


 But even if I was using D, there's no way in heck that I would 
 use a _MIXIN_ for that:

 mixin("I'm not sure how this is supposed too be 
 readable").unordered_map!(int) a;

 makes no sense to me at all, when I could just as well have 
 said 'boost'.



 Also, the search/replace thing won't work so well for any 
 real-world example (the second one is a lot closer to what I 
 had in mind... you can't just replace "T" with "T, U" and 
 expect it to work).


 So my point is: no, it's not a simple matter of abstracting 
 things away. Lined-up text really DOES make certain tasks 
 easier than they would be otherwise.


Mixins and templates are tools to avoid copy-paste, there is no 
point to using them just for the sake of that. I have already 
mentioned that first example is not related to copy-paste and 
thus not fixable with that, it is more related to alias. Second 
is fixed perfectly in D using string mixins and single template 
unary operator with much more readable code.

My point is - when you have a lot repetitive text pieces in your 
code, it is much better in longer scope to use advanced language 
tools instead of advanced editing tools. And this is one place 
where D is so superior do C++. I must admit I'd prefer to have 
template mixins allowed for statements to minimize string mixin 
usage but it is still much much better than copy-paste in my 
opinion.
Jan 16 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 16 January 2013 at 19:29:59 UTC, mist wrote:

 Mixins and templates are tools to avoid copy-paste, there is no 
 point to using them just for the sake of that. I have already 
 mentioned that first example is not related to copy-paste and 
 thus not fixable with that, it is more related to alias. Second 
 is fixed perfectly in D using string mixins and single template 
 unary operator with much more readable code.




String mixin are uglier than C-macros, IMO.
(No, I'm not saying they're worse. They're just uglier, visually 
speaking.)
I avoid string mixins as much as possible.


Not to mention they're quite intensive work for the compiler to 
do compared to a regular declaration, which creates obvious 
problems.





 My point is - when you have a lot repetitive text pieces in 
 your code, it is much better in longer scope to use advanced 
 language tools instead of advanced editing tools.


Only if the increase in ugliness is worth the ease of editing.



 And this is one place where D is so superior do C++.


Sure, but that's an unrelated discussion.



 I must admit I'd prefer to have template mixins allowed for 
 statements to minimize string mixin usage but it is still much 
 much better than copy-paste in my opinion.



The problem with the idea of a mixin is that it's just ___too 
much abstraction___.

It's almost like making a FactoryFactorFactory in Java, except 
now you have a MyClassOperatorMixinTemplate or something like 
that.


I don't know about you, but I just don't believe in abstracting 
away every single character I type.
Jan 16 2013
next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 16 January 2013 at 21:45:49 UTC, Mehrdad wrote:

 The problem with the idea of a mixin is that it's just ___too 
 much abstraction___.



Clarification: I meant the problem with the idea of using a mixin 
to solve THIS kind of editing problem.

Obviously there's appropriate situations for those too, but 
"avoiding text alignment" isn't high on that list imo.
Jan 16 2013
prev sibling parent "mist" <none none.none> writes:
Well, initially it was just a harmless joke about some unique D 
features. It is digitalmars.D newsgroup after all, no idea why 
you have taken this so seriously.

But well, if you want to take this seriously, then I need to 
state that I can't agree with "Only if the increase in ugliness 
is worth the ease of editing.". Prevention of copy paste is 
always worth any additional ugliness or incomfort it brings to 
programmer. Because as programmer count and program support 
lifetime grows any copy-paste is almost doomed to become a bug. 
And ugly code is just ugly. Being ugly is not a bug.

I am using C-macros of preventing copy-paste all the time, by the 
way, when coding plain C. This is our general team policy. And 
despite C macros are so bad, in the end of the day it is still 
worth it.

It is sometimes a rather complex task of using generic toolchain 
properly, though - I am sad that because of widespread prejudice 
overall average level of meta-programming culture is rather low 
and can result in what you have called 
MyClassOperatorMixinTemplate.
Jan 17 2013
prev sibling parent reply Marco Nembrini <marco.nembrini.co gmail.com> writes:
On 16.01.2013 20:07, Mehrdad wrote:


 When you have a ton of similar lines of code which need to be edited in
 parallel, lining them up lets you edit all of them in one keystroke.
 Saves me quite a lot of annoying editing in the long run, actually.


With Sublime Text you don't even have to align columns to do multiple 
simultaneous edits, just ctrl + click to create multiple cursors and 
then type/edit away. It has a lot of nice features :)

-- 

Marco Nembrini
Jan 16 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Wednesday, 16 January 2013 at 22:29:10 UTC, Marco Nembrini 
wrote:

 On 16.01.2013 20:07, Mehrdad wrote:


 When you have a ton of similar lines of code which need to be 
 edited in
 parallel, lining them up lets you edit all of them in one 
 keystroke.
 Saves me quite a lot of annoying editing in the long run, 
 actually.


 With Sublime Text you don't even have to align columns to do 
 multiple simultaneous edits, just ctrl + click to create 
 multiple cursors and then type/edit away. It has a lot of nice 
 features :)




Uh, you sort of missed the point...
The point was that you align similar-looking lines when /writing/ 
the code, so that it's in the right form when you need to modify 
it later, and all you need to do is Alt-Click-Drag to create 20 
cursors, and type away.

Or to put it another way: the whole point is to turn an O(n) 
operation into an O(1) operation. If you have to make O(n) 
cursor-additions then you've defeated the whole purpose.


That said, what you mentioned is not just a Sublime feature...
I use SciTE which does exactly the same thing. =P
Jan 16 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/17/2013 04:10 AM, Mehrdad wrote:

 On Wednesday, 16 January 2013 at 22:29:10 UTC, Marco Nembrini wrote:

 On 16.01.2013 20:07, Mehrdad wrote:


 When you have a ton of similar lines of code which need to be edited in
 parallel, lining them up lets you edit all of them in one keystroke.
 Saves me quite a lot of annoying editing in the long run, actually.


 With Sublime Text you don't even have to align columns to do multiple
 simultaneous edits, just ctrl + click to create multiple cursors and
 then type/edit away. It has a lot of nice features :)




 Uh, you sort of missed the point...
 The point was that you align similar-looking lines when /writing/ the
 code, so that it's in the right form when you need to modify it later,
 and all you need to do is Alt-Click-Drag to create 20 cursors, and type
 away.

 Or to put it another way: the whole point is to turn an O(n) operation
 into an O(1) operation. If you have to make O(n) cursor-additions then
 you've defeated the whole purpose.


That cannot be true. Drag alone is O(n). (eg. emacs does not require drag!)


 That said, what you mentioned is not just a Sublime feature...
 I use SciTE which does exactly the same thing. =P
Jan 16 2013
parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 17 January 2013 at 05:13:51 UTC, Timon Gehr wrote:

 That cannot be true. Drag alone is O(n). (eg. emacs does not 
 require drag!)




Er... depends on what you're talking about.

I'm talking about clicks/keypresses, not "drags". 1 drag == 1 
operation.
Jan 16 2013
prev sibling parent Marco Nembrini <marco.nembrini.co gmail.com> writes:
On 17.01.2013 14:10, Mehrdad wrote:


 Uh, you sort of missed the point...
 The point was that you align similar-looking lines when /writing/ the
 code, so that it's in the right form when you need to modify it later,
 and all you need to do is Alt-Click-Drag to create 20 cursors, and type
 away.

 Or to put it another way: the whole point is to turn an O(n) operation
 into an O(1) operation. If you have to make O(n) cursor-additions then
 you've defeated the whole purpose.


 That said, what you mentioned is not just a Sublime feature...
 I use SciTE which does exactly the same thing. =P


Hmm I see. I was thinking more of the situation where the lines are not 
aligned (maybe someone else's code), and you want to add something to 
all of them once. If you need to edit them multiple times then aligning 
is better.

Hmm that's good on Scite, most of the editors I had tried before Sublime 
didn't have this feature...
-- 

Marco Nembrini
Jan 17 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 16, 2013 at 12:57:43AM +0100, Rob T wrote:
[...]

 The sad part is that after all these decades, we're still _writing_
 code, and we're doing it in essentially the exact same way as was
 done 30 years ago using a text editor.
 
 For whatever reason, no other means of constructing software
 programs has really taken off, and I have to wonder why.


[...]

I think it's because people have vastly underestimated (1) the
complexity of programming -- it is non-trivial to reduce it to a simple,
tractable paradigm, and (2) the expressive power of language -- that is,
a linear medium of concept representation.

It's paradoxical that a 1D (i.e. linear) representation is more useful
for capturing the complexity of programming as opposed to, say, a 2D
graphical representation, say, or even a 3D representation. But perhaps
it's not so paradoxical if one considers that a linear representation is
sufficient to capture all of programming, and processing a 2D or 3D
representation adds no expressive power yet introduces more expensive
processing on the part of the compiler/language processor.

Or maybe it's just because humans are just linear-thinking creatures. :)


T

-- 
Verbing weirds language. -- Calvin (& Hobbes)
Jan 15 2013
next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Wednesday, 16 January 2013 at 01:31:20 UTC, H. S. Teoh wrote:

 Or maybe it's just because humans are just linear-thinking 
 creatures. :)


I was just a while ago thinking that a reason why text based 
programming has been so predominant may be that the ability to 
transmit and discuss programming problems are much easier to do 
when the program is represented in written form.

The minute you move to what could be a much more efficient and 
effective method of programing, you suddenly lose the ability to 
easily transmit the source code to other people. For example, it 
is very easy to post code samples in this forum for discussion, 
but if we represented programs in graphical form, we would have 
to upload images instead which not quite as easy to do.

Another issue at hand, is when collaborating over the wire with 
Git and other revision control systems, none of them operate 
effectively when using encoding methods that are not text based. 
Revision control systems just don't work well with binary files.

Having said this, there may still be better ways of representing 
programs that do not lose the advantages of text based 
programming, but what those methods look like is not so obvious.

--rt
Jan 15 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 16, 2013 at 03:54:17AM +0100, Rob T wrote:
[...]

 I was just a while ago thinking that a reason why text based
 programming has been so predominant may be that the ability to
 transmit and discuss programming problems are much easier to do when
 the program is represented in written form.
 
 The minute you move to what could be a much more efficient and
 effective method of programing, you suddenly lose the ability to
 easily transmit the source code to other people. For example, it is
 very easy to post code samples in this forum for discussion, but if
 we represented programs in graphical form, we would have to upload
 images instead which not quite as easy to do.


I invented a 4-dimensional esolang once, that represented program code
as tiles in an N*N*N*N tesseract. It was ultimately represented in text,
but you couldn't effectively program directly in a text editor because
it was a pain to keep things aligned properly, and non-trivial programs
wouldn't fit on your screen. For coding, I wrote a 4D tile editor.  :-P

Extreme example, granted. But you could include snippets of code in,
say, email, and the recipient could paste it into the 4D editor for
viewing, editing, etc..



 Another issue at hand, is when collaborating over the wire with Git
 and other revision control systems, none of them operate effectively
 when using encoding methods that are not text based. Revision control
 systems just don't work well with binary files.


That's not quite true, you know. Binary diffing has been around for a
long time now. But I suppose you could say that there is currently no
effective, generic way to display binary diffs in an understandable way.
But then, I believe git has diff plugins that one could write custom
diff displayers for, so this is merely a small impediment, not a
fundamental one.



 Having said this, there may still be better ways of representing
 programs that do not lose the advantages of text based programming,
 but what those methods look like is not so obvious.


[...]

Whatever structures said methods may use, can ultimately be reduced to
some kind of linear representation, which in turn can be reduced to some
text representation. I mean, no matter what you do, it will ultimately
have to be stored as a sequence of binary bytes. And programmers like
getting to the bottom of things, so directly manipulating a text
representation is the most obvious approach.

Now, granted, just because something can be represented as text doesn't
mean a text editor is the best tool for manipulating it (XML comes to
mind ;-)). One could imagine programming by visually manipulating
graphs, for example. Or take music composition as a kind of analogous
process: while you can certainly use a text editor to edit, say, a
Lilypond file and spell out notes and stuff directly, most people would
prefer a graphical interface where you can manipulate the musical
notation directly instead. Trying to write highly-polyphonic music
interspersed with chords in plain text format is possible, but extremely
painful and tedious, whereas writing it out in musical notation is
almost trivially straightforward. I've no idea what the programming
analogue of musical notation would be, though.  (Please don't say APL.
;-P)


T

-- 
Ignorance is bliss... but only until you suffer the consequences!
Jan 15 2013
parent "Rob T" <alanb ucora.com> writes:
On Wednesday, 16 January 2013 at 06:05:41 UTC, H. S. Teoh wrote:

 That's not quite true, you know. Binary diffing has been around 
 for a
 long time now. But I suppose you could say that there is 
 currently no
 effective, generic way to display binary diffs in an 
 understandable way.
 But then, I believe git has diff plugins that one could write 
 custom
 diff displayers for, so this is merely a small impediment, not a
 fundamental one.


Better than using binary files would be to store the state of the 
system using text (json, xml, whatever). For correct visual 
representation as intended by the programmer, the state of the 
visual representation is loaded up when the graphical editor is 
launched.

A nice thing about a graphical representation of code, is that 
the execution can be animated for much better feedback and 
debugging abilities.


 Whatever structures said methods may use, can ultimately be 
 reduced to
 some kind of linear representation, which in turn can be 
 reduced to some
 text representation. I mean, no matter what you do, it will 
 ultimately
 have to be stored as a sequence of binary bytes. And 
 programmers like
 getting to the bottom of things, so directly manipulating a text
 representation is the most obvious approach.


True.

This is interesting, and it maps to text based source code.

SAM - An Animated 3D Programming Language (PDF)
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1.7976&rep=rep1&type=pdf

[...]

 Lilypond file and spell out notes and stuff directly, most 
 people would
 prefer a graphical interface where you can manipulate the 
 musical
 notation directly instead. Trying to write highly-polyphonic 
 music
 interspersed with chords in plain text format is possible, but 
 extremely
 painful and tedious, whereas writing it out in musical notation 
 is
 almost trivially straightforward. I've no idea what the 
 programming
 analogue of musical notation would be, though.  (Please don't 
 say APL.


Not exactly music, and not a general purpose 3D programming 
language but this is somewhat interesting (and annoying!)
http://www.youtube.com/watch?v=Tq0hbfvNKWQ
Jan 15 2013
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-01-16 at 03:54 +0100, Rob T wrote:
[=E2=80=A6]

 I was just a while ago thinking that a reason why text based=20
 programming has been so predominant may be that the ability to=20
 transmit and discuss programming problems are much easier to do=20
 when the program is represented in written form.


But this does not predicate that the stored form is a text file, just
that it has to have a text rendering.


 The minute you move to what could be a much more efficient and=20
 effective method of programing, you suddenly lose the ability to=20
 easily transmit the source code to other people. For example, it=20
 is very easy to post code samples in this forum for discussion,=20
 but if we represented programs in graphical form, we would have=20
 to upload images instead which not quite as easy to do.


Why?

Smalltalk embodied all these problems and Smalltalk programmers have no
difficulty sharing.


 Another issue at hand, is when collaborating over the wire with=20
 Git and other revision control systems, none of them operate=20
 effectively when using encoding methods that are not text based.=20
 Revision control systems just don't work well with binary files.


This is a big problem even with binary diff techniques. This is likely
the molehill that will be turned into a mountain so as to preserve the
standard model of text files for source code.


 Having said this, there may still be better ways of representing=20
 programs that do not lose the advantages of text based=20
 programming, but what those methods look like is not so obvious.


See Smalltalk.

The problem to solve is how to not rely on images the way Smalltalk
does. This was a soluble problem 20 years ago but no-one with money was
interested. Hopefully in the coming finding round the modern versions of
those ideas will get funded.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 16 2013
prev sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 01/15/2013 08:29 PM, H. S. Teoh wrote:

 It's paradoxical that a 1D (i.e. linear) representation is more useful
 for capturing the complexity of programming as opposed to, say, a 2D
 graphical representation


Typical code is 2d because of line-oriented statements and indented 
block structure. Reading a truly linear file of code in 1d would be 
quite a nightmare.
Jan 17 2013
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 17/01/2013 12:30, Jeff Nowakowski wrote:

 On 01/15/2013 08:29 PM, H. S. Teoh wrote:

 It's paradoxical that a 1D (i.e. linear) representation is more useful
 for capturing the complexity of programming as opposed to, say, a 2D
 graphical representation


 Typical code is 2d because of line-oriented statements and indented
 block structure. Reading a truly linear file of code in 1d would be
 quite a nightmare.


It depends on how you look at it.

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.

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.  And again, 
you could think of it as a curve, passing from the beginning of each 
line to the end and then to the beginning of the next line.

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.

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

Stewart.
Jan 17 2013
next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 17 January 2013 at 20:17:06 UTC, Stewart Gordon 
wrote:

 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.  And again, you could think of it as a 
 curve, passing from the beginning of each line to the end and 
 then to the beginning of the next line.


  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.

// c example, originally isprime and main don't have
// return types, defaulting to int instead.
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.
Jan 17 2013
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jan 18 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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.
Jan 18 2013
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jan 19 2013
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
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).
Jan 19 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Thursday, 17 January 2013 at 20:17:06 UTC, Stewart Gordon 
wrote:

 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.

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

 Stewart.


So far we have not considered what happens when we get into 
parallel programming. It seems that the old ways of viewing code 
breaks down. We have to represent in text form not just one thing 
happening at one time, but many things happening at the same 
time, so the dimensions increase and the interactions between 
simultaneous cooperating components often becomes unpredictable 
in ways that cannot be represented very well in text form. You 
can still represent the code in text form, but I wonder how 
effective that is compared with a graphical approach to the 
problem, i.e., simulating the programming model graphically in 2 
or 3D space.

--rt
Jan 17 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 17, 2013 at 11:43:33PM +0100, Rob T wrote:

 On Thursday, 17 January 2013 at 20:17:06 UTC, Stewart Gordon wrote:

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.

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

Stewart.


 
 So far we have not considered what happens when we get into parallel
 programming. It seems that the old ways of viewing code breaks down.
 We have to represent in text form not just one thing happening at
 one time, but many things happening at the same time, so the
 dimensions increase and the interactions between simultaneous
 cooperating components often becomes unpredictable in ways that
 cannot be represented very well in text form. You can still
 represent the code in text form, but I wonder how effective that is
 compared with a graphical approach to the problem, i.e., simulating
 the programming model graphically in 2 or 3D space.


[...]

It's easy to represent in 2D or 3D a *simulation* of program execution
(i.e., a particular instance of execution), but how do you represent
concurrent program *logic*?

For example, consider this: you have a program in which up to 5 threads
may be running at the same time, and they access a number of shared
variables.  In order to fully capture the semantics of the program
(w.r.t. to concurrency), you'd have to somehow depict *all possible
interleavings* of the 5 threads, including parallel executions. How
would such a thing be depicted in 2D or 3D?

Furthermore, if you're going to be mapping degrees of freedom in state
space (which is essentially what you're doing if you want to capture the
interactions between simultaneous cooperating components) into Euclidean
space, then 3D is, in general, going to be far too few dimensions to
fully represent the program. Non-trivial concurrent programs have far
too many degrees of freedom to capture in a mere handful of dimensions.
You'll need to be able to display (*and* visualize) spaces of arbitrary
dimensionality (anywhere from 4D to, say, 237D, or 10423D for large
projects) to be able to work with such a programming model.


T

-- 
"A man's wife has more power over him than the state has." -- Ralph Emerson
Jan 17 2013
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 17 January 2013 at 23:35:37 UTC, H. S. Teoh wrote:


 It's easy to represent in 2D or 3D a *simulation* of program 
 execution (I.e., a particular instance of execution), but how 
 do you represent concurrent program *logic*?

 For example, consider this: you have a program in which up to 5 
 threads may be running at the same time, and they access a 
 number of shared variables.  In order to fully capture the 
 semantics of the program (w.r.t. to concurrency), you'd have to 
 somehow depict *all possible interleavings* of the 5 threads, 
 including parallel executions. How would such a thing be 
 depicted in 2D or 3D?

 Furthermore, if you're going to be mapping degrees of freedom 
 in state space (which is essentially what you're doing if you 
 want to capture the interactions between simultaneous 
 cooperating components) into Euclidean space, then 3D is, in 
 general, going to be far too few dimensions to fully represent 
 the program. Non-trivial concurrent programs have far too many 
 degrees of freedom to capture in a mere handful of dimensions. 
 You'll need to be able to display (*and* visualize) spaces of 
 arbitrary dimensionality (anywhere from 4D to, say, 237D, or 
 10423D for large projects) to be able to work with such a 
 programming model.


  I can only think that each thread would be a window (or 3d box), 
and have no immediate connections. Then you enable specific 
references of what you're interested in (sorta like the sorting 
vs container model where they are separated, make x sorters + y 
containers, not x*y combinations).

  If they get re-ordered based on what's selected/available then 
it would have to find the best fit to represent the connections 
between data, depending on how many blocks there are (VS table 
layout? Or similar to circuit boards) which then gives you a semi 
2d/3d view.

  If instead it say connects using wires showing certain 
connectivity (with id tags or something) then you just specify 
what variables, structures, or specific threads that are directly 
related (use one as a parent which then spreads out) and it hides 
the unneeded information until requested.

  But that's just how I see it with a debugger. Although I can 
dream it, I don't know if I could write it. Might get some game 
programmers to make the GUI interface.

  Hmmm programming and using a controller to navigate the views 
from the compiler/debugger...
Jan 17 2013
prev sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
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.
Jan 18 2013
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jan 19 2013
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
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.
Jan 21 2013
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jan 21 2013
parent Jeff Nowakowski <jeff dilacero.org> writes:
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.
Jan 21 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-01-16 at 00:57 +0100, Rob T wrote:
[=E2=80=A6]

 The sad part is that after all these decades, we're still=20
 _writing_ code, and we're doing it in essentially the exact same=20
 way as was done 30 years ago using a text editor.


In the early to mid 1980s there was a move to not using text files but
using AST with meta-data as the stored form of code. Not just the syntax
oriented editing people but people doing for C, Fortran, etc. what
Smalltalk did for Smalltalk, treat the text form of the code as a
rendering of the stored form.

Sadly two things stopped this from becoming the norm: a. hardware wasn't
up to the job required (whereas now it is the other way round); b.
programmers refused to give up files containing text as the stored form.

Now look at people not still using Emacs and VIM: IDEs everywhere. What
do IDEs spend most of their time doing? Reconstructing ASTs on the fly
in order to provide all the help and code completion programmers now
claim is their inalienable right.


 For whatever reason, no other means of constructing software=20
 programs has really taken off, and I have to wonder why.


It would have done if programmers had been less conservative and more
willing to be open to change. But no, text files had to be the right
medium of storage. Bah.

In the next round of funding in Europe, there are various project
proposals to revisit the whole 1980s way of thinking about code
development and code development environments. Replace text file as the
stored form with a representation of the AST with meta-data. Allow IDEs
like Eclipse, IntelliJ IDEA, NetBeans not to have to infer ASTs in
parallel to compiling code. Reclaim some memory and machine cycles by
getting IDEs right.

(Emacs|VIM|GEdit|Sublime Text|.*) your days really ought to be numbered.
We the programmers demand development tools that are modern and up to
date. Eclipse, IntelliJ IDEA, NetBeans are legacy as well.

There is an analogy: actor model, CSP, dataflow were all invented in the
1960s and 1970s but studiously ignored by programmers in favour of
"close to the metal" shared-memory multi-threading because parallelism
was about performance and you have to wring every cycle.  Bah. Mere
infrastructure. Now any programmer who isn't using dataflow, CSP or
actors for concurrency and parallelism is legacy. Look at D ;-)

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 16 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Of course now programmers rely on Git and Mercurial, there is likely no
chance of people giving up on hierarchies of text files as the way of
storing code.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 16 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 15 January 2013 at 23:57:44 UTC, Rob T wrote:

 On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:

 Quite a nice read on the coding style used in Doom.

 http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


 The sad part is that after all these decades, we're still 
 _writing_ code, and we're doing it in essentially the exact 
 same way as was done 30 years ago using a text editor.

 For whatever reason, no other means of constructing software 
 programs has really taken off, and I have to wonder why.

 --rt


We are using writing to communicate between people for thousands 
of year now. This is clearly the most efficient way to express 
idea, including to a computer.
Jan 16 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 17, 2013 at 06:28:30AM +0100, deadalnix wrote:

 On Tuesday, 15 January 2013 at 23:57:44 UTC, Rob T wrote:

On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:

Quite a nice read on the coding style used in Doom.

http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550


The sad part is that after all these decades, we're still
_writing_ code, and we're doing it in essentially the exact same
way as was done 30 years ago using a text editor.

For whatever reason, no other means of constructing software
programs has really taken off, and I have to wonder why.

--rt


 
 We are using writing to communicate between people for thousands of
 year now. This is clearly the most efficient way to express idea,
 including to a computer.


Not to mention, linear writing developed *from* 2D drawings.


T

-- 
There are 10 kinds of people in the world: those who can count in
binary, and those who can't.
Jan 16 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Thursday, 17 January 2013 at 06:52:39 UTC, H. S. Teoh wrote:

 On Thu, Jan 17, 2013 at 06:28:30AM +0100, deadalnix wrote:

 We are using writing to communicate between people for 
 thousands of year now. This is clearly the most efficient way 
 to express idea, including to a computer.


 Not to mention, linear writing developed *from* 2D drawings.


  Somehow what seems like would work good is a card-file system. 
Assuming the order of functions/declarations don't matter and you 
let the editor deal with where it places things (say, 
alphabetically or by attributes like private, pure, etc), then 
having a partial 3d view where you can flip through various 
function definitions & header documentation, then open only the 
function(s) of interest in question, hiding anything unrelated. 
If there's anything global or variables it accesses those could 
be listed too along with their type, and perhaps where the type's 
definition comes from for reference; and any functions it calls 
along with others with the same overloading name.

  Hmmm really wish I could do more Art/3d stuff...
Jan 16 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 17, 2013 at 08:26:16AM +0100, Era Scarecrow wrote:

 On Thursday, 17 January 2013 at 06:52:39 UTC, H. S. Teoh wrote:

On Thu, Jan 17, 2013 at 06:28:30AM +0100, deadalnix wrote:

We are using writing to communicate between people for thousands
of year now. This is clearly the most efficient way to express
idea, including to a computer.


Not to mention, linear writing developed *from* 2D drawings.


 
  Somehow what seems like would work good is a card-file system.
 Assuming the order of functions/declarations don't matter and you
 let the editor deal with where it places things (say, alphabetically
 or by attributes like private, pure, etc), then having a partial 3d
 view where you can flip through various function definitions &
 header documentation, then open only the function(s) of interest in
 question, hiding anything unrelated. If there's anything global or
 variables it accesses those could be listed too along with their
 type, and perhaps where the type's definition comes from for
 reference; and any functions it calls along with others with the
 same overloading name.


[...]

That sounds like a very good idea. In fact, Vim has a feature called
folding, where parts of the file are folded into a single line, to be
expanded/collapsed at will. Properly configured, this can be made to
auto-collapse all functions, nested blocks, etc., to be expanded at
will. This makes long source code much more navigable (though it doesn't
change sorting order -- I can see where that may be useful).


T

-- 
In theory, software is implemented according to the design that has been
carefully worked out beforehand. In practice, design documents are
written after the fact to describe the sorry mess that has gone on
before.
Jan 17 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
 On Thu, Jan 17, 2013 at 08:26:16AM +0100, Era Scarecrow wrote:

 Somehow what seems like would work good is a card-file system. 
 Assuming the order of functions/declarations don't matter and 
 you let the editor deal with where it places things (say, 
 alphabetically or by attributes like private, pure, etc), then 
 having a partial 3d view where you can flip through various 
 function definitions & header documentation, then open only 
 the function(s) of interest in question, hiding anything 
 unrelated. If there's anything global or variables it accesses 
 those could be listed too along with their type, and perhaps 
 where the type's definition comes from for reference; and any 
 functions it calls along with others with the same overloading 
 name.


 [...]

 That sounds like a very good idea. In fact, Vim has a feature 
 called folding, where parts of the file are folded into a 
 single line, to be expanded/collapsed at will. Properly 
 configured, this can be made to auto-collapse all functions, 
 nested blocks, etc., to be expanded at will. This makes long 
 source code much more navigable (though it doesn't change 
 sorting order -- I can see where that may be useful).


  NotePad++ does this too. However you are still managing the 
order of the functions, obviously in structs the order of 
variables matter (but not anywhere else), so if the editor 
handled where it was placed you'd always have a consistant 
layout. This likely would help quite a bit with managing source 
code.

  Course alphabetical could be a default after any other 
specialized functions are done. Examples are I'd want 
front/popFront next to eachother in the list, back/popBack, 
length, opIndex, opIndexAssign, all the slices together along 
with opDollar. Etc. Probably also have them in in multiple 
fold-outs where it's sorted by some criteria (unittests, public 
API, templates, pure/ safe).

  Could also have different operators and function predefined (but 
in grey for example), then enabling it gives you a default basic 
skeleton in which to add your operator specific code.

  All of this is what you could do without actually needing the 
compiler (but probably needs proper syntax checking).
Jan 17 2013
parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 17 January 2013 at 16:25:11 UTC, Era Scarecrow wrote:

 On Thu, Jan 17, 2013 at 08:26:16AM +0100, Era Scarecrow wrote:

 Somehow what seems like would work good is a card-file 
 system. Assuming the order of functions/declarations don't 
 matter and you let the editor deal with where it places 
 things (say, alphabetically or by attributes like private, 
 pure, etc), then having a partial 3d view where you can flip 
 through various function definitions & header documentation, 
 then open only the function(s) of interest in question, 
 hiding anything unrelated. If there's anything global or 
 variables it accesses those could be listed too along with 
 their type, and perhaps where the type's definition comes 
 from for reference; and any functions it calls along with 
 others with the same overloading name.


 [...]

 That sounds like a very good idea. In fact, Vim has a feature 
 called folding, where parts of the file are folded into a 
 single line, to be expanded/collapsed at will. Properly 
 configured, this can be made to auto-collapse all functions, 
 nested blocks, etc., to be expanded at will. This makes long 
 source code much more navigable (though it doesn't change 
 sorting order -- I can see where that may be useful).


  NotePad++ does this too. However you are still managing the 
 order of the functions, obviously in structs the order of 
 variables matter (but not anywhere else), so if the editor 
 handled where it was placed you'd always have a consistant 
 layout. This likely would help quite a bit with managing source 
 code.

  Course alphabetical could be a default after any other 
 specialized functions are done. Examples are I'd want 
 front/popFront next to eachother in the list, back/popBack, 
 length, opIndex, opIndexAssign, all the slices together along 
 with opDollar. Etc. Probably also have them in in multiple 
 fold-outs where it's sorted by some criteria (unittests, public 
 API, templates, pure/ safe).

  Could also have different operators and function predefined 
 (but in grey for example), then enabling it gives you a default 
 basic skeleton in which to add your operator specific code.

  All of this is what you could do without actually needing the 
 compiler (but probably needs proper syntax checking).



Ditto with SciTE (which uses the same editing component, 
Scintilla, as Notepad++)
Jan 17 2013