Lambda the Ultimate

Chrsitopher Fry and Mike Plusch:

Water(TM) is a new Web services and general-purpose programming language that allows you to program in the ConciseXML syntax. Water is an open object-oriented language designed to simplify the creation of new Web services. Water is extremely flexible and adheres to a"Learn Once, Use Everywhere" philosophy where data, logic, and presentation have a uniform representation. Water also implements a capability security model to provide secure execution in protected domains. Water builds upon the ideas from a number of different languages such as Scheme, Self, Lisp, Java, SmallTalk, Self, JavaScript, HTML, and XML.

Let's take for granted the goodness of representing programs in a way that lets other programs take them as data (s-expr xml). For the sake of argument, let's say we sometimes don't want to munge the program. Then it seems we're left with a really verbose way to program, like XSLT.

Wouldn't it be "nicer" to have an underlying uniform representation for data, logic & presentation, with some sugar on-top to distinguish between data, logic & presentation when that's a useful thing to do?

A similar language was presented at LL2. The last talk was about LZX, which is focused on client side execution (whereas water seems more like a middleware thing). Unfortunately LZX isn't out yet, and I can't find any website for it. But it gave really cool demos.

• Best two-page summary I've read about what's fundamentally wrong with XML.
• Good two-page description of capability-based security.
• Attempts to incorporate both of these.

But I've not determined how well, or if I'd want to program in Water anyway.

I need to go back and review the video of LZX at LL2. LZX and Water were briefly compared. Water seems more clean as a language. LZX seems more capable as a GUI canvas.

It seems straightforward: if the representation of data, logic & presentation are the same; it becomes more difficult to identify which-is-which, it increases the cognitive load, consumes brainpower.
The fun thing about usability testing is that you often find out that your beliefs about how quickly or slowly you do things turn out to be plain wrong. What I think is important here is that a fundamental change in representation is sliding-in without an attempt to figure out if that's a "bad thing".

"In the 1960s, people actually measured language understandability —a major factor in software productivity." The Emperor with No Clothes & Command name design

Thanks to website usability issues a lot of people have heard about discount usability testing techniques, and those techniques can be applied to programming language design.

Mixing data and behavior doesn't concern this old Lisp programmer. In fact I still prefer Scheme + SXML to Water or any other XML-like behavior notation. Maybe I am used to it. Maybe round brackets are more soothing to the eye.

But also there are better tools for programming behavior in Lisp. I could imagine (and maybe there actually is) a good display editor for Water that clearly distinguishes what is code and what is data based on detecting what "mode" the user is in.

My main takeaway for water, however, is that it's a solution in search of a problem. Since it doesn't have a GUI aspect, that tells me that it's most appropriate to run it on the server. And indeed the water folks seem to say that themselves. However they seem largely uninterested in execution speed, which does not seem at all appropriate for a server technology to me.

Another point that I heard voiced is although there are a profusion of different languages that have to be learned in order to create websites (XML, Java, javadoc, javascript, JSP, XSL, CSS, etc), it doesn't really matter since at least in large companies, no one person has to learn with all the languages themselves.

I'm dubious as to the advantages of unified syntax -- if it doesn't come with simplification of semantics, then you haven't really won anything. However you have lost all the tools that other people have created that work with the standard syntaxes, and all the shared knowledge that other people have amassed. Would you really want to have to write your own javadoc tool, just because you tossed out java syntax and moved to water?

Unified syntax should definitely not be a holy grail. But it does so happen that a simple language, Scheme, does have unified syntax, so all the better. JScheme or SISC are pretty good choices across all these dimensions: simple semantics, simple syntax for code and data, integration with Java to use all the tools others have created.

http://developers.slashdot.org/article.pl?sid=02/11/28/0251248&mode=thread&tid=156