Rosetta Code:Village Pump/Uses Algorithm Template: Difference between revisions

Abstracted tasks and resolving complains on multiple axes.
(further thoughts)
(Abstracted tasks and resolving complains on multiple axes.)
Line 17:
 
:: Clearly, when an algorithm is specified the reason the task writer wanted to write that task was to see how that algorithm would be implemented. However, the point here is that such tasks may lacky utility outside of that rosetta code task page, and they may offer little insight as well. Obviously, few people would use ethiopian multiplication when most (but not all) languages implement multiplication already. However, it might be less obvious that a linked list implementation has little utility in some languages when in other languages the implementation might be useful and in other languages the facility is fundamental to an understanding of the language itself -- here the implementation does something useful (it lets the programmer work with a collection of items) but the specification can sometimes get in the way of that usefulness. But perhaps instead of a template, these tasks could be arranged hierarchically -- each "requires algorithm" or "unidiomatic" task could be required to have a parent task which asks to solve the problem without any restrictions on the algorithm. In other words, we might have a general Sort task and then underneath it would be filed all the various sort algorithm tasks. Or, we might have a simple "multiplication" task (which would mostly distinguish between infix, prefix and postfix and esoteric languages) and Ethiopian Multiplication would be filed underneath it. Or does this idea have flaws or introduce future issues? --[[User:Rdm|Rdm]] 15:29, 22 June 2010 (UTC)
:: Yes, but the example problem specified to be solved by the algorithm can be abstracted into a more general task. (In Ethiopian Multiplication, the more general task would be to multiply two integers. Trivial in most languages, but so are the control flow tasks. In the case of linked lists, the more generalized form might be a mutable sequence/container.) I don't see a problem with that. It also allows languages to note on one page that, no, ''this isn't the way you should do it'', and then ''point'' to a more appropriate solution for some part of the problem. That's a recurring gripe I've seen on this wiki and elsewhere about some of the poor-fit-but-not-impossible lang/task intersections. I've also seen people question whether or not the more-idiomatic-but-not-task-conformative examples as being on the task pages. This gives those examples somewhere more appropriate to go. --[[User:Short Circuit|Michael Mol]] 15:50, 22 June 2010 (UTC)