Greg Luck's Blog

I want to way in on this flame war that James Gosling has triggered with his mild criticism of scripting languages. I think it is unfair and unhelpful. Here is my two cents worth.

I am still feeling my way on Ruby and Ruby on Rails. I spent a half day with Prag Dave, have done a ROR tutorial and have the two Ruby books. I also read a book on comparative programming languages to see what the experts thought.

I like the idea of having a few tools on the toolbelt, thus avoiding the “if all you have is a hammer, every problem looks like a nail” phenomenon.

I was not a particularly early adopter of Java. I got going with it about 1.2. The early Java was high on hype and low on class libraries and frameworks. And it was slow.

It seems to me that Bruce Tate, Dave Thomas and David Hansson amongst others are out flaming people rather than dealing with the criticisms raised.

Bruce should get over advancing Ruby by attacking Java. His beyond series seems to overlook the Tiobe stats. Java is growing in popularity, not declining. The thing that is declining is Perl. He should start thinking in terms of beyond Perl.

Dave Thomas ridicules the idea of an IDE. Perhaps when Ruby’s class libraries are too big for him to keep in his head he will reconsider. One new thing that has made JavaScript and CSS nicer to do was the adding of those languages to IntelliJ’s IDE. I have had enough of groundless claims that real projects can be done in Ruby 10 times faster. I know of a project done late last year which took three times as long to do in Ruby than was estimated for it to be done in Java.

David attacks Java too. I have seen complaints about verbosity which overlooked the IDE generation of same and the resulting readability. Having attended sessions on Ruby and a session given by Guido Van Rossum on Python, a common criticism against both is that there are no really large systems written in them. I am not sure if there never will be. But boring maintainability issues like readability are a factor.

This sort of behaviour turns me off in a big way. I think these guys should be mindful of the vast numbers of us that are still in the undecided camp on Ruby.

So, what will it take to convince me one way or another? Not attacks on my current language of choice, that’s for sure. I need to resolve the following preliminary issue list:

1. No decent IDEs
2. very few libraries. I think there are about 500 gems compared with around 20000 Java libs in open source alone
3. no native threads
4. An active record one: Active Record does not use prepared statements and executes very poorly on a database. Now maybe a language/framework does not always need to be fast, but it should allow for efficient execution on a database, which is often shared infrastructure.
5. Slow? execution speed. I need to do my own measurement on this one but I have it on my radar as a problem.
6. The possibility of developers creating unmaintable code with clever tricks. Not sure on this one either until I have more experience.

If anyone can help out with any of those I am happy to hear from you.

On the positive side, Ruby is open source, follows the Unix way, has been around for a decade and is loved by a lot of people I respect greatly. Most open source responds well to criticism and gets better. Let’s hope thats what happens with Ruby rather than Ruby not getting better but the criticisers being taken out.

As to Java, what I have personally seen in the last year is large scientific C++ applications moving to the Java platform. I was personally involved in a 12 million line one of these. The other is large mainframe COBOL and BASIC systems moving to Java. Along with the growth shown on tiobe.com, I think Java is quite safely in the mainstream of computing. On the Tiobe index Java is ranked number 1 and Ruby number 22.

Anyone for Haskell? Sounds like an interesting language. It is ranked number 70.

Having initially posted this I wondered what Hani over at The Bile Blog was making of all of this. Here it is: http://jroller.com/trackback/fate/Weblog/tss_bringing_out_the_best

Today I released ehcache-1.2 beta 5. Quite a few people have been playing with the new features. I think the whole listener area has been very well road tested now. Ditto with the DiskStore performance redesign. I am also very happy that people are playing with the distributed cache stuff. Fixed a couple of bugs in that area. This release package up fixes to all known issues in the new 1.2 feature set.

What makes me enormously happy is the time and care other developers take to report bugs and patches. If they see a broken window, they know I want to fix it and so they tell me about it. And they sometimes give me the pane of glass too. Great stuff. Release early, release often.

Some guys have created a java cache test tool called cache4j_perfomance_tester.

The results for ehcache-1.1 and ehcache-1.2 follow.

According to their test methodology both versions of ehcache are the fastest for all three scenarios. Compared with oscache, ehcache was 4 times faster for two of the scenarios and twice as fast for one.

I find these results interesting. I had the JCS guy Aaron Smuts complaining about the old performance numbers I had up for JCS. They were quite old so I removed them. I didn’t have the time to do my own analysis but I am happy that someone else has. Ehcache is in good shape.

ehcache-1.1

ehcache-1.2

Greg Luck

The last week or so I have been developing a new version of the http://ehcache.sf.net project web site with Maven 2.0.

Why? The old site featured a couple of toilet roll web pages, the longest of which was 2026 lines. That’s a long toilet roll. With the upcoming release of 1.2 and a lot more features to write about, something had to give. I knew I wanted a nice side nav bar and to provide some extra info about the project over what I had been doing. I thought about doing all the redesign by hand or moving the site to confluence, which I have an open source license for. But I am lazy.

I met the guys from Maven 2.0 in Portland at last year’s OSCON and I knew that Mergere was paying about 8 guys to work on Maven 2.0 full time. So I went to take a look at what they were up to. It looked like there was a lot of stuff you get free out of the box.

A week later and the site is done. I think it is a big improvement over what was there, and I think Maven 2.0 ended up being a pretty good choice to to it. From here on it will be very easy to maintain.

So, what did I think?

The Good

• APT, Maven 2′s simple documentation adopted tag language, is simple with a very easy to learn syntax and high productivity.
• You can call into Ant for stuff that Maven does not do. Nice.
• Tons and tons of great reports and site output that are generated from your pom.xml or with a little plugin setup.
• The #maven channel at irc.codehaus.org. Thanks guys!

The Bad

• APT is limited. No superscripts. Difficult to combine multiple things or it gets confused.
• Maven is hard to get into.
• Very poor documentation. I logged a few bugs on this. Unless the maven guys want to keep getting bugged on IRC they need to write more and better doco.
• Maven 2 has a lot less plugins than Maven 1.

The Ugly

• Doxia barfs on APT when you have a tag mismatch with an error like “missing ‘>’”. Try finding that in a 500 line document with no line number indicated.
• A general lack of useful error messages which pinpoint what is really going on. SCM and Clover plugins are partiularly bad.
• MOJO properties don’t seem to have a standard naming convention. I got caught up with seemingly random variations around the_tag, theTag and thetag.

Where to now? I am not yet building ehcache on Maven. I did restructure the code to follow the Maven directory structure. The Ant build works very well however and I am wary about how much time it will take to get everything working. Maybe version 2.1.

Would I recommend it? If you like the new ehcache site, you can get the same thing for your own project , using ehcache as an example, in no time. But if you do. copy the ehcache pom.xml. Those 424 lines of config were hard won.

Years ago I used to use vi for all of my programming. I also used JEdit for a while. I remember being in a Sun conference about 7 years ago when the speaker asked for a show of hands as to whether the assembed programmers were using text editors or IDEs. About 90% were using text editors. She asked “Why?” The answer some audience members gave was that the Java IDEs were crap. And so they were.

However since then they have come along way. Today the rare individual you encounter who does not use an IDE is a Unix hacker who has been living in a cave. Or a Ruby fanatic. The Ruby guys tend to use TextMate, which is a nice text editor. I have been using it the past few days. Apart from the .conf files it gets its cursor out of sync on, it seems to work well. So why aren’t they using IDEs? I think the answer is the same we gave at that Java seminar 7 years ago. I have tried out about 5 of them now and that is my conclusion. ActiveState’s Komodo is probably the best.

Dave Thomas in his Ruby talk at OSCON dealt with the issue differently; he was openly disparaging of the whole idea of IDEs or any language that was either compiled or verbose enough to require one. His argument was that, in Ruby, you write so little code that things like autocomplete do not matter. And there is no compile to do.

In Java by contrast, I find autocomplete, syntax highlighting, quick documentation lookup and so on highly productive.

Continuing the verbosity theme, over at Loud Thinking David Heinemeier Hansson was reduced to giggles by the following Java code snippet:

UploadedFile uploadedFile = (UploadedFile) fileUpload1.getUploadedFile();

It is certainly far more verbose than the equivalent Ruby code. On the other hand it is a familiar idiom; one which is very easy to parse. It has high readability. What about its writability? Is it really that much more work? I thought I would take a similar example and count the key strokes required to produce it in IntelliJ IDEA. Here is the sample piece of code from ehcache:

CacheEventListener cacheEventListener = (CacheEventListener) iterator.next();

It contains 77 characters, including whitespace characters, starting from the first “C”. Is this really 77 keystrokes? Following is the exact key sequence I used to write the above code:

C E L CTRL-SPACE RET SPACE CTRL-SPACE RET SPACE = SPACE i t CTRL-SPACE RET . CTRL-SPACE RET ; ALT-ENTER RET

That is a total of 21 keystrokes, not 77.

Ok, so it was quick to type. Is the instance variable name silly? “cacheEventListener” is the first suggestion made by IntelliJ, as would “uploadedFile” be. I don’t think it is silly; I think it is readable. That you use the class name indicates to the reader that it is a CacheEventListener with no other notable qualities, thus the simple name.

There are many other code examples that require far less keystrokes to write. IDEs like IntelliJ give automation support to structures like looping and exceptions and many others. Rather than the 4:1 ratio in the above example, these can get closer to 10:1.

I like the idea of having lots of tools on my tool belt. I have had a little time lately and have been working my way through Ruby on Rails. I am pretty slick on vi and find TextMate easy enough. But every character of code is a key stroke I typed into the keyboard. And every little bit of API I had to go and lookup in my browser. So lets not kid ourselves: the Ruby community would be much more productive with a great IDE like IntelliJ IDEA.