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

[Ken Anderson <address@hidden>]

I like Martin's remark that calling something a "scripting language" was a 
gross injustice.  A friend recently asked me what a scripting language was.
I basically said it was a language that mainstream programers turn to when 
their language becomes too much of a burden.  He was a Lisp programmer, and 
didn't see much need for such a language.

I think Martin's statement "Because these languages are much easier to 
refactor" should be "Because these languages are much easier to write, and 
use".  Refactoring is just one issue.  The less code you have, the easier 
it is to refactor.

The fact that dynamic languages are (usually) interactive is a major win.
People are suprised the first time they ask me a Java question and i answer 
it by typing into Jscheme.

Peter Norvig seems to have become a Python convert:
http://www.norvig.com/python-lisp.html
http://www.norvig.com/Lisp-retro.html

I believe you could write Java applications with a substantial fraction of 
it written in Jython.  This wouldn't be the Word/Oracle example you're 
waiting for but i suspect that's where people like Martin are heading.

k


At 12:16 AM 7/11/2002, Daniel Weinreb wrote:



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