Monday, September 24, 2007

Does the language really matter?

Just read this post from JRuby god Ola Bini which pointed to an older article by Paul Graham. Eloquently as ever, Paul explains his views that more clever guys use superior technology and therefore are likely to succeed in business (i.e. be more successful than the competition).

During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.


I agree with his conclusion that more clever guys will be more flexible in choosing their tools. But is it really true that this translates into business success? If so, how can it be that MySpace succeeded although it was (originally) built on ColdFusion (in 2003 I believe). How can it be that Facebook is rumored to be sold at 10 billion dollars while being built on PHP (I do not mean to diss PHP, but it is hardly a technology known for its extravagant cleverness)? Regarding the ColdFusion example above I read that MySpace chose this technology because they simply had a development team that happened to know it well (and thus was efficient enough at cranking out the code).

My take on this question is that the chosen technology just has to fit sufficiently well to the problem. If that is given the team that is more proficient in their technology will have the advantage.

Thursday, September 20, 2007

Slightly slimmed down Cairngorm

Currently, I am in the finishing stages of a Flex 2 project (actually a pet project of mine and 2 buddies). We have chosen to use Cairngorm for the client-side architecture. Generally, I am quite happy with this choice because it saved us from having to re-invent the wheel and it works quite well for us.

But.

At the beginning of the project we felt that Cairngorm introduces too much bureaucracy into our client-side architecture. It was simply too heavy for our needs (more like J2EE in 2001 than Ruby on Rails in 2007). So we stripped out two parts that we thought are adding unnecessary complications:

  • The most annoying bit for us were the value objects (VOs). We already have a model and we have an event object. We simply had no reason to create another object for transporting data. If we want to pass a model object to the business delegate we simply pass this model. I we want to pass some very simple set of variables (say, a string and an integer) we simply add that into the event. No need for VOs in our case.
  • We use only one business delegate. This delegate encapsulates all available services. To be honest, I am not sure if Cairngorm is even meant to be implemented like this, but anyway, it saves us from creating a new delegate whenever we add a service. All we need to do is add a new method to our delegate.
So adding a new service boils down to
  • adding a method in the delegate and the controller respectively
  • creating a new event class
  • creating a new responder/command class
Even coming from a RoR background where DRY is the dogma we can live with that.