Apparently this guy hasn’t heard the news
I read this fascinating post from Paul Murphy, but it makes me wonder…. Hasn’t Paul heard the news, Java has code completion.
Steve loves us, he really loves us
OK, I admit it. I may have been wrong about Apple not caring about us nerds. Steve now says:
We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February
Cool. I’m not so sure this an altruistic move, but then again what is? The free market is good, especially when if forces companies to do the right thing. Welcome back Apple, we love you.
Nerds vs the new Apple
All the nerds I know, which is pretty much everyone, are all pissed-off at Apple due to the much publicized iPhone bricking. Personally I think there is mass confusion here in the geekosphere. When Apple did nothing but sell computers it existed for and was powered by we nerds. Apple was the in-crowd’s alternative to the evil empire. That was then this is now. Now Linux is do-it-yourselfers’ OS, and Mac OS, perish the thought, is becoming main stream. My Dad, not a computer scientist, has even traded in his Windows laptop for a MacBook.
Face it, Apple’s has moved beyond targeting the nerds and is targeting the mass market by creating the best high tech devices the world has ever seen. First it was the iPod then iPhone now iTouch… These things are -not- meant to be hacked they are meant to be the best purpose-built functional appliances obtainable. The best music player, best phone, best media player, and best whatchamacallit on the market for the -average- user. Ironically this means -removing- choice. This means it, whatever -it- is,will not do everything but it will do the thing it does do very well. If you don’t like what it does buy something else. If you want to hack something, buy a mp3 player or phone that runs Linux. Apple isn’t targeting the nerds and we need to get over it and move on.
Java sluggish not slow
Last week Jonathan Schwartz made a now infamous announcement that SUN would change its ticker symbol from SUNW to JAVA. The condemnation was near unanimous and immediate. A common complaint with Johnathan’s equating SUN to Java was that Java is a relic of the past. Here are some excerpts from the replies to his post
In the minds of many people, Java == slow . . .
Java means slow. Painfully slow. And badly written . . .
Synonyms for Java are ‘Big’, ‘Fat’, ‘Bloated’, and ‘Slow’ . .
Java is a slow bloated ancient system . . .
. . .
. . .
. . .
The postings go on but you get the point. I disagree with the characterization of Java as “slow”. Most objective language comparisons and benchmarks show Java to be among the faster languages around. Certainly not a fast as C but much much fast than the currently popular Web 2.0 languages (ruby, python, php, perl,….). It seems the word “slow” is being incorrectly substituted for another word, “sluggish”. In other words it has a lot of inertia, slow to start, but once it gets going it cooks (thanks to the JIT).
With that technicality out of the way, I agree with the general sentiment that Java does have to change to compete in today’s world. It must become more agile, even at the cost of total speed.
The technical hurdles to make Java more nimble pail in comparison to the cultural ones. Can the Java community embrace a new way of programming and updated language specifications required to enter the new age? Some don’t think so. Time will tell.
The Java space vs time trade-off
QT is popular application development framework used most notably in KDE where it is -the- toolkit of choice for programmers. Recently QT has added bindings for Java, Ruby, python, C#(Mono), to go along with its legacy C++ bindings. Richard Dale has performed a comparison of the bindings on the popular colliding mice QGraphicsView example. It results illustrate the typical Java space vs time trade-off
Here are the memory figures from top with the ratio to the C++ value in brackets for the bindings languages:
- C++ virtual: 15.6Mb resident: 7.3Mb shared: 9.9Mb
- QtJambi (java-6-sun-1.6) virtual: 239Mb (15x) resident: 46Mb (6.27x) shared: 20Mb (3.24x)
- QtRuby virtual: 33.2Mb (2.13x) resident: 16Mb (2.18x) shared: 9.9Mb (1.6x)
- Qyoto virtual: 45Mb (2.88x) resident: 17Mb (2.32x) shared: 12Mb (1.94x)
So QtRuby and Qyoto/Mono use about twice the memory of C++, and QtJambi uses twice as much again. Next I divided the ‘real time’ by the ‘user time’ plus ’system time’ figures, and calculated the mill consumption relative to C++:
- QtJambi (java-6-sun-1.6) 1.8 times slower
- QtRuby 4.1 times slower
- Qyoto 5.0 times slower
We haven’t done much performance tuning for the Qyoto bindings yet, and it may be possible to speed them up and beat ruby…….
……
……
I haven’t got a current version of PyQt to try the same test, but I would expect it to be pretty much as fast as QtJambi and consume about the same memory as QtRuby or Qyoto though.