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