NOKs said:
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
. Won't macros and type inference make