Papers we love: Van excentrieke naar menselijke code

De paper van deze week zag ik in een tweet voorbij komen en ik dacht gelijk: deze paper moet ik  lezen. De titel, Studying the language and structure in non-programmers’ solutions to programming problems, is lang, de paper zelf valt mee. Centraal staan twee experimenten waarbij zowel kinderen als volwassenen worden geobserveerd bij het oplossen van problemen. Deze problemen worden zo abstract mogelijk beschreven, waarna van de deelnemers wordt verwacht dat ze op papier duiden hoe deze kunnen worden opgelost.

Het mooie is dat geen van de gemeten deelnemers ervaring heeft met programmeren. Hierdoor zijn ze dus niet (nog) gewend aan constructies van programmeertalen die wij inmiddels als vanzelfsprekend beschouwen. Dat is interessant, omdat de manier waarop (software) engineers naar data en algoritmiek kijken behoorlijk afhangt van het standpunt waaruit er wordt gekeken. Enerzijds is er de wiskundige kant, waarbij je kijkt naar de (getalsmatige) eigenschappen, anderzijds zal je ook naar de semantiek van de programmeertaal en de bijbehorende computer moeten kijken. Zowel syntactisch als qua code moet je ineens heel erg bewust zijn van je keuzes. Kleine (functioneel equivalente) veranderingen in je code kunnen immers grote impact hebben op performance bijvoorbeeld. Zoals de auteurs aangeven werp je hier zowel een drempel mee op voor nieuwkomers, als dat het resulteert in een complexere normale situatie voor meer ervaren mensen.

Complexiteit komt hier volgens de auteurs voort uit de noodzaak om meerdere mentale transformaties te moeten maken tussen de verschillende modellen waarin je het probleem moet plaatsen. Om te onderzoeken wat wel een natuurgetrouw model is zijn deze experimenten dan ook uitgevoerd. De opzet ervan is eenvoudig: geef de deelnemers abstracte probleembeschrijvingen en laat ze naar eigen inzicht een oplossing formuleren op een leeg A4’tje. Qua problemen is gekozen voor een spel-context (delen van Pacman beschrijven) en voor een “bedrijfs” context (mutaties van waarden in tabellen).

Na het uitvoeren van de experimenten is er aan software professionals gevraagd om de gegeven oplossingen te beoordelen op typische software thematiek. Hierbij wordt onderscheid gemaakt tussen verschillende invullingen. Een voorbeeld is het eerste: programming style. Hieruit volgen event-based statements (wanneer x doe y), maar ook restricties (x mag niet), declaraties (er is x) of imperatieve statements (doe x).

Naast deze beschrijvingen worden ook de verdeling en prevalence — hoe vaak een constructie gemiddeld voor komt per antwoord — gegeven. Een hoge prevalentie suggereert dus ook een generiek, veel gebruikt patroon. Een deel van de aanbevelingen van deze studie is dan ook dat deze patronen wellicht uit moeten worden gewerkt in programmeeromgevingen zodat deze dus een meer “menselijk” mentaal model krijgen bij programmeertalen dan wel programmeeromgevingen. Nu ga ik niet alle tabelletjes oplepelen (lees de paper!) maar ik wil wel een paar leuke dingen uitlichten.

Voor de boolean operator “en” zien we gelijk iets opvallends: mensen kiezen er in natuurlijke taal vaak voor om een constructie op te schrijven die logisch gezien niet betekent wat ze denken. Een voorbeeld: “voor alle x die beginnen met y en z…” is een logische or, maar wordt door (de Engelstalige) proefpersonen als een and beschreven. Een andere is de boolean negatie “niet”. Deze komt a) weinig voor in de gegeven oplossingen en b) wanneer hij voorkomt heeft hij een andere prioriteit als we gewend zijn. Een zin als “niet X of Y” betekent mentaal “niet(x of y)”, terwijl we syntactisch “niet(x) of y” verwachten.

Wat mij ook erg opviel is dat je algemeen gezien over veel van de oplossingen ook nog kan zeggen dat ze reactief zijn in de beschrijving van de oplossing. Er is weinig aandacht voor specifieke controlflow, buiten wat declaratieve startbeschrijvingen. Daarna wordt alles reactief en zijn de oplossingen dus beschreven als reacties op gebeurtenissen. Als laatste wordt ook gesuggereerd dat we een rijkere editor context moeten realiseren. Dit is iets wat ik ook persoonlijk ook ten zeerste onderschrijf, projectional editing is wat mij betreft een geniaal concept en iets waarmee we nog grote usability verbeteringen kunnen maken.

Tot slot zijn er natuurlijk ook weer genoeg kritiekpunten. Om er een paar te noemen: de testgroep is klein en niet zo divers, de opdrachten zijn vrij eenvoudig. Daarnaast is Tekst ambigu, wat je zeker bij complexe problemen wil voorkomen. Daarnaast wordt er heel veel undefined behaviour toegestaan door constructies als “ongeveer iedere x” te accepteren. Desalniettemin zet het je wel aan het denken. Vooral de prevalence / categorisering per onderwerp laat je over een aantal dingen wel kritisch nadenken. Hierdoor vind ik het ook een erg leuke paper om eens te lezen als je stil wil staan bij de gekke constructies die je nu dagelijks aan het uittypen bent.


Over deze papers we love: binnen Sogyo hebben we de traditie dat we maandelijks een nieuwsbrief rondsturen. De nieuwsbrief gaat veel over interne feitjes, echter sinds februari 2015 verzorgd Kevin van der Vlist het topic: papers we love. Hij deelt met ons papers die interessant zijn om te lezen en ons kunnen inspireren. De topic is uitgegroeid tot een mooie verzameling die we ook graag hier willen delen.