chin@ankh.ftl.fl.us (Albert Chin) (05/27/90)
As most of you know, the development platforms on the Apple II and IIgs
are sometimes in need of enhanced features and bug fixes. Usually in the
case of enhanced features, the company that is developing the software
will only add features when enough users ask for it. This is ludicrous.
In addition, the time necessary to compile all bug fixes is often very
long and many people don't have the time to document all bugs they have
encountered.
As programmers, we are entitled to the best development platform for our
computer of choice. This makes developing powerful programs easier.
Therefore, for the next three weeks, I propose a plan to notify ALL Apple
II and IIgs companies developing software for programmers and report to
themm bugs and enhancements which we would like to see to their programs.
Here is how to accomplish this:
o Make note of my E-MAIL address and mail to me, within the next three
weeks, all enhancements you would like to see to your current
development platform. In addition, please document all bugs that you
have found in the software to date. Please leave me you mailing
address and E-MAIL address. The mailing address is optional.
o Notify other programmers in your area of what I am doing. I would like
to provide as comprehensive a list as possible to the companies whom
we are addressing. It is important that we all unite to make the IIgs
development system the best.
I would appreciate someone leaving me MAIL that will leave this message
on Apple OnLine and GENIE. I don't have accounts on these systems and,
therefore, cannot send this message. Please, will someone do this and
have the programmers on America OnLine and GENIE mail their requests to
you and then you can forward them to me.
At the end of three weeks, I will compile all MAIL sent to me and then
send a copy of this to ALL that have responded to this request. I will
then wait one more week in case there are any last-minute changes.
This is the only chance we, as programmers, have of obtaining a very
powerful development system we can all agree on and be proud of. Please,
in addition to noting bugs and enhancements, note features that you find
especially useful. This will help in our cause.
Your comments and criticisms are welcome. Please respond and post this
message everywhere.
\bye
Albert Chin ... mthvax!mamia!albert
crash!mthvax!mamia!albert
bsherman@mthvax.cs.miami.edu (Bob Sherman) (05/28/90)
In <341@ankh.ftl.fl.us> chin@ankh.ftl.fl.us (Albert Chin) writes: [stuff deleted] >As programmers, we are entitled to the best development platform for our >computer of choice. This makes developing powerful programs easier. >Therefore, for the next three weeks, I propose a plan to notify ALL Apple >II and IIgs companies developing software for programmers and report to >themm bugs and enhancements which we would like to see to their programs. >Here is how to accomplish this: > o Make note of my E-MAIL address and mail to me, within the next three > weeks, all enhancements you would like to see to your current > development platform. In addition, please document all bugs that you > have found in the software to date. Please leave me you mailing > address and E-MAIL address. The mailing address is optional. > o Notify other programmers in your area of what I am doing. I would like > to provide as comprehensive a list as possible to the companies whom > we are addressing. It is important that we all unite to make the IIgs > development system the best. > >I would appreciate someone leaving me MAIL that will leave this message >on Apple OnLine and GENIE. I don't have accounts on these systems and, >therefore, cannot send this message. Please, will someone do this and >have the programmers on America OnLine and GENIE mail their requests to >you and then you can forward them to me. >At the end of three weeks, I will compile all MAIL sent to me and then >send a copy of this to ALL that have responded to this request. I will >then wait one more week in case there are any last-minute changes. >This is the only chance we, as programmers, have of obtaining a very >powerful development system we can all agree on and be proud of. Please, >in addition to noting bugs and enhancements, note features that you find >especially useful. This will help in our cause. >Albert Chin ... mthvax!mamia!albert > crash!mthvax!mamia!albert I think it would be a lot easier to use things that are already in place such as the Apple II Developers Assn. Most all of the Apple II developers and programmers belong to this group, and that would be the place to reach those you want to reach both for bugs and assistance in correcting them.. -- bsherman@mthvax.cs.miami.edu | bsherman@pro-exchange | MCI MAIL:BSHERMAN
jm7e+@andrew.cmu.edu (Jeremy G. Mereness) (05/30/90)
Excerpts from netnews.comp.sys.apple2: 26-May-90 Attention ALL Apple Program.. Albert Chin@ankh.ftl.fl. (2412) > o Make note of my E-MAIL address and mail to me, within the next three > weeks, all enhancements you would like to see to your current > development platform. As a Unix user, I have come to expect the simplicity and power of /bin/cc as a c compiler. It is powerful, fast, and one can rest assured that if something goes wrong, it is your code, not a bug in the linker or the compiler. It is powerful enough so that C code may be ported easily from one machine/CPU to another. This coupled with editing the thing in an extremely powerful text-editor like gnu-emacs. I also have come to expect a shell as powerful and useful as C-shell, along with all the typical utility commands from Unix, i.e. grep, diff, lint, file redirection, make command pipe-lining, etc. These are not extraordinary things to ask for, even under the 16-bit environment of the GS. MS-DOS was an attempt to reporoduce this environment for the PC, albeit a sloppy one. The GS is a much nicer 16 bit machine than the PC, but no-one has put together a development package that can carry its own waight. Finally, this development package should be easily obtainable, if not standard equipment. Unix itself is shipped with cc and all the tools necessary to develop on it, even if the customer never intends to program on his machine. This is done so that software may be distributed as source code, which is machine independent and customizable. Expecting a programmer to shell out hundreds of extra dollars to develop on a machine only discourages development. Expecting //gs programmers to buy macintoshes to do development is absolutely ludicrous. The word is that Apple can't do anything about APW because they are obliagate to the Byte Works; that MPW is something that they have full rights to, so they focus their attention on it. Until this situation is rectified and Apple supports a powerful native-based compiler for the //gs, the industry will not have a reason to have confidence in the product. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |Jeremy Mereness | Support | Ye Olde Disclaimer: | |jm7e+@andrew.cmu.edu (internet) | Free | The above represent my| |a700jm7e@cmccvb (Vax... bitnet) | Software | opinions, alone. | |staff/student@Carnegie Mellon U. | | Ya Gotta Love It. | ---------------------------------------------------------------------------
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/01/90)
In article <UaMezV600VR088tFhE@andrew.cmu.edu> jm7e+@andrew.cmu.edu (Jeremy G. Mereness) writes: >As a Unix user, I have come to expect the simplicity and power of >/bin/cc as a c compiler. It is powerful, fast, and one can rest assured >that if something goes wrong, it is your code, not a bug in the linker >or the compiler. Ha! In my years of experience developing software on UNIX, I must have uncovered over a hundred bugs in compilers from around a dozen vendors. In fact during the last week we ran into two more on MIPS (SGI 4D) machines. >It is powerful enough so that C code may be ported >easily from one machine/CPU to another. This has very little to do with the compiler! Arbitrary C code is in fact NOT particularly portable; it takes care to avoid stepping beyond the bound of what the language guarantees for your programs to be portable. Most portability problems that I've encountered have arisen from applications exploiting operating-system specific features that are not universally available in all C environments. Portability even among UNIX variants has been unduly difficult; that has historically motivated the /usr/group 1984 Standard (which in turn contributed to the IEEE 1003.1 POSIX standard, the ANSI C standard, and the X/Open Portability Guide), development of "multiple universe" systems such as Pyramid's and mine (which in turn contributed to Gould's, Sequent's, Sun's and others), and to merged BSD/SystemV/Xenix as in UNIX System V Release 4. Given the hassle even when porting among UNIX systems, it should not be surprising that ensuring portability among non-UNIX systems is hard work. >This coupled with editing the thing in an extremely powerful text- >editor like gnu-emacs. Gnu EMACS is a notorious resource hog, making it not a very good choice for personal computers. It is also not the editor of choice where I work (where we have access to essentially every common UNIX text editor) among people who have been exposed to "sam". Since "sam" resembles to a fair degree the ORCA Desktop editor, this argues that the latter is not a particularly bad choice. I find it eminently usable. >I also have come to expect a shell as powerful and useful as C-shell, There are several shell-like environments available for the IIGS. Of course, shell features such as background processes and "job control" are rather difficult to emulate in the GS/OS environment, since they rely on UNIX-specific features. >along with all the typical utility commands from Unix, i.e. grep, >diff, lint, file redirection, make command pipe-lining, etc. All these except for "lint" are available for the IIGS, and some of them (command-line I/O redirection and piplines) are supported by the APW/ORCA shell. There is no need for "lint" if the compiler does a good job of producing diagnostics. ORCA/C includes a "Check for errors" invocation that is in effect the same as "lint" (using prototypes helps). >MS-DOS was an attempt to reporoduce this environment for the PC, I see little evidence for that. MS-DOS is gratuitously unlike UNIX in many ways. >The GS is a much nicer 16 bit machine than the PC, but no-one has >put together a development package that can carry its own waight. This is simply untrue. Mine is set up with a very nice development environment; not UNIX, but not bad considering the constraints. >Finally, this development package should be easily obtainable, if not >standard equipment. Unix itself is shipped with cc and all the tools >necessary to develop on it, even if the customer never intends to >program on his machine. This also is untrue. Software development tools are normally unbundled by UNIX VARs these days. It should be obvious why. >This is done so that software may be distributed as source code, Not at all. It used to be done because UNIX was originally distributed as a snapshot of a software development system, and there was no particular reason to omit any of the available tools from the distribution. Indeed, because AT&T was not allowed to provide support to external UNIX licensees, it was essential that tools be included so the licensees could support themselves. It was never because of a deliberate policy of encouraging applications to be distributed in source code form. (It happens that some were and some were not; usually one has to pay a lot extra for sources and sometimes they are simply unavailable.) >Expecting a programmer to shell out hundreds of extra dollars to >develop on a machine only discourages development. Expecting non-programmers to shell out hundreds of extra dollars for a system that will only run applications produced by others discourages sales! It's the same reason that the basic IIGS package does not include hard disk, modem, etc. Only those who need them should have to pay for them. >Expecting //gs programmers to buy macintoshes to do development >is absolutely ludicrous. I will agree with this to the extent that I think Apple is paying too much attention to COMMERCIAL developers and not enough to PERSONAL developers. The latter I agree should not be expected to buy a Macintosh to support their IIGS (I sure as hell won't; I'd drop Apple altogether in favor of IBM first). The "Mac-think" that personal computer users are idiots who can't be expected to develop their OWN, UNIQUE applications is quite the opposite of the original Apple vision. There is NO WAY that commercial developers can meet every personal computing need. To restore the vision there must be more emphasis on the private computist, and the Apple IIGS happens to be a fairly good match for his needs, IF there is a turnaround in the software industry trend of dropping Apple IIGS flavors of useful, personal products (including games, which are one of the strongest inducements to invest in a personal computer for home use). >The word is that Apple can't do anything about APW because they are >obliagate to the Byte Works; that MPW is something that they have full >rights to, so they focus their attention on it. That's not exactly what Apple said, but in any case I have seen no evidence that would lead me to believe that Apple could or would produce a superior equivalent to APW, even if they owned the sources outright. In fact if you read their dialogue carefully, they made it pretty evident that they think they don't have enough resources to tackle something like that. At any rate they have refused to do so. I agree with Apple's decision to not confuse the issue by maintaining "separate but equal" APW/ORCA environments. Going with just one of these two environments will certainly simplify development, since add-on utilities no longer will be found to work on one but not the other, due to different versions of the shell etc. >Until this situation is rectified and Apple supports a powerful >native-based compiler for the //gs, the industry will not have a >reason to have confidence in the product. ORCA/C is as "powerful" as you could ask for. What difference should it make to anyone what label is stuck on it? Apple HAS labeled the Megamax compiler with their name, but that doesn't make it a better compiler. Again, I have no reason to think that Apple staff could or would produce a compiler significantly better than what we already have. Why should they attempt to duplicate existing facilities rather than concentrate on new ones? I have NEVER heard commercial software publishers attribute their poor or nonexistent support of the IIGS to lack of Apple-provided compilers or assemblers. They offer several other excuses though..