lesscode.org

I’d like to follow up Ryan’s post with a quick note on what they call high REST. The definition seems to be using GET/POST/PUT/DELETE. Those are the four significant methods in RFC2616, but every other version of HTTP has contained additional methods, and there are no widely deployed applications that operate that way. WebDAV is a bad example, since it doesn’t use POST, and defines many additional methods. LOCK, COPY, MOVE, and other methods are required to make it a useful protocol. The Atom protocol uses only those four methods, but it hasn’t seen wide deployment (though it may).

This reality sort of pokes a hole in the argument that “high REST” standardizes what is already known to work. That doesn’t mean it won’t work, but GET/POST/PUT/DELETE advocates who claim they are pointing out the obvious are actually making a religious argument, and that poor thesis is playing the role of C-3PO in the Ewok village. It’s unproven technology, and it should be viewed with healthy skepticism.

Discussion on REST seems to be moving in a constructive direction all over the place with Tim Bray and Don Box both contributing. I think Dare Obasanjo’s notes from a talk given by Google’s Nelson Minar almost a year ago may have put some valuable terminology behind ideas that have been floating around for some time and may have even brought us to a place where we can have an actual conversation about this stuff:

To begin he defined what he called ‘low REST’ (i.e. Plain Old XML over HTTP or POX) and ‘high REST’. Low REST implies using HTTP GETs for all API accesses but remembering that GET requests should not have side effects. High REST involves using the four main HTTP verbs (GET, POST, PUT, and DELETE) to manipulate resource representations, using XML documents as message payloads, putting metadata in HTTP headers and using URLs meaningfully.

The definitions of low REST / high REST could be tweaked a bit (maybe they were when I wasn’t looking?) but I do like the idea of putting terms we can all agree on to the subset that’s the reality behind most of machine/web interfaces that seem to be working today. POX isn’t that term because it unnessarily constrains the media type; “low REST” should include the mostly non-XML web (i.e. the text/html, image/*, text/css, text/javascript, etc. web) where it conforms to the constraints of GET and POST.

The reason I like this approach is because it could remove the artificial and often harmful separation made between the web people interact with and the web machines interact with. Exposing resources for machine consumption isn’t any different than exposing resources for human consumption until you get down to the media type (and not then if you subscribe to Microformats). That is, some form of hyper-media (links / URIs) and a simple, universal interface (HTTP) are the really big wins you get with REST because those things are what creates the possibility of having a hugely distributed and uncoordinated system of interaction. The choice of document format is something else entirely and the decisions there ought to be based on a whole other set of concerns.

If I cared at all about the term anymore, I would go so far as to say that anything conforming to the constraints of at least one HTTP method and that also exposes references to other resources using URIs should be considered “a web service”. But “web service” has been defined to death and it doesn’t seem to be helping.

The first time I heard someone attempt to describe the GET/POST subset as something we should pay attention to was Michael Champion on xml-dev. This was usually thrown out when someone championing REST used the “REST is the web and the web is working” argument (I use that argument to this day, btw). Michael would often be the one to point out that it wasn’t exactly true and that a subset of what REST describes seemed to be working well on the web (GET/POST, URIs, caching), while another subset was clearly—sometimes knowingly—being violated (GET w/ side-effects, uncool URIs), and yet another subset was used only rarely (PUT/DELETE/OPTIONS, content negotiation).

Not being able to distinguish which of these subsets of applied REST one is refering to is hurting our ability to have meaningful conversations about this stuff. For example, consider the following conversation; I’ve seen it hundreds of times now:

Restafarian: 80% of developers use the XXX REST API because they find it easier to deal with.
Tool Vendor: That’s not really REST. It only uses GET and POST and breaks rule #5034
Restafarian: Oh yea, well SOAP/WS-* sucks.
Tool Vendor: Go write some PHP you dirty hippie!

I’d like that to stop happening.

But I don’t think adopting wrong or ambiguous terminology is going to help either. I’d like to register my nits with the few sentences that Dare provided and see if anyone else is thinking along similar lines.

To begin he defined what he called ‘low REST’ (i.e. Plain Old XML over HTTP or POX) and ‘high REST’.

Like I said before, POX is kind of, ummm, bad, I think. It focuses too much on the format. XML is not why the web is working. URLs and HTTP is why the web is working. HTTP and URLs work so well they’re even capable of being useful in spite of complexities in media-types based on XML.

Low REST implies using HTTP GETs for all API accesses but remembering that GET requests should not have side effects.

Fully constrained GETs are really important but POST should fall under low-REST too. By the definition above, low-REST can never modify anything. Throw POST in there, it’s a big part of the present day human/web and is likely to play a bigger role in the machine/web.

High REST involves using the four main HTTP verbs (GET, POST, PUT, and DELETE) to manipulate resource representations, using XML documents as message payloads, putting metadata in HTTP headers and using URLs meaningfully.

I think we ought to downgrade XML to a “bestcommon practice” or something. Microformats and JSON are two notable examples of non-XML representations that seem to be working quite well and are absolutely capable of being used high-RESTfully.

I’m pretty sure I’ll always be a high-RESTafarian but I could definitely see myself coming out as a lo-RESTafarian as well if some of this were grinded out a bit more.

SYS-CON Media publisher/editor Jeremy Geelan, a fine chap who interviewed The Father of Java just the other day, contacted me about re-publishing Gosling Didn’t Get The Memo on sys-con.com. This is the same site that published Gosling’s original remarks.

It took me about five seconds to agree, within an hour we were sharing the front page with the original Gosling quote, and we’ve just now broken into the top three most heavily read articles on the site for the day. The republished post is here and is pretty much an exact copy (comments and all).

So yea, I’m stoked.

I should also mention that there was likely some back-channel prodding that helped lead to this. Adaptive Path’s Jesse James Garrett was panelist at the SYS-CON hosted Real-World AJAX event earlier this week in New York (see: Geelan interviews Jesse). From what I can gather, Jesse played no small part in getting the article picked up.

Huge thanks to both Jesse and Jeremy from lesscode.org.

I’ve been actively developing software for the past 17 - 18 years. When I began, back in 1987, the recommended language of choice was C. The rationale at that time being that C is a language that closely and faithfully mimics the inner workings of the underlying low level machinery.

Obsession with the infrastructure. Yes, computing infrastructure is fascinating. But what is a computer?

Mainframe is the Computer

If you asked IBM 20 years ago what is a computer, they’d tell you that the mainframe is the computer. They were selling mainframes at that time, and to them every problem looked like a nail.

Network is the Computer

At around the same time, Sun Microsystems attempted to take over the world with their slogan “Network is the computer”. The exact opposite of mainframes. Great.

Database is the Computer

Also, another big-ass vendor, Oracle, had to make an attempt to take over the world with their vision of a database being the computer. Yes, databases are fun.

Desktop is the Computer

Finally, Microsoft took a swing at it by announcing that desktop is the king. Yes, desktop is so cool, so sexy. And, as it became more and more affordable, it really started taking over the world by the storm.

Who cares?

Really, honestly, who cares? Why should we care? Why should we act as foot soldiers (unpaid foot soldiers, mind you) for those vendors? It’s like us paying them to bombard us with their advertising.

I must say that I’m at a loss when it comes to why are we, 20 years after these ugly vendor wards started raging, still caught in the debate. What’s in it for us? Yes, we all understand what’s in it for the vendors. But, why should we care about helping them see that their definition, their slogan wins?

It’s like getting caught in trying to define what is electricity. The producers of electric power claim that electricity is turbines that generate it. The producers of copper wires claim that electricity is wires. The producers of light bulbs claim that electricity is the end-point, the light bulbs that deliver incandescent light to our homes.

But do we, as consumers, care whose vision wins? No. All we care for is that when we turn the switch on, the room gets filled with light.

Who is Serving Whom?

My understanding has always been that we have invented computers to serve us. Now I see that all we’re doing is expending inordinate amounts of time serving them. I don’t see any justification for why this should be so, and I therefore proclaim here that it’s high time that we cease and desists and insist that all this computing infrastructure start serving our needs.

But in order for that to happen, we first must stop obsessing about the computing infrastructure. It’s about time we get over it.

Applications are Infrastructure

Just so that we’re clear on what encompasses the computing infrastructure, I’d like to point out here that it’s not only about the hardware and the middleware and the operating systems, databases, and frameworks. Application software also counts.

We all know how much we tend to obsess about the applications. Many of us find a number of software applications fascinating. Well, snap out of it! Stop serving your favorite applications, and start looking into how to make those applications serve you.

You should start looking at applications as being a kind of anomaly, a necessary evil produced out of dire necessity in the attempt to cover the gaping holes in the existing computing machinery. Applications are superfluous, and will eventually recede into the background. Today, they hold the center stage, and many people obsess about them. But that is bound to change.

Once we grow up and stop obsessing over the infrastructure, we’ll finally be ready to embrace the wonderful world of computing on our own terms. This is similar to how we had to grow up and embrace the wonderful world of printed word. It wasn’t easy, and it took some serious schooling, but eventually we managed to pull it off.

Yes, there are still pockets of illiteracy even among the most developed countries, but these are negligible compared to the overwhelming literacy that is now the cornerstone of our culture.

I’ve been blissfully neglecting this site for months with the assumption that a large part of our goal was completed. After watching good people like Martin LaMonica and Jon Udell balance out the mainstream tech press with coverage of lessish tools and languages, and having seen forward looking companies like RedMonk inject themselves into the traditional analyst racket with smart, honest, and unignorable critique, and having seen herds of Java luminaries migrate to simpler, more agile tools and languages, and after hearing Bill Gates say that less code was the only metric, and having watched David, Bill, Ian, Adrian, Phillip, Aristotle, Harry, Mark, Mark, Chad, Curt, James and many other extremely talented programmers dismantle all the common hollow arguments for superfluous complexity and replace them with simple methodologies and working code, after all that I just figured there wasn’t much to do around here.

But I completely forgot about James Gosling:

“There have been a number of language[s] coming up lately,” noted James Gosling today at Sun’s World Wide Education & Research Conference in New York City when asked if Java was in any kind of danger from the newcomers. “PHP and Ruby are perfectly fine systems,” he continued, “but they are scripting languages and get their power through specialization: they just generate web pages. But none of them attempt any serious breadth in the application domain and they both have really serious scaling and performance problems.”

We’ll get back to that in a second.

I believe that a majority of people in IT now consider dynamic languages like Perl, Ruby, Python, and PHP to be very much capable of sitting at the table with Java and .NET for a wide range of common technical problems. Similarly, straight-forward systems like REST, Microformats, and Atom are generally considered legitimate alternatives to the vendor/analyst/press peddled technologies like WS-* for a wide range of integration issues. In other words, I could walk into most shops during a technology evaluation and put these technologies on the table as legitimate considerations without being too worried about being laughed out of the room. This is not to claim superiority for a given task, just that the competitive playing field is beginning to level off.

This was not the case last year at this time, so what happened? Something must have changed. None of these technologies underwent huge feature or stability increases in the past year. I’m unaware of any breakthrough in scaling these systems past what they’re already capable of. There have been some improvements in running dynamic languages on the mainstream VMs, which many predicted would lead to quick acceptance, but that’s not it either. So what changed?

Minds changed. Respectful debate, honesty, passion, and working systems created an environment that not even the most die-hard enterprise architect could ignore, no matter how buried in Java design patterns. Those who placed technical excellence and pragmaticism above religious attachment and vendor cronyism were easily convinced of the benefits that broadening their definition of acceptable technologies could bring.

The people who are still unconvinced are those that just don’t care or are too lazy to spend a small amount of time researching and validating the arguments, which brings us back nicely to James Gosling’s recent statements.

On The Current Quantity of Language

“There have been a number of language[s]

This part is notable because it’s actually true. There have, in fact, been some number of languages. While I stand steadfastly by James’ analysis of the current quantity of language, we will quickly diverge in opinion from here.

A quick note to aspiring Java pundits: play close attention to the next few statements. While none of them have any basis in reality, they have proven sufficient in creating fear and uncertainty in the minds of those who are evaluating these technologies.

On “Scripting Languages”

“PHP and Ruby are perfectly fine systems,” he continued, “but they are scripting languages

James pulled this directly out of “Effective Java Advocacy Beans”, section 6.8.3 “Dealing with questions on dynamic languages”:

First, call anything not statically compiled a “scripting language”. Attempt to insinuate that all languages without an explicit compilation step are not to be taken seriously and that they are all equivalently shitty. Best results are achieved when you provide no further explanation of the pros and cons of static and dynamic compilation and/or typing and instead allow the reader to simply assume that there are a wealth of benefits and very few, if any, disadvantages to static compilation. While the benefits of dynamic languages–first realized millions of years ago in LISP and Smalltalk–are well understood in academia, IT managers and Sun certified developers are perfectly accepting of our static = professional / dynamic = amateurish labeling scheme.

This technique is also known to result in dynamic language advocates going absolute bat-shit crazy and making complete fools of themselves. There have been no fewer than three head explosions recorded as a result of this technique.

Also, avoid the term “dynamic language” at all cost. It’s important that the reader not be exposed to the concepts separating scripting languages like bash, MS-DOS batch, and perl-in-the-eighties from general purpose dynamic languages like Ruby, Python, Smalltalk, and Perl present day.

We’ve tried our best to clear up any ambiguity related to the term “scripting language” in the past:

• Wikipedia: Scripting Language describes the difference between specialized scripting languages and general purpose dynamic languages.
• The State of the Scripting Universe Van Rossum, Thomas, Hobbs, Conway, Pall weigh in on this misconception and others.
• Web Dominated by J2EE? is a rant on an article spreading the same misinformation.
• Arrogance, ignorance, and a blinding Sun is David Heinemeier Hanson correcting the same misinformation somewhere else.
• RADlab, scripting and scale, a blog entry by Gosling saying the exact same stuff and a comment thread full of people correcting Gosling’s dated evaluation of dynamic languages.

On “They Just Generate Web Pages”

and get their power through specialization: they just generate web pages.

Gosling shows his ignorance regarding the current feature set provided by dynamic languages and what people are using them for. A cursory glance over rubyforge.org’s project tree reveals that the number of projects that “just generate web pages” are really quite small: 151 of 1,342 total projects are registered under Internet::WWW/HTTP::Dynamic Content and many of those projects are related to using the web (HTTP/URIs) as a platform for integration more than they are for “generating web pages”. I expect Perl and Python break down even wider.

Update: Seo Sanghyeon provides a list of popular Python related applications that have nothing to do with generating web content.

I’d also like to note that exposing resource representations via HTTP/URLs has been moving into areas other than “generating web pages”. This was the plan when HTTP was originally designed but has only recently begun to really catch on. Specialization and enhanced capabilities related to generating and serving hyper-media over HTTP are and will continue to increase in value. The web server is becoming a key piece of integration infrastructure. What James refers to as “generating web pages” is now a general purpose technique for exposing resources to anything outside of the application process.

On “breadth of application domain”

But none of them attempt any serious breadth in the application domain

It’s hard to determine what kind of breadth is missing when you consider the capabilities provided by modern dynamic language environments, the platforms they run on, and the extensions and bridges that allow them to use damn near any other program or library available. James uses the example of “interplanetary navigation”, which is a really good example except that it isn’t; most of us aren’t working at NASA and those of us who are working at NASA are doing things like trying to get the payroll and accounting systems working together or building simple productivity applications. Gosling seems bent on meeting the needs of the 20% while leaving the 80% with a platform that’s losing bids to dynamic/agile shops.

“That’s the kind of power I do not envy”.

Lastly, Peter Yared (former Sun hacker) and the rest of the folks over at ActiveGrid should also be interested to learn that no one is attempting to widen the viability of dynamic languages in the “application domain”.

On Scaling and Performance

and they both have really serious scaling and performance problems.

It is simply not possible for me to add anything to the massive set of material addressing this topic.

Scalability:

• Why PHP Scales
• Large Scale PHP
• The PHP Scalability Myth
• The J2EE guy still doesn’t get PHP
• IBM poop heads say LAMP users need to “grow up”
• It’s boring to scale with Ruby on Rails
• Does Ruby on Rails scale? A clear and definitive answer
• New Take On Scalability
• Scaling with Rails
• What’s all the fuss about Ruby on Rails

Performance:

• High performance PHP
• A subjective analysis of two high-level, object-oriented languages
• Making the Case for PHP at Yahoo!
• Is Ruby Better Than …?
• RailsExpress.blog

Why people are upset

There have been multiple responses to Gosling’s statements ranging in sentiment from outrage to amusement:

• Curt Hibbs: It’s sad, James Gosling is clueless
• Chad Fowler: Gosling Thinks Ruby Just Generates Web Pages
• David Heinemeier Hansson: Pay no attention to the heathens and Distinguishing power from versatility
• Assaf: James Gosling Explains what’s wrong with Java
• James Robertson: The Static Empire gets Nervous
• Frank Wiles: Seriously funny

All we’re asking is that you stop spreading misinformation about the current state of dynamic languages to the press, analysts, and your customers. This does not require you to champion or otherwise support these technologies – just stop lying about them. One year ago, this type of behavior could be attributed to a lack of documentation and discussion on these issues, today it’s impossible to attribute to anything but malice.