One of my favored books in the 1980s was ‘A Taste of Smalltalk’. This was a very short book that gave you the flavor of Smalltalk programming (the language and IDE) as compared to Pascal, C, and Lisp. I believe it is always important to show multiple programming languages for concepts and this book followed that rule. The goal of this post-series is to take ‘A Taste of Smalltalk’ and apply it to Flex. This is the second of my comparisons in this series, where the first one was in Ruby.

This is a multi-part series. The first in the series is here.

Tower of Hanoi — With Graphics

To follow the flow of code progress within “A Taste of Smalltalk”, we next need to include a graphical representation of the disks and their movement between the poles. As mentioned previously, converting this part to Ruby has a problem: Ruby doesn’t include graphic capabilities. So we have to pick an extension or add-on to Ruby that will enable us to hook into the graphics system.

This is a multi-part series. The first in the series is here.

Tower of Hanoi — With Model Objects

The book “A Taste of Smalltalk” jumps from showing a single ‘TowerOfHanoi’ object to both adding in Disk model objects and putting on a graphical representation of those Disk objects. Given Ruby has no built-in graphic capability, I want to separate these two changes. So first we can put in Disk objects and study that change. This should work for anyone with a Ruby installation and does not require installing Tk or Shoes or anything. After that, we can go into some GUI toolkit code just to finish up the comparison and have bonus points.

This is a multi-part series. The first in the series is here.

Tower of Hanoi – With A Real Object

The first two examples were not really object-based. They are purely procedural, the algorithm is expressed completely recursively, and execution state is maintained on the call stack. This works fine if we are just ‘tracing’ the algorithm, but it does not let us show the state of the towers at any given time. We also don’t see much in the way of real objects. By adding the state of the towers in, we now have a reason to have stateful objects and new Classes of objects to maintain that state. The added code with some explanation is in Chapter 4, Page 45.

This is a multi-part series. The first in the series is here.

Tower of Hanoi – Procedural With Input

The second example from “A Taste of Smalltalk” is in Chapter 3, page 36 and does basic IO. Except that Smalltalk-80 includes a Windowing graphics system so it can automatically open Dialogs and other things. Smalltalk (started in 1972) was one of the environments that created personal computers and included abilities in its VM and Libraries that are now submerged into the operating system (some 30 years later). Now that these abilities are ‘intrisically’ present, there are many different ways to access them – so Ruby does not include graphics itself (in its own terms) but calls extensions that provide those graphics. Given I don’t really want to go into Tk or Web programming when discussing a language itself, I will simplify the problem and make it so we only need to get the value somehow… So ‘gets’ is fine.

One of my favored books in the 1980s was ‘A Taste of Smalltalk’. This was a very short book that gave you the flavor of Smalltalk programming (the language and IDE) as compared to Pascal, C, and Lisp. I believe it is always important to show multiple programming languages for concepts and this book followed that rule. The goal of this post-series is to take ‘A Taste of Smalltalk’ and apply it to Ruby.

There are lots of topics in programming languages, IT infrastructure, and system design that turn out to be all about persistence vs. being ephemeral. I don’t believe people realize it, but “being ephemeral” is the core question and the standard answer should be? 42. Which given it is >0 is ‘Yes’. So “Be Ephemeral” unless you can’t possibly be ephemeral.

There is also a PDF version here which might be easier to read because it has a bit more formatting.

There is also a PDF version here which might be easier to read because it has a bit more formatting.

This document describes the life cycle process used by the ABC project, the motivations for that life cycle, and how that life cycle was determined and implemented.  Our primary goal is to document ABC’s process so other teams can gain a better understanding of it and use it to help develop processes for other teams.  Our secondary goal is to continue documenting and crystallizing ABC’s process for use within the ABC team.  The ABC project was a specific project for the XYZ company, but names have been changed and any proprietary materials removed.  This makes the material available to a wider audience, with only a few holes.

The ABC project’s process has several salient characteristics that impact how it can be described. (1) It is currently in use within XYZ. (2) It has had several months to work our rough edges. (3) It was primarily guided with a core set of goals. (4) It is principally based on an integration of several documented and mainstream development practices.  So to describe the process we can alternate from the very concrete (“the ABC team does this”) to the more general (“Booch suggests doing this”).  We can also leverage existing writings and just describe the differences from those writings and how they were integrated into the ABC process.  We hope that connecting these differing abstraction layers and perspectives will both make the process more understandable and make the concepts more applicable to other teams.

This document describes the standards ChiMu Corporation uses for Java development.  Documenting these standards is important for our own needs and our customers, but we provide these standards publicly to help other teams who are establishing or growing their own standards.  These standards may also help developers to better understand good software design: they are especially designed to help a developer think about the issues (e.g. some of them are “radical”).  In many cases you may object to our recommendations and decide on a different standard, but the acts of reasoning about the issues and documenting your solutions is even more important[*].