DOT programmeren/problemen: verschil tussen versies

Uit Inf20
Naar navigatie springen Naar zoeken springen
 
(22 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 3: Regel 3:
== Problemen bij het leren en onderwijzen van programmeren ==
== Problemen bij het leren en onderwijzen van programmeren ==


In het programmeer-onderwijs moet je rekening houden met de verschillende problemen die leerlingen kunnen hebben. Dit zijn problemen van allerlei soorten:
=== Problemen van leerlingen ===


== "Karakter"-problemen ==
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.


* programmeren vereist doorzettingsvermogen: het lukt niet altijd de eerste keer, sommige concepten en opdrachten zijn gewoon lastig;
=== Vragen en problemen van docenten ===
* als je programmeert maak je fouten: daar moet je mee leren omgaan;
 
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]]"
** zie: http://philbagge.blogspot.co.uk/2015/02/eight-steps-to-promote-problem-solving.html


== Conceptuele problemen ==
== Conceptuele problemen ==
Regel 14: Regel 24:
* sommige concepten zijn lastig te begrijpen;  
* 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;
* 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 ==
== Andersoortige problemen ==
Regel 21: Regel 92:
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.
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.
: 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?).

Huidige versie van 29 okt 2015 om 16:19

DOT programmeren
  1. Problemen
  2. Beschikbaar materiaal
  3. Hulpmiddelen
  4. Keuzes en prioriteiten

Manier van werken

Zie ook Regels en richtlijnen
Zie ook Artikelen bewerken

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

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?).