Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Am Sonntag 26 April 2009 04:38:42 schrieb Jason Dusek: As always, opinions on aesthetics differ slightly, but overall, everyone seems to mostly agree... Eh? Since when did they mostly agree? The 200 column example we've seen brought out a lot of disagreement. Well, to be picky, Bob (Thomas Davie) wrote: As always, opinions on aesthetics differ slightly, but overall, everyone seems to mostly agree that we should try to keep lines short where possible, but lengthen then when needed. And the disagreement is about whether it's needed to lengthen such lines. While I can easily imagine the need for 100-character lines to improve readability, 200 is way beyond my imagination :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
2009/04/26 Daniel Fischer daniel.is.fisc...@web.de: While I can easily imagine the need for 100-character lines to improve readability, 200 is way beyond my imagination :) It's not beyond someone's imagination, though. Would you like that line to land on your screen? If we do not preserve the old ways, it'll be anarchy all the way down. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Am Sonntag 26 April 2009 23:08:41 schrieb Jason Dusek: 2009/04/26 Daniel Fischer daniel.is.fisc...@web.de: While I can easily imagine the need for 100-character lines to improve readability, 200 is way beyond my imagination :) It's not beyond someone's imagination, though. Would you like that line to land on your screen? Nope. I like my lines short. If we do not preserve the old ways, it'll be anarchy all the way down. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
2009/04/26 Miguel miguelim...@yandex.ru: 2009/04/26 Jason Dusek jason.du...@gmail.com: If we do not preserve the old ways, it'll be anarchy all the way down. How exactly are you going to preserve old ways? Whenever are we are presented with the a question of correct conduct, we must re-affirm our commitment to the practices handed down to us. When we revisit this question -- Should we maintain the 80 column limit? -- it as an opporunity to affirm this practice. Through this exercize, we perenially renew our faith in this convention, accepting the bonds of convention. This ritual -- the line-length reminding ritual -- is played out across all programming communities several times a year. Everyone says the same things. Then they all go away with the 80 column limit re-established in their minds. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 8:59 pm, Miguel Mitrofanov wrote: Something like newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Nobody would be really interested in deriving clause, because it basically says derive everything possible. Therefore, it seems pointless to move it to another line. For what it's worth, my personal Haskell style lines up data T = C1 ... | ... | Cn ... deriving (...) so I'd have this as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) where the longest line is 86 columns. I would regard putting the 'deriving' clause on the same line as 'newtype' as obfuscatory except perhaps in the most trivial case. I wouldn't be at all happy with 86 columns, so I'd shrink it further. But this is progress. We've moved from is a 200-column line reasonable to is attaching an already long deriving clause to the end of the previous line on the grounds that nobody will be interested in it good layout style or not, and why/why not? I'll note there that the costs and benefits are, as usual, asymmetric. Someone who already understands what this is all about, in particular someone who knows what everything possible is, will be helped by hiding irrelevant detail (if this _is_ a way to hide it). Someone other than the author may very well not know this, and this deriving clause may even be the way that they learn it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Am Samstag 25 April 2009 08:48:16 schrieb Thomas Davie: On 24 Apr 2009, at 14:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Sure... arrow :: forall (~) b c d e. ( Arrow (~), Show (d ~ e), Show (c ~ d), Show (b ~ c), Show b, Show c, Show d, Show e, Arbitrary (d ~ e), Arbitrary (c ~ d), Arbitrary (b ~ c), Arbitrary b, Arbitrary c, Arbitrary d, Arbitrary e, EqProp (b ~ e), EqProp (b ~ d), EqProp ((b,d) ~ c), EqProp ((b,d) ~ (c,d)), EqProp ((b,e) ~ (d,e)), EqProp ((b,d) ~ (c,e)), EqProp b, EqProp c, EqProp d, EqProp e) = b ~ (c,d,e) - TestBatch . In all seriousness though, that one got broken, but I do find that I occasionally have lines around 100 characters that just look silly if I break them, this is a good example: filterNonRoots (GCase e bs) = filter ((/= e) ^()^ (not . (`elem` bs))) Not that I'd deny that it can sometimes be more readable to have longer lines*, but in this example, would filterNonRoots (GCase e bs) = filter ((/= e) ^()^ (not . (`elem` bs))) be any less readable in your opinion? [*] but I think 200 characters is beyond the limit Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Something like newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Nobody would be really interested in deriving clause, because it basically says derive everything possible. Therefore, it seems pointless to move it to another line. On 24 Apr 2009, at 16:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Loup ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 10:51, Daniel Fischer wrote: Am Samstag 25 April 2009 08:48:16 schrieb Thomas Davie: On 24 Apr 2009, at 14:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Sure... arrow :: forall (~) b c d e. ( Arrow (~), Show (d ~ e), Show (c ~ d), Show (b ~ c), Show b, Show c, Show d, Show e, Arbitrary (d ~ e), Arbitrary (c ~ d), Arbitrary (b ~ c), Arbitrary b, Arbitrary c, Arbitrary d, Arbitrary e, EqProp (b ~ e), EqProp (b ~ d), EqProp ((b,d) ~ c), EqProp ((b,d) ~ (c,d)), EqProp ((b,e) ~ (d,e)), EqProp ((b,d) ~ (c,e)), EqProp b, EqProp c, EqProp d, EqProp e) = b ~ (c,d,e) - TestBatch . In all seriousness though, that one got broken, but I do find that I occasionally have lines around 100 characters that just look silly if I break them, this is a good example: filterNonRoots (GCase e bs) = filter ((/= e) ^()^ (not . (`elem` bs))) Not that I'd deny that it can sometimes be more readable to have longer lines*, but in this example, would filterNonRoots (GCase e bs) = filter ((/= e) ^()^ (not . (`elem` bs))) be any less readable in your opinion? Yes – this particular line is mixed in with several other pattern matches, each of which has a similar form, laying it out on one line lets you see the similarities and differences, laying it out on two lines creates visual noise. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Miguel Mitrofanov miguelim...@yandex.ru writes: On 24 Apr 2009, at 16:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Something like newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Nobody would be really interested in deriving clause, because it basically says derive everything possible. Therefore, it seems pointless to move it to another line. You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) It is just so much clearer than a one liner. I'd like to hear what people think about it, comparing to newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) (Yes, I rewrote it so it actually is in one line. You email editor clearly fooled you.) P.S. I moved your reply down below the citation to make this email easier to understand. -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 18:34, Xiao-Yong Jin wrote: Miguel Mitrofanov miguelim...@yandex.ru writes: On 24 Apr 2009, at 16:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Something like newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Nobody would be really interested in deriving clause, because it basically says derive everything possible. Therefore, it seems pointless to move it to another line. You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) Well, first impression I've got from this was that FirstTransformer, SecondTransformer and the rest are on the same level: newtype MyCool Monad = MyCoolMonad (FirstTransformer) (SecondTransformer) (ThirdTransformer Whatever) which is very confusing. deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) A lot of unnecessary information distracting the reader. It's better kept somewhere else, where it doesn't attract too much attention - like in the end of the line. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Am Samstag 25 April 2009 16:44:45 schrieb Miguel Mitrofanov: On 25 Apr 2009, at 18:34, Xiao-Yong Jin wrote: Miguel Mitrofanov miguelim...@yandex.ru writes: On 24 Apr 2009, at 16:37, Loup Vaillant wrote: 2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Something like newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Nobody would be really interested in deriving clause, because it basically says derive everything possible. Therefore, it seems pointless to move it to another line. You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) Well, first impression I've got from this was that FirstTransformer, SecondTransformer and the rest are on the same level: newtype MyCool Monad = MyCoolMonad (FirstTransformer) (SecondTransformer) (ThirdTransformer Whatever) which is very confusing. You have a point there. If split over several lines, I'd recommend each line indented further than the previous to indicate nesting: newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) But I wouldn't really prefer that over having it on one line. deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) A lot of unnecessary information distracting the reader. It's better kept somewhere else, where it doesn't attract too much attention - like in the end of the line. There I have to disagree. IMO, having the deriving clause on the same line (unless it's a very short one) obscures the code and makes it *much* harder to read. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On Sat, Apr 25, 2009 at 10:34:05AM -0400, Xiao-Yong Jin wrote: You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Doubtlessly, this is better than a one-liner, and I don't write lisp :). However I'd change the deriving clause and write it as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) I don't think deriving clauses are unimportant and I like to see them. Also, I don't mistake the transformers as different parameters because of the parenthesis and because they're transformers, reading their names gives you a clue of how they may be used. Whoever knows transformers expect to see this kind of nesting. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 19:08, Felipe Lessa wrote: On Sat, Apr 25, 2009 at 10:34:05AM -0400, Xiao-Yong Jin wrote: You don't write lisp, do you? Or probably it is just me. But I would prefer to write the line as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) Doubtlessly, this is better than a one-liner, and I don't write lisp :). Doubtfully, after reading a message from Daniel Fischer. Also, I don't mistake the transformers as different parameters because of the parenthesis You should really try Lisp. In my opinion, parenthesis are a kind of noise - too small, too many. and because they're transformers, reading their names gives you a clue of how they may be used. So... you really think transformers CAN'T be parameters? You're going to be surprised. Whoever knows transformers expect to see this kind of nesting. Whoever knows Haskell - no offense - expects to see both. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On Sat, Apr 25, 2009 at 07:38:59PM +0400, Miguel Mitrofanov wrote:
Also, I don't mistake the transformers as different
parameters because of the parenthesis
You should really try Lisp. In my opinion, parenthesis are a kind of
noise - too small, too many.
I don't try lisp because I don't like a lot of parenthesis as
well. However the problem isn't with parenthesis, it is with
their excessive usage. In this case they're helpful, IMO.
and because they're transformers, reading their names gives
you a clue of how they may be used.
So... you really think transformers CAN'T be parameters? You're going to
be surprised.
[...]
Whoever knows Haskell - no offense - expects to see both.
Haha :), so giving a clue of how they may be used means
meaning that they will always be fully applied now? Sorry, but
don't go hostile on me putting words on my mouth.
How do you *usually* see transformers being used? Questions of
how you read something in a glance have to touch the question of
how much you *expect* to see something. So, if I expect to see
data D = Constructor Something
Other
Here
or
data D = Constructor {field1 :: Something
,field2 :: Other
,field3 :: Here}
then I can misread
data D = Constructor (Something
(Other
Here))
This is Daniel's point: you misread it because you expected
something else. So, was Daniel trying to say that you can't have
one field on multiple lines? Not at all. When I see two or more
transformers, I expect to see them nested, and probably most
other people have the same expectations.
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 19:59, Felipe Lessa wrote: On Sat, Apr 25, 2009 at 07:38:59PM +0400, Miguel Mitrofanov wrote: Also, I don't mistake the transformers as different parameters because of the parenthesis You should really try Lisp. In my opinion, parenthesis are a kind of noise - too small, too many. I don't try lisp because I don't like a lot of parenthesis as well. However the problem isn't with parenthesis, it is with their excessive usage. In this case they're helpful, IMO. Of course they are. My point was not that everything should be clear without parenthesis, but that the user shouldn't have false impressions - the notation should either give a true impression (like Daniel suggested, with every other line indented more than the previous one - though I don't like it), or not to give any impression at all, so that the reader would be forced to read the noise. and because they're transformers, reading their names gives you a clue of how they may be used. So... you really think transformers CAN'T be parameters? You're going to be surprised. [...] Whoever knows Haskell - no offense - expects to see both. Haha :), so giving a clue of how they may be used means meaning that they will always be fully applied now? Well, then, is that ALWAYS so obvious that this particular name denotes a transformer? Of course, if it's not a standard transformer like StateT or WriterT, but something written by the same guy who invented this MyCoolMonad type? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
There will always be some people who prefer longer lines. The real issue is, how do we deal with the fundamental disagreement here? It's not like we can have both. Also those people who like long lines -- will they all agree to a long line length? -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 25 Apr 2009, at 21:09, Jason Dusek wrote: There will always be some people who prefer longer lines. The real issue is, how do we deal with the fundamental disagreement here? It's not like we can have both. Also those people who like long lines -- will they all agree to a long line length? Is there a fundamental disagreement here? There are those who are driven by an archaic standard from the width of the terminal screen, and there are those who are driven by the aesthetics of their code. As always, opinions on aesthetics differ slightly, but overall, everyone seems to mostly agree that we should try to keep lines short where possible, but lengthen then when needed. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
It's surely more than enough to Haskell, Python, Perl, C++ and other very concise and expressive languages. But for Java and the likes it may well be just barely enough for a single *identifier* alone!! :P 2009/4/21 Dusan Kolar ko...@fit.vutbr.cz: Dear all, reading that according the several style guides, lines shouldn't be too long (longer than 78 characters). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
2009/4/21 Edward Kmett ekm...@gmail.com: I find a hard 80 character line length limit to be somewhat ridiculous in this day and age. I've long since revised my personal rule of thumb upwards towards 132, if only because I can still show two windows of that side by side with no worries, along with all the IDE browsing baggage, even on a fairly crippled laptop, and I've been able to have 132 columns since I picked up my first vt220 terminal in 1984 or so. Good catch. But here's another: modern day IDEs like Eclipse or Netbeans offer so friggin' many features all in-you-face at the same time that the puny window reserved for code may be very well in the 80-chars limit anyway. ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On Tue, Apr 21, 2009 at 9:52 AM, Neil Mitchell ndmitch...@gmail.com wrote: P.S. We really need such a well written style guide for haskell. Python has this nice PEP (Python Enhancement Proposals). Should we start making our own HEP? We have one: urchin.earth.li/~ian/style/haskell.html It should be called the Haskell Enhacement Language Proposals to get any attention. ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
2009/04/25 Thomas Davie tom.da...@gmail.com: 2009/04/25 Jason Dusek: There will always be some people who prefer longer lines. The real issue is, how do we deal with the fundamental disagreement here? It's not like we can have both. Also those people who like long lines -- will they all agree to a long line length? There are those who are driven by an archaic standard from the width of the terminal screen, and there are those who are driven by the aesthetics of their code. False dichotomy :) I am appalled on an aesthetic as well as practical level by lines that reach outside my terminal. It's not important, though -- that's something I've gotten used to; naturally if the standard had been 100 I would have gotten used to that. It's about following clear standards, not ignorance of the width of my screen. As always, opinions on aesthetics differ slightly, but overall, everyone seems to mostly agree... Eh? Since when did they mostly agree? The 200 column example we've seen brought out a lot of disagreement. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
2009/4/23 Miguel Mitrofanov miguelim...@yandex.ru: On 23 Apr 2009, at 12:17, Thomas Davie wrote: Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. 200 sounds awfully long. Do you have any example? Loup ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Some material I've read on typography -- can't find the reference now -- suggests ~65 is the best number of characters per line. The advice was, if your page is larger than that, you should make columns. That fits my observations. In particular, I noticed that your emails were particularly comfortable to read, which might also be partly be caused by the extra indent at the start of your lines, which also seems comfortable. Not sure how applicabable all this is to code, though :-) Gr. Matthijs signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 23 Apr 2009, at 10:02, Matthijs Kooijman wrote: Some material I've read on typography -- can't find the reference now -- suggests ~65 is the best number of characters per line. The advice was, if your page is larger than that, you should make columns. That fits my observations. In particular, I noticed that your emails were particularly comfortable to read, which might also be partly be caused by the extra indent at the start of your lines, which also seems comfortable. Not sure how applicabable all this is to code, though :-) I think the non-applicable to code observation is very likely true – we'd like to be able to write nice descriptive variable names. In doing this, we probably want them to be more than the 1 or 2 characters that Haskellers traditionally use, maybe of the order of 5-10. Given this, it would seem a shame to only be able to fit 6-13 litterals on a line, that sounds like we'll quickly be having to wrap lines with deffinititions of any significance on them. My personal preference with Haskell is to ignore the 78 character limit, but only when layout otherwise becomes horrible otherwise. Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 23 Apr 2009, at 12:17, Thomas Davie wrote: On 23 Apr 2009, at 10:02, Matthijs Kooijman wrote: Some material I've read on typography -- can't find the reference now -- suggests ~65 is the best number of characters per line. The advice was, if your page is larger than that, you should make columns. That fits my observations. In particular, I noticed that your emails were particularly comfortable to read, which might also be partly be caused by the extra indent at the start of your lines, which also seems comfortable. Not sure how applicabable all this is to code, though :-) I think the non-applicable to code observation is very likely true – we'd like to be able to write nice descriptive variable names. In doing this, we probably want them to be more than the 1 or 2 characters that Haskellers traditionally use, maybe of the order of 5-10. Given this, it would seem a shame to only be able to fit 6-13 litterals on a line, that sounds like we'll quickly be having to wrap lines with deffinititions of any significance on them. My personal preference with Haskell is to ignore the 78 character limit, but only when layout otherwise becomes horrible otherwise. Haskell is a very horizontal language, and to limit our horizontal space seems pretty weird. +1. I sometimes use lines up to 200 characters long, when I feel they would be more readable. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
The question of which column width is right is not a revealing one -- there is little technical or scientific basis to prefer 117 to 80. The line length that we prefer is similarly unenlightening. The number of people who, when pushing for column widths greater than 80, choose 132 instead shows us how just how unexploratory and hidebound folks are on this issue. Like you didn't pick 132 because it's the other traditional terminal size. Column width is rather like driving on a certain side of the road. Is one side better than the other? No. Let's change it! Why? The year after you change the ordinance, people will still be crashing into one another when they get up in the morning and switch by mistake -- and people out in the country will drive on the old side for a decade afterward, to Hell with the law. All this and *not for any benefit*. The effect of liberalizing the line length will be anarchy. I'll be resizing my terminal several times a week because some goofball likes 91 characters while another likes 354. Whereas now, we expect code from most sources to fit in 80 columns *and it does*. I've not changed the width of my terminal for code, email or reading in, well, uhm -- well ever since I changed it to 80. 80 columns is a wise limit because it's in wide use. It's not about whether I like it best -- it's about whether I expect most everyone else to be happy with code that I write in it (and I do). In matters where there is no clearcut best answer, social convention creates a clear expectation. Now in the presence of new knowledge, social convention must be changed. Unfortunately, there is no new science on line lengths. There is no reason to prefer any other column width to 80; the number was chosen a long time ago. Let's accept it and move on. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Really, the whole thing makes me wish we had blasphemy laws. If any person, in speaking or in writing, shall indicate a preference for column widths other than 80 or indent characters other than spaces (`0x20`) they shall be compelled to present some science or be subject to imprisonment. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 22 Apr 2009, at 8:09 pm, Jason Dusek wrote: Really, the whole thing makes me wish we had blasphemy laws. If any person, in speaking or in writing, shall indicate a preference for column widths other than 80 or indent characters other than spaces (`0x20`) they shall be compelled to present some science or be subject to imprisonment. I did find a paper that claimed that 95-character lines were significantly faster to read than three shorter lengths. On closer study, it turned out that they were using the paging model rather than the scrolling model: once you came to the end of a (short) page of text, you had to hit the Next button to see the next page. What they had in fact proved was that hitting the Next Page button takes time... Now that I have access to a recent Mac laptop, I've found that in reading plain text, I like to make the lines narrower and to approximate continuous scrolling: read one paragraph, stroke the pad to move the next one up, keep on doing it. There are several important differences between program text and ordinary running natural language text. In particular, program text is two-dimensional in a way that ordinary text is not. By the way, in the era of punched cards, while the *cards* were 80 columns, one's *text area* was not. Typically the last 8 columns were used for a sequence number, so that if you dropped your cards -- yes, this happened -- you could sort them back into order, and to provide editing facilities. So people were really programming with 72-column lines. That seemed to work pretty well, and printers seemed to have no trouble reproducing it in books. I do know a psychologist who has done reading studies; I must see if I can talk him into looking into this. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Some material I've read on typography -- can't find the reference now -- suggests ~65 is the best number of characters per line. The advice was, if your page is larger than that, you should make columns. If someone has done some studies with specifically program text, I'd of course be really interested to know what they discovered; but I really do suspect the issue of line length is more about having a convention than having the best one. Would people who prefer, for example, 132 character lines switch to 66 if that were empirically the best? Probably not. The 80 column convention sets a clear expectation for all of us; it's not a matter of what anyone likes. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Dear all, reading that according the several style guides, lines shouldn't be too long (longer than 78 characters). http://www.cs.caltech.edu/courses/cs11/material/haskell/misc/haskell_style_guide.html http://www.haskell.org/haskellwiki/Programming_guidelines I would like to know, whether 78 characters bound still makes a sense... Even if I connect to my linux box with text terminal, it is not a 80x24 characters HW text terminal, but a window emulating this in whatever else OS, thus, I can usually extend this to see longer lines easily. Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other? Regards, Dušan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Dusan Kolar ko...@fit.vutbr.cz writes: Dear all, reading that according the several style guides, lines shouldn't be too long (longer than 78 characters). http://www.cs.caltech.edu/courses/cs11/material/haskell/misc/haskell_style_guide.html http://www.haskell.org/haskellwiki/Programming_guidelines I would like to know, whether 78 characters bound still makes a sense... Even if I connect to my linux box with text terminal, it is not a 80x24 characters HW text terminal, but a window emulating this in whatever else OS, thus, I can usually extend this to see longer lines easily. Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other? I believe it is a good practice too keep each line short and easy to read. The following is taken from python style guide. Maximum Line Length Limit all lines to a maximum of 79 characters. There are still many devices around that are limited to 80 character lines; plus, limiting windows to 80 characters makes it possible to have several windows side-by-side. The default wrapping on such devices disrupts the visual structure of the code, making it more difficult to understand. Therefore, please limit all lines to a maximum of 79 characters. For flowing long blocks of text (docstrings or comments), limiting the length to 72 characters is recommended. http://www.python.org/dev/peps/pep-0008/ P.S. We really need such a well written style guide for haskell. Python has this nice PEP (Python Enhancement Proposals). Should we start making our own HEP? -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Hi I believe it is a good practice too keep each line short and easy to read. The following is taken from python style guide. Maximum Line Length Limit all lines to a maximum of 79 characters. There are still many devices around that are limited to 80 character lines; plus, limiting windows to 80 characters makes it possible to have several windows side-by-side. The default wrapping on such devices disrupts the visual structure of the code, making it more difficult to understand. Therefore, please limit all lines to a maximum of 79 characters. For flowing long blocks of text (docstrings or comments), limiting the length to 72 characters is recommended. http://www.python.org/dev/peps/pep-0008/ P.S. We really need such a well written style guide for haskell. Python has this nice PEP (Python Enhancement Proposals). Should we start making our own HEP? We have one: urchin.earth.li/~ian/style/haskell.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Dusan Kolar wrote: ... Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other? ... As a little historical detour I think the 80 character limit goes back to 1928 when IBM designed their punched card format http://en.wikipedia.org/wiki/Punched_card#IBM_80_column_punch_card_format I guess it subsequently got embedded into printing and screen widths and related software. The slightly less than 80 characters allows for CR LF characters. Richard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
I find a hard 80 character line length limit to be somewhat ridiculous in this day and age. I've long since revised my personal rule of thumb upwards towards 132, if only because I can still show two windows of that side by side with no worries, along with all the IDE browsing baggage, even on a fairly crippled laptop, and I've been able to have 132 columns since I picked up my first vt220 terminal in 1984 or so. It seems silly _25 years later_ to still not be able to have even that much breathing room. Shorter lengths work very poorly in languages like C# with long LINQ queries, you tend to have verbose enough member and method names that you obtain some pretty ridiculous splits. You wind up with some similar scenarios with list compehensions in Haskell. I'm not saying that every line should be 130+ characters long, I'm just saying that 132 characters seems like a more natural hard cut off point. -Edward Kmett On Tue, Apr 21, 2009 at 10:53 AM, Richard Kelsall r.kels...@millstream.comwrote: Dusan Kolar wrote: ... Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other? ... As a little historical detour I think the 80 character limit goes back to 1928 when IBM designed their punched card format http://en.wikipedia.org/wiki/Punched_card#IBM_80_column_punch_card_format I guess it subsequently got embedded into printing and screen widths and related software. The slightly less than 80 characters allows for CR LF characters. Richard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Edward Kmett ekm...@gmail.com writes: I find a hard 80 character line length limit to be somewhat ridiculous in this day and age. I've long since revised my personal rule of thumb upwards towards 132, if only because I can still show two windows of that side by side with no worries, along with all the IDE browsing baggage, even on a fairly crippled laptop, and I've been able to have 132 columns since I picked up my first vt220 terminal in 1984 or so. I prefer 3 coding windows side by side. And being able to read one line at a glance is a huge advantage. The size of my urxvt is 80x77 FYI. It seems silly _25 years later_ to still not be able to have even that much breathing room. It is not silly. With larger monitor, I can fit more windows side by side. Shorter lengths work very poorly in languages like C# with long LINQ queries, you tend to have verbose enough member and method names that you obtain some pretty ridiculous splits. You wind up with some similar scenarios with list compehensions in Haskell. I know nothing about C#, and I don't care about that. In Haskell, your list comprehension would be much more readable, if you break your lines. The same as complex RE in perl code. I'm not saying that every line should be 130+ characters long, I'm just saying that 132 characters seems like a more natural hard cut off point. -Edward Kmett -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Xiao-Yong Jin xj2...@columbia.edu wrote: Edward Kmett ekm...@gmail.com writes: I find a hard 80 character line length limit to be somewhat ridiculous in this day and age. I've long since revised my personal rule of thumb upwards towards 132, if only because I can still show two windows of that side by side with no worries, along with all the IDE browsing baggage, even on a fairly crippled laptop, and I've been able to have 132 columns since I picked up my first vt220 terminal in 1984 or so. I prefer 3 coding windows side by side. And being able to read one line at a glance is a huge advantage. The size of my urxvt is 80x77 FYI. But the discussion is about a coding standard -- surely if I claimed to like to have 4 windows side by side, that wouldn't be a good reason to reduce the standard to 40 columns? Being able to read one line 'at a glance' seems to me to be improved if that line contains the complete equation, rather than just a fragment. Comprehension of a group of related equations can be improved if they all fit on one screen (vertically). Some code that I've written is intended to look like (and function as) rewrite rules and looks vastly better with pattern and replacement all on the same line. All the arguments can cut both ways -- for those who like coding with windows side by side, what about those who like coding with one window above another? Coding style is very situational, but the 80 character standard came about due to a once-ubiquitous device limitation (which no longer exists). The *real* purpose of a coding standard, of course, is to give people something to argue over when they could be actually doing something more productive. So in the end, it's all good, I suppose. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Robert Greayer robgrea...@yahoo.com writes: Xiao-Yong Jin xj2...@columbia.edu wrote: Edward Kmett ekm...@gmail.com writes: I find a hard 80 character line length limit to be somewhat ridiculous in this day and age. I've long since revised my personal rule of thumb upwards towards 132, if only because I can still show two windows of that side by side with no worries, along with all the IDE browsing baggage, even on a fairly crippled laptop, and I've been able to have 132 columns since I picked up my first vt220 terminal in 1984 or so. I prefer 3 coding windows side by side. And being able to read one line at a glance is a huge advantage. The size of my urxvt is 80x77 FYI. But the discussion is about a coding standard -- surely if I claimed to like to have 4 windows side by side, that wouldn't be a good reason to reduce the standard to 40 columns? Being able to read one line 'at a glance' seems to me to be improved if that line contains the complete equation, rather than just a fragment. Comprehension of a group of related equations can be improved if they all fit on one screen (vertically). Some code that I've written is intended to look like (and function as) rewrite rules and looks vastly better with pattern and replacement all on the same line. All the arguments can cut both ways -- for those who like coding with windows side by side, what about those who like coding with one window above another? Coding style is very situational, but the 80 character standard came about due to a once-ubiquitous device limitation (which no longer exists). It's probably just a personal taste. My argument is just that I prefer moving my eyes vertically to horizontally. And I like that most news papers do that for me. And I'm grateful that most people on the mailing list write emails with proper line wrap as well. The *real* purpose of a coding standard, of course, is to give people something to argue over when they could be actually doing something more productive. So in the end, it's all good, I suppose. Right. We should do something more productive than debating over such a useless concept related to personal taste. -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Robert Greayer wrote: But the discussion is about a coding standard -- surely if I claimed to like to have 4 windows side by side, that wouldn't be a good reason to reduce the standard to 40 columns? Being able to read one line 'at a glance' seems to me to be improved if that line contains the complete equation, rather than just a fragment. Comprehension of a group of related equations can be improved if they all fit on one screen (vertically). Some code that I've written is intended to look like (and function as) rewrite rules and looks vastly better with pattern and replacement all on the same line. All the arguments can cut both ways -- for those who like coding with windows side by side, what about those who like coding with one window above another? Coding style is very situational, but the 80 character standard came about due to a once-ubiquitous device limitation (which no longer exists). The *real* purpose of a coding standard, of course, is to give people something to argue over when they could be actually doing something more productive. So in the end, it's all good, I suppose. 80 characters may be the device limitation from long ago, but there are other reasons to keep lines from getting too long, as have been mentioned... the ease of reading vertically, the common use of 80-char windows that can be fit side-by-side. As far as arguments cutting both ways, I think it's really a Goldilocks question. Some code has lines that are clearly too long to be practical (because they will look ugly as they wrap on most people's editors), and 40 characters is clearly too short. Somewhere in the middle is just right. Now, we may disagree on what just right is, but I just want to establish that the various arguments for longer or shorter lines can be regarded as forces that tug the coding standard in one direction or the other, and I think it's valuable to look for the equilibrium. I think 80 characters is a decent compromise. 80-character windows seem to be very common. At work everyone uses them, and as monitors got wider, they put windows side-by-side. Seems like a common practice. Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Xiao-Yong Jin schrieb: P.S. We really need such a well written style guide for haskell. Python has this nice PEP (Python Enhancement Proposals). Should we start making our own HEP? http://www.haskell.org/haskellwiki/Category:Proposals ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On Tue, 2009-04-21 at 13:52 +0100, Neil Mitchell wrote: P.S. We really need such a well written style guide for haskell. Python has this nice PEP (Python Enhancement Proposals). Should we start making our own HEP? We have one: urchin.earth.li/~ian/style/haskell.html Yes, it's good. We should publicise it more. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Hi, i hate those html forms that show you [haskell,python] code in a narrow box that is suposed to make the code clear, but it darkens the code by cutting it. Maybe having all lines shorter helps, but the narrow window effect is chasing us nonsensely.- haroldo 2009/4/21 Richard Kelsall r.kels...@millstream.com Dusan Kolar wrote: ... Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other? ... As a little historical detour I think the 80 character limit goes back to 1928 when IBM designed their punched card format http://en.wikipedia.org/wiki/Punched_card#IBM_80_column_punch_card_format I guess it subsequently got embedded into printing and screen widths and related software. The slightly less than 80 characters allows for CR LF characters. Richard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
Dusan Kolar wrote: Dear all, reading that according the several style guides, lines shouldn't be too long (longer than 78 characters). http://www.cs.caltech.edu/courses/cs11/material/haskell/misc/haskell_style_guide.html http://www.haskell.org/haskellwiki/Programming_guidelines I would like to know, whether 78 characters bound still makes a sense... Even if I connect to my linux box with text terminal, it is not a 80x24 characters HW text terminal, but a window emulating this in whatever else OS, thus, I can usually extend this to see longer lines easily. Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other? There is a deeper reason. Much work in typography has shown that humans read text best when it's around 76 characters wide; if things get narrower than that then cohesion is lost, if things get wider then it takes a long time to acquire the beginning of the next line. This is the reason why newspapers and magazines are designed with columns at the width they are, why the unix fmt tool has the default settings it does, why mail readers (e.g. Thunderbird) autowrap around there, etc... The historical 80x24 terminal is often cited as the reason for the ~80 character limit, and is as often disparaged as it is praised in light of modern displays (does huge display = many windows, or huge display = one huge window?). But regardless of technical capabilities, there is a cognitive issue at stake. Naturally, code /= text, but there are many similarities; I'm not aware of any HCI studies contrasting them in terms of cognitive load at different widths however. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
wren ng thornton w...@freegeek.org wrote: There is a deeper reason. Much work in typography has shown that humans read text best when it's around 76 characters wide; if things get narrower than that then cohesion is lost, if things get wider then it takes a long time to acquire the beginning of the next line. My impression of the research is that it isn't nearly so conclusive. See [1] for a brief survey of findings for online reading speed/comprehension and a relatively recent study. The results are all over the place. Nevertheless, your later point - code /= text, is key. I'd expect there's a study that focuses on code, though I don't have one at my fingertips. I imagine reading speed for code is overall much lower than for natural language, which I expect is an important factor affecting eye movement. I'd also guess that reading patterns are quite different -- scanning backward or forward to find a definition, etc. It's different enough that I'd discount research focusing on natural language text as being relevant. [1] http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Is 78 characters still a good option? Was: [Haskell-cafe] breaking too long lines
On 22 Apr 2009, at 2:53 am, Richard Kelsall wrote: Dusan Kolar wrote: ... Or is the reason much deeper? Or, is the bound set to 78 characters just because it is as good number as any other? ... As a little historical detour I think the 80 character limit goes back to 1928 when IBM designed their punched card format Interestingly enough, IBM also made 96-column cards. But the one time I had to use them, I found that the keypunch didn't actually print all 96 columns. It may be worth noting that the era of 80-column keypunches was also the era of 132-column printers. DEC terminals used to have a 132-column mode, and some terminal emulators still offer you an 80/132 choice. Poking around on the web, I found http://www.svendtofte.com/code/max_width_in_ie/ from which the rest of this message is a quote. (The original has links.) - There has been several studies, on the topic of on line line-lengths, one of the better was done by the department of psychology at Wichita State University, entitled The Effects of Line Length on Children and Adults' Online Reading Performance, and it clearly shows, in many different situations, and under different speed requirements, how people read on-line. More on the subject can be found in the company Human Factors Internationals' newsletter, Reading Text Online. While from reading these articles, you get the clear image, that there are no firm rules, but only vague ideas, and maybe this is best. But still, some conclusions are drawn by the researchers: From this study, as well as the studies mentioned above, it is suggested that full-screen line length should be avoided for on-line documents, especially if a large amount of text is presented. For adults, it is suggested that medium line lengths should be presented (approximately 65 to 75 CPL). Children, on the other hand, indicated their preference for the narrowest line length (45 CPL) and, thus, it may be beneficial to use narrow line lengths when possible. The emphasis added are mine. Further, we can also discern, that a good reading width, should be around 60 CPL (characters per line). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
