Computer Science of enkel Software Engineering?
We kunnen zo ongeveer de volgende gebieden (in volgorde) onderscheiden:
1) hardware fabricage
2) hardware ontwerp (circuitry, plaatsing)
3) hardware specificatie (architectuur, functioneel ontwerp)
4) software engineering (specificatie, ontwerp, fabricage, aanpassing)
5) toepassingen en methoden, hierop gericht.
en de vraag is, op welke gebieden de onderafdeling der wiskunde zich concentreert.
1) Ik denk hier aan opdamptechnieken, het valt misschien meer onder de physica der vaste stoffen dan onder electrotechniek, het valt in elk geval buiten het terrein van de onderafdeling der wiskunde.
2) Dit gebied valt onder electrotechniek: hier zijn wel wiskundige problemen, nl. die van de schakeltheorie (equivalentie en zo) en optimaliseringsopgaven onder combinaritorische vrijheden. Hier fungeert de wiskunde voor mijn gevoel als toeleveringsbedrijf, het gebied valt buiten de wiskunde als zodanig.
3) Dit gebied ligt op de grens van electrotechniek en wiskunde: de vorige gebieden perken het realiseerbare af, software levert en motiveert de verlangens. Het wordt daardoor tot een meer wiskundige activiteit dan de vorige twee. Tevens fungeert wiskunde hier weer als toeleveringsbedrijf (bv. via de stochastiek en simulatie ter optimalisering of tijdige detectie van knelpunten).
4) Dit gebied ligt als abstracte discipline op het gebied van de onderafdeling der wiskunde; overige takken der wiskunde (bewijstheorie en stochastiek) kunnen weer als toeleveringsbedrijf functioneren.
5) Via de toepassingen waaiert het gebied in zijn totaliteit ver uit buiten de competentie van de wiskunde; wel ligt er een duidelijke taak op het gebied van methoden (numerieke, optimaliseringstechniek, programmeertalen, heuristiek, simulatie en programmeren). Hier is de rekenautomaat in hoofdzaak gereedschap, de wiskunde toeleveringsbedrijf en ligt het doel in het toepassingsgebied.
Gebieden 1) en 2) vallen duidelijk buiten ons directe werkterrein, 4) en 5) vallen er duidelijk binnen. Gebied 3) —wat ik vroeger deed— is het vraagpunt en het is de vraag of we dit laten schieten of niet. Betrekken we het in de activiteiten, dan tenderen we naar Computer Science, laten we het schieten, dan blijft 4) —wat ik nu doe— over als bouwsteen van een wiskundige richting “Software Engineering”. (In deze indeling taxeer ik Lunbeck hoofdzakelijk in 5, met dien verstande, dat ik van hem uitbreiding van het toepassingsgebied en bijbehorende methodenontwikkeling verwacht.)
Mijn neiging is op het ogenblik erg om 3) te laten schieten en me op 4) te concentreren en me daarbij meer te laten sturen door wat je als mens kan en zou willen dan wat op bestaande apparatuur vraagt. Ik wil proberen om wat van de overwegingen bloot te leggen, die tot deze plaatsbepaling van mij geleid hebben, omdat ze voor een gedeelte ongetwijfeld relevant zijn voor de plaatsbepaling van de onderafdeling in dit vakgebied.
De overgang van 3 naar vier was om te beginnen om historische redenen noodzakelijk: te lang zijn rekenautomaten ontworpen op grond van technische mogelijkheden (een begrijpelijke traditie!) en te lang is het probleem hoe je ze nu eigenlijk gebruikt naar later gedelegeerd. Om iets verstandigers te zeggen over hoe machines er eigenlijk uit zouden moeten zien, was 4) dus noodzakelijk. Inmiddels heeft dit mij helemaal opgeslokt en is mijn neiging om 3 te laten waaien. Waarom? Defaitisme en onmacht, zo je wilt.
Een belangrijke, opportunistische overweging is ongetwijfeld dat de TH niet beschikt over de electrotechnische gesprekspartner, die hiervoor nodig zou zijn. Dat Heetman in dezen incompetent is wordt nog verzwaard door het feit, dat hij de grenzen van zijn eigen competentie niet kent. Tengevolge daarvan zie ik pogingen tot samenwerking als heilloos en frustrerend en zelfbescherming noodt mij om contact met hem te minimaliseren. Het heeft toch geen zin. Dit is een profane, practische overweging, maar het is voor mij een heel sterk motief om mij terug te trekken op het gebied, dat ik onafhankelijk op een nette manier bestrijken kan, om het stuk er uit te lichten, dat past in het beeld van de wiskundig ingenieur. (Dit soort gesprekspartner had ik nog wel, toe ik Electrologica adviseerde, nu ik Philips-Electrologica adviseer is dat veel minder omdat het concept van het verkoopbare product daar pregnanter naar voren komt.)
Naast deze interne rem is er een externe: sinds universiteiten niet meer laboratoriummachines ontwerpen en bouwen, sinds de machine geworden (verworden?) is tot een industrieel serieproduct, zit de industriele machineontwerper aan handen en voeten gebonden, zijn terms of reference liggen voor 88 procent hardstikke vast, het gaat er niet meer om om iets goeds (dwz. beters) te maken, het gaat er om om hetzelfde te maken, maar liefst goedkoper. Wat zal ik dan leuke machines ontwerpen, of, op kleinere schaal: normen voor gezonde hardware specificaties, als je die ideeen nog niet aan de straatstenen kwijtkunt? Dit klinkt misschien erg bitter (is het misschien ook wel) maar het is een realiteit, waarvoor ik niet mijn kop in het zand wil steken. Het puin, dat op het ogenblik tot norm verheven wordt, (omdat iedereen het koopt) is afstotend.