Everything passes, everything. -- Anthony de Mello, Awareness
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.
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.
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
The books are ordered, by increasing level of complexity.