NOKs <[EMAIL PROTECTED]> wrote: > 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,
C#'s pretty close to Java, typing-wise, and C++'s not that far away. I did mention one GOOD statically typed language in my previous post... unfortunately it's one of those for which you need a bunch of CS PhD's -- Haskell. > 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? One great programming principle is "Dont' Repeat Yourself": when you're having to express the same thing over and over, there IS something wrong. I believe the "DYR" phrasing is due to the so-called Pragmatic Programmers, who are paladins of Ruby, but I also believe it's a principle most experienced programmers could accept. So, when in Java you have to code: FooBar zap = (FooBar) glak; you KNOW there must definitely be something wrong -- what's the POINT of making you say "FooBar" TWICE?! There are two ways to let you avoid declaring variables, enabling DYR and enhancing productivity: a. do everything at runtime (as Java will of course do for the check, in the above code, that glak CAN be properly "cast to a FooBar"); if you do ALL the typechecks at runtime, consistently, you get a dynamically typed language. "Dynamically" is much the same as "at runtime". And it turns out that the only check you really need is: -- when you call bleep.zupdok(), DOES whatever object bleep refer to support a 'zupdok' method that is callable with no args? Runtime typing is enabled, as a productive programming approach, by the fact that, whatever your language's approach to typing, you NEED unit-tests anyway (because they're indispensable to check, necessarily at runtime, a lot of things nobody can check statically)... and, as a side effect, good unit-tests will also duplicate all the (very modest) checks a statically typed language could do for you. b. do everything at compile time. The typesystems of Java, C#, C++ are substantially too weak and inconsistent for that; however, language such as ML (in its several variants) and Haskell prove that a typesystem CAN be designed to allow that. With a properly designed typesystem, you don't NEED declarations either: you code something like (in Python syntax) def f(a, b): return a+b and the compiler deduces "a and b must be variables of a typeclass that supports addition, and function f's return value is going to be of the same typeclass as a and b". So, if you later call f(2,3), the compiler accepts that and knows the result must be an int, but if you try to code f('zap', 67) the compiler screams at you because it knows you can't add a string and an int. This "type inference" is very powerful, and practically equivalent (at least in the Haskell variant, based on "classes of types", aka "typeclasses", not mere types) to the "dynamic typing" you get with Python, with further benefits (you get some errors diagnosed faster, without even needing to run your unit-tests, which saves you a few seconds when it happens). Unfortunately, I believe Haskell (and SML, etc) only really suit programmers who have a very particular qualification and mindset -- essentially, higher degrees in mathematics or CS, or the equivalent (some people will have that knack without formal titles, of course, but it's somewhat hard to predict who will). If you have the rare fortune that your programming team can be counted on to be composed only of such people, do give Haskell a try (and don't forget Common Lisp, another language of uncanny power), and you may be even happier than with dynamic language (not necessarily -- a high-profile site has just been recoded from Lisp to Python, essentially for highly pragmatic reasons, for example -- but Python-friendly, Lisp-centered authorities such as Norvig and Graham still think Lisp would have an advantage in such circumstances, assuming of course the pragmatical issues can be swep away in your case). If "really good" static typing, as in Haskell, is not a real possibility -- that is, in the real world, given the choice between dynamic typing as in Python and faulty semi-static "but with some inevitable runtime aspects AND lots of redundancy required of the programmer" typing as in, say, Java -- I really have no doubt that dynamic typing increases programmer productivity quite substantially. At Google, I see the same brilliant engineers code in Python, C++, and Java (the three general purpose languages Google uses), and the productivity results that I observe appear to fully confirm my opinions (already formed on the basis of other experiences, both regarding my own coding and that of other programmers, of varying skills, I observed in the past). Once you've decided to give dynamic-typing languages a try, the issue still remains open between Ruby and Python, of course (there are others, from Tcl to Perl, from Lua to Applescript, etc, etc, but I see no real reasons to consider any other but Python and Ruby for your task). Despite the many differences of detail (mostly, though not exclusively, details of "syntax sugar"), I consider Ruby and Python to be essentially equivalent *as languages*, so I would suggest you choose on a strictly pragmatical basis -- quality of framework and library, execution speed, tools, books, third-party extensions, &c. I see it as a tribute to both languages that (not having much real-world experience with Rails vs, say, Django) I don't know for sure which one would suit you best, though I suspect that, if nothing else for reasons of "maturity", it might be Python. Be aware, though, that at least one Ruby fanatic has verbally assaulted me quite intensely for daring to express these, which I consider to be very even-handed, judgments (apparently, by considering "a mere syntax sugar issue" the fact that in Python you code, e.g., "if a>b: c=d", while in Ruby you may code the other way 'round, "c=d if a>b", I must have insulted some gods at whose altar such fanatics worship...); if you choose to listen to such fanatics, you should then definitely get a second opinion rather than trust my own assessment of these issues. Alex -- http://mail.python.org/mailman/listinfo/python-list