DOT programmeren/problemen: verschil tussen versies
(5 tussenliggende versies door dezelfde gebruiker niet weergegeven) | |||
Regel 51: | Regel 51: | ||
* het proces van programmeren is grotendeels onzichtbaar: in de meeste gevallen zie je alleen het complete programma, je weet niet hoe de programmeur tot dat resultaat gekomen is. | * het proces van programmeren is grotendeels onzichtbaar: in de meeste gevallen zie je alleen het complete programma, je weet niet hoe de programmeur tot dat resultaat gekomen is. | ||
** mogelijk kunnen we gebruik maken van Test Driven Development als manier om het proces van programmeren zichtbaar te maken. | ** mogelijk kunnen we gebruik maken van Test Driven Development als manier om het proces van programmeren zichtbaar te maken. | ||
=== Het programmeerproces === | |||
Hoe kom je van een probleem naar een oplossing, in de vorm van een programma? Welke strategieën kun je daarbij hanteren? | |||
Hoe kun je dit proces zichtbaar maken - op een manier dat anderen ook kunnen zien hoe je dit aangepakt hebt? | |||
=== Rekenproces: uitvoering van een programma === | |||
== Ontwerpen == | |||
Het oplossen van een probleem door middel van een programma is een ontwerpprobeem. Je moet hierbij een brug slaan tussen de technologie: de programmeertaal, libraries, enz., en het probleem. Hiervoor moet je de technologie beheersen, en je moet strategieën hebben voor het aanpakken van een probleem. | |||
Je kunt dit probleem van twee kanten aanpakken: | |||
* je begint bij het probleem: dit heet ook wel top-down; | |||
* je begint bij de technologie: bottom-up. | |||
In de praktijk gebruik je een combinatie van deze twee. | |||
Ontwerpen is anders dan de meeste andere zaken die je op school leert: | |||
* je hebt niet altijd een eenduidige beschrijving van het probleem; die moet je vaak zelf maken; | |||
* bij een bepaald probleem zijn er vaak meerdere oplossingen mogelijk; | |||
* de eerste goede oplossing die je bedenkt hoeft niet de beste te zijn: je moet altijd kijken of er nog betere oplossingen mogelijk zijn. | |||
Voor het ontwerpen heb je heel veel andere vaardigheden nodig. Je werkt "aan de top van de hiërarchie van Bloom". Dit betekent dat je de lager liggende vaardigheden moet beheersen om op dit niveau goed werk te kunnen leveren. | |||
: Je moet bijvoorbeeld in staat zijn om je eigen oplossingen te analyseren: hoe goed zijn deze, welke eigenschappen kun je hiervan vaststellen - ook voordat je het ontwerp helemaal uitwerkt? | |||
=== Hoe gebruik je bepaalde programmeer-constructies? === | |||
Een eerste stap bij het leren programmeren is om de betekenis van de verschillende constructies te leren. Maar uiteindelijk wil je leren hoe je deze constructies gebruikt bij het oplossen van bepaalde programmeerproblemen. | |||
== Dosering en volgorde == | == Dosering en volgorde == | ||
Regel 68: | Regel 97: | ||
Omdat de verschillen tussen de leerlingen zo groot zijn, is het zeer wenselijk om leerlingen in hun eigen tempo te laten werken. Dit sluit ook aan bij de wens tot "Mastery based learning": een leerling gaat pas verder met een volgend concept, als hij het vorige begrepen heeft. (Sommige leerlingen gaan hierdoor sneller dan de rest, andere juist langzamer; dat zegt niets over het uiteindelijke niveau.) | Omdat de verschillen tussen de leerlingen zo groot zijn, is het zeer wenselijk om leerlingen in hun eigen tempo te laten werken. Dit sluit ook aan bij de wens tot "Mastery based learning": een leerling gaat pas verder met een volgend concept, als hij het vorige begrepen heeft. (Sommige leerlingen gaan hierdoor sneller dan de rest, andere juist langzamer; dat zegt niets over het uiteindelijke niveau.) | ||
==== " | ==== Onderwijs"probleem": becijferen ==== | ||
Omdat de verschillen tussen de leerlingen zo groot zijn, is het lastig om het werk van de leerlingen te becijferen. | In het onderwijs is het vaak nodig om cijfers uit te delen aan de leerlingen. Omdat de verschillen tussen de leerlingen zo groot zijn, is het lastig om het werk van de leerlingen te becijferen. | ||
Mogelijke niet-conventionele benaderingen: | Mogelijke niet-conventionele benaderingen: | ||
* Als je het leerproces goed zou kunnen monitoren, dan zou je de voortgang/groei kunnen becijferen, in plaats van het niveau op een bepaald moment. | * Als je het leerproces goed zou kunnen monitoren, dan zou je de voortgang/groei kunnen becijferen, in plaats van het niveau op een bepaald moment. | ||
* Als je met badges werkt, dan kun je een cijfer geven voor de behaalde badges (aantallen, niveau?). | * Als je met badges werkt, dan kun je een cijfer geven voor de behaalde badges (aantallen, niveau?). |
Huidige versie van 29 okt 2015 om 16:19
Problemen bij het leren en onderwijzen van programmeren
Problemen van leerlingen
In het programmeer-onderwijs moet je rekening houden met de verschillende problemen die leerlingen kunnen hebben. Dit zijn problemen van allerlei soorten: van begripsproblemen tot houding en gedrag.
Vragen en problemen van docenten
Daarnaast heb je als docent te maken met een aantal problemen en vragen:
- wat is een goede manier van doseren van de stof? (Hoeveel nieuwe concepten tegelijk, wanneer maak je een volgende stap?)
- hoe ga je om met de grote verschillen die er zijn tussen de leerlingen?
"Karakter"-problemen; houding en gedrag
- Programmeren vereist doorzettingsvermogen: het lukt niet altijd de eerste keer, sommige concepten en opdrachten zijn gewoon lastig;
- Als je programmeert maak je fouten: daar moet je mee leren omgaan;
- "Learned helplessness"
Conceptuele problemen
- sommige concepten zijn lastig te begrijpen;
- misconcepties: als je een concept verkeerd begrijpt, kan dit de toepassing en de volgende stappen in het leerproces blokkeren;
- volgorde: voor het begrijpen van een bepaald concept heb je andere concepten nodig; deze moet je dan wel eerst (goed) beheersen;
- dosering: als je teveel concepten tegelijk introduceert, dan vermindert dit het begrip van de afzonderlijke concepten.
Concepten die soms lastig zijn
- begrip variabele
- procedures (en functies): scope
- procedures (en functies): nesting
- procedures (en functies): recursie
- conversie tussen getallen en strings (waarom, hoe, wanneer?)
- basisconcept: representatie van getallen; gebruik van strings voor in- en uitvoer.
Redeneren over programma's en processen
- logische redeneringen; correctheidsargumenten;
- efficiëntie-redeneringen; complexiteit;
Foutzoeken (debugging)
Onzichtbare processen
Bij het programmeren heb je te maken met enkele processen die grotendeels onzichtbaar zijn:
- het proces dat bij een programma hoort is meestal onzichtbaar: je ziet alleen het programma, de invoer, en het resultaat.
- je kunt het aspecten van het proces zichtbaar maken in een log;
- dit blijft een conceptueel lastig probleem, omdat (i) computers zo ontzettend snel zijn; en (ii) je vaak wilt redeneren over alle mogelijke processen bij een programma, in plaats van over een concreet proces (voorbeeld).
- het proces van programmeren is grotendeels onzichtbaar: in de meeste gevallen zie je alleen het complete programma, je weet niet hoe de programmeur tot dat resultaat gekomen is.
- mogelijk kunnen we gebruik maken van Test Driven Development als manier om het proces van programmeren zichtbaar te maken.
Het programmeerproces
Hoe kom je van een probleem naar een oplossing, in de vorm van een programma? Welke strategieën kun je daarbij hanteren?
Hoe kun je dit proces zichtbaar maken - op een manier dat anderen ook kunnen zien hoe je dit aangepakt hebt?
Rekenproces: uitvoering van een programma
Ontwerpen
Het oplossen van een probleem door middel van een programma is een ontwerpprobeem. Je moet hierbij een brug slaan tussen de technologie: de programmeertaal, libraries, enz., en het probleem. Hiervoor moet je de technologie beheersen, en je moet strategieën hebben voor het aanpakken van een probleem.
Je kunt dit probleem van twee kanten aanpakken:
- je begint bij het probleem: dit heet ook wel top-down;
- je begint bij de technologie: bottom-up.
In de praktijk gebruik je een combinatie van deze twee.
Ontwerpen is anders dan de meeste andere zaken die je op school leert:
- je hebt niet altijd een eenduidige beschrijving van het probleem; die moet je vaak zelf maken;
- bij een bepaald probleem zijn er vaak meerdere oplossingen mogelijk;
- de eerste goede oplossing die je bedenkt hoeft niet de beste te zijn: je moet altijd kijken of er nog betere oplossingen mogelijk zijn.
Voor het ontwerpen heb je heel veel andere vaardigheden nodig. Je werkt "aan de top van de hiërarchie van Bloom". Dit betekent dat je de lager liggende vaardigheden moet beheersen om op dit niveau goed werk te kunnen leveren.
- Je moet bijvoorbeeld in staat zijn om je eigen oplossingen te analyseren: hoe goed zijn deze, welke eigenschappen kun je hiervan vaststellen - ook voordat je het ontwerp helemaal uitwerkt?
Hoe gebruik je bepaalde programmeer-constructies?
Een eerste stap bij het leren programmeren is om de betekenis van de verschillende constructies te leren. Maar uiteindelijk wil je leren hoe je deze constructies gebruikt bij het oplossen van bepaalde programmeerproblemen.
Dosering en volgorde
- hoe snel kan een leerling nieuwe onderwerpen verwerken? Welke dosering werkt goed?
- zie ook: Badass - verschillende soorten leercurves; minimaliseren van "learning in progress".
Andersoortige problemen
Grote verschillen tussen leerlingen
Bij het vak Informatica, en in het bijzonder bij het programmeren, zijn de verschillen tussen de leerlingen erg groot. Sommige leerlingen zijn hiermee bezig vanaf hun 6e of 7e, en besteden een belangrijk deel van hun vrije tijd hieraan. Voor andere leerlingen is het helemaal nieuw. Als docent moet je leren omgaan met deze grote verschillen. En je moet accepteren dat een leerling soms (veel) verder is dan jezelf.
- Net als bij muziek en sport zijn er leerlingen die op de leeftijd van 14 of 15 jaar een volwassen niveau bereikt hebben. Zij zijn voor sommige onderdelen op het niveau van enkele jaren vervolgopleiding, en hierin zijn ze soms beter dan hun docent. Bij muziek en sport is dat een bekend gegeven, en docenten (en leerlingen) kunnen hiermee omgaan.
Leerlingen laten werken in eigen tempo
Omdat de verschillen tussen de leerlingen zo groot zijn, is het zeer wenselijk om leerlingen in hun eigen tempo te laten werken. Dit sluit ook aan bij de wens tot "Mastery based learning": een leerling gaat pas verder met een volgend concept, als hij het vorige begrepen heeft. (Sommige leerlingen gaan hierdoor sneller dan de rest, andere juist langzamer; dat zegt niets over het uiteindelijke niveau.)
Onderwijs"probleem": becijferen
In het onderwijs is het vaak nodig om cijfers uit te delen aan de leerlingen. Omdat de verschillen tussen de leerlingen zo groot zijn, is het lastig om het werk van de leerlingen te becijferen.
Mogelijke niet-conventionele benaderingen:
- Als je het leerproces goed zou kunnen monitoren, dan zou je de voortgang/groei kunnen becijferen, in plaats van het niveau op een bepaald moment.
- Als je met badges werkt, dan kun je een cijfer geven voor de behaalde badges (aantallen, niveau?).