Re:some issues.... (Score 1)

Are there any performance issues with REXX, especially for large implementations?

I've only ever found huge file io a problem. Solution is to replace linein(File) with charin(File,,BufferLength). You can write your own linein() definition and the interpreter will find it before finding its own built-in linein(). Not sure that's terribly good design but it can be useful.

How much can you do self-contained in REXX today?

date(), time(), stream() (querying file attributes) is about it; everything else is OS-transparent only if it's spelt the same etc.

Like perl, are there ways to be strict with REXX (it wasn't totally apparent from the article)?

Yes. signal on novalue is the main one: it traps the use of undeclared variables.

Is REXX really that popular out there?

I believe it's very popular with mainframe sysadmin types, who don't do applications, natch.

Is anyone else uncomfortable with case insensitive languages?

Nope :-) The rexx philosophy is that since eNgLiSH is case-insensitive, even with proper names, so should the programming language be, except for inside quotes of course.

I didn't think the original article was that good actually. It didn't mention the built-in tracer, which is brilliant, nor the parse command, which is odd but handy. Nor did it mention the main lack, regexps, over (under?) perl, though there are regexp function libraries for some envs.

The clarity is the main thing: I once had to analyse the obscure reaches of some pseudo-code in an AI paper for a masters assignment and was able to type it in almost to the character in rexx, then put in loads of variable displays and other traces. Found a bug in the paper, got an A...