A wonderful feeling.

Now I’m going to have to have another look at List Comprehensions in Ruby: shouldn’t there be “Higher Order List Comprehensions in Ruby?”

Me Notyou: Not sure what you were expecting me to accomplish; I think this method goes a long way in terms of readability. That being said, I’m perfectly comfortable with Ruby’s established idioms for collections.

As to performance, it’s up to the compiler in a dynamic language to optimize method invocations; this is a growth edge for Ruby. Besides, I just wanted to show what could be done; I wouldn’t use this or any other “interesting” technique in production code without profiling.

But let’s talk about accomplishing “very little”… I honestly felt the same way when I first saw Ruby itself. What, I wondered, did Ruby do that Lisp (Scheme was my chosen dialect) hadn’t done twenty years before?

Lisp had mature implementations, including some incredibly fast compilers. It had phenomenal REPL environments from Emacs to GUIs. It was a regular, stable language without Ruby’s annoying little corner cases. Ruby was very weak in almost every area of comparison.

But you know, I had to stop and ask myself, “maybe there is a Gestalt thing here, maybe Ruby has a design to it that makes it more fun, or easier, or (gulp) better to use in the sense that a saw with a certain heft and balance is better to use than another with a shaper blade but a more awkward handle.”

I’m not going to tell anyone that they’re wrong and that HOM is a must-have feature. But I would encourage people reading this to at least consider the idea that small differences in syntax and style may be useful even if they don’t appear to do anything you couldn’t have done with Ruby’s existing idioms.

But since it is interesting baggage, let’s go:

Ruby is interesting because it provides people who cannot contribute anything of substance a means to contribute their very own “DSL” to the world. Unfortunately, a so-called “DSL” is nothing more than syntactic sugar.

That’s quite the observation. We could substitute “Lisp Macros” for Ruby and say the same thing, couldn’t we?

Without getting into this particular DSL, isn’t it a bit of a fallacy to say “these people misuse a tool, therefore the tool is no damn good?” There are plenty of excellent things accomplished with Ruby, things that are just outright useful. Isn’t that all that matters?

Now as to the objective content of your message: DSLs do not increase coupling. And cohesion is a good thing: the general use of these two words is that it is beneficial to lower coupling while increasing cohesion

Of you feel DSLs in general increase rather than decrease coupling, I invite you to articulate you thoughts on my own blog post where I claimed the opposite: that DSLs allow you to separate concerns. I wouldn’t want to burden Kevin’s article with a debate about something he isn’t claiming in this post.

Unfortunately, a so-called "DSL" is nothing more than syntactic sugar. Using a "DSL" gives you shorthand, but often also increases the coupling and cohesion in your software.

So we have "Higher Order Messaging (HOM)" that is not "higher order" but merely "higher coupling".

When I look at Ruby today, I see a language that is devolving into a giant melange of fragmented idioms. A lot of energy in the Ruby community goes into acting clever vs. being clever. So-called "Higher Order Messaging" is a great example of something that acts clever but is not clever.

I certainly agree with your viewpoint that most modern DSLs are a form of syntactic sugar, but I also feel that’s usually the point. It would not have been too much of a stretch to have had a similar argument against C in 1972.

Your comment is either unrelated to this post, or it is trivially false.

If it’s unrelated, then take it elsewhere; there are plenty of places to have a discussion about the faults and merits of DSLs.

Otherwise, you consider this implementation of higher-order messaging on enumerables in Ruby to be a domain specific language. That’s arguable, but what isn’t arguable is the fact that this implementation doesn’t increase coupling in any way.

A quick walkthrough of the dependencies shows this plainly:

The extension to HigherOrderMessage has no dependencies.

The extension to Module depends only on HigherOrderMessage.

The extensions to Enumerable depend only on the extension to Module and the built-in Enumerable methods.

All of these dependencies happen through simple method calls, no poking around in each other’s internals, so any piece of this implementation can be changed independently of the others. That is what reduced coupling is all about, yes?