Artificial Complexity and Internet Applications

By chromatic
December 2, 2008 | Comments: 4

The Polyglot Programmer

In twenty five years of programming, I've used a couple of dozen programming languages -- perhaps ten or twelve to write serious programs. (I once counted at least ten languages as part of my work on Perl 6 and Parrot; generally two or three for most of my Parrot work.) I've also used at least that many markup languages for serious projects.

Good programmers seem to end up as polyglot programmers. The Pragmatic Programmers have long advised learning a new language every year. Not only does it stretch your mind to move to different syntax and paradigms, but it's a great way to see how idioms in different languages make certain problems easier and harder to solve.

The Language of the Domain

Lisp and Scheme and Smalltalk and Forth programmers all talk about building programs bottom-up, where in effect you create a vocabulary which describes the domain of the problem, then solve the problem by reusing that vocabulary. Though many developers are severely wrong about domain-specific languages, successful software often requires the use of language specific to the problem domain for the names of entities and APIs and other software artifacts.

In one sense, software development is sympathetic magic.

Unsympathetic and Cruel Science

Consider HTML. Consider CSS. They're declarative languages intended to describe semantic elements of a document. The lines get fuzzier when describing CSS, as the extensible nature of HTML and XML attributes allow some degree of customization to insert further semantic descriptions (see microformats) -- but make no mistake. These are languages designed to describe documents and styles. If your business is selling fire engines, you have to add the relevant domain concepts of a fire engine body, chassis, color, siren, model, and engine yourself.

That's not bad -- but likely you've already expressed these concepts in your business logic already.

In a web app, you likely have a relational data store which describes these concepts, often created and maintained through SQL and DDL. You likely have business objects, which describe these concepts again in a class/object form, through some popular modern language. You have a templating system which produces HTML and CSS, or XML and XSLT, which futher manipulate those concepts. You may have JavaScript, which again requires some degree of understanding and expressing business concepts, at least at the presentation layer.

That's three programming languages and at least two markup languages.

Complexity is a Pervasive and Subtle Trap

The HTTP model -- document-based distributed computing on a global scale -- offers tremendous benefits which overcome some of its limitations. In a similar way, the relational model confers many benefits for data storage and retrieval, especially when multiple applications share the same store. As well, one of the hardest-learned lessons of software development is that separation of concerns is more than a good idea. Business rules and presentation logic are different things.

Yet perhaps this separation has gone too far. Perhaps in trying to exploit the benefits of the HTTP/REST model, we've piled language upon language and paradigm atop paradigm, and the artificial complexity of the system grows and grows, until the mishmash between each layer of this rickety tower threatens to overwhelm our solutions.

I'm not arguing that we should all become monoglots again. To the contrary! I wonder, though. Is the current model of building web applications sufficiently simple, or is it holding back systems which would be better, more reliable, more robust, more correct, and easier to build and maintain?


You might also be interested in:

4 Comments

I've moaned about this for sometime.

We have tool proliferation but we're really not making things 'better'.

Bluntly I was better off 25 years ago writing C on both sides of a socket than my current MySQL/Rails/Ruby/HAProxy/Apache/HTML/CSS/Javascript/ActionScript/RubyAMF app.

It's not just the context switch going from one to the other, it's also the impedance mismatch between each layer.

At this stage of the game (post RPC, CORBA, EJB, J2EE) why do we still give a damn where the object lives? Why isn't remote object access transparent to the app? Why are we still beating objects into relational databases? Why is drawing something in a browser fraught with peril?

So many open source projects, so little progress.

I feel in totality that the current model of building web applications is it holding back systems which would be better, more reliable, more robust, more correct, and easier to build and maintain. and I agree with your thoughts.


Good post, and I agree, chromatic.

Though we can't turn time back, sometimes I long for the early days of UNIX and DOS, when I had C in my left holster and Turbo Pascal in my right, and men were men ,,,,, :) *

* See Zane Grey western novels.

It used to be possible to write entire apps (both text-only and GUI ones) in just one language, say C, along with some libraries, or at most in two languages (C and embedded SQL), if you were writing a database-related app, say, using Pro*C or Informix ESQL/C.

Sigh.

>> Why are we still beating objects into relational databases?

Because Dr. Codd proved that there is no superior model of data. Period, Full stop. The OO/xml folk are just re-inventing old wheels (COBOL copybooks and IMS, respectively). To pre-empt the objection: framework programmers (java and otherwise) write Action Objects and Data Objects; which are semantically equivalent to olde COBOL stuff. Just ask Bruce Tate.

I find it amusing is that Model Driven Architecture is making a comeback. All apps are just CRUD for a 3NF database. You just have to know how to make the database.

News Topics

Recommended for You

Got a Question?