*blink* That's neat.

[Martijn Faassen]

Niels Diepeveen <niels at endea.demon.nl> wrote:

> Martijn Faassen schreef:
>> 
>> I'm not claiming we should ignore HCI people. You were the one who started
>> with the silly usability research comment. :) But if certain HCI people
>> produce research that shows 'and' and 'or' are about the worst names for
>> these operators, then I'd indeed question that research and those particular
>> HCI people. There isn't actually such research, is there, though, I assume?

> I wouldn't be surprised if there was. If you use common words for
> certain things, people will assume that they know what they mean. So
> they _will_ write things like "if a is 1 or 2". Stands to reason that
> that doesn't mean "always", right?

Sure, I remember making that mistake long long ago. But I don't think
there's a good solution to this learning problem in any case.

> Forcing them to use unfamiliar
> symbols like "=="

I'm not sure how 'is' worse, except that indeed perhaps it does look too much
like natural language in combination with 'or'. '=' would've been better
as a symbol, but of course that was already in use for assignment.
 
> and "||" would probably cause them to think twice
> about what they really mean, and save them a few hours looking for a
> problem that turns out to be in the one piece that is so obviously
> right.

I don't think it's possible to avoid this kind of newbie problem in any
case. I also think the 'couple of hours' is likely exaggarated; a newbie
isn't going to experiment with boolean expressions in a large program
immediately, hopefully. (if the newbie *is* going to do that, the newbie
has something else to learn; always experiment in isolation)

> Counterintuitive semantics are a far greater problem than
> unfamiliar syntax.

True, though it would seem hard to avoid to call || and && 'or' and 'and'
anyway. And it can't be *that* incredibly hard to learn about 'and' and
'or's behavior. I suppose we do need those HCI people to back all this
up with research, though. :)

>   BTW, my own observation is that many people have enormous problems
> understanding Boolean expressions with multiple operators, no matter how
> you write them. This is especially true if there is negation involved
> somewhere.

I always seem to be able to rewrite my booleans to something I can 
follow. I think it's a knack one picks up in programming. booleans can
definitely be made to look complex, though.

>> Note that I'm not questioning the Alice result on case-sensitivity;
>> I'm sure case-sensitivity confused beginners. 

> I'm not sure Alice has much of a "result" to offer on the subject. As
> far as I can tell from the paper I have read, doing away with case
> sensitivity was just the nearest hack available, not a decision based on
> scientific analysis of the whole interface problem.

True; I don't think there was done any double-blind research into this
phenomenon. It was just an anecdotal observation, perhaps in a more
controlled setting than ours, but probably still doesn't weigh much more
strongly than our own anecdotal observations.

> I'd want to see some
> serious research before accepting sweeping statements like "Case
> sensitivity is a bug in programming languages intended for novice
> users.". (That should be taken to mean that I think the Alice project is
> not serious research; I just think it's far from conclusive on this
> issue. Even simple people aren't that simple.)

Right -- and if you're going to learn programming, you're going to have
to learn about programming discipline; perhaps it's better to learn it
sooner than later, too, as you're going to need it anyway. I think one
of the most important things one can do to increase learnability of a
language is to increase orthogonality and readability. Programs will
always be tricky to write, but at least it should be possible to write
code one can read again later. Case-insensitivity only does potential
harm in that regard. 'or' and 'and' versus '||' and '&&' are probably
fairly neutral, though I do think 'or' and 'and' are slightly
prettier. :)

Usability research on programming languages is probably tough to do;
you can do some testing showing non-programmers parts of a program
and asking them what it does and get results that way, but that doesn't
necessarily tell you one bit about how usable the language will be to
a programmer the next day, or the next month, or the next year. And *those*
experiments will be pretty hard to do in a clean fashion.

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?