Ontwerpen van een programmeervak

Vandaag is de laatste dag van een periode van twee weken, waarin bij mij thuis een dakkapel is geplaatst. Het eindresultaat ziet er prima uit.
Collegadocent Thomas de Boer (bij het vak SAO) kwam van de week met een aardige metafoor m.b.t. ontwerpen: hij liet een aantal schetsen zien van een ontwerp van een nieuwe betegeling en aankleding van zijn plaatsje en vergeleek dat met het eindresultaat: duidelijk grote verschillen. Datzelfde geldt voor onze dakkapel: het eindresultaat wijkt op een aantal plaatsen duidelijk af van het oorspronkelijke ontwerp (overigens wel steeds binnen de grenzen van de goedgekeurde bouwaanvraag).
In beide gevallen is de belangrijke oorzaak dat in het oorspronkelijke ontwerp niet met alles rekening gehouden is en bovendien wensen veranderen en situaties ter plekke soms net iets anders zijn dan oorspronkelijk gedacht.
Kortom: hoe goed het ontwerp ook is, de uiteindelijke implementatie zal dit ontwerp naar alle waarschijnlijkheid nooit voor 100% volgen.

En dat brengt me op de titel van dit stukje: ontwerpen van een programmeervak. Samen met Thomas geef ik nu ook het vak inleiding programmeren voor o.a. TBK-studenten. Dit vak is dit jaar compleet nieuw ontworpen. Gekozen is voor een OO-aanpak omdat dat beter zou aansluiten bij de menselijke perceptie van dingen, samenstelling van dingen, eigenschappen van dingen enz. Een ding uit de werkelijkheid wordt een object in Java, zeg maar.
Toch is het uitleggen hoe je volgens het OO principe moet programmeren niet zo eenvoudig: leg bijvoorbeeld maar eens uit hoe de main-methode in Java functioneert!
Blijft verder ook de vraag over, hoe gedetailleerd moet je zaken vertellen. Nu zit in het vak een hoofdstuk over arrays. Na de uitleg hierover kwam bij mij de vraag naar boven of uitleg over arrays eigenlijk wel in dit vak nodig is. In plaats van arrays zijn Vectors, Lists en andere structuren eenvoudiger in gebruik. Ik overweeg dan ook volgend jaar het hoofdstuk over arrays te laten vervallen en direct iets over bijvoorbeeld Vectors te melden. Zo leren studenten dat (zeker in OO) zoveel mogelijk hergebruikt moet worden en gelukkig is er al veel in de Java bibliotheken te vinden.
En zo zijn er meer zaken in het oorspronkelijke ontwerp, die al tijdens uitvoering aanpassing vereisen. Zo is het veel studenten onduidelijk wat de betekenis is van this (de aanduiding van het object dat de betreffende methode ontvangt). Het begrip super is zo mogelijk nog onduidelijker.
Een constructor in een klasse is ook zoiets. Wat geef je nu wel en wat geef je niet mee in de parameterlijst van de constructor?
De ideeën voor aanpassing van het ontwerp voor komend jaar liggen al klaar (en zo moet het natuurlijk ook met onderwijs geven).

5 Comments on “Ontwerpen van een programmeervak

  1. Bekijk eens How to Design Programs, waarbij de schrijvers als doelstelling hebben dat mensen leren programmas te ontwerpen. Wellicht een bron van inspiratie?

    http://www.htdp.org/2003-09-26/Book/curriculum-Z-H-2.html

    Veel te vaak ontaarden programmeer vakken in technische details over hoe je in een bepaalde taal iets moet noteren. De syntax is vaak te beperkt en te ingewikkeld, waardoor het daadwerkelijk programmeren (ontwerpen van programmas) op de achtergrond wordt gedrukt.

    PS: Ooit eens naar Ruby gekeken?
    http://www.ruby-lang.org/en/
    http://poignantguide.net/ruby/

    PPS: Maak alstublieft even tijd om de mensen een reversie control system te leren gebruiken. RCS is essentieel voor programmeren. Subversion (client/server) en Darcs (distributed) zijn vrij goed op dit moment.

    http://subversion.tigris.org/
    http://darcs.net/

  2. Addendum:

    Class-based OO van Java is natuurlijk alleen een stap vooruit als men terug kijkt op talen zoals C en C++. Het is echter maar een kleine stap vooruit.

    “We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.” — Guy Steele, Java spec co-author

    De exacte definite van OO wordt zelfs erg beïnvloed door de programmeertaal waarin men denkt. — http://www.paulgraham.com/reesoo.html

  3. Gideon,

    Dank voor het meedenken….
    Laten we echter niet vergeten dat het hier een inleidend programmeercollege betreft voor niet-informatici.

  4. Daarom juist is Java waarschijnlijk overkill van de meeste studenten die zelf waarschijnlijk nooit een erg groot programma zullen hoeven schrijven.

    Een scripting taal zoals Ruby of Python zou waarschijnlijk voor de meesten eenvoudiger te leren zijn en meer dan genoeg voor hun doeleinden.

    Als snelheid (compileren) een noodzaak is dan zouden Lisp en Smalltalk in veel opzichten toegankelijker en sneller zijn dan Java.

    Vergelijk bijvoorbeeld het BioBike project van Stanford en hun overwegingen voor de keuze van Lisp: http://nostoc.stanford.edu/Docs/whylisp.html