Recently, some people have asked on the Selenium mailing list why HTML Selenese (the language of Selenium Core) doesn't include conditional "if" statements or "for" loops, or, more generally, why there isn't some way to reuse code (with functions or subroutines). Adding them in would be pretty straightforward. (Andrey Yegorov has written a "flow control" user extension that provides support for "if/goto" statements in HTML Selenese, but you really shouldn't use it.) In this article, I'm going to explain why we don't just add support for conditionals and loops directly into Selenium Core (which is also why, in my opinion, humans shouldn't write tests that use the flow control extension). In some cases, nothing is better than something, when the something is considered harmful.
Goto Considered Harmful
The main reason why we don't want to add support for a "goto" statement in HTML Selenese is that the Go To Statement Is Considered Harmful. In his classic 1968 article for the Association for Computing Machinery, Edsger W. Dijkstra successfully argued that use of "go to" statements (or "jump" instructions) makes one's code less intelligible, and that "the go to statement should be abolished from all 'higher level' programming languages (i.e. everything except, perhaps, plain machine code)".
Adding a "goto" statement would completely undermine the entire point of HTML Selenese: simplicity. Straightforward non-branching tables are easy for non-programmers to read and understand. Many Selenium users report that their customers are able to grok Selenium tests (and even fix bugs in them), which gets more people involved in the testing/requirements gathering process. If we added "goto" to Selenese, and people actually used it, that kind of end-user/developer interaction would come grinding to a halt.
Nobody Needs to Write a Goto Statement
Ultimately, though, all of our programs are ultimately compiled down and assembled into plain machine code, which makes ample use of "jump" instructions in order to get its job done. Under the hood, all of the fancy object-oriented features available in higher level languages are automatically translated into "goto" statements by compilers (who guarantee the correctness of the resulting assembly code).
[In fact, as I understand it, that's exactly how Yegorov uses his flow control extension: he never (or rarely) writes HTML Selenese by hand, but rather he generates his HTML Selenese from another higher-level programming language that makes no direct reference to "goto" statements. In a very real sense, he "compiles" a higher-level language into HTML Selenese. (Please correct me if I'm wrong about this; I'm basing this on an old post of his from March 2006.)]
That's certainly one way to do it, but I argue that it's totally unnecessary. He could simply run his tests in a high-level language directly with Selenium RC.
Implementing Proper Flow Control
For one thing, that's too difficult. While JS interpreters have been getting more and more compatible as time goes on, it's still very difficult to write a complicated program that behaves the same way in all browsers, say nothing of writing a full language parser/interpreter in JS.
(In another article, I'll write up exactly how far people have gone in this direction... it's not pretty.)
Easier to Read/Translate Without Flow Control
Finally, there are two important advantages to not supporting flow control in HTML Selenese, even if we could do it "right".
1) By limiting the expressive power of the language, we make Selenese substantially easier to translate into other languages, as we do in Selenium IDE. You can use Selenium IDE to translate HTML Selenese directly into any language that we support in Selenium RC. If we supported writing tests in a "full language", we wouldn't be able to provide translators into all of those other languages. (Language translation is hard; the problem is substantially simplified when you don't have any sophisticated language constructs to translate.)
2) HTML Selenese is about simplicity; that's the whole reason the language exists. Turning HTML Selenese into a full-blown scripting language, with all the advantages that would bring, would still undermine its simplicity (though not as badly as implementing "goto").
If you want a scripting language, use a scripting language! We support that 100%! :-)
In another article I'll discuss a few of our failed attempts to support a full language parser/interpreter in JS.