Sat, 3 May 1997 16:54:30 -0700
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 services that provide APIs to core applications features. The goal is
to maximize the productivity "lift" that a LispOS application server can
provide to the prospective users.
Take Quicken as an example. Rather than just writing a Lispy version of
Quicken, why not provide an abstract accounting services API? 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 accounting services API.
This moves the task of solutions-developers up a level of abstraction. Instead
of implementing accounting grunt-work abstractions, they get to concentrate of
extending the basic API with specialized behaviors for their application. This
creates a much bigger productivity lift for the platform than a good Lispy IDE
alone can deliver (IMO).
This approach could benefit a number of domains. We can identify a reasonable
set of them and implement application services APIs 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>
The views expressed are mine alone,
unless you agree with me.