Sorry, this really is OT, but I've been doing some research on this
issue, so I thought I see what folks here think:
Francesco Biscani wrote:
> However the C++ programming style which is
> sometimes referred to as "modern" C++
OK, so I'll take it as a given for the moment that Modern C++ is
typesafe, and, of course JAVA is. Those are the two primary languages
that people seem to want to use rather than Python.
I recently had a Java vs. Python discussion at work, so I dug into it on
the net once again -- My thesis is that aside from syntax, library
support etc, etc, the difference is static vs. dynamic typing. Here's my
* Dynamic typing allows more flexibility and therefor greater productivity.
* Static typing provides more safety, and the ability to optimize
Ignoring performance issues, that leaves: Productivity vs. type safety.
What I've found is that folks that are fans of statically typed
languages really don't get how much productivity can increase. If you
haven't really written code in a dynamic language (and I mean "really",
if you write Fortran with Python syntax, that doesn't count), you tend
to think that all you're saving is the typing involved in declaring
types and interfaces, etc. That's simply not the case -- dynamically
typed languages let you build far more flexible systems with far less
code. This has been well documented, at least anecdotally.
So the question is: does the type safety you get out weigh the
productivity gains? Some say not for quickie scripts, but yes to big
systems, or particularly for "if it fails, someone can die" systems. I'm
not so sure.
We all make type errors when writing code (forget to turn that string
into a number before passing it off to the calculation code, or
whatever), the fact that a static language's compiler catches a lot of
errors like that doesn't mean at all that they wouldn't get caught
quickly with a dynamic language. In fact, my personal experience is that
those kind of errors get caught very quickly, usually the first test of
the code in question. The point is that while the compiler can catch
those bugs for you, those aren't the bugs I care about. In fact, in my
reading, I haven't found a SINGLE anecdote by anyone about a deep, hard
to find bug caused by a type error in a dynamic language, Not one.
Has anyone seen such an anecdote? Or better yet, a real study?
So why are people so concerned, and letting these issues drive their
decisions? A couple reasons:
1) All they know is that their compiler is catching a lot of errors, so
they can imagine that some of those errors would never be found if the
compiler wasn't finding them -- you know that sense of relief when you
finally get a bunch of code to compile! Even though it may not work
right at all, there's still a sense of accomplishment.
2) When you've primarily worked with static languages, you really don't
get how much less code you can write with a dynamically typed language
-- you're so used to thinking that a given method is designed to work
with a couple specific types and classes -- what's so hard about
declaring them? I think folks see the gains from type checking, and
really have no idea that there are significant costs. Here's a good
essay about that:
A quote from that: "So I tried writing some applications in Python, and
then Ruby (well known dynamically typed languages). I was not entirely
surprised when I found that type issues simply never arose."
3) A point made in that article: some folks have bad memories from C (or
Fortran), with type issues. The problem is that they are mistaking weak
typing (or no typing!), like you get when you cast a pointer to a new
type, with dynamic typing, where the type is checked, just not 'till run
time. I used to write Fortran code where you'd pass in references to a
procedure that expected certain types, and the compiler wouldn't check
anything, it would just merrily go along and use that memory address,
which could be total garbage -- that did suck!
This is also a good article about the issue (from the Author of
"Thinking in Java", no less):
Here's a choice quote from that one:
you bring up an interesting question in suggesting that a
dynamically-typed language may require more unit testing than a
statically typed language. Of this I am not convinced; I suspect the
amount may be roughly the same and if I am correct it implies that the
extra effort required to jump through the static type-checking hoops may
be less fruitful than we might believe.
My way of phrasing that -- you're either testing a given code path or
you're not -- if you are not, then you don't know if the code works. If
you are, then you're testing the types and the results at the same time
-- there's no extra testing required to test the typing.
Well, enough written about that! Sorry for the OT post.
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception