This surely will sound like a troll, but the main thing that struck me here was the statement: "Just getting the code out of VisualWorks was a pain." How can anybody use a development environment that doesn't expose the source code in plain-text files?
Can somebody who likes VW expound on the advantages it provides?
Using a fully relective image based system like various Smalltalks provide can be very disconcerting at first when you are used to files.
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.
The advantage when working with Smalltalk is that your application is alive, all your objects are alive ... it's like working in "irb" or "ipython", but with a true IDE that can do all sorts of things.
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.
Why? Well, smalltalk didn't always have nice OO code management tools. You used to have a good handle on your "changes" and "sources" files. At one point (early '90s), it was not a problem to take code from a text file you "filed-out" in Digitalk smalltalk and "file-in" the same text in ParcPlace's smalltalk.
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.
You can file code in and out of every smalltalk I've ever used. Its just a pain compared to getting an image. Or on most smalltalks now, you can just load monticello packages in ( its a smalltalk code & object distributed versioning system ).
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.
Smalltalk has been using images since ever. The image contains your world - your code, development tools and all your complete environment, preserving its state between your sessions. When it's time to deliver the application to its users, you just take out whatever is not the application and its dependencies and give the image to your client.
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 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.
I find having a live interactive debugger on the actual data makes it far easier to 'get the state of the system' rather than some text files which have very little to do with the state of the system and usually just represent code whereas a 'system' is a combination of code and data.
That's a very valid point -- actually being able to see the state of the data it very important in knowing what's going on. As Brooks and Raymond put it: "Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."
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]]
(b) and (c) initiallly have the same representation, but they behave differently. I don't like this, so I'm creating a language where the text representation of an object defines how it behaves: if two objects have the sdame representation, their internal structure is the same, and their behaviour will (with one exception) be the same. This representation format is used as a serialisation format, and is also used to write literals in the language. This means that it's possible to display precisely the value of any object, including all the sub-objects it contains.
Yes you can because 'a' is an object and your array [1,2] is a different object. They have the same value but a different identity. You can use a smalltalk inspector to see both value and identity.
There are objects in the modern day Squeak image that were created when Smalltalk-80 was released. In fact, if you explore around Squeak's image, you can find all sorts of disconnected bits and pieces that nobody uses anymore, that are just along for the ride because they are in the image. Sort of Smalltalk pseudogenes. It's organic, very different, and to me as a biologist who likes to program, quite fascinating.
There are some good points about how many people use images in this avi bryant interview that is completely different from the 'steroetypical' idea that many people have of how 'everyone' uses images:
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
> How can anybody use a development environment that doesn't expose the source code in plain-text files?
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.
Can somebody who likes VW expound on the advantages it provides?