HOME     SITEMAP     RSS     TWITTER     EMAIL    
Search:   

FollowSteph Follow Steph as he posts Blog Blazer Friday
 
 

Why You Can't Just Compare Languages With Lines of Code

Comparing Apples and Oranges

It’s incredible the number of bloggers comparing one computer programming language to another by just comparing a small snippet of code and saying “See look, I can write this in 5 lines of code where in this other language it takes me 50”. This is especially common for comparisons between languages such as Java versus Ruby (specifically Ruby on Rails versus any J2EE framework).

I hate to be another person adding fuel to this same fire, but I have to speak out. These comparisons just don’t work. It’s not even comparing apples to oranges, it’s comparing apples to liquid nitrogen. There is just no comparison, they’re completely different.

The comparisons are comparing the built-in libraries and not the languages.

The big difference with languages like PHP and Ruby is that a lot of functionality is built into the native libraries whereas Java has more verbose API’s (and it’s been built to handle more than just web applications). But that’s ok, that’s what open source is for. Maybe you can’t just do something like image.rotate(90) in Java with the native APIs, but nothing prevents you from getting an open source image library that does. There are tons that do. And after you’ve done it once, you’ll always know how to do it. The comparison no longer works.

Again, this is a comparison of the built-in library API’s. Java’s is much more detailed and lower level to allow you more flexibility whereas the others offer the high level functionality for free. Which is better? It depends. In either case, I can take that 50 line implementation in basic Java and extract it to a few lines by using open source libraries. So that’s not a valid comparison. And if you really wanted to push that, then you should also compare what the open source image library offers in terms of image manipulation compared to the other built in language! Again you can’t compare, it just doesn’t work.

The issue with most of the comparison examples is that are too small. A 50 line code snippet doesn’t mean anything. We all talk about how university/college computer science courses don’t really prepare you for the “real world”. Another case in point. A few lines of code doesn’t not represent a real world application.

LandlordMax I built it expecting lots of versions and different people working on the code base. How important is it to get to market first? Personally I don’t think it’s that important. And David from 37Signals really iterates it well in this video, being first is not always a good thing. My company LandlordMax was not the first by far and yet we’re succeeding very well.

Therefore you need to determine where you want to be in a few years. Speed of development is important but it’s not the end all be all. If it is, realize that your growth cost in the following graph will increase exponentially faster. Twitter is being hit by this right now. They burst right out of the gates but right now they’re having problems with that growth. PayPal is also falling apart. I have no doubt that the cost to add new features to PayPal is excruciatingly expensive. We’ve all been part of projects or systems where adding anything, and I mean even the simplest of changes, required extreme efforts. Some systems become unmaintainable.

To understand just how bad code can get, I recommend viewing Alberto Savoia’s presentation at BOS last year. That or visiting TheDailyWTF almost any day.

Scalability (Team Size – NOT Performance)

Everyone seems to talk about scalability in terms of performance, but what about in terms of team growth? If you only have a few developers you can use any language successfully. But as your team size grows some languages don’t scale so well anymore. Ever try to work on a PHP system with a dozen developers? Unless you have, you can’t really appreciate how difficult this can be. With Java, it’s still difficult, but not nearly as much. And it’s not just the tools, certain language lends themselves better to having multiple developers. For example with a dynamic language there are some theoretical limitations on what you can possibly know at compile time within the program. With statically typed languages, there are still limitations, but they’re a lot less. If you don’t know what I’m talking about right here, don’t worry, it’s pretty technical and I’ll discuss this in depth in another post.

I can already hear arguments such as “with Ruby on Rails you’ll never need 10 developers”. I doubt that, but ok, let’s go with that argument. Will they always be the same 10 developers? Not likely. In which case will the replacement developers be able to pick up where the others left off? With dynamically typed languages this is much harder. The IDE’s, because of the theoretical limits, can’t offer the same level of tools and support. For example, because you can’t know for sure of a variable is of a certain type at compile time you can’t provide a tool to drill down into the object within the IDE. This can only be done at runtime.

Another big aspect of dynamic versus static is that it’s very difficult to create refactoring tools in dynamic languages. Again, for the same reasons, because we can’t know the type an object until runtime, most refactorings need to be done by hand with “find/replace string”. This is difficult and very error prone, which is why it’s not often done. And the more refactorings are skipped, the worse they will get with time. Exponentially worse!

Scalability (Code Size)

Another big argument used in comparing programming languages is that one language will take up a fraction of the code base as another. We’ve already alluded to this with the library discussion, where this is not necessarily true (actually I believe it’s not at all true). But in any case, let’s assume it is. Does the language scale up to bigger code bases?

For simple applications it doesn’t matter too much. For example the business logic behind our Free Real Estate Analyzer is pretty minimal. I won’t say there isn’t any, but if you compare it to a normal application for a business (or god forbid an enterprise web application, or even a government application) the business logic is extremely simple. No exception cases, no weird possibilities, no crazy logic. How do these languages scale up for all these cases?

Scalability (Performance)

And of course you have to talk about performance. How do they scale up in terms of actual performance? But notice I put this near the end!!! I don’t think this should be a central theme because all things being equal, the differences aren’t going to make or break the decision unless you expect millions of visitors on a daily basis. And even then you have money for more hardware and smart people to figure out the bottlenecks.

Miscellaneous

What about integrations with other systems? If you’re a contractor and need to work in larger companies you’ll find that most new systems have to integrate with older existing systems. How well does you’re language work with this. Even small businesses have to do this!

What about deployment? If you’re going to be selling it as an application that your customers need to install, can it be easily deployed? For example RoR has some issues with this. Even PHP can be a beast to deploy (think shared hosting). Java also has it’s issues, but if you do it well all you need is a ear/war file.

What about combining the system with other components? For example PHP is problematic if you want to include several open source components because of namespacing. This isn’t necessarily bad, it’s just something you need to be aware of.

What about extensions of the language? For example Java has more open source libraries than any other language. That’s an amazingly powerful asset. You need something that’s not in the language, go find an open source library. And usually there’s more than one great option. RoR is still lacking in this respect, but that’s because it’s still relatively new. I suspect this will change a lot with time.

Conclusion

I guess what I’m trying to say in a very round about way is that you can’t just compare languages directly based on how many lines of code it takes to implement a small task. That’s the worse comparison of all. What you need to do is look at what you’re trying to do as a whole today and tomorrow and base your decision on the factors you find important. Different languages are better for different scenarios.

For example if you need high initial productivity than by all means use a language like PHP or RoR. If you’re only building a one-off application that’s simple and will never grow, use PHP or RoR. But if you’re planning to build a system that will be around for a long time with lots of people passing through it, then use Java. Anywhere in between, well that’s the gray area where either type of language could easily work. It all depends on where you want to go and what you expect the lifespan of your system will be.

Something else I’d like to note, I’m seeing a lot of people getting excited by MVC frameworks in the dynamically typed languages. This is great to see because before there wasn’t really any consistent framework, but it’s still years behind what’s going on in the Java world. MVC frameworks were a great jump forward, and thank you Struts for bringing that mainstream (about 8-9 years ago).

But even now the Java community is looking at alternatives to the MVC frameworks, it’s been found deficient. It’s a great step forward, but it’s not enough. Right now we’re starting to see event based web frameworks such as JSF and GWT really picking up steam. And I’ll be honest, once you’ve tried an event based framework it’s incredibly hard to go back to an MVC framework. It’s just so much more intuitive and powerful. I just hope the other languages start to look at creating new event based frameworks sooner than later. They’re very powerful!



 
Like this article?

Comments:

  •     Sohail
    · July 6th, 2008  · 4:39 pm  · Permalink

    Food for thought. Though I think that your points about dynamic languages are somewhat on the mark, I think it just speaks to the need to have smaller components.

  •     Gene Wirchenko
    · July 8th, 2008  · 1:09 pm  · Permalink

    Another area where the five vs. fifty lines of code can hit is the special case. The five-line segment might handle most cases, but one is limited to certain options. The fifty-line case might be able to do more.

    Depending on the language, adding just one little bit more of functionality to the five-line segment might mean having to write the fifty lines.

    I remember seeing this in FoxBASE. A fellow developer wanted the functionality of the menu-handling commands but with a timeout. Adding the timeout would have required having to write a menu handler.

    Depending on what you expect to need, it might make more sense to write the fifty lines in the first place.

    Sincerely,

    Gene Wirchenko

  •     Jos Hirth
    · July 8th, 2008  · 4:20 pm  · Permalink

    Another thing which is often forgotten with those 5 vs 50 line “benchmarks” is the required effort to get there. And the effort it takes the next guy to understand it.

    I never understood why there are some people who are fixated on the number of keystrokes. It’s by far the least interesting aspect of any programming language. As long as the typing speed isn’t the bottleneck it won’t matter.

    I mean… I never looked back and thought: “Oh I could have saved about 1% of the time if I only had to write 20% of the code.” Seriously… why would I do that?

    But I did get annoyed by bad documentation, the lack of code conventions, bad tool chains, run-time errors which should have been caught sooner, etc. All those small annoyances which waste my precious thinking time.

  •     Greg M
    · July 9th, 2008  · 1:40 am  · Permalink

    A good point, but it comes across a bit too blanket. There _are_ examples where the difference comes down to the expressivity of the language, and where it comes from something artificial (like core library coverage, that’s usually pretty obvious.

    Even wrt libraries though, sometimes one can factor out a common code pattern as a library in a particular language, but another language isn’t expressive enough to do that, and is left with a “Design Pattern” instead.

  •     Bookmarks about Programming
    · July 9th, 2008  · 1:48 am  · Permalink

    […] Why You Can’t Just Compare Languages With Lines of Code https://www.followsteph.com/2008/07/06/why-you-cant-just-compare-languages-with-lines-of-code/ – bookmarked by 2 members originally found by Pizamstarz on July 06, 2008 […]

Write a reply:





 


SOFTWARE AND BOOKS BY STEPHANE GRENIER:

LandlordMax Property Management Software

LandlordMax is the EASIEST
Property Management
Software available!
Try it for free!

Real Estate Pigeon

Real Estate Pigeon
The place to ask and answer
all your real estate questions

Blog Blazers: 40 Top Bloggers Share Their Secrets to Creating a High-Profile, High-Traffic, and High-Profit Blog!

Blog Blazers is a book that
features secrets from the
Top 40 Bloggers on the web

How to Generate Traffic to Your Website ebook

How to Generate Traffic to
Your Website
is an ebook for
to you achieve success


 

FollowSteph
More resources from Stephane Grenier:
PUBLICATIONS
For people who work on the web
Blog Blazers
How to Generate Traffic to Your Website
 
SOFTWARE
The EASIEST Property Management Software available!
LandlordMax


Copyright @2003-2024
LandlordMax Property Management Software

Disclaimer: This is a personal blog about my thoughts, experiences and ideas. The contents of this blog are for informational purposes only. No content should be construed as financial, business, personal, or any other type of advice. Commenters, advertisers and linked sites are entirely responsible for their own content and do not represent the views of myself. All decisions involve risks and results are not guaranteed. Always do your own research, due diligence, and consult your own professional advisors before making any decision. This blog (including myself) assumes no liability with regard to results based on use of information from this blog. If this blog contains any errors, misrepresentations, or omissions, please contact me or leave a comment to have the content corrected.