Maybe not the end of Scala

A little more analysis needs to go into the last post. I perfectly understand there are people out there who like Scala - I don't understand it (why they like it), but they do and good for them. But I think the Scala world is split in two, those who are simply searching for a better Java that is statically typed, and those who actually think Scala itself is a sterling idea.

I think those who are looking for a better Java that is statically typed now have competition in their choices. A language very much like Java, interoperates almost perfectly with Java, can be eased into simply with Java and has a dynamic option if you want it, vs something that is really quite different. I just think Groovy++ will slow down Scala's adoption. People may examine both and decide Scala, I suppose that could happen.

Will Groovy++ spell the end of Scala?

As much as we all "try to be friends", the successor to Java (and there clearly needs to be one) "battle" between Groovy, Scala and Clojure will IMHO, only heat up this year with the introduction of Groovy++. Groovy ++ adds to Groovy static typing with very little in terms of trade off (meta programming) - allowing mixing of static and dynamic code in the same application. Groovy++ apps are the same speed as Java - sometimes faster, sometimes slower depending on how the problem is expressed. IMHO, Groovy++ is really Java ++ and is thus a natural and easy path for the millions of Java programmers. Groovy not being controlled by the boffins at Snoracle hopefully means innovation in the platform can happen much faster and address real developer needs.

I personally don't see Clojure as a competitor for Groovy, Clojure seems to attract people interested in expressing primarily functional problems and can mix with other JVM languages easily. There is a place for it - I'm pretty sure it isn't everywhere (even though I am sure you can do everything in it) and it does my head in. I like Clojure, don't get me wrong, but I like it in the same way I like a regular trip to the dentist.

Scala on the other hand really decides to do things differently, and as I have said in the Illegal Argument podcast, I don't think its mixing of imperative and functional styles along with its weird, clearly academically experimental syntax will win out. Scala is an academic experiment built and designed by a very clever person. But... It is too different, it doesn't seamlessly interoperate with Java and it lends itself to unreadable code far too often. Clearly some people like it, but I can't for the life of me understand why they do. For me, it doesn't help that the primary Scala book written by Martin just reeks of language arrogance as well.

The argument i hear most often is "well, there isn't really a contender in Java.next for a statically typed language". Well, now there is - well almost - later in the year because of issues around open sourcing code.

Will Groovy++ spell the end of the use-case for Scala? Someone can take the Java spec and pretty much code in Java directly in Groovy++ - you can't do that in Scala. They can then be slowly introduced to type interference and all kinds of other programming concepts. Or they can take it the other way as a dynamic language and be introduced to the benefits of static typing. I certainly think it has a greater chance of supplanting Java than Scala does anyway.

iPhone delusions

Its sad to see Josh Marinacchi go from Snoracle, especially for what reasons that I think of are simply fallacious.

If you haven't read it already, go read his Sun blog.

The argument I think he is making is that 90% of the people out there are essentially stupid and don't care about the restrictions iPhone/iPodTouch/iPodTouch300% (i.e. iPad) put on them. I don't see that demographic. I see the 10% of people who have iPhones as being that special kind of dementia known as Apple-fanboys/girls (you know who you are) or people who think this screen touchy thing is cool and Apple did a sufficiently better job than . That there are 100,000 Applications out there only helps because 80% of them are crap and all but the last 1% are games. Those same apps done with a decent phone platform (like Android, which may suffer from being too open in its App store) can really be quite awesome - as people with jailbroken iPhones attest.

Those who break their phones do so only because they know there is something better. And I think this is where the average iPhone user (not the fan-boys, we know thats an incurable disease) sits, once they know there is something better (and with the latest update for multi-touch in the US for the Nexus One, we know the hardware is better and the software is now at least as good) they will either (a) move when their term comes up to the new cool thing (and all the predictions show Android will be the Smart phone of choice, after RIM with iPhone a 3rd place with its dedicated... fanboy offering) or (b) Apple will now have to catch up.

Yes, I said catch-up. Apple is now behind, those things that Josh says apparently don't matter - replaceable batteries, better hardware, multi-tasking software are all very much visible to the "stupid" people and they make a difference. Everyone else is behind in "cool" but Apple always does cool better. I'm not sure what the iPad is, I'm sure it will sell but I'm not sure I'll have any respect for anyone who actually buys one.

Apple could change a lot of its restrictions - there is nothing inherint in the platform I believe that would stop it from competing with Android. The one thing that Apple really has under its belt is iTunes - the music library is available to people all over the world, not just the US like Amazon's one is. Get that sorted out Amazon.

I buy Mac OS for one reason - I want a good UI (which Windows 7 has IMHO) and a good underlying UNIX style OS (Windows doesn't have). Don't talk to me about Linux - that will never be a desktop OS for anyone other than the truly marginalized.

So if I can conclude - my essential reason why I believe Josh is wrong is simply that the only open phone platform from the ground up, Android is the only one really causing the iPhone serious dents and causing Steve Jobs to get his knickers in a twist. Apple is now behind in software and hardware innovation and with so many phone vendors getting on board, providing access to so many niche markets to address every different kind of phone user, an open and open source platform simply cannot be defeated. IMHO of course. Apple is just digging itself into a worse and worse hole, and the iPad is just a crowning example of the lack of innovation in the last 12 months.

Its just a pity Josh jumped from one dying company to another. I have enjoyed what you have done for JavaFX, I just hope you can make a difference to Palm.

Open JDK has a lot to answer for

I have never been so disgusted with a podcast as when listening to the excuses coming from Alex and Joe in Episode 279 of the Java Posse Podcast. If there was ever a clear message from Sun that the value of Java code written and maintained in the future is less than the value of Java code today, this was it.

Alex and Joe seem to believe that since the Open JDK now exists, Sun can sit back and pick and choose from implementations that other people do instead of investing in its flagship product (the one its stock ticker is named after, how ironic). Not only this, but they seem to believe that they can do so and be completely fickle about it. Dick's comment about the JCP I think is superfluous, there is no JCP process for JDK 7 so they are putting it in what they will.

Whether Alex/Joe's opinion are a reflection of Sun's official policy I don't know, but I hope that on purchase Oracle dump this attitude (and anyone who holds it) and puts new life into the language. This complacency is simply not acceptable, you innovate or you become irrelevant. I know that the team have to solve modularity in JDK 7 and that it is a big problem to solve, but the messages that Alex and Joe are sending are completely wrong and they deserve a severe caning from PR. The implication is that while Sun spends its resources on JavaFX, its core language, Java languishes. Borland did this with Delphi and JBuilder and look where it got them! (Borland is now owned by a COBOL company, MicroFocus, Delphi is now owned by a database company, Embarcadero - oooooh now *that* is spooky).

IMHO Scala is clearly an academic dumping ground of ideas and the static camp are using it because they have nothing else to express their needs in. And please don't mention JavaFX. Sun clearly needs new and strong leadership in this team to bring Java forward.

After 24 hours I am no longer angry, just extremely disappointed that this situation has been allowed to develop. If ever there was a reason to fork the open jdk, this is it. Larry, its up to you now.

mor.ph and deployment fun

So I use http://mor.ph for deployment of my Grails applications. The development account was great, fantastic to deploy to and try out your application. I didn't realize this transformed (database and all) into your deployed site otherwise I would have held it in dev mode until the customer had set up all their data, but then I wouldn't have discovered some other problems... Like that since you get two app servers, and it load balances, it serializes session state (how often, I don't know). But as I use the Acegi plugin for Grails, it generally (definately in my case) creates a User object - which isn't serialized..... Which means I have been getting persistence errors all through my logs.

Of course, I thought I had solved it with just User and Role, but I forgot I embedded an Address in there as well, and it would need the treatment. Wouldn't it be great if these sites gave you a bundle you could run in a VM on your own machine to mimic their deployment so you could fix your issues before you swap from single server, single db to the full cluster of mor.ph? Oh well, it is a great service in any case!

groovy tip #3534

Don't do integer arithmetic in gstrings.

int time = 1730
println "${time/100}"

I know Mars Edit is going to screw up that code block. Anyway, although time is an int, it gets converted to a BigDecimal in the gstring, and you get a 17.3 instead of the expected 17.

And last but not least, our first Illegal Argument podcast has gone out. It hasn't shown up on iTunes yet, hopefully that will be soon.

Site Mesh and pageProperty in Grails

So Grails 1.1 comes with SiteMesh 2.4 and uses the FastPageParser. If you go have a look in your web-app/WEB-INF/sitemesh.xml file you will see the following:

<sitemesh>
    <page-parsers>
        <parser content-type="text/html" class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        <parser content-type="text/html;charset=ISO-8859-1"             class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        <parser content-type="text/html;charset=UTF-8"            class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        </page-parsers>
    <decorator-mappers>
        <mapper class="org.codehaus.groovy.grails.web.sitemesh.GrailsLayoutDecoratorMapper" />
    </decorator-mappers>
</sitemesh>

How many of you Grails developers have ever had to look in there? Cool isn't it that Grails shields you from this stuff - one of the many, many reasons why I love this framework.

Unfortunately, FastPageParser is actually deprecated and has bugs when using the <content tag="x"> constructs - HTML comments are output as raw text and <script> tags loose their <. Migrating to Site Mesh 2.4.1 (or .2 now with the GAE) fixes the <script> problem, but not the HTML problem.The partial solution (as emailed to me by one James) is to replace it with the HTTPPageParser - this is faster (by about twice) and is the recommended replacement for FastPageParser.

The only problem is that it has an outstanding bug - if you include an "<" anywhere in an HTML element (e.g. in the value) then the rendering goes haywire. It is a known fault in Site Mesh but no-one bothered to create a test case for Joe or investigate precisely where the problem is. Content tags are pretty important to anyone laying out their content in any kind of sophisticated manner (as is extractProperty, which isn't actually surfaced in Grails for some weird reason), so I gave Joe the test case and narrowed it down to the Lex rules. Unfortunately, I am not a Lex guru, so I had to leave it there.

I'll be putting up a screen cast of this stuff at some point in the near future. I'll link when its available.