Hangman QOL-improvements list

[WouterVrielink]

• Specificatie is op sommige punten niet super duidelijk. Verdient een goede scan
  • In de voorbeelden onder "Background" staan streepjes (-) ipv lage streepjes (_). Hier gaat ook wat fout in de één na laatste alinea, waar het voorbeeldpatroon ---- is, terwijl dat -OO- moet zijn.
  • Op een of andere manier realiseren studenten niet altijd dat er meer opties "word families" zijn dan "woord bevat letter" en "woord bevat letter niet".
  • Bij Specification 5.6. staat "pick a word": moet je de eerste pakken zoals eerder aangegeven of moet dit random zijn?
  • Specification 4: (and grading!), maar we doen hier niets mee bij grading
  • Spec. 7: opnieuw spelen lijkt me onnodig.
  • In de tekst staat associative array, terwijl studenten dit kennen als een dictionary. Uitleg erbij, of vervangen
  • Explicieter maken dat het grootste (if not all) van de algoritmiek in guess moet zitten. De rest van de functies doet eigenlijk vrij weinig verder. Misschien guess ook meer opdelen in subtasks?
  • Het is niet helemaal duidelijk wat de rol is van iedere functie in het grote geheel. Waarschijnlijk is het beter om de interface te geven of volledig te schrappen. Bij geven wordt de intentie van een aantal van de functies ook direct duidelijker. Volgens mij is het ook niet nodig al deze functies te behouden. Finished én win én lost is best dubbel.
• Studenten begrijpen niet goed wat if __name__ = "__main__" doet
• Aan de ene kant moet je reprompten, en aan de andere kant moet je exceptions gooien. Voor studenten is het vaak niet duidelijk welk van de twee waar moet gebeuren. (haakt in op vorige punt)
• In beschrijving staat overal she/her. Kan ook ambigu blijven.
• Veel mensen doen cards niet (of niet gefoccused). Weten hierdoor niet goed hoe ze losse functies moeten testen. Idealiter komt er een filmpje over de python interpreter. Daarnaast kan er een check50 komen en cards dan pass/fail maken.
• Lexicon class wordt nu opgevraagd in Hangman. Niet duidelijk en niet conform standaard OOP. Duidelijker zou zijn als je words meegeeft aan de __init__. Dan kan Lexicon ook direct een variabele meekrijgen waar je de filepath meegeeft.
• Datastructuren zijn niet echt in het oog, daardoor gaan sommige studenten aan de slag met lijsten ipv de bedoelde dictionaries.

[mjdv]

Ik ben hier nu voorzichtig naar aan het kijken (in mjdv/hangman): een paar vragen/opmerkingen.

Bij Specification 5.6. staat "pick a word": moet je de eerste pakken zoals eerder aangegeven of moet dit random zijn?

Waar staat aangegeven dat je de eerste moet pakken? Ik zie alleen maar suggesties om één van de mogelijke woorden te pakken, zonder specificatie welke het is.

Specification 4: (and grading!), maar we doen hier niets mee bij grading

De intentie was: de nakijkers runnen het programma ook even kort, en testen of de interface iets zinnigs doet. Als we uiteindelijk toch alleen op de check50 checks af gaan heeft het voor de studenten geen nut om dat deel van de opdracht ook te doen, dus dan kunnen we het er beter uit halen, lijkt me.

Waarschijnlijk is het beter om de interface te geven of volledig te schrappen.

Dat is misschien handig, zeker als de opdracht (evil hangman) als te groot/ingewikkeld ervaren wordt. Maar dit is wel een redelijke grote ingreep, dus dan kijk ik toch ook even naar @stgm en/of @Jelleas: lijkt het jullie ook een goed idee? Dit loopt ook samen met...

Aan de ene kant moet je reprompten, en aan de andere kant moet je exceptions gooien. Voor studenten is het vaak niet duidelijk welk van de twee waar moet gebeuren. (haakt in op vorige punt)

De intentie was: de Hangman class gooit exceptions, en de interface code vangt die (met try/catch) op. Als we de interface geven, wordt het (hopelijk) vanzelf duidelijk hoe die exceptions werken.

In beschrijving staat overal she/her. Kan ook ambigu blijven.

Dit is mijn gewoonte, overgenomen uit speltheorieliteratuur die ik gelezen heb. Ik denk dat de tekst van de opgave clunky wordt zonder voornaamwoorden: dus dan zijn de keuzes she, he, of enkelvoudig they. (Of een mengeling.)

Niet duidelijk en niet conform standaard OOP.

Bedoel je dat het beter zou zijn als de Hangman class initializer een Lexicon-object als argument neemt? Ik zie de woordenlijst eerder als een soort back-end dingetje (juist weg-geabstraheerd voor de gebruiker), en de Lexicon class als de manier waarop de Hangman class met die 'back-end' interfacet. (Natuurlijk is dit sowieso krom, want in het echt zou je van iets als Lexicon geen hele class maken.)

[stgm]

@WouterVrielink is nog een week op vakantie!

Ik zou ondertussen gewoon verder gaan. Heb ook wel wat input op bovenstaande, dat helpt wellicht ;-) Ik spreek daarbij vooral over de classic (voorheen lovely)-versie.

• Het geven van de interface is een mogelijkheid. Om goed te kunnen beslissen hebben we een up-to-date uitwerking van de opdracht nodig (met alle andere aanpassingen verwerkt). Kun je die maken?
• Voor zover ik me correct herinner hebben we exceptions al uit de opdracht verwijderd. Alleen nog assertions aanwezig. Kijk maar even wat de consequenties zijn.
• She/her is prima.
• Hangman die een instantie van Lexicon maakt lijkt me geen probleem, als dat idd is wat Wouter bedoelt.

[WouterVrielink]

Ha @mjdv! Dit heb ik al een tijdje terug geschreven dus ik weet zelf ook niet helemaal meer wat ik bedoelde overal... Ik geloof dat een deel van de problemen al opgelost was in eerdere (kleine) aanpassingen.

Waar staat aangegeven dat je de eerste moet pakken? Ik zie alleen maar suggesties om één van de mogelijke woorden te pakken, zonder specificatie welke het is.

Ik kan dit niet terug vinden. Wel zie ik bij "classic" dat er staat If the player has run out of guesses, pick a word from the word list and display it as the word that the computer initially "chose." Ik denk dat dit een artefactje is van de evil versie van het algoritme, want je verandert niet van gekozen woord. Mogelijk bedoelde ik dit.

Ik denk inderdaad dat het net is om die exceptions af te vangen op die manier. Dat geeft direct een goed idee van hoe je dit soort dingen "in het echt" kan gebruiken. Ik heb destijds bij vrij weinig studenten een try/catch gezien, en bij heel veel mensen een kopie van de check zoals hij in de class ook al staat. Als we de interface niet geven moeten we de nadruk dus wel op try/catch leggen.

Bedoel je dat het beter zou zijn als de Hangman class initializer een Lexicon-object als argument neemt? Ik zie de woordenlijst eerder als een soort back-end dingetje (juist weg-geabstraheerd voor de gebruiker), en de Lexicon class als de manier waarop de Hangman class met die 'back-end' interfacet. (Natuurlijk is dit sowieso krom, want in het echt zou je van iets als Lexicon geen hele class maken.)

Ja dat bedoel ik inderdaad. Op die manier hoef je bij een herhaling van het spel niet helemaal opnieuw Lexicon in te lezen. Ik denk dat het een best representatieve manier is van hoe je het in het echt zou doen. Ik vind het zelfs een heel goed instapvoorbeeld voor dingen waar je van een datastructuur een class zou willen maken om zoals jij ook zegt weg te abstraheren voor de gebruiker. Normaal zou je wel iets doen waarin je als het ware meer woorden aan je lexicon zou kunnen toevoegen, via een import_words_from_file() oid (waardeloze naamgeving dit). Voor nu lijkt het me prima als de init van Lexicon een filename aanneemt waaruit alles ingeladen wordt. De Hangman init neemt dan een Lexicon object aan. Eventueel kan je dan ook testen met een kleinere versie van een woordenlijst :)