www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - On 80 columns should (not) be enough for everyone

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
The unittest topic is about to get derailed so I want to continue this silly
discussion here.

Wheres Nick? I want to see the CRT vs LCD discussion heated up again with
Andrei claiming that LCDs are so Godlike but yet claims 80 columns is enough
for everyone.

80 colums is an artifact of the old age. Just like the preprocessor is an
artifact of the C language. And many other old things are artifacts. There's no
reason to keep these artifacts around anymore.

A couple of things, Andrei:
1. 80 colums is way too restrictive. 80 columns wasn't determined by some
scientific method to be a good size for code, it's a product of limitations of
the older generation hardware. Who will run a brand new language like D in a
freakin' Terminal? 

Have you ever heard of the expression "limitations boost creativity"? That can
be considered a good thing, if creativity is what you're after. In code, it's
not. You're looking for clarity in code. 80 column limitations are good for C
obfuscation contests and nothing else. 80 columns means people are going to
*work around* the limit, by using hacks and workarounds to make everything fit
in place. Do you really believe that programmers are going to spend any time at
all thinking: *"oh this line doesn't fit on 80 columns. I should now spend some
time thinking about how to improve and rewrite the design of my code. 80
columns really is the golden ration"*?

If you want to see more files on the screen, get multiple screens. Is Facebook
running out of money, can't they afford a few monitors for the C++ guru? Yes, I
know you're not allowed to comment on that one. :)

2. A widescreen aspect ratio causes less eye strain. Wider code means the same.
It doesn't have to stretch all the way to be effective, but 80 columns is too
limiting. Do a Google search and read what people have go say about that.

3. Less columns means more rows. And generally coders *hate* it when they can't
see a function that fits on a single screen. They hate having to scroll up and
down. This common syntax form is a proof of that:
void main() {
    void foo() {
         while (true) {
             if (done) {
             }
         }
     }
}

I find that unpleasant to read. Not impossible, but unpleasant. I can live with
it though, but if you limit code to 80 limits that's going to become a mess to
read.

3. It's 2010. Does your GNU/emacs still not support wrapping lines by word
boundaries? Scite had this since the '90s, and that's not even an advanced
editor. Vim supports word wrapping as well. Heck, I'm pretty sure you can
customize it to wrap on whatever boundary you want to (although I'm only
speculating, but pretty much everything in Vim is customizable). You can even
customize how your cursor reacts if it's on an 'artificial' new line, one that
has been wrapped.

Isn't technology amazing?

4. Just how many files do you want to edit at a single time on the screen?
We're not really multitasking beings, you know. Try using one of your hands and
do forward circles, as if it were a wheel. With the other one do backward
circles. And now use your foot to draw a circle on the floor. You're end up
looking like a clown in seconds, and a bad one at that. 

Again, people who want to have documentation, and code, and IRC chats in
display buy more computer screens. Why should your code have to suffer if you
really want to do multiple things all at once? 

Bottom line:

If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on. I don't see why everyone
has to cater to your rules only, regardless of what your professional
experience might be. You're a big contributor to Phobos, but you're not the
only one. I tend to believe that D is (or should be) a community effort, so
please don't hijack D away from the community by forcing your own rules down to
everyone else.
Jan 30 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Also, it's 2011 apparently. I'm still stuck in 2010 it seems. :p
Jan 30 2011
prev sibling next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Andrej Mitrovic wrote:

 The unittest topic is about to get derailed so I want to continue this
 silly discussion here.

 80 colums is an artifact of the old age. Just like the preprocessor is an
 artifact of the C language. And many other old things are artifacts.
 There's no reason to keep these artifacts around anymore.

Yes, but there has to be some limit, horizontal scrolling is much worse. Someone at my workplace likes to make 400+ columns lines of code for example, he likes it but it confuses the shit out of me.
 A couple of things, Andrei:
 1. 80 colums is way too restrictive. 80 columns wasn't determined by some
 scientific method to be a good size for code, it's a product of
 limitations of the older generation hardware. Who will run a brand new
 language like D in a freakin' Terminal?

Terminals can host more than 80 columns these days.
 If you want to see more files on the screen, get multiple screens. Is
 Facebook running out of money, can't they afford a few monitors for the
 C++ guru? Yes, I know you're not allowed to comment on that one. :)

iirc Andrei commented facebook installed him a 30inch screen.
Jan 30 2011
prev sibling next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 30/01/11 5:17 PM, Andrej Mitrovic wrote:
 The unittest topic is about to get derailed so I want to continue this silly
discussion here.

 Wheres Nick? I want to see the CRT vs LCD discussion heated up again with
Andrei claiming that LCDs are so Godlike but yet claims 80 columns is enough
for everyone.

 80 colums is an artifact of the old age. Just like the preprocessor is an
artifact of the C language. And many other old things are artifacts. There's no
reason to keep these artifacts around anymore.

<snip>

Is this really worth arguing about? Just stick to 80 columns. It's not a big deal.
Jan 30 2011
next sibling parent Matthias Walter <xammy xammy.homelinux.net> writes:
On 01/30/2011 01:01 PM, Peter Alexander wrote:
 On 30/01/11 5:17 PM, Andrej Mitrovic wrote:
 The unittest topic is about to get derailed so I want to continue
 this silly discussion here.

 Wheres Nick? I want to see the CRT vs LCD discussion heated up again
 with Andrei claiming that LCDs are so Godlike but yet claims 80
 columns is enough for everyone.

 80 colums is an artifact of the old age. Just like the preprocessor
 is an artifact of the C language. And many other old things are
 artifacts. There's no reason to keep these artifacts around anymore.

 <snip>

Is this really worth arguing about? Just stick to 80 columns. It's not a big deal.

allowed columns. Why? Well, phobos' names like tr will be (or are) refactored to translate and with camelcase we encourage people to use descriptive names. And with template parameters and everything I do not want to call functions, putting 1 argument on every line. I'd suggest raising it to 120 or 150...
Jan 30 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Peter Alexander:

 Is this really worth arguing about?

You are right, let's stick to 90-95 columns and let's close this discussion. Bye, bearophile
Jan 30 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/30/2011 12:25 PM, bearophile wrote:
 Peter Alexander:

 Is this really worth arguing about?

You are right, let's stick to 90-95 columns and let's close this discussion.

I, too, would love to vote how others should format their code. FWIW here's a data point: $ wc -l std/**/*.d 138793 total $ grep '.\{81,\}' std/**/*.d | cut -f1 -d:| uniq -c | sort -nr 6742 std/datetime.d 145 std/bind.d 116 std/base64.d 106 std/windows/registry.d 92 std/file.d 81 std/socket.d 67 std/internal/math/biguintcore.d 66 std/math.d 64 std/conv.d 60 std/regexp.d 54 std/internal/math/gammafunction.d 51 std/numeric.d 35 std/stream.d 34 std/internal/math/biguintx86.d 32 std/regex.d 30 std/traits.d 22 std/container.d 21 std/zip.d 21 std/random.d 21 std/format.d 21 std/algorithm.d 19 std/signals.d 18 std/utf.d 18 std/string.d 18 std/internal/math/errorfunction.d 16 std/loader.d 14 std/typelist.d 14 std/internal/math/biguintnoasm.d 13 std/typecons.d 12 std/range.d 12 std/concurrency.d 11 std/json.d 11 std/date.d 10 std/functional.d 10 std/c/windows/winsock.d 10 std/bigint.d 9 std/encoding.d 7 std/path.d 6 std/zlib.d 6 std/xml.d 6 std/outbuffer.d 5 std/stdio.d 5 std/mathspecial.d 5 std/array.d 4 std/variant.d 4 std/typetuple.d 4 std/mmfile.d 4 std/md5.d 4 std/cpuid.d 3 std/socketstream.d 3 std/process.d 3 std/getopt.d 3 std/dateparse.d 3 std/ctype.d 2 std/windows/charset.d 2 std/uri.d 2 std/uni.d 2 std/stdarg.d 2 std/c/stdlib.d 2 std/c/osx/socket.d 2 std/compiler.d 2 std/c/linux/socket.d 1 std/windows/syserror.d 1 std/windows/iunknown.d 1 std/system.d 1 std/stdiobase.d 1 std/stdint.d 1 std/__fileinit.d 1 std/exception.d 1 std/demangle.d 1 std/datebase.d 1 std/c/windows/com.d 1 std/cstream.d 1 std/complex.d 1 std/bitmanip.d 1 Binary file std/perf.d matches Andrei
Jan 30 2011
prev sibling parent Bernard Helyer <b.helyer gmail.com> writes:
Here's SDC, just for kicks:

[SDC]$ find src/sdc -name "*.d" -print0 | xargs --null wc -l | sort -rn | 
head -n 1
 12545 total
[SDC]$ find src/sdc -name "*.d" -print0 | xargs --null grep '.\{81,\}' | 
cut -f1 -d:| uniq -c | sort -nr
     81 src/sdc/gen/value.d
     44 src/sdc/gen/expression.d
     35 src/sdc/lexer.d
     26 src/sdc/gen/base.d
     24 src/sdc/parser/declaration.d
     24 src/sdc/gen/declaration.d
     19 src/sdc/gen/sdctemplate.d
     16 src/sdc/gen/statement.d
     13 src/sdc/global.d
     12 src/sdc/gen/sdcfunction.d
     11 src/sdc/sdc.d
      9 src/sdc/gen/sdcpragma.d
      8 src/sdc/parser/expression.d
      8 src/sdc/parser/base.d
      8 src/sdc/gen/sdcmodule.d
      7 src/sdc/parser/conditional.d
      7 src/sdc/gen/attribute.d
      6 src/sdc/parser/sdcimport.d
      6 src/sdc/parser/attribute.d
      6 src/sdc/extract/base.d
      4 src/sdc/parser/sdctemplate.d
      4 src/sdc/parser/enumeration.d
      4 src/sdc/gen/sdcimport.d
      4 src/sdc/gen/enumeration.d
      3 src/sdc/sdc4de.d
      2 src/sdc/token.d
      2 src/sdc/gen/type.d
      2 src/sdc/gen/cfg.d
      2 src/sdc/gen/aggregate.d
      1 src/sdc/tokenstream.d
      1 src/sdc/terminal.d
      1 src/sdc/source.d
      1 src/sdc/parser/statement.d
      1 src/sdc/parser/sdcpragma.d
      1 src/sdc/parser/sdcclass.d
      1 src/sdc/parser/aggregate.d
      1 src/sdc/ast/statement.d
      1 src/sdc/ast/expression.d
Feb 01 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrej Mitrovic wrote:
 80 columns
 wasn't determined by some scientific method to be a good size for code, it's
 a product of limitations of the older generation hardware.

80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.
Jan 30 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/30/2011 12:27 PM, Walter Bright wrote:
 Andrej Mitrovic wrote:
 80 columns
 wasn't determined by some scientific method to be a good size for
 code, it's
 a product of limitations of the older generation hardware.

80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.

Also: pick a random book or newspaper and count the characters in a line. They range between 60 and 80, counting for about 10 words per line. This has been the case ever writing systems have been invented. It is a fallacy to assume that 80 has anything to do with the first monitors. In fact, it's the opposite - the monitors were conceived following a universal human constant. One funny thing is that at my employer (where each and every employee has a 30" 2560x1600 monitor) everything is under constant debate, starting with which email server and ending with choosing UserId versus UserID. Nobody and not once has debated the 80 column rule. Phobosians have voted with their fingers. Long lines in Phobos are rare and the result of lack of enforcement, not a stylistic choice. Jonathan simply didn't know about that, and has graciously agreed to align to that convention (thanks!). Andrei
Jan 30 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/31/11 11:54 AM, Ulrik Mikaelsson wrote:
 FWIW: Here's my two cents; (Non-Phobos participant, so feel free to
 click delete now)

 I'm not sure whether text-books and program-code are really comparable
 in this respect. When reading books I hardly put much attention to
 each particular word, while in computer-code, each token is very
 significant. The "flow" of reading is simply different. If it weren't,
 we would hardly use hard line-breaks at all, just concatenate
 statements like we concatenate sentences in text, and use<your word
 processor>  to format code. Especially, we would not use monospaced
 fonts and care about "columns".

Well the fact of the matter is that style used in books is very influential. People do copy book samples into code and continue working in the same style from them. I've been asked for (and released) the source code of all snippets in TDPL.
 I would rather like to hear whether any mathematicians ever insert
 hard-breaks into their equations just "to not get them too wide".

I'm not sure I can qualify as a mathematician but my research is very math-heavy. In my thesis (http://erdani.com/research/dissertation_color.pdf) I frequently inserted line breaks even when not technically necessary, check e.g. eq. 2.16 on page 12.
 Personally, I've been a long time on the fence regarding strict
 line-length, and my current position is:
   90 columns is the rule of thumb. 80 columns is often hard to fit
 using readable names, but 90 columns generally works.

Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm now more inclined to increase and/or soften the recommended limit for Phobos. Andrei
Jan 31 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm 
 now more inclined to increase and/or soften the recommended limit for 
 Phobos.

I think 110 columns are a little too many. I have suggested 90-95 chars max (but less than 80 on average) after seeing both the problems caused by too much short lines (to keep lines below 70-80 chars I have seen programmers use 2 spaces to indent or use very short variable names. This is worse than 95 chars long lines), and seeing lines with 120+ chars that cause troubles to older programmer that can't use a too much small font because of their older eyes. Bye, bearophile
Jan 31 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Russel Winder:

 What say we cut the agist crap.

There are also armies of programmers with myopia :-) Bye, bearophile
Jan 31 2011
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 31/01/2011 17:54, Ulrik Mikaelsson wrote:
<snip>
 One special-case which often cause problems, is function-calls,
 especially "method"-calls. Roughly lines like: (note 3-level leading
 indent)
              otherObj1.doSomethingSensible(otherObj2.internalVariable,
 this.config, this.context);

 At this point, I can see two obvious alternatives;
              otherObj1.doSomethingSensible(otherObj2.internalVariable,
 this.config,
                                            this.context);
 vs.
              otherObj1.doSomethingSensible(otherObj2.internalVariable,
                                            this.config,
                                            this.context);

If only your newsreader were also set to wrap at 90, it would be clearer. Why align the continuation lines with the open bracket? I think the shortness of lines resulting therefrom is the root cause of what you say next:
 Both have advantages and problems. In the first alternative, you might
 miss the second argument if reading too fast, and in the second
 alternative, the vertical space can be quickly wasted, especially if
 the line get's just slightly too long due to many small arguments.

If OTOH you stick to a standard number of spaces by which to indent, which generally allows multiple arguments to fit on one line otherObj1.doSomethingSensible(otherObj2.internalVariable, this.config, this.context); you don't lead people into the trap of seeing one argument per line. That said, I've probably in my time done something similar to your example. And at other times, I might do otherObj1.doSomethingSensible( otherObj2.internalVariable, this.config, this.context ); Stewart.
Feb 01 2011
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright Wrote:

 Andrej Mitrovic wrote:
 80 columns
 wasn't determined by some scientific method to be a good size for code, it's
 a product of limitations of the older generation hardware.

80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.

Print text doesn't have indentation levels though. Assuming a 4 character indent, the smallest indentation level for code in a D member function is 8 characters. Add a nested conditional and code is starting 16 characters in, which when wrapped at 80 characters begins to look like a newspaper column. I wrap all my comments at 79 characters, but allow code to spill as far as 110 (which is the number of columns on an 8.5x11" piece of paper in landscape mode).
Jan 30 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/30/2011 01:20 PM, Sean Kelly wrote:
 Walter Bright Wrote:

 Andrej Mitrovic wrote:
 80 columns
 wasn't determined by some scientific method to be a good size for code, it's
 a product of limitations of the older generation hardware.

80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.

Print text doesn't have indentation levels though.

It does - bulleted and numbered lists, certain sidebars, block quotes.
 Assuming a 4 character indent, the smallest indentation level for
 code in a D member function is 8 characters.  Add a nested
 conditional and code is starting 16 characters in, which when wrapped
 at 80 characters begins to look like a newspaper column.

Newspaper columns are strongly optimized for being read quickly. Not a bad standard I guess. I don't contend that your choice works for you, but I refute this particular rationalisation of it. Indentation should NOT be discounted as a participant to the maximum line width. If anything it adds overhead, not reduces it. Andrei
Jan 30 2011
parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:

 On 01/30/2011 01:20 PM, Sean Kelly wrote:
 Walter Bright Wrote:

 Andrej Mitrovic wrote:
 80 columns
 wasn't determined by some scientific method to be a good size for code, it's
 a product of limitations of the older generation hardware.

80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.

Print text doesn't have indentation levels though.

It does - bulleted and numbered lists, certain sidebars, block quotes.

True. Though multiply nested such blocks are rare.
 Assuming a 4 character indent, the smallest indentation level for
 code in a D member function is 8 characters.  Add a nested
 conditional and code is starting 16 characters in, which when wrapped
 at 80 characters begins to look like a newspaper column.

Newspaper columns are strongly optimized for being read quickly. Not a bad standard I guess. I don't contend that your choice works for you, but I refute this particular rationalisation of it. Indentation should NOT be discounted as a participant to the maximum line width. If anything it adds overhead, not reduces it.

I just said that indentation reduces available space for code. How is that discounting it? That aside, I don't know that the comparison to newspaper columns really holds. Sentences wrap naturally, while I'm not sure the same holds for a code statement--consider languages that require one statement per line. At the very least, wrapping a statement often requires additional consideration to line up related sections to ease readability. That isn't to say that I think a programmer should pack as much as possible into a line of code. Quite the contrary, in fact. I'm simply relating my experience with having a hard 80 column break, which is something I used to do religiously.
Jan 30 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
FWIW: Here's my two cents; (Non-Phobos participant, so feel free to
click delete now)

I'm not sure whether text-books and program-code are really comparable
in this respect. When reading books I hardly put much attention to
each particular word, while in computer-code, each token is very
significant. The "flow" of reading is simply different. If it weren't,
we would hardly use hard line-breaks at all, just concatenate
statements like we concatenate sentences in text, and use <your word
processor> to format code. Especially, we would not use monospaced
fonts and care about "columns".

I would rather like to hear whether any mathematicians ever insert
hard-breaks into their equations just "to not get them too wide".

Personally, I've been a long time on the fence regarding strict
line-length, and my current position is:
 90 columns is the rule of thumb. 80 columns is often hard to fit
using readable names, but 90 columns generally works. When the code
exceeds 90 columns, I try to look for:
 * local variable names that can be shortened without breaking their
descriptiveness.
 * sub-expressions in the line, which can be reasonably be extracted
into separe pre-computed variable. (Which also increases readability
of the code by itself.)
 * unnecessary nested depth in the function, and try to either
refactor parts out to separate functions, or refactor the function to
be more pass-based rather then nested.

One special-case which often cause problems, is function-calls,
especially "method"-calls. Roughly lines like: (note 3-level leading
indent)
            otherObj1.doSomethingSensible(otherObj2.internalVariable,
this.config, this.context);

At this point, I can see two obvious alternatives;
            otherObj1.doSomethingSensible(otherObj2.internalVariable,
this.config,
                                          this.context);
vs.
            otherObj1.doSomethingSensible(otherObj2.internalVariable,
                                          this.config,
                                          this.context);

Both have advantages and problems. In the first alternative, you might
miss the second argument if reading too fast, and in the second
alternative, the vertical space can be quickly wasted, especially if
the line get's just slightly too long due to many small arguments.
(I.E. debug-output of many short-named local variables.) In these
cases, I usually just leave it to overflow. That will
 * hint to the reader that it's still just one single function-call
 * arguments won't be missed
 * not waste unnecessary vertical space
 * it's up to the code-viewer to determine whether a line-wrap is
actually needed, which it might even indicate using a wrap-marker in
the margin (not possible with a manual line-break).

For other common long-line sources like enums, array literals etc, I
usually block-format and insert line-breaks as usual to not exceed 90
columns wide.

My guess is, if I worked enough with long mathematical expression, I
would use roughly the same guidelines.

/ Ulrik

(*doh* that was probably more than 2 cents worth.)

2011/1/30 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 On 01/30/2011 12:27 PM, Walter Bright wrote:
 Andrej Mitrovic wrote:
 80 columns
 wasn't determined by some scientific method to be a good size for
 code, it's
 a product of limitations of the older generation hardware.

80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.

Also: pick a random book or newspaper and count the characters in a line. They range between 60 and 80, counting for about 10 words per line. This has been the case ever writing systems have been invented. It is a fallacy to assume that 80 has anything to do with the first monitors. In fact, it's the opposite - the monitors were conceived following a universal human constant. One funny thing is that at my employer (where each and every employee has a 30" 2560x1600 monitor) everything is under constant debate, starting with which email server and ending with choosing UserId versus UserID. Nobody and not once has debated the 80 column rule. Phobosians have voted with their fingers. Long lines in Phobos are rare and the result of lack of enforcement, not a stylistic choice. Jonathan simply didn't know about that, and has graciously agreed to align to that convention (thanks!). Andrei

Jan 31 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/1/31 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 On 1/31/11 11:54 AM, Ulrik Mikaelsson wrote:
 I'm not sure whether text-books and program-code are really comparable
 in this respect. When reading books I hardly put much attention to
 each particular word, while in computer-code, each token is very
 significant. The "flow" of reading is simply different. If it weren't,
 we would hardly use hard line-breaks at all, just concatenate
 statements like we concatenate sentences in text, and use<your word
 processor> =C2=A0to format code. Especially, we would not use monospaced
 fonts and care about "columns".

Well the fact of the matter is that style used in books is very influenti=

 People do copy book samples into code and continue working in the same st=

 from them. I've been asked for (and released) the source code of all
 snippets in TDPL.

Sorry, maybe I was unclear, I wasn't referring to code-snippets in a book. I meant the kind of text-books I understood Walter refer to, that made the basis for 80x25. Think fiction, not programming books. I absolutely agree there are good UI-design reasons to limit column-width in these. Commonly such text is also "text-align: justify", and even broken up into multiple-column layouts to reduce horizontal scan, but precisely those two things make me skeptical about just HOW relevant it actually is for computer-code.
 I would rather like to hear whether any mathematicians ever insert
 hard-breaks into their equations just "to not get them too wide".

I'm not sure I can qualify as a mathematician but my research is very math-heavy. In my thesis (http://erdani.com/research/dissertation_color.p=

 I frequently inserted line breaks even when not technically necessary, ch=

 e.g. eq. 2.16 on page 12.

Thank you, interesting for the topic (although I didn't understand a thing of the actual math :). I note however that given the very terse variable-names (as is common in math), the lines don't actually grow very long. However, where you HAVE chosen to insert line-breaks, is at equality-operators which I would say is roughly a statement in programming-language terms. ("A =3D B" is a statement, while "A+B" is not.) Interestingly enough, this is roughly the rule-of thumb I use. Try hard to keep statements below 90 characters, but don't resort to manual line-breaks if it's not possible.
 Personally, I've been a long time on the fence regarding strict
 line-length, and my current position is:
 =C2=A090 columns is the rule of thumb. 80 columns is often hard to fit
 using readable names, but 90 columns generally works.

Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm no=

 more inclined to increase and/or soften the recommended limit for Phobos.

real value of the 80/90/120/whatever-rule is not really the actual line-length itself. If that was the case, editors with auto-indentation could quite easily have additional rules for automatic code-wraps. The actual value of having the rule is to alert the coder that something _might_ be sub-optimally expressed. Perhaps D should have something similar to pylint? Sure, much of the need for pylint goes away in a statically typed language, but it's also quite good in diagnosing design by code-complexity measurements. OTOH things like symbols-per-file, arguments-per-function, operations-per-function, etc. could be good indicators to quickly spot hairy code. One could also check for naming-conventions and probably other cleanliness-aspects as well.
Jan 31 2011
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2011-01-31 at 13:41 -0500, bearophile wrote:
[ . . . ]
 I think 110 columns are a little too many. I have suggested 90-95
 chars max (but less than 80 on average) after seeing both the problems
 caused by too much short lines (to keep lines below 70-80 chars I have
 seen programmers use 2 spaces to indent or use very short variable
 names. This is worse than 95 chars long lines), and seeing lines with
 120+ chars that cause troubles to older programmer that can't use a
 too much small font because of their older eyes.

What say we cut the agist crap. Just because anyone over 50 (like me) has worsening eyesight doesn't mean they can't work quite happily with 110 character lines using 8pt fonts. I like 110 character lines in smaller fonts, and I like 2 space indents. And proportional fonts -- Ocean Sans MT rules -- why all this monospace font obsession (*). At the end of the day source code consistency is the only really important thing. Anyone amending a file or adding a file to a codebase must do it in the style of the current code so as to avoid spoiling consistency, and creating specious changes in version control. Just because I object to a coding style doesn't mean I can't use it if I am amending someone else code. Whoever is the project leader for a project defines a style and then everyone works with it -- even if that style is some crappy 80 column stupidity ;-) (*) Flame wars should be directed to /dev/null -- or if you insist on using Windows, whatever the equivalent is. :-) --=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 russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 31 2011
parent Kagamin <spam here.lot> writes:
Russel Winder Wrote:

 Just because anyone over 50 (like me) has worsening eyesight doesn't
 mean they can't work quite happily with 110 character lines using 8pt
 fonts.  I like 110 character lines in smaller fonts, and I like 2 space
 indents.  And proportional fonts -- Ocean Sans MT rules -- why all this
 monospace font obsession (*).

I use Verdana 15pt (monospaced fonts don't really scale to this extent and usually don't have characters beyond ASCII). Pixels are small and displays are big nowadays, my editor can accomodate 150 columns in windowed mode.
Feb 01 2011
prev sibling next sibling parent reply JMRyan <nospam nospam.com> writes:
Walter Bright <newshound2 digitalmars.com> wrote in
news:ii4an2$1npj$1 digitalmars.com: 

 80 columns came from how many characters would fit on a standard size
 8.5*11 sheet of paper. Even punch cards followed this precedent.

This suggests (without exactly stating) one of my personal reasons for a strict line length limit: sometimes programmers like to print their code. Maybe I'm showing my age, but I find dead trees best for code review. One *can* use a smaller font (hard on the eyes) or print in landscape (yuck--and even that is not enough for some code). PS. I knew about the punch card precident and have even used key punch machines myself, but I didn't know that punch card length was based on earlier precident. Given the absurd length of line printer output of the day, that surprises me.
Jan 31 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
JMRyan wrote:
 Walter Bright <newshound2 digitalmars.com> wrote in
 news:ii4an2$1npj$1 digitalmars.com: 
 
 80 columns came from how many characters would fit on a standard size
 8.5*11 sheet of paper. Even punch cards followed this precedent.

This suggests (without exactly stating) one of my personal reasons for a strict line length limit: sometimes programmers like to print their code. Maybe I'm showing my age, but I find dead trees best for code review. One *can* use a smaller font (hard on the eyes) or print in landscape (yuck--and even that is not enough for some code). PS. I knew about the punch card precident and have even used key punch machines myself, but I didn't know that punch card length was based on earlier precident. Given the absurd length of line printer output of the day, that surprises me.

Looking it up shows that the history is a bit more complicated than I said: http://en.wikipedia.org/wiki/Hollerith_card http://en.wikipedia.org/wiki/Characters_per_line
Jan 31 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/30/2011 07:27 PM, Walter Bright wrote:
 Andrej Mitrovic wrote:
 80 columns
 wasn't determined by some scientific method to be a good size for code, it's
 a product of limitations of the older generation hardware.

80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.

Code is no newspaper article. And newspaper articles are rarely multi-indented. Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent reply Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Andrej Mitrovic napisa=C5=82:

 If you really want to set up a column limit that *everyone* has to abide =

Actually that's a splendid idea. Let's take it easy. Regardless of that sil= ly beef I'm really curious what distribution will emerge. What is your preferred *maximum* length for a line of D code? (please reply= with a number only) --=20 Tomek
Jan 30 2011
next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Tomek Sowi=C5=84ski wrote:
 Andrej Mitrovic napisa=C5=82:
=20
 If you really want to set up a column limit that *everyone* has to abi=


=20
 Actually that's a splendid idea. Let's take it easy. Regardless of that=

=20
 What is your preferred *maximum* length for a line of D code? (please r=

=20

May occasionally be extended to 80 if there is no easy way to reflow the code below 70, but never above 80. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 30 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/30/2011 12:55 PM, Tomek Sowiński wrote:
 Andrej Mitrovic napisał:

 If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge.

Agreed. FWIW I'm ready to go with anything that Phobos heavyweights vote.
 What is your preferred *maximum* length for a line of D code? (please reply
with a number only)

80. Andrei
Jan 30 2011
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Tomek Sowiński Wrote:
 
 What is your preferred *maximum* length for a line of D code? (please reply
with a number only)

110
Jan 30 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Tomek Sowiński wrote:
 What is your preferred *maximum* length for a line of D code? (please reply
with a number only)

6.022e+23
Jan 30 2011
prev sibling next sibling parent reply foobar <foo bar.com> writes:
Tomek Sowiński Wrote:

 Andrej Mitrovic napisał:
 
 If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge. What is your preferred *maximum* length for a line of D code? (please reply with a number only) -- Tomek

I think that putting an artificial limit is incredibly stupid. Haven't anyone here learned the "No magic numbers" rule?!?! Walter correctly pointed out that it's harder to read long rows, however, unlike printed text and ancient terminals, current display technology is much more dynamic. Font size, zoom level, screen form-factor, window size, resolution, etc means that each person can configure his own individual optimal view. As the OP said, use word wrap and adjust your editor window width/font size/zoom level/etc to your liking. If your editor does not support this "new" feature, go get a new editor and don't bother other people with different preferences. Stop forcing this moronic "one size fits all" attitude on everyone.
Jan 30 2011
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

foobar wrote:
 Tomek Sowi=C5=84ski Wrote:
=20
 Andrej Mitrovic napisa=C5=82:

 If you really want to set up a column limit that *everyone* has to ab=



 Actually that's a splendid idea. Let's take it easy. Regardless of tha=


 What is your preferred *maximum* length for a line of D code? (please =


 --=20
 Tomek

I think that putting an artificial limit is incredibly stupid. Haven't =

=20
 Walter correctly pointed out that it's harder to read long rows, howeve=

is much more dynamic.=20
 Font size, zoom level, screen form-factor, window size, resolution, etc=

=20
 As the OP said, use word wrap and adjust your editor window width/font =

 If your editor does not support this "new" feature, go get a new editor=

 Stop forcing this moronic "one size fits all" attitude on everyone.=20

Do you know of any editor that can word wrap *while respecting indentation*? Any editor I know will wrap to the first column, which renders indentation pointless in the presence of long lines... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 30 2011
next sibling parent foobar <foo bar.com> writes:
Jérôme M. Berger Wrote:

 foobar wrote:
 Tomek Sowiński Wrote:
 
 Andrej Mitrovic napisał:

 If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on.

What is your preferred *maximum* length for a line of D code? (please reply with a number only) -- Tomek

I think that putting an artificial limit is incredibly stupid. Haven't anyone here learned the "No magic numbers" rule?!?! Walter correctly pointed out that it's harder to read long rows, however, unlike printed text and ancient terminals, current display technology is much more dynamic. Font size, zoom level, screen form-factor, window size, resolution, etc means that each person can configure his own individual optimal view. As the OP said, use word wrap and adjust your editor window width/font size/zoom level/etc to your liking. If your editor does not support this "new" feature, go get a new editor and don't bother other people with different preferences. Stop forcing this moronic "one size fits all" attitude on everyone.

Do you know of any editor that can word wrap *while respecting indentation*? Any editor I know will wrap to the first column, which renders indentation pointless in the presence of long lines... Jerome -- mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr

I personally prefer long lines and always code (in eclipse) when the code editor is maximized. I never needed to word-wrap code due to my preferences but every time I need to edit code written by a co-worker that uses Emacs on only a third of the screen I struggle with the many redundant line breaks that just keep breaking my train of thought. I'm sure that it's trivial to add to a code editor that already provides auto indentation a mode to do the same for word-wrap if it doesn't do that yet. In any case, Even without that, it's much more readable than forcing redundant line breaks in the middle of code-lines (e.g. "sentences").
Jan 30 2011
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-30 15:32:45 -0500, "Jrme M. Berger" <jeberger free.fr> said:

 	Do you know of any editor that can word wrap *while respecting
 indentation*?

Xcode. Wrapped line are indented 2 spaces more than the true indent of the line. Given that indentation is generally done by a factor of 4 spaces, it's really easy to spot a wrapped line. This is configurable, of course. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 30 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Michel Fortin wrote:
 On 2011-01-30 15:32:45 -0500, "J=C3=A9r=C3=B4me M. Berger" <jeberger fr=

=20
     Do you know of any editor that can word wrap *while respecting
 indentation*?

Xcode. =20 Wrapped line are indented 2 spaces more than the true indent of the line. Given that indentation is generally done by a factor of 4 spaces,=

 it's really easy to spot a wrapped line. This is configurable, of cours=

=20

Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 31 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jérôme M. Berger wrote:
 	Do you know of any editor that can word wrap *while respecting
 indentation*? Any editor I know will wrap to the first column, which
 renders indentation pointless in the presence of long lines...

Word-wrapping code is a bad idea.
Jan 30 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Walter Bright wrote:
 J=C3=A9r=C3=B4me M. Berger wrote:
     Do you know of any editor that can word wrap *while respecting
 indentation*? Any editor I know will wrap to the first column, which
 renders indentation pointless in the presence of long lines...

Word-wrapping code is a bad idea.

My point exactly. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 31 2011
prev sibling next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

spir wrote:
 On 01/30/2011 09:32 PM, "J=C3=A9r=C3=B4me M. Berger" wrote:
     Do you know of any editor that can word wrap *while respecting
 indentation*? Any editor I know will wrap to the first column, which
 renders indentation pointless in the presence of long lines...

         Jerome

Yop, geany :-) http://en.wikipedia.org/wiki/Geany =20

do not see at a glance that a line is wrapped. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 31 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/31/2011 11:33 PM, "Jérôme M. Berger" wrote:
 	Nope it wraps to the same indent level as the original line, so you
 do not see at a glance that a line is wrapped.

It shows it's a wrapped line using a dedicated "wrapping-arrow" sign. I never use this feature for code, though. Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent reply foobar <foo bar.com> writes:
so Wrote:

 I think that putting an artificial limit is incredibly stupid. Haven't  
 anyone here learned the "No magic numbers" rule?!?!

 Walter correctly pointed out that it's harder to read long rows,  
 however, unlike printed text and ancient terminals, current display  
 technology is much more dynamic.
 Font size, zoom level, screen form-factor, window size, resolution, etc  
 means that each person can configure his own individual optimal view.

 As the OP said, use word wrap and adjust your editor window width/font  
 size/zoom level/etc to your liking.
 If your editor does not support this "new" feature, go get a new editor  
 and don't bother other people with different preferences.
 Stop forcing this moronic "one size fits all" attitude on everyone.

I agree, but i guess they are talking about standard library.

Right, so does that mean it should be made _less_ readable by a diverse community of people? I have no issue with any style Andrei or others use when they code for themselves, be it 10 characters per row or 1000. I do place a MUCH higher weight on making the stdlib readable and accessible for a large range of diverse people with different cultures, languages, traditions, eye-sight, screen sizes, and preferred beer flavors. ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which is by far one of worst ever. both Java and C# are surprisingly high on this list and are behind various "new-age" scripting languages such as python and Ruby and languages that were designed to be readable by humans such as Smalltalk.
Jan 30 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
foobar wrote:
 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which
 is by far one of worst ever. both Java and C# are surprisingly high on this
 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.

I think you've mixed up libraries with languages. Please rephrase so we know what you're referring to and give specifics.
Jan 30 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail Erdani.org> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 foobar wrote:
 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which
 is by far one of worst ever. both Java and C# are surprisingly high on this
 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.

what you're referring to and give specifics.

Seconded. Also there is this one presupposition that reflects poorly on foobar's argument: that choosing foobar's preferred convention inherently makes the code more accessible. In fact, a stronger argument could be made to the contrary as we're talking about a maximum and 80 < 120. Andrei from the ER
Jan 30 2011
parent reply foobar <foo bar.com> writes:
Andrei Alexandrescu Wrote:

 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 foobar wrote:
 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which
 is by far one of worst ever. both Java and C# are surprisingly high on this
 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.

what you're referring to and give specifics.

Seconded. Also there is this one presupposition that reflects poorly on foobar's argument: that choosing foobar's preferred convention inherently makes the code more accessible. In fact, a stronger argument could be made to the contrary as we're talking about a maximum and 80 < 120. Andrei from the ER

That's just incorrect since I didn't even specify my style convention. As I said multiple times before, Phobos is design with Andrei in mind: meaning that if you are Andrei-like (or if you _are_ indeed Andrei) it would be easy to read and use. Otherwise it confusing as hell and hard to navigate. In addition, you now want to force artificial limits that don't make any sense. You completely miss the most important principle - it doesn't matter how good and efficient your product is if no one's using it. Phobos is a very good product that I for one will never use. Just looking at the one huge page for algorithms is enough to discourage many people.
Jan 30 2011
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-31 02:18:26 -0500, foobar <foo bar.com> said:

 Phobos is a very good product that I for one will never use. Just 
 looking at the one huge page for algorithms is enough to discourage 
 many people.

But is Phobos the problem or is the one-page-per-module documentation the problem? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 31 2011
parent foobar <foo bar.com> writes:
Michel Fortin Wrote:

 On 2011-01-31 02:18:26 -0500, foobar <foo bar.com> said:
 
 Phobos is a very good product that I for one will never use. Just 
 looking at the one huge page for algorithms is enough to discourage 
 many people.

But is Phobos the problem or is the one-page-per-module documentation the problem? -- Michel Fortin michel.fortin michelf.com http://michelf.com/

Phobos' organization is the problem. If you read the C++ standard you'll see that their description of the stdlib describes <algorithm> as a library. Hence, c++'s design is a single file per library. Phobos does exactly the same mistake. D has a far superior module system that doesn't require this moronic design. Please let's use it. I have a hard time believing that having a separate doc page per function is a better solution than to properly organize the code.
Jan 31 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/31/2011 01:18 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 foobar wrote:
 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which
 is by far one of worst ever. both Java and C# are surprisingly high on this
 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.

what you're referring to and give specifics.

Seconded. Also there is this one presupposition that reflects poorly on foobar's argument: that choosing foobar's preferred convention inherently makes the code more accessible. In fact, a stronger argument could be made to the contrary as we're talking about a maximum and 80< 120. Andrei from the ER

That's just incorrect since I didn't even specify my style convention. As I said multiple times before, Phobos is design with Andrei in mind: meaning that if you are Andrei-like (or if you _are_ indeed Andrei) it would be easy to read and use. Otherwise it confusing as hell and hard to navigate.

But that goes for anyone, including your code. Code written in foobar's style is designed with foobar in mind: meaning that if you are foobar-like (or if you _are_ indeed foobar) it would be easy to read and use. Otherwise it is confusing as hell and hard to navigate. I can only assume you'd have a hard time writing code that does not have foobar's signature. Same here. Besides, it seems to have worked for me; at work I'm not considered one of the more obfuscated coders. Also, I wrote a little library Loki which is regarded as very small and readable for what it does. Its functionality has been shadowed by the much larger and comprehensive Boost, but Loki's code has always been the simplest and cleanest although it implements rather advanced concepts. Do you have any publicly available samples of your work that we might look at?
 In addition, you now want to force artificial limits that don't make
 any sense.

 You completely miss the most important principle - it doesn't matter
 how good and efficient your product is if no one's using it. Phobos
 is a very good product that I for one will never use. Just looking at
 the one huge page for algorithms is enough to discourage many
 people.

From what I've seen, everyone who advocates D2 mentions std.algorithm as one of its main strengths, and never as a liability. I have difficulty reconciling that signal with one opinion relayed anonymously. Andrei
Jan 31 2011
next sibling parent foobar <foo bar.com> writes:
Andrei Alexandrescu Wrote:

 On 01/31/2011 01:18 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 foobar wrote:
 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which
 is by far one of worst ever. both Java and C# are surprisingly high on this
 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.

what you're referring to and give specifics.

Seconded. Also there is this one presupposition that reflects poorly on foobar's argument: that choosing foobar's preferred convention inherently makes the code more accessible. In fact, a stronger argument could be made to the contrary as we're talking about a maximum and 80< 120. Andrei from the ER

That's just incorrect since I didn't even specify my style convention. As I said multiple times before, Phobos is design with Andrei in mind: meaning that if you are Andrei-like (or if you _are_ indeed Andrei) it would be easy to read and use. Otherwise it confusing as hell and hard to navigate.

But that goes for anyone, including your code. Code written in foobar's style is designed with foobar in mind: meaning that if you are foobar-like (or if you _are_ indeed foobar) it would be easy to read and use. Otherwise it is confusing as hell and hard to navigate. I can only assume you'd have a hard time writing code that does not have foobar's signature. Same here. Besides, it seems to have worked for me; at work I'm not considered one of the more obfuscated coders. Also, I wrote a little library Loki which is regarded as very small and readable for what it does. Its functionality has been shadowed by the much larger and comprehensive Boost, but Loki's code has always been the simplest and cleanest although it implements rather advanced concepts. Do you have any publicly available samples of your work that we might look at?
 In addition, you now want to force artificial limits that don't make
 any sense.

 You completely miss the most important principle - it doesn't matter
 how good and efficient your product is if no one's using it. Phobos
 is a very good product that I for one will never use. Just looking at
 the one huge page for algorithms is enough to discourage many
 people.

From what I've seen, everyone who advocates D2 mentions std.algorithm as one of its main strengths, and never as a liability. I have difficulty reconciling that signal with one opinion relayed anonymously. Andrei

Everything is relative. Loki is a c++ library and I'm sure it's one of the best c++ libs. This is relative to a horribly unfriendly language which is used by a certain type of people. I'm OTOH comparing to a different set of languages, their libs and their users. Also, I never said that Phobos is poor from an implementation point of view, on the contrary, I too think that especially the new phobos modules (Algorithms) and concepts (Range) are very good and efficient. My reoccurring complain is about _usability_ of this awesome code base. The code is poorly organized in few huge files, functions are poorly named, etc. I keep taking about the API while you keep talking about its implementation. D needs to cater for different kinds of people, not just American born C++ guru programmers, but a diverse community of programmers with different programming backgrounds (that includes web developers that only learned scripting languages), different nationalities (They don't need to have native level English capabilities including understanding of American culture and insider jokes), different OS users (not just *nix geeks), etc.
Jan 31 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/31/11 1:07 PM, Steven Schveighoffer wrote:
 On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 01/31/2011 01:18 AM, foobar wrote:

 You completely miss the most important principle - it doesn't matter
 how good and efficient your product is if no one's using it. Phobos
 is a very good product that I for one will never use. Just looking at
 the one huge page for algorithms is enough to discourage many
 people.

From what I've seen, everyone who advocates D2 mentions std.algorithm as one of its main strengths, and never as a liability. I have difficulty reconciling that signal with one opinion relayed anonymously.

I think the main problem is with ddoc. This, from std.algorithm is a f**king mess IMO: Jump to: BoyerMooreFinder EditOp Group NWayUnion OpenRight SetDifference SetIntersection SetSymmetricDifference SetUnion SortOutput Splitter SwapStrategy Uniq Until balancedParens boyerMooreFinder bringToFront canFind completeSort copy count endsWith equal fill filter find findAdjacent findAmong group indexOf initializeAll insert isPartitioned isSorted largestPartialIntersection largestPartialIntersectionWeighted levenshteinDistance levenshteinDistanceAndPath makeIndex map max min minCount minPos mismatch move moveAll moveSome nWayUnion no none partialSort partition reduce remove reverse schwartzSort semistable setDifference setIntersection setSymmetricDifference setUnion skipOver sort splitter stable startsWith substitute swap swapRanges topN topNCopy uninitializedFill uniq unstable until yes (in voice of comic-book guy) Worst navigation bar ever. -Steve

Let's fix it! I'm thinking along the lines of finding some broad groups, e.g. Searching find until mismatch startsWith ... Sorting sort partialSort partition ... Set operations setUnion setDifference ... ...? We'd eliminate the unstructured "jump to" section and we create the grouping by hand (sigh). Andrei
Jan 31 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Andrei Alexandrescu wrote:
 We'd eliminate the unstructured "jump to" section and we create the
 grouping by hand (sigh).

Maybe we can get the best of both worlds: how about a "Group:" or "Tags:" section in the ddoc that a program could automatically pull out to make the listing? I think we can do that without modifying the compiler. Scanning the text in javascript or whatever for that section would be simple enough.
Jan 31 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/31/11 1:22 PM, Adam Ruppe wrote:
 Andrei Alexandrescu wrote:
 We'd eliminate the unstructured "jump to" section and we create the
 grouping by hand (sigh).

Maybe we can get the best of both worlds: how about a "Group:" or "Tags:" section in the ddoc that a program could automatically pull out to make the listing? I think we can do that without modifying the compiler. Scanning the text in javascript or whatever for that section would be simple enough.

Great idea! Andrei
Jan 31 2011
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-01-31 14:13:40 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Let's fix it! I'm thinking along the lines of finding some broad groups, e.g.
 
 Searching
 
 find until mismatch startsWith ...
 
 Sorting
 
 sort partialSort partition ...
 
 Set operations
 
 setUnion setDifference ...
 
 ...?
 
 We'd eliminate the unstructured "jump to" section and we create the 
 grouping by hand (sigh).

Please do. Grouping by task is very useful when you're searching for a particular function. That said, it'd help if Ddoc could help too... For documenting Objective-C files I have made my own documentation generator (written in D!) which gives you this kind of output: <http://michelf.com/projects/asounding/reference/class-ASNEngine.html> For generating the above page, all I have to do in my header file is to specify which documentation group each function belongs to and the rest is done automatically. Here's the corresponding header file; notice I only have to write a group directive when the group changes, not for each function: <http://michelf.com/docs/tests/ASNEngine.h> -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 31 2011
prev sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Steven Schveighoffer wrote:
 I think the main problem is with ddoc.  This, from std.algorithm is a
 f**king mess IMO:

Note that that is generated through some short javascript in the html header. I remember writing a brief change to that to make it look a lot better (organized into a simple grid) but it seems to be lost now. I'd be willing to redo it though. Need to make a github account to get commit power back, but if there's agreement on changes, I'll make them.
Jan 31 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
Steven Schveighoffer wrote:
 I'm all for it (voice with no authority).

Here it is with the brief css change to put it in a grid: http://arsdnet.net/d-web-site/std_algorithm.html It's a very small change that, to me, makes a huge difference.
 I really think ddoc needs to be revamped to do more in this area,
 along with cross-linking.

Agreed. Though, if we can't change the compiler, we could do this with a macro too. Use ($func std.file.read) to read a file. And the $func macro can simply link it to the right place, or to something like my own dpldocs.info/std.file.read to redirect/search for the referenced item. Say... I wonder... there's already a class "d_psymbol" in the html, I could do this in the script too, or maybe with a simple tweak to the existing macro. I did it in script on that same link. I'm not in love with it, but it proves the concept is easy enough with what we already have.
Jan 31 2011
next sibling parent Adam Ruppe <destructionator gmail.com> writes:
 Say... I wonder... there's already a class "d_psymbol" in the

No, I'm wrong. That's only the currently referenced symbol. No point linking back to itself! Gotta go back to the drawing board for good cross referencing.
Jan 31 2011
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 31.01.2011 22:06, schrieb Steven Schveighoffer:
 On Mon, 31 Jan 2011 15:38:50 -0500, Adam Ruppe <destructionator gmail.com>
wrote:
 
 Steven Schveighoffer wrote:
 I'm all for it (voice with no authority).

Here it is with the brief css change to put it in a grid: http://arsdnet.net/d-web-site/std_algorithm.html It's a very small change that, to me, makes a huge difference.

It does help, but I was kind of hoping for something that shows the structure. For example I see 'OpenRight' is an enum, and 'yes' is a member of that enum, but they are listed in random order (OpenRight coming at the beginning and yes coming at the end). This is still pretty much fail.

For D1 (maybe it works with D2 as well? It used dmd) there was CandyDoc (I think the latest version was in the dsss svn?) It produced a good overview, IMHO, see http://bildupload.sro.at/p/370054.html
Jan 31 2011
prev sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Steven Schveighoffer wrote:
 It does help, but I was kind of hoping for something that shows the
 structure.

Those relationships are in the HTML too.... try it now: http://arsdnet.net/d-web-site/std_algorithm.html (I know it needs some work still, I'm just sick of Javascript after spending 20 minutes tracking down a bug caused by me using the same variable name twice! Gah! And wow do I miss foreach.)
Jan 31 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:

 (I know it needs some work still, I'm just sick of Javascript after
 spending 20 minutes tracking down a bug caused by me using the
 same variable name twice! Gah! And wow do I miss foreach.)

A good C lint is very good at spotting that kind of bugs. There are lints for JS too, but I don't know if they are able to spot this kind of bug. Bye, bearophile
Jan 31 2011
prev sibling parent reply foobar <foo bar.com> writes:
Walter Bright Wrote:

 foobar wrote:
 ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which
 is by far one of worst ever. both Java and C# are surprisingly high on this
 list and are behind various "new-age" scripting languages such as python and
 Ruby and languages that were designed to be readable by humans such as
 Smalltalk.

I think you've mixed up libraries with languages. Please rephrase so we know what you're referring to and give specifics.

I just tried to save typing :) Just replace above "language foo" with "language foo's standard library" Java (the language itself) is mediocre at best but the Java standard libraries are excellent with comprehensive usable documentation to boot. Phobes is half a notch above c++ stdlib which is the worst ever from a usability and readability perspective. Are we still using G-d files? really?
Jan 30 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
foobar wrote:
 Java (the language itself) is mediocre at best but the Java standard
 libraries are excellent with comprehensive usable documentation to boot.
 
 Phobes is half a notch above c++ stdlib which is the worst ever from a
 usability and readability perspective. Are we still using G-d files? really?

Please take a module or function in the phobos documentation, and rewrite it to how you think it should be done and post it, as an example of how to do it right. We welcome such help.
Jan 30 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/30/2011 10:18 PM, foobar wrote:
 Right, so does that mean it should be made_less_  readable by a diverse
community of people?
 I have no issue with any style Andrei or others use when they code for
themselves, be it 10 characters per row or 1000.
 I do place a MUCH higher weight on making the stdlib readable and accessible
for a large range of diverse people with different cultures, languages,
traditions, eye-sight, screen sizes, and preferred beer flavors.

There is only one true beer flavor.
 ATM, Phobos ranks extremely poorly in this regard.

Sure. How can we ensure Phobos contributors drink Pilsner Urquell? http://en.wikipedia.org/wiki/Pilsner_Urquell Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/31/2011 07:38 PM, foobar wrote:
 I keep taking about the API while you keep talking about its implementation.
   D needs to cater for different kinds of people, not just American born C++
guru programmers, but a diverse community of programmers with different
programming backgrounds (that includes web developers that only learned
scripting languages), different nationalities (They don't need to have native
level English capabilities including understanding of American culture and
insider jokes), different OS users (not just *nix geeks), etc.

+++ (insider jokes are excluding jokes) (I'm unsure about tolerating Heineken drinkers, though) Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/30/2011 09:32 PM, "Jérôme M. Berger" wrote:
 foobar wrote:
 Tomek Sowiński Wrote:

 Andrej Mitrovic napisał:

 If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on.

What is your preferred *maximum* length for a line of D code? (please reply with a number only) -- Tomek

I think that putting an artificial limit is incredibly stupid. Haven't anyone here learned the "No magic numbers" rule?!?! Walter correctly pointed out that it's harder to read long rows, however, unlike printed text and ancient terminals, current display technology is much more dynamic. Font size, zoom level, screen form-factor, window size, resolution, etc means that each person can configure his own individual optimal view. As the OP said, use word wrap and adjust your editor window width/font size/zoom level/etc to your liking. If your editor does not support this "new" feature, go get a new editor and don't bother other people with different preferences. Stop forcing this moronic "one size fits all" attitude on everyone.

Do you know of any editor that can word wrap *while respecting indentation*? Any editor I know will wrap to the first column, which renders indentation pointless in the presence of long lines... Jerome

Yop, geany :-) http://en.wikipedia.org/wiki/Geany Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent David Nadlinger <see klickverbot.at> writes:
On 1/30/11 7:55 PM, Tomek Sowiński wrote:
 Andrej Mitrovic napisał:

 If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge. What is your preferred *maximum* length for a line of D code? (please reply with a number only)

80
Jan 30 2011
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 30.01.2011 19:55, schrieb Tomek Sowiński:
 Andrej Mitrovic napisał:

 If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge. What is your preferred *maximum* length for a line of D code? (please reply with a number only)

about 100 (don't care if its 2 chars more to fit a ");" or something like that)
Jan 30 2011
prev sibling next sibling parent Jim <bitcirkel yahoo.com> writes:
Tomek Sowiński Wrote:

 Andrej Mitrovic napisał:
 
 If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge. What is your preferred *maximum* length for a line of D code? (please reply with a number only) -- Tomek

--- No limit --- Although indentation makes lines "longer" they do not make them harder to read. So I don't put an artificial limit because I don't know how many levels of indentation I will need. Do you manually adjust and put new line-breaks on every line of code if you need to add a level on indentation???
Jan 30 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Tomek Sowinski" <just ask.me> wrote in message 
news:20110130195553.5db1ed2e Las-Miodowy...
What is your preferred *maximum* length for a line of D code? (please reply 
with a number only)

I generally try to stick to about 80 as a rule-of-thumb, but I'll go up to around 100 (or more in rare cases, but in those cases I cringe) when I think breaking it would uglify it too much. So I don't really have an exact number.
Jan 30 2011
prev sibling next sibling parent Don <nospam nospam.com> writes:
Tomek Sowiński wrote:
 Andrej Mitrovic napisał:
 
 If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge. What is your preferred *maximum* length for a line of D code? (please reply with a number only)

Second preference: 110.
Jan 31 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Tomek Sowiński wrote:
 1 respondent answered "1 mole" which I also excluded as a 22-order-of-magnitude
 outlier.

What kind of a jerk is that respondent?
Jan 31 2011
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 30/01/2011 18:55, Tomek Sowiński wrote:
 Andrej Mitrovic napisał:

 If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge. What is your preferred *maximum* length for a line of D code? (please reply with a number only)

My preferred maximum length for Java is 120. I haven't coded much D to have an opinion about the length for D, but I would suspect it would be more or less the same: Yes, on many things D code lines will have shorter length than Java (you can have free functions, you have the "auto" declarator for variables, you have scope statements, etc.), but on other things D code might have more (const/immutable and other attributes, like pure, safe, etc., etc.). But in any case this poll is only an informative curiosity. It does not make sense for it to affect Phobos's style standards, it is the (weighted) opinion of the Phobos/Druntime developers that should matter, of course. -- Bruno Medeiros - Software Engineer
Feb 10 2011
prev sibling next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Tomek Sowi=C5=84ski napisa=C5=82:

 What is your preferred *maximum* length for a line of D code? (please rep=

120. --=20 Tomek
Jan 30 2011
prev sibling next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Sean Kelly napisa=C5=82:

 Print text doesn't have indentation levels though.  Assuming a 4 characte=

8 characters. Add a nested conditional and code is starting 16 characters= in, which when wrapped at 80 characters begins to look like a newspaper co= lumn. I wrap all my comments at 79 characters, but allow code to spill as = far as 110 (which is the number of columns on an 8.5x11" piece of paper in = landscape mode). Yeah. If counted without indents, 90 characters would probably suffice, but= with them it's at least 120 so that nested code doesn't get stifled. And I'm programming with a proportional font -- far more readable than a mo= no-space. --=20 Tomek
Jan 30 2011
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Tomek Sowi=C5=84ski <just ask.me> wrote:

 Andrej Mitrovic napisa=C5=82:

 If you really want to set up a column limit that *everyone* has to  =


 abide to, then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of tha=

 silly beef I'm really curious what distribution will emerge.

 What is your preferred *maximum* length for a line of D code? (please =

 reply with a number only)

80 columns of code. Indents may change that slightly. -- = Simen
Jan 30 2011
prev sibling next sibling parent so <so so.do> writes:
 I think that putting an artificial limit is incredibly stupid. Haven't  
 anyone here learned the "No magic numbers" rule?!?!

 Walter correctly pointed out that it's harder to read long rows,  
 however, unlike printed text and ancient terminals, current display  
 technology is much more dynamic.
 Font size, zoom level, screen form-factor, window size, resolution, etc  
 means that each person can configure his own individual optimal view.

 As the OP said, use word wrap and adjust your editor window width/font  
 size/zoom level/etc to your liking.
 If your editor does not support this "new" feature, go get a new editor  
 and don't bother other people with different preferences.
 Stop forcing this moronic "one size fits all" attitude on everyone.

I agree, but i guess they are talking about standard library.
Jan 30 2011
prev sibling next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Walter Bright napisa=C5=82:

 What is your preferred *maximum* length for a line of D code? (please r=


=20
 6.022e+23

That's a whole mole of code! ;-) --=20 Tomek
Jan 30 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:ii46g5$1g66$1 digitalmars.com...
 The unittest topic is about to get derailed so I want to continue this 
 silly discussion here.

 Wheres Nick? I want to see the CRT vs LCD discussion heated up again with 
 Andrei claiming that LCDs are so Godlike but yet claims 80 columns is 
 enough for everyone.

Heh :) This is what I do: My editor shows a faint vertical line at the end of column 80. I use that as a rough general guideline, but not a hard-and-fast rule. I agree with Andrei that the longer a line of code or text gets beyond 80 columns, the harder it gets to read. Heck, I had one co-worker once who had his code total-fullscreen on a 16:9 with lines extending all the way to the end: it was horrible. I do think you can go a little bit further than 80 columns while still being perfectly readable, but I think 80 is a sensible time-honered rule of thumb for maximum compatibility as long as you're not too strict about it. One other reason to not be too strict about the 80-column guideline is elastic tabstops. With those, propotional fonts become perfectly sensible to use for code, and then "80-columns" inherently becomes "fuzzy". Minor side note: Vertical space being much more important than horizontal for both code and other text is the primary reason I'd never consider getting a widescreen monitor. (For TV's I can go either way, though, as long as the non-widescreen can properly scale/letterbox widescreen signals.)
 80 colums is an artifact of the old age. Just like the preprocessor is an 
 artifact of the C language. And many other old things are artifacts. 
 There's no reason to keep these artifacts around anymore.

Like Andrei said, it may not be a technical limitation anymore, but it is still a human limitation. Any remotely modern computer is perfectly capable of speeding up voice playback by 10x, but nobody does it that fast because the human user is the limiting factor. Of course, if someone said "let's use 90 or 100 lines as the guideline", I wouldn't object at all. But 80 has a lot of history behind it, and is therefore much easier to agree on as a rough standard, and it does still work out, again, as long as you're not too strict about it. (And it doesn't hurt that I'm a fan of both powers-of-two and the 1980's, so there's that nice warm psychological connection ;) )
 A couple of things, Andrei:
 1. 80 colums is way too restrictive. 80 columns wasn't determined by some 
 scientific method to be a good size for code, it's a product of 
 limitations of the older generation hardware. Who will run a brand new 
 language like D in a freakin' Terminal?

There's a lot of text-mode junkies out there. And for Unix users, there may be times when they need to work in pure text-mode. Also, it's common to have a million other frames showing (see a typical Eclipse setup), so that can really limit how many columns people have available, too.
 If you want to see more files on the screen, get multiple screens. Is 
 Facebook running out of money, can't they afford a few monitors for the 
 C++ guru? Yes, I know you're not allowed to comment on that one. :)

He probably already has as many as his cubicle will hold ;)
 2. A widescreen aspect ratio causes less eye strain. Wider code means the 
 same.

That's just plain rediculous. I don't know where you got that. *Maybe* for watching video, but certainly not text.
 3. Less columns means more rows. And generally coders *hate* it when they 
 can't see a function that fits on a single screen. They hate having to 
 scroll up and down. This common syntax form is a proof of that:
 void main() {
    void foo() {
         while (true) {
             if (done) {
             }
         }
     }
 }

 I find that unpleasant to read. Not impossible, but unpleasant. I can live 
 with it though, but if you limit code to 80 limits that's going to become 
 a mess to read.

FWIW, I'd write that this way: void main() { void foo() { while(true) if(done) { } } } I'm a big fan of "stacking" flow-control statements like that whenever the outer statements don't have anything else in their body. Like this (stupid example): // Draw funny design (and yes, this could be optimized better) if(shouldRefresh) foreach(int x; 0..width) foreach(int y; 0..height) if(x ^ y < width*height / 2) buffer[x + y*width] = palette[(x+y) % $]; Instead of something more like: // Draw funny design (and yes, this could be optimized better) if(shouldRefresh) { foreach(int x; 0..width) { foreach(int y; 0..height) { if(x ^ y < width*height / 2) buffer[x + y*width] = palette[(x+y) % $]; } } }
 3. It's 2010. Does your GNU/emacs still not support wrapping lines by word 
 boundaries? Scite had this since the '90s, and that's not even an advanced 
 editor. Vim supports word wrapping as well. Heck, I'm pretty sure you can 
 customize it to wrap on whatever boundary you want to (although I'm only 
 speculating, but pretty much everything in Vim is customizable). You can 
 even customize how your cursor reacts if it's on an 'artificial' new line, 
 one that has been wrapped.

That's not a bad point. But if a line is that long, it's going to be difficult to read anyway without doing it manually and taking syntax into acount: auto str = join(formatStr1, formatStr2, formatStr3, formatStr4, formatStr5).format(someValue1, someValue2, cond? "" : someStr, someValue3 + someValue4); Vs: auto str = join( formatStr1, formatStr2, formatStr3, formatStr4, formatStr5 ) .format( someValue1, someValue2, cond? "" : someStr, someValue3 + someValue4 ); I find the second one perfectly readable, but I can't even make head or tails of the first one, and I just wrote it a few seconds ago!
 4. Just how many files do you want to edit at a single time on the screen? 
 We're not really multitasking beings, you know.

I'm rarely editing only one file at a time. Frequently a whole handful. (But I "Ctrl-Tab" through them.)
 If you really want to set up a column limit that *everyone* has to abide 
 to, then make a poll to see what everyone can agree on. I don't see why 
 everyone has to cater to your rules only, regardless of what your 
 professional experience might be. You're a big contributor to Phobos, but 
 you're not the only one. I tend to believe that D is (or should be) a 
 community effort, so please don't hijack D away from the community by 
 forcing your own rules down to everyone else.

Sounds fair. (But I'm not a Phobos dev, so my opinion on that is probably irrelevent.)
Jan 30 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 80 colums is an artifact of the old age.


An elegant width, from a more civilized age.
 Any remotely modern computer is perfectly capable
 of speeding up voice playback by 10x, but nobody does it that fast because
 the human user is the limiting factor.

People who use screen readers often crank up the playback rate to 2x. The software adjusts the pitch so it doesn't sound like the Chipmunks. I've often wondered why DVRs don't do this (I've sent the suggestion to Tivo, they ignored me). I'd like the option to play the news (or other talk shows) at a faster rate, with pitch adjustment. I've found I can watch Tivo at 3x with the closed captioning on, and can almost keep up. The problem with DVRs at any fast forward speed is they turn the sound off! Grrrr. A golden opportunity missed. I'd also love it if youtube etc. did this. It's so boring looking at youtube presentations because they talk so slow. I'd love a double speed youtube viewing option. Remember I posted this in case some troll tries to patent it.
Jan 30 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter:

 Remember I posted this in case some troll tries to patent it.

I sometimes see&hear documentaries at 140-160% speed. Bye, bearophile
Jan 30 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:ii4p8u$2ico$1 digitalmars.com...
 Nick Sabalausky wrote:
 80 colums is an artifact of the old age.


An elegant width, from a more civilized age.
 Any remotely modern computer is perfectly capable
 of speeding up voice playback by 10x, but nobody does it that fast 
 because
 the human user is the limiting factor.

People who use screen readers often crank up the playback rate to 2x. The software adjusts the pitch so it doesn't sound like the Chipmunks. I've often wondered why DVRs don't do this (I've sent the suggestion to Tivo, they ignored me). I'd like the option to play the news (or other talk shows) at a faster rate, with pitch adjustment. I've found I can watch Tivo at 3x with the closed captioning on, and can almost keep up. The problem with DVRs at any fast forward speed is they turn the sound off! Grrrr. A golden opportunity missed. I'd also love it if youtube etc. did this. It's so boring looking at youtube presentations because they talk so slow. I'd love a double speed youtube viewing option. Remember I posted this in case some troll tries to patent it.

I wish someone would finally just patent getting patents. (IBM's come close from what I hear, but it's not quite there yet.) That's probably the only way the US will ever be rid of the dammed things. Heck, with the USPTO being as grossly incompetent as it is, it would probably be granted: it would just have to be written in a sufficiently ultra-pedantic style.
Jan 30 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
Nick Sabalausky wrote:
 I wish someone would finally just patent getting patents. (IBM's come close 
 from what I hear, but it's not quite there yet.) That's probably the only 
 way the US will ever be rid of the dammed things. Heck, with the USPTO being 
 as grossly incompetent as it is, it would probably be granted: it would just 
 have to be written in a sufficiently ultra-pedantic style.

I agree that patents are a blight on the industry.
Jan 30 2011
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 01/30/2011 04:29 PM, Nick Sabalausky wrote:
 Minor side note: Vertical space being much more important than horizontal
 for both code and other text is the primary reason I'd never consider
 getting a widescreen monitor.

Widescreen monitors are awesome as an alternative to dual-screen monitors. I liked the idea of being able to compare stuff side-by-side with dual screens, but never liked the implementation. Too much fussing around and an ugly gap in the middle. As for vertical space, I just made sure the monitor I bought had as much or more than the old one it replaced.
Jan 30 2011
parent "Nick Sabalausky" <a a.a> writes:
"Jeff Nowakowski" <jeff dilacero.org> wrote in message 
news:ii4rdu$2lvc$1 digitalmars.com...
 On 01/30/2011 04:29 PM, Nick Sabalausky wrote:
 Minor side note: Vertical space being much more important than horizontal
 for both code and other text is the primary reason I'd never consider
 getting a widescreen monitor.

Widescreen monitors are awesome as an alternative to dual-screen monitors. I liked the idea of being able to compare stuff side-by-side with dual screens, but never liked the implementation. Too much fussing around and an ugly gap in the middle.

Yea, not bad at that.
 As for vertical space, I just made sure the monitor I bought had as much 
 or more than the old one it replaced.

I'm typically limited more horizontally than vertically, so replacing a non-widescreen with a widescreen that's at least as tall would likely mean getting one that's too wide to fit.
Jan 30 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 01/30/2011 10:29 PM, Nick Sabalausky wrote:
 void main()
 {
      void foo()
      {
         while(true)
         if(done)
         {
         }
      }
 }

 I'm a big fan of "stacking" flow-control statements like that whenever the
 outer statements don't have anything else in their body.

 Like this (stupid example):

 // Draw funny design (and yes, this could be optimized better)
 if(shouldRefresh)
 foreach(int x; 0..width)
 foreach(int y; 0..height)
 if(x ^ y<  width*height / 2)
      buffer[x + y*width] = palette[(x+y) % $];

 Instead of something more like:

 // Draw funny design (and yes, this could be optimized better)
 if(shouldRefresh)
 {
      foreach(int x; 0..width)
      {
          foreach(int y; 0..height)
          {
              if(x ^ y<  width*height / 2)
                  buffer[x + y*width] = palette[(x+y) % $];
          }
      }
 }

Nice idea :-) Really makes sense, imo. Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 30/01/2011 17:17, Andrej Mitrovic wrote:
<snip>
 80 colums is an artifact of the old age.  Just like the
 preprocessor is an artifact of the C language.  And many other old
 things are artifacts.  There's no reason to keep these artifacts
 around anymore.

Other than, as you begin to say, the difficulty in deciding on where to move the line to.
 A couple of things, Andrei:
 1.  80 colums is way too restrictive.  80 columns wasn't determined
 by some scientific method to be a good size for code, it's a
 product of limitations of the older generation hardware.  Who will
 run a brand new language like D in a freakin' Terminal?

For all I know, people probably still do run the D compiler in the terminal app on Unix-like systems.
 Have you ever heard of the expression "limitations boost
 creativity"?  That can be considered a good thing, if creativity is
 what you're after.  In code, it's not.  You're looking for clarity
 in code.  80 column limitations are good for C obfuscation contests
 and nothing else.  80 columns means people are going to *work
 around* the limit, by using hacks and workarounds to make
 everything fit in place.  Do you really believe that programmers
 are going to spend any time at all thinking: *"oh this line doesn't
 fit on 80 columns.  I should now spend some time thinking about how
 to improve and rewrite the design of my code.  80 columns really is
 the golden ration"*?

For all I know, Fortran programmers probably still do this kind of stuff all the time. I guess the designers of Fortran 90 for some reason thought it was right to "protect" programmers by keeping a line length limit, though they did at least increase the limit to 132. Does anyone here know how Fortran 95, 2003 and 2008 compare? <snip>
 3.  It's 2010.  Does your GNU/emacs still not support wrapping
 lines by word boundaries?  Scite had this since the '90s, and
 that's not even an advanced editor.  Vim supports word wrapping as
 well.

But automatic word wrapping is usually designed to be used on prose, not program code. Do those programs have a word wrapping algorithm that makes program code look good? <snip>
 If you really want to set up a column limit that *everyone* has to
 abide to, then make a poll to see what everyone can agree on.

Therein lies the problem - in this day and age, everyone's screen is different, and everyone's needs are different. Even if we can get people to agree on a limit of 100 in this day and age, it might not suit the programmers of the future. After all, OUAT people managed with the 32 columns of the ZX Spectrum. Stewart.
Jan 30 2011
next sibling parent reply foobar <foo bar.com> writes:
Stewart Gordon Wrote:

 Therein lies the problem - in this day and age, everyone's screen is 
 different, and everyone's needs are different.  Even if we can get 
 people to agree on a limit of 100 in this day and age, it might not suit 
 the programmers of the future.  After all, OUAT people managed with the 
 32 columns of the ZX Spectrum.
 
 Stewart.

That's why I'm opposed to *any* artificial limit as proposed by Andrei.
Jan 30 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/31/2011 01:48 AM, foobar wrote:
 Stewart Gordon Wrote:

 Therein lies the problem - in this day and age, everyone's screen is
 different, and everyone's needs are different.  Even if we can get
 people to agree on a limit of 100 in this day and age, it might not suit
 the programmers of the future.  After all, OUAT people managed with the
 32 columns of the ZX Spectrum.

 Stewart.

That's why I'm opposed to *any* artificial limit as proposed by Andrei.

Opposition rendered anonymously from an armchair quarterback has little credibility. If you join Phobos on technical merit, we will all be very glad to do our best to accommodate your needs. Andrei
Jan 31 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 31.01.2011 00:17, schrieb Stewart Gordon:
 On 30/01/2011 17:17, Andrej Mitrovic wrote:
 <snip>
 80 colums is an artifact of the old age. Just like the
 preprocessor is an artifact of the C language. And many other old
 things are artifacts. There's no reason to keep these artifacts
 around anymore.

Other than, as you begin to say, the difficulty in deciding on where to move the line to.
 A couple of things, Andrei:
 1. 80 colums is way too restrictive. 80 columns wasn't determined
 by some scientific method to be a good size for code, it's a
 product of limitations of the older generation hardware. Who will
 run a brand new language like D in a freakin' Terminal?

For all I know, people probably still do run the D compiler in the terminal app on Unix-like systems.

1. The D-Compiler doesn't care if the code fits in your terminal 2. You can have bigger terminals than 80x25 - just resize your xterm/rxvt/gnome-terminal/putty/whatever
Jan 31 2011
parent "Nick Sabalausky" <a a.a> writes:
"Daniel Gibson" <metalcaedes gmail.com> wrote in message 
news:ii67i0$1vf2$2 digitalmars.com...
 Am 31.01.2011 00:17, schrieb Stewart Gordon:
 For all I know, people probably still do run the D compiler in the
 terminal app on Unix-like systems.

1. The D-Compiler doesn't care if the code fits in your terminal 2. You can have bigger terminals than 80x25 - just resize your xterm/rxvt/gnome-terminal/putty/whatever

Not if you're in text-mode. Which could happen if your X11 gets fucked. Which has happened to me [randomly] on more than one occasion. Of course, if that does happen, then editing D code probably wouldn't be your biggest priority, so I'm not really making much of a point here...
Jan 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 30 January 2011 10:55:53 Tomek Sowi=C5=84ski wrote:
 Andrej Mitrovic napisa=C5=82:
 If you really want to set up a column limit that *everyone* has to abide
 to, then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge. =20 What is your preferred *maximum* length for a line of D code? (please rep=

 with a number only)

My _preferred_ limit would be no limit but that if your line is getting to = be=20 around 100 - 120 characters, then you should really look at breaking it up.= If I=20 had to have a hard limit, I'd then pick 120 so that it would be rare that I= 'd=20 have to worry about it, and if I had to compromise a bit because others tho= ught=20 that that was too long, then I'd pick 100. Particularly when you get much=20 indentation going on and _especially_ when you have descriptive names, it's= =20 pretty easy to hit 80 characters, and it definitely feels overly limiting.= =20 Personally, I find that it harms code formatting readability to consistentl= y be=20 forced to break up lines due to an 80 character limit. It's especially bad = when=20 you treat it as an absolute, hard limit, and things like the semicolon at t= he=20 end of the line make it so that you hit 81 characters and have to break up = the=20 line. So, if I have any say on the matter, I'd say 100 - 120 characters max if we= 're=20 putting a limit on it. I do feel very strongly about coding style, because = I=20 hate having to twist how I write code to fit another style (though fortunat= ely,=20 my natural style is at least close to how Phobos generally is). However, it= is=20 normal to have to adjust your coding style on some level when working in a= =20 group. I don't want to make a big stink about it either. 80 characters per = line=20 _is_ one of the worst conventions out there IHMO, but if that's what we go = with,=20 then I'll do it. I suspect that the major reason that many of my lines tend to go over 80=20 characters is that I almost always pick very descriptive variable and funct= ion=20 names, and that makes lines longer. It could be that if a programmer who fa= vored=20 short variable names were to write the same code that I typically do, then= =20 they'd almost always stay within 80 characters. In any case, I vote 100 - 120 characters for the limit, and I'd _really_ li= ke to=20 not be restricted to 80 characters, but if that's what I have to do, then t= hat's=20 what I have to do. =2D Jonathan M Davis
Jan 30 2011
prev sibling next sibling parent Max Samukha <maxsamukha spambox.com> writes:
On 01/30/2011 07:17 PM, Andrej Mitrovic wrote:
 The unittest topic is about to get derailed so I want to continue this silly
discussion here.

 Wheres Nick? I want to see the CRT vs LCD discussion heated up again with
Andrei claiming that LCDs are so Godlike but yet claims 80 columns is enough
for everyone.

 80 colums is an artifact of the old age. Just like the preprocessor is an
artifact of the C language. And many other old things are artifacts. There's no
reason to keep these artifacts around anymore.

 A couple of things, Andrei:
 1. 80 colums is way too restrictive. 80 columns wasn't determined by some
scientific method to be a good size for code, it's a product of limitations of
the older generation hardware. Who will run a brand new language like D in a
freakin' Terminal?

 Have you ever heard of the expression "limitations boost creativity"? That can
be considered a good thing, if creativity is what you're after. In code, it's
not. You're looking for clarity in code. 80 column limitations are good for C
obfuscation contests and nothing else. 80 columns means people are going to
*work around* the limit, by using hacks and workarounds to make everything fit
in place. Do you really believe that programmers are going to spend any time at
all thinking: *"oh this line doesn't fit on 80 columns. I should now spend some
time thinking about how to improve and rewrite the design of my code. 80
columns really is the golden ration"*?

 If you want to see more files on the screen, get multiple screens. Is Facebook
running out of money, can't they afford a few monitors for the C++ guru? Yes, I
know you're not allowed to comment on that one. :)

 2. A widescreen aspect ratio causes less eye strain. Wider code means the
same. It doesn't have to stretch all the way to be effective, but 80 columns is
too limiting. Do a Google search and read what people have go say about that.

 3. Less columns means more rows. And generally coders *hate* it when they
can't see a function that fits on a single screen. They hate having to scroll
up and down. This common syntax form is a proof of that:
 void main() {
      void foo() {
           while (true) {
               if (done) {
               }
           }
       }
 }

 I find that unpleasant to read. Not impossible, but unpleasant. I can live
with it though, but if you limit code to 80 limits that's going to become a
mess to read.

 3. It's 2010. Does your GNU/emacs still not support wrapping lines by word
boundaries? Scite had this since the '90s, and that's not even an advanced
editor. Vim supports word wrapping as well. Heck, I'm pretty sure you can
customize it to wrap on whatever boundary you want to (although I'm only
speculating, but pretty much everything in Vim is customizable). You can even
customize how your cursor reacts if it's on an 'artificial' new line, one that
has been wrapped.

 Isn't technology amazing?

 4. Just how many files do you want to edit at a single time on the screen?
We're not really multitasking beings, you know. Try using one of your hands and
do forward circles, as if it were a wheel. With the other one do backward
circles. And now use your foot to draw a circle on the floor. You're end up
looking like a clown in seconds, and a bad one at that.

 Again, people who want to have documentation, and code, and IRC chats in
display buy more computer screens. Why should your code have to suffer if you
really want to do multiple things all at once?

 Bottom line:

 If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on. I don't see why everyone
has to cater to your rules only, regardless of what your professional
experience might be. You're a big contributor to Phobos, but you're not the
only one. I tend to believe that D is (or should be) a community effort, so
please don't hijack D away from the community by forcing your own rules down to
everyone else.

I think there is no need to establish a fixed limit. "Avoid long lines" recommendation in the style guide would be enough.
Jan 31 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
90 as a rule of thumb with some exceptions.
Jan 31 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 30 Jan 2011 14:47:26 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Tomek Sowiński wrote:
 What is your preferred *maximum* length for a line of D code? (please  
 reply with a number only)

6.022e+23

It's amazing that D does so much, and to top it off, it's only ONE LINE OF CODE! -Steve
Jan 31 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 30 Jan 2011 13:55:53 -0500, Tomek Sowiński <just ask.me> wrote:

 Andrej Mitrovic napisał:

 If you really want to set up a column limit that *everyone* has to  
 abide to, then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge. What is your preferred *maximum* length for a line of D code? (please reply with a number only)

80 -Steve
Jan 31 2011
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 01/31/2011 01:18 AM, foobar wrote:

 You completely miss the most important principle - it doesn't matter
 how good and efficient your product is if no one's using it. Phobos
 is a very good product that I for one will never use. Just looking at
 the one huge page for algorithms is enough to discourage many
 people.

From what I've seen, everyone who advocates D2 mentions std.algorithm as one of its main strengths, and never as a liability. I have difficulty reconciling that signal with one opinion relayed anonymously.

I think the main problem is with ddoc. This, from std.algorithm is a f**king mess IMO: Jump to: BoyerMooreFinder EditOp Group NWayUnion OpenRight SetDifference SetIntersection SetSymmetricDifference SetUnion SortOutput Splitter SwapStrategy Uniq Until balancedParens boyerMooreFinder bringToFront canFind completeSort copy count endsWith equal fill filter find findAdjacent findAmong group indexOf initializeAll insert isPartitioned isSorted largestPartialIntersection largestPartialIntersectionWeighted levenshteinDistance levenshteinDistanceAndPath makeIndex map max min minCount minPos mismatch move moveAll moveSome nWayUnion no none partialSort partition reduce remove reverse schwartzSort semistable setDifference setIntersection setSymmetricDifference setUnion skipOver sort splitter stable startsWith substitute swap swapRanges topN topNCopy uninitializedFill uniq unstable until yes (in voice of comic-book guy) Worst navigation bar ever. -Steve
Jan 31 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 31, 2011 11:13:40 Andrei Alexandrescu wrote:
 On 1/31/11 1:07 PM, Steven Schveighoffer wrote:
 On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:
 On 01/31/2011 01:18 AM, foobar wrote:
 You completely miss the most important principle - it doesn't matter
 how good and efficient your product is if no one's using it. Phobos
 is a very good product that I for one will never use. Just looking at
 the one huge page for algorithms is enough to discourage many
 people.

From what I've seen, everyone who advocates D2 mentions std.algorithm as one of its main strengths, and never as a liability. I have difficulty reconciling that signal with one opinion relayed anonymously.

I think the main problem is with ddoc. This, from std.algorithm is a f**king mess IMO: Jump to: BoyerMooreFinder EditOp Group NWayUnion OpenRight SetDifference SetIntersection SetSymmetricDifference SetUnion SortOutput Splitter SwapStrategy Uniq Until balancedParens boyerMooreFinder bringToFront canFind completeSort copy count endsWith equal fill filter find findAdjacent findAmong group indexOf initializeAll insert isPartitioned isSorted largestPartialIntersection largestPartialIntersectionWeighted levenshteinDistance levenshteinDistanceAndPath makeIndex map max min minCount minPos mismatch move moveAll moveSome nWayUnion no none partialSort partition reduce remove reverse schwartzSort semistable setDifference setIntersection setSymmetricDifference setUnion skipOver sort splitter stable startsWith substitute swap swapRanges topN topNCopy uninitializedFill uniq unstable until yes (in voice of comic-book guy) Worst navigation bar ever. -Steve

Let's fix it! I'm thinking along the lines of finding some broad groups, e.g. Searching find until mismatch startsWith ... Sorting sort partialSort partition ... Set operations setUnion setDifference ... ...? We'd eliminate the unstructured "jump to" section and we create the grouping by hand (sigh).

At minimum, it needs to be smarter about user-defined types. The functions for a class or struct should not be grouped with free functions. They should be grouped with the type that they're in. _That_, at least, should be automatable, but it wouldn't help any with std.algorithm, since it's full of free functions (though it would be a big improvement for std.datetime). Unfortunately, you can't really automate the sorting based on usage. Best case, you could create tags on functions that said which grouping they went in, and perhaps that would be well worth doing, but you still have to worry about tagging them. So, on some level, the grouping is going to have to be done by hand. - Jonathan M Davis
Jan 31 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 31 Jan 2011 14:17:50 -0500, Adam Ruppe <destructionator gmail.com>  
wrote:

 Steven Schveighoffer wrote:
 I think the main problem is with ddoc.  This, from std.algorithm is a
 f**king mess IMO:

Note that that is generated through some short javascript in the html header. I remember writing a brief change to that to make it look a lot better (organized into a simple grid) but it seems to be lost now. I'd be willing to redo it though. Need to make a github account to get commit power back, but if there's agreement on changes, I'll make them.

I'm all for it (voice with no authority). I typically ignore that Jump To bar and use the browser's find. I really think ddoc needs to be revamped to do more in this area, along with cross-linking. I really like dil's output (see tangos' docs). -Steve
Jan 31 2011
prev sibling next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Tomek Sowi=C5=84ski napisa=C5=82:

 Actually that's a splendid idea. Let's take it easy. Regardless of that s=

=20
 What is your preferred *maximum* length for a line of D code? (please rep=

=20 Alright, I'm wrapping up this toy study. Two things before the numbers come: - A few respondents gave 2 numbers, one "reasonable", the other "if I real= ly have to". I took the latter (larger) number as I was after maximum lengt= h, something usable as a setting for a repository hook. - 2 respondents said "no limit". I excluded them from computations, albeit= it's a valid answer. 1 respondent answered "1 mole" which I also excluded = as a 22-order-of-magnitude outlier.
 lengths =3D c(80, 80, 110, 120, 80, 80, 100, 100, 120, 110, 90)
 summary(lengths)

80.00 80.00 100.00 97.27 110.00 120.00=20
 sd(lengths)  # standard deviation

 quantile(lengths, c(.1, .25, .5, .75, .9))

80 80 100 110 120=20
 library(moments)
 skewness(lengths)  # take with a grain of salt, little data

 length(lengths) # count

--=20 Tomek
Jan 31 2011
prev sibling next sibling parent Tomek =?UTF-8?B?U293acWEc2tp?= <just ask.me> writes:
Tomek Sowi=C5=84ski napisa=C5=82:

 Alright, I'm wrapping up this toy study. Two things before the numbers co=

=20
  - A few respondents gave 2 numbers, one "reasonable", the other "if I re=

gth, something usable as a setting for a repository hook.
  - 2 respondents said "no limit". I excluded them from computations, albe=

d as a 22-order-of-magnitude outlier. Steven came in late with his datapoint, so once again:
 lengths =3D c(80, 80, 110, 120, 80, 80, 100, 100, 120, 110, 90, 80)
=20
 summary(lengths)

80.00 80.00 95.00 95.83 110.00 120.00=20
=20
 sd(lengths)  # standard deviation

=20
 quantile(lengths, c(.1, .25, .5, .75, .9))

80 80 95 110 119=20
=20
 skewness(lengths)  # take with a grain of salt, little data

=20
 length(lengths) # count

--=20 Tomek
Jan 31 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/31/2011 06:54 PM, Ulrik Mikaelsson wrote:

I share most of Ulrik mentions.

 I'm not sure whether text-books and program-code are really comparable
 in this respect.

Even if they were (which is imo absurd to state), what would count is not column number, but content length -- which is different in the case of code due to indentation. Thus, to get 80-char max line length, we'd have to allow up to, say, column #100 ;-) Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/30/2011 07:55 PM, Tomek Sowiński wrote:
 Andrej Mitrovic napisał:

 If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on.

Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge. What is your preferred *maximum* length for a line of D code? (please reply with a number only)

99 Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 31 Jan 2011 15:38:50 -0500, Adam Ruppe <destructionator gmail.com>  
wrote:

 Steven Schveighoffer wrote:
 I'm all for it (voice with no authority).

Here it is with the brief css change to put it in a grid: http://arsdnet.net/d-web-site/std_algorithm.html It's a very small change that, to me, makes a huge difference.

It does help, but I was kind of hoping for something that shows the structure. For example I see 'OpenRight' is an enum, and 'yes' is a member of that enum, but they are listed in random order (OpenRight coming at the beginning and yes coming at the end). This is still pretty much fail.
 I really think ddoc needs to be revamped to do more in this area,
 along with cross-linking.

Agreed. Though, if we can't change the compiler, we could do this with a macro too.

I think the compiler needs to change. See dil for an example of how much better it could be. http://dl.dropbox.com/u/17101773/doc/dil/main.html Also I think before descent was abandoned, it added cross-linking, but I'm not sure what state that is in (or if it went over to DDT). -Steve
Jan 31 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 01/31/2011 08:32 PM, Jonathan M Davis wrote:
 At minimum, it needs to be smarter about user-defined types. The functions for
a
 class or struct should not be grouped with free functions. They should be
 grouped with the type that they're in._That_, at least, should be automatable,

Isn't that's what namespaces are for? A big advantage of OO-like coding (or custom namespaces) for std modules.
 but it wouldn't help any with std.algorithm, since it's full of free functions
 (though it would be a big improvement for std.datetime).

See above. Why aren't many algorithms implemented in the modules defining what they operate on? Sure, "free" algorithms precisely are meant ot be generic. But in most cases there is, or could (should) be, a top-level type. In particular, don't many algos work on ranges? Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 31, 2011 13:25:16 spir wrote:
 On 01/31/2011 08:32 PM, Jonathan M Davis wrote:
 At minimum, it needs to be smarter about user-defined types. The
 functions for a class or struct should not be grouped with free
 functions. They should be grouped with the type that they're in._That_,
 at least, should be automatable,

Isn't that's what namespaces are for? A big advantage of OO-like coding (or custom namespaces) for std modules.
 but it wouldn't help any with std.algorithm, since it's full of free
 functions (though it would be a big improvement for std.datetime).

See above. Why aren't many algorithms implemented in the modules defining what they operate on? Sure, "free" algorithms precisely are meant ot be generic. But in most cases there is, or could (should) be, a top-level type. In particular, don't many algos work on ranges?

Classes and structs already group functions naturally, and that grouping needs to be evident in the generated ddoc pages. As for free functions, there's a huge difference between namespacing functions and grouping them in documentation. Namespacing was introduced in C++ to avoid name collisions. D uses modules as namespaces and also allows you to avoid name collisions. But that doesn't mean that there isn't value or necessity in grouping functions within a namespace or module. If there aren't all that many functions in a module, then you don't really need to group them, but when you get as many functions as you do in std.algorithm, it can definitely be useful. std.algorithm doesn't have problems with name collisions and doesn't need to be broken up, but it _is_ large enough that grouping some of its documentation would be useful. And simply grouping the links to the functions at the top would be a definite improvement. Regardless, it's a separate issue from namespacing. - Jonathan M Davis
Jan 31 2011
prev sibling next sibling parent Ulrik Mikaelsson <ulrik.mikaelsson gmail.com> writes:
2011/1/31 spir <denis.spir gmail.com>:
 On 01/30/2011 09:32 PM, "J=C3=A9r=C3=B4me M. Berger" wrote:
 =C2=A0 =C2=A0 =C2=A0 =C2=A0Do you know of any editor that can word wrap =


 indentation*? Any editor I know will wrap to the first column, which
 renders indentation pointless in the presence of long lines...

Yop, geany :-) http://en.wikipedia.org/wiki/Geany

Kate does this too, and clearly marks out it's an auto-wrapped line http://imagebin.org/135452 Personally, I'd like it to find the starting-parenthesis of the call and indent to it, though.
Jan 31 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 31 Jan 2011 18:08:53 -0500, Adam Ruppe <destructionator gmail.com>  
wrote:

 Steven Schveighoffer wrote:
 It does help, but I was kind of hoping for something that shows the
 structure.

Those relationships are in the HTML too.... try it now: http://arsdnet.net/d-web-site/std_algorithm.html (I know it needs some work still, I'm just sick of Javascript after spending 20 minutes tracking down a bug caused by me using the same variable name twice! Gah! And wow do I miss foreach.)

Yes, it's in the right direction, but it does need work. BTW, foreach is available, but you can't use it on arrays (HAHAHAHA!) it's one of the reasons I use objects in JS most of the time instead of arrays: for(key in obj) { var elem = obj[key]; /* use elem */ } of course, I'd only recommend this on objects you have used as arrays. What I mean by that is, you don't have any methods or prototypes, because those will also be iterated. https://developer.mozilla.org/en/JavaScript/Reference/Statements/for...in -Steve
Feb 01 2011