lesscode.org

• The Meme.
• The Architecture.
• The Wikipedia Entry.
• The Tag.

Recently David Heinemeier-Hanson asked “How do we fork the word enterprise?”. This will do for now.

via Patrick Logan and Mark Baker

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.

Sam Ruby posts the slides from his FOSSSL keynote entitled, “The Case For Dynamic Languages”.

The slides make the case as well as slides can. I especially liked this bullet on Macro-performance vs Micro-performance:

Modest hardware running Perl can easily saturate your bandwidth

Similarly powerful arguments all the way through…

Jason Hunter (Jason Hunter), a renowned Java evangelist an the author of two highly popular books on J2EE technology (Java Servlet Programming, and Java Enterprise Best Practices, ) posted an interesting blog entry last week: The Innovator’s Dilemma: It’s Happening To Java. The “innovator’s dilemma” that Jason is talking about is expressed as follows: “you can listen to customers, provide them with what they want, but still lose out – because a cheaper, not-as-good but good-enough competitor comes in and eats your market.”

Kind of reminds me of the days when I was shopping for my home audio system. I used to visit lots of high-end shops, where knowledgeable sales personnel would engage me in detailed demos of various components, but at the end of the day I would walk across the street to some of those cheap outlets (Circuit City etc.) to see if I could get same or similar components for less.

The dilemma Jason is referring to is specifically related to Java. Here we have an exorbitantly expensive platform, that, ten years after its launch, had reached a point where it is too complex to be able to be used in any meaningful, let alone feasible fashion. So, in a way, we could say that the situation is similar to what was happening to the mainframes 15 - 20 years ago, when the businesses reached the end of their rope and realized that they need to adopt a more disruptive technology.

Jason’s thesis is that Ruby on Rails is this disruptive technology. Java is now being perceived as a sitting duck, similar to how mainframes were the sitting ducks of the early nineties. And similar to how client/server technology came about and claimed the market share traditionally reserved for the mainframes, RoR is today poised to eat into the Java’s market share (hence the ‘disruptive’ epithet).

One of the strongest arguments he makes about RoR’s threat is this one: “In programming these days, cheaper isn’t about price, it’s about mental effort.”

Now, anyone who’s ever tried to develop a web application using the J2EE frameworks, and then tried to to the same thing using RoR, will undoubtedly agree that RoR requires significantly less of a mental effort. And thus, RoR is significantly cheaper.

Ironically, it was this same quality that made Java so attractive 10 years ago. Due to the fact that Java was so much simpler than C++ (so much so that in its early days Java used to be called ‘C minus-minus’), it made huge inroads into the development community’s mind share, and overtook C++ as the language of choice when it comes to developing applications. Lowering the cost of software development is obviously a strong driving force in motivating the adoption of the new technology.

The mood in the Java camp nowadays is really strange. As is to be expected, the prevailing sentiment is the one of huge denial. This is similar to the mainframe crowd sentiment 15 years ago.

But the odd thing is that the same people who tend to shrug off RoR’s threat to Java seem to be at the same time working frantically on proving that Java can be concise too. Ironically, they are attempting to introduce simplicity into the Java platform by adding new features to it! This leaves an open question: since when is bloat to be regarded as simplification?

In the final analysis, it is extremely significant that a number of top-echelon Java evangelists are jumping into RoR heads first, and are buying into it hook, line and sinker. The worrisome aspect of all this is that, once RoR takes off and hits the mainstream, who’s going to do the new development? Most of the existing development workforce hadn’t managed yet to make the transition from procedural to object-based approach. The full fledged OO nature of Ruby, coupled with its dynamic nature, may prove to be too big of a challenge for the average application developer out there.

Twenty years ago I got involved in a course of AI (Artificial Intelligence) study. Soon afterwards, I’ve learned, much to my dismay, that this field has been, somewhat maliciously, dubbed ‘giant solution in search of a problem.’ Much as I’ve tried to convince myself (and the others) that AI has some pragmatic potential, I had to eventually abandon my efforts, and turn to some of those truly pragmatic solutions (such as RDBMS, for example).

History tends to repeat itself, and so (not surprisingly), I’ve ran into the same scenario (i.e. got involved with more than one ‘giant solution in search of a problem’, or GSISOP) throughout my meandering career.

The first major bump in the road was working with CASE (Computer Aided Software Engineering) tools. Those beasts used to be all the rage in the mid to early ‘80s, but witness the speed with which CASE turned into a dirty word in the early ‘90s. That utopia had to be abandoned promptly.

The next bump came in the form of ‘screen scrapers’ which were proposed as a GSISOP to bridge the gap between the monolithic mainframe apps and the burgeoning two-tier client/server enablers.

One of the biggest GSISOP bumps I’ve ever experienced was Lotus Notes, later dubbed Domino (does anyone even remember that unruly beast?) That platform was so ridiculously clunky, that even the biggest Domino zealots had extremely hard time explaining what is it that this product actually does?

Fast forward to 2005. What is the GSISOP we as a development community are forced to deal with today? CASE is dead as a doornail; screen scraping and client/server are dead as well; so is Domino. Does it mean that GSISOP is dead too? I wouldn’t bet the farm on that.

Ten years ago I’ve abandoned the world of two- and three-tier client server technology for the new kid on the block. That kid was then called the ‘nomadic code’. Remember the ‘network is the computer’ slogan? Or, for that matter, does anyone here remember the ‘PC killer’ – the NC (the network computer, or the glorified dumb terminal that was all the rage back in 1996)?

I remember how in those heady days me and some of my more idealistic colleagues firmly believed that the applications of the future will consist of modules of highly mobile code buzzing around the net, arriving ‘just in time’ to assist with some hairy, highly critical, highly demanding and customized behavior. We furthermore believed that these modules will live in a highly competitive environment, vying for the end-user’s attention, competing to deliver the best, most robust service, thus building their own reputation. Talk about GSISOP!

Yes, we were the Java evangelists. For us, Java was the way of the future.

We had to endure a lot of flack for our beliefs. But we’ve persisted, prevailed, and through Herculean efforts managed to bring Java into the corporate fold. Despite the false and doomsday claims that Java was ‘too slow’, that it ‘wouldn’t scale’, that it was ‘too complex’, today we see that Java is the bread-and-butter of the contemporary corporate computing.

So why am I telling you all this boring stuff? The reason is that today we finally have this ‘new kid on the block’ – Ruby on Rails. Similar to what Java was ten years ago, RoR today promises a completely new way of not only looking at things, but also on doing things.

And similar to the case with Java ten years ago, many people fail to see the true potential of RoR. Not surprisingly, because, same as Java from ten years ago, RoR is not a GSISOP.

Why am I convinced that RoR is not a GSISOP? First of all, it’s not ‘giant’ (same as Java was an agile, small footprint solution ten years ago). Secondly, it’s not a ‘solution in search of a problem’, because it deals with a very specific problem at hand – how to implement the principle of Occam’s Razor. And it does it extremely successfully.

So, if Java is not a GSISOP, why do we need another non-GSISOP? Doesn’t the principle of Occam’s Razor (‘entities should not multiply beyond necessity’) go directly against having two similar solutions?

You see, the problem is that Java WAS not a GSISOP, but (sadly) grew into one over the years. Today, I claim that Java slowly and maybe imperceptibly morphed itself into a GSISOP. One need go no further than examine the Struts framework, for example, if one would like to understand what a GSISOP really is.

As we all know, Java community is getting mighty agitated over the RoR promise. What’s particularly amusing to me personally is how the same people who had to endure unjustified attacks on Java some eight-ten years ago, are now using the same unjustified argumentation to attack RoR!

Of course, a number of Java supporters are now rushing out to perform what I like to call ‘putting a lipstick on a corpse’, in order to prove that Java is indeed capable of doing anything that RoR can do. These are sadly misplaced efforts, which eerily remind me of the long gone days of the screen scraping efforts. Same as the mainframe folks tried desperately to prove that Mainframes can do client/server computing without leaving their comfy OS, Java advocates are now wasting their time trying to prove that ‘Java can be concise too’! It resembles some political PR where a spokesperson of some dictatorial regime claims that their regime can be democratic too. Yes, there is no doubt that it can, but the real question is: why isn’t it? If Java can be concise too, then why isn’t it concise already? Why do we need Struts? If Java is by its nature concise, why did we end up with such monstrosities as Struts and Jetspeed and Expresso and Tapestry, etc., all of which harken back to the bad old days of mainframe programming?

In the future (if the future ever comes for me), I’m planning to discuss the shift in the philosophy of complex system development that RoR brings to the table. I’m planning to focus on the complex-vs-complicated dichotomy in particular.