[Copyright © IBM Corporation, 1994]
Designs that provide for human variability and preferences inevitably are more costly to implement than those that ignore human nature. The most obvious cost is in performance; for example, Rexx's decimal arithmetic will be slower than binary arithmetic until manufacturers start providing hardware support for user-friendly arithmetic. Rexx's dynamic nature means that, even with advanced compilers, programs in Rexx are usually slower than those written in languages that move most of the burden of data conversion and typing onto the programmer.
Even so, as hardware speeds increase exponentially, Rexx becomes useful for more and more applications. To illustrate the magnitude of this change, the first Rexx implementation for PC's ran at about 115 Rexx clauses (statements) per second on the original IBM PC. In 1994, on an IBM PS/2 9595 using the Intel Pentium chip running at 66MHz, OS/2 Rexx runs at over 40,000 clauses per second -- enough for substantial processing at human response rates.
The second disadvantage of Rexx is that it is relatively hard to implement. This, however, is a task that is done infrequently; the investment rapidly pays off in improved user programs and productivity.
Finally, Rexx's data type, the string, is not well supported by many other languages, so there can be extra cost involved in data conversions when Rexx invokes or uses programs written in "lower-level" languages such as C or BASIC. This cost can be important when small programs with little function are called, but if significant processing is to be done then data conversion on entry and return is relatively inexpensive.