On Coupling and Data Flow

by moodyharsh 2014-10-02

In electronics there is no need to “name” components and their “connections”.
“naming” is for humans. Electrons simply don’t care.

I find this point of view missing in all Software Engineering discussions related to coupling.
I don’t even think there is a name for it.

I propose to call it “name coupling”.

All programming pathologically suffers from name-coupling.

By name coupling what I imply is how a function has to know the name of
the function or object it would like to call.

Hence there is a need extra for indirections to achieve basic modularity

  • Function Pointers
  • Dynamic Namespaces (packages in lisp)
  • Mediator / Messaging / Interceptor / Reflection / Dependency Injection / Service Locator / Proxy …
  • DLLs
  • Aspect Oriented programming

Electronics is the most visible example of nameless coupling.

Every so-called “Very High Level beyond Functional” language as of 2014
implements static bindings for names as the default.

Contrast to this, Assembly programming languages don’t need any complex
indirections like above because of the notion of indirect jumps or computed gotos.

SPARC: jmpl %o7
MIPS: jal $ra
X86: jmp *%eax
ARM: mov pc, r2
IA64: br.ret.sptk.few rp
6502: jmp ($0DEA)
65C02: jmp ($0DEA,X)
65C816: jsr ($0DEA,X)

This is an instruction level Proxy Pattern which naturally gives rise to modularity
and even self-modifying code.

Programming language designers are doomed to reinvent what is useful and forgotten with stupid names.

Every time you call a function, you are “name coupling” a function’s name.
Every time you make an object you are “name coupling” a class’s name.

Without changing the dependent’s code you simply can’t add more code around the coupling point.
Contrast this with electronics, where you add new pathways around an existing connection.

This simplest use case for this is debugging / mocking.

I find it silly to use words like Information Hiding in the context of OOP where all the names, “information”, are practically hard-coded.

In Data Flow / Flow Based approaches you can, in theory, use gensyms or Enums for all components and connections in a graph and it will still work. You can always add / replace components at individual connections.

I find this radically unique and to me it is like a litmus test for Component Oriented Systems.

You can avoid name coupling by using a Messaging Bus.

I suppose what I am advocating is similar to the divorce between

  1. a primary key and a name
  2. a function name and a function pointer
  3. a computed goto label and a goto label
  4. static and dynamic dispatch ( thanks @Ged )
  5. call and a message

How can we change the behavior while keeping the same name, if other programs are relying on the old behavior?
What names can be used for labels and placeholders, not memory addresses.