Entering the age of JVM Language Wars?

After the Browser Wars it seems that we are entering an age of the JVM Language Wars. It seems that everybody who has spent a decent amount of time with Java suddenly feels the need to create the "next big language for the JVM", the successor of Java.

The most recent incarnations of this symptom are:

• JetBrains creates Kotlin, a "statically-typed JVM-targeted programming language"
• Red Hat develops Ceylon, a "Java based language, Taking Java to the next level" (Gavins post, wikipedia entry, InfoQ presentation)

I am a bit puzzled at those projects... ok, Java as a language might be outdated and cumbersome nowadays but it is not as if there are no modern alternatives... Groovy, JRuby and Scala come immediately to mind ...

Update: @bertolami asks the interesting questions: Will the JVM benefit or suffer from this? Will the Java community benefit?

I wonder if the language landscape on the JVM will present itself similar as the Java webframeworks landscape today... somehow I doubt this, because Java is mostly routed in The Enterprise(tm) nowadays, and The Enterprise(tm) somehow associates Java with their IT-strategy. Changing that strategy is only done at a glacial pace, therefore adoption of new Java languages will only happen in niches and a lot of those niches are already taken by other modern languages.

Update: A nice post about this: Scala, Kotlin, Ceylon... let's start by being honest

Update 2011-11-13: Just extending the list:

• Mirah, a new way of looking at JVM languages
• Eclipse Xtend, a language made for Java developers

If you like this, follow me on twitter...

Feature Branching vs. Continuous Integration

I posted my thoughts to the topic of Feature Branching vs. Continuous Integration some month ago.

Now here is a very good video interview where Mike Mason and Martin Fowler characterize Feature Branching and the problems that may result from it and where they see that Feature Branching is applicable and where it is not recommended.

And here is an experience report by Sarah Taraporewalla that describes sarcastically the problems you get into with Feature Branching.

The conclusion I take away from that:
Feature Branching is good for loosely coupled collaboration typically found in open source projects. Feature Branching is not recommended for dedicated teams with tight collaboration, which is the type of collaboration you are striving for in a typical Scrum project.

Update 2011-08-14:

Interesting points from the above interview are:

• The pain from merging increases exponentially with the age of your branch.
• In practice feature branches discourages refactoring: You are not improving the core codebase when working on a new feature, because you are afraid of merging those core refactorings back later. You rather build your feature around the existing core, as it is, living with its shortcomings...
• Alternatives are feature toggles and branch by abstraction (archtiectural branching)
• Using feature branches for organizational control is a sign of a dysfuntional environment. If you don't trust your team to commit frequently, then you have a problem that can't be solved with a version control system.

Related is the article by Martin Fowler describing Semantic Conflicts. The main conclusion there is that tools only can support in merging textual conflicts but they can never solve semantic conflicts.

If you like this, follow me on twitter...

Quotes of the Week: JavaScript

A very large group of developers still thinks of JavaScript as a joke.

- davy brion

 

JavaScript is Assembly Language for the Web.

- Scott Hanselman

JavaScript is the ugly duckling among programming languages. It takes time to embrace it and discover its beauty.

- Slo

Javascript is fast becoming a serious contender to Ruby and JVM languages.

- aslak hellesoy

After almost a decade of the ruby community being the web innovation lead, it really looks like the javascript community is taking over.

- @bertolami

 

If you like this, follow me on twitter ...

Kindle = Free Internet Access

Recently I bought a Kindle 3G. I am living in Switzerland and I bought it from Amazon.com.

Amazon offers free internet access with this device over the cellular network. Everywhere, globally. The goal is that you can access the Kindle shop and buy books everywhere on the world.

The Kindle has also a built in web browser that you can use to access the internet.
Now the question is: Can you browse the internet for free everywhere on the world with your Kindle?
This is not completely clear from Amazons product description and there are different contradicting reports floating on the internet. To help to clarify the topic here my experience:

Last month I was in Norway, Singapore, Bali and Lombok and everywhere I could access the internet for free without a problem. It was not always a 3G connection, it worked also over EDGE and GPRS.

Of course the browser experience on the Kindle is not comparable with other mobile devices: It is quite slow and cursor navigation has to be done with the cursor buttons. Also typing on the kindle keyboard is quite cumbersome.

Nevertheless I think this is an invaluable feature of the Kindle!

I was primary using Gmail, Google Reader and Twitter. Through their mobile interfaces those sites are definitely usable on the Kindle and this was a comfortable (and cheap) way to stay at least minimally connected throughout my vacation.

If you like this, follow me on twitter...