dowst@JPL-VLSI.ARPA (05/29/87)
My vote is for dropping the language discussion at this point. The diatribes are getting to heavy, and the contributions to the needs of most Apple owners' knowledge base are minimal. Most decent Apple program development is done in assembly language. Most home users find AppleSoft sufficient for their programming needs. Neither C nor Pascal/Modula have much utility for "the rest of us". Although I have been a programmer for over 30 years, I admit that I can't make any linguistic evaluations at the level the discussion has now reached. I am not sure that the various authors can either. Henry Dowst evaluations at
gwyn@BRL.ARPA.UUCP (05/30/87)
I have to disagree with your claim that "neither C nor Pascal/Modula have much utility for "the rest of us"". It is said that currently most Macintosh commercial software is being written in C; both C and Pascal (I don't know about Modula-2) are available for the whole Apple II family; the Apple IIGS has good 16-bit C and Pascal compilers available (Apple provides an assembler and a C compiler), and the IIGS built-in AppleSoft BASIC is effectively limited to the 8-bit world. It is certainly true that the choice of language is not terribly relevant to the buyer of a turnkey package; however, even in that situation it may make a difference. For example, if MouseTalk had been developed under Apple's Pascal, it would not be able to be easily moved onto my hard disk nor access ProDOS files for upload/download; these capabilities are important to me as a product user. Some Apple Pascal-based software, for example Wizardry, runs more slowly than it should, as a direct consequence of the language implementation used. Infrequent, amateur programmers may well be advised to stick to AppleSoft BASIC, since it comes with the machine and is accommodated in Apple documentation. However, for serious programming projects, AppleSoft BASIC has a number of severe limitations (among them lack of modular subroutines and too limited variable names) that make it not usually the best choice. Beagle Brothers has a BASIC compiler for those who need more speed for their BASIC programs. Assembly language has the advantage of permitting direct control over everything programmable about the machine, but it requires taking care of numerous low-level details that a higher-level language handles for the programmer. Even worse, assembly code is machine-specific and cannot readily be ported to other systems. These characteristics have adverse impact on the long- term economics of software development, even for hobbyist programmers. Apple Pascal has the advantage of being a higher-level language, and one that is usually taught in introductory Computer Science courses, but it has the notable drawback of using its own incompatible operating system and disk format. There are at least two C packages available for the Apple II; the one I use, Aztec C65, works well and makes it fairly easy to port applications from the UNIX environment at work to my home system. I believe that Forth, Fortran-77, and Lisp are also available in some form for the Apple II, but I don't have any experience with those products. For the Apple IIGS, the three choices at present seem to be assembler (basically ORCA/M, which is also for sale from the ByteWorks), C, and TML Pascal. All three are available through APDA, the first two (Apple products) in Beta test versions. For what it's worth, of the languages available to me at home for Apple II programming, my approximate choice ratio is: assembler 5% (limited to special circumstances) BASIC 10% (mostly small, one-shot tests or contributed code) C 85% (most major applications) I have no motivation to buy more languages that are functionally similar to these; if I were developing AI applications, I might buy Lisp or Prolog or some such language (if none were available, I'd produce one rather than trying to use the wrong tools for the job). I'm considering porting Icon to the IIGS to support certain cryptographic applications (although C seems to be best for most of what I have in mind). One thing to keep in mind: Serious software development practically requires a hard disk. The 5Mb ProFile I have is not really enough; 20Mb seems like the best size for the typical developer. 40Mb and larger would require partitioning for ProDOS, which is probably an acceptable nuisance if you really need the space -- which you will if you work with digitized images or sound. In case you haven't inferred it, I consider the IIGS to be a much more capable system than the //e, particularly from the programmer's viewpoint. Even though preliminary software support for the IIGS is a bit rough, I am really glad I upgraded.
ranger@ecsvax.UUCP (Rick N. Fincher) (06/01/87)
In article <8705291829.aa03893@VGR.BRL.ARPA>, gwyn@BRL.ARPA (Doug Gwyn, VLD/VMB) writes: > One thing to keep in mind: Serious software development practically > requires a hard disk. The 5Mb ProFile I have is not really enough; > 20Mb seems like the best size for the typical developer. 40Mb and larger > would require partitioning for ProDOS, which is probably an acceptable > nuisance if you really need the space -- which you will if you work with > digitized images or sound. Is there still a 32 MB limit for Prodos 16 volumes? I had heard that the volume sizes were greatly increased for Prodos 16 but I have not been able to get the Tech reference manual yet, so I don't know. Rick Fincher ranger@ecsvax
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/02/87)
In article <3306@ecsvax.UUCP> ranger@ecsvax.UUCP (Rick N. Fincher) writes: >Is there still a 32 MB limit for Prodos 16 volumes? I had heard that >the volume sizes were greatly increased for Prodos 16 but I have not >been able to get the Tech reference manual yet, so I don't know. I thought I remembered the ProDOS 16 Tech. Ref. saying that, but I'll check and if it's different I'll let you know. Note that the 32Mb limit corresponds to the maximum size that a 16-bit block pointer (for 512-byte blocks) can reference. This is the fundamental constraint, built into the structure of ProDOS directories. The format has to be changed or extended somehow to access a larger partition.
eww@OBERON.LCS.MIT.EDU.UUCP (06/03/87)
Ummmm, pardon my ...... but in regard to a 32MB restriction to a ProDos Volume; if one were given a 160MB drive, just what are the parameters required by ProDos to utilize such a unit? ie: 1. What separation of the theoretical 160Mb's are required? 2. Are directories sufficient or are partitions of 32Mb's neccessary? 3. Is it that ProDos requests different "Drives" such as slot# "X" drive #1, slot# "X" drive #2 etc. etc.?
rupp@cod.UUCP (06/05/87)
Let me add Z-Basic, and Micol-Basic to the list of alternatives to Applesoft. These two languages are much more modern in approach and greatly improve on Applesoft's modest capabilities. Right now they are limited to 8-bit mode, but we can only hope that GS specific versions will appear eventually. [I have no connection with any product mentioned above. My opinions are solely my own and are offered for your information. How's that, Gary?]
sloan@pnet02.UUCP (06/06/87)
Well, when I talked to the folks at Apple about the 32MB limit, they had
_absolutely *NO*_ plans on changing the maximum disk size.
Personally, some ProDOS software gurus and some hardware geeks should be able
to come up with the same idea as folks that partition drives for DOS 3.3!
Have one, two, or however many "volume" directories it takes. ie:
/HDA /HDB /HDC etc, etc....
Steve
UUCP: {ihnp4!crash, hplabs!hp-sdd!crash}!gryphon!pnet02!sloan
INET: sloan@pnet02.CTS.COM