lesscode.org


Archive for March, 2006

Time To Stop Obsessing About The Infrastructure?  13

Cat.: Theory
12. March 2006

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.

Gosling Didn’t Get The Memo  107

Cat.: Then they fight you...
12. March 2006

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:

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:

Performance:

Why people are upset

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

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.