Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Catch
As with all new things, Water still has a few kinks to iron out.
Because the Water language specification is new, it's still evolving. Code written in earlier versions of Water sometimes breaks when a new version of Steam XML is released by Clear Methods. This issue has been smoothing out over time, but right now it makes coming up with stable demonstration code difficult. In their defense, I must say that I've found Clear Methods and the Water language community very helpful in answering questions and responding to bug reports. I'm told that the next major release of Steam XML is due out shortly.
Also, as all programmers know, when a language makes something easy, it usually takes away a certain level of flexibility. This is true with Water and Steam XML. One example that comes to mind is a form I created that accepted credit card information. Steam let me set up a server that interacted with the form very easily, but the credit card numbers were converted to decimal format by default because they were too large to be stored as integers. They looked like numbers; therefore, they were coerced into a numeric format by the server, presumably to save the programmer some steps in converting data. In this case, however, the floating-point credit card number lost digits of precision in the process, and lost digits on a credit card number means that the card number is invalid. Not good. This situation was fixed by returning strings of digits above nine digits long as string data that can be parsed or converted to Java BigIntegers.
As an interpreted language, Water also has a (in some cases large) speed disadvantage. In one application I was testing for doing Base 64 conversion, Java performed the conversion in 0.016 seconds—Water took 15.0 seconds. The upside is that I can use those same Java classes in Water and pull the speed gain right into my Water program!