Re: CHAT: programming langs
From: | Lars Henrik Mathiesen <thorinn@...> |
Date: | Wednesday, November 17, 1999, 11:26 |
> Date: Tue, 16 Nov 1999 20:07:50 -0500
> From: Brook Conner <nellardo@...>
> Um, no. Not the power - that will be there. The problem is using
> English as a specification language. It doesn't work. Specifications
> today are not all prose. They can include complex diagrams, formal
> symbols, and all sorts of other non-English stuff.
Well, I shouldn't have said 'plain English'. If people need to use
specialized sublanguages to explain something to other people, of
course they need them to explain it to the computer too. And formal
symbols and diagrams are used because they are more precise than
prose, so programming a computer to understand them should be simpler
than general natlang understanding.
> This is a commn occurance in spoken language - we leave things out
> and the listener has to infer what is meant. That's harder than even
> understanding the speech stream - it requires knowledge of the
> world. Forget compute power - this is an open research problem.
What I imagine could be extremely useful is support for iterative
design. You describe a problem in terms of what you need and what
you've got already; the computer tries to work out a procedure to get
the result you want, and describes it in broad terms.
You can then ask it to do things like describe a specific step in the
procedure in more detail, run the procedure on some test data, answer
what-if questions. And then you tell it what it did wrong and iterate.
Sort of programming by discussion.
And once in a while you'll have to say 'Oh, let me show you'... and
then you get an editor window where you can type the 5 lines of perl
that are needed for the really central part of the procedure.
> Lars Henrik Mathiesen writes:
> > I'd still like to be able to just say 'delete rest of text and send'.
>
> Sure would be nice, but what happens when you realize that what the
> computer thought was the "rest" is not what you thought it was? "and
> send...." oops.
Perhaps I'd make a little pause while waiting for visual feedback...
'delete rest of text and... oops, undo'.
> My point was not that *all* menu actions are faster - my point was
> that different UI actions have different *perceived* durations that
> *do not* match wall clock time.
That is very true. You should just have put 'some keyboard shortcuts',
and I'd have kept my mouth shut.
> > And it also depends on how good the UI is at making the keyboard or
> > the mouse useful. Posting dialogs with the OK button under the pointer
> > is good.
>
> Maybe - if it is an information-only dialog, putting it under the
> cursor is obstructive. UI design simply is not that simple.
I'm thinking of modal dialogs. 'Converting the image to indexed colors
may cause loss of quality. [OK] [Cancel]' type silly warnings. The
applications I've seen use this technique all made the distinction.
> > And if only the Windows file dialog would start 'positioned'
> > (dashed outline, not selecting) at the last file opened by the
> > application, "try the next one instead" would be CTRL+F4 CTRL+O DOWN
> > ENTER.
>
> Um, clearly a very easy key sequence to remember :-)
Yes, it is --- when you know that the individual key presses mean
'close current document', 'post open file dialog', 'go to next
object', 'open selected object'. Each one has an immediate effect in
the GUI, and the meanings are general enough that they are useful in
most Windows and Motif applications. So you don't actually need to
remember the sequence as much as invent it again; it's not magic that
has to be learned by heart.
> > (Would be useful with a mouse too, I always forget where in the
> > list of files I'd gotten to. My digital camera produces hundreds of
> > files all called something like mvc-123s.jpg).
>
> A product of brain-damaged software design by Sony engineers more
> interested in reducing product cost than providing useful, intelligent
> abilities.
Sure. They should have put a keyboard on the camera so I could name
the files while shooting.
What naming convention would you choose, given that the storage medium
is a DOS-formatted floppy? (There's no upload progam to interact with
the user).
Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@...> (Humour NOT marked)