A lot of programmers are drawn to the field of computer science precisely because there were no rules restricting the worlds they created. In some sense, we do rely upon the power of "being able to do anything" in order to unleash the creative and technical power of computers for solving problems in new ways. Yet experienced developers generally realize that choosing a development platform with more narrow capabilities can actually help focus the problem and produce a better product--and that those restrictions are there for their own good!
This seeming paradox is actually a pervasive Zen Truth, which shows up in every area of philosophical inquiry. I like to borrow terminology from the political theorists, who have articulated the two types of freedom: "freedom to" and "freedom from". You might say that each restriction placed on a software developer is a limitation of their "freedom to", which provides someone else (another developer or the user themselves) a "freedom from". The classic statement "your right to swing your arm ends where my nose begins" captures the importance of balancing the power of the individual and the guarantees offered to others.
The balance comes into play no matter how you design a system; you cannot "opt-out" of the decisions! Any failure on your part to put a restriction in place is an implicit declaration that everything is permitted. That may have been an expedient choice in the Wild West of computer history, but software is now a tightly intertwined urban landscape...where lawlessness breeds chaos. Although security restrictions are experiencing a boon due to the prevalence of hackers, very little emphasis is currently being placed on imposing clever restrictions on an application's internal structure. If your computer were a country, it's as if there are detailed immigration policies but no one is bothering to enforce traffic laws!
When I think about most of the tools and frameworks that are being marketed today, I'm reminded of the story of Stone Soup. I'll paraphrase the fable like this:
A mischevious individual sits with a stone and some water in a pot. Curious villagers come to see what's being made, and the stranger tells them that it's "stone soup". The people doubt that you can really make soup from a stone, but they sit and wait to watch and see if anything happens.Note This image is very popular on the web, and I cannot find the original source to attribute. Please contact me if you know where it is from.As the time passes, the chef mourns the fact that there's no salt, because that would make the stone soup "much better". Someone runs home to get salt to put in the pot. Then the chef mentions that there are no carrots, which is too bad since carrots really give that extra "oomph" to stone soup. That leads another person to run to their garden to get the ingredient, and this pattern is repeated a few times. Eventually it makes a great pot of soup--leaving the villagers in awe of the magic stone's power.
Usually the man with the stone is seen as a hero for getting the hungry villagers to share their ingredients with the community instead of hoarding them. Thus the moral of the story is that when you catalyze a group so that everyone contributes what they can, a greater good is achieved. But I always felt like a more obvious moral was important:
If you provide all the seasonings, vegetables, and meat then you will have soup--stone or no stone!
To recast this lesson into engineering terminology:
Projects can end up succeeding in spite of infrastructure...rather than because of it.
Like these hungry villagers, programming communities often achieve outstanding results by using tools which have no more to do with their success than the stone. In fact, software developers are especially vulnerable to stone soup salesmen because of the discoveries often attributed to Alan Turing. Since computing is universal, even bad tools can't stop you from solving any problem you need to. The only place new computing "power" comes into the picture is when a platform clearly defines which problems it doesn't solve--so that it may be closer fit to the problems you are interested in.
Thus, to truly find advantage in a new platform, it must be very specific about the limitations it created to reshape its environment in a manner more catalytic than the Universal Computation stone!
