[Prev][Next][Index][Thread]
Re: SICP & the Dumbing Down of American Comp Sci
-
Subject: Re: SICP & the Dumbing Down of American Comp Sci
-
From: Joe Davison <joda@interaccess.com>
-
Date: Sat, 16 Oct 1999 19:15:02 -0400 (EDT)
-
Organization: Dis
-
References: <7sp42b$71a$1@nnrp1.deja.com> <7t256r$ik7$2@beta.qmw.ac.uk> <37F4DEF8.A4FBB49D@acm.org> <Pine.LNX.3.96.991001182426.1056I-100000@punaluu.informatik.uni-freiburg.de> <7tg1qu$49c@bobs.unbc.ca>
-
Reply-To: joda@interaccess.com
-
Xref: grapevine.lcs.mit.edu comp.lang.functional:15545 comp.lang.dylan:10988
David Casperson wrote:
>
> It is my opinion that the value of OOP in SE is related to the issue of
> maintenance. If you model classes after real world constructs, then
> even if there are changes in what is required of the software, your
> model ought to be able to cope with the changes. Or, in other words,
> people can change the requirement specs on you, but they can't change
> the real world on you. (Of course this is a generalization)
>
> I think that it is worth stressing over and over again to students that
> good code isn't code that is easily written, but code that is easily
> maintained.
>
While I strongly agree with your sentiments, I'd phrase it slightly
differently. It's not "maintenance", it's "evolution".
The fact is that any program useful enough to last beyond the end
of the course is going to need to evolve to fit new situations.
I speak from experience; I've been working on switching software
and software tools for Lucent Technologies for over 20 years. I
came to Bell Labs in 1976 fresh out of graduate school (Johns Hopkins)
and became part of the team working on 1ESS (Electronic Switching System)
a big (by then standards) program (800K of assembler) that served
in large city switches. It had first gone to the field in 1965, and
by the time I got there telephony had changed significantly. The program
ran faster and had much more functionality than when it started.
There are a number of large software systems, and it's basically
not possible to develop them and forget them -- They must be designed
as evolving software systems.
Today we're looking at distributed object systems to build such systems,
but the basic nature hasn't changed -- they still need to evolve.
Did your students ever hear of an "upgrade" for a software program?
It is almost certain that most of them will spend most of their
careers evolving existing software systems -- even if they design
and develop the initial version themselves.
joe