Python from Wise Guy's Viewpoint

[Pascal Costanza]

Ralph Becket wrote:
> Pascal Costanza <costanza at web.de> wrote in message news:<bn86o9$gfh$1 at newsreader2.netcologne.de>...
> 
>>Ralph Becket wrote:
>>
>>>This is utterly bogus.  If you write unit tests beforehand, you are 
>>>already pre-specifying the interface that the code to be tested will 
>>>present.
>>>
>>>I fail to see how dynamic typing can confer any kind of advantage here.
>>
>>Read the literature on XP.
> 
> What, all of it?
> 
> Why not just enlighten me as to the error you see in my contention 
> about writing unit tests beforehand?

Maybe we are talking at cross-purposes here. I didn't know about ocaml 
not requiring target code to be present in order to have a test suite 
acceptable by the compiler. I will need to take a closer look at this.

>>>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.
> 
> That is not true unless your test suite is bit-wise exhaustive.

Assertions cannot become out-of-date. If an assertion doesn't hold 
anymore, it will be flagged by the test suite.

>>>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?
> 
> Feedback directed optimisation and dynamic FDO (if that is what you
> are suggesting is an advantage of HotSpot) are an implementation
> techonology and hence orthogonal to the language being compiled.
> 
> On the other hand, if you are not referring to FDO, it's not clear
> to me what relevance HotSpot has to the point under discussion.

Maybe we both understand language implementation, and it is irrelevant?

>>>A strong, expressive, static type system provides for optimisations
>>>that cannot be done any other way.  These optimizations alone can be
>>>expected to make a program several times faster.  For example:
>>
>>You are only talking about micro-efficiency here. I don't care about 
>>that, my machine is fast enough for a decent dynamically typed language.
> 
> Speedups (and resource consumption reduction in general) by (in many 
> cases) a factor or two or more consitute "micro-efficiency"?

Yes. Since this kind of efficiency is just one of many factors when 
developing software, it might not be the most important one and might be 
outweighed by advantages a certain loss of efficiency buys you elsewhere.

> The difference between an untyped program that doesn't work (it produces
> the wrong answer) and a dynamically typed program with a type bug (it
> may throw an exception) is so marginal that I'm tempted to lump them both
> in the same boat.

Well, but that's a wrong perspective. The one that throws an exception 
can be corrected and then continued exactly at the point of the 
execution path when the exception was thrown.

>>[...]
>>The burden of proof is on the one who proposes a solution.
> 
> What?  You're the one claiming that productivity (presumably in the 
> sense of leading to a working, efficient, reliable, maintainable 
> piece of code) is enhanced by using languages that *do not tell you 
> at compile time when you've made a mistake*!

No, other people are claiming that one should _always_ use static type 
sytems, and my claim is that there are situations in which a dynamic 
type system is better.

If you claim that something (anything) is _always_ better, you better 
have a convincing argument that _always_ holds.

I have never claimed that dynamic type systems are _always_ better.

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)