Testing the waters.
Fri, 9 May 1997 09:39:31 +0200
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
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: firstname.lastname@example.org , WWW: http://www.lavielle.com/~joswig/