afongen

Bill Higgins wrote something that resonates with me:

We began bootstrapping the Admin Web UI in September and I thought we’d made good progress in such a short amount of time. Erich didn’t seem so impressed with what he saw. I was a bit frustrated by this because I thought Erich was being unreasonable – we’d made good progress for the short amount of time we’d been working on it. But after a few more minutes of chatting, I realized that there was simply a mismatch in what we were evaluating. I was evaluating the state of the Admin Web UI vs. the resources (time and people) we’d had to work on it; Erich was evaluating the state of the Admin Web UI vs. his vision of what an awesome Admin Web UI should look like.

I can relate. To Erich Gamma more than Bill.

At work I am sharply critical of what we do. For every app we work on, I have in mind something far better than what we end up releasing. I want us to do an amazing job and naively believe we can.

After a recent user acceptance test of an application we’re working on, I was dismayed by how fragile the app felt. It just isn’t as good as I know it can be. In contrast, the development supervisor was thrilled because, like Bill Higgins, he was evaluating the state of the app versus resources available — and mostly because it was indeed better than it had been 6 weeks earlier.

Bill’s insight is a good one, to recognize the need to think in terms of both “current vs. previous” and “current vs. ideal.” I spend most of my time worrying about “current vs. ideal,” (worse: my ideal, which is a damn brutal standard). A healthy dose of celebrating progress would good for me. Without a good, hard look at a just-completed iteration, I don’t get that sense of progress so am likely to be drawn into a morass of despair. Likewise, the less despondent among my team could do well to get a sense of where we sit in relation to where we need to be, to help inspire and keep the work interesting.

It’s important to take time as a team (and individually!) to reflect on what you’ve done. Not only is it an obvious opportunity to learn from successes and failures, it can be help keep up morale. But as time pressures loom, it’s easy to let that time slip. Don’t.

No, really. Please, please, pretty please with sugar on top.

I frequently run into problems that developers either can’t figure out or had no idea existed, problems that stem from fundamentally not understanding HTTP.

For example, every few weeks I find myself evangelizing the Post-Redirect-Get pattern. Simplified, it goes like this:

1. User submits form with POST (“buy this stuff!”).
2. Server processes form, sends redirect to the browser to go to the results page.
3. Browser requests results page with GET.
4. Server sends results page.

One trick in doing this is that if you want to display a message about the transaction in step 2 on the page in step 3 (“you bought the stuff!”), you need to temporarily stuff that message into session then remove it when you’re done. Rails makes this easy by introducing the Flash, but it’s becoming more common in other frameworks, too.

Simple enough, and it solves all sorts of problems that I won’t get into now. But I still run into conceptual difficulties:

• Maybe a developer thinks that the browser works directly with Java objects (or PHP, or C#…) and can just manipulate and share these with the server somehow in stateful way. Nope. HTTP is stateless, and your HTML form is just that: HTML.
• It could be that a developer believes that the message can be sent back to the browser in the response in step 2 and be somehow available after the browser gets the HTML page in step 4. Um, no. Not the way you’re thinking.

The nitpicky and clever among you will point out that with trickery and by misunderstanding or misconstruing what I’m saying, it’s possible to do those things. For instance, you could use Ajax and DWR to communicate “directly” with Java objects from browser-based JavaScript. True… but not the point. It’s still not like the browser is a Java client communicating over RMI. Nothing like it. There’s a reason I put “directly” in quotes.

But how about that second example? You could stuff a message in a cookie in the response, and re-use that cookie in the results page. Right? Well, yes. Very good of you to notice.

Dreaming up these workarounds implies that you understand HTTP at least well enough to know its limitations and its mechanics. I’m not talking about you, I’m talking about people who just do not conceptually understand an HTTP transaction. And it’s not just at work, it’s not just among Java programmers, I encounter these issues all over the place and on all sorts of platforms.

I can’t really blame the developers, at least the junior ones. The APIs that we work with nowadays to write web apps remove us from the nitty-gritty of HTTP, just as we are removed from the pain of TCP/IP programming. That might be a good thing, but it leaves us with a leaky abstraction.

So what? So I’ve got a little pet peeve of a pattern. Big deal. What else is HTTP gonna get you?

Unless you have even a basic understanding of HTTP, there will be whole classes of vulnerabilities and design flaws in your web applications. You’ll have insecure session management, for starters, and probably cross-site request forgery bugs. I frequently encounter inadequately restricted URLs because of a misled belief that if a link to a page/resource isn’t exposed, that no one can get there.

Note that I wrote design flaws. These are not just developer problems, code-level vulnerabilities. Poor session management often starts with poor architecture and design. Misunderstanding the basic protocol behind the web can contribute to design problems that manifest in broken code.

How do you learn HTTP? Google around. The third chapter from the out-of-print Web Client Programming with Perl is a good start. If you like paper, I highly recommend Chris Shiflett’s HTTP Developer’s Handbook.

Here’s the trick: it’s not hard! Spend just a few minutes to understand the basics of HTTP. You’ll be a better developer, and your apps will be better for it.

When children learn to read and write, they are often taught to memorize spelling rules. In English, you are probably familiar with “I before E except after C.” (I would list more, but I never actually memorized any of them. :) For every rule, there are of course exceptions: eight, height, caffeine… The exceptions may not always make sense, but fluent readers and writers internalize them and understand that the simplified rules that we are taught as children are not sufficient to describe the complexity of a living language.

Visual artists are taught rules of design, the sort of thing that the rest of us find in books like The Non-Designers Design Book. Once they have achieved a level of mastery over these rules, they know when to break them. They understand that the rules are conventions.

Then there are programmers.

I don’t want you to think that I believe this of all programmers — it may even be a minority — but I regularly encounter developers who are made deeply uncomfortable by deviation from rules that they have understood to be set in stone but that in practice can be adapted fluidly. Or those who are just unwilling to accept that there are classes of problems that don’t have a single, clean solution.

I have an unsubstantiated, wild-ass hunch that they’re the same people who work on formal, mathematical proof of the “correctness” of programs. I say this not to impugn their character or ideas, simply to try to understand. I have a liberal arts background, so this is still a foreign way of thinking for me.

(By the way. It may happen that one or two people I’ve talked to recently about these topics will think I’m talking about them. I’m not. Get over yourselves.)

Let’s take web standards as an example. It should be no surprise to long-time readers that I am a web standards advocate. The three-legged stool and all that. I believe that unobtrusive JavaScript is an important and useful way to use standards to best advantage. But I am not a zealot. Sometimes it’s just not practical to take extreme measures to avoid behavioral attributes like “onclick” in your HTML. Maybe you’re using a framework that generates that code, and you can’t get away from it. It’s okay. Take a deep breath. You’ll live. I’ll live.

And then you’ll create something like the UJS Rails plugin to address a shortcoming in your framework of choice. Bravo! I knew you could do it.

Even the standards leave room for plenty of controversy, or at least wiggle-room. Is the kerfuffle over serving XHTML as text/html still going on? I really don’t know. I stopped paying attention years ago but still feel twinges of guilt about recommending XHTML Strict as a standard at work.

Security is an example of a problem that is likely to have less-than-ideal solutions. Consider threat modeling, an important part of a secure software development life cycle. In the threat modeling process, you identify and assess threats and vulnerabilities to your system, identifying those that pose the greatest risk. Security is risk management. It’s a balancing act: if there’s a low likelihood that a vulnerability will be exploited or that it will cause much damage if it is exploited, then you may choose not to devote development resources to creating countermeasures. Sometimes one security solution causes another to pop up elsewhere, and you have to decide which poses the greater risk. It’s ugly. I know.

Accessibility is another of those murky areas. In almost every conversation I have about accessibility, questions arise without satisfactory answers. Are PDFs accessible? They can be. It depends. Is this JavaScript technique accessible? For some people, yes. For others, no.

In all these situations, it comes down to making an informed, professional judgment. Novices do not have the knowledge necessary to make these judgments. That’s what makes them novices. That’s why children learn simplified spelling rules, why budding designers are taught the rules and conventions of their field, why beginning web developers should learn to use web standards and accessible development techniques. Adopting these rules and putting them into practice, over time we bump up against when they fail us. In time we develop a sense for how we can best respond to these failures, to this discord. We learn how best to move past the rules because we understand why they are there in the first place.

Some years ago, right about the same time that I started to move into Java, it became clear that Macromedia was trying more aggressively to woo Java developers. ColdFusion was rewritten in Java, so it’s now an app running inside a servlet container / app server, allowing ColdFusion developers to tap into the rest of the Java platform. With the introduction of Flash remoting, they positioned Flash more clearly as a development platform for rich internet applications. They released Flex, making Flash RIA development a hell of a lot easier for programmers unfamiliar with or intimidated by a Flash toolset aimed squarely at visual designers. No more confusing timelines! Just sweet, sweet XML. ;-)

Pretty sure JRun is dead, though. No complaints here.

Since the acquisition of Macromedia, Adobe has been keeping up the pace, with new releases of ColdFusion and Flex. And now AIR, which I’ll get to in a bit.

I don’t know how successful the ColdFusion rewrite has been in getting Java developers to start using it. I’m not suggesting that my personal experience is any guide, but I know more CF developers who have been introduced to Java and to object-oriented programming in the last few years than I know Java developers who have discovered ColdFusion. I did give it honest consideration at work a few years back but was turned off by its being an expensive, closed-source platform. Remember, my background is largely in the open source world.

Because of that background and bias, I was more than a little bit pleased to see Adobe open source the Flex SDK. As I wrote at the time, Flex’s being open source meant that I would consider recommending it to my employer. This is still true.

My employer is in the process of rewriting their ERP from a Win32 client-server desktop app to a Java EE web application. A decidedly nontrivial undertaking, especially considering that the developers have little background or understanding of web apps. This lack of experience and skills makes it difficult to create a compelling HTML/CSS/JavaScript replacement for a desktop app. Browser environments are limiting. It is possible to bend HTML to your will, and well-implemented Ajax helps, but to make it, well, not suck requires skill. To make it really kick ass requires serious skill. If you’re lucky and well-funded, you can hire enough people with that skill to pull it off. If you’re a state agency… well, good luck.

I remain hopeful, though. I just set my standards absurdly high.

I should insert a disclaimer here. I am by no means speaking for my employer. I’m just exploring the type of situation when I think a Flash-based RIA would make sense.

It is no accident that Adobe has been pushing Flash for RIAs. Flash apps look cool. They can suck, too, sure. But with a toolset like Flex, creating something that at least looks and acts more than halfway decent is a hell of a lot easier than creating an equivalent UI with HTML/CSS/JavaScript.

I’m not trying to sell Flex as a panacea. I know enough not to believe that a technology will solve development woes. But I have played around with Flex enough that if I’m writing a network-aware back-office app, one that’s likely to do well as an RIA, I’m very likely to use Flex because it will be easier to create better UIs. (Insert warnings about forking the web here. Except that I’m talking about RIAs here, not crappy Ajax apps.

Enter AIR.

AIR is something new from Adobe — the second beta is being announced at this week’s Adobe MAX — for creating Flash-based desktop applications. As desktop apps, they have access to operating system resources that browser-based apps don’t. The AIR installer is damn easy to work with. But the magic behind the acronym (Adobe Integrated Runtime) is that you can build the app with either HTML / JavaScript or Flash / Flex. Your JavaScript code can use ActionScript APIs to access the desktop goodness or Flash components on the page, and vice versa.

Color me impressed.

So when I saw that Adobe was going on a cross-country bus tour this summer to evangelize AIR, I signed right up to learn more. Last week the on AIR bus tour came to Minneapolis. The venue was a great choice: the old Varsity theater in Dinkytown, which I honestly didn’t think was still used as often as it appears to be. Comfortable seating. Catering by the Loring. Toss in an open bar, and we were prepped for one of the finest vendor events I’ve attended.

Since I’ve been watching video from the tour all summer, there weren’t a whole lot of tutorial surprises awaiting me. But it was about what you’d expect: Mike Chambers walked through building an AIR app with Flex, Kevn Hoyt showing us an app built with HTML & JavaScript. Show a bit more whiz-bang techie goodness for the next couple hours, and we all leave happy, planning blog entries like this one.

Actually, I planned a better blog entry than this one, but I want more of a chance to play with both Flex and AIR before I write that.

I mentioned earlier that I don’t know any Java developers who have been drawn into the ColdFusion world. Likewise, I don’t know many Java developers who have been doing anything with Flex. It could just be that I don’t hang out with enough Java developers. It seems, though, that the scope is expanding, and Adobe’s setting their sights a bit wider than Java. Good news all around.

In a conversation on the Agile Toolkit Podcast, Dave Thomas mentioned that the Pragmatic Programmers are publishing a book on Erlang. I’m fairly certain he said it was due this summer but I can’t be bothered to check, sorry.

This is good news! The next month or so are really busy for me, working on a couple presentations and a side project or two, and after that I’ll be digging into Scala in a big way, but then I do want to look into Erlang. Why? Concurrency. It just plain fascinates me. I also happen to believe that it will be increasingly important in the coming years, especially with multi-core systems turning up on everyone’s desk or lap. But mostly I’m just interested. Java Concurrency in Practice is staring at me from the bookshelf, I should probably crack that open.

Ah, so little time…

Update: the book has been released in beta.

In his Web Framework Manifesto, David Pollak identifies a number of features that he believes web frameworks should have, and I think he’s right on the money. He starts out with what you’d expect to find from one of the newer frameworks.

• A quick and easy way to map between a relational database and the target application.
• Easy, “right by default,” HTTP request mapping.
• Automatic “view” selection and composition.

So far, so good. In Rails, Django, and other similar frameworks that emerged about the same time with the same values, this is largely accomplished by staying DRY, by favoring convention over configuration, and by being focused and limited in scope. DHH makes much of his having no interest in Rails as a one-size-fits-all framework, and this is a Good Thing. Yes, it means that Rails isn’t a good fit for every app. Get over it. It also means that although Rails et al changed a lot in their emphasis on radical simplicity, they didn’t change enough. I don’t see Rails as the future of web development so much as I see it as representative of a final stage of MVC web frameworks, wrapping up up a lot of good ideas and giving us something to work with as we get over the hump into the next stage. Whatever that will be.

I’ll put my money on a few ideas: component-based architectures, addressing how Ajax shifts how and where state is managed, and better state/scope/workflow management with continuations.

Pollak gets into some of that in his next criteria, which is quite a list. He starts with a discussion of components. (I won’t quote everything here. I really suggest you go read the full piece.)

• Pages must be composed of arbitrary components that manage their own state.
• The rendering of components must be asynchronous based on user-based and external event-based state change.
• Components should be live (or seamlessly persisted) at all times, ready to respond to events.

Right away we’re getting into an area where older-style MVC frameworks like Struts, which is still alive and kicking thankyouverymuch, completely fall down. I’ve been dancing around this for years without getting into it too deeply here, but I just don’t think that MVC is a perfect match for web applications. It is useful as a separation of concerns, but the action-based controllers that we’ve been used to in MVC web programming are becoming inadequate with the rising use of Ajax. We are hitting a wall and should be able to do so much more.Both the Java and the .NET worlds seem to be moving toward components, albeit with slower adoption than either Sun or Microsoft would like. (I don’t know what I’m basing that on, by the way: I freely admit that it’s just a gut feeling. I also admit that I don’t deeply understand the shift to components and what it entails. I just haven’t taken the time.)

• The browser should be honored and feared. That means the back button should “do the right thing”
• There should exist a simple, unified way to describe modal user behavior (e.g., filling out a multi-page form.)
• Sessions should be tied to a browser window/tab, not to a browser session.

I am interested in Seam and RIFE in part because of how they manage state — especially using continuations in RIFE. Seaside has demonstrated what that can be like, done well. Not only do we have continued usability problems with managing state across multiple HTTP requests, but considering that it’s still in the OWASP Top 10, I’d say it’s fair to say it’s a significant security problem, as well.

• Mapping between object fields and HTML (or whatever the presentation layer is) should be “right by default”

We spend far, far too much time messing around with this at a low level, and it offers far too many opportunities for niggling little bugs to introduce themselves. I won’t trouble you with details about how I just spent two days doing something that should have taken twenty minutes. I’m still too angry about it.

It should come as little surprise that I am delighted by Pollak’s emphasis on security. Web frameworks do not do enough for security, period. I believe that developers can and must understand the range of attacks to which their software is likely to be subjected, even if they don’t become security experts, but frameworks should also make it easier to do the right thing than not to. Input validation should be centralized, simple, and a default. Output encoding should be handled properly by default. Access control should be more transparent and pluggable. And so on. Pollak has good suggestions.

• input from the browser should never be trusted, but should always be tested, validated, and destroyed if it is unexpected
• There should be a single way of describing input validation.
• There should exist an orthogonal security layer such that objects that are not accessible to a user should never be returned in a query for the user and fields on an object that are not accessible should not be visible.
• Code should be impervious to a replay attack. That means that fields in forms should have random names that change for each request.
• The framework and runtime should correctly and gracefully deal with non-ASCII characters.

The last one is not just a security issue, but I lumped it in there because it does fit.

I love the idea of random names for form fields. So simple, yet we’re so caught up in the annoying low-level mapping of field names to back-end objects, that it gets overlooked. And as valuable as the Commons Validator framework can be, calcifying field names in even more config files is tiresome, error-prone, and constricting.

Finally, deployment. I’ve written before how as much as I like Rails, Capistrano, and Mongrel, and as confident as I am that a Rails apps can be deployed so they perform, scale, and can be well managed, I’d still feel sheepish suggesting deployment scenarios that change as often as Rails’s “proven practices” seem to. Maybe I should just get over it. Regardless, it’s clearly something to take into account when considering a development platform.

• Deploying the web application should be as simple as putting a file in a known location (e.g., a WAR file on a J2EE server) or by executing a single command (e.g., Capistrano.)
• Deployments should contain all dependencies.
• The production environment should support modern technology including executing multiple threads in a single process and allowing for many “live” objects to be corresident
• The production environment should support hot code replacement
• The development environment should support hot code replacement such that once a file is saved, it becomes live at the next HTTP request.

The last is so very, very important. Shortening the feedback is vital, one of the much-touted features of Rails and other dynamic language frameworks. It can be done with Java and a decent IDE, but not always. And although I think it’s obvious, this is far from universally understood or believed. Not long ago, because of a really slow database load and a design error, a developer I know had to wait 15 minutes for a Java web app to deploy and load. Unacceptable. I don’t know how she or her supervisor tolerated it, because it meant that she could make and test at most four changes an hour. Or, more likely, make more changes than were really safe, which is what a long feedback cycle encourages.

The benefits of frequent and automated testing should be well known by now, or at least I think they should be, so I won’t write ano more about that now.Where does all this lead? Shortly after he wrote this manifesto, David Pollak responded to it by releasing Scala with Sails, now known as the lift web framework. You can get a feel for some of it in the recent announcement on his blog. Lift is written in Scala, a functional/object-oriented language (yes, both) that compiles to Java bytecode, so it runs on the JVM and has access to the Java API. Scala is my next language, if only so I can work with (and on?) lift. Much as I have high hopes for JRuby on Rails, I think that lift is something to watch, especially if the development team can do half of what they set out to do. As is clear from the Pollak’s essay, we need to push web frameworks more than we have done.

Java SE 6 was released last week. How many of us are now running 2 major versions behind? :)

There are a few goodies in this release, including performance gains and better debugging and monitoring, but the one I’ve been waiting for is JSR 223, explicit support for “scripting” languages. I first got excited about this JSR when it seemed that the reference implementation would be PHP. At the time I did most of my work in PHP, and I was excited about bridging the languages. Instead Java 6 ships with Rhino, a JavaScript interpreter written in Java, but that’s just fine if not better. There’s a longer list at scripting.dev.java.net anyway, including PHP on the JVM.

Why does this matter? I believe that the future of Java is not so much Java-the-language as Java-the-platform. I have felt this from the day I first encountered Jython (four years ago already?). Encounters since then with JRuby, Rhino, and Scala have only made my convictions firmer. Recent actions from Sun (and the JCP) lead me to believe that more than a few people there there recognize that if the JVM is one of Java’s core strengths, then the Java platform has a future somewhat distinct from the language. Sun hired two lead JRuby developers (locals Charles Nutter and Thomas Enebo). With JSR 223 and now JSR 292 (“Supporting Dynamically Typed Languages on the Java Platform”), which I believe we can expect in Java 7, it will be taken a significant step further. As Danny Coward points out in a recent interview, JSR 292 introduces the first bytecode in the JVM that is not used by Java. To me, this is a fairly clear endorsement of non-Java languages as part of a broader Java platform.

Microsoft is doing the same thing, by the way. Sure, much was made of multiple languages running on the .NET Common Language Runtime when it was first announced, but I have the distinct impression that C# is very much the canonical language for .NET development. But a few things have happened in the past year that tell me this is changing: Microsoft hired Jim Hugunin, lead developer of IronPython, a Python implementation for .NET (Hugunin is also the creator of Jython), then released IronPython for ASP.NET They’ve also been working with Zend to make the PHP experience better on IIS, including writing FastCGI for IIS 7.

I’m kind of surprised that I haven’t written about this more here. I think I’ve avoided it because it seems so damn obvious. But it isn’t, not really. It may be obvious within the areas of the blogosphere where I spend time and in the local Ruby community. But in the real world of day-to-day Java development to which I subject myself, in which most are unaware even that Sun has open sourced Java (it’s a culture thing), much less that Java 6 has been released and what it includes, talk of languages other than Java is very strange and uncomfortable news. I still get polite nods and bemused or uncomprehending looks. Daily.

It also occurs to me that there are readers of this blog who do not live immersed in the world of Java and who have valid reasons for being unaware of recent events. :-)

A quick note. I put “scripting” in quotes above because labelling languages like Ruby and Python as “scripting languages” is unfair and indicative of the historically dismissive attitude that some programmers have held toward them. To sound au courant, you should know that the currently favored term is “dynamic” or “dynamically typed” to distinguish them from statically typed, early binding languages like Java. The wrinkle is that in JSR 223, those languages are used for scripting, playing second fiddle to Java. JSR 292 shifts this balance.

So there. Nothing earth-shattering, but now at least maybe you understand why I talk about JRuby a lot.

I’ve spent my life immersed in language. By the time I graduated from high school, I’d studied at least a dozen: French, Spanish, Italian, Esperanto, Russian, Mandarin, Irish Gaelic, German, Latin… French is the only one I learned very well, but still I developed a profound appreciation for how study of one language can enrich my understanding of others, including and especially my native tongue, English. In college, as a French major with a linguistics emphasis, I of course studied even more languages. Frequently I found myself better able to express or understand certain ideas in languages other than English.

My father was a programmer and often expressed his conviction that there is a connection between languages used for programming and those for human communication, asserting that they occupy the same area of the brain. I have no idea whether that’s true, but it sounds reasonable and I’d believe it. He, too, had occasion to learn new languages for his work, although the only ones I ever knew about were C, C++, Ada, and possibly COBOL. I think it no accident that the first programming language in which I felt truly at home was Perl, which is strongly influenced by linguistics and ideas about human language and expressiveness (see, for example, Allison Randal’s “On Topic“).

It should come as no surprise that now, as a working programmer, I believe the study of multiple programming languages to be not only extremely valuable, but essential. And maybe it’s close-minded of me, but it surprises and disappoints me when other programmers do not feel the same. I work on a team of Java programmers, and with one exception I am the only one who is even remotely interested in things outside the Java world. This is crippling. That sounds like an exaggeration, but I believe it to be true. A monoculture is limiting and dangerous. It doesn’t matter whether you’re working with .NET, Java, Ruby, or whatever. Working under the assumption that a single tool can be an effective one-size-fits-all tool is a serious mistake. It limits your thinking, it limits your creativity, it limits your ability to solve problems.

Here’s some advice I recently gave someone who was looking to hire a .NET web developer:

I’m not suggesting that you hire someone who isn’t strong in .NET. If you don’t currently have strong .NET skills, then obviously that’s a very important consideration. Neither am I suggesting that you look only at developers with experience in .NET and something else. I’m suggesting that a candidate who has experience with .NET and another platform may — may — turn out to be a stronger candidate because s/he can critically assess what .NET has to offer rather than blindly follow the One True Microsoft Way.

I work with Java programmers. That’s what they are: Java programmers who happen to be working on web apps. Except for maybe something like Scheme covered in an intro computer science course, they don’t have experience with anything but Java. And it hurts us. Because when they look at a problem, all they see is Java. When I suggest a way of doing things that isn’t a canonical approach in the Java world, I get strange, uncomprehending looks. And we end up with overarchitected, overcomplicated application designs that solve problems we don’t have — or that fail to solve the ones we do have.

Example. An complicated call stack for a form submission that retrieves search results. POST form, push criteria to the call stack, redirect to a GET to the results display page, pull criteria off the stack. Okay, the call stack isn’t complicated, but the code behind it was. The programmer who designed this spent a long time working this out and unsuccessfully trying to address problems like dealing with multiple windows. Solution? Submit the form with GET in the first place. Dead obvious to a web developer, not so much to a Java programmer who’s not used to the web. But maybe that’s not fair since it’s a domain problem.

Example. A former coworker insisted that the text output of a certain COBOL program could never be parsed and made into something more meaningful. Why? Because he was exclusively a Java programmer, and Java’s a pain in the ass for text manipulation. Well, I work with languages like Perl and Ruby, steeped in a history of text manipulation. I munge text for breakfast. I looked at the problem and figured it would take about half an hour with a few regular expressions. Java didn’t even have regular expressions in the core API until four years ago, so this way of approaching a problem still doesn’t occur to most Java programmers.

Example. I find myself cleaning up a lot of clunky JavaScript code, written by people who treat it as “Java Lite” and who don’t understand JavaScript’s object model, which is quite different from Java’s. Different, not worse — and certainly not the One True Java Way.

I’m not writing this to rag on Java programmers, it’s just that they happen to be the source of my daily frustrations.

All this said, it’s quite possible to have an excellent web developer who knows only Java, or .NET, or ColdFusion, or PHP, or whatever. Regardless of whether they’ve worked in a diversity of languages or have been steeped in a monoculture, I think it’s worth asking about the strengths and weaknesses are of their chosen platform, because it’s a strong indication of how carefully and how creatively they’re thinking about the problems before them.

This is part of why I worry about what to suggest instead of Java EE, or rather what we can introduce to Java EE to be more productive. Part of my growth as a developer has been learning that not everyone has an easy time learning another language. I have always had an easy time learning languages, whatever the sort. I love to learn a new language, to stretch my mind and see what it has to teach me. This is far from universal. But I have to keep reminding myself of that, especially when I have trouble understanding why so few people are interested in extending the Java platform with non-Java languages.

More on that another day.

Google Maps is cool, sure, but last night I saw Google Maps Mobile. That is impressive.

A prediction: if a couple years from now I am still mired in a Java monoculture, I will strangle someone. Probably myself.

As I have explained before, and with some apology for the double negative to which I am about to subject you, I do not believe that Java can never be viable for web application development, or that it is a bad language. I simply assert that it is an exceedingly poor choice for the web applications that I work on. Because it’s past 1 a.m. and my son will be waking me up in less than five hours, and maybe because despite my curmudgeonly nature I am reasonably polite after all, I will spare my employer the (mild) embarrassment of an all-out rant. Suffice it to say that working among the Convinced as I do, I am very much in the minority in my belief that Java EE — really, a Java monoculture — is the number one culprit for the project I’m working on being so very, very late. It isn’t the only problem we have, but it’s a big one.

The question I’m left with is this: what do I propose as an alternative?

.NET is out. We’d need lots of new hardware and be locked with a single, closed-source vendor. Please do not bring up Mono.

Cold Fusion? Same single-vendor problem, and I remain unconvinced.

There are Python frameworks like Django and TurboGears. I like them. They’re just not compelling enough for me to suggest using them.

Tcl? Sorry, private joke.

To my mind, it comes down to PHP (using any of a number of frameworks) or Ruby on Rails.

We would stand to benefit more from both Ruby and Rails, but I am concerned about deployment scenarios. Large-scale Rails deployments are possible, but it’s still a new enough platform that people are still working out the kinks for how to do it well. To be honest, we’d just be talking about a medium-size deployment, but the same concerns apply. Could we do it? Yes. I have faith in our system administrators and our developers. I would just feel really guilty about going to them every 3-6 months with a new way of setting up the servers to deploy Rails apps. I admit that I haven’t been following that scene for a while, but it does seem every time I poke my head in that there’s something significantly different.

On the other hand, I’m satisfied that we know how to work well with PHP, at least from a sysadmin perspective. On the development side we would certainly move a lot faster than we do with Java. As PHP becomes more Java-like, you’d think that a transition from Java would be easy. That’s the whole point, right? PHP has a low barrier to entry. On the other hand, its similarities to Java (at least in the object model) may make the transition harder, as I’ve found that Java programmers are somehow blinded to or misunderstand significant platform differences — e.g. PHP’s share-nothing architecture. We would also struggle with maintaining a large PHP codebase, much as we struggle maintaining Java code in reasonable order.

But honestly? In my gut, I hesitate to propose PHP because of the language itself. It doesn’t feel that much better to write PHP code than Java code — sometimes it’s worse, especially some of PHP 5’s Java-inspired syntax. Mostly, though, I think it’s the lack of closures and blocks, language features that I’ve come to expect and rely on. Peter Williams brings up the same point about PHP.

I first learned blocks and closures about two years ago and now find programming without them mildly painful. I think that Mark Jason Dominus got it right when he said

in another thirty years people will laugh at anyone who tries to invent a language without closures, just as they’ll laugh now at anyone who tries to invent a language without recursion.

There are just so many common classes of problem that are simply and cleanly solved by closures that not having them seems like a crime.

I think I’m holding out for JRuby on Rails.