[implementations-list] Transferring maintainership of Vimpulse (was: Re: viper-in-more-modes)

Thu Jan 29 02:50:28 CET 2009

On Wed, Jan 28, 2009 at 6:14 PM, Stephen Bach <sjbach at sjbach.com> wrote:
...
> I agree there are problems with viper, but I'm not positive replacing it
> wholesale is the best approach.  In my experience, the more ambitious
> the project, the less likely it is to reach any milestone of usefulness.
> Viper is 13000+ lines of seasoned code, and it mostly works in its goal
> of pure-vi emulation.

I agree.  It would be very hard to rewrite Viper from scratch.  As
popular blogger Joel Spolsky wrote:

     "The idea that new code is better than old is patently absurd.
Old code has been used. It has been tested. Lots of bugs have been
found, and they've been fixed. ... [Architectural] problems can be
solved, one at a time, by carefully moving code, refactoring, changing
interfaces. Even fairly major architectural changes can be done
without throwing away the code. On the Juno project we spent several
months rearchitecting at one point: just moving things around,
cleaning them up, creating base classes that made sense, and creating
sharp interfaces between the modules. But we did it carefully, with
our existing code base, and we didn't introduce new bugs or throw away
working code."[1]

The books "Working with Legacy Code" by Michael Feathers and
"Refactoring" by Martin Fowler, and the SourceMaking website[2], talk
about how to refactor.  The free PDF ebook "Object-Oriented
Reengineering Patterns"[3] also talks about dealing with old code,
though I think "Working with Legacy Code" is better.

...
> - You seem to know what you're doing, so good luck.  I'll follow your
>  work, and when vimp / vimpersonator is ready, I'll try it. :-)

Yes; if you go ahead and write it, then when it's ready, I too will
try it.  Good luck.

-Jason

^  [1].  http://www.joelonsoftware.com/articles/fog0000000069.html

^  [2].  http://sourcemaking.com/refactoring

^  [3].  http://www.iam.unibe.ch/~scg/OORP/