Slashdot Mirror
Rexx for Everyone
An anonymous reader writes "It's easy to get lost in the world of 'little languages' -- quite a few have been written to scratch some itch of a company, individual, or project. Rexx is one of these languages, with a long history of use on IBM operating systems, and good current implementations for Linux and other Free Software operating systems. Rexx occupies a useful ecological niche between the relative crudeness of shell scripting and the cumbersome formality of full systems languages. Many Linux programmers and systems administrators would benefit from adding a Rexx implementation to their collection of go-to tools."
Useless? Sure, but it looked a lot cooler than your average progress bar, and I could poke my head into the room to see at a glance how far along I was on my hour-long 2MB download from Aminet (via a 28.8 modem).
Dewey, what part of this looks like authorities should be involved?
>> Its good to have diversity in your language choices, because different languages have different strengths and weaknesses, and having a good command of more than one can often make you much better, individually.
One issue is that rexx when compared to perl, pales in comparison. There are reasons for diversity with regard to differnt language styles, as each serves a niche, but you're kidding yourself if you think rexx serves any purpose for future scripting development.
There are reasons for python, perl, tk/tcl, C, C++, C#, java, lisp, and even smalltalk... but rexx? Lacking in the strengths of perl, and yet having more glaring weaknesses, with little in the way of development and integration that perl already has in a stronger and more up to date fashion.
Only reason to learn rexx is to help support previously written applications that would require too much time and effort to rewrite in a better support scripting language.
Rexx is the embedded scripting language in the terminal program Zoc. This is the only windows client I've found that I particularly like and one of the main reasons I chose it way back in the day was because of it's powerful scripting language. I don't script muds anymore, but if I did I'd be glad for its continued existance. As far as using rexx for assorted small programming tasks I can't vouch for it, it's compromise between absolute simplicity and power/flexibility makes it fill the terminal scripting niche pretty well, imho.
I owe a lot to REXX. I used to love REXX. Back when I was a co-op at IBM I spent two years doing nothing but REXX on VM/CMS (note to youngsters: it was an OS for the 370 family). It paid for my car and a trip to Europe. But more importantly it got me used to scripting languages. After learning REXX, it was a small step to Perl (version 4.036). Since I learned Perl, I've never looked back at REXX. I'd be amazed if REXX hadn't evolved once it got off of mainframes, but I really doubt if it can do anything that Perl can't. They are both in the same nitch, but Perl has one thing that REXX doesn't: Perl is more fun. When everything else is said and done, enjoying your time at work is a huge advantage.
Life is too short to waste on REXX. Stick to Perl have fun.
- doug
Yeah, I can see right away why I would want to write programs in this language. No object model. No regular expressions. Cobol-like syntax. This is more like BASIC (and not even the Visual variety) than Perl or Awk.
I know it may come off as such, but this really isn't meant as flamebait. I just really don't get why people would want to write new code in such a dreadful language.
(To be fair, I think the same of PL/SQL coders; but at least they have a good reason -- "Larry made me do it.")
the growth in cynicism and rebellion has not been without cause
In the kde world DCOP goes a long way toward providing this very powerful although easy to use app-scripting environnement. Almost all KDE Apps have a useful DCOP interface.
If think AppleScript is good too in the Mac-world (never tried this one)
My perception is that, these days, many people who use scripting languages tend to know two or three. One is generally bash/Perl/VBScript, and the other is a (for want of another term) "more modern" scripting language such as Python or Ruby.
bash and Perl are ideal for ripping together short scripts that do relatively simple things. The problem you often encounter with these languages is that it's hard to maintain scripts of more than a few hundred lines unless you're very disciplined in how you structure your code. VBScript on Windows sits in this area as well.
Python and Ruby fill the >100 line script niche by adding nice OO features. Python and Ruby scripts are generally easier to support than bash/Perl scripts once you get beyond a few hundred lines of code.
TCL seems to sit somewhere in the middle. I've never met anyone who actually uses it regularly, so I'm not really competent to slot it in anywhere...
Where does Rexx fit? Frankly, these days, it doesn't - these tools pretty much have the market cornered on both Windows and Unix platforms. New tools will emerge to split the "market" further, but to do that they'll offer some compelling extra feature to get people to switch. Rexx, being an existing solution, isn't likely to offer that compelling new feature.
The question Rexx advocates need to address is "Why would someone *switch* to my language?". In order to answer that, they need to be able to reasonably objectively discuss the pros and cons of Rexx vs. Perl/Python/bash/..., and I don't know of many Rexx people who can do that; they tend to know Rexx and nothing else in the scripting space.
> Language Diversity.
Language Diversity rules. However, a really good language ought to be designed
so that you can use diverse programming paradigms within the limits of that
language. Perl is taking some steps along these lines. Perl5 already has very
good support for procedural programming, basic functional programming, basic
contextual programming, and with a little work you can get it to do basic OO
programming also. Perl6 is revamping the OO stuff to be a first-class citizen,
as well as bolstering the contextual and functional stuff too. (There's even
talk of continuations and lazy evaluation.) There is also talk of adding
support for logical programming (a la prolog), but I don't know whether that's
really going to happen.
There's still work to do, of course. Perl6 is a long way from being ready.
But the list of languages that have influenced its design is *lengthy*.
Right now, there are things I can do in elisp or Inform easier than in Perl5.
The object model coming in Perl6 will shorten that list to just elisp, and
it will be possible to implement textbuffers using the Perl6 object model;
if someone (such as myself -- I'm seriously thinking about it) does so and
puts it on CPAN, then I won't need elisp either, except for customizing Emacs.
So now I'm learning Scheme, which has some *more* things Perl5 doesn't have,
such as continuations -- but word has it these things are going to be in
Perl6, so I figure I'll get a leg up on the concepts by understanding them
in Scheme now.
Hopefully, multiparadigmatic VHLLs such as Perl, Python, and so forth will
utterly take over, eventually, except for extreme low-level stuff like
bootloaders and device drivers. For that to happen, we'll probably need
optimizing compilers for these languages, or a really good, ubiquitous VM.
(Parrot hopes to be the latter. We'll see how that goes. The Java VM is
almost ubiquitous enough, but it's not good enough, and none of the VHLLs
target it AFAIK (presumably because it's designed especially for Java).)
Cut that out, or I will ship you to Norilsk in a box.
Sure, but I was doing this on production systems in 1990. As I said, I'm not advocating REXX. However, it had a lot of really cool features that didn't seem to be in wide existence anywhere else at the time it came around. Python is much nicer than REXX, and I love it to the point that it's my primary development language, but REXX was alive and doing the same stuff (on a more primative level) nearly 15 years go. You have to give it some credit for that.
Dewey, what part of this looks like authorities should be involved?
Language diversity isn't necessarily a good thing. Some really cool code (cvsup and portupgrade) has been kept out of the FreeBSD base system because it would require importing yet another language (modula 3 and ruby, respectively).
Of course, if you're a closed-source programmer, you can use whatever compiled language you like; but with open-source code, using obscure languages imposes a cost upon your users and limits your code's usage.
Tarsnap: Online backups for the truly paranoid