[math-fun] software eutrophication [was: math-fun] about pdf readers
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.
"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
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
the classical term is bitrot, no? http://en.wikipedia.org/wiki/Bit_rot even if code is inscribed in eternal stone and executed faithfully by infallible high speed gnomes, bit rot still strikes because someone doesnt quite get gnomian and wraps a "convenience function" or something around the stele ... look on my works, ye mighty, and despair Tippy-tapped on my iPad On Feb 13, 2012, at 6:21 AM, Victor Miller <victorsmiller@gmail.com> wrote:
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
_______________________________________________ math-fun mailing list math-fun@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/math-fun
There's something more akin to the Peter Principle going on here. http://en.wikipedia.org/wiki/Peter_Principle http://en.wikipedia.org/wiki/Software_Peter_principle There's also a corollary to Moore's Law: The number of levels of software emulation increases to make each software release slower than the previous one, even though it is running on faster hardware. (How come the mouse of my PC circa 2010 has more lag than the mouse on the Xerox Alto?) This is why the software emulation of a wristwatch on your iPod Nano requires nearly the entire CPU of the Nano, even though it has perhaps 10,000,000 times as much processing power as the earliest electronic watch. At 06:51 AM 2/13/2012, Thane Plambeck wrote:
the classical term is bitrot, no?
http://en.wikipedia.org/wiki/Bit_rot
even if code is inscribed in eternal stone and executed faithfully by infallible high speed gnomes, bit rot still strikes because someone doesnt quite get gnomian and wraps a "convenience function" or something around the stele ... look on my works, ye mighty, and despair
Tippy-tapped on my iPad
On Feb 13, 2012, at 6:21 AM, Victor Miller <victorsmiller@gmail.com> wrote:
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.
On 2/13/2012 3:39 PM, Henry Baker wrote:
This is why the software emulation of a wristwatch on your iPod Nano requires nearly the entire CPU of the Nano, even though it has perhaps 10,000,000 times as much processing power as the earliest electronic watch.
It's clearly useless if it doesn't have automatic updates with Twitter and Facebook integration developed atop Java emulated in Javascript. Get with the times, man. -Robert
On Monday 13 February 2012 14:21:48 Victor Miller wrote:
Lately I've taken to describing software as "being encrusted with barnacles".
Heard in a dev-team meeting a few years ago: "More barnacles than ship". -- g
So, Bill, have you had any better luck with Macsyma, or some other symbolic software? -- Gene
________________________________ From: Bill Gosper <billgosper@gmail.com> To: math-fun@mailman.xmission.com Sent: Sunday, February 12, 2012 5:01 PM Subject: [math-fun] software eutrophication [was: math-fun] about pdf readers
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.
participants (8)
-
Bill Gosper -
Eugene Salamin -
Fred lunnon -
Gareth McCaughan -
Henry Baker -
Robert Smith -
Thane Plambeck -
Victor Miller