Smalltalk Tidbits, Industry Rants

The great thing about aList.first() and aList.last() is that they are intention revealing methods. A user of a List treats it as a black box, and simply ask for the first or last element. The problem with methods like aList.get(0) and aList.get(aList.size() - 1) is that they are implementation revealing. You have to know how the List is implemented to get it to do useful work.

As a rule, the Java class library (which I have become altogether too familiar with) is implementation revealing. You are forever asking objects for their parts (get methods, anyone?) and passing those parts to other objects to do the work. This is the antithesis of Object Oriented programming.

The correct way to design a class is to write intention revealing methods so that a user of the class can ask it to do useful work without knowing anything at all about how it is implemented. From the outside, the class is a black box.

The cell phone is a great mental model for how to design a class. You just punch in the number of the person you want to speak to, and the phone takes care of the rest. You don't need to know anything at all about how the cell network operates, how it interfaces to the land-line system, or anything else for that matter, to complete your call. The phone is a black box with an intention revealing API.

Alan Kay has lamented publicly on more than one occasion that he should have called it Message Oriented programming to drive home the idea that designing the correct messages is of paramount importance.

You just know that because Java's List class doesn't have a "last" method, that everyone who needs to access the last element is going to have to write "alist.get( alist.size() - 1 ) WHICH IS DUPLICATED CODE.

Duplicated code is a sign of bad design, and leads to bugs. There's probably been a million bugs where someone coded alist.get( alist.size() ) attempting to get the last element (which will instead throw an exception), and no doubt less that 80% of those bugs have been fixed.

It wouldn't be so bad if Java programmers could extend existing classes.

Comment by Troy Brumley

I keep coding CType(myCollection.Item(1), MyType).blah in my .NET application. It's going to drive me to write my own collections. Over on my blog I've also complained about the whole lack of our block/message idiom and how it inflates code size when compared to Smalltalk.

Oh, and Amen to Kieth re extending classes. I sometimes wonder if Decorator is so popular because you can't subclass and/or extend most base classes in the (ahem) more mainstream curly-brace world?

Actually...
x = list.get( list.size() -1 )
won't give you much joy if list can be empty, so the full version of list.last would have to be something like:
if(list.size() > 0){
x = list.get( list.size() -1 )
}
unless you like to get IndexOutOfBounds exceptions.

Comment by James Robertson

If List had a last() method (as it does in Smalltalk and Ruby), it wouldn't need to be implemented (possibly badly) by every developer that needs it.

The funny thing is, LinkedList has a #first and a #last method. That means the code is there but most developers can't use it, because it's not in the List interface. This is really a sign of good design.

But there's more wrong with the collections in Java: optional methods Which means the implementation may or may not support the method. This is one of the benefits of static typing. You know at compiletime that the instance will have the method.

I couldn't quite explain why Martin Fowler was right and Cafe au Lait was wrong, but isomer said it quite well: intention vs implementation. And we have a perfect example: Ruby's array are 0-indexed and Smalltalk's are 1-indexed. So to access the first element in Ruby, you do arr0, but in Smalltalk it arr at: 1. Having a first (and last) method makes sure that you don't need to remember that, which is great, especially if you switch between languages often.

Comment by Terry

I consider intention programming to be critical for good st code. That is also why I don't like enforced type specifications. They tend to make you think implementation and not intention.

@James
I wasn't arguing your point, just showing that lack of a last() method isn't just tedious but can also generate runtime problems if the access code isn't carefully implemented.

well, this is just a note about ruby and not for Smalltalk, but it should be noted that 1/3 of those methods in the ruby Array class are taken "for free" from the Enumerable mixin.

I use #first all the time, btw, and I use #last a fair bit as well. Perhaps Java developers don't simply due to their absence? It can be hard to miss what's not provided.
Since Java 1.0 they've had java.util.Vector firstElement() and lastElement().

Isaac, we aren't discussing the (obsolete) Vector class. The class in question is java.util.List.

James we aren't discussing the (obsolete) Vector class
There is no java.util.List class - it's an interface.

Far from being obsolete, here's the Java 5 Vector class

Comment by James Robertson

Dunno Isaac, I have plenty of friends developing in Java, and class vector mostly makes them swear. They use the new(ish) Collection libraries

From my highly limited experience with Smalltalk, I will suggest that two reasons why many-methods-per-class is more palatable in Smalltalk than Java are: 1) Smalltalk has a less syntacic overhead per method 2) Smalltalk (at least what I've seen) has "method categories", a tool for organizing methods, if you have 100 of something it is much easier to handle that with some categories, that in one long list.

I love posts and comments like this one

"From my highly limited experience with Smalltalk, I will suggest that two reasons why many-methods-per-class is more palatable in Smalltalk than Java are: 1) Smalltalk has a less syntacic overhead per method 2) Smalltalk (at least what I've seen) has "method categories", a tool for organizing methods"

I'll add a third technique used in Smalltalk for organizing code, which the Java and .Net world miss: Extensions. In many Smalltalk implementations, the ability to divide the methods into multiple packages means you can navigate methods by which layer of the system the method supports. For example, methods on domain objects that answer GUI-related information will (hopefully) be stored in a GUI package. The same applies for methods used for testing, debugging, persistency and so on.

When browsing classes, it is easy to filter methods by packages.

In Smalltalk, a set of classes does not necessarily define a subsystem/component. Instead, a subsystem can add behaviour across classes.

@Isaac
It doesn't matter that Vector is still in there, but it is recommended that it's not used anymore, mostly because all its methods are synchronized. It implements java.util.List to fit into the Collections API, but again: it's recommended not to use it. The fact that it's still used by Swing etc, just means that Sun hasn't gotten around to changing that.
But it's curious to see that Vector had the first/lastElement methods, whereas they were removed from the Collections API... I assume the change of guard at the Java team at Sun is the reason here.

java.util.LinkList provides all the funtionallity your looking for in java without the overhead of synchronization. java.util.List as was pointed out is an interface not a class, it has no implementation. All it does it define what methods must be present for what most computer science course define as a list. Those definitions do not include first/last fuctionality. First/Last are convienence methods. And Java has for a long while provided them in at least two implementations of the List interface, Vector and LinkedList.

Now if you want to compair library size and complexity of java/c# with Ruby/Smalltalk, there's a good discussion there and many have talked about it.

Comment by Troy Brumley

I'm still getting used to using the idea of interfaces myself. I'm not entirely sure I like them, but they don't seem as evil as I thought they'd be when I came over from Smalltalk. Still, the distinction isn't obvious to the full time Smalltalker who isn't also coding in Java or .NET. Bear with us over in Smalltalk land :)

Mike, I use ArrayList as an implementation of the List interface. Could you please tell me how the presence of "last" in LinkedList helps me? Had a last method ben defined in the List interface itself, and implemented in all its sub-classes, then it would have been easier to use "last" for all List classes. All it shows is that the developers who wrote the LinkedList class made other developers' task a little bit easier.

murphee wrote It doesn't matter that Vector is still in there, but it is recommended that it's not used anymore
This argument is an appeal to authority "it is recommended" without saying who the authority is, or showing where they say it.

it's curious to see that Vector had the first/lastElement methods
I agree - it would be interesting to hear, from those who designed the List interface, why they chose not to include first/last.

@Isaac
This argument is an appeal to authority "it is recommended" without saying who the authority is, or showing where they say it.

OK, you're right. Let me state my reason for the recommendation "Don't use Vector and Hashtable": All methods on these container classes are synchronized which causes synchronization overhead even if the object is never accessed from different threads (I know...modern VMs could get rid of that overhead, but that's not quite here yet and only on those with modern dynamic compilers). If you need synchronized access, then you can synchronize an instance by using Collections.synchronized*.

With all this, and more modern additions (like new Collection classes from the java.utils.concurrency.*, eg. CopyOnWriteList), there isn't really much reason for using Vector. So my recommendation: if you need a List, use ArrayList. If several threads access it: look at appropiate options like the ones mentioned above. And only then, if you decide that really Vector is the best choice, Then use Vector.
Is this an acceptable explanation? (You don't have to agree with it, but that's what I state as reasons).

Is this an acceptable explanation?
Sure! You've made it clear that this is your viewpoint, and not some kind of official recommendation.

But it's not just one person's opinion - this is also a common practice. Supplying the justification is helpful, but why is it so wrong to tell people what common practice is among Java developers?

"All it does it define what methods must be present for what most computer science course define as a list" It sounds like there should be 2 interfaces, MinimalList and ExtendedList. MinimalList has the minimal set of list functionality, ExtendedList extends MinimalList and has all the "convienence" methods that can be accomplished using the MinimalList functionality, and a class ListExtender should implement ExtendedList and wrap a MinimalList, adding the Extended methods.

There's just too much fighting the same sorts of extremist blah blah blah. I came at this debate from the domain specific language point of view in: Humane interfaces, simplisticity, and domain languages.

AOP's static crosscutting features can help in transforming a minimalistic interface into a humane interface. In fact, you can get a organization feature similar to "method categories" in smalltalk. See Creating humane interfaces using AspectJ for more details (uses AspectJ-based examples, but the idea is more general).

Here is another problem with the Java approach. The doc for List says: "The List interface provides four methods for positional (indexed) access to list elements. Lists (like Java arrays) are zero based. Note that these operations may execute in time proportional to the index value for some implementations (the LinkedList class, for example)." So if your method uses list.get(list.size()-1) and it is passed a linked list with a billion elements in, then you are in big trouble. IMHO this breaks the liskov substitution principle since the code is O(1) for an array-type list and O(N) for a linked list. Of course the LinkedList class has getFirst and getLast, but you cannot use them in your code if you want it to work with any type of list.

As a small aside to the more important debate (intention vs implementation, humane vs minimalist, good OO vs Demeter violations) please, please stop talking about the method count as any sort of meaningful metric: it is an apples to oranges comparison.

In Ruby, an Array is something you can new up and actually use. It mixes in (think inherits from an abstract class, java people) 23 methods from the Enumerable module. It also adds another 11 sugary/c++/operator sort of methods like + & etc.

In java, List is a java construct called an interface. To actually use a list, a typical java programmer will new up a LinkedList (or an ArrayList). A LinkedList implements 6 interfaces, 4 of which are generified in java 1.5. It has 5 parent classes in its parent hierarchy. The resulting surface area is 58 methods (not including the "virtual" surface area of the generics). That does not count static methods in utility classes like Collections that can operate on Lists and adds things like sort, shuffle, min, max, reverse, swap...just the sort of things that the Ruby Array gets from its Mixin.

So the real comparison is 23 + 11 + 44 to 58 + about 30 or so...wow, imagine that; if you think of the common things you would do with a list, Ruby and Java do about the same stuff. They just do it in a different OO structure.

It is also obvious but worth noting that we are looking at the sort of classes that should end up with the largest surface area: basic CS things like Bags, Dictionaries, and Lists are going to have more methods than your average complex business class in your custom app that only your team uses.

John Lindsey it is an apples to oranges comparison
Indeed, see the comment "It's just an utterly false comparison"

It's wonderful that anyone can associate Minimal with Java, and keep a straight-face :-)

One thing confuses my humble brain about all these posts. Some folks are saying "We can make a minimal interface" and others are saying "a richer interface is more friendly". It seems to me that you can make both groups happy by having both sets of interface: start out with the minimal one at the core, and building an optional "layer" on top of it that adds all the "humane" stuff.

Anthony, as another user mentioned, Ruby's Array class "mixes in" the Enumerator module. It's Ruby's way of doing multiple inheritance, I believe.

The Enumerator module gives the Array class these methods:

     all?, any?, collect, detect, each_with_index, entries,
     find, find_all, grep, include?, inject, map, max, member?, min,
     partition, reject, select, sort, sort_by, to_a, to_set, zip

Here are the Array instance methods, if anyone's interested:

     &, *, +, -, <<, <=>, ==, [], []=, abbrev, assoc, at, clear,
     collect, collect!, compact, compact!, concat, dclone, delete,
     delete_at, delete_if, each, each_index, empty?, eql?, fetch, fill,
     first, flatten, flatten!, frozen?, hash, include?, index, indexes,
     indices, initialize_copy, insert, inspect, join, last, length, map,
     map!, nitems, pack, pop, pretty_print, pretty_print_cycle, push,
     rassoc, reject, reject!, replace, reverse, reverse!, reverse_each,
     rindex, select, shift, size, slice, slice!, sort, sort!, to_a,
     to_ary, to_s, transpose, uniq, uniq!, unshift, values_at, zip

Trackback from Bernard Notarianni Humane interface debat A big debat is agitating the blogoshere since Martin Fowler wrote about the “humane” interface style, versus the “minimal” style. An argument from the “minimal” camp has been quoted by James Robertson: A 78 method List class is about three times as ......

Java development does NOT always rot the brain, some people write code for a living, not having much time for geek-wannabee discussions as this one. Don't you guys have any work to do?

It always grates on me when, after looking over 10 lines of code involving a List named "arr" that what the guy meant was Stack. If you are really dealing with a Platonic "List", I don't know why you'd need an indexed getter, much less first and last.