Epic codefest: 7 programming languages in 7 days

Much of today's buzz is about alternative programming languages, and the pitch often emphasizes "increased developer productivity" (IMHO, a sham on multideveloper projects). As long as the language has garbage collection, strings, real types, and so on, it shouldn't matter. This means nearly anything at a higher level than C or its mangled Neanderthal cousin C++ should reap the same productivity out of developers.

That said, a shiny new hammer will always be tempting to those who get infatuated with their tools. But to pitch a switch to another programming language, you need to prove to your boss that the transition costs aren't ridiculously high. Here I would agree with the proselytizers for change. It doesn't take much to train good developers to learn a new language -- so I decided to prove it.

Most business apps are just big versions of what I like to call "Granny's Addressbook," a simple CRUD application that doesn't need to scale or be protected against cross-site scripting attacks because it lives on GrannyLAN. These apps take requests and write them to the database. They read from the database and display the results on a Web page. There's not much more to them.

Because of this, I tend to use Granny to evaluate new technologies. (See "Which freaking PaaS should I use?" and "Will the future be written entirely in JavaScript?" for examples of this.) Granny is also something my firm uses in its staff development program and to vet job applicants. No security, no search -- just something you should be able to bang out inside of a day depending on how carefully you code it.

So what better way to get a first look at the cost of switching programming languages than to turn Granny loose on a bunch of developers and break them in on a language and tools they've never used before?

Here are the results of this attempt to teach our developers seven languages in seven days. Armed with a pre-prepared PostgreSQL database and AJAX-y HTML, we implemented Granny as a "quintessential application" in Java, Kotlin, Ruby, Scala, Clojure, JavaScript (Node.js), and Go. You can find the list of GitHub URLs and basic instructions here.

These aren't necessarily "best practices," and with a 24-hour deadline, there are bound to be mistakes. Still, the code is a good idea of comparative implementations in the various languages, as you'll see.

Methodology

For each language, we chose a developer who didn't know the language at all. For example, our UI/JavaScript-savvy Web developer was assigned Java, which he's never really done, living as he does in JavaScript/JQuery/HTML/CSS land. For Node.js, we put to the test a back-end Java developer who didn't know JavaScript.

To ensure each version of Granny was "quintessential," we used the frameworks and methods most common for the language in question, though this should be taken with a grain of salt. For Java, our JavaScript guy started out with JAX-RS and the Java EE stack before moving to Spring. We also relied on the most commonly used free tools, and because we're an open source shop, we used Linux across the board.

We contacted the company or community behind most of the languages and asked whether a mentor could be supplied. (We have enough in-house expertise in Java, JavaScript, and Ruby to do the mentoring ourselves.) We also used community forums, IRC, and mailing lists where possible. Our thinking: A company/organization with enough PR energy to help with the article will be helpful to a paying customer as well. A community that functions on this short a timeline in a helpful manner for a n00b will be reasonably helpful to developers on real projects.

Most developers implemented Granny first in Java and Spring, according to our staff dev guide for a comparable experience. Then after many moons, they implemented it in their assigned "new" language. Aside from the overall guidance above (be "quintessential" and "conventional"), nothing was dictated, like "use higher order functions" or "declare your types." Then each developer was asked some basic questions.

• What makes this language special?
• What did you like about it?
• What frameworks and runtimes did you use?
• What IDE, editor, and so on did you use?
• How did you build Granny?
• Now that you're done, would you find it easier to implement Granny again in Java (or whatever language you are most skilled in) or in the new language we assigned you?
• What things did you learn that you will take back to your "day job"?
• Where did you get your questions answered?
• Would you recommend using this language on a project; if so, where/when?
• What was the biggest drawback (besides lack of familiarity)?

Following you will find the takeaways from this experiment in programming language transition, as told by each Granny's Addressbook developer.

 Day one: Java GrannyDeveloper: Mark Pettit, JavaScript developer extraordinaire

Java is obviously a well-established language with a substantial community behind it and abundant documentation.

I used the Spring MVC framework and the Spring Tool Suite IDE. Having no experience setting up back-end frameworks, I relied on the suggestions of my colleagues in making this decision. Jackson with Jersey was another option, but we decided Spring would be easier to work with in the end, albeit more complicated to set up.

As a front-end developer, I've never had the occasion to get familier with REST Services or controllers, let alone try to implement them. Now when my back-end colleagues talk about database connections and POJOs (Plain Old Java Objects), I can nod knowingly instead of letting my eyes gloss over. Fortunately, my programmer colleagues were all very helpful in pointing me in the right directions. Deep Mistry (yes, that's his real name) was especially helpful getting me through the Spring setup.

 Day two: Kotlin Granny

Developer: Lifford Pinto, Java/Spring guy with his head in the clouds

Given that Kotlin is a fairly young language, it wins coolness points. A new language is a programmer's turn-on.

Kotlin is a statically typed language that compiles into JVM bytecode or JavaScript. Brought to you by developers at JetBrains, Kotlin promises to be safer than, compile at least as fast as, and be more concise than Java while remaining simple and expressive.

I don't think it would be fair to say that I liked or disliked it, considering the fact that I spent only a day working with it. It does have enough appeal to make me want to revisit this exercise without the constraint of the do-it-in-a-day deadline. It was easy to set up, and the documentation has several examples to help you get familiar with the language. I appreciated that the Kotlin team was willing to provide us with mentor support even on short notice.

I do most of my development work on Eclipse-based IDEs, but the obvious choice of IDE for Kotlin was JetBrains IntelliJ. I used the Kara Framework to quickly set up an MVC application. It's hard to say if this was "quintessential" or not -- Kotlin hasn't been around long enough. Regardless, this was easy to work with and set up. I couldn't easily figure out how to communicate to the front end via JSON, so I quickly switched to hack string manipulation to get 'er done. Talking to the database was easy via Kotlin's JDBC library.

 Day three: Ruby Granny

Developer: Brian Crucitti, "The New Guy"

What makes Ruby special for this particular type of development is Rails, a framework for Ruby that I'm sure most people have heard of. Once I had a basic grasp of Rails, putting this application together was incredibly easy.

I installed Ruby and Rails; three Rails commands later, I had a basic app outline and database. Getting the main page set up took me a moment of searching through the new directory and replacing the existing public/index.html with my own code. After that, a bit of trial, error, and code analysis allowed me to set my JavaScript file to accurately communicate with the Ruby back end.

I didn't have many questions or trip-ups making the app. In preparation, I studied the Rails tutorial. The first few chapters were enough for me to set up almost all of the Ruby aspects of Granny's Addressbook.

I would definitely recommend using Ruby for all sorts of projects. It's a language that's very easy to read and write. I would definitely recommend using Ruby and Rails for Web applications, especially small ones.

If I had to write a similar application again, I would definitely choose to write it in Ruby over just about any other option, especially with Rails. It was so easy to set up the basic outline of the app, which is all a Granny-level app really needs.

The one drawback to this project is that I don't feel like I learned very much Ruby. I learned several Rails commands, which did all the work in creating the Ruby files for me. As I've stated before, this project was very simple to achieve using Ruby and Rails. I'm sure there's a wealth of powerful abilities in Rails and Ruby, but it wasn't called for here. I'd like to study them more.

For development, I used TextWrangler for the Mac because I like text highlighting and it has a convenient method of switching between files in a directory tree. I ordinarily use Notepad++ for Windows, and TextWrangler had a similar feel.

 Day four: JavaScript Granny

Developer: Deep Mistry, Java/Spring guy hell-bent on a NoSQL future, and yes, that is his real name

Derived from Java, Scheme (derived from Lisp), and Self (derived from Smalltalk), JavaScript has become the go-to language for most front-end developers. It has become a fundamental language for writing for Web apps mainly because RESTful APIs (using JSON) have become standard, as opposed to SOAP (using XML). When your back end is also written in JavaScript, JSON marshaling and unmarshaling becomes a near flawless natural process.

In fact while writing Granny's Addressbook in JavaScript, I didn't even think once about the whole marshaling/unmarshaling process. It occurred to me only after a POST request worked correctly that I had actually never mapped the JavaScript object at all. The weirdest thing for me (a Java Spring guy) was not thinking in terms of object-oriented design. Using variables without defining their types, passing entire methods -- er, functions -- as arguments, and closures on variables whose functions have returned long back felt totally insane the first time. However, within 24 hours of working with it, I was already starting to like it and am unsure now that I will see Java the same way as before.

I used Node.js and Express framework. I also used a node-postgres client for Node.js to work with PostgreSQL as a back-end database. I used JetBrains WebStorm IDE, which I found very easy to work with, especially since I'm already familiar with IntelliJ IDEA. WebStorm has extensive support for Node.js and Express. In fact, it includes the option to create a Node.js Express project out of the box. (WebStorm is proprietary, but I used the 30-day trial version.)

To create Granny, all I needed to do was to create a right run configuration using the app.js file (which WebStorm auto-generated), and I was good to go. One thing that I did struggle with was the lack of an option for plain-old HTML views. Instead, I was offered .jade and .jshtml views, which I was completely unfamiliar with. I did find a simple work-around, however; instead of configuring the IDE to use HTML, I let it use Jade and simply performed import <foo.html> -- and I was done.

If I were asked to implement another RESTful back end in JavaScript, I would definitely use Node.js and Express. It would be much easier and faster for me now that I know the basics of how this combo handles the flow.

I learned a lot about JavaScript and functional languages in general, including how to make Web apps with minimal code. With Java and Spring I now feel that I am writing tons of classes, interfaces, and XML files for something that could be done in a few lines of JavaScript. It got me more interested in dynamic languages, which I would most certainly pursue during my free time.

I had lots of questions regarding JavaScript in general, for which I went through some of Douglas Crockford's lectures to get a quick boot starter for JavaScript. Apart from that, for many of the database connectivity questions I went to the documentation on the node-postgres GitHub page. Otherwise, for most of the questions regarding Express or Node.js I simply searched the Internet and found similar questions on Stack Overflow.

But unless there is any reasonable valid reason for using JavaScript for the back end, I wouldn't recommend doing so. It worked pretty well for a small project like Granny's Addressbook, but add scalability, security, and larger project requirements, and I'm pretty sure more problems would creep up. For any small project that doesn't include these as requirements, using Node.js and Express would be my choice, if not for the ease of working with JSON, then for simplicity.