In Holland we have a yearly development contest called “Development Tools” (formerly RAD Race). In two days, several teams consisting of two coders build an administrative application according to fixed requirements, with database access, forms, reports, the works. The contest was originally organized for 4GL RAD tools, but in recent years Java teams have entered the competition. Without too much success though, for no Java team has up till now managed to beat the 4GL tools. This year, for the first time, a Rails team joined up. And not just any Rails team; my co-bloggers from “rubyenrails.nl“, Remco van ‘t Veer and Michiel de Mare were in it. Today the results from the contest were published, and guess what — Remco and Michiel came in second! They beat all the Java teams; first place was for the CrossmarX Application Engine. Congratulations to Remco and Michiel, and to Rails of course!!

Following up on my recent post on Ruby and Rails’ enterprise-readiness, we might want to rethink any strategies comparing or opposing Ruby with Java. Don’t get me wrong: Ruby is a breeze where Java is a mouldy draught; Ruby is a butterfly where Java is an ostrich; Ruby makes you smile where Java is often a maniacal grin. But also they’re both gusts of air, both have wings, both evoke emotion. Both are object oriented languages, both have classes, and methods, and instance variables, and structured in-code documentation, and closures (more or less), both are pass-by-reference-by-value, both have apis for Lists and Maps and Files and Regexps… The list goes on and on.

Most Java coders that are first introduced to Ruby recognize a lot of things; and what they don’t know, still feels like what they’ve always wanted. There is the new syntax to learn, and so many new apis, and Ruby’s coding standards differ from Java’s — but let’s not overreact. If you’re a good Java (or otherwise OO) programmer, you will easily pick up Ruby.

All this goes to say that the introduction of Ruby and Rails in the (Java-oriented) enterprise must not be hindered by arguments like “We have already invested so much in Java, we don’t want that to go to waste.” If you have invested in a Java infrastructure, in Java-skilled developers, you have already invested in Ruby and Rails. You have (hopefully) trained your developers to understand object orientation, as well as things like MVC architecture, test-driven development, standards-based programming. Java is but a tool — or at least it should be. Ruby just builds on that.

The same goes for the Java-based infrastructure. Investments there aren’t wasted either. The time will come, sooner rather than later, when Ruby and Rails will neatly run inside a JEE application server. We will be able (if we aren’t already) to develop web frontends in Rails, talking to JEE business components, message queues, connectors, web services, data sources and what not. We will be freed from the restraints that Java forces upon frontend developers, with its xml and pojos and faces and struts.

Let Ruby and Java blossom in the enterprise — together like a daisy and a rambler rose!

In the recent, rather entertaining discussion between James McGovern and the rest of the world, about Ruby and Rails being enterprise-ready or not, a lot of emphasis was placed on the speed of development that Ruby and Rails may offer. Anne Zelenka correctly stated that speed of development isn’t all that important in an enterprise environment.

In a way it is sad, but big enterprises, large corporations, might not care much whether an application could be developed with Rails in half the time it would take with Java. Development (I’m including design here) is only a small piece of the entire implementation of an application. There’s functional testing to be done, training of end-users as well as support staff, setting up and maintaining the technical infrastructure for development, test, acceptance and production environments, data conversion, and overhead costs like project management, meetings, planning, the works. Things you can happily do without (more or less) if you’re a web startup, but not so for your average enterprise. (I’m not saying an enterprise couldn’t cut back on them, but most just don’t or won’t — it seems to be a given when you’re entering the enterprise world). And then of course there is application maintenance. Long ago I learned that, as a rule of thumb, application maintenance costs 20% of application development — yearly. That’s 20% of the costs of design, development and testing. Which means that, if you keep developing new applications, your yearly planning slowly fills up with maintenance work.

Instead of just focussing on the amount of development time you might save on, why not focus more on the reasons why development time can be saved on? For example, one of the reasons developing in Rails is so much faster, is the principle of ‘convention over configuration’. I think that might hold some attraction, as it is something that many enterprises are already trying to achieve, for instance with software factories: standards based coding. As a by-product of this, you need less code for your application, which also means less code to maintain. Another example is the shorter build cycle (at my current Java project, the “record” for longest build time stands at 1.2Ms). And how about prototyping? You might actually sit down with an end user and prototype view, model and controller in a Rails application. I’ve never seen that done properly in a Java environment. Prototyping often results in better user acceptance. Or test driven development, which in Rails is not an afterthought as it is in Java. TDD can prevent many unnecessary bugs, so also means less maintenance. (At the moment I am on a project where unit tests “are not needed because all code is generated with OptimalJ.” Yeah right.)

If Ruby and Rails can solve problems that enterprises currently have in their development environment, and save time and money in the process, they could become more interesting for bigger companies.
Of course, there are also reasons why enterprises may not want to use Ruby and Rails — but that’s for another post. Or maybe I should leave that to James McGovern.

Disclaimer: I am neither an enterprise architect, nor a thought leader on that subject. My opinions are based on my work for Dutch enterprises, which may not be comparable to U.S. enterprises. And I’m talking primarily about developing web applications, where Rails excels.

For me, one of the principles of programming has always been: “Use the programming language best suited for the job; and if there is none, create a new language.” I believe this is directly related to the idea of Domain Specific Languages (DSL) that are all the rage right now. Creating a new language that is best suited for a specific problem domain: that really says it all, doesn’t it? Still, it’s a quote that I first heard when I started my programming career, which was about twenty years ago — and it may very well be even older than that. How did people go about creating a language back then? (I mean parsing and compiling or interpreting it, not designing the language.) And how do we do it today? Has anyone ever asked the questions:

• “What programming language is best suited for implementing another (DS) language?”
• “At what point will creating and maintaining a new (DS) language result in less work than using a second-best language for solving the problem?”
• “Can we describe a new language that is meant specifically for creating DSLs, a meta-DSL?”

I was led to these questions after reading a post by Obie Fernandez on his blog. He describes how his team created a DSL that describes a data model. Depending on its context, the DSL code will either create a table creation script, a script for creating stored procedures, or XHTML code for display in a browser. His description is not all too elaborate, I must say, so maybe I’m missing some interesting feature here. But it sounded to me like nothing more than doing some data transformations. Wouldn’t XML and some XSLT scripts have done the job here? Also, if you create a DSL for this, you have the added disadvantage that you’ll have to maintain the DSL implementation as well (even if the DSL is easy to write in Ruby). Three DSL implementations even, one for each context you can use. The idea of contexts is nice, until you need to implement an extra feature in one context that will conflict with the others. Unfortunately, Obie never got round to answer this question that I put in my comment on his blog post.

I believe a lot of XML code written out there could actually be called a DSL in its own right. Someone wrote the other day (in one of the 40,000 blogs I try to read now and then) that XML is Java’s tool for creating DSLs; and I agree to some point. To some point. I mean, I write XML every day (in the form of JSPs), so by now I’m used to writing conditional statements and loops in the form of XML tags, but it’s hardly elegant if you think of it. It’s actually plain ugly. (And if you think that’s not ugly enough, go take a look at the next step in XML programming: Jelly, executable XML. Yuck!)

Mixing data and code is (in principle) a bad thing, I think; whether you start of with data and mix in code (like in XML) or you start with creating a DSL and add in data (like in Obie’s example). I would prefer to to put the data in XML (or Yaml, or a database, or some other form of structured data) and keep the code separate. This will also give you better insight whether you’ll need to create a DSL for processing the data, of if you can simply use XSLT.

P.S. “Simply use XSLT”? Did I just write that down? I take it back! I can fully understand how having to write XSLT can drive any sane person to code his own DSL. In assembler, if needs be!

Thanks to the North Western winds continuing to sweep over the island, the temperature has dropped to about 12 degrees. The boulevard where our hotel is situated is almost empty: this morning we went for a stroll there but we were hit full on by the storm; this is where it reaches the island first, not yet weakened by the many streets packed with houses and buildings that lie immediately behind the hotel complex. Malta is crowded. We saw from the air and later, during the taxi drive, how Valetta, the capital, together with neighbouring cities, spreads out over a large part of the island; all houses, no green; and shortly after you leave the city, the next one begins — Qawra, where we’re staying.

Qawra and its neighbour-cities cover an entire landslide (and some more) overlooking St. Paul’s Bay. Our hotel is on the North West side (the windy side right now); but if you cross over to the other side of town you’re at the other side of the land as well, where there’s another bay and considerably less wind. That’s where I am now: catching some sun, pretending the wind’s not there. I’m sitting on a bench; there’s a small patch of coastline that seems to have been overlooked by the hotels and clubs that cover the rest of the rocky beach: Bar Fuego (“Free Salsa lessons every Thursday and Friday night”), Diving School/Tauchschüle Octopus Garden (“The best place to be / Is under the sea”), Vintage Wine Bar (“Wine me, dine me the Vintage way”). All old and worn out and desolate this time of year. It seems I always end up in places like this, its glory day long gone, nothing new built since decades: every stone, every billboard, the stuff they sell in the shops: all reminders of better times than these.

View of Qawra from the boulevard