Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rutgers!att!dptg!pegasus!psrc
From: psrc@pegasus.ATT.COM (Paul S. R. Chisholm)
Newsgroups: comp.software-eng
Subject: Re: Theory vs. Practice in CS Education
Summary: compiler messages in CS course
Message-ID: <4251@pegasus.ATT.COM>
Date: 15 Nov 89 15:01:29 GMT
References: <880@dms.UUCP> <7044@hubcap.clemson.edu>
Organization: AT&T Bell Laboratories
Lines: 40

What good are compiler courses?  Well, when writing code I want to run
fast, I always feel more comfortable when I know more or less what the
compiler is going to turn my code *into*; and the only way I can do
that is at least read about compiler implementation techniques.

From albaugh@dms.UUCP (Mike Albaugh):
> having written a "toy" compiler is a godsend when attempting to unravel
> the obscure error messages from other "state of the art" compilers.

In article <7044@hubcap.clemson.edu>,
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
(William Thomas Wolfe, 2847) writes:
> Then it's obviously high time that the market started to demand
> better error messages.  Users should not have to understand the
> internals of a product in order to make use of it.

The dreaded, justifiably famous CS 701/702/703 compiler course at the
University of Wisconsin at Madison had a project to implement a language
with a large subset of Ada's features.  I pulled my grade up from a
high B to a low AB by rewriting all of my error messages to be more
readable.  Is that the right kind of training a grade student should
get?  Better believe it!

Most people worked in pairs, and you had to build on your earlier
work, so it was a good de facto course in software maintenance as
well.  The UW-Madcity "systems programming" curriculum strongly
emphasized lots of non-trivial programming, though when I was there
(1979-1981), there wasn't a "software engineering" course per se.

A cute anecdote to finish with:  Near the end of semester, we were told
to turn in some sort of internal documentation on how our compilers
worked, suitable for turning over to a maintenance programmer.  Someone
suggested, "Should we write a flowchart?"  The entire class burst out
laughing.

>     Bill Wolfe, wtwolfe@hubcap.clemson.edu

Paul S. R. Chisholm, AT&T Bell Laboratories
att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.