Well there are version control tools in Smalltalk land. The primary one that ships with Pharo is called, Monticello [0].
Images are also a huge advantage which the author has obviously not had time to exploit.
Knowing next to nothing about Smalltalk before the summer I checked out Pharo and wrote a small application to scrape the HN front page and display the links in a Painter window. I watched a few videos, read some tutorials, and eventually had a working Smalltalk program in a couple of days. It was actually a pleasant experience.
A typical workflow starts by writing a snippet of code in the playground that instantiates the program you want to run. You execute it and get dropped in the debugger. You slowly add the missing methods and tests, stepping through the debugger as you go, and eventually your program runs. If you ever need to take a break you can save your image -- debugging session and all -- and pick it up later. There's no need to load up your source code and try to rebuild your application state to get to the point you were at when you last left your work.
That's really powerful for interesting systems like the Moose platform [1].
Overall I think the author is too biased to his existing tools to appreciate what Smalltalk is really about.
Original author of the blog post here. I find it interesting that your takeaway from my blog post is that I am writing unfavorable over smalltalk. I quite liked it. I think I mentioned that I was checking out Smalltalk, didn't claim to summarize longer experience with it.
Images are also a huge advantage which the author has obviously not had time to exploit.
Knowing next to nothing about Smalltalk before the summer I checked out Pharo and wrote a small application to scrape the HN front page and display the links in a Painter window. I watched a few videos, read some tutorials, and eventually had a working Smalltalk program in a couple of days. It was actually a pleasant experience.
A typical workflow starts by writing a snippet of code in the playground that instantiates the program you want to run. You execute it and get dropped in the debugger. You slowly add the missing methods and tests, stepping through the debugger as you go, and eventually your program runs. If you ever need to take a break you can save your image -- debugging session and all -- and pick it up later. There's no need to load up your source code and try to rebuild your application state to get to the point you were at when you last left your work.
That's really powerful for interesting systems like the Moose platform [1].
Overall I think the author is too biased to his existing tools to appreciate what Smalltalk is really about.
[0] http://pharo.gemtalksystems.com/book/PharoTools/Monticello/ [1] http://moosetechnology.org/