ibm-netrexx

Proposed NetRexx Language improvements

Classic

List

Threaded

40 messages Options

George Hovey-2

Re: Proposed NetRexx Language improvements

Kermit,
I only ever wrote one COBOL program and I try not to think about it :-)!

I just took a look at Nick Gravgaard's "Elastic Tabstops" page -- interesting concept, especially the possibility of using proportional fonts which potentially have greater legibility than monospaced fonts. For a sobering critique of this idea see https://wincent.com/blog/tabs-vs-spaces-or-spaces-vs-tabs-and-elastic-tabstops. Elastic tabstops don't appear to interfere with our usual concept of indenting code (ie, as far as leading space on a line). BTW, do you mean that you don't indent NetRexx code?
George

On Fri, Aug 27, 2010 at 5:25 PM, Kermit Kiser <[hidden email]> wrote:

Actually the jEdit developers are at this moment in the process of implementing something called "elastic tabstops" which appears to be far superior to tabs and spaces as it can automatically align things even if the programmer does not use the correct tabs or spaces. However I would be worried about making NetRexx require indentation (thinking of Cobol, etc. ugh!) as it could conflict with slick new tools like elastic tabstops.

http://en.wikipedia.org/wiki/Elastic_tabstop

-- Kermit

On 8/27/2010 1:12 PM, George Hovey wrote:
Mike,
My two cents on tabs.

Tabs are a holdover from the days when we entered programs on 110 baud Teletypes and would have considered using strings of spaces an obscene waste of computer resources. They are huge trouble makers for the reasons you have described and (IMHO) should have been discontinued ages ago.

jEdit handles this quite nicely by defining "soft" tabs which cause the TAB key to emit spaces in numbers equivalent to traditional hard tabs. Of course, other editors may not support this idea, or the programmer may destroy consistent tabbing through incautious editing. So the burden of checking indentation should be on the compiler.

One approach is to specify an equivalent tab size with an option (default value 8 for 'nix users?); leading strings of spaces not containing an integer multiple of this value could be flagged by the compiler as an aid to programmers. It could also make other checks, such as verifying that increasing levels of indentation differ by exactly one tab equivalent. It might even, as a convenience, optionally fix programs containing hard tabs and re-tab programs to a different value on demand for use with different editors.

Wouldn't this approach make the concept of indentation indicating conditionality safe and convenient? It seems to me that Connor's idea of regarding a program as a visual artifact plays to one of the mind's great strengths. And the value of consistent indentation has been understood heuristically for decades (I started with FORTRAN IV); what is gained by not making it a requirement of NetRexx?
George

On Fri, Aug 27, 2010 at 11:37 AM, Mike Cowlishaw <[hidden email]> wrote:

This problem is not due to using indentation to indicate nesting, it is due to inconsistent indentation. There is no advantage to be gained from inconsistent nesting, so best to prevent it. This problem is solved by using any editor which uses one tab for each indentation level, and automatically replacing any spaces that the programmer may use for the same purpose (I guess that most editors should be capable of supporting this. The quantity of horizontal space that the tab represents can be adjusted to fit programmer preference...

Tabs are a no-go for those of us who do use more than one editor, because it seems quite arbitrary how many spaces each tab represents (I have seen 2, 4, 5, and 8 all commonly used). If tabs are not mixed with spaces it sort of works .. but line comments over the the right all end up misaligned when one changes from editor to editor. When tabs and spaces for indentation are mixed, or sometimes spaces are used and then on other lines tabs are used, then one just ends up with a mess for the initial indention, too.

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

  
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

George Hovey-2

Re: Proposed NetRexx Language improvements

On Fri, Aug 27, 2010 at 8:48 PM, George Hovey <[hidden email]> wrote:

Kermit,
I only ever wrote one COBOL program and I try not to think about it :-)!

I just took a look at Nick Gravgaard's "Elastic Tabstops" page -- interesting concept, especially the possibility of using proportional fonts which potentially have greater legibility than monospaced fonts. For a sobering critique of this idea see https://wincent.com/blog/tabs-vs-spaces-or-spaces-vs-tabs-and-elastic-tabstops. Elastic tabstops don't appear to interfere with our usual concept of indenting code (ie, as far as leading space on a line). BTW, do you mean that you don't indent NetRexx code?
George
On Fri, Aug 27, 2010 at 5:25 PM, Kermit Kiser <[hidden email]> wrote:
Actually the jEdit developers are at this moment in the process of implementing something called "elastic tabstops" which appears to be far superior to tabs and spaces as it can automatically align things even if the programmer does not use the correct tabs or spaces. However I would be worried about making NetRexx require indentation (thinking of Cobol, etc. ugh!) as it could conflict with slick new tools like elastic tabstops.

http://en.wikipedia.org/wiki/Elastic_tabstop

-- Kermit

On 8/27/2010 1:12 PM, George Hovey wrote:
Mike,
My two cents on tabs.

Tabs are a holdover from the days when we entered programs on 110 baud Teletypes and would have considered using strings of spaces an obscene waste of computer resources. They are huge trouble makers for the reasons you have described and (IMHO) should have been discontinued ages ago.

jEdit handles this quite nicely by defining "soft" tabs which cause the TAB key to emit spaces in numbers equivalent to traditional hard tabs. Of course, other editors may not support this idea, or the programmer may destroy consistent tabbing through incautious editing. So the burden of checking indentation should be on the compiler.

One approach is to specify an equivalent tab size with an option (default value 8 for 'nix users?); leading strings of spaces not containing an integer multiple of this value could be flagged by the compiler as an aid to programmers. It could also make other checks, such as verifying that increasing levels of indentation differ by exactly one tab equivalent. It might even, as a convenience, optionally fix programs containing hard tabs and re-tab programs to a different value on demand for use with different editors.

Wouldn't this approach make the concept of indentation indicating conditionality safe and convenient? It seems to me that Connor's idea of regarding a program as a visual artifact plays to one of the mind's great strengths. And the value of consistent indentation has been understood heuristically for decades (I started with FORTRAN IV); what is gained by not making it a requirement of NetRexx?
George

On Fri, Aug 27, 2010 at 11:37 AM, Mike Cowlishaw <[hidden email]> wrote:

This problem is not due to using indentation to indicate nesting, it is due to inconsistent indentation. There is no advantage to be gained from inconsistent nesting, so best to prevent it. This problem is solved by using any editor which uses one tab for each indentation level, and automatically replacing any spaces that the programmer may use for the same purpose (I guess that most editors should be capable of supporting this. The quantity of horizontal space that the tab represents can be adjusted to fit programmer preference...

Tabs are a no-go for those of us who do use more than one editor, because it seems quite arbitrary how many spaces each tab represents (I have seen 2, 4, 5, and 8 all commonly used). If tabs are not mixed with spaces it sort of works .. but line comments over the the right all end up misaligned when one changes from editor to editor. When tabs and spaces for indentation are mixed, or sometimes spaces are used and then on other lines tabs are used, then one just ends up with a mess for the initial indention, too.

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

  
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

FreeFall

Re: Proposed NetRexx Language improvements

In reply to this post by Thomas.Schneider.Wien

George et all,

Netrexx3 <- Tabetha2 seems to me a non starter, for the simple reason that you have not an iota of field experience with Tabetha.

On that basis, all programming languages were once non-starters. They all have to start somewhere, even in unlikely places, or places where the author was not thanked for his troubles (eg Rexx). However, I don't hold out much hope for Tabetha; people prefer VHS over Betamax, so what is the point in producing another Betamax?

Experience shows that languages always have unintended consequences. For example, Java was designed by a team of conspicuously smart people and ideas extensively bounced around. Still, Java's OO model turned out to have consequences that its designers didn't like one bit (see Joshua Bloch, "Effective Java" for various examples).

Sure. That's why they evolve. Starting with a small user group, who write real programs, is best as it allows things to be ironed out before the language gets set in stone.

MFC has always been extremely suspicious of "innovations" in NetRexx, and I think his suspicions well founded. Novelties should only be introduced cautiously. The last thing NetRexx needs IMHO is to fall victim to "feature-itis". In fact, I could be happy with it as it is, except for fears about future Java compatibility those in the know say are unfounded.

I agree that it is easy to find nice novelties and too easily bolt them onto a language. However, part of the philosophy of Tabetha is to minimise the instruction set (there are far fewer instructions than there are even in Rexx, but I would argue that the language is more powerful and has a more intuitive syntax). Exactly the things that Rexx programmers value.

But that doesn't mean there are no new ideas worthy of inclusion in NetRexx, and I hope you will continue to expound on features of Tabetha and their virtues. What I've heard so far seems well worth pondering. Does Tabetha have a "white paper"?

No. Work on Tabetha started in the early eighties (1980 or 81), including my nesting by indentation, with my final year project delivered in 1985 (if we are lucky, the university will still have a copy in the library, I have misplaced mine). Since then I've developed it bit by bit when the enthusiasm got the better of me; one day I'll complete the Language Guide! This could be in my 'retirement', but if conventional language features continue to advance at their current pace, Tabetha will still have much to offer!

BTW, does your use of indentation as a language element pre-date Python's?

I guess so, Python was produced in the late 1980's, but that does not mean than someone behind Python did not have the same idea earlier.

I guess I should patent the unique elements of Tabetha to allow it to be commercialised, so that I might be able to earn a living from it, and hence give it the time it deserves. But writing and filing patents takes time and money; neither of which I have much of (Catch 22). Currently I'm supposed to be concentrating on finding a new contract!

Connor.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Kermit Kiser

Re: Proposed NetRexx Language improvements

In reply to this post by George Hovey-2

George ;

My COBOL experience is back about 30 years so I doubt that the current version is much like it. And thinking about having to use DYL250 again would give me cold chills!

I DO use indentation a lot to make it easy for me to understand what my NetRexx programs are doing. That is exactly why I do not want the compiler to use it! It is for me, not the computer! We don't currently have that many ways to "humanize" code, so turning that one over to the compiler is a bad idea in my opinion.

I do have some ideas on how to improve that situation - to me a program is a hierarchical tree structure with branches, nodes and leaves which can be stored in an XML type format and displayed or manipulated in a graphical format. I did some work in that area but ran out of time and resources before completing it. It is nice to see that others are looking at similar approaches (Google's "App Inventor" for Android being the latest if not best example.) It seems odd to me that after so many years of programming computers, we are still stuck writing code. Code is for computers and they should write it! Of course that assumes that there is no loss of flexibility or capability with a graphical approach. Maybe one day I will get time to finish the graphical IDE for NetRexx that I started long ago.

-- Kermit

On 8/27/2010 5:48 PM, George Hovey wrote:

Kermit,
I only ever wrote one COBOL program and I try not to think about it :-)!

I just took a look at Nick Gravgaard's "Elastic Tabstops" page -- interesting concept, especially the possibility of using proportional fonts which potentially have greater legibility than monospaced fonts. For a sobering critique of this idea see https://wincent.com/blog/tabs-vs-spaces-or-spaces-vs-tabs-and-elastic-tabstops. Elastic tabstops don't appear to interfere with our usual concept of indenting code (ie, as far as leading space on a line). BTW, do you mean that you don't indent NetRexx code?
George
On Fri, Aug 27, 2010 at 5:25 PM, Kermit Kiser <[hidden email]> wrote:
Actually the jEdit developers are at this moment in the process of implementing something called "elastic tabstops" which appears to be far superior to tabs and spaces as it can automatically align things even if the programmer does not use the correct tabs or spaces. However I would be worried about making NetRexx require indentation (thinking of Cobol, etc. ugh!) as it could conflict with slick new tools like elastic tabstops.

http://en.wikipedia.org/wiki/Elastic_tabstop

-- Kermit

On 8/27/2010 1:12 PM, George Hovey wrote:
Mike,
My two cents on tabs.

Tabs are a holdover from the days when we entered programs on 110 baud Teletypes and would have considered using strings of spaces an obscene waste of computer resources. They are huge trouble makers for the reasons you have described and (IMHO) should have been discontinued ages ago.

jEdit handles this quite nicely by defining "soft" tabs which cause the TAB key to emit spaces in numbers equivalent to traditional hard tabs. Of course, other editors may not support this idea, or the programmer may destroy consistent tabbing through incautious editing. So the burden of checking indentation should be on the compiler.

One approach is to specify an equivalent tab size with an option (default value 8 for 'nix users?); leading strings of spaces not containing an integer multiple of this value could be flagged by the compiler as an aid to programmers. It could also make other checks, such as verifying that increasing levels of indentation differ by exactly one tab equivalent. It might even, as a convenience, optionally fix programs containing hard tabs and re-tab programs to a different value on demand for use with different editors.

Wouldn't this approach make the concept of indentation indicating conditionality safe and convenient? It seems to me that Connor's idea of regarding a program as a visual artifact plays to one of the mind's great strengths. And the value of consistent indentation has been understood heuristically for decades (I started with FORTRAN IV); what is gained by not making it a requirement of NetRexx?
George

On Fri, Aug 27, 2010 at 11:37 AM, Mike Cowlishaw <[hidden email]> wrote:

This problem is not due to using indentation to indicate nesting, it is due to inconsistent indentation. There is no advantage to be gained from inconsistent nesting, so best to prevent it. This problem is solved by using any editor which uses one tab for each indentation level, and automatically replacing any spaces that the programmer may use for the same purpose (I guess that most editors should be capable of supporting this. The quantity of horizontal space that the tab represents can be adjusted to fit programmer preference...

Tabs are a no-go for those of us who do use more than one editor, because it seems quite arbitrary how many spaces each tab represents (I have seen 2, 4, 5, and 8 all commonly used). If tabs are not mixed with spaces it sort of works .. but line comments over the the right all end up misaligned when one changes from editor to editor. When tabs and spaces for indentation are mixed, or sometimes spaces are used and then on other lines tabs are used, then one just ends up with a mess for the initial indention, too.

Mike

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

Fernando Cassia-2

Re: Proposed NetRexx Language improvements

In reply to this post by George Hovey-2

On Fri, Aug 27, 2010 at 6:04 PM, George Hovey <[hidden email]> wrote:
>
> MFC has always been extremely suspicious of "innovations" in NetRexx, and I
> think his suspicions well founded. Novelties should only be introduced
> cautiously. The last thing NetRexx needs IMHO is to fall victim to
> "feature-itis".

+1
I second that. :)

FC
--
"It begins with a blessing
And it ends with a curse;
Making life easy,
By making it worse;"
-- Kevin Ayers

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Rupp Peter - prupp

RE: Proposed NetRexx Language improvements

In reply to this post by Kermit Kiser

Hello,

FWIW, I have written Python (and C) code for years, and you surely will find some python fanatic out there who would rather die than give up indentation-based block delimeters. Well….after spending years in Python I can honestly say it’s no big deal. In some cases, it can become a pain-in-the-butt especially if you’re in a large block of code and when paged down several pages (in your editor, inside xterm)….it’s very difficult trying to determine which indented piece belongs to owning “if” or “while”. It’s also a bit tricky to produce dynamically created blocks of code, simply because there’s no obvious delimiter keyword you can tack on the end of a block. In any case, having blocks delimited by {} pairs, or DO/END is perfectly ok (to me anyway). Hard-core Pythoner’s make a big deal out of indentation-delimited blocks, but in practice, it doesn’t seem to matter either way.

My 2-cents.

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kermit Kiser
Sent: Saturday, August 28, 2010 1:50 PM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] Proposed NetRexx Language improvements

Kermit,
I only ever wrote one COBOL program and I try not to think about it :-)!

I just took a look at Nick Gravgaard's "Elastic Tabstops" page -- interesting concept, especially the possibility of using proportional fonts which potentially have greater legibility than monospaced fonts. For a sobering critique of this idea see https://wincent.com/blog/tabs-vs-spaces-or-spaces-vs-tabs-and-elastic-tabstops. Elastic tabstops don't appear to interfere with our usual concept of indenting code (ie, as far as leading space on a line). BTW, do you mean that you don't indent NetRexx code?
George

On Fri, Aug 27, 2010 at 5:25 PM, Kermit Kiser <[hidden email]> wrote:

Actually the jEdit developers are at this moment in the process of implementing something called "elastic tabstops" which appears to be far superior to tabs and spaces as it can automatically align things even if the programmer does not use the correct tabs or spaces. However I would be worried about making NetRexx require indentation (thinking of Cobol, etc. ugh!) as it could conflict with slick new tools like elastic tabstops.

http://en.wikipedia.org/wiki/Elastic_tabstop

-- Kermit

On 8/27/2010 1:12 PM, George Hovey wrote:

Mike,
My two cents on tabs.

Tabs are a holdover from the days when we entered programs on 110 baud Teletypes and would have considered using strings of spaces an obscene waste of computer resources. They are huge trouble makers for the reasons you have described and (IMHO) should have been discontinued ages ago.

jEdit handles this quite nicely by defining "soft" tabs which cause the TAB key to emit spaces in numbers equivalent to traditional hard tabs. Of course, other editors may not support this idea, or the programmer may destroy consistent tabbing through incautious editing. So the burden of checking indentation should be on the compiler.

One approach is to specify an equivalent tab size with an option (default value 8 for 'nix users?); leading strings of spaces not containing an integer multiple of this value could be flagged by the compiler as an aid to programmers. It could also make other checks, such as verifying that increasing levels of indentation differ by exactly one tab equivalent. It might even, as a convenience, optionally fix programs containing hard tabs and re-tab programs to a different value on demand for use with different editors.

Wouldn't this approach make the concept of indentation indicating conditionality safe and convenient? It seems to me that Connor's idea of regarding a program as a visual artifact plays to one of the mind's great strengths. And the value of consistent indentation has been understood heuristically for decades (I started with FORTRAN IV); what is gained by not making it a requirement of NetRexx?
George

On Fri, Aug 27, 2010 at 11:37 AM, Mike Cowlishaw <[hidden email]> wrote:

This problem is not due to using indentation to indicate nesting, it is due to inconsistent indentation. There is no advantage to be gained from inconsistent nesting, so best to prevent it. This problem is solved by using any editor which uses one tab for each indentation level, and automatically replacing any spaces that the programmer may use for the same purpose (I guess that most editors should be capable of supporting this. The quantity of horizontal space that the tab represents can be adjusted to fit programmer preference...

Tabs are a no-go for those of us who do use more than one editor, because it seems quite arbitrary how many spaces each tab represents (I have seen 2, 4, 5, and 8 all commonly used). If tabs are not mixed with spaces it sort of works .. but line comments over the the right all end up misaligned when one changes from editor to editor. When tabs and spaces for indentation are mixed, or sometimes spaces are used and then on other lines tabs are used, then one just ends up with a mess for the initial indention, too.

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
 
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
 
  

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________

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]

alansam

Re: Proposed NetRexx Language improvements

On 30 August 2010 12:27, Rupp Peter - prupp <[hidden email]> wrote:

Hello,

FWIW, I have written Python (and C) code for years, and you surely will find some python fanatic out there who would rather die than give up indentation-based block delimeters. Well….after spending years in Python I can honestly say it’s no big deal. In some cases, it can become a pain-in-the-butt especially if you’re in a large block of code and when paged down several pages (in your editor, inside xterm)….it’s very difficult trying to determine which indented piece belongs to owning “if” or “while”. It’s also a bit tricky to produce dynamically created blocks of code, simply because there’s no obvious delimiter keyword you can tack on the end of a block. In any case, having blocks delimited by {} pairs, or DO/END is perfectly ok (to me anyway). Hard-core Pythoner’s make a big deal out of indentation-delimited blocks, but in practice, it doesn’t seem to matter either way.

My 2-cents.

Very well put; sums up my impression of indentation-based block languages too. There's a certain amount of comfort in knowing that somewhere in the code there's something that indicates I'm done with a block. (Much like parentheses, brackets etc. It looks odd if you forget to close them...

Alan.
--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Alan

--
Needs more cowbell.

Tom Maynard

OT: Indentation, was Re: [Ibm-netrexx] Proposed NetRexx Language improvements

On 8/30/2010 3:13 PM, Alan Sampson wrote:

Very well put; sums up my impression of indentation-based block languages too. There's a certain amount of comfort in knowing that somewhere in the code there's something that indicates I'm done with a block. (Much like parentheses, brackets etc. It looks odd if you forget to close them...

I use the Parallax Inc. "Propeller Tool" to code in the Spin language for their Propeller multi-core microcontroller. I has indentation-based blocks, but the IDE has the option of visually designating them (CTRL-I toggles this feature), e.g.

This visual aid completely removes my objection to whitespace as a programming element (um, because it's not white anymore?).

Tom.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Jeff Hennick

Re: OT: Indentation, was Re: [Ibm-netrexx] Proposed NetRexx Language improvements

Looks good, but how good is it at cut and paste? That is my biggest problem with it, either in my own code (for example if I wanted to move "screen[dy*tv_hc + dx] := di" to its own subroutine requiring moving it out to the left margin) or from others code (for example sample code from email or list such as this). With an explicit End / } of some kind, I can just drop it in, test, and if I want, run it through a tidyfier to properly indent for reading / publishing.

Jeff

On 8/30/2010 4:45 PM, Tom Maynard wrote:

I use the Parallax Inc. "Propeller Tool" to code in the Spin language for their Propeller multi-core microcontroller. I has indentation-based blocks, but the IDE has the option of visually designating them (CTRL-I toggles this feature), e.g.

This visual aid completely removes my objection to whitespace as a programming element (um, because it's not white anymore?).

Tom.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

FreeFall

Re: Proposed NetRexx Language improvements

In reply to this post by alansam

On 30 Aug 2010, at 21:13, Alan Sampson wrote:

Very well put; sums up my impression of indentation-based block languages too. There's a certain amount of comfort in knowing that somewhere in the code there's something that indicates I'm done with a block. (Much like parentheses, brackets etc. It looks odd if you forget to close them...

Paragraph[

When speaking:

UnorderedList[

Don't forget to enunciate your full stops. Period.

To some people it might sound odd to just leave them hanging. Period.

]UnorderedList

]Paragraph

;-)

To others, it is more elegant to use just enough syntax to do the job.

Now really, be honest, which is better?

One great attraction of Rexx is that it has simple syntax without much of the bureaucracy associated with other languages. Why not take another step in that direction?

If one has difficulty working out where the end of a block of code lies, there are two choices:

a) Add an end clause & label to help.

b) As a book on good coding practices might suggest;

write code in sections that are small enough to be easily comprehensible

(typically fitting on one screen).

I opt for b; I've not yet heard a convincing argument for choosing a over b.

I do admit, when having to work one someone else's poorly constructed code, I add end labels and comments to make more sense of it. But then, that code tends not to use indentation properly, sometimes with ends not matching their beginning. If code had to rely on correct indentation, there would be less sloppy programming with missing elses and ends (a significant source of bugs).

But enough of this, changing people's religion is easy in comparison to their coding practices! I shall keep quite about elegant syntax. Period.

Connor.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Tom Maynard

Re: OT: Indentation, was Re: [Ibm-netrexx] Proposed NetRexx Language improvements

In reply to this post by Jeff Hennick

On 8/30/2010 4:21 PM, Jeff Hennick wrote:

Looks good, but how good is it at cut and paste? That is my biggest problem with it...

Since the Propeller Tool and the Spin language are far from on-topic in this forum, I'll just say quickly that the IDE handles cut/paste very nicely, along with laterally shifting selected text right and left, and has a number of other features that endear it.

Rather than burn bandwidth here, I refer you to http://www.parallax.com for Propeller information, including the Propeller Tool IDE.

t++

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

George Hovey-2

Re: Proposed NetRexx Language improvements

In reply to this post by Rupp Peter - prupp

Kermit, Peter, Connor,
To me Conor's "If it looks right, it is right" has a very seductive sound (am I the only one who makes errors in blocks of conditionals that are embarrassingly hard to track down?), but I see there are problems with getting it to look right. Also Kermit finds it dehumanizing. I guess we don't need more stress.

You mention wanting real delimiters: {} or Do End. jEdit has a good graphical display for matching the delimiters {}, [] and (). But no one has got it to work with Do End (I think it was on Slava Pestov's TODO before he decamped). Could NetRexx allow us to use {}, perhaps as an alternative to Do End? I suspect it would reduce my error rate :) !
George

On Mon, Aug 30, 2010 at 3:27 PM, Rupp Peter - prupp <[hidden email]> wrote:

Hello,

FWIW, I have written Python (and C) code for years, and you surely will find some python fanatic out there who would rather die than give up indentation-based block delimeters. Well….after spending years in Python I can honestly say it’s no big deal. In some cases, it can become a pain-in-the-butt especially if you’re in a large block of code and when paged down several pages (in your editor, inside xterm)….it’s very difficult trying to determine which indented piece belongs to owning “if” or “while”. It’s also a bit tricky to produce dynamically created blocks of code, simply because there’s no obvious delimiter keyword you can tack on the end of a block. In any case, having blocks delimited by {} pairs, or DO/END is perfectly ok (to me anyway). Hard-core Pythoner’s make a big deal out of indentation-delimited blocks, but in practice, it doesn’t seem to matter either way.

My 2-cents.

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kermit Kiser
Sent: Saturday, August 28, 2010 1:50 PM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] Proposed NetRexx Language improvements
George ;

My COBOL experience is back about 30 years so I doubt that the current version is much like it. And thinking about having to use DYL250 again would give me cold chills!

I DO use indentation a lot to make it easy for me to understand what my NetRexx programs are doing. That is exactly why I do not want the compiler to use it! It is for me, not the computer! We don't currently have that many ways to "humanize" code, so turning that one over to the compiler is a bad idea in my opinion.

I do have some ideas on how to improve that situation - to me a program is a hierarchical tree structure with branches, nodes and leaves which can be stored in an XML type format and displayed or manipulated in a graphical format. I did some work in that area but ran out of time and resources before completing it. It is nice to see that others are looking at similar approaches (Google's "App Inventor" for Android being the latest if not best example.) It seems odd to me that after so many years of programming computers, we are still stuck writing code. Code is for computers and they should write it! Of course that assumes that there is no loss of flexibility or capability with a graphical approach. Maybe one day I will get time to finish the graphical IDE for NetRexx that I started long ago.

-- Kermit

On 8/27/2010 5:48 PM, George Hovey wrote:

Kermit,
I only ever wrote one COBOL program and I try not to think about it :-)!

I just took a look at Nick Gravgaard's "Elastic Tabstops" page -- interesting concept, especially the possibility of using proportional fonts which potentially have greater legibility than monospaced fonts. For a sobering critique of this idea see https://wincent.com/blog/tabs-vs-spaces-or-spaces-vs-tabs-and-elastic-tabstops. Elastic tabstops don't appear to interfere with our usual concept of indenting code (ie, as far as leading space on a line). BTW, do you mean that you don't indent NetRexx code?
George
On Fri, Aug 27, 2010 at 5:25 PM, Kermit Kiser <[hidden email]> wrote:
Actually the jEdit developers are at this moment in the process of implementing something called "elastic tabstops" which appears to be far superior to tabs and spaces as it can automatically align things even if the programmer does not use the correct tabs or spaces. However I would be worried about making NetRexx require indentation (thinking of Cobol, etc. ugh!) as it could conflict with slick new tools like elastic tabstops.

http://en.wikipedia.org/wiki/Elastic_tabstop

-- Kermit

On 8/27/2010 1:12 PM, George Hovey wrote:
Mike,
My two cents on tabs.

Tabs are a holdover from the days when we entered programs on 110 baud Teletypes and would have considered using strings of spaces an obscene waste of computer resources. They are huge trouble makers for the reasons you have described and (IMHO) should have been discontinued ages ago.

jEdit handles this quite nicely by defining "soft" tabs which cause the TAB key to emit spaces in numbers equivalent to traditional hard tabs. Of course, other editors may not support this idea, or the programmer may destroy consistent tabbing through incautious editing. So the burden of checking indentation should be on the compiler.

One approach is to specify an equivalent tab size with an option (default value 8 for 'nix users?); leading strings of spaces not containing an integer multiple of this value could be flagged by the compiler as an aid to programmers. It could also make other checks, such as verifying that increasing levels of indentation differ by exactly one tab equivalent. It might even, as a convenience, optionally fix programs containing hard tabs and re-tab programs to a different value on demand for use with different editors.

Wouldn't this approach make the concept of indentation indicating conditionality safe and convenient? It seems to me that Connor's idea of regarding a program as a visual artifact plays to one of the mind's great strengths. And the value of consistent indentation has been understood heuristically for decades (I started with FORTRAN IV); what is gained by not making it a requirement of NetRexx?
George

On Fri, Aug 27, 2010 at 11:37 AM, Mike Cowlishaw <[hidden email]> wrote:

This problem is not due to using indentation to indicate nesting, it is due to inconsistent indentation. There is no advantage to be gained from inconsistent nesting, so best to prevent it. This problem is solved by using any editor which uses one tab for each indentation level, and automatically replacing any spaces that the programmer may use for the same purpose (I guess that most editors should be capable of supporting this. The quantity of horizontal space that the tab represents can be adjusted to fit programmer preference...

Tabs are a no-go for those of us who do use more than one editor, because it seems quite arbitrary how many spaces each tab represents (I have seen 2, 4, 5, and 8 all commonly used). If tabs are not mixed with spaces it sort of works .. but line comments over the the right all end up misaligned when one changes from editor to editor. When tabs and spaces for indentation are mixed, or sometimes spaces are used and then on other lines tabs are used, then one just ends up with a mess for the initial indention, too.

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
 
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
 
  
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
 
 
_______________________________________________
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]

George Hovey-2

Re: OT: Indentation, was Re: [Ibm-netrexx] Proposed NetRexx Language improvements

In reply to this post by Tom Maynard

Very nice, but I hope we are agreed that NetRexx should not require a special editor to be intelligible. This should be possible with nothing but a suitable indentation scheme (IMHO).
George

On Mon, Aug 30, 2010 at 4:45 PM, Tom Maynard <[hidden email]> wrote:

On 8/30/2010 3:13 PM, Alan Sampson wrote:

Very well put; sums up my impression of indentation-based block languages too. There's a certain amount of comfort in knowing that somewhere in the code there's something that indicates I'm done with a block. (Much like parentheses, brackets etc. It looks odd if you forget to close them...

I use the Parallax Inc. "Propeller Tool" to code in the Spin language for their Propeller multi-core microcontroller. I has indentation-based blocks, but the IDE has the option of visually designating them (CTRL-I toggles this feature), e.g.

This visual aid completely removes my objection to whitespace as a programming element (um, because it's not white anymore?).

Tom.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

alansam

Re: Proposed NetRexx Language improvements

In reply to this post by George Hovey-2

On 30 August 2010 17:42, George Hovey <[hidden email]> wrote:

You mention wanting real delimiters: {} or Do End. jEdit has a good graphical display for matching the delimiters {}, [] and (). But no one has got it to work with Do End (I think it was on Slava Pestov's TODO before he decamped). Could NetRexx allow us to use {}, perhaps as an alternative to Do End? I suspect it would reduce my error rate :) !
George

Just for fun I thought I'd try the following in jEdit:

If (condition)
then
Do -- {
...
End -- }

and

Loop label lll condition -- {
...
End lll -- }

and lo; it works. jEdit highlights the matching braces even inside comments. (Works for parens. "( )" and square brackets "[ ]" too.) Not brilliant, but better than nothing.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Alan

--
Needs more cowbell.

Mike Cowlishaw

RE: NetRexx versions

In reply to this post by alansam

I posted the full changes list (some nuggets of info there, also some ideas for future enhancements). It is > 100KB, though, so awaiting approval. Here's last few lines (all 2.xx changes):

- 00.08.26 2.00 -- NetRexx 2 general release -- above changes included
C 00.10.16       Import of 'default' package now searches all classpath segments
L 00.10.02       Printwriter on input ignored as dependent on -savelog
L 01.04.01       Imported classes not discarded after -prompt [memory leak]
- 01.04.01 2.01 -- refresh -- above changes included
M 01.05.22       LOOP Until code did not test control variable after stepping
- 01.05.22 2.02 -- refresh -- above changes included
- 04.12.18 2.04 Look for moved .jars in IBM JVM
- 05.01.14 2.05 Cosmetic blank lines were written if -comments

Looks like three of those were bug fixes. 3 in five years isn't too bad :-). The others were adjusting to changes in the Java environment(s).

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Robert L Hamilton

Re: NetRexx versions

Yes, that's a good record. I'm reminded of what my boss said of one 'product' we were pushing 'out the door;' " If that doesn't come back, it'll mean no one's using it."

On another note: Why was the 3-parm date function not included in nRExX ? And, in general, how were decisions made on differences between REXX and nREXX? Certainly, JAVA acted as a 'third rail.'

Many thanks for the help and Enjoy the Day.

bobh

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Mike Cowlishaw

RE: NetRexx versions

Yes, that's a good record. I'm reminded of what my boss said of one 'product' we were pushing 'out the door;' " If that doesn't come back, it'll mean no one's using it."

:-)

On another note: Why was the 3-parm date function not included in nRExX ? And, in general, how were decisions made on differences between REXX and nREXX? Certainly, JAVA acted as a 'third rail.'

There's no date function in NetRexx (ditto I/O) because the assumption was that people would use the existing Java classes for that. And they were a lot of work, beyond my resources (me).

Also I think at that time (1997) the three-parm date function was not in 'classic' Rexx either, or at least very new. (It was in ANSI Rexx -- 1996.)

Many thanks for the help and Enjoy the Day.

You're welcome -- Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Thomas.Schneider.Wien

Re: NetRexx versions

In reply to this post by Mike Cowlishaw

Hello Mr. MFC,
.... *not so bad done from your side* :-) :-)

What I'm really anry about is, that NetRexx does *not* become the proper *recognition*, neither within IBM, nor in the public, because so many individuals
do not even know that NetRexx, as a language, does exist now for more than
10 years (when my memory serves me rigth)
...

The major issue, thus would be (from my point of view)

*How can we spread the knowledge of NetRexx'es existance within IBM and
out of IBM as quick as possible* ????

To repeat (the hundred's of time) my view-point:

***Surely NOT with closed discusssion Lists (nowadays, at least) ***

Thomas Schneider.
===============================================

Am 03.09.2010 16:23, schrieb Mike Cowlishaw:

I posted the full changes list (some nuggets of info there, also some ideas for future enhancements). It is > 100KB, though, so awaiting approval. Here's last few lines (all 2.xx changes):

- 00.08.26 2.00 -- NetRexx 2 general release -- above changes included
C 00.10.16       Import of 'default' package now searches all classpath segments
L 00.10.02       Printwriter on input ignored as dependent on -savelog
L 01.04.01       Imported classes not discarded after -prompt [memory leak]
- 01.04.01 2.01 -- refresh -- above changes included
M 01.05.22       LOOP Until code did not test control variable after stepping
- 01.05.22 2.02 -- refresh -- above changes included
- 04.12.18 2.04 Look for moved .jars in IBM JVM
- 05.01.14 2.05 Cosmetic blank lines were written if -comments

Looks like three of those were bug fixes. 3 in five years isn't too bad :-). The others were adjusting to changes in the Java environment(s).

Mike
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

--
Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Tom. (ths@db-123.com)

George Hovey-2

Re: NetRexx versions

On Fri, Sep 3, 2010 at 7:00 PM, Thomas Schneider <[hidden email]> wrote:

Hello Mr. MFC,
.... *not so bad done from your side* :-) :-)

What I'm really anry about is, that NetRexx does *not* become the proper *recognition*, neither within IBM, nor in the public, because so many individuals
do not even know that NetRexx, as a language, does exist now for more than
10 years (when my memory serves me rigth)
...

The major issue, thus would be (from my point of view)

*How can we spread the knowledge of NetRexx'es existance within IBM and
out of IBM as quick as possible* ????

To repeat (the hundred's of time) my view-point:

***Surely NOT with closed discusssion Lists (nowadays, at least) ***

Thomas Schneider.
===============================================

Am 03.09.2010 16:23, schrieb Mike Cowlishaw:
I posted the full changes list (some nuggets of info there, also some ideas for future enhancements). It is > 100KB, though, so awaiting approval. Here's last few lines (all 2.xx changes):

- 00.08.26 2.00 -- NetRexx 2 general release -- above changes included
C 00.10.16       Import of 'default' package now searches all classpath segments
L 00.10.02       Printwriter on input ignored as dependent on -savelog
L 01.04.01       Imported classes not discarded after -prompt [memory leak]
- 01.04.01 2.01 -- refresh -- above changes included
M 01.05.22       LOOP Until code did not test control variable after stepping
- 01.05.22 2.02 -- refresh -- above changes included
- 04.12.18 2.04 Look for moved .jars in IBM JVM
- 05.01.14 2.05 Cosmetic blank lines were written if -comments

Looks like three of those were bug fixes. 3 in five years isn't too bad :-). The others were adjusting to changes in the Java environment(s).

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

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

George Hovey-2

Re: NetRexx versions

In reply to this post by Thomas.Schneider.Wien

Hi Thomas,
As a prerequisite we must have the whole package tested and perfected to the point that new users don't have a negative experience. Premature advertising could be damaging to our cause.
George

On Fri, Sep 3, 2010 at 7:00 PM, Thomas Schneider <[hidden email]> wrote:

Hello Mr. MFC,
.... *not so bad done from your side* :-) :-)

What I'm really anry about is, that NetRexx does *not* become the proper *recognition*, neither within IBM, nor in the public, because so many individuals
do not even know that NetRexx, as a language, does exist now for more than
10 years (when my memory serves me rigth)
...

The major issue, thus would be (from my point of view)

*How can we spread the knowledge of NetRexx'es existance within IBM and
out of IBM as quick as possible* ????

To repeat (the hundred's of time) my view-point:

***Surely NOT with closed discusssion Lists (nowadays, at least) ***

Thomas Schneider.
===============================================

Am 03.09.2010 16:23, schrieb Mike Cowlishaw:
I posted the full changes list (some nuggets of info there, also some ideas for future enhancements). It is > 100KB, though, so awaiting approval. Here's last few lines (all 2.xx changes):

- 00.08.26 2.00 -- NetRexx 2 general release -- above changes included
C 00.10.16       Import of 'default' package now searches all classpath segments
L 00.10.02       Printwriter on input ignored as dependent on -savelog
L 01.04.01       Imported classes not discarded after -prompt [memory leak]
- 01.04.01 2.01 -- refresh -- above changes included
M 01.05.22       LOOP Until code did not test control variable after stepping
- 01.05.22 2.02 -- refresh -- above changes included
- 04.12.18 2.04 Look for moved .jars in IBM JVM
- 05.01.14 2.05 Cosmetic blank lines were written if -comments

Looks like three of those were bug fixes. 3 in five years isn't too bad :-). The others were adjusting to changes in the Java environment(s).

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

_______________________________________________
Ibm-netrexx mailing list
[hidden email]