Rosetta Code:Village Pump/SMW Examples by language and concept: Difference between revisions
Rosetta Code:Village Pump/SMW Examples by language and concept (view source)
Revision as of 20:56, 7 October 2015
, 8 years agolist monads vs list comprehensions vs nested iteration
(Need to keep the concept and language together.) |
(list monads vs list comprehensions vs nested iteration) |
||
| (5 intermediate revisions by 3 users not shown) | |||
Line 4:
}}
The basic idea: Tag examples in a way that says "{{{TASK}}} has an example which demonstrates {{{PROGRAMMING CONCEPT}}} in {{{LANGUAGE}}}". {{{PROGRAMMING CONCEPT}}} would be something like "memoization", "for loops", "array math", "network communication", etc.
The goal: To give new users a place to find "examples of {{{PROGRAMMING CONCEPT}}} in {{{LANGUAGE}}}". If we have a task specifically for that concept, examples may not be detailed (shallow requirements to allow for many languages) or "real world" (most examples will be academic by nature) enough. The concept may be basically specific to that language. It may have a different name in the language community (like "include", "import", "use", etc.). This setup would give the opportunity for people to see many different uses of a concept in a language to gain a better understanding of how to use it in that language or in their situation (rather than in programming in general). It would also allow users to search for a concept more easily without having to set up redirects or have a long discussion about the most "general" terminology for it. It may also help us organize tasks by having an underlying "tagging" system that shows how tasks may be grouped together by the concepts that they invoke.
I'll lay out my plan here. Please add comments to the sections they relate to.
Line 30 ⟶ 32:
{{demonstration of|polymorphism|Java}}</pre>
:::::That would give the task C and Java for the language property (whichever it ends up being) and "for loops" and "plymorphism" for the concept property. Connecting the concept and language properties makes it look like the task shows polymorphism in C and for loops in Java, but that's not how they were meant to be tagged. For that to be the intent, the intent of this system would have to be "{{{TASK}}} demonstrates {{{PROGRAMMING CONCEPT}}} and has examples in {{{LANGUAGE}}}". I want to make sure the concept stays with the language. --[[User:Mwn3d|Mwn3d]] 16:15, 29 June 2011 (UTC)
:::::: Did you to say ''polymorphism'' instead of ''plymorphism''? -- [[User:Gerard Schildberger|Gerard Schildberger]] 17:52, 2 September 2012 (UTC)
::*This of course is dependent on dicussions about the property organization
:*This template should go under each language header as the examples get tagged, and it would not display anything. We would need one template for each concept (a la {{tmpl|works with}}).
Line 38 ⟶ 43:
:*Links on property pages won't go directly to examples, but rather the top of the task pages
::*People complain about this every once in a while. I don't know how to fix it. Someone may have to JavaScript that for us (please!).
===Just make a start with a manual page – a few issues and lists of tasks===
Tagging is attractive but ambitious – how about a simpler start: a page with a few issue headers, and some links to particular tasks beneath each issue.
I think this (perhaps evolving towards tagging) would solve a structural problem which continues to create a pressure towards creating tasks of rather doubtful quality which:
# Are relevant to a limited number of languages,
# miss the potential for comparing quite different approaches to the same problems,
# and overemphasize indexing on notation, making it harder to find things by deeper and more pragmatic issues.
'''Problem''' ?
:The core Rosetta principle is '''task focus''', which yields more insight, but there is also an interest in looking up notational issues.
:The result is 'tasks' and task proposals which raise the eyebrows of some, and are stoutly defended by others. Things like:
:* 'Loops/do-While' (rather than conditional repetition)
:* 'List Comprehensions' (rather than building sets)
:* Run-time type detection (rather than pattern-matching or type conditional evaluation etc)
'''Solution''' ?
: Protect '''task focus''' (and the breadth of language relevance, depth of insight, and usefulness to learners which it brings) by separating out the perfectly legitimate (but quite distinct) interest in '''notational comparisons within particular language families'''
:The way to do that is clearly by gradually building some kind of alternative indexing or an additional Table of Contents, or even a full-blown tagging system, to reduce the pressure toward notationally preoccupied and narrowly conceived pseudo-tasks.
'''Possible headers''' ?
:Others may have a very different shopping list. The first things that come to my mind might be:
:* Repetition – ''fold'' and ''reduce'' vs loops
:* Set building – list monads vs list comprehensions vs nested iteration
:* Type-conditional evaluation – pattern matching vs run-time type detection
:etc [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 20:03, 7 October 2015 (UTC)
| |||