www.digitalmars.com         C & C++   DMDScript  

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

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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 (unless you have lines full of M's, in which case readability is the least of your problems. :-P)
 - No full justification by default. Existing justification schemes
 could be improved (most implementations suffer from rivers of
 whitespace in a justified paragraph -- they could learn from LaTeX
 here). Needs native hyphenation support (using JS to patch up this
 flaw is a failure IMO).
 
To be honest, I'm not a big fan of justified text. Obviously I can live with it, but even without the occasional "rivers of whitespace" issue, I find the lack of jagged edges gives my eyes too few reference points, so I end up losing my place more easily. The value of justified text's smooth edges, to me, seems somewhat "Adrian Monk" (wikipedia, if you don't know).
I looked it up but didn't quite understand the reference. In any case, I find jagged edges ineffably ugly. It just *looks* sloppy, esp. when there are ready algorithms out there that will fix it for you automatically. It just hearkens back to the bygone days of handwriting. Surely such trifling limitations are no longer applicable in a digital medium?
 - Pixel sizes should be banned, as well as hard-coded font sizes.
 These tie you to assumptions about specific user screen dimensions,
 which are almost always wrong. In this day and age, the only real
 solution is a fully dynamically adaptive layout. Everything else is
 just a relic from paper layouts, and is a dead-end.
Yea. Admittedly, I do occasionally use pixels for a little bit of spacing here and there (never for more than 8px), but I can happily give them up - especially with so much now using those ultra-high pixel density screens. Pixels just don't make much sense now unless you're already dealing on a raster level anyway, like a photo or something.
Exactly!! I have a pretty high-density pixel screen, and it annoys me to the uttermost when websites specify font sizes in pixels, which, inevitably, are squint-inducing microscopic sizes on my screen. And even with photos, jpegs *are* scalable to some extent, which mostly alleviates the need for specific pixel sizes. As I said, pixel sizes are really only applicable with images. It makes no sense at all to use pixel sizes with text and fonts, because it bears no relation to physical screen size at all. [...]
 - Unable to express simple computations on sizes, requiring
 circumlocutions that make the CSS hard to read and maintain.
Yes! That's one of my big issues with CSS, the inability to do anything computationally. And yea, dealing with images tends to make that become more of an issue. Ultimately, the root problem here regarding the lack of computability, is that HTML/CSS is not, and never has been, a UI layout format (No matter how much people insist on treating it as such...*cough*mozilla*cough*.) It's a *document* format. Always has been. Everything else is a kludge, and is doomed to be so from the start.
Even for a *document* format, it's rather limited in the kinds of layouts it can do. All the cool CSS hacks that people pull are nothing more than just that: hacks. [...]
 ...And yet 9 times out of 10 it *still* ends up far more readable
 on-screen than an 8.5" x 11" two-column PDF. Go figure.
You need a better PDF reader. (Hint: Adobe Reader is not one of them. :-P)
 On Sun, Aug 11, 2013 at 04:47:09PM -0700, Walter Bright wrote:
 On 8/11/2013 4:33 PM, Andrei Alexandrescu wrote:
[...]
 Currently ereaders are great for reading novels and such with
 little typography needs. But they're terrible for textbooks and
 reference material, mainly because the screen is both low res and
 is way too small.
 
 It's like programming with an 80*24 display (I can't believe I was
 able to use them!).
[...] I still program with 80*24 displays. Well, more like 80*40, but I find that it's actually far more readable than the common obsession with squint-inducing microscopic fonts trying to cram as much on the screen as possible. Having too many characters per line quickly gets very hard to read.
Heck, I started out on the 40-character-width AppleSoft BASIC. Although I'm sure other people can best me on that (altair, punch cards, etc).
I started out with 40-character Applesoft 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. :) 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. 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.) T -- This is not a sentence.
Aug 12 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

Just a note, you are somehow breaking most threads you answer to.

Bye,
bearophile
Aug 12 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 12, 2013 at 06:49:08PM +0200, bearophile wrote:
 H. S. Teoh:
 
 Just a note, you are somehow breaking most threads you answer to.
[...] It's not my fault, it's the mailman/NNTP interface that's causing problems. I use the mailing list interface. T -- What do you call optometrist jokes? Vitreous humor.
Aug 12 2013
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 12 August 2013 at 17:03:44 UTC, H. S. Teoh wrote:
 It's not my fault, it's the mailman/NNTP interface that's 
 causing
 problems. I use the mailing list interface.
Btw was anyone planning to fix this on server side? I dream of the day when bunch of mail-based responses won't render web forum interface almost unreadable :)
Aug 12 2013
prev sibling 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