Problemet med programmering

På 1980- och 90-talen, Bjarne Stroustrup designade och implementerade programmeringsspråket C++, som populariserade objektorienterad programmering och påverkade många andra programmeringsspråk, inklusive Java.

C++ förblir det arketypiska datorspråket på hög nivå (det vill säga ett som bevarar egenskaperna hos det naturliga, mänskliga språket), och det används fortfarande av miljontals programmerare. Många av systemen och applikationerna från PC- och Internet-epoken skrevs i C++. Trots allt är språket fortfarande kontroversiellt, till stor del för att det är notoriskt svårt att lära sig och använda, och även för att Stroustrups design tillåter utvecklare att göra allvarliga programmeringsmisstag i syfte att bevara sin frihet.

Stroustrup, sedan många år forskare vid AT&T Bell Labs, är nu professor i datavetenskap vid Institutionen för teknik, vid Texas A&M University, nära Houston.

Teknikgranskning : Varför är de flesta program så dåliga?

Bjarne Stroustrup : Vissa program är faktiskt ganska bra med alla standarder. Tänk på Mars Rovers, Google och Human Genome Project. Det är kvalitetsmjukvara! För femton år sedan skulle de flesta människor, och särskilt de flesta experter, ha sagt att vart och ett av dessa exempel var omöjligt. Vår tekniska civilisation är beroende av mjukvara, så om mjukvara hade varit lika dålig som dess värsta rykte, skulle de flesta av oss ha varit döda vid det här laget.

Å andra sidan, att titta på genomsnittliga kodbitar kan få mig att gråta. Strukturen är skrämmande, och programmerarna tänkte uppenbarligen inte djupt på korrekthet, algoritmer, datastrukturer eller underhållbarhet. De flesta människor läser faktiskt inte kod; de ser bara att Internet Explorer fryser.

Jag tror att det verkliga problemet är att vi (det vill säga vi mjukvaruutvecklare) befinner oss i ett permanent undantagstillstånd och griper efter halmstrån för att få vårt arbete gjort. Vi utför många mindre mirakel genom försök och misstag, överdriven användning av brutalt våld och massor av tester, men – så ofta – räcker det inte.

Mjukvaruutvecklare har blivit skickliga på den svåra konsten att bygga någorlunda pålitliga system av opålitliga delar. Problemet är att vi ofta inte vet exakt hur vi gjorde det: ett system har bara utvecklats till något minimalt acceptabelt. Personligen föredrar jag att veta när ett system kommer att fungera, och varför det kommer att fungera.

BARN : Hur kan vi fixa röran vi befinner oss i?

BS : I teorin är svaret enkelt: utbilda våra mjukvaruutvecklare bättre, använd mer passande designmetoder och design för flexibilitet och för lång tid. Belöna korrekta, solida och säkra system. Bestraffa slarv.

I verkligheten är det omöjligt. Människor belönar utvecklare som levererar mjukvara som är billig, buggig och förstklassig. Det beror på att folk vill ha snygga nya prylar nu. De inte vill ha besvär, vill inte lära sig nya sätt att interagera med sina datorer, vill inte ha förseningar i leveransen och vill inte betala extra för kvalitet (såvida det inte är uppenbart i förväg – och ofta inte ens då). Och utan verkliga förändringar i användarbeteende är det osannolikt att mjukvaruleverantörer kommer att förändras.

Vi kan inte bara stoppa världen i ett decennium medan vi programmerar om allt från våra kaffemaskiner till våra finansiella system. Å andra sidan är det dyrt, farligt och deprimerande att bara röra på sig. Betydande förbättringar behövs, och de kan bara komma gradvis. De måste komma på bred front; ingen enskild förändring är tillräcklig.

Ett problem är att akademiska skorstenar kommer i vägen: för många människor pressar något område som ett universalmedel. Bättre designmetoder kan hjälpa, bättre specifikationstekniker kan hjälpa, bättre programmeringsspråk kan hjälpa, bättre testtekniker kan hjälpa, bättre operativsystem kan hjälpa, bättre infrastruktur för mellanprogram kan hjälpa, bättre förståelse av applikationsdomäner kan hjälpa, bättre förståelse av data strukturer och algoritmer kan hjälpa – och så vidare. Till exempel kan typteori, modellbaserad utveckling och formella metoder utan tvekan ge betydande hjälp inom vissa områden, men drivs som de lösning med uteslutande av andra tillvägagångssätt, garanterar var och en misslyckande i storskaliga projekt. Människor driver vad de vet och vad de har sett fungera; hur kunde de annars? Men få har den tekniska mognad att balansera kraven och resurserna.

BARN : Tanken bakom C++ var att programmerare skulle arbeta hårdare i utbyte mot mer effektiv kod. Bell Labs ville ha ett språk som några riktigt smarta människor skulle använda för att skriva kod som skulle köras på datorer som Electronic Switching Systems (ESS) som inte var särskilt snabba. Idag finns det många mjukvaruutvecklare och datorer är väldigt snabba. Försämrar det poängen med C++?

BS : C++ designades inte specifikt för de stora växlingsmaskinerna, utan för ett stort antal applikationer. Bell Labs var hemmet för en otrolig mängd intressanta projekt som spänner över alla skalor och använder i princip alla typer av datorer och operativsystem. Men ja, den genomsnittliga Bell Labs-programmeraren var betydligt mer kapabel än de flesta människors föreställning om en genomsnittlig programmerare, och tillförlitlighet och prestanda (i den ordningen) ansågs vara betydligt viktigare än på de flesta andra platser.

Prestanda är fortfarande ett problem i många av de applikationer som jag är intresserad av: gränssnittens lyhördhet, start- och stängningstid för applikationer. Mjukvaruutvecklare har neutraliserat den häpnadsväckande prestandan hos modern datorhårdvara genom att lägga till lager på lager av överarbetade [mjukvara] abstraktioner. Vi verkar ha nått gränserna för linjär hastighetsökning för hårdvara, men i många fall skulle vi kunna vinna ett par storleksordningar tillbaka från mjukvaran.

Som sagt, C++ har verkligen blivit alltför expertvänligt i en tid då graden av effektiv formell utbildning för den genomsnittliga mjukvaruutvecklaren har minskat. Lösningen är dock inte att fördumma programmeringsspråken utan att använda en mängd olika programmeringsspråk och utbilda fler experter. Det måste finnas språk för dessa experter att använda – och C++ är ett av dessa språk.

BARN : Så här i efterhand, när du designade C++, var inte ditt beslut att byta ut programmerarens effektivitet, säkerhet och mjukvarutillförlitlighet för körtidsprestanda ett grundläggande misstag?

BS : Tja, jag tror inte att jag gjorde en sådan avvägning. Jag vill ha elegant och effektiv kod. Ibland får jag det. Dessa dikotomier (mellan effektivitet kontra korrekthet, effektivitet kontra programmeringstid, effektivitet kontra hög nivå, et cetera.) är falska.

Vad jag gjorde var att designa C++ som först och främst ett systemprogrammeringsspråk: jag ville kunna skriva drivrutiner, inbyggda system och annan kod som behövde använda hårdvara direkt. Därefter ville jag att C++ skulle vara ett bra språk för att designa verktyg. Det krävde flexibilitet och prestanda, men också förmågan att uttrycka eleganta gränssnitt. Min uppfattning var att för att göra saker på högre nivå, för att bygga kompletta applikationer, måste du först köpa, bygga eller låna bibliotek som ger lämpliga abstraktioner. Ofta, när människor har problem med C++, är det verkliga problemet att de inte har lämpliga bibliotek – eller att de inte kan hitta de bibliotek som är tillgängliga.

Andra språk har försökt att mer direkt stödja applikationer på hög nivå.

Det fungerar, men ofta går det stödet på bekostnad av specialisering. Personligen skulle jag inte designa ett verktyg som bara kunde göra vad jag ville – jag strävar efter allmänhet.

BARN : Hur förklarar du det faktum att C++ både kritiseras och förbittas av många programmerare men samtidigt används väldigt brett? Varför är det så framgångsrikt?

BS : Det glittriga svaret är: Det finns bara två typer av språk: de som alla klagar på och de som ingen använder.

Det finns mer användbara system utvecklade på språk som anses hemska än på språk som prisas för att vara vackra – många fler. Syftet med ett programmeringsspråk är att hjälpa till att bygga bra system, där bra kan definieras på många sätt. Min korta definition är korrekt, underhållbar och tillräckligt snabb. Estetik spelar roll, men först och främst måste ett språk vara användbart; den måste tillåta verkliga programmerare att uttrycka verkliga idéer kortfattat och prisvärt.

Den främsta anledningen till C++s framgång är helt enkelt att den uppfyller sina begränsade designmål: den kan uttrycka ett stort antal idéer direkt och effektivt. C++ var inte designat för att bara göra en sak riktigt bra eller för att förhindra att människor gör saker som anses vara dåliga. Istället koncentrerade jag mig på allmänhet och prestation.

Jag är säker på att för varje programmerare som ogillar C++ finns det en som gillar det. En vän till mig gick dock till en konferens där huvudtalaren bad publiken att med handuppräckning ange, en, hur många som ogillade C++, och två, hur många personer som hade skrivit ett C++-program. Det var dubbelt så många i den första gruppen än i den andra. Att uttrycka motvilja mot något du inte känner brukar kallas för fördomar. Dessutom är klagande alltid mer högljudda och säkrare än förespråkarna – förnuftiga människor erkänner brister. Jag tror att jag vet mer om problemen med C++ än bara om någon annan, men jag vet också hur man undviker dem och hur man använder C++s styrkor.

Och sedan förväntar du dig naturligtvis inte att förespråkare för språk som förlorade i konkurrens med C++ är artiga om det. Mjukvaruutveckling har inte den graden av professionalism - även om jag hoppas att det så småningom kommer att göra det. Vetenskapen är annorlunda i detta avseende: när ett nytt verktyg, teknik eller teori vinner fram ser människor det som framsteg. Inom mjukvara är bidrag från konkurrenter och föregångare inte allmänt erkända, uppskattade eller ens förstådda.

BARN : I Designen och utvecklingen av C++ , du hävdar att Kierkegaard var ett inflytande på din uppfattning om språket. Är det här ett skämt?

BS : Lite pretentiöst, kanske, men inte ett skämt. Mycket funderande kring mjukvaruutveckling är fokuserat på gruppen, teamet, företaget. Detta görs ofta till en punkt där individen är helt nedsänkt i företagskulturen utan utlopp för unika talanger och färdigheter. Företagspraxis kan vara direkt fientligt inställd till individer med exceptionell kompetens och initiativ i tekniska frågor. Jag anser att en sådan hantering av tekniska människor är grym och slösaktig. Kierkegaard var en stark förespråkare för individen mot mängden och har några seriösa diskussioner om vikten av estetik och etiskt beteende. Jag kunde inte peka på ett specifikt språkdrag och säga: Se, det finns 1800-talsfilosofens inflytande, men han är en av rötterna till min ovilja att eliminera egenskaper på expertnivå, att avskaffa missbruk och att begränsa funktioner till stöd endast användningar som jag vet är användbara. Jag är dock inte särskilt förtjust i Kierkegaards religiösa filosofi.

BARN : Vad ångrar du mest?

BS : Ingen ånger! Jo, visst drömmer jag om vad jag kunde ha gjort annorlunda och bättre, men seriöst, vem är jag att gissa, säg, årgång Bjarne 1984? Han kan ha varit mindre erfaren än jag, men han var inte mindre smart, förmodligen smartare, och han hade en bättre förståelse av ordet 1984 än jag. C++ har använts för att bygga många system som förbättrar våra liv, och det har haft en betydande positiv inverkan på senare språk och system. Det är något att vara stolt över.

Klick här för att läsa vår andra intervju med Stroustrup.

Dölj