I think both James and Guido have good points. For example, I really like interfaces in Java and I really like the flexible and incredibly easy-to-use collections in Python.

Maybe what we need is a language that has both static and dynamic typing.

Why is it that downcasting in Java requires an explicit cast, by the way? Wouldn't it be simpler to allow that, then to implement generics? This would solve the problem with collections, wouldn't it?

Before I give my exp let me list my language skilss:

Weak Type:

Perl
PHP
Userland UserTalk
Javascript
Python(light exp)

Strong Type:

Java
C

While weak typing does let you fast prototype strong type seems to allow you to do more robust..

Plus you are dealing with totally very different debugging types or workflows in eak and strong type languages..

I don?t see how (finger)typing can be of such importance in a discussion on strong/weak typing in computer languages. Lines of code has nothing to do with productivity. Compactness of code does not necessarily make it easier to read. Haskell is very compact, partly because of implicit types, but also very hard to read.

I also have trouble with understanding the practice of using a compiler as a static type-checking tool. For me, a compiler is a tool which produce binaries given source code. For static source code analysis I use dedicated tools such as lint.

One interesting area where strong and weak typing has interesting effects is Genetic Programming (GP). In GP programs are randomly generated and then tested. The programs that solves the problem best are allowed to reproduce, and the process is iterated until a satisfactory solution has been found.

The first GP engines used Lisp programs which allowed random creation of robust programs (meaning that it could execute at all, compared to a random C program). However the resulting solutions where often impossible to understand. Later, GP has explored strongly typed languages. The benefits are that the enormous search space is reduced, and that it becomes possible to understand what the generated solutions actually do.

I guess GP generation of programs reflect the productivity discussion: Creating untyped programs is very fast, but expanding upon the solution is impossible since they are hard to understand. They are also slow. Creating typed programs is slower, but they execute faster and are easier to understand.

I am not sure if I agree with this myself though ...

I think the real issue of how to get a program correct is much bigger than getting the data types correct, but for compilers with no runtime checking like C, getting the types to match is very important for the program to function. Designing a more strongly type-checked language like C++ is good because it reduces the chances of a type mismatch at runtime. This was an important design consideration as C++ evolved from C, but it follows from the decision to have "no runtime" intelligence. If a program accesses a long int as if it were a char, even though both are numbers, the value returned will be way off the mark. This kind of checking is mainly a mechanical process. Using the wrong type of number is an easy mistake to make, but there are lots of ways the variable types can match while the meanings are scrambled, as when passing parameters to a function in the wrong order. Type checking (strong or weak) does nothing to detect this kind of problem. The full process of getting the program correct is a far greater endeavor than checking types "strongly" or "weakly."

Compare this "mechanical" type-checking of C/C++ with the runtime typing of Python. The Python runtime environment knows the type of each object and can do a good job of interworking between the related types. If a "wrong" type of a number is passed to a function, the Python runtime will do it's best to make it work - to make the "cast" automatically. To guard against the problem of misordered function arguments, Python offers the powerful syntax of specifying the arguments by name rather than by position. This cannot be done in C/C++ but it is a great way to reduce errors. Verilog is the only other language I know of that has something like this (named signal ports to modules) and the ASIC design groups I have been part of have all mandated this syntax over positional ports for large modules.

Yes, you might get lucky and have a C++ compiler-detected type mismatch in a function argument misordering, but you might just as well be unlucky and have the misordering not cause a type mismatch (e.g., reversed ints). Python will certainly detect a type mismatch it can't handle, (it will happen at runtime instead of compile-time), but neither environment will detect all mistakes. There is no substitute for a proper verification process! Because Python is easy to run, I typically run the developing program often, as I add functionality. Then, the distinction between compile-time and run-time checking essentially goes away.

BTW, for all of g++'s strong type checking, I have managed to confuse it (by accident) with legitimate (I believe) default values for function arguments to the point it delivered a very screwy value when reading one numeric arguement type as another. That took some serious debugging!

Another aspect of Python that I find greatly reduces my mistakes is the use of pointers/references to access all objects. When I'm doing complex things with classes, references are what I want anyway. A C/C++ variable NAME with a VALUE and a maybe a POINTER and an ADDRESS makes keeping track of when to use a "*" and a "&" tricky. Thankfully there is strong type checking in C++! I really need it, ...but with Python I don't... With Python, I'm using a single object referencing scheme that I can just get right the first time, every time. Again, strong (compile-time) type checking in C++ is very important for C++, but "compile-time" checking in Python would be much less valuable.

In summary, I think the discussion of strong vs. weak type checking is dealing with just the tip of the iceberg. The majority of the discussion of what makes a language good for a particular application is much vaster than this, but it requires looking under the surface, ...and sometimes that is hard. I find it all but impossible to discuss the actually important language issues with my C programming friends - they have no experience with a good, object-oriented VHLL (Very High Level Language) like Python, so they have no mental framework within which to evaluate the points I make. (To be fair, the most knowledgeable C++ programmer I know is a Python enthusiast.) The essence of it for me is that I can write reliable programs with many fewer iterations (whether compile-time or run-time triggered) with Python than I can with C++, doing more functionality in much less time. I use C++ where speed of execution is critical (SystemC), but with a 2 GHz processor, Python is quick enough for a surprising number of jobs!

"That all sounds fine to me in theory. It makes sense that the sooner I find programming errors the better. Strong typing helps me find errors at compile time. Weak typing makes me wait until a runtime exception is thrown. The trouble is that I use Mailman and qmail. Both are completely written in Python and both work fine. They aren't prototypes, they're applications, and they both seem quite robust to me. So where does theory miss practice?"

I know that Mailman is written in Python, but I always thought that qmail (from DJB) was written entirely in C.

Here's my take on the strong vs weak/static vs dynamic typing issue.

Python and Java are the two main languages I use. Both are used behind the scenes at Artima.com, for example. I tend use Python for scripts, single file programs that do one thing. I tend to use Java for apps or systems.

I have a stong-typer personality, so I feel more comfortable building systems in a strongly typed environment. But I do really appreciate Python's economy of finger typing.

Although some of the extra finger typing you have to do in Java comes from the need to declare variable types, I think Java requires a lot of gratuitous finger typing. Common things I do in Java should be easy, and require a minimum of finger typing. Things like iteration and opening a file seem very verbose in Java, and not because I have to declare types.

I had the gratuitous finger typing in mind when I asked Gosling to what extent he had programmer productivity in mind when he designed Java. Gosling replied that the main way he was trying to improve productivity was to make memory corruption bugs impossible. He didn't seem to be concerned with finger typing:

http://www.artima.com/intv/gosling319.html

I think one of the reasons people like IntelliJ IDEA is because it gives you finger typing shortcuts for verbose Java language structures. That helps reduce finger typing when programming in Java, but you still have to look at all that verbosity when reading code. As Guido points out, the advantages of conciseness is not just reducing finger typing but reducing the amount of code you read.

I suspect I would enjoy using a language whose compiler (and/or interpreter) inferred types where possible, and required the programmer to explicitly provide types where they can't be inferred.

One post in Slashdot that made me stop and think pointed out that languages affect the way we think, and that perhaps the most important robustness benefit of a compiler that enforces strong typing is not catching typos (sorry) but forcing the programmer to think more about types in the first place.

My feeling when programming in Python and Java is that Python tries hard to get out of your way and let you get things done. Java actually tries to get in your way and slow you down when you are doing something the designers think needs to be done carefully to be robust. So for example, checked exceptions force me to do more typing, and encourages but doesn't force me to do more thinking. I can't just open a file for reading without dealing with the possibility that it will throw IOException.

I think some of the out-of-your-way/in-your-way difference between Python and Java comes from the different goals the designers had for these languages. One was intended primarily for scripts, the other for systems. But as I mentioned in a different post, I think in many places Java is more verbose than it needs to be even given that from time to time Java is trying to get in my way for my own good.

I've kind of missed the debates I used to have about this (ex COBOL, C, C++ programmer in the '70s and 80's - saw the light doing Smalltalk in the early '90s, now doing Java). One thing I've noticed is usually the proponents of weak (I mean run-time) type checking have tried developing with both types of languages and have made a choice while the proponents of strong (I mean compile time) have only used languages with no checking (like C) with bad results, switched to compile time checking (like C++ or Java) and had better results and have never actually developed with run-time checking. They are confused about what is really going on and imagine disastrous things happening. In fact, the disasters don't actually happen. I have my own theories about why not but have no way of proving or disproving them.

While using Smalltalk I did have some type errors which were caught at runtime but not not nearly as many as you would think if you counted the number of compile time type errors I get in Java and assumed they would be equal. This is thoroughly tested Smalltalk code in large quantities, not something small or flaky that could be claimed to have a lot of bugs that just weren't discovered yet. Also, I honestly can't remember even once that a bug that was discovered in testing turned out to be a wrong type that wasn't caught by the run-time type checking. I was not only more productive at writing code, but also it seemed to have fewer bugs of any kind than when I developed in other languages. My guess is that it was because I was able to concentrate more on what I was doing as opposed to keeping a compiler happy. Most of my type mistakes caught by the Java compiler I think are less because I had an unclear notion of what type I was passing and more because I make some silly mistake in tediously explaining and reassuring the compiler that I know what I'm doing. A brain, mine at least, can only deal with so many things at once and I suspect that by not being distracted by satisfying a compiler (that has a very simple-minded way of trying to check correctness) I was able to keep my real intention in mind and actually made fewer type mistakes. And those I did make were successfully caught during run-time testing.

Really late to the party, but it seems to me that static typing is best for projects where the developer count is high and inter-developer communication is limited ( like corporate IT ), but dynamic typing is better for a single developer or a small team in close contact ( OSS or scripting ).

Because the API *is* the most important semantic communication, and static typing conveys more information.