Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!cmcl2!adm!smoke!gwyn From: gwyn@smoke.brl.mil (Doug Gwyn) Newsgroups: comp.sys.apple2 Subject: Re: Choosing a language (ML vs HLL) Message-ID: <16040@smoke.brl.mil> Date: 2 May 91 20:50:21 GMT References: <9105010011.AA10540@apple.com> <14106@ucrmath.ucr.edu> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 72 In article <14106@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >I would also like to comment on HLLs being an "enabler"... >If HLLs enable people to do so much on the GS, how come we aren't >seeing a plethoria of software for the GS. There are at least five or >six HLL compilers for the GS I'm aware of. Sure, a few applications >dribble in (Hypercard, e.g.), but I don't see people porting a lot >of software from the PC or the MAC to the GS. Most software over there >was written in Pascal or C. What's the problem? Where is all the ASSEMBLY-LANGUAGE software for the IIGS? You don't see much commercial software support for the IIGS, period. This has very little to do with programming languages. >(1) Most C and Pascal programs are not portable! C portability is a myth. > Pascal is even worse. I'll attack C. I can't speak for MPW C, but I > know for a fact that ORCA and APW C's standard libraries are anything > but (of course, "standard library" is an oxymoron). You think segment- > ation on a PC is bad, try segmentation on the 816! Finally, most C and > Pascal programs written on PCs or Macs were written specifically for > PCs or Macs. They are system dependent. Sure, you can port a lot of > UNIX utilities to APW, but are they that useful if you don't have > UNIX? Being able to type "ls" rather than "cat" doesn't excite me. Perhaps you should make logical arguments rather than trying to come up with rationalizations for a position you already hold on other grounds. ORCA/C most certainly does provide a rather complete implementation of the library functions specified in the C standard. There is nothing "oxymoronic" about the concept of standard library functions. APW C predated the C standard, but even it provides a fairly complete set of standard C library functions. C is, in my opinion as a specialist in software portability, the best language to use for programming for portability. Nobody in his right mind would maintain that any choice of a programming language automatically guarantees complete portability of code written in the language; however, if you are TRYING to code portably, C provides good support for doing so. I have written hundreds of applications that run on a variety of different systems, from 8-bit Apple IIs to Cray-2s. They were coded carefully in C and were easy to port, in many cases requiring NO editing whatsoever. AT&T UNIX System source code is available only under license, and the cost is prohibitive for licensing the source for home use. Therefore porting UNIX source code is not an option. I have several independent reimplementations of UNIX utilities, and they have been QUITE useful on my Apple //e, originally, and now my IIGS. By the way, one does not need to create an executable program simply to alias "ls" to "CAT" in the APW or ORCA shell environments. >(2) Once you manage to port your program from a bigger machine to the GS, > you'll find that it runs horribly slow. I've tried a few programs on > my 80386 and GS. The ORCA/C version ran about 50-100 times slower than > the Turbo C version. That's why you don't see a lot of developers porting > games to the GS. Even if they can lick the compatibilty problems, you've > still got a problem with speed. Given your exhibited level of experience with HLLS on the Apple IIGS so far, it doesn't surprise me that your ports worked poorly. (Note also that the speed comparison was between different knids of hardware and you failed to mention the relevant clock rates etc. Certainly a 33MHz 80386 should be EXPECTED to run faster than a 2.8MHz IIGS.) I've gotten reasonable performance from lots of applications coded in C on my IIGS. Further, I have many applications running on my IIGS that I would not have had the time to code in assembler, but did have the time to port from another system where the C code already existed. By all means, if you think you don't have but the one machine to deal with, make a hobby out of it. When you finally discover that you have to move to another platform and none of your applications are available due to having coded them all in an excessively machine-dependent manner, remember that some of us tried to warn you in advance.