What Arc should learn from Ruby

There was a lot of buzz surrounding Arc before it was released. Then Paul Graham made an early version available to the public and most people weren’t too impressed. Paul is a charismatic figure and has his own following, so despite the uncertain welcome that the language received, Arc managed to attract a small community of curious developers. Then silence. For a few months, most people hardly heard anything about Arc. Until today. A post on news.arc suddenly found its way into the spotlight. In this post, its author tried to summarize the status of the language, its failure to attract new developers or even retain the existing ones, and what is perceived as a lack of leadership for the project and a very uncertain future.

I joked about this and said that “Arc is the infogami of programming languages”. Infogami was a project started by Aaron Swartz, that was claiming it was going to revolutionize the web “like the Macintosh did for computers” (if I recall the quote correctly). Despite the great expectations and the grand announcements that were made, the project (launched by what was a YCombinator startup) never really flew. But I digress; the point is that Arc, like infogami was wrapped in layers of expectations, like a scallop with bacon, but the delivery and the outcome were less than stellar.

Don’t hold this against Paul (or Aaron); projects fail or have rocky starts all the time. It’s the nature of software and of this business. Don’t jump to conclusions too quickly and assume that Arc has failed and is dead, either. Paul seems to have long term plans for the language. Many popular languages today were absolutely obscure to most developers for their first several years. Should Arc become the great language many had hoped for, people will have no qualms in adopting it in 1, 3 or even 5 years time.

I think that Paul is trying to distinguish between what the core features of the language are and its libraries, and his aim and focus is currently directed towards the former; a core that he wishes to change and evolve with a certain degree of freedom. From many of his writings, it is apparent that Paul has set out one clear cut criterium for the features of his language: whatever changes are made, need to make Arc concise. Concise doesn’t mean terse or unreadable, it means powerful and expressive enough to enable the language’s users to write a certain program with much less code than what’s required by other commonly adopted languages, and if possible, even by the most popular dialects of Lisp.

This approach to the design of the core language is far from off course. For example, Ruby’s conciseness is one of its most appreciated characteristics and one of the prominent features that sets it apart from compiled languages like C or Java. But a powerful and well designed programming language is not enough. That’s not really what developers are after.

Programmers are looking for solutions to existing problems and pains. They want tools, and this includes languages, that are good at helping them while they try to implement certain types of software. The languages may be general purpose, but if they don’t represent an advantage over other alternatives in a particular domain, they are hardly used.

In short, libraries and the ecosystem surrounding programming languages are often as important as the languages themselves.

In a somewhat related “ask News.YCombinator” question, Clojure was mentioned as a possible “next big thing” for the Lisp world. As you can imagine, the subject of Arc was brought up and Paul stepped in with a few comments. Two significant ones specifically focused on the subject of libraries, trying to address what is currently perceived as one of Arc’s big weaknesses, whereas it’s a strong point for Clojure, which can rely on all the existing code available for the Java world (since Clojure targets the JVM).

The first of these comments included the following quote:

Powerful libraries are a cheap way to make a new language the language du jour. (Think Rails.) They’re not the critical ingredient if you’re trying to make something to last; they may even hurt. — Paul Graham

And the second one, further explained what his position was:

The dangers of libraries are that they distract one’s attention from the core language, and that they could conceal or perpetuate flaws in the core language. I’m not saying that languages *shouldn’t* have powerful libraries, btw, just that they may not be 100% upside. — Paul Graham

Read that first quote again. I agree with the initial part of it, but find the conclusion is not supported by the facts. Paul himself brought up the example of Ruby and Rails, so let’s explore this further and see what Arc could learn from Ruby’s experience.

Ruby was a very good programming language that for a long time was hardly used outside of Japan. Beside the scarcity of documentation in English, one of the major untold challenges of the language was that it didn’t really solve a particular problem. It was a beautiful general purpose language and that was it. Sure, quite a few smart early adopters realized the potential of the language, and it started to gain some momentum amongst Perl developers, as a possible Perl successor. But let’s face it, for most people Perl was good enough.

Ruby’s core didn’t really change in 2006, when a large majority of the development community acknowledged the merits of the language. Ruby in 2000 and Ruby in 2006 were not really that different. What was drastically different about the two was the ecosystem surrounding Ruby. And the fact that Ruby now offered an incredible solution for those developers who desired to address the problem of web development. Matz was right, Rails is Ruby’s killer application.

But let’s not stop here. Paul agrees that Ruby’s growth rate has been exponentially increased thanks to Rails. So much so that he mentioned it as an emblematic example of a “cheap way” to bring a language to the front of the class. He concludes however, that this is not really the right approach or the critical ingredient needed to create something that lasts. He even goes so far as to say that it may end up hurting the language. And in this, I absolutely disagree.

I disagree because the history of Ruby and that of a few other programming languages shows how the arrival of a community of interested developers has always had many more benefits than drawbacks, provided that a minimal leadership for the projects existed. Taking an accelerated course in Ruby History 101, we’d discover that Ruby already had its own group of fans and a growing English speaking community. Ruby was able to stand on its own merits. What Rails did was inject an incredible amount of attention towards Ruby from developers, companies and the tech oriented media.

What was the effect of all this on Ruby? Countless libraries were written for the language; thousands of companies, particularly startups, adopted Ruby as their language of choice. There was a spur of alternative new Ruby web frameworks (like Merb, Ramaze, etc…) and also a dozen alternative implementations that attempt to improve upon the shortcomings of the language’s main implementation and, in a few occasions, to integrate Ruby with other existing VMs (e.g. with JRuby and IronRuby). There were a grand total of two generally available books on the topic, yet now bookstores are filled with Ruby-specific books, not just ones about Rails (something I predicted to my wife back in 2004). Perhaps more importantly, Ruby is now also widely used outside of the web development world as the truly general purpose language it was intended to be. Every time a DSL is needed, Ruby delivers. There are very popular conferences for the language held throughout the year and companies (e.g. Engine Yard) and VCs are investing money in the future of Ruby. mod_ruby wasn’t working for Rails? Along came Mongrel (and several other alternatives) and now even mod_rails to address the deployment issues.

Paul, I’ll take this flourishing community and ecosystem if its downside is just a sea of newbies asking silly questions in forums. Rails has shown the world what Ruby is capable of, and by doing so, it also presented Ruby’s faults in a clear light. Only this time, there weren’t 100 people ready to jump in and fix it; there were 10,000, several companies and millions of dollars to back it up. To me this is a critical ingredient to make something last.

I understand that Paul isn’t rushing when it comes to Arc, and that he wants to perfect his language before letting a large crowd gather around it, but the risk here is the alienation of early adopters and letting many people who were genuinely interested in the project down. Arc like Ruby did (and unlike Clojure), cannot rely on a wealth of existing code. To ensure its bright future Arc will therefore need to make up for this with, yes, a well designed powerful core, but above all with a growing set of libraries, a growing community and if possible, at least one easily identifiable area where Arc shines in resolving one problem better than other existing languages are capable of doing. Based on the trend of the development world, this killer application will probably come in the form of a Rails or Seaside equivalent for Arc. There isn’t a mad dash, Arc is still very young after all, but it would be a mistake to underestimate the importance of such a critical component for the future and success of this language.