Re: Object REXX is a s***...
- From: Steven Levine <steve53@xxxxxxxxxxxxxxxxxxx>
- Date: Thu, 23 Mar 2006 05:39:42 GMT
In <T7NIEJzxPvaD092yn@xxxxxx>, on 03/22/2006
at 06:21 AM, @tin.it (Alessandro) said:
I know what a stem is (that is a sort of array whose elements are
accessed by keys rather than numeric indexes)
You may think so. However, there more to stems that just this. They have
some special properties. In an expression, the label A. is not a stem, it
is a variable name which may or may not happen to be the member of a stem.
This is easy to see with
say a.
a. ='really'
a.1 = 'one'
say a.
say a.1
say a.2
besides that, being an high level language REXX should make programming
easier and more productive, but with its odd logic it often causes more
troubles than it solves
I and many others don't find this to be case. IMO, the key to working
with any language is to understand how it was intended to be used and work
within the paradigm.
the problem is that it was born as a command shell scripting language and
all the new features which have been added during the years do not always
fit well with the original purpose of the language
You will need to provide examples. The language definition has not
changed in something like 15 years. I am excluding Object REXX here
because it is not the same language.
e.g. dealing with hexadecimal numbers is a nightmare (as the format is
not endian-agnostic)
There are simple solutions for all of this. This what reverse is for.
having to use CALL, when a procedure return value is not used, is another
of the most boring 'features' and is one of the most typical hint of the
original purpose of the REXX language (they had to use CALL to avoid
passing the procedure result to the command shell)
I would not call it boring. It's the way I prefer to call function to let
readers know that the return value is unused. REXX is hardly unique in
this kind of feature.
the only good REXX feature is its full integration with the OS...
It's not integrated with the OS. It is integrated with the command shell
and EPM and dfsee and mesa and DB2 and many other applications that choose
to use it as the basis of an application macro language. As Mike states,
this was one of the design goals.
IAC, there's no reason to use REXX when it is not the proper choice for
the problem at hand. For example, REXX stems are a handy associative data
store, but quickly fall over when the stems get too large. When I know
I'm going to have large numbers of entries in the stem, I write the code
in Perl, which for a large class of problems, can run as fast as compiled
code.
Also, it's not may nature to complain about a language that has not had
any significant new development in over 10 years.
Regards,
Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <steve53@xxxxxxxxxxxxxxxxxxx> MR2/ICE 2.67 #10183
Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------
.
- References:
- Re: Object REXX is a s***...
- From: Steven Levine
- Re: Object REXX is a s***...
- From: Steven Levine
- Re: Object REXX is a s***...
- Prev by Date: Re: Object REXX is a s***...
- Next by Date: Re: Object REXX is a s***...
- Previous by thread: Debuggin/tracing (Re: Object REXX is a s***...
- Next by thread: Re: Object REXX is a s***...
- Index(es):
Relevant Pages
|