java follies [was: PHP vs Perl (Put on flame proof gear)]

Ross Werner ross at
Mon Mar 20 20:34:22 MST 2006

On Mon, 20 Mar 2006 13:35:55 -0800, Levi Pearson <levi at> wrote:
> On Mar 20, 2006, at 1:52 PM, Bryan Sant wrote:
>> Not that I don't believe you, but please supply and example.  How
>> would a dynamic language make a singleton, prototype, strategy,
>> flyweight, facade, or adapter pattern unneeded?
> Well, take Strategy (and the other patterns that differ from Strategy  
> only in intent).  For most uses, you can replace the strategy object  
> with a higher-order function or code block or something of that nature,  
> depending on what language you're using.

Another great example. I've often thought that Java could trivially have  
type-safe higher-order functions. Picture this fake-and-fraudulent Java  

// Code Sample #1
	void doSomething(function:String(int, int) bar) {
		System.out.println(bar(5, 10));

The method "doSomething" takes as its only parameter a function with the  
return type String, and two int parameters. "doSomething" calls that  
function with 5 and 10 and then prints out the String returned.

// Code Sample #2
public interface Foo {
	String myFunction(int, int);

	void doSomething(Foo bar) {
		System.out.println(bar.myFunction(5, 10));

This code is, functionally, exactly identical to the first. I see no  
reason why Java can't automatically do this for us instead of forcing us  
to create Interfaces all over the place to get the same result.

(Of course, even with having to create interfaces, I don't really buy your  
argument that the "Strategy" design pattern in so very different in  
another language than in Java. I agree that other languages provide a more  
helpful way to implement some design patterns, but that's a far cry from  
saying it "requires no extra thought".)

> I'm not trying to insult Java or Java users, just to point out that  
> static typing does add conceptual overhead in some (but certainly not  
> all) tasks.

I agree that Java does give you some conceptual overhead, but hopefully  
the above example will make it clear that static typing is not to blame  

> In the real world, static typing does not alleviate the need for unit  
> tests, and few unit tests need to be written specifically to catch type  
> errors, since they will usually show up in the sort of test that you'd  
> write for a statically-typed language, too.  So, that cost for dynamic  
> languages is just about as bogus as the extra keyboard overhead people  
> try to place on Java.

I've done a lot of programming in both statically typed languages and  
dynamically typed languages. Other people I know have done a lot of  
programming in both as well, and prefer dynamically typed languages. I see  
pros and cons to each, but I don't see either side winning, even in any  
particular environment. So I've decided that it's just a matter of taste.  
Some people like the taste of statically typed languages--others prefer  
the savory sweetness of dynamically typed languages.

Since I like the first, my goal is to gather all the juicy sweetness of  
other languages--the parts that can be "borrowed" whether or not the  
target language is statically typed or not. Maybe I'll end up ditching  
Java in favor of another statically typed language that does things more  
how I want it to do them. Maybe I'll end up inspiring some changes to Java  
itself. Maybe I'll just end up depressed that nobody listens to me. Who  
knows! But I'm enjoying the ride so far. :)

> I think you interpreted my response to your earlier post as anti-Java,  
> while I didn't mean it that way at all.  I was just trying to broaden  
> the discussion a bit.  Maybe I'm overly optimistic, but I think that  
> features of Lisp, Smalltalk, Ruby, Haskell, ML, etc. will be working  
> their way into mainstream languages over the next few years.

I fully agree, and I'm both looking forward to it and looking forward to  
hastening it!

	~ Ross

More information about the PLUG mailing list