Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!paperboy!hsdndev!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: <16057@smoke.brl.mil>
Date: 3 May 91 21:22:28 GMT
References: <14106@ucrmath.ucr.edu> <16040@smoke.brl.mil> <14159@ucrmath.ucr.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 61

In article <14159@ucrmath.ucr.edu> rhyde@clemente.ucr.edu (randy hyde) writes:
>>> re: all you need is alias to do "ls" instead of "cat"
>How much do you use UNIX?  Probably less than I do!

Your ignorance of the UNIX community is showing.

>ls and cat do not produce the same output.

Of course they don't.  You said that you didn't think that being able to
type "ls" instead of "CAT" was such a big deal.  If that was your only
concern, then aliasing "ls" to "CAT" would provide even that.

However, if you do need to obtain a simple list of filenames, then the
absence of a UNIX-like "ls" IS a big deal.  In fact, I've felt the need
for a UNIX-like "ls" quite frequently in the course of IIGS software
development.

>My comment was that most GS/APW or ORCA users don't need these fancy
>scripts (since the GS doesn't support multiprogramming, hence effectively
>eliminating the possibility of many UNIX scripts).

Very few UNIX shell scripts actually require multitasking.  The main
requirement is for unidirectional pipes, which the ORCA shell does provide.

>It's Byteworks problem to provide decent libraries.  Because they
>didn't, few people
>can port their PC applications (indeed, BW should go beyond the standard
>"UNIX" libraries and supply the superset provided by most PC C compiler
>vendors).

ByteWorks provides practically the entire set of standard (not "UNIX")
C library functions, which is all that portable C programs can rely on,
plus interfaces for the Apple toolsets, GS/OS, and the shell.  I don't
know what else you seem to want, but it isn't a reasonable expectation.

>If you think you're so good, here's a challenge, start with a PC or Mac-based
>version of FLEX and BISON and port them to the GS (Yes, this has been done, the
>results I've seen [due to segment limitations on the GS] is not very pretty).

I don't accept such challenges.  If one wants to port GNU software, he
should start with the GNU sources, not with the result of hackery by PC
butchers.  Such an effort would also be a test of the portability of
the GNU software itself, which is not necessarily very high to start
with.  Remember that the GNU project is specifically aimed at providing
software in a UNIX-like environment, and so it is entitled to exploit
UNIX-specific features that are not available under other operating
systems.  Also, GNU code might assume that you will use GCC, so some
of it makes essential use of the nonstandard extensions to C that GCC
provides.

I have ported to the IIGS a large amount of C code that was designed
for portability.  The only ByteWorks ORCA/C library limitation that
still (as or ORCA/C 1.2) gets in my way is the lack of the v*printf()
functions.  Releases of ORCA/C before 1.2 had so many compiler bugs
that porting was inordinately difficult; release 1.2 is much better.

My usual procedure is to develop utilities on UNIX, which has a much
better software development environment, then port them to my IIGS
when I need them.

I have never encountered any "segment limitations", whatever they are.