"NOKs" <[EMAIL PROTECTED]> writes: > Thanks! That's really useful. I'm not sure if I'm a "dynamically typed" > guy - coming form C#, very strict language, and C++, statically typed, > but i definetly searched and see the debate going strong. Not try to > start it here, but do you think that statically typed - namely, if I > undertood correctly, the fact that there's no need to declare the > variables - do you think it has such an effect on productivity?
Alex Martelli gave an excellent overview of this question, and his answer ("Yes"). However, you're in a forum for dynamically typed languages, so that's to be expected. In a forum devoted to statically typed languages, you'll find people who will answer the other way, using their experience and observations as the grounds for that conclusion. What's notably lacking for both camps is any real research on the subject. I've seen it claimed that the SPARK folks have that research, but have been unable to find such. What SPARK papers I have found concentrate more on correctness than productivity: IIRC, they claim millions of lines of production code with no errors. I wanted to point out that there are other more sides to this issue. To start with, when you say "declare variables", you really mean "declare variables TYPES". There are dynamically typed languages where you have to declare every variable, and others where variables spring into existence when mentioned. Python is halfway between the two, requiring you to declare arguments, and only creating variables when they are assigned to. As Alex mentioned, there are statically typed languages where you don't have to declare the variables types either. I'm just starting to look into this, and I don't know of any that don't require you to declare all your variables as well. Finally, there's a camp that pushes static typing up a notch, practicing what's called "Design by Contract" (DbC). Languages like Eiffel and D incluce DbC facilities. With these, you add extra code that provides checks on the preconditions to a method invocation, postconditions when it exits, invariants for an object, and various conditions on a loop. This help with the DRY principle, as a good set of unit tests would check all these things before and after each test, so you'd have to code the checks (or invocations of them) for every method invocation in every test. With language support, you only code them once, and the compiler generates code to check them automatically. Again, people who use them swear by them - but have no hard data to back up their believes. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list