Python from Wise Guy's Viewpoint

[Ralph Becket]

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?

> > 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* they are not required.
*And* if they are present, they can only flag a problem at runtime.
*And* then at only a single site.

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

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

> > 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"?

> > On top of all that, you can still run your code through the profiler, 
> > although the need for hand-tuned optimization (and consequent code
> > obfuscation) may be completely obviated by the speed advantage 
> > conferred by the compiler exploiting a statically checked type system.
> 
> Have you checked this?

Do you mean have I used a profiler to search for bottlenecks in programs
in a statically type checked language?  Then the answer is yes.

Or do you mean have I observed a significant speedup when porting from
C# or Python to Mercury?  Again the answer is yes.

> Weak and dynamic typing is not the same thing.

Let us try to draw some lines and see if we can agree on *something*.

UNTYPED: values in the language are just bit patterns and all
operations, primitive or otherwise, simply twiddle the bits
that come their way.

DYNAMICALLY TYPED: values in the language carry type identifiers, but
any value can be passed to any function.  Some built-in functions will
raise an exception if the type identifiers attached to their arguments 
are of the wrong sort.  Such errors can only be identified at runtime.

STATICALLY TYPED: the compiler carries out a proof that no value of the
wrong type will ever be passed to a function expecting a different type,
anywhere in the program.  (Note that with the addition of a universal
type and a checked runtime dynamic cast operator, one can add dynamically
typed facilities to a statically typed language.)

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.

> No. The original question asked in this thread was along the lines of 
> why abandon static type systems and why not use them always. I don't 
> need to convince you that a proposed general solution doesn't always 
> work, you have to convince me that it always works.

Done: just add a universal type.  See Mercury for example.

> [...]
> 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*!

-- Ralph