Testing the waters.

[Rainer Joswig]

At 9:48 Uhr +1000 9.5.1997, Chris Bitmead uid(x22068) wrote:

>You won't get portability from LispOS to other versions of CL in any
>case, because you won't have the POS ported to the other version of
>CL. And POSes are always very tightly integrated with the virtual
>machine and garbage collector, and application code.


If you don't define interfaces that will make your code
portable (as portable as you can), then you're doing something
wrong. I want Lisp code to be as portable as possible.


********************** MAXIMIZE PORTABILITY **************************


Define the system rigorously in layers and modules.
This is extremely important. Don't make the mistake
not doing this - your code will get unmaintainable, unevolvable,
big, complicated ... simply a mess.
Sometimes you will need to replace subsystems -
make it as easy as possible.


>You may get your existing CL lisp programs working on LispOS, but they
>won't do things the LispOS way, so they fall into the general category
>of how to get legacy applications working on LispOS.


I don't agree a bit with this posting.


If I have CL+TCP -> I get instantly CLX -> then I can start using
a lot of Lisp code. Files don't matter here a bit.

If I have CL+Threads+TCP -> I can get instantly CL-HTTP -> then
I can start using a lot of Lisp code. Files don't matter
here a bit.

I don't see at all why Franz's own web server (where can I get it?)
should be better than CL-HTTP.
If we can get a hand on it we can judge whether it is good.
Right now CL-HTTP is freely available (minus giving improvements
back to the developers - which is a good thing).
If you don't like something -> hack it up.
Which by the way also uses persistent object stores.

CL-HTTP on the Lisp Machine:
  White House installation uses Statice
  Statice is a OODB for Genera and Lucid CL
  The user/group substrate has an API which makes uses of Statice
  when available. Information about the documents are stored
  in Statice.

CL-HTTP on the Mac:
  Infostop from Digitool uses WOOD.

If you have an object store which makes all code *unportable*,
then this is a *really* bad thing. The tragic of Lisp was/is
unportable application code.

If the project leads to a common defsystem, a common definition
for threads, a common definition for a TCP/IP interface,
a graphics substrate, a persistent object store, a 3d API,
... - this should all be supported on the other Lisps that
would be a possible target.

If you are going to start a project where you even can't use
vanilla CLOS application code - good luck.


My tip is just: Use abstraction to get away from particular 
underlying layers. Make as few assumptions about how some
services works as possible.


Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041
Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202,
Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/