I came across an interesting language comparison today - a Red-Black tree implementation in Java, Python, C++, and Java. One of the things that jumped at me was stylistic - in all the implementations, the insert() method was very, very long. Why did that strike me? Well, I've been doing Smalltalk so long that anything over 7-10 lines starts to grate on me. So I took a look at it; here's how I would refactor that method in Smalltalk:

 

rbInsert: aVal and: sw 
	((left notNil and: [left color = self red]) 
	       and: [right notNil and: [right color = self red]]) 
	               ifTrue: 
	                       [color := self red.
	                       left color: self black.
	                       right color: self black].
	aVal < val 
	       ifTrue: [self rotateOnLesserVal: sw] 
	       ifFalse: [self rotateOnGreaterVal: sw]

Which, at least for me, makes it far, far easier to follow. This has a lot to do with tool use, I think. In Smalltalk, we edit method at a time using a code browser; most people edit other languages in a text editor (sometimes embedded in an environment, such as Eclipse - but it's still text editing). The Smalltalk tools really push you toward small methods - partly just so that it all fits in the visible part of the pane. Which isn't that different, I guess - the old policy I had in C was that a method should be no longer than a page - i.e., the visible portion of the text editor without scrolling.

Most of the conclusions made in the post seem ok to me - I definitely value dynamic typing more highly, but that's probably because my longer use of it has convinced me that the kinds of errors that static advocates worry about just don't come up that much. Nearly every time I see a MessageNotUnderstood, it's an initialization problem.

The only other quibble I'd have is with the assertion that Java is compiled. Like Smalltalk, it's dynamically compiled - byte code is converted to platform executable at runtime by the VM.