[net.micro.amiga] Ban the binaries!

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?