The Merging of REXXes?
There are many more Rexx implementations in existence than I thought necessary to cover all the different environments. For most environments there are at least two - if not more - implementations to choose from. There are exceptions; Amiga-Rexx and TEXX are as far as I know the only ones for the Amiga and MacIntosh, respectively. But there are three (or more) Rexx interpreters for DOS, for Unix, and for OS/2. And I'm not even taking into consideration anything other than classic Rexx.
In addition, not all implementations for the same platform adhere to the Rexx standard in the same way or to the same degree. "Which standard" is not a valid question for me; there's only one, and that is ANSI X3J18. Note that this is not about extensions outside the standard.
My wish is simple. It's to see the developers and maintainers of those Rexx implementations for the same environment work together to merge their versions into one - that conforms completely to the ANSI standard. But its implementation certainly isn't simple and easy. Some of these Rexxes are freeware, some cost money. And I'll certainly side-step issues like good/bad regarding freeware/for-money.
Still, imagine a merged version of for example BREXX, Regina, Personal REXX, uni-REXX, REXX/imc, and S-REXX that covers the DOS, OS/2, Unix, and Windows environments. Ideally, include Amiga-REXX, IBM-Rexx, and MacREXX (sorry, I mean TEXX) to cover the Amiga, MacIntosh, and mainframe areas. If the people involved could agree on using the same basic engine, a huge step forward would be the result in respect to conformity and cooperation. And they could each still add their own extensions, that being one of the reasons user select one implementation over another - given the choice. Other reasons include maintenance, support, and paper manuals.
A plus-point for such a setup is that maintenance of the basic engine can be done by a (much) larger group of knowledgeable people; those who designed this basic engine (and their own original version) in the first place. So if I discover a bug in (say) REXX/imc for DOS - that isn't part of an extension - then bringing it to Ian's attention will be a boon to ANY user of Rexx, whichever implementation or environment. Because the basic engine gets fixed, the fixed engine goes to all its suppliers, and thence to the users. So a problem caught in a Mac version may well result in happier users in VM/CMS. Of course, Ian may well choose to supply (and support) a Rexx only for Unix. No reason not to.
Another plus; it frees up time and people for interesting things, like improving manuals, or - finally - having some time to think creatively on extensions to the ANSI standard. Or spend more time relaxing at home with the family. Porting of Rexx programs would become a lot easier, right? No need to consider differences within the standard, just those relating to platforms and supplier-specific extensions.
"Why should I pay for Ed's uni-REXX when I can get the same thing free from Mark?" Because they are NOT the same; the extensions are different. Also, there's a difference in support from the various suppliers. Not to mention printed manuals (too expensive for freeware implementors), and the interfaces to various related products; Charles' RexxTerm might not work with any Rexx on IBM mainframes. "It just moves the problems from one level to another" you say? True. But we all gain; users due to the conformity, and suppliers from a larger base of knowledgeable people to draw on - who also have a smaller package to worry about. Isn't that worth something?
Vendors need to recoup money spent on something, else they'd be out of business real fast. But if their investment is (quite a bit) less, then there's also less they need to recoup. " Vendors aren't allowed to sell GNU-software." Right. So IBM's users would pay for IBM's share in implementing the combination of basic engine plus IBM's extensions, but NOT for the basic engine itself. Meaning, the basic engine is always available for anyone who wants to use it under the GNU license (if that's what the original group of implementors agreed on). "But then I," says a vendor, "cannot charge customers what I'm charging them now." So very true. I would expect the prices to go down, which in turn leads to more sales, which MORE than makes up for the difference!
"What if a certain extension is added to the Standard, but MY supplier doesn't support it (yet)?" If you really want or need it, you can always badger your supplier, or go to one that does support it. You have a wider choice of suppliers, for one. With the basic engine being the same for all, it's much easier for your supplier to get the necessary code and add it in. In fact, if something *is* added to the Standard, then all parties will *want* to supply it; their user-base will decrease if they don't. Freeware OR for money.
Also, it becomes more difficult to find a crippled version of the basic engine; all suppliers will want to have the latest/greatest version soon. So something like MS incorporating a "crippled" version of Regina in some platform of theirs will be likely to happen.
But let's first see if we make it through the Y2K scare/problem, and then determine if things have changed enough to try such a collaboration.