I am a retired main frame Systems Analyst/Programmer who started programming in 1958 at the bit (not byte) level on a 650-RAMAC which was an ancient IBM monsterously slow as molasses tube machine. Thence I gravitated to 1410 assembler, 360 assembler, 1401 asembler, 7080 assembler and finally COBOL. This hositroy consists of about 30% of the languanges in which I programmed --- Robert Lowe <[EMAIL PROTECTED]> wrote:
> This is a simplification of bloat's causes, but it > is something I have > observed during my career as a programmer. > > Bloat is not a function of actual code complexity or > ignorance of > resource usage.it is caused by bad management and > time pressure. In a > lot of modern software projects the mentality is to > "always create" or > "always move forward" This leads to a culture where > code review and > rewrites are deemed to be bad because it does not > look or feel > productive. > > So, what you end up with is a culter that assumes > everything is an > error of omission. That is, if something breaks, > you write more code > to fix it. You never fix the underlying problem, > you only keep adding > to it to fix the problem by hacks and workaround. > This would be sort > of like saying "My car is making a funny noise, can > I add a part to > the engine to make it stop?" > > In terms of algorithmic complexity, even something > like a word > processor doesn't do a lot in that arena. What it > does do is operate > with the operating system. The operating system had > bugs that were > worked around by adding code to it, and so you have > to work around > those problems that creates for your program in > addition to the > problems that you create yourself. So the bloat of > the OS causes you > to bloat your product, which causes your product to > be buggier, which > makes you bloat it more.... > > It's a vicious cycle. It stems from laziness (in > that it is always > easier to add than to analyze code), bad management > (if they aren't > writing new code, I'll fire them), and too much time > pressure (code > faster! the deadline is approaching). > > There are other facets to the problem, with lots of > studies talking > about it. Still, in my own observation the three > things I mention > above are really what causes bloat. Ironic that 2 > of the 3 aren't > even committed by people that write the code. > > -Bob > > > On Wed, 6 Oct 2004 20:11:58 -0400, Byron Q. > Desnoyers Winmill > <[EMAIL PROTECTED]> wrote: > > On Wed, Oct 06, 2004 at 06:37:20PM -0500, Keith > wrote: > > > I would guess that it is economics. As the price > of space and speed go > > > down, and the price of efficiency (coding time) > remains constant or > > > goes up, it's cheaper to put bloatware on bigger > faster machines. > > > > Sorry, I wasn't refering to the > business/programming culture. I'm > > more than aware of the excuses for not optimising > for space or > > speed. I even saw one book which said not to do > it at all, even > > if your program was unbearably slow, because you > are designing for > > the hardware of tomorrow. Or whatever. > > > > More to the point is this: my meager programming > background has > > exposed me to the efficiency of algorithms, with > respect to speed. > > That is to say O(n), O(n^2), etc. stuff. Yet I > rarely hear about > > space efficiency (either code or data). In fact, > I never hear > > about it beyond mention of the memory hierarchy > (registers, cache, > > RAM, disk, and whatever I missed in between). > When you think about > > it, it is kind of strange because memory capacity > has been growing > > at roughly the same rate as processor speeds, or > maybe even more > > slowly. I suppose this is because you rarely > create much more data > > when you iterate something (you may increase the > amount of data by > > n^2, but almost never more). > > > > If all programmers are given the same, limited, > understanding, you > > would think they are (on average) the same > throughout time. Yes, > > programmers of old had to be more conscious of > memory usage (RAM > > and permenant storage). On the other hand, I > would think that that > > would only change memory usage by a small factory. > Maybe a factor > > of 2 or 4. Small, just like optimising code > without considering > > the algorithm would produce small increases in > performance. Yet > > I get the impression that the bloat is on the > order of a factor of > > 10 or 100, even after you strip out the resources > (because improved > > image/sound quality requires more storage). > > > > Byron. -- System6 is sponsored by <http://lowendmac.com/> and... 123Inkjets.com <http://lowendmac.com/ad/123inkjets.html> Support Low End Mac <http://lowendmac.com/lists/support.html> System 6 Heaven <http://www.euronet.nl/users/mvdk/system_6_heaven.html> System6 info: <http://lowendmac.com/lists/system6.html> --> AOL users, remove "mailto:"; Send list messages to: <mailto:[EMAIL PROTECTED]> To unsubscribe, email: <mailto:[EMAIL PROTECTED]> For digest mode, email: <mailto:[EMAIL PROTECTED]> Subscription questions: <mailto:[EMAIL PROTECTED]> Archive: <http://www.mail-archive.com/system6%40mail.maclaunch.com/> Using a Mac? Free email & more at Applelinks! http://www.applelinks.com
