Rails only solves easy problems

Thanks for your attention. Now let me explain this. Ruby on Rails is a great application framework, Ruby having the best combination of power, shortness and readability. It's more powerfull per line of code than Java and more readable than Lisp. Rails is probably the best tool for the job. But what job?

Application classification diagramm

There are different types of applications. To classify applications and find the right tools for a project, I've created an application classification diagramm (ACD). This ACD is based on my experiences and the relevancy of factors for my projects. Your company may have a different ACD.

Application classification diagramm

The easiest projects are Webtop (1) projects. These are web and desktop applications including forums, blogs, wikis and other Web2.0 software. If you earn money through hosting such applications, your software is still in this category, but it has higher constraints for scalability and reliability. I mark those projects with a "+". Examples in this category would be Digg in the standard and Rallypoint and Basecamp in the + category.

The next category are Business (2) projects. If you sell something through your application, then the application is a B application. For this category you have to think about laws and regulations which apply to your application. Bugs cost a lot of money or jail in this category. Examples in this category are eBay, Amazon or iTMS.

The next category are Realtime (3) applications. You could argue that realtime applications are easier than business applications, but I think from a development angle, real time applications pose higher constraints on your tools than business applications.

If you run money, your're in a different camp and in the Money (4) category. No bugs there please. You don't want a bug where 0.001% of the time 1c is lost. For money software there are also more security constraints and more laws and regulations than for business software in general. Your applications needs to correctly log everything, provide a high security level, store everything securely, prevent tempering with the data and enable audits. Examples are bank and stock exchange software.

The hardest category to write software for are Life (5) applications. Everytime human lifes depend on your application, it's in this category. Examples would be nuclear power plant software, medicine applications or train management software.

Developer, inhouse or customer?

An orthogonal dimension to projects is the developer (D), inhouse (I) and customer (C) dimension. Tools are determined by this dimension too, though mostly this dimension depends on soft skills, role and process definitions. Deciding factors are who defines the application, what the application should do and who decides if the application does everything as defined. It's easiest when the developer of the application decides what the application should do and if it's fullfilling the specification. No communication overhead, no misunderstandings. The developer can very flexible change the goals and features. It gets harder when someone other then the developer decides all this, but the person is still inhouse. This happens with project managers, upper management, sales or marketing departments. There is more communication overhead, more people involved and more misunderstandings. The hardest projects are those where an external customer defines the application and decides if the application works according to spec. High communication overhead, unclear processes, conflicting processes, undefined roles, conflicting tools and no clear understanding of the goals happen all the time.

From my experiences with Rails and my experiences with the Rails community, most Rails projects are D1+ or I1+, with some projects being C2 or D2+. Most Basecamp projects seem to be either D1+ or I1+, with the free ones probably being D1 projects.

The size dimension

Some other dimensions are project size and the integration level. Some tools are better suited for smaller projects while other tools are better suited for bigger projects. So code size is a deciding factor for tool selection.

Application classification diagramm

Some applications are standalone which means they don't interface with other systems. Most often the only other software the application uses are databases. Database integration has been around for quite some time and is well understood, so I count database frontends as standalone. Integration projects usally need to interface with messaging systems, SAP and user databases.

This matrix is not optimal, as it uses lines of code (LOC) as one dimension. Languages differ a lot in the number of lines they need to solve a problem, Java needing much more than Ruby for example, DSLs and rule engines needing the least. A better metric would be number of classes, or number of methods, but coding styles differ here too. And for bigger systems LOC seem to describe the problems with the system more than other metrics.

Without knowing any number (I plan to do a survey on this in the future), I'd guess most Rails applications fall into the S10K or S100K range, with few projects being I100k.

There are other factors like "is the project from scratch" or does it extend an existing application, which could also be discussed.


There are different types of applications and you need different tools to develop them. Rails is an excellent tool for a special type of application. For other types you should use other tools. Does Rails only solve easy problems? Probably. But it's not important if it only solves easy problems, but if it solves your problems.

Weak versus strong languages, who wins the fight?

With all the buzz in scripting languages (again 🙂 often programming languages are divided into weak versus strong typed or dynamic versus static typed languages. I don't know how often some of us have seen this discussion, the first time for me was when I had to argue with C++ developers because I wanted to use Python (and then did) for web/database development nearly ten years ago.

Static versus dynamic

What does weak versus strong mean? This is based on the type system of the programming language. Languages where the type of references can change are usually called dynamic (weak), languages where the type of a reference is fixed are called static (strong). Take these two examples:

   String name = "stephan";


   def name = "stephan"

The first one is in Java and the second one is in Groovy. In the Java example a reference (variable) name is created. Then a data structure which contains stephan is created and assigned to the reference.

In the second example the same is done in Groovy. Where is the difference? Consider this:

   String name = "stephan";
   name = new Name("stephan");


   def name = "stephan"
   name = new Name("stephan")

The first example doesn't work, but the second does. This is because Java is statically typed which means the reference is statically typed. A reference possesses a type, in this case String. A reference with type String can only point to data structures which contain data of type String. In Groovy the reference is dynamically typed. So the type of the reference can change from String to Name when the data which it points to changes.

Another example in Groovy:

   String name = "stephan"

Hey, this is Java right? Didn't I say, Groovy is dynamic not static typed? Yes, you're right. But Groovy is more than this. Groovy is both dynamic and static. So the developer can choose a reference to be dynamic or static, just as needed.

Although categorizing languages into dynamic versus static (which the dynamic camp uses) describes languages better than weak versus strong (which the static camp uses), those categorizations are too simple to be useful, as seen already in the case of Groovy.

And there are at least two dimensions for typing, reference typing and data structure typing. In programming languages both references and data structures can be typed. This matrix divides languages between dynamic and static typed languages for references and for data structures.


Ruby, Python, Smalltalk and Java have all statically typed data structures (you could argue Ruby has dynamically typed data structures). But Ruby and Python use dynamic references while Java uses static references.

In the bottom right, there is C which has typed references but untyped data structures. And C doesn't enforce that typed references point to the correct data structures (because those are not typed). C data structures can be typed by adding a type field to the structure and checking the type before any operations on the data structure. Some C developers did this for more reference safety.

Other languages are even more free. Javascript for example uses prototyping for object creation, not classes in the traditional way. Maps and objects do not differ in Javascript and are essentially the same. Javascript does not know methods but executable attributes are used as methods. Libraries like Prototype or Base extend Javascript with an inheritance based class system.

Some languages can change the data structures although the data structures are typed. In languages with Meta support (Ruby, Groovy, ...) data structures can be changed, fields and methods can be added at runtime.

Scripting languages

I think there is more to this than the simple 2×2 matrix from above. Sometimes people use the terms dynamic and static, but mean scripting and compiled. What is scripting? Traditionally scripting languages were interpreted languages. In web devlopment scripting languages like Ruby and PHP make development easier. No compilation is needed and after changing your programm you can hit reload in the browser and see the new result. This way turn around times are minimized and development is speed up. But the line gets blurred. Scripting languages get virtual machines and are compiled to byte code for better performance. Java compiles to byte code which is interpreted. New Java VMs then don't interpret all byte code but compile the byte code to native code on the fly and as needed. Also compiled languages like Java get new classloaders and containers which compile new source code to byte code on the fly. And VMs like the Java VM run new languages like Groovy which can be compiled on the fly. For example in the excellent Grails framework.

Functional languages

Some people use dynamic versus static and mean object oriented versus functional. Consider these two examples (taken from Cedric Beust):

List result = new ArrayList();
File f = new File(directory);
for (String fileName : f.list()) {
  if (fileName.endsWith(".gz")) {
Collections.sort(result, new Comparator() {
  public int compare(String o1, String o2) {
    return o2.compareTo(o1);
  public boolean equals(Object o) {
    return super.equals(o);


zippedFiles = Dir.new(dir).
  entries.sort.reverse.delete_if { |x| ! (x =~ /gz$/) }

Both code fragments do the same thing which is sorting all zipped files in a directory.
The first is Java style object oriented (though this could be written shorter) and the second
is Ruby functional style. As can be seen, the second is easier to write, understand and
maintain. Especially in applications which have to deal with lots of lists functional programming makes code considerably shorter. Web applications often use lists (customers, projects, todo items) and so profit from languages which support functional style programming.


The whole discussion about dynamic and static languages is senseless. There are more dimensions which characterize a language than dynamic versus static. Scripting/compiled and functional/OO are other important things to consider. Languages like Groovy support object oriented and functional programming styles, can be used as a scripting language and compiled to byte code, support both dynamic and static typing of references and with meta programming capabilites support modifying static typed data structures.

I think there is still more to say about dynamic versus static. But this post needs to end here.

Who wins the fight? The is no fight, know your tools and use the best tool for the job. But at least the static/dynamic dimension is less usefull than it seams at first.