4 ms·
Byte magazine had a cover feature 23 years ago entitled "Fighting Fatware". We're doomed to repeat history... https://archive.org/details/BYTE-1993-04 https:/
by timthorn 11y ago
Byte magazine had a cover feature 23 years ago entitled "Fighting Fatware".
We're doomed to repeat history...
https://archive.org/details/BYTE-1993-04 https://archive.org/details/BYTE-1993-04
The article starts:
Dave Brown, a Keene, New Hampshire-based entrepreneur, got his Christmas wish last year - a copy of Microsoft's Access relational database manager for Windows. Excitement turned to disappointment, however, once Brown tried to run the program. Despite the fact that his system had the 4 MB of RAM that Microsoft recommends, Access was "hideously slow." A call to Microsoft technical support revealed the truth: He needed at least 8 MB of RAM to achieve acceptable performance. Now Brown has two options: He can spend $200 for more RAM or wait for version 1.1, which Microsoft claims will run better with 4MB.
- timthorn 11y agoA second notable quote: One controversial aspect of the software-bloat problem is the increased use of high-level languages, particularly C and C++. While assembly programming can produce very tight code, the common belief is that with C or any other high-level language the code will be larger. However, a good programmer, says WordPerfect's LeFevre, can minimize the growth of code while making the most of a high-level language's advantages. Lotus Development (Cambridge, MA) ported 1-2-3 from assembly to C between versions 2.01 and 3.0. Consequently, the code size nearly tripled, from 1.4 MB to 4 MB. Not all of that growth is attributable to the difference between C and assembly-version 3.0, for example, included the printing utility Allways and had significantly more features-but it was a major contributor. The resulting product would not run acceptably under DOS until the company delayed its release to compress and optimize the code.