Talk:$err.rex: Difference between revisions

10,912 bytes added ,  8 years ago
m
→‎How does this fit here?: added a comment or two ...
 
m (→‎How does this fit here?: added a comment or two ...)
Line 2:
 
This does not seem to be a task - are you sure this is the right site for it? (I'm thinking maybe move it to another wiki and include a link there from your user page?) --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 13:23, 9 May 2016 (UTC)
 
-----
 
I'm not understanding about a link to there from my user page.   How would that help?
 
Why would a CBLF, er..., a person, looking at   '''a'''   Rosetta Code (REXX) solution/entry wander off to my user page   (assuming that they know who/what I am --- the author of the code, and I'm not one that puts my name on every [or any] REXX program that I enter), and then, from there, go off to another site to look at some code which may or may not explain or show the missing REXX code).   Ya, I know, they could always look it up in the "history" thingy, assuming that I entered/updated the correct section.   In my case, I almost always change the '''RUBY''' section, and then prepend the '''REXX''' section.
 
Whenever I'm at a site that has those indirect and rather obtuse links, the links seem to be broken or not working in more cases than not.   And I can never quite trust those links, with all the cra... er, crud there is on those webpages.
 
 
Anyway, addressing the issue at hand ---
 
The $ERR (REXX) program is definitely not a solution to a specific Rosetta Code task --- at least, not directly.   I do think it belongs on Rosetta Code because of references (uses) of this REXX program by various other REXX programs (solutions) entered for solutions/problems/tasks on Rosetta Code.   I don't have the skills nor ability to create   ''another''   Wiki to move these few essential (my choice of words) support programs to it.   Each of these support programs also have a separate help (documentation) file, and it is separate for the same reasons.   [They also have other support documentation, specifically a logic flow and a sample use (usage) file which shows sample uses, but I thought that would be the straw that broke the camel's back here on Rosetta Code.]   The separate help files (possibly) aren't required, but I believe that more documentation is better then too little.   You can always ignore it, but if you need it, ... it's there, ... er, here, I mean.
  And it's not like you have to read or see it, it's only there if you go down the link chain, so to speak, a rabbit hole that you don't have to travel down.
 
By   ''rabbit hole'',   ya know, ya link to a page, then ya link to another page, then ...
 
The $ERR (REXX) program is an external routine that other REXX programs on Rosetta Code make use of, those other REXX that are present on Rosetta Code and which do solve specific Rosetta Code problems (tasks).   Rather than having numerous copies of these commonly used REXX program(s) attached/affixed to those tasks, I've included them here since these "common-core" REXX routines make the other REXX programs useable and complete --- it is the idiomatic method that REXX programmers always used since the 1980's (oy veh, that does show my age).   This isn't the only occurrence of such a "helper" REXX program, but it was the only one that was previously renamed (or moved) and made other links to it invalid (i.e., broken links, a bane if I ever saw one, and I always interpret broken links as a symptom of a poorly maintained web site).   Since I didn't want to argue the point with someone who buys ink by the barrel, I left the broken links as they were for (quite) sometime, hoping the problem with be fixed by the "someone" who broke it in the first place.   It wasn't.   More fool, me.   (Adding a re-direct would've worked, but those thingys are a mystery to me, and I'm not sure that would solve the problem, and that's assuming that I have the authority and know-how to add/implement those re-directs thingys, possibly creating another rabbit hole).   So eventually, I made it consistent with the other (easy to understand) helper programs and reinstated it (with a new version that included better documentation (comments) and other such improvements, along with a comment to explain what it is and how ya gets to here (er, ... there).
 
Normally, most of the (small) solutions to various Rosetta Code problems don't require these helper/assist REXX programs.   Or perhaps, a better way to express that is to say that I chose not to enter a more robust (and voluminous) REXX example.   But as the solutions get more complex and bulkier (and robust), and rather than including them with those solutions, the idiomatic method of handing these types of routine functions is to write an external routine (i.e., a REXX program) and just invoke that routine to perform some common (useful) service.
 
By the way, in case you don't know it, the REXX language (for instance), doesn't have any "higher" math functions, no trigonometric or hyperbolic functions, and it doesn't even have things like a square root (SQRT) function, so we REXX programs have to roll our own   (or borrow someone else's version).   Normally, the SQRT function would be included in another external routine, but here on Rosetta Code, that doesn't lend itself to that option, so it would just be easier to include the source within the REXX program that uses that function.   I just use the SQRT function as an example, and SQRT happens to be short enough that that technique is useable and feasible.
 
There is a whole 'nother back-story on that, and it lies in the roots of how REXX came to being, and how the original environment facilitated such external (REXX) programs for ease-of-use and performance issues.
 
 
For instance, issuing specific error or informational messages for the various REXX programs that do, in
fact, issue error messages because of interaction with a user (such as games, where incorrect or incomplete input is expected, and indeed, happens with common frequency) --- as in the case of games when there is a lot of interaction with a user (that is, a player or players). &nbsp; Having these error message in an external routine makes the presentation of those messages external to the calling program and doesn't clutter up the program being presented at any specific Rosetta Code task. &nbsp; The issuance of those error message just detracts from the solution (entry), and makes it pretty bulky. &nbsp; Of what I've observed on Rosetta Code, most computer programmers don't handle errors at all, that is, they assume that the input(s) from the users/players are correct and without error. &nbsp; (A utopia !!) &nbsp; I don't subscribe to that philosophy. &nbsp; If there is an interaction with the user (or player in some cases), there <u>will</u> almost certainly be errors. &nbsp; Checking for those errors (or lack of input, misspellings, typos, wrong types of inputs, too little, too much, etc) really makes the programs more robust and not fail with some obscure (or ugh, general) error message. &nbsp; This isn't just a problem with interpretative languages, but with input to solutions (computer programs) that aren't guaranteed to be perfect. &nbsp; Now, some Rosetta Code tasks say (something to the effect) that to assume the input is correct &nbsp; (if there is input data/numbers/integers (positive) to be processed). &nbsp; With games and other interactive situations, not so much.
 
 
In the vein of wanting world peace ···
 
I wish there was something more of a guideline about entering "largish" Rosetta Code solutions (entries), that is, if a computer program is over a certain size (source lines), put the program into a separate section, diminishing the bulk of the Rosetta Code collection of entries. &nbsp; I know this is a problem of most of the "popular" Rosetta Code tasks (popular = many entries = many lines of code = slow rendering = ···). &nbsp; There appears (to me) too much code golf as it is, and entering a robust solution seems to be atypical, and even frowned upon to some degree -- at least, that's been my impression, unfortunately. &nbsp; As you are probably aware, the REXX programs that I've entered contain a lot of comments, a commodity that should be encouraged, I should think. &nbsp; In that vein, I reduce the size of the (some) REXX programs by having commonly-issued error message(s) in an external REXX program, along with the boilerplate code to help insure the user actually sees the error message(s) [in color {red} if supported], and with the necessary auxiliary information such as what the error is (in the vernacular), where it occurred (which program, which line, which REXX variable --if that is appropriate), what action caused the error, etc. &nbsp; Now, all this comes at a price. &nbsp; Because of this bulk, is the main reason the external program exists, that, and the error recovery (flushing the stack, closing all open files, etc). &nbsp; Now, this is just a routine to ensure the user actually sees the error (or informational) messages; &nbsp; the $ERR REXX program in reality, uses another program ($T, in my case) that handles the situation of ensuring that there is a CONS (console) device and it is "enabled", along with the checking if the REXX interpreter and/or operating system (and terminal) supports color, and if so, uses a specific color if requested. &nbsp; Yada, yada, yada.
 
Another case is the use of specific BIFs that may or may not be present in older (or newer, for that matter) REXXes. &nbsp; The LINESIZE, SOUND, SLEEP, SCRSIZE, CHANGESTR, COUNTSTR, and various options for the DATE and TIME functions, etc, and others, which I don't include within the (host) REXX programs, but link to if the user wants (or needs) actual working code if their REXX interpreter doesn't have that facility (or BIF). &nbsp; In actuality, all of my (regular, at home) REXX programs have a boilerplate epilog that determines which REXX (interpreter) is being used, what operating system it's running under, and sets/defines various "system" variables indicating what command to use to clear the terminal screen, what option to use to inquire/set environmental variables (the &nbsp; ''pool'' &nbsp; name), handles any request for (help) documentation), and some other stuff that I won't bore ya with regarding error recovery and stuff like that there. &nbsp; I really don't appreciate (REXX Rosetta Code, and in general) entries that make use of BIFs (or facilities) that aren't present in all REXXes. &nbsp; This is one of the main reasons that I insisted that major deviations from Classic REXX have their own language category, otherwise it would be a Tower of Babel --- what would be the usefulness of having all the BASIC variants being lumped together, for instance? &nbsp; But that is an old and practically dead horse that still comes up at times --- and a subject that I wish I could have with the powers-that-be.
 
 
Yeah, I know, I know ···
 
Ya ask me what time it is, and I tell ya how to build a watch. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 19:50, 9 May 2016 (UTC)