lesscode.org

I couldn’t resist jumping into the Choose a single layer of cleverness discussion, that is raging on David Heinemeier Hansson’s blog. The majority of the challenges to David’s thesis were so widly off mark, that it had left me completely bewildered. What’s even more bewildering, to me at least, is that many of the misplaced comments seem to be coming from established Ruby and Rails practitioners.

Anywho, the comment that got my particular attention is quoted below; my full reply is reproduced below the quoted comment:

“Just like I’d expect my operating system to respond if I try to write to a file I don’t have permission on, I want my database server to manage the basic rules of the DATA, ie, what relates to what, and which columns should be unique. This is to prevent anything out of the ordinary from affecting the consistancy of the database. The minute you let bad data get in there is the minute any maintainability you love in your application tier goes to hell.”

Bzzzt! Right here, we have the crux of the problem.

I think the cognitive discrepancy lies in equating RDBMS with an operating system. Nothing justifies that parallel.

If we step back and look at what RDBMS is, we’ll no doubt be able to conclude that, as its name suggests (i.e. Relational Database Management System), it is a system that specializes in managing the data in a relational fashion. Nothing more.

Folks, it’s important to keep in mind that it manages the data, not the MEANING of the data!

And if you really need a parallel, RDBMS is much more akin to a word processor than to an operating system.

A word processor (such as the much maligned MS Word, or a much nicer WordPress, for example) specializes in managing words. It does not specialize in managing the meaning of the words.

So who is then responsible for managing the meaning of the words? It’s the author, who else?

Same is with Rails. Rails is the author of the data. As an author, it uses the RDBMS to manage that data in a relational fashion. But, just as we, as the authors of the words, do not expect WordPress to manage the meaning of our words, Rails does not expect the RDBMS to manage the meaning of its data.

As a matter of fact, it would be really terrible if those tools would assume the management of the meaning of the information that is being fed into them. Imagine typing up a letter, only to be jolted when your favorite editor refuses to take the word you’ve just typed, deeming it ‘incoherent’, or ‘not complying with certain constraints’. You’d toss that piece of junk out the window in no time.

Why should Rails developers be any different? Why should we tolerate RDBMS opinions on our data? We’re the masters, RDBMS is the servant, it should shut up and serve. End of discussion.

As for the ongoing ‘the sky is falling’ discussion about what if some other device accesses the RDBMS, it’s the same dilemma as ‘what if some other person accesses our document, and starts changing it?’ There are ways to manage that. Yes, we’re always exposed, always vulnerable to all kinds of attacks, but that’s how life is. You should start getting used to it by now.

Having spent some time in the VS2005 environment, I can say the following about DSL’s:

A domain-specific language (DSL) is a language designed to be useful for a specific task in a fixed problem domain, in contrast to a general-purpose language. DSLs are gaining popularity in the field of software engineering to enhance productivity, maintainability, and reusability of software artifacts, and enable expression and validation of concepts at the level of abstraction of the problem domain.

Using domain-specific languages, one can build customized modeling tools and essentially define a new modeling language and implement it very simply. For example, a specialized language may be used to describe a user interface, a business process, a database, or the flow of information, and then used to generate code from those descriptions.

I built a (small) DSL for modeling application integration scenarios, which is always an issue in the IT business world. First, I defined all of the specific domain model terms used in application integrations scenarios such as XML messages, source – destination applications, XSL maps, business units, protocols, business rules, etc. Then I described the designer definitions that make up the visualization tool. Once the meta data was defined in a supplied Visual Studio template, you build the solution and another instance of Visual Studio fires up with your visual designer implemented.

You then use the visual designer you just created to draw/model the application integration scenario and when you run this solution, it code generates the solution.

Of course, I have left out a lot of detail and it was not easy the first couple of times. I have left out a set of code generators, which take a domain model definition and a designer definition as input, and produce code that implements both of the components as output. The code generators also validate the domain model and designer definition, and raise errors and warnings accordingly. But eventually, you get the hand of it.

Think of it this way, DSL is a tool for building tools :-) For example, anyone that has used the Class Designer in Visual Studio is using a DSL outputted visual designer, specifically designed for building classes.

The process has been quite the learning experience for me and has proven to be very enlightening. I am an old guy, been writing code for 15 years. Quite frankly, I don’t give a hoot about which programming language I use cause I see them all as being the same, some better than others, but still hand crafting code. I don’t want to hand craft code anymore – every time I get involved in a software development project I a) have done it before and b) oh man, this is going to take 6 months of grinding it out. In other words, it’s gonna hurt.

I see DSL’s as a evolution in our software industry to use higher level abstractions in the way of visual designers to so that I can spend time “designing” the solution and have most of the infrastructure code generated for me, that I otherwise would have to grind it out.

If anyone is interested in more information about DSL’s and don’t mind reading it from Microsoft, download the DSL Toolkit and have a read of the documents at: Microsoft Domain-Specific Language (DSL) Tools

A number of people that are making the painful transition to lesscode seem to misunderstand the underlying philosophy of the movement. For some reason, some of them get hung up on the quantity (read: number of lines of code). But, by doing that, I’m afraid they are completely missing the boat.

Let me state it in no uncertain terms: lesscode is not about the number of lines of code. In other words, we can revisit some legacy app and rewrite it so that in the end it results in dramatically smaller amount of lines of code, and still not produce an app that would qualify as being ‘lesscode’ worthy.

So if not the number of lines of code metric, what then would qualify an app as being a bona fide lesscode product?

The thing that often gets overlooked when we’re talking about the lesscode discipline is that there is a qualitative aspect to it. Yes, the most obvious factor that hits us upon inspecting a typical lesscode app is the drastically reduced number of lines of code, but that phenomenon is merely the outcome of some deeper, less visible causes and conditions underlying the discipline. We need to now expose and examine those causes and conditions (and stop fixating on mere symptoms):

1. Je ne sais quoi (“I know not what”) – the indefinable quality. Christopher Alexander calls it Quality Without A Name
   
   This sounds like a bailout answer; however, it’s actually very true. Lesscode is qualified by something that is utterly satisfying, yet no one can put their finger on it.

2. Language choice – the language we choose for writing the code determines how we think about designing and programming. Choosing to write code in Assembler or in COBOL would not be very conducive to producing the lesscode app that would be utterly satisfying.

3. Smart Servant – if the platform/language of our choice is very needy, very fussy and expects us to exert exorbitant amounts of effort just to keep it from throwing a fit any time something changes, that situation will not be very conducive to producing a lesscode worthy product.

What we really need if we are to practice the discipline of lesscode is a Smart Servant product. What that means is that such a product must be very non-intrusive and very supportive of our flakey short term memory. The only realistic way to develop a truly lesscode app is to work in an environment that minimizes the cognitive friction.

A significant problem in the trenches for Web Services isn’t the ability to play nice or not with existing Internet protocols, or its complicated type system, or Object/XML impedence. It’s optionality. When you get down to it, too much in Web Services is optional. Calling the specs composable and thus dressing that up as feature is pointless - optionality is a curse. Yes, WS specs are designed to be composable, but this underplays the fragmentation costs of not having an interoperable core.

Optionality here means: a) the state space for communications is huge , b) everything has to be negotiated, c) no clear layering resulting in dependency issues. These introduce complexity and thus drive up costs. As a result I disagree that implementing something like WS-Eventing is “simple”, exactly because there is freeform composition. And that’s just WS-Eventing. What about addressing, transfer, policy, wsdl, faulting, the various reliable messaging approaches? The list goes on and on. Even the basic SOAP stack seems to be difficult to get right; we’re on the third generation inside 7 years of what is supposed to be stable computing infrastructure.

Favouring optionality can’t possibly be a good idea for protocols, or even protocol frameworks like SOAP. In that sense RSS or Atom have more interop potential, precisely because they take options away by design, even though they wouldn’t present an obvious choice for mainstream enterprise purposes.

Ur-Protocol

Here’s Elliotte Harold and Ted Neward arguing over the merits of HTTP as a Highlander Protocol.

Elliotte:

“Web Services Addressing is trying to define an addressing scheme that can work over HTTP, SMTP, FTP, and any other protocol you can imagine. However, each of these protocols already have their own addressing systems. Developers working with these protocols don’t want and don’t need a different addressing system that’s marginally more compatible with some protocol they’re not using in exchange for substantially less compatibility with the protocol they are using. Besides nobody’s actually doing web services over anything except HTTP anyway. Doesn’t it just make more sense to use the well understood, already implemented debugged HTTP architecture for this instead of inventing something new? “

Ted:

“No, it doesn’t. There’s no sense in trying to take bits that were designed for a distributed hypermedia system (Fielding’s words, not mine) and trying to bend it to fit a problem space that isn’t distributed hypermedia. Can we learn from the REST architectural style? Absolutely–and the new WS-* specs, including SOAP, do exactly that, favoring self-descriptive messages over RPC calls as the principal abstraction to deal with. But does that mean we tie ourselves solely to HTTP? Oh, hell no.”

The problem with using HTTP as the Highlander protocol has been described best by Marshall Rose:

"HTTP has become the reuse platform of choice, largely because:
 - it is familiar
 - it is ubiquitous
 - it has a simple request/response
 - it usually works through firewalls
These are all good reasons, and - if HTTP meets your communications requirements - you 
should use it. The problem is that widespread availability of HTTP has become an excuse 
for not bothering to understand what the requirements really are. It's easier to use HTTP, 
even if it's not a good fit, that to understand your requirements and design a protocol 
that does what you really need."  

HTTP bias aside, sometimes you do have to work across multiple protocols. That results in the problem of managing and preserving addresses and message identity. And when you do have to span protocols and systems for messaging purposes, especially where there are multiple self-interested administrations, you want to have a standard envelope that provides at minimum a means of identifying the message, the sender, the recipients, and probably time stamping. Some kind of ability to correlate messages. These are baseline criteria - without them you’re toast. You need standard headers not just for routing traffic (important) but because you need to know what the heck is going on operationally - you want a standard means of asking the various endpoints (or nodes, or gateways, or hubs, or whatever you want to call them) questions. Where is my message? How many messages did you drop? Which messages did you drop? When? Whose messages are you dropping? Will you resend this message? How many messages have you sent to so and so? What open items do you have? And so on. However WS, and in particular, SOAP, doesn’t provide a standard (as in non-optional) set of headers and thus it doesn’t provision this kind of generic communication facility. I’ll confess that this has never made sense to me, given SOAP’s protocol framework and inter-systems ambitions.

Ted has a specific rant about broadcast and push being unsuitable to run over HTTP. I don’t think there’s any argument that, formally speaking, HTTP is not the right protocol for those jobs. But here’s the kicker. Blogs and RSS syndication are exactly that, done over HTTP infrastructure. The world has not gone running to push RSS over XMPP because there is obviously a scale problem when you draw things out on a napkin. [Which is not to say this writer wouldn’t like to see more Atom over XMPP; it’s clearly a good idea. Nonetheless the Web sky is not falling in yet. ]

And even in the push scenario, what’s the point of a protocol framework? Why not use XMPP for push/pubsub? Does this mean when people on the ground start getting Eventing systems and EDAs built out over commodity IM, can we expect to see another rounds of the “It’s Not Sufficient” meme played out again, this time for messaging protocols?

What now for SOAP?

If you want to span systems asynchronously in a manageable fashion you’ve got to have standard models for addressing and identity baked in. These are not optional if this stuff is expected to work. It’s taken some time for the WS community to get round to dealing with addressing and naming, but this is key stuff for getting something done over a gateway and for me, SOAP’s value is largely in dealing with gateways asynchronously. Addressing being an optional add-on to SOAP is quite strange then, although now that it exists that’s good news. Down the line then what would be useful is a subset and hardening of SOAP; a 1.3 revision where WS-A and some key message headers are non-optional.

WS should be starting out with, and not ending with, profiles like RAMP.

I’ve written previously on the trade-offs that microformats make in vocabulary design. I’m still not sure how I feel about the short-string issue, but it appears no one is waiting for me to make up my mind, so I figured I’d try it out.

So far I like it that microformats depend on well-understood technology, and that a lazy dev could point their HTML rendering component at the page if they didn’t feel like writing support. OTOH, parsing can be a bear. I think I may have cheated a little in that I insisted on XHTML, but even that had its own problems, since it’s tied to a DTD. Either you write your own entity resolver or the XML parser downloads three DTD files from w3.org. Rotten. I let my example client do just that in the interest of brevity.

On the lesscode side of things, the draft includes Python implementations of a client and server. With margins, the IETF txt format ends up allowing something less than the usual number of columns, so it cramped my Python style a little bit. I think they ended up pretty short, but one of the nice things about Python is that someone can always show you a way to do it that’s shorter and clearer. So, let’s have it! (no generators allowed, to keep things adaptable to those other languages :)