I don’t know how something that fails to make the proper Foleyesque slobering noises about dynamic typing and Ruby on Rails managed to get voted up on reddit, but I am glad this did. It is a rather excellent article that manages to nail the issue without really taking sides. My only complaint is this: it gets the recommendation exactly wrong.
If you use a slobby language like python you will have to become extremely neat. If you work on a project with more than one programmer you will have to start documenting the types of every function in comments or you you will find yourself having discussions like “fred, does this method expect a list of hashes that map ints to strings, or a list of hashes that map ints to user objects?”. You will also have to be very serious about your testing strategy to make sure that you maintain the ability to refactor when you have a lot of code, otherwise it is impossible to know when you have broken something. If you have only 60% unit test coverage in some area, you will need to do a lot of manual testing to ensure you haven’t broken something with your refactoring.
Likewise if you work in a language like Java (or better yet, haskell!) you can be a lot sloppier. You can make interface changes and depend on the compiler (or a refactoring tool) to find all the various places you have just broken.
One should pick tools that correct ones own tendencies, not tools that exacerbate problems.
So my recommendation would be this: if you are very precise about types, so much so that you can maintain them all in your head, then dynamic languages are the way to go–they will offer you flexibility and less writing out of types. If you find yourself slipping a bit in your precision, then you want a compiler which checks static types for you. I know that I am a slob, so I think that type inference is in my future.
Ivan | 10-Oct-06 at 6:52 am | Permalink
Jay this is so true. Why is it only a few people seem to understand this? Everyone flocks to scripting languages for the quick and dirty, but it’s nothing like that!
On the contrary, the scripting language is a very sharp knife, while a rigid language like Java is a set of knives from sharp to plain dull. This can be very beneficial when you don’t know who else will be using the cutting boards at work
Reg Braithwaite | 10-Oct-06 at 8:10 am | Permalink
Thanks for your kind words!
I’ve made a rather important change to the essay. I hope you like the new version even more.
http://weblog.raganwald.com/2006/10/if-sneetches-with-stars-use-java-and.html
Reg Braithwaite | 10-Oct-06 at 10:35 am | Permalink
Ivan:
People often talk about how well certain languages “scale.” While they think they mean “scale to larger problems” what they often really mean is “scale to larger teams.”
Many people think of the two as equivalent, because how would you solve a large problem with a small team?
The answer, according to the expert chef, is to use sharper knives.
jay | 10-Oct-06 at 1:54 pm | Permalink
Reg,
I completely agree. What I was trying to say is that sharper knives are harder to use on larger teams, and not all problems are solvable by one misanthropic genius and a good LISP implementation (heresy!).
Reg Braithwaite | 10-Oct-06 at 5:07 pm | Permalink
Jay:
I understand that you are saying that sharper knives are harder to use on larger teams. That isn’t what I’m saying, I was only saying that most people think along those lines.
My experience is that when people say “larger teams” they never mean more peopel with the same level of skill as the smaller team.
This drives the dullness of the knives, and they are left with less skilled people using duller knives, and trying to make up for that with “volume.”
And you know what? Some people believe that they can become the Walmart of development and somehow have the magical logistics to make this work.
Perhaps they can. But it is very difficult to manage large-scale logistics, and it is very difficult to obtain good results from large teams.
I would say that there are far more people who believe it can be done than there are managers qualified to do it.
I am a lazy guy. I have obtained very good results with smaller teams of very good people. So I don’t throw all that experience in the garbage and chase the promised land of equal results with bigger teams with merely okay people.
Instead, I spend my time looking for ways to make smaller teams of good people even better.
That’s just my way.