Talk:Type detection: Difference between revisions
Content added Content deleted
Line 21: | Line 21: | ||
:I agree – that seems sensible, unless they can give a proper account of themselves [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 15:17, 8 October 2015 (UTC) |
:I agree – that seems sensible, unless they can give a proper account of themselves [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 15:17, 8 October 2015 (UTC) |
||
==Could the draft description be coaxed into something useful== |
|||
As Craigd has taken the trouble to start thinking about a task description, perhaps we should try to see if a spark of spam can indeed be coaxed into life as a useful task ? |
|||
Using a quick checklist of Rosetta values (copied from from the landing-page formulation), a good task with |
|||
:1. Lend itself well to solutions to in '''as many different languages as possible''' |
|||
:2. demonstrate how languages are '''similar and different''' |
|||
:3. aid a person with a '''grounding in one approach to a problem in learning another''' |
|||
Good scope for alternative approaches and the maximum number of languages is best served by the principle of [[Rosetta_Code:Add_a_Task#Task_focus|Task focus]], which is specified on the ''Add a Task'' page. |
|||
Broadly, tasks from the world outside computer languages, which make no assumptions about particular models of computing, yield better insight and deeper comparisons. The value of the Rosetta stone was that 3 very different languages were dealing with the same external (non-linguistic) task. |
|||
Given that, the text processing context sounds promising, and should probably be more focal than a framing like "Show a function/procedure which … ''. Perhaps for example, (thinking about Goal 1 above) that is not quite how a declarative language would be used. Better to make no assumptions about language-internal issues, and to frame the task itself. |
|||
On Goals 2 and 3 (demonstrate how languages are similar and different, & learning another approach) you would need to allow for the differences such as, for example, that between run-time "Type detection" and compiler-driven pattern-matching. Framing it too tightly in terms of "type detection" assumptions would marginalise some languages and miss the scope for comparing different approaches. |
|||
Finally on the learning aspect of Goal 3, it would clearly be good to find a task which learners are quite likely to actually encounter and think about |
|||
( It may also be worth looking at some existing tasks which already demonstrate type-conditional evaluation or flow – ''flattening lists'', for example – just to check that something more focused is really required ) [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 18:34, 9 October 2015 (UTC) |