Waarom Arc niet bijzonder objectgeoriënteerd is

Er is op dit moment een soort maniakaal enthousiasme voor objectgeoriënteerd programmeren, maar enkele van de slimste programmeurs die ik ken, zijn er het minst enthousiast over.

Mijn eigen gevoel is dat objectgeoriënteerd programmeren in sommige gevallen een nuttige techniek is, maar het is niet iets dat elk programma dat je schrijft moet doordringen. Je moet nieuwe typen kunnen definiëren, maar je hoeft niet elk programma uit te drukken als de definitie van nieuwe typen.

Ik denk dat er vijf redenen zijn waarom mensen van objectgeoriënteerd programmeren houden, en drieënhalf daarvan zijn slecht:

1. Objectgeoriënteerd programmeren is spannend als je een statisch getypeerde taal hebt zonder lexicale closures of macro's. Tot op zekere hoogte biedt het een manier om deze beperkingen te omzeilen. (Zie Greenspun's Tenth Rule.)

2. Objectgeoriënteerd programmeren is populair in grote bedrijven, omdat het past bij de manier waarop zij software schrijven. In grote bedrijven wordt software doorgaans geschreven door grote (en vaak veranderende) teams van middelmatige programmeurs. Objectgeoriënteerd programmeren legt een discipline op aan deze programmeurs die voorkomt dat een van hen te veel schade aanricht. De prijs is dat de resulterende code opgeblazen is met protocollen en vol met duplicatie. Dit is geen te hoge prijs voor grote bedrijven, omdat hun software waarschijnlijk toch al opgeblazen en vol met duplicatie zal zijn.

3. Objectgeoriënteerd programmeren genereert veel wat op werk lijkt. Vroeger, in de tijd van fanfold, was er een type programmeur dat slechts vijf of tien regels code per pagina plaatste, voorafgegaan door twintig regels met uitgebreid opgemaakte commentaar. Objectgeoriënteerd programmeren is als crack voor deze mensen: het laat je al deze steigers direct in je broncode opnemen. Iets wat een Lisp-hacker zou afhandelen door een symbool op een lijst te plaatsen, wordt een heel bestand met klassen en methoden. Het is dus een goed hulpmiddel als je jezelf, of iemand anders, wilt overtuigen dat je veel werk verricht.

4. Als een taal zelf een objectgeoriënteerd programma is, kan deze door gebruikers worden uitgebreid. Nou ja, misschien. Of misschien kun je het nog beter doen door de subconcepten van objectgeoriënteerd programmeren à la carte aan te bieden. Overloading, bijvoorbeeld, is niet intrinsiek gebonden aan klassen. We zullen zien.

5. Objectgeoriënteerde abstracties sluiten netjes aan bij de domeinen van bepaalde specifieke soorten programma's, zoals simulaties en CAD-systemen.

Ik heb persoonlijk nooit objectgeoriënteerde abstracties nodig gehad. Common Lisp heeft een enorm krachtig objectensysteem en ik heb het nog nooit gebruikt. Ik heb veel dingen gedaan (bijv. hash-tabellen vol met closures maken) die objectgeoriënteerde technieken zouden hebben vereist om te doen in zwakkere talen, maar ik heb nooit CLOS hoeven gebruiken.

Misschien ben ik gewoon dom, of heb ik aan een beperkte subset van applicaties gewerkt. Er is een gevaar bij het ontwerpen van een taal op basis van je eigen programmeerervaring. Maar het lijkt gevaarlijker om dingen toe te voegen die je nooit nodig hebt gehad omdat men denkt dat het een goed idee is.