Talk:Josephus problem: Difference between revisions

→‎failings of languages not working with other languages: added various comments concerning REXX variants. -- ~~~~
(→‎failings of languages not working with other languages: added various comments concerning REXX variants. -- ~~~~)
Line 14:
http://rosettacode.org/wiki/Rosetta_Code:Village_Pump/Dialects#REXX.2C_ooRexx.2C_and_others
 
::: This is the first I've ever heard that ''many'' others think that ooRexx is a (valid) Classic REXX interpreter.   (Note that some IBM documents refer to ''standard'' REXX instead of ''Classic'' REXX).   I was always under the impression that all (if not most) REXXes which weren't object oriented (oRexx, and later, ooRexx), they later called ''Classic'' REXXes.   Note that those REXXes weren't called ''Classic'' until object-oriented REXXes were introduced.   Whereas oRexx and ooRexx ''may'' interpret most Classic REXXes correctly, that implies that some Classic REXXes won't/can't be interpreted/executed correctly/successfully.   I applaud the attempt at documenting the ''little differences'', but the bigger differences are much more important to document.   Any attempt at grading these differences, no matter how ''small'', just diminishes the importance of those differences.   What is important is that the programs will execute differently (and most probably show different or even incorrect results).   It is these differences (and enhancements) that make oRexx and ooRexx "not Classic":   notably the treatment of stems and stemmed variables: Classic REXX treats them as variables, oRexx and ooRexx treat them as objects.   Sometimes this is a very subtle (and almost imperceptible syntactically) difference, but the execution (evaluation of the expression) is markedly different.   Another sharp dividing line is the use of ''' -- ''' as the start of ''in line'' comments (not a part of Classic REXX, but Regina REXX has introduced it in release 3.4).   ''' A = --B '''   is a valid Classic REXX statement, as unary operators are permitted.   [The use of multiple unary operators often come up with the use of the '''INTERPRET''' instruction (most often with "calculator"-type programs or those programs that allow the user to enter algebraic expressions such as for the '''truth table''' and the '''24 game''' on Rosetta code), or with computer generated statements as with the '''24 game/solve''' on Rosetta Code.   The use of ''in line'' comments ''may or may not'' be allowed in Regina REXX, depending upon which options are in effect, ''and/or'' which version of Regina REXX is being used.   Please don't think that I'm attempting to grade the differences or assign levels of importance to various incompatibilities, I'm not an expert in all the differences between Classic REXX and the object-oriented REXXes.   Another topic would be the limitiations of the various REXX interpreters;   I've not marked any REXX (program) examples as incorrect (if they wouldn't work on some REXXes);   some of these would be the use of long clauses, the use of some gylphs, the use of newer BIFs (built-in functions) and/or enhancement to some BIFs, etc. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 00:05, 10 May 2013 (UTC)
I shall remove the "criticism right now. My words were meant to help other users.
Yet I DO insist that Rexx programs that don't use the ++, i.e., the oo features, do have their proper place in the REXX category and only those that do (use them) should and do appear under ooRexx.
--[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 07:42, 9 May 2013 (UTC)
 
:: What about those programs that use ooRexx enhancements, but not object-orientated (++) features?   Especially language constructs that no Classic REXX accept?   (Of course, if you think that ooRexx '''is''' a Classic Rexx, then this argument would be moot).   Should novices be expected to see a REXX program (in the REXX section) on Rosetta Code and then try to use a Classic REXX interpter and expect it to work?   This is one major reason that I pushed for a distinct oRexx and ooRexx section.   At that time, NetRexx already had its own section. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 00:05, 10 May 2013 (UTC)
 
:::Is there anyone else interested in this particular language topic and could they voice their
opinion(s)?
Line 22 ⟶ 27:
 
::::I don't know REXX and its versions, but it seems that if this has been debated before and their is no resolution as yet then may I suggest that REXX ooREXX and netREXX etc be treated as separate languages the way the BASICs are? With separate Category: pages that might want to add that the other versions should be checked for compatability notices. If someone knows for example, that an ooREXX solution works for REXX then maybe they could add that as a note in the ooREXX solution. The idea being to have the REXXs have solutions where it would become common for people to add notes on what happened when they tried it on another version of REXX.
 
::::: It may not have been obvious, but ooRexx and one NetRexx (example) programs were moved to their respective sections.   In that sense, the issue has been partly solved, if not by segregation only as viewed by looking at the example programs to see if they used object-oriented (++) features.   This didn't address the underlying problem of use none-classic REXX constructs for Classic REXX, however.   It seems to have come down to '''what''' is a Classic REXX interpreter? -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 00:05, 10 May 2013 (UTC)
 
::::If it is possible to modify one version to work on multiple versions - and you check that it does; then this should be noted too.<br> Just a thought. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 14:11, 9 May 2013 (UTC)
 
::::: Yes, it's possible to modify REXX programs to execute under REXX, PL/I, Fortran, IBM assembler, ''and'' ooRexx. &nbsp; It would be a fun and amusing exercise, but not practical &nbsp; (kinda like programming in HQ9+, Brainf***, Befunge, or Whitespace). &nbsp; Three main concerns: &nbsp; one has to ''think'' in several languages (and know each of their limitations), &nbsp; and have access to each of those compilers/interpreters, ''and'' take the time to test each of them. &nbsp; I have access to seven "common" REXXes plus almost all flavors of Regina REXX, and it takes a lot just to check those versions out. &nbsp; Indeed, three of them are too much trouble to test. &nbsp; Another would be to think what statements are in common and not use those REXX statements that can't be (of won't be) acceptable in another language (and even if in the ''same'' language, if you catch my humor). &nbsp; I don't program in that mode, it's too restrictive &nbsp; (and as the ole joke goes, nobody's paying me enough). &nbsp; I have never worked at a shop that said: "go ahead and program for our IBM FORTRAN H compiler, but don't you use any FORTRAN statements that won't work on a CDC or Cray Fortran compiler". &nbsp; I'm sure that there are circumstances where that isn't the case, but most programmers try to code the most efficient (and productively) for a specific compiler/interpreter (unless they are in the business of selling software instead of just ''using'' it). -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 00:05, 10 May 2013 (UTC)
 
:::::;The Rexx programs that carry my name should work on all REXXes ( I cannot test them on others since I don't have any other - I had TSO Rexx till 12/2012)