From personal experience, the version of Java on Macs seems to have lagged significantly behind the version widely available on other platforms from Sun/Oracle. It's not clear to me yet exactly what this announcement/reaction refers to, but if it means clients who use Macs wind up downloading/installing up-to-date Java runtimes like everyone on other platforms, and have the latest version as a result, that sounds like a good thing.

For what it’s worth, I can see a very strong case for type-safe rendering and systematic parsing of this kind of structured data. However, to my knowledge, no mainstream statically-typed language is expressive enough out-of-the-box to represent the structure of a typical JSON/XML/whatever schema in a concise, readable, maintainable form to support these goals.

Many popular statically-typed languages support all the basic arithmetic and logical operations for numeric and boolean data. Their standard libraries often include a bewildering array of additional mathematical functions as well. However, the basic text operations of rendering and parsing strings just don’t seem to get the same sort of support in most cases, perhaps because they are so much broader in scope. Likewise, manipulating structured data is often a weak point: today’s mainstream statically-typed languages tend to lack both the general flexibility you get with dynamic typing and the expressiveness and polymorphic tricks you get with algebraic data types and pattern matching in various functional programming languages.

I’m not sure I’d go quite that far. There are several subtle advantages in Python (and one or two not so subtle ones) that IMHO make working with formatted text significantly easier overall.

For example, Java’s basic string formatting tool, String.format, and its regex patterns rely on numerical indices to identify specific placeholders and capture groups. In Python, you can use meaningful names in each case.

Another small but often useful win for Python is having raw strings, which cut down dramatically on backslash pollution when you’re writing regex patterns.

Finally, in perhaps the fairest example of the wider statically vs. dynamically typed language comparison, we have Java’s infamous verbosity against Python’s famous readability. Simple things like matching a regex with capture groups can require several lines of code and explicit creation of several objects in Java. In Python, you rarely need more than a single call to a function in re to get the same job done.

I don’t know how much of that is reality and how much is popular perception. In any case, here are some general trends in mainstream statically-typed languages and mainstream dynamically-typed languages today that might contribute to the popularity of the latter for web development:

• The dynamic languages do not require the extra compilation steps in a build process. This probably speeds up prototyping. A lot of the web development in dynamic languages is probably done by small businesses or start-ups, and that sort of culture places a lot of emphasis on rapid prototyping.
• The dynamic languages tend to have much easier basic text processing. Basics like string formatting and regular expression parsing are a horrendous chore in languages like C++, Java and C#, relative to the trivial one-liners widely available in “scripting” languages.
• The dynamic languages also tend to have built-in support for structured data like nested hashes and arrays, where again you need to jump through hoops in typical mainstream static languages today. That kind of structured data is widely useful for defining easy interchange formats between browser-side code and server-side code. For example, on a current project, we have standardised JSON data that is accessed using several different programming languages in different contexts. In JavaScript or Python, it’s a breeze. In Java, it’s a chore.
• Integrations of popular dynamic languages with popular web servers are widely available and easy to set up. Setting up a Java-based web application is the sort of thing people write whole books about, dropping the names of half a dozen different technologies along the way.
• Likewise, integrations of popular dynamic languages with popular database systems are widely available and easy to use.
• A lot of web development projects are, rightly or wrongly, not treated as critical software systems where bugs are unacceptable. Encountering an error at run-time and dumping the visitor to some sort of error page is often considered an acceptable response, and people seem to expect and tolerate this behaviour without quite the same level of loathing they reserve for “Your application has crashed” dialogs or blue screens of death.
• Perhaps most important of all, most web development software is small. More formal systems with static typing and well-specified interfaces probably have a better cost/benefit ratio on larger systems where it is harder for developers to see the big picture and more difficult to co-ordinate people working on different parts of a system without such tools.

I think these are more reflections of the languages in current use and their surrounding cultures, rather than inherent traits of static vs. dynamic typing, but if we’re talking about the state of the industry today, there doesn’t seem to be any practical distinction.

Whether to do The Big Rewrite always boils down to one very simple question: do the expected gains outweigh the expected losses?

Usually, the argument against doing a rewrite boils down to two key points:

1. it takes time and resources just to get back to what you already had, which confers no immediate business benefit; and
2. you risk losing the bug fixes and special cases that have accumulated during the real world use of the original implementation.

Those are certainly valid concerns, and IME it is often true that their impact is underestimated. However, what the doomsayers tend to ignore is all the potential benefits from writing a second version of something from scratch but with the experience gained from doing it once already:

1. you can design based on the knowledge accumulated during the real world use of the original implementation, giving code that might be easier to maintain in future and/or allowing you to add new functionality that was not realistic before;
2. you can refine your requirements based on that same experience, cutting out things that haven’t helped in practice and cleanly integrating requirements that weren’t anticipated the first time around, leaving you with a code base that is fitter for its purpose;
3. while you lose all the old bug fixes and special case handlers, you also get to clear out all the old hacks and bolt-on workarounds that are maintenance hazards and a high risk of causing future bugs; and
4. the best tool for the job the first time around might not be the best tool for the job any more, and a rewrite lets you revisit that decision and take advantage of any relevant advances in development tools, programming techniques, industry knowledge, etc.

I’m sure some rewrites really are just because a developer wants to write something new instead of working with what is already there, and those are almost always a bad idea IMHO. On the other hand, it can be annoying if someone comes in assuming that this is the only possible motivation for a rewrite, without considering whether there is another justification for the decision.

In that case, would you mind explaining something that is confusing me, please? It sounds like you started the rewrite in early 2005, planned to release in mid 2006, and actually had a finished product in early 2007, which isn't on schedule but is hardly unheard of for a software project. However, you then seem to jump to saying the new version wasn't available across your entire international market until 2010. What happened in between?

Not very well yet: our voting system is still transparently biased towards the larger parties, and the compromise reached by the Liberal Democrats and Conservatives in the coalition doesn't go all the way to offering the public a referendum on PR in the Commons (though they do seem to be proposing it for the elected Lords).

But I do take your point: it seems likely that the presence of the Liberal Democrats in the coalition is pushing the civil liberties agenda higher up the government priority list. I think that is partly because it is a big Lib Dem policy area anyway, but also partly because it is something where both parties in the coalition can readily agree on most issues and say they were doing what their voters asked for. Any coalition wants to show early success to reduce the scepticism in the ranks, and since the Tories and Lib Dems have well known differences in economic policy so the top issue of today can't really help both of them at the same time, this is probably the next best area to look for that success story.

I find it ironic that the US should decide to introduce this measure under a new government when the old one was notorious for abuse of authority.

Meanwhile, here in the UK, we just handed electoral annihilation to the administration that introduced a similar guilt-by-suspicion DNA system here, not long after the European level courts ruled that keeping innocent people's DNA on the database indefinitely was illegal anyway.

One of the first proposals brought up by our new coalition government, indeed one of the points where both parties agreed on almost everything despite their general political differences, was a "Freedom Bill". That will basically be a mass repeal of all the draconian, intrusive, guilt-assuming laws that the previous lot brought in under a climate of fear that they perpetuated more effectively from the corridors of power than any terrorist group ever could. Introducing safeguards so that innocents' DNA is removed from the database in a timely fashion will be an acid test of that bill: they've talked the talk, now will they really follow through?

Hi, I’m a real typography geek. (Chorus: “Hi, typography geek!”)

Sure we do. We know Knuth was crazy to talk about paragraph-based hyphenation and justification, and it is madness that the Knuth-Plass algorithm remains the gold standard in H&J today and something that only TeX itself, InDesign, and a few high-end specialist packages can match even now. We hate all those fiddly thin spaces that you have to type manually, too; we’d much rather just have our adjacent quotation marks and superscripts clashing.

Speaking of superscripts, we know Knuth’s font design skills were appalling as well. Anyone could design a system of fonts that was still clearly legible when used to typeset mathematics with sub-subscripts at 4/5pt on the one hand, yet provided extensible brackets surrounding multi-line expressions without looking overly large on the other. We know this from the vast number of font families available from the world’s leading type foundries today that do the job, and the way mathematical journals have given up on TeX because modern fonts provide a much wider range of mathematical symbols that are still clearly distinguishable from any Latin or Greek glyphs that may appear nearby.

Maybe TeX was just behind the times, though. After all, in an era when TeX could only typeset a variety of proportional fonts with intelligent hyphentation, ligatures and correct punctuation, at a useful range of sizes, in a way that could survive photocopying a research paper and still be legible, the world’s serious typographers were probably already using word processors that could render a fixed size, monospaced font on their dot matrix printer with underlining!

TeX’s handling of fonts is archaic by modern standards, of course, though updates like XeTeX do a much better job when it comes to things like OpenType and Unicode. However, in fairness, Knuth developed TeX many years ago, at a time before these modern standards were a glint in their metaphorical parents’ eyes. I think it’s rather unfair to criticise on this basis, and much of what he did has set the standard for three decades.

Getting back on topic, if the person or people behind the tool we’re discussing can do half the job for musical notation that Knuth did for mathematics, it will be a very fine achievement indeed. As with mathematics, it is relatively easy to scribble musical symbols in a way that is technically correct, but rendering music in a way that remains clear and effective even when read at speed in large volumes is quite a different thing. Nitpicking about some of the typography in an early demo seems a little unfair, given the already high standard of the overall rendering.

Sorry, I wasn't clear: I was referring to big companies in the business software world, such as Microsoft and Adobe. Certainly the games world has been suffering a rash of silly DRM-related failures recently, but alas, that sort of software is not a common sight on my work machines. :-)