Static typing sucks for most things – languages at that level should be prototype-based – but there are some cases where it is useful. Therefore, it should be optional – provided the syntactic cost is not too great. IMO, the syntactic cost is negligible – if you treat type safety as just another sort of contract.

Phil Goetz, just because a lot of people went down the same wrong road doesn’t mean there aren’t other routes. It’s a sign that it’s premature to design languages for provable correctness, but progress is being made on fragments, like type safety.

IMO, the big improvements are coming with more microlanguages on VMs. Programming languages (like Java) become popular for some good reasons, then get locked in due to network effects. Its hard to displace them, and its hard to improve upon them significantly without breaking backwards compatibility. But nowadays with the JVM and CLR, you have multiple languages running in the same VM, and many can talk to each other. Think Java’s type system sucks? You can code in Scala and still call your old Java code, use Java deployment systems (Tomcat, Glassfish), and all that. Like dynamic languages? Then you can code in JRuby, Groovy or Jython and talk to your old Java code too. Lock-in is no longer as big of a hurdle as it was.

As some other people have mentioned, functional languages seem to be becoming more popular. I’d really like to see Scala and F# take off, but I wouldn’t bet that they will.

On the subject of formal proofs, I pretty much agree with Doug S.

Dynamic languages have their place, and I’ve written plenty of Python. Java is just horrible, because the type system is strong enough to get in your way but doesn’t protect you from doing fishy stuff like casting things to and from Object.

In a language that strictly requires strong, static typing across the board you have more guarantees about the behavior of code you aren’t familiar with, compilers can produce faster code, and the code is made more tractable to static analysis. Ideally, errors such as possible null references and invalid type casts should be caught at compile time, not runtime. The main issue is to make the type system simultaneously as strong as possible and as unobtrusive as possible.

Peanut Gallery: I agree completely. In my previous post feel free to translate mention of “high-level abstractions, strong type safety, and absolute referential transparency” as “I think Haskell is pretty nifty”. It may be worth noting that Microsoft has hired a lot of Haskell guys and C# has moved in that direction with lambdas, some limited type inference, lazy sequences, &c. So that’s at least one mainstream, “respectable” language taking direction from Haskell…

As others have pointed out, once you know enough that you can tell the difference between a correct program and an incorrect program, you’ve already constrained your design enough that actually writing the code becomes trivial by comparison. If you have a specification that’s precise enough to use formal methods on, the hard work has already been done.

The irony, of course, is that current trends in programming languages are often moving away from strong/static/safe type systems, towards weaker type systems in languages such as Python.

Off topic – but: languages should not force programmers to use one or the other paradigm: static typing is just dynamic typing with a contract imposed on the types.

In the research community, there is still lots of work and progress going on with regard to type systems, and much of that work will definitely make its way into production languages eventually. The advantages are too great to ignore, and a dynamically typed language can never be as safe or as fast as a statically typed language. I think the future of programming languages lies in making languages with improved type systems derived from things like Hindley-Milner (Haskell, ML) as easy to use as languages with type systems like Python.

For example, Philip Wadler and Robby Findler are working on being able to rigorously and safely combine typed and untyped sections of code in a single program, which would give you the advantages of a good type system (type safety, security, performance, etc.) and still allow you to use untyped code when that is needed. Additionally, languages like Haskell that provide a static type system with type inference (which infers types for you rather than requiring you to specify them yourself as in Java…) provide many of the advantages of a dynamically typed language like Python while still being type-safe, more secure, and faster. (See 38:17 and on in Faith, Evolution, and Programming Languages for information about the work on “evolutionary types”.)

In the long term, I think we’ll see stronger and richer type systems than anything that exists today, but with better inference and much better tool support. The main reason that dynamic languages are so popular at present is because of their ease of use and convenience, which translates into productivity and happy programmers. Better inference on the part of the type system combined with good IDE support could make a statically typed language almost as convenient while still providing huge advantages in terms of reliability, security, and performance.

Another factor that can make programs dramatically easier to formally reason about is maintaining referential transparency, but most current languages pay little attention to this issue.

A language and environment supporting high-level abstractions, strong type safety, and absolute referential transparency would allow for a lot more formal verification than languages like Java, which do mediocre to poorly on all three…

There is even a well-known correspondence between strongly typed algorithms and constructive formal proofs: correctly implementing a formal spec is equivalent to providing a constructive proof of the corresponding theorem.