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

[David Requena]

El 22/08/2010 16:32, George Hovey escribió:

Your statement "NO NEEDED OPEN SOURCE NetRexx, NO NEEDED NetRexx modification. JUST LIBRARIES"

What I did mean (not particularly addressed to you) is:
Maybe it's time to stop bickering about NetRexx not being open source or lacking some feature and start *using what is* available or *implementing what is missed*.
I keep reading people complaining about NetRexx lacking REXX I/O. Well, there are already two different implementations of this and *nobody* uses them.

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.

Where could this idea come from? NetRexxC has been at java 1.1.2 since the time pterodactyls flew daily. NetRexxA has been at java 1.2 since little later.

It's a well known fact in this list I've certain grievances with NetRexx as it is today. These are mainly related to that very same fact: the java platform continued evolving ant NetRexx is starting to lag.

My proposals have all been directed to strengthen NetRexx interoperability with newer java versions:

- No longer working scripts in the distributed package.
- Real inner minor classes (thats not local or anonymous).
- Having Rexx type implement CharSequence interface as string does.
- Implemented interfaces taken into account when matching method signatures.
- Apply some kind type inference to Collections so we get java generics without its abhorrent syntax.

So no, I diden't mean that :-)

---


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

El 22/08/2010 16:58, René Jansen escribió:

The 'declined interoperability' did never preclude me from doing useful work.

Same here

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.

Agreed. That would simplify the use of collections from NetRexx by avoiding the need for unnatural continuous casts. No need for specific syntax.

You have seen what inner class support stirred up.

Or the lack of full support for them ;-)

Generally spoken, changes should pass the language board before being considered for implementation. By the way, we have some vacant positions there.

That is a cryptic offer that I think should be more explicitly stated. Or not at all :-)

---


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

This is beginning to seem a bad case of a debate with everyone defending more or less the same points!!
;-)

El 22/08/2010 20:07, George Hovey escribió:

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]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[David Requena]

Peter,

I think I more or less share your vision. Keeping the language itself as simple and small as possible while implementing as much functionality in its *standard library* is "The right way to go"(TM).

NetRexx already has access to java's massive library as a starting point which can and should be leveraged. Adding a rexxsish layer on top of it shouldn't be a problem as I tried to convey with my former example on REXX I/O.

I envision a central repository à la CPAN in which library and software components would be available for users to mix and match. They would be categorized by functional area (or domain if you like) but also by sanctioned or contrib status. The former would be packaged under org.netrexx.* and would need to pass stricter controls for inclusion (may be even RexxLA signed jars!)

To be honest I've been working in a proof of concept of one such an infrastructure. That, when ready for public review will (again) much of this can be done without any language modification nor access to NetRexxC sources. Anyone whiling to help is welcome!

NetRexx in its present state is a wonderfully capable language. That is after all why we all are subscribed to this very same list.


El 23/08/2010 6:52, Rupp Peter - prupp escribió:

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] [[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]

[David Requena]

Thomas,

That would never qualify as advertising. It is for once right on topic!
I'm asking four your forgiveness on my forgetting to mention your product in my previous discussion.

El 23/08/2010 12:20, Thomas Schneider escribió:

 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

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

Hello David,
   I would like to *underline* your suggested approach.

As far as I am concerned, all of the Rexx2Nrx run-time library has already gone open source (at www.KENAI.com, project Rey)

The only change to the 'documented' version on www.Rexx2Nrx.com is that:

The package name is 'com.thsitc.rey.rt'  (and not Rexx2Nrx.Rexx2RT)
     -- this change was made to follow common Java rules, indicating the responsible party

The prefix 'Rexx' in the varios classes has been replaced by 'Rey'., to avoid conflicts with potential duplcate names,
as I did encounter with my implementation of TRACE (for tracing the original classic rexx Source), and to avoid
short name conflicts with future standard NetRexx vs. 3 classes.

The class 'strfun' has been renamed to ReyFuncs.

All methods documented are still available.

And some missing methods have been added to provide all functions available in 'classic Rexx' in a function oriented
manner as well.

I already did propose to Rene to use this run-time library in the first NetRexx open source distribution, but he replied
he does want to seperate the 'phases', which I do fully understand.

I am currently in process to update the documentation and produce a PDF for the Run-time package as a single document.

kind regards from Vienna,
Tom.

========================================================================================= 
Am 23.08.2010 20:44, schrieb David Requena:

Peter,

I think I more or less share your vision. Keeping the language itself as simple and small as possible while implementing as much functionality in its *standard library* is "The right way to go"(TM).

NetRexx already has access to java's massive library as a starting point which can and should be leveraged. Adding a rexxsish layer on top of it shouldn't be a problem as I tried to convey with my former example on REXX I/O.

I envision a central repository à la CPAN in which library and software components would be available for users to mix and match. They would be categorized by functional area (or domain if you like) but also by sanctioned or contrib status. The former would be packaged under org.netrexx.* and would need to pass stricter controls for inclusion (may be even RexxLA signed jars!)

To be honest I've been working in a proof of concept of one such an infrastructure. That, when ready for public review will (again) much of this can be done without any language modification nor access to NetRexxC sources. Anyone whiling to help is welcome!

NetRexx in its present state is a wonderfully capable language. That is after all why we all are subscribed to this very same list.


El 23/08/2010 6:52, Rupp Peter - prupp escribió:

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] [[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]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]