On 2006-06-16 17:59:07 -0400, Joachim Durchholz <[EMAIL PROTECTED]> said:
> I think it's easier to start with a good (!) statically-typed language > and relax the checking, than to start with a dynamically-typed one and > add static checks. > With the right restrictions, a language can make all kinds of strong > guarantees, and it can make it easy to construct software where static > guarantees abound. If the mechanisms are cleverly chosen, they > interfere just minimally with the programming process. (A classical > example it Hindley-Milner type inference systems. Typical reports from > languages with HM systems say that you can have it verify thousand-line > programs without a single type annotation in the code. That's actually > far better than you'd need - you'd *want* to document the types at > least on the major internal interfaces after all *grin*.) > With a dynamically-typed language, programming style tends to evolve in > directions that make it harder to give static guarantees. This is purely a matter of programming style. For explorative programming it is easier to start with dynamic typing and add static guarantees later rather than having to make decisions about representation and have stubs for everything right from the start. The lisp programming style is arguably all about using heterogenous lists and forward references in the repl for everything until you know what it is that you are doing, then choosing a more appropriate representation and filling in forward references once the program gels. Having to choose representation right from the start and needing working versions (even if only stubs) of *every* function you call may ensure type correctness, but many programmers find that it also ensures that you never find the right program to code in the first place. This is because you don't have the freedom to explore possible solutions without having to break your concentration to satisfy the nagging of a static type checker. -- http://mail.python.org/mailman/listinfo/python-list