Smalltalk for Scripting

Blaine makes the case for Smalltalk as a scripting language:

We all know that scripting is helpful for kicking off systems, moving files around, querying the state of a running application, and etc. This is available off the shelf for every Smalltalk dialect that I know of. The cool thing about scripting in Smalltalk is that since you have a powerful environment around you, you can write your script in a workspace. Now, if your script gets too big, you can start moving it to classes and refactoring. You can also move scripts to external files and load them in a runtime. Why do you configuration files when you can have runnable code that does it for you? Let the objects do the talking! Scripting is also great in running systems. If you run Smalltalk in headless mode, you can have scripts that query the state of the system while it's running! This can be very powerful and DANGEROUS! But, wait a minute, we have access to the compiled code and we can actually query the compiled code to make sure it doesn't do anything nasty. The bounds are limitless and once you start thingking about them, you wonder why am I writing unix bash scripts and then, you might be wondering, why not have the power of a compiled language, but the expressive power of an interpreted one? Smalltalk is all that and a whole lot more.

Beyond that, it's not hard to make VisualWorks (part of Cincom Smalltalk) act as a "real" scripting tool. You can set up an image that will read from stdin, expect to find a script (Smalltalk in file-out format) - load it, run, and exit. It's not perfect in that role yet - but it's one of the things we are working on at Cincom.