A recent article asked the question whether dynamic languages can scale or not. I think the question can’t be answered that easily. Just because a project that used Python failed, doesn’t prove that dynamic languages can’t scale. There are just too many reasons for project failure. And I think Smalltalk proved that there can be big commercial projects that build on dynamic languages. The best thing of course is to reduce or even avoid the need of scaling, by careful architecturing and refactoring and by using the right tool. And IMHO lines of code isn’t a very good measurement for scaling.

I don’t think static typing is the silver bullet. It’s still far too limited, at least when using it in an imperative language.

One sentence in the above mentioned article made me feel somewhat sick:

“Languages like Ruby and Scala introduce new programming constructs and paradigms that are beyond the cognitive abilities of the average programmer”

At first I think, Java is far beyond the cognitive abilities of the average programmer. The whole environment a Java programmer usually has to use is incredible complex (build systems Maven, Ant, web frameworks, OO mapper) counting probably many millions lines of code.

The cited sentence also means that we need stupid programmers that don’t extend their knowledge. I couldn’t live in a setting like that. I expect from people and especially from programmers to be flexible, to be able to learn new languages. It’s the only way to prove that they have really understood the ideas behind the language and not just it’s syntax and how to apply syntax to specific problems. If they aren’t flexible enough, they will soon be replaced by machines. It’s that simple. So instead of accepting that programmers are limited, challenge them and give them a possibility to enhance their knowledge. But never accept sentences like the one above.

I found the following two quotes on the Java Musings blog, which definitively rules out Java as a serious language:

“Do absolutely whatever it takes to write as little code as possible, because the best code is no code at all.” – Coding Horror

“In particular I believe, quite staunchly I might add, that the worst thing that can happen to a code base is size.” – Steve Yegge

Too true!

The six weeks at Fraunhofer this summer was a really great experience that I’d hardly like to miss. We implemented a people search engine that, with some love, could compete against Wink. And that within 4 weeks with only three highly motivated students (including me ;-) and without making any money out of it!

During the first two weeks, it turned out that Java really sucks. To see why, take a look at the next picture:

Getting an “java/lang/Object not found” error is maybe the worst thing that can happen to you when you program in Java. And that was only one of the many problems our Java-guy had to tackle. It was a real fight! Respect! After two weeks we couldn’t see him suffering any more and as such converted him to Ruby ;-)

While the one was fighting with Java, our hard-core Ruby scripting guy with long hairs managed it to see the following picture on his screen:

From this point on, we did all our crawling stuff on a separate server, far far away :)

The last picture shows the activity of “us three”. Notice the number of commits of “Others” in the picuture, which actually is zero. As I only made it on the second rank, I wrote a three liner Ruby script and “slightly” faked the statistics. Too sad that we don’t have a picture of that :)

This comparison popped into my mind this (hot) morning. To do just simple things, you need a lot of paper (in Java: XML) to extensibly describe every aspect. Okay, in Java you don't need to fill in those forms tree times as you often have to do in an office. Then you need another huge office that reads and evaluates those papers. In the comparison with Java that are very complicated and big tools that you need. I mean, have you ever tried to read a non-trivial Java application with just a very simple text-editor like notepad. It isn't possible for the simple reason that you have to click through innumerable directories and then see lots of methods that you are not interested in (getter/setter). Or think of deployment desciptiors and stuff like that. You really need tools to create them (other tools).

And the worst thing is, that all this is kind of a black box. You know that it's just too complex to understand. But if something goes wrong, what should you do? So in Java, in my hence and very unqualified opinion you spend a lot of time and money doing bureaucratic nonsense. But it's of course good in a sense to keep the people employed, like in bureaucracy (redtapism), the people create new rules (new bureaucratism) to not loose their job. But the effect is terrible. It hinders people to do their stuff.