Rosetta Code:Village Pump/SMW Examples by language and concept

From Rosetta Code
SMW Examples by language and concept
This is a particular discussion thread among many which consider Rosetta Code.


Discussion and planning for using SMW to organize/tag examples by language and concepts demonstrated by that example


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.

How I think we should do it:

  • Property pages:
  • The property name I thought of was "Demonstration of"
  • The idea would be to have one of these properties for each language (i.e. "Demonstration of/Language name")
If I understand SMW, the more natural form would be a property of Property:Demonstration of, and applying the property would be of the form [[Demonstration of::Language name]]--Michael Mol 14:30, 29 June 2011 (UTC)
  • Ideally these pages would be automatically generated by a bot when a new language is created. Do we still have a bot that does that stuff?
No, ImplSearchBot died ages ago. I think it may be worthwhile to create a "implicit page content" extension for uncreated pages. Reduces database bloat from edits-over-time, and can still be overridden. Otherwise, we could create a MW extension that provides a page under the Special: namespace. --Michael Mol 14:30, 29 June 2011 (UTC)
  • Having it organized this way would show a list of tasks on that page and each task would have a list of programming concepts
  • There may be a way to organize it the other way ("concepts with task lists"), or still another way to have it organized as "tasks with concept lists" and then also have a semantic query to show "concepts with task lists"
Yup; that could easily be done with an in-line semantic query. SMW's analog to "select tasks and concepts where language is ?" --Michael Mol 14:30, 29 June 2011 (UTC)
  • Concepts would have their own pages explaining what they are, but that might not be necessary
  • Tagging template:
  • I was thinking the form would be {{demonstrates|concept|language}} which would tag the page with [[demonstration of/language::concept]]. It can be read as "this example demonstrates concept in language".
The more natural SMW form, I think, would have the page tag with [[demonstration of::language]][[shows concept::concept]]. (It may be desirable to use Property:Demonstrates language and Property:Demonstrates concept, rather than Property:Demonstration of; you can have languages and concepts (and many other things, such as implementations, libraries, etc) which share names, but you wouldn't want to confuse the engine into thinking one is the other. --Michael Mol 14:30, 29 June 2011 (UTC)
[[demonstration of::language]] seems redundant because we already have [[implemented in language::language]]. I really think it's best to keep it all in one tag and let the property pages do some of the work. If we do it with the two tags then we will have two property pages which don't mean what we want until they're connected on some other page with a query. If each language has its own property page then things are already wrapped up nicely. --Mwn3d 14:51, 29 June 2011 (UTC)
That's the purpose of semantic properties and queries, though, to be queried against to produce results dependent on data relationships. I'm guessing you meant [[demonstration of language::]] was redundant because we have [[implemented in language::]], and you would be right. This kind of thing is why I created [[implemented in language::]] in the first place. I also don't like each language having its own property page from the perspective that semantic properties are supposed to describe simple relationships, as opposed to describing complicated things. Defining a semantic query is pretty simple; SMW comes with Special:Ask to help you do it. They're also not significantly computationally expensive; we have three of them on the main page. I'd far prefer a solution derived from queries than additional autogenerated properties; that's why we got SMW and MultiCategorySearch in the first place. --Michael Mol 15:47, 29 June 2011 (UTC)
The problem is keeping the task tied to a concept and language pair. The way you're proposing it we could have a situation like this:
{{demonstration of|for loops|C}}
{{demonstration of|polymorphism|Java}}
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. --Mwn3d 16:15, 29 June 2011 (UTC)
Did you to say polymorphism instead of plymorphism? -- 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 {{works with}}).
It might be worthwhile to tag tasks with Property:Invokes concept, and examples with Property:Demonstrates concept or Property:Demonstrates concept workaround. Then, at some later date, we may be able to pull examples into their own pages, and use the same core example code as solutions for multiple tasks. --Michael Mol 14:30, 29 June 2011 (UTC)
  • Possible problems:
  • Non-standard concept names
  • I think we might just have to deal with this and correct tags as they come up
  • 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:

  1. Are relevant to a limited number of languages,
  2. miss the potential for comparing quite different approaches to the same problems,
  3. 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 Hout (talk) 20:03, 7 October 2015 (UTC)