I think both static and dynamic typing have their merits and are not mutually exclusive. I'd like to see a language that has both.

Try these for both static and dynamic typing:

Dylan http://www.functionalobjects.com/

Claire http://claire3.free.fr/description.htm

> It is not necessary to try and quantify how many
> bugs are caused by the lack-of type-checking for
> three reasons:
>
> 1. It may not matter based on the type of application
> or system your are building.

Huh?

> 2. The answer is greater than 0.

I disagree. It has to be enough to justify the drawbacks. If you are going to write an program with 1000 bugs in one month using Java or C#, versus writing the same program with 1001 bugs in one week using Python or Ruby, which is better? You've got three extra weeks of testing to find one bug.

Anyway, how do you know that compile-time type checking reduces the number of bugs? Maybe it just changes the nature of bugs.

> 3. I can program in languages with strong typing.
> I don't consider this overly burdensome. In fact,
> I would love it if Python included this as an
> optional feature.

I would too. Interfaces would be a very nice addition too (see Frank Sommers' post above).

But let's not confuse strong typing with dynamic typing; Python does have strong types, just not declarations and compile-time checking.

> As an illustrative example, there has certainly been
> widely publicized bugs relating to bad data and
> mismatched types. One in particular in the
> Mars Lander -- see
> http://mars.jpl.nasa.gov/msp98/news/mco990930.html.

I looked briefly, but I couldn't see where the problem was based on using a dynamically-typed language. Are you saying the lander software wasn't written in a statically-typed language and rewriting it in one would have eliminated that bug?

This discussion comes up over and over. What is interesting is the static checking must be done side of the debate has never done anything with a dynamically typed language while the pro dynamic typing people have almost always done both.

The benefits of static typing are largely a myth. They were never there in the first place for safety. That was a justification used after the fact. Go back and see why C based languages for example have static typing in the first place. Also C is probably the least safe programming environment that there is.

Also someone talked about environments like IDEA that make good use of static typing, and that is true. But some of the features mentioned have been in Smalltalk environments from the start. I can ask to Inspect any variable and what do you know it tells me specifically what the object is and what methods it has. How?!? This must be impossible without strong typing right? Well the fact is the objects are strongly typed. It is just you don't have to tell what the variable is. This allows for polymorphism. Statically typed languages get around the type system and allow for polymorphism (which remember relies on the code NOT knowing what type it has - only what messages it responds to) by coming up with various cheats like casting and having the language use a richer notion of types.

I think if you are going to have a statically typed language you should have one like Eiffel that has a much better worked out theory of types and has generics so casting is not necessary.

But the fact is I know of no one that has used dynamically typed languages for any length of time that finds they have more bugs than a statically typed language. Don't just go by what you read in your CIS 101 text book.

various cheats like casting and having the language use a richer notion of types
Why is having a richer notion of types cheating?

David Kempster wrote:
"But the fact is I know of no one that has used dynamically typed languages for any length of time that finds they have more bugs than a statically typed language."

The way the question is phrased makes it impossible to refute. There are many other features that contribute to the "defect rate" of a language than typing. For example, there are *many* features of C++ that are problematic for non-expert programmers, and removing static typing wouldn't help one bit.

My own experience might be interesting to relate. For a long period of time, as a consultant I worked on projects in both Smalltalk and in C++. The overall defect rate in C++ was much higher and the productivity lower (as you might expect for general application programming). But we found that as components were evolved by different groups of programmers, relatively speaking many more integration errors crept into the Smalltalk code base over time.

One programmer would change a class in some way, seemingly have everything working, and then it would break code elsewhere in the application or in another application using a library. There was no comprehensive way to see what a change might affect, and often these bugs lay dormant in code until much later.

As Bob Martin and others have said, a comprehensive unit test suite can go a long way toward compensating for the lack of static typing. But lacking such a suite you are on dangerous ground as code gets large and multiple developers are working together.

BTW, contrary to your original statement, I have used many different OO languages (both statically and dynamically types) and I prefer static typing for building large-scale systems.

Isaac is absolutely right. Implicit typing is very powerful and probably the best way to do larger-scale development.

Dynamic typing means you can't test it (code coverage etc). Static typing means that you sometimes have more typing to do, and that your program may be less able to adapt at runtime if the object model changes.

The best world is implicit typing coupled with something like Eclipse. You certainly don't have to wait until you "compile" your program to find out if there are typing errors in it; this is a flaw in the editing environment, not the language. Good language support within Eclipse for implicitly typed languages would give you the best of both worlds. A "to-do" list could show you implicitly called functions there's no current match for, and allow you to write them quickly.

The fact that Java 1.5's "templates" do not include the primitive types makes them borderline useless. I can count the number of times I've made a casting error while iterating over a collection class on one hand, in many years of Java coding. I can't count the number of times I've had to put together crappy object-based structures with wrapper objects or worse, just to handle primitives in a reasonable fashion (not to mention the ridiculous storage overhead this incurs).

I figured Java templates would allow me to make a collection of longs to doubles, and do it efficiently. Guess we'll all still be waiting...

I figured Java templates would allow me to make a collection of longs to doubles, and do it efficiently
For example?

This is the Nice programming language
http://nice.sourceforge.net/

   void main(String[] args){      
      let a = new ArrayList();      
      a.add(30000.0d);
      a.add(30000.0d);
      println(a[0]==a[1]);
   }

I:\Nice\Test>nicec --sourcepath .. -a t.jar -R Test
nice.lang: parsing
Test: parsing
Test: typechecking
Test: generating code
Test: linking
Test: writing in archive
nice.lang: writing in archive

I:\Nice\Test>java -jar t.jar
true

> As an illustrative example, there has certainly been
> widely publicized bugs relating to bad data and
> mismatched types. One in particular in the
> Mars Lander -- see
> http://mars.jpl.nasa.gov/msp98/news/mco990930.html

As I understand that problem, it had nothing to do with programming language types. I don't know the code, but it sounds to me like a variable named "altitude" was interpreted by one team as feet and another as meters. The compiler/interpreter just saw a numeric type that seemed to match. I don't see how static typing can help in such cases, where the wrong algorithms or interpretations are applied to data.

If I had written that code I would probably have chosen a variable name like "altitudeMeters" to remind myself and others. That would work in either C++ or Python.

Greg Jorgensen
PDXPerts LLC, Portland, Oregon USA

I realize this is an old thread, but it seems worth pointing out:

If you really care that much about types in your Python code, just handle the exceptions yourself and either run unit tests or run it through pychecker.

For the most part, I've found as I embrace OOP more, the types don't really matter. That is to say, I have a function that parses and computes taxes on objects with a 'price' member which I convert to a decimal format before computation. I dont need to know what type of object it was, so long as it has a 'price' that can be converted to numeric (and Python's quite happy to convert strings for me too if they've been read in from files without converting).