>>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.

Wow wow, hold on here! As far as I know, Visual Age for Smalltalk and also Visual Age for Java was implemented in Smalltalk. If that ain't large programs...

Also, I happen to know some of the guys who helped starting up OTI in Zürich where Eric Gamma works now and helps doing Eclipse. They did Smalltalk before, and also larger systems. Even embedded Smalltalk if I'm not all wrong!

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

I felt this way about new features in C++, and then in Java, but then I found Lisp.

I'm relatively new to Common Lisp, I'm comming there from C/C++/Java and I can assure you, it's far from boring. There are so many interesting *new* concepts, even though the ANSI spec didn't change.

One of the unique and more powerful characteristics of Lisp is its macros. (Don't worry, they have nothing to do with C/C++ "macros"). Common Lisp macros, along with closures and other features, make it possible to extend the language with whatever fashonable new paradigms you want.

> > 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.

A shovel is simpler then a Caterpillar, but this is not in favour for the shovel if you have to move large masses.

And here is the complete story...

Depends on the scope and size of the project. Dynamically is good for small and quick and and fool proof. Rendering a result set from a SQL select into HTML for instance.

There are a lot of application domains with a lot of evolved logic out there - and evolved for very plausible reasons.

In my opinion average developer productivity declined steeply from 1995 onwards and is not on the rise yet.

Bluntly, I blame the rise of dynamic languages and the invention of the Application Servers to host them.

The software industry spent a fortune on improving the curly braces '{}', that´s how we ended up with Java.

We had heated debats in our company on this, which eventually cooled down and finally resulted in a change of company policy. Let the developers decide: Estimate your effort, calculate your budget, opt for your style of programming and languages.

Outcome which did not surprise the C++ community:

The sheer expressive power of C++ outweights it´s drawbacks when it comes to getting the job done within time and budget and in good quality. May be that is not true for small projects but we don´t do that.

The most skilled did not discuss language issues too long (they silently opted for C++ and PL/SQL!!!), they spend there mental energy more wisely and concentrate on the application domain and customer needs (the less skilled struggle with technicalities of all kind more often).

When we compared the estimates against the final outcome, the picture was obvious. PL/SQL outperformed C++, which outperformed Java, which outperformed Smalltalk, which outperformed PHP and Perl.

The big surprise was PL/SQL, which is like C++ a complex, static language.One group built a Server which operated as a XML-Wrapper which called PL/SQL procedures. From then on we stopped using Appication Servers, Java, Perl and things like that.

> Have you ever added an exception to a method and then had> to change many other methods with either 'throws' clauses> or try/catch blocks? Have you ever changed the type of a> function argument and then had to find all usages and> change them? Have you ever changed a class and then had> to recompile, and redeploy, all the classes that used> that class? These are just three of the issues that don't> occurr nearly as often in dynamically typed languages.

... have you ever used not unix vi (which is definitely good for processing huge amount of plain text, but not as a development environment), but any good IDE with code navigation, refactoring, dependencies, etc.? You put your changes, compile, and the IDE allowes you to easily navigate to all problematic places. You use refactoring feature of IDE (or some third-party plugin) to rename variable, class, method, extract class interface or inline code...Am I have a chance to be right? ;-)

> Have you ever added an exception to a method and then had> to change many other methods with either 'throws' clauses> or try/catch blocks? Have you ever changed the type of a> function argument and then had to find all usages and> change them? Have you ever changed a class and then had> to recompile, and redeploy, all the classes that used that> class? These are just three of the issues that don't> occurr nearly as often in dynamically typed languages.

As someone who is completely ignorant of writing real programs in dynamic languages, *not* having to do all those things you list sounds scary to me. But then, your thesis is that you've got the tests to assuage my fears. (Assuming you've got 100% test coverage.)

How often do those examples happen, though? Here are my responses to your list of questions that I believe shows why I haven't felt the desire to be freed of type-safety (most certainly because I don't have the right mindset): (1) I generally avoid checked exceptions because I don't believe in their value, so I'm not usually refactoring throws clauses; (2) I don't often find myself changing the type of an argument -- I assume this happens most often with numeric types (float -> double or vice versa), and I simply don't find myself working often with those types (3) yes, not having to rebuild all/redeploy would be useful, but again, this only happens if you're making an incompatible change like the two examples.

Also, does anyone ever care about the readability benefits of type-safety? In other words, function(int param) already tells me more than function(param), just as "List<User> getMembers()" tells me more than "List getMembers()". Maybe these are somehow non-issues in dynamically-typed languages.

So I guess my question is what are the benefits of dynamically typed languages that would make your thesis conceivable? I read a whole other thread on Artima and I stil don't really get it.

I never know what folk mean by "weakly typed", but if you mean dynamically typed then you'll find a Smalltalk example on p342 of the 1995 GoF book "Design Patterns: Elements of Reusable Object-Oriented Software".

Even with perfect TDD, static typing is still very important for two reasons:

1) Library development (and usage)

If you own your entire application from the command-line arguments to thefinal output, then TDD gives you all of the protection that you need.However, if you are only developing a class library with a very largeinterface for clients to use, then static typing is needed since users willnot properly TDD their code. In my experience, while novice programming hatedealing with compile errors, they hate opening a debugger even more and it isvery hard to produce good runtime error messages. Therefore, compile-timeerrors are still to be preferred to runtime errors.

2) Performance

In my opinion, despite what everyone says about C++, the major motivation forstrong motivation for static typing is high performance, not safety. The factthat C++ has raw pointers tells you that raw C++ is not all that concernedabout safety.

As for TDD, it can be very hard to write isolated tests for some types ofcode. For example, if you are using Python to write scripts to direct thebuild process for an expensive build, it is very hard to make a small fasttest that will run quickly. Instead, I will run a incremental rebuild thattakes 10 minutes and then the Python script crashes because I misspelled thename of a single variable very late in the process. If this had been Javacode, I would have found this out in 5 seconds.

My main reason for using Python for this project is that it is free, it isavailable everywhere, it has better text processing and it is better thanshell scripting.

7 years later - it's 2010. In 2003, I was also a and Java developer and in 2007, I moved over to C#. Back then, I liked the idea of strong-typing, but since then, I've discovered Ruby - at work - and I too have become convinced that the way to go is test-driven development. Unit testing makes me far more confident about my code than static typing ever did. Good post Robert. What's your take on this now that 2010's here?