Re: Robert Martin on the Relevance and Future of Scripting and Dynamic Languages

[Daniel Weinreb <address@hidden>]

>
>
>
>* "[Dynamic] languages are much easier to refactor" - it's not as simple as
>that.  It sounds as though his real point is that *deploying* updates in
>dynamic languages is easier (see my third bullet point below).  But as for
>the actual refactoring, if I change a method name in Smalltalk, say, how do
>I go about finding and changing every place where that method is invoked?
>What if other unrelated classes have a method by the same name?  With a
>languages that knows the types of its variables, it is possible to reliably
>automate refactoring, making refactoring - *especially* large scale
>refactoring - easier to do reliably in a static language.  (I'd be
>interested to hear counterclaims from anyone with experience of large scale
>refactoring in e.g. Smalltalk).  This is a fairly new development, though -
>it's only quite recently that tools like IDEA and Eclipse have become widely
>available to support this.  Perhaps Martin is not fully taking this into
>account.
>
That's just what I was thinking.  I suspect we're going to hear a 
powerful counterclaim
from David Simmons, who is evidently using Smalltalk technology a lot 
more powerful
than what I was exposed to some twenty years ago...

>
>
>* "If we write unit tests in the XP way, we don't need type safety" - wow,
>quite a claim! 
>
Yes, I agree completely. XP points out that it would really be nice if 
we had unit test suites
so damned good that if the program passes the suite, we can be extremely 
confident that
the code is entirely bug-free.  This is a great goal to have and I am 
completely and totally
in favor of extensive unit testing, but let's not kid ourselves as to 
how closely we can
reach the goal.  Checking that can be done by reasoning about the code 
rather than
by enumerating sets of test cases that somehow purport to be a sample 
that stands in for
all possible cases is a good thing to have, even if you're being very 
diligent writing test cases.

>
>
>* Compilation performance and deployment: ... Martin
>didn't make a very good case against static typing in general in this area,
>...
>
Furthermore, it's not necessary to make hypothetical arguments about "on 
the order of N squared".
These things can and should be measured with actual real-time timers; 
there's no excuse for being
so lazy as to talk about "N squared". Surely there are ample references 
in the literature to measurements
of compile times? If I were going to mouth off in public on that topic, 
I'd sure like to have hard
empirical data.

(On my last Java project, we had a hard time getting the Java dependency 
checking all correct,
for reasons that I can't remember any more, so we always just did 
complete recompiled using
Jikes, which was, as they say in this part of the world, wicked fast.)

>  I suspect that some of the
>really large systems to which he alludes would be impractical if written
>entirely in dynamic languages.
>
(It's possible that not everyone on this list has the same vision of 
what set of langauges
are "dynamic", even in the context of this discussion...)

>
>
>Martin's prediction is based on trends for existing languages, which may be
>valid for the 10-year timescale he mentions, if not particularly prescient.
>
On the other hand, we've been hearing arguments along the lines of 
"computers are so fast now that
runtime speed is much less important than it used to be, therefore we'll 
give up speed so that..."
for so many years, and yet things change in this regard relatively slowly.

As I've said before, I will believe that a major turning point has come 
when I learn that the
next releases of Microsoft Word and Oracle's RDBMS are written in a 
"dynamic"/"lightweight"/"scripting"
language (including C#).