Lately I've taken to describing software as "being encrusted with barnacles". Their presence makes it almost impossible to get to the core of the matter and fix it. Here's a typical life-cycle -- someone slaps to together something with some approximation of initial functionality. Subsequent workers either see it as a black box, or seek to preserve an interface to the old functionality and encrust it with extra stuff. The cycle repeats and repeats. Victor http://en.wikipedia.org/wiki/Barnacle On Sun, Feb 12, 2012 at 9:20 PM, Fred lunnon <fred.lunnon@gmail.com> wrote:
"Software eutrophication" --- brilliant coinage! More insightful than mere "bloat", it not only depicts accurately what happens to virtually every successful system that has been around for long enough, but also implicitly suggests that this process is not accidental but inevitable.
I doubt if it's a function of project leadership particularly --- though when a system sprouts bucketloads of new "features" with every release, while bugs in the core system remain unaddressed from one version to the next, it's plain that that weak management can be contributary.
When you've watched the same thing happen often enough --- financial crash, dare I mention --- it eventually begins to dawn on you that there must be deep and diffuse reasons why these things are the way they are, and those reasons are not the obvious ones.
Identifiable proximate causes might vary from case to case, but I claim that what is really driving this and similar phenomena is a variation of Ivan Illich's law of counter-productivity. [ http://en.wikipedia.org/wiki/Ivan_Illich ]
WFL
On 2/13/12, Bill Gosper <billgosper@gmail.com> wrote:
RobM>
The reason we lose more performance than Moore's law gives back is because there are so many programmers (undeserving of the title "software engineers") who would rather use some huge, unoptimal software package or library than spending days, weeks or even years learning how to do it efficiently. (Market forces play a role too :-)
Something like this describes Mathematica's misbegotten and hopelessly overloaded Sum facility, which grows slower with each version. It just took 9 minutes to do absolutely nothing with one of those Lambert identities I sent. Trying a trivial simplification like shift or rename the summation index takes many more minutes. Julian, Corey and I wasted most of yesterday trying to work around this, which is pretty much of a showstopper for porting my path invariance stuff to Mma. We tried hiding HoldForms everywhere, inserting undefined functions, faked summation operators,... but nothing was much good for actually manipulating Sums Just now I made a function which, if wrapped around a transformation of a Sum, reduces the time from many minutes to many seconds. But it happens inside the Sum, and doesn't help you extract summand factors which are independent of the index, e.g. Of all the insane things Mma must be trying in those 9 minutes, why not this actually useful one?
Hillclimbing for performance workarounds is made difficult by Sum attempting to ameliorate the delays by caching results. Which ClearSystemCache doesn't clear!
The whole design of Sum appears based on the assumption that the very last thing in the world I want from typing Sum is a sum. I would *much* rather have several screenloads of HypergeometricPFQRegularizeds, or just give up and get $Aborted. Sum even offers 6*22 strategy X method combinations with which to destroy my sum. Unfortunately, the default is Automatic, and there is no Method->None ! (And if there were, it would ruin the typesetting.)
This too is neither math nor fun. --rwg Perhaps the problem is ossified project leadership. _______________________________________________ math-fun mailing list math-fun@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun