I don't necessarily think all the alternatives to XML suck, but the mindless, knee-jerk rejection of XML because it contains a small amount of additional syntax certainly does. Like all tools, it's a question of how you use it. Please think twice before subjecting yourself, your fellow programmers, and your users to more fragile, ASCII-only, ad hoc syntaxes.

This is an occasion where I agree that both alternatives (XML and more light-weight approaches) are worth being considered.

Implementing a blog is writing a tiny handler that shoves stuff into the database and out of it, and then spending ridiculous amounts of time filtering comments for spam. Which is one of the really difficult things to do on the internet - validating users as real users, without being inaccessible.

Haben Sie es sich mit “Ihrer” Haus-und-Hof-Programmiersprache gemütlich gemacht? Vielleicht ist die Zeit gekommen, sich neu und breiter zu orientieren – glaubt man zumindest dem Tenor zahlreicher Blog-Postings, stehen wir vor der Zeit der “polyglotten Programmierer”.

Meine Kolumne im aktuellen JavaSPEKTRUM ist online.

Down in the big Java One trade-show, there was a “SOA village”, where all the vendors of SOAP/WSDL/WS-* technology were talking about Governance and Reliability and Integration and so on. “Village” is the word all right; a village left behind by history. It was kind of sad, actually. REST may not have won, but SOA-as-in-WSDL is in the middle of losing.

My second take-away, watching the presentations’ sample code: there was way too much of it. When you’ve been living in Ruby-land for a while, Java’s verbosity starts to hurt your eyes. In particular those constructors spilling across two or three lines, festooned with hideously-nested generics cruft; that’s just wrong.

The so far certainly RESTful Web of Linking Open Data provides an outstanding real world pattern for RESTful SOA - as long as there is only read access. Imagine enterprises can easily publish their data internally in the same way, and so cross-enterprise organizations could do (assumed that security requirements are as well satisfied). When it comes to UPDATE in Linking Open Data, this most probably will be realized using SPARQL Update. While this is a language not an application protocol, it is based on assumptions on such a protocol, e.g. by addressing the Graph Store and not the Graph. So it might by worthy to "avoid making the same mistakes as Web services".

More on InfoQ.

Every language has a complexity budget. Java blew through it with generics in Java 5. Now, seriously, take another look at this:

@NotEmpty List<@NonNull String> strings = new ArrayList<@NonNull String>();

Does that even look like Java? That complexity budget is just a dim smudge in our rear-view mirror here. We’re so busy keeping the compiler happy here, we’ll completely forget what our actual project it.

All this is coming at exactly the worst possible time for Java the Language. The community is really, really excited about dynamic languages now. Instead of those contortions, we could just say:

var strings = ["one", "two"];

Now seriously, which one would you rather write? True, the dynamic version doesn’t let me enlist the compiler’s aid for enforcement. True, I do need many more unit tests with the dynamic code. Still, I’d prefer that “low ceremony” approach to the mouthful of formalism above.

So, getting back to that mainstream Java developer… it looks like there are only two choices: more dynamic or more static. More formal and strict, or more loosey-goosey and terse. JSR 308 will absolutely accelerate this polarization.

I have a similar feeling with Scala — I have no doubt it’s now probably 50 times faster than JRuby, and will probably continue to be at least an order of magnitude faster for the foreseeable future; its type system will probably catch errors I never knew I was able of making — but I just can’t see myself having fun programming in it.

More important, the MySQL deal has demonstrated our commitment to the open source community and gained us huge amounts of good will from people who don't like to pay for things, which for a company in our dire situation is absolutely invaluable.

Brilliant.

• Legacy. People insist on being able to protect their existing investments, in terms of hardware, software, and skills. Being able to run Ruby as just another language on the JVM, essentially including the option to simply deliver byte code without ever talking about a change in the programming language, is perceived as a key requirement.
• Performance and Scalability. Scaling with processes instead of threads; having to manage a cluster of long-running processes; being forced to rely on Apache's features for load-balancing: there was general agreement that this is a lot worse than being able to rely on the existing Java infrastructure.

I don't necessarily agree with these criticisms. For one, I believe systems should be coupled much more loosely than by running them on the same VM and integrating them on the language level. I also think that in many cases, scaling with processes in a shared-nothing architecture scales perfectly well, and it also doesn't require any sophisticated infrastructure beyond a boilerplate Unix platform. I expect a lot of innovation to occur within the Ruby VM space, specifically around Rubinius. And lastly, I know from personal experience that in many cases the JVM and a fat app server sitting on top of it are used to serve a simple JSP/servlet application to a few dozen users, i.e. used in a scenario where Perl CGI would suffice.

But while I don't find these arguments convincing enough for many use cases, it's very hard to find arguments against running Ruby on the JVM. JRuby has reached a level of maturity that makes it a great choice even if you don't care about Java at all. As it runs Rails, I'm reasonably confident it will run basically any Ruby library I could care about -- except, of course, those that rely on a native library to deliver their features. But in this case, the vast ecosystem of Java libraries should outweigh this disadvantage easily.

So assuming you can deploy your Ruby application to a JVM platform without hassle, why wouldn't you?

Eclipse and similar environments want to be self-hosting, but they're not, because Java is not self-hosting. In spite of Java's smattering of dynamic facilities, Java remains as fundamentally incapable of self-hosting as C++. Self-hosting only works if the code can "fold" on itself and become more powerful while making itself smaller and cleaner. I'm not really talking about macros here, even though that's probably the first thing you thought of. I'm thinking more along the lines of implementing JITs and supercompilers in the hosted runtime, rather than in the C++ or Java "hardware" substrate, which is where everyone puts them today.

I suspect (without proof) that in self-hosted environments, you can eventually cross a threshold where your performance gains from features implemented in the hosted environment outpace the gains from features in the substrate, because of this self-reinforcing effect: if code can make itself faster and smarter, then it will be faster and smarter at making itself faster and smarter. In C++ and Java, making this jump to the self-reinforcing level is essentially intractable because, ironically, they have so many features (or feature omissions) for the sake of performance that they get in their own way.

To be sure, Emacs, the current crop of popular scripting languages, and other modestly self-hosting environments are all pretty far from achieving self-reinforcing performance. But Emacs has achieved it for productivity – at least, for the relatively small percentage of Emacs users who learn enough elisp to take advantage of it. There are just enough of us doing it to generate a steady supply of new elisp hackers, and the general-purpose artifacts we produce are usually enough to keep the current crop of casual users happy.

(Personally, I've abandoned the Emacs religion and switched to TextMate. But I'm among the casual users who will be happy that they can switch back the day I can no longer use a Mac ...)

In addition, it is not very often that you can be part of a team that aspires to radically change the dynamics of building a new language, to the extent that a developer can write their own model-driven language in a straightforward way while getting all the language services (Intellisense, colorization, etc.) for “free”.

Sounds a lot like Xtext to me …

Any hint, preferably before tomorrow 10am CET, would be greatly appreciated :-)