Ain't No Stopping Us Now

According to a recent eWeek article, there will be four times more Ruby programmers within five years. Before all the haters start making cracks about it going from one thousand to four thousand professional Rubyists, here is a juicy bit from Mark Driver, Gartner analyst:

"There are under one million professional Ruby developers now and we're projecting there will be four million plus by 2013."

And oh yeah, what about that whole "Ruby is for hobbyists" misinformation campaign? Officially debunked by Gartner:

Driver later told eWEEK that Gartner's research shows "strong interest" in Ruby and that the percentage of developers that will be creating commercial systems versus those that are hobbyists will be even greater for Ruby than for other languages. "Ruby will be more interesting to commercial developers"

Just imagine the power of one million people out there, right now. Developing, sharing, recruiting others... to use their favorite programming language! What did you think I was talking about, politics?

I Want My API

I just ran into a really great resource for open source API documentation. Called gotAPI, it links in a delightfully searchable way all of the APIs we love, but turn out to not actually know. Well, we know them, just not well enough to have their numbers setup for speed dial on our cell phones. Or our code able to call them directly without looking up a reference first.

Here is a small sample of ones I will actually use regularly:

• HTML


• CSS


• JavaScript


• Prototype


• jQuery


• Ruby Standard Library


• Ruby on Rails


• Erlang


• MySQL


• PostgreSQL


• Selenium

Plus gotAPI is a domain name I can probably remember. That should keep me from several pointless button mashing Google searches per hour just to end up back on the same sites that gotAPI is already linking to.

RubyConf 2007 - Day 2 - "The Ruby VM Smackdown Begins"

As the sun rose over the hills of North Carolina, the quiet betrayed a seething fire blazing in the hearts of three development teams. "Three teams enter, one team leaves!" Yes, I am talking about the main event, people, the one, the only, Ruby VM Smackdown! The room was jam packed, the anticipation was high.

As good fortune would have it, I was sitting right next to the head of the team who was my personal favorite to win the day. Yes, I am referring to Evan Phoenix, leader of Team Rubinius along with co-conspirator Ryan Davis. You should have seen the look at their faces when the JRuby team showed the Rubinius RSpec test suite as part of their demo! But I am getting ahead of myself...

I like the underdog in a fight, when the underdog is tough, and under-estimated by their opponents. On one side, the resources of Microsoft, on the other, the full power of Sun. And then, THE LADS. If you don't want to see that one go down, you have no passion for the cutting edge of innovation. And if you do not know about the history of innovation in the software industry, you might miscalculate the odds. Gentlemen, to your corners... I want a clean fight!

MC Chad Fowler got up, and gave a brief intro to the show. "We are about to see what Matz called 'wonderous' last night," he said. And it was true.

First up, was John Lam of Microsoft with IronRuby armed with "State of IronRuby".

Next, Charles Nutter and Thomas Enebo of Sun with JRuby using "Ruby for the JVM" style.

Last, the challenger, Evan Phoenix with Rubinius wielding "Rubinius 1.0".

Wow. Bread and circuses, indeed!

I will be posting individually about each of the Ruby VM contestants, and will update the above links when I am done...

After all that excitement, the crowd was starved. We shuffled out to eat our lunches, and converse on all we had seen. From everyone I spoke with, the mood in the crowd was firmly in the Rubinius corner, with a close second to JRuby, with third place probably going to YARV. Hardly anyone I spoke with at RubyConf had any interest in using IronRuby at all!

That is to be expected from a conference like RubyConf, well known for its strong ABM (Anything But Microsoft) attitude, which is pretty unfair. That said, I think the uptake in the .NET community will be the measure of the success of IronRuby, not whether they can get the typical RubyConf attendee to switch back to Windows.

In the afternoon, I got to see some great sessions, from:

"Refactotum: Ruby" - Stuart Halloway
"Maximizing Productivity" - Eric Hodel
"Mac OS X Loves Ruby" - Laurent Sansonetti

I will be posting individually for each session when I get a chance, and will update the links here.

Once the afternoon's sessions had wrapped up, a large group of us overran a local BBQ joint named Mac's, with tasty BBQ, a great beer selection, and a bunch of Harleys in the parking lot. Despite our somewhat atypical appearance (nerd chic) for NC, we were welcomed warmly by the locals. There must've been 30+ people from RubyConf there, it was great!

We then returned at the perfect moment to hear Matz's keynote speech. And it was good. Really good. Matz is charming, and quite funny. His wit was so much better able to emerge in a forum where he was simply presenting, rather than the somewhat less successful "town hall" format that had been attempted the evening before. I have a separate posting with his remarks which will be up later:

RubyConf 2007 - Keynote by Matz

Once the keynote had ended, I just had to go up and shake the man's hand. I know it may be corny, but I really did suddenly appreciate what he really does, which is to inspire the community. People keep looking to Matz for all the answers, but the answers are up to us, my friends. No superheros, remember?

Afterwards, I want to the legendary RejectConf, held right next door. Don't ask me how I wedged my way in, but I did it. To everyone who's toes I stepped on: sorry! There was a fun series of lightning talk (5-10 min) presentations of pretty much brand-new stuff. The beauty of RejectConf is its appeal to the ADD'd-out techno-junkie: every few minutes something else. I will be posting a rundown of RejectConf when I get a chance here:

RubyConf 2007 - RejectConf

RejectConf was really a great highlight of RubyConf. Once they kicked us out, the entire crowd immediately migrated directly next door to the hotel bar where we drank beers and chatted loudly about techno-babble to our great enjoyment. I staggered up to my room, to rest up and prepare myself for Day 3.

RubyConf 2007 - Day 1 - "What Makes Code Beautiful" - Marcel Molina

I remember Marcel Molina from the first RailsConf, when the Rails core team was introduced to the audience. What had impressed me at the time, besides his cool glasses, was the fact that Marcel comes from a literature background.

That makes his take on programming in Ruby very interesting, because he approaches it from an aesthetic perspective, not just a functional one. To Marcel, code must achieve both, for it to be considered beautiful.

What Is Beautiful?
Here are some historical definitions of beauty:
Plato - "The ability to grasp mere appearances cannot lead to adequate understanding. At its worst, the appreciation of beauty can mire us in the world of sense experience... but at its best it can lead to the understanding of goodness."
Rousseau - "I have always believed that good is none other than Beauty in action, that the one is inextricably bound up with the other and that both have a common source..."

There is something deeper than appearances that makes something beautiful.

Looking at human language, meaning is often implicit in sentences. Normally in software, using rhetorical effects is considered bad, unlike literature.

Ruby had an appeal to Marcel as a language, as a visceral response to the language itself. But why? Elegance and beauty are used to describe Ruby code, but what does that mean?

Settle On A Working Definition
Marcel goes with Thomas Aquinas for a working definition of beauty requiring three qualities:
Proportion - Economy of size & ratio of parts
Integrity - a glass hammer may look good, but it doesn't work for a hammer - to have integrity, a thing must fit its intended purpose
Clarity - something should be simple and clear. There is a big difference between sophistication and complication

Apply definition of beauty to software
Marcel provided a contrived example, a case study that created a Coercion class to "help" when parsing XML. In his example, he starts with a 25 line class with three methods and such obfuscated code that even the author admitted that he does not understand it. He then proceeds to show how it can be reduced to 12 lines of reasonably clear syntax.

To achieve beauty, we need checks and balances between each of the qualities of beauty - each is necessary, but none are sufficient themselves alone.

Does code quality relate to beauty?
Marcel cites Kent Beck's "Smalltalk - Best Practice Patterns" as a strong influence. The book is full of pearls of wisdom like "most good Smalltalk methods fit into a few lines". After reading the book, Marcel realized that it was a set of descriptions of the elements that make Smalltalk code beautiful.

How Is This Useful?
We may not be very impressed by the beauty in a case statement. But imagine programming before the 'if' statement. 'If' is way better than assembly code... there is a relativity to what makes code beautiful. Today, Ruby is considered beautiful. In the future, we may consider it as ugly as 70's assembly code based on the aesthetics available to us.

"An expert is someone who has made all the mistakes that can be made in a very narrow field" - Neils Bohr

Ruby is optimized for beauty.
- try to imagine better modes of expression
- violations of beauty rules reveal mistakes
- do enough of this and you will innovate

Programming Language Family Tree

My colleague Michael Hocter just sent me a great link to a diagram showing the history of the evolutions of the major programming languages. I just love this kind of visual representation of information!

Note how C# has taken ideas from Java...then Java goes and draws inspiration from C#. Also note how C# 2.0 takes its inspiration from Ruby. The two programming languages that drew from the most other languages (five) were Oak, which turned into Java, and Ruby.