I honestly fail to see the problem.  A so-called command-line interface
  is indistinguishable from a protocol if it is intelligently designed, like
  the Common Lisp read-eval-print-loop.  A more MTV generation-friendly user
  interface can then be built independently and either talk the protocol or
  call the functions directly depending on how tight you want the coupling.

  If you design your "graphical" user interface so the coupling is so tight
  you cannot de-couple the user interface from the code, you have designed
  it very weakly to begin with.  However, designing protocols must be rocket
  science or something since so few people seem to get them right.  In my
  view, however, a user interface /is/ a protocol whether it uses a sequence
  of characters or a sequence of events.  The so-called event loop in these
  newfangled user interfaces is no harder to program and design for than
  intelligently designed command loops.  Of course, Windows victims never
  quite grasp what a command-line user interface /could be/ because of the
  braindamaged command-line they are used to from MS-DOS.

  Users want menus of options, some say.  Well, that is not as incompatible
  with command-line interfaces as some believe.  Interactive help functions
  and even predictive help functions have been implemented successfully, but
  as the mouse crowd has taken over completely, many command-line interfaces
  do little more than allow the barest input line editing because designers
  think in terms of window-system events and not in terms of user actions.

  And, of course, there is the throwback to mainframe-style forms input that
  is not even as powerful as the forms processing languages of the past, on
  the so-called "web", where even the state information of the past is not
  actually available to the programmers although it may be faked.  All in
  all, the main reason so many users want only one particular user interface
  style is that the one they had to learn is so goddamn braindamaged and
  hard to learn that they fear every user interface must be equally rotten
  and random and so prefer a consistently rotten user interface to a smart
  user interface that is not rotten.  It is one of those ways that Microsoft
  /really/ locks their users into their system: Give them something they
  market as "user-friendly" which it most certainly is not, and pretend that
  everything else even worse.  By usurping the term "user-friendly" to mean
  their particular way of doing things, they effectively destroy all hope of
  creating actually user-friendly user interfaces.  Since the Linux crowd
  is also lacking in insight and have been overexposed to the Windows ways,
  nothing good will come out of that camp this decade, either.

  It is hard to be a user these days.

--
Erik Naggum, Oslo, Norway

Speaking of which, if you have a Lisp app server and you
want to generate a graphic (e.g., a plot) to be seen
on a browser as well be printable by the browser user,
is there an approach that satisfies all of the following:

- "high quality" screen as well as printed version (e.g.,
  PostScript or PDF quality and expressive power for the
  printed version)

- screen version shown "directly" on web page
  like an image*, instead of having to have Acrobat Reader
  plugin get loaded and display on a separate, new page

- does not require separate code to generate the screen
  and printed versions

CAPI from LispWorks provides an excellent GUI interface that spans
PC Windows and X Windows.

Common Windows on Allegro is also an excellent native GUI.

I've heard that Corman CL has tight integration with native GUI, but I
don't know the details.

Macintosh Common Lisp is well-reknowned for its tight integration with the
Mac toolbuilding set.

CLIM (available for the Mac, for Allegro, and for LispWorks) provides
very innovative approach to windowing.

I've heard that there's a Garnet toolkit that offers a good windowing
interface on one or more Lisp platforms, but I don't know the details.

First of all, GUIs exist.  Maybe you mean you want a common interface that
is community accepted, and that might not be terrible.  But even so, it
would take more than that to "make Lisp popular".

I daresay that there are few actual applications that are worth doing
commercially which are being held back for lack of a good GUI
capability.  If you want to make Lisp popular, concentrate on coming
up with a practical business need.  If you have a proper business story
and a good product, the interface is going to be a mere detail.

I think you aren't focused on the right things.

I'm not denying there is public resistence to Lisp.  I'm just saying
that the answers are not so simplistic as "if only there were an xxx"
for various "xxx" tools, because implementations have come up with these
tools and Lisp has not, as a consequence, rocketed to success.

The problem of Lisp's acceptance is a long-standing political one.
People often cite superficial objections in various places where they
want to keep Lisp out, but if you overcome those objections you often
find other objections behind them because the real objections are often
emotional, not technical.

What will get people interested in Lisp is evidence of business success.
There is a lot of good mechanism available for building such successes.
The concentration on "technology" and not on "business" is what is holding
things back, IMO.  Crank out those killer apps, and people will come.
Don't, and no one will care.

more scary would be if people were actually able to force everyone to use
such "asps", in which case not only do they control your system software,
but your whole user experience.
what if you want to be a creative user? what if you want to do something
they didn't have planned allready for you? ok then, you're sol.

a grid computer does not have so much of the cost that your experience is
controlled by a single party, but offers many of the advantages talked
about otherwise.
personally I would want to keep some of my data close, in a location
controlled by me, and other data out in the open, and yet other data
available to whoever is interested.

for now I am not developing a fully distributed system, first I aim to
build a concurrent system and build a distributed system on that.
my system will not have servers or controlling parties, only a mass of
nodes which swap data based partly on locatity and partly on the
interconnections of the data.

I had before thought out some of the protocol details, but it seems I never
implement things exactly as planned before. I almost have a concurrent
system, and it is allready persistent, I will use this as a base for
distribution. it will maintain loose synchronization, where synchronization
is kept more tight in some places (between nodes actively working on data),
but becomes looser as less activity is occuring on it.
data has temporary owners, and these owners are used for synchronizing
control. before was the definition of the control facilities, and how to
handle loss of reachability and similar.
it would be up to the creator to offer some info relating to control of the
information, and the plan is that this info will have an effect on the
protocol (some data may become read only once the owner goes down, other
data will just change owners, ...).

conceptually data will be live, rounding up nodes to do its bidding. ways
will be needed of controlling such data (sanity checks as it were, to limit
some data from gaining too many resources which were not offered
originally, or from endlessly replicating itself to gain control).

nevermind, thoughts are not very clear. I just don't like the idea of
web-apps becomming dominant (I use hotmail, and in many ways it pails
compared to a real email client, though the email clients I use can't
really use hotmail...).

anyone watch "max headroom"?...
compare with "serial experiments lain" or "chobits"...
different worlds as it were.

nevermind.

anyways, I am not one for trying to find "the next big thing"...

That's another reason to hate GUI work.

I think there is some general concensus that Apple knows a thing or two
about designing and implementing GUIs.  They have now for more than a
decade been pushing hard to get programmers to separate the application
from the user interface, using the mechanism of "AppleEvents" to do
this.  AppleEvents provides some standard data types and verbs, plus it
is extensible by individual programs.  If a program uses AppleEvents to
communicate between the UI and the engine then it is automatically
scriptable (using AppleScript or any other OSA-compatable language, such
as UserTalk (the language in Frontier)) AND recordable, such that user
GUI actions can be recorded at a high level of abstraction (*not* as
move the mouse here, click there etc) in human-readable form into a
script that can be replayed or modified.  Support for AppleEvents is
built right into application frameworks such as MacApp (Apple), the
Think Class Library (Symantec), PowerPlant (Metrowerks) and Cocoa
(NeXT/Apple).

There is also flash.  Vector graphics, animation, but also a programming
language, forms, URLs etc etc.  There are quite usable web sites done
*entirely* in flash, such as the one belonging to the Hell Pizza stores
here in Wellington <http://www.hell.co.nz>.

A web/browser interface doesn't necessarily mean HTML.

  I find this line of argument extremely puzzling.

| It's easy to say, "Once I've got the application working, with all the
| proper hooks in it, I can just add the interface and everything will work
| out fine."

  Perhaps you are unaware of how "the interface" can be expressed in a
  multitude of ways?

  A good programmer will naturally design the user interface as part of the
  application (how could it be otherwise?), but in such a way that it the
  communication between the application and the user interface is through a
  well-defined protocol instead of randomized event processing.

| In such cases, things usually turn out badly.

  I think you should reveal your inductive basis: What, precisely, have you
  observed that led you to this very strange conclusion?

| For interactive systems, figuring out where to separate interface
| functionality from application functionality can be very tricky.  It
| requires a lot of thinking about both sides to do it right.

  But it becomes a lot easier if you formulate the interface/interaction as
  a protocol.  Those who think in terms of the graphic interaction when
  they should have been thinking about the information flow tend to get
  /everything/ wrong.

| (For example, in my application program logic it might result in the
| cleanest design if I get values X, Y, and Z from the user in that order,
| but a strict ordering may not be ideal in the interface.  I should be
| careful not to allow unnecessary constraints to propagate from
| application to interface, unless I've checked out how it will affect
| things in the interface.)

  But this is so stunningly irrelevant!

| Of course, for good programmers who are aware of human- computer
| interaction issues, this is not a problem, but not everyone is a good
| programmer.

  I am puzzled as to what you think this discussion is about.

  A simple control question is perhaps in order: Do you think that it is
  impossible to find /any/ boundary between code that communicates with the
  user and code that communicates with other code?  Or, phrased differently,
  do you think it is impossible to find /any/ boundary between code whose
  main if not only function is to produce information for user consumption
  and code whose main if not only function is to produce values for other
  code?

--
Erik Naggum, Oslo, Norway

It's not clear that calling Java "shitty" is really fair.
But its strengths are, um, quite different from Lisp's, so
it's not surprising that someone who likes Lisp a lot sees
Java as rather nasty.

but java has static typing, does not have macros or multiple
inheritance, does not have generic functions, and it lacks sexpr
notation. oh yeah, and it is slow, as in not compiled to native code.

btw, most folks here do not think Lisp is perfect, that's just me.

hey, you tell us what you think as you get into it, yer asking the choir
about the sermon.

:)

--

SomeLongName variable = new SomeLongName (...);

And the:

item = (SomeLongName)vector.get(i);

casting required everywhere.  There are probably other examples too, but
the problem with these is that they require the name of the data type to
be hard-coded in many locations, which makes it very hard to change.

Java in general lacks helpful abstraction facilities such as macros and
higher-order functions, and forces you to write everything in terms of
its own peculiar brand of OOP.

Thus it doesn't surprise me that Lispers might denigrate Java ;-)

Nope!  The above questions (true or not) don't matter at all, because
they are almost *never* asked--that's why I hate it.  Java is pushed
and advocated because Sun throws an enormous amount of money at it.
They hand out leather jackets with the "Java" logo on them.  They
bring it up at tasty, expensive, lunches.  After hearing a tale of woo
about a project that uses a different language, they say that if it
was Java they would be willing to loan developers for free if such a
bind ever happened again.  They organize tasty, expensive lunches
around Java education and bring in whomever they can, even the people
who aren't qualified *at all* to choose a language--just to increase
the internal pressure to use Java.  They make it seem like such an
enormously important technology that if we don't use it and acquire
Java skills, our careers will go absolutely nowhere. I could go on and
on...

I hate Java passionately, though not primarily for technical reasons
(though are plenty of technical reasons to dislike it).  In a social
sense, Java is a polar opposite of Lisp--it's language that seems to
have been invented as a corporate controlled Sun-benefitting populist
tool that everyone should use (preferably on a box with multiple Sparc
CPU's).  Lisp is a language that was evolved by smart programmers into
a powerful tool that smart programmers can exploit to develop powerful
software (and even have fun at the same time).

I'm not trying to flame Java programmers or put Lisp programmers on a
pedestal.  Smart programmers have written good software with both
languages.  Nor am I saying that the previous paragraph is 100% pure
truth--I'm sure my views on Java are jaundiced by my professional
situation.  Just interpret them as the thoughts of an idealist
who's seen Sun marketing at work...

Are there any Common Lisp libraries to help construct such
interfaces?  Are we talking about things like
command completion/history/editing/help, optional
and keyword arguments?  Could or should it be done through
an emacs inferior-something buffer?

  Why do you assume all this?  And more importantly, /how/ did you arrive
  at all these assumptions?

  I need some evidence that you understand what a protocol is before I want
  to explain the principles here further.

  E.g., are you knowledgeable of how the Emacs command loop works?

--
Erik Naggum, Oslo, Norway