Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?

[Nick Sabalausky]

On Mon, 12 Aug 2013 09:18:26 -0700
"H. S. Teoh" <hsteoh at 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 at 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!