Static vs. dynamic typing

Several people that I somewhat respect blogged how good dynamic typing is and how restrictive static typing is. I feel uncomfortable about as I see how well static typing could facilitate software development process.

I do not see it as restricting.

I see it as facilitating.

I do not argue with that good programs could be written using dynamically typed languages. A plenty has been already written. And there are quite a lot of awful programs written using statically typed languages.

I also do not argue with that dynamically typed programs are usually simpler to type, since that there is less to type.

However programs exist not just for being executed. There are other tools that need to read the program beyond compiler or interpreter. There are other humans that need to read the program. And the human that will wear your skin will be other human in a year or so if you worth anything as programmer. So when writing programs, you need to address that future you as well.

The type is a specification of the value expected to be. The compiler (or interpreter) checks that these specifications are consistent. It also can optimize basing on these specifications at own leisure.

However other tools are able to use these specifications as well. If we take Eclipse Java IDE, there are following facilities that jump to mind when I think about static typing:

• Refactoring
• Navigation to type definition
• Incremental compilation and error checking as code is typed

APT-based code generation is another example of how static typing information could be used.

And this is possible even with as broken type system as Java's is.

Humans also benefit from type annotations. Type information communicates (albeit incompletely) a contract of the component. The expected kind of value is specified in a standard place and in a standard way. If type annotations are missing, this information would have been communicated anyway, but other means were used (for example, comments).

Most dynamically typed languages that I know support optional type annotations. Some typing information could be inferred basing on source code in dynamically typed languages. However, such inference will be incomplete, and that will limit tools and understandability of the programs. For example, refactoring will not work reliably.

Another issue is that Java requires too much type annotations even in places where such information could be easily derived (for example, collection for and final variables). Generics in Java are hopeless broken as well, but I have already ranted about it.

Java 5 vs. .NET 2.0 generics: past vs. future

There is a thing that struck me out about Java 5 vs. .NET 2.0 generics.

Major design constraint for the generics in Java 5 was the backward compatibility. Much of the statically available information related to generics is not retained in the byte code. It is erased during a compilation process. The generics become sort of consistent with the rest of the language. There is even ability to retrofit old API to the new language features as it could be seen from the collection framework.

As result, the generics in Java 5 cause a kind of "fake" feeling. There are a lot of things that cannot be done using Java 5 generics which are desirable. For example, a instance of a generic class cannot learn about arguments with which it was created. Some awkward constructs like "((ArrayList<String>)(Object)(new ArrayList<Integer>())).add("Test")" do not create a runtime exception (the compiler honestly warns that there might be a problem).

However by doing so, Java was positioned as a "legacy" language where the burden of the past outweights needs of the future development.

In .NET 2.0, the generics were added as a new feature. It looks like the backward compatibility was not a major constraint during the development. It is a bit facilitated since new collections also implement untyped collections interfaces. However unlike Java 5 counterparts, .NET 2.0 generics do need invoking the backward compatibility argument for explaining weird features. They are much cleaner. So generics in .NET 2.0 looks like mostly motivated by their future use.

On other hand, it is puzzle to me why generics did not make into .NET 1.0. Lack of generics was well documented problem of Java. And .NET framework IS primarily inspired by Java (it was quite funny to read some MS documents that discuss C# and very carefully avoid mentioning Java and mentioning such remote languages as as C). And many fundamental Java language problems were fixed in .NET. This one belongs exquisite group of language problems that .NET designers chosen to reproduce. I kinda understand time-to-market arguments. But I do not believe that few additional months would have made a difference here. Many Java proposals for generics were on the table for long time, and it was possible to select a good one from the start. At least it would have saved them from the shame of CodeDom API.

So it looks like Java position itself as legacy language and .NET as an actively developed language runtime. It might be explained by the fact that the Java had much longer past than .NET. However it does not bode well for Java future. This is a possible reason why Sun started development of the new language called Fortress instead of adding needed features to Java. Open sourcing Java might break this self-image problem and cause implementing and trying more daring features in Java language, but I would not bet on it.