lesscode.org

Fifteen, twenty years ago North America was a culinary wasteland, save for the rare pockets scattered along east, west and south coasts. A brief trip to places like New Orleans would shock and jolt the palate of the plain white crustless bread, stake-and-potatoes visitors. Of course, let’s not forget other fine culinary spots, such as Manhattan, San Francisco, and several other islands in the otherwise homogenous sea of mediocrity.

Things started to change rapidly in the nineties, reaching levels of unprecedented sophistication in dinning and wining. Today, we can enjoy the incredibly opulent selection offered to us through stores such as The Whole Paycheck (er, Whole Foods), but things were drastically different only fifteen years ago.

I remember how unpopular wine drinking was not that long ago. Especially in my neck of the woods (I live in Vancouver, British Columbia, where most locals still mentally inhabit the 19th century time zone). Up until very recently, this was a beer country. All normal, regular males were expected to drink beer. Wine was mostly available in those hideous 4 litre carton boxes, and tasted like pee that went bad. Anyone caught preferring or, god forbid, drinking wine was declared gay on the spot. It used to be very hard to smuggle a bottle of import wine into one’s apartment.

At social gatherings, wine drinking was reserved for the female population. Men were either expected to chug beer, or go with some hard booze.

Luckily, things started changing for the better, and now we have pretty decent selection of import wines from all around the world. Plus, straight men are not afraid that they’ll be labelled as ‘faggots’ if they are seen drinking wine in public.

What Does Wine Have to Do With Ruby on Rails?

Programming languages and development platforms are kind of similar to alcoholic beverages. Majority of software developers choose products that belong to the beer category. Sure, there’s plenty of variety there, but in the final analysis, it’s all beer after all. Thus programming languages such as Pascal, Perl, Java, C#, ColdFusion, PHP etc. are basically just different varieties of beer (like, dark beer, pale ale, lager, etc.) Languages such as Assembler and C are more like hard liqueurs (e.g. whiskey, tequila, vodka). Languages such as Smalltalk, Python, Lisp, are like white wine — sophisticated and enchanting.

Finally, languages like Ruby (with all its domain specific flavors, such as Rake and Ruby on Rails) are like red wine. Red wine is that special gamut of products that demand incredibly high level of devotion and finesse, thus creating its own breed of aficionados.

And like the friction that wine drinkers were having with the overruling beer crowd, Ruby and Ruby on Rails users are today experiencing similar friction coming from the ‘beer crowd’ of programming languages. Most of the dissent seems to be coming from the ‘plain vanilla’ lager crowd (the Java consumers). There’s also some dissent coming from the ‘white wine’ crowd, but in a much more civilized fashion.

I wonder if the same cultural evolution, that helped promote the spreading of the red wine culture throughout North America, will happen for the ‘red wine of software development’, that is, for Ruby on Rails? At this point, it doesn’t seem very likely, as anyone who’s using Rails seems to be labelled in a knee-jerk fashion as being ‘queer’. It is obvious that the mainstream crowd of software developers (i.e. the beer drinking crowd) is extremely uncomfortable with the uprising of the red wine drinking crowd (i.e. the Ruby on Rails). The beer drinking crowd confesses that they simply don’t get what could possibly be so enchanting about enjoying the red wine.

Hopefully, cooler heads will prevail, and the medical findings that red wine is actually beneficial for one’s health will pave the way toward adopting the red wine consumption on a larger scale.

Bob Ippolito, speaking about the upcoming flashticle, offers proof in the pudding for things I wrote a week ago:

This is a total of a whopping 117 lines of very liberally spaced Python code that defines all three database tables and fully implements every feature of both sample applications.

The PHP version of the pizzaService backend […] is 138 lines of code, is one big security flaw (doesn’t escape SQL properly, big surprise), is MySQL specific, and it doesn’t include the DB schema and can’t create any tables for you (thank you tg-admin sql create).

The Java version of the BirthdayOrganizer backend, which I won’t even bother linking to, is well… ginormous. 246 lines of XML configuration sludge in 5 files, 29 lines of SQL schema in 1 file, and 3004 lines of Java code in 45 files. Holy crap. If you add that all up, the trivial BirthdayOrganizer example is only a hair shorter than all of flashticle! And the BirthdayOrganizer example builds on top of 15 Java dependencies and requires a J2EE server plus ant. Friends don’t let friends code Java. Oh, and it’s also MySQL specific, but you better be damn well sure that there’s a stub implementation you can subclass and an XML file you can mangle in order to support something else if you so choose to write that 200 lines of code to support a single three column table database.

I’d like to offer several snippets collected from the recent discussion threads on programming languages (regarding conciseness and verbosity). One person wrote:

The important point about verbosity is not the time you spend typing: it’s about how difficult it is to read and understand the code.

To which the other fellow responded:

And verbosity makes code easier to read. I don’t have to know anything to understand the code. Everything I need to know is there in front of me.

Now, that’s an interesting way to look at the problem of understanding the code. Would you agree that the more verbose the source code is, the easier it gets to understand it?

Finally (and inevitably), the sacred cow of corporate computing (Java) is dragged in to demonstrate the benefits of verbosity as a feature that encourages reusability through increasing the level of abstraction:

The verbosity of Java code also encourages developers to implement more abstractions and reusable components. The ease of coding in some languages often results in more code, in my experience. It’s easier to just write more code than to stop and think about reusable solutions. In Java and other verbose languages, ‘coding for the moment’ is a losing strategy.

Interesting stuff, innit? Do any of you guys agree with this, or have comments to offer?

There seems to be a big disconnect between the bureaucratic-minded developers and the so-called hackers (’hackers’ in Paul Graham’s sense of the word). This disconnect is getting exacerbated lately by the explosive success of the hackers’ business model (witness the juggernaut that is Ruby on Rails, 37signals, etc.)

Bureaucrats obviously dislike languages that require thinking. Bureaucrats prefer to migrate expertise from the individuals and into the prescribed ’system’ (by prescribed ’system’ we mean faceless, nameless policies and procedures). This is precisely why bureaucrats insist that only languages such as Java and C# are worthy of their attention. They despise any languages that cannot easily be offloaded onto some mechanical device, such as Eclipse’s Modeling Framework, or onto some overseas organization.

Hackers on the other hand tend to despise any mechanization, or industrialization of the process of creating software. Hackers are not buying into the possibility of drawing a picture that could be used to generate the machine executable code. Real hackers know that programming is like higher mathematics — it’s too abstract to be ever faithfully expressed visually.

What’s interesting is how bureaucrats use FUD to push forward their agendas. First they insist that all programming languages were created equal. After all, it’s all ones and zeros, so what’s the big fuss?

But then they turn around and claim how all languages were actually not created equal, because in Java we have the pinnacle of simplicity — in Java, you can do something in one, and only one proper way (so, the simplicity in Java turns out to actually be rigidity). The FUD bureaucrats are spreading is so lame, so desperate, that it would be hilarious if it wasn’t so bloody damaging to our industry.

It’s definitely going to be an uphill battle for the hackers. I firmly believe that creativity will, in the end, win. But lots of people are going to try and kill creativity, no matter what the price.

I predict that it’s going to get very ugly. Much uglier than it already is. The time is slowly coming for us to make the decision — are we going to support the creative way of doing it, or the bureaucratic way?

I’m not a programming language designer, but I know what love is.

Bruce Eckel:

I think we’ve mostly been hearing from people who have come from Perl and found Ruby to be a ‘better Perl, with objects that work,’ or people who are finally convinced that dynamic languages have merit, and so mix the enthusiasm of the first time dynamic language user (quite a rush, as I remember from my 2-month experience with Perl many years ago) with their experience of Ruby. So far, I’ve heard from the hyper-enthusiasts about Ruby being cool, or that it has begin-end blocks and they don’t like indentation to delineate scope. That kind of thing: ‘I like this, I don’t like that,’ which is fine but not compelling.

David Heinemeier Hansson:

I’m losing track of the ill-conceived comparisons, but I do know what’s astoundingly clear: Bruce Eckel doesn’t like Ruby, he doesn’t like the attention its getting, and he doesn’t like people such as Bruce Tate fueling that attention. No beef, that’s cool. But why not just say it like that? You could even have presented yourself as the polar opposite to the so-called hyper-enthusiasts: A hyper-detractor! The label comes complete with a cape, an evil smirk, and long tirades about how the other side is no match for your master plan.

Another issue is a perennial side-show in the world-wide computer programming circus: the spectacle of nerds arguing over programming tools. The data model can’t represent the information that the users need, the application doesn’t do what what the users need it to do, and instead of writing code, the “engineers” are arguing about Java versus Lisp versus Perl versus Tcl. If you want to know why computer programmers get paid less than medical doctors, consider the situation of two trauma surgeons arriving at an accident scene. The patient is bleeding profusely. If surgeons were like programmers, they’d leave the patient to bleed out in order to have a really satisfying argument over the merits of two different kinds of tourniquet.

Programmers would rather squabble about minituae - it seems this transcends community or language choice. Yet a Python programmer can become functional in Ruby in short order, and vice versa. That’s an important message for anyone that worries about how a software system is going to be supported a few years out - it suggests that with respect to the job market, the languages are interchangeable. They are platform neutral, both run on the JVM or interoperate with .NET. That’s an important message for anyone who requires back-end systems integration. They complement mainstream enterprise development by providing a disciplined approach to scripting when scripting is what’s required. That’s an important message for anyone who ever got saddled with a now-critical, yet spaghetti-like webapp that grew out of a quick scripting hack. They are highly suited for those who need to write software but do not have a systems programming or pure CS background. That’s an important message for anyone who just wants to get something down without going to market for engineers. They’re productive, and while we can’t tell you what productivity is, we know it when we see it. What’s my point? That there are plenty of interesting messages to be sending out, as opposed to the one that suggests programmers will always, every time, without fail, quibble. Is it really that inconceivable that the growing interest in particular frameworks (Rails) and languages (PHP) by enterprise types floats all dynamic boats?

Ruby’s a great language. Ditto Python. About the best anyone can do in terms of differentiating the core languages is mumble something about elegance, or how good closures^[1] are. Yet for about 98.6% of what you do as a working stiff, the core language differences are irrelevant^[2]. You might get hung up on whitespace or the end keyword, but that’s a bit like getting hung up on driving on the “wrong side of the road” when you go on holidays. You’ll get used to it, unless you intent to expend a lot of energy refusing to get used to it.

Still, from all the blog noise this gem of quote is worth pulling out:

But Ruby has only emerged in the last 5 years or so, and only gotten the catalyst in the last 2. Right now, I’m looking for a dynamic language that I can sell into conservative accounts, because I can be more productive with them for certain problems. I actually like Python, Lisp and Smalltalk, though of the three, I’ve only used Smalltalk in anger, and only on very limited apps. Iwould be happy with any of the 3 as an alternative. Smalltalk’s the most pure, Python the most approachable, and Lisp the most powerful. It’s jsut that as a consultant at conservative Java accounts, I need to also consider market penetration. Java has already popped. In Ruby, I see a possible catalyst in Rails. In Smalltalk and Python, I don’t. But since Beyond Java, I’ve used Rails, Spring and Plone on various applications, and been peased with each.

That’s from Bruce Tate, commenting on Bruce Eckel’s entry. That kind of realism coming from a developer is refreshing.

1. Anyone who really feels Ruby closures are a critical technical factor should be wondering why they’re not develping in Smalltalk or CLisp.
2. Python is further along in terms of library support. Libraries do matter, but in terms of core langauge design, they are a contingent diffentiator.