LispOS/LispVM Applications

[Bill House]

Please forgive if this is in the list twice. I just got a message saying this
had not been delivered:
---------------------------
I'm putting this into a separate thread, but it's definitely inspired by some
of the Fuchs papers I point to in the same-named message.

First of all, I see agent-oriented applications as being the "killer app" for
Lispy systems -- it's something they ought to be able to do way better than
Java or C++. Personal productivity apps, spreadsheets, Quicken, etc. are all
needed things, but these also are things that non-Lisp systems have in
abundance. The main arguments for LispOS in this case are that "it's a better
development environment" and (hopefully) "it's a more ergonomic and engaging
end-user environment." However, I think that the strengths of Lisp are
leveraged more in the AOP and AI arenas than in traditional apps. I'll be happy
to expand on why, if anyone's interested, but I'll move on for now.

That being said, I agree that the use cases for traditional applications need
to be supported in LispOS. However, I'm not sure that supporting them in
traditional ways is the right approach. What I'm thinking of is providing some
builtin application objects that provide APIs to core application feature sets.
The goal is to maximize the productivity "lift" that a LispOS application
server can provide to the prospective users, while giving solution developers
the most leverage for quickly creating customized systems.

Take Quicken as an example. Rather than just writing a Lispy version of
Quicken, why not provide a set of accounting objects? All accounting systems
deal with the same basic abstractions -- charts of accounts, budgets, ledgers,
journals and transactions. Provide an API to these, along with the source, as
part of the system. 

The advantage of this is that, now, any LispVM or LispOS agent in the field can
connect to a given LispOS server and interact with the standard accounting
services. Yet, solution developers can specialize it as needed. This moves the
task of solutions-developers up a level of abstraction. Instead of implementing
grunt-work abstractions, they get to concentrate of extending the basic objects
with their own specialized behaviors. This could create a much bigger
productivity lift for the platform than a good Lispy IDE alone may deliver
(IMO).

A number of domains could benefit from this approach. We can identify a
reasonable set of them and implement application objects for all. FWIW, I think
I could deal with the accounting one pretty well -- I've certainly created
enough of them on other platforms. <sigh> We could also include some mobile
agent objects, spreadsheet objects, grids and data browsing objects, perhaps
some neural nets, GAs, etc. It could be a kind of C/S and applications
toolkit-in-a-box. My hope is that by creating the major bits of a few
applications domains, we can sort of turn the LispOS dearth-of-applications
negative into a positive. Does this sound crazy?

Bill House
--
http://www.dazsi.com
The views expressed are mine alone,
unless you agree with me.