subject:"\"On 80 columns should \\\(not\\\) be enough for everyone\""


Ulrik Mikaelsson wrote:

I might be wrong, I hardly ever get to touch things that low-level,
unfortunately.

However, I think the DSP:s included in most STB:s are severely limited
in how much you can twist them. AFAIU, that's one quiet important
aspect of the whole HTML5 video-codec debacle. I.E. in the boxes I
work with, the entire video-processing-chain is done in one pipe-line,
separated from the CPU almost directly at the network-interface, and
color-keyed back with other graphics in the very last rendering-step.
(Much as the old Voodoo2-cards worked.)


From the economics stand-point, there's a HUGE cost-focus on them, so

every chance of removing costs from hardware is taken.  Every dollar
saved on hardware is roughly a dollar on the bottom-line, and in the
volumes STB:s sell, that's millions of dollars. Sure, software costs
might go up, but not likely by millons of dollars yearly. I.E. even if
you CAN use the DSP-components to post-process audio, I would not be
surprised to learn it hasn't got the power to do it simultaneously
with video-playback.

Again, I don't work low-level enough to tell for sure, and TiVo might
spend a lot more on the hardware than I'm used to, but hardware
limitations in this industry is a very real challenge, especially for
things like post-processing. I too would love 2X playback with working
audio though. :)



The real money for Tivo is not the box cost, but the recurring subscription 
revenue. Even better if this idea is nontrivial to implement, as that would give 
the first mover an exclusive.

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

2011-01-31 Thread 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)

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)

2011-01-31 Thread 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: Audio time-compression (Was: On 80 columns should (not) be enough for everyone)

I might be wrong, I hardly ever get to touch things that low-level,
unfortunately.

However, I think the DSP:s included in most STB:s are severely limited
in how much you can twist them. AFAIU, that's one quiet important
aspect of the whole HTML5 video-codec debacle. I.E. in the boxes I
work with, the entire video-processing-chain is done in one pipe-line,
separated from the CPU almost directly at the network-interface, and
color-keyed back with other graphics in the very last rendering-step.
(Much as the old Voodoo2-cards worked.)

>From the economics stand-point, there's a HUGE cost-focus on them, so
every chance of removing costs from hardware is taken.  Every dollar
saved on hardware is roughly a dollar on the bottom-line, and in the
volumes STB:s sell, that's millions of dollars. Sure, software costs
might go up, but not likely by millons of dollars yearly. I.E. even if
you CAN use the DSP-components to post-process audio, I would not be
surprised to learn it hasn't got the power to do it simultaneously
with video-playback.

Again, I don't work low-level enough to tell for sure, and TiVo might
spend a lot more on the hardware than I'm used to, but hardware
limitations in this industry is a very real challenge, especially for
things like post-processing. I too would love 2X playback with working
audio though. :)

2011/1/31 Walter Bright :
> Ulrik Mikaelsson wrote:
>>
>> Of course, I don't know what HW the Tivo is using, perhaps they're just
>> lazy. :)
>
> I thought that DSP's were programmable.
>

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


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)

2011-01-31 Thread 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)

2011-01-31 Thread 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)

2011-01-31 Thread 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)

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: Audio time-compression (Was: On 80 columns should (not) be enough for everyone)


Ulrik Mikaelsson wrote:

Of course, I don't know what HW the Tivo is using, perhaps they're just lazy. :)


I thought that DSP's were programmable.

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

2011-01-31 Thread 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)


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)

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: On 80 columns should (not) be enough for everyone


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

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

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

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)

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)


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)


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)


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)


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: On 80 columns should (not) be enough for everyone


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

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


JMRyan wrote:

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

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

2011-01-31 Thread bearophile

Russel Winder:

> What say we cut the agist crap.

There are also armies of programmers with myopia :-)

Bye,
bearophile

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


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

Re: Audio time-compression (Was: On 80 columns should (not) be enough for everyone)

2011/1/31 Walter Bright :
>> I think the reason I.E. YouTube and Tivo don't do it is that AFAIU, it
>> is fairly CPU-consuming (FFT back and forth?) In the TiVo-case, my
>> guess is nobody paid for the hardware, and in the YouTube-case I doubt
>> neither Flash nor JavaScript will enable the performance required.
>> Perhaps it can be done browser-dependently with HTML5.
>
> I think the problem is it either never occurred to Tivo or Youtube, or they
> don't care about it. When I shut off my Tivo service, I told them that such
> a feature would entice me to keep it. But I seriously doubt they transmitted
> my idea to the right people.

Perhaps, although I develop for STB:s at work, and I know how
amazingly price-pressed the hardware is. Seriously, it's designed to
show live HD, but the developers manual for one manufacturer, there's
a performance-warning about animated GIF:s (not kidding).

My guess is, the only FFT the box can manage is the one hard-coded in
the video-chip, which can't easily be exploited for other means.

Of course, I don't know what HW the Tivo is using, perhaps they're just lazy. :)

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

2011-01-31 Thread 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)

2011-01-31 Thread 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)


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)

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: Audio time-compression (Was: On 80 columns should (not) be enough for everyone)


Ulrik Mikaelsson wrote:

2011/1/30 Walter Bright :

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

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 KNEW I wasn't alone at this. My S.O. usually just rolls her eyes
when I do this. (Tip: VLC does it for at least double-speed)

I think the reason I.E. YouTube and Tivo don't do it is that AFAIU, it
is fairly CPU-consuming (FFT back and forth?) In the TiVo-case, my
guess is nobody paid for the hardware, and in the YouTube-case I doubt
neither Flash nor JavaScript will enable the performance required.
Perhaps it can be done browser-dependently with HTML5.


I think the problem is it either never occurred to Tivo or Youtube, or they 
don't care about it. When I shut off my Tivo service, I told them that such a 
feature would entice me to keep it. But I seriously doubt they transmitted my 
idea to the right people.




Now, what we need is the audio-equivalent of this:
http://www.youtube.com/watch?v=6NcIJXTlugc


That is an impressive algorithm!

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

2011-01-31 Thread JMRyan

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

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

2011-01-31 Thread 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)

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)


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)

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)


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)

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: On 80 columns should (not) be enough for everyone

2011-01-31 Thread Russel Winder

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. :-)
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

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


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)

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)

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: On 80 columns should (not) be enough for everyone

2011/1/31 Andrei Alexandrescu :
> 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> 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.

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.pdf)
> I frequently inserted line breaks even when not technically necessary, check
> 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 = 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:
>>  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.
Actually, writing and reading about it got me thinking. I think the
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.

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

2011-01-31 Thread bearophile

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

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

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)

90 as a rule of thumb with some exceptions.

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

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

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

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: On 80 columns should (not) be enough for everyone

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

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


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

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


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

Audio time-compression (Was: On 80 columns should (not) be enough for everyone)

2011/1/30 Walter Bright :
> 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! G.
>
> 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 KNEW I wasn't alone at this. My S.O. usually just rolls her eyes
when I do this. (Tip: VLC does it for at least double-speed)

I think the reason I.E. YouTube and Tivo don't do it is that AFAIU, it
is fairly CPU-consuming (FFT back and forth?) In the TiVo-case, my
guess is nobody paid for the hardware, and in the YouTube-case I doubt
neither Flash nor JavaScript will enable the performance required.
Perhaps it can be done browser-dependently with HTML5.

Now, what we need is the audio-equivalent of this:
http://www.youtube.com/watch?v=6NcIJXTlugc

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

2011-01-31 Thread 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: On 80 columns should (not) be enough for everyone

2011-01-31 Thread Nick Sabalausky

"Daniel Gibson"  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...

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

2011-01-31 Thread Daniel Gibson


Am 31.01.2011 00:17, schrieb Stewart Gordon:

On 30/01/2011 17:17, Andrej Mitrovic wrote:


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

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

2011-01-31 Thread Max Samukha

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.

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

2011-01-31 Thread 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: On 80 columns should (not) be enough for everyone

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.

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


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)

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)

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: On 80 columns should (not) be enough for everyone

"Jeff Nowakowski"  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.

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

2011-01-30 Thread Sean Kelly

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.

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

2011-01-30 Thread 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)

2011-01-30 Thread 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: On 80 columns should (not) be enough for everyone

2011-01-30 Thread Stewart Gordon


On 30/01/2011 17:17, Andrej Mitrovic wrote:


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?




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?




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.

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

2011-01-30 Thread Jeff Nowakowski


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.

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


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.

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

"Walter Bright"  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! G.
>
> 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.

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

2011-01-30 Thread bearophile

Walter:

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

I sometimes see&hear documentaries at 140-160% speed.

Bye,
bearophile

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

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

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.

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


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)


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)

2011-01-30 Thread 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: On 80 columns should (not) be enough for everyone)

"Tomek Sowinski"  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.

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

"Andrej Mitrovic"  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 wrappi

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

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)

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)

2011-01-30 Thread 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)

2011-01-30 Thread 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)

2011-01-30 Thread 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)

2011-01-30 Thread 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)

2011-01-30 Thread 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)

2011-01-30 Thread 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)

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: On 80 columns should (not) be enough for everyone

2011-01-30 Thread Andrei Alexandrescu


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

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

2011-01-30 Thread 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: On 80 columns should (not) be enough for everyone

2011-01-30 Thread Tomek Sowiński

Sean Kelly napisał:

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

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

-- 
Tomek

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