[lug] Re: recycling code [WAS Fwd: NICHOLAS PETRELEY: "The Open Source" ]

[rm at mamma.varadinet.de]

On Thu, Mar 22, 2001 at 12:25:46PM -0700, Matt Clauson wrote:
> All of these are valid points.  However, making something more modular, or 
> converting it from OOP to procedural, does not necessarily mean that you have 
> to rewrite the damn thing from scratch.  Yes, some items will have to be 
> rewritten.  That's an acceptable casualty.  But it doesn't mean having to 
> rewrite from the ground up now, does it?  Splitting a class up into several 
> procedures, as well as the data...  Ah, hell, I forget the term now... (kids: 
>  don't use Perl too the exception of C -- it rots your brain)  ah, yes, 
> structures.  Anyway, splitting up the class into its components doesn't 
> necessarily mean than you have to rewrite supermassive amounts of code from 
> the ground up.  Some rewriting is needed, yes....  But do we have to rewrite 
> Pine from scratch to make PIMP?

Two remarks: no, in theory one doesn't have to rewrite from scratch.
BUT: you have to admit that it's much harder to read a lot of 
'foreign' code then to rewrite certain code from scratch. In an
ideal world the existing code would be:

 - well written, meaning written to be understandable 
 - well documented
 - constantly maintained. Let me elaborate this a bit more:
   when code is under constant developement or being fixed
   every once in a while, it tends to be more uniform, consistent
   and easier to understand. Unfortunately _many_ OS projects don't
   fall into this category. Often someone picks up (almost) dead
   code because of a personal 'itch', spends an incredible amount
   of time to understand what's there, fixes his/her itch (often
   breaking other parts because of shallow understanding of the
   software) and leaves it where it is. We just went through a
   project that uses the harvest web gatherer. The harvest project died
   at least three times so far. The latest reanimation labels itself
   'harvest-ng' and "lives" on sourceforge. When we started to use
   the new code we had to realize that the whole engine would crush
   under medium or high load (serveral dozend web sites). Since
   our bot indexes several hundred major servers we had to fix quite
   a bit of code. The patches where send to the maintainer but received 
   only a lukewarm welcome ... basically the software does what the current
   maintainer needs it for, so he is happy and doesn't have time to work 
   on it any more ... Now, we _could_ fork again, create harvest-ng2++, but
   that's against the whole idea. 
   Have you seen the number of zombie projects on sourceforge? 

As harsh as it might sound, often rewriting is much more easy
than code fixup. 

> Rewriting code to avoid bad libraries (either in code, licensing, or some 
> other issue) is also something that can't be avoided sometimes, and falls in 
> the category of 'acceptable casualty'.  Sometimes that happens.  A good 
> example of this would be the entire KDE vs. Gnome debacle.  The QT library 
> had some issues, and still does.  The competition is healthy, and Gnome is 
> making progress.  Nautilus looks pretty damn sweet overall, and I'd probably 
> choose it over kfm fairly rapidly.  But my interests and needs have changed.

I think many OS developers underestimate the time, experience and patience
it takes to develop even a mid-size application. There's a _huge_ step
between a 200 line perl program (that might be a very powerfull application)
and a 2000 line codebase. This isn't just i shift in quantity but also
in quality.

[ ... ]

> The Gnome UI still feels 'kludgy', and has some rendering glitches.  It's 
> still a major "developmer's platform".  This isn't a bad thing, because the 
> people who use it will fix bugs that annoy them. Gnome doesn't feel like it's 
> progressing as fast as KDE did in the same stage.  There's lots of apps still 
> in the 0.x stage in the code...  And Gnome is trying to push v2.0 out the 
> door.  The backend framework is there, but the USABLE apps that 
> [(boss)|(parents)|(kids)|(joe sixpack)] can use JUST ISN'T there.  
> Admittedly, with KDE, the entry barrier that you encounter with Unix 
> (multi-user over single, different concepts, etc) is still there...  But 
> still, I find KDE much easier to use and more friendly, especially when 
> looking at it more from a novice perspective.

I've tro agree here. Sadly, even the backend part leaves one wanting.
Oh, it shure is here, it's just moving so fast nobody sees/uses it.
What's todays component architecture. After a while, if APIs change
long before they ever reach a stable level, developers get reluctant
to go ahead and implement new APIs. L:ooking at my nice collection
of Apple OpenDoc literature i can tell you: i got burned early and
don't want to waste that much time any more ;-)

> You bring up good points about the need to rewrite code, or even the desire 
> to.  However, this is costing Gnome a lot in user share, and the app bloat 
> that Gnome is seeing may eventually cost the project dearly.  Multiple apps 
> are a good thing given the right circumstances...  Scratching an itch or 
> doing something for the 'hack value' is a good thing, given the right 
> circumstances...  But doing to excess  may destroy the goals you REALLY want 
> to achieve, just for the sake of 'being cool'.

Yes, agreed again. Hack value seems to be a very high virtue in
the Gnome comunity. Unfortunately, the end users often have to
suffer. There's a tendency to allways include the latest and coolest
gnome features, even so they are lightyears from stable. Let me 
give an example here: the gnome-db API. A great idea (have a common
API to access all sorts of data providers, similar maybe to Perl's
DBI modules) with some significant drawbacks: not only did the backend
dsepend on Gnomes component architecture (orbit/oaf/monikers) and those
changed often and unpredictable, the software also required a lot of
non-database stuff. I wanted to use it as a general interface between
webservers and database servers--well, compilation required me to
install stuff like gnome-print, gnome-gtkhtml, the X libraries,
gnome-common etc. etc. most of it in early alpha stage. This is not
what i want on my servers. At some time we used to giggle and
make rude comments about MS 'creeping featuritis' ...


  ralf