Bikes and Code

Web development can be a bit of a beast, at least from the perspective of a programmer who is aware of the limits of his brain.

Back in the good old days, you could build entire desktop applications with one programming language, C++ or whatever that may have been. Whether the code you were working on was for the presentation layer or deep in the business logic, you were dealing with the same syntax, the same debugger and the same paradigms. The advent of large web applications completely destroyed that.

Depending on the language and framework you are using, any reasonable web application typically requires detailed knowledge of no less than four languages. HTML for your content, CSS for presentation, Javascript for any dynamic effects and some other language that you are using to do your server side processing. Technically speaking, two of these are not programming languages (HTML and CSS) as they offer no control structures, but they are still a syntax that you must keep in mind when working with them.

The problem with this is that no matter how good you are at programming, there is some mental overhead associated with the requirement to switch syntaxes in your head as you move from working on one aspect of the project to another. Generally speaking, most languages have their own distinct set of advantages and selecting the correct language for a given project is an important. That said, the more languages a programmer needs to use to work with a given project, the less likely they are to be an expert in all of them. This is an important enough point to note that it is corporate policy at Google to work with one of something like four languages. (Steve Yegge talks a bit about this here)

So I’m going to postulate that keeping the number of distinct languages that are needed to keep a given production application working and maintained to a minimum is an important consideration. If your project is using the aforementioned three web presentation languages, then a mixture of PHP, Java and Perl on the server side, you have dropped a large brick wall in front of any developers new to the system and added additional mental overhead to working on the project even for your top developers.

The grass is greener…

Which brings me to the Google Web Toolkit (GWT). I have used this in a few projects now and am fairly comfortable with the framework. I can safely say that I know it very well from an applications development perspective. When I first started using it, it was like magic. I got to write and debug Java code, which I was very familiar with, but when I was done, I could compile the project and run it in a browser with the same functionality.

The more I used it, the more I began to feel that I was actually more productive with it than by writing straight HTML/CSS/Javascript and tying that to a servlet or JSP based back end. I will emphasize that this was a ‘feel’ more than any sort of hard numbers, but more on that when I get to the criticism part of this post.

I’ve rambled before on some of the problems that I have with Java and was looking around to try out a new web application framework. I settled on Ruby on Rails to build Gifti.ca and I do really enjoy working with this framework. It has often been said that there is nothing like moving to a new language to show you deficiencies in the one you usually use, but the opposite is true as well. You see, with Rails, I was back to how I originally worked with web applications, four or five languages. This was when I had my ‘ahah!’ moment about the GWT and what it was that I really enjoyed about it.

Java, simpler?

In this case, yes, with the GWT, you need to work with two languages, Java and CSS. You can build an entire web application with the GWT and the resulting HTML that you actually put into the page is absolutely minimal. For all intents and purposes, you link to the Javacript file that the GWT generated for you and the entire application merrily builds itself in the web browser. For the most part, the major browsers work fairly interchangeably as well. The generated code is quite fast, better than humans can generate according to the Google propaganda and I have no reason to doubt them.

You do need to keep a handle on the CSS, but even then, a number of the classes have methods which allow you to programatically set various alignment parameters and the like so those can be taken out of the CSS as well. The AJAX functionality they have baked into the framework plugs into a servlet container so beautifully I’d be hard pressed to come up with a simple reason not to use Java on the server side with a GWT front end.

Eliminating two of the languages that you need to keep in mind when working on a project is a huge benefit mentally speaking. Fewer major context switches when going from layout to client side logic to styling meant that I found it easier to stay in the zone. This is why I need to make intelligent arguments with myself when starting up a new project as to why I’m not immediately firing up Eclipse and coding up a GWT project.

But…

I have some concerns about the framework. I feel more productive when I am using it, but I know that I spend longer building the user interface than I would have with a plain old fashioned web application. On the other hand, the UIs I tend to build with the GWT are more sophisticated. It is a balancing act. While I never bothered to keep any statistics, I would be surprised if the GWT was any more productive than anything other web application framework.

There is one very serious problem with the GWT and I have no real idea how to address it at this point, which is why my latest project isn’t using it. The GWT makes it easy, very easy to build your entire application with it. If you deploy a website built entirely with the GWT, search engines will not be able to index you. At least, not yet. All of your content will be buried in the compiled Javascript which in turn means that unless the search robot is running a full Javascript engine, you are out of luck.

Worse, if you want to support a version of the site that actually works without Javascript, you are left with writing another front end for the application entirely from scratch. My experience has been that this is painful.

Which also really means that before you jump into using the GWT for a given project, it pays to know your audience. For a general purpose web application that is to be used by a large and diverse group, the GWT is probably not the best choice. This is double so if the web application is geared more towards searchable content such as a blog. If you are building an intranet application or know for a fact that the clients that you are interested in will be running a full featured browser, then the GWT is an excellent technology to choose to go with. It’s probably also going to work rather well in an environment where web searchable content isn’t terribly important, a mashup with Google Maps or something along those lines.

Anyhow, long and the short of it is that I will continue to use the GWT for projects for the foreseeable future, it’s just too powerful for me to ignore. Being able to effectively ignore HTML and Javascript for a certain class of application is highly appealing to me.

Most of what I’m going to ramble about here was covered much more eloquently and in far greater depth in Beyond Java. These are my personal feelings and anecdotes on Java and it’s history. I should also note that despite what appears to be a moderately negative tone, I still do use Java extensively and used it to build the product of the rather short lived startup I co-founded.

I first encountered Java way back in 1998. This was effectively my first programming language, though I had done some C++ in high school. That wasn’t formally, mostly self taught and pretty much purely due to laziness. At one of the computer shows in Vancouver, (which might have been Comdex, did that show travel around?) I talked my father into buying me a C++ compiler and toolchain. It was definitely Borland, I’m fairly certain it was one of the Turbo C++ packages, though I have no idea which version now. Regardless, my main goals were to ease my physics and math homework by writing programs to do various tedious calculations for me. That was more or less a success, I still recall the joy at punching 3 numbers in and getting the solutions to the quadratic equation back. I learned about loops, variables and if statements, but nothing else really. But I digress.

At Carleton University, the first programming course I took was in Java, at this point in time, we’re talking Java 1.1 for the most part, the entire API was a couple of hundred classes at most. Supposedly it was kind of exciting because it was object oriented, but that was way beyond me for at least a semester. Mostly what I recall from my entrance to the world of programming was my epic battles with the compiler. I hated javac. There was perfectly valid… things in my file, at least as far I could tell, but javac would tell me that in no uncertain terms that I could not go so far as to call that text ‘code’. Eventually, the program compiled and joy was felt throughout the lands. Immediately thereafter, I would run the program, which would crash with a NullPointerException or some other fun error case. This was before the time of decent debuggers, at least to a novice programmer, so with a liberal smattering of System.out.printlns, eventually I could figure out where I had a mistake. Then change the code, fight with the compiler and the scenario would repeat itself until I could run the test cases provided in the assignment.

All in all, though, Java in those early days was a pretty simple language. You would make an array, do stuff with it and be happy about it. Or, once you started to grok how this object oriented stuff worked, you’d make a Vector and stuff things inside of it and you would never worry about resizing the array again. I mean, there wasn’t much to the language, check out the 1.1.1 API I just googled for. There were a couple of weird features for a novice to see, anonymous inner classes are a great example, it took me years to really understand how to effectively use those things.

Java 1.2 was introduced in December of my first year and included a number of things, the only ones that actually mattered to me as a fledgling programmer was Swing and the Collections library. Swing because the winter term had a Java graphical user interface (GUI) course and the collections library because I could now cheat and use LinkedList instead of always having to write my own for each assignment. Maybe it wasn’t every assignment, it just seemed that way, still.

Java 1.3 did not really add anything of use to me and stayed out of my awareness. Java 1.4 added a few more things and I wrote a fair bit of code with that version. Still though, Java was still the same old Java as I had used back when I started with it. There were new libraries, and that was nice, Java was growing with me as I needed to do more with it. There wasn’t any real new syntax that had to be learned, if you hadn’t seen regular expressions before, it was a bit of a shock to see Perlish things in Java 1.4 but for those of us who had used them, it was nice to have the power of regular expressions in Java.

By this time I was working in the industry, specifically on a rather interesting Java application that was officially using 1.3 Java when I first showed up on the scene, 1.4 shortly after I started writing code for it. I should  note that I mean interesting in terms of the curse, “May you live in interesting times”. Not as in, “That book is great, some really interesting points.” The system was the definitive legacy but business critical application, so arbitrarily going to a new Java version wasn’t going to happen until the powers that be had given it the official green light. At the time I was happily drinking the generics kool-aid, helped in no small part by the .NET team at the company who was gushing about how much the .NET generics implementation had helped them. I pushed for the migration and eventually we had migrated to a 1.5 JVM and all was good.

I learned the new syntax for the generics and for a while it was great, but a few things were beginning to bug me. In the entire time I had worked at this company, I hadn’t actually seen a ClassCastException in the wild. This appeared to be the main thing that the generics were attempting to fix. The syntax was a bit clumsy and fairly verbose, especially if you had descriptive class names. Making a generic class was an exercise in pain. Enough so that after one serious attempt, I nixed it in favour of a single purpose class that could only take instances of a given interface. Most grievous in my mind was that after going through all of this anguish to get a generic class, as soon as you hit run time, you could not use reflection to actually figure out what *should* be in the container. I remember being shocked when I found this out and needing a coffee break to reassess.

From what I could tell, all of this extra syntax was being entirely tossed out before run time, which meant all that extra typing and ‘safety’ was a merely a compile time check. One of the first lessons learned in programming was that just because something compiles does not mean it works. So while getting a bit of extra information at compile time is nice, I couldn’t help but think the benefits of the check was not worth the cost of the extra time spent typing and managing the syntax. (Side note, no, it’s not ‘just typing’, it is the most fundamental skill a programmer needs to have and should be taken very seriously. Arguments here and here.)

Regardless, I soldiered on and slowly encountered other 1.5 enhancements that made Java more complex. Annotations, which through a new syntax would allow you to add some extra meaning to a method, class or variable. Enumerations, which I do love using when the previous option was lists of static final integers or strings. That however, was done with a new keyword, ‘enum’, which by some entertaining coincidence was the exact variable name used throughout our codebase for Enumerations. (Enumeration enum = hash.keys(); Eventually I will write more on code quality in that entertaining project.) Never mind the fact that now you have to talk about Enumerations or enumerations, which is always entertaining. Then there is the varargs syntax, which just feels like a solution in search of a very specific problem. Seriously, I mean, have you ever needed this? Then there is autoboxing, a nice feature, but blurs the lines between objects and the Java primitive types, which can lead to a whole new way for developers to misunderstand what a block of code is doing.

I no longer feel that Java is a good language for a new developer to start programming in. It has it’s advantages, but those are almost exclusively in the domain of large ‘enterprise’ systems now. Some of the changes appear to have been to keep maintenance costs down and to mitigate the damage a low quality programmer can do. Some of the changes appear to have been good ideas, but they were done at the cost of making the syntax more complex and complexity is the enemy of software development.

The object-relational impedance mismatch. Unquestionably one of the stickier problems that a developer working with a database backed system has to deal with today. Depending on exactly who you believe, it’s fairly safe to say that a significant percentage of developers have encountered this particular problem. I won’t go into extreme detail on the problem as this article covers the main points beautifully. I will give a brief outline of the problem, then discuss my thoughts on Hibernate and Ruby on Rails, two technologies which address some of the problems. Neither is perfect, but they both have merits.

Most software developed today is object oriented (OO). This isn’t news to anyone, it makes a developer’s life easier as it allows you to conveniently forget about big chunks of code, which means you can hold more of the system in your head at once. This is good all around. At the same time, a sizable percentage of development efforts store their data in a relational database. Databases allow someone working on a software project to ignore the issues of storing and retrieving data. Thus, in many of these projects, the world of objects meets the world of relational databases and that causes problems.

One of the ‘solutions’ to the problem, quoted as they only address the actual software development aspect of the equation and not the political or infrastructural aspects, is Object-Relational Mapping (ORM) software. ORM software tries to take an object model and map it to a relational database or vice versa, depending on the system. The idea behind ORM is that if you manage to intelligently write something that maps from one to the other, you can keep your database and OO software distinct without having to deal with the messy logic that is required to go from one to another.

What I’m getting into here is more the ‘feel’ of the frameworks in question I am not passing judgement on either one as both of these frameworks provide significant benefits and drawbacks.  I’ve used both of these a fair bit in recent months and while by no means an expert, I can at least appreciate what they are trying to do. I should also note that there are likely errors, I am certainly overlooking aspects of Hibernate, my defence to that is poor, mainly that the framework is just too huge and knowing it all is at least a year long full time project. Few people other than full time Hibernate developers can afford that kind of investment.

If I had to use a single sentence to describe how a developer should approach the Hibernate framework, it would be, “The object model is god.” Hibernate is geared around using XML or annotations (what I actually used primarily) to mark up the object oriented Java code with hints, pointers and information on how an object should be written into the database. In practice, this means that in many cases until you actually go into production where other people start relying on the data, you may not even need to think about the database on anything more than a trivial level. You write your Java, add the hibernate hooks and let the framework do the rest.

With the ActiveRecord aspect of the Ruby on Rails framework, the equivalent statement would be, “The database is god.” In Rails, you create your database, set up all of the tables in some normalized fashion, following a naming convention and walk away. Rails then analyzes the actual database and generates objects which you then use in your application. You need to provide hints to the system when you start working with actual concrete relationships, but in general Rails does a decent job of generating objects which let you save and retrieve data.

I suppose it should not be a surprise that the Java based framework takes the approach that the objects are the key to the system and the database is a pesky, but important aspect that needs to be managed. Rails, a framework which is possibly THE case study in pragmatic programming, on the other hand, simply re-writes itself to match the database. Put another way, the feel I get from Hibernate is, “Write good OO code and we can map it onto a database.”  Rails, on the other hand appears to be simpler, “Well, you’re stuck with that database, here are the objects to manipulate it.”

The unsaid downside to Hibernate and the one problem I have with it is that you can go a long ways towards avoiding SQL and thinking directly about the database, until you need to refactor your code. Refactoring your code will likely mean needing to refactor the database to match your changes and in many organizations, this is simply not possible due to political reasons. (Accounting and sales have their own systems which use your data! You’ll break them if you change!)  At this point, SQL will start creeping into your code, while not a bad thing in and of itself, SQL that makes it into the system does start to mitigate the benefits of a full ORM system. Of course, this problem could be minimized by keeping an array of objects that do have accurate mappings and then putting an abstraction layer on top of that to massage the Hibernate equipped objects into actual system objects.

This is not to say that refactoring a Rails application would not end up with the same problems, however, your Rails code, by virtue of being generated from the database and not from the objects means that you have some sort of stability in terms of having a layer that does accurately map to the database, whether you like it or not.

The opposite approach that these two frameworks take is fairly interesting, especially when you work with them back to back. My gut feeling is that, all other things being equal which I should stress they are not right now, over the long term the Rails approach is going to be the more maintainable of the two. Unfortunately, for the foreseeable future, Rails simply will not be an option for political and business reasons, some valid, some not. (Valid: More good Java developers than Ruby developers right now. Not Valid: Scalability arguments, very, very few applications need to scale to millions of concurrent users, so for most of us, this isn’t even a concern.)

Anyhow, that’s it for now, it’s been on my mind for a while.