What's the big deal about using isomorphisms as opposed to transforms? I think they help you avoid indirection. And I think indirection is the root of all complexity.

It's interesting that programming-language afficionados, especially the elite ones (i.e. the ones that like functional languages) tend to love adding new features to their languages, but that they do this by increasing indirection and abstraction. Parameterized types, virtual methods, function pointers, closures, continuations, etc. All of these things make programs harder to understand. Yes, they add a lot of power, but I think we should focus on making programs more powerful without having to resort to more abstractions to do it. We should be gaining power by removing layers of abstraction, rather than by adding more layers to cope with the inadequacies of the existing layers.

Amusingly, a lot of programmers hate lisp-style macros because they think they make programs harder to read. I completely disagree. I think macros decrease the level of abstraction in a program. They make the syntax more directly-meaningful, closer to the problem domain. Which brings us back to the quote by Graydon I started this post with.

But the quote aside, there's a controversial (at least to me) idea in here, either that or I'm confused on terminology. Most of computer science is about applying indirection. The commonly held wisdom in language design is that we help people build bigger systems by finding new ways to hide the details from them. That's called abstraction, and has gotten us functions/procedures, objects, frameworks, etc. And I would put macros in the same category. When I use a macro, I don't have to know how its implemented (and its probably implemented with some of the aforementioned goop). So for me, macros increase the level of abstraction in a program...

Jim Weirich observes that Pythonistas and Rubyists bring different assumptions to the table:

Python follows C++ and Java in using "." as a structure selector operation, while Ruby is more closely attuned to Smalltalk's message sending paradigm. Both approaches work and are interally consistent, but be prepared for surprises if you try to interpret one using the assumptions of the other.

Jeffrey Shell blogs on Python's philisophy of simplicity and then references a comp.lang.python post that goes over his assessment of Ruby vs Python in great detail. In the blog post, he extols the Python module system and quotes Tim Peters' "The Zen of Python". The newsgroup post goes over the stuff in Ruby that is matched by Python 2.2.

Hans Nowak has a series of 3 (so far) comparison posts. Here's some things I picked up:

first post

He sort of likes creative use of punctuation in Ruby. I'm the same. The use of ? and ! seem good to me.

second post

Ruby yield works on closures.
Ruby can define methods on instances.

third

He's not sure what the big deal is about procedure objects (closures). First classness.

Over at Fog Creek, they're having a comment fest on Dynamic Languages and Enterprise Applications. There are some interesting posts by Jim S. and Phillip J. Eby that are worth your reading time. They're too big to post in here, and the comments don't have anchors so I can't link directly.