Tag Archives: Smalltalk

New Tricks

I recently resumed working a bit on a VA Smalltalk-based system I first created over a dozen years ago. VA Smalltalk is a fantastic programming environment, but I quickly realized how much I missed automated build packaging in that world. Each build takes only a few minutes, but it’s manual, requiring clicks through a GUI and waiting for results. I wanted this to now be automated like the rest of the continuous integration free world.

Fortunately, some folks have recently built tools to help.

I started with Ernest Micklei’s Melissa tool, a handy EpPackager front-end for scripting builds.  Using it to automate builds for our headed (GUI) images was straightforward: I just created a workspace and CMD file for my particular requirements.

But scripting headless (cross-development, XD) packaging was not so simple, due to the nature of passive images and the fact that the controls are hopelessly embedded in the XD development UIs.  Eventually, I found that Thomas Koschate cracked that nut with his nice HqaAutomatedBuildSupport tools (available at VASTGoodies.com).  To use it, I mainly just created my own AbtBuildSpecification to specify the maps, subsystems, and features to match what I used in my XD Image Properties.

For consistency’s sake, I wrote some code to invoke AbtBuildSpecification build from MelissaBuilder. When done, I set up the CMD files as Windows Scheduled Tasks (schtasks) to run overnight.

It’s a handy process, but clearly something that could benefit from standardization by the VA Smalltalk vendor.  For example, there are different ways to script startup loads: abt.cnf, Melissa, AbtImageStartup, or some combination of these.  Perhaps our friends at Instantiations will soon include this in the base product.  Our venerable community could certainly benefit from a common way of doing these new tricks.

PHP Ecterators

“…When in the why and the wherefore is neither rhyme nor reason?”

Shakespeare, The Comedy of Errors II.2

When it comes to the common workhorse task of iterating over a collection, there are nearly as many approaches as there are languages. And these varied implementations often demonstrate the relative strengths or weaknesses of each platform.  In languages with dynamic typing and closures, iterating over collections is typically succinct and elegant. Lacking these benefits, you get code-bloat train wrecks like C++ iterators and templates.

Fortunately, good approaches often get reused. Both Ruby and Smalltalk have what I alone call the ecterators: those venerable iterator methods whose names, inspired by Alice’s Restaurant, end in “ect”: select, reject, collect, inject, and detect.  In a single line of code, you can apply a code block across a collection and get the result.  I often think in terms of the ecterators, so I miss them when working in a language that doesn’t have them.

Such was the case recently when working in PHP.  Modern versions of PHP have helpful functions like array_filter, array_reduce, and array_map, and with PHP 5.3’s lambdas/blocks and closures, you can create a Ruby-like feel.  But those non-rhyming names and inconsistent parameters just don’t do it for me.  You might say PHP lacks some reason and a lot of rhyme.  So I took a moment to write some simple alias functions, like so:

        function select($array, $callback) {
            return array_filter($array, $callback);
        };
        function collect($array, $callback) {
            return array_map($callback, $array);
        };
        function inject($array, $initial, $callback) {
            return array_reduce($array, $callback, $initial);
        };

So now I can write familiar code:

        $numbers = array(1, 2, 3, 4, 5);
        $even_numbers = select($numbers, function ($ea) { return $ea % 2 == 0; });
        $squares = collect($numbers, function ($ea) { return $ea * $ea; });
        $sum = inject($numbers, 0, function ($sum, $ea) { return $sum + $ea; });

There, reason and rhyme.

Going to Xtreams

Perhaps a blog named “WriteStreams of Consciousness” has an implied obligation to cover I/O streams.  And since streams are among the most essential programming building blocks, I’m always interested in better mousetraps there.

Smalltalk is home to perhaps the first truly elegant streams implementation, particularly when compared to other approaches developed around that time, such as those in C and C++.  You can’t get much simpler than ‘myfile.txt’ asFilename readStream contents to open and read a file, and yet there’s significant power in the classes behind that.  But new designs for stream libraries since followed, including pluggable/chainable I/O stream architectures, such as those found in Java, C#, and even advanced parallel stream processing frameworks.

Not to be outdone, Michael Lucas-Smith and Martin Kobetic have recently developed a new pluggable stream framework for Smalltalk called Xtreams, and I couldn’t resist giving it a try.  In the authors’ own words,

Xtreams is an abstract producer/consumer pipeline over arbitrary source and destination types… you get a unified API for accessing files, sockets, pipes, strings, collections and many many other kinds of things.

It’s a Google Code project, but the code is in the Cincom Public Repository: just three mouse clicks away after downloading and starting VisualWorks.  It consists of several packages as described on the project page, along with SUnit test cases.  I loaded the base set of packages and walked through the examples in Michael’s basic primer and in the various package comments, while reading the wiki documentation.

Immediately, I found the basic API improvements (over conventional streams) refreshing.  But the real beauty lies in “stacking” streams, collections, and even block closures.  For example, this stacks an encoding stream atop a write stream atop a byte array to convert your string to UTF-8 encoded bytes:

(ByteArray new writing encoding: #utf8) write: ‘Hello’; conclusion

Or, to do Base-64 encoding (for sending binary data as text):

String new writing encodingBase64 write: myBytes

For arbitrary transformations, you can provide your own transforming: block, as in this example:

“Multiply each pair of input elements together and return the result”
((Array withAll: (1 to: 20)) reading transforming: [ :in : out | out put: in get * in get ]) rest

And why limit ourselves to strings and arrays on the inside (as terminals)?  Here’s streaming over a collection:

(1 to: 10000) reading ++ 1000; read: 5

… and a block closure:

| a b | a := 0. b := 1.   “Fibonacci”
[ | x | x := a. a := b. b := x + a. x ] reading read: 20

Stacking sources, terminals, and transforms: it’s nearly as much fun as the Mousetrap or Incredible Machine games, but without the Rube Goldberg chunkiness.

I only scratched the surface in playing around, but it’s a nice package, which is being further refined and extended.  If you’re a VisualWorks Smalltalker, give it a try.

While Smalltalk is an important incubator for significant technology innovation, it’s certainly not a “by the masses” language.  So if you’re hesitant to jump into a Smalltalk image and code away, just read the summary of what Xtreams does and ask, “can my streams framework do that?”  Hopefully we’ll soon see this kind of power and design elegance in other languages.

Contrast

I happened to notice that an SUnit I added today was number 1,000.  Perhaps I should get free groceries for that milestone, but it reminded me just how much and why we take xUnits and test-driven-development (TDD) for granted.  I was a bit more aware, having spent yesterday working on a customer’s C++ code which had no xUnits or test scaffolding.

It really was a study in contrasts.

For the customer’s C++ code, I found myself fighting in the Visual Studio debugger mostly with overzealous constructors and destructors (folks, just instantiate and delete objects in constructors/destructors, don’t use them for wild stuff like reading registries, calling decryption libraries, and connecting and disconnecting from databases).  But the real hassle was having to run the code-compile-link-bounce-deploy gauntlet far too many times.  Often this isn’t bad (yes, incremental compile and auto build all help), but in this case, it took a lot set-up time getting data in the state it needed to be in before calling this code, and every code change required repeating that.  That’s usually true even of hot swap JVMs.

Compare that to my SUnit-driven VA Smalltalk code.  I wrote the test case and my first stub method before I wrote the code.  I ran the test, and of course, it failed (failed big, too: red, not yellow, due to an expected message not understood exception).  I re-ran the SUnit with Debug, and started filling in the code – in the debugger.  I added methods and even an entire class that didn’t exist before I started debugging.  I inspected objects and ivars and even changed a few to guide me through crafting and whittling at the code.  I ran it again and got to yellow.  One more “code it while debugging it” pass and the test went green.

Red, then yellow, then green.  My favorite development process.

I’ll soon upgrade my Visual Studio 2008 to 2010 and look forward to the new features it offers (thank you, Microsoft for finally bundling ASP .NET MVC, and for abandoning your own JavaScript kluges and just adopting jQuery).  But, decades later, it’s still nowhere near as productive as VA Smalltalk, VisualWorks, and Pharo, where you can write the code in the debugger while the system is still running and never have to stop it.

Why haven’t we learned?

Make an Object for That

“I wanted nothing else than to make the object as perfect as possible.”
Erno Rubik

I recently enhanced one of my search functions to support additional criteria.  It was originally a very modest search, accepting only an account number and amount.  But, over time, search fields and flags were added and the primary method grew to accepting a very long parameter list, and then to receiving a tightly-coupled dictionary of search keys and their values.  I looked at the method and thought, “what idiot wrote this thing?”  That’d be me.

It’s an easy trap to fall into.  Layering new functions atop an existing O-O system requires ongoing diligence to refactor and maintain clean design patterns.  The temptations are many; for example, standard objects like those workhorse collections can lure one away from crafting valuable new custom classes.  But there are defenses, such as a good library of xUnit test cases to support refactoring.  Good design and test-driven development pay dividends long after the original code is written.

In this case, a command object did the trick.  Have a findPersons* method that takes far too many parameters?  Create a PersonSearch or PersonQuery command/value object to house them.

There are many benefits to this besides cleaner code.  xUnit test cases usually come easier and are less brittle.  You can better factor behaviors such as validation and conversion onto the command object itself.  This can improve reuse across the client and server.

A basic security requirement for any rich web or client/server system is that validation occurs both at the client and at the server.  If the command object is commutable, this means you write the validation code once, to be used on both sides.  This works well with Google Web Toolkit (GWT), Server Smalltalk (SST), and similar frameworks.

This sent me on a brief witch hunt; for example, I searched for related methods with too many parameters: MyClass methodDictionary do: [ :ea | ea parameterCount > 3 ifTrue: [ Transcript cr; show: ea printString ]].  I found and fixed a few, and toyed with a Smalllint rule for it.   It never seems to end with the perfect object, but often much closer.

Let My Smalltalk Go

At some point while building etoy and Croquet pyramids in Egypt, Seaside happened.  But the Squeak children grumbled amongst themselves rather than pursue this new promised land with fixed purpose.  Aliens who just wanted that milk and honey (Seaside) had enough on their hands learning Hebrew (ahem, Smalltalk) to be bothered  by Squeak traditions.  So the sea parted and a new Smalltalk platform arose, taking Seaside contributors with it.

Pharo [sic] is a Smalltalk platform built from Squeak.  It’s smaller and cleaner than Squeak, and is replacing it as the Seaside base in that lineage.  The development and licensing model is very deliberately a benevolent dictatorship in order to focus efforts and push the community forward more quickly and efficiently.  Perhaps democracy is overrated.

My first reaction upon downloading and using Pharo is that it’s “Squeak with a haircut.”  The look and feel is cleaner (Mac-like), and there are no bright colors and etoys.  By default, it retains Squeak’s “one OS window” presentation, but that hardly matters when you just want to do Smalltalk and use it as a Seaside platform.  The base class libraries are very familiar, and it comes with all the expected browsers and tools, like the SUnit TestRunner and Monticello source control.

Loading Seaside is just one ScriptLoader loadSeaside30 away.  It gets even easier than that: the Seaside One-Click Experience is migrating from Squeak to Pharo.  That’s further evidence of Seaside’s new emphasis on Pharo over Squeak.

For a 1.0 RC 1, it’s quite stable and workable.  I did get several tool walkbacks, but nothing that I couldn’t work around and occasionally debug.  I’ll definitely keep an eye on this as it continues marching to the promised land.