Slashdot Mirror

It *has* been done before. I worked on it years ago. One of my colleagues came up with it in 1999.

http://www.waterlanguage.org/

It was brilliant to work in, but it didn't catch on.

Right now, when making a web app, I have to create PHP scripts that generate SQL queries, crunch the data, and then output HTML and possibly client-side Javascript. What a pain in the ass - there's at least 3 languages involved and really the whole thing is a mother to debug.

An alternative would be to freeze HTMLv4 now, throw out XHTML, go with browsers that use "pure" XML and a styling/formatting system, and define a style/format for XHTML.

Personally, I work with a language called Water, and I could build that XML styling/formatting system in Water and let it convert those styles and formats to HTML that would render in today's browsers for me, and have instant compatibility.

That said, there's significant investment in learning HTML and its variants in the world today, and if we go forward in a manner that enables existing HTML/XHTML programmers to transition their HTML/XHTML skills forward, then we will significantly increase adoption speed of the new standard because people will be able to start using it immediately and then learn the nuances of what else they can do with it later. That's why Water allows you to use XHTML directly in Water: valid XHTML code executes natively in Water, so if you can program in XHTML, you have an instant start with Water. However, it's easy to define (and style/format) your own "tags" in Water (they're actually object classes), so you can extend (or replace) XHTML as desired.

Ultimately, defining a new standard like HTMLv5 is all well and good, but meaningless until the browsers all implement it... and let's face it, they don't even have completely compatible implementations of any of the old standards yet, and here we are talking about a new one. On the other hand, by using a system like Water which can take a standard format and convert it into the browser-specific nonsense, we could create cross-browser compatibility for a new standard practically as quickly as we could spec it in Water.

I did some fairly extensive work with google maps, and I can say that their API is very well documented.

Personally, I wrote a local API for it in the language I'm working in, Water, and let Water deal with all the Google stuff for me. By mixing Water's AJAX features with Google's map API, I was able to create a fully AJAX enabled map API which notifies the server about every user action on the map, including clicking, dragging, etc, and deals with user initiated actions in an object oriented manner (for example, if a user clicks on a pin point on the map in the browser, it fires an event in the corresponding place object in the server). I also created an interface to KML, the language which was used by Google Earth and which is sometimes used by google maps now. KML is also well documented. I linked that into our place objects as well, so you can easily get a google map or some kml for any place object. KML is also useful because some other commercial mapping products are now starting to use KML as well.

I certainly wouldn't have been able to do all this without excellent documentation and a rich API from Google. Thanks to them providing both, the implementation went quickly and easily, and now Water has a fabulous map API thanks to Google making it all easy. And yes, I do have a clue what some of the alternatives are: prior to doing the implementation with Google Maps, I did another implementation using government services. (Actually, both are just subclasses of our abstract cartographer class, so it's a very direct comparison.) Google offered a much richer and easier API.

I did look at some other online mapping services, and if they offered an API, I found them to be more limited.

I can't comment on the Microsoft API or documentation, I haven't tried them.

Java? What is this "Java"? I program in XML.

Plusch is an MIT and Sloan School graduate, whose drive for speed is well balanced by Fry's more cautious approach. Originally from Ohio, he had a particular dislike for programming, until Water came along. Plusch's business drive is a good foil for Fry's arts and sciences orientation.
Both Plusch and Fry are authors and oft-requested speakers on the technical conference tour. Fry has been published numerous times in the Communications of the ACM. Plusch has several books under his belt including, "Water: Simplified Web Services and XML Programming", published by Wiley.
Plusch was asked just how committed he is to the Water language. He responded, "I would not be surprised if I end up doing Water related work for the rest of my life. I'm considering getting my first tatoo -- the Water logo."

Along the lines of "LISP with ugly parens" is the Water project at MIT.

I've had my own adventure along these lines (Unigrok really *is* XML) but you sort of run into problems embedding a real language into XML because of function return values.

As in how would your "syntax" indicate returning values from a function or user-defined tag. Try to be too general and pretty soon you've got XSL on your hands (and still haven't solved the problem).

I think it's lame, but if you're interested then check out the Water programming language at waterlanguage.org