Technology Soup
As a wise man once told me, “the advancement of computer science can be measured in levels of abstraction.” Okay, I lied, no wise man ever told me anything like this, although it’s not far-fetched and not too hard to believe.
Now that I am done fibbing, I’ll jump straight to my beef. The problem with abstractions is that they naturally take a multitude of forms, because not everyone can agree on how to abstract away simple mechanisms into higher level concepts. What usually ends up happening is as the levels of abstraction stack higher, the path to a simple task becomes simpler, but we lose sight of the overall picture.
If I take the first level of abstraction as assembly code/machine code, which abstracts away physical CPU instructions into some binary representation, I can argue that this first level of abstraction is as simple as anyone will ever get. It’s just add, subtract, multiple, and maybe a divide here and there. Add in some reads and writes and you’ve got yourself the basic LEGOs of every modern day system.
Our problems start here. The next logical progression is to complain that we need higher order constructs to be more expressive and more elegant in our approach to problems. This gives rise to higher level languages like C. Our complaints continue until we finally reach the pinnacle of general expressiveness, a strongly-typed, polymorphic, object-oriented, virtualized language (like Java) having lost all direct connection to those loveable adds, subtracts, multiplies, and divides.
Next we grow unhappy with how the general approach has become so … general… so we develop languages made for specific tasks. Out pops the glut of scripting languages, PHP, PERL, Ruby, JavaScript, VBScript, Python, and [insert your language du jour here]. We live with this lack of generality because we say things like, “Oh, but PHP makes it easier for you to do [Task A] and, oh, PERL is so much easier for [Task B],” all while sounding totally knowledgeable.
Don’t get me wrong. I like choices, but sometimes I think there is just too much emphasis placed on being “politically correct” in choosing the weapons of war.
Exhibit A. I’m building a web site to track financial portfolios in real time. This project entails (from back to front) interacting with several web services exposing interfaces via WSDL/SOAP then wrapping that functionality along with some peripheral necessities into another WSDL web service that manages entire portfolios made up of sets of stock symbols. Next this web service must have a client that can translate and expose these features as an HTTP service. The HTTP/HTML documents generated are then rendered in the end-user’s browser where we would like to have all the snazzy web 2.0 goodies to provide a GUI. That’s the at-a-glance high-bit description of the problem.
Now let’s count the alphabets in our soup (again from back to front). We’ve got WSDL, so I’ll choose to use a specific implementation of XQuery (mxquery by Donald Kossman et al.) to query the web services of interest, process the XML, and spit out more functionality in the web service extensions provided by mxquery. So far I feel good because I’ve tackled a 2 front problem using 1 (non-standard) technology. Next I need a SOAP client, since browsers don’t have direct SOAP functionality. I’ll choose PHP to do this for me since, again, I tackle two fronts with one language - SOAPClient on one end of PHP and bad-ass HTTP functionality on the other end. Afterall, PHP is the Hypertext Preprocessor. Next we need to 2.0 goodness so we’ve got to have AJAX running, making HTTP GET/POST requests to my PHP. Lastly, we’ll need CSS to make sure this whole ordeal doesn’t look like something from circa 1990.
Depending on how you count, you’ll get a total of 4 to 6 technologies/concepts in that quick little sketch. Although it might seem like it while reading through that grocery list of implementation decisions, the choices for what technologies and languages to utilize at what step are not easy decisions. Remember, you want to be able to say, “X makes Y easy to do.”
The problem? That was great and all for an individual project at such a small scale, but imagine having to build companies on these evolving technologies. You want to stay nibble, so you want to utilize all the newest technologies. “X makes Y easy to do.” But, you also want to have a go-to move that you can hang your hat on, because, frankly, the only way you’ll ever be flexible enough to utilize the perfect technology X to solve Y in the real world is if you churn through employees at a high rate. This doesn’t sound like a good solution.
Speaking of XQuery, it officially became a W3C recommendation less than 3 weeks ago. I don’t want to pick on XQuery, because I honestly love some of the decisions they made with the specification - it’s almost as flawless as a commitee decision can be, but it is fresh on my mind, and it was what brought up my angst. XQuery, like all computer science, is an abstraction. It’s an abstraction built to handle the very specific task of wrangling the wild world of XML and taming it in elegance. PHP was an abstraction, an abstraction to wrestle and tackle the evolving problems in an evolving world of HTTP. JavaScript was an abstraction, likewise, to provide the richness to the browser. See where I am going?
No? Okay. Well, I never was a convincing person. The problem here is that these technologies are here to provide the layer of abstraction that is the essence of progress in this field. However, in doing so at such specific means, they diffract our efforts to generalize lower level problems into higher level solutions. Because as we tackle the problems we want to solve, we inevitably take on a whole host of specific solutions and are forced to piece them together. As I said before, this is essentially correct and great. Who doesn’t like to have rectangular LEGOs to make walls and square LEGOs to make floors? The problem arises when you’ve got a work force thats used to using square LEGOs all their lives and are now looking at rectangular LEGOs in that odd manner. Don’t believe me? Try talking to SQL folks about XQuery.