The D Programming Language (was: Still more new operators)

[Henry Spencer]

> >Most machines cannot handle bits with anywhere near the efficiency
> >with which they handle bytes...
> 
> Be careful; cause and effect are circular here.  I've been contacted by
> more than one computer architect who wanted bit addressability but had
> trouble convincing management to accept the slightly added expense because
> they would observe that such a facility could not be exploited from popular
> high-level languages...

I once had the opportunity to ask Bill Wulf what he thought of bit-oriented
machines; his answer was "I wish they weren't so damned slow".  I'm afraid
I haven't seen anything since that invalidates that assessment.  There is
something to be said for providing bit addressability, but one must realize
that actually exploiting it will be slow and that there will still be a
large payoff for trying to work on byte or word boundaries whenever possible.

Also, designing D so it will run real well on our hypothetical dream machine
is probably not a good idea.

> >Please explain how avoiding superfluous words and keeping necessary ones
> >short is consistent with changing {/} to begin/end for no particular reason.
> 
> A better reason for a change here is the problems cause by "dangling else"

You misunderstood here, Doug.  I have no objection to self-bracketing
control constructs, in fact I quite like them.  What I was objecting to was
retaining an explicit bracketing construct but changing its spelling.
-- 
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry