Stamp Coupling in multiple paradigms

Functional programming languages are awesome, but sometimes, especially if they are multi-paradigm (scala, ruby, ...) they can give you extra ropes to hang yourself with. 

In particular,

 a functional language which doesn't impede mutable variables and global mutation of objects floating around in memory might allow you to do thinks succinctly without actually improving the modularity or bug-free-ness your code. 

Now - these "gateway" langauges (i call them "gateway" languages, because they provide a gateway drug to functional programming that isn't doesn't embrace the paradigm entirely), I beleive, need special treatment - idioms and antipatterns should be embraced early on, do avoid a soup which contains the worst of both worlds.

In my first attempt at a scala application, I found that I was writing code that was as cumbersome as the last OO project I worked on, while being as terseness as the last LISP project I worked on - without the bugfree-ness (of the former), nor the expressiveness (of the latter. 

Im not sure there is any one solution to this.  But I hope this blog post helps to outline that functional programming syntactical sugaring doesnt always solve software engineering problems associated with undesirable coupling.

I ran into some stamp coupling at work today, and realized its hard to think of a good example of it on the fly, so I jotted these two down for future reference.

Stamp coupling : In a functional style

Although functional languages are generally better with avoiding mutation, some languages (like scala), tend to discourage it less than others.  Also, with the Guava function APIs, we can mix object oriented programming with functional programming, to create very tricky forms of stamp coupling that can be harder to spot than traditional imperative code.  Like this:

          //yuck !
          def badFunction(d : Dog):Bool = { 
                     d.setBark("woof !");
                     True

          }  

          //the use of functional programming here isn't giving us more testable code.
          //rather, we are still using side effects, albeit, we are compartmentalizing them into a function.
          dog.do(badFunction);       
         
         Instead, you can call a function by name directly in most any functional language.  That would be much cleaner.  A langauge which defied the thing-like abstraction of everything would be much harder to implement such an anti-pattern to begin with - that is - a language such as LISP or Clojure. 

Stamp coupling: Another example, in an OO style

Here's another form of unnecessary coupling, using classes and Ruby.    In the GoodClass implementation, we have parametric coupling - the best form.  In the bad class, we have mutation of an input object.