Python from Wise Guy's Viewpoint

[Pascal Costanza]

Joachim Durchholz wrote:
> 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.

You are changing topics here.

In a statically typed language, when I write a test case that calls a 
specific method, I need to write at least one class that implements at 
least that method, otherwise the code won't compile.

In a dynamically typed language I can concentrate on writing the test 
cases first and don't need to write dummy code to make some arbitrary 
static checker happy.

>>> 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.

I don't care about that difference. My development environment is 
flexible enough to make execution of test suites a breeze. I don't need 
a separate compilation and linking stage to make this work.

> (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...)

Don't let your production code run with assertion checking off then.

>>> 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).

I hear that in the worst case scenarios, static type checking in modern 
type systems needs exponential time, but for most practical cases this 
doesn't matter. Maybe it also doesn't matter for most practical cases 
that you can't check all permutations of data in a test suite.

>>>> + 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.

The results that are reported in the papers I have read are very 
impressive. Can you give me the references to the papers you have read?

> 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.

Oh, so you haven't read the literature? And above you said you did.

Well, the research that ultimately lead to the HotSpot Virtual Machine 
originated in virtual machines for Smalltalk and for Self. Especially 
Self is an "extremely" dynamic language, but they still managed to make 
it execute reasonably fast.

When all you wanted to say is that Java is not fast, that's not quite 
true. The showstopper for Java is the Swing library. Java itself is very 
fast.

In certain cases it's even faster than C++ because the HotSpot VM can 
make optimizations that a static compiler cannot make. (For example, 
inline virtual methods that are known not to be overridden in currently 
loaded classes.)

> 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.)

I know sluggish software written in statically typed languages.

>> 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.

Right.

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

Right, that's the question.

> 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.)

Check the literature about metaobject protocols.


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)