One way to test an engineering technique is to see how projects that tried it have gone. If the project fails, you suspect the technique is bad. If the project succeeds, you suspect the technique is good. It's harder than it sounds to make use of such information, though. There are too few projects, and each one has many different peculiarities. It's unclear which peculiarities led to the success or the failure. In a word, these are experiments are natural rather than controlled.
One kind of information does shine through from such experiments, however. While they are poor at comparing or quantifying the value of different techniques, they at least let us see which techniques are viable. A successful project requires that all of the techniques used are at least tolerable, because otherwise the project would have fallen apart. Therefore, whenever a project succeeds, all the techniques it used must at least be viable. Those techniques might not be good, but they must at least not be fatally bad.
This kind of claim is weak, but the evidence for it is very strong. Thus I'm surprised how often I run into knowledgeable people saying that this or that technique is so bad that it would ruin any project it was used on. The most common example is that people love to say dynamically typed languages are useless. In my mind, there are too many successful sites written in PHP or Ruby to believe such a claim.
Even one successful project tells us a technique is viable. What if there are none? This question doesn't come up very often. If a few people try a technique and it's a complete stinker, they tend to stop trying, and they tend to stop pushing it. Once in a while, though....
Once in a while there's something like synchronous RPC in a web browser. The technique certainly gets talked about. However, I've been asking around for a year or two now, and I have not yet found even one good web site that uses it. Unless and until that changes, I have to believe that synchronous RPC in the browser isn't even viable. It's beyond awkward. If you try it, you won't end up with a site you feel is launchable.
Subscribe to:
Post Comments (Atom)
2 comments:
I am pretty sure I covered this already in our discussion on LtU.
In addition, more basically, I think modeling remote procedure calls in a distributed application is folly. The reason is that a procedure call, remote or not, dictates control flow. In a web application that supports multiple services, such as an online client and a fallback offline client, there is no way to do control flow. Everything has to be nondeterministic refinement of data flow. Every "procedure" has to be given fair access to the scheduler, and the trick is to build a system that determines the flow of control on demand. It is actually also possible to prove programs correct in this style, and show that they have important properties for distribution and federation; such a style for composing services was proposed in the '80s but never was adopted due to immature theorem proving tools. With todays tools, good engineers might be able to pull it off. The trick then becomes how to make this uber-hacker technology easily usable by Otis Tackleberry and Suzy Creamcheese.
Just 2 cents.
Just to be clear, the reason why you want to avoid control flow is that it requires explosion in error handling strategies, because errors form a contextual net with all the states in the system. There are state machine strategies for avoiding explosion of those mathematical formulas (expressions), but they're not directly related to problem domain decomposition.
What that indicates to me is stuff like GWT asyncCallback fails the same test as synchronous remote procedure calls, because the way asyncCallback works, it can't handle such explosions, because it induces a very specific control flow graph and that control flow is not obvious to the programmer (IMHO).
Bottom line: You still have to justify why you think "synchronous" remote procedure calls are the problem. And the other, bigger, question, is how well do asynchronous remote procedure calls actually fair when measured using various software engineering qualities?
Post a Comment