Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!ut-sally!utah-cs!shebs
From: shebs@utah-cs.UUCP
Newsgroups: comp.edu,comp.lang.misc
Subject: Re: Teaching Assembler
Message-ID: <4625@utah-cs.UUCP>
Date: Thu, 4-Jun-87 09:59:48 EDT
Article-I.D.: utah-cs.4625
Posted: Thu Jun  4 09:59:48 1987
Date-Received: Sat, 6-Jun-87 07:36:31 EDT
References: <7401@boring.cwi.nl> <2046@a.cs.okstate.edu> <1748@megaron.arizona.edu>
Reply-To: shebs@utah-cs.UUCP (Stanley Shebs)
Organization: PASS Research Group
Lines: 42
Xref: utgpu comp.edu:377 comp.lang.misc:421

In article <1748@megaron.arizona.edu> debray@arizona.edu (Saumya Debray) writes:

>I'm astounded at the number of CS (graduate!) students who're so hidebound
>by their BASIC heritage that they can't write a recursive program to save
>their lives, and who're so conditioned to think in terms of destructive
>assignment that any mention of declarative or applicative programming only
>evokes slack-jawed stares.  I find this frustrating at best, terrifying at
>worst.

I agree, but with the qualification that the folks working in the various
styles of declarative programming have spent so much time pontificating on
the advantages of that style that multi-order-of-magnitude slowdowns are
usually ignored (Your work is the exception not the rule, Saumya!) and "large
programs" may be all of two pages.  Utah teaches functional programming
with Lisp, Scheme, and Miranda in several undergrad courses, but nevertheless
all we seem to produce are C hackers.  Hardly surprising, since the students
write fibonacci and merge sorts in functional languages then wait minutes
for results, then go to the C hacking classes and write graphical editors,
spreadsheets, and so forth, all of which are very speedy.  I think the
students don't have any trouble drawing conclusions from the side-by-side
comparison of elegant/useless with fast/useful...

Of course, this isn't inherent in declarative languages, it's more that
the surrounding culture offers no rewards for implementors doing mundane
things like putting in the ability to call curses or X, and compiling
to efficient native code.  Too bad...

>I think a more productive approach would be to (a) spend more time
>designing the algorithms and data structures (a bubble sort, even if
>microcoded, can only do so well!); (b) code the program in a high level
>language to reduce the development time; and (c) use the time you've
>managed to save in this way to profiling your program and recoding hot
>spots in assembler if necessary.

Amen, but I don't recall many high-level language (Lisp, Prolog, Lucid,
etc) implementations that even *allow* the calling of assembly language
routines!  (Too "impure" I suppose)

>Saumya Debray		CS Department, University of Arizona, Tucson

							stan shebs
							shebs@cs.utah.edu