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.

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.

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

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!

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.

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

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

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.

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.

On Tuesday, 13 August 2013 at 09:52:25 UTC, Chris wrote:
> On Tuesday, 13 August 2013 at 01:00:12 UTC, deadalnix wrote:
>> On Monday, 12 August 2013 at 18:57:12 UTC, Chris wrote:
>>> On Monday, 12 August 2013 at 17:23:39 UTC, Dicebot wrote:
>>>> On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote:
>>>>> On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote:
> True, true. There weren't many options back in the day. But that's no excuse for bad or absurd language design. $asolutely $no $need $to $have $a $syntax $like $this =>

And I recall that PHP was meaning something like "Personally, I
Hate Perl" :)