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

["Anton van Straaten" <address@hidden>]

> I was recently given a reference to the following article "Talk to
> programming guru Robert Martin about his vision for the next decade of
> programming" from March of this year.
>
>     http://www.itworld.com/AppDev/1262/itw-0314-rcmappdevint/
>
> I was curious whether people here share a similar opinion?

I agree with Martin's prediction:

"So, Bob Martin's prediction for this decade: Keep an eye on languages like
Python, Ruby, and Smalltalk. They are likely to become extremely important."

But that's not really new, it's been happening for a while.  More
importantly, I think the actual factors behind this trend are not the ones
he identifies - although some people may be following the trend because of
their belief in those factors.  Three of his points which at the very least
need serious qualification are:

* "[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.

* "If we write unit tests in the XP way, we don't need type safety" - wow,
quite a claim!  Certainly, both unit testing and type safety are useful at
detecting bugs.  But unit testing is not even close to a 100% replacement
for type safety.  One of the many reasons is the point above: type
declarations give the machine more information about a program, and that's
almost never a bad thing, allowing more intelligent automated processing of
code, more intelligent editing of code (e.g. automatic name completion and
context-sensitive help), and better performance optimizations.

* Compilation performance and deployment: "Dynamically typed languages,
however, have virtually zero compile time. There are no declarations to hunt
down. Compilation can occur while the code is being edited. As projects get
larger and larger, this ability to be instantaneously compiled will become
ever more important. Finally, there is the issue of deployment."  Martin
didn't make a very good case against static typing in general in this area,
merely against C++, which has very simplistic dependency management.  He
acknowledges that Java is better, but doesn't provide any solid criticism,
he simply asserts that "the problem still exists".  But Java is actually
quite good at compiling "while code is being edited" and "instantaneous
compiling" - some Java IDEs do exactly that.  (He didn't say whether his
clients with half-hour Java compiles are using the much faster IBM Jikes
compiler.)

Besides, dependencies in (languages like) Java can be enormously reduced by
properly separating interface from implementation - resulting in better
system designs, in addition to faster compiles and quicker deployment.
Martin is most likely describing the consequences of poor design practices
when he complains about Java compile times (or perhaps just talking about
Sun's Java-based compiler).

Of course, part of the reason for the success of dynamic languages is that
they are more forgiving in many ways, and not having to bother about the
appropriateness of dependencies is one of those ways.  But the fact that
dynamic languages make it easier to deploy poorly coupled designs, without
obvious upfront cost, is a double-edged sword.  I suspect that some of the
really large systems to which he alludes would be impractical if written
entirely in dynamic languages.

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.
But as I mentioned towards the end of the last flurry of activity on this
list, I would hope to see languages arising that make use of features like
type inferencing and soft typing to make the use of types less "costly", and
ideally, mixable with untyped programs (notwithstanding the horrible
academic implications for such systems).  If the pendulum swings away from
static typing, it won't be so much because of intrinsic problems with the
mechanism, as due to the particular mix of features and benefits which
current languages provide, which only indirectly have to do with their type
discipline.

Anton