Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!ut-sally!seismo!mcvax!boring!budd
From: budd@boring.UUCP
Newsgroups: net.lang
Subject: Re: Structured assembler (the conventional reply)
Message-ID: <6737@boring.UUCP>
Date: Thu, 23-Jan-86 13:18:04 EST
Article-I.D.: boring.6737
Posted: Thu Jan 23 13:18:04 1986
Date-Received: Sun, 26-Jan-86 04:21:25 EST
Reply-To: budd@mcvax.UUCP (Tim Budd)
Organization: CWI, Amsterdam
Lines: 139
Apparently-To: rnews@mcvax

[ I know I'll regret this ]

>I would like to tell you folks about a couple of assembler/compilers
>I wrote for a real nice structured programming language for the 6502.  
>First, however, a little background.
> ...
>Have a heart, this stuff is my opinion, and my observations (I am entitled
>to my own opinion), and send any death threats, etc. directly to me via
>mail.
>
>Mike Schwartz @ 3Com Corp.

no death threats; far from it.  I think a well defended counter-orthodox
opinion is good every now and then for those of us who hold to the
conventional beliefs, in order to force us to consider WHY we hold those
ideas, and to ask ourselves if we might not be wrong, after all.

Therefore, here is my rendering of the conventional arguments.

The arguments Mike puts forward seem to concern two ideas, portability and
machine resource utilization.  I will treat these as two issues in turn.
A typical quote on the first issue:

>This leads me to some questions that I have for all the UNIX gurus out
>there.  Is 'C' really portable, or is UNIX pretty tough to port anyway
>(by pretty tough, I mean a few months' work)?  Are other applications
>written in 'C' really portable?  (I bet most are near impossible to
>port from UNIX to the 8086).

Well, there is software and then there is software.  The term covers a lot
of different things.  One difference in software is how close you need to
get to the actual machine.  For some types of software, i.e. device
drivers, it is necessary to be quite close to the real hardware.  This type
of code is generally not very portable.  C allows you to program much of
this code in a high level language, but that still doesn't make it
portable to different hardware situations.  On the other hand, many
applications written in C do not need to concern themselves with the
hardware much at all.  My Little Smalltalk system, for example, is written
entirely in C, and runs on about two dozen different machines with no more
than a few system calls changed here and there (all nicely handled in one
place using #ifdef's).

I expect that the kind of applications that Mike is used to, vidio game
programming, is closer to the device driver style of programming than to
interpreter construction (Little Smalltalk is an interpreter) style of
programming.  Thus I'm not surprized that he wouldn't think C would add
much to portability in this area.  I'm inclined to think that even here it
would help some (with the proper choice of system call interface), but it
certainly isn't going to solve the whole problem.

Mike's second point concerns machine resources.

>Is it worth it for portability to have
>programs that run at half the speed (or less) than the computer is
>capable of (or will it matter if they make computers go fast enough)?
>Or does it make more sense to use a language that fits the architecture
>of the target machine (faster smaller code)?  Is time better spent porting
>code that is not optimized for the target (but works) or is that time better
>spent making a more optimized program for the target?

Any of my former students on the net who have heard me give my ``The
position of Computer Science in the grand scheme of Western Civilization''
lecture will get the feeling they have heard this already.  They are right.
In fact, I probably do a better job in lecture than I can do here. 
(particularly since I'm suffering from a cold right now), Nevertheless:

I think it is frequently the case that computer science students forget why
computer science is important.  Basically stated, there are problems that
need to be solved, and in many cases the solutions to those problems is
greatly facilitated (or even possible at all) only using a computer.  Thus
the computer is merely a tool used for a larger purpose, namely to solve
problems.  The difficulty is that problems arise from situations involving
people.  People tend to view things differently than computers.  In
particular, people usually conceptualize problems, and in as much as we
have any idea HOW people solve problems, they seem to solve problems in a
manner different from that used by computers.
Thus the fundamental problem in computer science (to my mind), is how to
bridge the gap between problem formulation in people-terms, and problem
solution in computer-terms.  In the previously mentioned lecture I usually
go into some detail mentioning how the various fields of computer science
can be viewed in this light, which I won't do here, other than to say that
there are some obvious consequences for programming language design implied
by this attitude.

The most obvious observation is that you can push the language design issue
in the direction of the computer-terms side of the picture, forcing the
user of the language to think more like the computer, or you can push the
language in the direction of the people-terms side (in various different
ways), and leave it to the language implementor, and not the problem solver
to decide how this will eventually get mapped down to the computer level.
Admittedly, in the latter case, various inefficiencies necessarily get
introduced.  But this may be more than offset by the fact that it is easier
to think (and program) in a language closer to the one the problem 
is conceptualized in.  Let me toss in another one of Mikes quotes here:

>I shudder to think of a highly structured 'C' program spending the
>majority of its time pushing and poping registers, passing arguments,
>and returning a whole byte (or word or more) for a true/false condition.
>It seems to me that all this time could be spent running someone else's
>program - allowing more programs to run (and faster).  However, one of
>these days, disk drives will be real fast, and Ram will be real fast,
>and the CPUs will run at gigahertz clock speeds - then who cares (we all
>will even then...).

to which the conventional answer might be ``I shudder to think of all the
brain cell hours that are needlessly wasted pondering poorly structured
programs, tracking down illegal subscript errors or pointers gone wild''
APL programmers (a strange breed of their own) have been telling us for
years that the most important measure is the time between a problem
definition and the problem solution, and if by using a high level language
this time is cut in half (or less) then who cares if in so doing you use 10
times more machine resources.  It is people time that is important, not
machine time.  Again, there is software and there is software.  My own
personal opinion is that for the VAST majority of what most people program,
the argument that people time is more important is the right one, and the
language should be a very high level language (not even `C', but more
abstract, but that's a different issue altogether that I can lecture on
some day if people want).  I will ALWAYS admit that there is some software
(editors, compilers) for which this isn't true, and for those a language
that permits the generation of more ``efficient'' code is preferable.  Most
people don't write compilers, other than toy ones in college.

Well, I've rambled on more than I should have in my physically (and
mentally, I assume) weakened state.  I close with just one more quote from
Mike:

>I think 'C' is a very good language for the average engineer (most of us
>are average by definition), but is unusable for any application where
>speed and code size are real critical.

I quite agree.  I'm glad most people don't have to program such
applications.

As with mike, let me close with a plea for reasoned discussion, and fewer
death treats.

--tim budd  (mcvax!budd)
assn't prof, dept of computer science, the university of arizona,
on leave at the CWI, amsterdam, the netherlands.