The ideal is low coupling and high cohesion. That's supposed to mean your system is composed of parts that can be understood separately. Low coupling means that the innards of each module are isolated from the others. High cohesion means that each module presents a clear and distinct purpose.
Thinking in terms of interfaces (in the general sense) helps towards this ideal. If an interface is cluttered with dozens of functions, it's a sign that it could be refactored into more cohesive units.
> Low coupling means that the innards of each module are isolated from the others.
Isn't coupling just the complexity of the dependency graph? I would say depending on an interface is coupling as well. In my experience complex static typesystems encourage highly abstracted interfaces which are sometimes even more cancerous dependencies (that doesn't apply for really basic and practical things like Iterables which come with the language).
For this reason, IMHO an even better ideal than coding against interfaces is relying on concrete datatypes that are just a given, like structures and arrays of integers.
Maybe my understanding is idiosyncratic, but I see low coupling as most essentially meaning that the modules interact at small and well-defined boundaries, which gives you flexibility when you want to do things with the units like test them, replace them, etc.
Depending on an interface can be a kind of coupling, sure, but I think it depends. I think abstract interfaces, or at least statically typed data types, can be great for understandable systems...
In Haskell, there's work being done on allowing some kind of module signature, so that you can have several implementations of the same API be compatible with the same source code. I'm interested to see how that will play out.
You could see a Java-style interface as a specific global name given to a set of method signatures. Using that name incurs a dependency on the library that defines it. Sometimes it makes sense to redefine the interface in your own library, and then you can use adapters to make other implementations compatible—but this is all kind of boilerplate stuff that you wouldn't need if Java was more flexible with interfaces...
Thinking in terms of interfaces (in the general sense) helps towards this ideal. If an interface is cluttered with dozens of functions, it's a sign that it could be refactored into more cohesive units.