Upcoming release 4.01 of NetRexx

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Upcoming release 4.01 of NetRexx

ThSITC
Hi there,

Going from 3.04 to 4.01 is a *major step*.

As the first November 2015 is very soon:

1.) Is there anywhere a *white paper* describing *what is coming up* ?
2.) May&Should  I help in testing the new version?

I'm currently working quite a lot with NetRexx 3.04. Congratulation for
the Devel Team.

Kind regards from Vienna,
Thomas Schneider.



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

Kermit Kiser
Thomas --

Since no one else seems to be responding to your notes, I will take a
brief try.

I don't know where you are getting your date projections concerning
NetRexx releases but I do know that in the years since NetRexx was made
open source in 2011, only one new version has been released per year.
These have all been 3.0x versions which are relatively minor changes
compared to the possible changes in a 4.xx release. (The Kenai mention
of 4.00 at Nov. 2015 is probably an accidental misstatement.)

Many of the requested features for a 4.xx NetRexx version involve
changes to the language syntax or at least the addition of instructions
or keywords. These kinds of changes really require discussion on the
list and some consensus by the ARB before implementation is possible. I
have not seen any such discussions. The only feature I have seen any
work or discussion on recently is an "address" feature that René seems
to be pursuing but there is not even a Kenai issue requesting such a
feature and no discussions on the NetRexx mailing list about it.

I don't see any possibility of a 4.xx release this year or probably even
next year. There are now enough change requests and problem reports on
the project site to justify another 3.xx release, possibly in 2016 if
resources allow.

You probably will not like my next conclusion and it's reasoning:

NetRexx is dead.

There are 40 members on the project site and about 50 semi-active
members on the mailing list. I doubt there are more than a few hundred
NetRexx programmers in the whole world. Pretty much only René and myself
actively develop features and fixes for NetRexx and our time there is
quite limited by other life activities in general. That is not a
self-sustaining community.

NetRexx is the "Betamax" of computer languages: We who use it know that
it is much more powerful and efficient to use than other languages, but
there is not enough "market share" to keep it alive.

NetRexx is marketed to the wrong target audience. Some Java programmers
might look at it but most of those people looking for an alternative JVM
language have selected or will select one of the more popular JVM
languages: Jython, JRuby, Groovy. They won't look much at NetRexx
because few use it and it is not requested in Job postings. A better
target audience would be newcomers such as MIT and UC Berkeley are
addressing with Scratch, Snap!, App Inventor, etc. NetRexx should
interface with something like Blockly for presenting an IDE. The future
is visual programming and NetRexx should stake a claim in that realm and
address new programmers in order to have a chance to move forward.

NetRexx (the translator) is poorly written. Don't get me wrong - Mike
Cowlishaw is brilliant and an inspired writer of efficient code! But the
NetRexx translator is ivory tower precision that discards parse tree
elements as soon as possible and uses other efficient optimizations that
completely ignore the needs of real world programmers for an IDE and
other development cycle tools like Eclipse, Netbeans, Ant, builders,
testers etc. that can integrate with it. No exits or hooks or structures
for such development tools exist. This helps create a "chicken or egg"
problem: Without development tools, programmers will not choose NetRexx.
Without programmers, there is no one to create developer tools.

I am sorry if this disturbs your view of the future but I am trying to
be realistic here. The lack of response to your inquiries only confirms
my viewpoint.

-- Kermit

On 2015-10-05 3:49 AM, Thomas Schneider wrote:

> Hi there,
>
> Going from 3.04 to 4.01 is a *major step*.
>
> As the first November 2015 is very soon:
>
> 1.) Is there anywhere a *white paper* describing *what is coming up* ?
> 2.) May&Should  I help in testing the new version?
>
> I'm currently working quite a lot with NetRexx 3.04. Congratulation for
> the Devel Team.
>
> Kind regards from Vienna,
> Thomas Schneider.
>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

Mike Cowlishaw
 
Kermit wrote:

> NetRexx (the translator) is poorly written. Don't get me
> wrong - Mike Cowlishaw is brilliant and an inspired writer of
> efficient code! But the NetRexx translator is ivory tower
> precision that discards parse tree elements as soon as
> possible and uses other efficient optimizations that
> completely ignore the needs of real world programmers for an
> IDE and other development cycle tools like Eclipse, Netbeans,
> Ant, builders, testers etc. that can integrate with it. No
> exits or hooks or structures for such development tools
> exist.

I think that's a little unfair.  The translator was written (bootstrapped)
in classic Rexx, and it was/is difficult to represent a parse tree in that
language.  That is the main reason for the very 'flat' structure of the
translator.  Further, the translator was intended to be suitable for other
source languages than Rexx (NetRexx) -- we had five in mind (one of which
was SmallTalk) which needed quite different parse trees.  And finally, the
PCs that NetRexx ran on in 1995 were about 400 times slower than today's, so
the emphasis on efficiency was essential.  The translator was barely fast
enough to be useable on anything but the latest machines at the time.

As for exits and hooks for Eclipse, etc., since those didn't exist at that
time it was not possible to foresee what would be required.  Indeed, few
IDEs existed at that time, and very few people used them.

Writing programs today is very different from 20 years ago.  As an example,
my current project, MapGazer, is built in a much simpler way than the old
PMGlobe program; the former rewrites multiple windows or the entire screen
on every mouse-move whereas the latter goes to enormous lengths to only
write areas of the window that have changed.

If writing a language translator today I would structure it very differently
from the NetRexx translator.  Ideally the translator should be rewritten
with the benefit of hindsight, but as you imply, it's probably not worth the
effort.

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

ThSITC
In reply to this post by Kermit Kiser
Hi Kermit,

many thanks for Your response.

I think, however, You are too pessimistic. For sure, MFC did his best at
the time he did invent NetRexx. When my memory does serve me right, he
did originally design the Translator originally for *other Languages* as
well, and did have to work on much less effective computers back in the
1990's then nowadays. Also, all those IDE's nowadays
available have not been present those days.

I haven't seen any reports what the NetRexx ARB is discussing. I got the
Date Nov. 2015 for the 4.0 release from
Kenai (sorry, wrote 4.01 in the topic above).

Anyway, the organizer of the Java Users Group here in Vienna did express
a *sounds interesting* after I did
forward my intention to present NetRexx on this meeting in December 2015
(including the www.netrexx.org URL,
which he did shortly review).

As I will be a speaker there start of Decemeber now anyway, I am asking
all members of the group to send me their
synopsis. I currently have no access to the RexxLA contents, as I
haven't been able to pay the
annual fee for private reasons ... :-(

What You and Rene are doing for NetRexx maintenance is great.

Keep pls. up the great work :-)
Thomas Schneider.
==================================================================================================



Am 18/10/2015 um 06:11 schrieb Kermit Kiser:

> Thomas --
>
> Since no one else seems to be responding to your notes, I will take a
> brief try.
>
> I don't know where you are getting your date projections concerning
> NetRexx releases but I do know that in the years since NetRexx was
> made open source in 2011, only one new version has been released per
> year. These have all been 3.0x versions which are relatively minor
> changes compared to the possible changes in a 4.xx release. (The Kenai
> mention of 4.00 at Nov. 2015 is probably an accidental misstatement.)
>
> Many of the requested features for a 4.xx NetRexx version involve
> changes to the language syntax or at least the addition of
> instructions or keywords. These kinds of changes really require
> discussion on the list and some consensus by the ARB before
> implementation is possible. I have not seen any such discussions. The
> only feature I have seen any work or discussion on recently is an
> "address" feature that René seems to be pursuing but there is not even
> a Kenai issue requesting such a feature and no discussions on the
> NetRexx mailing list about it.
>
> I don't see any possibility of a 4.xx release this year or probably
> even next year. There are now enough change requests and problem
> reports on the project site to justify another 3.xx release, possibly
> in 2016 if resources allow.
>
> You probably will not like my next conclusion and it's reasoning:
>
> NetRexx is dead.
>
> There are 40 members on the project site and about 50 semi-active
> members on the mailing list. I doubt there are more than a few hundred
> NetRexx programmers in the whole world. Pretty much only René and
> myself actively develop features and fixes for NetRexx and our time
> there is quite limited by other life activities in general. That is
> not a self-sustaining community.
>
> NetRexx is the "Betamax" of computer languages: We who use it know
> that it is much more powerful and efficient to use than other
> languages, but there is not enough "market share" to keep it alive.
>
> NetRexx is marketed to the wrong target audience. Some Java
> programmers might look at it but most of those people looking for an
> alternative JVM language have selected or will select one of the more
> popular JVM languages: Jython, JRuby, Groovy. They won't look much at
> NetRexx because few use it and it is not requested in Job postings. A
> better target audience would be newcomers such as MIT and UC Berkeley
> are addressing with Scratch, Snap!, App Inventor, etc. NetRexx should
> interface with something like Blockly for presenting an IDE. The
> future is visual programming and NetRexx should stake a claim in that
> realm and address new programmers in order to have a chance to move
> forward.
>
> NetRexx (the translator) is poorly written. Don't get me wrong - Mike
> Cowlishaw is brilliant and an inspired writer of efficient code! But
> the NetRexx translator is ivory tower precision that discards parse
> tree elements as soon as possible and uses other efficient
> optimizations that completely ignore the needs of real world
> programmers for an IDE and other development cycle tools like Eclipse,
> Netbeans, Ant, builders, testers etc. that can integrate with it. No
> exits or hooks or structures for such development tools exist. This
> helps create a "chicken or egg" problem: Without development tools,
> programmers will not choose NetRexx. Without programmers, there is no
> one to create developer tools.
>
> I am sorry if this disturbs your view of the future but I am trying to
> be realistic here. The lack of response to your inquiries only
> confirms my viewpoint.
>
> -- Kermit
>
> On 2015-10-05 3:49 AM, Thomas Schneider wrote:
>> Hi there,
>>
>> Going from 3.04 to 4.01 is a *major step*.
>>
>> As the first November 2015 is very soon:
>>
>> 1.) Is there anywhere a *white paper* describing *what is coming up* ?
>> 2.) May&Should  I help in testing the new version?
>>
>> I'm currently working quite a lot with NetRexx 3.04. Congratulation for
>> the Devel Team.
>>
>> Kind regards from Vienna,
>> Thomas Schneider.
>>
>>
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>>
>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

Fernando Cassia-2
In reply to this post by Kermit Kiser
On 10/18/15, Kermit Kiser <[hidden email]> wrote:

> You probably will not like my next conclusion and it's reasoning:
>
> NetRexx is dead.

I would change your statement to "All languages(*) are (mostly) dead"
"as long as they don't run inside the browser OR are not used for
low-level, OS programming (C/C++)".

In other words, everything is (sadly, imho) moving "to the web", which
in today's standards means JS/HTML5. Java stays relevant because it
runs complex business code on the server side. Client side Java
(desktop java apps, not applets) stays _somewhat_ relevant because of
SWT/Swing and a handful of well-written good apps (Jitsi, Vuze,
JDwonloader, Sweet Home 3D, Minecraft, come to mind). [wrt Desktop
Java, the upcoming Java 9 with its modular approach and the ability to
also compile stand-alone, native executables will help Java code get
into places that until now were reluctant to deploy anything Java].

In order to stay relevant going forward, all other languages need to
be "translated" into JS, or run more or less seamlessly within the
browser. That's what ANY language that wants to stay somewhat
mainstream and relvant imho needs to get into.

I'm not saying JVM languages don't have a niche. They do. Jython and
JRuby thrive because they solve problems with Python and Ruby by
extending the former langs into the JVM ecosystem and libraries.

I think a NetRexx-to-JS translator (or maybe NetRexx-on-DukeScript?
has anyone tried that?) would raise some eyebrows. Netbeans
integration would be possible if someone approaches the guys from the
NB team and ask for help on how to do a plug-in (I've seen more
obscure langs with NB plugin support).

Finally, let me mention that, to exaggerate, "there's a new language
born every minute" (eg GOLO, another JVM lang from some research
institute in France, now handed over to the Eclipse Foundation), and
niche langs all face the same troubles. It's not like NetRexx is alone
in this situation.

Extending NetRexx into other apps/products/frameworks is the way to
keep it relevant. How about controlling Gnome/KDE from NetRexx ?How
about making NetRexx runnable on Linux "automagically" like Bash
scripts? Could that be part of the setup/install process?. These are
little things that can be slowly built over time....

Once someone sees a language/script solving some real problem of his,
from the arrangement of icons on his desktop to fetching news and
displaying em on their desktop as a scrolling feed, people get
interested and start looking into it, like it happened with
traditional Rexx under OS/2. People didn't get into Rexx because they
were attracted to the name or language. They (mostly) got into OS/2
Rexx because they first downloaded a script to do a certain task on
their OS/2 system, then they attempted to modify it to do something
else, then they were confident enough to write another script to do
another task, and so the snowball grew and kept moving. ;)

Sadly I haven't had the time to play with NetRexx, but sooner or later
I will. Not all hope is lost ;)

FC

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

Fernando Cassia-2
In reply to this post by Kermit Kiser
On 10/18/15, Kermit Kiser <[hidden email]> wrote:

> You probably will not like my next conclusion and it's reasoning:
>
> NetRexx is dead.
>
> There are 40 members on the project site and about 50 semi-active
> members on the mailing list. I doubt there are more than a few hundred
> NetRexx programmers in the whole world.

- "Nobody comes to this cafe anymore".
- Does anybody else even know that this coffee shop is here, on this
dark corner of the city?
- I don't know... if they want to come they should be here. *shrugs*

...So the regulars look at each other and decide life sucks, and that
their favorite meeting place is doomed. ;-)

Think about this from a biology, evolutionary perspective. When
smaller, more fragile species want to survive what do they do?. They
jump onto another species, piggyback onto them, use them for food,
heat, or transportation. Fleas couldn't thrive and go places without
dogs as hosts.

Sorry for the comparison, I couldn't think of an easier one. ;)

Ok, fleas are not the best image... unless in a cartoon...

http://cdn.toonvectors.com/images/2/3798/toonvectors-3798-940.jpg

here are some nicer ones ...

http://i.dailymail.co.uk/i/pix/2012/09/21/article-0-151FB79E000005DC-662_638x415.jpg
http://animals.ekstrax.com/wp-content/uploads/2014/03/Animals-riding-animals-21.jpg

Translation: "NetRexx everywhere"
NetRexx hooks and NetRexx samples for every piece of software you can think of.
PLUS, perhaps more importantly, examples of NetRexx interfacing into
such software, and mention of NetRexx into other projects'
documentation.

See? great idea. Now we only need someone to work on it 24/7/365.
;-) *sarcasm*

FC

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

Kermit Kiser
In reply to this post by Mike Cowlishaw
Perhaps I was a bit unfair in my characterization of the NetRexx
translator. I understand the logic of your reply.

But I am also somewhat biased since I spent much of my 31 year IT career
attempting to customize and integrate IBM software into an environment
with thousands of diverse users with unique needs. IBM software seldom
allowed much customization or enhancement in my experience and seemed to
be designed to prohibit any usage patterns that were outside of concepts
imagined by the developers.

(It was a philosophy issue - instead of maximizing product flexibility
as I would do, IBM minimized it. For example I supported an IBM
mainframe program product called ISPF for many years. Several user exits
were incorporated in the product but the only function allowed by IBM in
these exits was to log usage. I could not restrict access to functions
or add functionality to the product or do any customization whatsoever
via the exits. I know these "narrow vision" restrictions were arbitrary
and unneeded because an earlier predecessor of the product allowed an
exit (which was inherited by ISPF for compatibility) to slip through
which gave complete access to product functionality and enhancement
capabilities! But the later IBM seemed unable to accept that a user
might have different workflow requirements than they had conceived
internally. End of rant!)

Anyway, whatever the reason, NetRexx is not easy to customize or enhance
or integrate with other tools like code analyzers or code completers, etc.

I am sorry if my view offends.

-- Kermit

On 2015-10-18 12:02 AM, Mike Cowlishaw wrote:

>  
> Kermit wrote:
>
>> NetRexx (the translator) is poorly written. Don't get me
>> wrong - Mike Cowlishaw is brilliant and an inspired writer of
>> efficient code! But the NetRexx translator is ivory tower
>> precision that discards parse tree elements as soon as
>> possible and uses other efficient optimizations that
>> completely ignore the needs of real world programmers for an
>> IDE and other development cycle tools like Eclipse, Netbeans,
>> Ant, builders, testers etc. that can integrate with it. No
>> exits or hooks or structures for such development tools
>> exist.
> I think that's a little unfair.  The translator was written (bootstrapped)
> in classic Rexx, and it was/is difficult to represent a parse tree in that
> language.  That is the main reason for the very 'flat' structure of the
> translator.  Further, the translator was intended to be suitable for other
> source languages than Rexx (NetRexx) -- we had five in mind (one of which
> was SmallTalk) which needed quite different parse trees.  And finally, the
> PCs that NetRexx ran on in 1995 were about 400 times slower than today's, so
> the emphasis on efficiency was essential.  The translator was barely fast
> enough to be useable on anything but the latest machines at the time.
>
> As for exits and hooks for Eclipse, etc., since those didn't exist at that
> time it was not possible to foresee what would be required.  Indeed, few
> IDEs existed at that time, and very few people used them.
>
> Writing programs today is very different from 20 years ago.  As an example,
> my current project, MapGazer, is built in a much simpler way than the old
> PMGlobe program; the former rewrites multiple windows or the entire screen
> on every mouse-move whereas the latter goes to enormous lengths to only
> write areas of the window that have changed.
>
> If writing a language translator today I would structure it very differently
> from the NetRexx translator.  Ideally the translator should be rewritten
> with the benefit of hindsight, but as you imply, it's probably not worth the
> effort.
>
> Mike
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

Mike Cowlishaw
 

> Perhaps I was a bit unfair in my characterization of the
> NetRexx translator. I understand the logic of your reply.
>
> But I am also somewhat biased since I spent much of my 31
> year IT career attempting to customize and integrate IBM
> software into an environment with thousands of diverse users
> with unique needs. IBM software seldom allowed much
> customization or enhancement in my experience and seemed to
> be designed to prohibit any usage patterns that were outside
> of concepts imagined by the developers.
>
> (It was a philosophy issue - instead of maximizing product
> flexibility as I would do, IBM minimized it. For example I
> supported an IBM mainframe program product called ISPF for
> many years. Several user exits were incorporated in the
> product but the only function allowed by IBM in these exits
> was to log usage. I could not restrict access to functions or
> add functionality to the product or do any customization
> whatsoever via the exits. I know these "narrow vision"
> restrictions were arbitrary and unneeded because an earlier
> predecessor of the product allowed an exit (which was
> inherited by ISPF for compatibility) to slip through which
> gave complete access to product functionality and enhancement
> capabilities! But the later IBM seemed unable to accept that
> a user might have different workflow requirements than they
> had conceived internally. End of rant!)

Have to agree about ISPF -- although I rarely used it.  But it's not really
'an IBM philosophy' ... my LEXX editor (written ten years before NetRexx)
was totally modular and extensible -- every command was a separate module
either written in Rexx or PL/I and users could add and modify any command as
they wished.

Indeed, originally VM/CMS was shipped with source code.  It was a sad day
when it went 'object code only' ... End of rant!

:-)

Mike


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

Martin Packer
I suspect the real issue - as with MOST software vendors - is the amount of developer time / budget available.

But then I code my own stuff on The "Principle" Of Sufficient Disgust :-) so what do *I* know? :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,

Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: [hidden email]

Twitter / Facebook IDs: MartinPacker
Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:        "Mike Cowlishaw" <[hidden email]>
To:        "'IBM Netrexx'" <[hidden email]>
Date:        21/10/2015 10:15
Subject:        Re: [Ibm-netrexx] Upcoming release 4.01 of NetRexx
Sent by:        [hidden email]




 

> Perhaps I was a bit unfair in my characterization of the
> NetRexx translator. I understand the logic of your reply.
>
> But I am also somewhat biased since I spent much of my 31
> year IT career attempting to customize and integrate IBM
> software into an environment with thousands of diverse users
> with unique needs. IBM software seldom allowed much
> customization or enhancement in my experience and seemed to
> be designed to prohibit any usage patterns that were outside
> of concepts imagined by the developers.
>
> (It was a philosophy issue - instead of maximizing product
> flexibility as I would do, IBM minimized it. For example I
> supported an IBM mainframe program product called ISPF for
> many years. Several user exits were incorporated in the
> product but the only function allowed by IBM in these exits
> was to log usage. I could not restrict access to functions or
> add functionality to the product or do any customization
> whatsoever via the exits. I know these "narrow vision"
> restrictions were arbitrary and unneeded because an earlier
> predecessor of the product allowed an exit (which was
> inherited by ISPF for compatibility) to slip through which
> gave complete access to product functionality and enhancement
> capabilities! But the later IBM seemed unable to accept that
> a user might have different workflow requirements than they
> had conceived internally. End of rant!)

Have to agree about ISPF -- although I rarely used it.  But it's not really
'an IBM philosophy' ... my LEXX editor (written ten years before NetRexx)
was totally modular and extensible -- every command was a separate module
either written in Rexx or PL/I and users could add and modify any command as
they wished.

Indeed, originally VM/CMS was shipped with source code.  It was a sad day
when it went 'object code only' ... End of rant!

:-)

Mike


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive :
http://ibm-netrexx.215625.n3.nabble.com/




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

ThSITC
I *think* one of the major reasons of the currently missing *success* of NetRexx is that
*IBM* did never actively *market* it.

Whil'st classic Rexx, as well as NetRexx, did have a *lot* of IBM-internal enthusiasts, they
were hidden from the outside world (i.e. IBM Customers) by IBM.

A couple of years ago (around 2005) I did speak with IBM Austria Tech people:
They were not even aware that NetRexx does exist at all.

This has been due to the fact that IBM those times did force EGL  :-(

I think that NetRexx, when invented on a University, could have the strength
as Nikolas Wirth's Pascal did have many years ago in *Teaching Programming*.

May I, anyway, *remind You* that I'm still waiting for answers my previous
msg:

Please do forward any good NetRexx Language Presentations to me
until 7th November the latest for consolidation, as I do have my 1 h speak
at the Technical University of Vienna at the Java Users Group Meetup there,
with some 64 participants - Young Students and Company Founders.


My intention is to *consolidate* what I get

The Topic of my presentation is:

NetRexx -- a human oriented Language for Java Users.

Greetings from Cloudy Vienna.
Thomas Schneider.
======================================================================





Am 21/10/2015 um 11:26 schrieb Martin Packer:
I suspect the real issue - as with MOST software vendors - is the amount of developer time / budget available.

But then I code my own stuff on The "Principle" Of Sufficient Disgust :-) so what do *I* know? :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,

Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: [hidden email]

Twitter / Facebook IDs: MartinPacker
Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:        "Mike Cowlishaw" [hidden email]
To:        "'IBM Netrexx'" [hidden email]
Date:        21/10/2015 10:15
Subject:        Re: [Ibm-netrexx] Upcoming release 4.01 of NetRexx
Sent by:        [hidden email]




 
> Perhaps I was a bit unfair in my characterization of the
> NetRexx translator. I understand the logic of your reply.
>
> But I am also somewhat biased since I spent much of my 31
> year IT career attempting to customize and integrate IBM
> software into an environment with thousands of diverse users
> with unique needs. IBM software seldom allowed much
> customization or enhancement in my experience and seemed to
> be designed to prohibit any usage patterns that were outside
> of concepts imagined by the developers.
>
> (It was a philosophy issue - instead of maximizing product
> flexibility as I would do, IBM minimized it. For example I
> supported an IBM mainframe program product called ISPF for
> many years. Several user exits were incorporated in the
> product but the only function allowed by IBM in these exits
> was to log usage. I could not restrict access to functions or
> add functionality to the product or do any customization
> whatsoever via the exits. I know these "narrow vision"
> restrictions were arbitrary and unneeded because an earlier
> predecessor of the product allowed an exit (which was
> inherited by ISPF for compatibility) to slip through which
> gave complete access to product functionality and enhancement
> capabilities! But the later IBM seemed unable to accept that
> a user might have different workflow requirements than they
> had conceived internally. End of rant!)

Have to agree about ISPF -- although I rarely used it.  But it's not really
'an IBM philosophy' ... my LEXX editor (written ten years before NetRexx)
was totally modular and extensible -- every command was a separate module
either written in Rexx or PL/I and users could add and modify any command as
they wished.

Indeed, originally VM/CMS was shipped with source code.  It was a sad day
when it went 'object code only' ... End of rant!

:-)

Mike


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive :
http://ibm-netrexx.215625.n3.nabble.com/





_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

Roger Tobie
In reply to this post by Kermit Kiser
Hello, all

I am a long time reader of your group's emails and at one time a somewhat reluctant user of IBM mainframes. I have never responded to or commented on anything before from this group, but Kermit's "rant" strikes a sensitive spot in my memory. My memory is that the IBM I knew projected an attitude of always knowing best. They acted as if they always knew what the customer wanted and needed even before the customer did. I think this attitude was encapsulated in something they called "account control". And they would, if they could, make the customer totally dependent on Big Blue. And also, I suspect they did really want to maintain control of their software which the customer would inevitably screw up of they were allowed to modify it, no doubt causing them endless support headaches. At the last company where I worked, which with a minor exception was an all IBM shop, I stayed away from the mainframe as much as possible preferring to devote my time to PCs and RS 6000s. In the particular position I was in I could get away with this since all the computerized typesetting functions I was in charge of ran either on PCs, Macs, or an RS 6000. No problem, even though I was once accused of being afraid of the mainframe. You're right. I was. It was running MVS under the control of JCL. ARGH!

So, when REXX was introduced to our shop and I took an in-house course in it my reaction was, "My God! This is really good and it's 'user' friendly. How did IBM ever let this out? And who is this guy, Mike Cowlishaw? What is he? Some sort of maverick or something? He's certainly not cut in the usual IBM mold." My job involved processing streams of text supplied by the mainframe and replacing various imbedded tags with the code to perform typographic functions in two packages, one called Interleaf, the other called FrameMaker. I did this with a program that I had written in COBOL which ran both on the mainframe and on PCs under DOS using something called Realia COBOL. One can do a surprising amount of text processing in COBOL. When I was exposed to REXX I thought it would be an ideal language for processing streams of text. I still think so. But . . . But unfortunately REXX was only available on the mainframe. The one DOS version sort of available at the time was underpowered and inadequate and not from IBM. Also my COBOL program worked, was fast, was essentially bug free, and I could easily modify it if I had to. I had written and rewritten and re-rewritten it years before at another company and brought it with me to my last employer.

I have often had a hankering to convert that COBOL program to REXX and/or Python but so far I haven't. I am now retired from the computer world and playing about on my own learning things like HTML5 and CSS3. But, who knows, REXX might really be a very good candidate for creating a pre-processor for Web pages. I'm still thinking about it.

Cheers to you all especially Mike Cowlishaw,
Roger Tobie

On 10/21/2015 4:21 AM, Kermit Kiser wrote:
Perhaps I was a bit unfair in my characterization of the NetRexx translator. I understand the logic of your reply.

But I am also somewhat biased since I spent much of my 31 year IT career attempting to customize and integrate IBM software into an environment with thousands of diverse users with unique needs. IBM software seldom allowed much customization or enhancement in my experience and seemed to be designed to prohibit any usage patterns that were outside of concepts imagined by the developers.

(It was a philosophy issue - instead of maximizing product flexibility as I would do, IBM minimized it. For example I supported an IBM mainframe program product called ISPF for many years. Several user exits were incorporated in the product but the only function allowed by IBM in these exits was to log usage. I could not restrict access to functions or add functionality to the product or do any customization whatsoever via the exits. I know these "narrow vision" restrictions were arbitrary and unneeded because an earlier predecessor of the product allowed an exit (which was inherited by ISPF for compatibility) to slip through which gave complete access to product functionality and enhancement capabilities! But the later IBM seemed unable to accept that a user might have different workflow requirements than they had conceived internally. End of rant!)

Anyway, whatever the reason, NetRexx is not easy to customize or enhance or integrate with other tools like code analyzers or code completers, etc.

I am sorry if my view offends.
P.S. Your view certainly doesn't offend me.
Roger


-- Kermit

On 2015-10-18 12:02 AM, Mike Cowlishaw wrote:
  Kermit wrote:

NetRexx (the translator) is poorly written. Don't get me
wrong - Mike Cowlishaw is brilliant and an inspired writer of
efficient code! But the NetRexx translator is ivory tower
precision that discards parse tree elements as soon as
possible and uses other efficient optimizations that
completely ignore the needs of real world programmers for an
IDE and other development cycle tools like Eclipse, Netbeans,
Ant, builders, testers etc. that can integrate with it. No
exits or hooks or structures for such development tools
exist.
I think that's a little unfair.  The translator was written (bootstrapped)
in classic Rexx, and it was/is difficult to represent a parse tree in that
language.  That is the main reason for the very 'flat' structure of the
translator.  Further, the translator was intended to be suitable for other
source languages than Rexx (NetRexx) -- we had five in mind (one of which
was SmallTalk) which needed quite different parse trees.  And finally, the
PCs that NetRexx ran on in 1995 were about 400 times slower than today's, so
the emphasis on efficiency was essential.  The translator was barely fast
enough to be useable on anything but the latest machines at the time.

As for exits and hooks for Eclipse, etc., since those didn't exist at that
time it was not possible to foresee what would be required.  Indeed, few
IDEs existed at that time, and very few people used them.

Writing programs today is very different from 20 years ago.  As an example,
my current project, MapGazer, is built in a much simpler way than the old
PMGlobe program; the former rewrites multiple windows or the entire screen
on every mouse-move whereas the latter goes to enormous lengths to only
write areas of the window that have changed.

If writing a language translator today I would structure it very differently
from the NetRexx translator.  Ideally the translator should be rewritten
with the benefit of hindsight, but as you imply, it's probably not worth the
effort.

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

Bill Fenlason
In reply to this post by Kermit Kiser
I've followed this discussion with interest, and agree that in its
current state, the future of NetRexx is not very bright.  (That is why I
essentially stopped work on the Eclipse plugin a long time ago.)  And
also, NetRexx does not "play nice" with other tools using more
traditional approaches.

The root of the problem is that the language is not designed to have a
static definition, but depends on dynamic interpretation.  It is that
way on purpose.  For example, in order to solve the keyword
extensibility problem, all words are defined to be variable names, and
are determined to be keywords dynamically, depending on the prior
usage.  This does not allow the easy specification or generation of an
AST in the traditional manner.

This problem can only be solved by a new language version in which the
dynamic interpretation aspects are removed. I rather doubt that is in
the cards.

Bill

On 10/21/2015 4:21 AM, Kermit Kiser wrote:

> Perhaps I was a bit unfair in my characterization of the NetRexx
> translator. I understand the logic of your reply.
>
> But I am also somewhat biased since I spent much of my 31 year IT
> career attempting to customize and integrate IBM software into an
> environment with thousands of diverse users with unique needs. IBM
> software seldom allowed much customization or enhancement in my
> experience and seemed to be designed to prohibit any usage patterns
> that were outside of concepts imagined by the developers.
>
> (It was a philosophy issue - instead of maximizing product flexibility
> as I would do, IBM minimized it. For example I supported an IBM
> mainframe program product called ISPF for many years. Several user
> exits were incorporated in the product but the only function allowed
> by IBM in these exits was to log usage. I could not restrict access to
> functions or add functionality to the product or do any customization
> whatsoever via the exits. I know these "narrow vision" restrictions
> were arbitrary and unneeded because an earlier predecessor of the
> product allowed an exit (which was inherited by ISPF for
> compatibility) to slip through which gave complete access to product
> functionality and enhancement capabilities! But the later IBM seemed
> unable to accept that a user might have different workflow
> requirements than they had conceived internally. End of rant!)
>
> Anyway, whatever the reason, NetRexx is not easy to customize or
> enhance or integrate with other tools like code analyzers or code
> completers, etc.
>
> I am sorry if my view offends.
>
> -- Kermit
>
> On 2015-10-18 12:02 AM, Mike Cowlishaw wrote:
>>   Kermit wrote:
>>
>>> NetRexx (the translator) is poorly written. Don't get me
>>> wrong - Mike Cowlishaw is brilliant and an inspired writer of
>>> efficient code! But the NetRexx translator is ivory tower
>>> precision that discards parse tree elements as soon as
>>> possible and uses other efficient optimizations that
>>> completely ignore the needs of real world programmers for an
>>> IDE and other development cycle tools like Eclipse, Netbeans,
>>> Ant, builders, testers etc. that can integrate with it. No
>>> exits or hooks or structures for such development tools
>>> exist.
>> I think that's a little unfair.  The translator was written
>> (bootstrapped)
>> in classic Rexx, and it was/is difficult to represent a parse tree in
>> that
>> language.  That is the main reason for the very 'flat' structure of the
>> translator.  Further, the translator was intended to be suitable for
>> other
>> source languages than Rexx (NetRexx) -- we had five in mind (one of
>> which
>> was SmallTalk) which needed quite different parse trees.  And
>> finally, the
>> PCs that NetRexx ran on in 1995 were about 400 times slower than
>> today's, so
>> the emphasis on efficiency was essential.  The translator was barely
>> fast
>> enough to be useable on anything but the latest machines at the time.
>>
>> As for exits and hooks for Eclipse, etc., since those didn't exist at
>> that
>> time it was not possible to foresee what would be required. Indeed, few
>> IDEs existed at that time, and very few people used them.
>>
>> Writing programs today is very different from 20 years ago.  As an
>> example,
>> my current project, MapGazer, is built in a much simpler way than the
>> old
>> PMGlobe program; the former rewrites multiple windows or the entire
>> screen
>> on every mouse-move whereas the latter goes to enormous lengths to only
>> write areas of the window that have changed.
>>
>> If writing a language translator today I would structure it very
>> differently
>> from the NetRexx translator.  Ideally the translator should be rewritten
>> with the benefit of hindsight, but as you imply, it's probably not
>> worth the
>> effort.
>>
>> Mike
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>>
>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6140 / Virus Database: 4450/10859 - Release Date:
> 10/20/15
>
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Reply | Threaded
Open this post in threaded view
|

Re: Upcoming release 4.01 of NetRexx

ThSITC
In reply to this post by ThSITC
--- >>> Also this one, *as a reminder* <<<
Thomas ==> >>>>>> ;-)
============================================================================

Am 21/10/2015 um 13:53 schrieb Thomas Schneider:
I *think* one of the major reasons of the currently missing *success* of NetRexx is that
*IBM* did never actively *market* it.

Whil'st classic Rexx, as well as NetRexx, did have a *lot* of IBM-internal enthusiasts, they
were hidden from the outside world (i.e. IBM Customers) by IBM.

A couple of years ago (around 2005) I did speak with IBM Austria Tech people:
They were not even aware that NetRexx does exist at all.

This has been due to the fact that IBM those times did force EGL  :-(

I think that NetRexx, when invented on a University, could have the strength
as Nikolas Wirth's Pascal did have many years ago in *Teaching Programming*.

May I, anyway, *remind You* that I'm still waiting for answers my previous
msg:

Please do forward any good NetRexx Language Presentations to me
until 7th November the latest for consolidation, as I do have my 1 h speak
at the Technical University of Vienna at the Java Users Group Meetup there,
with some 64 participants - Young Students and Company Founders.


My intention is to *consolidate* what I get

The Topic of my presentation is:

NetRexx -- a human oriented Language for Java Users.

Greetings from Cloudy Vienna.
Thomas Schneider.
======================================================================





Am 21/10/2015 um 11:26 schrieb Martin Packer:
I suspect the real issue - as with MOST software vendors - is the amount of developer time / budget available.

But then I code my own stuff on The "Principle" Of Sufficient Disgust :-) so what do *I* know? :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,

Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: [hidden email]

Twitter / Facebook IDs: MartinPacker
Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:        "Mike Cowlishaw" [hidden email]
To:        "'IBM Netrexx'" [hidden email]
Date:        21/10/2015 10:15
Subject:        Re: [Ibm-netrexx] Upcoming release 4.01 of NetRexx
Sent by:        [hidden email]




 
> Perhaps I was a bit unfair in my characterization of the
> NetRexx translator. I understand the logic of your reply.
>
> But I am also somewhat biased since I spent much of my 31
> year IT career attempting to customize and integrate IBM
> software into an environment with thousands of diverse users
> with unique needs. IBM software seldom allowed much
> customization or enhancement in my experience and seemed to
> be designed to prohibit any usage patterns that were outside
> of concepts imagined by the developers.
>
> (It was a philosophy issue - instead of maximizing product
> flexibility as I would do, IBM minimized it. For example I
> supported an IBM mainframe program product called ISPF for
> many years. Several user exits were incorporated in the
> product but the only function allowed by IBM in these exits
> was to log usage. I could not restrict access to functions or
> add functionality to the product or do any customization
> whatsoever via the exits. I know these "narrow vision"
> restrictions were arbitrary and unneeded because an earlier
> predecessor of the product allowed an exit (which was
> inherited by ISPF for compatibility) to slip through which
> gave complete access to product functionality and enhancement
> capabilities! But the later IBM seemed unable to accept that
> a user might have different workflow requirements than they
> had conceived internally. End of rant!)

Have to agree about ISPF -- although I rarely used it.  But it's not really
'an IBM philosophy' ... my LEXX editor (written ten years before NetRexx)
was totally modular and extensible -- every command was a separate module
either written in Rexx or PL/I and users could add and modify any command as
they wished.

Indeed, originally VM/CMS was shipped with source code.  It was a sad day
when it went 'object code only' ... End of rant!

:-)

Mike


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive :
http://ibm-netrexx.215625.n3.nabble.com/





_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/




_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/