Meditations on programming, startups, and technology
New Relic

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.


If you enjoyed this post, then make sure you subscribe to my Newsletter and/or Feed.

receive my posts by email

10 Responses to “What Arc should learn from Ruby”

  1. Brandon says:

    This was a good read. Thanks.

  2. Joe Strickler says:

    You’re missing the point. Having more developers right now would certainly mean the language would be more usable right now.

    But this is harmful if you are still working on the language. As you know, once a library becomes even a defacto standard, it’s done; you can’t change the language characteristics employed in that library without pissing everyone off.

    And I think that’s why Paul feels it is not only unnecessary, but could be harmful; bad “features” could get locked into the language if it’s more heavily adopted right now.

  3. Joe, I see your point, but I still think that having no useful libraries and no “real problem to solve” hurt the language more. There are plenty of toy languages which are used by very few because of this.

  4. mark says:

    Great read. I would like to differ one one point – while Rails injected a lot of interest, I and several others never cared much about rails.

    In my case the usage scenario was that I needed a better language than perl and php. Despite the reassurance of developers of those two languages I quickly came to realize that both ruby and python are better languages (for my needs). An interview done by matz influenced me on picking ruby, and while I did learn python too I felt that Ruby is simply more beautiful. But python source code is acceptable too, unlike perl or php.

    Rails injected a lot of ecosystems into the system, which is a good thing. But it sometimes is tied too closely to rails. I would like to remain as independent as possible.

    This is why I still have avoided rails.

    I just want to state that the development of ruby as a general purpose language is not dictated by rails – just influenced a lot. But we should not over-emphasize this.

  5. Ted Henry says:

    > Ruby was a very good programming language

    > [Ruby] was a beautiful general purpose language

    I think the novelty of Ruby has worn off for most programmers and it’s time to let both of these go. Ruby is merely an ok language with major implementation bugs. As far as beautiful languages go, Ruby looks like ASCII vomit in comparison to Scheme. Compare making a lambda in both languages, for example. Then, of course, there are macros, which Ruby doesn’t have.

  6. Ted, De gustibus non est disputandum. ;-)

  7. @Antonio

    Thanks for the interesting read!

    @Ted

    There is something to be said for the difference in readability between Ruby and Scheme. A set of RSpec test cases read like English and can be easily understood by someone trying to get up to speed with the existing functionality and requirements of an app. Can Scheme offer that? Self-documentation shouldn’t be the only form of documentation but it’s a pretty nice side effect of a very readable language.

  8. Ali says:

    @Arthur
    I’d totally agree, but you shouldn’t design the semantics of a language around readability. Yes, I find Ruby more readable. Which do I find more beautiful? Scheme. Every. Single. Time.

  9. Greg Koenig says:

    Hi Antonio. Your blog posting has been linked from reddit.com. Someone on reddit briefly said what I’m going to say here, but I wanted to hopefully pass along some food for thought directly to your blog.

    I believe that the concept you are discussing is the “Worse is Better” idea, described by Lisp hacker Richard Gabriel ca. 1991. (If you never have, I recommend reading his article “Lisp: Good News, Bad News, How to Win Big”.) In essence, Ruby gains followers who bring time, energy, and money with them because Ruby is “good enough” to get things done now, even if it has some flaws that it may have to live with due to setting things in stone early on. Arc, on the other hand, gains none of this because it is being developed to be the Right Thing. According to Gabriel’s argument, Ruby will likely win out (at least in the short term).

    Although I don’t always agree with everything Paul Graham says, he is a smart guy and certainly knows very well what Gabriel learned at lucid.com. I suspect, based on reading things that Graham has written such as his essay “The Hundred-Year Language”, that he is trying to do the Right Thing with Arc because he is trying to lay down a foundation that will long outlast languages like Ruby. Consider, for instance, the challenges faced by the Perl community with the transition to Perl 6 or faced by the Python community with the transition to Python 3. Both of these break some amount of backwards compatibility in order to allow the languages to grow. Is it a sure thing that their respective communities will accept these changes and that the languages will continue to thrive? I guess I’m not yet convinced of that.

    Anyway, thanks for taking the time to write such a thorough blog posting!

  10. Gabe says:

    @Greg – Very good point. I know Graham wants to do the Right Thing with Arc. I hope he can succeed as it would be really exciting, but I don’t hold out high hopes. The history of the software world is strewn about with failed projects with lofty goals. The loftier the goal the more likely a project is to fail and have its lunch eaten by some half-baked project someone threw together to solve some half-baked problem.

Leave a Reply

I sincerely welcome and appreciate your comments, whether in agreement or dissenting with my article. However, trolling will not be tolerated. Comments are automatically closed 15 days after the publication of each article.

Current month ye@r day *

Copyright © 2005-2012 Antonio Cangiano. All rights reserved.