Visuele beperkingen, of programmeren zonder bril

Sinds de laatste jaren ben ik het gemak van een hulpmiddel als Visual Studio 2003 (VS) erg gaan waarderen en bouw ik met veel plezier mijn nieuwste applicaties in VB.NET of C#. Je zou je haast gaan afvragen waarom beginnerscursussen in development niet beginnen met instructies over het gebruik van VS. Toch vermijden wij als docenten zoiets als de pest en dat heeft goede redenen!

Er sluipen over het algemeen gemakkelijk verkeerde gewoonten in het programmeren, reden waarom ikzelf in de jaren tachtig gewaarschuwd werd voor Basic (toen overigens nog geenszins 'visual' te noemen). Omdat ik in mijn opleiding begonnen was met Nassi-Schneidermandiagrammen en daarna Cobol, meende ik me wel wat Basic te kunnen permitteren, maar ik was blij toen ik over kon stappen naar C. Basic code was in die tijd absoluut onleesbaar, met zijn verplichte regelnummers en zijn gebrek aan (automatische) inspringmogelijkheden. De typeloze en niet declareerbare variabelen maakten Basic programma's stomweg onbetrouwbaar. In zekere zin het mooiste ben ik naderhand nog het programmeren in assemblytaal (Z80, M65000) gaan vinden, maar dat is een ander verhaal. Het voornaamste is dat ik allemaal programma's in louter code schreef, die louter met tekst werkten als invoer en als uitvoer. Mijn editor kon een regel kopieren of verplaatsen en het woord waar de cursor op stond verderop in de tekst zoeken - dat was voldoende. Zo 'onvisueel' kun je nog steeds programmeren, bijvoorbeeld door console-applicaties te bouwen. Maar wie doet dat nog ooit?

Ja, die jongen in Utrecht die ik kende deed dat. Die had zelf zijn eigen Unixsysteem gebouwd, waarmee een complete website in de lucht werd gehouden. Alles geschreven in C en Perl. Er kwam geen spatje visuele ondersteuning aan te pas - dat zou trouwens ook minder handig zijn geweest aangezien de man slechtziend was. Er was geen probleem waar je hem over belde dat hij niet binnen de kortste keren al typende (via een Terminal verbinding) oploste.

Werkelijk, visueel programmeren kan uitermate handig zijn als je graag wilt werken op de RAD-manier. Rapid Application Development gaat uit van de GUI (Graphical User Interface), dus van wat de gebruiker van het programma op het scherm ziet. Je bedenkt wat er zichtbaar moet worden en bedenkt daar dan de nodige business logic bij, die vervolgens in werkende programmacode dient te resulteren. Dit is heel vaak een mooie methode en VS is hier enorm geschikt voor. Toch ben ik blij dat ik deze methode niet van begin af aan heb toegepast. Programmeurs die het vak willen leren kunnen beter een omweg maken en de visuele elementen niet centraal stellen. Waarom?

Wat ik bij beginners die al aardig met VS overweg kunnen soms merk, is dat ze als het ware zelf geen woord meer in kunnen tikken. Voortdurend zijn ze in de weer met muis en dropdownlijstjes, drukken ze op Control plus spatiebalk om autocomplete te forceren, plakken ze stukken code uit een voorbeeld in in hun programma. Je word gewoon moe als je het alleen maar aanziet. Programmeren verwordt zo tot aanpassen van wat ingevuld, aangevuld of op andere manieren aangereikt wordt. Het is vermoeiend voor je armen en ogen en het schiet in wezen niet op. In dezelfde tijd dat je zo visueel bezig bent met een programma, had je al typend twee programma's kunnen schrijven. Bovendien krijg je de taalelementen op deze wijze niet echt 'in de vingers'.

Dus, bezint eer gij bezint, en leer een programmeertaal om te beginnen niet in een visuele omgeving. Laat een programma als VS werkelijk een hulpmiddel zijn en niet een beperkend harnas!

P.S. Je kunt Statement Completion ook afzetten. Zie Tools, Options, Editors, All languages, General. Dan kun je je code gewoon zelf typen en hoef je niet steeds op Escape te drukken als je door je regels heen wilt wandelen.

maart 2005