Strongtalk is smalltalk with a static type system. The history is interesting – a bunch of intelligent and motivated people getting together to produce results – but the project was stopped when Sun bought the company and redirected it to work on Java instead.
From a language point of view, strongtalk is notable because it retro-fits a static type system onto a dynamic language. In other words, you can write old fashioned smalltalk code in a strongtalk system – but, if you’d prefer to get the advantages of static typing you can write type annotations and play in the strongtalk world. So, you can write some modules of your system in a free-flowing dynamically typed style, and write others in a stricter statically typed manner. This also reminds me of the “retro-fitted static type system” for Erlang (which is a dynamically typed language). If I remember correctly, that effort apparently discovered that most of the erlang standard library could actually be assigned static types without any change. A dynamic-type fan would say “that shows that static typing doesn’t capture significant errors”, whereas a static-type fan would say “if you’re writing statically typeable code anyway, you may as well use a type-checker which makes sure you’ve not slipped up”.
I was surprised by the optional nature of the type-checker in strongtalk. My c++/ocaml background had lead me to believe that type-checking was an integral part of the compiling process. In fact, it is integral to the compiling process in those languages since the code generator needs to know the static types. But in the strongtalk system, the code generator is more flexible. If you supply static types, it will generate faster code. If you don’t supply static types, it will generate smalltalk-like code which checks the types at runtime. So, you don’t have to run the type-checker at all. Very strange.