Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!ultra!hayes
From: hayes@ultra.com (John Hayes)
Newsgroups: comp.lang.rexx
Subject: Re: A Suggestion For Adding Function Pointers To REXX
Message-ID: <1990Feb9.181153.417@ultra.com>
Date: 9 Feb 90 18:11:53 GMT
Reply-To: hayes@ultra.com (John Hayes)
Organization: Ultra Network Technologies
Lines: 33


This entire discussion seems to have been conducted under the assumption that
REXX is a programming language.  As I learned it, while it may technically
be called a language, it's primary design function was to provide a better
way to write simple interpreted scripts than exec2 (An older interpreted
language available on VM/CMS systems for those in the Amiga world...).
These scripts were generally installation scripts or otherwise small scripts
to be executed only occasionally, not to become a major programming language. 

REXX scripts (or programs as some people prefer to call them) are very easy to
write, thus making it the perfect language for prototyping parts of larger
software projects.  Initially, REXX was only available as an interpreter.
The ease of programming in it has led to the development of the REXX compiler.
Upon the initial design of REXX, it was never supposed to be anything but an 
interpreted language.  A similar parallel can be drawn to (gasp!) the BASIC 
programming language.  

BASIC was for many of the recent generation, a quick and easy way to learn a
lot of bad programming habits.  Most of the computers (espicially micro 
computers) ran a version of interpreted basic (microsoft basic became a defacto
standard).  As the popularity of BASIC grew (and microcomputer became more
powerful) a compiler BASIC evolved into what is now commonly called Business 
BASIC.  And now we have a generation of 'programmers' who know Business BASIC
and call themselves software engineers.

As I see it, using REXX as anything but a quick prototyping language and
for macro definition under XEDIT, we are just bound to waste more cpu cycles
by not having those applications written in a true, optimizable language.



-- 
John Wm. Hayes  hayes@ultra.com  UltraNetwork Technologies  (408)922-0100 x204