Het probleem met programmeren

In de jaren ’80 en ’90, Bjarne Stroustrup ontwierp en implementeerde de programmeertaal C++, die objectgeoriënteerd programmeren populair maakte en tal van andere programmeertalen, waaronder Java, beïnvloedde.

C++ blijft de archetypische computertaal op hoog niveau (dat wil zeggen, een taal die de kenmerken van natuurlijke, menselijke taal behoudt), en wordt nog steeds gebruikt door miljoenen programmeurs. Veel van de systemen en applicaties uit het pc- en internettijdperk zijn geschreven in C++. Desondanks blijft de taal controversieel, vooral omdat het notoir moeilijk te leren en te gebruiken is, en ook omdat het ontwerp van Stroustrup ontwikkelaars in staat stelt ernstige programmeerfouten te maken in het belang van het behoud van hun vrijheid.

Stroustrup, jarenlang onderzoeker bij AT&T Bell Labs, is nu hoogleraar computerwetenschappen aan de afdeling Engineering van de Texas A&M University, in de buurt van Houston.

Technologie beoordeling : Waarom is de meeste software zo slecht?

Bjarne Stroustrup : Sommige software is eigenlijk best goed volgens alle normen. Denk aan de Mars Rovers, Google en het Human Genome Project. Dat is kwaliteitssoftware! Vijftien jaar geleden zouden de meeste mensen, en vooral de meeste experts, hebben gezegd dat elk van die voorbeelden onmogelijk was. Onze technologische beschaving is afhankelijk van software, dus als software zo slecht was geweest als zijn slechtste reputatie, zouden de meesten van ons allang dood zijn geweest.

Aan de andere kant kan ik huilen als ik naar gemiddelde stukjes code kijk. De structuur is verschrikkelijk en de programmeurs hebben duidelijk niet diep nagedacht over correctheid, algoritmen, datastructuren of onderhoudbaarheid. De meeste mensen lezen de code niet echt; ze zien Internet Explorer gewoon bevriezen.

Ik denk dat het echte probleem is dat wij (dat wil zeggen, wij softwareontwikkelaars) in een permanente noodtoestand verkeren en ons aan strohalmen vastgrijpen om ons werk gedaan te krijgen. We verrichten veel kleine wonderen met vallen en opstaan, overmatig gebruik van brute kracht en heel veel testen, maar - zo vaak - is het niet genoeg.

Softwareontwikkelaars zijn bedreven in de moeilijke kunst om redelijk betrouwbare systemen te bouwen uit onbetrouwbare onderdelen. Het probleem is dat we vaak niet precies weten hoe we het hebben gedaan: een systeem evolueerde gewoon naar iets dat minimaal acceptabel was. Persoonlijk wil ik liever weten wanneer een systeem zal werken en waarom het zal werken.

KINDEREN : Hoe kunnen we de puinhoop waarin we ons bevinden oplossen?

BS : In theorie is het antwoord simpel: leid onze softwareontwikkelaars beter op, gebruik meer geschikte ontwerpmethoden en ontwerp voor flexibiliteit en voor de lange termijn. Beloon correcte, solide en veilige systemen. Slordigheid straffen.

In werkelijkheid is dat onmogelijk. Mensen belonen ontwikkelaars die software leveren die goedkoop, buggy en eerste is. Dat komt omdat mensen nu mooie nieuwe gadgets willen. Zij niet doen ongemak willen, geen nieuwe manieren willen leren om met hun computers om te gaan, geen vertragingen in de levering willen en niet extra willen betalen voor kwaliteit (tenzij het van tevoren duidelijk is - en vaak zelfs dan niet). En zonder echte veranderingen in het gebruikersgedrag zullen softwareleveranciers waarschijnlijk niet veranderen.

We kunnen de wereld niet tien jaar stilleggen terwijl we alles herprogrammeren, van onze koffiemachines tot onze financiële systemen. Aan de andere kant is gewoon doormodderen duur, gevaarlijk en deprimerend. Er zijn aanzienlijke verbeteringen nodig, en die kunnen alleen geleidelijk komen. Ze moeten op een breed front komen; geen enkele wijziging is voldoende.

Een probleem is dat academische schoorstenen in de weg zitten: te veel mensen duwen een bepaald gebied als een wondermiddel. Betere ontwerpmethoden kunnen helpen, betere specificatietechnieken kunnen helpen, betere programmeertalen kunnen helpen, betere testtechnologieën kunnen helpen, betere besturingssystemen kunnen helpen, betere middleware-infrastructuren kunnen helpen, beter begrip van toepassingsdomeinen kan helpen, beter begrip van gegevens structuren en algoritmen kunnen helpen - enzovoort. Bijvoorbeeld, typetheorie, op modellen gebaseerde ontwikkeling en formele methoden kunnen op sommige gebieden ongetwijfeld aanzienlijke hulp bieden, maar ze worden gepusht de oplossing met uitsluiting van andere benaderingen, elk garandeert mislukking in grootschalige projecten. Mensen pushen wat ze weten en wat ze hebben zien werken; hoe zouden ze anders kunnen? Maar weinigen hebben de technische volwassenheid om de eisen en de middelen in evenwicht te brengen.

KINDEREN : Het idee achter C++ was dat programmeurs harder zouden werken in ruil voor efficiëntere code. Bell Labs wilde een taal die een paar echt slimme mensen zouden gebruiken om code te schrijven die zou draaien op computers zoals Electronic Switching Systems (ESS) die niet erg snel waren. Tegenwoordig zijn er veel softwareontwikkelaars en computers zijn erg snel. Doet dat afbreuk aan het punt van C ++?

BS : C++ is niet specifiek ontworpen voor de grote schakelmachines, maar voor een enorm scala aan toepassingen. Bell Labs was de thuisbasis van een ongelooflijke reeks interessante projecten op elke schaal en met vrijwel elk soort computer en besturingssysteem. Maar ja, de gemiddelde Bell Labs-programmeur was aanzienlijk beter in staat dan het idee van de meeste mensen van een gemiddelde programmeur, en betrouwbaarheid en prestaties (in die volgorde) werden als significant belangrijker beschouwd dan op de meeste andere plaatsen.

Prestaties zijn nog steeds een probleem in veel van de applicaties waarin ik geïnteresseerd ben: responsiviteit van interfaces, opstart- en sluitingstijd van applicaties. Softwareontwikkelaars hebben de verbazingwekkende prestaties van moderne computerhardware geneutraliseerd door laag op laag van overmatige [software]abstracties toe te voegen. We lijken de limieten van lineaire versnelling voor hardware te hebben bereikt, maar in veel gevallen zouden we een paar ordes van grootte terug kunnen winnen van de software.

Dat gezegd hebbende, C++ is inderdaad te deskundig geworden in een tijd waarin de mate van effectieve formele opleiding van de gemiddelde softwareontwikkelaar is afgenomen. De oplossing is echter niet om de programmeertalen te verdoezelen, maar om een ​​verscheidenheid aan programmeertalen te gebruiken en meer experts op te leiden. Er moeten talen zijn die deze experts kunnen gebruiken - en C++ is een van die talen.

KINDEREN : Was uw beslissing om de efficiëntie, beveiliging en softwarebetrouwbaarheid van de programmeur in te ruilen voor runtimeprestaties achteraf niet een fundamentele fout bij het ontwerpen van C++?

BS : Nou, ik denk niet dat ik zo'n afweging heb gemaakt. ik wil elegant en efficiënte code. Soms snap ik het. Deze dichotomieën (tussen efficiëntie versus correctheid, efficiëntie versus programmeertijd, efficiëntie versus hoog niveau, enzovoort) zijn nep.

Wat ik wel deed, was C++ ontwerpen als allereerst een systeemprogrammeertaal: ik wilde apparaatstuurprogramma's, embedded systemen en andere code kunnen schrijven die hardware rechtstreeks moest gebruiken. Vervolgens wilde ik dat C++ een goede taal zou zijn voor het ontwerpen van tools. Dat vereiste flexibiliteit en prestaties, maar ook het vermogen om elegante interfaces uit te drukken. Mijn mening was dat om dingen op een hoger niveau te doen, om complete applicaties te bouwen, je eerst bibliotheken moest kopen, bouwen of lenen die de juiste abstracties leveren. Wanneer mensen problemen hebben met C++, is het echte probleem vaak dat ze geen geschikte bibliotheken hebben, of dat ze de beschikbare bibliotheken niet kunnen vinden.

Andere talen hebben geprobeerd om toepassingen op hoog niveau directer te ondersteunen.

Dat werkt, maar vaak gaat die ondersteuning ten koste van specialisatie. Persoonlijk zou ik geen tool ontwerpen die alleen zou kunnen doen wat ik wilde - ik streef naar algemeenheid.

KINDEREN : Hoe verklaart u het feit dat C++ zowel door veel programmeurs breed wordt bekritiseerd als verafschuwd, maar tegelijkertijd zeer breed wordt gebruikt? Waarom is het zo succesvol?

BS : Het vlotte antwoord is: er zijn maar twee soorten talen: de talen waar iedereen over klaagt en de talen die niemand gebruikt.

Er zijn meer bruikbare systemen ontwikkeld in talen die als afschuwelijk worden beschouwd dan in talen die worden geprezen omdat ze mooi zijn - veel meer. Het doel van een programmeertaal is om te helpen bij het bouwen van goede systemen, waar goed op vele manieren kan worden gedefinieerd. Mijn korte definitie is: correct, onderhoudbaar en voldoende snel. Esthetiek is belangrijk, maar eerst en vooral moet een taal nuttig zijn; het moet real-world programmeurs in staat stellen om real-world ideeën bondig en betaalbaar uit te drukken.

De belangrijkste reden voor het succes van C++ is simpelweg dat het voldoet aan de beperkte ontwerpdoelen: het kan een enorm scala aan ideeën direct en efficiënt uitdrukken. C++ is niet ontworpen om slechts één ding heel goed te doen of om te voorkomen dat mensen dingen doen die als slecht worden beschouwd. In plaats daarvan concentreerde ik me op algemeenheid en prestaties.

Ik weet zeker dat er voor elke programmeur die een hekel heeft aan C++, er wel een is die het leuk vindt. Een vriend van mij ging echter naar een conferentie waar de hoofdspreker het publiek vroeg om door handopsteken aan te geven hoeveel mensen C++ niet leuk vonden en twee hoeveel mensen een C++-programma hadden geschreven. In de eerste groep zaten twee keer zoveel mensen dan in de tweede. Het uiten van een afkeer van iets dat je niet weet, staat meestal bekend als vooroordeel. Ook zijn klagers altijd luider en zekerder dan voorstanders - redelijke mensen erkennen gebreken. Ik denk dat ik meer weet over de problemen met C++ dan wie dan ook, maar ik weet ook hoe ik ze kan vermijden en hoe ik de sterke punten van C++ kan gebruiken.

En dan verwacht je natuurlijk niet dat voorstanders van talen die de concurrentie met C++ hebben verloren daar beleefd over zijn. Softwareontwikkeling heeft niet die mate van professionaliteit, hoewel ik hoop dat dit uiteindelijk wel het geval zal zijn. De wetenschap is daarin anders: als een nieuwe tool, techniek of theorie het wint, zien mensen dat als vooruitgang. In software worden bijdragen van concurrenten en voorgangers niet algemeen erkend, gewaardeerd of zelfs maar begrepen.

KINDEREN : In Het ontwerp en de evolutie van C++ , beweert u dat Kierkegaard een invloed had op uw opvatting van de taal. Is dit een grap?

BS : Een beetje pretentieus misschien, maar geen grap. Veel denken over softwareontwikkeling is gericht op de groep, het team, het bedrijf. Dit wordt vaak gedaan tot het punt waarop het individu volledig wordt ondergedompeld in de bedrijfscultuur zonder enige uitlaatklep voor unieke talenten en vaardigheden. Bedrijfspraktijken kunnen direct vijandig zijn tegenover personen met uitzonderlijke vaardigheden en initiatief in technische aangelegenheden. Ik vind een dergelijk management van technische mensen wreed en verkwistend. Kierkegaard was een groot voorstander van het individu tegen de massa en voert een serieuze discussie over het belang van esthetiek en ethisch gedrag. Ik kon niet een specifiek taalkenmerk aanwijzen en zeggen: kijk, daar is de invloed van de negentiende-eeuwse filosoof, maar hij is een van de wortels van mijn onwil om kenmerken op expertniveau te elimineren, misbruiken af ​​te schaffen en kenmerken te beperken tot ondersteuning alleen toepassingen waarvan ik weet dat ze nuttig zijn. Ik ben echter niet zo dol op de religieuze filosofie van Kierkegaard.

KINDEREN : Waar heb je het meeste spijt van?

BS : Geen spijt! Nou, natuurlijk droom ik van wat ik anders en beter had kunnen doen, maar serieus, wie ben ik om te twijfelen aan bijvoorbeeld 1984 vintage Bjarne? Hij was misschien minder ervaren dan ik, maar hij was niet minder slim, waarschijnlijk slimmer, en hij begreep het woord van 1984 beter dan ik. C++ is gebruikt om veel systemen te bouwen die ons leven verbeteren, en het heeft een aanzienlijke positieve invloed gehad op latere talen en systemen. Dat is iets om trots op te zijn.

Klik hier om ons tweede interview met Stroustrup te lezen.

zich verstoppen