When browsing using the System Browser with a class selected, click the question mark in the second top pane to see the class comments.

The one for Mark is Object Design: Roles, Responsibilities, and Collaborations, by Rebecca Wirfs-Brock. It’s useful for a newbie to OO because it helps you learn to think about what you should make into objects, what other objects each one should know about and what each type should do. It’s not a coding book, it’s more of a “how to think about the problem” book.

Ramon, have you seen Working Effectively with Legacy Code, by Michael Feathers. This book deals with converting a big, existing OO application that was built with pervasive dependencies of the kind you mentioned above to one that has eliminated the dependencies enough to build unit tests for everything. It looks at specific situation(with Java examples) in a similar way to Kent’s Smalltalk Best Practice Patterns. I bought it while working on a large, 10 year old VA Smalltalk app that’s deployed in production in corporate America, and is being improved and extended.

It’s easy in Smalltalk as well, just type in “html inspect.” in your render method, and you’ll see an inspector on it. From there, you can see what kind of object it is, highlight the class name, click alt + b, and you’ll be looking at a browser on the class. Be sure to read my Terse Guide to Seaside, where I simply tell you what all those things are.

Types aren’t as necessary in a runtime system like Smalltalk, you have the live object there, just look at it. Static languages let you see what type an object “should” be, Smalltalk lets you see what the object actually is, and pick it up and play with it, send messages to it, things you can’t really do in many other languages.

You’re right, it’d be easier if you could see how Smalltalkers work, but I’ve never done a screen cast, maybe I’ll look into it.

What about learning Squeak? It is very easy to get lost/confused in Squeak. Here’s an example:

1. Open up an image that has Seaside installed.
2. Open a SystemBrowser and navigate to any renderContentOn: method (like WAStore renderContentOn:).
3. Where does the “html” argument come from? How can I find out what class “html” is? In a static language, this is easy since the method signature has the type included.

Why is there a PackageBrowser and a SystemBrowser? I notice that the PackageBrowser has comments for the Objects (necessary when getting to know the architecture) but the SystemBrowser does not (at least by default). Is there a way to view Object comments in the System Browser? When do you use one versus using the other?

I realize that issues like these are relatively minor stumbling blocks for newbies like me and I can sense the power behind Seaside, but a bunch of these stumbling blocks in a row create frustration. Are there any videos demonstrating “typical development” in Squeak? The Lisp videos out there are inspiring for people wanting to get into Lisp. Where are the Squeak videos? How ’bout some screencasts Ramon?

Your blog is a must read for Squeak newbie developers wanting to get into Seaside development. Your writing style is clear and to the point. Please keep it up, and sorry for the rambling.

TO MARK : The first book about OO should be Meyer’s Object-Oriented Software Construction.
It is about statically typed world but it is *very* *very* good. Quite provocative but the reasoning behind each choice (ex : when to use inheritance vs composition) is always clear and well thought. Design Patterns should come next I suppose and Refactoring third.

I picked up many of the little things by reading a fantastic book by Kent Beck called “Smalltalk Best Practice Patterns”, which despite the title, applies to far more than just Smalltalk. It’s a must read to understand how to think about everyday programming and what little things simply must be done well to write good readable object oriented code.

Some more favorites were Refactoring, Analysis Patterns, and Enterprise Application Patterns from Martin Fowler. He’s an awesome pattern sleuth and a great writer. Anything he writes is worth reading.

Then I read a fantastic book called Streamlined Object Modeling by by Jill Nicola, Mark Mayfield, and Mike Abney that really gets down and dirty about modeling business rules with the simplest possible set of patterns. Samples came in Smalltalk and Java, which had a nasty habit of showing just how ugly and verbose Java and its ilk really are, when stacked up with identical code in Smalltalk.

Domain Driven Design, by Eric Evans is also a great, if not extremely long read. This guy’s done some serious thinking about code. His depth is amazing, and quite beyond me, but I still pick it up on occasion and try to grok more and more of his thinking.

I’ve also learned a great deal simply from reading the sources of Seaside, Magritte, and Scriptaculous. Lukas and Avi are fantastic programmers and I’ve learned a great deal about how good frameworks are written, from using and extending theirs. There’s nothing like using great code, to teach you how to write great code.

These are the programs and books that have shaped my style the most, I’m sure others have different lists, and I’ve left quite a few out, but these are my favorites.

Functions should also be composeable.

Of course there’s the matter of whether state is better modelled by objects or monads, as a Smalltalker, you can guess my response to that.

Once you cross that barrier, you’ll find that the correction to software modelling already has a name - functional programming.

I admit my apparent “zealotry” in encouraging the use of a pure, monadic, lazily evaluated functional language (for similar reasons re: modelling software) - so I would recommend Haskell.

Gah, I just realised I’m on a Smalltalk forum - I’ll probably get nailed for this comment.

Tests can help turn the light on for some people, but once that light comes on… you don’t need tests to write nice composeable objects. Not that having tests is ever a bad thing.

As far as pain goes, yes, I think we do all have to feel the pain ourselves. Pain is memorable, some of us can learn from a more experienced person, but most need to suffer a little bit themselves to “believe” what they’re being told.

another guide to avoid coupling to your surrounding infrastructure / context is test driven design. don’t understand me wrog: you don’t have to write your tests first (for me test driven is not implicitly test first), but keep testability in mind. i often ask myself ‘how big would be the pain to test this class? … can i mock the dependencies in an easy way?’. you almost come automatically to a design with low coupling and therefore to a better chance to reuse or combine your objects in new ways.

the only question that remains is if you also have to make your own experiances in order to ‘feel’ the pain should you write some tests for your classes … :o)