peter@graffiti.UUCP (Peter da Silva) (11/23/85)
I originally posted the following to net.news.group only, but it does address a point that needs to be made... to wit, that while UNIX implies portability, portability does not imply UNIX. > The Mac is not UNIX. There is not one relatively standard compiler that > everyone uses. #ifdef's just don't cut it, because the compilers are very > different from each other. The idea of distributing source only is, > frankly, stupid, and people who have programmed so little on the Mac that > they would make such a suggestion should not be going around pretending to > be experts. Well how about getting together & doing something about making these radically different languages pull together a bit more? Over in net.amiga there has been a little discussion on trying to write programs that can be ported easily between the AMIGA, the ST, and the MAC. If the MAC can't even port to the Mac not only does this cut Mac users out of this game but it hardly makes the Mac look like a real computer... for the rest of us or not. If what you say is true and unavaoidable I've just lost most of my considerable respect for the Macintosh and its user community. After all... ifdefs do cut it everywhere else. It's possible with a little work to write a program that can compile and run on the IBM-PC with a variety of compilers, VMS, *and* various semi-compatible flavors of UNIX. The same program, mind you... [On further consideration... this would definitely make a useful net.software. project. Someone might even get a paper on "porting programs between radically different environments" or something. Hey, Ken, ever considered porting curses to the Macintosh? :->] -- Name: Peter da Silva Graphic: `-_-' UUCP: ...!shell!{graffiti,baylor}!peter IAEF: ...!kitty!baylor!peter
guido@boring.UUCP (11/25/85)
In article <465@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: >After all... ifdefs do cut it everywhere else. It's possible with a little >work to write a program that can compile and run on the IBM-PC with a variety >of compilers, VMS, *and* various semi-compatible flavors of UNIX. The same >program, mind you... Yes, but it doesn't come naturally (nor free). You may indeed be overestimating the "professionalism" of Macintosh C programmers (though it's slowly improving, now, with examples like SKEL available and all the books out). From what I've seen, many of them had never written in C before they got their Mac. Also, someone on a 128k Mac doesn't have the spare memory to add all the #ifdef's to their code in the first place. >[porting software to radically different environments] An example of portable software for various windowing systems is "Brown Windows", which runs on Suns, Apollos and other workstations. But this is a LARGE shell of extra software, and after porting it to the Mac I believe you would be left with little space for your program, AND the user interface wouldn't be too Mac-ish. The same would be true for GKS. The best approximation of what you want would probably be using the Aztec "shell" environment and go back to printf. Then you can write portable programs that run with no modification on Unix and Macs. But: no windows, no mouse, no dialogs, not a single Macintosh-like feature (even the corners of the screen aren't round any more!). Here it would even make sense to port curses :-> -- Guido van Rossum, CWI, Amsterdam, Holland (guido@mcvax.UUCP)
gus@Shasta.ARPA (11/26/85)
> Well how about getting together & doing something about making these radically > different languages pull together a bit more? Over in net.amiga there has been > a little discussion on trying to write programs that can be ported easily > between the AMIGA, the ST, and the MAC. If the MAC can't even port to the Mac > not only does this cut Mac users out of this game but it hardly makes the Mac > look like a real computer... for the rest of us or not. If what you say is > true and unavaoidable I've just lost most of my considerable respect for the > Macintosh and its user community. > > After all... ifdefs do cut it everywhere else. It's possible with a little > work to write a program that can compile and run on the IBM-PC with a variety > of compilers, VMS, *and* various semi-compatible flavors of UNIX. The same > program, mind you... > This is beginning to sound like the old "What's the best language" debate that has raged ever since the first FORTRAN compiler in the 50's, or even earlier with "what's the best assembly language architecture?" Unfortunately most programming languages (C especially) allow too much flexibility in the implementation. This is compounded by the fact that there are too many un-obvious choices to make when adapting a language like C to the Mac. (The old "glue routine" problem. I has been the experience of many that no matter how well certain differences between two architectures are understood, the job of porting from one to another is non-trivial. IFDEF's are currently the best solution to this problem, but they must be applied manually, and as the program becomes more complex, the IFDEF's make it harder and harder to read. The Mac has made portability even harder by stressing the concept of user interface consistency. Most Mac users agree that it is the Mac's unique user interface, and Apple's ability to convince third party developers to abide by that interface is what sets it apart from most other machines. The Amiga and the ST also have a window oriented interface, but they do not have a company behind them like Apple that stresses user interface consistency. In the case of the ST, the system disk contains examples of programs that violate the user interface (The terminal DA, View File) and the Amiga has too many features which simply make it inconvenient at times not to use the standard interface. "Portable" Mac programs, thus, simply are not looked upon as highly by Mac users unless a significant amount of work is done to make them "Macish" at which time they are no longer portable. The Amiga, with 256K of ROM and all sorts of fancy hardware also inhibits portability. The ST eems to be a parasite that cannot live on its own, so it must stress portability (with IBM PS's running GEM) else clutch at what ever straws it has for a market other than its price. Most computer manufacturers (especially those making IBM clones and UNIX boxes) stress portability in order to decrease the amount of work that they have to do to be accepted into the marketplace. Other companies, Apple, and Commodore/Amiga, being two striking examples, have decided that their products are unique enough so that portability is no longer an issue and third party developers are willing to create software that will only run on these machines. It is obvious that Apple has succeeded in this regard. Commodore, having a much newer product, hand having current financial difficulties has yet to prove that the Amiga can survive, but at least they are trying. Users of these machines are not only interested in using software that works, but also software that makes best use of the unique capabilities of their machine. (Otherwise, they would have bought a machine which runs "portable" software.) It is thus simply not practical to post one source and expect it to fully take advantage of many different architectures. One of the worst problems in thie regard that is plaguing the Macintosh is the lack of many programming language environments which have been designed to specifically support the Mac architecture. Most, if not all existing systems were ported from other machines and thus bring with them constructs that simplyt don't work on the Mac. The most common of these is the TTY window. This is a concept that has been part of most languages since the very first machines. (The EDVAC, one of the earliest Von Neuman machines used a Baudot teletype and paper tape for I/O) Unfortunately, with very few exceptions, language developers have deemed it their duty to support all of the standard features of a language even if those features run contrary to standard Mac programming practice. A perfect example is a PASCAL ReadLn, or a C Scanf. Both of these routines block until a CR is received on the input stream (i.e. the user tytpes RETURN). This is NEVER done in a good Macintosh program because it disallows other activities that the user might want to do such as work with another window, open a Desk Accessory, etc. SO WHY BOTHER SUPPORTING PORTABLE LANGUAGES???? Some people might argue that readln and writeln are useful on the Mac for debugging. A much better way to debug is to use a symbolic debugger. Why havn't developers been writing good symbolic debuggers rather than spending lots of time and effort supporting features that are not conducive to good Mac programming?