Testing the waters.

[Adam Alpern]

;; >I sure hope you don't apply that reasoning to your own applications -
;; >ever heard of modular design? 

;; A can only assume you have never used an object database.

Not a C++ one, no, but I've used WOOD, a persistent heap of MCL for
quite a while now. Before using WOOD I had written object-walking code
that dumped readable forms to a text file, or a byte-streamed
representation to a binary file. When I switched to wood I just turned
off all my custom-written routines, but the application-level code
never changed one line because the persistence was encapsulated. YMMV.

;; >You don't need a degree in software
;; >engineering to separate out platform-dependent code from
;; >platform-independent code. 

;; What if every piece of Lisp code in the entire system continues to
;; work if you either..
;; - Pass it a pointer to memory
;; - Pass it a pointer to an object not in memory, but instead is in the POS.

An object is an object - if you propose an object store that really is
that transparent, then is completely not an issue - application-level
code doesn't need to know where the object is. When you want to port
the app to, say, MCL, you'll just have to do the saving yourself - I
don't see why you think this will affect the 90% or more of the
application that doesn't know about or care about persistence.

;; How do you separate out the code which works with the POS? You can't,
;; because all code can work with the POS.

Wrong - all code works with objects. It shouldn't care where those
objects are. Yes, the app will be structures slightly differently for
a non-POS system, since you'll have to save explicitly, but that's not
a big deal.

;; >If LispOS is based on CL, application level
;; >code should be VERY portable between LispOS and other CLs. 

;; Not if you assume the existance of a POS, and the "other" CL does not
;; support a POS. (Some CLs do support them BTW, so there is some degree
;; of portability, but it's not in the CL standard I don't think).

Again, you missed my argument. See above.

;; >Only the
;; >levels that interface with the OS will be non-portable.  

;; You are thinking in conventional paradigms. Now you have to learn to
;; think outside the square. It's hard to explain how a POS simplifys
;; everything if you have never used one.

Again, I've used one. It did simplify my life. Show me hard evidence
that your claims will completely revolutionize the way I program
though. This issue is irrelevant to most applications though - they
spend most of their time just doing things with objects, not worrying
about where those objects are.

;; Try sometime making a C++ application work with both Oracle and an
;; ODBMS. Good luck! Many dead carcasses lie on that trail. (Most of them
;; on the Oracle trail BTW).

Been there, done that. Found more carcasses with Q+E though.

;; >I write applications right
;; >now that have one common source base that will compile on Solaris,
;; >HP-UX, AIX, Windows NT, and Linux, and a small set of
;; >platform-dependent code.

;; Good for you. Have you got any that work with ObjectStore, Versant,
;; Oracle, Sybase and flat files? I didn't think so.
                                  ^^^^^^^^^^^^^^^^^

Funny how you can say that without hearing an answer first.

Chris Bitmead:
;; That depends on how you view the legacy bin. The legacy bin has got
;; many useful, essential and interesting things in it. I like the legacy
;; bin. I use the legacy bin. It's still the legacy bin tho'.

And I'd rather get things done that constantly re-write every utility
under the sun. Computers are supposed to be useful, remember?

Anyway, we're not going to agree about all this anytime soon, it seems
- why don't you set about designing your POS and presenting a spec for
consumption and discussion. I'll happily list what my persistence
requirements are and then get about designing cool applications. It
won't fly if it ain't got apps.

Adam