Python from Wise Guy's Viewpoint

[Joachim Durchholz]

Pascal Costanza wrote:

> Ralph Becket wrote:
>> I fail to see how dynamic typing can confer any kind of advantage here.
> 
> Read the literature on XP.

Note that most literature contrasts dynamic typing with the static type 
systems of C++ and/or Java. Good type systems are /far/ better.

>> Are you seriously claiming that concise, *automatically checked* 
>> documentation (which is one function served by explicit type 
>> declarations) is inferior to unchecked, ad hoc commenting?
> 
> I am sorry, but in my book, assertions are automatically checked.

But only at runtime, where a logic flaw may or may not trigger the 
assertion.
(Assertions are still useful: if they are active, they prove that the 
errors checked by them didn't occur in a given program run. This can 
still be useful. But then, production code usually runs with assertion 
checking off - which is exactly the point where knowing that some bug 
occurred would be more important...)

>> For one thing, type declarations *cannot* become out-of-date (as
>> comments can and often do) because a discrepancy between type
>> declaration and definition will be immidiately flagged by the compiler.
> 
> They same holds for assertions as soon as they are run by the test suite.

A test suite can never catch all permutations of data that may occur (on 
a modern processor, you can't even check the increment-by-one operation 
with that, the universe will end before the CPU has counted even half of 
the full range).

>>> + Efficiency: As Paul Graham puts it, efficiency comes from 
>>> profiling. In order to achieve efficiency, you need to identify the 
>>> bottle-necks of your program. No amount of static checks can identify 
>>> bottle-necks, you have to actually run the program to determine them.
>>
>> I don't think you understand much about language implementation.
> 
> 
> ....and I don't think you understand much about dynamic compilation. 
> Have you ever checked some not-so-recent-anymore work about, say, the 
> HotSpot virtual machine?

Well, I did - and the results were, ahem, unimpressive.
Besides, HotSpot is for Java, which is statically typed, so I don't 
really see your point here... unless we're talking about different VMs.

And, yes, VMs got pretty fast these days (and that actually happened 
several years ago).
It's only that compiled languages still have a good speed advantage - 
making a VM fast requires just that extra amount of effort which, when 
invested into a compiler, will make the compiled code still run faster 
than the VM code.
Also, I have seen several cases where VM code just plain sucked 
performance-wise until it was carefully hand-optimized. (A concrete 
example: the all-new, great graphics subsystem for Squeak that could do 
wonders like rendering fonts with all sorts of funky effects, do 3D 
transformations on the fly, and whatnot... I left Squeak before those 
optimizations became mainstream, but I'm pretty sure that Squeak got 
even faster. Yet Squeak is still a bit sluggish... only marginally so, 
and certainly no more sluggish than the bloatware that's around and that 
commercial programmers are forced to write, but efficiency is simply 
more of a concern and a manpower hog than with a compiled language.)

> There are excellent programs out there that have been written with 
> static type systems, and there are also excellent programs out there 
> that have been written without static type systems. This is a clear 
> indication that static type systems are not a necessary condition for 
> writing excellent programs.

Hey, there are also excellent programs written in assembly. By your 
argument, using a higher language is not a necessary condition for 
writing excellent languages.

The question is: what effort goes into an excellent program? Is static 
typing a help or a hindrance?

One thing I do accept: that non-inferring static type systems like those 
of C++ and Java are a PITA. Changing a type in some interface tends to 
cost a day or more, chasing all the consequences in callers, subclasses, 
and whatnot, and I don't need that (though it does tell me all the 
places where I should take a look to check if the change didn't break 
anything, so this isn't entirely wasted time).
I'm still unconvinced that an inferring type system is worse than 
run-time type checking. (Except for that "dynamic metaprogramming" thing 
I'd like to know more about. In my book, things that are overly powerful 
are also overly uncontrollable, but that may be an exception.)

Regards,
Jo