Recently I have read some suggestions that CC suffers from Simplexity and Leaky Abstractions - the former claimed since CC is seen to "take something incredibly complex and try to wrap it in something simpler, [only to] just shroud the complexity"; the latter since "All non-trivial abstractions, to some degree, are leaky."
Yet, I am one to argue that, regarding Simplexity, it is more a case of discovering a simple truth, and not one for sweeping complexity under the rug. This returns to an argument I have long made - exposing operational semantics in anything other than low-level or internal APIs is absurd, as this breaks the basic principle of automation, which is loose coupling. This is one thing that Web Services and REST have had right from the start - exposing only axiomatic semantics and hiding operational semantics. Without making the latter opaque, there is little chance one can ever decouple atoms from business logic. One should never have to know the details in how the services they consume work, rather, one should only have to understand the relationships of the services they consume, when they can impact the consumer - which is what choreography addresses.
Regarding CC, it is the discovery of what service providers have done as both a business and technological model - business in respect to hiding the complexity of what they provide to their consumers, technology in respect to the ease of integration - mashing-up - their services. It is a natural progression of models from distributed computing, whilst providing the abstractions in terms of definition and description. To drive a car, one doesn't necessarily need to fully understand the internals of the engine, drive train, suspension, electrical system, etcetera. One only needs to understand the abstract interfaces - steering, brakes, accelerator, gear box, environmental controls, etcetera - and how they function (and most drivers seemingly under. This is the difference between operational and axiomatic semantics. Those who cannot get over operational semantics would, in essence, still have drivers use a manual choke and crank starter, because "you just have to understand how it works, man."
Which is a good segue to Leaky Abstractions - by definition, this places all practical technology abstractions, which could hardly be referred to as "trivial", as "leaky". The author's own example of driving a car in the rain exposes the flaws in this argument. The abstract interfaces of the car have everything to do with control, speed, internal environment, status monitoring of the car, whether in motion or not. "The weather can never be completely abstracted away" is neither here nor there, because the constraints of climate on driving a car have to do with the laws of physics, human biology, etcetera, and not whether the internals of driving a car having themselves been encapsulated.
The comments on the Simplexity and Leaky Abstractions of CC have more to do with the cynicism of those who feel it to be another victory of style over substance, and less to do with any real issues with CC. I do concur that the taxonomy blur does leave one disorientated and wondering what the buzzwords truly represent. Whilst I do not expect CC to be the end-all of computing models, I see it as yet another step in the right direction, and evolution of compute models, and driving technology toward the democratization of innovation, content, community and commerce.
Comments