[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Robert Martin on the Relevance and Future of Scripting and Dynamic Languages
>* "[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
That's just what I was thinking. I suspect we're going to hear a
from David Simmons, who is evidently using Smalltalk technology a lot
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
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
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
(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
language (including C#).