Meta

Archive for the ‘Ruby’ Category

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 Scratch (a visual programming language). This is the third of my comparisons in this series, where the first one was in Ruby.

Ruby has a strong recommendation against using CamelCase for method and variable names and to use only underscores instead. There are lots of arguments out there on different naming conventions, and whatever side I pick in isolation is fairly irrelevant since either the whole community or the individual team has to chose the best approach.

Tower of Hanoi — Rules on Rails

In part 6 we changed the algorithm of Tower Of Hanoi to work without requiring the stack — it instead “more naturally” put sufficient state and logic into the model that the model could start and stop and continue as needed. I believe with Ruby 1.8.x, this is required to have Rails be able to work with the Tower of Hanoi. So we should try it out and see how well it works 🙂

Tower of Hanoi — With Rule Disks (and no stack)

The first passes at the Tower of Hanoi algorithm were all done with the algorithm being a recursive call on the stack. This is ‘true’ as an algorithm, but comes off as a bit unnatural for humans.

But it also has a problem in that the algorithm can not be ‘suspended’ in mid activity unless the language allows a feature (called a continuation) that can suspend the stack itself. Although Ruby is multi-threaded and running two threads works in RubyShoes, Rails does not work either with a stateful server (and multiple threads) or with continuations. At the end of each controller dispatch the session or the database has to have persisted all state. So we need to do something like formalizing the state of the Disks and Towers to make the Tower of Hanoi work with Rails.

Also, the Smalltalk code in this section was among the most ‘closure-oriented’, so this helps show how that maps to Ruby.

Tower of Hanoi — With Rule Disks (and no stack)

The first passes at the Tower of Hanoi algorithm were all done with the algorithm being a recursive call on the stack. This is ‘true’ as an algorithm, but comes off as a bit unnatural for humans. But it also has a problem in that the algorithm can not be ‘suspended’ in mid activity unless the language allows a feature (called a continuation) that can suspend the stack itself. For a multi-threaded language, this inability to suspend may not be a problem because you could create one thread for the algorithm and another thread to listen for whenever a new (interesting) change in state occurs. This is how the RubyShoes version works: the algorithm is in a new thread separate from the GUI thread (otherwise things behave badly). Similarly, the Smalltalk-80 GUI is being drawn in a different thread than the main execution thread. But in many circumstances even this multi-thread version would not work: say you have a client-server version (e.g. Rails) or want to pause/suspend the execution of the 100-tall tower of hanoi. And finally, if you only have a single-threaded language like Flex, things just don’t work at all for intermediate renderings unless you can make the algorithm not be dependent on the call stack.

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. Flex lives inside a Flash player (or app), so it is inherently capable of doing sophisticated graphics. Actually it is hard to ‘contain’ yourself to just doing the simplest possible thing when animating sprites around the screen is very easy. But to try to compare Flex to Ruby and Smalltalk, we want to keep things in about the same ballpark — and again study how different languages work with the same problem.

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. Even though Flex has no issue with graphics, I want to separate these two changes both to match Ruby and because the changes are logically somewhat separate. So first we can put in Disk objects and study that change. After that, we can go into the GUI code.

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.

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.

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.