Wednesday, April 08, 2009


For some reason I feel compelled to chime in on this debate. I like both languages. I like Scala more, but Ruby is fun.

(Reader Beware: This post was written in one pass with little to no editing.)

I don't like how people get all steamed about their languages, as if it's part of them. But, if used properly, this energy can be channeled into creating better languages, so I guess its a necessary evil. The problem is, it not often used properly. Developers seem to just get mad at each other instead of talking through things civilly, and thinking critically and objectively. This is nothing new, and nothing that hasn't been said a thousand times I'm sure, but I think serves well as a nice introduction.

Maybe the problem is that so many of the elements of programming languages are based on feel, as opposed to simple fact. I wish we'd all think more logically and have nice intelligent debates, and I wish we could support our arguments more with fact.

Now for a debate. I was tweeting with Daniel Spiewak who said,

"Obie has once again decided to completely miss the point. Twitter's legacy code is bad *because* of Ruby, not in spite. The experiences described by @stevej and @al3x precisely mirror my own: it isn't impossible to write large, maintainable Ruby...just hard."

I asked him if he could elaborate on "because of", and to that he replied,

"Ruby makes it *hard* to architect a large infrastructure and to keep it maintainable. I think that dynamic typing is part of the problem, but not all of it. Possibly the way the module system works? It isn't impossible to do large apps in Ruby (as Obie and Ola remind us), but it takes more effort and more discipline. Java and Scala both make this sort of large scale code base much easier to create and maintain."

Now, I don't necessarily disagree with that (and recall that I do like Ruby). But I'd like to point out that I've been on a lot of Java projects that were completely unmaintainable. You could easily call them absolute disasters. In fact, the majority of the Java projects that I've been on have been disasters (yes, yes get your laughs in and tell me that its my fault...but its not. I did a lot to help those failing/flailing projects). Maybe that's because I've picked bad projects, and haven't many changes to work with great teams on applications built correctly from the start.

But, I think that emphasizes my point a little. Who has? How many projects are built correctly from the ground up, by talented, disciplined developers? I'd say not many. Most developers are horrible, and the language wouldn't make a shred of difference. And for those developers who are really good, the language probably doesn't make that much difference either. A group of solid developers could easily build something far more maintainable in Ruby than the garbage developers who are writing in Java.

But can those same developers build something more maintainable in Java or Scala? I think it depends on a whole number of things (listed at the end of the post). If there's a good chance of turnover on the project, then you probably want something with type information in the code because it serves so well as documentation. But if there's little chance of turnover it probably doesn't matter.

That said, even with turnover, because Ruby is inherently higher level that Java its probably more easy to maintain. Java is just not a good language anymore, it has not stood the test of time. It came about to fix some problems with C++, and had a syntax that appealed to those developers, but that was 1994. It has not evolved. Ruby is so much more expressive than Java that the lack of type information probably doesn't mean much at all.

Scala on the other hand, probably no contest for large projects. I think Twitter made the right decision. They get the type safety, the type documentation, and the high level expressiveness all together. I do like Ruby a lot, but Scala just feels better to me, and feel is very important, even if its not measurable.

But all that could be wrong. How many large projects have actually been built in Scala? Few. I said in the beginning that I want people to think critically and objectively. It would be nice if we could base some of these debates on fact. Are there any facts out there that large Java projects are more maintainable than Ruby? There may well be, and if so, we should get that information out there. Then again, there may be documentation that supports the opposite.

So I'm not really calling for comments here, though they are always welcome. What I am calling for is experiments, evidence, observations, or facts that support that one language is more maintainable than the other for any sized project.

Here are some questions whose answers would be helpful (in no particular order):

  • What language was used?

  • What was the size of the project:

    1. LOC? Production and Test code.

    2. Number of developers?

    3. Number of testers?

  • How long did the project take?

  • What was the amount turnover?

  • What was the experience level of the developers?

  • The amount of time the team has been together?

  • The amount of time the developers have spent with the language used?

  • Type of project? (Obviously if the language chosen was a horrible choice for the project, it makes a difference)

This information is probably pretty difficult to come by. The lack of it shouldn't impede intelligent debate, but the presence of it could help us as a community.


  1. I agree that Java is not the best language any more, but I don't think you can say that it has not stood the test of time. A language created in 1994 that is still the one of the most popular languages cannot be called anything but wildly successful. But things are always going to be improved, one day somebody will come up with something that makes Ruby look old and awful.

  2. I was really trying to emphasize that it hasn't evolved properly, and to most competent developers its considered a low level language.

    Maybe its stood the test of time in that people still use it. But, I think that is just a product of it riding the wave of its initial massive popularity, along with political, conservative resistance to change.

    It hasn't stood any test of time where serious language enthusiasts would dare call it a great language. It did some decent things 10 years ago, but its gig is up.

  3. I really don't think that any mentioned language is a barrier for creating a big application. It's more of creating good models and solid architecture. Of course proper module system and high level features help to make it more easier to change and understand. But having good taste and creating application specific abstractions is much more critical to success.

  4. I think that is in line with what I meant. Its the people, the process, the decisions more than the language.

    Static typing for documentation doesn't buy you anything at all if the types that are created don't make any sense to begin with. I've seen this enough times to be sick to my stomach.

    The best people usually don't fall into that though. They create types that make sense and when they don't make sense, things get refactored. Since refactoring is easier with a static type system, thats one argument for languages in that camp. A pretty major one.

    The Ruby people will say (and rightfully) that tests help here, but I still don't think that changes much. You need less tests in a statically typed language. Less so in a purely immutable, functional language. Having to write fewer (and there for refactor fewer) tests makes a difference as well.

    I'm in the static camp, I guess, for large apps. I still really enjoy Ruby though.

  5. @Jack

    I think you're opinion pretty closely mirrors my own. I have also seen some really horrible Java code. In fact, strange as it may sound, I have also seen some really nasty Scala code as well. Contrary to what the detractors say, the nasty Scala code wasn't really any more difficult to understand than the nasty Java, just a little bit shorter.

    Your choice of language is never going to *guarantee* good architectural decisions. However, certain languages are more amenable to gigantic, large scale architectures than are others. For really big stuff, I tend to like languages which are object-oriented (hybrid or otherwise) and statically typed. Static typing does a couple of things:

    * It makes refactoring *possible* (not just easier)
    * It keeps the moron sub-contractors from doing what they do best; or at least, makes it more evident when they do
    * It eliminates some really hard-to-follow patterns (like monkey patching)

    Dynamic languages like Ruby are very alluring. Now, by "dynamic" I mean more than just the type system; I'm talking about the entire philosophy of the language. I would define Ruby as dynamic, and Perl as not. Anyway, the allure of these languages comes from the sheer number of things you can do in a very short span of code. Unfortunately, this allure also brings a terrible temptation to be lazy. You tend to think a lot less about the designs you're creating. You often implicitly assume that you can just "fix it up later". While this is true in the strictest sense, it doesn't usually happen. Instead, more monkey patching is applied to fix the problems caused by the last round, and so on. Trust me, I've seen this happen in projects. It doesn't have to with a dynamic language, but it often does.

    Does that mean that Ruby (and dynamic languages in general) is unfit for larger applications? Not at all. However, it does mean that you have to be significantly more disciplined to get away with it. You have to be very intentional about your testing and your design, something that most developers simply aren't willing (or aren't able) to do.

    I wish I had some hard numbers and cases to back this up, but I don't right off the top of my head. A lot of this is based on the feel I've gotten from projects in various languages, both large and small.

  6. Before I go to bed I want to at least say this...

    Certain, small refactorings are easily possible, and have been proven so. So, to say that refactoring in dynamic languages is impossible is just wrong. Maybe you should change impossible to include only large refactorings, or complicated refactorings, or gulp...practical refactorings.

    I do think we are on the same page entirely, and I appreciate your feedback (especially on the grammar stuff I asked you).

    Goodnight Moon.

  7. I agree that the developers play a bigger role than the language. Our current system is written for in a proprietary language+app server combo you can't even buy anymore (Forte 4GL), meaning you don't have as many features as java or ruby, and you certainly don't have new open source libraries coming either.

    However, I managed to build a system supporting a nation-wide network using it. I have been able to hire people with OOP skills and teach them the language. I carefully screened candidates. Since then, one of the people wrote a graphics module to dynamically draw screens using primitives. Its nothing you couldn't have done using Java's AWT.

    I think this all goes to say that people are much more important than any language.

  8. Great Post.....I actually had a chance to work on a large project in Ruby and had a chance to have Pragmatic Dave try to evangelize me into Ruby submission....

    I like the language, but it is a tool.

    What language was used?


    What was the size of the project:

    LOC? Production and Test code.
    ~25,000 Lines of Code

    Number of developers?
    between 10-20 depending on the dev cycle etc. (in pairs)

    Number of testers?
    ~2-4 depending on the iteration.

    How long did the project take?

    What was the amount turnover?
    Constant churn....some have been on it for years others only stay a few months

    What was the experience level of the developers?
    junior to senior

    The amount of time the team has been together?
    3 years

    The amount of time the developers have spent with the language used?
    0-3+ years

    Type of project? (Obviously if the language chosen was a horrible choice for the project, it makes a difference)
    Customer facing transactional website

    Personally from my experience on this project I think that this project was beyond the limit of where ruby is a beneficial choice from a technology standpoint. Many of the developers on the project prefer tricky "cool" techniques over maintainable solid code. TDD is rigorously followed but elegance of the language makes it difficult to maintain and trace.