I’ve been using Java now for a couple of weeks. It’s not as bad as some of my friends have made it out to be. Specifically, they talk a lot about “AbstractFactoryFactories” and other things that would seem, on the surface, to be ugly abstractions that should never have been born–mainly because they are “hard to read and maintain.” The phrase “botched abortion of a language” has been thrown around at least once. Ick.
That’s the thing. Abstractions are INHERENTLY hard to read and maintain. The action of an abstraction is to take equivalence classes of well-defined thoughts and have something represent them; a “symbolization,” if you will. To understand them deeply, you need to be able to look at the underlying primitive thoughts and verify for yourself that the abstraction is well-defined. This is usually too difficult and time-consuming for most people, so they substitute it with memorization, trusting in time invariance for the many-to-one mapping:
(Groups of Thoughts) ==>> (Symbols).
An example of an abstraction at work: derivatives. Why people can make money off of derivative financial products? More often than not, they are abstractions that are too difficult for most people to understand. The creators of these assets are the only people who are qualified enough to make smart bets on them, because they are the only people who have taken the time to understand how the inner mappings of values and ideas will change over time.
A different example of this is the “for loop” abstraction. In most languages, wrapping n repeated statements into fewer than n lines has a standard implementation that does not change over time. It is a successful abstraction. People use it and don’t get screwed. Most languages do not mess around with their default implementation of for-loops in successive versions, for this reason.
When someone looks at an “AbstractFactoryFactory” and grimaces, it is not because of inherent “ugliness”–formal constructions do not, to my knowledge, have an established metric for beauty. It is more likely that the coder simply has not had the opportunity to write and call as many of these particular abstractions as they have of for loops, for example. To them, the fear is very real. Should they “buy” this “derivative-code product,” by changing/editing/using it, they could very well be risking hours, days, weeks, even months of their future time, should their change be based on a faulty, hard-to-understand assumption. It is unfamiliar.
Abstractions present both utility and inherent difficulty to human consumers, as the amount of time anyone has to understand a new idea is, unfortunately, finite. How do we best assign our trust to the creators of the abstractions that we use every day?