12 Apr
2017
12 Apr
'17
3:17 p.m.
On 04/12/2017 05:33 PM, Eric Smith via cctalk wrote:
On Wed, Apr 12, 2017 at 9:55 AM, Sean Conner via
cctalk <
cctalk at classiccmp.org> wrote:
What the heck its religion. So here's my stir...
BASIC, why is that the most universal language implemented on nearly every
micro and many other systems.
Seriously it is a suck language but it gets work done.
The yabut, is its THE only language that is somewhat portable and
generally implemented
on most everything can be named. Regardless of the CPU there basic on
it or for it.
Its been stuffed into 1k or EPROM if you can live with integers. Can't
say that with
C until recently with cross compilers, or Fortran, Pascal, Java, or
Perl. The only
exception is maybe assembly but porting a program from say 6502 to z80 is a
major pain.
C isn't perfect. Come to think of most of the languages are pretty much
in that boat.
Me, Assembly the native machine knows it and if need be I can crank a
small program
by hand. C is nice what you want some structure and still get close but
not quite
married to the iron. Pascal is good, it will typecheck you sensless.
Never saw Java,
Ruby, or python with anything under 32 bits. LUA is cool if you have
at least a meg
of ram. The list goes and the problems go on. In the end you use what
you know
and what is available.
So I have a Tandy M100 with an 80C85, and 32K of ram... Pick BASIC,
peak and poke
assembly (from inside basic) or out of choices. Same for the PX-8 but
that runs a
Z80 and OS (CP/M) but even it is space constrained enough that without a
disk
C or any other compiler will not fit (even with the 120K ramdisk wedge)
but BASIC
is in ROM.
Sure the S100 machines run it well with lots of ram and disk. Even
compilers
like BDS-C. But with two floppys around 240 or 360K your in tight spaces
for that.
So from a long term STAB (Society To Abolish Basic, down with GOTO!) member
its often the only choice to get something done.
In the end its about getting something done. If your being paid more so
and less
choice.
Allison
Yeah, I'm having a hard time with that too.
I mean, pedantically, it
should be:
#include <stdlib.h>
int main(void) { return EXIT_SUCCESS; }
where EXIT_SUCCESS is 0 on every plaform except for some obscure system no
one has heard of but managed to influence the C committee back in the late
80s.
Returning zero from main to indicate success is perfectly valid according
to the most recent three C standards. ISO/IEC 9899:1990(E) ?7.10.4.3,
ISO/IEC 9899:1999(E) ?7.20.4.3 ?5 and ISO/IEC 9899:2011(E) ?7.22.4.4 ?5
both requires that either 0 or EXIT_SUCCESS as an argument to exit() be
considered success. EXIT_SUCCESS may or may not be zero, but zero is
considered success regardless of that.
One annoyance with the way the standard defines the EXIT_x macros is that
if you use other exit status values, including those from sysexits.h (not
part of the C standard), it's possible that an intended failure status
value might happen to match EXIT_SUCCESS on some standard-compliant
implementation.
?5.1.2.2.3 ?1 of both :1999 and :2011 state that if execution reaches the
closing brace of main without a return statement, that it is equivalent to
returning zero, so even the return statement in this alleged non-portable
example is unnecessary.
On the other hand, the earlier ISO/IEC 9899:1990(E) ?5.1.2.2.3 says that
main returning with no value yields an undefined termination status.
-- Eric "not a language lawyer but I play one on the internet" Smith