Åtta programspråk som vi älskar att hata

Att man inte ska tappa humöret är lätt att säga – men inte för oss som försörjer oss genom att kämpa med datorer. Alla som har brottats med ett programspråks besynnerliga logik vet vad jag talar om.

Visst – varje programspråk har beundrare som lovsjunger dess intuitiva struktur. Och visst – nästan alla programspråk har skapats av någon som hade en storartad plan för hur programmering skulle förenklas. Och de lyckades ofta – i snäv bemärkelse. Avigsidan är att det brukar finnas bieffekter som inte är lika lyckade.

För hur bra ett programspråk än är så finns det alltid något krångel, någon irriterande egenhet eller inkonsekvens som kan förstöra en hel kväll, en hel weekend – eller ett helt bokföringsår.

Och vi programmerare kan inte göra så mycket åt saken. Den installerade basen kan vara för stor för att vi ska kunna dumpa ett irriterande språk. Chefen kanske älskar stacken så mycket att hen struntar i nödropen från kodaporna. Och dessutom är det svårt att komma överens om vilket språk man ska ha i stället.

Den bistra sanningen är att vi kanske inte har något val. Vi använder redan de bästa verktyg som människohjärnan kan skapa. Från Gödel och Turing har vi fått lära oss att logiska mekanismer har skarpa kanter. Och visst kan det vara vårt eget fel ifall vi programmerar dåligt. Men när programspråket tvingar våra hjärnor till akrobatiska yogaställningar är det orimligt att skylla på hjärnorna.

Men om man är införstådd med begränsningarna i olika programspråk blir det åtminstone enklare att kringgå dem. Om vi inte kan kasta ut programspråken från våra kodförråd kan vi försöka förstå och föregripa deras egenheter. Och ibland hjälper det att klaga. Här är åtta programspråk som vi älskar att hata – men som vi inte klarar oss utan.

C

C är ett programspråk som kanske borde kallas för ”portabel assembler” snarare än för ett komplett språk. Är det någon som gillar att skriva separata headerfiler? Har någon använt preprocessorn för något krångligt utan att nästan mista förståndet?

I teorin ska vi kunna använda pekararitmetiken för att göra smarta saker, men är det någon som törs göra något mer än att allokera datastrukturer? Är det över huvud taget en bra idé att vara alltför smart med pekare? Det är så man förstör kod. Och om man lyckas vara smart brukar man behöva skriva en mycket lång kommentar för att dokumentera. Vilket förbrukar den tid som du har sparat genom att vara smart. Och är det någon som kan komma ihåg alla reglerna för hur man skriver C-kod och undviker alla tänkbara säkerhetsluckor, som buffertöverfyllningar?

Men vi har inget val. Unix är skrivet i C, och det körs på de flesta mobiltelefoner och det mesta i molnet. Visserligen behöver inte alla som skriver kod för dessa plattformar använda C, men någon måste hålla reda på alla asterisker och klammerparenteser, annars går det åt pipan.

Och nu börjar även Unix-människorna att överge C. På senare tid har en del patchar för Linux-kärnan kommit i Rust. Utvecklarna anser att det språkets striktare uppbyggnad gör att man slipper några av de säkerhetshål som C-utvecklarna lämnar efter sig när de är smarta. Men övergången kommer att ta många år, och vi kommer troligen att skriva och jaga reda på C-pekare även när vi har slutat med Cobol.

Javascript

Javascripts skapare ville hitta på något modernt. Tyvärr dömde de oss, trots sin briljans, att för all framtid räkna klammerparenteser, hakparenteser och vanliga parenteser – och att se till att de är korrekt nästlade, förstås. Alla anonyma funktioner, omslutningar och JSON-strukturer ger våra fingrar rikligt med gymnastik på tangentbordet.

Sedan har vi alla besynnerliga detaljer. Om x är en sträng som håller tecknet för 1 så kommer x+1 att ge oss strängen 11 och x–1 ger oss talet noll. Och är det någon som minns skillnaden mellan false, null, NaN och undefined? De verkar likna varandra, men varför måste Javascript ha alla fyra? Och varför uppför de sig inte konsekvent?

Och sedan har vi de hastiga förändringarna. Ny Javascript ser ofta inte alls ut som gammal Javascript. Det beror på nya funktioner för uppackning och packning, spreading och unspreading av objekt och arrayer av objekt. Koden ser ut som ett hav av dubbla citat, trippelcitat, dubbla frågetecken och tre punkter. Kom ihåg att “=>” är en pil som anropar en funktion, men att “>=” är ett sätt att jämföra tal. De nya funktionerna är jättebra om man gillar dem, men vi andra blir bara förvirrade.

Hur som helst. Internet, webben och en centrifugiljon webbläsare tänker inte försvinna. Och sedan dök det supersmarta Node.js-teamet och byggde en plattform för körning av Javascript på servrar. Nu har det blivit ett av de mest populära sätten att bygga nya, progressiva webbapplikationer. Kodarna gläds åt isometrisk kod som kan köras både i webbläsare och på servern. Det spelar ingen roll hur utvecklarna klagar. Vi kommer att hålla på med anonyma funktioner och closures i årtionden.

PHP

PHP är egentligen inte ett programspråk. Det är snarare att verktyg för att göra statisk html lite smartare. Man kan lagra information i en databas och konkatenera den med statiska taggar. Det kanske finns annat också, men det verkar som om allt vi gör med PHP är att klistra ihop strängar som vi hämtar från en databas.

Eller – så var det förr. Några av PHP:s skapare har lyssnat på våra klagomål och lagt till finesser som starkare typning, smartare strängar och förbättrad integrering med MySQL. PHP har verkligen blivit bättre, och det klarar mer avancerade kodbaser. Och allt detta låter ju fint, men bli inte alltför entusiastisk. För samtidigt som utvecklarna lägger till nya finesser så avvecklar de en del av de gamla. Vilket innebär att det bara är en tidsfråga innan gammal kod slutar att fungera.

Att bråka om leksakskod eller småbarnssyntax är inte värt besväret. Det mesta på webben – Wordpress, Joomla, Drupal – levereras genom PHP-kod. Sedan har vi Facebook (Meta), som till stor del är skriven i PHP, och som fortsätter att suga i sig en stor del av vår tid. Vi ska bara vara tacksamma för att Facebook byggde Hiphop Virtual Machine (HHVM) och därmed inspirerade Zend att skapa PHP 8.2.

De här nya PHP-maskinerna är ofta dubbelt så snabba, vilket kommer att spara miljoner på elräkningen och därmed garantera att vi kommer att fortsätta med PHP i många år.

Cobol

Cobol såg dagens ljust 1959. Det borde vara skrotat sedan länge, med tanke på språkets komplexa syntax med hundratals begränsade ord. Men Cobol-älskarna envisas med att ta fram nya versioner. De lånar idéer från andra språk och spikar fast dem i ett ramverk som är mer än 60 år gammalt. Visste du att det finns ett Cobol 2014? Det har dynamiska tabeller – något som folk har försökt stoppa in i Cobol sedan 2002. Och sedan har vi Visual Cobol 8.0 som kan länka ihop ditt Cobol med Java- eller Dotnet-kod. Så att det blir enklare att fortsätta köra din gamla kod tillsamman med mer moderna stackar.

Vi har förvisso bättre verktyg för att skriva affärslogik som manipulerar databaser. Men ingen tycks vilja göra sig besväret att byta, för det är enklare att köpa en större dator och fortsätta att köra Cobolkoden. Cobolvännerna brukar påpeka att gammal logik aldrig slits ut, så varför riskera att tillföra fel genom att försöka modernisera? Arbetsmarknaden för Cobolprogrammerare är mycket god. Det finns Cobol-jobb på försäkringsbolag och krigsmaterialtillverkare överallt. Folk som har kört stordatorer sedan de infördes använder fortfarande Cobol för att sköta sina jobb. Så även om datavetare förfasar sig står arbetsgivarna i kö, och cheferna säger: ”Om det inte är trasigt ska du inte laga det. Köp bara en större stordator.”

R

R togs fram för datavetenskap och används fortfarande flitigt av datavetare. Fast en del har gått över till Python eftersom de tycker att R är för mystiskt. En del traditionella programmerare avskräcks av R:s interaktiva upplägg – det som ibland kallas för ”skissblocksläge”. Den som vill lägga till några siffror eller räkna ut standardavvikelsen i en datamängd behöver bara mata in några siffror i R:s kommandotolk så kommer svaret direkt. Så R är inte bara ett programspråk, det är ett verktyg.

Språket kan verka konstigt och förvirrande. Många av instruktionerna är gjorda för att vara snabba och koncisa. Det är bra om man jonglerar med provrör på labbet och vill att R ska räkna ut ett tal samtidigt. Interpunktion som kommatecken är väldigt kraftfullt. En gång upptäckte jag att räddningen ur min nöd bestod i att lägga till ett kommatecken till. Detta efter timmar av huvudvärk.

R:s syntaktiska egenheter och datastrukturer driver datavetare till vansinne – och kommer att göra så även i framtiden. Det finns en installerad bas av R-paket och bibliotek som är oemotståndlig. Många av paketen har öppen källkod och är beredda att svara på dina frågor, eller på din chefs nycker, med en snabb graf. Det är helt enkelt mycket lättare att slita sitt hår när man ska begripa sig på dubbelparenteserna i R än att skriva om alla dessa paket i ett annat programspråk.

Java

Okej, den virtuella maskinen och biblioteken är från 1990-talet. Men Javas syntax lever kvar i 1970-talet, då C skapades. Automatisk minneshantering kan synas vara ett stort steg framåt – ända tills din kod bestämmer sig för att ta paus medan skräpminnesinsamlingen tar över. Android-utvecklare brukar utbyta tips om hur man ordnar skräpminnesinsamling i god tid – så att det inte sätter igång mitt i något viktigt, som när man ringer till 112.

Javaprogrammerare har klagat i många år på problem med språket, och Oracle har tagit itu med åtminstone en del av dem. Men det har skapat nya problem. En del nyare kod och nyare bibliotek fungerar inte med gamla virtuella maskiner. Själv har jag ägnat en helt dag åt att kämpa med java.lang.UnsupportedClassVersionError, men jag kunde inte hitta någon permanent lösning. Det är nästan som om varje ny version av Java efter 1.4 är ett nytt språk.

Det kommer nya versioner av Java med nya finesser i snabbare takt än någonsin tidigare. Det kan verka som om de skivar korven tunnare, men fortare. Och det är utmärkt om man behöver de nya finesserna, men det skapar mer och mer krångel för oss som ska se till att koden är stabil och körbar.

Och det här spelar ingen roll. Java är grundvalen för webben och för mobiltelefoner. Det är fortfarande det första programspråk som många lär sig. Mängden bibliotek är mer omfattande och mer värdefull än för nästan något annat språk. Inte bara det. Många finurliga nya programspråk bygger i hemlighet på Java. De kompileras nämligen till Javas bytekod. Java kommer alltid att ingå i stacken. Det är bara att vänja sig.

Python

Python är ett modernt programspråk som yngre utvecklare gillar. Interpunktionen är måttlig och koden ser lite renare ut än vanligt. Vad finns det att klaga på? I stället för att räkna och para ihop klammerparenteser för att avgränsa kodblock räknas vi whitespaces och se till att kolumnerna passa ihop. Se bara till att använda ett jämnbrett typsnitt!

Men till att börja med så är det ett hopp mellan Python 2.7 och 3.0. Det är en stor förändring, men inte den enda. Många senare versioner har ändringar som kan knäcka din kod. Funktioner som förr gav svaren 0 eller 1 ger svaren sant eller falskt i Python 3.6. Ord som “async” och “await” har blivit reserverade nyckelord i version 3.7. Teamet bakom Python har dock hört gråten från kodare som inte kan hålla reda på versionerna. Så nu tycks de flesta av förändringarna vara tillägg och nya finesser som inte stör din gamla kod.

Visst, teamet har inget val om det vill fortsätta att förbättra språket. Men alla som vill underhålla ett större projekt och jobba med äldre bibliotek kommer att behöva hålla ögonen öppna i all framtid för att hålla reda på vilken version av Python de har.

Ännu mer komplicerat blir det eftersom många populära utföranden av Linux använder Python för systemuppgifter. Så även som du kan hålla reda på versionerna i din egen kod kan Linuxdistributionen köra något annat. Så sent som i fjol slutade min Pythonkod att fungera när jag uppgraderade den underliggande versionen av Linux. För även den Pythonversion som jag hade i burken uppdaterades i tysthet. Hoppsan. Men språket är så inkört att vi sitter där med det.

Invändningar spelar ingen roll, för i de mjuka vetenskaperna har man fallit för Python. Biologer och ekonomer anser att Python är det enda rätta. En del vill till och med att Python ska vara obligatoriskt i prospekt för aktier och obligationer. På så vis ska bankfolket kunna lura skjortan av oss med Python i stället för med juristspråk. Triumftåget är igång och det är fullt med ekonomer och biologer.

Swift

För att ladda en Iphone behöver du en speciell kontakt. Och om du vill programmera den – ja, då behöver du ett speciellt språk. Apple vill alltid göra allting på sitt eget sätt. Nu är det inte bara Apple som använder Swift. Det finns en liten grupp som tycker att Swift är toppen att köra på servrar. Men bortsett från det så är Swift något som bara används inom Apples runda väggar.

Som programspråk är Swift bättre än Objective-C som det till stor del har ersatt. Interpunktionen är vettigare, inmatningen är bättre. Header-filerna har försvunnit och minneshanteringen är mer automatiserad.

Men trots alla dessa förbättringar är livet fortfarande hårt för utvecklarna. Språket är omfattande, och därför svårt att lära in. Handböckerna består av hundratals sidor som räknar upp alla nya finesser från invecklade typer till tuplar och protokoll. Det är omöjligt att räkna upp alla kluriga och dunkla idéer som har hängts på detta slagskepp.

Andra företag har gjort på andra sätt. Google försökte göra Go så enkelt som möjligt för att koden skulle bli enkel att läsa och förstå. Swifts otaliga smarta finesser kan säkert spara tid de gånger då programmeraren vet hur man använder dem. Men det är inte så säkert att nästa programmerare som läser koden begriper vad den går ut på. Swift har så många smarta funktioner att det är nästan omöjligt att lära sig alla.

Bästa exemplet på denna överdrivna klurighet är att alla som kodar kan skapa nya operatorer med användning av vilka unicode-tecken som helst. Och visst är det kul att man kan använda emojier i programkod, i synnerhet om det är några av de mer färgstarka, men nästa person som läser koden lär bli undrande.

Men inget av detta spelar någon roll, för Apple älskar sitt eget programspråk lika mycket som Apple älskar att gå sin egen väg. Visst skulle det vara fint om man kunde utbyta kod med världen utanför Apples runda fästning, men det kommer inte att ske. Så bästa lösningen är att läsa på om Swift och kanske sedan hålla sig till en mindre delmängd av funktionerna.