My lab partner Devlin and I were talking the other day about a talk by Roy Fielding. He allegedly spoke on the way that REST has been misconstrued by its partisans, self-proclaimed RESTafarians. In his dissertation, Dr. Fielding described REST not as an "optimal" software architecture but as one that naturally emerges on the web because of the unique constraints imposed by HTTP. During the talk, Dr. Fielding challenged his audience to consider the natural architectures that might emerge if the constraints were different: what would a web built on a stateful protocol, or a non-uniform protocol, look like?

Of course, rather than actually considering Dr. Fielding's question my mind has been on other applications of his methodology. I've been working (for some value of "work") on yet another programming language (no, it's not called "YAPL"). The idea so far has been to combine JQuery-style Javascript with Erlang's pattern matching and async message passing, while ditching Erlang's single assignment and obtuse syntax. Now I'm wondering if that's such a great idea - not because I like the syntax (which is grody in the extreme) or single assignment (since mutable state is often easier on the brain), but because I'm wondering if Erlang's nice concurrency features are an emergent feature of the whole programming system, dependent on the language's flaws as much as its strengths for structure. Maybe in a world where Erlang had sane syntax, none of its cool applications would exist?

Similarly, the hot new document-oriented database paradigm exemplified by CouchDB and BigTable seems at first glance to put some pretty serious constraints on developers. I'm sure it'd be the first reaction of many programmers to address those constraints by adding features, or publishing workarounds. Unfortunately, removing the constraints, even in the interests of performance or user-friendliness, could detract from scalability, the databases' primary feature.

I'll add just a couple of final questions to this post-with-lots-of-long-sentences... what constraints are you trying to work around that you'd be better off leaving alone? How can you better "go with the flow" and work with emergent architectures instead of against them? Are you making life a little tougher than it is?

Tags: september 21st 2007 programming erlang jquery toga couchdb bigtable constraints REST