Rosetta Code:Village Pump/Dialects
This is a particular discussion thread among many which consider Rosetta Code.
Summary
What are, or should be, the Rosetta Code conventions for dialects of programming languages - implementations on specific platforms that may have minor differences of syntax and functionality from the official distributions?
Discussion
I would rather have different dialects not count as language of their own. Otherwise we have many main languages, which are similar in many ways, and many more items to show the code for. The navigation gets cluttered up and language lists would need to be structured in a hierarchy. This is already a problem with ZX80 Basic and C64 Basic and maybe more variants.
I propose
- have an entry page for the dialect which redirects to the main language
- allow different, dialect specific implementations of the same problem on the page of the "main" language.
Codecop 13:33, 28 January 2012 (UTC)
- My general position has been to leave the distinction to the language community. To a C++ programmer, all BASIC implementations might look alike, but to people with production code in QuickBasic, that's a nonsensical position. --Michael Mol 14:44, 28 January 2012 (UTC)
- I tend to agree, it will be very specific to the language and community. Guidance and suggestions are probably welcome and this would be a good anchor page, but I would not want to weigh in on any of the languages mentioned above. --Dgamey 14:51, 28 January 2012 (UTC)
Examples
Icon and Unicon
Hi, I did a lot of the work on Icon and Unicon which are closely related. Much of what I went through is discussed on the talk pages for Category_talk:Unicon. What you are proposing isn't far from what I did. Here's a summary, you can also see how it looks (there's over 450 examples on RC):
- Each distinct variant gets it's own page/category. If there are minor variants, it may make sense to put them in a section of the major variant's page.
- In tasks, I have one header with both major variant names in a single header line. Both Icon/Unicon were used because of recognition and to prevent orphaned headings (This may become more problematic as there is also a Jcon and ObjectIcon). Orphaned headings and duplicate efforts is a big problem if you have more than a few contributors. I found that having a combined header that sorts early worked best.
- Under the task heading there is a structure that allows different solutions where there are differences. However, where the differences are very minor I usually rely upon description text.
I tried a couple of kicks at it and found this approach practical (not necessarily perfect). It may or may not work with others. Hope this helps.
--Dgamey 14:42, 28 January 2012 (UTC)