From: mathew <meta@...>
Date: 2005-07-19T01:20:55+09:00
Subject: Re: Cross Language style mutation

Michael Campbell wrote:
> Can you expand on this a little?  I find myself "borrowing" paradigms
> and styles from one language/platform/pattern/etc. to the next as I
> play with them, and would love to hear others' experiences in
> cross-language idea implementation.

It can be good, but it can also be dangerous.

For example, I've seen code from a Lisp fan who insisted on implementing 
Lisp primitives like car and cdr, and then writing everything in Lisp 
style with a Lisp-like API where all the parameters were lists of lists 
of lists. The resulting code worked fine, but it was basically 
unmaintainable by anyone else; I'm a Scheme fan, and even I found it 
impenetrable.

You could do that easily in Ruby. Would it be a good idea? I don't think 
so. But a Common Lisp developer would probably describe it as merely 
borrowing a highly effective paradigm from a more mature and powerful 
language.

I think that coding style transplants depend a lot on the specifics of 
the donor and recipient languages--how similar they are, and how 
flexible the recipient language is. Trying to implement reflection and 
duck typing in FORTH is always going to be hard work, because it's just 
not that kind of language; and trying to do it in Java is going to be 
painful because it's such a rigid and fussy language.

There's something to be said for using the most obvious implementation 
method that the language best supports, even if it's not necessarily the 
most elegant method.

There's a similar issue around object orientation. Some people get so 
hooked on the idea of OO that they end up writing code where every piece 
of the problem is decomposed into objects; they develop an almost 
pathological aversion to simple imperative programming. The result is 
usually an API that's horribly bloated and complex, and code where there 
ae so many classes that working out what's going on resembles the old 
spaghetti code problems of (say) FORTRAN.

Again, my feeling is that objects should be used where it makes 
sense--to model classes of object in the problem domain, and to provide 
an API that's as simple as possible. If you then end up with a method 
that has a page or two of imperative code, that's not necessarily a sign 
of failure. Some tasks *are* best expressed as "Do these ten things in 
sequence".


mathew