Via holygoat.co.uk:
Subtext - an "example centric" programming language.
While I didn't particularly like Subtext itself from what I've seen so far (that doesn't say much, I'm extremely picky), I like a lot of the overall ideas, and there's a document on that site everyone should read:
Manifesto of the Programmer Liberation Front
It's a long read, but lots of interesting thoughts, including gems like this:
Terseness is prized in Math and Science. While being able to write Quicksort in 3 lines may seem like a powerful feature, it is in fact bad for the actual practice of programming. Theorems and Laws of Nature may last a century before becoming obsolete, and are generally about widely relevant concepts. Programs are lucky to make it to the next release, and are mostly about highly localized and detailed concerns. The primary use-case of programming is the modification of code written by someone else. Readability, as opposed to terseness, is far more important in programming.Many programming languages are designed as if saving keystrokes was important. This might have been appropriate when we used teletypes to program, but it is not relevant in real life programming, where far more time is spent reading and thinking than typing, and especially when there is a smart IDE to fill in some of the typing.
There are some areas of the manifesto I disagree with, though. For instance, as much as I really want a programming language that uses a more structured approach, and is less tied to text, there is a fundamental problem with that:
Editors are everywhere, paper even more widespread, and people write articles and textbooks.
Textual programs are easy to jot down notes about and reproduce on any kind of system. Anything that depends on graphics or a specialised tool is severely restricted in that regard.
I've spent a lot of time thinking about new approaches to programming languages myself, and one of the things I decided was that as much as I'd like to free myself from being tied to text, I could not do so completely. Instead, my approach was to start experimenting with a language design specified entirely based on it's semantics (this is not a new idea, btw.), and with at least two representations: A textual, human readable, representation suited for interchange, and a representation suited for editing and "exploration" in a structured tool.
I don't think Subtext would be too unsuitable for that - it's mostly text based, after all, and what the tool provides seems to be more about providing a well defined IDE as the primary method of editing and working with programs as a structured graph.
And while you're thinking about this, read Stefano's take on it as well. I particularly liked his comment about how it's just like RDF