Dynamic For The Win

Everything passes, everything. — Anthony de Mello, Awareness

Take a look at what is happening around you. Relational databases are replaced by NoSQL databases. SOAP is replaced by REST, Javascript is dominating web development. The only place where dynamic is not winning is in the world of programming languages. But even if you take a look at programming languages, you can see that many of the largest most vital sites, such as Facebook and Wikipedia, are using dynamic languages. Why?

Dynamic is Better

It’s not the strongest of the species that survives, nor the most intelligent, but those who are most responsive to change. — Charles Darwin

What I mean when I say that dynamic is better is that dynamic systems are more responsive to change. And change, as they say, is the only thing that we can be sure of!

  • If I need to add a new field to a NoSQL database, I just do it.
  • If I need to add new field to my RESTful web service, I just do it.
  • If I need to alter the behavior of my Javascript UI, I change it, reload the page, done!

Soap vs. REST

REST is beating the hell out of SOAP nowadays, but you may have noticed that most “RESTful” web services aren’t really RESTful. They don’t follow the HATEOAS rule, they are just “Accessible over HTTP”. So why the big fuss about “REST” if no one is using it as intended? Because there are no contracts for REST! You are not constrained by WSDL and all the other bloated specifications. You can just publish your services without contracts, write some documentation and be done with it.

Relational vs. NoSQL Databases

NoSQL is the new rave, and most people think that it is because they allow us to handle large amounts of data, fast. I don’t think that is the main reason. I think the main reason is that they are schemaless. It is easy to add or remove fields without changing the data of all the other items of similar type. The problem with relational databases is not, in most cases, that they are slow, it is that they have a rigid contract that make them painful to work with. This effect is also, often, amplified by having O/R-mappers wrap the tables in static types.

Javascript vs. RIA Plugins

Javascript is the clear winner as the programming language of the web. Silverlight finally threw in the towel and Java is only living in ancient bank applets. Javascript is one of the most dynamic languages that you can imagine and it has won the battle of the web! Cool!

Programming Languages

In the area of programming languages, both client (not web) and server, dynamic is not winning, yet. Even though languages like C# and Objective-C are becoming more and more dynamic, they are still nowhere near Ruby and Python.
Java has stagnated and Scala is even more typeful than Java, although type inference relieves you from having to declare most of the types. Clojure is an interesting dynamic JVM language but it suffers since you still have to compile the code.

But dynamic will win when it comes to programming languages too. Why? For the same reasons that dynamic is winning everywhere else. They are more suited for solving ever changing problems. The problems I try to solve everyday, always has to do with integrating with something else, and it is much easier to do with dynamic programming languages.

So why is dynamic not winning in the area of client and server programming? I think there are a few reasons.

  • Education, most of us have been taught programming at a university that propagates for statically typed, compiled languages. We have been taught that dynamic languages are bad and that they may be suitable for scripting but nothing else. It has been hammered into us, so hard that we have a hard time letting go of this.

  • Tradition, the folklore says that dynamic programming languages are too slow. The fact that they are not, has not changed this. You may remember that the argument was the same against Java fifteen years ago.

  • And then there is the main reason, dynamic is harder!

Dynamic is Harder

So why isn’t everyone using dynamic programming langugages? Because, it is harder. It is easier to write really bad code in dynamic languages. But, on the other hand, it is also easier to write really good code in dynamic languages.

It is harder to develop large systems, because when you are using convention over configuration, it is really important to know the conventions and most people don’t take the time to learn what they use properly, they rely on the IDE for guiding them down the right path.
If you are suffering from IDEitis, the transition to dynamic languages is going to be tough until you realize that the help you get from the IDE is also what is holding you back.

The problem is moved from the programming language to me, the programmer, architect or whatever title I feel entitled to. If I am using a dynamic language and I screw up, it is my fault. If I don’t organize the code in a way that can be understood by others, it is my fault. If I make changes to core classes, and the system stops working, it is my fault. I am responsible! I am in control!

An example, third party libraries in Ruby

I remember a comment from one of my colleagues, when he found out that I had a problem with a library (a Ruby Gem) that didn’t behave the way I wanted it too.

Ah, you’re using Ruby, then you can just fix it. — Mattias Arthursson

Right on Mattias, I can just fix it!

Almost every Ruby Gem lives at Github. The flexibility this brings is tremendous. If a library is not working the way I think it should, I can just fix it. The process goes something like this:

  • Fork it
  • Make the appropriate changes
  • Push it back up to Github (to my fork)
  • Change the Gemfile, that holds my project dependencies, to use my fork instead.
  • Optionally, I may also send a pull requests of my patch to the maintainer of the library.
  • The maintainer takes a look at it and pulls it in, relieving me of the burden of keeping my fork up to date.

The process is so simple, it is almost seamless.

I’ll finish with another quote.

It is vain to do with more, what can be done with less. — William of Occam

It’s a new year, it is time to prepare for the future, a dynamic future! Here are some books that I can recommend, they are about Ruby and Javascript, since they are my current favorites. But if you like other dynamic languages better, knock yourself out!


The books are ordered, by increasing level of complexity.





This Post Has 7 Comments

  1. Agreed – dynamic for the win!

    I want to mention that Objective-C actually, largely thanks to its Smalltalk-heritage, has many awesome dynamic abilities that doesn’t come far behind Ruby/Python. Check out this post on Stack Overflow for some examples.

  2. Not to mention MacRuby on the Objective-C platform.

    Still, I don’t see how NoSQL and REST makes a strong case for dynamic, unless you are simply refering to the english word “dynamic”.

  3. @Christian, I agree, I didn’t know that Objective-C was that dynamic.

    @Joakim, I am referring to the word dynamic, as in dynamically typed. With that I mean that the typing doesn’t have to be declared in advance and that it can be changed at runtime. That is two properties that NoSQL databases have and that REST also has since there is usually no schema declaration for REST services. I know that there are some that think there should be, with, for example WADL (Web Application Description Language).

  4. Can you explain what the connection is between your Ruby/Git example (as in “it is open source so I can make my own fork”) and the fact that Ruby is dynamically typed?
    I fail to see why this isn’t possible with other kinds of languages.

  5. @Bjarke, I agree that the Rubygems-Github example is not specific to dynamic languages. It was more meant to show that it is very much the spirit of Rubyists.

    But that said, it is easier to change a library in Ruby that many other libraries depend on since the library is dynamically typed.

    If I would do the same thing in Java library, for example commons-collections, I would run into all sorts of trouble, since other libraries would be dependent on that specific version and interface. Not so in Ruby, unless I actually break some functionality.

  6. Premature conclusions are the root of all evil.

Leave a Reply

Close Menu