xEvents is now well on its way, with major components being added to the system at each iteration. Vithun and Prabhu will soon be posting about interesting technical challenges we've encountered so far and are grappling with now. For my part I'd like to say something about our choice of Groovy and Grails as platform.
PhilPapers, our flagship product at the Institute, is mostly written in Perl. It's made up of kilometres of Perl code which I know inside out. At this stage I'm constantly reusing tools from this code base, and I feel I know every little quirk of the stack PhilPapers is built on --MySQL, Apache, HTML::Mason, FastCGI. These are compelling reasons to stick with a platform, yet I decided to jump ships. There are two main reasons for this:
1. Labour shortage. Perl's title as 'glue of the web' is long lost and the population of Perl mongers appears to be dwindling. Sure, there are still large systems running on Perl (I gather it's in widespread use at Amazon and BBC), but it's not a platform new entrants to the profession choose, and, realistically, junior programmers are often all that I can afford, so Perl is not a good choice for me. Last time I had to hire a Perl programmer, I very nearly failed.
Another factor that entered my decision is that one day we'll need to rewrite PhilPapers yet again (hopefully not before 2020) to make it Web 5.0 and incorporate all the latest conveniences of modern life. When that day comes it will be great to be at ease with the state-of-the-art platform. This is also part of why I've chosen Groovy+Grails as my next platform.
Groovy is a language that compiles into Java bytecode. From .groovy files you generate .class files which can be used exactly like .class files compiled from .java files. You can even mix Groovy and Java classes in your programs (using either Java from Groovy or Groovy from Java). In fact when you code in Groovy you use Java libraries all the time because that's a big part of the attraction of the platform: the API is a superset of Java's vast API ecosystem. Grails is an application framework similar to Rails for Ruby. It provides all the main benefits of Rails, plus this: it's an extension of Spring, arguably the most battle-tested and slickest application framework there is.
Many of the virtues of the Groovy+Grails combination are obvious from the above. I won't say much more on this because the Grails web site already has a good sales pitch. The only thing I'd like to add is that Groovy as a programming language is perfect (for me). Its C-style curvy brackets make it feel homely to someone who's spent most of his waking adult life starring at Perl, C, or Java code. Its syntax feels maximally clean and concise, but not obscure like Perl's. It's incredibly predictable. It has all the things that Java misses, closures and scripts in particular. It also has the things that Perl misses, for example, proper OO, without missing any of the cool Perl features which make it so well suited to Web development and text processing (e.g. string interpolation, compact regular expression handling). Its dynamic typing system is right on the sweet spot between paranoia and helpfulness.
Barring any major social or economic obstacles (I'm a little worried about Oracle trying too hard to monetize the JVM), I predict that Groovy+Grails is going to steadily gain in popularity over the coming years, because it's a winner on all counts from a technical point of view. As for finding Groovy+Grails developers, any Java programmer can be converted into a Groovy+Grails programmer within a few weeks, because the syntax is incredibly easy to learn and the APIs are basically Java's. I predict a stream of would-be converts for the foreseeable future.