I'm working on modernizing Rosetta Code's infrastructure. Starting with communications. Please accept this time-limited open invite to RC's Slack.. --Michael Mol (talk) 20:59, 30 May 2020 (UTC)

User:Mwn3d/Word mincing

From Rosetta Code

I've noticed a couple instances of people getting too technical. Maybe people are trying to be cute. Maybe they're trolling. Maybe they're just computer programmers and (like computers) they try to take everything literally. In any case, such rigidity gets in the way of lots of things, and I have decided to voice my opinions about some of the more prominent "arguments" as I notice them. The basic advice for these situations is usually "lighten up, Francis."

Function vs. Subroutine vs. Method vs. whatever term your language uses for it[edit]

For the purposes of tasks on this site, these words are all pretty much interchangeable. Getting all bent out of shape because a task says "function" and you want to do it in assembly or some language where you don't really have a nice way to return a value just gets in the way of things. Do the best you can and note the difference in behavior. If it goes against the intention of the task, then we will discuss it. In general it's probably OK not to match up exactly on little things like that.

Random vs. Pseudo-random[edit]

I don't think there is a language out there that has a true random number generator built in. When we say "random" in a task we probably mean "pseudo-random". That's just what people call it because saying "pseudo-random" is a mouthful. Unless the task is to create a pseudo-random number generator or receive truly random numbers from a true random number generator (random.org or something), these words are also interchangeable.

Print (in the console) vs. print (on paper) vs. print (on a window) vs. show vs. display[edit]

This is sort of like random/pseudo-random. In general, this means print to standard output (wherever that goes). In tasks which are about printers or GUIs it should be made obvious in the task description which one is required.

Also, it is very good practice to show example use and output from an example (where there is output to be shown). Some tasks (like Singly-linked list/Element definition) simply don't have output, so it doesn't need to be shown. Tasks which require calculation or generation of something should have output shown pretty much no matter what. If the output is long (in bytes, not necessarily number of lines), consider making a separate page for your example and linking to it from the task page (a la 99 Bottles of Beer/C++/Object Oriented and 99 Bottles of Beer#An object-oriented solution).

Run forever vs. hardware limits vs. "infinite"[edit]

These all basically mean "don't add any new mechanisms for stopping the program". Programs which "run forever" should just keep calculating and spitting out answers until some outside force (OS, hardware limits, cosmic radiation, a blackout, 2012, etc.) stops the program. There should be nothing added to the program that would make the user able to end it cleanly.


More to come as I see/remember similar situations.