As I was thinking about this some more, checked exceptions start looking like explicit typing. The reason people want checked exceptions is to make sure that no error conditions go unprocessed. Same thing that explicit typing people want. But let's apply the testing argument. If your testcases actually tested the relevant error conditions, then you wouldn't need to have a language mechanism to ensure that the errors got handled. At least, you could make all exceptions unchecked, and eliminate the multi-arm catch hairballs that are lying around. It's not like all those catch blocks that are empty, printing stacktraces, or logging exceptions are really improving the robustness of the systems that they are in.

He concludes with a section about comments intended for comment processors like doctest, iContract, and XDoclet.

All of these functions of comments as metadata could be implemented by extending the language instead. (Contracts are from Eiffel, for example, which supports them in its core syntax.) However, the use of structured comments as metadata lets a third-party tool address a gap in the language in a way that leaves the source structure intact for compilers and other source processors (such as editors, source debuggers, and refactoring tools) that wouldn't recognize an extended grammar. Just as comments are an escape hatch for human readers, they're an escape hatch for development tools as well.

And these two kinds of comments - natural language and structured metadata - are related. They both add information that can't be expressed in the primary programming language. And they're both useful to humans too.

Marc is asking about standards. As far as I know, we don't really have much experience with this kind of metadata in real world, real scale applications. Seems early for standardization. Of course, that never stopped the W3C or the JCP.

• Chris Double has a series of entries covering continuation based web frameworks, continuation based web servers, and SISC.
• Bill Clementson moved his blog and picked up an RSS feed. He also picked up some continuation based web server papers that Chris missed.
• James Strachan and Bob Werken over at codehaus are building a java friendly dynamic language. The goal is to integrate well with Java and be familiar to Java programmers. I'd guess it would be C# friendly as well, which means that if the MS guys keep their promises to improve the CLR for dynamic languages, Groovy will end up being better on CLR than on the JVM. I didn't see any references to continuations. There's a reference to Bachrach's JSE.
• Alex Martelli weighs in in the Ruby vs Python discussion.
• Michele Simionato and Jimmy Retzlaf report on their experiences with Psyco, the Python partial evaluator.

Why not build a web application that lets you do this both before and after conferences? That way you could see if expectations and reality met up. By allowing many people to do this, you might be able to come up with a way of recommending conferences to people. If conference organizers were willing to cough up some of their evaluation data, you could use that as input as well. Maybe something like this would work as a sub-application of a site like tribe.net.

test-driven development => example-driven development
unit test => technology facing examples
programmer support tests => checked examples
retained checked examples => change detectors

I think that this could use some more work to make these ideas even clearer to the non-infected. The other observation that he made was that there are two roles for examples. Some examples are written to guide near term development -- what functionality needs to be implemented next, and what do examples of its use look like? Other examples are used exclusively for rechecking that the past behavior of some code remains unchanged. Some guiding examples eventually become rechecking examples, but not all rechecking examples were originally guiding examples.

CodePaste is a RubLog blog that allows anyone to add a page containing source code via a special link. This code is then syntax highlighted and displayed on the blog.

Lisp, Smalltalk, (dynamic languages I have decades of experience with) as well as Python, Ruby, etc. have good support for not only making prototype code, they also have good support for making prototype objects and data structures.

Lists, maps, arrays, even self-referencing structures can all be entered end edited in a command loop or workspace using a very simple (i.e. few characters) syntax. There are also the mundane (now that Java brought them to the masses) aspects of these languages like garbage collection and array bounds checking.

} else {

I remember the first time I saw Python, and saw that indentation was significant. I was really turned off by it, and it kept me away for quite some time. Part of that was because a long time ago I had to implement a compiler for a language that had a similar offside rule, and it was a nasty experience. Having used Python for a while now has made me a believer in the indentation based syntax. As I was browsing the OCaml documentation, I noticed that OCaml code has a similar flavor to Python code. I don't know if OCaml relies on indentation or not, but it's going to be interesting to find out.

I have yet to experience an environment for a static language that is as usable in this way as a system designed with a REP loop in mind.

Declan McCullagh's News.com article tells both sides of the story. Cem Kaner, quoted in McCullagh's story, had own take on this issue.

The software industry as a whole needs to find ways to improve software reliability. If we don't find a way to do it, the legal system is going to find way to do it for us.

Whenever you publish any data on the web, even simply posting to a mailing list with a public archive, you're releasing information that could be used to profile you. I could build a tool to smush together information about mailboxes from mail archives without FOAF. FOAF just makes this data, and the act of publication, more explicit. FOAF is therefore a showcase for the kind of issues that are going to be increasingly important in the future (now, even); it's not necessarily a problem for FOAF to solve, IMO.

For a long time, the right strategy for GNU was to build a basic unix replacement differentiated primarily by licensing. As software goes, the core of unix is a simple architecture, reflecting its history as a design first realized by a very small team of people.

Well, that part's done and the strategy won.

Nowadays, the proprietary competition is about databases, and productivity apps, and browsers, and middleware layers. The software we're competing against is not like unix: it isn't simple; it wasn't built by a small number number of people; it's a moving target. It isn't a tractable project to clone this proprietary software under different licensing.

If the goal is still "(a) build a free alternative to proprietary software", then a new strategy is called for: competition on _software_architecture_, not just licensing.

It *is* about how dynamic linking and binding works in a system. But how that works is intimately associated with the language design.

Then Jon goes on to amplify Patrick's point about interactive environments:

As programming increasingly relies on external services and alien environments, it becomes as much a game of exploration and discovery as of design and specification. I think dynamic languages and interactive programming environments help make us better explorers and discoverers, and I think that's only going to matter more as time goes on.