On 12/02/03 15:32, Alan Blackwell wrote:
The one thing that can be easily done on screen is to change
colours - hence the ubiquitous availability of keyword colouring.
And jolly ugly it all is too, despite being somewhat useful.
At least emacs and eclipse let me tone it all down from
the hideously sparse vt320-a-like colour palette.
On the face of it, if there was anything to be gained by
distinguishing certain categories of words, then colouring them
would be a better solution than using all caps. However, I'm not
sure that there is real justification for making keywords stand
out. It seems to me that keywords ought to work like punctuation
(unobtrusive, just sufficient to indicate underlying structure),
rather than like headlines.
The main benefits I notice using syntax-colouring in emacs and
eclipse are that:
+ when you mistype a reserved word, you realise it (this
would have saved me a lot of time debugging the C switch()
statement I once wrote that had 'defualt:' in it instead of
'default:'),
+ when you get your quoting wrong on some moby string expression,
the program code south of there literally gets browned-out.
But I can't help feeling that, as I infer from Alan's comments,
we programmers are languishing in a fairly impoverished visual
landscape when it comes to working with code, perhaps due to the
strong ties to ASCII and the perceived need to have stuff editable
on son-of-vt320, and printable by a five-year old LaserJet.
Plus, most programmers seem to have the visual design sense of
a bag of hammers; see the default settings of 'vim' and
'ls' in most Linux distributions for delightful examples that
are even worse than the green-and-blue-and-maroon-on-white
defaults Visual Studio had last time I used it.
The real challenge in typography is to support both fluency of
reading and emphasis of structure within a compositional
structure that does not produce visual strain. I think that most
of the research that has been done into reading performance can
easily be generalised for programming - if only we have the
characterisation of "fluency", "structure" and "strain".
Would this (at least in principle) help on the kinds of fairly
low-resolution devices we use to read things on much of the time?
My laptop screen has 144 pixels to the inch, which is almost adequate
for type rendering, but the 1920x1200 screen is still way too small
for editing tasks, which is why I still carry around pens, two
notebooks and an A4 pad to supplement it.
But it's definitely a lot better than the old 25x80 ASCII-only green-on-
black terminals I was using until far too recently, and which have probably
served to reinforce the very narrow range of presentation options
in the minds of most working programmers. And anyway, the compiler
doesn't care what colour or typeface variable 'foo' is, so why
should they? That's almost like marketing or interior decorating
or something, and obviously not Real Programming.
I think it's no surprise that when many programmers consider altering
their source code to be more readable, they think (at most) of
the disdainfully-named pretty-printing (which usually means
canoncalised indentation and white-space, and maybe some emboldening
in the hard copy).
But they don't seem to think of pretty-editing or pretty-programming,
where syntactically-irrelevant presentational aspects of the code
are nevertheless considered an important and useful aspect of the
source, and are easily maintainable by the tools they have to hand.
If they did, we might end up in a world where identifiers didn't
need to be in camel case, or contain underscores or dots, because
they could be highly descriptive or completely hidden when we wanted
them to be, without them all having to be purple.
--
Frank Wales [EMAIL PROTECTED]
----------------------------------------------------------------------
PPIG Discuss List ([EMAIL PROTECTED])
Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss
Announce admin: http://limitlessmail.net/mailman/listinfo/announce
PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
