www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is D the Answer to the One vs. Two Language High ,Performance Computing

reply Walter Bright <newshound2 digitalmars.com> writes:
http://elrond.informatik.tu-freiberg.de/papers/WorldComp2012/PDP3426.pdf
Aug 11 2013
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 11 August 2013 09:22, Walter Bright <newshound2 digitalmars.com> 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';
Aug 11 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 11 Aug 2013 01:22:34 -0700
Walter Bright <newshound2 digitalmars.com> 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. :)
Aug 11 2013
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 11 August 2013 at 15:42:24 UTC, Nick Sabalausky wrote:
 On Sun, 11 Aug 2013 01:22:34 -0700
 Walter Bright <newshound2 digitalmars.com> 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 ;)
Aug 11 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 <newshound2 digitalmars.com> 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
Aug 11 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/11/13 10:20 AM, Nick Sabalausky wrote:
 On Sun, 11 Aug 2013 09:28:21 -0700
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> 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 <newshound2 digitalmars.com> 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
Aug 11 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/11/13 12:00 PM, Nick Sabalausky wrote:
 On Sun, 11 Aug 2013 11:25:02 -0700
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> 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
Aug 11 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 11 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 11 Aug 2013 20:01:27 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> 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 future will tell what the right replacement is.

The right replacement is to have dynamic page layout that doesn't depend on CSS hacks or other arbitrary decisions by the publisher like number of columns, etc.. This isn't the age of paper anymore; layout should be done automatically by the end-user's browser, not by content producers, who should be worrying about the content, not the layout.

Exactly. In other words, the right solution is more or less equivalent to HTML 1 or 2. They already had it pretty much right back in the 90's. But then people wanted their "dancing pigs" so to speak, and we ended up with this unholy mutant we have know: HTML 5. World's worst UI format, and no longer a good document format either. ...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.
 
 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).
Aug 11 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 12 Aug 2013 09:18:26 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> 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" <hsteoh quickfur.ath.cx> 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 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.

Yea. But as we've both said, layout belongs more on the viewer's end rather than the content provider's end anyway, so I'm not sure HTML/CSS, as a document format, really even *should* provide much, if anything, in the way of layout. That's why I think HTML 1/2 are actually somewhat better for documents than HTML 4/5 (which is more like a half-assed UI system than a "document" format).
 
 [...]
 ...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)

Heh :) I haven't allowed Adobe Reader on my system in probably at least 10 years. I use FoxIt reader now (or the one built into FF22). Neither are particularly spectacular though, but I haven't found anything better. And I'm not sure how much better it *could* be since PDF is almost as poorly suited to reflowing as a JPEG (an exaggeration, but a fairly small one).
 
 
 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 BASIC too. I quite liked it, it forces your code to be simple and to-the-point. Of course, code back in those days was also a tangled mess of GOTO's of spaghetti code, so perhaps my memory has been tainted by nostalgia. :)

Heh, yea. While I have fond memories and high nostalgia/respect for those older BASICs, I'm not sure I would really want to use them again, except maybe as a teaching aid for first time programmers. (I think they're very good for learning flow-of-exection - which I see as the most fundamental concept in programming.)
 
 On Mon, Aug 12, 2013 at 11:51:29AM +0200, John Colvin wrote:
 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.

I find 8pt completely unreadable, both in print and on-screen. In print, I'd prefer at least 10pt or 12pt.

Good point sizes are pretty highly dependent on a lot of factors though, like screen size, pixel density, and even the font itself or the language. Ex: Windows notepad looks "right" for me at 10pt, but anytime I have Japanese text, even just the phonetic alphabets without any Chinese kanji, I have to bump it up to at least 12pt. Not that I use notepad for much.
 On screen, I set my browser
 to force minimum font size to 16pt, because some websites insist on
 using microscopic fonts (usually by specifying pixel sizes, which is
 silly since they can't possibly predict pixel density on users'
 screens / browser window sizes!). The web became a lot more readable
 after that. (And it also exposed a lot of flaws in HTML/CSS designs
 that are hardcoded to a specific font size -- once you force the font
 size to be larger than the designers anticipated, the layout breaks
 left right and center. Which is silly; in this day and age, this
 stuff should be automated. There's no reason why designers should
 still be tweaking pixels that don't reflect what's actually displayed
 on the users' screens anyway.)
 

Hear, hear!
Aug 12 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/11/13 12:09 PM, Nick Sabalausky wrote:
 On Sun, 11 Aug 2013 20:43:17 +0200
 "Tyler Jameson Little" <beatgammit gmail.com> 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
Aug 11 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 11 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 academists defend the likes of IEEE etc., which use the funds gathered that way for good purposes. I know most conferences don't prevent their authors from putting their work online. In CS it is very rarely the case that a paper cannot be found without having to pay for it, and in those rare cases a little social engineering gets you the paper (I wrote the author and got it once).
 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. :-)

Well I'm unconvinced but this seems to be one of those potayto-potahto kind of things. I do agree the situation can improve. Andrei
Aug 12 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Aug 13 2013
prev sibling next sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
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 <SeeWebsiteForEmail erdani.org> 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 <newshound2 digitalmars.com> 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.
Aug 11 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 11 August 2013 at 15:42:24 UTC, Nick Sabalausky wrote:
 On Sun, 11 Aug 2013 01:22:34 -0700
 Walter Bright <newshound2 digitalmars.com> 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.
Aug 11 2013
prev sibling next sibling parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
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.
Aug 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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 <newshound2 digitalmars.com> 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.
Aug 12 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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. :-)
Aug 12 2013
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
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
Aug 12 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
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.
Aug 12 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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.
Aug 12 2013
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
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 <newshound2 digitalmars.com> 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
Aug 12 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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:


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?" ;)
Aug 12 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
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.
Aug 12 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Aug 12 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Aug 12 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
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.
Aug 12 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Aug 12 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
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?
Aug 12 2013
prev sibling next sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
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...
Aug 12 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Aug 12 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 12 Aug 2013 12:34:22 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> 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.
Aug 12 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Aug 12 2013
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
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
Aug 12 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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 that is that it just gets handed to an overworked reviewer without the time or inclination to try and understand the work properly. With journals you have a right of reply and if it's obvious that a referee is either biased or not capable of understanding the work, you can appeal to the editor to discount their opinion.
 Journal papers.

Yes, but that's insufficient in CS given the dominance of proceedings as a publication venue. It's also my impression that quite a lot of top-tier journal publications are essentially the final step of a process that begins with 2-3 years of hawking around a particular body of work through the conferences -- without which it's unlikely you'll get a look-in except in obscure journals. (But top-tier journals tend to be problematic in all fields -- your best bet of publishing in any major journal is to co-author with someone who's already published there.)
 Many academists defend the likes of IEEE etc., which use the funds gathered
that
 way for good purposes. I know most conferences don't prevent their authors from
 putting their work online. In CS it is very rarely the case that a paper cannot
 be found without having to pay for it, and in those rare cases a little social
 engineering gets you the paper (I wrote the author and got it once).

I regularly have pain and annoyance trying to get hold of stuff that has been published in IEEE proceedings lines. Besides, we were talking about the time delay between academia and industry -- I don't think that we can expect that many companies to take out library subscriptions or risk $25 a pop on papers. But I think open access is another debate, albeit one that I think in principle is pretty unanswerable in the internet age.
 Well I'm unconvinced but this seems to be one of those potayto-potahto kind of
 things. I do agree the situation can improve.

Well, everyone has their own priorities and different experience of the problems, and depending on your area of work (and the institutions you're affiliated with) different things may affect you more or less. I used to joke with various professors that they would have to die before we could solve the problems of research publication, because from their point of view the pros almost invariably outweighed the cons -- they were adept at working with the current system and had much at risk with alternatives. These were people I had great affection for, you understand, but I think that point wasn't entirely without merit -- not because they had a conflict of interest in a selfish way, but because their sense of responsibility both towards the quality of their own work and their ability to positively influence the careers of their students led them to prefer the system that they knew over alternatives.
Aug 12 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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).
Aug 12 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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 ... :-)
Aug 12 2013
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
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.
Aug 13 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
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:




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" :)
Aug 13 2013
prev sibling next sibling parent "ProgrammingGhost" <dsioafiseghvfawklncfskzdcf sdifjsdiovgfdisjcisj.com> writes:
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
Aug 18 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 August 2013 18:24, ProgrammingGhost
<dsioafiseghvfawklncfskzdcf sdifjsdiovgfdisjcisj.com> 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';
Aug 18 2013
prev sibling next sibling parent "ProgrammingGhost" <dsioafiseghvfawklncfskzdcf sdifjsdiovgfdisjcisj.com> writes:
On Sunday, 18 August 2013 at 17:28:16 UTC, Iain Buclaw wrote:
 On 18 August 2013 18:24, ProgrammingGhost
 <dsioafiseghvfawklncfskzdcf sdifjsdiovgfdisjcisj.com> 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?
Aug 19 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Aug 19 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Aug 11 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 11 Aug 2013 09:28:21 -0700
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> 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 <newshound2 digitalmars.com> 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).
Aug 11 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 11 Aug 2013 11:25:02 -0700
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> 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.
Aug 11 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 11 Aug 2013 20:43:17 +0200
"Tyler Jameson Little" <beatgammit gmail.com> 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.
Aug 11 2013
prev sibling next sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
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
Aug 11 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 11 Aug 2013 16:33:26 -0700
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> 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).
Aug 12 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 12 Aug 2013 13:50:19 +0200
"Wyatt" <wyatt.epp gmail.com> 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.
Aug 12 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 12 Aug 2013 13:45:02 +0200
Joseph Rushton Wakeling <joseph.wakeling webdrake.net> 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.
Aug 12 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 12 Aug 2013 21:23:17 +0200
"Idan Arye" <GenericNPC gmail.com> 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? ;)
Aug 12 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 12 Aug 2013 18:51:39 +0200
"Dicebot" <public dicebot.lv> 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.
Aug 12 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 13 Aug 2013 03:00:10 +0200
"deadalnix" <deadalnix gmail.com> 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.
Aug 12 2013
prev sibling next sibling parent reply John Joyus <john.joyus gmail.com> writes:
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?
Aug 17 2013
next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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


=20
 This article claims the "Performance [of D] is equivalent to C".
=20
 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sequential pi =3D 3.141592653589970752 iteration count =3D 1000000000 elapse time =3D 8.623442 C++: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sequential pi =3D 3.14159265358997075 iteration count =3D 1000000000 elapse =3D 8.61212399999999967 D: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D pi= _sequential.d =CF=80 =3D 3.141592653589970752 iteration count =3D 1000000000 elapse time =3D 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D pi= _sequential.d =CF=80 =3D 3.141592653589970752 iteration count =3D 1000000000 elapse time =3D 8.616558 And you are going to ask about DMD aren't you :-) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D pi= _sequential.d =CF=80 =3D 3.141592653589970752 iteration count =3D 1000000000 elapse time =3D 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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Aug 18 2013
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
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.
Aug 18 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Aug 18 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
 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.
Aug 18 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Aug 18 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Aug 18 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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?
Aug 18 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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 = 1000000000 elapse time = 8.623442 C++: ==================== Sequential pi = 3.14159265358997075 iteration count = 1000000000 elapse = 8.61212399999999967 D: ======================== pi_sequential.d π = 3.141592653589970752 iteration count = 1000000000 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 = 1000000000 elapse time = 8.616558 And you are going to ask about DMD aren't you :-) ======================== pi_sequential.d π = 3.141592653589970752 iteration count = 1000000000 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.
Aug 18 2013
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Aug 18 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 18 Aug 2013 06:35:30 -0400
Jeff Nowakowski <jeff dilacero.org> 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.
Aug 18 2013