[765] in Depressing_Thoughts
Re: classes at the 'tute
rlk@ATHENA.MIT.EDU (rlk@ATHENA.MIT.EDU)
Sat Mar 4 17:40:28 1989
OK, as someone now in industry, let me throw in my own two cents.
Jik, you're right that a lot of the CS curriculum here is very theoretical.
And even though you don't state it explicitly, there's a lot that you do
need to know that isn't taught. A lot of this is what I call
'engineering'. By that I mean the ability to take the abstract concepts
that you learn very well here and apply them to real problems. 6.170, by
the way, is no exception; it teaches you a lot of engineering theory for
one definition (Liskov's et al.), but it doesn't teach you about the sort
of compromises that have to be made on any real project (e. g. the CLU
compiler compiled itself, but only when the strict type checking was
turned off). There is not a single required class that teaches you how
to debug anything (software, hardware, mechanical, whatever; in my
experience my method of attack on a hardware problem isn't much different
from how I go about debugging a code error; in fact it's not always clear
what is what in the particular work I do). There are, however, a lot of
classes that teach formal automata theory, algorithm theory, and the like.
It's true that I have yet to find a use for automata theory.
That said, let me point out that there is a flip side to all this. A lot
of even the most arcane theory pops up where you don't expect it. For
example, fast searching algorithms and expression matching techniques
are based on automata theory. And some knowledge of algorithm analysis
can make it easier to determine the optimal algorithm for a problem, o
or eliminate a poor one (although I wish 6.046 would go into the practical
aspects of algorithm evaluation, such as the fact that large constant
factors, or even constant overheads, can be very important depending
upon the application (asymptotic running times are not the Meaning of Life).
6.170 is very important material, although it's presented in a somewhat
overwhelming fashion (and the tests are pure bullshit; they only test
theory; the broad point that organization is needed on large projects is
often missed by people new in the field. My experience with GNU Emacs
is that RMS understands this point very well, despite his reputation as
a pure hacker; the FSF is a lot better organized to handle medium to
large projects than it was 3 years ago or so. As for 18.06, most
mathematical and scientific programming (and a lot of commercial software)
is just linear algebra.
Don't knock 6.002 and 6.003, by the way; it's the basis of what computers
are made of, even if you don't wind up using it later on.
One class I would suggest every aspiring engineer take is 6.033
(Computer System Engineering). Despite its reputation as the Course 6
HUM-D, it really is about engineering -- analysis and solution of
problems. I see lots of people around who can hack circles around me,
or who know lots more algorithms than I do, but who can't put
together a program to meet a customer's needs. The computer industry
needs all sorts of people, and based on my somewhat limited experience
(as a watchmaker, and now an engineer in a rather theoretical group in
a rather academic-oriented company), there are precious few people with
broad-based knowledge.
