Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: HLL on 65816
Message-ID: <1991Jan7.062538.23401@nntp-server.caltech.edu>
Date: 7 Jan 91 06:25:38 GMT
References: <1673@madnix.UUCP>
Organization: California Institute of Technology, Pasadena
Lines: 42

rat@madnix.UUCP (David Douthitt) writes:

>| >Given how universities are pushing "modular" code these days, and the
>| >amount of people writing *tiny* subroutines
 
>| That's really sad. Has everybody forgotten the original reasons for inline()
>| and parametric defines? They can't be THAT anal retentive about modularity.

>Please explain further what you mean here - WITHOUT getting salty.

What I am talking about is that subroutine overhead and dealing with it when
it's large is an old problem in computer science. I simply can't believe that
colleges today are actually training people to modularize their code to death
without also explaining performance considerations and how they can be dealt
with: inline specifiers, which generate explicit code from functions; and
parametric defines, which generate explicit code via macro replacement.

>Have you ever see a FORTH programmer's C code?  Subroutines everywhere.
>Personally, I don't see how that is so bad - except that C function calls
>might have abominable execution time overhead.  Tsk tsk - shoulda used
>FORTH :-)

You're right -- shoulda used FORTH, if that's what you know. Such a person is
still programming in FORTH most of the time but is mentally translating from
FORTH semantics to C. When I first got started in Pascal (a short and very
discouraging experience) I tried to keep programming as if I were using Basic.
Needless to say, nothing worked. I turned to assembly; soon I found that
projects of any reasonable size required modular organization just so I could
keep track of them. By the time I decided to learn C, I welcomed the idea of an
efficient language with the minimum amount of pascal-style progam block
structure (necessary for manageable programs) and the semantics (often more
compactly expressed) of both assembly and basic -- when each was appropriate.
The ANSI changes (especially prototyping) deal with nearly everything I could
have wanted changed in C.

The structure of a programming language cannot help but dictate to some extent
the programming styles which will tend to produce efficient/coherent/correct
results in that language. I just can't see a CS curriculum that doesn't at
least address the question of 'which language for the job?'.

Todd Whitesel
toddpw @ tybalt.caltech.edu