The Artima Developer Community
Sponsored Link

Weblogs Forum
Are Dynamic Languages Going to Replace Static Languages?

83 replies on 6 pages. Most recent reply: Aug 6, 2010 11:26 AM by Stephen Monette

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 83 replies on 6 pages [ « | 1 2 3 4 5 6 | » ]
Greg Vaughn

Posts: 55
Nickname: gvaughn
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 5, 2003 4:42 PM
Reply to this message Reply
Advertisement
A couple of months ago my mind went down this same path. I do believe that TDD compensates for many of the things static typing helps with. Over an IM conversation with Glenn Vanderburg, he came up with a good counter-point. The pointcut concept introduced by AOP is very powerful, and relies on static typing. I haven't gotten my hands into AOP enough to be sure, but my impression is that it could be viewed as a compensation for the lack of meta-programming. Since weakly typed languages are more likely to offer meta facilities, this may be a moot point.

I'm glad to read the article to refresh this idea in my mind, because I think it may tie into the other direction my mind has been going lately (and I love those connections between ideas). I've recently began emphasizing the difference between the business logic classes, and the system infrastructure classes and how the different goals imply the different approaches we should use.

Now I'm confronted with the question: Is system infrastructure best with static typing, and business logic with weak typing?

I think I'll start up a new background thread...

Ezra elias kilty Cooper

Posts: 1
Nickname: ezra
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 6, 2003 2:23 AM
Reply to this message Reply
Sure it's a bit of a pain (in Java) to add "throws" specs or catch blocks in a dozen places because you decide to throw a new exception, but as Arnold deVoos points out, this does maintain the validity of your interface contracts--which is more important on a large multi-person software project or a library, than it is for experiments, prototypes, and modest projects. Another plus is that it helps you to think about important things: to take the example of Java exceptions, it reminds you to go through the hierarchy of callers and ask the question, "Does this exception need to be handled at this level or can I burden my callers with it?" Remember finding the callers can be a tricky problem to solve using grep because method CallerFunc may match the search string because it calls MySpecIsChangedFunc, but method UberCallerFunc may call CallerFunc, and thus it may need to know about your exception, even though it doesn't match "MySpecIsChangedFunc". Under strong typing, iterating the fix-compile-fix cycle a few times allows you to find all the callers, and all the callers' callers.

More generally, static typing can often help find the location of errors. It's no substitute for unit tests, but typically when a unit test fails it just reports FAILURE, and leaves you to find the problem. In a language like Python, my experience is that the errors you see are such as "Empty list on line x" (paraphrasing here), which doesn't throw much light on the problem. But in a really good typed language, such as ML, you get something more along the lines of:

Passing type "Pet list". Expected "Pet list list".

which might suggest to me that I took the car instead of the cdr (if you can forgive my dated LISPisms).

But the more popular static languages are too restrictive--that's the clarion call that I heard in this forum. For example, the problems with multiple inheritance in C++ often necessitate to type hierarchies instead of more fluid type dags or other more fluid relationships, which SmallTalk or Python can handle easily. When new requirements come up and an existing type hierarchy becomes inappropriate, this can put C++ programmers in the damnable position of choosing between completely restructuring the class hierarchy, or hacking around it (say, with a wrapper class or by using a lot of downcasting) which invalidates the whole benefit of static typing. Java's interface/implementation distinction may be an improvement, since it permits one common form of "multiple inheritance" while retaining the static-typing benefits, but it still leaves a lot of cases uncovered.

Languages such as ML (which alleviate the need of dilligently declaring variables, yet still detect type errors) solve a lot of these problems but are wildly unpopular, in part because of their sometimes obtuse syntax (but then, Perl somehow took off). Maybe ML also compiles slowly--can anyone speak to this--Krish? ML is not perfect but lots of its ideas could be usefully put to work (how about function closures in a future Java so we wouldn't have to clog up our code with those one-method anonymous classes so often?) I'm optimistic that it might be possible to create a beautiful language that would have a type-system as strong as ML's or C++'s, one that's at least as flexible as Java's, and would allow a looser style of coding as ML, Perl, or Python.

Greg Vaughn

Posts: 55
Nickname: gvaughn
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 6, 2003 11:26 AM
Reply to this message Reply
A friend just pointed me at Paul Graham's essay http://paulgraham.com/hp.html Hackers and Painters that has some bearing on this topic. Here's an excerpt:


...a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you've already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that's not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.

Nigel Campbell

Posts: 1
Nickname: nobby
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 6, 2003 10:01 PM
Reply to this message Reply
> For example, Eclipse is a large scale progam however its
> able to overcome the problems of static type checking. I
> don't believe that there's a Smalltalk program of
> comparable size to the Eclipse project. The evidence

Smalltalk was often used for in-house projects in sizes up to 1000's of classes. I can think of a major CASE tool (LINC Design Assistant) written in Smalltalk.

Another large project substantially written in a dynamic language is Mozilla. Mozilla is a good example of two-language development (a core of fast stuff written in a low level language with ancillary functionality written in something high level). Javascript is a dynamically typed language.

ZOPE is a large-ish code base mostly written in Python.

The idea is not new. CAD systems and other large software projects have made extensive use of LISP. Often there is still a core of C or some such language to maintain fast internal data structures. I can think of a few examples: Interleaf ("100,000 lines of lisp saved 1,000,000 lines of C"), a CAD program made by Texas Instruments (can't remember the name), and (to a certain extent) AutoCAD.

Nigel.

Bill Venners

Posts: 2248
Nickname: bv
Registered: Jan, 2002

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 7, 2003 3:49 AM
Reply to this message Reply
> A friend just pointed me at Paul Graham's essay
> http://paulgraham.com/hp.html Hackers and Painters that
> has some bearing on this topic. Here's an excerpt:
>
>
> ...a programming language should, above all, be malleable.
> A programming language is for thinking of programs, not
> for expressing programs you've already thought of. It
> should be a pencil, not a pen. Static typing would be a
> fine idea if people actually did write programs the way
> they taught me to in college. But that's not how any of
> the hackers I know write programs. We need a language that
> lets us scribble and smudge and smear, not a language
> where you have to sit with a teacup of types balanced on
> your knee and make polite conversation with a strict old
> aunt of a compiler.

Thanks for the link. I would say that sometimes we use programming languages to think, other times to build. Most people have both pens and pencils, and use them for different kinds of tasks.

Perhaps I risk revealing too much to armchair psychologists out there, but at some point -- high school, college, I don't remember -- I pretty much stopped using pencils. I prefer pens, I think for their stark, strong lines. When I screw something up, instead of erasing, I always scribble it out. Maybe excessive pen use is a sign of a more static-typing-oriented personality.

Lalo Martins

Posts: 1
Nickname: lalo
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 7, 2003 6:34 AM
Reply to this message Reply
Ironically, I'm in the opposite position with regard to work - my work is very dynamic, done mostly in python and zope, and the projects I get involved with for fun make me write some C. But as far as the feeling is concerned, you're right, it's easy to miss the dynamic languages.

What's more - I find it that language-enforced encapsulation (eg, private members) are more a burden than they are worth.

Andrew Koenig

Posts: 10
Nickname: ark
Registered: Apr, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 7, 2003 8:29 AM
Reply to this message Reply
The typical [sic] behavior of statically typed languages is to force us to say what the types of our variables are when we write our programs. Dynamically typed languages avoid this problem, at the cost of failing to detect type errors until the program executes.

There are some langauges that give us at least some of the advantages of both worlds. ML is such a language that I've used: It is statically typed, but types are polymorphic and the compiler infers them for you. Programming in such a language feels almost like programming in a dynamically typed language, except that you don't have to wait until run time to learn about type errors.

Here's a quick example:
val a = "foo"
val b = 42
Even though I did not explicitly say what types a and b have, the compiler figures it out for me. It is as if I had written
val a: string = "foo"
val b: int = 42
If I now write an expression that tries to evaluate a+b, the compiler will detect the error and refuse to compile the program.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 7, 2003 8:17 PM
Reply to this message Reply
> But how would you find the call sites in a dynamicaly
> typed language? For what string would you grep?

You'd run your unit tests and see which ones broke.

> Don't get me wrong, I find the dynamically typed languages
> more productive overall. But the "find all callers"
> problem represents a very real practical difference that I
> have not seen addressed in the static vs. dynamic
> discussion.

Granted.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 7, 2003 8:22 PM
Reply to this message Reply
> Color me skeptical about claims like "we'll catch it in
> testing." History tells me that when schedule pressure
> hits, things that don't HAVE to be done fall on the floor.
> With static typing you don't get the option to be sloppy
> and find typing errors at runtime (often in production.)

Have you ever found that the incindence of casts and type-unsafe structures increases with date pressure?

Type safe languages provide no guarantee of type safety, let along correctness. It all comes down to the discipline of the programmers. Any team that is disciplined enough to maintain type safety will be disciplined enough to maintain unit testing.

> And I don't ascribe this to the thoughtful developers in
> this forum, but there are many who just won't follow
> through on the testing requirement, even without external
> pressures. They want to get things out quick and move on
> to the next bit of fun.

We'll find the all...

Kenny Tilton

Posts: 4
Nickname: kenzo
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 7, 2003 8:33 PM
Reply to this message Reply
"I wish I was programming in Ruby or Python, or even Smalltalk. "

How about Common Lisp? Mature, compiled, and ANSI Standard.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 8, 2003 5:46 AM
Reply to this message Reply
> "I wish I was programming in Ruby or Python, or even
> Smalltalk. "
>
> How about Common Lisp? Mature, compiled, and ANSI
> Standard.

I get the general impression that mature is often a synonym for 'old (and therefore boring)'. Developers love new languages and new features. Look at the unbridled joy each new early version of Java was met with, and compare that with the increasing indifference as changes in later versions became smaller and smaller.

On this basis, I predict that one of the biggest hidden factors in the increase in popularity of Python is the decrease in dynamism in the evolution of Java.

Vince.

Dennis Doubleday

Posts: 3
Nickname: ddoubleday
Registered: Apr, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 8, 2003 2:18 PM
Reply to this message Reply
> > With static typing you don't get the option to be
> sloppy
> > and find typing errors at runtime (often in
> production.)
>
> Have you ever found that the incindence of casts and
> type-unsafe structures increases with date pressure?

Not analogous at all. There are very few methods in most statically-typed programs that require casting of arguments to methods (Java generics will reduce even that small number). For the vast majority the compiler does the work. For a dynamically-typed large program, EVERY method call becomes suspect at this basic level, even before you begin testing program logic. A thorough test suite is much harder to construct in that case.

> Any team that is
> disciplined enough to maintain type safety will be
> disciplined enough to maintain unit testing.

Do you really believe that? I have witnessed many counter-examples. In fact, I would venture to say that I have RARELY seen a software product that even attempted a complete test suite (Jakarta POI is impressive, though.)

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 9, 2003 2:40 PM
Reply to this message Reply
> Color me skeptical about claims like "we'll catch it in
> testing." History tells me that when schedule pressure
> hits, things that don't HAVE to be done fall on the floor.
> With static typing you don't get the option to be sloppy
> and find typing errors at runtime (often in production.)

I wrote a dynamic language while at Bell Labs that we used for on switch procedure control. It was designed so that we could ammend the procedure and 'fix' tools in the field because we had to be able to make the procedure (software release upgrades) happen, in spite of software problems.

I was very nervous about the languages use, but we did find that it improved our productivity and the stability of our tools dramatically. And, I put a simple converage analysis mechanism in it. I created a bit array in memory that had 2 bits per line. One bit was for line executed and the other was for branch taken. When the VM exited, it wrote out this bit array. I could then use a simple program that read the bit array, and the original source file. The output was an nroff document, or a pageable ANSI terminal control document that either highlighted the lines you had covered, or those that you had not. Bold was used for line coverage and underline for branch coverage.

We could then, very easily create a printout to review after our test session that told us exactly was was still needing to be covered. What this meant is that we didn't have to stare at the source and devise test procedures up front.

We'd run through the procedure once, and then look at the coverage to decide what other tests needed to be run verses code that we could visually inspect and write it off as not needing execution coverage.

The majority of lines not covered where generic error message blocks which if syntactically correct were, good enough to just inspect the message visually, and leave it.

John Watson

Posts: 1
Nickname: jkwatson
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 10, 2003 12:50 AM
Reply to this message Reply
Even worse, don't you end up with a system where each "interface" has to have unique method names associated with it? So, let's say that I have one "interface" with a method "react". I decide that a better name might be "makeItSo", so I do my refactoring and change all "react" calls to "makeItSo". Oops! Someone else on the team already had an "interface" with a "makeItSo" method. Now I want to refactor my original method call name to something different. Wouldn't it become extremely difficult to decide which "makeItSo" calls were for my interface, and which were for the other guy on the team? How do you address issues like this without strong typing?

Premkumar Natarajan

Posts: 1
Nickname: pondyprem
Registered: May, 2003

Re: Are Dynamic Languages Going to Replace Static Languages? Posted: May 10, 2003 7:16 AM
Reply to this message Reply
I feel dual type checking (switching on/off) by the compiler would give the advantages of both the worlds, any comments?

Flat View: This topic has 83 replies on 6 pages [ « | 1  2  3  4  5  6 | » ]
Topic: Have Generics Killed Java? Previous Topic   Next Topic Topic: Adding Optional Static Typing to Python


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us