Rosetta Code talk:Solve a Task

Alternative Solutions

Is there a proper method for adding alternative solutions for a particular language for alreadys-solved tasks? Binki (talk) 15:23, 9 January 2014 (UTC)

No "proper" method, but I usually only consider adding another solution if it is sufficiently different from what is there. This could be using a different algorithm (if the task allows), or a different style of programming if your language allows say functional and OO styles and the two forms of solution look sufficiently different. We try not to have another example in the same language just because someone else has managed to solve the task, and you really need to ask if you could improve an existing solution first. Looking at most tasks examples, hardly any have multiple solutions in the same language. --Paddy3118 (talk) 16:25, 9 January 2014 (UTC)

Occasionally, I'll write two solutions. Not very often though, and then only usually when there's really two different ways to go about it. Most tasks don't have that many options, given that I always strive to be idiomatic in my solutions too; they've got to be how I'd want others to solve them. Where a task has two or more idiomatic solutions, it's usually because the language draws more distinctions than the task author thought of. –Donal Fellows (talk) 19:38, 9 January 2014 (UTC)

On a few occasions, when I enter a programming solution (version 1 would be strictly for the task's requirements), and then I may add a 2^nd solution that does more (than asked for beyond the extra credit), but that version of the programming code may be a bit cluttered in supporting/providing the auxiliary/supplemental information, that clutter causing the hiding or obscuring or otherwise obfuscating the original intent of the 1^st programming version (solution).   The language that I use (REXX) is more verbose than most languages as it only has one type of data (a character string), and more program statements are usually needed to accomplish any given task, and I try to supply comments to almost all statements.   As a result of all that, the program can get quite bulky quickly, and the bulkier the program, the harder to read (in general), unless one takes care in keeping the comments neatly separated from the program proper by using a healthy amount of whitespace, proper (and sometimes consistent) indentation(s), and other good health habits.   REXX seldom wins in a code golf game.   Now, if someone were to rank Rosetta Code programming languages by the percentage of statements that included comments, that would be mighty interesting.   But that's like saying that I have one of the better displays of button-hook collections, but the field of competition would be narrow indeed. -- Gerard Schildberger (talk) 05:40, 13 January 2014 (UTC)