Slashdot Mirror
O'Reilly on the Virtues of Rexx
gaijincory writes "O'Reilly's ONLamp has written an interesting article on the history and virtues of Rexx, the first widely used scripting language concocted 25 years ago. According to the review, 'Rexx employs decimal rather than binary arithmetic' and 'You don't need to declare or predefine your variables. Rexx automatically allocates them when you first refer to them.'
I'd be interested to hear about any success (or failure) implementation stories."
Rexx employs decimal rather than binary arithmetic. [...] You don't need to declare or predefine your variables. Rexx automatically allocates them when you first refer to them. Are these supposed to be positive points? Because it kind of flies in the face of coding best practices...
"I'm a first year programming student at an Ivy League school and I've just finished my Visual Basic classes."
As Ann Landers would've said, "An Ivy League School in New Haven?"
In the 70s there was a de facto competition among a bunch of Yale students to try to get some preposterous story accepted and published in her column. Parent proudly upholds the tradition.
IBM made it available for nearly all of its operating systems. In particular, it was extremely handy if you were on a VM/CMS system.
(S(SKK)(SKK))(S(SKK)(SKK))
In some languages, like perl, the compiler will warn you about dynamically allocating variables if you have the appropriate options turned on. I am not sure if REXX has a similar flag. The dynamic scope of variables was mostly a feature for people who were just writing shell scripts and what not, where you only had global scope anyway.
I used to be the VM/ESA systems programmer (king geek) for a state university (I'm still at that university, it's been over 21 years).
REXX was the first serious scripting language that IBM delivered for VM (EXEC was awful and EXEC2 not much better). Our systems development (applications) staff wrote quite a number of in-house REXX applications interfaced to DMS/CMS (this was before ISPF was very usable under VM). Most of these were working with CUFS (later Advantage). I used REXX extensively to match-merge two files, generate reports, and reformat data. I also rewrote some programs in REXX that had originally been implemented in SNOBAT (a snobol4 dialect for System/370).
Roll forward a few years. All the sudden, I'm responsible for Unix servers as well as VM. Although I installed regina on our Unix servers, I figured out pretty quickly that perl was the preferred script language for Unix (I first installed 4.0.36). I saw that there were a lot of facilities and working scripts in perl that I'd have to build for myself in REXX, so I made a point to learn perl. I still used REXX for things that interacted with our VM/ESA and z/OS & TSO/ISPF environment.
Roll forward a few more years. IBM drops HESC, and VM becomes prohibitively expensive to keep. Meanwhile, our academia is moving to Unix and PC-based teaching, and a Unix-based ERP is on the horizon. We decided to eliminate VM. I spent quite a few hours writing perl scripts to parse DMS/CMS panel sources and REXX programs, to build ISPF panels and generate ISPF-friendly REXX from the DMS/CMS REXX code (fortunately most of the code was cookie-cutter so it was easy to do a find/replace). I knew these programs would be eliminated when the ERP was in place.
Now I'm so neck-deep in Oracle (database, application server, and other toys) and SCT Banner that I maybe spend 10 minutes a day on our z/OS system, and haven't written a new program there (in any language, much less REXX) in six months. I still maintain or help debug a REXX program now-and-then.
REXX was a success, but for us VM died. I still like REXX, but perl has pretty-well replaced it for me. The last time I wrote a REXX program I caught myself writing perl-isms into it that I had to fix.
Doug
REXX's history isn't even really mentioned.
First of all, REXX is hardly the first popular scripting language, there were lots of them before it. REXX was designed as an alternative to EXEC2 which was a replacement for EXEC and that's just on IBM's VM mainframe systems. Listing other scripting systems prior to REXX is left as an exercise for the reader.
As for history, REXX wasn't developed as an official IBM project. It was developed as an internal tools project by Mike Cowlishaw at IBM's research lab in Hursley, England (the VENTA lab) because EXEC2 basically sucked. It was distributed on IBM's internal tools system (VMTOOLS and IBMVM) and became hugely popular inside IBM.
It was made available as an unsupported tool through the IBM VM user group and became so popular that despite IBM managment wanting EXEC2 to be the "official" scripting language, nobody in their right minds used EXEC2 and REXX became almost universal. Pressure from their commercial VM/CMS and VM/XA users forced IBM to make REXX a supported product.
In the mid 1980s, a PC version became available internally on the IBMPC and PCTOOLS systems and quite a few internal tools were written in REXX but despite internal popularity, IBM didn't release the PC version of REXX until much later when a vastly expanded (some would say bloated) version was released as a fairly expensive commercial product.
As a side note, REXX was released as a scripting language for PCs with later versions of OS/2 but by that time OS/2 was insignificant in the PC industry.
One unrelated note, Cowlishaw is also famous as the keeper of the IBM Jargon Dictionary - a tongue firmly in cheek listing of IBMisms.
This is why I *ALWAYS* begin my PHP scripts with:
have made Rexx open source: get yourself some of that here
At the time however, it wasn't a relatively small group of consumers, if one was referring to consumers that use computers.
People must put things in context. The Amiga started out with a very large percentage of marketshare. It was only in its end years that market share dwindled so, via incredible growth in _other_ market shares.
For a while, REXX was a very dominant programming language. Then again, so was TCL for a while, and so was BASIC.
The most obvious drawback in REXX is that the standard I/O calls don't work on the mainframe (where you have to use EXECIO calls), so it's not very portable. Really, REXX's biggest benefit is its tight integration with TSO (the mainframe command interpreter) and ISPF (the screen interface and editor). When REXX is by itself on other platforms, these benefits disappear. I use REXX on MVS (now called z/OS), but it just pales in comparison to Perl or Python for other environments.
Keep in mind REXX predates the adoption of C-ish syntax (C, C++, Java, Perl, Python, PHP, etc), so it's not as easy to switch gears mentally as it would be among the C-ish family. As you'd expect, the syntax has its quirks, especially if you don't use it much. None of the standard library functions has names like C's, unlike Perl and PHP. Truth be told, REXX looks a whole lot like structured BASIC.
REXX is quirky. You can use stems as associative arrays, but there is no mechanism to iterate over them. (I'm not joking.) No regular expressions built into the language like Perl has. No built-in systems programming interfaces (you have to ADDRESS the operating system to run commands, like bash, etc. - more of a flow control language like bash than an environment like Perl) While there are modern extensions like OO for REXX, they're not standard in all REXX interpreters, and are as clumsy as adding OO to BASIC, Fortran, COBOL, and other pre-C languages.
WROX has a REXX book, the only new one in ages and ages. Unfortunately, it concentrates on non-mainframe platforms where there frankly isn't as much to talk about because you don't have the tight integration with the OS.
The problem is just how javascript defines dynamically allocated variable. Try to do the same thing in Python and it will work the way you want it to.
Ewige Blumenkraft.
... REXX is yet another interpretive scripting language, one that is exceedingly clear and non-cryptic -- one can return to a REXX script you wrote a decade ago and understand it (try that with perl!).
And REXX has a much easier learning curve than something like perl, even easier (IMHO) than plain vanilla unix hell scripting. If you're in a large group or a group with a high turnover, you could do a lot worse than selecting REXX as a scripting standard.
For specifics as to why you might choose REXX over another scripting language in your toolkit, it has tremendous parsing capabilities (you can specify a template when you read text from the input stream, and have REXX bust up the incoming text to fit the template, adjusting case if desired) as well as very nice ways of dealing with arrays ("stems" in REXX parlance).
One of the niceties of using REXX in the mainframe world was that you could specify the environment a command string would be interpreted in. Not quite AppleScript, where you can direct scriptable apps to do your bidding, but the next best thing.
This allows you to co-opt other portions of your system to do the work for you, and not reinvent the wheel at every turn. Think of this as the "script as conductor" philosophy of scripting.
But REXX is also capable of functioning as a standalone programming environment. In the mainframe realm, I've done socket programming, dynamic sql, screen painting and more file conversions than I want to think about using REXX. I do code using a fair assortment of compiled languages, but when it's crunch time, nothing beats a good interpretive scripting facility to deliver the goods in a timely manner.
Sadly, aside from the unix/dos command shell, I don't believe many other environments are generally supported under non-mainframe REXX (I don't believe I've ever seen REXX operating as an EMACS macro, for example), but given the flexibility of the unix shell environment, that is generally sufficient.
It's still used in IBM mainframes, and is the scripting language of choice in OS/2 (which is _still_ in heavy use, though not at home).
:
For those of you NOT clued in, Rexx also comes as ObjectRexx, which, as you might guess is fully object oriented.
IBM has completely open-sourced it, and there is also a second open-source implementation (Regina Rexx).
Check out what's been going on at
http://www.rexxla.org/>
For 90% of what people use a scripting language for, Rexx beats the pants of Perl. it's easy to use and it's _readable_.
On many platforms, you can construct full GUI apps with it too, from paint programs, to GUI unzippers, etc.
Oh, it's nice enough! My preferred scripting language along with Python. I've easily written stuff like converters from BSDL (boundary scan description language) to XML, even a simulation of 3-d nuclear spin diffusion in sparsely abundant cubic lattice.
I almost forgot. The main reason it was handier than sliced bread on the amiga is that NO other language on any other platform had the concept of an ARexx "port" for direct communication from one process to another.
I don't think it was anything but a name to address translator where the buffer named had to be read before another write to it was performed else the system went up in copious clouds of profanity. But if you paid attention to your housekeeping it was at least as stable as writing to a disk file, and a heck of a lot faster.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
A very clever play on words that seems to be something like the old "fill in the blank" stories.
Was around a few posts back, but then it was about deploying JAVA on the desktop.
No, REXX is shit. It sucks, it bites, it blows syphilitic goats through coffee stir-sticks. I'd compare it to the aborted offspring of third-generation addiction research monkeys if the Crackmonkey Defense League wouldn't picket me for it.
Why, I hear you ask, am I so violently opposed to this allegedly powerful "scripting" "language"? It's because I once had to use it.
I wrote a test harness with it. You know, one of those things that scripting languages are supposed to be good for? You'd think REXX would make such a task easy, wouldn't you? You'd be wrong.
How do I hate REXX? Let me count the ways:
You know? Procedures, aka functions aka subroutines? Those handy little things that let you subdivide your complex tasks into lots of simple ones? Ain't gottem'.
What it has is a kind of GOSUB-with-arguments that it pretends are real procedures and look enough like them that they fooled me until it was too late.
See, when you find a procedure definition in a reasonable scripting language, it's a no-op, right? It's either an expression that creates the procedure then and there or it's a thing that the interpreter finds in the source code before it starts running the program. Either way, when running through the code, the interpreter just sort of does nothing immediate when it finds a procedure definition.
So all we scripting hacks need to remember to do is to define our procedures before we use them, right?
Well, in REXX, they're labels. As soon as the thread of execution reaches a fake procedure, it wanders right in, up until it hits the RETURN statement, at which point it's an error if you're lucky or a return from some unexpected function if you're not.
And kazam! Good programming habits go unpunished.
And let's not think about the sort of spaghetti code this, uh, feature can lead to. No, really, let's not.
Since the pretend procedures are just labels, there has to be some way to monkey around with the scope to get something like local variables, right? There is. And it's vile.
There's a command (whose name I've mercifully forgotten) which creates a new global scope. You call it in your pretend-procedure and ta-da, everything's local now. Hooray, unless you want to actually access a real global variable. But they thought of that--the command lets you list the variables from the previous scope that you want to access and they get stuck into the new scope.
So far, so good, right?
The problem is that these scopes nest. So if fake-procedure FOO needs to write to global variable BLAT and declares it in its scope-creation thingy, this works fine if you call FOO from the mainline.
But what if function BAR calls FOO? Well then, the BLAT that FOO writes to will belong to BAR's scope unless BAR also declares BLAT to belong to the previous scope. And if QUUX calls BAR, the same thing happens.
So if you want to modify a global variable from a function you have to make sure that every function that can conceivably be part of its call chain cooperates. And if you mess up and don't find all of those cases, there's no warning or error message.
Y'know, there are other problems with REXX but they're not as bad. At least, I could have worked around them if I'd had a decent procedure system. A lot of language brokenness is tolerable if you only ever need to solve it once. REXX doesn't give me even that capability.
To be balanced, I should say some nice things about it:
There we go. That's nice, isn't it?
Like, . . .er . . . bash? Or csh or ash or ksh or . . . .
This is what makes these languages powerful - it's a concept that will never die because it's too useful.
Regards,
Tim
This is all just my personal opinion.
IBM open sourced Rexx. It's available here: oorexx.org.