Python 2.2.2 on OS/390 V2R10

[John Roth]

"Dennis Lee Bieber" <wlfraed at ix.netcom.com> wrote in message
news:pn14qa.9l3.ln at beastie.ix.netcom.com...
> <posted & mailed>
>
> Alex Martelli fed this fish to the penguins on Sunday 03 November 2002
> 08:51 am:
>
>
> > Me, I remember Rexx as a pretty good scripting language back from
> > the '80s, when I worked for IBM -- Rexx is what first gave me the
> > taste for using "scripting" languages wherever feasible.  I hear it
> > also took roots in the Amiga world, and I assume it must have
> > grown and developed in the 14 years since I last used it, but I
> > haven't kept track.  But what do you think is "a typical kludge"
> > about it?
> >
>         ARexx was essentially the only supplied programming language
on the
> Amiga once AmigaBASIC was no longer updated (ie, about v2.x of the OS,
> or anyone with lots of RAM -- M$ had designed AmigaBASIC such that
they
> were storing status bits in the upper 8-bits of address registers
> (expecting no one to need more than 24-bits of address). ARexx /did/
> change the I/O system somewhat -- much cleaner than what my various
> REXX books show as normal IBM operations. It also took advantage of
the
> Amiga's message-passing IPC system, with the result that it became the
> macro language for many applications (if you must, it was the
> equivalent of VBA in Office -- except it was still stand-alone also).
> Multiple ARexx programs could talk to each other this way.
>
>         One feature of REXX that is often useful is that any
statement/command
> that is not recognized as part of the language itself is passed to the
> "command interpreter" (shell) that the program is running in. No need
> for things like "os.system(external_command)" -- just put
> "external_command" as the statement to be executed. This comes in real
> handy if the "command interpreter" is really another application --
the
> commands then can be commands for that application

That's actually one of the things I dislike about it. It's a major
philosophy
difference: to me, scripting languages are built around the assumption
that
the purpose of the script is to issue system commands, and the remainder
of the language is in a supporting role. It leads to real interesting
language
design problems, especially in extensibility and understandability.

Languages like Python, Perl and Ruby take the opposite approach: you
suffer a bit more pain in issuing a system command, and  you get a lot
of language benefits from that.

It's also the reason I called it a "typical kludge." When you start out
with
the notion of a list of commands, and then start enhancing the stream to
add functions, you wind up kludging lots of stuff.

However, this is not a discussion that is going anywhere. People seem
to have their likes and dislikes, and maintain them with almost
religious
fervor.

John Roth