digitalmars.D - On 80 columns should (not) be enough for everyone
- Andrej Mitrovic (24/24) Jan 30 2011 The unittest topic is about to get derailed so I want to continue this s...
- Andrej Mitrovic (1/1) Jan 30 2011 Also, it's 2011 apparently. I'm still stuck in 2010 it seems. :p
- Lutger Blijdestijn (8/21) Jan 30 2011 Yes, but there has to be some limit, horizontal scrolling is much worse....
- Peter Alexander (3/7) Jan 30 2011 Is this really worth arguing about?
- Matthias Walter (7/22) Jan 30 2011 One argument that I can think of is to at least raise the number of
- bearophile (4/5) Jan 30 2011 You are right, let's stick to 90-95 columns and let's close this discuss...
- Andrei Alexandrescu (83/86) Jan 30 2011 I, too, would love to vote how others should format their code. FWIW
- Bernard Helyer (44/44) Feb 01 2011 Here's SDC, just for kicks:
- Walter Bright (8/11) Jan 30 2011 80 columns came from how many characters would fit on a standard size 8....
- Andrei Alexandrescu (16/28) Jan 30 2011 Also: pick a random book or newspaper and count the characters in a
- Ulrik Mikaelsson (58/90) Jan 31 2011 FWIW: Here's my two cents; (Non-Phobos participant, so feel free to
- Andrei Alexandrescu (14/30) Jan 31 2011 Well the fact of the matter is that style used in books is very
- bearophile (4/7) Jan 31 2011 I think 110 columns are a little too many. I have suggested 90-95 chars ...
- Russel Winder (29/36) Jan 31 2011 What say we cut the agist crap.
- bearophile (4/5) Jan 31 2011 There are also armies of programmers with myopia :-)
- Kagamin (2/7) Feb 01 2011 I use Verdana 15pt (monospaced fonts don't really scale to this extent a...
- Ulrik Mikaelsson (37/62) Jan 31 2011 yle
- Stewart Gordon (19/36) Feb 01 2011 If only your newsreader were also set to wrap at 90, it would be clearer...
- spir (11/13) Jan 31 2011 Even if they were (which is imo absurd to state), what would count is no...
- Sean Kelly (2/16) Jan 30 2011 Print text doesn't have indentation levels though. Assuming a 4 charact...
- Tomek =?UTF-8?B?U293acWEc2tp?= (13/14) Jan 30 2011 r indent, the smallest indentation level for code in a D member function...
- Andrei Alexandrescu (9/29) Jan 30 2011 Newspaper columns are strongly optimized for being read quickly. Not a
- Sean Kelly (4/37) Jan 30 2011 True. Though multiply nested such blocks are rare.
- JMRyan (11/13) Jan 31 2011 This suggests (without exactly stating) one of my personal reasons for a
- Walter Bright (4/20) Jan 31 2011 Looking it up shows that the history is a bit more complicated than I sa...
- spir (7/18) Jan 31 2011 Code is no newspaper article. And newspaper articles are rarely multi-in...
- Tomek =?UTF-8?B?U293acWEc2tp?= (8/9) Jan 30 2011 to, then make a poll to see what everyone can agree on.
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (12/20) Jan 30 2011 silly beef I'm really curious what distribution will emerge.
- Andrei Alexandrescu (4/8) Jan 30 2011 80.
- Sean Kelly (2/4) Jan 30 2011 110
- Tomek =?UTF-8?B?U293acWEc2tp?= (5/6) Jan 30 2011 ly with a number only)
- Walter Bright (2/3) Jan 30 2011 6.022e+23
- Tomek =?UTF-8?B?U293acWEc2tp?= (5/8) Jan 30 2011 That's a whole mole of code! ;-)
- Steven Schveighoffer (5/9) Jan 31 2011 It's amazing that D does so much, and to top it off, it's only ONE LINE ...
- Simen kjaeraas (6/13) Jan 30 2011 =
- foobar (7/18) Jan 30 2011 I think that putting an artificial limit is incredibly stupid. Haven't a...
- so (1/13) Jan 30 2011 I agree, but i guess they are talking about standard library.
- foobar (6/22) Jan 30 2011 Right, so does that mean it should be made _less_ readable by a diverse ...
- Walter Bright (3/8) Jan 30 2011 I think you've mixed up libraries with languages. Please rephrase so we ...
- Andrei Alexandrescu (5/13) Jan 30 2011 Seconded. Also there is this one presupposition that reflects poorly on ...
- foobar (5/20) Jan 30 2011 That's just incorrect since I didn't even specify my style convention.
- Michel Fortin (7/10) Jan 31 2011 But is Phobos the problem or is the one-page-per-module documentation
- foobar (4/18) Jan 31 2011 Phobos' organization is the problem. If you read the C++ standard you'll...
- Andrei Alexandrescu (18/43) Jan 31 2011 But that goes for anyone, including your code. Code written in foobar's
- foobar (8/61) Jan 31 2011 Everything is relative. Loki is a c++ library and I'm sure it's one of t...
- spir (9/11) Jan 31 2011 +++
- Steven Schveighoffer (18/27) Jan 31 2011 I think the main problem is with ddoc. This, from std.algorithm is a
- Andrei Alexandrescu (13/41) Jan 31 2011 Let's fix it! I'm thinking along the lines of finding some broad groups,...
- Adam Ruppe (7/9) Jan 31 2011 Maybe we can get the best of both worlds: how about a "Group:" or
- Andrei Alexandrescu (3/12) Jan 31 2011 Great idea!
- Jonathan M Davis (11/65) Jan 31 2011 At minimum, it needs to be smarter about user-defined types. The functio...
- Michel Fortin (18/36) Jan 31 2011 Please do. Grouping by task is very useful when you're searching for a
- spir (12/17) Jan 31 2011 Isn't that's what namespaces are for? A big advantage of OO-like coding ...
- Adam Ruppe (8/10) Jan 31 2011 Note that that is generated through some short javascript in the
- Steven Schveighoffer (7/17) Jan 31 2011 I'm all for it (voice with no authority).
- Adam Ruppe (16/19) Jan 31 2011 Here it is with the brief css change to put it in a grid:
- Adam Ruppe (3/4) Jan 31 2011 No, I'm wrong. That's only the currently referenced symbol. No
- Steven Schveighoffer (12/21) Jan 31 2011 It does help, but I was kind of hoping for something that shows the
- Daniel Gibson (4/20) Jan 31 2011 For D1 (maybe it works with D2 as well? It used dmd) there was CandyDoc
- Adam Ruppe (6/8) Jan 31 2011 Those relationships are in the HTML too.... try it now:
- bearophile (4/7) Jan 31 2011 A good C lint is very good at spotting that kind of bugs. There are lint...
- Steven Schveighoffer (16/24) Feb 01 2011 Yes, it's in the right direction, but it does need work.
- foobar (5/15) Jan 30 2011 I just tried to save typing :)
- Walter Bright (4/9) Jan 30 2011 Please take a module or function in the phobos documentation, and rewrit...
- spir (9/13) Jan 31 2011 Sure. How can we ensure Phobos contributors drink Pilsner Urquell?
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (18/39) Jan 30 2011 t silly beef I'm really curious what distribution will emerge.
- foobar (3/37) Jan 30 2011 I personally prefer long lines and always code (in eclipse) when the cod...
- Michel Fortin (10/12) Jan 30 2011 Xcode.
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (9/20) Jan 31 2011 e.
- Walter Bright (2/5) Jan 30 2011 Word-wrapping code is a bad idea.
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (7/13) Jan 31 2011 My point exactly.
- spir (7/33) Jan 31 2011 Yop, geany :-) http://en.wikipedia.org/wiki/Geany
- =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= (8/17) Jan 31 2011 Nope it wraps to the same indent level as the original line, so you
- spir (8/10) Jan 31 2011 It shows it's a wrapped line using a dedicated "wrapping-arrow" sign. I ...
- Ulrik Mikaelsson (6/11) Jan 31 2011 Kate does this too, and clearly marks out it's an auto-wrapped line
- David Nadlinger (2/6) Jan 30 2011 80
- Daniel Gibson (3/7) Jan 30 2011 about 100 (don't care if its 2 chars more to fit a ");" or something
- Jim (4/15) Jan 30 2011 --- No limit ---
- Nick Sabalausky (6/8) Jan 30 2011 I generally try to stick to about 80 as a rule-of-thumb, but I'll go up ...
- Jonathan M Davis (53/62) Jan 30 2011 My _preferred_ limit would be no limit but that if your line is getting ...
- Don (3/11) Jan 31 2011 100 (8 levels of 4-space indent, + 65 characters).
- Ulrik Mikaelsson (1/1) Jan 31 2011 90 as a rule of thumb with some exceptions.
- foobar (4/14) Jan 31 2011 My complaint is not about the implementation itself as it is about it's ...
- Walter Bright (3/20) Jan 31 2011 Please take a Phobos module or a function, and rewrite its API to demons...
- so (7/10) Jan 31 2011 This one i don't understand. (seems i fail to understand many things
- Steven Schveighoffer (3/10) Jan 31 2011 80
- Tomek =?UTF-8?B?U293acWEc2tp?= (20/30) Jan 31 2011 ly with a number only)
- Tomek =?UTF-8?B?U293acWEc2tp?= (16/31) Jan 31 2011 ally have to". I took the latter (larger) number as I was after maximum ...
- Walter Bright (2/4) Jan 31 2011 What kind of a jerk is that respondent?
- spir (7/11) Jan 31 2011 99
- foobar (5/63) Jan 31 2011 You just got my hopes up in the previous paragraph..... :(
- foobar (6/16) Feb 01 2011 var foo = [bar, baz];
- Bruno Medeiros (14/18) Feb 10 2011 My preferred maximum length for Java is 120. I haven't coded much D to
- Nick Sabalausky (92/140) Jan 30 2011 Heh :)
- Walter Bright (14/18) Jan 30 2011 People who use screen readers often crank up the playback rate to 2x. Th...
- bearophile (4/5) Jan 30 2011 I sometimes see&hear documentaries at 140-160% speed.
- Nick Sabalausky (7/27) Jan 30 2011 I wish someone would finally just patent getting patents. (IBM's come cl...
- Walter Bright (2/7) Jan 30 2011 I agree that patents are a blight on the industry.
- Jeff Nowakowski (7/10) Jan 30 2011 Widescreen monitors are awesome as an alternative to dual-screen
- Nick Sabalausky (6/17) Jan 30 2011 Yea, not bad at that.
- spir (7/39) Jan 31 2011 Nice idea :-) Really makes sense, imo.
- Stewart Gordon (23/49) Jan 30 2011 Other than, as you begin to say, the difficulty in deciding on where to
- foobar (2/9) Jan 30 2011 That's why I'm opposed to *any* artificial limit as proposed by Andrei....
- Andrei Alexandrescu (5/14) Jan 31 2011 Opposition rendered anonymously from an armchair quarterback has little
- Daniel Gibson (4/19) Jan 31 2011 1. The D-Compiler doesn't care if the code fits in your terminal
- Nick Sabalausky (6/14) Jan 31 2011 Not if you're in text-mode. Which could happen if your X11 gets fucked.
- Max Samukha (3/27) Jan 31 2011 I think there is no need to establish a fixed limit. "Avoid long lines"
- Jonathan M Davis (15/31) Jan 31 2011 Classes and structs already group functions naturally, and that grouping...
The unittest topic is about to get derailed so I want to continue this silly discussion here. Wheres Nick? I want to see the CRT vs LCD discussion heated up again with Andrei claiming that LCDs are so Godlike but yet claims 80 columns is enough for everyone. 80 colums is an artifact of the old age. Just like the preprocessor is an artifact of the C language. And many other old things are artifacts. There's no reason to keep these artifacts around anymore. A couple of things, Andrei: 1. 80 colums is way too restrictive. 80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware. Who will run a brand new language like D in a freakin' Terminal? Have you ever heard of the expression "limitations boost creativity"? That can be considered a good thing, if creativity is what you're after. In code, it's not. You're looking for clarity in code. 80 column limitations are good for C obfuscation contests and nothing else. 80 columns means people are going to *work around* the limit, by using hacks and workarounds to make everything fit in place. Do you really believe that programmers are going to spend any time at all thinking: *"oh this line doesn't fit on 80 columns. I should now spend some time thinking about how to improve and rewrite the design of my code. 80 columns really is the golden ration"*? If you want to see more files on the screen, get multiple screens. Is Facebook running out of money, can't they afford a few monitors for the C++ guru? Yes, I know you're not allowed to comment on that one. :) 2. A widescreen aspect ratio causes less eye strain. Wider code means the same. It doesn't have to stretch all the way to be effective, but 80 columns is too limiting. Do a Google search and read what people have go say about that. 3. Less columns means more rows. And generally coders *hate* it when they can't see a function that fits on a single screen. They hate having to scroll up and down. This common syntax form is a proof of that: void main() { void foo() { while (true) { if (done) { } } } } I find that unpleasant to read. Not impossible, but unpleasant. I can live with it though, but if you limit code to 80 limits that's going to become a mess to read. 3. It's 2010. Does your GNU/emacs still not support wrapping lines by word boundaries? Scite had this since the '90s, and that's not even an advanced editor. Vim supports word wrapping as well. Heck, I'm pretty sure you can customize it to wrap on whatever boundary you want to (although I'm only speculating, but pretty much everything in Vim is customizable). You can even customize how your cursor reacts if it's on an 'artificial' new line, one that has been wrapped. Isn't technology amazing? 4. Just how many files do you want to edit at a single time on the screen? We're not really multitasking beings, you know. Try using one of your hands and do forward circles, as if it were a wheel. With the other one do backward circles. And now use your foot to draw a circle on the floor. You're end up looking like a clown in seconds, and a bad one at that. Again, people who want to have documentation, and code, and IRC chats in display buy more computer screens. Why should your code have to suffer if you really want to do multiple things all at once? Bottom line: If you really want to set up a column limit that *everyone* has to abide to, then make a poll to see what everyone can agree on. I don't see why everyone has to cater to your rules only, regardless of what your professional experience might be. You're a big contributor to Phobos, but you're not the only one. I tend to believe that D is (or should be) a community effort, so please don't hijack D away from the community by forcing your own rules down to everyone else.
Jan 30 2011
Also, it's 2011 apparently. I'm still stuck in 2010 it seems. :p
Jan 30 2011
Andrej Mitrovic wrote:The unittest topic is about to get derailed so I want to continue this silly discussion here.80 colums is an artifact of the old age. Just like the preprocessor is an artifact of the C language. And many other old things are artifacts. There's no reason to keep these artifacts around anymore.Yes, but there has to be some limit, horizontal scrolling is much worse. Someone at my workplace likes to make 400+ columns lines of code for example, he likes it but it confuses the shit out of me.A couple of things, Andrei: 1. 80 colums is way too restrictive. 80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware. Who will run a brand new language like D in a freakin' Terminal?Terminals can host more than 80 columns these days.If you want to see more files on the screen, get multiple screens. Is Facebook running out of money, can't they afford a few monitors for the C++ guru? Yes, I know you're not allowed to comment on that one. :)iirc Andrei commented facebook installed him a 30inch screen.
Jan 30 2011
On 30/01/11 5:17 PM, Andrej Mitrovic wrote:The unittest topic is about to get derailed so I want to continue this silly discussion here. Wheres Nick? I want to see the CRT vs LCD discussion heated up again with Andrei claiming that LCDs are so Godlike but yet claims 80 columns is enough for everyone. 80 colums is an artifact of the old age. Just like the preprocessor is an artifact of the C language. And many other old things are artifacts. There's no reason to keep these artifacts around anymore. <snip>Is this really worth arguing about? Just stick to 80 columns. It's not a big deal.
Jan 30 2011
On 01/30/2011 01:01 PM, Peter Alexander wrote:On 30/01/11 5:17 PM, Andrej Mitrovic wrote:One argument that I can think of is to at least raise the number of allowed columns. Why? Well, phobos' names like tr will be (or are) refactored to translate and with camelcase we encourage people to use descriptive names. And with template parameters and everything I do not want to call functions, putting 1 argument on every line. I'd suggest raising it to 120 or 150...The unittest topic is about to get derailed so I want to continue this silly discussion here. Wheres Nick? I want to see the CRT vs LCD discussion heated up again with Andrei claiming that LCDs are so Godlike but yet claims 80 columns is enough for everyone. 80 colums is an artifact of the old age. Just like the preprocessor is an artifact of the C language. And many other old things are artifacts. There's no reason to keep these artifacts around anymore. <snip>Is this really worth arguing about? Just stick to 80 columns. It's not a big deal.
Jan 30 2011
Peter Alexander:Is this really worth arguing about?You are right, let's stick to 90-95 columns and let's close this discussion. Bye, bearophile
Jan 30 2011
On 01/30/2011 12:25 PM, bearophile wrote:Peter Alexander:I, too, would love to vote how others should format their code. FWIW here's a data point: $ wc -l std/**/*.d 138793 total $ grep '.\{81,\}' std/**/*.d | cut -f1 -d:| uniq -c | sort -nr 6742 std/datetime.d 145 std/bind.d 116 std/base64.d 106 std/windows/registry.d 92 std/file.d 81 std/socket.d 67 std/internal/math/biguintcore.d 66 std/math.d 64 std/conv.d 60 std/regexp.d 54 std/internal/math/gammafunction.d 51 std/numeric.d 35 std/stream.d 34 std/internal/math/biguintx86.d 32 std/regex.d 30 std/traits.d 22 std/container.d 21 std/zip.d 21 std/random.d 21 std/format.d 21 std/algorithm.d 19 std/signals.d 18 std/utf.d 18 std/string.d 18 std/internal/math/errorfunction.d 16 std/loader.d 14 std/typelist.d 14 std/internal/math/biguintnoasm.d 13 std/typecons.d 12 std/range.d 12 std/concurrency.d 11 std/json.d 11 std/date.d 10 std/functional.d 10 std/c/windows/winsock.d 10 std/bigint.d 9 std/encoding.d 7 std/path.d 6 std/zlib.d 6 std/xml.d 6 std/outbuffer.d 5 std/stdio.d 5 std/mathspecial.d 5 std/array.d 4 std/variant.d 4 std/typetuple.d 4 std/mmfile.d 4 std/md5.d 4 std/cpuid.d 3 std/socketstream.d 3 std/process.d 3 std/getopt.d 3 std/dateparse.d 3 std/ctype.d 2 std/windows/charset.d 2 std/uri.d 2 std/uni.d 2 std/stdarg.d 2 std/c/stdlib.d 2 std/c/osx/socket.d 2 std/compiler.d 2 std/c/linux/socket.d 1 std/windows/syserror.d 1 std/windows/iunknown.d 1 std/system.d 1 std/stdiobase.d 1 std/stdint.d 1 std/__fileinit.d 1 std/exception.d 1 std/demangle.d 1 std/datebase.d 1 std/c/windows/com.d 1 std/cstream.d 1 std/complex.d 1 std/bitmanip.d 1 Binary file std/perf.d matches AndreiIs this really worth arguing about?You are right, let's stick to 90-95 columns and let's close this discussion.
Jan 30 2011
Here's SDC, just for kicks: [SDC]$ find src/sdc -name "*.d" -print0 | xargs --null wc -l | sort -rn | head -n 1 12545 total [SDC]$ find src/sdc -name "*.d" -print0 | xargs --null grep '.\{81,\}' | cut -f1 -d:| uniq -c | sort -nr 81 src/sdc/gen/value.d 44 src/sdc/gen/expression.d 35 src/sdc/lexer.d 26 src/sdc/gen/base.d 24 src/sdc/parser/declaration.d 24 src/sdc/gen/declaration.d 19 src/sdc/gen/sdctemplate.d 16 src/sdc/gen/statement.d 13 src/sdc/global.d 12 src/sdc/gen/sdcfunction.d 11 src/sdc/sdc.d 9 src/sdc/gen/sdcpragma.d 8 src/sdc/parser/expression.d 8 src/sdc/parser/base.d 8 src/sdc/gen/sdcmodule.d 7 src/sdc/parser/conditional.d 7 src/sdc/gen/attribute.d 6 src/sdc/parser/sdcimport.d 6 src/sdc/parser/attribute.d 6 src/sdc/extract/base.d 4 src/sdc/parser/sdctemplate.d 4 src/sdc/parser/enumeration.d 4 src/sdc/gen/sdcimport.d 4 src/sdc/gen/enumeration.d 3 src/sdc/sdc4de.d 2 src/sdc/token.d 2 src/sdc/gen/type.d 2 src/sdc/gen/cfg.d 2 src/sdc/gen/aggregate.d 1 src/sdc/tokenstream.d 1 src/sdc/terminal.d 1 src/sdc/source.d 1 src/sdc/parser/statement.d 1 src/sdc/parser/sdcpragma.d 1 src/sdc/parser/sdcclass.d 1 src/sdc/parser/aggregate.d 1 src/sdc/ast/statement.d 1 src/sdc/ast/expression.d
Feb 01 2011
Andrej Mitrovic wrote:80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware.80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.
Jan 30 2011
On 01/30/2011 12:27 PM, Walter Bright wrote:Andrej Mitrovic wrote: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!). Andrei80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware.80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.
Jan 30 2011
FWIW: Here's my two cents; (Non-Phobos participant, so feel free to click delete now) I'm not sure whether text-books and program-code are really comparable in this respect. When reading books I hardly put much attention to each particular word, while in computer-code, each token is very significant. The "flow" of reading is simply different. If it weren't, we would hardly use hard line-breaks at all, just concatenate statements like we concatenate sentences in text, and use <your word processor> to format code. Especially, we would not use monospaced fonts and care about "columns". I would rather like to hear whether any mathematicians ever insert hard-breaks into their equations just "to not get them too wide". Personally, I've been a long time on the fence regarding strict line-length, and my current position is: 90 columns is the rule of thumb. 80 columns is often hard to fit using readable names, but 90 columns generally works. When the code exceeds 90 columns, I try to look for: * local variable names that can be shortened without breaking their descriptiveness. * sub-expressions in the line, which can be reasonably be extracted into separe pre-computed variable. (Which also increases readability of the code by itself.) * unnecessary nested depth in the function, and try to either refactor parts out to separate functions, or refactor the function to be more pass-based rather then nested. One special-case which often cause problems, is function-calls, especially "method"-calls. Roughly lines like: (note 3-level leading indent) otherObj1.doSomethingSensible(otherObj2.internalVariable, this.config, this.context); At this point, I can see two obvious alternatives; otherObj1.doSomethingSensible(otherObj2.internalVariable, this.config, this.context); vs. otherObj1.doSomethingSensible(otherObj2.internalVariable, this.config, this.context); Both have advantages and problems. In the first alternative, you might miss the second argument if reading too fast, and in the second alternative, the vertical space can be quickly wasted, especially if the line get's just slightly too long due to many small arguments. (I.E. debug-output of many short-named local variables.) In these cases, I usually just leave it to overflow. That will * hint to the reader that it's still just one single function-call * arguments won't be missed * not waste unnecessary vertical space * it's up to the code-viewer to determine whether a line-wrap is actually needed, which it might even indicate using a wrap-marker in the margin (not possible with a manual line-break). For other common long-line sources like enums, array literals etc, I usually block-format and insert line-breaks as usual to not exceed 90 columns wide. My guess is, if I worked enough with long mathematical expression, I would use roughly the same guidelines. / Ulrik (*doh* that was probably more than 2 cents worth.) 2011/1/30 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:On 01/30/2011 12:27 PM, Walter Bright wrote:Andrej Mitrovic wrote: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!). Andrei80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware.80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.
Jan 31 2011
On 1/31/11 11:54 AM, Ulrik Mikaelsson wrote:FWIW: Here's my two cents; (Non-Phobos participant, so feel free to click delete now) I'm not sure whether text-books and program-code are really comparable in this respect. When reading books I hardly put much attention to each particular word, while in computer-code, each token is very significant. The "flow" of reading is simply different. If it weren't, we would hardly use hard line-breaks at all, just concatenate statements like we concatenate sentences in text, and use<your word processor> to format code. Especially, we would not use monospaced fonts and care about "columns".Well the fact of the matter is that style used in books is very influential. People do copy book samples into code and continue working in the same style from them. I've been asked for (and released) the source code of all snippets in TDPL.I would rather like to hear whether any mathematicians ever insert hard-breaks into their equations just "to not get them too wide".I'm not sure I can qualify as a mathematician but my research is very math-heavy. In my thesis (http://erdani.com/research/dissertation_color.pdf) I frequently inserted line breaks even when not technically necessary, check e.g. eq. 2.16 on page 12.Personally, I've been a long time on the fence regarding strict line-length, and my current position is: 90 columns is the rule of thumb. 80 columns is often hard to fit using readable names, but 90 columns generally works.Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm now more inclined to increase and/or soften the recommended limit for Phobos. Andrei
Jan 31 2011
Andrei:Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm now more inclined to increase and/or soften the recommended limit for Phobos.I think 110 columns are a little too many. I have suggested 90-95 chars max (but less than 80 on average) after seeing both the problems caused by too much short lines (to keep lines below 70-80 chars I have seen programmers use 2 spaces to indent or use very short variable names. This is worse than 95 chars long lines), and seeing lines with 120+ chars that cause troubles to older programmer that can't use a too much small font because of their older eyes. Bye, bearophile
Jan 31 2011
On Mon, 2011-01-31 at 13:41 -0500, bearophile wrote: [ . . . ]I think 110 columns are a little too many. I have suggested 90-95 chars max (but less than 80 on average) after seeing both the problems caused by too much short lines (to keep lines below 70-80 chars I have seen programmers use 2 spaces to indent or use very short variable names. This is worse than 95 chars long lines), and seeing lines with 120+ chars that cause troubles to older programmer that can't use a too much small font because of their older eyes.What say we cut the agist crap. Just because anyone over 50 (like me) has worsening eyesight doesn't mean they can't work quite happily with 110 character lines using 8pt fonts. I like 110 character lines in smaller fonts, and I like 2 space indents. And proportional fonts -- Ocean Sans MT rules -- why all this monospace font obsession (*). At the end of the day source code consistency is the only really important thing. Anyone amending a file or adding a file to a codebase must do it in the style of the current code so as to avoid spoiling consistency, and creating specious changes in version control. Just because I object to a coding style doesn't mean I can't use it if I am amending someone else code. Whoever is the project leader for a project defines a style and then everyone works with it -- even if that style is some crappy 80 column stupidity ;-) (*) Flame wars should be directed to /dev/null -- or if you insist on using Windows, whatever the equivalent is. :-) --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 31 2011
Russel Winder:What say we cut the agist crap.There are also armies of programmers with myopia :-) Bye, bearophile
Jan 31 2011
Russel Winder Wrote:Just because anyone over 50 (like me) has worsening eyesight doesn't mean they can't work quite happily with 110 character lines using 8pt fonts. I like 110 character lines in smaller fonts, and I like 2 space indents. And proportional fonts -- Ocean Sans MT rules -- why all this monospace font obsession (*).I use Verdana 15pt (monospaced fonts don't really scale to this extent and usually don't have characters beyond ASCII). Pixels are small and displays are big nowadays, my editor can accomodate 150 columns in windowed mode.
Feb 01 2011
2011/1/31 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:On 1/31/11 11:54 AM, Ulrik Mikaelsson wrote:al.I'm not sure whether text-books and program-code are really comparable in this respect. When reading books I hardly put much attention to each particular word, while in computer-code, each token is very significant. The "flow" of reading is simply different. If it weren't, we would hardly use hard line-breaks at all, just concatenate statements like we concatenate sentences in text, and use<your word processor> =C2=A0to format code. Especially, we would not use monospaced fonts and care about "columns".Well the fact of the matter is that style used in books is very influenti=People do copy book samples into code and continue working in the same st=ylefrom 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.df)I would rather like to hear whether any mathematicians ever insert hard-breaks into their equations just "to not get them too wide".I'm not sure I can qualify as a mathematician but my research is very math-heavy. In my thesis (http://erdani.com/research/dissertation_color.p=I frequently inserted line breaks even when not technically necessary, ch=ecke.g. eq. 2.16 on page 12.Thank you, interesting for the topic (although I didn't understand a thing of the actual math :). I note however that given the very terse variable-names (as is common in math), the lines don't actually grow very long. However, where you HAVE chosen to insert line-breaks, is at equality-operators which I would say is roughly a statement in programming-language terms. ("A =3D B" is a statement, while "A+B" is not.) Interestingly enough, this is roughly the rule-of thumb I use. Try hard to keep statements below 90 characters, but don't resort to manual line-breaks if it's not possible.wPersonally, I've been a long time on the fence regarding strict line-length, and my current position is: =C2=A090 columns is the rule of thumb. 80 columns is often hard to fit using readable names, but 90 columns generally works.Seems reasonable. Since both Jonathan and Don prefer longer lines, I'm no=more inclined to increase and/or soften the recommended limit for Phobos.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.
Jan 31 2011
On 31/01/2011 17:54, Ulrik Mikaelsson wrote: <snip>One special-case which often cause problems, is function-calls, especially "method"-calls. Roughly lines like: (note 3-level leading indent) otherObj1.doSomethingSensible(otherObj2.internalVariable, this.config, this.context); At this point, I can see two obvious alternatives; otherObj1.doSomethingSensible(otherObj2.internalVariable, this.config, this.context); vs. otherObj1.doSomethingSensible(otherObj2.internalVariable, this.config, this.context);If only your newsreader were also set to wrap at 90, it would be clearer. Why align the continuation lines with the open bracket? I think the shortness of lines resulting therefrom is the root cause of what you say next:Both have advantages and problems. In the first alternative, you might miss the second argument if reading too fast, and in the second alternative, the vertical space can be quickly wasted, especially if the line get's just slightly too long due to many small arguments.<snip> If OTOH you stick to a standard number of spaces by which to indent, which generally allows multiple arguments to fit on one line otherObj1.doSomethingSensible(otherObj2.internalVariable, this.config, this.context); you don't lead people into the trap of seeing one argument per line. That said, I've probably in my time done something similar to your example. And at other times, I might do otherObj1.doSomethingSensible( otherObj2.internalVariable, this.config, this.context ); Stewart.
Feb 01 2011
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, Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
Walter Bright Wrote:Andrej Mitrovic wrote: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).80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware.80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.
Jan 30 2011
Sean Kelly napisa=C5=82:Print text doesn't have indentation levels though. Assuming a 4 characte=r 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 co= lumn. I wrap all my comments at 79 characters, but allow code to spill as = far as 110 (which is the number of columns on an 8.5x11" piece of paper in = landscape mode). Yeah. If counted without indents, 90 characters would probably suffice, but= with them it's at least 120 so that nested code doesn't get stifled. And I'm programming with a proportional font -- far more readable than a mo= no-space. --=20 Tomek
Jan 30 2011
On 01/30/2011 01:20 PM, Sean Kelly wrote:Walter Bright Wrote:It does - bulleted and numbered lists, certain sidebars, block quotes.Andrej Mitrovic wrote:Print text doesn't have indentation levels though.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.Assuming a 4 character indent, the smallest indentation level for code in a D member function is 8 characters. Add a nested conditional and code is starting 16 characters in, which when wrapped at 80 characters begins to look like a newspaper column.Newspaper columns are strongly optimized for being read quickly. Not a bad standard I guess. I don't contend that your choice works for you, but I refute this particular rationalisation of it. Indentation should NOT be discounted as a participant to the maximum line width. If anything it adds overhead, not reduces it. Andrei
Jan 30 2011
Andrei Alexandrescu Wrote:On 01/30/2011 01:20 PM, Sean Kelly wrote:True. Though multiply nested such blocks are rare.Walter Bright Wrote:It does - bulleted and numbered lists, certain sidebars, block quotes.Andrej Mitrovic wrote:Print text doesn't have indentation levels though.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.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.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.
Jan 30 2011
Walter Bright <newshound2 digitalmars.com> wrote in news:ii4an2$1npj$1 digitalmars.com:80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent.This suggests (without exactly stating) one of my personal reasons for a strict line length limit: sometimes programmers like to print their code. Maybe I'm showing my age, but I find dead trees best for code review. One *can* use a smaller font (hard on the eyes) or print in landscape (yuck--and even that is not enough for some code). PS. I knew about the punch card precident and have even used key punch machines myself, but I didn't know that punch card length was based on earlier precident. Given the absurd length of line printer output of the day, that surprises me.
Jan 31 2011
JMRyan wrote:Walter Bright <newshound2 digitalmars.com> wrote in news:ii4an2$1npj$1 digitalmars.com: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_line80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent.This suggests (without exactly stating) one of my personal reasons for a strict line length limit: sometimes programmers like to print their code. Maybe I'm showing my age, but I find dead trees best for code review. One *can* use a smaller font (hard on the eyes) or print in landscape (yuck--and even that is not enough for some code). PS. I knew about the punch card precident and have even used key punch machines myself, but I didn't know that punch card length was based on earlier precident. Given the absurd length of line printer output of the day, that surprises me.
Jan 31 2011
On 01/30/2011 07:27 PM, Walter Bright wrote:Andrej Mitrovic wrote:Code is no newspaper article. And newspaper articles are rarely multi-indented. Denis -- _________________ vita es estrany spir.wikidot.com80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware.80 columns came from how many characters would fit on a standard size 8.5*11 sheet of paper. Even punch cards followed this precedent. That paper size has stood the test of time as being a comfortable size for reading. Reading longer lines is fatiguing, as when one's eyes "carriage return" they tend to go awry. You can see this yourself if you resize and reflow a text web site to be significantly wider than 80 columns. It gets harder to read.
Jan 31 2011
Andrej Mitrovic napisa=C5=82:If you really want to set up a column limit that *everyone* has to abide =to, then make a poll to see what everyone can agree on. Actually that's a splendid idea. Let's take it easy. Regardless of that sil= ly beef I'm really curious what distribution will emerge. What is your preferred *maximum* length for a line of D code? (please reply= with a number only) --=20 Tomek
Jan 30 2011
Tomek Sowi=C5=84ski wrote:Andrej Mitrovic napisa=C5=82: =20de to, then make a poll to see what everyone can agree on.If you really want to set up a column limit that *everyone* has to abi==20 Actually that's a splendid idea. Let's take it easy. Regardless of that=silly beef I'm really curious what distribution will emerge.=20 What is your preferred *maximum* length for a line of D code? (please r=eply with a number only)=20I use 70. May occasionally be extended to 80 if there is no easy way to reflow the code below 70, but never above 80. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 30 2011
On 01/30/2011 12:55 PM, Tomek Sowiński wrote:Andrej Mitrovic napisał:Agreed. FWIW I'm ready to go with anything that Phobos heavyweights vote.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. Andrei
Jan 30 2011
Tomek Sowiński Wrote:What is your preferred *maximum* length for a line of D code? (please reply with a number only)110
Jan 30 2011
Tomek Sowi=C5=84ski napisa=C5=82:What is your preferred *maximum* length for a line of D code? (please rep=ly with a number only) 120. --=20 Tomek
Jan 30 2011
Tomek Sowiński wrote:What is your preferred *maximum* length for a line of D code? (please reply with a number only)6.022e+23
Jan 30 2011
Walter Bright napisa=C5=82:eply with a number only) =20What is your preferred *maximum* length for a line of D code? (please r==20 6.022e+23That's a whole mole of code! ;-) --=20 Tomek
Jan 30 2011
On Sun, 30 Jan 2011 14:47:26 -0500, Walter Bright <newshound2 digitalmars.com> wrote:Tomek Sowiński wrote:It's amazing that D does so much, and to top it off, it's only ONE LINE OF CODE! -SteveWhat is your preferred *maximum* length for a line of D code? (please reply with a number only)6.022e+23
Jan 31 2011
Tomek Sowi=C5=84ski <just ask.me> wrote:Andrej Mitrovic napisa=C5=82:If you really want to set up a column limit that *everyone* has to =t =abide to, then make a poll to see what everyone can agree on.Actually that's a splendid idea. Let's take it easy. Regardless of tha=silly beef I'm really curious what distribution will emerge. What is your preferred *maximum* length for a line of D code? (please ==reply with a number only)80 columns of code. Indents may change that slightly. -- = Simen
Jan 30 2011
Tomek Sowiński Wrote:Andrej Mitrovic napisał: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.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
Jan 30 2011
I think that putting an artificial limit is incredibly stupid. Haven't anyone here learned the "No magic numbers" rule?!?! Walter correctly pointed out that it's harder to read long rows, however, unlike printed text and ancient terminals, current display technology is much more dynamic. Font size, zoom level, screen form-factor, window size, resolution, etc means that each person can configure his own individual optimal view. As the OP said, use word wrap and adjust your editor window width/font size/zoom level/etc to your liking. If your editor does not support this "new" feature, go get a new editor and don't bother other people with different preferences. Stop forcing this moronic "one size fits all" attitude on everyone.I agree, but i guess they are talking about standard library.
Jan 30 2011
so 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. ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which is by far one of worst ever. "new-age" scripting languages such as python and Ruby and languages that were designed to be readable by humans such as Smalltalk.I think that putting an artificial limit is incredibly stupid. Haven't anyone here learned the "No magic numbers" rule?!?! Walter correctly pointed out that it's harder to read long rows, however, unlike printed text and ancient terminals, current display technology is much more dynamic. Font size, zoom level, screen form-factor, window size, resolution, etc means that each person can configure his own individual optimal view. As the OP said, use word wrap and adjust your editor window width/font size/zoom level/etc to your liking. If your editor does not support this "new" feature, go get a new editor and don't bother other people with different preferences. Stop forcing this moronic "one size fits all" attitude on everyone.I agree, but i guess they are talking about standard library.
Jan 30 2011
foobar wrote:ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which list and are behind various "new-age" scripting languages such as python and Ruby and languages that were designed to be readable by humans such as Smalltalk.I think you've mixed up libraries with languages. Please rephrase so we know what you're referring to and give specifics.
Jan 30 2011
== Quote from Walter Bright (newshound2 digitalmars.com)'s articlefoobar wrote: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 ERATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which list and are behind various "new-age" scripting languages such as python and Ruby and languages that were designed to be readable by humans such as Smalltalk.I think you've mixed up libraries with languages. Please rephrase so we know what you're referring to and give specifics.
Jan 30 2011
Andrei Alexandrescu Wrote:== Quote from Walter Bright (newshound2 digitalmars.com)'s articleThat'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.foobar wrote: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 ERATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which list and are behind various "new-age" scripting languages such as python and Ruby and languages that were designed to be readable by humans such as Smalltalk.I think you've mixed up libraries with languages. Please rephrase so we know what you're referring to and give specifics.
Jan 30 2011
On 2011-01-31 02:18:26 -0500, foobar <foo bar.com> said:Phobos is a very good product that I for one will never use. Just looking at the one huge page for algorithms is enough to discourage many people.But is Phobos the problem or is the one-page-per-module documentation the problem? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 31 2011
Michel Fortin Wrote:On 2011-01-31 02:18:26 -0500, foobar <foo bar.com> said:Phobos' organization is the problem. If you read the C++ standard you'll see that their description of the stdlib describes <algorithm> as a library. Hence, c++'s design is a single file per library. Phobos does exactly the same mistake. D has a far superior module system that doesn't require this moronic design. Please let's use it. I have a hard time believing that having a separate doc page per function is a better solution than to properly organize the code.Phobos is a very good product that I for one will never use. Just looking at the one huge page for algorithms is enough to discourage many people.But is Phobos the problem or is the one-page-per-module documentation the problem? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 31 2011
On 01/31/2011 01:18 AM, foobar wrote:Andrei Alexandrescu Wrote: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?== Quote from Walter Bright (newshound2 digitalmars.com)'s articleThat'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.foobar wrote: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 ERATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which 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.In addition, you now want to force artificial limits that don't make any sense. You completely miss the most important principle - it doesn't matter how good and efficient your product is if no one's using it. Phobos is a very good product that I for one will never use. Just looking at the one huge page for algorithms is enough to discourage many people.From what I've seen, everyone who advocates D2 mentions std.algorithm as one of its main strengths, and never as a liability. I have difficulty reconciling that signal with one opinion relayed anonymously. Andrei
Jan 31 2011
Andrei Alexandrescu Wrote:On 01/31/2011 01:18 AM, foobar wrote: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.Andrei Alexandrescu Wrote: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?== Quote from Walter Bright (newshound2 digitalmars.com)'s articleThat'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.foobar wrote: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 ERATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which 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.In addition, you now want to force artificial limits that don't make any sense. You completely miss the most important principle - it doesn't matter how good and efficient your product is if no one's using it. Phobos is a very good product that I for one will never use. Just looking at the one huge page for algorithms is enough to discourage many people.From what I've seen, everyone who advocates D2 mentions std.algorithm as one of its main strengths, and never as a liability. I have difficulty reconciling that signal with one opinion relayed anonymously. Andrei
Jan 31 2011
On 01/31/2011 07:38 PM, foobar wrote:I keep taking about the API while you keep talking about its implementation. D needs to cater for different kinds of people, not just American born C++ guru programmers, but a diverse community of programmers with different programming backgrounds (that includes web developers that only learned scripting languages), different nationalities (They don't need to have native level English capabilities including understanding of American culture and insider jokes), different OS users (not just *nix geeks), etc.+++ (insider jokes are excluding jokes) (I'm unsure about tolerating Heineken drinkers, though) Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:On 01/31/2011 01:18 AM, foobar wrote: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. -SteveYou 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.
Jan 31 2011
On 1/31/11 1:07 PM, Steven Schveighoffer wrote:On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote: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). AndreiOn 01/31/2011 01:18 AM, foobar wrote: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. -SteveYou 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.
Jan 31 2011
Andrei Alexandrescu wrote:We'd eliminate the unstructured "jump to" section and we create the grouping by hand (sigh).Maybe we can get the best of both worlds: how about a "Group:" or "Tags:" section in the ddoc that a program could automatically pull out to make the listing? I think we can do that without modifying the compiler. Scanning the text in javascript or whatever for that section would be simple enough.
Jan 31 2011
On 1/31/11 1:22 PM, Adam Ruppe wrote:Andrei Alexandrescu wrote:Great idea! AndreiWe'd eliminate the unstructured "jump to" section and we create the grouping by hand (sigh).Maybe we can get the best of both worlds: how about a "Group:" or "Tags:" section in the ddoc that a program could automatically pull out to make the listing? I think we can do that without modifying the compiler. Scanning the text in javascript or whatever for that section would be simple enough.
Jan 31 2011
On Monday, January 31, 2011 11:13:40 Andrei Alexandrescu wrote:On 1/31/11 1:07 PM, Steven Schveighoffer 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, 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 DavisOn Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote: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).On 01/31/2011 01:18 AM, foobar wrote: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. -SteveYou 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.
Jan 31 2011
On 2011-01-31 14:13:40 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> said:Let's fix it! I'm thinking along the lines of finding some broad groups, e.g. Searching find until mismatch startsWith ... Sorting sort partialSort partition ... Set operations setUnion setDifference ... ...? We'd eliminate the unstructured "jump to" section and we create the grouping by hand (sigh).Please do. Grouping by task is very useful when you're searching for a particular function. That said, it'd help if Ddoc could help too... For documenting Objective-C files I have made my own documentation generator (written in D!) which gives you this kind of output: <http://michelf.com/projects/asounding/reference/class-ASNEngine.html> For generating the above page, all I have to do in my header file is to specify which documentation group each function belongs to and the rest is done automatically. Here's the corresponding header file; notice I only have to write a group directive when the group changes, not for each function: <http://michelf.com/docs/tests/ASNEngine.h> -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 31 2011
On 01/31/2011 08:32 PM, Jonathan M Davis wrote:At minimum, it needs to be smarter about user-defined types. The functions for a class or struct should not be grouped with free functions. They should be grouped with the type that they're in._That_, at least, should be automatable,Isn't that's what namespaces are for? A big advantage of OO-like coding (or custom namespaces) for std modules.but it wouldn't help any with std.algorithm, since it's full of free functions (though it would be a big improvement for std.datetime).See above. Why aren't many algorithms implemented in the modules defining what they operate on? Sure, "free" algorithms precisely are meant ot be generic. But in most cases there is, or could (should) be, a top-level type. In particular, don't many algos work on ranges? Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
Steven Schveighoffer wrote:I think the main problem is with ddoc. This, from std.algorithm is a f**king mess IMO:Note that that is generated through some short javascript in the html header. I remember writing a brief change to that to make it look a lot better (organized into a simple grid) but it seems to be lost now. I'd be willing to redo it though. Need to make a github account to get commit power back, but if there's agreement on changes, I'll make them.
Jan 31 2011
On Mon, 31 Jan 2011 14:17:50 -0500, Adam Ruppe <destructionator gmail.com> wrote:Steven Schveighoffer wrote: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). -SteveI think the main problem is with ddoc. This, from std.algorithm is a f**king mess IMO:Note that that is generated through some short javascript in the html header. I remember writing a brief change to that to make it look a lot better (organized into a simple grid) but it seems to be lost now. I'd be willing to redo it though. Need to make a github account to get commit power back, but if there's agreement on changes, I'll make them.
Jan 31 2011
Steven Schveighoffer wrote:I'm all for it (voice with no authority).Here it is with the brief css change to put it in a grid: http://arsdnet.net/d-web-site/std_algorithm.html It's a very small change that, to me, makes a huge difference.I really think ddoc needs to be revamped to do more in this area, along with cross-linking.Agreed. Though, if we can't change the compiler, we could do this with a macro too. Use ($func std.file.read) to read a file. And the $func macro can simply link it to the right place, or to something like my own dpldocs.info/std.file.read to redirect/search for the referenced item. Say... I wonder... there's already a class "d_psymbol" in the html, I could do this in the script too, or maybe with a simple tweak to the existing macro. I did it in script on that same link. I'm not in love with it, but it proves the concept is easy enough with what we already have.
Jan 31 2011
Say... I wonder... there's already a class "d_psymbol" in theNo, I'm wrong. That's only the currently referenced symbol. No point linking back to itself! Gotta go back to the drawing board for good cross referencing.
Jan 31 2011
On Mon, 31 Jan 2011 15:38:50 -0500, Adam Ruppe <destructionator gmail.com> wrote:Steven Schveighoffer wrote:It does help, but I was kind of hoping for something that shows the structure. 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'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 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). -SteveI 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.
Jan 31 2011
Am 31.01.2011 22:06, schrieb Steven Schveighoffer:On Mon, 31 Jan 2011 15:38:50 -0500, Adam Ruppe <destructionator gmail.com> wrote: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.htmlSteven Schveighoffer wrote: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'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.
Jan 31 2011
Steven Schveighoffer wrote:It does help, but I was kind of hoping for something that shows the structure.Those relationships are in the HTML too.... try it now: http://arsdnet.net/d-web-site/std_algorithm.html (I know it needs some work still, I'm just sick of Javascript after spending 20 minutes tracking down a bug caused by me using the same variable name twice! Gah! And wow do I miss foreach.)
Jan 31 2011
Adam Ruppe:(I know it needs some work still, I'm just sick of Javascript after spending 20 minutes tracking down a bug caused by me using the same variable name twice! Gah! And wow do I miss foreach.)A good C lint is very good at spotting that kind of bugs. There are lints for JS too, but I don't know if they are able to spot this kind of bug. Bye, bearophile
Jan 31 2011
On Mon, 31 Jan 2011 18:08:53 -0500, Adam Ruppe <destructionator gmail.com> wrote:Steven Schveighoffer wrote:Yes, it's in the right direction, but it does need work. BTW, foreach is available, but you can't use it on arrays (HAHAHAHA!) it's one of the reasons I use objects in JS most of the time instead of arrays: for(key in obj) { var elem = obj[key]; /* use elem */ } of course, I'd only recommend this on objects you have used as arrays. What I mean by that is, you don't have any methods or prototypes, because those will also be iterated. https://developer.mozilla.org/en/JavaScript/Reference/Statements/for...in -SteveIt 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.)
Feb 01 2011
Walter Bright Wrote:foobar wrote: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?ATM, Phobos ranks extremely poorly in this regard. Far worse than C++ which list and are behind various "new-age" scripting languages such as python and Ruby and languages that were designed to be readable by humans such as Smalltalk.I think you've mixed up libraries with languages. Please rephrase so we know what you're referring to and give specifics.
Jan 30 2011
foobar wrote:Java (the language itself) is mediocre at best but the Java standard libraries are excellent with comprehensive usable documentation to boot. Phobes is half a notch above c++ stdlib which is the worst ever from a usability and readability perspective. Are we still using G-d files? really?Please take a module or function in the phobos documentation, and rewrite it to how you think it should be done and post it, as an example of how to do it right. We welcome such help.
Jan 30 2011
On 01/30/2011 10:18 PM, foobar wrote:Right, so does that mean it should be made_less_ readable by a diverse community of people? I have no issue with any style Andrei or others use when they code for themselves, be it 10 characters per row or 1000. I do place a MUCH higher weight on making the stdlib readable and accessible for a large range of diverse people with different cultures, languages, traditions, eye-sight, screen sizes, and preferred beer flavors.There is only one true beer flavor.ATM, Phobos ranks extremely poorly in this regard.Sure. How can we ensure Phobos contributors drink Pilsner Urquell? http://en.wikipedia.org/wiki/Pilsner_Urquell Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
foobar wrote:Tomek Sowi=C5=84ski Wrote: =20ide to, then make a poll to see what everyone can agree on.Andrej Mitrovic napisa=C5=82:If you really want to set up a column limit that *everyone* has to ab=t silly beef I'm really curious what distribution will emerge.Actually that's a splendid idea. Let's take it easy. Regardless of tha=reply with a number only)What is your preferred *maximum* length for a line of D code? (please =anyone here learned the "No magic numbers" rule?!?!--=20 Tomek=20 I think that putting an artificial limit is incredibly stupid. Haven't ==20 Walter correctly pointed out that it's harder to read long rows, howeve=r, unlike printed text and ancient terminals, current display technology = is much more dynamic.=20Font size, zoom level, screen form-factor, window size, resolution, etc=means that each person can configure his own individual optimal view.=20=20 As the OP said, use word wrap and adjust your editor window width/font =size/zoom level/etc to your liking.=20If 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.=20Do you know of any editor that can word wrap *while respecting indentation*? Any editor I know will wrap to the first column, which renders indentation pointless in the presence of long lines... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 30 2011
Jérôme M. Berger Wrote:foobar wrote: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").Tomek Sowiński 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 -- mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.frAndrej Mitrovic napisał: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.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
Jan 30 2011
On 2011-01-30 15:32:45 -0500, "Jérôme M. Berger" <jeberger free.fr> said:Do you know of any editor that can word wrap *while respecting indentation*?Xcode. Wrapped line are indented 2 spaces more than the true indent of the line. Given that indentation is generally done by a factor of 4 spaces, it's really easy to spot a wrapped line. This is configurable, of course. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jan 30 2011
Michel Fortin wrote:On 2011-01-30 15:32:45 -0500, "J=C3=A9r=C3=B4me M. Berger" <jeberger fr=ee.fr> said:=20Do you know of any editor that can word wrap *while respecting indentation*?=20 Xcode. =20 Wrapped line are indented 2 spaces more than the true indent of the line. Given that indentation is generally done by a factor of 4 spaces,=it's really easy to spot a wrapped line. This is configurable, of cours=e.=20So that makes one very platform-specific editor. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 31 2011
Jérôme M. Berger wrote:Do you know of any editor that can word wrap *while respecting indentation*? Any editor I know will wrap to the first column, which renders indentation pointless in the presence of long lines...Word-wrapping code is a bad idea.
Jan 30 2011
Walter Bright wrote:J=C3=A9r=C3=B4me M. Berger wrote:My point exactly. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.frDo 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...=20 Word-wrapping code is a bad idea.
Jan 31 2011
On 01/30/2011 09:32 PM, "Jérôme M. Berger" wrote:foobar wrote:Yop, geany :-) http://en.wikipedia.org/wiki/Geany Denis -- _________________ vita es estrany spir.wikidot.comTomek Sowiński 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... JeromeAndrej Mitrovic napisał: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.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
Jan 31 2011
spir wrote:On 01/30/2011 09:32 PM, "J=C3=A9r=C3=B4me 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. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.frDo you know of any editor that can word wrap *while respecting indentation*? Any editor I know will wrap to the first column, which renders indentation pointless in the presence of long lines... Jerome=20 Yop, geany :-) http://en.wikipedia.org/wiki/Geany =20
Jan 31 2011
On 01/31/2011 11:33 PM, "Jérôme M. Berger" wrote:Nope it wraps to the same indent level as the original line, so you do not see at a glance that a line is wrapped.It shows it's a wrapped line using a dedicated "wrapping-arrow" sign. I never use this feature for code, though. Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
2011/1/31 spir <denis.spir gmail.com>:On 01/30/2011 09:32 PM, "J=C3=A9r=C3=B4me M. Berger" wrote:*while respecting=C2=A0 =C2=A0 =C2=A0 =C2=A0Do you know of any editor that can word wrap =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.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
Jan 31 2011
On 1/30/11 7:55 PM, Tomek Sowiński wrote:Andrej Mitrovic napisał:80If 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)
Jan 30 2011
Am 30.01.2011 19:55, schrieb Tomek Sowiński:Andrej Mitrovic napisał:about 100 (don't care if its 2 chars more to fit a ");" or something like that)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)
Jan 30 2011
Tomek Sowiński Wrote:Andrej Mitrovic napisał:--- 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???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
Jan 30 2011
"Tomek Sowinski" <just ask.me> wrote in message news:20110130195553.5db1ed2e Las-Miodowy...What is your preferred *maximum* length for a line of D code? (please reply with a number only)I generally try to stick to about 80 as a rule-of-thumb, but I'll go up to around 100 (or more in rare cases, but in those cases I cringe) when I think breaking it would uglify it too much. So I don't really have an exact number.
Jan 30 2011
On Sunday 30 January 2011 10:55:53 Tomek Sowi=C5=84ski wrote:Andrej Mitrovic napisa=C5=82:lyIf 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.=20 Actually that's a splendid idea. Let's take it easy. Regardless of that silly beef I'm really curious what distribution will emerge. =20 What is your preferred *maximum* length for a line of D code? (please rep=with a number only)My _preferred_ limit would be no limit but that if your line is getting to = be=20 around 100 - 120 characters, then you should really look at breaking it up.= If I=20 had to have a hard limit, I'd then pick 120 so that it would be rare that I= 'd=20 have to worry about it, and if I had to compromise a bit because others tho= ught=20 that that was too long, then I'd pick 100. Particularly when you get much=20 indentation going on and _especially_ when you have descriptive names, it's= =20 pretty easy to hit 80 characters, and it definitely feels overly limiting.= =20 Personally, I find that it harms code formatting readability to consistentl= y be=20 forced to break up lines due to an 80 character limit. It's especially bad = when=20 you treat it as an absolute, hard limit, and things like the semicolon at t= he=20 end of the line make it so that you hit 81 characters and have to break up = the=20 line. So, if I have any say on the matter, I'd say 100 - 120 characters max if we= 're=20 putting a limit on it. I do feel very strongly about coding style, because = I=20 hate having to twist how I write code to fit another style (though fortunat= ely,=20 my natural style is at least close to how Phobos generally is). However, it= is=20 normal to have to adjust your coding style on some level when working in a= =20 group. I don't want to make a big stink about it either. 80 characters per = line=20 _is_ one of the worst conventions out there IHMO, but if that's what we go = with,=20 then I'll do it. I suspect that the major reason that many of my lines tend to go over 80=20 characters is that I almost always pick very descriptive variable and funct= ion=20 names, and that makes lines longer. It could be that if a programmer who fa= vored=20 short variable names were to write the same code that I typically do, then= =20 they'd almost always stay within 80 characters. In any case, I vote 100 - 120 characters for the limit, and I'd _really_ li= ke to=20 not be restricted to 80 characters, but if that's what I have to do, then t= hat's=20 what I have to do. =2D Jonathan M Davis
Jan 30 2011
Tomek Sowiński wrote:Andrej Mitrovic napisał:100 (8 levels of 4-space indent, + 65 characters). Second preference: 110.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)
Jan 31 2011
90 as a rule of thumb with some exceptions.
Jan 31 2011
Walter Bright Wrote:foobar wrote: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.Java (the language itself) is mediocre at best but the Java standard libraries are excellent with comprehensive usable documentation to boot. Phobes is half a notch above c++ stdlib which is the worst ever from a usability and readability perspective. Are we still using G-d files? really?Please take a module or function in the phobos documentation, and rewrite it to how you think it should be done and post it, as an example of how to do it right. We welcome such help.
Jan 31 2011
foobar wrote:Walter Bright Wrote:Please take a Phobos module or a function, and rewrite its API to demonstrate your point.foobar wrote: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.Java (the language itself) is mediocre at best but the Java standard libraries are excellent with comprehensive usable documentation to boot. Phobes is half a notch above c++ stdlib which is the worst ever from a usability and readability perspective. Are we still using G-d files? really?Please take a module or function in the phobos documentation, and rewrite it to how you think it should be done and post it, as an example of how to do it right. We welcome such help.
Jan 31 2011
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.
Jan 31 2011
On Sun, 30 Jan 2011 13:55:53 -0500, Tomek Sowiński <just ask.me> wrote:Andrej Mitrovic napisał:80 -SteveIf 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)
Jan 31 2011
Tomek Sowi=C5=84ski napisa=C5=82:Actually that's a splendid idea. Let's take it easy. Regardless of that s=illy beef I'm really curious what distribution will emerge.=20 What is your preferred *maximum* length for a line of D code? (please rep=ly with a number only) =20 Alright, I'm wrapping up this toy study. Two things before the numbers come: - A few respondents gave 2 numbers, one "reasonable", the other "if I real= ly have to". I took the latter (larger) number as I was after maximum lengt= h, something usable as a setting for a repository hook. - 2 respondents said "no limit". I excluded them from computations, albeit= it's a valid answer. 1 respondent answered "1 mole" which I also excluded = as a 22-order-of-magnitude outlier.lengths =3D c(80, 80, 110, 120, 80, 80, 100, 100, 120, 110, 90) summary(lengths)Min. 1st Qu. Median Mean 3rd Qu. Max.=20 80.00 80.00 100.00 97.27 110.00 120.00=20[1] 16.18080quantile(lengths, c(.1, .25, .5, .75, .9))10% 25% 50% 75% 90%=20 80 80 100 110 120=20library(moments)[1] 0.1645005[1] 11 --=20 Tomek
Jan 31 2011
Tomek Sowi=C5=84ski napisa=C5=82:Alright, I'm wrapping up this toy study. Two things before the numbers co=me:=20 - A few respondents gave 2 numbers, one "reasonable", the other "if I re=ally have to". I took the latter (larger) number as I was after maximum len= gth, something usable as a setting for a repository hook.- 2 respondents said "no limit". I excluded them from computations, albe=it it's a valid answer. 1 respondent answered "1 mole" which I also exclude= d as a 22-order-of-magnitude outlier. Steven came in late with his datapoint, so once again:lengths =3D c(80, 80, 110, 120, 80, 80, 100, 100, 120, 110, 90, 80) =20 summary(lengths)Min. 1st Qu. Median Mean 3rd Qu. Max.=20 80.00 80.00 95.00 95.83 110.00 120.00=20=20[1] 16.21354=20 quantile(lengths, c(.1, .25, .5, .75, .9))10% 25% 50% 75% 90%=20 80 80 95 110 119=20=20[1] 0.3121957=20[1] 12 --=20 Tomek
Jan 31 2011
Tomek Sowiński wrote:1 respondent answered "1 mole" which I also excluded as a 22-order-of-magnitude outlier.What kind of a jerk is that respondent?
Jan 31 2011
On 01/30/2011 07:55 PM, Tomek Sowiński wrote:Andrej Mitrovic napisał:99 Denis -- _________________ vita es estrany spir.wikidot.comIf 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)
Jan 31 2011
Andrei Alexandrescu Wrote:On 1/31/11 1:07 PM, Steven Schveighoffer wrote:Excellent!On Mon, 31 Jan 2011 12:09:01 -0500, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote: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 ... ...?On 01/31/2011 01:18 AM, foobar wrote: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. -SteveYou 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.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 compatibilityAndrei
Jan 31 2011
Adam Ruppe Wrote:Steven Schveighoffer wrote:var foo = [bar, baz]; foo.forEach(function (elem) { elem.doSomthing(); }); Available since version 1.6It 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.)
Feb 01 2011
On 30/01/2011 18:55, Tomek Sowiński wrote:Andrej Mitrovic napisał:My preferred maximum length for Java is 120. I haven't coded much D to have an opinion about the length for D, but I would suspect it would be more or less the same: Yes, on many things D code lines will have shorter length than Java (you can have free functions, you have the "auto" declarator for variables, you have scope statements, etc.), but on other things D code might have more (const/immutable and other attributes, like pure, safe, etc., etc.). But in any case this poll is only an informative curiosity. It does not make sense for it to affect Phobos's style standards, it is the (weighted) opinion of the Phobos/Druntime developers that should matter, of course. -- Bruno Medeiros - Software EngineerIf 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)
Feb 10 2011
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message news:ii46g5$1g66$1 digitalmars.com...The unittest topic is about to get derailed so I want to continue this silly discussion here. Wheres Nick? I want to see the CRT vs LCD discussion heated up again with Andrei claiming that LCDs are so Godlike but yet claims 80 columns is enough for everyone.Heh :) This is what I do: My editor shows a faint vertical line at the end of column 80. I use that as a rough general guideline, but not a hard-and-fast rule. I agree with Andrei that the longer a line of code or text gets beyond 80 columns, the harder it gets to read. Heck, I had one co-worker once who had his code total-fullscreen on a 16:9 with lines extending all the way to the end: it was horrible. I do think you can go a little bit further than 80 columns while still being perfectly readable, but I think 80 is a sensible time-honered rule of thumb for maximum compatibility as long as you're not too strict about it. One other reason to not be too strict about the 80-column guideline is elastic tabstops. With those, propotional fonts become perfectly sensible to use for code, and then "80-columns" inherently becomes "fuzzy". Minor side note: Vertical space being much more important than horizontal for both code and other text is the primary reason I'd never consider getting a widescreen monitor. (For TV's I can go either way, though, as long as the non-widescreen can properly scale/letterbox widescreen signals.)80 colums is an artifact of the old age. Just like the preprocessor is an artifact of the C language. And many other old things are artifacts. There's no reason to keep these artifacts around anymore.Like Andrei said, it may not be a technical limitation anymore, but it is still a human limitation. Any remotely modern computer is perfectly capable of speeding up voice playback by 10x, but nobody does it that fast because the human user is the limiting factor. Of course, if someone said "let's use 90 or 100 lines as the guideline", I wouldn't object at all. But 80 has a lot of history behind it, and is therefore much easier to agree on as a rough standard, and it does still work out, again, as long as you're not too strict about it. (And it doesn't hurt that I'm a fan of both powers-of-two and the 1980's, so there's that nice warm psychological connection ;) )A couple of things, Andrei: 1. 80 colums is way too restrictive. 80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware. Who will run a brand new language like D in a freakin' Terminal?There's a lot of text-mode junkies out there. And for Unix users, there may be times when they need to work in pure text-mode. Also, it's common to have a million other frames showing (see a typical Eclipse setup), so that can really limit how many columns people have available, too.If you want to see more files on the screen, get multiple screens. Is Facebook running out of money, can't they afford a few monitors for the C++ guru? Yes, I know you're not allowed to comment on that one. :)He probably already has as many as his cubicle will hold ;)2. A widescreen aspect ratio causes less eye strain. Wider code means the same.That's just plain rediculous. I don't know where you got that. *Maybe* for watching video, but certainly not text.3. Less columns means more rows. And generally coders *hate* it when they can't see a function that fits on a single screen. They hate having to scroll up and down. This common syntax form is a proof of that: void main() { void foo() { while (true) { if (done) { } } } } I find that unpleasant to read. Not impossible, but unpleasant. I can live with it though, but if you limit code to 80 limits that's going to become a mess to read.FWIW, I'd write that this way: void main() { void foo() { while(true) if(done) { } } } I'm a big fan of "stacking" flow-control statements like that whenever the outer statements don't have anything else in their body. Like this (stupid example): // Draw funny design (and yes, this could be optimized better) if(shouldRefresh) foreach(int x; 0..width) foreach(int y; 0..height) if(x ^ y < width*height / 2) buffer[x + y*width] = palette[(x+y) % $]; Instead of something more like: // Draw funny design (and yes, this could be optimized better) if(shouldRefresh) { foreach(int x; 0..width) { foreach(int y; 0..height) { if(x ^ y < width*height / 2) buffer[x + y*width] = palette[(x+y) % $]; } } }3. It's 2010. Does your GNU/emacs still not support wrapping lines by word boundaries? Scite had this since the '90s, and that's not even an advanced editor. Vim supports word wrapping as well. Heck, I'm pretty sure you can customize it to wrap on whatever boundary you want to (although I'm only speculating, but pretty much everything in Vim is customizable). You can even customize how your cursor reacts if it's on an 'artificial' new line, one that has been wrapped.That's not a bad point. But if a line is that long, it's going to be difficult to read anyway without doing it manually and taking syntax into acount: auto str = join(formatStr1, formatStr2, formatStr3, formatStr4, formatStr5).format(someValue1, someValue2, cond? "" : someStr, someValue3 + someValue4); Vs: auto str = join( formatStr1, formatStr2, formatStr3, formatStr4, formatStr5 ) .format( someValue1, someValue2, cond? "" : someStr, someValue3 + someValue4 ); I find the second one perfectly readable, but I can't even make head or tails of the first one, and I just wrote it a few seconds ago!4. Just how many files do you want to edit at a single time on the screen? We're not really multitasking beings, you know.I'm rarely editing only one file at a time. Frequently a whole handful. (But I "Ctrl-Tab" through them.)If you really want to set up a column limit that *everyone* has to abide to, then make a poll to see what everyone can agree on. I don't see why everyone has to cater to your rules only, regardless of what your professional experience might be. You're a big contributor to Phobos, but you're not the only one. I tend to believe that D is (or should be) a community effort, so please don't hijack D away from the community by forcing your own rules down to everyone else.Sounds fair. (But I'm not a Phobos dev, so my opinion on that is probably irrelevent.)
Jan 30 2011
Nick Sabalausky wrote:An elegant width, from a more civilized age.80 colums is an artifact of the old age.Any remotely modern computer is perfectly capable of speeding up voice playback by 10x, but nobody does it that fast because the human user is the limiting factor.People who use screen readers often crank up the playback rate to 2x. The software adjusts the pitch so it doesn't sound like the Chipmunks. I've often wondered why DVRs don't do this (I've sent the suggestion to Tivo, they ignored me). I'd like the option to play the news (or other talk shows) at a faster rate, with pitch adjustment. I've found I can watch Tivo at 3x with the closed captioning on, and can almost keep up. The problem with DVRs at any fast forward speed is they turn the sound off! Grrrr. A golden opportunity missed. I'd also love it if youtube etc. did this. It's so boring looking at youtube presentations because they talk so slow. I'd love a double speed youtube viewing option. Remember I posted this in case some troll tries to patent it.
Jan 30 2011
Walter:Remember I posted this in case some troll tries to patent it.I sometimes see&hear documentaries at 140-160% speed. Bye, bearophile
Jan 30 2011
"Walter Bright" <newshound2 digitalmars.com> wrote in message news:ii4p8u$2ico$1 digitalmars.com...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.An elegant width, from a more civilized age.80 colums is an artifact of the old age.Any remotely modern computer is perfectly capable of speeding up voice playback by 10x, but nobody does it that fast because the human user is the limiting factor.People who use screen readers often crank up the playback rate to 2x. The software adjusts the pitch so it doesn't sound like the Chipmunks. I've often wondered why DVRs don't do this (I've sent the suggestion to Tivo, they ignored me). I'd like the option to play the news (or other talk shows) at a faster rate, with pitch adjustment. I've found I can watch Tivo at 3x with the closed captioning on, and can almost keep up. The problem with DVRs at any fast forward speed is they turn the sound off! Grrrr. A golden opportunity missed. I'd also love it if youtube etc. did this. It's so boring looking at youtube presentations because they talk so slow. I'd love a double speed youtube viewing option. Remember I posted this in case some troll tries to patent it.
Jan 30 2011
Nick Sabalausky wrote:I wish someone would finally just patent getting patents. (IBM's come close from what I hear, but it's not quite there yet.) That's probably the only way the US will ever be rid of the dammed things. Heck, with the USPTO being as grossly incompetent as it is, it would probably be granted: it would just have to be written in a sufficiently ultra-pedantic style.I agree that patents are a blight on the industry.
Jan 30 2011
On 01/30/2011 04:29 PM, Nick Sabalausky wrote:Minor side note: Vertical space being much more important than horizontal for both code and other text is the primary reason I'd never consider getting a widescreen monitor.Widescreen monitors are awesome as an alternative to dual-screen monitors. I liked the idea of being able to compare stuff side-by-side with dual screens, but never liked the implementation. Too much fussing around and an ugly gap in the middle. As for vertical space, I just made sure the monitor I bought had as much or more than the old one it replaced.
Jan 30 2011
"Jeff Nowakowski" <jeff dilacero.org> wrote in message news:ii4rdu$2lvc$1 digitalmars.com...On 01/30/2011 04:29 PM, Nick Sabalausky wrote:Yea, not bad at that.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.I'm typically limited more horizontally than vertically, so replacing a non-widescreen with a widescreen that's at least as tall would likely mean getting one that's too wide to fit.
Jan 30 2011
On 01/30/2011 10:29 PM, Nick Sabalausky wrote:void main() { void foo() { while(true) if(done) { } } } I'm a big fan of "stacking" flow-control statements like that whenever the outer statements don't have anything else in their body. Like this (stupid example): // Draw funny design (and yes, this could be optimized better) if(shouldRefresh) foreach(int x; 0..width) foreach(int y; 0..height) if(x ^ y< width*height / 2) buffer[x + y*width] = palette[(x+y) % $]; Instead of something more like: // Draw funny design (and yes, this could be optimized better) if(shouldRefresh) { foreach(int x; 0..width) { foreach(int y; 0..height) { if(x ^ y< width*height / 2) buffer[x + y*width] = palette[(x+y) % $]; } } }Nice idea :-) Really makes sense, imo. Denis -- _________________ vita es estrany spir.wikidot.com
Jan 31 2011
On 30/01/2011 17:17, Andrej Mitrovic wrote: <snip>80 colums is an artifact of the old age. Just like the preprocessor is an artifact of the C language. And many other old things are artifacts. There's no reason to keep these artifacts around anymore.Other than, as you begin to say, the difficulty in deciding on where to move the line to.A couple of things, Andrei: 1. 80 colums is way too restrictive. 80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware. Who will run a brand new language like D in a freakin' Terminal?For all I know, people probably still do run the D compiler in the terminal app on Unix-like systems.Have you ever heard of the expression "limitations boost creativity"? That can be considered a good thing, if creativity is what you're after. In code, it's not. You're looking for clarity in code. 80 column limitations are good for C obfuscation contests and nothing else. 80 columns means people are going to *work around* the limit, by using hacks and workarounds to make everything fit in place. Do you really believe that programmers are going to spend any time at all thinking: *"oh this line doesn't fit on 80 columns. I should now spend some time thinking about how to improve and rewrite the design of my code. 80 columns really is the golden ration"*?For all I know, Fortran programmers probably still do this kind of stuff all the time. I guess the designers of Fortran 90 for some reason thought it was right to "protect" programmers by keeping a line length limit, though they did at least increase the limit to 132. Does anyone here know how Fortran 95, 2003 and 2008 compare? <snip>3. It's 2010. Does your GNU/emacs still not support wrapping lines by word boundaries? Scite had this since the '90s, and that's not even an advanced editor. Vim supports word wrapping as well.But automatic word wrapping is usually designed to be used on prose, not program code. Do those programs have a word wrapping algorithm that makes program code look good? <snip>If you really want to set up a column limit that *everyone* has to abide to, then make a poll to see what everyone can agree on.<snip> Therein lies the problem - in this day and age, everyone's screen is different, and everyone's needs are different. Even if we can get people to agree on a limit of 100 in this day and age, it might not suit the programmers of the future. After all, OUAT people managed with the 32 columns of the ZX Spectrum. Stewart.
Jan 30 2011
Stewart Gordon Wrote:Therein lies the problem - in this day and age, everyone's screen is different, and everyone's needs are different. Even if we can get people to agree on a limit of 100 in this day and age, it might not suit the programmers of the future. After all, OUAT people managed with the 32 columns of the ZX Spectrum. Stewart.That's why I'm opposed to *any* artificial limit as proposed by Andrei.
Jan 30 2011
On 01/31/2011 01:48 AM, foobar wrote:Stewart Gordon Wrote: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. AndreiTherein lies the problem - in this day and age, everyone's screen is different, and everyone's needs are different. Even if we can get people to agree on a limit of 100 in this day and age, it might not suit the programmers of the future. After all, OUAT people managed with the 32 columns of the ZX Spectrum. Stewart.That's why I'm opposed to *any* artificial limit as proposed by Andrei.
Jan 31 2011
Am 31.01.2011 00:17, schrieb Stewart Gordon:On 30/01/2011 17:17, Andrej Mitrovic wrote: <snip>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/whatever80 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.
Jan 31 2011
"Daniel Gibson" <metalcaedes gmail.com> wrote in message news:ii67i0$1vf2$2 digitalmars.com...Am 31.01.2011 00:17, schrieb Stewart Gordon: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...For all I know, people probably still do run the D compiler in the terminal app on Unix-like systems.1. The D-Compiler doesn't care if the code fits in your terminal 2. You can have bigger terminals than 80x25 - just resize your xterm/rxvt/gnome-terminal/putty/whatever
Jan 31 2011
On 01/30/2011 07:17 PM, Andrej Mitrovic wrote:The unittest topic is about to get derailed so I want to continue this silly discussion here. Wheres Nick? I want to see the CRT vs LCD discussion heated up again with Andrei claiming that LCDs are so Godlike but yet claims 80 columns is enough for everyone. 80 colums is an artifact of the old age. Just like the preprocessor is an artifact of the C language. And many other old things are artifacts. There's no reason to keep these artifacts around anymore. A couple of things, Andrei: 1. 80 colums is way too restrictive. 80 columns wasn't determined by some scientific method to be a good size for code, it's a product of limitations of the older generation hardware. Who will run a brand new language like D in a freakin' Terminal? Have you ever heard of the expression "limitations boost creativity"? That can be considered a good thing, if creativity is what you're after. In code, it's not. You're looking for clarity in code. 80 column limitations are good for C obfuscation contests and nothing else. 80 columns means people are going to *work around* the limit, by using hacks and workarounds to make everything fit in place. Do you really believe that programmers are going to spend any time at all thinking: *"oh this line doesn't fit on 80 columns. I should now spend some time thinking about how to improve and rewrite the design of my code. 80 columns really is the golden ration"*? If you want to see more files on the screen, get multiple screens. Is Facebook running out of money, can't they afford a few monitors for the C++ guru? Yes, I know you're not allowed to comment on that one. :) 2. A widescreen aspect ratio causes less eye strain. Wider code means the same. It doesn't have to stretch all the way to be effective, but 80 columns is too limiting. Do a Google search and read what people have go say about that. 3. Less columns means more rows. And generally coders *hate* it when they can't see a function that fits on a single screen. They hate having to scroll up and down. This common syntax form is a proof of that: void main() { void foo() { while (true) { if (done) { } } } } I find that unpleasant to read. Not impossible, but unpleasant. I can live with it though, but if you limit code to 80 limits that's going to become a mess to read. 3. It's 2010. Does your GNU/emacs still not support wrapping lines by word boundaries? Scite had this since the '90s, and that's not even an advanced editor. Vim supports word wrapping as well. Heck, I'm pretty sure you can customize it to wrap on whatever boundary you want to (although I'm only speculating, but pretty much everything in Vim is customizable). You can even customize how your cursor reacts if it's on an 'artificial' new line, one that has been wrapped. Isn't technology amazing? 4. Just how many files do you want to edit at a single time on the screen? We're not really multitasking beings, you know. Try using one of your hands and do forward circles, as if it were a wheel. With the other one do backward circles. And now use your foot to draw a circle on the floor. You're end up looking like a clown in seconds, and a bad one at that. Again, people who want to have documentation, and code, and IRC chats in display buy more computer screens. Why should your code have to suffer if you really want to do multiple things all at once? Bottom line: If you really want to set up a column limit that *everyone* has to abide to, then make a poll to see what everyone can agree on. I don't see why everyone has to cater to your rules only, regardless of what your professional experience might be. You're a big contributor to Phobos, but you're not the only one. I tend to believe that D is (or should be) a community effort, so please don't hijack D away from the community by forcing your own rules down to everyone else.I think there is no need to establish a fixed limit. "Avoid long lines" recommendation in the style guide would be enough.
Jan 31 2011
On Monday, January 31, 2011 13:25:16 spir wrote:On 01/31/2011 08:32 PM, Jonathan M Davis wrote: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 DavisAt 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?
Jan 31 2011