Except for short scripts I generally start programming by figuring out what the data will look like. In a strongly typed language I have a built in language for describing my data. Of course the data structures change as the program evolves but I find it massively helpful to have that description up front.

What's that quote? Something like:

"Show me your algorithm and I will remain puzzled, but show me your data structure and I will be enlightened."

Exactly.

To often, I think we're focused on the writing of code rather than the reading of code. Annotations sometimes seem repetitive, but repetitive can aid the readability.

Type inference might be a very nice compromise. Haskell allows you to annotate with type information, and that may provide more helpful errors, but usually it's optional. But people do it anyway, because type information tells a reader so much about the program.

If we just focus on writing, then clearly the programming language is meant only for unidirectional communication from a human to a computer. But if we focus on reading as well, then it becomes about humans communicating with other humans.

Type inference (Haskell, C#) can be handy. Optional typing (many Schemes/Lisps, e.g. Gambit-C, SBCL or Clojure) is also an option.

I see your point, but dynamic typing is not the only way to get (most of) these benefits, and both of the above show significant performance boosts.

It's really not that hyped up lately, but i really think that optional typing would be the best of both worlds in that matter. You can write your programs without thinking about types, and then you add types for safety/speed.

With a little bit of type propagation i think it would lead to quite a natural style of programming.

C#/CLR hints towards that from the other side with the dynamic type, but for syntaxic and cultural reasons, it won't be the same thing as a dynamic language allowing you to use types.

Also, Clojure type hinting is not at all optional typing, as it doesn't enforce types at all. It's purely for performance reasons, and i really think is the wrong way to go about things.

I once read lispers discussion on Qi language. One (actual) Qi user told us that he managed to prove that number 42 has type String.

This is the price of optional typings. It leave random holes in your program.

This paper presents an optional type system where type errors can only occur in the untyped sections:

http://homepages.inf.ed.ac.uk/wadler/papers/blame/blame-sche...

Depends which developers you're talking about. For the developers writing the code in question? Sure. For the developers trying to use that code? ...well, you're going to have to tell them about the types, or hope they can read your code-- the latter isn't really a win at all.

The most exciting thing about types is that they can completely prevent you from typing that program.

If you cannot figure proper types, you won't write proper program. You "fail early".