Re: Bug#139945: ITP: prokyon3 -- a multithreaded MP3 manager and tag editor for Linux.
On Thu, Mar 28, 2002 at 09:49:43PM +0100, Marcus Brinkmann wrote:
> where standardization is little and diversity high. And in general, I have
> never seen a case where "write once, throw away, write again" is a good
> programming paradigm.
It's iterative development in the flesh. First, I think you overstate by
saying "throw away." Even when code is rewritten there is a learning
process involved and a set of basic techniques and constraints that can
be carried from prior revisions. The sad truth is that new requirements
come up and this often requires rewriting. It's not an easy thing to
come up with a framework that's general enough to deal with the unknown
and still has good performance. E.g., one set of driver updates in the
linux kernel was for pci hot plugging. When the kernel was first written
that hardware just didn't exist, so it would be hard to make a good
design for it. That sort of thing is going to come up, and that sort of
driver change is inevitable. Another example of change is the zero-copy
patches. Those are sometimes intrusive (not at all portable outside a
particular kernel), but absolutely critical for performance. The hurd
guys aren't worrying about that just yet, are they? And sometimes
there's just more than one way to do something and the only way to see
how it's going to work and fit together with other pieces and be
maintainable, stable, and fast over the long term is to try it. The
willingness of the linux kernel developers to try new ideas and dump
them if they don't work is a source of strength in their development
model. I think it's pure arrogance if not stupendous self delusion for
the hurd developers to poo-poo that model (calling it a "fairly bad
kernel" and "a bad joke") when their model frankly has so little to show
for itself--we've heard a lot of "when our grand design is finally
finished..." from the hurd folks over the years. I'll be damned if I
want to see someone criticizing a working project in favor of one that
can't meet the requirements the first project already fulfills.
--
Mike Stone
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: