{"action":"opened","issue":{"url":"https://api.github.com/repos/exercism/xhaskell/issues/181","repository_url":"https://api.github.com/repos/exercism/xhaskell","labels_url":"https://api.github.com/repos/exercism/xhaskell/issues/181/labels{/name}","comments_url":"https://api.github.com/repos/exercism/xhaskell/issues/181/comments","events_url":"https://api.github.com/repos/exercism/xhaskell/issues/181/events","html_url":"https://github.com/exercism/xhaskell/issues/181","id":163611772,"number":181,"title":"discussion: Should we provide stubs with the exercises?","user":{"login":"rbasso","id":16487165,"avatar_url":"https://avatars.githubusercontent.com/u/16487165?v=3","gravatar_id":"","url":"https://api.github.com/users/rbasso","html_url":"https://github.com/rbasso","followers_url":"https://api.github.com/users/rbasso/followers","following_url":"https://api.github.com/users/rbasso/following{/other_user}","gists_url":"https://api.github.com/users/rbasso/gists{/gist_id}","starred_url":"https://api.github.com/users/rbasso/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rbasso/subscriptions","organizations_url":"https://api.github.com/users/rbasso/orgs","repos_url":"https://api.github.com/users/rbasso/repos","events_url":"https://api.github.com/users/rbasso/events{/privacy}","received_events_url":"https://api.github.com/users/rbasso/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/exercism/xhaskell/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-07-04T06:36:46Z","updated_at":"2016-07-04T06:36:46Z","closed_at":null,"body":"We can provide exercises with a stub solution, like this one:\r\n\r\n```haskell\r\nmodule LeapYear (isLeapYear) where\r\n\r\nisLeapYear :: Integer -> Bool\r\nisLeapYear year = undefined\r\n```\r\n\r\nI believe we could make the Haskell track more enjoyable and accessible for beginners adding stubs to all exercises. This could save users from inspecting the test suites to figure out what they need to implement.\r\n\r\nI see two possible objections to this:\r\n\r\n1. Figuring out what is the exercise is part of the exercise\r\n2. Some tests that currently allow polymorphic solutions would have to be restricted\r\n\r\nAbout **1**, I think it is too difficult for beginners, and it gets easy and boring after a while. As an example, look at our first test suite:\r\n\r\n```haskell\r\n{-# OPTIONS_GHC -fno-warn-type-defaults #-}\r\n\r\nimport Control.Monad (unless)\r\nimport System.Exit   (exitFailure)\r\n\r\nimport Test.HUnit\r\n    ( (~:)\r\n    , (~=?)\r\n    , Counts (failures, errors)\r\n    , Test   (TestList)\r\n    , runTestTT\r\n    )\r\n\r\nimport LeapYear (isLeapYear)\r\n\r\nmain :: IO ()\r\nmain = do\r\n         counts <- runTestTT isLeapYearTests\r\n         unless (failures counts == 0 && errors counts == 0) exitFailure\r\n\r\nisLeapYearTests :: Test\r\nisLeapYearTests = TestList $ map test cases\r\n  where\r\n    test (label, year, expected) = label ~: isLeapYear year ~=? expected\r\n    cases = [ (\"leap year\"                  , 1996, True )\r\n            , (\"standard and odd year\"      , 1997, False)\r\n            , (\"standard even year\"         , 1998, False)\r\n            , (\"standard nineteenth century\", 1900, False)\r\n            , (\"standard eighteenth century\", 1800, False)\r\n            , (\"leap twenty fourth century\" , 2400, True )\r\n            , (\"leap y2k\"                   , 2000, True ) ]\r\n ```\r\n\r\nThere is no single mention of the argument type of `isLeapYear`. Is it *Int*, *Integer* or any *Integral*? Should I choose? Which one is better?\r\n\r\nI don't see what people are learning reading tests like this, specially after repeating it 70 times.\r\n\r\nThe problem with **2** is that, by allowing a \"polymorphic solution/library\", we end up writing unidiomatic tests, and we expose users to bad coding practices. We should allow freedom on how to implement a solution, but the interface is what defines a problem, and the problem should be well defined and clearly stated.\r\nAlso, in real life, we don't usually try to write a library to fit already written tests without any type annotations.\r\n\r\nIn #143 we met some problems related to this flexible approach. At the time It sounded like a good idea to allow it, now I believe it's undesirable from a pedagogical point of view.\r\n\r\nCurrently, only those exercises have stub solutions:\r\n\r\n- all-your-base\r\n- forth\r\n- lens-person\r\n- list-ops\r\n- rna-transcription\r\n- zipper\r\n\r\nFor the first exercises, we have more than 800 visible solutions, but that drops rapidly to 10 solutions in the later ones. Maybe we can get people to go a little further giving a little help with stub solutions! :smile: \r\n\r\nShould we add stubs for other exercises?"}}
{"actor":{"display_login":"rbasso"}}