Rosetta Code talk:Village Pump/Suggest a programming task: Difference between revisions
Content deleted Content added
Underscore (talk | contribs) |
→Task guidelines?: Moved |
||
Line 4: | Line 4: | ||
== Task guidelines? == |
== Task guidelines? == |
||
Moved to [[Village Pump:Home/Task creation process discussion]] |
|||
The new [[J]] and [[Python]] contributors are creating lots of new tasks in preference to solving existing tasks. Should we be providing guidance on the types of tasks suitable for Rosetta Code? Here are my ideas, feel free to contradict. |
|||
* Rosetta Code is about language ''comparison''. We should encourage solving existing tasks in preference to creating new tasks. |
|||
* We encourage contribution from the public in their free time. If we choose tasks that are too large or difficult, then we are likely to only get a few solutions. Tasks should be chosen which can be implemented succinctly in a variety of languages. |
|||
* Rosetta Code started mostly with trivial tasks designed to demonstrate language features. Do we want to retain that focus? Are there any feature areas we forgot? |
|||
* The more tasks we have, the more each individual task gets lost within [[:Category:Solutions by Programming Task]]. We can solve this either by adding structure (subcategories) or restricting the number of tasks (merging and rejecting). |
|||
* Duplication should be avoided. If two tasks are demonstrating the same language features, then one should be cut. |
|||
I think it would be fine to restrict our focus considering that there are [[Help:Similar Sites|other sites]], like Literate Programs, for showing off public code. --[[User:IanOsgood|IanOsgood]] 12:01, 24 December 2007 (MST) |
|||
Quite often the task descriptions are created with a particular set of languages (or a particular paradigm) in mind, and other languages may not map into it completely. I think it may be better to allow creation of new tasks, but filter/merge them where there is a redundancy to a more generic task at a later time. It is actually nicer to have a larger number of tasks because it allows new contributers a little more flexibility in choosing the tasks (but it becomes harder for languages to become complete). [[User:Rahul|Rahul]] 20:09, 7 October 2008 (UTC) |
|||
:I disagree. I don't think that particular languages are thought of when creating tasks. Maybe very general paradigms are thought of (like "object oriented" or "functional"), but mostly the focus is something that people do frequently or can learn a lot from. Merging isn't very easy if a lot of examples sprout up quickly, especially since merging is human enough that a bot can't do it well and--even when called upon--experts on a particular language don't frequently merge old examples and change them for the new task (see: [[String Length]] and [[Loop Structures]] vs [[Iteration]]). Having a large number of tasks is nice in some ways and not nice in others. It's nice because we can have good coverage of programming ideas, but not nice because they can get lost in the solutions category (even with the recent reorganization). I think we should continue to make sure that new tasks are unique, valuable, and possible in many languages. This can be helped by not encouraging a create then review and merge/delete sort of process.--[[User:Mwn3d|Mwn3d]] 20:33, 7 October 2008 (UTC) |
|||
:: Oh I meant stuff like [[Object_Serialization]] where the task is created with languages that support both objects and inheritance ~/a paradigm/. I am not saying it is done consciously, rather it is an observation. As a suggestion towards the cons of numerous related tasks, perhaps we can have a way to promote only really nice and generic tasks to the solutions page (or equivalent)?. I agree with your comment on merge of old examples but I think we do need a way to introduce more generic/useful/better tasks in a less painful way than to update the task description and force all implementations to change.[[User:Rahul|Rahul]] 21:57, 7 October 2008 (UTC) |
|||
:::We've got ''way'' too much structured code on RC. I need to create a task solvable only by goto.. ;-) |
|||
:::Rather than promoting pages to the Solutions By Task page, why don't we move them to a "Retired" subcategory? Sadly, though, this means we're going to need some sort of approval process. Gah. Procedures and rules. I move we continue this discussion at the Village Pump. --[[User:Short Circuit|Short Circuit]] 03:33, 11 October 2008 (UTC) |
|||
:::I think a better title for Object Serialization might be "Saving/loading program state" and an example that allows many types of language to provide examples. Whilst you might strive for program paradigm neutrality, I still think it would be useful to have tasks that are naturally trivial in some class of languages - say constraints, or bit manipulation. |
|||
:::Since we are comparing languages although the task description may describe an algorithm to use, if your language has a feature that is normally used you might be justified in using the built-in feature with an explanation as well as, or instead of, the algorithm asked for. For example, it would be a shame if someone reading the quicksort task went away thinking that it was THE way to sort in Python/Perl/Ruby etc.. --[[User:Paddy3118|Paddy3118]] 16:43, 11 October 2008 (UTC) |
|||
As I see it, three useful kinds of tasks are (and should be) on Rosetta Code: trivial examples for demonstrating discrete language features, practical examples of how to accomplish ordinary tasks, and more complex examples that show how a given language is used in practice to write nontrivial programs. That allows for a lot of different tasks. (The third category in particular covers everything from [[Roman Numerals]] to [[RCBF]].) But tasks that don't fit neatly into any of those categories probably don't belong here, and tasks that are too similar to be simultaneously useful should be deleted. —[[User:Underscore|Underscore]] 17:38, 13 October 2008 (UTC) |
Revision as of 17:45, 13 October 2008
Get moving on these
Can we get moving on some of these? --Short Circuit 23:00, 7 November 2007 (MST)