"Terry Reedy" <[EMAIL PROTECTED]> writes: > Nonetheless, picking on and characterizing Tim's statement as > anti-flexibility and un-scientific is to me writing of a sort that I > would not tolerate from my middle-school child.
Now it is you who are taking Sussman's comments out of context. Sussman does not claim that Python is "un-scientific" -- he merely holds it up as a example of canonical engineering that eschews the kinds of flexibility that is to be found in biological systems and in the practice of science. In this regard, Sussman is merely criticizing engineering "best practices" in general, not Python in specific, and is arguing that if we want to engineer systems that are as robust as biological systems then we need to start exploring radically different approaches to software design. > Python is an algorithm language and a tool used to engineering > information systems, which is something different. The next > sections are about exploratory behavior. Languages do not 'behave', > let alone 'explore'. I think you are missing the point. Sussman is making a broad criticism of software engineering in general, as it is understood today. The essay in questions was written for a graduate-level MIT computer science class that aims to explore potential avenues of research into new languages and approaches that encourage and facilitate more robust software systems. As good as Python is, it is still largely an encapsulation of the best ideas about software engineering as it was understood in the early 80's. We're now 20+ years on, and it behooves our future Computer Science researchers to consider if we might not be able to do better than we could in 1984. > So Python seems to have the sort of flexibility that he implicitly > claims it does not. Python most certainly does *not* have the type of flexibility that he is talking about. For instance, one of the things that he talks about exploring for more robust software systems is predicate dispatching, which is an extension of multiple dispatch. Although you might be able to cobble something like this together in Python, it would end up being very cumbersome to use. (E.g., Guido wrote an essay on doing multiple dispatch in Python, but you wouldn't actually want to write Python code that way, because it would be too syntactically cumbersome.) In dialects of Lisp (such as Scheme), however, subsystems to explore such alternative programming models can be written completely within the language (due, in part to their syntax extension facilities). This is how the Common Lisp Object System came to be, for instance. CLOS supports all sorts of OO stuff that even Python doesn't, and yet Lisp without CLOS isn't even an OO language. > The general problems of software inflexibility that he mentioned in > a previous section have nothing specific to do with Python. Right. And he never said they did. > When he gets to solutions, one long section (page 13) somewhat > specific to languages, versus applications thereof, is about > extensible generic operations "where it is possible to define what > is meant by addition, multiplication, etc., for new datatypes > unimagined by the language designer." Well, golly gee. Guess what? > Not only is Python code generic unless specialized (with isinstance > tests, for instance), but it is highly extensible for new datatypes, > just as Sussman advocates. There is a special method for just about > every syntactic construct and builtin function. And 3.0 may add a > new generic function module to dispatch on multiple arguments and > possibly predicates. You didn't read the paper very carefully. Sussman points out that traditional OO languages are up to this sort of stuff to some extent, but not to the extent which he thinks is required to solve future challenges. He things, for instance, that predicate dispatching, backtracking, and first-class continuations will be required. |>oug -- http://mail.python.org/mailman/listinfo/python-list
