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 except on computers (such as IBM’s mainframes and POWER series) that support user-friendly decimal arithmetic in hardware.
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 ran at over 40,000 clauses per second – enough for substantial processing at human response rates. In 2012, speeds of almost 15 million clauses per second have been obtained on a PC (see the RexxCPS list).
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.
Please send any corrections or additions to Mike Cowlishaw, firstname.lastname@example.org.
Copyright © Mike Cowlishaw 1980, 2012.