Opa vs. Node.js: What If Things Go Wrong?, Page 2
Opa vs. Node.js: What If Things Go Wrong?
We all know that writing the code isn't the last step -- often the "fun" begins only then with testing and debugging. Therefore, it is only fair to see how the languages compare in that respect. In fact, there are three aspects to consider here: how well the languages help detect errors, their support for debugging, and their support for testing. We will not look at testing in this article as both languages are quite comparable in that respect. We will begin by looking at debugging facilities.
GET http://localhost:8001/join?_=1327952561187&nick=akoprowski 400 (Bad Request)
and pointed to the place where the relevant Ajax request was made. It will then still take some work and debugging experience to link this error with the typo that we introduced.
We then made equivalent error in Opa's code replacing length with lenght here. Opa would now not allow us to run such a flawed program and reported the following error (shortened here for presentation):
File "src/main.opa", line 152, characters 21-28
Expression has a record type incompatible for access to field lenght. […]
Hint: Perhaps you meant length or merge?
We then tried a similar test with user-defined data-types. We replaced text with txt in the record defining a chat message in Node.js and in Opa. The results were the same: runtime error in Node, not directly related to the problem and a clear error message in Opa.
Then we decided to see what would happen with malformed HTML, an important building block for interfaces in both languages. In Node.js in tables presenting chat message, we replaced the second closing tag with "," which resulted in a working program (modern browsers are quite good at "fixing" markup errors) but wrong presentation. We also played with some other similar markup errors, some of them leading to difficult to spot deficiencies in the output.
In Opa's example, tables are not used but when we introduced this very error to the snippet presented in the Server-/Client-side Separation and Communication section, we got a clear error message:
Hint: File "src/test.opa", line X, characters X-X
Open and close tag mismatch
We got similar compile-time errors when trying other variants of flawed HTML.
Finally, we tried playing with arithmetic errors. Both in Node.js and in Opa, there are equivalent functions computing memory usage in megabytes. Just to keep things simple, we replaced the second occurrence of the number 1024 with a string "1024." We found similar results: an undefined runtime error in Ajax call for Node.js and the following compilation error in Opa:
File "src/main.opa", line 91, characters 28-41.
Function was found of type 'a, 'a -> 'a but application expects it to be of type int, string -> 'b.
Types int and string are not compatible.
While the above error message may not be very clear for somebody who never used Opa, take our word for it -- for regular Opa users this is as clear as a day.
To sum up, we think those results are quite astounding. A large class of programming errors that goes unnoticed in Node.js and requires heavy testing and debugging is automatically detected in Opa and reported with helpful (most of the time) error messages. And we only scratched the surface, as Opa is actually capable of detecting much more involved problems than those presented and discussed here.
This should not be overlooked and is perhaps the most important feature distinguishing Opa. It also corresponds to something that Haskell programmers know for years: with a properly designed language it is possible to write "almost correct" programs at the first go and tremendously decrease time and effort spent on debugging and testing.
Originally published on http://www.developer.com.
Page 2 of 2