[PRL] Code's Worst Enemy
Joe Marshall
jmarshall at alum.mit.edu
Wed Jan 2 13:17:10 EST 2008
On Dec 29, 2007 11:25 AM, William D Clinger <will at ccs.neu.edu> wrote:
> Matthias wrote:
> > And the entire system actually rests on the gluing
> > together of N separate existing libraries (lib scheme,
> > wx:windows, and a slew of others initially and over
> > the years more joined).
>
> Mitch wrote:
> > So, what can we do about this? If this is a (the?) Big Problem, shouldn't
> > we be working on it?
>
> Yes.
>
> Matthias wrote:
> > I consider it a real problem but not a 'grand challenge' type
> > question.
I think it might be one in disguise. (Well, maybe not `grand', but
certainly `worthy of funding'.)
> Riccardo wrote:
>> But the message I got was that any project that starts
>> small and grows over the course of ten years to hundreds
>> of thousand lines of code will almost inevitably be a
>> mess, irrespectively of the language.
You say `almost inevitably'. Are there counter-examples?
Although there are a lot of opinions on why code bloat happens,
is there *evidence* to show what is going on?
Matthias suggests:
>with very few exceptions,
>re-factoring is not something you can publish about and
>yet it requires a huge effort. We can't just afford it
>all.
This suggests that it is simply a problem of economics:
incremental simplification has less immediate value than
incremental complexification. It sounds plausible, but is
it testable? A solution seems obvious: increase the value
of simplification and/or decrease the value of complexification.
Has no one ever done this? (Is it not doable?)
Are there even metrics for these quantities?
I think the problem might be far more interesting and difficult
than it first appears.
Just my opinion.
--
~jrm
More information about the PRL
mailing list