One key difference between automated functional test scripts and application code is their target audience. The application code is developed and maintained by programmers, while the test scripts may be developed, executed and maintained by testers, developers, business analysts and even customers (_this backed by the fact TestWise is the most used software product for projects I know using it_).
The fact is that testers, business analysts and customers generally do not possess strong programming skills, and this changes the whole paradigm. It is not hard to imagine that a 85MB download of Eclipse (a Java IDE), configuration of library path and JDK path will do to a non tech-savy tester as the first chapter of automated testing orientation program. And you might hear screaming minutes later: "What does 'compiler error' mean?".
I believe automated tests shall use interpreted/scripting languages (such as Ruby) instead of compiled languages (such as Java), maybe that's why they are called "test scripts". And as a functional test script language, it should have following characteristics:
easy to learn,
no compilation required,
concise, readable syntax,
extensible syntax to use domain specific language,
Acceptance tests integrated into the continuous build server provides team members constant feedback, its benefits is quite obvious. Here I show you how to include web acceptance tests (using Watir) in CruiseControl server for a typical Java/J2EE project.