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.
I created a register-based VM named RCPU, for educational purposes. You can find it at https://github.com/ddfreyne/rcpu. It has most of what you’d expect from a register-based VM, and even has video output (rcpu-assemble samples/video.rcs and then rcpu-emulate the resulting file with --video).
I have been using sublime-markdown-extended (https://github.com/jonschlinkert/sublime-markdown-extended), which has the nice feature of recognising and highlighting frontmatter blocks. Would love to see frontmatter support in the MarkdownEditing package as well!
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.
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 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 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.
I do not know the situation in the US, but there is a legal maximum of 12 minutes of advertising per 60 minutes in Europe, which boils down to a legal max of 20%. 50% seems unrealistically high.