Vikram Goyal's Blog

October 2005 Archives

Making it easy for everybody

Yes, I am confused about which way to go with Java.

I just read this article .

On one hand, the keepers of the Java flame are making the language harder and harder to understand and use (Generics anyone?). On the other, Bruce wants it so simplified that he wants it to read like spoken English ("Ruby may not be to your liking, but it's a pretty clean language, and it's much closer to English than Java."). Like English?

No hablo inglés

Yes, for those who don't understand Spanish (neither do I) the sentence above reads "I don't speak English". So is there a Ruby in Spanish? It gives "programming languages" a whole new meaning. :)

What are we doing? When a programming language matures, and Java has matured, it provides cannon fodder for people to take it in new directions. Some want it to attain a level of maturity that will only make sense to die hard fanatics, while some want to make it as simple as chips. I ferverently hope that I will never have to take sides and be able to maintain a sensible level, because I have a strong dislike for both directions in which Java is being pulled right now.

Analyzing mobile tools for Java proposal from Nokia

Nokia has released a proposal for creating a new project in Eclipse for mobile phone development tools. This move comes after Nokia entered in a partnership with Eclipse that I had talked about earlier.

While this is great news for the market, because it brings in much needed competition, I also think that the proposal is a catchup from both Eclipse and Nokia to the excellent work done by Netbeans and Sun with their Mobility Pack.

Two of the core features are a direct response to the features in the Mobility Pack, namely, UI design tools and application creation wizards. The UI design tool description is starkly similar to the Visual Mobile Designer in Netbeans.

Even the rest of the core features are present in Netbeans in some form or another: Debugging, Generic and Customisable build processes, Device and emulator framework, Obfuscation and Signing.

If you do a feature by feature comparison, this catchup will be evident: Here is the Eclipse + Nokia proposal and here is the feature list in Nokia Mobility pack 4.1 (I haven't looked at the 5.0 beta yet).

The only interesting and unique feature that I found in the Nokia proposal comes in the debugging environment:

"The goal of this item is to enhance the current Debugging environment so that it is possible to use mobile runtimes, either emulator or a real device. This task extends to launching the JVM and applications(s) on the local emulator or on the device itself, and allowing the developer to attach to that application under test"

Real device? It will allow you to debug on a real device from within the IDE? Now that would be cool. Can you do that with Netbeans?

Off the XP bandwagon

For some time now I went on the Agile programming bandwagon convinced that it was the next best thing since sliced bread. After a sustained year of practicing it, I am off the wagon. It is annoying, superficial and doesn't necessarily produce better results than traditional programming.

My problems with Agile programming.

-- Without a design up front, you are shooting in the dark hoping that what you are doing now will retrofit the final solution. This doesn't work for me. I want to analyze a problem domain to death before I commit any time to it. Traditional programming methods don't preclude the idea of a prototype to test your designs and neither do they disallow changes.

-- The last thing that I want is for another developer sitting with me and criticizing my code, while I am writing the code. And no, I don't want to do the same to him. It leads to friction, waste of time (two developers working on the same task?), hassle and fuss over finding two developers who will get along with each other and so on. The worst possible idea.

-- Continuous small builds is a great idea. But continuous small builds lead to a nightmare in code management and dependencies. What would have worked yesterday wouldn't work today because somebody else refactored something that has broken the current build cycle. On the other hand if everybody was programming against a well set design there would be less (I say 'less' not 'no') integration issues.

-- Project requirements are always in a flux. This is the central tenet of XP and I find this always-in-the-dark kind of coding irritating.

While your mileage may wary, I am pretty sure that XP is not working for me.

This work is licensed under a Creative Commons License.