Smalltalk: Welcome to the Balkans
threeriversinstitute.org
threeriversinstitute.org
Can somebody who likes VW expound on the advantages it provides?
That said, I too find it a bit disturbing not to be able to import/export changes to the base image as text-files and being unable to build a clean image from source-code only.
I also find that disturbing. Another vthing i find disturbing, which may be a related problem is that although Smalltak lets you do all sorts of cool things like rotate its menus 30 degrees while the application is still running, often it just doesn't do what I expect for no apparent reason (other Smalltalk programmers seem to have the same experience). I suspect this progem is related to the fact that you can't simply get the state of the system as a set of text files. For me, at least, developing in Smalltalk feels a bit like walking around wonderingg whether I'll fall in the quicksand.
But can you do this in Smalltalk? OK, you have inspectors that show you a representation of your data, but the representation is incomplete. I haven't used Smalltalk in years, so I'll gave an example in Python to show what I mean:
>>> a = [1,2]
>>> b=[a,a]
>>> c=[[1,2],[1,2]]
>>> b
[[1, 2], [1, 2]]
>>> c
[[1, 2], [1, 2]]
>>> b[0][0]='x'
>>> b
[['x', 2], ['x', 2]]
>>> c[0][0]='x'
>>> c
[['x', 2], [1, 2]]
It's a different language, but I found this paper on making SBCL (a lisp compiler) build from source interesting: http://www.doc.gold.ac.uk/~mas01cr/papers/s32008/sbcl.pdf
The previous situation was that the CMUCL compiler, which SBCL forked from, was essentially defined by the image, which was incrementally changed into new versions--- and over decades this process had made the source code that was nominally "the CMUCL source" increasingly different from the in-memory image that was actually CMUCL.
I still find the image-based model vaguely fascinating in its blurring of the compile-time/runtime distinction, something that occasionally gets resurrected under various guises: http://en.wikipedia.org/wiki/Interactive_programming
An exception got thrown? The code browser takes you to the method that did it. You fix the error, and repeat the action that triggered the exception, and since the application doesn't completely die, you only need to repeat the last step.
It's crazy ... with the obvious disadvantage that it's hard to export / import source-code. That's why frameworks are distributed as already built images.
In those days, there were only two good ways to "version" your code: 1 - copy the entire image pared with "changes" and "sources" files; 2 - "file-out" some or all of your code to a text file. I did this often. It is fair to say that less professional developers did not do this, but that's no different than today's developers that don't use any form of version control.
While file in and out is a pain for large amounts of code, monticello and metacello make bringing code in and out of an image quite easy.
I wasn't particularly comfortable when I started. It was new, foreign and none of my tools that I was used to worked. I couldnt find all instances of string 'XYZ' and replace it with 'ZYX' in the ways I was used to and it bothered me but if you give a system like smalltalk enough time, you will see the advantages.
I have a hard time now when I'm working in ruby, perl or any other language where I don't have a debugger that can halt at any point in running code so I can examine everything about it: all my data, code, everything. I can run snippets of code against that data to verify results and then update my code right then, hit proceed and my bug is fixed. I never liked debuggers before smalltalk and now I know why, most debuggers are just too limited. I remember the glorious C days of finding the suspected cause of a bug and then recompling to test to make sure it was it. I remember the web app development days of logging and print statements.
What I have now when I do web development in Seaside is the ability to drop a breakpoint into any location in my code, get the debugger and quickly see, test and fix any issues I'm having. I love it and don't want to go back.
There are, however, tons of things I want to change about Smalltalk and the various communities that surround it, but for me, the core experience is second to none that I have ever experienced.
I could just as easily say how can anybody use a development environment that only exposes the source code in something as archaic as plain-text files?
Files may make working with known tools easier and may have all kinds of advantages in other areas such as deployment, but images are far superior for the actual experience of developing working code. Tinkering with live objects real time beats the hell out of a run/compile/debug cycle that throws everything away and starts from scratch every time.
1 - I used to have a commercial app framework in smalltalk. You could take a fresh Digitalk smalltalk system (or even one with lots of mods as long as there were no namespace conflicts) and "file-in" my app framework code and all was well. The tools of that day allowed you to "file-out" the code to a plain text file(s) or save it in object repos with revision history.
2 - Porting between the two major vendors of the day, Digitalk and ParcPlace, was trivial if you were a solid smalltalk programer.
For the last 10 years, I've on and off tried to use smalltalk again, but the tool sets are horrid compared to what they used to be. A 1994 Digitalk smalltalk was a great toolset. Maybe in a few years, Pharo will be on par with what we had then.