On Mon, 20 Mar 2006 13:35:55 -0800, Levi Pearson <[EMAIL PROTECTED]> 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:
// 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
here.
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
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
