[slimpl] some comments about vim internals

[Brad Beveridge]

On 3/5/06, Larry Clapp <larry at theclapp.org> wrote:
<SNIP>
> I like what you've done; what follows discusses both your code and my
> thoughts on the general design of the project.
Thanks, I really appreciate you taking the time to look at it.
I agree that the we ought to use packages instead of a naming
convention, I'll start converting the code to that.  I don't tend to
write much (any?) code that needs enforced namespace discipline, so
I'm not that used to immediately using packages.

>   Emacs
>     <-> presentation layer (Elisp)
>       <-> backend interface (Elisp)
>         <-> backend implementation (Elisp/CL)
>           <-> swank (CL)
>
>   Vim
>     <-> presentation layer (Vim+ECL)
>       <-> backend interface (ECL)
>         <-> backend implementation (Elisp/CL)
>           <-> swank (CL)
The above scenario is precisely what I think.  Except I'm not sure
about the backend implementation needing to run on both Elisp and CL -
are we unnecessarily limiting ourselves by using Elisp?  And what do
we really gain?
The way I am tackling the "rewrite" right now is to cut and paste
slime functions and rename to ooze as I go, that way I am forced to
read the code and make sure I think it will sort of work, rather than
having a bit of code that behaves slightly differently in CL than in
its native CL environment.  So far I am changing very very little,
mostly just replacing some small flexible functions with functions
that only return a single value, and marking those functions as "need
more work!".

> The backend would compile in both Elisp and CL.  It would probably
> have three sub-parts: a common part, some CL->Elisp glue that let the
> common part run on Elisp, and some Elisp->CL glue that let the common
> part run on CL.  (Does Elisp have #+ and #-?)
I imagine that right now I am not diverging too far from vanilla
Elisp, so maybe the common part could be written in plain Elisp & just
create some Elisp -> CL glue where needed?

> ... And now I'd like to comment on my comment  :)  with an excerpt
> from http://www.objectmentor.com/publications/dip.pdf:
>
> > The Definition of a "Bad Design"
<SNIP>
I really liked that.  I am totally open to design discussions and
criticisms - although I have been doing software for 5 years now, I've
really only had one project where I actually had any design input (it
was a success though!).  Hacking together piles of existing code to
get it working is different that starting from scratch :)

The problem with OSS projects is that you have a bunch of people
wanting to help, but until someone makes something that kinda works,
it is hard to get everyone moving in the same direction.  I don't know
that I can, or want to be, the guy that gets the skeleton built.  I'm
going to keep tracking ahead with ooze (feel free to take the name if
you like it :), but I frankly don't expect to be the first person to
get code that we can gather around.

So, although I am doing _something_ useful, I want other people to do
more useful stuff :)

Cheers
Brad