In today’s episode of ADDcasts we are joined by James Ladd, an Ozzie Ruby developer. James leads the Redline.st project, which enables developers to write programs in Smalltalk that run on the JVM – like JRuby, but for Smalltalk. After some Redline discussion, James tells us what exactly he had in mind when he mentioned “immutability” last week, and talks to us about the design tradeoffs. We also discuss James’s East-oriented design compass for designing object-oriented code. Dave and Pat fight about whether procedural code is actually OO.
Interesting links from the show:
Podcast: Play in new window | Download (Duration: 56:14 — 64.4MB)
Podcast (video): Play in new window | Download (Duration: 56:14 — 841.2MB)
1. Comment by Jeff Heon
22/Apr/2011 at 9:45 am
That was a very entertaining episode
The immutability part 1, objects as values, reminded me a lot of Clojure’s approach to value, identity and state. A nice summary here: http://www.infoq.com/presentations/An-Introduction-to-Clojure-Time-Model
But part 2 of immutability, eschewing getters, seemed to be totally different that the Clojure approach, as it champions passing data around as hash maps where you associate new data easily or access data with a simple lookup, essentially a getter. Actually, I might be totally misunderstanding it.
In any case, the podcast was really interesting and I’ll spend some time trying to wrap my head around the East Oriented Programming. Thank you guys.
Oh and by the way thank you so much for putting the right meta-data in the downloadable mp3s. I’m use to have to put it by hand if I want to find it correctly in my iTunes afterwards. It was a nice surprise to have it already there.
2. Comment by Ben Mabey
23/Apr/2011 at 1:02 pm
Great episode.
Your conversation about the Writer/Formatter reminded me of this presentation on why getters on so bad that used the same exact example: http://bit.ly/fGjmu1
WRT immutability, Jeff is spot on with the similartiy with Clojure. I haven’t watched the newer presentation above yet but Rich Hickey’s talk on state, identity, and time is a classic: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
With clojure 1.2 protocols and records were introduced which really bring in the best of OO (e.g. polymorphism) without allowing the mutation apsect which is what tends to lead to such hard to understand OO code. Here is brief introductory article on protocols: http://www.ibm.com/developerworks/java/library/j-clojure-protocols/
Another really good read, especialy if you are coming from Ruby, is this post on doing FP in OO (Ruby): http://www.harukizaemon.com/2010/03/functional-programming-in-object-oriented-languages.html
Thanks again for the postcast!
3. Comment by james ladd
29/May/2011 at 3:31 am
recently I had a discussion on East and below is a part of that discussion – I hope it adds value.
Im interested in learning new ways to write software and make what I am writing more
readable to others, so Im ok with people disagreeing. I learn more if they do.
I think I led with a poor example and reasoning as I have limited time to think on
weekends as I look after my twin boys who are 2.5
Lets forget the accessor and mutator side of things and just focus on the implications of
asking an object for information and working on it, rather than asking that object with the
information to do the work. This is the key principle – Tell Don’t Ask
When we allow callers to ask for data and we want to know what they do with that data we have
to find all callers and look in detail at what they do with the data. Usually what they do with
it will be spread over multiple statements, even if those statements just a ‘get’ of multiple
attributes. When they can ask for each ‘field’ this task becomes larger and possibly harder.
Why did they ‘get’ just two attributes here but in other code they ‘get’ 6?
In addition, when we allow callers to ask for the data I usually see multiple callers doing
the same processing on the returned data. This might be as subtle as a conversion to uppercase,
but I have seen much more repetition creep in. How often have you seen this in the caller:
returned_collection.each {}
This repetitive processing should be in one place – and highlites a missing concept/abstraction.
For example, Why does the caller iterate over the returned_collection?
When you face the calls East and ask the object with the information to do the work then the
use cases become more evident. For example, “customer.printOn envelope” provides more meaning
than looking at multiple call sites. Note I’m not discussing the implementation of Envelope here
- personally Id be using an object, even if in Ruby/Smalltalk.
When the use cases are encapsulated in an object like Envelope then the commonality of multiple
“functional object” objects can be refactored and kept DRY.
Testing in the case where you can ask an object for attributes requires a lot of setup like
“when I call this accessor, then return that value”. In contrast when faced East the testing
changes. Usually there is a simpler expectation like “when I call this method, that object
receives these calls.”
What I would like to see happen is for people to try this approach and see how it effects their
design and their process of getting from A to B. Personally I have found the process to be more
effective in time and the ability to understand the resulting code, which I also find there is
less of.
4. Pingback by jamesladdcode.com » Blog Archive » More East …
11/Jun/2011 at 9:15 pm
[...] I was a special guest on ADDcasts back in episode 4: http://addcasts.com/2011/04/21/episode-4-special-guest-james-ladd-talks-to-us-about-running-smalltal…. After the episode aired I received some questions about East. What follows is part of my response [...]