Xref: utzoo comp.sys.ibm.pc:52479 comp.os.minix:11176 comp.unix.xenix:12038 comp.realtime:697 comp.arch:16506 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!uplherc!esunix!bambam!bpendlet From: bpendlet@bambam.UUCP (Bob Pendleton) Newsgroups: comp.sys.ibm.pc,comp.os.minix,comp.unix.xenix,comp.realtime,comp.arch Subject: Re: Bloat costs Message-ID: <1532@bambam.UUCP> Date: 12 Jun 90 23:33:41 GMT References: <2662D045.3F02@tct.uucp> Organization: Evans & Sutherland Computer Corp., Salt Lake City, Utah Lines: 61 From article <2662D045.3F02@tct.uucp>, by chip@tct.uucp (Chip Salzenberg): > Substitute "four megabytes of RAM" for "COBOL", however, > and you get a depressingly accurate summary of the attitude > of the day. Am I implying that that 4M-or-die programmers > are trogolodytes as well? You bet your data space I am. > -- > Chip Salzenberg at ComDev/TCT , A long time ago (about 10 years), at a company that has since changed its name several times, I and 3 other damn good programmers spent a year or so writing the runtime support libraries for a COBOL system that generated code for an 8080 based "terminal" called the UTS400. The compiler ran on a number of different machines and generated code that ran on the '400. You linked the code with our runtime code and you got an application you could down load to an eight inch floppy and then boot on the '400. Our library did all the weird arithmetic and data formatting that COBOL needs. It also implemented a disk file system, host communications, screen formatting, data entry validation, multithreading (yes it was a multiuser system, up to 4 users if I remember correctly), and segment swapping. It fit in 10K bytes. Normal '400s had 24K, some had 32K. I know that at least one 20K lines COBOL program ran on the machine all day, every day. Marketing decided we should also support indexed sequential files. They "gave" us 1K to implement it. That is, the code for the indexed sequential file system could not increase the size of the library by more than 1K bytes. We wrote the indexed sequential files module in 2K and rewrote the rest of the system to fit in 9K. So when people tell me they have done incredible things in tiny memories on absurd machines I beleive them. I've even been know to buy them a drink. Yes, it can be done. But for most things it is an absurd waste of time. I can write code 5 to 10 times faster when I DON'T have to worry about every byte I spend than when I'm memory tight. And I can write code that RUNS several times faster when I'm free with memory than when I have to count every byte. Some times you must run a ton of program on a pound of computer. Many, if not most, commercial programs in the MS-DOS world fall into that realm. But, most programming done in the name of "memory efficiency" is just wasted time. You have to sell a lot of copies to make back the cost of all that code tightening. Not to mention what it does to the cost of further development. Bob P. P.S. I also learned an important lesson on the power of structured design and prototyping form this project. But, that's another story. -- Bob Pendleton, speaking only for myself. UUCP Address: decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet X: Tools, not rules.