Interesting People mailing list archives

Teaching programming concepts from info-dylan and a UPenn Prof


From: David Farber <farber () central cis upenn edu>
Date: Fri, 20 Aug 1993 22:12:47 -0500



From: qobi () kappa cis upenn edu (Jeffrey Mark Siskind)
Re: Sudden interest in Dylan/Dylan should be open.

   But being pessimistic/realistic
   as I am, I see no (absolutely **no**) chance for Dylan in the mainstream.
   It remains to be see how many programmers can be converted from
   C/Pascal/C++. And this is most of the time not a question of
   the individual programmer, but this is decided by management.

I agree that however unfortunate, Dylan (or Lisp or Scheme or Prolog or SML
or ...) has a slim chance of success in the mainstream market. Part of the
problem is run-time compiled-code efficiency. The Dylan effort is address that
very well. But an even bigger part of the problem is the momentum of the
marketplace and the education of programmers (more general than what you
called management). Most programmers are incredibly unsophisticated. They have
no notion of abstraction. No notion of a function which transforms one
representation into another. No notion of operators which combine
transformations. They write programs that move single values around in memory.
C++ is little more than glorfied assembler the way most people use it. Look at
real programmers out there and the code they write. Count the percentage of
lines of C++ programs that are assignment statements that move non-agregate
data. I don't mean to insult any person on this list. There are clearly many
good programmers out there who program and design algorithms at a much higher
level. (I bet there is a high correlation between the set of such people and
the set of readers of this list.) This can be done is Dylan, Scheme, Prolog,
Lisp, SML, Haskell, or C/C++ for that matter. We all believe that things in
OODLs and function languages make this more conducive than in C/C++, which is
why people are trying promote Dylan. But I guess that if you gave Dylan to the
vast majority of current programsers, they would use it like the way they used
 C++, which is in turn the way they used C, which is in turn the way they used
BASIC, ...

Let me give you an example. There is a grad student who recently showed me
some `nice OBJECT ORIENTED C++ code' she had written. Every, and I mean every,
procedure returned an error code. She claimed that she was familiar with
`professional industrial programming practise' had been taught that that was
the way to make robust code. That meant that she couldn't write a FUNCTION.
Every procedure had to return its results by side effecting either an argument
or a global data structure. (Not that that is bad, there are times whent that
is appropriate.) But with here style she couldn't combine functions, think
about the process of data manipulation here program was doing, or abstract
control structures. It turned out that the hundreds of lines of beautifull
object oriented C++ code that she had written, spread across a dozen files
repleat with #include headers, private protocol definitions and all the rest
WAS ALGORITHMICALLY NOTHING MORE THAN A *SINGLE* TABLE LOOKUP. The honest
truth: one line of properly written code in almost any language.

Now she is getting her PhD in computer science.

This is not an isolated example. I taught graduate AI here at UPenn last fall.
When I teach I use an extension of CommonLisp that I've written called
Screamer which adds backtracking and constraint satisfaction. The nice thing
about this is that it allows separating the search strategy from the
specification of the search space. I spent a good part of the semester showing
how many of the classic AI programs can be reformulated and solved in short
easily understood Screamer programs. I also show how much of the progress in
AI can be formulated as simple transformations on these programs. Things like
memoization, partial evaluation, lifting, partial-order vs. total order,
changes in evaluation order. I can show how the differences between many
parsing algorithms and grammer formalisms (like Early, CKY, Tomita, DCG, ATN)
can be expressed as small changes, often a single line or even A SINGLE WORD
change to a properly written program. How you can turn a parser into a model
of language acquition by a lifting transformation combined with a change of
search order. How you can perform the model-feature-point matching of model
based vision using the same constraint satisfaction techniques (and even code)
as nonlinear-planning.

With all of this I had to teach good programming style to many grad students
who had never learned Lisp. Moreover, most had never even learned how to
program recursively. Recursion, or structural induction forms the basis of
most of the logical foundation of AI and computer science. And I had to teach
this to grad students.

Towards the end of the course, several of the students commented to me that
they were getting into trouble because they were trying to solve their problem
sets and term projects in their operating systems course using the programming
style (and most of thaught) I had taught them. Their professor was criticizing
them. Some thought that they were `tainted' by having taken my course. I
simply smiled an felt successful in having made my modest conribution to their
education.

The biggest problem as I see it is in education. Sussman and Ableson tried to
change that with 6.001. Teach undergrads from the start how to *THINK* in high
level yet precise terms and bridge the gap via abstraction. But unfortunately
that has not caught on very much in the mainstream. Most universities have
given up or are giving up on teaching 6.001 derivatives. I personally have
experienced such debates at Berkeley, UPenn, Harvey Mudd. A big part of the
problem is that even most university professors of computer science lack
sophistication in their programming accumen. They aren't even aware of what
their missing. I've heard many famous professors vehemently argue for the
virtues of teaching C as the first programming language and how C is inherently
based on optimal design decisions, or how students don't need to know anything
that is taught is 6.001, or how a C-based course prepares the students better
for all subsequent non-AI courses in the curriculum and that only AI students
need to learn Lisp/Scheme. These are prominent professors in world-class
institutions saying this. It takes years, perhaps several academic
generations, to completely retrain professors to retrain their students in how
to think and program before Dylan will catch on.
        Jeff


Current thread: