Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 19 August 2013 at 22:16:39 UTC, ProgrammingGhost wrote: Is it true? Are you able to read a line (or two) at once? I have been doing it since early school days and was quite surprised to find out later that it is not the common case. Well, when reading technical literature I often come back and re-read some intense paragraphs carefully word-by-word but it is more like fallback. And yes, I do try to organize the code in such way that going quickly up-down through it is possible.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 18 August 2013 at 17:28:16 UTC, Iain Buclaw wrote: On 18 August 2013 18:24, ProgrammingGhost wrote: On Sunday, 11 August 2013 at 18:25:02 UTC, Andrei Alexandrescu wrote: For a column of text to be readable it should have not much more than 10 words per line. Going beyond that forces eyes to scan too jerkily and causes difficulty in following line breaks. This. Also some people can read a line a second because they read downward instead of left to right. Although I heard this through hearsay Probably more like two lines at once, if they are reading a book. Reading code? I reckon you can read downwards on that. :) Is it true? Are you able to read a line (or two) at once?
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 18 August 2013 at 18:33:05 UTC, Dicebot wrote: ... When people expect to get a performance gain from simply using certain language, it just can't end good. Specially because they tend to do the common fallacy of comparing languages instead of implementations.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sun, Aug 18, 2013 at 09:26:45AM +0100, Russel Winder wrote: > On Sun, 2013-08-18 at 01:59 -0400, John Joyus wrote: > > On 08/11/2013 04:22 AM, Walter Bright wrote: > > > http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf > > > > This article claims the "Performance [of D] is equivalent to C". > > > > Is that true? I mean even if D reaches 90% of C's performance, I > > still consider it great because of its productive features, but are > > there any benchmarks done? > > Not a statistically significant benchmark but an interesting data > point: > > C: > > Sequential > pi = 3.141592653589970752 > iteration count = 10 > elapse time = 8.623442 > > C++: > > Sequential > pi = 3.14159265358997075 > iteration count = 10 > elapse = 8.612123967 > > D: > > pi_sequential.d > π = 3.141592653589970752 > iteration count = 10 > elapse time = 8.612256 > > > C and C++ were compiled with GCC 4.8.1 full optimization, D was compiled > with LDC full optimization. Oh go on, let's do it with GDC as well: > > pi_sequential.d > π = 3.141592653589970752 > iteration count = 10 > elapse time = 8.616558 > > > And you are going to ask about DMD aren't you :-) > > pi_sequential.d > π = 3.141592653589970752 > iteration count = 10 > elapse time = 9.495549 > > Remember this is 1 and only 1 data point and not even a sample just a > single data point. Thus only hypothesis building is allowed, no > deductions. But I begin to believe that D is as fast as C and C++ > using GDC and LDC. DMD is not in the execution performance game. [...] This may be merely only a single isolated data point, but it certainly matches my experience with GDC / DMD. I find that gdc -O3 consistently produces code that outperforms code produced by dmd -O -inline -release. As for comparison with C/C++, I haven't really tested it myself so I can't say. But I *will* say that it's far easier to write casual code (i.e., not hand-tuned for performance) in D that has similar performance to the C/C++ equivalent. T -- Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 18 August 2013 at 18:31:17 UTC, Timon Gehr wrote: I guess that's debatably mimicking C behaviour. What behavior do you refer to?
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 18 August 2013 at 18:26:13 UTC, John Colvin wrote: On Sunday, 18 August 2013 at 18:08:58 UTC, Dicebot wrote: Yes, in limited circumstances if you write D like you would write C, you can get comparative performance. I'd say in all cases when you mimic C behavior in D one should expect same or better performance with ldc/gdc unless you hit a bug. array literal allocations. I guess that's debatably a performance bug. I have said "C behavior", not "C syntax". That is the main problem with comparing _language_ performance - stick to same semantics and you are likely to get same performance but it may require quite inconvenient coding style (i.e. working around array literals is a huge pain). So probably it makes more sense to compare idiomatic code. But where are the limits? It is a bit easier with vm-based languages because performance of vm implementation itself does matter and can be compared. Compiled languages with same backend? No idea how to benchmark those properly. When people expect to get a performance gain from simply using certain language, it just can't end good.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 08/18/2013 08:26 PM, John Colvin wrote: On Sunday, 18 August 2013 at 18:08:58 UTC, Dicebot wrote: Yes, in limited circumstances if you write D like you would write C, you can get comparative performance. I'd say in all cases when you mimic C behavior in D one should expect same or better performance with ldc/gdc unless you hit a bug. array literal allocations. I guess that's debatably a performance bug. I guess that's debatably mimicking C behaviour.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 18 August 2013 at 18:08:58 UTC, Dicebot wrote: Yes, in limited circumstances if you write D like you would write C, you can get comparative performance. I'd say in all cases when you mimic C behavior in D one should expect same or better performance with ldc/gdc unless you hit a bug. array literal allocations. I guess that's debatably a performance bug.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
Yes, in limited circumstances if you write D like you would write C, you can get comparative performance. I'd say in all cases when you mimic C behavior in D one should expect same or better performance with ldc/gdc unless you hit a bug.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 18 August 2013 18:24, ProgrammingGhost wrote: > On Sunday, 11 August 2013 at 18:25:02 UTC, Andrei Alexandrescu wrote: >> >> For a column of text to be readable it should have not much more than 10 >> words per line. Going beyond that forces eyes to scan too jerkily and causes >> difficulty in following line breaks. > > > This. > Also some people can read a line a second because they read downward instead > of left to right. Although I heard this through hearsay Probably more like two lines at once, if they are reading a book. Reading code? I reckon you can read downwards on that. :) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 18:25:02 UTC, Andrei Alexandrescu wrote: For a column of text to be readable it should have not much more than 10 words per line. Going beyond that forces eyes to scan too jerkily and causes difficulty in following line breaks. This. Also some people can read a line a second because they read downward instead of left to right. Although I heard this through hearsay
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sun, 18 Aug 2013 06:35:30 -0400 Jeff Nowakowski wrote: > On 08/18/2013 01:59 AM, John Joyus wrote: > > On 08/11/2013 04:22 AM, Walter Bright wrote: > >> http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf > > > > This article claims the "Performance [of D] is equivalent to C". > > > > Is that true? I mean even if D reaches 90% of C's performance, I > > still consider it great because of its productive features, but are > > there any benchmarks done? > > That claim is highly dubious. D's garbage collector is a known > performance bottleneck. Well, but aside from that one thing, people need to keep in mind that D is not dynamic/interpreted/VMed, and does have full low-level capabilities. Those are the things that make C fast, and D shares them. Plus modern C codegen also makes things fast, but D generally uses C backends, so again D shares that, too.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 08/18/2013 01:59 AM, John Joyus wrote: On 08/11/2013 04:22 AM, Walter Bright wrote: http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf This article claims the "Performance [of D] is equivalent to C". Is that true? I mean even if D reaches 90% of C's performance, I still consider it great because of its productive features, but are there any benchmarks done? That claim is highly dubious. D's garbage collector is a known performance bottleneck. I read the paper and didn't see any benchmarks. It was mostly about how they interfaced with a C library. Yes, in limited circumstances if you write D like you would write C, you can get comparative performance. However, the point of D is to allow high-level coding and to make use of garbage collector by default, so that's where the interesting comparisons are to be made.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sun, 2013-08-18 at 01:59 -0400, John Joyus wrote: > On 08/11/2013 04:22 AM, Walter Bright wrote: > > http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf > > This article claims the "Performance [of D] is equivalent to C". > > Is that true? I mean even if D reaches 90% of C's performance, I still > consider it great because of its productive features, but are there any > benchmarks done? Not a statistically significant benchmark but an interesting data point: C: Sequential pi = 3.141592653589970752 iteration count = 10 elapse time = 8.623442 C++: Sequential pi = 3.14159265358997075 iteration count = 10 elapse = 8.612123967 D: pi_sequential.d π = 3.141592653589970752 iteration count = 10 elapse time = 8.612256 C and C++ were compiled with GCC 4.8.1 full optimization, D was compiled with LDC full optimization. Oh go on, let's do it with GDC as well: pi_sequential.d π = 3.141592653589970752 iteration count = 10 elapse time = 8.616558 And you are going to ask about DMD aren't you :-) pi_sequential.d π = 3.141592653589970752 iteration count = 10 elapse time = 9.495549 Remember this is 1 and only 1 data point and not even a sample just a single data point. Thus only hypothesis building is allowed, no deductions. But I begin to believe that D is as fast as C and C++ using GDC and LDC. DMD is not in the execution performance game. Further fudging, the code is just one for loop. The parallel results are just as encouraging for D. I will say though that std.concurrency and std.parallelism could do with some more work. On the other hand C has nothing like it, whilst C++ has a few options including TBB. As I say, indicators, not statistically significant results without big data samples and serious ANOVA. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 08/11/2013 04:22 AM, Walter Bright wrote: http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf This article claims the "Performance [of D] is equivalent to C". Is that true? I mean even if D reaches 90% of C's performance, I still consider it great because of its productive features, but are there any benchmarks done?
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Tue, Aug 13, 2013 at 11:52:23AM +0200, Chris wrote: > On Tuesday, 13 August 2013 at 01:00:12 UTC, deadalnix wrote: [...] > >Rewind history back to early 2000 and you'll understand. At the > >time, PHP was the best solution (which says more about how bad the > >situation was than how great PHP was :D). > > True, true. There weren't many options back in the day. But that's > no excuse for bad or absurd language design. $asolutely $no $need > $to $have $a $syntax $like $this => > > At least it does its job ok. I honestly don't understand what's so bad about using $ for variables. That has nothing to do with PHP's *real* design flaws, which are many and varied. To fixate on $ only hides the real problems, described here: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ Note that using $ for variables isn't listed there. T -- "I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Tuesday, 13 August 2013 at 09:52:25 UTC, Chris wrote: On Tuesday, 13 August 2013 at 01:00:12 UTC, deadalnix wrote: On Monday, 12 August 2013 at 18:57:12 UTC, Chris wrote: On Monday, 12 August 2013 at 17:23:39 UTC, Dicebot wrote: On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: True, true. There weren't many options back in the day. But that's no excuse for bad or absurd language design. $asolutely $no $need $to $have $a $syntax $like $this => And I recall that PHP was meaning something like "Personally, I Hate Perl" :)
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Tuesday, 13 August 2013 at 01:00:12 UTC, deadalnix wrote: On Monday, 12 August 2013 at 18:57:12 UTC, Chris wrote: On Monday, 12 August 2013 at 17:23:39 UTC, Dicebot wrote: On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: unless it's a very specific thing like web development where PHP etc are handier. D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox. Hehe, sometimes I have the feeling that PHP is only language that does _not_ rock for webdev :) Well, probably with the exception of Brainfuck. No sure about latter though. PHP is terrible. The fact that you have to mark variables with $ is simply ridiculous. PHP is not very exciting. But it does the job. Alas, why do the mediocre solutions always find acceptance? Rewind history back to early 2000 and you'll understand. At the time, PHP was the best solution (which says more about how bad the situation was than how great PHP was :D). True, true. There weren't many options back in the day. But that's no excuse for bad or absurd language design. $asolutely $no $need $to $have $a $syntax $like $this => At least it does its job ok.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Tue, 13 Aug 2013 03:00:10 +0200 "deadalnix" wrote: > On Monday, 12 August 2013 at 18:57:12 UTC, Chris wrote: > > On Monday, 12 August 2013 at 17:23:39 UTC, Dicebot wrote: > >> On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: > >>> On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: > unless it's a very specific thing like web development > where PHP etc are handier. > >>> > >>> D rox for webdev too :) Only downside is it isn't > >>> pre-installed like php tends to be, but it still rox. > >> > >> Hehe, sometimes I have the feeling that PHP is only language > >> that does _not_ rock for webdev :) Well, probably with the > >> exception of Brainfuck. No sure about latter though. > > > > PHP is terrible. The fact that you have to mark variables with > > $ is simply ridiculous. PHP is not very exciting. But it does > > the job. Alas, why do the mediocre solutions always find > > acceptance? > > Rewind history back to early 2000 and you'll understand. At the > time, PHP was the best solution (which says more about how bad > the situation was than how great PHP was :D). Yea, a lot of web development best practices were still in the process of emerging back then. Nobody really knew how to do it right (being a brave new world and all that). So PHP was basically just a convenient preprocessor and a way to glue pages up to a MySQL backend. Unfortunately, since then it's evolved into a grotesque seven and a half headed monster that spits acid and consumes kittens. Also, if you look into it's eyes you'll go insane and try to bootstrap sandpaper. Or something like that. In any case it's not a pretty sight.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 08/12/2013 09:44 PM, Nick Sabalausky wrote: > You really should post that somewhere as a "blog" article. Probably will write something up on academic publishing in the near future -- bug me if I don't follow up on that ... :-)
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 18:57:12 UTC, Chris wrote: On Monday, 12 August 2013 at 17:23:39 UTC, Dicebot wrote: On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: unless it's a very specific thing like web development where PHP etc are handier. D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox. Hehe, sometimes I have the feeling that PHP is only language that does _not_ rock for webdev :) Well, probably with the exception of Brainfuck. No sure about latter though. PHP is terrible. The fact that you have to mark variables with $ is simply ridiculous. PHP is not very exciting. But it does the job. Alas, why do the mediocre solutions always find acceptance? Rewind history back to early 2000 and you'll understand. At the time, PHP was the best solution (which says more about how bad the situation was than how great PHP was :D).
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 08/12/2013 10:04 PM, Andrei Alexandrescu wrote: > I'd agree a lot more with what follows if it weren't for workshops, symposia, > and journals, which together complete quite a large spectrum of publication > and > debate venues, all with different tradeoffs. I agree that there are other avenues of dissemination out there, but I do feel that the particular predominance of conference proceedings in CS skews the field quite strongly. Regarding journals -- I was quite shocked when I first realized what long review times can be found in some major computer science journals (I hope this has changed, but it was certainly true when I was looking more intensely at the literature in the period 2008-2010). I personally suspect that's a direct consequence of proceedings being the main publication venue -- journal turnaround times _could_ be much, much faster, and are in many other fields (e.g. physics), but people tolerate those long delays essentially because of cultural factors -- there's an expectation that you target conferences for quick publication, journal for long-term archival. > But that's a matter common to all deadline-oriented work. The tradeoffs are > well > known. Also, Journals and trade magazines don't have such. Yes, but in CS the deadline-oriented venues predominate much more than in other fields, and on grounds that I don't believe are valid any more (there are now quicker and easier ways to disseminate the latest results in a fast-moving field). > On the upside that's incentive for producing good-quality work. Indeed, > conference proceedings are predictably better than workshops or > non-peer-reviewed publications. I agree there are better and worse conferences and that the selection practices of better conferences offer an incentive to authors to do well. I just think that they'd have the same incentive to do well and a better chance of achieving it if the main publication venue was instead well-run journals with fast review turnaround. It may be academic cultural bias, because my preference (and the norm in my field) is for meetings to be places for discussion and exchange rather than a publication venue, so I don't mind meetings where the contents have not been strongly reviewed. On the other hand in my field, unrefereed electronic preprints are a perfectly normal first dissemination method and are viewed pretty much as first-class publications in research/citation terms, though not of course in terms of career brownie points or formal research assessments. You'd think that would be an insane free-for-all but the data suggests not so -- researchers' care for their own reputation means that what's out there is usually not so different in quality from what winds up in the journals. > I haven't seen anyone really complaining about it. Not sure what surveys you > mention. Students who don't submit this time around have more time focusing on > research. The complaint is principally mine, because I think if there's empirical work that relies on user input in some way (whether it's people playing a game, or answering survey questions, or assessing the relevance of query results, or the quality of user interface designs...), you have to be quite careful about how you select your test subjects in order to avoid biasing the results. In my experience this is not something computer scientists take into consideration. Then again, my general experience is that CS doesn't have very good empirical traditions in general, and those that exist tend to be biased by the history of the discipline. But I also think they're negatively affected by deadline-focused publication. > We're all guilty of that to a small extent. Generally people are good at > picking > relevant literature, and my advisers were very careful in reviewing > quotations. I don't think many people _deliberately_ try and mis-cite work, but I think it's an accidental consequence of deadline-focused work. (Hey, you see the same thing in software development with horrible hacks being put in to make sure the product is "fixed" for the release deadline, right?:-) > That may happen at second and third tier venues. Good conferences accept good > research, which means a submitter won't risk a rejection by chopping work in > multiple pieces and submitting it separately. Never really heard of a labmate > doing this. But I imagine you have encountered the close cousin of this approach, which is: produce a piece of work for conference X; get rejected; rework it in a couple of weeks to make it look like something suitable for conference Y ... ? I find that kind of slanting of a work in order to "sell" it to be problematic, although I'd accept that it depends on who's doing it and how extreme the slanting is. As for good conferences, I'd suggest a major complaint here is that while it may be difficult to get a really bad paper in there, it's easy for a good paper to be bumped with no real justification, and a typical reason for tha
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Mon, 12 Aug 2013 09:18:26 -0700 "H. S. Teoh" wrote: > On Mon, Aug 12, 2013 at 02:53:44AM -0400, Nick Sabalausky wrote: > > On Sun, 11 Aug 2013 20:01:27 -0700 > > "H. S. Teoh" wrote: > > > > > > I personally prefer single-column with no more than about 40 ems > > > in width or thereabouts. Anything more than that, and it becomes > > > uncomfortable to read. > > > > > > > For me, it's closer to 80. With 40 the line breaks are too frequent > > for my eyes. And it just "feels" cramped. > > Wait, are you talking about 80 *characters*, or 80 ems? Most > characters are significantly narrower than 1 em, so 40 ems actually > work out to about 70 characters or so in a variable-width font > Erm, good point. I use monospaced fonts so much (both in code and accessing this NG) that the distinction didn't enter my mind. > (unless you have lines full of M's, in which case readability is the > least of your problems. :-P) Heh :) > > > > - No full justification by default. Existing justification schemes > > > could be improved (most implementations suffer from rivers of > > > whitespace in a justified paragraph -- they could learn from LaTeX > > > here). Needs native hyphenation support (using JS to patch up this > > > flaw is a failure IMO). > > > > > > > To be honest, I'm not a big fan of justified text. Obviously I can > > live with it, but even without the occasional "rivers of whitespace" > > issue, I find the lack of jagged edges gives my eyes too few > > reference points, so I end up losing my place more easily. The > > value of justified text's smooth edges, to me, seems somewhat > > "Adrian Monk" (wikipedia, if you don't know). > > I looked it up but didn't quite understand the reference. > He's highly OCD and one of his most common issues is that anything "uneven" distracts and bugs the hell out of him, to a frequently problematic degree. (One of the best shows on TV, IMO). I guess what I was trying to say with the reference was that, to me, the smooth sides of justified paragraphs seem more of an aesthetic benefit than a practical one, and indeed (for me anyway) the smooth edges are closer to being an aesthetically-pleasing *hindrance* since, like I said, there's less visual reference for me to distinguish between the different lines of text. > > > - Pixel sizes should be banned, as well as hard-coded font sizes. > > > These tie you to assumptions about specific user screen > > > dimensions, which are almost always wrong. In this day and age, > > > the only real solution is a fully dynamically adaptive layout. > > > Everything else is just a relic from paper layouts, and is a > > > dead-end. > > > > Yea. Admittedly, I do occasionally use pixels for a little bit of > > spacing here and there (never for more than 8px), but I can happily > > give them up - especially with so much now using those ultra-high > > pixel density screens. Pixels just don't make much sense now unless > > you're already dealing on a raster level anyway, like a photo or > > something. > > Exactly!! I have a pretty high-density pixel screen, and it annoys me > to the uttermost when websites specify font sizes in pixels, which, > inevitably, are squint-inducing microscopic sizes on my screen. And > even with photos, jpegs *are* scalable to some extent, which mostly > alleviates the need for specific pixel sizes. As I said, pixel sizes > are really only applicable with images. It makes no sense at all to > use pixel sizes with text and fonts, because it bears no relation to > physical screen size at all. > Yea, and even with images, I think we would be well off to make heavier use of vector formats (ex, SVG) than we currently do. (Of course, if I had designed SVG it wouldn't have been XML, but whatever.) Obviously not all images are appropriate for vectors, such as photos, but a lot of things are, like UI elements. Even in games, for example, if you're not doing realtime 3d (ex: most mobile and casual games) then it's a good (and I assume common) best practice to create it all in vector format (2d or 3d), keep all the "master" versions vector, and then purely for performance purposes just render out at build-time (or asset-export-time) to whatever sets of bitmap sizes you need for the various target devices. I imagine that's one of the reasons of why so many of the 2D mobile games have a cell-style look - not just "friendly" accessibility, but also because cell-style works well with vector, and vector works well for accommodating the myriad of screen sizes and densities, plus the occasional print advertisement and merchandising, etc. > > [...] > > > - Unable to express simple computations on sizes, requiring > > > circumlocutions that make the CSS hard to read and maintain. > > > > Yes! That's one of my big issues with CSS, the inability to do > > anything computationally. And yea, dealing with images tends to make > > that become more of an issue. > > > > Ultimately, the root problem here regarding the lack of
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 20:33:46 UTC, Dicebot wrote: I always feel so sad when awesome irony usage gets totally unnoticed because is it just too awesome to be obvious. http://en.wikipedia.org/wiki/Poe%27s_law
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 20:13:13 UTC, Nick Sabalausky wrote: *ahem* How is column width in PDF articles related to whether or not D is the answer to the One vs. Two Language High Performance Computing Dilemma? ;) I always feel so sad when awesome irony usage gets totally unnoticed because is it just too awesome to be obvious.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Mon, 12 Aug 2013 18:51:39 +0200 "Dicebot" wrote: > On Monday, 12 August 2013 at 16:28:01 UTC, Nick Sabalausky wrote: > > Yea. (And for vertical sh'mups!) That's also the reason 4:3 > > monitors > > would have to be pryed from my cold dead hands. 16:9 is fine > > for videos > > and games, but my computer isn't a glorified TV > > ... > > It has bugged me too in laptop screens but I don't feel it is an > issue now for large desktop ones. Once monitor gets big enough so > that you start needing some sort of tiling to utilize the space, > exact shape does not matter that much anymore. Even typical 24" > is enough for 3 full-sized terminal windows side by side. > > What is completely frustrating though, is horrible DPI on those > monitors. 1080p on 24" is a joke and it is a de-facto standard. What I find amusing/depressing about HD is that I was using monitors capable of higher-than-HD resolutions (and so were most people) years before anyone had even heard the phrases "high definition" or "flat panel television". And I was playing higher-than-SD games on my PC long before HDTV, as well. When HDTVs were still new and expensive (and they were still making HDTV CRTs - also expensive), I bought a clearance-sale 21" VGA for $25 which goes all the way up to 1600x1200.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Mon, 12 Aug 2013 21:23:17 +0200 "Idan Arye" wrote: > On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: > > On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: > >> unless it's a very specific thing like web development > >> where PHP etc are handier. > > > > D rox for webdev too :) Only downside is it isn't pre-installed > > like php tends to be, but it still rox. > > Yea, but how is that related to column width in PDF articles? > Please stay on-topic... *ahem* How is column width in PDF articles related to whether or not D is the answer to the One vs. Two Language High Performance Computing Dilemma? ;)
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Mon, 12 Aug 2013 12:34:22 -0700 "H. S. Teoh" wrote: > > But this is only the least of PHP's problems. I'm not going to repeat > what people have said about PHP's flaws, but you can read all about it > here: > > http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ > Ever since I first came across that, it's been my all-time favorite article on the web. He absolutely hits the nail on the head. > As for why mediocre solutions always find acceptance, I really don't > know either. I think it has a lot to due with most people equating "good" and "popular". Popularity, by its very nature, is driven primarily by a self-feedback loop, so the "core" of popularity-based selections tends to be highly influenced by statistical noise, and is therefore fairly random. Since "90% of everything is crap", most of these somewhat-random popularity-based selections tend to be crap. Hence, PHP being on every freaking server in existence (including mine, embarrassingly enough). Plus, most people (or really, humans in general) just aren't well suited to making merit-based choices anyway. Too easily influenced by less meritful factors like emotion, mental association, mistaken assumptions, impulse, popularity, etc. > I've come to adopt the rule of thumb that if something is > popular, then assume it sucks by default, until it's proven otherwise. > It has worked pretty well for me so far. > I wound up doing the same, somewhat unconsciously. A Pavlovian response I guess. And I agree, while it *has* occasionally led me astray, it usually serves me well. Of course, I'm a guy to usually tends to fall outside the bell curves anyway, so YMMV I suppose.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 8/12/13 4:45 AM, Joseph Rushton Wakeling wrote: On 08/12/2013 05:57 AM, Andrei Alexandrescu wrote: On 8/11/13 4:45 PM, Joseph Rushton Wakeling wrote: On Sunday, 11 August 2013 at 23:37:28 UTC, Andrei Alexandrescu wrote: That's an odd thing to say seeing as a lot of CS academic research is ten years ahead of the industry. I would personally venture to say that the publication practises of academia in general and CS in particular have many destructive and damaging aspects, and that industry-academia gap might be narrowed quite a bit if these were addressed. Could be improved, sure. Destructive and damaging - I'd be curious for some substantiation. In the case of CS in particular, the publication system is different from much of academia because it's so strongly based around conferences and conference proceedings. I'd say that's damaging in several ways. I'd agree a lot more with what follows if it weren't for workshops, symposia, and journals, which together complete quite a large spectrum of publication and debate venues, all with different tradeoffs. First, it means people write to the submission deadline rather than to their work having reached a satisfactory point of readiness. All other activities grind to a halt in the run-up to major conference deadlines -- you see students and postdocs in particular pulling all-nighters in order to make sure that everything gets done in time. But that's a matter common to all deadline-oriented work. The tradeoffs are well known. Also, Journals and trade magazines don't have such. Besides the health implications of that, such a last-minute rush has plenty of scope for making mistakes or introducing errors, errors that will be in the permanent academic record with little scope for correction (conference proceedings generally don't carry errata). On the upside that's incentive for producing good-quality work. Indeed, conference proceedings are predictably better than workshops or non-peer-reviewed publications. There are also more direct sources of bias -- e.g. if the work is based on user surveys, the chances are all the people in the lab _not_ working towards a paper deadline will be shanghaied into completing those surveys, disrupting their own work and also ensuring that the results are based on a very skewed selection of the population. I haven't seen anyone really complaining about it. Not sure what surveys you mention. Students who don't submit this time around have more time focusing on research. This pressure to deliver on deadline something that will be accepted by the conference can also lead to quite a superficial approach to the existing literature, with references skimmed quickly in order to find any random phrase that may support the current piece of work (even though on closer reading it may actually indicate the opposite). We're all guilty of that to a small extent. Generally people are good at picking relevant literature, and my advisers were very careful in reviewing quotations. The second source of damage comes via the conference review process. Because conferences are all-or-nothing affairs -- you get accepted or you don't -- there's a strong tendency to submit multiple papers presenting different facets of essentially the same work to multiple different conferences, just to ensure that _something_ gets accepted. That means overwork both for the authors (who have to write all those extra papers) and also for conference referees, who have to deal with the resulting excess of papers. That may happen at second and third tier venues. Good conferences accept good research, which means a submitter won't risk a rejection by chopping work in multiple pieces and submitting it separately. Never really heard of a labmate doing this. Reviewers are also working to deadlines, and with a lot of papers to assess in a short space of time (which is very disruptive to their other work), that can lead to snap and very superficial judgements. If there's a discrepancy in the amount of work that has to be done -- e.g. a "yes" means just a "yes", but a "no" means having to write a detailed report explaining why -- that can lead to accepting papers simply to lessen the workload. Agreed. There are also financial aspects -- because most conferences (understandably) won't accept papers unless at least one author comes to present, it means that authors' ability to publish their work can be constrained by their labs' ability to fund travel, accommodation and conference fees rather than by the quality of what they've done. Journal papers. And finally, when all is done and dusted, the proceedings of conferences are almost invariably then locked up behind a publisher paywall, despite the fact that almost all the document preparation work is done by authors and conference volunteers. How many tech businesses can afford the annual subscriptions to digital libraries? (I'm thinking small startups here.) Many acade
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Mon, 12 Aug 2013 13:45:02 +0200 Joseph Rushton Wakeling wrote: > On 08/12/2013 05:57 AM, Andrei Alexandrescu wrote: > > On 8/11/13 4:45 PM, Joseph Rushton Wakeling wrote: > >> On Sunday, 11 August 2013 at 23:37:28 UTC, Andrei Alexandrescu > >> wrote: > >>> That's an odd thing to say seeing as a lot of CS academic > >>> research is ten years ahead of the industry. > >> > >> I would personally venture to say that the publication practises of > >> academia in general and CS in particular have many destructive and > >> damaging aspects, and that industry-academia gap might be narrowed > >> quite a bit if these were addressed. > > > > Could be improved, sure. Destructive and damaging - I'd be curious > > for some substantiation. > > In the case of CS in particular, the publication system is different > from much of academia because it's so strongly based around > conferences and conference proceedings. I'd say that's damaging in > several ways. > > First, it means people write to the submission deadline rather than > to their work having reached a satisfactory point of readiness. All > other activities grind to a halt in the run-up to major conference > deadlines -- you see students and postdocs in particular pulling > all-nighters in order to make sure that everything gets done in time. > > Besides the health implications of that, such a last-minute rush has > plenty of scope for making mistakes or introducing errors, errors > that will be in the permanent academic record with little scope for > correction (conference proceedings generally don't carry errata). > There are also more direct sources of bias -- e.g. if the work is > based on user surveys, the chances are all the people in the lab > _not_ working towards a paper deadline will be shanghaied into > completing those surveys, disrupting their own work and also ensuring > that the results are based on a very skewed selection of the > population. > > This pressure to deliver on deadline something that will be accepted > by the conference can also lead to quite a superficial approach to > the existing literature, with references skimmed quickly in order to > find any random phrase that may support the current piece of work > (even though on closer reading it may actually indicate the opposite). > > The second source of damage comes via the conference review process. > Because conferences are all-or-nothing affairs -- you get accepted or > you don't -- there's a strong tendency to submit multiple papers > presenting different facets of essentially the same work to multiple > different conferences, just to ensure that _something_ gets > accepted. That means overwork both for the authors (who have to > write all those extra papers) and also for conference referees, who > have to deal with the resulting excess of papers. > > Reviewers are also working to deadlines, and with a lot of papers to > assess in a short space of time (which is very disruptive to their > other work), that can lead to snap and very superficial judgements. > If there's a discrepancy in the amount of work that has to be done -- > e.g. a "yes" means just a "yes", but a "no" means having to write a > detailed report explaining why -- that can lead to accepting papers > simply to lessen the workload. > > There are also financial aspects -- because most conferences > (understandably) won't accept papers unless at least one author comes > to present, it means that authors' ability to publish their work can > be constrained by their labs' ability to fund travel, accommodation > and conference fees rather than by the quality of what they've done. > > And finally, when all is done and dusted, the proceedings of > conferences are almost invariably then locked up behind a publisher > paywall, despite the fact that almost all the document preparation > work is done by authors and conference volunteers. How many tech > businesses can afford the annual subscriptions to digital libraries? > (I'm thinking small startups here.) > > I suppose you could say that many of these issues are > personal/professional failings of individual researchers or labs, but > in my experience these failings are driven by the pressure to publish > conference papers, and young researchers are pretty much trained to > follow these working practices in order to succeed. > > What particularly frustrates me about this particular situation is > that the justification for the current system -- that computer > science is too fast-moving for journal publication to keep up with > the latest results -- simply doesn't hold water in an age of > electronic publication. It's habit and professional career > structures, rather than the interests of research communication, that > maintain the current system. > > I could go on, but I think these examples will serve as > substantiation. :-) You really should post that somewhere as a "blog" article.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Mon, Aug 12, 2013 at 08:57:10PM +0200, Chris wrote: > On Monday, 12 August 2013 at 17:23:39 UTC, Dicebot wrote: > >On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: > >>On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: > >>>unless it's a very specific thing like web development where PHP > >>>etc are handier. > >> > >>D rox for webdev too :) Only downside is it isn't pre-installed like > >>php tends to be, but it still rox. > > > >Hehe, sometimes I have the feeling that PHP is only language that > >does _not_ rock for webdev :) Well, probably with the exception of > >Brainfuck. No sure about latter though. > > PHP is terrible. The fact that you have to mark variables with $ is > simply ridiculous. PHP is not very exciting. But it does the job. > Alas, why do the mediocre solutions always find acceptance? Marking variables with $ is actually not a bad thing; it helps set variables apart from, say, type identifiers, functions, etc.. But in the context of PHP, it's kinda pointless. But this is only the least of PHP's problems. I'm not going to repeat what people have said about PHP's flaws, but you can read all about it here: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ As for why mediocre solutions always find acceptance, I really don't know either. I've come to adopt the rule of thumb that if something is popular, then assume it sucks by default, until it's proven otherwise. It has worked pretty well for me so far. T -- WINDOWS = Will Install Needless Data On Whole System -- CompuMan
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: unless it's a very specific thing like web development where PHP etc are handier. D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox. Yea, but how is that related to column width in PDF articles? Please stay on-topic...
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 17:23:39 UTC, Dicebot wrote: On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: unless it's a very specific thing like web development where PHP etc are handier. D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox. Hehe, sometimes I have the feeling that PHP is only language that does _not_ rock for webdev :) Well, probably with the exception of Brainfuck. No sure about latter though. PHP is terrible. The fact that you have to mark variables with $ is simply ridiculous. PHP is not very exciting. But it does the job. Alas, why do the mediocre solutions always find acceptance?
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 17:03:44 UTC, H. S. Teoh wrote: It's not my fault, it's the mailman/NNTP interface that's causing problems. I use the mailing list interface. Btw was anyone planning to fix this on server side? I dream of the day when bunch of mail-based responses won't render web forum interface almost unreadable :)
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: unless it's a very specific thing like web development where PHP etc are handier. D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox. Hehe, sometimes I have the feeling that PHP is only language that does _not_ rock for webdev :) Well, probably with the exception of Brainfuck. No sure about latter though.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: unless it's a very specific thing like web development where PHP etc are handier. D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox. Yes, but it's still a bit of a gamble to use D. You'd need a (virtual) server.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Mon, Aug 12, 2013 at 06:49:08PM +0200, bearophile wrote: > H. S. Teoh: > > Just a note, you are somehow breaking most threads you answer to. [...] It's not my fault, it's the mailman/NNTP interface that's causing problems. I use the mailing list interface. T -- What do you call optometrist jokes? Vitreous humor.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: unless it's a very specific thing like web development where PHP etc are handier. D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 16:28:01 UTC, Nick Sabalausky wrote: Yea. (And for vertical sh'mups!) That's also the reason 4:3 monitors would have to be pryed from my cold dead hands. 16:9 is fine for videos and games, but my computer isn't a glorified TV ... It has bugged me too in laptop screens but I don't feel it is an issue now for large desktop ones. Once monitor gets big enough so that you start needing some sort of tiling to utilize the space, exact shape does not matter that much anymore. Even typical 24" is enough for 3 full-sized terminal windows side by side. What is completely frustrating though, is horrible DPI on those monitors. 1080p on 24" is a joke and it is a de-facto standard.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
H. S. Teoh: Just a note, you are somehow breaking most threads you answer to. Bye, bearophile
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
The authors of that article sum it up quite well. I used D for the same reasons and I don't see why I should use any other language for new projects, unless it's a very specific thing like web development where PHP etc are handier. For years I had been dreaming of something like D.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Mon, 12 Aug 2013 13:50:19 +0200 "Wyatt" wrote: > On Sunday, 11 August 2013 at 17:20:37 UTC, Nick Sabalausky wrote: > > rare few who have a monitor that swivels vertically or some > > Once you go vertical, you never go back! > > No, really, considering how much nicer it is for _every kind of > documentation_ (and most code), it's sad that this standard > feature of good Dell monitors for at least five years is rare. > > -Wyatt Yea. (And for vertical sh'mups!) That's also the reason 4:3 monitors would have to be pryed from my cold dead hands. 16:9 is fine for videos and games, but my computer isn't a glorified TV (as the manufacturers apparently insist on pretending). For non-TV uses of a computer (ie, the whole freaking point) 16:9 is just absolutely awful. 5:4 is tolerable, but even that's nearly impossible to find now. My stupid laptop has a 16:9 built-in because I literally couldn't find anything better. Normally I just have it connected to my 4:3 CRT. What I've ended up doing is mounting my taskbar on the left side of the screen instead of the bottom. The built-in 16:9 is downright unusable otherwise. And I've found it's even an improvement on the 4:3, too.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Mon, Aug 12, 2013 at 02:53:44AM -0400, Nick Sabalausky wrote: > On Sun, 11 Aug 2013 20:01:27 -0700 > "H. S. Teoh" wrote: > > > > I personally prefer single-column with no more than about 40 ems in > > width or thereabouts. Anything more than that, and it becomes > > uncomfortable to read. > > > > For me, it's closer to 80. With 40 the line breaks are too frequent > for my eyes. And it just "feels" cramped. Wait, are you talking about 80 *characters*, or 80 ems? Most characters are significantly narrower than 1 em, so 40 ems actually work out to about 70 characters or so in a variable-width font (unless you have lines full of M's, in which case readability is the least of your problems. :-P) > > - No full justification by default. Existing justification schemes > > could be improved (most implementations suffer from rivers of > > whitespace in a justified paragraph -- they could learn from LaTeX > > here). Needs native hyphenation support (using JS to patch up this > > flaw is a failure IMO). > > > > To be honest, I'm not a big fan of justified text. Obviously I can > live with it, but even without the occasional "rivers of whitespace" > issue, I find the lack of jagged edges gives my eyes too few reference > points, so I end up losing my place more easily. The value of > justified text's smooth edges, to me, seems somewhat "Adrian Monk" > (wikipedia, if you don't know). I looked it up but didn't quite understand the reference. In any case, I find jagged edges ineffably ugly. It just *looks* sloppy, esp. when there are ready algorithms out there that will fix it for you automatically. It just hearkens back to the bygone days of handwriting. Surely such trifling limitations are no longer applicable in a digital medium? > > - Pixel sizes should be banned, as well as hard-coded font sizes. > > These tie you to assumptions about specific user screen dimensions, > > which are almost always wrong. In this day and age, the only real > > solution is a fully dynamically adaptive layout. Everything else is > > just a relic from paper layouts, and is a dead-end. > > Yea. Admittedly, I do occasionally use pixels for a little bit of > spacing here and there (never for more than 8px), but I can happily > give them up - especially with so much now using those ultra-high > pixel density screens. Pixels just don't make much sense now unless > you're already dealing on a raster level anyway, like a photo or > something. Exactly!! I have a pretty high-density pixel screen, and it annoys me to the uttermost when websites specify font sizes in pixels, which, inevitably, are squint-inducing microscopic sizes on my screen. And even with photos, jpegs *are* scalable to some extent, which mostly alleviates the need for specific pixel sizes. As I said, pixel sizes are really only applicable with images. It makes no sense at all to use pixel sizes with text and fonts, because it bears no relation to physical screen size at all. [...] > > - Unable to express simple computations on sizes, requiring > > circumlocutions that make the CSS hard to read and maintain. > > Yes! That's one of my big issues with CSS, the inability to do > anything computationally. And yea, dealing with images tends to make > that become more of an issue. > > Ultimately, the root problem here regarding the lack of computability, > is that HTML/CSS is not, and never has been, a UI layout format (No > matter how much people insist on treating it as > such...*cough*mozilla*cough*.) It's a *document* format. Always has > been. Everything else is a kludge, and is doomed to be so from the > start. Even for a *document* format, it's rather limited in the kinds of layouts it can do. All the cool CSS hacks that people pull are nothing more than just that: hacks. [...] > ...And yet 9 times out of 10 it *still* ends up far more readable > on-screen than an 8.5" x 11" two-column PDF. Go figure. You need a better PDF reader. (Hint: Adobe Reader is not one of them. :-P) > > On Sun, Aug 11, 2013 at 04:47:09PM -0700, Walter Bright wrote: > > > On 8/11/2013 4:33 PM, Andrei Alexandrescu wrote: > > [...] > > > Currently ereaders are great for reading novels and such with > > > little typography needs. But they're terrible for textbooks and > > > reference material, mainly because the screen is both low res and > > > is way too small. > > > > > > It's like programming with an 80*24 display (I can't believe I was > > > able to use them!). > > [...] > > > > I still program with 80*24 displays. Well, more like 80*40, but I > > find that it's actually far more readable than the common obsession > > with squint-inducing microscopic fonts trying to cram as much on the > > screen as possible. Having too many characters per line quickly gets > > very hard to read. > > > > Heck, I started out on the 40-character-width AppleSoft BASIC. > Although I'm sure other people can best me on that (altair, punch > cards, etc). I started out with 40-character Applesoft
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 11:45:31 UTC, Joseph Rushton Wakeling wrote: On 08/12/2013 05:57 AM, Andrei Alexandrescu wrote: On 8/11/13 4:45 PM, Joseph Rushton Wakeling wrote: On Sunday, 11 August 2013 at 23:37:28 UTC, Andrei Alexandrescu wrote: First, it means people write to the submission deadline rather than to their work having reached a satisfactory point of readiness. All As a (former) Academia person, I could only concur. From this point of view, this "publish or perish" mantra is a bad one. Believe it or not, but, to date, the most serious school about that is the Russian school. AFAICT, those guys (at least those that I encountered), they are really doing some work, *then* looking for a conference to publish their results. For many others (of us), it is exactly the opposite: "OMG, the deadline for that conference in Podung is approaching so fast! what should I gather from my (unfinished) work to come up with a paper?" Let's not even discuss about: "why writing a single paper, when I could split my work in two or three papers, just to have better impact factor?" ;)
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 15:49:25 UTC, monarch_dodra wrote: On Sunday, 11 August 2013 at 15:42:24 UTC, Nick Sabalausky wrote: On Sun, 11 Aug 2013 01:22:34 -0700 Walter Bright wrote: http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf Holy crap those two-column PDFs are hard to read! Why in the world does academia keep doing that anyway? (Genuine question, not rhetoric) But the fact that article even exists is really freaking awesome. :) My guess is simply because it takes more space, making a 4 page article look like a 7 page ;) Actually I think the opposite is true. Many CS conferences for example have page limits and as multi-column allows you to use a smaller font, and still have a readable document, the multi-column layout lets you submit a longer paper. In my experience with conference paper submission (which for me usually had a 6 or 8 page limit) was getting the thing short enough to submit. Craig
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 08/12/2013 09:12 AM, Nick Sabalausky wrote: > I'm seeing a lot of focus here on the printed page. People can do > whatever the heck they want when they go print handouts and such. > But that doesn't mean they have to, or should, shoehorn their > electronic publications into a form that's poorly suited for > electronic use. One thing that's worth remembering is that printing out copies for reading and thinking purposes is still quite important -- there's a great benefit in disconnecting from screen, from e-reader, from any electronic devices, and reading, scribbling and thinking with just you, a printed copy and some note paper. Having well-laid-out print copies makes that process much, _much_ nicer. If I compare the not-so-nice 2-column conference proceedings with a well-prepared journal article, there's no comparison. Typography still matters a great deal for effective research communication. > Didn't someone here say not too long ago that most of those > publications are just written in latex anyway? If that's the case, then > I really don't see any issue with having separate formats for print > handouts vs electronic distribution (But then I'm not versed in latex, so > maybe I'm missing something). Depends on the discipline. Some (e.g. physics) are pretty wedded to LaTeX. Others are almost all based around Word. Different branches of computer science seem to favour one or the other -- ACM and IEEE conference proceedings have templates in both, and the author is asked to generate the PDF copy from whichever they use, and it's the PDF, and _only_ the PDF, that is used for dissemination purposes. In other cases (e.g. Spring Lecture Notes) the publisher does ask for source copy and does make use of it. Where journals are concerned, different journals handle things differently but in my experience, these days LaTeX is not so often used as the actual formatting mechanism. When authors provide LaTeX source, it'll most likely be used as an input for the typesetter's internal workflow, most often using InDesign, with XML, HTML and PDF copies being exported. There are some physics journals which were almost certainly using LaTeX as their formatting mechanism some years ago, but have now switched to that kind of alternative workflow. You can tell because the copyediting stage introduces typos that are only explicable if the submitted LaTeX source has been imported into something like Word and copyedited there.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 15:42:24 UTC, Nick Sabalausky wrote: Holy crap those two-column PDFs are hard to read! Hehe, "Introduction to the DWARF debugging format" by Michael Eager is a 3-column pdf: down, up, down, up, down, left, right, A, B, Instant Kill.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 17:20:37 UTC, Nick Sabalausky wrote: rare few who have a monitor that swivels vertically or some Once you go vertical, you never go back! No, really, considering how much nicer it is for _every kind of documentation_ (and most code), it's sad that this standard feature of good Dell monitors for at least five years is rare. -Wyatt
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 08/12/2013 05:57 AM, Andrei Alexandrescu wrote: > On 8/11/13 4:45 PM, Joseph Rushton Wakeling wrote: >> On Sunday, 11 August 2013 at 23:37:28 UTC, Andrei Alexandrescu wrote: >>> That's an odd thing to say seeing as a lot of CS academic research is >>> ten years ahead of the industry. >> >> I would personally venture to say that the publication practises of >> academia in general and CS in particular have many destructive and >> damaging aspects, and that industry-academia gap might be narrowed quite >> a bit if these were addressed. > > Could be improved, sure. Destructive and damaging - I'd be curious for some > substantiation. In the case of CS in particular, the publication system is different from much of academia because it's so strongly based around conferences and conference proceedings. I'd say that's damaging in several ways. First, it means people write to the submission deadline rather than to their work having reached a satisfactory point of readiness. All other activities grind to a halt in the run-up to major conference deadlines -- you see students and postdocs in particular pulling all-nighters in order to make sure that everything gets done in time. Besides the health implications of that, such a last-minute rush has plenty of scope for making mistakes or introducing errors, errors that will be in the permanent academic record with little scope for correction (conference proceedings generally don't carry errata). There are also more direct sources of bias -- e.g. if the work is based on user surveys, the chances are all the people in the lab _not_ working towards a paper deadline will be shanghaied into completing those surveys, disrupting their own work and also ensuring that the results are based on a very skewed selection of the population. This pressure to deliver on deadline something that will be accepted by the conference can also lead to quite a superficial approach to the existing literature, with references skimmed quickly in order to find any random phrase that may support the current piece of work (even though on closer reading it may actually indicate the opposite). The second source of damage comes via the conference review process. Because conferences are all-or-nothing affairs -- you get accepted or you don't -- there's a strong tendency to submit multiple papers presenting different facets of essentially the same work to multiple different conferences, just to ensure that _something_ gets accepted. That means overwork both for the authors (who have to write all those extra papers) and also for conference referees, who have to deal with the resulting excess of papers. Reviewers are also working to deadlines, and with a lot of papers to assess in a short space of time (which is very disruptive to their other work), that can lead to snap and very superficial judgements. If there's a discrepancy in the amount of work that has to be done -- e.g. a "yes" means just a "yes", but a "no" means having to write a detailed report explaining why -- that can lead to accepting papers simply to lessen the workload. There are also financial aspects -- because most conferences (understandably) won't accept papers unless at least one author comes to present, it means that authors' ability to publish their work can be constrained by their labs' ability to fund travel, accommodation and conference fees rather than by the quality of what they've done. And finally, when all is done and dusted, the proceedings of conferences are almost invariably then locked up behind a publisher paywall, despite the fact that almost all the document preparation work is done by authors and conference volunteers. How many tech businesses can afford the annual subscriptions to digital libraries? (I'm thinking small startups here.) I suppose you could say that many of these issues are personal/professional failings of individual researchers or labs, but in my experience these failings are driven by the pressure to publish conference papers, and young researchers are pretty much trained to follow these working practices in order to succeed. What particularly frustrates me about this particular situation is that the justification for the current system -- that computer science is too fast-moving for journal publication to keep up with the latest results -- simply doesn't hold water in an age of electronic publication. It's habit and professional career structures, rather than the interests of research communication, that maintain the current system. I could go on, but I think these examples will serve as substantiation. :-)
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 16:28:21 UTC, Andrei Alexandrescu wrote: On 8/11/13 8:49 AM, monarch_dodra wrote: On Sunday, 11 August 2013 at 15:42:24 UTC, Nick Sabalausky wrote: On Sun, 11 Aug 2013 01:22:34 -0700 Walter Bright wrote: http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf Holy crap those two-column PDFs are hard to read! Why in the world does academia keep doing that anyway? (Genuine question, not rhetoric) But the fact that article even exists is really freaking awesome. :) My guess is simply because it takes more space, making a 4 page article look like a 7 page ;) Double columns take less space and are more readable. Andrei Printed, for sure. On screen, doubtful.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Monday, 12 August 2013 at 03:02:59 UTC, H. S. Teoh wrote: I still program with 80*24 displays. Well, more like 80*40, but I find that it's actually far more readable than the common obsession with squint-inducing microscopic fonts trying to cram as much on the screen as possible. Having too many characters per line quickly gets very hard to read. T I am actually going the opposite way. My go to font size when coding is now 8pt, I can't stand working with anything much larger. I wouldn't use anything that large for publishing, but it's my preference for reading code.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sun, 11 Aug 2013 16:33:26 -0700 Andrei Alexandrescu wrote: > On 8/11/13 12:00 PM, Nick Sabalausky wrote: > > > B. There's nothing stopping authors from making their PDFs a > > single-column at whatever line width works well. Like I said, > > personally I've never found 8" line width at a normal font size to > > be even the slightest hint harder than 10 words per line (in fact, > > sometimes I find 10 words per line to be *harder* due to such > > frequent line breaks), *but* if the author wants to do 10 words per > > line in a PDF, there's *nothing* in PDF stopping them from doing > > that without immediately sacrificing those gains, and more, by > > going multi-column. > > This started with your refutation of my argument that two columns > need less space. One column would fill less of the paper, which was > my point. This is, indeed, the motivation of conferences: they want > to publish relatively compact proceedings. > > There is a lot of research and practice on readability, dating from > hundreds of years ago - before the start of typography. In recent > years there's been new research motivated by the advent of new media > for displaying textual information, some of which supports your view, > see e.g. http://goo.gl/qfHcJz. However, most pundits do suggest > limiting the width of text lines, see the many results of > http://goo.gl/HuPEXV. > FWIW, I should clarify that I'm not necessarily advocating a complete and total lack of "max-width". > > Bottom line, obviously multi-column PDF is a bad situation, but we > > already *have* multiple dead-simple solutions even without throwing > > our hands up and saying "Oh, well, there's no good *multi-column* > > solution ATM, so I have no way to make my document readable without > > waiting for a reflowing-PDF or CSS5 or 6 or 7 or whatever." > > > > An obsessive desire for multi-column appears to be getting in the > > way of academic documents that have halfway decent readability. > > Meanwhile, the *rest* of the word just doesn't bother, uses > > single-column, and gets by perfectly fine with entirely readable > > documents (Well, except when they put out webpages with gigantic > > sizes, grey-on-white text, and double-spacing - Now *that* makes > > things *really* hard to read. Gives me a headache every single time > > - and it's always committed by the very people who *think* they're > > doing it to be more readable. Gack.) > > Again, two-column layout is being used as a vehicle for putting a > wealth of information in a good quality format that is cheap to print > and bind (most conference proceedings are simply printed on letter/A4 > paper and bound at the university bindery). The rest of the paper > publishing world has different constraints because they print > document in much larger numbers, in a specialized typography that use > folios divided in different ways, producing smaller, single-column > books. It strikes me as ignorant to accuse the academic world of > high-brow snobbery because it produces good quality printed content > with free software at affordable costs. > > > I *really* wish PDF would die. It's great for printed stuff, but > > its mere existence just does far more harm than good. Designers are > > already far too tempted to treat computers like a freaking sheet of > > paper - PDF just clinches it for them. > > Clearly PDF and other fixed-format products are targeted at putting > ink on paper, and that's going the way of the dinosaur. At the same > time, the publishing industry is very much in turmoil for the time > being and only future will tell what the right replacement is. > I'm seeing a lot of focus here on the printed page. People can do whatever the heck they want when they go print handouts and such. But that doesn't mean they have to, or should, shoehorn their electronic publications into a form that's poorly suited for electronic use. Didn't someone here say not too long ago that most of those publications are just written in latex anyway? If that's the case, then I really don't see any issue with having separate formats for print handouts vs electronic distribution (But then I'm not versed in latex, so maybe I'm missing something).
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sun, 11 Aug 2013 20:01:27 -0700 "H. S. Teoh" wrote: > > I personally prefer single-column with no more than about 40 ems in > width or thereabouts. Anything more than that, and it becomes > uncomfortable to read. > For me, it's closer to 80. With 40 the line breaks are too frequent for my eyes. And it just "feels" cramped. > > - No full justification by default. Existing justification schemes > could be improved (most implementations suffer from rivers of > whitespace in a justified paragraph -- they could learn from LaTeX > here). Needs native hyphenation support (using JS to patch up this > flaw is a failure IMO). > To be honest, I'm not a big fan of justified text. Obviously I can live with it, but even without the occasional "rivers of whitespace" issue, I find the lack of jagged edges gives my eyes too few reference points, so I end up losing my place more easily. The value of justified text's smooth edges, to me, seems somewhat "Adrian Monk" (wikipedia, if you don't know). > > - Pixel sizes should be banned, as well as hard-coded font sizes. > These tie you to assumptions about specific user screen dimensions, > which are almost always wrong. In this day and age, the only real > solution is a fully dynamically adaptive layout. Everything else is > just a relic from paper layouts, and is a dead-end. Yea. Admittedly, I do occasionally use pixels for a little bit of spacing here and there (never for more than 8px), but I can happily give them up - especially with so much now using those ultra-high pixel density screens. Pixels just don't make much sense now unless you're already dealing on a raster level anyway, like a photo or something. > Things like > aligning images should be based on treating image size as an actual > quantity you can compute sizes on; any hard-coded image sizes is > bound to cause problems when the image is modified. > > - Unable to express simple computations on sizes, requiring > circumlocutions that make the CSS hard to read and maintain. Yes! That's one of my big issues with CSS, the inability to do anything computationally. And yea, dealing with images tends to make that become more of an issue. Ultimately, the root problem here regarding the lack of computability, is that HTML/CSS is not, and never has been, a UI layout format (No matter how much people insist on treating it as such...*cough*mozilla*cough*.) It's a *document* format. Always has been. Everything else is a kludge, and is doomed to be so from the start. > > > >If someone expands their browser to be two-feet wide and ends up > > >with too much text per line, then really they have no one to blame > > >but their own dumbass self. > > > > This is a frequent argument. The issue with it is that often people > > use tabbed browsing, each tab having a page with its own approach to > > readability. > > The *real* problem is that webpage layout is still very much confined > by outdated paper layout concepts. The browser should be able to > automatically columnize text to fit the screen. Maybe with horizontal > scrolling instead of vertical scrolling. Layouts should be flexible > enough that the browser can resize the fonts to keep the text > readable. Seriously, this isn't 1970. There's no reason why we should > still be fiddling with this stuff manually. Layouts should be > automatic, not hardcoded or at the whims of designers fixated on > paper layout concepts. > Exactly. In fact, we *already* had all this. It was called HTML 1. But then some jackass designers came in from the print world and demanded webpages match their photoshop mockups to the pixel, thus HTML mutated into the world's worst UI layout system. (Of course I skipped a few steps there, but you get the picture.) If we weren't trying to force app UIs and manual page layouts into web pages, we could have *already* had nice document layout systems tailored to the individual user (with tabbed browsing *not* being an obstacle to basic window resizing, and with multiple device form factors *never* being an issue for any content creator), instead of this current endless circle where W3C occasionally hands out some new half-baked CSS gimmick that a few of the more overzealous designers can optionally employ in order to force a one-size-fits-all approach to "readability" onto everyone who visits that one particular site, thus leading to inevitable problems and ultimately the W3C's next round of half-baked hacks to the CSS spec. > > [...] > > >I *really* wish PDF would die. It's great for printed stuff, but > > >its mere existence just does far more harm than good. Designers are > > >already far too tempted to treat computers like a freaking sheet of > > >paper - PDF just clinches it for them. > > > > Clearly PDF and other fixed-format products are targeted at putting > > ink on paper, and that's going the way of the dinosaur. At the same > > time, the publishing industry is very much in turmoil for the time > > being and only fu
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 8/11/13 4:45 PM, Joseph Rushton Wakeling wrote: On Sunday, 11 August 2013 at 23:37:28 UTC, Andrei Alexandrescu wrote: That's an odd thing to say seeing as a lot of CS academic research is ten years ahead of the industry. I would personally venture to say that the publication practises of academia in general and CS in particular have many destructive and damaging aspects, and that industry-academia gap might be narrowed quite a bit if these were addressed. Could be improved, sure. Destructive and damaging - I'd be curious for some substantiation. Andrei
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sun, Aug 11, 2013 at 04:33:26PM -0700, Andrei Alexandrescu wrote: > On 8/11/13 12:00 PM, Nick Sabalausky wrote: > >On Sun, 11 Aug 2013 11:25:02 -0700 > >Andrei Alexandrescu wrote: > >> > >>For a column of text to be readable it should have not much more > >>than 10 words per line. Going beyond that forces eyes to scan too > >>jerkily and causes difficulty in following line breaks. Filling an > >>A4 or letter paper with only one column would force either (a) an > >>unusually large font, (b) very large margins, or (c) too many words > >>per line. Children books choose (a), which is why many do come in > >>that format. LaTeX and Word choose (b) in single-column documents. The solution is to have adaptive layout that adapts itself to your screen. I personally prefer single-column with no more than about 40 ems in width or thereabouts. Anything more than that, and it becomes uncomfortable to read. Actually, another interesting idea is left-to-right scrolling instead of vertical scrolling. You'd lay out the text in columns that exactly fit the height of the screen, and have as many columns as needed to fit the entire text. If that exceeds the screen width, scroll horizontally. [...] > >>Multicolumn is best for screen reading, too. The only problem is > >>there's no good flowing - the columns should fit the screen. There's > >>work on that, see e.g. > >>http://alistapart.com/article/css3multicolumn. Fixing the number of columns is bound to fail, because user screen dimensions cannot be predicted in advance. The only *real* solution is to use an adaptive layout algorithm that adapts itself as needed. > >A. HTML has good flowing, and has had it since freaking v1. No need > >for upcoming CSS tricks: As long as the author doesn't go and do > >something retarded like use a fixed layout or this new "zoom out > >whenever the window shrinks" lunacy, then all any user ever has to do > >is adjust the window to their liking. > > Clearly HTML has made good progress toward reaching good formatting, > but is not quite there yet. Ugh. I don't consider HTML as good formatting at all. HTML+CSS still has these shortcomings: - No full justification by default. Existing justification schemes could be improved (most implementations suffer from rivers of whitespace in a justified paragraph -- they could learn from LaTeX here). Needs native hyphenation support (using JS to patch up this flaw is a failure IMO). - Text width should be limited to 40em by default. - Many layout solutions require CSS circumlocutions and hacks, because CSS simply isn't expressive enough for many formatting needs. This causes spotty browser support and fragility. - Pixel sizes should be banned, as well as hard-coded font sizes. These tie you to assumptions about specific user screen dimensions, which are almost always wrong. In this day and age, the only real solution is a fully dynamically adaptive layout. Everything else is just a relic from paper layouts, and is a dead-end. Things like aligning images should be based on treating image size as an actual quantity you can compute sizes on; any hard-coded image sizes is bound to cause problems when the image is modified. - Unable to express simple computations on sizes, requiring circumlocutions that make the CSS hard to read and maintain. - Unable to express simple things like headers and footers, requiring hacks with floats and divs and whatnot, which, again, requires making assumptions about user screen size, which inevitably will go wrong. > >If someone expands their browser to be two-feet wide and ends up with > >too much text per line, then really they have no one to blame but > >their own dumbass self. > > This is a frequent argument. The issue with it is that often people > use tabbed browsing, each tab having a page with its own approach to > readability. The *real* problem is that webpage layout is still very much confined by outdated paper layout concepts. The browser should be able to automatically columnize text to fit the screen. Maybe with horizontal scrolling instead of vertical scrolling. Layouts should be flexible enough that the browser can resize the fonts to keep the text readable. Seriously, this isn't 1970. There's no reason why we should still be fiddling with this stuff manually. Layouts should be automatic, not hardcoded or at the whims of designers fixated on paper layout concepts. [...] > >I *really* wish PDF would die. It's great for printed stuff, but its > >mere existence just does far more harm than good. Designers are > >already far too tempted to treat computers like a freaking sheet of > >paper - PDF just clinches it for them. > > Clearly PDF and other fixed-format products are targeted at putting > ink on paper, and that's going the way of the dinosaur. At the same > time, the publishing industry is very much in turmoil for the time > being and only future will tell what the right replacement is. [...] The right r
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 8/11/2013 4:33 PM, Andrei Alexandrescu wrote: Clearly PDF and other fixed-format products are targeted at putting ink on paper, and that's going the way of the dinosaur. At the same time, the publishing industry is very much in turmoil for the time being and only future will tell what the right replacement is. Currently ereaders are great for reading novels and such with little typography needs. But they're terrible for textbooks and reference material, mainly because the screen is both low res and is way too small. It's like programming with an 80*24 display (I can't believe I was able to use them!). (I was eagerly looking at the Surface tablet when it came out, but what killed it for me was the low res display. I want to read books on a tablet, and a low res display doesn't do that very well.) I'd like an ereader that has a full 8.5*11 display.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 23:37:28 UTC, Andrei Alexandrescu wrote: That's an odd thing to say seeing as a lot of CS academic research is ten years ahead of the industry. I would personally venture to say that the publication practises of academia in general and CS in particular have many destructive and damaging aspects, and that industry-academia gap might be narrowed quite a bit if these were addressed.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 8/11/13 12:09 PM, Nick Sabalausky wrote: On Sun, 11 Aug 2013 20:43:17 +0200 "Tyler Jameson Little" wrote: I really wish this was more popular: __ | || | 1 | 2| | || | || || | || | 3 | 4| | || | || ___ page break ___ | || | || | 1 | 2| | || || | || | || | 3 | 4| | || This allows a multi-column layout with less scrolling. Yea, that's another thing that would help. This is still too rigid. I think the right answer is adaptive flowed layout (http://goo.gl/CXylLi - warning it's a PDF :o)), where the system selects a typography-quality layout dynamically depending on the characteristics of the device. Why can't we get the same for academic papers? They're even simpler because each section can be forced to be the same size. I keep getting more and more convinced that it's just comes back down to the usual old problem of glacial bureaucratic-like nature of academia. I truly believe the academic world is beginning to sink under the weight of its own outdated traditions. This is just one symptom of that, just like all the ways the MPAA/RIAA struggled against the societal changes they wanted to pretend weren't really occurring. That's an odd thing to say seeing as a lot of CS academic research is ten years ahead of the industry. Andrei
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 8/11/13 12:00 PM, Nick Sabalausky wrote: On Sun, 11 Aug 2013 11:25:02 -0700 Andrei Alexandrescu wrote: For a column of text to be readable it should have not much more than 10 words per line. Going beyond that forces eyes to scan too jerkily and causes difficulty in following line breaks. Filling an A4 or letter paper with only one column would force either (a) an unusually large font, (b) very large margins, or (c) too many words per line. Children books choose (a), which is why many do come in that format. LaTeX and Word choose (b) in single-column documents. [...] Multicolumn is best for screen reading, too. The only problem is there's no good flowing - the columns should fit the screen. There's work on that, see e.g. http://alistapart.com/article/css3multicolumn. A. HTML has good flowing, and has had it since freaking v1. No need for upcoming CSS tricks: As long as the author doesn't go and do something retarded like use a fixed layout or this new "zoom out whenever the window shrinks" lunacy, then all any user ever has to do is adjust the window to their liking. Clearly HTML has made good progress toward reaching good formatting, but is not quite there yet. If someone expands their browser to be two-feet wide and ends up with too much text per line, then really they have no one to blame but their own dumbass self. This is a frequent argument. The issue with it is that often people use tabbed browsing, each tab having a page with its own approach to readability. B. There's nothing stopping authors from making their PDFs a single-column at whatever line width works well. Like I said, personally I've never found 8" line width at a normal font size to be even the slightest hint harder than 10 words per line (in fact, sometimes I find 10 words per line to be *harder* due to such frequent line breaks), *but* if the author wants to do 10 words per line in a PDF, there's *nothing* in PDF stopping them from doing that without immediately sacrificing those gains, and more, by going multi-column. This started with your refutation of my argument that two columns need less space. One column would fill less of the paper, which was my point. This is, indeed, the motivation of conferences: they want to publish relatively compact proceedings. There is a lot of research and practice on readability, dating from hundreds of years ago - before the start of typography. In recent years there's been new research motivated by the advent of new media for displaying textual information, some of which supports your view, see e.g. http://goo.gl/qfHcJz. However, most pundits do suggest limiting the width of text lines, see the many results of http://goo.gl/HuPEXV. Bottom line, obviously multi-column PDF is a bad situation, but we already *have* multiple dead-simple solutions even without throwing our hands up and saying "Oh, well, there's no good *multi-column* solution ATM, so I have no way to make my document readable without waiting for a reflowing-PDF or CSS5 or 6 or 7 or whatever." An obsessive desire for multi-column appears to be getting in the way of academic documents that have halfway decent readability. Meanwhile, the *rest* of the word just doesn't bother, uses single-column, and gets by perfectly fine with entirely readable documents (Well, except when they put out webpages with gigantic sizes, grey-on-white text, and double-spacing - Now *that* makes things *really* hard to read. Gives me a headache every single time - and it's always committed by the very people who *think* they're doing it to be more readable. Gack.) Again, two-column layout is being used as a vehicle for putting a wealth of information in a good quality format that is cheap to print and bind (most conference proceedings are simply printed on letter/A4 paper and bound at the university bindery). The rest of the paper publishing world has different constraints because they print document in much larger numbers, in a specialized typography that use folios divided in different ways, producing smaller, single-column books. It strikes me as ignorant to accuse the academic world of high-brow snobbery because it produces good quality printed content with free software at affordable costs. I *really* wish PDF would die. It's great for printed stuff, but its mere existence just does far more harm than good. Designers are already far too tempted to treat computers like a freaking sheet of paper - PDF just clinches it for them. Clearly PDF and other fixed-format products are targeted at putting ink on paper, and that's going the way of the dinosaur. At the same time, the publishing industry is very much in turmoil for the time being and only future will tell what the right replacement is. Andrei
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 08:22:35 UTC, Walter Bright wrote: http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf Interesting, and certainly D being a wide spectrum language is a reason that many of us investigate it. Julia is aiming at the same space as that mentioned in the paper, so I think that their point that D is the only choice here is not true any more. No comment on the paper's formatting, which seems to its most salient feature :-) -- Brian
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 15:42:24 UTC, Nick Sabalausky wrote: On Sun, 11 Aug 2013 01:22:34 -0700 Walter Bright wrote: http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf Holy crap those two-column PDFs are hard to read! Why in the world does academia keep doing that anyway? (Genuine question, not rhetoric) It's convenient for embedding figures without using up excessive space or resorting to *shivers* word wrapping. Even without taking that in to account, I've always had a soft spot for 2 column layout, when done right. Most of the physics papers I read use it and I never have any problems. It's only really bad if they make the columns too narrow compared to the font width and you get too few words per line.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sun, 11 Aug 2013 20:43:17 +0200 "Tyler Jameson Little" wrote: > > I really wish this was more popular: > __ > | || > | 1 | 2| > | || > | || > || > | || > | 3 | 4| > | || > | || > ___ page break ___ > | || > | || > | 1 | 2| > | || > || > | || > | || > | 3 | 4| > | || > > This allows a multi-column layout with less scrolling. Yea, that's another thing that would help. > > Why can't we get the same for academic papers? They're even > simpler because each section can be forced to be the same size. I keep getting more and more convinced that it's just comes back down to the usual old problem of glacial bureaucratic-like nature of academia. I truly believe the academic world is beginning to sink under the weight of its own outdated traditions. This is just one symptom of that, just like all the ways the MPAA/RIAA struggled against the societal changes they wanted to pretend weren't really occurring.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sun, 11 Aug 2013 11:25:02 -0700 Andrei Alexandrescu wrote: > > For a column of text to be readable it should have not much more than > 10 words per line. Going beyond that forces eyes to scan too jerkily > and causes difficulty in following line breaks. Filling an A4 or > letter paper with only one column would force either (a) an unusually > large font, (b) very large margins, or (c) too many words per line. > Children books choose (a), which is why many do come in that format. > LaTeX and Word choose (b) in single-column documents. > > [...] > > Multicolumn is best for screen reading, too. The only problem is > there's no good flowing - the columns should fit the screen. There's > work on that, see e.g. http://alistapart.com/article/css3multicolumn. > A. HTML has good flowing, and has had it since freaking v1. No need for upcoming CSS tricks: As long as the author doesn't go and do something retarded like use a fixed layout or this new "zoom out whenever the window shrinks" lunacy, then all any user ever has to do is adjust the window to their liking. If someone expands their browser to be two-feet wide and ends up with too much text per line, then really they have no one to blame but their own dumbass self. B. There's nothing stopping authors from making their PDFs a single-column at whatever line width works well. Like I said, personally I've never found 8" line width at a normal font size to be even the slightest hint harder than 10 words per line (in fact, sometimes I find 10 words per line to be *harder* due to such frequent line breaks), *but* if the author wants to do 10 words per line in a PDF, there's *nothing* in PDF stopping them from doing that without immediately sacrificing those gains, and more, by going multi-column. Bottom line, obviously multi-column PDF is a bad situation, but we already *have* multiple dead-simple solutions even without throwing our hands up and saying "Oh, well, there's no good *multi-column* solution ATM, so I have no way to make my document readable without waiting for a reflowing-PDF or CSS5 or 6 or 7 or whatever." An obsessive desire for multi-column appears to be getting in the way of academic documents that have halfway decent readability. Meanwhile, the *rest* of the word just doesn't bother, uses single-column, and gets by perfectly fine with entirely readable documents (Well, except when they put out webpages with gigantic sizes, grey-on-white text, and double-spacing - Now *that* makes things *really* hard to read. Gives me a headache every single time - and it's always committed by the very people who *think* they're doing it to be more readable. Gack.) I *really* wish PDF would die. It's great for printed stuff, but its mere existence just does far more harm than good. Designers are already far too tempted to treat computers like a freaking sheet of paper - PDF just clinches it for them.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 18:25:02 UTC, Andrei Alexandrescu wrote: On 8/11/13 10:20 AM, Nick Sabalausky wrote: On Sun, 11 Aug 2013 09:28:21 -0700 Andrei Alexandrescu wrote: On 8/11/13 8:49 AM, monarch_dodra wrote: On Sunday, 11 August 2013 at 15:42:24 UTC, Nick Sabalausky wrote: On Sun, 11 Aug 2013 01:22:34 -0700 Walter Bright wrote: http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf Holy crap those two-column PDFs are hard to read! Why in the world does academia keep doing that anyway? (Genuine question, not rhetoric) But the fact that article even exists is really freaking awesome. :) My guess is simply because it takes more space, making a 4 page article look like a 7 page ;) Double columns take less space Per column yes, but overall, no. The same number of chars + same font == same amount of space no matter how you rearrange them. If anything, double columns take more space due to the inner margin and increased number of line breaks (triggering more word-wrapping and thus more space wasted due to more wrapped words - and that's just as true with justified text as it is with left/right/center-aligned. For a column of text to be readable it should have not much more than 10 words per line. Going beyond that forces eyes to scan too jerkily and causes difficulty in following line breaks. Filling an A4 or letter paper with only one column would force either (a) an unusually large font, (b) very large margins, or (c) too many words per line. Children books choose (a), which is why many do come in that format. LaTeX and Word choose (b) in single-column documents. and are more readable. In *print* double-columns are arguably more readable (although I've honestly never found that to be the case personally, at least when we're talking roughly 8.5" x 11" pages). But it's certainly not more readable in PDFs, which work like this (need monospaced font): Start | /| |/ | | Scroll | | Up / | Scroll | /| Scroll Down |/ | Down | / | | / | | /| |/ | / /---/ / | /| |/ | | Scroll | | Up / | Scroll | /| Scroll Down |/ | Down | / | | / | | /| |/ | / /---/ / | /| |/ | | Scroll | | Up / | Scroll | /| Scroll Down |/ | Down | / | | / | | /| |/ | | End Multicolumn is best for screen reading, too. The only problem is there's no good flowing - the columns should fit the screen. There's work on that, see e.g. http://alistapart.com/article/css3multicolumn. Andrei I really wish this was more popular: __ | || | 1 | 2| | || | || || | || | 3 | 4| | || | || ___ page break ___ | || | || | 1 | 2| | || || | || | || | 3 | 4| | || This allows a multi-column layout with less scrolling. The aspect ratio on my screen is just about perfect to fit half of a page at a time. I don't understand why this is rarely taken advantage of... For example, I like G+'s layout because posts seem to be layed out L->R, T->B like so: | 1 | 2 | 3 | | 4 | 2 | 3 | | 4 | 2 | 5 | | 6 | 7 | 5 | Why can't we get the same for academic papers? They're even simpler because each section can be forced to be the same size.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 8/11/13 10:20 AM, Nick Sabalausky wrote: On Sun, 11 Aug 2013 09:28:21 -0700 Andrei Alexandrescu wrote: On 8/11/13 8:49 AM, monarch_dodra wrote: On Sunday, 11 August 2013 at 15:42:24 UTC, Nick Sabalausky wrote: On Sun, 11 Aug 2013 01:22:34 -0700 Walter Bright wrote: http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf Holy crap those two-column PDFs are hard to read! Why in the world does academia keep doing that anyway? (Genuine question, not rhetoric) But the fact that article even exists is really freaking awesome. :) My guess is simply because it takes more space, making a 4 page article look like a 7 page ;) Double columns take less space Per column yes, but overall, no. The same number of chars + same font == same amount of space no matter how you rearrange them. If anything, double columns take more space due to the inner margin and increased number of line breaks (triggering more word-wrapping and thus more space wasted due to more wrapped words - and that's just as true with justified text as it is with left/right/center-aligned. For a column of text to be readable it should have not much more than 10 words per line. Going beyond that forces eyes to scan too jerkily and causes difficulty in following line breaks. Filling an A4 or letter paper with only one column would force either (a) an unusually large font, (b) very large margins, or (c) too many words per line. Children books choose (a), which is why many do come in that format. LaTeX and Word choose (b) in single-column documents. and are more readable. In *print* double-columns are arguably more readable (although I've honestly never found that to be the case personally, at least when we're talking roughly 8.5" x 11" pages). But it's certainly not more readable in PDFs, which work like this (need monospaced font): Start | /| |/ | | Scroll | | Up / | Scroll | /| Scroll Down |/ | Down | / | | / | | /| |/ | / /---/ / | /| |/ | | Scroll | | Up / | Scroll | /| Scroll Down |/ | Down | / | | / | | /| |/ | / /---/ / | /| |/ | | Scroll | | Up / | Scroll | /| Scroll Down |/ | Down | / | | / | | /| |/ | | End Multicolumn is best for screen reading, too. The only problem is there's no good flowing - the columns should fit the screen. There's work on that, see e.g. http://alistapart.com/article/css3multicolumn. Andrei
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sun, 11 Aug 2013 09:28:21 -0700 Andrei Alexandrescu wrote: > On 8/11/13 8:49 AM, monarch_dodra wrote: > > On Sunday, 11 August 2013 at 15:42:24 UTC, Nick Sabalausky wrote: > >> On Sun, 11 Aug 2013 01:22:34 -0700 > >> Walter Bright wrote: > >> > >>> http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf > >> > >> Holy crap those two-column PDFs are hard to read! Why in the world > >> does academia keep doing that anyway? (Genuine question, not > >> rhetoric) > >> > >> But the fact that article even exists is really freaking > >> awesome. :) > > > > My guess is simply because it takes more space, making a 4 page > > article look like a 7 page ;) > > Double columns take less space Per column yes, but overall, no. The same number of chars + same font == same amount of space no matter how you rearrange them. If anything, double columns take more space due to the inner margin and increased number of line breaks (triggering more word-wrapping and thus more space wasted due to more wrapped words - and that's just as true with justified text as it is with left/right/center-aligned. > and are more readable. > In *print* double-columns are arguably more readable (although I've honestly never found that to be the case personally, at least when we're talking roughly 8.5" x 11" pages). But it's certainly not more readable in PDFs, which work like this (need monospaced font): Start | /| |/ | | Scroll | | Up / | Scroll | /| Scroll Down |/ | Down | / | | / | | /| |/ | / /---/ / | /| |/ | | Scroll | | Up / | Scroll | /| Scroll Down |/ | Down | / | | / | | /| |/ | / /---/ / | /| |/ | | Scroll | | Up / | Scroll | /| Scroll Down |/ | Down | / | | / | | /| |/ | | End Of course, you can zoom out enough that the entire page is viewable on one screen so you don't have that ridiculous scroll-dance, but then everything becomes too small to be readable, unless you're one of the rare few who have a monitor that swivels vertically or some ridiculous size like 36" (which isn't applicable to the vast majority of users).
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On 8/11/13 8:49 AM, monarch_dodra wrote: On Sunday, 11 August 2013 at 15:42:24 UTC, Nick Sabalausky wrote: On Sun, 11 Aug 2013 01:22:34 -0700 Walter Bright wrote: http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf Holy crap those two-column PDFs are hard to read! Why in the world does academia keep doing that anyway? (Genuine question, not rhetoric) But the fact that article even exists is really freaking awesome. :) My guess is simply because it takes more space, making a 4 page article look like a 7 page ;) Double columns take less space and are more readable. Andrei
Re: Is D the Answer to the One vs. Two Language High , Performance Computing Dilemma?
On Sunday, 11 August 2013 at 08:48:04 UTC, Iain Buclaw wrote: ..whatever happened to std.serialize? I am gathering information to start yet another review/inclusion attempt + waiting for Jacobs confirmation. In progress.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sunday, 11 August 2013 at 15:42:24 UTC, Nick Sabalausky wrote: On Sun, 11 Aug 2013 01:22:34 -0700 Walter Bright wrote: http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf Holy crap those two-column PDFs are hard to read! Why in the world does academia keep doing that anyway? (Genuine question, not rhetoric) But the fact that article even exists is really freaking awesome. :) My guess is simply because it takes more space, making a 4 page article look like a 7 page ;)
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Sun, 11 Aug 2013 01:22:34 -0700 Walter Bright wrote: > http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf Holy crap those two-column PDFs are hard to read! Why in the world does academia keep doing that anyway? (Genuine question, not rhetoric) But the fact that article even exists is really freaking awesome. :)
Re: Is D the Answer to the One vs. Two Language High , Performance Computing Dilemma?
On 11 August 2013 09:22, Walter Bright wrote: > http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf That looks to have been written well over a year ago... But still a good point in it, whatever happened to std.serialize? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Is D the Answer to the One vs. Two Language High , Performance Computing Dilemma?
http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf
