The Fnordistan Department of Software Engineering

This is my first attempt at a tutorial. The process of packaging a VisualWorks development image as a runtime image for deployment is covered in much more detail in Cincom’s Application Developer’s Guide. However, I thought it would be worthwhile to write a simple illustrated guide to cover the basics.

The tutorial is here.

I welcome comments, corrections, etc. I will finish the tutorial with a how-to on compressing the image and using ResourceHacker to make a Windows executable shortly.

Just a small update to SmallRoller, with an auto-scaling probability chart. I have also made the sourcecode available.

I have been writing programs in Smalltalk at home for my own edification, while in my regular job I am mostly working in Java nowadays.

When I first started learning Java, I had no idea — no idea — just how much Java owed to Smalltalk! I still didn’t really appreciate it until recently, when I started digging into Smalltalk more seriously. From the notion of everything descending from “Object” to garbage collection to the inheritance model to polymorphism, almost everything Java does is basically aping Smalltalk. Often not very well. I am using Java’s Collections a lot, and even though Collections are a relatively new transplant from Smalltalk, compare this:


for (Iterator iter = myList.iterator(); iter.hasNext(); ) {
myThing thing = (myThing) iter.next();
thing.doSomething();
}


with this:


myList do: [:thing | thing doSomething ]


I’m not just griping about syntax here; which one, conceptually, looks and feels more elegant, more intuitive? Look at all the method calls and casts you have to do just to iterate through a list of arbitrary objects in Java.

That’s the sort of thing I didn’t really notice until I started working with Smalltalk. Now I shake my head and wonder how much better life would be if it had been Smalltalk rather than Sun’s Java that had been poised to catch the wave in the 90s.

Now, some Smalltalk constructs still feel more awkward to me than the Java equivalents. For example:


if (boolValue) {
doThis();
} else {
doThat();
}


feels more intuitive to me than:


boolValue
ifTrue: [ doThis ]
ifFalse: [ doThat ]


But I realize this is a matter of taste, and being more comfortable with familiar syntax.

Frankly, I like Perl’s flexibility even better in this regard:


doThis() if $boolVal;


or


$boolVal or doThat();


Actually, this is all a good argument for programmers to be multi-lingual. I don’t think anyone can be a “master” of any language until they are fluent in many.

Here is a good article on the advantages of dynamic typing. I am becoming convinced that the “advantage” of static typing is that it provides minor babysitting services for bad programmers. Try writing a Java package that performs all sorts of calculations with int, double, float, and long data types and has to go back and forth between them…. the need to cast, convert, and develop special ways of handling “loss of precision” will drive you nuts.

SmallRoller has been updated. Version 1.1 adds the ability to display a probability graph for the dice settings you choose. I have also made available an image file which will run on multiple platforms (including Macs and Linux), though it requires you have VisualWorks from Cincom installed first. Feel free to leave comments or bug reports.

The next improvements I plan to add, as time allows, will be the ability to calculate “open” die rolls and other non-standard dice combinations. Eventually I’d like to allow probability calculations for multiple game system and user-defined dice types. DicePro does a good job of handling almost every imaginable dice type, but does not calculate probabilities.