ddfreyne

This appears to use the theoretical schedule, rather than real-time information. I live next to a busy tram line, and what I see through the window does not match what the site shows.

In case you couldn’t tell from the old-school theme, this web page hasn’t been updated since late 2008 (2008.11.28).

The analogy given in the article is pretty accurate. The Smalltalk environment is unique in that it allows very easy access to the libraries, the IDE and the language’s internals (including the compiler!). The Smalltalk debuggers are among the best ones I have ever used.

(I’m mostly speaking out of my experience with VisualWorks, a commercial Smalltalk implementation, but other implementations are similar.)

I would greatly recommend everyone to give Smalltalk a try. The IDEs are pretty ugly and cumbersome, but don’t let that put you off. Get a feeling of the minimalism of the programming language and the pure form of object orientation. Dig through the code of the standard library — it’s quite easy — and check out the implementations of TrueClass, FalseClass, BlockClosure etc.

Unfortunately, many parts of the Smalltalk IDEs are horribly outdated and make Smalltalk a very poor choice of environment to use for production code.

Smalltalk lives in its own little world, and the tools that you’d normally use during day-to-day development are integrated in the IDE, and there is virtually no possibility of using external tools. The text editors are pretty bad, and you can’t use vim or emacs or Sublime Text. The Smalltalk VCSes are particularly horrible. For version control, you need to use systems such as Monticello or Store, both of which make me cringe just thinking about them again.

I also feel that Smalltalk coders get locked in into their environment. Many Smalltalkers that I have met are quite unfamiliar with what is happening in the outside world. Most of them have never heard of git, for example (and quite a few did not know what Subversion was). When an interesting technology enters the Smalltalk world, people seem to rush to reimplement it in Smalltalk (yes, there is STON — Smalltalk Object Notation).

These were the main reasons why I quit my Smalltalk job. A sad decision, but one that was unavoidable in the long run.

Smalltalk is a nice language and has IDEs with some very nice features that I would love to see in other environments, but it is also severely lagging behind in many other areas. I would like the Smalltalk community to be more aware of what is happening outside and build bridges. Without that mindset, I feel Smalltalk will simply fade out completely.

Source: I used to be a professional Smalltalker for almost three years.

There is a typo: foo2.ord in the first class Foo(T) example should be foo2.value.ord.

I admit I did fall into that trap once, long ago. I’m very aware of the consequences now.

The reason for writing the article, however, is because I have seen the same mindless behaviour with other people as well.

I believe it boils down to a matter of discipline.

If you say that you never randomly modify code in order to make it work (according to the tests), then that is great, and that is how every developer should work. However, my experience is that people who lack discipline (or face a looming deadline) tend to not take their time to properly reason about code and instead rely on the test suite to tell them whether code is right or not.

I (sadly) average 1 article written per 3 years, so there wouldn’t be much of a point in creating page views.

I have occasionally been tempted into the mindless code modifying that I described. That is in the past though!

More importantly, I have also seen this happen in professional environments. A very large test suite is very useful, but it is absolutely not a catch-all safety net.

I was using iTunes playlists as an example that switching to different parts of the UI does not interrupt playback.

I admit that the behavior is quite odd at first, but once you get used to it, it is really useful. It is the behavior you would expect in a desktop app — for example, you wouldn’t want iTunes to stop playing when you select a playlist, would you?

On FOSDEM a couple of years back, that question came up during a talk as well. IIRC, FreeBSD needs a VCS where they can delete changesets permanently, for legal reasons.

For distraction-free writing, I prefer vim in a fullscreen terminal.