http://ubuntuguide.net/display-clipboard-history-in-ubuntu-gnomeunity-using-diodon-indicator

It was *amazing* (in a horrible way) watching him, when changing to a different object, go through the following steps:

* Find his windows file window, and dig around in the filesystem to find the right file.
* Look around to see if he had an editor open already, and if he didn’t immediately see it, he’d just double-click the file to open a new one (unsurprisingly, this would get minimized when he wanted to find another file, so…)
* Use the “Find” command in the editor to get to the class name/method/whatever he was looking for. And if it matched a bunch of other strings, well, hit F3 until you find it!
* Do some work.

So when I mentioned Eclipse, and how much more productive I was in it, and showed him how choosing “Find Declaration” from a variable/method/class/whatever took you *right to that declaration*, in whatever file it was in, he was impressed.

Of course, he would never *use* Eclipse after I installed it for him… took to long to start! He could never get used to *not* closing the “editor” when he was done editing a file.

So, as I say, he is a pretty productive programmer. But not fun to watch…

It’s true that it needs some immersion to get the feel but once you can feel in The Zone, it’s great.

About the missing pieces:
1. Editor. True, why that happens? two reasons (a) we probably need more people that cares about usability and gets it and (b) all methods use to be too short to justify fancy editing so it never gets prioritized
2. Browser. One usually gets used to have open N browsers as a (pretty decent) workaround. A guy has made a framework to make browsers so if you have a great idea on how to redesign the developing experience its only a matter of design and dedication. This other guy has made tODE, an interesting approach to the problem: http://www.youtube.com/watch?v=FGkdXwGtfd8 he could use the help of a designer but developing a seaside application directly on the browser at least sounds interesting.
3. Source. The source code you usually save it in Monticello packages (Smalltalk’s Git commits) and, as you mention, it’s also all in the changes file. To be practical, if you save your code in packages, then you save the image and you are using OSX’s TimeMachine, then you are super safe.

Keep writing and experimenting!

PS: here is an essay I wrote about why I’m using Smalltalk
http://sebastianconcept.com/brandIt/10-reasons-why-im-using-smalltalk-for-airflowing

But they took me a *long* while to get used to, and of course there are tradeoffs. The VM lets me pop a USB stick with my app into any computer I’m likely to find throughout the world and run it. It also let’s me optimize bottlenecks by writing them as a C plugin to the VM. Also, the new JIT VMs are orders of magnitude faster in some cases, and in any case I’ve never noticed any speed problem. The final cool thing about the VM, especially in Squeak/Pharo, is that it is written in a subset of Smalltalk that gets translated to C, which means it can be coded and simulated in the image.

As for the image, I can’t live without the live, open, dynamic environment it brings; and enjoy the freedom from files. Also, many Smalltalkers constantly (like every day maybe) load their code into a new image to combat the “hidden things” problem. This is especially easy with Metacello, a recent package management tool; and a menu of easy persistence options to bring the data along with the code.

Some times is surprising to see how many contemporary techniques were invented in smalltalk a couple of decades ago.

The changes log is a plain text file – it contains all the code changes and new code you’ve added to the image.