Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Epic codefest: 7 programming languages in 7 days

Learning a new programming language isn't hard if you understand the fundamentals

By Andrew C. Oliver, InfoWorld, 03/04/13

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.

For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.