Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn From: gwyn@smoke.brl.mil (Doug Gwyn) Newsgroups: comp.sys.apple2 Subject: Re: Hello and comments... Message-ID: <14841@smoke.brl.mil> Date: 13 Jan 91 03:20:11 GMT References: Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 48 In article SHBOUM@MACALSTR.EDU writes: >>It's not a matter of laziness, but of effective use of one's limited >>lifespan. When I can produce (AND MAINTAIN, an important point) dozens >>of applications for use on a wide variety of systems using a HLL in the >>same time that I could produce fewer, less maintainable applcations on a >>single platform, what would you think I ought to choose? > Well are you interested in quality or quantinty? Sure you could write >lots of programs for lots of computers using C, but would those programs >really take advantage of that computer's resources? First of all, if an application does what is wanted, who cares whether or not it exploits system-specific features that are not needed to get the job done? Also, even for classes of applications that require system features that may not be available universally, for example an interactive painting program, normally only a small portion of the overall system need be specific to a particular platform. For example, the BRL-CAD package includes interactive 3-D solid modeling tools and frame-buffer utilities, with support for a wide variety of disparate vendor hardware, yet it is entirely implemented in C (some portions are specific to the hardware, but because of modular design, a variety of choices are available and more can be added). To port, for example, the frame-buffer utilities to my IIGS, the main task I would have to do would be to implement a small library of functions conforming to a certain generic interface specification, and link that with the applications. The implementation of the library may use a few asm{...} sections if necessary to improve display speed, but only after it proves to be a bottleneck (which it might not, it's hard to say in advance). Note that if the entire suite of tools had been coded in some assembly language (which we were not stupid enough to do), porting to the variety of platforms that are now supported would have been utterly out of the question. In 1978 the small software house that I then worked for released what was definitely the spiffiest interactive graphics system for facilities management and architectural purposes then available. It utilized a Unibus-master display processor, function buttons, digitizing tablet, etc. Practically the whole package, apart from the vendor's operating system, had been implemented in Fortran. Certain critical portions involving manipulation of the memory management unit and low-level support for dynamic memory allocation involved a modest amount of assembly-language code. The Fortran code exploited vendor extensions for boolean operations on integers, to pack and unpack data fields; otherwise, it was highly portable, so that when the time came to use a different graphics technology, porting involved vastly less work than would have been required had the system been written entirely in assembler. Performance was also extremely good. Today one would use C rather than Fortran, but otherwise this approach is still recommended.