Who's minister of propaganda this week?

[Steven D. Majewski]

On Wed, 14 Mar 2001, Nicola Musatti wrote:
> 
> But those things that the compiler used to check for you may well have
> become new tests for you to write: if the trade-off between the decrease
> in actual code size and the increase in test number is negative, even
> the better support for refactoring turns out to be an illusion. 

What sort of tests are you expecting to have to do ? 

 In a dynamically typed, polymorphic language (like Python,Lisp,Scheme...)
the language runtime does the type checking for you and in a object
oriented language, dispatching takes the place of most other type 
conditionals. 

( OK: not having multiple dispatch in Python means that some manual
dispatching is sometimes required, but usually this is burried deep
in some classes __coerce__ method. ) 

 If think you're expecting a file, what you are probably *really* 
expecting is a file-like object with a read or write method. Testing
if it is in fact a file is probably the wrong thing to do. ( This
has been termed "pedantic typechecking" in c.l.python ). If you try
to write to something that is non-writable, the runtime will signal
an error.  If you want a function that can take, for example, either
a filename or a file-like-object ( file, pipe, stringIO, socket, etc.)
then you need to distinguish between string-like and file-like args.
Probably the best method is to test getattr( obj, "write" ) [or "read"].

> >   Expressiveness ... is a far better aid to
> >   correctness ...
> 
> Here I'm puzzled, but maybe it's only a "language" problem. What do you
> mean by "Expressiveness"? I ask because until now I thought
> expressiveness was an advantage of strongly typed languages (namely,
> C++) over typeless ones.

You can read:
"On the Expressive Power of Programming Languages" by Matthias Felleisen
<http://citeseer.nj.nec.com/felleisen90expressive.html>
if you want a formal definition. 

I don't think static typing has much difference in expressiveness
one way or another. Polymorphism -- in either it's static or dynamic
variants is, I think, a plus. Otherwise, type annotation of any style
increases redundancy (this is good from a software engineering POV)
and verbosity, and thus reduce your expressiveness/verbosity ratio.


One terminological dispute (which has been endlessly debated on 
comp.lang.*, but may be an important distinction that is causing
some of your confusion. ):

 C++ is not usually considered "strongly typed" 

 There are two axis: 
   static vs. dynamic typing, and string vs. weak typing. 

    C++ is statically, but not strongly typed (certainly
     not compared to Haskell or ML) 

    Python, Lisp and Scheme are dynamically typed. 
      (Comparing whether one has a stronger type system than
       the other is probably beyond me(*), but by some definitions
       they are all considered to be "stronger" than C/C++ . ) 


-- Steve Majewski <sdm7g at Virginia.EDU> 

[(*) I think there's some argument to be made, especially in the
 light of a lot of c.l.python discussion about rationals, integer
 division, long int extensions, etc. that Python's numeric type
 system is, in some sense, weaker than Scheme's. But I don't have
 time to properly make that argument, so you can just take it as
 opinion. And mostly everyone seems to want to fix python to be
 "stronger" if it can be done without too much expense in processor
 time or code-breakage. ]