CLIM mail archive
The cost of CLIM and its future
At such time as CLIM is available in a portable form on Franz, Lucid, MCL,
Allegro/PC, CLOE, --->>> AND CMU-CL <<<--- , my management will switch to it
What I want to know is, why does your management expect far more of Lisp
plus CLIM than it does of any C plus whatever-the-prevailing-UI-system-is-
for-one-platform? Why is CLIM expected, right now, to be 100% portable to
every Lisp implementation and every platform in the known universe, when
UI tools for C are not really portable at all?
Scott asks a good question. One he has asked before, and that all of
us playing with CLIM as a user interface face must address. The
question has validity! From whence comes this expectation of a Lisp
interface where no such expectation exists for any other language?
My answer, for what its worth...
I have convinced management that my choice of Lisp for our tools is a
sound technical choice. We examine other languages such as C++ with
(it is hoped) an objective analysis of just how those tools fullfil
our needs. One aspect of this choice is portability. While we could do
(with some difficulty) all the things done by our Lisp tools in e.g.
C++, It would add a lot to the effort to make a C++ version as
portable as our Lisp version. Management has found that (amongst other
charming features) the portability of Lisp is higher than other
implementation choices. This portability is a large factor in their
As there is currently no CLIM available for all our platforms (dare I
mention MCL??) management has available exactly what thay would have
in a C++ environment: interface anarchy. They are comfortable with the
simplistic Lispview interface on the Sun because it is there. They are
comfortable with the simplistic Mac Toolbox interface on the MCL
version of the model because it is there. However, a portable
interface for Lisp is a natural expectation because they have found
Lisp itself to be very portable. The extra difficulty of C++
portability means that management has no such expectation for a C++
interface. The problem is not with CLIM's current lack of portable
implementations, but rather with the existance of a large number of
highly portable Lisp implementations underneath.
Main Index |