People who loved Rexx now speak about it in past tense... :/

[George Hovey-2]

Rene,
Thank you for your detailed answer to my question; the catalog of systems you feel necessary to support was quite interesting since I haven't programmed an IBM mainframe since 1967 and was unaware of all this history and platform baggage that has built up.  I encountered Rexx using OS/2; I loved it and especially liked an editor it had that could be extended with commands written in Rexx.  [Thank you Kermit for making this possible in jEdit using NetRexx.]

I hope MFC will weigh in on this, but it seems to me that a fundamental goal of NetRexx is to leverage Java's "write once, run anywhere" and skip all this version stuff.  People loosely say that NetRexx is a JVM language, but I think it is more accurate to say that it is a Java-leveraging language, since it produces Pure Java source rather than direct byte code.  As MFC has explained elsewhere, this guarantees compatibility of NetRexx's byte code with industry standard tools.  It also guarantees in some sense perfect Java compatibility since NetRexx's output must pass inspection by javac.

I would like to stress the importance of this last point since I believe it is crucial to the future success of NetRexx, and because I notice that several posts between yours and this reply argue for a standalone version of NetRexx that distances itself from Java.  I think this would be the WRONG way to go.  It would put us back in the platform version soup and drive away the next generation of NetRexx programmers.

I don't think there will be any great influx of ooRexx programmers; as other posts in this thread show they are seriously put off by Java technology (though I would have thought that experience with ooRexx would have gotten them over the OO barrier).

I believe that the likeliest  adopters of NetRexx will be Java programmers.  There are said to be 5,000,000 of these;  if only 1 in a 1000 of these became interested in NetRexx, this would be a busy forum.  Like NetRexx users, they are sold on Java technology and think the Java class library is the most important development since the internet, but many are put off by its clunky C syntax and complex access models.  They would respond positively to something like "NetRexx: Java as it should have been" (corny, I admit).

But if it is to be used by more than hobbyists, it needs an iron-clad contract with the user, something like:

   "If you can write it in Java you can call it from NetRexx; if you can write it in NetRexx you can call it from Java".

I'm not a language theorist, so I'm not certain that this is exactly true, but the intent is that you tell the programmer, in clear and simple terms, that he can mix Java and NetRexx in a production environment without endangering the company.  At that point he can go to his manager a say "I've found a wonderful open source way to write Java more quickly and with easier maintenance.  Let's set up a task force to try it out."  This is basically how Java supplanted C++ as the standard development language at my last company.

MFC has already given NetRexx the right 'ethos' (seems to be a popular term in this thread): minimize, don't include unneccessary constructs, recast Java concepts in ways that make more sense.

NetRexx has received respectful and favorable treatment from the press in the past.  If we get it working smoothly before its relaunch, it could have a bright future indeed.

George

On Fri, Aug 20, 2010 at 5:34 PM, René Jansen <[hidden email]> wrote:

George,

I think it is a good point you are making and indeed I avoided going to deep into it, because I do mean it when I say it might mean different things to different people. So anything that follows is just my personal opinion of this evening.

First I think it is the general approach to things: the translator might be complex in order to keep the language simple. This is, I think,  what is meant when it is said that it is a language for humans, not for computers. Secondly there are some identical concepts over all Rexx implementations that are missing or lacking in other languages. Parse, Trace, a variable might be treated as string or numerical, and there is nothing to declare, and in the case of NetRexx, nothing superfluous to declare.

While I see the commonality, Thomas might very well comment on the small dissimilarities because he met those implementing his cross-Rexx product. (How is that for another free ad?)
When I see the Rexx language family, I am mainly speaking about the common features of the VM and MVS products, the DOS and Windows interpreters, the VM/MVS compiler and library product, Object Rexx, Rexx/6000, imc/rexx, Regina. And there is lots more, and remind me to have a large list on the RexxLA web site some day. In a way the differences are what defines the common part.

Speaking about differences is largely a problem of luxury. It is only now that you have a wide choice of architectures and platforms, and I remember my first ten years of Rexx were TSO only. For someone working on AIX, it might have been Rexx/6000 for years and years. When we got the Rexx compiler, for the first time we needed to fret about what was faster, the compiled interface for the external routines or the interpreter. And whether to compile to tokenized runtime modules or real linked load modules.

Most native implementations share the same interface for external functions. On the mainframe you'd sometimes write them in assembler when it was easier for the targeted product, like RACF or JES2. The interfaces are similar across languages, and most modern native implementations have exactly the same interface, a point that is only illustrated and driven home by the recent 64/32 bits problems you might have heard about - or not, if you really only are focussed on NetRexx.

There is an ISO standard for Rexx language implementations (ok, it might be ANSI) - what implements this rightly may be called a family.

String functions (or better said, the things that can be treated as character or numerical) are indentical over Classis, ooRexx and NetRexx, where ooRexx has the luxury of specification as function argument or the more modern 'hidden instance pointer' (object oriented) paradigm. All implementations share the same string functions, in NetRexx implemented as methods on type Rexx.

Treatment of decimal numbers in an intuitively and understandable, failsafe way is found across the Rexx language family. Here Rexx does not only implement an IEEE standard, it is more like the IEEE  standard implements the Rexx language family way. The same goes for numerical precision and the mechanism to specify it.

Interaction with the environment and the ability to be integrated as a macro language is shared over the language family - NetRexx is a bit spartan in a sense that reflects the early thoughts about platform and environment of the JVM implementors around 1995. This has changed and it might be time for an "address" or "outtrap" in NetRexx.

The stream I/O library is seen, at least by most members of the RexxLA board including me, a part of the language family. In a version of the language definition that saw the light just after the integration of the 370 language interpreter into TSO, stream I/O functions were defined, remember that the VM interpreter used the native platform functions for this, oddly conforming to the NetRexx approach to this. These stream I/O functions were for some reason or another never included in the mainframe product, but delivered as a separate installable library. This library is crucial in writing compatible I/O routines and will be of value to Rexx users on the mainframe, and as such it is an object of interest to RexxLA. The library is written in PL/I, which is not beyond the capabilities of the RexxLA talent pool, but might spell trouble for the open sourcing. Fortunately PL/I can generate assembler listings which might enable us to skirt this problem. But there are no definite p!
 lans for this, and there will be no attempt at this done before we finish the currently running open source project.

Regina is the open source implementation with most platforms to run on; it is of great interest to RexxLA, as is Thomas Scheiders' product, Rexx2Nrx, also (very recently) open sourced, that will make it possible to juggle different versions of Rexx and do assisted conversions from one platform to another.

Further away in the future there might be other developments, like ooRexx and NetRexx approaching each other in the form of a new version of Object ANSI (or was it ISO) Rexx. We might see ooRexx running on virtual machines, or native versions of NetRexx. These are things that are limited by our imagination, talent and time. You might agree that there is more of the former and less of the latter two, and this is what makes it imported that talented people with time on their hands join RexxLA, to safeguard the things that make up this language family.

I am in a very premature cooperation with some people from NetKernel, to make NetRexx one of the languages that it supports. I see some benefits in a server system that can replace and rollback functionality at runtime. This will probably need modifications to the translator - to run interpreted - and so it might not be seen for some time still; static NetRexx generated classes might be in much earlier.

If you have a large and functioning family, like I have, you feel at home everywhere and you can do your work without minding the other people too much; I think the same goes for a language family; it has common roots, a patriarch, family stories and the occasional eccentric nephew. But this is what makes it a family.

best regards,

René Jansen.

On 20 aug 2010, at 21:28, George Hovey wrote:

> Rene,
> I am left with the feeling that you have evaded my core question:  what makes ooRexx and NetRexx belong to the "Rexx family of languages" and presumably amenable to and worthy of co-development by the same organization?  Is it that each contains the four-character sequence "Rexx" in their names?  I once read an online symposium on the subject of "C-based programming Languages".  The invited panel were the people ordinarily regarded as the inventors of C, C++ and Java.  It turned out that the last two vehemently denied that their languages were "C-based" or even related to one another, although their syntaxes bore a resemblance.  I think a similar statement might be made about ooRexx (and all other forms of "Rexx" I've heard of) and NetRexx.
>
> Would you agree that development of NetRexx 3.0 will require a strong knowledge of and extensive experience with Java?  If so, other than yourself, do the RexxLA developers meet this requirement?  Or are even interested in NetRexx development?
>
> I personally am interested only in NetRexx, which I feel supplanted all other forms of "Rexx".  I can understand that reasonable people might come to a different conclusion, but why should we be bound together?  What's the advantage?  Does it speed the development of either language?
> George
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[FreeFall]

George, Mike,

Please don't misunderstand me, I never said that we should move NetRexx off of the Java platform, merely that NetRexx should insulate us from having to know anything about Java Objects.   Let me be absolutely clear:

[1] The powerful idea behind Classic Rexx is that it insulates the programmer from tedious things like the underlying machine's word length.   The computer does the trivial work so the programmer can concentrate on the real work.

[2] Using a ubiquitous virtual machine, ie Java VM, as the target architecture is a powerful way of being able to support NetRexx on most architectures.   

But, if in capitalising on [2], programmers need to understand the complex underworld of Java, we have thrown away the benefit of [1].

I recommend that we have our cake [1] and eat it [2]:   

We create no-nonsence objects and functions/instructions that make sense to Rexx programmers that are translated/compiled into Java Objects.    ie The computer does the trivial work so the programmer can concentrate on the real work.   

Seems like a no-brainer to me.

Regards,

Connor.

On 21 Aug 2010, at 02:37, George Hovey wrote:

Rene,
Thank you for your detailed answer to my question; the catalog of systems you feel necessary to support was quite interesting since I haven't programmed an IBM mainframe since 1967 and was unaware of all this history and platform baggage that has built up.  I encountered Rexx using OS/2; I loved it and especially liked an editor it had that could be extended with commands written in Rexx.  [Thank you Kermit for making this possible in jEdit using NetRexx.]

I hope MFC will weigh in on this, but it seems to me that a fundamental goal of NetRexx is to leverage Java's "write once, run anywhere" and skip all this version stuff.  People loosely say that NetRexx is a JVM language, but I think it is more accurate to say that it is a Java-leveraging language, since it produces Pure Java source rather than direct byte code.  As MFC has explained elsewhere, this guarantees compatibility of NetRexx's byte code with industry standard tools.  It also guarantees in some sense perfect Java compatibility since NetRexx's output must pass inspection by javac.

I would like to stress the importance of this last point since I believe it is crucial to the future success of NetRexx, and because I notice that several posts between yours and this reply argue for a standalone version of NetRexx that distances itself from Java.  I think this would be the WRONG way to go.  It would put us back in the platform version soup and drive away the next generation of NetRexx programmers.

I don't think there will be any great influx of ooRexx programmers; as other posts in this thread show they are seriously put off by Java technology (though I would have thought that experience with ooRexx would have gotten them over the OO barrier).

I believe that the likeliest  adopters of NetRexx will be Java programmers.  There are said to be 5,000,000 of these;  if only 1 in a 1000 of these became interested in NetRexx, this would be a busy forum.  Like NetRexx users, they are sold on Java technology and think the Java class library is the most important development since the internet, but many are put off by its clunky C syntax and complex access models.  They would respond positively to something like "NetRexx: Java as it should have been" (corny, I admit).

But if it is to be used by more than hobbyists, it needs an iron-clad contract with the user, something like:

   "If you can write it in Java you can call it from NetRexx; if you can write it in NetRexx you can call it from Java".

I'm not a language theorist, so I'm not certain that this is exactly true, but the intent is that you tell the programmer, in clear and simple terms, that he can mix Java and NetRexx in a production environment without endangering the company.  At that point he can go to his manager a say "I've found a wonderful open source way to write Java more quickly and with easier maintenance.  Let's set up a task force to try it out."  This is basically how Java supplanted C++ as the standard development language at my last company.

MFC has already given NetRexx the right 'ethos' (seems to be a popular term in this thread): minimize, don't include unneccessary constructs, recast Java concepts in ways that make more sense.

NetRexx has received respectful and favorable treatment from the press in the past.  If we get it working smoothly before its relaunch, it could have a bright future indeed.

George

On Fri, Aug 20, 2010 at 5:34 PM, René Jansen <[hidden email]> wrote:

George,

I think it is a good point you are making and indeed I avoided going to deep into it, because I do mean it when I say it might mean different things to different people. So anything that follows is just my personal opinion of this evening.

First I think it is the general approach to things: the translator might be complex in order to keep the language simple. This is, I think,  what is meant when it is said that it is a language for humans, not for computers. Secondly there are some identical concepts over all Rexx implementations that are missing or lacking in other languages. Parse, Trace, a variable might be treated as string or numerical, and there is nothing to declare, and in the case of NetRexx, nothing superfluous to declare.

While I see the commonality, Thomas might very well comment on the small dissimilarities because he met those implementing his cross-Rexx product. (How is that for another free ad?)
When I see the Rexx language family, I am mainly speaking about the common features of the VM and MVS products, the DOS and Windows interpreters, the VM/MVS compiler and library product, Object Rexx, Rexx/6000, imc/rexx, Regina. And there is lots more, and remind me to have a large list on the RexxLA web site some day. In a way the differences are what defines the common part.

Speaking about differences is largely a problem of luxury. It is only now that you have a wide choice of architectures and platforms, and I remember my first ten years of Rexx were TSO only. For someone working on AIX, it might have been Rexx/6000 for years and years. When we got the Rexx compiler, for the first time we needed to fret about what was faster, the compiled interface for the external routines or the interpreter. And whether to compile to tokenized runtime modules or real linked load modules.

Most native implementations share the same interface for external functions. On the mainframe you'd sometimes write them in assembler when it was easier for the targeted product, like RACF or JES2. The interfaces are similar across languages, and most modern native implementations have exactly the same interface, a point that is only illustrated and driven home by the recent 64/32 bits problems you might have heard about - or not, if you really only are focussed on NetRexx.

There is an ISO standard for Rexx language implementations (ok, it might be ANSI) - what implements this rightly may be called a family.

String functions (or better said, the things that can be treated as character or numerical) are indentical over Classis, ooRexx and NetRexx, where ooRexx has the luxury of specification as function argument or the more modern 'hidden instance pointer' (object oriented) paradigm. All implementations share the same string functions, in NetRexx implemented as methods on type Rexx.

Treatment of decimal numbers in an intuitively and understandable, failsafe way is found across the Rexx language family. Here Rexx does not only implement an IEEE standard, it is more like the IEEE  standard implements the Rexx language family way. The same goes for numerical precision and the mechanism to specify it.

Interaction with the environment and the ability to be integrated as a macro language is shared over the language family - NetRexx is a bit spartan in a sense that reflects the early thoughts about platform and environment of the JVM implementors around 1995. This has changed and it might be time for an "address" or "outtrap" in NetRexx.

The stream I/O library is seen, at least by most members of the RexxLA board including me, a part of the language family. In a version of the language definition that saw the light just after the integration of the 370 language interpreter into TSO, stream I/O functions were defined, remember that the VM interpreter used the native platform functions for this, oddly conforming to the NetRexx approach to this. These stream I/O functions were for some reason or another never included in the mainframe product, but delivered as a separate installable library. This library is crucial in writing compatible I/O routines and will be of value to Rexx users on the mainframe, and as such it is an object of interest to RexxLA. The library is written in PL/I, which is not beyond the capabilities of the RexxLA talent pool, but might spell trouble for the open sourcing. Fortunately PL/I can generate assembler listings which might enable us to skirt this problem. But there are no definite p!
 lans for this, and there will be no attempt at this done before we finish the currently running open source project.

Regina is the open source implementation with most platforms to run on; it is of great interest to RexxLA, as is Thomas Scheiders' product, Rexx2Nrx, also (very recently) open sourced, that will make it possible to juggle different versions of Rexx and do assisted conversions from one platform to another.

Further away in the future there might be other developments, like ooRexx and NetRexx approaching each other in the form of a new version of Object ANSI (or was it ISO) Rexx. We might see ooRexx running on virtual machines, or native versions of NetRexx. These are things that are limited by our imagination, talent and time. You might agree that there is more of the former and less of the latter two, and this is what makes it imported that talented people with time on their hands join RexxLA, to safeguard the things that make up this language family.

I am in a very premature cooperation with some people from NetKernel, to make NetRexx one of the languages that it supports. I see some benefits in a server system that can replace and rollback functionality at runtime. This will probably need modifications to the translator - to run interpreted - and so it might not be seen for some time still; static NetRexx generated classes might be in much earlier.

If you have a large and functioning family, like I have, you feel at home everywhere and you can do your work without minding the other people too much; I think the same goes for a language family; it has common roots, a patriarch, family stories and the occasional eccentric nephew. But this is what makes it a family.

best regards,

René Jansen.

On 20 aug 2010, at 21:28, George Hovey wrote:

> Rene,
> I am left with the feeling that you have evaded my core question:  what makes ooRexx and NetRexx belong to the "Rexx family of languages" and presumably amenable to and worthy of co-development by the same organization?  Is it that each contains the four-character sequence "Rexx" in their names?  I once read an online symposium on the subject of "C-based programming Languages".  The invited panel were the people ordinarily regarded as the inventors of C, C++ and Java.  It turned out that the last two vehemently denied that their languages were "C-based" or even related to one another, although their syntaxes bore a resemblance.  I think a similar statement might be made about ooRexx (and all other forms of "Rexx" I've heard of) and NetRexx.
>
> Would you agree that development of NetRexx 3.0 will require a strong knowledge of and extensive experience with Java?  If so, other than yourself, do the RexxLA developers meet this requirement?  Or are even interested in NetRexx development?
>
> I personally am interested only in NetRexx, which I feel supplanted all other forms of "Rexx".  I can understand that reasonable people might come to a different conclusion, but why should we be bound together?  What's the advantage?  Does it speed the development of either language?
> George
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Fernando Cassia-2]

On Fri, Aug 20, 2010 at 10:37 PM, George Hovey <[hidden email]> wrote:

> would like to stress the importance of this last point since I believe it is
> crucial to the future success of NetRexx, and because I notice that several
> posts between yours and this reply argue for a standalone version of NetRexx
> that distances itself from Java.  I think this would be the WRONG way to
> go.  It would put us back in the platform version soup and drive away the
> next generation of NetRexx programmers.
>
> I believe that the likeliest  adopters of NetRexx will be Java programmers.
> There are said to be 5,000,000 of these;  if only 1 in a 1000 of these
> became interested in NetRexx, this would be a busy forum.  Like NetRexx
> users, they are sold on Java technology and think the Java class library is
> the most important development since the internet, but many are put off by
> its clunky C syntax and complex access models.  They would respond
> positively to something like "NetRexx: Java as it should have been" (corny,
> I admit).

George,

I agree with everything you said above, FWIW.

FC

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Fernando Cassia-2]

On Fri, Aug 20, 2010 at 8:33 AM, René Jansen <[hidden email]> wrote:
> certainly food for thought.

Thanks for the lengthy reply, René. My habit of "thinking aloud" with
no filter often leads me to trouble on mailing lists. I´m happy to see
that my post was well accepted.

My replies below the appropiate paragraphs:

> Note that the slashdot article is about OS/2 and the past tense could be
> caused by association with the particular Rexx that was in there. Not in the
> first OS/2 SE version, because that was vetoed by Mircrosoft who knew a good
> thing which they did not have the rights to when they saw it.

Hence .net, whose only purpose is to steal mindshare from Java. :)

> But do remember that both SE and EE were dogs

I began using OS/2 at version 2.0, the first 32-bit version, on a
40Mhz AMD 386-40 with 8MB of RAM, so I didn´t have the misfortune of
havng to deal with Microsoft´s 16bit OS/2
:-)

> Note that SAA (that declared Rexx the cross-platform procedures language)
> and OS/2 together are the primary reasons that the non-VM or MVS crowd got
> to know Rexx, Mansfield Rexx on DOS nonewithstanding.  It peaked with those,
> and it was a disappointment to most of us when Workplace OS was cancelled -
> it spelled doom for all things connected to OS/2 and its components.

Agree. ARexx has also a quite strong following on the Amiga.

> It´s not the better things that win; let's fast forward the video recorders but
> let us do include workplace shell and SOM into the equation. There is no
> question that activity around Rexx peaked in 1995 and was impacted with
> OS/2's reputation, not its quality.

Do not forget VX-Rexx, it also played a role. When Scitech Software
managed somehow to convince Sybase (which has the rights of everything
Powersoft once owned) to open source the Watcom C++ compiler, creating
OpenWatcom, I begged them for months to try to get Watcom VX-Rexx also
open sourced. It never happened, sadly.

> I have seen perfect books, campaigns and
> slide decks for products you have never heard of.

I have quite a good memory for obscure products that had a niche
market, good potential  but died... CA-Realizer, Oracle PoweObjects...
:)

> Note that it is slightly off-topic for the netrexx list but I am sure the
> admin will allow it. This should be on the RexxLA list, and I invite you to
> become a member. Note that on the RexxLA list Prof. Flatscher is fine-tuning
> the oooRexx integration package's tagline for maximum impact, and I applaud
> that, and the way that a lot of native speakers are helping him.

Thanks René,  I welcome and accept that offer. Let´s continue the
discussion there.

FC

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

El 21/08/2010 13:06, Connor Birch escribió:

[1] The powerful idea behind Classic Rexx is that it insulates the programmer from tedious things like the underlying machine's word length.   The computer does the trivial work so the programmer can concentrate on the real work.

[2] Using a ubiquitous virtual machine, ie Java VM, as the target architecture is a powerful way of being able to support NetRexx on most architectures.   

But, if in capitalising on [2], programmers need to understand the complex underworld of Java, we have thrown away the benefit of [1].

I recommend that we have our cake [1] and eat it [2]:   

We create no-nonsence objects and functions/instructions that make sense to Rexx programmers that are translated/compiled into Java Objects.

I don't know if you realize that last sentence really hits the nail:

- You want some classic-rexx-like abstraction or idiom in NetRexx?
- OK, we build objects (classes) and functions/instructions (methods) on top of java objects.

The point is: NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES

This can be done today, it's already done for REXX I/O.

Don't take my word, behold:

    /* Adaption of COLLECTOR, an example found at: *
     * The REXX LANGUAGE 2nd Ed, pg. 143           */
    import nrio.RXFile

    parse arg inputname lineendchar

    buffer = ''
    infile = RXFile(inputname)

    do forever
        nextchar = infile.CHARIN()
        if nextchar=lineendchar then leave
        buffer=buffer||nextchar
        end
   
    Say buffer

NetRexx even accepts the (incorrect) 'do forever' idiom with just a warning.
I didn't bother with queue which TRL describes as implementation dependent.

OK, what happens here? We wanted our old REXX I/O mechanisms. We didn't want to
muck around the whole day with FileInputStreams and their ilk. So we imported
Max Marsiglietti's RXFile class and magically got access to CHARIN, CHAROUT,
LINEIN, and friends.

Want your cake? Have it!

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

P.S.2: This is just an example of how I think this should be done. Surely much REXX-like
functionality is still  missing. Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. Which is BTW not the case for neither of the two conditions...




_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[FreeFall]

On 21 Aug 2010, at 21:06, David Requena wrote:

El 21/08/2010 13:06, Connor Birch escribió:

[1] The powerful idea behind Classic Rexx is that it insulates the programmer from tedious things like the underlying machine's word length.   The computer does the trivial work so the programmer can concentrate on the real work.

[2] Using a ubiquitous virtual machine, ie Java VM, as the target architecture is a powerful way of being able to support NetRexx on most architectures.   

But, if in capitalising on [2], programmers need to understand the complex underworld of Java, we have thrown away the benefit of [1].

I recommend that we have our cake [1] and eat it [2]:   

We create no-nonsence objects and functions/instructions that make sense to Rexx programmers that are translated/compiled into Java Objects.

I don't know if you realize that last sentence really hits the nail:

- You want some classic-rexx-like abstraction or idiom in NetRexx?
- OK, we build objects (classes) and functions/instructions (methods) on top of java objects.

The point is: NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES

This can be done today, it's already done for REXX I/O.

Don't take my word, behold:

    /* Adaption of COLLECTOR, an example found at: *
     * The REXX LANGUAGE 2nd Ed, pg. 143           */
    import nrio.RXFile

    parse arg inputname lineendchar

    buffer = ''
    infile = RXFile(inputname)

    do forever
        nextchar = infile.CHARIN()
        if nextchar=lineendchar then leave
        buffer=buffer||nextchar
        end
   
    Say buffer

NetRexx even accepts the (incorrect) 'do forever' idiom with just a warning.
I didn't bother with queue which TRL describes as implementation dependent.

OK, what happens here? We wanted our old REXX I/O mechanisms. We didn't want to
muck around the whole day with FileInputStreams and their ilk. So we imported
Max Marsiglietti's RXFile class and magically got access to CHARIN, CHAROUT,
LINEIN, and friends.

Want your cake? Have it!

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

P.S.2: This is just an example of how I think this should be done. Surely much REXX-like
functionality is still  missing. Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. Which is BTW not the case for neither of the two conditions...

 

Thanks for this David.   

We didn't want to
muck around the whole day with FileInputStreams and their ilk. 

1. Absolutely right!   Thanks for the example code.   I don't see this code documented in either MC's The NetRexx Language, MC's NetRexx 2, or IBM's Red Book: Creating Applications Using NetRexx.   Have I missed it somewhere, or is there another book that I need (the reference above suggests a book on Rexx rather than NetRexx; does the Rexx book actually cover NetRexx or do I need a different reference)?   

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

2. Where can I find Max Marsiglietti's classes, and anyone else's useful classes, and their documentation?   

3. How can we ensure that everyone gets a full set of documentation so that people do use RXFile, Rexx2Nrx, NetRexxDE etc?    It can't be that hard to create one depository for downloads can it?   Or better still (always the optimist), one comprehensive User Guide, and one Reference?

4. Objects are really good where inheritance can be the mechanism for reusability.  However, for basic classes, like String, it is a lot handier, and syntactically nicer, and no doubt more efficient, for them to be built into the language rather than being formally treated as Classes.   I would suggest that basic things like CHARIN and LINEIN are in this category; not sure why there is resistance to this (No disrespect to MC, but Classic Rexx would have been better, I believe, and Rexx programs more portable, if it contained I/O as part of the language).    

 

Surely much REXX-like
functionality is still  missing.

5. This is a limiting factor for NetRexx's success.   If we want NetRexx to take its rightful place, we DO need to fix this, one way or the other.

Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. 

     

6. It surprises me that we are now in 2010, still without a complete solution.   So what is the problem do we think, and what can be done about it?

7. How many subscribers are there to this forum, and how many have the Java skills to build the missing objects, and the time to do it?   If this number is less than 1, should we find some way of funding a contractor to do the work?   Or am I talking heresy?    Or are we aspiring to being a community of boring old farts, who talk a lot, achieve little, and seem irrelevant to real world programming?   Which are we closest to now?   (I'm deliberately being Devil's Advocate).  

Regards,

Connor.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Rupp Peter - prupp]

David,

You hit the nail on the head.   Agree totally.   

   

Peter

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of David Requena
Sent: Saturday, August 21, 2010 3:07 PM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] People who loved Rexx now speak about it in pasttense... :/

 

El 21/08/2010 13:06, Connor Birch escribió:

[1] The powerful idea behind Classic Rexx is that it insulates the programmer from tedious things like the underlying machine's word length.   The computer does the trivial work so the programmer can concentrate on the real work.

 

[2] Using a ubiquitous virtual machine, ie Java VM, as the target architecture is a powerful way of being able to support NetRexx on most architectures.   

 

But, if in capitalising on [2], programmers need to understand the complex underworld of Java, we have thrown away the benefit of [1].

 

I recommend that we have our cake [1] and eat it [2]:   

 

We create no-nonsence objects and functions/instructions that make sense to Rexx programmers that are translated/compiled into Java Objects.

I don't know if you realize that last sentence really hits the nail:

- You want some classic-rexx-like abstraction or idiom in NetRexx?
- OK, we build objects (classes) and functions/instructions (methods) on top of java objects.

The point is: NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES

This can be done today, it's already done for REXX I/O.

Don't take my word, behold:

    /* Adaption of COLLECTOR, an example found at: *
     * The REXX LANGUAGE 2nd Ed, pg. 143           */
    import nrio.RXFile

    parse arg inputname lineendchar

    buffer = ''
    infile = RXFile(inputname)

    do forever
        nextchar = infile.CHARIN()
        if nextchar=lineendchar then leave
        buffer=buffer||nextchar
        end
   
    Say buffer

NetRexx even accepts the (incorrect) 'do forever' idiom with just a warning.
I didn't bother with queue which TRL describes as implementation dependent.

OK, what happens here? We wanted our old REXX I/O mechanisms. We didn't want to
muck around the whole day with FileInputStreams and their ilk. So we imported
Max Marsiglietti's RXFile class and magically got access to CHARIN, CHAROUT,
LINEIN, and friends.

Want your cake? Have it!

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

P.S.2: This is just an example of how I think this should be done. Surely much REXX-like
functionality is still  missing. Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. Which is BTW not the case for neither of the two conditions...

---

Saludos / Kind regards.

David Requena

 

***************************************************************************
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged.

If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank You.
****************************************************************************
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

David,
Your statement "NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES"
alarms me.  Do you mean that NetRexx becomes frozen in time vis a vis Java so that we are forever married to Java 1.6, and java/NetRexx interoperability gradually declines?  This strikes me as the kiss of death.
George

On Sat, Aug 21, 2010 at 4:06 PM, David Requena <[hidden email]> wrote:

El 21/08/2010 13:06, Connor Birch escribió:

[1] The powerful idea behind Classic Rexx is that it insulates the programmer from tedious things like the underlying machine's word length.   The computer does the trivial work so the programmer can concentrate on the real work.

[2] Using a ubiquitous virtual machine, ie Java VM, as the target architecture is a powerful way of being able to support NetRexx on most architectures.   

But, if in capitalising on [2], programmers need to understand the complex underworld of Java, we have thrown away the benefit of [1].

I recommend that we have our cake [1] and eat it [2]:   

We create no-nonsence objects and functions/instructions that make sense to Rexx programmers that are translated/compiled into Java Objects.

I don't know if you realize that last sentence really hits the nail:

- You want some classic-rexx-like abstraction or idiom in NetRexx?
- OK, we build objects (classes) and functions/instructions (methods) on top of java objects.

The point is: NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES

This can be done today, it's already done for REXX I/O.

Don't take my word, behold:

    /* Adaption of COLLECTOR, an example found at: *
     * The REXX LANGUAGE 2nd Ed, pg. 143           */
    import nrio.RXFile

    parse arg inputname lineendchar

    buffer = ''
    infile = RXFile(inputname)

    do forever
        nextchar = infile.CHARIN()
        if nextchar=lineendchar then leave
        buffer=buffer||nextchar
        end
   
    Say buffer

NetRexx even accepts the (incorrect) 'do forever' idiom with just a warning.
I didn't bother with queue which TRL describes as implementation dependent.

OK, what happens here? We wanted our old REXX I/O mechanisms. We didn't want to
muck around the whole day with FileInputStreams and their ilk. So we imported
Max Marsiglietti's RXFile class and magically got access to CHARIN, CHAROUT,
LINEIN, and friends.

Want your cake? Have it!

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

P.S.2: This is just an example of how I think this should be done. Surely much REXX-like
functionality is still  missing. Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. Which is BTW not the case for neither of the two conditions...

---
Saludos / Kind regards.
David Requena

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[rvjansen]

George,

no need to be worried - NetRexx has been married to Java 1.2 for the last 10 years. Unless you skipped the interpreter, I think that the translator still works with 1.12 or so. I tend to see that as a strength.

The 'declined interoperability' did never preclude me from doing useful work. Adding dependencies on higher Java versions should be done with utmost care and requires community decisions. Adding support for Java specifics that became available in higher versions (without breaking compatibility) should also be well thought out, and should pass Occam's razor. I think some support for annotations would be good. On generics the jury is still out. My hunch is that we can add that to NetRexx without any syntactic change. You have seen what inner class support stirred up. Generally spoken, changes should pass the language board before being considered for implementation. By the way, we have some vacant positions there.

best regards,

René.

On 22 aug 2010, at 16:32, George Hovey wrote:

David,
Your statement "NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES"
alarms me.  Do you mean that NetRexx becomes frozen in time vis a vis Java so that we are forever married to Java 1.6, and java/NetRexx interoperability gradually declines?  This strikes me as the kiss of death.
George

On Sat, Aug 21, 2010 at 4:06 PM, David Requena <[hidden email]> wrote:

El 21/08/2010 13:06, Connor Birch escribió:

[1] The powerful idea behind Classic Rexx is that it insulates the programmer from tedious things like the underlying machine's word length.   The computer does the trivial work so the programmer can concentrate on the real work.

[2] Using a ubiquitous virtual machine, ie Java VM, as the target architecture is a powerful way of being able to support NetRexx on most architectures.   

But, if in capitalising on [2], programmers need to understand the complex underworld of Java, we have thrown away the benefit of [1].

I recommend that we have our cake [1] and eat it [2]:   

We create no-nonsence objects and functions/instructions that make sense to Rexx programmers that are translated/compiled into Java Objects.

I don't know if you realize that last sentence really hits the nail:

- You want some classic-rexx-like abstraction or idiom in NetRexx?
- OK, we build objects (classes) and functions/instructions (methods) on top of java objects.

The point is: NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES

This can be done today, it's already done for REXX I/O.

Don't take my word, behold:

    /* Adaption of COLLECTOR, an example found at: *
     * The REXX LANGUAGE 2nd Ed, pg. 143           */
    import nrio.RXFile

    parse arg inputname lineendchar

    buffer = ''
    infile = RXFile(inputname)

    do forever
        nextchar = infile.CHARIN()
        if nextchar=lineendchar then leave
        buffer=buffer||nextchar
        end
   
    Say buffer

NetRexx even accepts the (incorrect) 'do forever' idiom with just a warning.
I didn't bother with queue which TRL describes as implementation dependent.

OK, what happens here? We wanted our old REXX I/O mechanisms. We didn't want to
muck around the whole day with FileInputStreams and their ilk. So we imported
Max Marsiglietti's RXFile class and magically got access to CHARIN, CHAROUT,
LINEIN, and friends.

Want your cake? Have it!

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

P.S.2: This is just an example of how I think this should be done. Surely much REXX-like
functionality is still  missing. Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. Which is BTW not the case for neither of the two conditions...

---
Saludos / Kind regards.
David Requena

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Robert L Hamilton]

I did a google on the string  .edu netrexx ( dot-edu netrexx)  and got hundreds of hits.  Netrexx is known in colleges and schools around the planet.  Maybe some of the teachers and students in those schools could furnish some help -- Perhaps a dissertation on NetRexx apps.

JAT

bobh

On Sun, Aug 22, 2010 at 8:59 AM, Connor Birch <[hidden email]> wrote:

On 21 Aug 2010, at 21:06, David Requena wrote:

El 21/08/2010 13:06, Connor Birch escribió:

[1] The powerful idea behind Classic Rexx is that it insulates the programmer from tedious things like the underlying machine's word length.   The computer does the trivial work so the programmer can concentrate on the real work.

[2] Using a ubiquitous virtual machine, ie Java VM, as the target architecture is a powerful way of being able to support NetRexx on most architectures.   

But, if in capitalising on [2], programmers need to understand the complex underworld of Java, we have thrown away the benefit of [1].

I recommend that we have our cake [1] and eat it [2]:   

We create no-nonsence objects and functions/instructions that make sense to Rexx programmers that are translated/compiled into Java Objects.

I don't know if you realize that last sentence really hits the nail:

- You want some classic-rexx-like abstraction or idiom in NetRexx?
- OK, we build objects (classes) and functions/instructions (methods) on top of java objects.

The point is: NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES

This can be done today, it's already done for REXX I/O.

Don't take my word, behold:

    /* Adaption of COLLECTOR, an example found at: *
     * The REXX LANGUAGE 2nd Ed, pg. 143           */
    import nrio.RXFile

    parse arg inputname lineendchar

    buffer = ''
    infile = RXFile(inputname)

    do forever
        nextchar = infile.CHARIN()
        if nextchar=lineendchar then leave
        buffer=buffer||nextchar
        end
   
    Say buffer

NetRexx even accepts the (incorrect) 'do forever' idiom with just a warning.
I didn't bother with queue which TRL describes as implementation dependent.

OK, what happens here? We wanted our old REXX I/O mechanisms. We didn't want to
muck around the whole day with FileInputStreams and their ilk. So we imported
Max Marsiglietti's RXFile class and magically got access to CHARIN, CHAROUT,
LINEIN, and friends.

Want your cake? Have it!

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

P.S.2: This is just an example of how I think this should be done. Surely much REXX-like
functionality is still  missing. Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. Which is BTW not the case for neither of the two conditions...

---
Saludos / Kind regards.
David Requena

 

Thanks for this David.   

We didn't want to
muck around the whole day with FileInputStreams and their ilk. 

1. Absolutely right!   Thanks for the example code.   I don't see this code documented in either MC's The NetRexx Language, MC's NetRexx 2, or IBM's Red Book: Creating Applications Using NetRexx.   Have I missed it somewhere, or is there another book that I need (the reference above suggests a book on Rexx rather than NetRexx; does the Rexx book actually cover NetRexx or do I need a different reference)?   

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

2. Where can I find Max Marsiglietti's classes, and anyone else's useful classes, and their documentation?   

3. How can we ensure that everyone gets a full set of documentation so that people do use RXFile, Rexx2Nrx, NetRexxDE etc?    It can't be that hard to create one depository for downloads can it?   Or better still (always the optimist), one comprehensive User Guide, and one Reference?

4. Objects are really good where inheritance can be the mechanism for reusability.  However, for basic classes, like String, it is a lot handier, and syntactically nicer, and no doubt more efficient, for them to be built into the language rather than being formally treated as Classes.   I would suggest that basic things like CHARIN and LINEIN are in this category; not sure why there is resistance to this (No disrespect to MC, but Classic Rexx would have been better, I believe, and Rexx programs more portable, if it contained I/O as part of the language).    

 

Surely much REXX-like
functionality is still  missing.

5. This is a limiting factor for NetRexx's success.   If we want NetRexx to take its rightful place, we DO need to fix this, one way or the other.

Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. 

     

6. It surprises me that we are now in 2010, still without a complete solution.   So what is the problem do we think, and what can be done about it?

7. How many subscribers are there to this forum, and how many have the Java skills to build the missing objects, and the time to do it?   If this number is less than 1, should we find some way of funding a contractor to do the work?   Or am I talking heresy?    Or are we aspiring to being a community of boring old farts, who talk a lot, achieve little, and seem irrelevant to real world programming?   Which are we closest to now?   (I'm deliberately being Devil's Advocate).  

Regards,

Connor.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

Connor,
It seems to me that what you are asking for might already be available in ooRexx.  Why not take a look at ooRexx -- it may be the answer to your prayers.

However, if not, you might give a close reading to MFC's "Introduction" and "Language Objectives", especially the section "Influence of Java" in the document "NetRexx 2" dated 22 May 2009.  It makes clear that he is after much more than byte code portability in targeting Java as NetRexx's "object language".  NetRexx is not just another JVM language du jour -- it has an intimate relationship with Java :).  Although MFC doesn't rule out directly targeting the JVM, that is not the route he chose.

BTW, it is not necessary that NetRexx programmers "understand the complex underworld of Java" in order to write useful programs.  As David points out, the places where we would like simplification, say file I/O, can be handled by libraries.

Finally, could you give me some idea of what a "no-nonsense object" that makes sense to Rexx programmers might be like?
George

On Sun, Aug 22, 2010 at 9:59 AM, Connor Birch <[hidden email]> wrote:

On 21 Aug 2010, at 21:06, David Requena wrote:

El 21/08/2010 13:06, Connor Birch escribió:

[1] The powerful idea behind Classic Rexx is that it insulates the programmer from tedious things like the underlying machine's word length.   The computer does the trivial work so the programmer can concentrate on the real work.

[2] Using a ubiquitous virtual machine, ie Java VM, as the target architecture is a powerful way of being able to support NetRexx on most architectures.   

But, if in capitalising on [2], programmers need to understand the complex underworld of Java, we have thrown away the benefit of [1].

I recommend that we have our cake [1] and eat it [2]:   

We create no-nonsence objects and functions/instructions that make sense to Rexx programmers that are translated/compiled into Java Objects.

I don't know if you realize that last sentence really hits the nail:

- You want some classic-rexx-like abstraction or idiom in NetRexx?
- OK, we build objects (classes) and functions/instructions (methods) on top of java objects.

The point is: NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES

This can be done today, it's already done for REXX I/O.

Don't take my word, behold:

    /* Adaption of COLLECTOR, an example found at: *
     * The REXX LANGUAGE 2nd Ed, pg. 143           */
    import nrio.RXFile

    parse arg inputname lineendchar

    buffer = ''
    infile = RXFile(inputname)

    do forever
        nextchar = infile.CHARIN()
        if nextchar=lineendchar then leave
        buffer=buffer||nextchar
        end
   
    Say buffer

NetRexx even accepts the (incorrect) 'do forever' idiom with just a warning.
I didn't bother with queue which TRL describes as implementation dependent.

OK, what happens here? We wanted our old REXX I/O mechanisms. We didn't want to
muck around the whole day with FileInputStreams and their ilk. So we imported
Max Marsiglietti's RXFile class and magically got access to CHARIN, CHAROUT,
LINEIN, and friends.

Want your cake? Have it!

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

P.S.2: This is just an example of how I think this should be done. Surely much REXX-like
functionality is still  missing. Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. Which is BTW not the case for neither of the two conditions...

---
Saludos / Kind regards.
David Requena

 

Thanks for this David.   

We didn't want to
muck around the whole day with FileInputStreams and their ilk. 

1. Absolutely right!   Thanks for the example code.   I don't see this code documented in either MC's The NetRexx Language, MC's NetRexx 2, or IBM's Red Book: Creating Applications Using NetRexx.   Have I missed it somewhere, or is there another book that I need (the reference above suggests a book on Rexx rather than NetRexx; does the Rexx book actually cover NetRexx or do I need a different reference)?   

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

2. Where can I find Max Marsiglietti's classes, and anyone else's useful classes, and their documentation?   

3. How can we ensure that everyone gets a full set of documentation so that people do use RXFile, Rexx2Nrx, NetRexxDE etc?    It can't be that hard to create one depository for downloads can it?   Or better still (always the optimist), one comprehensive User Guide, and one Reference?

4. Objects are really good where inheritance can be the mechanism for reusability.  However, for basic classes, like String, it is a lot handier, and syntactically nicer, and no doubt more efficient, for them to be built into the language rather than being formally treated as Classes.   I would suggest that basic things like CHARIN and LINEIN are in this category; not sure why there is resistance to this (No disrespect to MC, but Classic Rexx would have been better, I believe, and Rexx programs more portable, if it contained I/O as part of the language).    

 

Surely much REXX-like
functionality is still  missing.

5. This is a limiting factor for NetRexx's success.   If we want NetRexx to take its rightful place, we DO need to fix this, one way or the other.

Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. 

     

6. It surprises me that we are now in 2010, still without a complete solution.   So what is the problem do we think, and what can be done about it?

7. How many subscribers are there to this forum, and how many have the Java skills to build the missing objects, and the time to do it?   If this number is less than 1, should we find some way of funding a contractor to do the work?   Or am I talking heresy?    Or are we aspiring to being a community of boring old farts, who talk a lot, achieve little, and seem irrelevant to real world programming?   Which are we closest to now?   (I'm deliberately being Devil's Advocate).  

Regards,

Connor.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

Rene,
Your answer is considerably reassuring, but not totally so, principally I think, because of my own ignorance of language issues.  I'd like to describe my situation a bit so I can phrase my concerns in a more definite way.

I am an applications programmer, not a computer scientist.  I write libraries for my own use, but a reading of Joshua Bloch's "Effective Java" (a book that seems worth reading by NetRexxers) suggests that they would not pass muster for public use.  I don't have software architectural pretensions.

I work as a hardware/software consultant to scientific labs, typically designing instrument interfaces and providing supporting software.  I learned Java during a rare stint with a commercial software company during a downturn in the science business.  It was plain to me Java was head and shoulders over anything I'd seen.  But a couple of years later I discovered NetRexx and vowed that if I got back to consulting it would be my development language, partly due to earlier positive experiences with Rexx and partly because of its Java compatibility.

I did and it did, and I found it exceeded my expectations in every way.  I find writing in NetRexx life enhancing and suspect using it will add years to my life.  I don't want to program in any language but NetRexx.  However, I don't tell customers that I program in NetRexx (to those few who express an interest), but in "NetRexx, a form of Java" because they've heard of Java, and because until recently I thought this not too much of a liberty with the truth.

But I have a problem: scientific researchers expect a program to work at least until they die, so I have to think carefully about dependencies I incorporate in programs.  If I write in C I'm on pretty firm ground, but I'd rather live in a hollow log and drink muddy water ("C hates programmers").  Similarly, Java seems to be at least as safe since its colossal commercial importance will tend to prevent its guardians breaking old programs.  I also trust its class library for the same reason and have never hesitated to incorporate it in programs.

So I have a burning interest in the future of NetRexx and its relation to Java.  A certain amount of hostility to Java is being expressed in this forum and it makes me queasy.  If programs I write were to stop working, or I found it impossible to maintain them because of creeping incompatibility then I need to rethink my approach.  If NetRexx is to become a menace to my needs, then I think I would best start brushing up on Java, though that would pain me deeply.

Let me emphasize, in my earlier post I was not arguing for NetRexx to support every idea that shows up in Java; for example I was glad to see off anonymous classes.  I think it might be wise, from a marketing standpoint to describe NetRexx as a cleaner way to write Java, but I myself don't see it that way: perhaps "a way to write cleaner Java" is closer to the truth, though many of my programs show little or no trace of Java.

The core of my view is that there should be some contract between the user and NetRexx's architects as to its relation to Java.  I was only groping for the form this might take.  Perhaps there should be an examination of such issues and a "mission statement" produced before anyone writes code.  Another idea: write a short essay of two paragraphs: "You should consider ooRexx if", and "You should consider NetRexx if".

It occurs to me that my view of the necessity and desirability of NetRexx coexisting with Java might not be shared by anyone else.   I earnestly hope to hear the NetRexx heavy hitters opine on what makes NetRexx NetRexx and what they aim to conserve during its future development.
George

On Sun, Aug 22, 2010 at 10:58 AM, René Jansen <[hidden email]> wrote:

George,

no need to be worried - NetRexx has been married to Java 1.2 for the last 10 years. Unless you skipped the interpreter, I think that the translator still works with 1.12 or so. I tend to see that as a strength.

The 'declined interoperability' did never preclude me from doing useful work. Adding dependencies on higher Java versions should be done with utmost care and requires community decisions. Adding support for Java specifics that became available in higher versions (without breaking compatibility) should also be well thought out, and should pass Occam's razor. I think some support for annotations would be good. On generics the jury is still out. My hunch is that we can add that to NetRexx without any syntactic change. You have seen what inner class support stirred up. Generally spoken, changes should pass the language board before being considered for implementation. By the way, we have some vacant positions there.

best regards,

René.

On 22 aug 2010, at 16:32, George Hovey wrote:

David,
Your statement "NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES"
alarms me.  Do you mean that NetRexx becomes frozen in time vis a vis Java so that we are forever married to Java 1.6, and java/NetRexx interoperability gradually declines?  This strikes me as the kiss of death.
George

On Sat, Aug 21, 2010 at 4:06 PM, David Requena <[hidden email]> wrote:

El 21/08/2010 13:06, Connor Birch escribió:

[1] The powerful idea behind Classic Rexx is that it insulates the programmer from tedious things like the underlying machine's word length.   The computer does the trivial work so the programmer can concentrate on the real work.

[2] Using a ubiquitous virtual machine, ie Java VM, as the target architecture is a powerful way of being able to support NetRexx on most architectures.   

But, if in capitalising on [2], programmers need to understand the complex underworld of Java, we have thrown away the benefit of [1].

I recommend that we have our cake [1] and eat it [2]:   

We create no-nonsence objects and functions/instructions that make sense to Rexx programmers that are translated/compiled into Java Objects.

I don't know if you realize that last sentence really hits the nail:

- You want some classic-rexx-like abstraction or idiom in NetRexx?
- OK, we build objects (classes) and functions/instructions (methods) on top of java objects.

The point is: NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES

This can be done today, it's already done for REXX I/O.

Don't take my word, behold:

    /* Adaption of COLLECTOR, an example found at: *
     * The REXX LANGUAGE 2nd Ed, pg. 143           */
    import nrio.RXFile

    parse arg inputname lineendchar

    buffer = ''
    infile = RXFile(inputname)

    do forever
        nextchar = infile.CHARIN()
        if nextchar=lineendchar then leave
        buffer=buffer||nextchar
        end
   
    Say buffer

NetRexx even accepts the (incorrect) 'do forever' idiom with just a warning.
I didn't bother with queue which TRL describes as implementation dependent.

OK, what happens here? We wanted our old REXX I/O mechanisms. We didn't want to
muck around the whole day with FileInputStreams and their ilk. So we imported
Max Marsiglietti's RXFile class and magically got access to CHARIN, CHAROUT,
LINEIN, and friends.

Want your cake? Have it!

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

P.S.2: This is just an example of how I think this should be done. Surely much REXX-like
functionality is still  missing. Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. Which is BTW not the case for neither of the two conditions...

---
Saludos / Kind regards.
David Requena

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Rupp Peter - prupp]

Actually, I would like to take a stab at this one.

 

A couple perfect  examples of a Netrexx simplification of a complex java mess, would be something Python did with their standard library – specifically  Python’s socket and file objects, which are object abstractions of the Unix socket and file calls against a Unix file-handle.  Sure, they are Unix-like, but they are simple and very easy to code, and Python made it very easy.

 

For Python “file objects”, please see http://docs.python.org/library/stdtypes.html#file-objects

For Python “socket objects”, please see http://docs.python.org/library/socket.html

 

Here’s a description of what/why’s of Pythons Standard Library, and why it’s so cool….

(source: http://docs.python.org/library/)

“…Python’s standard library is very extensive, offering a wide range of facilities as indicated by the long table of contents listed below. The library contains built-in modules (written in C) that provide access to system functionality such as file I/O that would otherwise be inaccessible to Python programmers, as well as modules written in Python that provide standardized solutions for many problems that occur in everyday programming. Some of these modules are explicitly designed to encourage and enhance the portability of Python programs by abstracting away platform-specifics into platform-neutral APIs.”

You could write everything in netRexx syntax, but you don’t have to!  Instead, you can incorporate other folks java libraries (or products), of who wish to make them available as open-source.   You could incorporate these libraries into the netRexx “standard” library, one could probably create a netRexx “wrapper” object surrounding a call to other third-party java libraries that have contributed their code to open-source and netRexx.  This is exactly how Python language handles many of their standard library functions, which are implemented as C libraries, and somebody wrote a python “object” wrapper around it.   On the other hand, before you go running off and incorporating all sorts of libraries, you might want to test them first – many open-sourced libraries are written poorly, and either perform poorly or have serious bugs.   (stop me if you’ve heard this one before).   So, when building a standard library, it might be a good idea to have a quality process (test harness) built in to test various cases before releasing anything.

 

You may be asking…”Well Pete, why don’t you just use Jython?”, and the answer would be….I do, and it works pretty well, but I don’t believe the designers of the language have as clean design or long-term prospects that netRexx does.   In many cases, I have had Jython crash both the IBM and SUN jvm’s at different points….and this does not give me confidence… So I believe in netRexx.

 

As Blago would say “I may be crazy, but I’m not nuts)  

A poor attempt at humor ;-)

Peter

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: Sunday, August 22, 2010 10:42 AM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] People who loved Rexx now speak about it in pasttense... :/

 

Connor,
It seems to me that what you are asking for might already be available in ooRexx.  Why not take a look at ooRexx -- it may be the answer to your prayers.

However, if not, you might give a close reading to MFC's "Introduction" and "Language Objectives", especially the section "Influence of Java" in the document "NetRexx 2" dated 22 May 2009.  It makes clear that he is after much more than byte code portability in targeting Java as NetRexx's "object language".  NetRexx is not just another JVM language du jour -- it has an intimate relationship with Java :).  Although MFC doesn't rule out directly targeting the JVM, that is not the route he chose.

BTW, it is not necessary that NetRexx programmers "understand the complex underworld of Java" in order to write useful programs.  As David points out, the places where we would like simplification, say file I/O, can be handled by libraries.

Finally, could you give me some idea of what a "no-nonsense object" that makes sense to Rexx programmers might be like?
George

On Sun, Aug 22, 2010 at 9:59 AM, Connor Birch <[hidden email]> wrote:

 

On 21 Aug 2010, at 21:06, David Requena wrote:

El 21/08/2010 13:06, Connor Birch escribió:

[1] The powerful idea behind Classic Rexx is that it insulates the programmer from tedious things like the underlying machine's word length.   The computer does the trivial work so the programmer can concentrate on the real work.

 

[2] Using a ubiquitous virtual machine, ie Java VM, as the target architecture is a powerful way of being able to support NetRexx on most architectures.   

 

But, if in capitalising on [2], programmers need to understand the complex underworld of Java, we have thrown away the benefit of [1].

 

I recommend that we have our cake [1] and eat it [2]:   

 

We create no-nonsence objects and functions/instructions that make sense to Rexx programmers that are translated/compiled into Java Objects.

I don't know if you realize that last sentence really hits the nail:

- You want some classic-rexx-like abstraction or idiom in NetRexx?
- OK, we build objects (classes) and functions/instructions (methods) on top of java objects.

The point is: NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES

This can be done today, it's already done for REXX I/O.

Don't take my word, behold:

    /* Adaption of COLLECTOR, an example found at: *
     * The REXX LANGUAGE 2nd Ed, pg. 143           */
    import nrio.RXFile

    parse arg inputname lineendchar

    buffer = ''
    infile = RXFile(inputname)

    do forever
        nextchar = infile.CHARIN()
        if nextchar=lineendchar then leave
        buffer=buffer||nextchar
        end
   
    Say buffer

NetRexx even accepts the (incorrect) 'do forever' idiom with just a warning.
I didn't bother with queue which TRL describes as implementation dependent.

OK, what happens here? We wanted our old REXX I/O mechanisms. We didn't want to
muck around the whole day with FileInputStreams and their ilk. So we imported
Max Marsiglietti's RXFile class and magically got access to CHARIN, CHAROUT,
LINEIN, and friends.

Want your cake? Have it!

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

P.S.2: This is just an example of how I think this should be done. Surely much REXX-like
functionality is still  missing. Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. Which is BTW not the case for neither of the two conditions...

---

Saludos / Kind regards.

David Requena

 

 

 

Thanks for this David.   

 

We didn't want to
muck around the whole day with FileInputStreams and their ilk. 

 

1. Absolutely right!   Thanks for the example code.   I don't see this code documented in either MC's The NetRexx Language, MC's NetRexx 2, or IBM's Red Book: Creating Applications Using NetRexx.   Have I missed it somewhere, or is there another book that I need (the reference above suggests a book on Rexx rather than NetRexx; does the Rexx book actually cover NetRexx or do I need a different reference)?   

 

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

 

2. Where can I find Max Marsiglietti's classes, and anyone else's useful classes, and their documentation?   

 

3. How can we ensure that everyone gets a full set of documentation so that people do use RXFile, Rexx2Nrx, NetRexxDE etc?    It can't be that hard to create one depository for downloads can it?   Or better still (always the optimist), one comprehensive User Guide, and one Reference?

 

4. Objects are really good where inheritance can be the mechanism for reusability.  However, for basic classes, like String, it is a lot handier, and syntactically nicer, and no doubt more efficient, for them to be built into the language rather than being formally treated as Classes.   I would suggest that basic things like CHARIN and LINEIN are in this category; not sure why there is resistance to this (No disrespect to MC, but Classic Rexx would have been better, I believe, and Rexx programs more portable, if it contained I/O as part of the language).    

 

Surely much REXX-like
functionality is still  missing.

 

5. This is a limiting factor for NetRexx's success.   If we want NetRexx to take its rightful place, we DO need to fix this, one way or the other.

Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. 

     

6. It surprises me that we are now in 2010, still without a complete solution.   So what is the problem do we think, and what can be done about it?

 

7. How many subscribers are there to this forum, and how many have the Java skills to build the missing objects, and the time to do it?   If this number is less than 1, should we find some way of funding a contractor to do the work?   Or am I talking heresy?    Or are we aspiring to being a community of boring old farts, who talk a lot, achieve little, and seem irrelevant to real world programming?   Which are we closest to now?   (I'm deliberately being Devil's Advocate).  

 

Regards,

 

Connor.

 

 

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

 

***************************************************************************
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged.

If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank You.
****************************************************************************
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Fernando Cassia-2]

On Mon, Aug 23, 2010 at 1:52 AM, Rupp Peter - prupp
<[hidden email]> wrote:
> Actually, I would like to take a stab at this one.

Lovely discussion. I´m learning a lot.
I´d like to print this thread and re-read it every week.

And who started this?. Me, the humble guy.

(sorry, a little attempt at humor).
FC

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

El 22/08/2010 15:59, Connor Birch escribió:

We didn't want to
muck around the whole day with FileInputStreams and their ilk. 

1. Absolutely right!   Thanks for the example code.   I don't see this code documented in either MC's The NetRexx Language, MC's NetRexx 2, or IBM's Red Book: Creating Applications Using NetRexx.   Have I missed it somewhere, or is there another book that I need (the reference above suggests a book on Rexx rather than NetRexx; does the Rexx book actually cover NetRexx or do I need a different reference)?  

Well, it is not as it's a third party library. I wouldn't be documented at the canonical language documentation set unless we had some form of standard library or standard component repository to which it could be submitted.

In order to demonstrate that things can already be done with present NetRexx I went looking for a paradigmatic example of Classic REXX I/O. Were better to look than Mike's language specification book? ;-)

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

2. Where can I find Max Marsiglietti's classes, and anyone else's useful classes, and their documentation?  

Look at http://webspace.webring.com/people/ju/um_3777/. Documentation is included in the package.

3. How can we ensure that everyone gets a full set of documentation so that people do use RXFile, Rexx2Nrx, NetRexxDE etc?    It can't be that hard to create one depository for downloads can it?   Or better still (always the optimist), one comprehensive User Guide, and one Reference?

That seems to be a task for a dedicated NetRexx enthusiast (or a group of them)...

4. Objects are really good where inheritance can be the mechanism for reusability.  However, for basic classes, like String, it is a lot handier, and syntactically nicer, and no doubt more efficient, for them to be built into the language rather than being formally treated as Classes.   I would suggest that basic things like CHARIN and LINEIN are in this category; not sure why there is resistance to this (No disrespect to MC, but Classic Rexx would have been better, I believe, and Rexx programs more portable, if it contained I/O as part of the language).   

There're advantages too to the all-is-an-Object mantra. Java further advanced in this direction since NetRexx got frozen (see automatic un/boxing of primitive types). I mean, this is debatable.

 

Surely much REXX-like
functionality is still  missing.

5. This is a limiting factor for NetRexx's success.   If we want NetRexx to take its rightful place, we DO need to fix this, one way or the other.

Hmm.. not in my view. The stream based approach to I/O of the java platform provides some amazing genericity. Yes, it's a little harder to read a file but then you can use the very same piece of code to read from an openoffice document, an http request, another process' standard output, ..., you name it. All with a single API.

Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. 

     

6. It surprises me that we are now in 2010, still without a complete solution.   So what is the problem do we think, and what can be done about it?

Plainly nearly nobody is contributing anything today. We ,as a community start doing so.

There was once a proper NetRexx community (addmitedly linked to OS/2) which produced lots of good work like components, tutorials, FAQs, etc.
Where are today the Max Massiglietis, Mat Dillons, Martin Lafaix, etc. of lore?

7. How many subscribers are there to this forum, and how many have the Java skills to build the missing objects, and the time to do it?   If this number is less than 1, should we find some way of funding a contractor to do the work?   Or am I talking heresy?    Or are we aspiring to being a community of boring old farts, who talk a lot, achieve little, and seem irrelevant to real world programming?   Which are we closest to now?   (I'm deliberately being Devil's Advocate). 

We're dangerously near to match that description in my view ;-)


PD: Sorry folks, I've to leave now and go seeing a live echography of my soon to come new son! I'll post further replies later today :-) 



_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

One comment:
 

 4. Objects are really good where inheritance can be the mechanism for reusability.  However, for basic classes, like String, it is a lot handier, and syntactically nicer, and no doubt more efficient, for them to be built into the language rather than being formally treated as Classes.   I would suggest that basic things like CHARIN and LINEIN are in this category; not sure why there is resistance to this (No disrespect to MC, but Classic Rexx would have been better, I believe, and Rexx programs more portable, if it contained I/O as part of the language).      

 

But I/O *is* part of the languge in Classic Rexx.  The main reason I didn't include the CHAR and LINE functions in NetRexx was because at the time the base classes for I/O in Java were rather flaky, and I expected they would change or be enhanced, hence making it easier to do the Rexx-like model.   And then I ran out of time ...

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

  Am 22.08.2010 15:59, schrieb Connor Birch:
> 2. Where can I find Max Marsiglietti's classes, and anyone else's
> useful classes, and their documentation?
Helllo Connor & all,
    without wanting to make some *unwanted* advertising, I cannot insist
to repeat to this issue:

The Rexx2Nrx run-time package (idocumented onw:
www.Rexx2Nrx.com/run-time) does include:

RexxFile (my own implementation of Rexx line I/O).

Some tests I did do some years ago indicated, that it was 2-3 times
quicker than Max Marsiglietties 'nrio'
All methods are documented as wll on this home page.

The only things you have to do is:

Download  Rexx2Nrx from www.Rexx2Nrx.com, putting it onto the C disk,
for instance.

unzip Rexx2Nrx.zip (using the pathes provided)

add  'C:\Rexx2Nrx\Rexx2Nrx.jar' to your CLASSPATH

add the 'import Rexx2Nrx.Rexx2RT' NetRexx statement at the top of your
NetRexx program.

RexxFile implements bot a 'function oriented' as well as a 'method
oriented interface'

All the methods available are documented on www.Rexx2Nrx.com/-run-time
(on the left side frame).

This run-time package also includes a couple of classes, implementing
the 'function oriented'
implementation of the 'builtin' methods of NetRexx and/or the
'functions' missing in NetRexx,
as date,  time, random, etc.

All you have to do for using them in NetRexx is:

import Rexx2Nrx.Rexx2RT
class abc uses RexxFile, RexxTime , ...  -- note the use of the NetRexx
USES clause

file1='myfile.txt'

loop while lines(file1) > 0
    line=linein(file1)
    say line1
end

(for instance)

... when you like

Any questions/problems, ... just ask!

Thomas Schneider.

www.Rexx2Nrx.com
www.db-123.com
www.thsitc.com
--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[George Hovey-2]

Peter,
I have no quarrel with this but I don't quite get the point: is it that Python provides means to extend itself with external libraries?  So do C, C++, Java and NetRexx.  I've written a NetRexx class library supporting notions that I find useful in my work, for example, encapsulations of a subset of file I/O, that makes the target classes work in the NetRexx way.  As for "abstracting away platform-specifics", that is exactly what the Java Virtual Machine (JVM) does.
Further, Java contain a formal means of interfacing to C/C++ DLLs, and their equivalent in the 'nix world.  This gives access to a vast amount of code.

What every NetRexx programmer gains for free is immediate access to the Java class library (http://download.oracle.com/javase/1.4.2/docs/api/) with 2700+ classes and interfaces.  This is a very high quality library covering an extraordinary range of areas of business and engineering.  And it is not poorly coded.  Check out class Socket, for example; if this strikes you as too complex, wrap the parts you like in NetRexx and make it look any way you like.  NetRexx makes that easy.

No doubt a Standard NetRexx Class Library will exist once NetRexx is open sourced, and its definition and implementation can be under central control so as to avoid the quality issues you have mentioned.

As far as I can See  everything you've described already exists in Java, and hence in NetRexx.  And as you have noted, in a cleaner way.
George

On Mon, Aug 23, 2010 at 12:52 AM, Rupp Peter - prupp <[hidden email]> wrote:

Actually, I would like to take a stab at this one.

 

A couple perfect  examples of a Netrexx simplification of a complex java mess, would be something Python did with their standard library – specifically  Python’s socket and file objects, which are object abstractions of the Unix socket and file calls against a Unix file-handle.  Sure, they are Unix-like, but they are simple and very easy to code, and Python made it very easy.

 

For Python “file objects”, please see http://docs.python.org/library/stdtypes.html#file-objects

For Python “socket objects”, please see http://docs.python.org/library/socket.html

 

Here’s a description of what/why’s of Pythons Standard Library, and why it’s so cool….

(source: http://docs.python.org/library/)

“…Python’s standard library is very extensive, offering a wide range of facilities as indicated by the long table of contents listed below. The library contains built-in modules (written in C) that provide access to system functionality such as file I/O that would otherwise be inaccessible to Python programmers, as well as modules written in Python that provide standardized solutions for many problems that occur in everyday programming. Some of these modules are explicitly designed to encourage and enhance the portability of Python programs by abstracting away platform-specifics into platform-neutral APIs.”

You could write everything in netRexx syntax, but you don’t have to!  Instead, you can incorporate other folks java libraries (or products), of who wish to make them available as open-source.   You could incorporate these libraries into the netRexx “standard” library, one could probably create a netRexx “wrapper” object surrounding a call to other third-party java libraries that have contributed their code to open-source and netRexx.  This is exactly how Python language handles many of their standard library functions, which are implemented as C libraries, and somebody wrote a python “object” wrapper around it.   On the other hand, before you go running off and incorporating all sorts of libraries, you might want to test them first – many open-sourced libraries are written poorly, and either perform poorly or have serious bugs.   (stop me if you’ve heard this one before).   So, when building a standard library, it might be a good idea to have a quality process (test harness) built in to test various cases before releasing anything.

 

You may be asking…”Well Pete, why don’t you just use Jython?”, and the answer would be….I do, and it works pretty well, but I don’t believe the designers of the language have as clean design or long-term prospects that netRexx does.   In many cases, I have had Jython crash both the IBM and SUN jvm’s at different points….and this does not give me confidence… So I believe in netRexx.

 

As Blago would say “I may be crazy, but I’m not nuts)  

A poor attempt at humor ;-)

Peter

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: Sunday, August 22, 2010 10:42 AM

To: IBM Netrexx
Subject: Re: [Ibm-netrexx] People who loved Rexx now speak about it in pasttense... :/

 

Connor,

It seems to me that what you are asking for might already be available in ooRexx.  Why not take a look at ooRexx -- it may be the answer to your prayers.

However, if not, you might give a close reading to MFC's "Introduction" and "Language Objectives", especially the section "Influence of Java" in the document "NetRexx 2" dated 22 May 2009.  It makes clear that he is after much more than byte code portability in targeting Java as NetRexx's "object language".  NetRexx is not just another JVM language du jour -- it has an intimate relationship with Java :).  Although MFC doesn't rule out directly targeting the JVM, that is not the route he chose.

BTW, it is not necessary that NetRexx programmers "understand the complex underworld of Java" in order to write useful programs.  As David points out, the places where we would like simplification, say file I/O, can be handled by libraries.

Finally, could you give me some idea of what a "no-nonsense object" that makes sense to Rexx programmers might be like?
George

On Sun, Aug 22, 2010 at 9:59 AM, Connor Birch <[hidden email]> wrote:

 

On 21 Aug 2010, at 21:06, David Requena wrote:

El 21/08/2010 13:06, Connor Birch escribió:

[1] The powerful idea behind Classic Rexx is that it insulates the programmer from tedious things like the underlying machine's word length.   The computer does the trivial work so the programmer can concentrate on the real work.

 

[2] Using a ubiquitous virtual machine, ie Java VM, as the target architecture is a powerful way of being able to support NetRexx on most architectures.   

 

But, if in capitalising on [2], programmers need to understand the complex underworld of Java, we have thrown away the benefit of [1].

 

I recommend that we have our cake [1] and eat it [2]:   

 

We create no-nonsence objects and functions/instructions that make sense to Rexx programmers that are translated/compiled into Java Objects.

I don't know if you realize that last sentence really hits the nail:

- You want some classic-rexx-like abstraction or idiom in NetRexx?
- OK, we build objects (classes) and functions/instructions (methods) on top of java objects.

The point is: NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES

This can be done today, it's already done for REXX I/O.

Don't take my word, behold:

    /* Adaption of COLLECTOR, an example found at: *
     * The REXX LANGUAGE 2nd Ed, pg. 143           */
    import nrio.RXFile

    parse arg inputname lineendchar

    buffer = ''
    infile = RXFile(inputname)

    do forever
        nextchar = infile.CHARIN()
        if nextchar=lineendchar then leave
        buffer=buffer||nextchar
        end
   
    Say buffer

NetRexx even accepts the (incorrect) 'do forever' idiom with just a warning.
I didn't bother with queue which TRL describes as implementation dependent.

OK, what happens here? We wanted our old REXX I/O mechanisms. We didn't want to
muck around the whole day with FileInputStreams and their ilk. So we imported
Max Marsiglietti's RXFile class and magically got access to CHARIN, CHAROUT,
LINEIN, and friends.

Want your cake? Have it!

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

P.S.2: This is just an example of how I think this should be done. Surely much REXX-like
functionality is still  missing. Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. Which is BTW not the case for neither of the two conditions...

---

Saludos / Kind regards.

David Requena

 

 

 

Thanks for this David.   

 

We didn't want to
muck around the whole day with FileInputStreams and their ilk. 

 

1. Absolutely right!   Thanks for the example code.   I don't see this code documented in either MC's The NetRexx Language, MC's NetRexx 2, or IBM's Red Book: Creating Applications Using NetRexx.   Have I missed it somewhere, or is there another book that I need (the reference above suggests a book on Rexx rather than NetRexx; does the Rexx book actually cover NetRexx or do I need a different reference)?   

 

P.S.: RXFile have been available for ages now. I don't see anybody using it. Instead
I keep reading complains about NetRexx not having the features it implements.

 

2. Where can I find Max Marsiglietti's classes, and anyone else's useful classes, and their documentation?   

 

3. How can we ensure that everyone gets a full set of documentation so that people do use RXFile, Rexx2Nrx, NetRexxDE etc?    It can't be that hard to create one depository for downloads can it?   Or better still (always the optimist), one comprehensive User Guide, and one Reference?

 

4. Objects are really good where inheritance can be the mechanism for reusability.  However, for basic classes, like String, it is a lot handier, and syntactically nicer, and no doubt more efficient, for them to be built into the language rather than being formally treated as Classes.   I would suggest that basic things like CHARIN and LINEIN are in this category; not sure why there is resistance to this (No disrespect to MC, but Classic Rexx would have been better, I believe, and Rexx programs more portable, if it contained I/O as part of the language).    

 

Surely much REXX-like
functionality is still  missing.

 

5. This is a limiting factor for NetRexx's success.   If we want NetRexx to take its rightful place, we DO need to fix this, one way or the other.

Honestly, I believe if there actually existed a NetRexx
community, and if Classic REXX lovers were a significant portion of it, these things would
already be implemented. 

     

6. It surprises me that we are now in 2010, still without a complete solution.   So what is the problem do we think, and what can be done about it?

 

7. How many subscribers are there to this forum, and how many have the Java skills to build the missing objects, and the time to do it?   If this number is less than 1, should we find some way of funding a contractor to do the work?   Or am I talking heresy?    Or are we aspiring to being a community of boring old farts, who talk a lot, achieve little, and seem irrelevant to real world programming?   Which are we closest to now?   (I'm deliberately being Devil's Advocate).  

 

Regards,

 

Connor.

 

 

 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

 

***************************************************************************

The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged.

If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank You.
****************************************************************************

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[FreeFall]

One comment:
 

 4. Objects are really good where inheritance can be the mechanism for reusability.  However, for basic classes, like String, it is a lot handier, and syntactically nicer, and no doubt more efficient, for them to be built into the language rather than being formally treated as Classes.   I would suggest that basic things like CHARIN and LINEIN are in this category; not sure why there is resistance to this (No disrespect to MC, but Classic Rexx would have been better, I believe, and Rexx programs more portable, if it contained I/O as part of the language).      

 

But I/O *is* part of the languge in Classic Rexx. 

Sorry, I'm showing my antiquity, I used to use the first version of Classic Rexx, and needed EXECIO on VM for I/O

The main reason I didn't include the CHAR and LINE functions in NetRexx was because at the time the base classes for I/O in Java were rather flaky, and I expected they would change or be enhanced, hence making it easier to do the Rexx-like model.   And then I ran out of time ...

 

Mike

That makes sense.   Do you have more time now, at least to add these to the specification?, and/or influence the compiler writers? 

I like Peter's comments on Python; I don't know Python but it sounds as if it could be what we need.   Perhaps we should ride on the back of that (after all, that's the point of object orientation), and make the Python standard library work with NetRexx?   Sounds like a small effort for a large gain.

Connor.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

The main reason I didn't include the CHAR and LINE functions in NetRexx was because at the time the base classes for I/O in Java were rather flaky, and I expected they would change or be enhanced, hence making it easier to do the Rexx-like model.   And then I ran out of time ... 

 

 That makes sense.   Do you have more time now, at least to add these to the specification?, and/or influence the compiler writers?  

 

Time, possibly -- but not the motivation.  I am not doing anything on the Java platform (and haven't done since working on BigDecimal in 2003).   So I'm not current, and NetRexx isn't much use to me.   I don't even have the Java SDK installed anywhere at the moment. 

 

Mike  (still writing lots of -- mostly classic -- Rexx, tho!).

_______________________________________________
Ibm-netrexx mailing list
[hidden email]