Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site 3comvax.UUCP
Path: utzoo!watmath!clyde!cbosgd!hplabs!oliveb!3comvax!mykes
From: mykes@3comvax.UUCP (Mike Schwartz)
Newsgroups: net.lang
Subject: Re: structured assembler (BASIC)
Message-ID: <463@3comvax.UUCP>
Date: Thu, 27-Mar-86 18:50:44 EST
Article-I.D.: 3comvax.463
Posted: Thu Mar 27 18:50:44 1986
Date-Received: Sat, 29-Mar-86 04:50:23 EST
References: <443@3comvax.UUCP> <7900003@ztivax.UUCP> <153@crin.UUCP> <7947@watrose.UUCP>
Reply-To: mykes@3comvax.UUCP (Mike Schwartz)
Organization: 3Com Corp; Mountain View, CA
Lines: 76
Keywords: BASIC

In article <7947@watrose.UUCP> tohaapanen@watrose.UUCP (Tom Haapanen) writes:
>Then it would be well documented vomit.

Pick up a book on MicroSoft Basic for the PC before you rant and rave about
Basic being vomit.  The whole point I originally tried to make about
Basic is that it is extremely well refined and that it has as many man
hours of improvements made to it during the same time Unix has been refined.

Another point you seemed to miss is that the development environment for
Basic is quite good.  You can stop your program, display variables, patch
the SOURCE CODE, and eliminate long boring compilations.  Then when the
program logic is complete, it can be compiled ONCE and it will run
pretty damn fast.

<time for my asbestos suit>
If you want to talk about well documented vomit, I want to talk about
not-so-well documented vomit - Unix.  The 'C' programming language is
proof that structures like if..else.. and while...endwhile do not necessarily
make the best programs.  I peruse Unix sources occaisionally and I am
appalled at how UNREADABLE they are and I just do not see how anyone can
call 'C' a readable language.  As a matter of fact, the unix sources I
have seen (BSD 4.1) have exactly one comment per file, have variables that
have an average of 4 characters per name, and only the well documented
library routines are decernable without lots of time spent following the
logic of the programs step by step.  

In 'C', when you see a call like:
w=opnwndw(xqtnm);
the only way you can tell what it does is by using grep to find out
where the function is defined and if you are lucky, it will be documented.

At least in Basic, all of the keywords are WELL KNOWN, and no two programmers'
opnwndw() functions are different (the language defines the call), and the
language (Basic) tends to be geared toward using whatever hardware the
interpreter is implemented on in a easy to use way.  Not many implementations
of Unix (written in 'C') have been ported to machines and really use the
hardware - READ ON - I have not seen a compiler that will use the string
functions that the 808x family of processors provide.  These kinds of 
instructions (LODS, STOS, etc.) are what makes the processor FAST.

<can I take off my suit?>

Now, before I finish, I would like to point out that I actually have 
presented CONCRETE examples of why I think 'C' has serious problems.  I have
not even mentioned how big or slow 'C' programs are (the downfall of
Unix as a standard).  To say that a language is VOMIT because it does
not have if...then...else... kind of structures just shows that some
people do not use the proper procedures for evaluating the worth of
a language.

One last point.  Structured assembler language, as I know it and have
implemented it, does have if...else...endif... and all the rest of
the structured language constructs, including parameter passing.  It just
uses the most appropriate addressing modes for the target processor - by
definition.  There are 0 (count 'em ZERO) bytes of runtime hogwash appended
to the real code that you want, and there is only the slightest difference
between the code generated and the code that I would generate by hand.
If you speak 8086, the following "IF" statement illustrates structured
assembler language:

if es:[bx] == 10 then
.	print "hello, world"
else
.	print "goodbye world"
.	mov	ax, 3100
.	int	21H
endif

The keywords "if", "else", and "endif" are recognized directly by
the assembler and are not macros.  "print" can be a macro or a function
call, however the programmer desires.  Libraries are kept in source
format but may be linked in using a linker.  

mike schwartz
3Com Corp.  (usual disclaimers apply)
"real men get the job done"