Hello there,
thanks to all of you for the comments so far. I simply wanted to start this discussion *now*, so that we have some of a schedule for the *desired* enhancements. My conclusion would then be, to make 'Rey' a 'NetRexx preprocessor', to get the best out of this discussion. That would allow me to add the features I think are useful, not always fighting like Don Quichotte against wind-mills. kind regards from Vienna, Tom. -- Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com _______________________________________________ Ibm-netrexx mailing list [hidden email]
Tom. (ths@db-123.com)
|
Honestly, I don't fully understand why all the fuss about '+=' et all being so abstruse operators...
Hey guys, we're talking about a language which incorporates (of all things!!) '&&' as a (i)logical 'XOR' operator. Give that one to a novice programmer and see how well he gets it down his throat... OTOH maybe this damned fixation with the novice programmer, the passing-by-user, etc. goes a long way to explain why NetRexx never got much further than LOGO as mainstream programming language... Now that I think of it... even its open-sourcing process is proceeding at turtle speed! X'D Seriously now, the fact it's quite amazing given NetRexx' actual user base background. - Saludos / Kind regards, David Requena -----Original Message----- From: Thomas Schneider <[hidden email]> Sender: [hidden email] Date: Thu, 23 Sep 2010 22:58:48 To: IBM Netrexx<[hidden email]> Reply-To: [hidden email], IBM Netrexx <[hidden email]> Subject: [Ibm-netrexx] NetRexx enhancements -- reply Hello there, thanks to all of you for the comments so far. I simply wanted to start this discussion *now*, so that we have some of a schedule for the *desired* enhancements. My conclusion would then be, to make 'Rey' a 'NetRexx preprocessor', to get the best out of this discussion. That would allow me to add the features I think are useful, not always fighting like Don Quichotte against wind-mills. kind regards from Vienna, Tom. -- Thomas Schneider Projects ReyC & LOGOS on www.KENAI.com _______________________________________________ Ibm-netrexx mailing list [hidden email] _______________________________________________ Ibm-netrexx mailing list [hidden email] |
I recall what MC said about the ampersand in the sixth edition of his irreverent IBM Jargon Dictionary (1983): "& (ampersand). Character used in many IBM macro and command languages in order to make them hard to read and to type. Helps add to the mystique surrounding programmers that use such languages. Sometimes used doubled, for double confusion." :-) Part of the problem here is that when the designers of programming languages need a symbol for something, they pick a character from the keyboard they happen to be typing at. Mathematicians, on the other hand, are a bit more rigorous in trying to avoid ambiguity by using a more appropriate symbol (though they are not always consistent). They (quite rightly) expect the technology (eg book publishers, TEX, double byte character sets) to enable them. My apologies for mentioning this, but Tabetha uses the normal mathematical symbols for AND, OR and EXCLUSIVE OR, (as well as divide and multiply) obviating the need to use cumbersome compound symbols unnecessarily, and freeing up / * & and |, ( | is used as a field separator, where it looks the part). Because Tabetha does not have implied spaces, it needs no concatenation symbol || either (it is clearer to say what you mean rather than imply things). The question is, at what point in technological development, will programmers move to using the technology at our finger tips and start using appropriate symbols in our languages instead of compromising with compound symbols? All the characters we can reasonably expect to need could fit in a single byte character set, but with the rise of double byte character sets, it is even easier since sets like Lucida Sans Unicode contain everything needed, off the shelf. Sorry, my heresy is showing again. Tabetha does not have an increment operator/assignment, given that writing the full assignment is perfectly clear. Anyone who wants to save keystrokes could write a macro for their editor to turn their shorthand into the full statement. NetRexx is the same. If we were going to change NetRexx, I think we should do so only when the benefits are more significant. Though here is the catch, if the changes are to be significant, they will be too much for many traditionalists to stomach. Kind regards, Connor. On 23 Sep 2010, at 22:34, David Requena wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
On Fri, Sep 24, 2010 at 6:18 AM, Connor Birch
<[hidden email]> wrote: > All the characters we can reasonably expect to need could fit in a single > byte character set, but with the rise of double byte character sets, it is > even easier since sets like Lucida Sans Unicode contain everything needed, > off the shelf. Sorry, my heresy is showing again. That would be right if we typed with character sets. Unfortunately we type with keyboards. H*ck, my netbook doesn´t even have separate page up/down keys, instead forcing me to use a dual keystroke (Fn+Up/Down) to simulate a Page Up/Down key. I don´t think using Alt+nnn to get a given unicode character is going to make things easier. KISS - Keep it Simple, S..eriously FC _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by Thomas.Schneider.Wien
---- Connor Birch <[hidden email]> schrieb:
"Anyone who wants to save keystrokes could write a macro for their editor to turn their shorthand into the full statement." But when I read that bloody source I still have to see this_is_the_name_of_a_very_important_variable=this_is_the_name_of_a_very_important_variable+1 and the have to change two tokensif there is a need to do so _______________________________________________ Ibm-netrexx mailing list [hidden email] |
> But when I read that [snip] source I still have to see > this_is_the_name_of_a_very_important_variable=this_is_the_name > _of_a_very_important_variable+1 > > and the have to change two tokensif there is a need to do so Yes, the a+=1 shorthand is definitely the best candidate of Tom's list. Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Not a+=expression ? It's true 'expression = 1' is the commonest case, but the latter is also common and equally inconvenient if 'a' is complicated.
On Fri, Sep 24, 2010 at 6:25 AM, Mike Cowlishaw <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
Yes, the general case of a+=expression is what I meant, where +
is any operator.
And I still like: a+expression (in general: symbol operation expression) as a shorter way of
saying the same thing (does not work in classic or oo Rexx, of course,
because a clause that is an expression is a command).
Mike
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by FreeFall
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
El 24/09/2010 15:06, Mike Cowlishaw escribió:
While I admit that *any* chosen symbol would be completely arbitrary, this particular case is specially unfortunate in my view. - For any computer illiterate or novice programmer "&&" means "some form of 'AND'". That is because the symbol '&' has a very precise meaning in plain English (which happens to be 'AND'). - For any experienced programmer coming from C or C++ (and many others) '&&' is "logical AND". - For programmers coming from java '&&' is "short-circuiting logical AND". Given that 2nd and 3rd groups comprise a big chunk of the programmers population today, by choosing '&&' as an XOR operator NetRexx has gotten to alienate most of its actual and potential users. The problem is not alleviated by the fact that a single '&' means indeed "logical AND" in ´NetRexx. A language may of course choose '=' as an non-equal logical operator (after all some arbitrary symbol needs to be chosen). The thing is that such an election would be very unintuitive for *most* people. --- Saludos / Kind regards. David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by Mike Cowlishaw
On 9/24/10 13:06 Mike Cowlishaw said:
> On 9/23/10 21:34 David Requena said: >> Hey guys, we're talking about a language which incorporates (of all >> things!!) '&&' as a (i)logical 'XOR' operator. > > What would be the logical symbol/character for XOR? '�' would be > just as incomprehensible to the average programmer... Cool! Where'd you find that glyph, Mike? The Wiccan codepage? The Double-Byte Vampire Character Set? ;-)) > [but yes, > '||' would be what I might have chosen, had that not been widely in > use for 'concatenate']. I always wondered why the compound operator '/|' wasn't chosen. Visually it says "not-or" which isn't too big a conceptual leap to 'exclusive-or' for most people. -Chip- _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by David Requena
But David ....
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by Aviatrexx
> > > > What would be the logical symbol/character for XOR? > > '�' would be > > just as incomprehensible to the average programmer... > > Cool! Where'd you find that glyph, Mike? The Wiccan > codepage? The Double-Byte Vampire Character Set? ;-)) Google (for example): HTML exclusive or > > [but yes, > > '||' would be what I might have chosen, had that not > > been widely in > > use for 'concatenate']. > > I always wondered why the compound operator '/|' wasn't chosen. > Visually it says "not-or" which isn't too big a conceptual > leap to 'exclusive-or' for most people. I'm not sure, either (see post of a few minutes ago). There was precedent for &&, I'm sure, so I followed that. Mike _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by Thomas.Schneider.Wien
I use the += and related operators, and think if anything is added, that
should be the first candidate. I'm opposed to "a,b,c = x" although it is occasionally useful. Partially because it opens the door to: "Why didn't you do it like the other languages: "a=b=c=x" etc. I just don't think it is needed in a beautifully simple language like Rexx. Of course (IMHO) the ++ and -- operators are a couple of very bad features of C (along with the gratuitous break statements which have cost zillions of programming hours). It's such a shame that people let bad ideas become normal, and then expect them! Tinkering with a well designed language is a very slippery slope, and when different implementations support different syntax or capabilities there are always problems. Language evolution is fine, but it has to be carefully controlled. I think one of the strengths of Java is that Sun kept M$ from tinkering with it. There is an ANSI standard for Rexx and a single language definition for NetRexx, and it probably ought to stay that way. As for "NetRexx 3", maybe there should be community agreement well before anything is implemented? Mike owns the NetRexx name (philosophically if not legally), and it shouldn't be called NetRexx without his blessing. Of course everyone is free to invent their own language with any other name they choose :) I'm no fan of macro languages and preprocessors. Although they are occasionally useful, I think they tend to greatly muddy the water. The C preprocessor is a mess, and the PL/I preprocesssor doesn't have much to do with PL/I - it just sort of looks like it. That being said and from a language design standpoint, I've sometimes thought that a single token equivalence statement at the language level might not be a bad thing, at least in some cases. The "means" statement might help to get around keyboard and other clarity issues. It would be a restricted form of typical token substitution preprocessing, but limited to single tokens only. Over used though, it could really be a mess as well. For example, a BNF like equivalence token ("::=") or something more simple which is not a word could be used to specify the "means" statement. Then the statement "this ::= that" provides single token equivalence within a scope. A sequence of "means ::= ::= ; XOR means && ; " etc. allows some increased capability for clarity if used carefully. Obviously this has been done with various preprocessors, but I'm talking about token equivalence, not substitution. I think there is a bit of a difference between "this means that" and "#define this that", although in practice they are pretty much the same. The problem with something like this is knowing when to stop. It is much too easy to extend single token equivalence into "one for many" as in "flop means call that thing ; (i.e. #define flop call that thing )" etc. "because it is easy to do, it's just one string for another". Then comes "many to many" as in "do it means something else", and worse, the whole idea of "since we are substituting, why not add some parens, use $ for arguments, and maybe a conditional operator, etc. etc.". A very slippery slope indeed. Maybe not for NetRexx like languages though, since in effect it gives tokens specific meaning, and that is a bit counter to the idea that a word takes its meaning from the dynamic execution environment rather than from a fixed definition (i.e. reserved keyword) or a static definition (such as the "means" statement). And I definitely wouldn't like "++ means += 1" :-) Bill -------------------------------------------------------------------- mail2web.com - Microsoft® Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange _______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by David Requena
My vote goes for iinbdfi -- the old reliable
bobh On Fri, Sep 24, 2010 at 9:58 AM, David Requena <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by Mike Cowlishaw
I agree that '||' makes the most sense because it suggests 'OR', but somehow not the regular kind.
I would guess that the majority of programmers seriously involved with boolean functions are working in integrated circuit simulation and design. Their chosen languages, eg ADA and VHDL use operators such as XOR, NOR and AND which have the advantages of being pretty unambiguous and avoiding the frantic search for unclaimed symbols. Did you consider such an approach? BTW, apparently I am not alone in having difficulty remembering &&. This no doubt says something about my mental agility, but also about the infrequency with which this function is actually needed. However, after this airing of && grievances I think I just might remember henceforth! On Fri, Sep 24, 2010 at 12:34 PM, Mike Cowlishaw <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
In reply to this post by Thomas.Schneider.Wien
If we are going to change these symbols, lets not just plump for some other random symbol. Using ∧ for exclusive OR would be as crazy as using = for not equals, since ∧ is the mathematical symbol for AND!
If we change the symbols, lets be consistent and virtuous and use the proper mathematical ones. They may seem arbitrary to someone who does not know them, but the same could be said of any mathematical symbol; if we went down that route it would be a license to use all sorts of random symbols due only to personal preference, and some one would come up with a different sort of OR and we'd have ||| or &&& or &&| or something terrible. If, for consistency with our mathematics mates, we use = for equals, + for addition, then lets also use ∧ for AND, ∨ for OR, and ⊕ for EXCLUSIVE OR. It turns out that they are just as easy to remember as any other symbol and actually look nicer in expressions I think since they don't get mistaken for anything else. After all | does not really mean OR any more than any other symbol, and EXCLUSIVE OR is neither OR OR (||) or AND AND (&&). If we use the proper mathematics symbols, we'll not end up having to invent new compound symbols every time we include a new operation. I think some of the confusion stems from the words used, and not using the correct words when talking about the operators. When we say AND, what we really mean is BOTH. When we say OR, what we really mean is EITHER, and when we say EXCLUSIVE OR, what we really mean is ONE OF. When we think of it like this, the temptation to use & for BOTH is less attractive, and using the established mathematical symbols is easier to accept. In todays world, there is no difficulty in using the correct symbols; they have been provided by fellow human beings so that we can use them, lets not insult these good people by ignoring their efforts while making do with something far less adequate. If there is not much appetite for NetRexx to evolve, then this is the wrong forum to discuss these things. If the approach taken by Tebetha (which has no qualms about using the most appropriate symbols, or moving on from what other languages have done) makes sense to anyone, and they want to learn more about Tabetha (which has syntactic elegance for human usability as one of its key aims), I'd be happy to contribute to a separate forum (when I'm not so busy). Let me know, Connor at JoinedUpBusiness dot com. Connor. On 24 Sep 2010, at 17:37, Mike Cowlishaw wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] |
Frankly, if second-guessing Mike about his choice of glyph for an
relatively obscure operator is the best we can do, I'd say there are better uses for our time. He was working with a 3270 keyboard and an expected initial programmer base familiar with EXEC2 and PL/I. And I suspect that when he started the design, he had no idea it was going to be publicly available in the first place. NetRexx inherited those choices honestly. Before long, we'll have voice-dictated programs and the whole keyboard/glyph problem evaporates. That will spawn a movement to make programming terms more euphonic (we can say "substring" now!). With the development of RMM technology, we'll find out how faulty our cognitive processes are, and people will wax nostalgic for the good old days of striking a specific key to get a specific character. As for adding syntactic sugar to NetRexx, I find it hard on my programming pancreas. There is an elegance in the conceptual simplicity of the Rexx design that such accretions mar. Sort of like putting spinner hubcaps on a Roll-Royce, imho. I wish I could look back at when I was his age and say that a sub-optimal choice for a mathematical symbol was one of my most enduring regrets... :-/ -Chip- _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Hello Chip, and all:
Let me give you my synopsis: 1.) Chip, thanks for your elobarative explanation. Each and any letter of you does improve3 my english a LOT! 2.) Comparing classic Rexx to NetRexx Syntax, for me, looks as if NetRexx did *correct* some false decisions in the design of Rexx: examples: a) undefined variables get theitr UPPDERCASED value by default (in classic Rexx) b) this decision can only detected by the SEMANTIC analysis (as in Rexx2Nrx) as the original assignment may be postponded to a subroutine call! c) I assume that when Rexx has been designed and implemented, Mr. Mike Cowlishaw did already *know* the purpose of Parameters, but, by stepwise implementation, did introduce the ARG, PARSE ARG statemement, and later ooRexx the USE ARG statement..... in those times. the definition of a FUNCTION/SUBROUTINE by: FUNCTION abc(a,b,c) has been already common to *all* programming languages I do know. d) NetRexx now defines *prior* definition of a variable before first usage. Also a *correction* to the original (historically grown, and wrong) Rexx design. etc, etc etc. Thus: my viewpoint again: Let's keep Rexx as it is (by design). Dead Language (sorry to say) Let's enhance NetRexx as quick as possible. And spread the knowledge about it's existance as quick as possible (open member list, please) Otherwise, both Rexx, ooRexx, and NetRexx will die! Except all of use -relatively old- members of REXXLA (and IBM-NetRexx) *no one* of those young IBM programmers and/or consultants I'm currently meeting does even *know* either Rexx, nor NetRexx... It's a pity, we will have to change, ASAP, IMHO ... Tom. ============================================================== Am 24.09.2010 21:54, schrieb Chip Davis: > Frankly, if second-guessing Mike about his choice of glyph for an > relatively obscure operator is the best we can do, I'd say there are > better uses for our time. He was working with a 3270 keyboard and an > expected initial programmer base familiar with EXEC2 and PL/I. And I > suspect that when he started the design, he had no idea it was going > to be publicly available in the first place. NetRexx inherited those > choices honestly. > > Before long, we'll have voice-dictated programs and the whole > keyboard/glyph problem evaporates. That will spawn a movement to make > programming terms more euphonic (we can say "substring" now!). With > the development of RMM technology, we'll find out how faulty our > cognitive processes are, and people will wax nostalgic for the good > old days of striking a specific key to get a specific character. > > As for adding syntactic sugar to NetRexx, I find it hard on my > programming pancreas. There is an elegance in the conceptual > simplicity of the Rexx design that such accretions mar. Sort of like > putting spinner hubcaps on a Roll-Royce, imho. > > I wish I could look back at when I was his age and say that a > sub-optimal choice for a mathematical symbol was one of my most > enduring regrets... :-/ > > -Chip- > > > _______________________________________________ > 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)
|
In reply to this post by Aviatrexx
Hence, Chip:
-- why NOT simply re-introduce the common words AND, OR, and XOR as (possible) alternatives for &, | , && (Rexx notiation) ? -- By the way, BOOLE has been *wrong* to re-use these words for another purpose: Example: Austria, Hungary, and Slovakia Means the UNION in natural language (*NOT* the intersection) But that is *another story*. All computer languages *fail* compared to natural language meaning. Sorry to say. Thomas. ============================================================= Am 24.09.2010 21:54, schrieb Chip Davis: > Frankly, if second-guessing Mike about his choice of glyph for an > relatively obscure operator is the best we can do, I'd say there are > better uses for our time. He was working with a 3270 keyboard and an > expected initial programmer base familiar with EXEC2 and PL/I. And I > suspect that when he started the design, he had no idea it was going > to be publicly available in the first place. NetRexx inherited those > choices honestly. > > Before long, we'll have voice-dictated programs and the whole > keyboard/glyph problem evaporates. That will spawn a movement to make > programming terms more euphonic (we can say "substring" now!). With > the development of RMM technology, we'll find out how faulty our > cognitive processes are, and people will wax nostalgic for the good > old days of striking a specific key to get a specific character. > > As for adding syntactic sugar to NetRexx, I find it hard on my > programming pancreas. There is an elegance in the conceptual > simplicity of the Rexx design that such accretions mar. Sort of like > putting spinner hubcaps on a Roll-Royce, imho. > > I wish I could look back at when I was his age and say that a > sub-optimal choice for a mathematical symbol was one of my most > enduring regrets... :-/ > > -Chip- > > > _______________________________________________ > 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)
|
Free forum by Nabble | Edit this page |