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 your 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.
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?
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.
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 Granny
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.
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 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.
Developer: Deep Mistry, Java/Spring guy hell-bent on a NoSQL future, and yes, that is his real name
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
The other drawback is that there doesn't seem to be any extensive, easy support for databases. Yes, I was lucky enough to find a Postgres client, but that was an open source project written by someone who used the framework before. Let's say I wanted to switch to MongoDB, Neo4j, MySQL, Couchbase -- there's support for a few of these, but the switch wouldn't be easy. We basically would need to rewrite almost all the code.
Day five: Go Granny
Developer: Brian Crucitti, "The New Guy"