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.
2 replies on “Strongtalk”
Actually, it won’t generate faster code. The Strongtalk system had two pieces – one was a static typechecker, one was an optimizing compiler. The two were completely unrelated, in that the optimizer made no use at all of the static type information, and was purely a run-time dyanmic optimizer, based on feedback from the running program. The Strongtalk papers discuss this, but I can’t come up with a reference off the top of my head.
Ah, that’s interesting. My C/C++ background meant that I saw static types, and leaped to the (incorrect!) conclusion they’d be used to optimize message sends. I’ve now read through the entire strongtalk tour which comes with the system, and I now understand how the optimizer works. 🙂