Re: (Was: On 80 columns should (not) be enough for everyone)

[Bruno Medeiros]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

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

var foo = [bar, baz];
foo.forEach(function (elem) { 
elem.doSomthing(); 
});

Available since version 1.6

Re: (Was: On 80 columns should (not) be enough for everyone)

[Steven Schveighoffer]

On Mon, 31 Jan 2011 18:08:53 -0500, Adam Ruppe   
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

Re: (Was: On 80 columns should (not) be enough for everyone)

[bearophile]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Adam Ruppe]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Daniel Gibson]

Am 31.01.2011 22:06, schrieb Steven Schveighoffer:
> On Mon, 31 Jan 2011 15:38:50 -0500, Adam Ruppe  
> 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

Re: (Was: On 80 columns should (not) be enough for everyone)

[spir]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Jérôme M. Berger]

Walter Bright wrote:
> 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.

My point exactly.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: (Was: On 80 columns should (not) be enough for everyone)

[Jérôme M. Berger]

spir wrote:
> On 01/30/2011 09:32 PM, "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...
>>
>> Jerome
> 
> Yop, geany :-) http://en.wikipedia.org/wiki/Geany
> 
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.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: (Was: On 80 columns should (not) be enough for everyone)

[Jérôme M. Berger]

Michel Fortin wrote:
> On 2011-01-30 15:32:45 -0500, "Jérôme M. Berger"  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.
> 
So that makes one very platform-specific editor.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: (Was: On 80 columns should (not) be enough for everyone)

[Ulrik Mikaelsson]

2011/1/31 spir :
> On 01/30/2011 09:32 PM, "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...
>
> 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.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Jonathan M Davis]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[spir]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Steven Schveighoffer]

On Mon, 31 Jan 2011 15:38:50 -0500, Adam Ruppe   
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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Adam Ruppe]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

Andrei Alexandrescu Wrote:

> On 1/31/11 1:07 PM, Steven Schveighoffer wrote:
> > On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu
> >  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 ...
> 
> ...?

Excellent!

> 
> We'd eliminate the unstructured "jump to" section and we create the 
> grouping by hand (sigh).
> 

You just got my hopes up in the previous paragraph. :(

How about converting algorithm.d into a package and make those "groups" modules 
in this package? 
I'm sure this can be done with the help of some aliases for backwards 
compatibility

> 
> Andrei

Re: (Was: On 80 columns should (not) be enough for everyone)

[Adam Ruppe]

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.

Re: (Was: On 80 columns should (not) be enough for everyone)

[spir]

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.

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.


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

Re: (Was: On 80 columns should (not) be enough for everyone)

[spir]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[spir]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[spir]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[so]

Java is an excellent example of many very usable APIs, meaning that it  
very easy to both read Java code and understand what the functions do  
and write code that's just as readable *without* RTFM.


This one i don't understand. (seems i fail to understand many things  
nowadays!).
I have read the C++ standard library manuals many times, but still i find  
myself going back and reading it again occasionally.

Probably like my memory, STL also doesn't have the best of qualities.
But i have to ask, why would you target those that don't RTFM? It seems to  
me every language mainly targeting this kind of audience.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Michel Fortin]

On 2011-01-31 14:13:40 -0500, Andrei Alexandrescu 
 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:



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:





--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: (Was: On 80 columns should (not) be enough for everyone)

[Andrei Alexandrescu]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Steven Schveighoffer]

On Mon, 31 Jan 2011 14:17:50 -0500, Adam Ruppe   
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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Jonathan M Davis]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Adam Ruppe]

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.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Walter Bright]

foobar wrote:

Walter Bright Wrote:


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.


My complaint is not about the implementation itself as it is about it's API.
 Java is an excellent example of many very usable APIs, meaning that it very
easy to both read Java code and understand what the functions do and write
code that's just as readable *without* RTFM.



Please take a Phobos module or a function, and rewrite its API to demonstrate 
your point.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Adam Ruppe]

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.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Andrei Alexandrescu]

On 1/31/11 1:07 PM, Steven Schveighoffer wrote:

On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu
 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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Steven Schveighoffer]

On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu  
 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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Steven Schveighoffer]

On Sun, 30 Jan 2011 13:55:53 -0500, 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

-Steve

Re: (Was: On 80 columns should (not) be enough for everyone)

[Steven Schveighoffer]

On Sun, 30 Jan 2011 14:47:26 -0500, Walter Bright  
 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

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

Walter Bright Wrote:

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

My complaint is not about the implementation itself as it is about it's API. 
Java is an excellent example of many very usable APIs, meaning that it very 
easy to both read Java code and understand what the functions do and write code 
that's just as readable *without* RTFM. 

When I learned C++ in university, my notoriously demanding professor said that 
code should be self documenting and that comments are meant to compensate for 
poorly written code. 

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

Andrei Alexandrescu Wrote:

> On 01/31/2011 01:18 AM, foobar wrote:
> > Andrei Alexandrescu Wrote:
> >
> >> == Quote from Walter Bright (newshou...@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.
> >>> I think you've mixed up libraries with languages. Please rephrase so we 
> >>> know
> >>> 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.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Ulrik Mikaelsson]

90 as a rule of thumb with some exceptions.

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

Michel Fortin Wrote:

> On 2011-01-31 02:18:26 -0500, foobar  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.for...@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  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. 

Re: (Was: On 80 columns should (not) be enough for everyone)

[Andrei Alexandrescu]

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

Andrei Alexandrescu Wrote:


== Quote from Walter Bright (newshou...@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.

I think you've mixed up libraries with languages. Please rephrase so we know
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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Michel Fortin]

On 2011-01-31 02:18:26 -0500, foobar  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.for...@michelf.com
http://michelf.com/

Re: (Was: On 80 columns should (not) be enough for everyone)

[Don]

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)


100 (8 levels of 4-space indent, + 65 characters).
Second preference: 110.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Walter Bright]

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.

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

Andrei Alexandrescu Wrote:

> == Quote from Walter Bright (newshou...@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.
> > I think you've mixed up libraries with languages. Please rephrase so we know
> > 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.

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

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? 

Re: (Was: On 80 columns should (not) be enough for everyone)

[Jonathan M Davis]

On Sunday 30 January 2011 10:55:53 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_ limit would be no limit but that if your line is getting to be 
around 100 - 120 characters, then you should really look at breaking it up. If 
I 
had to have a hard limit, I'd then pick 120 so that it would be rare that I'd 
have to worry about it, and if I had to compromise a bit because others thought 
that that was too long, then I'd pick 100. Particularly when you get much 
indentation going on and _especially_ when you have descriptive names, it's 
pretty easy to hit 80 characters, and it definitely feels overly limiting. 
Personally, I find that it harms code formatting readability to consistently be 
forced to break up lines due to an 80 character limit. It's especially bad when 
you treat it as an absolute, hard limit, and things like the semicolon at the 
end of the line make it so that you hit 81 characters and have to break up the 
line.

So, if I have any say on the matter, I'd say 100 - 120 characters max if we're 
putting a limit on it. I do feel very strongly about coding style, because I 
hate having to twist how I write code to fit another style (though fortunately, 
my natural style is at least close to how Phobos generally is). However, it is 
normal to have to adjust your coding style on some level when working in a 
group. I don't want to make a big stink about it either. 80 characters per line 
_is_ one of the worst conventions out there IHMO, but if that's what we go 
with, 
then I'll do it.

I suspect that the major reason that many of my lines tend to go over 80 
characters is that I almost always pick very descriptive variable and function 
names, and that makes lines longer. It could be that if a programmer who 
favored 
short variable names were to write the same code that I typically do, then 
they'd almost always stay within 80 characters.

In any case, I vote 100 - 120 characters for the limit, and I'd _really_ like 
to 
not be restricted to 80 characters, but if that's what I have to do, then 
that's 
what I have to do.

- Jonathan M Davis

Re: (Was: On 80 columns should (not) be enough for everyone)

[Andrei Alexandrescu]

== Quote from Walter Bright (newshou...@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.
> I think you've mixed up libraries with languages. Please rephrase so we know
> 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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Walter Bright]

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.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Walter Bright]

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.

Re: (Was: On 80 columns should (not) be enough for everyone)

[Michel Fortin]

On 2011-01-30 15:32:45 -0500, "Jérôme M. Berger"  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.for...@michelf.com
http://michelf.com/

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

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. 

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

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.
> >> 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. 
> 
>   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:jeber...@free.fr
> http://jeberger.free.fr
> Jabber: jeber...@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").

Re: (Was: On 80 columns should (not) be enough for everyone)

[Jim]

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???

Re: (Was: On 80 columns should (not) be enough for everyone)

[Daniel Gibson]

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)

Re: (Was: On 80 columns should (not) be enough for everyone)

[Tomek Sowiński]

Walter Bright napisał:

> > What is your preferred *maximum* length for a line of D code? (please reply 
> > with a number only)  
> 
> 6.022e+23

That's a whole mole of code! ;-)

-- 
Tomek

Re: (Was: On 80 columns should (not) be enough for everyone)

[Jérôme M. Berger]

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

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:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: (Was: On 80 columns should (not) be enough for everyone)

[so]

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.

Re: (Was: On 80 columns should (not) be enough for everyone)

[David Nadlinger]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[foobar]

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. 

Re: (Was: On 80 columns should (not) be enough for everyone)

[Simen kjaeraas]

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 columns of code. Indents may change that slightly.


--
Simen

Re: (Was: On 80 columns should (not) be enough for everyone)

[Walter Bright]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Tomek Sowiński]

Tomek Sowiński napisał:

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

120.

-- 
Tomek

Re: (Was: On 80 columns should (not) be enough for everyone)

[Sean Kelly]

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

110

Re: (Was: On 80 columns should (not) be enough for everyone)

[Andrei Alexandrescu]

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

Re: (Was: On 80 columns should (not) be enough for everyone)

[Jérôme M. Berger]

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)
> 
I use 70.

May occasionally be extended to 80 if there is no easy way to
reflow the code below 70, but never above 80.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature