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:
- Teaching programming concepts from info-dylan and a UPenn Prof David Farber (Aug 20)