User talk:Gerard Schildberger
Flag as incorrect
Hi, I think you left a comment the above will erroneously return:... on a PLI example. Could you change this to use the template incorrect so that PLI users are flagged that the example needs attention. Thanks. --Paddy3118 18:22, 28 October 2010 (UTC)
Please summarize your edits
Just a little note: when editing, it's polite to include something meaningful in the summary that says what you've done -- for example, if you add a new solution to a task, it's nice to put something like "added language" in the summary to let others know what you've done.
I'm still trying to get the hang of things. I'm not sure of I'm doing this correctly (where to reply/type this stuff). I find this type of "interaction" a bit strange and out-of-sync sort of feeling.
First, I don't even know where this summary thing is (was?) until just recently. Previously, I didn't know what it was for, as I was just adding new code (examples) and thought the adding of a new (code) example was self-explanatory. I'll try to add something like (added new example or some such if that helps anyone understand what I just did. Hells bells, I don't even understand what I did half the time anyway. Hard to believe, but there are advantages of having senior moments.
Most of my updates (followups) are so minor that it would be distracting for casual readers what I've done, and I try to keep forcing my self to add comments to most of my REXX examples, something which seems might be a waste of time as I see very little evidence elsewhere of copious (or even brief) comments on (at) the statement level. I spend quite a bit of time dumbing-down my code to make it understandable for the novice (REXX) programmer. In doing so, I try to add (statement) comments on what the statements are doing/accomplishing, but the more advanced one gets, the more shortcuts one takes, and the code becomes obtuse with very little effort, sad to say.
REXX leads itself to writing a lot of "one-liner" subroutines (or, at the least, pretty short subroutines/procedures). This hides the commons tasks that happen over and over again, the duldrums of programming. The one-lines tend to end up at the bottom (end) of the program, usually after some kind of comment fence. Out of sight, out of mind. Most often, the one-lines are very general in nature and have been thourghly tested/debugged, and once written, almost never looked at again --- until Rosetta Code. Most REXX programmers write code on serveral classes of computers, PC's just being one. There is a lot of boilerplate to keep track of, environmental impacts, restrictions on command options, command names, command formats, terminal (console) support (linesize, screen width, fonts, file structure(s), file naming protocols, security concerns (read/write), operating system quirks (that's the polite word for it), etc, etc, etc. You wouldn'be believe the proglogue code that I have written (collected) over the ... ahem, decades of programming in REXX -- cough, cough, since around 1982 or so. And I'm a regular packrat. PL/I was way back in 1866 , er, make that 1966. Anywhooose, I'll try to make more summaries, even if almost all of them are quite bland and/or uninteresting. Gerard Schildberger
Under Special:Preferences is an option for the wiki to remind you to enter a summary if you forget; I highly recommend turning it on. (Look for "Prompt me when entering a blank edit summary" under the "Editing" tab.) -- Erik Siers 13:14, 29 October 2010 (UTC)
- Hi Gerard, Adding the summary takes little time, and really helps others. Thanks. --Paddy3118 06:27, 30 October 2010 (UTC)
I'm not sure where these summaries end up, as I never had seen any. Is it under the "history" section? I must confess, when I look at some code, I don't care to read about how and/or when changes where made, all I care about is the final product (so to speak) and I'm not particuraly interestred in the code's change pedigree. But that's me, and I realize that others might find that sort of detail interesting in some way. Gerard Schildberger
Welcome!
Welcome to Rosetta Code! I'm Mike, and I noticed you created an account.
Some quick things you should be aware of:
| Template:Mylang | Helps you show what languages you're familiar with, and helps us become aware of skills with languages we haven't seen. |
| Category:Unimplemented tasks by language | A place to find tasks missing solutions in various languages. |
| Blogs, twitter, facebook... | We have them, and are interested in yours. |
| Special:Webchat | Logs you into #rosettacode on the Freenode IRC channel. Not usually the most active communications medium, but occasionally helpful. It's logged at http://irclog.perlgeek.de/rosettacode/today. |
| Rosetta Code:Village Pump | A general Q/A and discussion area. |
| Rosetta Code:Finances | For most of Rosetta Code's history, expenses have been paid out of my pocket. I can't afford that much longer, and so you can see the state of Rosetta Code's finances, and how you may help. If you enjoy or are excited about the site, please consider reading through it. |
Sorry for the boilerplate; it can be a bit difficult giving an individual greeting to each person. If you post information about your technical interests and background, I'll probably read it. If you already have put that kind of information on your user page, I probably already have; I'm always interested in how people do and can benefit from Rosetta Code.--Michael Mol 12:31, 1 November 2010 (UTC)
Too much text on a page
Please try not to put more than a few KBs on a task page for each example. When the task pages get too large it gets difficult to manage. If you must add large examples or large output sections, please put them on a separate page and link them. --Mwn3d 03:57, 7 December 2010 (UTC)
- If you really want to do a large Sierpinski triangle, do it as an image (no more than 800 pixels wide?) and use that. The code to do that instead of an ASCII version can be seen as an Extra Credit item, and it has the advantage of keeping the page much smaller. –Donal Fellows 09:36, 7 December 2010 (UTC)
Request for dialogue
The text of an email sent to Gerard: <lang email>From: Paddy 3118 <paddy3118@xxx.net> Date: 7 December 2010 04:40 Subject: Rosetta code. To: GerardS@zzz.net
Hi Gerard,
Could you visit your talk page on Rosetta Code and chat about some of the issues raised?
Thanks.
- Paddy3118.</lang>
My email, and response
Sorry Paddy; at the point where people start sending open letters, I figure it's time I finally take a look.
<lang email>On Tue, Dec 7, 2010 at 6:21 PM, Gerard Schildberger <GerardS@rrt.net> wrote:
Michael Mol:
----- Original Message ----- From: "Michael Mol" <mikemol@gmail.com> To: "Gerard Schildberger" <GerardS@rrt.net> Sent: Tuesday, December 07, 2010 08:53 Subject: Rosetta Code, edits and communications
| Hey, it's me, Short Circuit.[1] | | I've been the recipient of some rumbles (not just from Paddy) about | folks wanting to have a dialog with you in your user talk page[2]. I | don't know your reasons for not communicating there, and I usually try | to leave the community alone when it comes to on-site activity, but | one of my responsibilities is to step in and try to resolve things | before they becomes major issues in the community.
I had tried to use the talk page, but found that it didn't work, so I just continued added programs to solve various tasks. It's not intuitive why (to me, anyway) why there needs to be a talk page when a simple E-mail would suffice.
Understood. Originally, I think, the "talk" pages were a simple hack by the original MediaWiki/Wikipedia devs to
provide a public discourse option. (They use the same formatting syntax and logic as any other page.) Primarily they get used on pages in the 'Main' namespace, but I suspect it was deemed simpler to enable them across all namespaces. I think they generally get used for "front-channel" (where email might be thought of as "back-
channel"), open communication.
Personally, I think the Talk namespaces' behavior is a hack, and I'd rather see an NNTP back-end, or at least a
decently-designed threaded forum. Unfortunately, the more I write and/or add, the more I have to maintain, Rosetta Code isn't my bread and butter, and so I work with what I can.
After all, E-mail gets to me directly, and I don't get on the Rosetta Code site that often. Also, some people don't interact well in forums,
Understood. Truth by told, I have two primary ways I keep up with the site. The first is email (the site emails
me whenever a page on my "Watchlist" is edited. The second is the RSS feed found on the "recent changes" page.
... if you're a student of newsgroups, then you know of what I speak. Not all discourse is benificial.
Believe me, I understand. I haven't been on newsgroups myself in a while, but some email lists have their problems, too.
As the founder and owner of the site, I have three primary roles. The first is to make sure the site stays online
and functioning. (Pay for the hardware, maintain the software). The second is to watch the forum behavior on the site, identify trouble spots, and attempt to interpret, moderate and intervene before things flare up and I wind up with a community schism on my hands. The third is to keep the site fluid and beneficial to a large cross-
section of users and audience.
| To that end, I'd like to offer some advice. | | First, you should check your user account preferences[3], and supply | the server software with your email address. It will happily email you | whenever someone wants to talk to you through the wiki software. | | Second, you should probably reply to messages left in your talk page. | I don't know if you've seen them or not (it doesn't seem you provided | the server software with your email address, so it's plausible you | haven't), but people have left notes in good nature offering ways for | you to interact more cleanly with the site structure and software.
Yes, if fact, that is exactly what happened. I didn't know that I had to provide an E-mail address to RC. I have since done that. I didn't even know that I had stuff there to read, yet another place to check to see if there are messages.
Completely understood. As far as system configuration, I could require an email address to proceed with sign-up,
but many folks have privacy concerns about giving their email address out, and wouldn't supply it anyway. It happens, and we figure things out as we need to.
Since I'm writing to you in the same good faith as you are, I would like to converse (somehow) about the general nature of quite a few of the tasks.
By all means! I appreciate the interaction. Before I continue reading, however, I'll note that every time I've
tried to place restriction on the tasks, I discover people find exceptions and ways that make the tasks I've written problematic in some fashion. Also, I'm trying to take an explanatory and speculative position, not an
apologist one; we've got all kinds of room for improvement, and I'm always looking for ways to get the site and
community functioning more comfortably and smoothly. (See my third role I noted above.)
Almost all of them assume an ASCII environment (which shouldn't automatically be assumed), and many many of the tasks are very loosely written and can be interpreted in too many (wrong) ways.
Understood. It's very difficult to write a task description that speaks to the intent of what the task writer
wants to expose and explore in the code examples. For tasks I've written, I've found that most hit one of three failure cases:
1) Solutions solve the exact letter of the task without hitting the concept I wanted to explore. 2) Solutions aren't written because the letter of the task makes incorrect assumptions unnecessary to the concept
I wanted to explore.
3) Solutions aren't written because the task is too vague, and people don't know what to do.
The sequence I've observed to work the best, as far as creation of successful tasks:
1) Someone creates a task, and uses
instead of
You are encouraged to solve this task according to the task description, using any language you may know.
, to invite people to critique it and add
some trial solutions.
2) As people add trial solutions, they'll hit on bugs in the spec 3) The 'talk' page for the task, and folks get together (usually) in good faith to figure out the best way to describe the task to meet the original writer's desires. 4) The task is refined, and we jump back to step 2.
5) Eventually people don't see a need to refine the task farther, and the task gets switched from
to
You are encouraged to solve this task according to the task description, using any language you may know.
. If I have time, I'll throw a note out to RC's Twitter and Facebook pages announcing the new task. Sometimes step 1 is skipped, and the author uses
You are encouraged to solve this task according to the task description, using any language you may know.
instead of
. When that happens, steps 2
and onward still occur; it just gets a little rougher.
Because of this, lots of examples are wrong (but I surely don't want to throw a monkey wrench in the works, and slight someone's code, just because the problem (task) wasn't stated clearly or even, correctly.
Understood completely. Not all of the tasks are well-written. Not all of the examples are well-written.
We have some templates (we call them ENA templates, short for 'examples needing attention') that allow people to
mark code examples as erroneous or faulty in some fashion. When those templates are used correctly, they examples in question get listed on that language's "Unimplemented in X" page under "examples needing attention".
The templates we have aren't necessarily ideal in their coverage and description. That's another work-in- progress, of course.
While writing this email, though, I had an idea for a flag which could be used to handle potentially incorrect
code without necessarily carrying a connotation that could be insulting to the original code's author. I'll have to give that some more thought.
A petty case in point, The Amb task. The wording suggests the Amb operator takes some number of expressions, and the task is to give an example. Quite a few programs assume exactly (only) four sets of words, while the intent (I believe) is to code a general Amb operator that works on SOME (should say ANY) number of expressions. A small but profound difference in the wording.
The task also assumes that there is only one answer, while in fact, the general case may have no or many answers. The task stated to find THE answer, and didn't say anything about the posibility of showing other answers (if there were any). ... And so it goes. It didn't mention if "the" would match up to "Einstein" for example (caseless compariosns), or what to do about punctuation (the obvious thing to do would be to ignore 'em). Yes, yes, I know, there weren't any of those pesky critters...
I'd encourage you to bring this up on the talk page. It's possible we can deprecate the task and offer a better
one. Or correct the existing one. When that task was created, I tried (and failed) to understand what Amb was about. I'm not that high in math...I've only got an associate's degree, and only got as far as Calc 2. I suspect most of what I know about math (beyond Calc 2, anyway), I've absorbed from watching Rosetta Code's community provide readable implementations of Wikipedia pages.
There are so many of these types of loosy-goosy type of definitions/rules that caused quite a few examples to not fulfill the requirements, at least, not the intent, and since I haven't got a dog in the fight, I feel better if I wouldn't throw stones (as least, not in a public forum). Hardly anything comes of those fights/discussions, as some people have quite a bit of emotion vested in the status quo or already-posted solutions.
And that's two parts of what I try to be there for. One, to see problems with the status quo and work toward
fixing them. RC doesn't do anyone any good if it gets stale and crusty, internally or out. Two, to try to keep the Rosetta Code wiki community genial and inclusive--we're very domain-focused, Rosetta code is a sort of tower of Babel, and there aren't very many people with the skill and interest needed to put the kinds of content on the site that it can potentially absorb. It can't afford to be hostile, as a community. Community management is, again, one of my two fundamental roles on the site.
I have plenty of other bliss projects that I'm working on at the moment. Bliss projects are those that give joy ...
Understood. Rosetta Code is something of a bliss project for me; I get a warm fuzzy every time I find that it
contributed some way to the improvement of a language, and every time I find people enjoy using it to improve their own skills and understanding. It makes me feel like I'm contributing to the field somehow.
Since this is Christmas time, I would just wish for some simple, clear, and consise difinitions (rules) of the tasks.
We do what we can. Perhaps some point soon we can come up with some good guidelines for how to build tasks, and
can go back and verify tasks against those guidelines.
That, and world peace. .... and enough money to pay for the heat ... but I digress.
I got lucky on that last; dress warm and keep the computers running. :)
As the old saw goes, be careful of what you ask. Anywhoooose.... If I included a "fix this example" thingy in every case like that, well, it would be pitchforks and torches time --- and I don't want my castle burned down..
Understood.
I've worked in programming for quite a few decades, and the number of times I've seen a correctly stated requirement (task) can be counted on one hand. Oooooooh, if you had a few more hours of reading time...
You might find a GraphJam I created yesterday to be amusing:
http://cheezburger.com/shortcircuit6453/lolz/View/4236897280
I wish a lot of the tasks wouldn't be so ego-centric. That is a problem that should be address, in my humble opinion. Well, maybe next Christmas then ...
| Thanks for all your contributions on the site!Yuppers, I'll continue for a few more examples, unless it becomes a royal pain in the neck-hole to continue. So far, the stuff that I've coded is mostly Micky Mouse stuff. I'm doing the simple ones that I can bang out in a few minutes. I spend quite a bit of time
re-working the example to properly present the data (to wit, reading the dataonce, finding the "widest" value,
and then making the output in a neat columnar format for instance. Another is adding commas for the human bean's eyeballs.
The language that I'm using is REXX, and it doesn't have any of the common trigonometric, geometric,
statistical, and other higher math functions at all, so I have to write them. That's not a problem, but
when I want to show a simple solution to something, I have to drag all that other baggage along, and that
makes some examples a bit ... well, verbose, and hides (if not completely overshadowing) the intent behind
the example. "C" kinda has the same problem, but it hides it with the INCLUDE statement, so people
don't see the baggage, but it's there, of course. One problem with REXX (as it's an interpreted
language), everything is out in the open and you can't hide the dirty linen and soiled clothes.
Later, 'gator.
Gerard Schildberger
Do you mind if I post this email on the wiki in your Talk namespace? It'd be handy for clarifying things (I think
a few people are annoyed with you), and (on reading it) it should help set a calming tone. It's also the first
chance I've had in a while for distilling into words my presence on the site. ;)
--
- wq</lang>
(I got permission to post the reply.) --Michael Mol 04:11, 8 December 2010 (UTC)