TIOBE Programming Community index

The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the world-wide availability of skilled engineers, courses and third party vendors. The popular search engines Google, MSN, and Yahoo! are used to calculate the ratings.

http://www.tiobe.com/tpci.htm via Java Posse

Socrates on SOAP

Two stories on web standards in imaginary dialog form.

• On SOAP: The S stands for Simple by Pete Lacey (via Blue Sky On Mars). Truly brilliant.
  
• The REST Dialogues by Duncan Cragg

Our industry moves from one stupid hype to the next. OOP, CASE, CORBA, ODBMS, Applets, push media (anyone remember "push media"?), VRML, Agents, JINI, Enterprise JavaBeans, Extreme Programming, Grid Computing, SOA, "Enterprise Service Bus".

We never learn. We're too afraid that we miss out on the Next Big Thing and our knowledge becomes obsolete. So we follow the hype. Even seemingly smart people fall victim to herd instinct. Billion dollar businesses are built on brain-dead technologies that look totally embarrassing in retrospect *cough* EJB 1-2 *cough*.

It's funny how little we learn from all this. We still believe the snake oil salesmen and are looking for the silver bullet. Heck, we're selling snake oil and silver bullets ourselves. We travel to the snake oil conferences, read and publish silver bullet books.

I think the problem is that the industry is too young and doesn't know its own history, so it can't learn from its past mistakes. Only the old people do, but no one listens to them any more. :)

The 30 Days IDE Swap Experiment (NetBeans / Eclipse)

I just found this interesting experiment in the JavaTools Community Newsletter. Developers are asked to switch IDE's (NetBeans/Eclipse) for 30 days. It's interesting to see what they said in the Q/A section (the rest I skipped).

To me the take away message is that when I need to do Swing / JSF work it's going to be worth looking into NetBeans.

For me, the evolution of my Java development environment of choice over the years was: vim -> XEmacs -> NetBeans (for Swing) -> Eclipse.

What I like most about Eclipse are the refactorings and the "quickfixes" (suggestions for fixing the code) and the cool code navigation features. Another big part of the Eclipse experience is that I can just start typing code without thinking about details, such as imports, field or superclass declarations, keep hitting Ctrl-1 and the IDE does all the busywork. Oh yeah, and the integrated JUnit support is also very nice.

Recently I had the misfortune of working on a C++ project in Visual Studio for a while and the pain was almost unbearable every time I had to go through a save / compile / link cycle to catch silly mistakes. Things that are instant in Eclipse took minutes.

IronPython and Jython

Right now, I don't do any kind of .NET development at all, but to be honest I got envious of IronPython after seeing this demo screencast. IronPython is the implementation of Python on top of .NET.

The somewhat sad story here is that Jim Hugunin, its author first created Jython on top of the JVM. It was pretty impressive back then, I remember writing applets in it many, many years ago. (1998 I think?)

Jim later created IronPython and got hired by Microsoft, where he currently works. Smart guy, it's a shame that we lost him to the dark side. :)

Anyway, back to the demo. The things I liked:

• The integration with Visual Studio looks great. I loved the example where your Python code calls a C# function and the debugger can show the mixed stack trace for both languages.
• The speed is impressive. Seems to be on par with CPython, depending on the scenario. Jython doesn't even come close.
• A minor, but nifty thing is that he has tab completition for every class and function in the .NET framework.

While IronPython is under heavy development, Jython seems to be almost abandoned. A few days ago I needed to do some log analysis as part of our all-Java build system and I wanted to use Jython to implement it. It was a disappointment though. It was slooow and the last release was more than a year ago, so it is not up to speed with the latest Python features at all. Shame really. It could be a great Groovy contender.

But here's hoping that Sun's hiring two JRuby developers, IronPython's progress and the support for dynamic languages in Java 6 will somehow help revive interest in Jython.

Update: the JRuby developers working for Sun even offered their help to Jython. Nice.

Rails / Django comparison

Found this on the Django mailing list. A nice Rails vs Django comparison.

I think there is one thing that both Rails and Django have over TurboGears: their main maintainers all use them to create web applications full-time, on a daily basis. I'm not sure whether this is true at all for TurboGears. But I'm still optimistic. The book is coming out real soon now and there is an ongoing effort to clean up the docs. The TurboGears users mailing list has 2300 subscribers vs. Django's 3300. A couple of month ago they were about the same. Hmm...

OpenJDK: Java has been open sourced

A couple of years late, but it's finally here*.

* Well, only javac and the HotSpot virtual machine for now, the rest is hopefully coming soon.

I wonder what the patent situation for the full Java stack really is and if it is any less alarming and confusing then with .NET and Mono.

• InfoQ: Sun open sources Java SE, ME, and Glassfish under GPLv2
• eWeek: Sun Pours Out Java Cup

Django Book preview: a nicely done comment interface

I'm a card-carrying TurboGears fan but I also keep an eye on the Django framework. You can think of both as Python's response to Ruby on Rails.

The Django team released a public preview of the upcoming Django book recently and I got to say, that the comment interface is so nicely done (in Django of course), that I have an urge to stay there and keep commenting. :)

Extra points for releasing the book under a free license (GFDL). Many open source projects died or withered away slowly due to the lack of good documentation. It's good to see the bar being raised in this regard.

Update: It seems that they use Jack Slotum's way cool YAHOO.ext package. Ajaxian entry.

PyJamas: a Python GWT clone

Google Web Toolkit is an interesting idea: let's write all our web site logic in one programming language instead of 2. You write all your code in Java and the framework's black voodoo custom compiler generates client side JavaScript for you, which in theory you'll never have to see and more importantly never have to debug. An analysis of GWT deserves its own post but right now I'd actually like to talk its Python clone: PyJamas.

You can check out the web demo here: PyJamas KitchenSink.

I admit that I haven't yet had the time to play much with PyJamas, but I have a few theoretical reservations.

I don't think its hard to see why GWT has potential. JavaScript does have a somewhat deserved bad reputation. I learned to hate it back in 1998-2000 when I was a full time web developer working on sites that had to support all major browsers and lost a significant amount of hair while struggling with browser incompatibilities. Yes, times have changed and JavaScript/EcmaScript has come a long way, but it is still a pain in the neck when it comes to development and especially debugging. And as we all know, developers spend most of their time debugging.

Here's where Java comes in. It's strongly and statically typed, so the compiler can check all kinds of stupid mistakes. I notice how annoying it is when I switch to a dynamic language from Java that I don't find out about these until I actually run the code:

• wrong type or number of arguments when calling a method
• calling a non-existing method
• referring to a non-existing class
• missing imports
• etc.

All these can be due to typos, copy & paste errors or simple lack of caffeine. :) However when I'm developing in Eclipse the IDE -- actually it's embedded compiler -- catches them instantaneously. I don't have to fire up the server process and invoke it in a browser window. It all happens when I'm still typing the code. One has to admit that this saves a lot of time.

Since dynamic languages don't have the luxury of the compiler catching these simple problems, there is a much stronger motivation to write an extensive unit test harness, so that these basic errors don't eat up too much of the developer's interactive debugging time. Having a test harness is a good thing, but having to write tests for trivial stuff that the compiler could check is, well unproductive.

Now its a matter of debate exactly how much time is saved or wasted by declaring your types and relying on the compiler to do these checks or not declaring them and creating a test harness and relying on shorter turnaround times instead.

Going back to PyJamas, I believe the problem is that Python and JavaScript are not different enough to have a significant productivity gain when you're writing and debugging Python code vs. JavaScript. All the silly mistakes will have to be caught at runtime.

I'm still looking forward to trying it out though since there is a good chance that I'm completely missing the point. :)