[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



I wrote:
> >  I suspect that some of the
> >really large systems to which [Martin] alludes would be
> >impractical if written entirely in dynamic languages.

which Dan rightly flagged:
> (It's possible that not everyone on this list has the same
> vision of what set of languages are "dynamic", even in the
> context of this discussion...)

I really meant to say "dynamically typed" languages.  Languages like Java
and C# are quite "dynamic" even though they're statically typed.  But I was
thinking of large systems written in languages like the ones Martin
mentioned: Perl, Ruby, Smalltalk; and of course Scheme & Lisp.  None of
these languages support reliable determination of the type of a variable,
except at runtime.

On this subject, I noticed that a relevant link was recently posted on the
weblog "Lambda the Ultimate":
http://lambda.weblogs.com/discuss/msgReader$3696

It's about "Refactoring Functional Programs"
(http://www.cs.ukc.ac.uk/research/groups/tcs/fp/Refactor/).  The latter page
defines refactoring as "changing the structure of a program without changing
its semantics".  When put that way, it seems pretty obvious that a language
with typed variables is going to have an edge.  As the authors put it, "We
suspect that functional languages are particularly suited to this form of
programming, because their clean semantic basis makes wholesale
transformations more feasible than for a language in the C family, say."

Their picking on C reminds me that typed variables are not the only issue -
the integrity of the type system is of course also a factor.  It also
reminds me that dynamically typed languages can't be written off entirely in
this area - for example, the automatic rewritability of a lambda-based
language like Scheme can be significant.  In fact, IIRC, PLT's DrScheme IDE
now has some features along these lines.  Still, lack of typed variables
would at least inhibit if not preclude entire categories of automated
refactoring possibilities.

Anton