Learning to read smalltalk

Smalltalk has a very simple grammar (it must be true because all the books say so). However, just because the syntax is easy, that doesn't mean it is necessarily easy to understand the code. Take this as an example

renderContentOn: html 
html table: [(self sortBlock 
value: (self filterBlock value: self items)) 
do: [:item | html tableRow: [self renderItemBlock 
value: item 
value: html]]].

I struggled with this for a while, mainly because I was trying to read it left to right. Whereas, what I should have been doing is reading it in unary, binary, keyword order. When you look at it that way the central block becomes more like this:

1. get the list of items
2. filter them by passing the complete item list to the filter block
3. sort the item list that is returned by the filterblock
4. iterate over the sorted list and render them.

It all makes perfect sense, once you get the hang of it.

Things are so much clearer in the morning

I don't know whether this is true of all programming languages, or whether there is something odd about Squeak, but it is amazing how things that made no sense the night before, are suddenly blindingly obvious the next morning!

Objects and messages - that's your lot

I had a problem, yesterday, trying to work out what -> meant. I came across it in the Seaside tutorial and couldn't find any reference to it in my various Squeak books.

Fortunately, the Beginners list offered an immediate answer. It is an infix operate for creating an Association. It is a bit like typing 1 @ 1 would return a Point. The answer is obvious, after the fact, but I was confused at the time.

Thinking about why I was confused made me realise that I still hadn't fully understood the concept of objects and messages, or perhaps to put it more accurately, I hadn't understood the fact that there really isn't anything else in Squeak. So, if what you are looking at is not an object, then it has to be a message. And, if it is a message, try typing it into a method finder window and see what it returns.

Seaside - wow that really is clever stuff

I had held off experimenting with Seaside because I - wrongly - thought that I needed to learn Squeak first. What changed my mind was a brief exchange I had, on the Beginners mailing list, about Morphic, Tweak and other UIs. I suddenly realised that Seaside was - in part - another rendering platform and therefore equally good for learning Squeak with.

Wow, having installed the system, I am really impressed. I will detail the impressive bits as I go along, but if you have been waiting to learn Squeak before tackling seaside, don't hold back.

And, we are back :-)

I decided to give myself a present. I have carved out some time - over the summer - to dive into Squeak. I finally realised that it just wasn't going to happen otherwise. So, this blog will now contain a lot more 'notes to self' and 'ahh, so that's how it works'.

Lively - Squeak for Javascript?

Dan Ingalls gave a really interesting presentation about his work on Lively. You can see the video here.
I have been following Lively for a while - as a side point, running it in Safari makes a heck of a difference to performance (not sure whether that also applies to Safari on a PC). You definitely don't want to judge the product based on Firefox.

Anyway, what really struck me about the video was the way Dan could execute javascript in the environment. Anyone who as played with Squeak will be immediately struck by the similarities. In fact, when you dig down into the code, the whole object model looks amazingly similar. I am going to have to find the time to play with this!

Getting a handle on objects from the Flaps

one of the things I really like about the Squeak environment is the flaps. Being able to pull tools straight into your project really fits the environment I want to create. However, I couldn't work out how to get programmatic control of the objects. Thanks to the Squeak beginners list, I now know the answer.

There are three ways to solve the problem:
1. Halo the object and choose inspect. You can then send messages to the object via the bottom pane of the inspector window. That's good, but it wasn't quite what I wanted because it didn't let me use the workspace to build up some code (although I could have done the coding in the inspector window, that wasn't really how I wanted to work)

2. Assign self to a global variable. This occurred to me as I was doing something else. The basic problem was how to get a reference to the object into the workspace I was using. The object must exist in the current project, but I didn't know where to start looking for it. So, if I did something like this Temp1 := self. in the inspector, then the object had just been assigned to a global and I should be able to reference it from anywhere - works nicely. However, I then started worrying about my Smalltalk dictionary getting filled up with rubbish. I am a minimalist at heart, and don't like 'stuff'. After some digging around I found that remove: object won't work in a dictionary, but removeKey: #symbol does. So that's useful to know too.

3. Finally, the way suggested in the list was to turn on the feature in the workspace (click on the menu item in the window bar) which supports "textual reference to dropped morph" or something like that - don't have the image in front of me. This means that when you drop the morph on the workspace, the morph's 'name' e.g. textbox3012 is written into the workspace. This reference can then be used as the object handle. This is a great solution except for the fact that if the morph name has a space in it, then the reference won't work. I must find out a bit more about this at some time.