Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
From: Erik Naggum <erik@naggum.no>
Date: 1999/07/25
Newsgroups: comp.lang.lisp
Message-ID: <3141913498252914@naggum.no>

* joswig@lavielle.com (Rainer Joswig)
| Let's cite the abstract from a paper (CACM Vol.34, No. 9 (Sept. 1991),
| pp. 58-59 ) presented by Scott McKay:
| 
|   McKay presents CLIM, the Common LISP Interface Manager.  Using CLIM,
|   programmers describe the user interface of an application in a
|   high-level language independent of any particular window substrate. The
|   programmers indicate their intent, and CLIM hides the details of how
|   the tasks are performed. CLIM provides a number of basic facilities,
|   including geometric modeling, affine transformations, text with
|   multiple fonts, and graphics.  It has a presentation facility that
|   remembers not only the output to a stream, but also the underlying
|   application object it represents and the presentation type associated
|   with the output. It also has facilities for input, with a translator
|   that coerces objects of one presentation type into objects of another
|   type. Thus, since the objects and commands used in the interface are
|   built on objects and operations in the application, the user interface
|   becomes a by-product of the application rather than an artifact of
|   graphic design.

  you're missing the point, Rainer.  at issue is not the coupling to the
  actual user interface code, like X windows or whatever.  at issue is how
  much the application code needs to be prepared to produce a by-product.

  it appears to me that your anger at critics of CLIM is misplaced because
  you don't understand what they are criticizing and they think they
  criticize something that isn't wrong with CLIM.  maybe this is because
  you don't see problem other people see and think CLIM has solved a
  serious problem that other people don't see.  I don't know.  but I have
  tried to get you, as an too ardent defender of CLIM, to answer some of my
  questions and issues, which, in particular, are to which degree CLIM
  offers means of abstraction that would be useful even without CLIM in the
  system.  again, it appears to me, from what _you_ say, that it doesn't,
  meaning that CLIM is good provided that you accept a non-trivial amount
  of design methodology that doesn't work too well without CLIM support.

  could you calm down and try to answer such questions?

  I'll make a parallel: we all know that CORBA solves a whole bunch of
  problems in distributed processing, but if that means we have to buy into
  the CORBA philosophy first, it may not be possible to use CORBA if the
  philosophy doesn't fit the application model.  in my view, CORBA is good
  _only_ if you accept that philosophy, and sucks if you don't.  to those
  who don't recognize that there _is_ a "CORBA philosophy", this would be
  an attack on CORBA in areas where it does work and is valuable, because
  they automatically express every problem in terms of the philosphy.

#:Erik
-- 
  suppose we blasted all politicians into space.
  would the SETI project find even one of them?