From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a4fcaebc2df9be6,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-16 08:51:25 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!agate!tcsi.tcs.com!uunet!mr.net!usenet From: "Paul Pukite" Newsgroups: comp.lang.ada Subject: Don't believe the hype: VB and ST Date: Thu, 16 Mar 95 10:34:26 CST Organization: DAINA Engineering Message-ID: <51322.pukite@daina.com> Reply-To: NNTP-Posting-Host: msp2-4.nas.mr.net X-POPMail-Charset: English Date: 1995-03-16T10:34:26-06:00 List-Id: EE Times, March 13, 1995 article by Alexander Wolfe about engineering CAD tools and Visual Basic: ``Nevertheless, Visual Basic has several negatives. Most notable, ease of use comes at the expense of speed and size. "VB is very resource-consumptive," said Escalades's Hsueh. "The resource issue prevents us from doing major engineering products with just VB tools." Another drawback is apparent when attempting to debug Visual Basic programs. According to R-Active Concepts' Drusinsky, "It's very difficult to get a bird's eye view of what the overall code structure is." That's because VB is event-driven, there's little explicit order to the code it generates, and it's hard to view sub-procedures.'' -- These two guys sell VB-based tools, no less! Clent/Server Today, March 95 review of a Smalltalk development system: ``Once we were able to load the product, we noticed the same variability when it came to loading just the Smalltalk image. The product on our test system took anywhere from 1:15 seconds to over four minutes to load each time. Loading the visual development environment took another minute or two. The performance problem with VisualAge comes from its sheer size. IBM sets the minimum system configuration for VisualAge as a 25-MHz 486 processor with 16MB of RAM; 24MB is recommended. Its Smalltalk image file is just over 7MB large, and when you add all the DLLs and other items it uses, you begin to hit serious performance problems on a 16 MB system. While working with VisualAge, it was not uncommon for the system to freeze while VisualAge worked with its own swap-file. At times our drive would spin for up to seven minutes while VisualAge worked. What we found very surprising is the fact that IBM recommends disabling the use of Windows for Workgroups networking because it takes up too much memory on 16 MB systems, which poses a serious problem to those working off a file server. Moreover, it also defeats the purpose of developing client/server applications. The real shock comes when you attempt to deploy Visual Age applications on client platforms. Your users will need to have at least 12MB of RAM to deploy runtime applications. Our simple to-do application stores entries from a text box in an ordered list and then displays them in a list box from which the entries can be removed or more added. This unadorned application generated a runtime module of nearly 7MB. That's because any VisualAge application needs almost the entire VisualAge runtime image.'' -- And we always thought that Ada had an "image" problem!