On Wed, 2002-12-11 at 00:41, Ron Johnson wrote: > Being an old fogey myself (no matter how many "daily snapshots" of the > code, and how many 10s of thousands of test records I kept in data > files, I just couldn't come near filling up a 40MB HDD), I *totally* > understand your point. However... > > Just today, I received 3 512MB SDRAMS for the grand sum of US$94. > That's 24,576x more RAM that was in my KayPro2, and 2,458x as much > RAM as in my first PC/AT. > Likewise, the 120GB drives that go for US$125 is 154,194x as much > capacity as the 2 380KB (yes, 380KB, not 360KB) in said KayPro2. > > In 1992, I bought a 250MB HDD, which is 1/480th the size of the > 120GB HDD. (It's 1/1280th the size of the new 320GB Maxtors...) > > So..... So what if programs are biggers now than they were back then? > They do a *heck* of a lot more!!!! I guess I over-editted my thoughts there. The point I was seeking to make was that we get programs the size necessary to handle what we seek of them to do. I regularly tell people how much greater the capabilities of a machine is compared to some of the early boxes I worked with, and how I paid extraordinary amounts given today's prices for barely nominal devices by today's standards. The stuff I did on a TRS-80 Model 1 with 4K of RAM, of which 1K was reserved for the screen! Sometimes today coding or choice of tools results in overly repetitious functions or functionality that introduces chrome of interest primarily to the coder, but as a rule, the growth in program (and supporting data and documentation) is at worst proportional to the growth in functionality, and very often the effective functionality is increasing faster if the programmer is focussing on the productive effects of the system. ISTR a strange design decision in very early Lotus 1-2-3, according to info passed on to me: in the days of 180 KB floppies, Lotus would save data files in blocks of 64KiB, no matter how little the actual spreadsheet was. That was modified quickly, although the memory on most systems then meant that people rarely would have a spreadsheet too large to fit on a floppy. > > No! I am NOT defending/condoning poor programmers and poor programming! > You being an ex-VAX programmer will understand that VMS 7.3 has a lot > more capabilities/functionality than VMS 1.0, and thus STARLET.OLB is > bigger now than it was 25 years ago. And more genericly, compiler > writers now optimize more for speed rather than code size. IMHO, it's > a valid trade-off. > > Of couse, now that programmers don't have the pressing need to write > really tight code, they've forgotten how. Many under 35 years of > age (unless they were C64 assembler geeks) have never learned how. > And object orientation hasn't helped one bit... I would suggest that it is not only a question of writing tight code for size, but that there is so much in the way of libraries and the like that programmers re-invent because they don't realise it is already there. It isn't intentional, but it does happen. > > > On Tue, 2002-12-10 at 22:18, Mark L. Kahnt wrote: > > I was digging through some old papers and found this from nearly a > > decade ago: > > > > (Dec. 21) > > I'm getting tired of lazy, slovenly, good-for-nothing programmers > > wasting my hard-earned hard disk space with their frivolous code. > > My first PC hard disk had a 10MB capacity. These days, I can think of > > individual applications that consume more space. > > It has to stop. Stop the insanity! It's getting to the point where I'm > > being forced to swap hard disks as often as I change my socks -- about > > once a year. Programmers and their corporate sponsors have to be taught > > to become thrifty with *our* hard disk space by writing compact > > programs. > > Here's my plan. For every megabyte of hard disk space a software > > product consumes, the publisher must rebate the customer $10. So if a > > program takes up 1MB we get $10 back. For 2MB we get $20 back and so on > > and so on. Buy Windows and you could get enough back for the down > > payment on a small ranch home in Levittown. > > Let me tell you friends, with such a plan in force we'll see smaller > > and more efficient programs hit the market in a hurry. It'll be like the > > good old days when programs came on single floppy disks or, better yet, > > audio cassettes. > > What I'm a little hazy on at the moment is how to enforce this policy. > > Maybe I'll send a few of my Brooklyn buddies to the executive suites of > > some major software publishers with a subtle message, like a fish > > wrapped in a newspaper, or a horse's head or a photograph of Pat > > Robertson. > > And how will you spend your rebate? Oh, have fun! Paint the town red, > > courtesy of... > > --John Edwards > > > > ====================================================================== > > Mark again -- > > > > The first hard drive I worked with on a desktop was 5 MiB, connected to > > a VAX 11/750 with a 100 MiB hard drive in the system room, back when > > they were the size of dishwashers. Then I lucked out and got a machine > > with 20 MiB on the desktop (powered by a PDP/11 processor.) 16 people > > worked on that VAX, developing compilers (4) and interpreters (5) for a > > number of different platforms (5), with multiple versions of the source > > code on the system in the days before RCS and CVS. I worked at squeezing > > the Pascal compiler onto one 180 KiB floppy (that's how big they were > > back then, before the second side of the disk also became available. > > > > I also remember that to do pretty well anything, you needed to program > > it - User Friendly meant that error messages were included, rather than > > just going off wildly and trashing the entire system ;) There is > > justification for larger code than we used to use because programs are > > doing vastly more than I did in the early 1980s when writing > > interpreters and compilers at Watcom. Graphics were only just being > > introduced to computers, and code was 8 or 16 bit on most platforms > > (except for the 32-bit VAX and the 36-bit IBM) and back then, we could > > save all sorts of memory by only saving the last two digits of the year > > ;) > > > > I look on program bloat as something comparable to governments and > > taxes: the more services you want provided, the more taxes or disk space > > (depending on the metaphor) are needed to do it. That said, those $600 > > hammers, $1000 pens and $1600 toilet seats probably could be optimised > > out of some code (closest parallel to the toilet seat is the Microsoft > > paper sodding clip.) Because we want our software to do so much, we must > > commit the resources to do that task, on the trust that programmers are > > going to respect the finite resources (the same way we want our > > governments to respect our finite wallets.) > -- > +---------------------------------------------------------------+ > | Ron Johnson, Jr. mailto:ron.l.johnson@cox.net | > | Jefferson, LA USA http://members.cox.net/ron.l.johnson | > | | > | "My advice to you is to get married: If you find a good wife, | > | you will be happy; if not, you will become a philosopher." | > | Socrates | > +---------------------------------------------------------------+ > > > -- > To UNSUBSCRIBE, email to debian-user-request@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > > -- Mark L. Kahnt, FLMI/M, ALHC, HIA, AIAA, ACS, MHP ML Kahnt New Markets Consulting Tel: (613) 531-8684 / (613) 539-0935 Email: kahnt@hosehead.dyndns.org
Attachment:
signature.asc
Description: This is a digitally signed message part