Python or Java or maybe PHP?

[Mike Meyer]

"NOKs" <liorm at noks.com> 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 <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.