Re: Great SWT Program

On Oct 14, 1:39 pm, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
Well, if you believe that GUIs are the be-all and end-all of user
interfaces, that might be true. I'm not convinced they are -- I'm
not sure what the user interface of 2057 will be like, but I have
no trouble believing it will be as foreign to what we have now as
GUIs initially seemed to me. If one believes that maybe GUIs are
not the last word, it seems to me obvious that exposure to more
than one type of interface is a good thing, in making it clear that
there *is* more than one way to do things.

This presupposes that they're all "different, but equal". Bleeding-
heart liberal bull***. Some are better than others. First came
patching or toggling stuff in by hand. Then came punched cards; a
distinct improvement. Then line-oriented interactive software on text
terminals -- actual interactive software! Then screen-oriented
terminal mode stuff. Then the GUI. Each an improvement over the last,
offloading more of the user's mental work onto the computer and
simplifying the mechanics of interaction so that the mechanics would
get out of the way easily and let the user focus their mental effort
on the actual job they were doing instead of the mechanics of
manipulating the interface. Also, each one providing a richer and more
informative feedback as the user worked.

I've no doubt something will surpass the present-day GUIs some day. It
might well be in less than ten years and will likely involve an
abstraction of command sources, such that the engine of software
doesn't even know or care if it came from automation, voice
recognition, text input, or mouse clicks. Add in a growth in input
tools -- touch screens, cameras that can recognize gestures, a "wand"
like mouse you wave in the air (they have this; the Nintendo Wii uses
one as its game controller), 3D (where appropriate), and voice
recognition, and you've got a lot of overlapping input methods.
Probably users will be able to develop their own styles of which to
use when, as already people do when the mouse and keyboard can both be
used for something. Some GUI features will no doubt persist; the use
of actual written text using glyphs from natural languages persisted
from the first days of line-oriented terminals onward after all. I
expect things like visual highlighting of selected objects, visible
docks or stacks of backgrounded tasks, the ability to physically
juxtapose objects being worked on in tandem, and the like will persist
indefinitely; they're too useful to give up and unlikely to be
superseded by anything conceivable. Menus might go entirely
contextual, but will likely persist in much their present form, though
voice command might make them used infrequently and mainly to browse
for a command you don't know for sure exists or whose exact name
escapes you. The clipboard will probably see big changes; once
hardware reaches the point that very wide or multiple displays are
commonly available, a visual scrapbook might replace the clipboard
concept. Even sooner than that, a clipboard history or clipboard MRU
seems likely given how useful it would be, accessed in various ways
and when opened taking the form of a window with icons, thumbnails, or
other representations of the contents. Probably this would allow
grouping by time, size, and type of data.

plus the
aforementioned "this is what we had to put up with back in the Dark
Ages before the invention of Super VGA" bit of history grounding so
they can thank their lucky stars that they get to program after the
invention of the equivalent of the light bulb instead of having to do
so by dim torchlight in the dark. ;)

Except, of course, that some of us actually *like* vi/emacs.

That's called Stockholm Syndrome. You might have heard of it. :)

If there's room, a bit of exposure to something functional for *real*
different stuff, plus C for low-level bits and bytes and masks,
pointer arithmetic and pointer debugging stuff.

I'd rate exposure to different paradigms as more important than
exposure to different languages in the same paradigm.

That's why I suggested Python, Smalltalk, and Java together; they're
all oriented toward different use scenarios and two are of practical
use.

Again,
it might be a moot point if one believes that the OO paradigm
will, and should, continue to be the dominant one throughout
these students' careers.

Eh? The only thing I foresee superseding OO is something that contains
an OO subset, likely something aspect-oriented. Actually, interacting
networks of OO or AO software seems likely to be the pinnacle; the
final big challenge after dealing with crosscutting concerns is
scaling things up robustly, and decomposing monoliths into interacting
modules that have separate address spaces and run concurrently is the
big thing there. A highly threaded program in a JVM is already rather
like that, as given a bug-free JVM it won't actually matter that they
technically share one address space.

Aside from OO, what is there now?

Procedural is a subset of OO, as OO is a subset of AO.

Functional is also a subset of OO, given that it's possible to write
code in a functional style in OO. A cleaner syntax for lambdas than
Java's anonymous inner classes and a "final by default, a keyword such
as 'mutable' required for non-final" change would make it easier but
wouldn't be required.

Pure functional is also really only of academic interest, because most
real-world programming problems are more naturally represented in
terms of changing state rather than as a mathematical expression
evaluation, and in practise the functional equivalents of a lot of
things would emulate statefulness by having "versioned states" such
that each was immutable, resulting in a memory hog. Ultimately,
functional is poorly suited for anything interactive; it might be
doable, indeed surely is if the language is turing-complete and not
completely batch-oriented in design, but it would be much more
difficult to program than in some other language. There will be niche
uses of pure functional stuff, though. I figured a next-gen LaTeX
might usefully employ a functional language under the hood, because
it's a stream processor at heart, but with back-references and the
like needing multiple passes, that can be represented as functional
inferences; and the present LaTeX shows much of its cruftiness and
presents users with much of their trouble when the underlying
statefulness and side-effect-capability of the macro system shows
through the veneer of structured declarative document coding.

(But pure OO is really only of academic interest too, e.g with
Smalltalk; the main problems preventing practicality there being poor
speed and the overhead of carrying around all the baggage of a heavy-
duty reflection API that the system uses and relies on internally.)

An ideal language would probably resemble Java but with aspect
features (so perhaps resembling AspectJ more) and having some other
features. Cleaner lambdas/closures, type inference, final-by-default,
a cannot-be-null version of each reference type, etc.

Well, you could type, from the command line, "gnuplot", whereupon
you get a screenful of text telling you how to access the online
help and giving the URL of a FAQ. Following the directions for
accessing the online help brings up something that tells you more
about how to use it.

Useful, if you have the luxury of a) a working net connection and b) a
working X session, so that gnuplot can be in a terminal window and you
can tab to a Firefox window and surf the web and google stuff with.

I guess I didn't make myself clear: The "online help" is built-in
and not connected, except in the sense of being about the same tool,
with the FAQ on the Web. The built-in online help does not require
a 'Net connection.

Unfortunately, if it's as you now describe, it instead requires
already being familiar with the application's keybindings to use
effectively. The usual catch-22 in other words.

I guess you don't read man pages, then. Most of them have a section
called "FILES" at the end.

Not from cover to cover; and nothing essential to normal use should be
in technical appendices instead of the main matter anyway.
Error recovery maybe, but it really should only be possible to have
those errors because of having messed with something at the same
technical level in the first place.

True .... though now that I think about it, the data communicated
over a (Unix) pipe doesn't have to be ASCII text.

True, but there isn't much point in sending jpegs around as byte-
streams when there is no way to present them to the user save as low-
resolution ASCII half-tones like you sometimes see posted to
usenet. :P

Anyway, for multiple tools collaboratively working on graphics, you
will rapidly run into scaling problems using streams at all. Same with
big enough texts. For big enough objects, what you really want is an
object server that holds the object and provides clients with views of
objects and other data about objects. A rectangle from an image, say.
This server also lets clients post modifications, and ensures serial
access in whatever way is appropriate. (In a Java system you might
have a single app with two threads and some sort of synchronized
object containing a bitmap, say.)

As far as I can remember, you've talked only about transferring
information via a system clipboard manually. I guess I'm
speculating, in a very vague way, about other kinds of interaction.
I'm not at all sure where I'm going with that, though; possibly
nowhere!

I went into a fair bit of detail about an "embedding" concept, based
on Microsoft's OLE stuff only hopefully without the standard MS shoddy
implementation to go with it. Given a *decent* implementation, and
extension to other concepts, you could have graphical tools that can
be run somewhat by automation or chain to one another in embedding
data of various sorts into larger documents or objects of some sort.

.

Quantcast