Mike Bowler

I had to go back and check the date when reading this article. For a moment, I thought I'd found an old article from the nineties. This sounds just like the anti-Java tirade that we used to hear from the C/C++ people. Only now it's Java people getting upset that they're now the ones being displaced.

I was also amazed that in 2008, people still feel that they have to justify the speed of Java. Yes, it's fast enough.

Two quotes really jumped out at me.

Java also enjoys a 10-times performance advantage over interpreted scripting languages like JavaScript, Perl and Python, he said. "The scripting languages aren't JIT-ted yet," he said.

There are two different things called Java that are being blended together and if we're going to make an apples-to-apples comparison, we have to split them apart. We have the Java language and we have the Java Virtual Machine (JVM). They are very different things and yet we tend to pretend they're the same.

In this case, we're comparing the JVM to the runtimes underneath JavaScript, Perl and Python. This is not a language comparison - it's a virtual machine comparison. Since JavaScript and Python (although not Perl) can all run on the JVM, it's a foolish comparison. Does the JVM use a JIT when it's running Java and then turn it off when running Python code? Clearly not.

All the languages mentioned here can run on multiple different virtual machines. Some of those virtual machines have JITs and some don't. The quote above doesn't seem to make any sense in this context.

Scripting languages are ideal for smaller programs but Java is the choice for larger programs, he said. "As your program grows in size, the lack of strong typing basically kills your ability to handle a very large program and so you don't find the million-line Perl program," he said. One-million-line Java programs are plentiful, Click said.

Didn't we give up on the idea of measuring by lines of code a couple of decades ago? So if it takes a million lines of code to write a given application in Java and it only takes 100,000 lines to write that same application in Ruby or Python or Perl, does it somehow magically make the Java version better because there are more lines?

One million lines of Perl (to use his example) would be a truly massive application. It would have significantly more functionality than the equivalent Java application simply because Perl code is very compact compared to Java code.

Now, I wouldn't choose Perl to create a huge application but that decision has nothing to do with the fact that it's dynamically typed. I would have no hesitation recommending Ruby or Smalltalk for something huge and they're both dynamically typed.

Link from James Robertson

In an effort to simplify how I explain Agile to people, I've tried to place the various practices into a small number of groupings. I've done a number of versions of this diagram over the years that have been posted here and have never been entirely happy with the results. I presented this version to XP Toronto last night to get some feedback from others in the Agile community and we had some good discussion.

The diagram here is the same one I presented last night and doesn't reflect any of the feedback I got.



This started from the idea that successful projects all have certain characteristics. They may not follow the same practices but they have certain things in common. The groupings of communication, motivation, planning and accuracy seem to be things that all successful projects share. Unsuccessful projects are lacking in one of more of these areas.

There's no single way to improve in a given area - many different practices could get you to the same goal and that's reflected in the sample practices in each area.

Note that the practices listed here are not intended to be exhaustive - I'm sure there are many more than should be here.

One comment from last night was that the label "alignment" might be better than "motivation".

Last night I spoke on rails dynamic finders at the TSOT Rails Project Night. The slides from that talk are here.

Colorado Software Summit has posted their annual call for papers. This is a phenomenal conference that I can't recommend highly enough. I've spoken there quite a few years and have attended many more.

I'll be speaking again at the TSOT Ruby on Rails Project Night. I had a lot of fun at the last one so I offered to speak again

Dynamic finders are one of those things that seem magical to people who are used to statically bound languages like Java or C. In this talk, I'm going to demystify some of this magic so that you can see how one of the more interesting methods in the Rails code actually works.

If you use Facebook, you can RSVP on the event page.