Author: Andrew

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.

In C++, exceptions have many advantages over traditional “error return values”. They’re harder to ignore, they’re a lot more flexible, you can use them in constructors, they don’t use up your return value slot, etc etc.

I’ve just noticed another advantage. Imagine you’re doing old-style success/failure return values. Somewhere in a deep chain of calls there is a failure, which gets manually propogated up to the top level. At the top-level, you get a failure value but how do you find the original failure point? Usually by binary searching down through the code.

If you’re using exceptions, you can set the DevStudio debugger to stop at the point where an exception is thrown. This immediately shows you the failure point.

Then again, you could always just code in ocaml and use it’s timetravelling debugger! In ocaml, you run your program until you notice the failure, and then you go backwards in time to find the original failure point. Ocaml rocks.

This Kuro5hin article about ” What’s wrong with C templates?” has lots of interesting questions/answers after it.

I’ve been eval’ing the IntelliJ IDEA java IDE recently. I’m not currently writing any java programs, so I dug out my old raytracer to try out the browsing and refactoring tools on. I’ve been hugely impressed by the feature set. The basic GUI is well thought out and useable. The autocompletion and refactoring facilities work well. It has many “intentional” features – for example, you can type in code which refers to non-existant functions/classes, and it’ll provide a little icon which allows you to choose “create this class” or “rename this reference”. It is integrated with CVS, JUnit and Ant. It also has it’s own local version control system, so you can ask it “what changes did I make in the last 5 minutes”. I’ve not yet found out how it handles searching API documentation, and it does require a whole heap of memory. But, it’s definitely way cool. Java isn’t the best language in the world, but IntelliJ idea makes the whole kaboodle very attractive.

From LtU, A brief introduction to Naked Objects. This sprung up in response to a question on squeak-dev along the lines of “if squeak if so OO, why do we use so much ascii text?”. This is closely related to work done on the Self language, which I looked at a few weeks ago. Self is a runtime-typed OO language, but without the notion of classes. Objects aren’t instanstances of a class. They just are. Self also has a morphic-esque direct manipulation GUI whereby you can leap in an manipulate any object directly. The big idea behind Self is one of a consistenly present world of manipulatable objects, much like the real world. Unfortunately, the Self runtime is only available on Mac and Sparc, of which I have neither, so I can’t play with it. But, the ideas are interesting. C++ certainly doesn’t present a “consistent” view of the world – using a std::map from the “source world” and using it in the “executable world” with the debugger are as different as night and day. Or at least they will be until someone writes a nice debugger plugin API for displaying custom types.

The other gem I’ve recently discovered is the ever-popular Big Ball of Mud programming pattern.