Smalltalk: Welcome to the Balkans

http://www.threeriversinstitute.org/blog/?p=466

by abyx • 16 years ago

43 22 16 years ago

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?

rbanffy2• 16 years ago

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.

cabalamat2• 16 years ago

> 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.

larsr• 16 years ago

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.

spooneybarger7• 16 years ago

You can do both of those things. You can file out changes and you can use text files to load in and build an image, it just isnt very commonly done.

_delirium• 16 years ago

> being unable to build a clean image from source-code only

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

bad_user• 16 years ago

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.

wingo• 16 years ago

I seem to recall hearing (from the GNU Smalltalk author) that the text representation of Smalltalk isn't even standard. See http://www.gnu.org/software/smalltalk/manual/html_node/Synta..., for example.

spooneybarger7• 16 years ago

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.

spooneybarger7• 16 years ago

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.

gnaritas• 16 years ago

> 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.

vladev• 16 years ago

what does this has to do with the Balkans?

matasar• 16 years ago

He's referring to Balkanization:

http://en.wikipedia.org/wiki/Balkanization

jhancock2• 16 years ago

It didn't used to be this bad:

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.

Smalltalk: Welcome to the Balkans

Related Stories