Imagine a new model for software development; in particular, imagine a
new model for the Lisp community. What would it be like?
I suspect the Lisp community is quite diverse, including professional
software engineers, academics, AI researchers, students, amateurs, etc.
I also suspect that there is a lot of real talent out there going to
waste. Not that producing applications is the only valid focus; it is
not.
But as it stands now, it would be extremely difficult for most Lisp
users to actually develop, maintain and market a complete application,
assuming that they were so inclined. Most simply don't have the time.
The question is, how to utilize the time and talent that is available.
We need to invent a new model, a model that could take advantage of
these wasted resources...
As a first step, what about a dozen or so "foundation applications".
These applications would be designed to support and encourage plug-ins.
Writing and maintaining a modestly sized plug-in would be a do-able
thing for most hackers. It would be an enjoyable thing for most hackers
to develop and maintain a portion, even a small portion, of a commercial
product.
CLOS is the perfect choice for this. Extending CLOS code is a snap, and
with CLIM, the applications could be easily ported. In fact extending
the applications might be entirely too easy, calling for carefully
defined
API's, or perhaps PPI's (plug-in programmer interface). In any case,
we have the right language to do this.
Plug-ins, of course, are not new, but what I have in mind is something a
bit different. The "foundation applications" would be mostly just the
user interface, basic services, and only the most fundamental and
generic operations. The applications would be designed to really
require plug-ins. The foundation applications would have to be modest
enough for one hacker to write and maintain. Perhaps they would be open
source; perhaps they would just publish their PPI's.
There would be a kind of natural selection at work here. Foundation
applications would have to be solid enough to attract plug-in authors.
Plug-ins which offered the same services would be in competition. I,
for one, would like to see competition resolved into collaboration,
perhaps with the ad hoc formation of small "internet design groups".
There is something enormously appealing about a plug-in architecture.
Users only buy the features they actually want and need, and don't have
to pay for the features they don't need. But what is most appealing
from the hacker's point of view is that a well designed plug-in
application might actually be able to compete with the big dogs, whereas
a single hacker is pretty much restricted to the shareware world.
These ideas are all half-baked at this point, but I think there might be
some potential here. What do you think ...
Glen
(I originally posted this article to the MCL mailing list, but I think
it may be of more general interest. Apologies to those who are reading
it twice.)
...
Glen Foy <········@concentric.net> writes:
> As a first step, what about a dozen or so "foundation applications".
The canonical foundation application that is still around is called
"Emacs" ;)
> These applications would be designed to support and encourage plug-ins.
Emacs.
> Writing and maintaining a modestly sized plug-in would be a do-able
> thing for most hackers. It would be an enjoyable thing for most hackers
Emacs.
> to develop and maintain a portion, even a small portion, of a commercial
> product.
Emacs.
> These ideas are all half-baked at this point, but I think there might be
> some potential here. What do you think ...
My suggestion: Get various experienced hackers together (maybe fund
Erik Naggum to work on it) to create an Emacs in CL(OS) with useable
portability packages for GNU FSF Emacs and XEmacs (possibly others).
This would achieve or further a number of (IMHO) worthy goals:
- Solid step towards a new Lisp Development Environment (look Ma, no
(Lisp)OS ;), since a CL extensible Emacs will become a valid stepping
stone for the development of useful integrated Lisp development
tools (plug-ins),
- Rescue Emacs from the claws of GUILE and the flaws of Emacs Lisp,
- Enable even more ambitious "plug-ins" to be written for this CLEmacs,
through Common Lisp's power and the performance advantages of mature
native-code compilation,
- Build a focal point for the Common Lisp community,
- etc.
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre R. Mai wrote:
>
> Glen Foy <········@concentric.net> writes:
>
> > As a first step, what about a dozen or so "foundation applications".
>
> The canonical foundation application that is still around is called
> "Emacs" ;)
I, too, like Emacs and use the MCL version, Fred (Fred Resembles Emacs
Deliberately). Fred is written in CL and the source is available. It's
missing a few bells and whistles, but still having the source is one of
the great strengths of MCL.
Let me give an example of a what a "foundation application" and its
plug-ins might be like ...
A foundation application author might write a bare-bones music notation
program. The application would be a graphical editor for the creation
of musical scores. The author would have to guard against doing too
much; he would have to deliberately leave out obvious and essential
parts of the design in order to attract plug-in developers. The
foundation application would just supply essential services and the most
basic and generic operations.
A plug-in developer might then decide to add MIDI playback capabilities
to the graphical editor. This would be a fairly modest plug-in, but
very useful for certain users. To support this, the foundation
application would have to maintain a semantic representation of the
score paralleling the graphical representation, and offer a well
designed API for the access of that information.
A more ambitious plug-in for the same graphical editor would be an OCR
engine. It would allow the user to scan existing sheet music,
extracting both the semantics and graphics.
The art of foundation application writing, as I see it, would require
both anticipation and restraint. You would need to anticipate obvious
extensions; you would need to make your API flexible enough to
accomodate at least some of the unanticipated, and you would have to
leave out interesting and juicy parts of the design....
Glen wrote:
> I, too, like Emacs and use the MCL version, Fred (Fred Resembles Emacs
> Deliberately). Fred is written in CL and the source is available. It's
> missing a few bells and whistles, but still having the source is one of
> the great strengths of MCL.
This sounds interesting. Where can you get hold of a copy from?
Cheers,
:) will
William Deakin <·····@pindar.com> writes:
> Glen wrote:
>
> > I, too, like Emacs and use the MCL version, Fred (Fred Resembles Emacs
> > Deliberately). Fred is written in CL and the source is available. It's
> > missing a few bells and whistles, but still having the source is one of
> > the great strengths of MCL.
>
> This sounds interesting. Where can you get hold of a copy from?
AFAIK, Fred is part of Digitool's MCL, so (again AFAIK) you'd need to
be a user of MCL to get hold of the source, unless I'm mistaken...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]