This comment is from The NetRexx Language Reference:
> The NetRexx language, as you will have seen, allows the writing of > programs for the > Java environment with a minimum of overhead and “boilerplate syntax”; > using NetRexx > for writing Java classes could increase your productivity by 30% or more. The following comment is from the IBM AWD web page for NetRexx (http://www-01.ibm.com/software/awdtools/netrexx/about.html): The speed and simplicity of developing in NetRexx is backed by benchmarks showing that the Java source for a typical class has about 35% more lexical tokens and requires about 20% more keystrokes than it would in NetRexx. A new research study using Java code has reported that most of Java code is "fluff": http://www.itworld.com/article/2881655/your-code-is-far-more-chaff-than-wheat.html (I found the link on Slashdot: http://developers.slashdot.org/story/15/02/11/1744246/your-java-code-is-mostly-fluff-new-research-finds) My question if not obvious is: Given that NetRexx is designed to be human readable more than computer readable in contrast to languages like Java, where does it stand on the fluff-meter? -- Kermit _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
While the study is presented as science I could not really grasp from the text what that team actually did. They might have zipped the code and counted what is left - there is no way to find out from the article.
I feel that NetRexx is somewhere between Prolog and COBOL verbosity-wise, but then again most languages are. We can just count the savings with respect to the generated Java, and they are impressive; the language also scores much higher on the subjective readability scale. From another perspective, you might establish the norm for chaff from what IDE’s support in adding to your code. In this light, the bean access methods of Java are all chaff and ‘properties indirect’ is certainly the way to go. Compared to Ruby and Python there is not much difference, except for the fact that I still come back to NetRexx for everything that I write because of speed, integration with the java class libraries, and sheer pleasure in development. best regards, René Jansen. > On 13 feb. 2015, at 07:06, Kermit Kiser <[hidden email]> wrote: > > This comment is from The NetRexx Language Reference: > >> The NetRexx language, as you will have seen, allows the writing of programs for the >> Java environment with a minimum of overhead and “boilerplate syntax”; using NetRexx >> for writing Java classes could increase your productivity by 30% or more. > > The following comment is from the IBM AWD web page for NetRexx (http://www-01.ibm.com/software/awdtools/netrexx/about.html): > > The speed and simplicity of developing in NetRexx is backed by benchmarks showing that the Java source for a typical class has about 35% more lexical tokens and requires about 20% more keystrokes than it would in NetRexx. > > A new research study using Java code has reported that most of Java code is "fluff": > > http://www.itworld.com/article/2881655/your-code-is-far-more-chaff-than-wheat.html > > (I found the link on Slashdot: http://developers.slashdot.org/story/15/02/11/1744246/your-java-code-is-mostly-fluff-new-research-finds) > > My question if not obvious is: Given that NetRexx is designed to be human readable more than computer readable in contrast to languages like Java, where does it stand on the fluff-meter? > > -- Kermit > > _______________________________________________ > 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/ |
In reply to this post by Kermit Kiser
The IT World link is bad, but the PDF link in the slashdot article is OK.
http://arxiv.org/pdf/1502.01410v1.pdf After a quick glance at the article, I one might assume that Rexx family languages might score a bit of fluff because of the use of DO ... END and THEN rather than { } and if ( ) ? Apparently they more or less assumed that "words" are fluff and that "delimiters" are required? I saw no evidence that they even recognized { and } as keywords(as I think they should be). As you pointed out, the tradeoff is between key strokes and readability. Original email: ----------------- From: René Jansen [hidden email] Date: Fri, 13 Feb 2015 12:12:42 +0100 To: [hidden email] Subject: Re: [Ibm-netrexx] NetRexx vs Java fluff While the study is presented as science I could not really grasp from the text what that team actually did. They might have zipped the code and counted what is left - there is no way to find out from the article. I feel that NetRexx is somewhere between Prolog and COBOL verbosity-wise, but then again most languages are. We can just count the savings with respect to the generated Java, and they are impressive; the language also scores much higher on the subjective readability scale. From another perspective, you might establish the norm for chaff from what IDEâs support in adding to your code. In this light, the bean access methods of Java are all chaff and âproperties indirectâ is certainly the way to go. Compared to Ruby and Python there is not much difference, except for the fact that I still come back to NetRexx for everything that I write because of speed, integration with the java class libraries, and sheer pleasure in development. best regards, René Jansen. > On 13 feb. 2015, at 07:06, Kermit Kiser <[hidden email]> wrote: > > This comment is from The NetRexx Language Reference: > >> The NetRexx language, as you will have seen, allows the writing of programs for the >> Java environment with a minimum of overhead and âboilerplate syntaxâ; using NetRexx >> for writing Java classes could increase your productivity by 30% or more. > > The following comment is from the IBM AWD web page for NetRexx (http://www-01.ibm.com/software/awdtools/netrexx/about.html): > > The speed and simplicity of developing in NetRexx is backed by benchmarks showing that the Java source for a typical class has about 35% more lexical tokens and requires about 20% more keystrokes than it would in NetRexx. > > A new research study using Java code has reported that most of Java code is "fluff": > > http://www.itworld.com/article/2881655/your-code-is-far-more-chaff-than-whea t.html > > (I found the link on Slashdot: http://developers.slashdot.org/story/15/02/11/1744246/your-java-code-is-most ly-fluff-new-research-finds) > > My question if not obvious is: Given that NetRexx is designed to be human readable more than computer readable in contrast to languages like Java, where does it stand on the fluff-meter? > > -- Kermit > > _______________________________________________ > 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/ -------------------------------------------------------------------- mail2web LIVE Free email based on Microsoft Exchange technology - http://link.mail2web.com/LIVE _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
A huge source of Java 'fluff' is declaring each and every property with all of its modifiers as contrasted with NetRexx's grouping approach. Another sad result of adherence to C syntax forced, it is said, by a marketing decision to ape C/C++ so as not to terrify potential converts to Java. Just as in the case of Java vs C/C++, the later language gets to correct deficiencies in its predecessor. Also, if you look at string processing-intensive Java code, NetRexx's novel concatenation operators eliminate a lot of clutter. On Fri, Feb 13, 2015 at 8:32 AM, [hidden email] <[hidden email]> wrote: The IT World link is bad, but the PDF link in the slashdot article is OK. -- "I don’t believe in the afterlife, although I am bringing a change of underwear." - W. Allen
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
I fully agree, George, but it's not that braces are banned, it's that
they are ill-suited for the task to which they are employed in C-based languages. The benefit of paired grouping glyphs is when they both are readily visible. Quotes around literals, parens around expressions, etc. rarely span much more than one line. It's far easier to find the open and close points in that case viz. an open brace on line 12 and it's matching close brace on line 42 (with many intervening braces). To my knowledge, none of the languages that use braces for that sort of long-span grouping have any capability to label the group, as Rexx and NetRexx do. In this case, I would argue that such labels are not "verbosity" as much as a valuable code-validity mechanism. As for automatic bracket matching, I wrote a simple XEDIT macro back in the 80's to do exactly that for Rexx to expose the structure of my code. Code readability and code delimiter matching are not mutually exclusive. -Chip- On 2/13/2015 10:13 AM, George Hovey wrote: > A huge source of Java 'fluff' is declaring each and every property > with all of its modifiers as contrasted with NetRexx's grouping > approach. Another sad result of adherence to C syntax forced, it is > said, by a marketing decision to ape C/C++ so as not to terrify > potential converts to Java. Just as in the case of Java vs C/C++, > the later language gets to correct deficiencies in its predecessor. > > Also, if you look at string processing-intensive Java code, NetRexx's > novel concatenation operators eliminate a lot of clutter. > > @Bill > Do/End gains readability at the expense of automatic bracket matching > in editors. You can, of course, supply them with labels at the > expense of more verbosity. > > We've been over { and } before and I discovered to my amazement that > they generate fury among IBMers, so I guess they're banned. > > > > > On Fri, Feb 13, 2015 at 8:32 AM, [hidden email] > <mailto:[hidden email]> <[hidden email] > <mailto:[hidden email]>> wrote: > > The IT World link is bad, but the PDF link in the slashdot article > is OK. > > http://arxiv.org/pdf/1502.01410v1.pdf > > After a quick glance at the article, I one might assume that Rexx > family > languages might score a bit of fluff because of the use of DO ... > END and > THEN rather than { } and if ( ) ? Apparently they more or less > assumed > that "words" are fluff and that "delimiters" are required? I saw no > evidence that they even recognized { and } as keywords(as I think they > should be). > > As you pointed out, the tradeoff is between key strokes and > readability. > > > > > Original email: > ----------------- > From: René Jansen [hidden email] <mailto:[hidden email]> > Date: Fri, 13 Feb 2015 12:12:42 +0100 > To: [hidden email] <mailto:[hidden email]> > Subject: Re: [Ibm-netrexx] NetRexx vs Java fluff > > > While the study is presented as science I could not really grasp > from the > text what that team actually did. They might have zipped the code and > counted what is left - there is no way to find out from the article. > > I feel that NetRexx is somewhere between Prolog and COBOL > verbosity-wise, > but then again most languages are. We can just count the savings with > respect to the generated Java, and they are impressive; the > language also > scores much higher on the subjective readability scale. > > >From another perspective, you might establish the norm for chaff from what > IDE’s support in adding to your code. In this light, the bean access > methods of Java are all chaff and ‘properties indirect’ is > certainly > the way to go. > > Compared to Ruby and Python there is not much difference, except > for the > fact that I still come back to NetRexx for everything that I write > because > of speed, integration with the java class libraries, and sheer > pleasure in > development. > > best regards, > > René Jansen. > > > > On 13 feb. 2015, at 07:06, Kermit Kiser <[hidden email] <mailto:[hidden email]>> wrote: > > > > This comment is from The NetRexx Language Reference: > > > >> The NetRexx language, as you will have seen, allows the writing of > programs for the > >> Java environment with a minimum of overhead and “boilerplate > syntax†; using NetRexx > >> for writing Java classes could increase your productivity by > 30% or more. > > > > The following comment is from the IBM AWD web page for NetRexx > (http://www-01.ibm.com/software/awdtools/netrexx/about.html): > > > > The speed and simplicity of developing in NetRexx is backed by > benchmarks > showing that the Java source for a typical class has about 35% > more lexical > tokens and requires about 20% more keystrokes than it would in > NetRexx. > > > > A new research study using Java code has reported that most of > Java code > is "fluff": > > > > > http://www.itworld.com/article/2881655/your-code-is-far-more-chaff-than-whea > t.html > <http://www.itworld.com/article/2881655/your-code-is-far-more-chaff-than-whea > t.html> > > > > (I found the link on Slashdot: > http://developers.slashdot.org/story/15/02/11/1744246/your-java-code-is-most > ly-fluff-new-research-finds > <http://developers.slashdot.org/story/15/02/11/1744246/your-java-code-is-most > ly-fluff-new-research-finds>) > > > > My question if not obvious is: Given that NetRexx is designed > to be human > readable more than computer readable in contrast to languages like > Java, > where does it stand on the fluff-meter? > > > > -- Kermit > > > > _______________________________________________ > > Ibm-netrexx mailing list > > [hidden email] <mailto:[hidden email]> > > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] <mailto:[hidden email]> > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > > -------------------------------------------------------------------- > mail2web LIVE Free email based on Microsoft Exchange technology - > http://link.mail2web.com/LIVE > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] <mailto:[hidden email]> > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > > > -- > "I don’t believe in the afterlife, although I am bringing a change of > underwear." - W. Allen > > > _______________________________________________ > 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/ |
Also worth mentioning is that when James Gosling was asked "what he'd most like to change in Java" (WWW5 conference, I think), his answer was: "the curly braces".
Mike > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Chip Davis > Sent: 13 February 2015 16:28 > To: IBM Netrexx > Subject: Re: [Ibm-netrexx] NetRexx vs Java fluff > > I fully agree, George, but it's not that braces are banned, > it's that they are ill-suited for the task to which they are > employed in C-based languages. > > The benefit of paired grouping glyphs is when they both are > readily visible. Quotes around literals, parens around > expressions, etc. > rarely span much more than one line. It's far easier to find > the open and close points in that case viz. an open brace on > line 12 and it's matching close brace on line 42 (with many > intervening braces). > > To my knowledge, none of the languages that use braces for > that sort of long-span grouping have any capability to label > the group, as Rexx and NetRexx do. In this case, I would > argue that such labels are not "verbosity" as much as a > valuable code-validity mechanism. > > As for automatic bracket matching, I wrote a simple XEDIT > macro back in the 80's to do exactly that for Rexx to expose > the structure of my code. Code readability and code > delimiter matching are not mutually exclusive. > > -Chip- > > On 2/13/2015 10:13 AM, George Hovey wrote: > > A huge source of Java 'fluff' is declaring each and every property > > with all of its modifiers as contrasted with NetRexx's grouping > > approach. Another sad result of adherence to C syntax > forced, it is > > said, by a marketing decision to ape C/C++ so as not to terrify > > potential converts to Java. Just as in the case of Java vs C/C++, > > the later language gets to correct deficiencies in its predecessor. > > > > Also, if you look at string processing-intensive Java code, > NetRexx's > > novel concatenation operators eliminate a lot of clutter. > > > > @Bill > > Do/End gains readability at the expense of automatic > bracket matching > > in editors. You can, of course, supply them with labels at the > > expense of more verbosity. > > > > We've been over { and } before and I discovered to my > amazement that > > they generate fury among IBMers, so I guess they're banned. > > > > > > > > > > On Fri, Feb 13, 2015 at 8:32 AM, [hidden email] > > <mailto:[hidden email]> <[hidden email] > > <mailto:[hidden email]>> wrote: > > > > The IT World link is bad, but the PDF link in the > slashdot article > > is OK. > > > > http://arxiv.org/pdf/1502.01410v1.pdf > > > > After a quick glance at the article, I one might assume > that Rexx > > family > > languages might score a bit of fluff because of the use > of DO ... > > END and > > THEN rather than { } and if ( ) ? Apparently they more or less > > assumed > > that "words" are fluff and that "delimiters" are > required? I saw no > > evidence that they even recognized { and } as > keywords(as I think they > > should be). > > > > As you pointed out, the tradeoff is between key strokes and > > readability. > > > > > > > > > > Original email: > > ----------------- > > From: René Jansen [hidden email] > <mailto:[hidden email]> > > Date: Fri, 13 Feb 2015 12:12:42 +0100 > > To: [hidden email] > <mailto:[hidden email]> > > Subject: Re: [Ibm-netrexx] NetRexx vs Java fluff > > > > > > While the study is presented as science I could not really grasp > > from the > > text what that team actually did. They might have > zipped the code and > > counted what is left - there is no way to find out from > the article. > > > > I feel that NetRexx is somewhere between Prolog and COBOL > > verbosity-wise, > > but then again most languages are. We can just count > the savings with > > respect to the generated Java, and they are impressive; the > > language also > > scores much higher on the subjective readability scale. > > > > >From another perspective, you might establish the norm > for chaff from what > > IDE’s support in adding to your code. In this light, > the bean access > > methods of Java are all chaff and ‘properties indirect’ is > > certainly > > the way to go. > > > > Compared to Ruby and Python there is not much difference, except > > for the > > fact that I still come back to NetRexx for everything > that I write > > because > > of speed, integration with the java class libraries, and sheer > > pleasure in > > development. > > > > best regards, > > > > René Jansen. > > > > > > > On 13 feb. 2015, at 07:06, Kermit Kiser > <[hidden email] <mailto:[hidden email]>> wrote: > > > > > > This comment is from The NetRexx Language Reference: > > > > > >> The NetRexx language, as you will have seen, allows > the writing of > > programs for the > > >> Java environment with a minimum of overhead and > “boilerplate > > syntax†; using NetRexx > > >> for writing Java classes could increase your productivity by > > 30% or more. > > > > > > The following comment is from the IBM AWD web page > for NetRexx > > (http://www-01.ibm.com/software/awdtools/netrexx/about.html): > > > > > > The speed and simplicity of developing in NetRexx is > backed by > > benchmarks > > showing that the Java source for a typical class has about 35% > > more lexical > > tokens and requires about 20% more keystrokes than it would in > > NetRexx. > > > > > > A new research study using Java code has reported > that most of > > Java code > > is "fluff": > > > > > > > > > http://www.itworld.com/article/2881655/your-code-is-far-more-c > > t.html > > > <http://www.itworld.com/article/2881655/your-code-is-far-more- > chaff-than-whea > > t.html> > > > > > > (I found the link on Slashdot: > > > http://developers.slashdot.org/story/15/02/11/1744246/your-jav a-code-is-most > > ly-fluff-new-research-finds > > > <http://developers.slashdot.org/story/15/02/11/1744246/your-ja va-code-is-most > > ly-fluff-new-research-finds>) > > > > > > My question if not obvious is: Given that NetRexx is designed > > to be human > > readable more than computer readable in contrast to > languages like > > Java, > > where does it stand on the fluff-meter? > > > > > > -- Kermit > > > > > > _______________________________________________ > > > Ibm-netrexx mailing list > > > [hidden email] > <mailto:[hidden email]> > > > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > > > > > _______________________________________________ > > Ibm-netrexx mailing list > > [hidden email] <mailto:[hidden email]> > > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > > > > > > > -------------------------------------------------------------------- > > mail2web LIVE Free email based on Microsoft Exchange > technology - > > http://link.mail2web.com/LIVE > > > > > > _______________________________________________ > > Ibm-netrexx mailing list > > [hidden email] <mailto:[hidden email]> > > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > > > > > > > > -- > > "I don’t believe in the afterlife, although I am bringing a > change of > > underwear." - W. Allen > > > > > > _______________________________________________ > > 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/ |
In reply to this post by Kermit Kiser
Mike,
Did Gosling happen to mention what he would have replaced the curley braces with? Keywords, or indentation (tabs)? Hopefully he wasn't thinking of parens as in lisp. I've sometimes thought a simple token replacement statement would be a useful addition to Rexx and NetRexx. It would be limited to simple replacement and without arguments as a macro language would have. For example: TOKEN "{" MEANS "do;"; TOKEN "}" MEANS "end;" would allow the use of curley brackets (for those who might want them) and so on. It would also allow the addition of the AND, OR and NOT keywords in logical expressions as in "if a = 2 or b = 3 then ...;" which I think is somewhat more readable the using "|" etc. token "AND" means "&"; token "OR" means "|"; token "NOT" means "\"; Bill Original email: ----------------- From: Mike Cowlishaw [hidden email] Date: Fri, 13 Feb 2015 20:07:17 -0000 To: [hidden email] Subject: Re: [Ibm-netrexx] NetRexx vs Java fluff Also worth mentioning is that when James Gosling was asked "what he'd most like to change in Java" (WWW5 conference, I think), his answer was: "the curly braces". Mike > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Chip Davis > Sent: 13 February 2015 16:28 > To: IBM Netrexx > Subject: Re: [Ibm-netrexx] NetRexx vs Java fluff > > I fully agree, George, but it's not that braces are banned, > it's that they are ill-suited for the task to which they are > employed in C-based languages. > > The benefit of paired grouping glyphs is when they both are > readily visible. Quotes around literals, parens around > expressions, etc. > rarely span much more than one line. It's far easier to find > the open and close points in that case viz. an open brace on > line 12 and it's matching close brace on line 42 (with many > intervening braces). > > To my knowledge, none of the languages that use braces for > that sort of long-span grouping have any capability to label > the group, as Rexx and NetRexx do. In this case, I would > argue that such labels are not "verbosity" as much as a > valuable code-validity mechanism. > > As for automatic bracket matching, I wrote a simple XEDIT > macro back in the 80's to do exactly that for Rexx to expose > the structure of my code. Code readability and code > delimiter matching are not mutually exclusive. > > -Chip- > > On 2/13/2015 10:13 AM, George Hovey wrote: > > A huge source of Java 'fluff' is declaring each and every property > > with all of its modifiers as contrasted with NetRexx's grouping > > approach. Another sad result of adherence to C syntax > forced, it is > > said, by a marketing decision to ape C/C++ so as not to terrify > > potential converts to Java. Just as in the case of Java vs C/C++, > > the later language gets to correct deficiencies in its predecessor. > > > > Also, if you look at string processing-intensive Java code, > NetRexx's > > novel concatenation operators eliminate a lot of clutter. > > > > @Bill > > Do/End gains readability at the expense of automatic > bracket matching > > in editors. You can, of course, supply them with labels at the > > expense of more verbosity. > > > > We've been over { and } before and I discovered to my > amazement that > > they generate fury among IBMers, so I guess they're banned. > > > > > > > > > > On Fri, Feb 13, 2015 at 8:32 AM, [hidden email] > > <mailto:[hidden email]> <[hidden email] > > <mailto:[hidden email]>> wrote: > > > > The IT World link is bad, but the PDF link in the > slashdot article > > is OK. > > > > http://arxiv.org/pdf/1502.01410v1.pdf > > > > After a quick glance at the article, I one might assume > that Rexx > > family > > languages might score a bit of fluff because of the use > of DO ... > > END and > > THEN rather than { } and if ( ) ? Apparently they more or less > > assumed > > that "words" are fluff and that "delimiters" are > required? I saw no > > evidence that they even recognized { and } as > keywords(as I think they > > should be). > > > > As you pointed out, the tradeoff is between key strokes and > > readability. > > > > > > > > > > Original email: > > ----------------- > > From: René Jansen [hidden email] > <mailto:[hidden email]> > > Date: Fri, 13 Feb 2015 12:12:42 +0100 > > To: [hidden email] > <mailto:[hidden email]> > > Subject: Re: [Ibm-netrexx] NetRexx vs Java fluff > > > > > > While the study is presented as science I could not really grasp > > from the > > text what that team actually did. They might have > zipped the code and > > counted what is left - there is no way to find out from > the article. > > > > I feel that NetRexx is somewhere between Prolog and COBOL > > verbosity-wise, > > but then again most languages are. We can just count > the savings with > > respect to the generated Java, and they are impressive; the > > language also > > scores much higher on the subjective readability scale. > > > > >From another perspective, you might establish the norm > for chaff from what > > IDEââ¬â¢s support in adding to your code. In this light, > the bean access > > methods of Java are all chaff and ââ¬Ëproperties > > certainly > > the way to go. > > > > Compared to Ruby and Python there is not much difference, except > > for the > > fact that I still come back to NetRexx for everything > that I write > > because > > of speed, integration with the java class libraries, and sheer > > pleasure in > > development. > > > > best regards, > > > > René Jansen. > > > > > > > On 13 feb. 2015, at 07:06, Kermit Kiser > <[hidden email] <mailto:[hidden email]>> wrote: > > > > > > This comment is from The NetRexx Language Reference: > > > > > >> The NetRexx language, as you will have seen, allows > the writing of > > programs for the > > >> Java environment with a minimum of overhead and > ââ¬Åboilerplate > > syntaxâ⬠; using NetRexx > > >> for writing Java classes could increase your productivity by > > 30% or more. > > > > > > The following comment is from the IBM AWD web page > for NetRexx > > (http://www-01.ibm.com/software/awdtools/netrexx/about.html): > > > > > > The speed and simplicity of developing in NetRexx is > backed by > > benchmarks > > showing that the Java source for a typical class has about 35% > > more lexical > > tokens and requires about 20% more keystrokes than it would in > > NetRexx. > > > > > > A new research study using Java code has reported > that most of > > Java code > > is "fluff": > > > > > > > > > http://www.itworld.com/article/2881655/your-code-is-far-more-c > > t.html > > > <http://www.itworld.com/article/2881655/your-code-is-far-more- > chaff-than-whea > > t.html> > > > > > > (I found the link on Slashdot: > > > http://developers.slashdot.org/story/15/02/11/1744246/your-jav a-code-is-most > > ly-fluff-new-research-finds > > > <http://developers.slashdot.org/story/15/02/11/1744246/your-ja va-code-is-most > > ly-fluff-new-research-finds>) > > > > > > My question if not obvious is: Given that NetRexx is designed > > to be human > > readable more than computer readable in contrast to > languages like > > Java, > > where does it stand on the fluff-meter? > > > > > > -- Kermit > > > > > > _______________________________________________ > > > Ibm-netrexx mailing list > > > [hidden email] > <mailto:[hidden email]> > > > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > > > > > _______________________________________________ > > Ibm-netrexx mailing list > > [hidden email] <mailto:[hidden email]> > > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > > > > > > > -------------------------------------------------------------------- > > mail2web LIVE Free email based on Microsoft Exchange > technology - > > http://link.mail2web.com/LIVE > > > > > > _______________________________________________ > > Ibm-netrexx mailing list > > [hidden email] <mailto:[hidden email]> > > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > > > > > > > > -- > > "I donât believe in the afterlife, although I am bringing a > change of > > underwear." - W. Allen > > > > > > _______________________________________________ > > 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/ -------------------------------------------------------------------- myhosting.com - Premium Microsoft Windows and Linux web and application hosting - http://link.myhosting.com/myhosting _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
> Did Gosling happen to mention what he would have replaced the > curly braces with? Keywords, or indentation (tabs)? > Hopefully he wasn't thinking of parens as in lisp. I'd just given a talk on NetRexx and we were doing a joint Q&A session, so I assumed he was thinking of keywords (not necessarily DO and END). One of the features of NetRexx that seemed to go down well was the labels on END. > I've sometimes thought a simple token replacement statement > would be a useful addition to Rexx and NetRexx. It would be > limited to simple replacement and without arguments as a > macro language would have. For > example: > > TOKEN "{" MEANS "do;"; TOKEN "}" MEANS "end;" > > would allow the use of curly brackets (for those who might > want them) and so on. > > It would also allow the addition of the AND, OR and NOT > keywords in logical expressions as in "if a = 2 or b = 3 then > ...;" which I think is somewhat more readable the using "|" etc. > > token "AND" means "&"; token "OR" means "|"; token "NOT" > means "\"; Just about every macro language seems to have started that way, then 'expanded' bit by bit -- and it shows. Much better to design a macro language 'fully fledged' from the start. Indeed, NetRexx/Rexx can be their own macro language as they are so good at string manipulation. Rexx was strongly influenced by the PL/I macro language; you might want to take a look at that. As an example of what it can do, see the snippet below .. the macros (conkurr) added concurrency to PL/I but hid all the mechanics. Mike /* Dining Philosophers problem. Test Conkurr */ test: proc options(main) reorder; %include(conkurr); dcl i,j,k; dcl (mod,addr) builtin; dcl action char(5); dcl occupancy fixed bin init(0); dopar; process(phil,5); do forever; /* think */ pause(ckey*1000); give ('ENTER') to(room); take ('PICKUP') from(fork) sub(ckey); take ('PICKUP') from(fork) sub(mod(ckey,5)+1); /* eat */ pause(ckey*100); give ('PUT') to(fork) sub(mod(ckey,5)+1); give ('PUT') to(fork) sub(ckey); give ('EXIT') to(room); end; process(fork,5); do forever; give ('PICKUP'); take ('PUT'); end; process(room); do forever; take (action); if action='ENTER' then occupancy=occupancy+1; else occupancy=occupancy-1; end; endpar; display('!Finished'); end /* main */; _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Free forum by Nabble | Edit this page |