Python from Wise Guy's Viewpoint

[Pascal Costanza]

Fergus Henderson wrote:
> Pascal Costanza <costanza at web.de> writes:

>>DEFUN is just one example. What about DEFTYPE, DEFCLASS, DEFPACKAGE, and 
>>so forth...
> 
> Well, DEFTYPE in lisp really just defines a function, doesn't it?
> So that's not much different than DEFUN.  Likewise, DEFCLASS just
> defines a collection of functions, doesn't it?  OK, maybe these
> also record some extra information in some global symbol tables.
> That is easily emulated if you really want.
> 
> I don't know exactly what DEFPACKAGE does, but if the others are any
> guide, it's probably not too hard either.

I am not sure if I understand you correctly, but are you actually 
suggesting that it is better to reimplement Common Lisp on your own than 
to just use one of the various Common Lisp implementations?

All I am trying to get across is that, in case you need the flexibility 
a dynamic language provides by default, and only occasionally need to 
restrict that flexibility, it's better to use a dynamic language from 
the outset. The price to pay is that you cannot make use of a 100% 
strict static type system anymore, but on the other hand you can pick 
one of the stable Common Lisp implementations with language features 
that have proven to work well during the past few decades.

Sure, if you don't need the flexibility of a dynamic language then you 
can think about using a static language that might buy you some 
advantages wrt to static checkability. But I highly doubt that this is a 
rational choice because I don't know any empirical studies that show 
that the problems that static languages intend to solve are in fact 
problems that occur in practice.

Let's inspect the list of those problems again:

a) performance

Good Lisp/Scheme implementations don't have problems in this regard.

b) documentation

Documentation can be handled well with comments and well-chosen names.

c) absence of a certain class of bugs

It's not clear whether this class of bugs really occurs in practice. 
There are also indications that these relatively trivial bugs are also 
covered by test suites as soon as they consist of a reasonable number of 
test cases.

d) unbreakable abstraction boundaries

Such boundaries seem to be as tedious to implement in dynamic languages, 
as is the case for dynamic features in static languages.

My conclusions would be as follows:

a) and b) are relatively uninteresting. c) needs convincing studies from 
the proponents of static type systems. As long as they don't provide 
them, it's just guesswork that these bugs are really important.

d) is the hard part. Proponents of static languages say that it's 
important to be able to express such boundaries because it increases 
their expressive power. (That's one thing I have learned from this 
discussion: It is arguable that this can also be an important kind of 
expressive power.) Proponents of dynamic languages say that it's more 
important to be able to work around restrictions, no matter whether they 
are intentional or not; it's better not to be able to paint yourself 
into a corner.

With regard to d, both "groups" don't have enough objective empirical 
evidence beyond their own subjective experiences. Static programmers 
don't have enough objective empirical evidence that their languages 
objectively increase the quality of their software, and dynamic 
programmers don't have enough objective empirical evidence that painting 
oneself into corners is a problem that occurs regularly.

So both views essentially boil down to be no more than subjective belief 
systems. And IMHO that's not so far from the "truth": I am convinced 
that these issues depend mostly on personal programming style and 
preferences and not so much on technological issues. Software quality is 
a social construct, and social problems can hardly be solved with 
technical means. If you have a bunch of good programmers and let them 
choose their preferred tools, it's more likely that they produce good 
software than when you have a bunch of average programmers and tell them 
what tools they must use.

(It's very important in this regard that we are not talking about 
braindead languages. There are both extremely stupid as well as 
excellent exemplars of static and dynamic languages.)


Pascal

-- 
Pascal Costanza               University of Bonn
mailto:costanza at web.de        Institute of Computer Science III
http://www.pascalcostanza.de  Römerstr. 164, D-53117 Bonn (Germany)