Problemet med programmering

I 1980'erne og 90'erne, Bjarne Stroustrup designet og implementeret C++ programmeringssproget, som populariserede objektorienteret programmering og påvirkede adskillige andre programmeringssprog, inklusive Java.

C++ forbliver det arketypiske computersprog på højt niveau (det vil sige et, der bevarer det naturlige, menneskelige sprogs funktioner), og det bruges stadig af millioner af programmører. Mange af systemerne og applikationerne fra pc'en og internettiden blev skrevet i C++. Til trods for alt det er sproget stadig kontroversielt, hovedsageligt fordi det er notorisk svært at lære og bruge, og også fordi Stroustrups design giver udviklere mulighed for at lave alvorlige programmeringsfejl i interessen for at bevare deres frihed.

Stroustrup, i mange år forsker ved AT&T Bell Labs, er nu professor i datalogi ved Institut for Ingeniørvidenskab, ved Texas A&M University, nær Houston.

Teknologigennemgang : Hvorfor er det meste software så dårligt?

Bjarne Stroustrup : Noget software er faktisk ret godt efter enhver standard. Tænk på Mars Rovers, Google og Human Genome Project. Det er kvalitetssoftware! For 15 år siden ville de fleste mennesker, og især de fleste eksperter, have sagt, at hvert af disse eksempler var umuligt. Vores teknologiske civilisation afhænger af software, så hvis software havde været lige så dårligt som dets værste ry, ville de fleste af os have været døde nu.

På den anden side kan jeg græde ved at se på gennemsnitlige kodestykker. Strukturen er rystende, og programmørerne tænkte tydeligvis ikke dybt over korrekthed, algoritmer, datastrukturer eller vedligeholdelse. De fleste mennesker læser faktisk ikke kode; de ser bare Internet Explorer fryse.

Jeg tror, ​​at det virkelige problem er, at vi (det vil sige vi softwareudviklere) er i en permanent undtagelsestilstand og griber efter halmstrå for at få vores arbejde gjort. Vi udfører mange mindre mirakler gennem forsøg og fejl, overdreven brug af rå magt og masser af test, men – så ofte – er det ikke nok.

Softwareudviklere er blevet dygtige til den vanskelige kunst at bygge rimeligt pålidelige systemer ud af upålidelige dele. Hagen er, at vi ofte ikke ved præcis, hvordan vi gjorde det: et system udviklede sig bare til noget minimalt acceptabelt. Personligt foretrækker jeg at vide, hvornår et system vil fungere, og hvorfor det vil.

BØRN : Hvordan kan vi ordne det rod, vi er i?

BS : I teorien er svaret enkelt: uddanne vores softwareudviklere bedre, brug mere passende designmetoder og design for fleksibilitet og langsigtet. Beløn ​​korrekte, solide og sikre systemer. Straf sjusk.

I virkeligheden er det umuligt. Folk belønner udviklere, der leverer software, der er billig, buggy og først. Det er fordi folk vil have smarte nye gadgets nu. De ikke ønsker besvær, ønsker ikke at lære nye måder at interagere med deres computere på, ønsker ikke forsinkelser i leveringen og ønsker ikke at betale ekstra for kvalitet (medmindre det er indlysende på forhånd – og ofte ikke engang da). Og uden reelle ændringer i brugeradfærd er det usandsynligt, at softwareleverandører ændrer sig.

Vi kan ikke bare stoppe verden i et årti, mens vi omprogrammerer alt fra vores kaffemaskiner til vores finansielle systemer. På den anden side er det dyrt, farligt og deprimerende bare at rode rundt. Der er brug for væsentlige forbedringer, og de kan kun komme gradvist. De skal komme på bred front; ingen enkelt ændring er tilstrækkelig.

Et problem er, at akademiske skorstene kommer i vejen: for mange mennesker skubber et område som et vidundermiddel. Bedre designmetoder kan hjælpe, bedre specifikationsteknikker kan hjælpe, bedre programmeringssprog kan hjælpe, bedre testteknologier kan hjælpe, bedre operativsystemer kan hjælpe, bedre middleware-infrastrukturer kan hjælpe, bedre forståelse af applikationsdomæner kan hjælpe, bedre forståelse af data strukturer og algoritmer kan hjælpe – og så videre. For eksempel kan typeteori, modelbaseret udvikling og formelle metoder utvivlsomt give betydelig hjælp på nogle områder, men skubbet som det løsning med udelukkelse af andre tilgange, garanterer hver for sig fiasko i storskalaprojekter. Folk presser det, de ved, og det, de har set virke; hvordan kunne de gøre andet? Men de færreste har den tekniske modenhed til at balancere kravene og ressourcerne.

BØRN : Tanken bag C++ var, at programmører ville arbejde hårdere til gengæld for mere effektiv kode. Bell Labs ønskede et sprog, som nogle få virkelig kloge mennesker ville bruge til at skrive kode, der ville køre på computere som Electronic Switching Systems (ESS), der ikke var særlig hurtige. I dag er der mange softwareudviklere, og computere er meget hurtige. Slæber det meningen med C++?

BS : C++ blev ikke designet specifikt til de store skiftemaskiner, men til en lang række applikationer. Bell Labs var hjemsted for en utrolig række interessante projekter, der spænder over alle skalaer og anvender stort set alle slags computere og operativsystemer. Men ja, den gennemsnitlige Bell Labs-programmør var betydeligt bedre end de flestes forestilling om en gennemsnitlig programmør, og pålidelighed og ydeevne (i den rækkefølge) blev betragtet som væsentligt vigtigere end de fleste andre steder.

Ydeevne er stadig et problem i mange af de applikationer, som jeg er interesseret i: reaktion på grænseflader, opstarts- og nedlukningstider for applikationer. Softwareudviklere har neutraliseret den forbløffende ydeevne af moderne computerhardware ved at tilføje lag på lag af overudviklede [software] abstraktioner. Vi ser ud til at have ramt grænserne for lineær speedup for hardware, men i mange tilfælde kunne vi vinde et par størrelsesordener tilbage fra softwaren.

Når det er sagt, er C++ faktisk blevet for ekspertvenligt på et tidspunkt, hvor graden af ​​effektiv formel uddannelse af den gennemsnitlige softwareudvikler er faldet. Løsningen er dog ikke at dumme programmeringssprogene ned, men at bruge en række forskellige programmeringssprog og uddanne flere eksperter. Der skal være sprog for disse eksperter at bruge - og C++ er et af disse sprog.

BØRN : Set i bakspejlet, i forbindelse med design af C++, var din beslutning om at afveje programmøreffektivitet, sikkerhed og softwarepålidelighed ikke en grundlæggende fejl?

BS : Jamen, jeg tror ikke, jeg lavede sådan en afvejning. Jeg vil have elegant og effektiv kode. Nogle gange forstår jeg det. Disse dikotomier (mellem effektivitet versus korrekthed, effektivitet versus programmørtid, effektivitet versus højt niveau, et cetera.) er falske.

Det, jeg gjorde, var at designe C++ som først og fremmest et systemprogrammeringssprog: Jeg ville være i stand til at skrive enhedsdrivere, indlejrede systemer og anden kode, der skulle bruge hardware direkte. Dernæst ønskede jeg, at C++ skulle være et godt sprog til at designe værktøjer. Det krævede fleksibilitet og ydeevne, men også evnen til at udtrykke elegante grænseflader. Min opfattelse var, at for at lave ting på højere niveau, for at bygge komplette applikationer, var du først nødt til at købe, bygge eller låne biblioteker med passende abstraktioner. Ofte, når folk har problemer med C++, er det virkelige problem, at de ikke har passende biblioteker – eller at de ikke kan finde de biblioteker, der er tilgængelige.

Andre sprog har forsøgt mere direkte at understøtte applikationer på højt niveau.

Det virker, men ofte kommer den støtte på bekostning af specialisering. Personligt ville jeg ikke designe et værktøj, der kun kunne gøre, hvad jeg ville – jeg sigter efter almenhed.

BØRN : Hvordan redegør du for, at C++ både er meget kritiseret og forarget af mange programmører, men samtidig er meget udbredt? Hvorfor er det så vellykket?

BS : Det smarte svar er: Der er kun to slags sprog: dem, alle klager over, og dem, ingen bruger.

Der er mere brugbare systemer udviklet på sprog, der anses for forfærdelige, end på sprog, der er rost for at være smukke – mange flere. Formålet med et programmeringssprog er at hjælpe med at bygge gode systemer, hvor godt kan defineres på mange måder. Min korte definition er korrekt, vedligeholdelig og tilstrækkelig hurtig. Æstetik betyder noget, men først og fremmest skal et sprog være brugbart; det skal give programmører i den virkelige verden mulighed for at udtrykke ideer fra den virkelige verden kortfattet og til en overkommelig pris.

Hovedårsagen til C++’s succes er simpelthen, at den opfylder sine begrænsede designmål: den kan udtrykke en lang række ideer direkte og effektivt. C++ er ikke designet til kun at gøre én ting rigtig godt eller forhindre folk i at gøre ting, der anses for dårlige. I stedet koncentrerede jeg mig om almenhed og præstation.

Jeg er sikker på, at for hver programmør, der ikke kan lide C++, er der én, der kan lide det. Men en af ​​mine venner gik til en konference, hvor hovedtaleren bad publikum om ved håndsoprækning at angive, hvor mange mennesker der ikke kunne lide C++, og to, hvor mange der havde skrevet et C++-program. Der var dobbelt så mange mennesker i den første gruppe end den anden. At udtrykke modvilje mod noget, du ikke kender, er normalt kendt som fordomme. Også klagere er altid mere højlydte og mere sikre end fortalere - fornuftige mennesker anerkender fejl. Jeg tror, ​​jeg ved mere om problemerne med C++ end bare om nogen, men jeg ved også, hvordan man undgår dem, og hvordan man bruger C++'s styrker.

Og så forventer du selvfølgelig ikke, at fortalere for sprog, der tabte i konkurrencen med C++, er høflige omkring det. Softwareudvikling har ikke den grad af professionalisme - selvom jeg håber, det vil ske. Videnskaben er anderledes i denne henseende: Når et nyt værktøj, en ny teknik eller teori vinder frem, ser folk det som fremskridt. Inden for software er bidrag fra konkurrenter og forgængere ikke bredt anerkendt, værdsat eller endda forstået.

BØRN : Ind Designet og udviklingen af ​​C++ , du hævder, at Kierkegaard var en indflydelse på din opfattelse af sproget. Er dette en joke?

BS : Lidt prætentiøst, måske, men ikke en joke. Meget tænkning omkring softwareudvikling er fokuseret på koncernen, teamet, virksomheden. Dette gøres ofte til det punkt, hvor individet er fuldstændig nedsænket i virksomhedskulturen uden udløb for unikke talenter og færdigheder. Virksomhedspraksis kan være direkte fjendtlig over for personer med exceptionelle færdigheder og initiativ i tekniske spørgsmål. Jeg anser en sådan ledelse af tekniske mennesker for grusom og spild. Kierkegaard var en stærk fortaler for individet mod mængden og har nogle seriøse diskussioner om vigtigheden af ​​æstetik og etisk adfærd. Jeg kunne ikke pege på et specifikt sprogtræk og sige: Se, der er indflydelsen fra filosoffen fra det nittende århundrede, men han er en af ​​rødderne til min modvilje mod at eliminere træk på ekspertniveau, at afskaffe misbrug og at begrænse træk til support kun anvendelser, som jeg ved er nyttige. Jeg er dog ikke særlig vild med Kierkegaards religiøse filosofi.

BØRN : Hvad fortryder du mest?

BS : Ingen fortrydelser! Nå, selvfølgelig drømmer jeg om, hvad jeg kunne have gjort anderledes og bedre, men seriøst, hvem er jeg til at gætte, f.eks. årgang 1984 Bjarne? Han var måske mindre erfaren end jeg, men han var ikke mindre klog, nok klogere, og han havde en bedre forståelse af ordet fra 1984 end jeg har. C++ er blevet brugt til at bygge mange systemer, der forbedrer vores liv, og det har haft en betydelig positiv indflydelse på senere sprog og systemer. Det er noget at være stolt af.

Klik her for at læse vores andet interview med Stroustrup.

skjule