LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (November 1997)Back to main REXXLIST pageJoin or leave REXXLIST (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Wed, 26 Nov 1997 09:17:59 -0600
Reply-To:     REXX Programming discussion list <REXXLIST@UGA.CC.UGA.EDU>
Sender:       REXX Programming discussion list <REXXLIST@UGA.CC.UGA.EDU>
From:         Doug Quale <qualed@MAIL.STATE.WI.US>
Organization: State of Wisconsin
Subject:      Re: Why REXX is not my favorite scripting language (was Re:
              regular expression matching)
Content-Type: text/plain; charset=us-ascii

Patrick TJ McPhee wrote: > > In article <3475D287.3E3E@mail.state.wi.us>, > Doug Quale <qualed@mail.state.wi.us> wrote: > > % I have always found the idea of multiple external environments to be > % unusual. (Always really only means for 3 years, since that was when I > % was first exposed to the concept.) In typical Unix usage, it is simple > % and inexpensive to connect programs using IPC plumbing, so programs are > % separate pieces designed to work together, rather than than favoring an > % inclusion arrangement. > > This is not true (I'm speaking as a Unix user of more than a decade, > although I'll disclaim that I was a CMS and VMS user before that). > There are a handful of piddly little applications that people solve > using handy pipelines, however this is not the norm, however much people > might want it to be. The norm in Unix is for every application to > implement its own procedural language, and this has always been the > case. A few applications (eg, troff and the compilers) are written in > such a way that you can stick extra programs in their pipelines, but > it's not possible to use features of those programs from within the > pipeline.

I don't really agree. There are a large number of extremely useful applications that people solve using handy pipelines. My experience is that Unix permits solving many problems in seconds that take people stuck with other OSes hours, in minutes Unix pipes handle tasks for which others require days. Far from just a few programs accepting pipes, I have a standard Unix toolchest of well over 100 programs that work well in pipelines. (Most other OSes don't even come with 100 useful programs, let alone 100 that work together.)

Troff is a good example of the pipeline approach, since tbl, eqn, pic and others are preprocessors whose output is piped into troff. (All these are little languages too, but as a tiny nit they aren't really "procedural".)

> > As an example of what I mean by that, if I write a troff preprocessor, > and I want to make a decision based on the size of the current font, I > either have to know enough about how troff processes things to figure > it out for myself (in fact, it's not possible to do this, since some > later stage in the pipeline might change the size of the font, and > there's no way I can know what's coming later on), or I have to > put the formatting instructions for every possible font size and use > troff's procedural language (which I would like to point out is different > from perl, csh, sh, ksh, bc, awk, m4, sendmail, vi, uucp, and all the > hundreds of other applications which originated in the Unix environment, > and nonetheless felt the need to embed some sort of procedural language).

Again, troff isn't a "procedural" language. Do you have a typesetting system that embeds REXX? I'd be curious to see it, since the requirements for typesetting don't seem to mesh well with a procedural language (which REXX is). (Your comments about difficulties in preprocessing troff are correct. Using a more powerful typesetting language such as TeX answers some of the difficulties in using troff, but adds other problems. TeX isn't a procedural language either; it's a macro language. Macro languages might work better than procedural for typesetting.)

> > % Important functions are made available in libraries, but they aren't > % external environments. I understand that OS/2 REXX can use dll's in > % this fashion, which is a good example of that strategy. > > Yes, but the idea of an environment is to provide Rexx to an > application, not to provide the application to Rexx. This isn't to say > that going the other way around is a bad idea, but environments are > definitely an embedded language idea, rather than a CMS/MVS idea. > > ISPF, to use your example, is an application environment which provides > a number of functions related to database manipulation, screen update, > menuing, and so forth. As I recall, it was a horrid environment to work > with. Personally, I wouldn't take a job that required me to come in > contact with it again, but it's definitely more than an application > library.

ISPF doesn't do anything that couldn't be done just as easily in an application library. In fact, that approach would be cleaner. (You're right again though, cleanest would be to eliminate ISPF.)


Back to: Top of message | Previous page | Main REXXLIST page