Python from Wise Guy's Viewpoint

Ralph Becket rafe at cs.mu.oz.au
Thu Oct 23 04:39:04 EDT 2003


Pascal Costanza <costanza at web.de> wrote in message news:<bn7a3p$1h6$1 at newsreader2.netcologne.de>...
> 
> + Design process: There are clear indications that processes like 
> extreme programming work better than processes that require some kind of 
> specification stage. Dynamic typing works better with XP than static 
> typing because with dynamic typing you can write unit tests without 
> having the need to immediately write appropriate target code.

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.

> + Documentation: Comments are usually better for handling documentation. 
> ;) If you want your "comments" checked, you can add assertions.

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?

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.

> + Error checking: I can only guess what you mean by this. If you mean 
> something like Java's checked exceptions, there are clear signs that 
> this is a very bad feature.

I think Fergus was referring to static error checking, but (and forgive 
me if I'm wrong here) that's a feature you seem to insist has little or
no practical value - indeed, you seem to claim it is even an impediment
to productive programming.  I'll leave this point as one of violent 
disagreement...

> + 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.
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:
- no run-time type checks need be performed;
- data representation is automatically optimised by the compiler 
  (e.g. by pointer tagging);
- polymorphic code can be inlined and/or specialised according to each
  application;
- if the language does not support dynamic typing then values need not
  carry their own type identifiers around with them, thereby saving 
  space;
- if the language does support explicit dynamic typing, then only 
  those places using that facility need plumb in the type identifiers 
  (something done automatically by the compiler.)

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.

> I wouldn't count the use of java.lang.Object as a case of dynamic 
> typing. You need to explicitly cast objects of this type to some class 
> in order to make useful method calls. You only do this to satisfy the 
> static type system. (BTW, this is one of the sources for potential bugs 
> that you don't have in a decent dynamically typed language.)

No!  A thousand times, no!

Let me put it like this.  Say I have a statically, expressively, strongly 
typed language L.  And I have another language L' that is identical to
L except it lacks the type system.  Now, any program in L that has the
type declarations removed is also a program in L'.  The difference is
that a program P rejected by the compiler for L can be converted to a
program P' in L' which *may even appear to run fine for most cases*.  
However, and this is the really important point, P' is *still* a 
*broken* program.  Simply ignoring the type problems does not make 
them go away: P' still contains all the bugs that program P did.

> > Soft typing systems give you dynamic typing unless you explicitly ask
> > for static typing.  That is the wrong default, IMHO.  It works much
> > better to add dynamic typing to a statically typed language than the
> > other way around.
> 
> I don't think so.

Yes, but your arguments are unconvincing.  I should point out that 
most of the people on comp.lang.functional (a) probably used weakly/
dynamically typed languages for many years, and at an expert level,
before discovering statically typed (declarative) programming and 
(b) probably still do use such languages on a regular basis.  
Expressive, static typing is not a message shouted from ivory towers 
by people lacking real-world experience.

Why not make the argument more concrete?  Present a problem 
specification for an every-day programming task that you think 
seriously benefits from dynamic typing.  Then we can discuss the 
pros and cons of different approaches.

-- Ralph




More information about the Python-list mailing list