Python from Wise Guy's Viewpoint

[Pascal Costanza]

Ralph Becket wrote:

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

Read the literature on XP.

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

I am sorry, but in my book, assertions are automatically checked.

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

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

It has value for certain cases, but not in general.

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

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

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.

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

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

You are making several mistakes here. I don't argue for languages that 
don't have a type system, I argue for languages that are dynamically 
typed. We are not debating strong typing.

Furthermore, a program P that is rejected by L is not necessarily broken.

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

Weak and dynamic typing is not the same thing.

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

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.

Otherwise I could come up with some other arbitrary restriction and 
claim that it is a general solution for writing better programs, and ask 
you to give counter-examples as well. This is not a reasonable approach 
IMHO.

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.

Furthermore, there are crap programs out there that have been written 
with static type systems, so a static type system is also not a 
sufficient condition for writing good software.

The burden of proof is on the one who proposes a solution.


Pascal