lesscode.org

Mark Jason Dominus:

If the Design Patterns movement had been popular in the 1980’s, we wouldn’t even have C++ or Java; we would still be implementing Object-Oriented Classes in C with structs, and the argument would go that since programmers were forced to use C anyway, we should at least help them as much as possible. But the way to provide as much help as possible was not to train people to habitually implement Object-Oriented Classes when necessary; it was to develop languages like C++ and Java that had this pattern built in, so that programmers could concentrate on using OOP style instead of on implementing it.

Update: and an excellent follow-up by Mark addressing a response by Ralph Johnson (one of the Gang of Four).

I wanted to point out an article called Why learning Haskell/Python makes you a worse programmer.

When I found the link in my aggregator, I was expecting the worst, but the title is just gratuitously incendiary. The actual article is thoroughly reasonable. It asserts that learning better languages will make your day job an excercise in demoralization and then asks the question: if you’re a C#/Java developer in the trenches, how do you benefit from your broadened horizons?

There is lots of good discussion in the comments; don’t skip them. What there is not, unfortunately but unsurprisingly, is an easy solution.

With all this talk about High and Low REST, I noticed something in a post by Mark Nottingham:

Don has effectively made the observation that a lot of other people (especially of the Web services sort) have made; while the benefits of GET’s transparency are obvious, they’re less apparent for PUT and DELETE, so why not just take the easy (lo) road and use POST?

I think there are two answers; 1) hopefully, we’ll have some concrete benefits for that transparency some day (think offline), and 2) thinking in terms of GET/PUT/DELETE first — using POST only as an escape hatch — leads you down a path where your application will be using transparent methods a lot more than opaque POSTs.

I’ll use my first post here to repeat the ideas from Bill’s post…

I think a cargo cult of REST has indeed emerged, and I’m seeing evidence of it on the ground, far from SOA discussions. I’m seeing REST evoked as something that is inherently good. I’m seeing people ask for REST support in their frameworks. I usually know what they mean, but their requests seem to be driven by the truthiness of REST, not the utility.

For instance, I often get annoyed with URI design discussions, where people put great importance into abstract design issues that no one else will notice or care about. In HTTP (and REST) URIs are supposed to be opaque strings, so why the obsession? I call bike shed. People are tackling the pointless decisions first, because they are low-stake and easy to think about. It also comes from an inversion of logic: good things are generally aesthetically pleasing; but many things that are aesthetically pleasing are superfluous and distracting.

What’s useful is that REST design doesn’t promise anything more than it can deliver. It doesn’t promise anything general about the body of the response (except I suppose that Content-type and other metadata will be accurate). It doesn’t promise anything about the URI. The use of verbs is in part to make the URI more opaque, so instead of rewriting the URI to express new actions, you use different verbs on the same URI. GET actually means something to intermediaries. POST, PUT, and DELETE only really mean something to humans. Which is okay, but it’s not interesting architecture.

It’s not bad to use these verbs, it’s just not particularly useful. I think High REST may be the result of people who just can’t help but make architecture. Low REST is people who are recognizing emergent architecture. REST isn’t a new idea, it is the recognition of the good ideas that are already around us. And like design patterns, the description is turning into prescription, and as with patterns we are seeing people use REST to justify premature architecture — probably a much worse sin than permature optimization.

I look at a protocol like OpenID which is wedded to HTTP and HTML — and even intimately connected to those poorly-specified browsers that we all can’t help but hate — and I think that’s great architecture. It’s not great because it is pretty underneath (it isn’t), it is great because it solves a hard problem inside fixed constraints without exceeding scope. It’s RESTful at heart, but not RESTful in form.

If there aren’t concrete benefits to using PUT or DELETE over POST, then why should we care? What hard problem is made easy? High REST seems to be uncovering non-problems.

Today’s myth: limiting the number of methods is a good idea.

From an old thread on WebDAV methods:

REST encourages the creation of new methods for obscure operations, specifically because we don’t want to burden common methods with all of the logic of trying to figure out whether or not a particular operation fits the 99.9% case or one of the others that make up 0.1%.

That doesn’t mean you want to make up a new method if you don’t have to, like getStockQuote. Use GET /stockQuote/43 for that. A small number of methods will get you pretty far, but perhaps not all the way. For authoring applications, you’re likely to hit some snags. You’re also likely to hit some religion.

I’ve branched off into the new thread (from Should Database Manage The Meaning? thread ) in order to start from a clean slate. The previous thread still has a number of unanswered questions lingering, and I didn’t want to introduce new ones.

What the lively debate in the ‘database and meaning’ thread revealed to me is that a number of people appear steeped in the shared data model/architecture. They’re all talking about multiple applications hitting a single database, and how that peculiar situation dictates stringent demands on what the database must be and how it must behave.

I come from a different world. In my world, the data is not sedentary, it is mobile. It travels places. As such, it is not shared, it gets to be exchanged.

Now, as you will no doubt have no problem imagining, if two or more apps are exchanging data, they don’t care where is that data coming from. Let’s say they all exchange the data using some sort of a schema (XML schema, most likely). What ends up happening is that data starts travelling back and forth (mobile data). The receiving apps have no way of ’sniffing’, or figuring out whether the data that had just arrived is coming from a fuly normalized RDBMS, or from a flat file, or from an email server, or from a legacy data store (Domino), or from some hairy brained hierarchical mainframe database, or what have you.

So, this is the reason why I’m so befuddled upon learning that so many people regard RDBMS as a holly grail. What difference does it make, once the mobile data hit the street?