Källkod? Maskinkod? Bankomatkortskod?

Vad är då det här ”kod” som data-nissarna pratar om hela tiden?
Jo, så här ”enkelt” är det: En dator är i grund och botten en väldigt väldigt enkel maskin. Om man skalar bort rätt många abstraktionsnivåer så har man en generell maskin som stegar sig igenom en lista med väldigt väldigt simpla instruktioner av stilen läs en bit data, skriv en bit data, lägg ihop två bitar data, gör något om en bit data är samma som en annan bit data. Det är de verktyg maskinen behöver för att visa videofilm, animera grafer i excel, räkna på vädersystem och styra målsökande raketer. Låter rätt absurt eller hur? Det är det här som folk lite släpphänt reducerar till att säga ”datorer jobbar bara med ettor å nollor”.

Vill man vara elak så kan man påpeka att en dator inte ens vet vad ett och noll är, det är värre än så. Den jobbar oftast med låg eller hög spänning genom ett antal miljoner mikroskopiska transistorer på ett kiselchip. Det är vi människor som kallar de olika spänningslägena ett och noll för att det är lättare för oss. Vi blir väldigt lätt förvirrade och vi är lata. Alltså gillar vi att använda oss av abstraktioner. Vi anser att effekten av att gå till köket, vrida på kranen och hålla en kastrull under tills den har vatten i sig, lägga några ägg i kastrullen, lyfta över den till spisen, vrida på rätt reglage och vänta tills vattnet bubblar plus några minuter till är ungefär samma som om vi hänger en gryta med soppa över en brasa och väntar tills den bubblar. Vi säger ”aha! saker som är lika!”, kallar det genast ”att koka” och så slipper vi beskriva varje litet steg varje gång vi vill att någon fixar frukost åt oss. Det räcker med att säga ”kan du koka lite kaffe” till vår kollega så förstår han vad vi vill att han ska göra.

Datorer däremot är som jag sagt tidigare fantastiskt korkade men lydiga. De behöver exakta instruktioner för varje litet irriterande delmoment. Den här listan med de väldigt väldigt grundläggande steg för steg-instruktionerna som vi visualiserar som ettor och nollor eller långa kedjor av siffror i udda talbaser kallas maskinkod. Det är helt enkelt en instruktion på datorns eget språk.

Programmerare är dock inte datorer. De tenderar snarare att vara smarta men olydiga och allt som oftast lata och lättuttråkade. De gillar helt enkelt inte att behöva skriva alla dessa små petiga beskrivningar om och om och om igen. Det är ju jättetråkigt och vem har tid med sånt? Det är ju en jätterepetitiv uppgift som man borde ge till någon korkad men lydig… aha!
Varför inte låta datorer skriva maskinkoden? Det låter ju som en perfekt uppgift för dem! Sagt och gjort så löser man problemet genom att skriva program som skriver program.

Eller ja… man har förskjutit problemet i alla fall. För nu måste man ju få programmen att skriva program som gör det man vill. Men det är ju ett mycket behagligare problem. Man kan nämligen se till att höja abstraktionsnivån steg för steg. Först ser man till att hitta på ett språk som man själv kan förstå, sen ser man till att traggla sig igenom den tråkiga uppgiften att skriva ett program på datorns språk som klarar av att sammanställa de instruktioner man skriver på sitt eget språk och översätta dem till datorspråk. När man sen gjort det så kan man i fortsättningen skriva alla sina program på sitt eget språk och låta sitt sammanställnings/tolk-program (kompilator) göra om dem till maskinkod som datorn förstår. Jättepraktiskt!

Alltså, ”människospråk” stoppas in i kompilatorn och ut kommer maskinkod. Den där byttan ”människospråk” man börjar med? Det är det vi kallar källkod. Källkod är helt enkelt en samling med instruktioner i ett format som ska vara läsbart för människor som sen omvandlas till ett format som ska vara läsbart för datorn.

Programmeringsspråk

De här programmeringsspråken då… varför finns det en massa sådana? kan vi inte bara skriva ett program som förstår vanlig vettig svenska eller engelska?
Nja… det är inte särskilt lätt faktiskt. Vanliga människospråk har en massa konstiga vagheter och inbyggda liknelser som gör att det är väldigt svårt att vara så exakt i sin tolkning som en maskin behöver. Vi är också rätt bra på onödigt ordbajseri. Se bara den här bloggposten som exempel. Datorer behöver inte känna att du tycker om dem eller veta vad du gjorde i helgen. De är så nöjda så med exakta instruktioner. Så vi ger dem det i den mån vi kan. Varför försöka få en dator att förstå vad vi menar med ”Kan du vara snäll och gå igenom den där listan och ge mig skillnaden mellan den högsta temperaturen och den lägsta” när man istället kan formulera sig mer koncist
(- (max templist) (min templist)) om man pratar något Lisp-liknande eller kanske get_max_value(templist) - get_min_value(templist) i något C/C++-liknande språk.

Trots att man lätt kan få för sig att källkod är någon konstig sörja som skrivs för att vara så mystiskt som möjligt så är sanningen alltså den helt omvända. Den större delen av all källkod som skrivs är faktiskt formulerad för att vara så tydlig och entydig som möjligt.

Abstraktionsnivåer och paradigmer

Men varför är de då så många de där språken?
I många fall av ungefär samma skäl som det finns så många olika människospråk.
Olika människor i olika kulturer med olika avsikter har olika behov av ett språk. Folk i en nomadisk ökenkultur har andra saker att uttrycka än vattenreningsingenjörer i miljoninvånarstäder. På samma sätt har folk som vill göra små roliga spel som blinkar på en hemsida andra behov än forskare som försöker göra jätteberäkningar på komplexa vädersystem.

Ibland är det nödvändigt att ha väldigt hård koll på vad maskinen faktiskt gör och då håller man sig kanske på en väldigt låg abstraktionsnivå som ligger så nära maskinens språk som möjligt så att man kan veta nästan exakt vad den gör hela tiden. De första programmeringsspråken som kallades assemblerspråk hamnar i den här kategorin. De är i princip en mer läsbar form av maskinkod där de numeriska koderna för olika grundläggande instruktioner bytts ut mot mer lättlästa förkortningar som ”JMP” och ”ADD”.

Börjar man komma upp i lite högre programkomplexitet så blir det snabbt svåröverskådligt och jobbigt att hålla på med assembler så då kliver man upp ett steg i abstraktionen till språk med högre abstraktionsnivå. Där klumpar man ihop ofta förekommande kombinationer av maskinkodsinstruktioner till enkla uttryck så att programmeraren inte ska behöva återuppfinna hjulet varje gång han skriver något. Visst… i praktiken så kanske datorn för att skriva ut lite text på en terminal behöver hämta en teckenkod från någonstans i datorminnet, kolla upp den koden mot en tabell av instruktioner för vilka siffror som ska skickas till grafikkortet för att det ska rita en bokstav på skärmen och sen upprepa detta tills du fått ut alla bokstäver du ville så att de går att läsa. Men när man nu listat ut hur man ska beskriva för datorn hur den ska göra detta så blir det lättare att till nästa gång helt enkelt säga ”När jag säger print "hej där!" så menar jag att du ska följa alla de där steg för steg instruktionerna jag sa sist.

Programmeringsspråket C är ett typiskt mellannivå-språk som ligger ett par abstraktionsnivåer över maskinkod men där man oftast rätt lätt kan föreställa sig hur kompilatorn kommer översätta en given bit av din källkod till maskinkod.

Problemet med mellannivåspråk är att de fortfarande är lite för klumpiga att arbeta med i längden. Väldigt många saker man skriver i dem återkommer väldigt ofta. Det är en hel dem mönster som återkommer om och om igen. Upprepning av kod är inte bara tröttsamt för programmeraren utan också en vanlig källa till fel. Andra saker är helt enkelt väldigt jobbiga att tänka omkring om man hela tiden måste hålla reda på hur man ska representera det så att datorn kan förstå det.

Vi kan ta en jämförelse med dans till exempel. När man lär sig någon sorts dans som total nybörjare så behöver man få förklarat precis vilka rörelser man ska göra var och hur. Det är bra och praktiskt men väldigt väldigt otympligt för något mer komplicerat än grunderna. När man sen har skaffat sig en förståelse av hur de olika dansstegen utförs så har man möjligheten att sätta ihop koreografier genom att prata om dansstegen utan att bli bländad av komplexiteten om man faktiskt skulle behöva beskriva varje enskild muskelrörelse som varje enskild deltagare ska utföra vid en given tidpunkt.

Roligt nog så finns det väldigt många olika sätt att lösa problemet med hur man ska försöka göra de här abstraktionerna. Det har lett till att det finns en himla massa olika programmeringsspråk för olika ändamål och med olika tankar bakom. Vissa av dem är väldigt spridda och i brett bruk, andra används bara av ett fåtal personer på någon instutition. Som allt annat går det mode i programmeringsspråk också så att något som anses som aldeles förträffligt idag kanske är alldeles förlegat om ett år (som tur är brukar det gå i lite längre cykler än så). Rätt mycket handlar också om personliga preferenser hos enskilda programmerare eller företag vilket gör att man kan få väldigt livliga diskussioner om vilket språk som är ”bäst”. En fråga som kan debateras i evigheter då den saknar ett absolut svar. Olika språk har sina olika styrkor och brister och det finns inget enskilt språk som är bättre än alla andra på alla punkter.

Vissa språk är dock mer användbart att ha koll på än andra på grund av hur vanligt förekommande de är. Programmeringsspråket C är fortfarande det absolut vanligaste språket att skriva drivrutiner och andra program där exakthet och liten storlek är viktigare än lättheten att göra olika saker. C++ och Java är så vitt jag vet kungarna av språk att skriva applikationer i. Om du vill få dina hemsidor att göra roliga saker i din webläsare så har du att välja på det grovt underskattade språket JavaScript eller eventuellt skriva små Flash-program i språket ActionScript. Alternativt så kan du göra mer komplicerade saker redan på webservern i språk som PHP, ASP, JSP, Python eller Perl

I vilket fall som helst så lönar det sig att hitta ett språk där det är lätt att uttrycka det du vill göra. Det förenklar ditt arbete något otroligt.

Tillfälligt avbrott

hmm…
Skulle jag vara klar innan midnatt? Aj då.
Jag får nog betrakta det här som ett färdigt segment och återkomma senare i veckan med mer. Jag har trots alls ett jobb att gå till om några timmar. Så kan det gå. Hoppas jag inte förvirrat allt för mycket nu. Är det något som är väldigt otydligt så finns alltid möjligheten att ställa frågor i kommentarerna!

Programmering är generellt formuleringen av tydliga instruktioner för någon eller något att följa.

När vi pratar om programmering är det allt som oftast datorer det handlar om men rent principiellt så är det inte någon fundamental skillnad mellan att säga åt en dator att rita en graf över vattentemperaturer på badplatser än att förklara för en människa hur den ska göra det. Skillnaden är att datorn är dum, fantasilös och väldigt snabb.

Varför går det då inte att bara säga till datorer ”rita en graf över vattentemperaturerna på sveriges största badplatser” och så gör den det? Svaret är att det gör det, men man måste se till att datorn vet vad rita innebär, vad en graf är och att den vet både vilka badplatserna är, hur temperatur betecknas och att du antagligen vill att den andra delen av stapeln är tid.

Om det tycks väldigt krångligt så kan du ju fundera över hur många år det tog dig att lära dig att rita en graf från grunden. Hur gammal var du när du först förstod vad läraren menade? Troligen en bit in i tonåren. Så datorn är egentligen väldigt väldigt snabb på att lära sig, men den kan väldigt lite från början.

Lite historik

Faktum är att bilden vi har av de första datorerna som stora rum av radiorör som blinkar och har mindre beräkningskraft än din första mobiltelefon är en sanning med modifikation. De första datorerna betecknades inte som ”computers” utan som ”electronic computers” och däri ligger en idag föga känd faktoid. Begreppet ”computer” har nämligen funnits åtminstone sedan 1600-talet då det benämnde en person som sysslade med att utföra beräkningar och då inte nödvändigtvis en högt utbildad forskare utan ofta någon som bara fått grundläggande instruktioner i hur den skulle utföra vissa repetitiva uppgifter.

Varför då? Jo, redan långt innan elektroniken var med på kartan hade man stora behov av tabeller för att kunna göra vissa uppskattningar till exempel i samband med beräkningar av försäkringspremier eller navigation. Försäkringsbolaget Lloyds of London som någon kanske hört talas om grundades till exempel 1688 vilket innebär att de fått förlita sig på handberäknade tabeller i nästan tre hundra år.

Fortfarande långt in på mitten av 1900talet utfördes en stor del av de beräkningar som samhället behövde (ekonomisk statistik, ballistiska beräkningar osv osv) av stora mängder människor som satt antingen med papper och penna eller med mekaniska räknehjälpmedel. När ni ser en film från andra världskriget där folk går igenom stora rum med mestadels kvinnor framför saker som ser ut som skrivmaskiner kan det tänkas att det rätt ofta är just ”computers” ni ser. Fascinerande inte sant?

Programmering har med andra ord funnits rätt länge. Om man vill vara väldigt generös så minst från 1600talet. Både i formen av instruktioner till mänskliga räknemaskiner och några hundra år senanare i form av hålkort som användes för att styra mönster i automatiserade vävmaskiner. Till och med om vi vill vara snålare och säga att vi med programmering bara räknar formulering av algoritmer för inmatning i en generaliserad beräkningsmaskin så hamnar vi en bit bak i tiden. Nej, vi pratar inte Turing nu utan hundra år tidigare runt 1840 då countess Ada Lovelace beskrev hur Charles Babbages analytiska maskin skulle kunna instrueras att utföra avancerade matematiska beräkningar.

För de flesta som är intresserade av att lära sig programmering är detta dock endast kuriosa. Programmering så som vi tänker på den idag började först bli intressant utanför akademiska cirklar en bit in på andra halvan av 1900talet och egentligen något som klev in på den stora scenen som något som förekommer i vårt vardagsliv runt millenieskiftet i samband med persondatorrevolutionen och den explosionsartade tillväxten av internet och webben.

Programmering idag

På det stora hela kan man säga att programmering idag är ett väldigt brett område som berör rätt många i vardagen. Allt ifrån folk som livnär sig på att skriva komplicerade affärssystem eller chatprogram till folk som vill få saker att röra på sig på sin hemsida eller vill få excel att räkna ut hur mycket pengar de spenderat den här månaden.

Det kan tyckas som väldigt olika saker men i grund och botten är det väldigt lika saker.

Allt som oftast ges instruktionerna till datorn i en textform formulerad för att vara så otvetydig som möjligt (datorer är inte så bra på tvetydighet) men samtidigt så läsbar som möjligt för människor. Den här formen av programmet som är läsbar och skrivbar av människor brukar generellt kallas källkod. Denna källkod består i princip av tre olika beståndsdelar: instruktioner, data samt olika former av punktuation och andra kontrolltecken för att göra det lätt för datorn att förstå gruppering och indelning av våra instruktioner. Om syftningsfel är förvirrande för människor så kan de vara helt katastrofala för en dator.

Tänk dig den där människan på kontoret som verkar ha någon form av störning som gör att han alltid tolkar dig så bokstavligt att det blir jättefel. Visst är det frustrerande? Datorer är värre med en faktor hundra ungefär. Nu kanske det är lättare att förstå varför den stackars IT-killen ansvarig för ert ekonomisystem sitter och ser så sliten ut framför sin skärm full av konstiga tecken och varnings-rutor. Han har troligtvis spenderat de senaste timmarna med motsvarigheten till att försöka lära en autistisk apa inte bara trycka på en knapp för att få en banan utan sen också använda bananen för att laga flygande jakob åt hela avdelningen.

Programmering bara för nördar?

Så är det bara att ge upp då och inse att livet inte behöver göras mer komplicerat än det är? Man kanske ska lämna programmerandet till de masochistiska personerna som väljer att viga sitt liv åt såna här övningar i futilitet?

Nej, inte nödvändigtvis.

Det fina i kråksången är nämligen att man inte behöver ge sig på hela kakan på en gång.

Man kan nämligen göra rätt mycket roligt utan att lära sig allt för mycket. Att skriva en konkurrent till Microsoft Word kräver eventuellt att du offrar ett antal kor till någon ohelig gudom men för att få excel att rita dina grafer utifrån dina datatabeller eller att få din webbläsare att göra något roligt när du klickar på en knapp kräver på sin höjd en tillräcklig förståelse för hur programmering fungerar för att veta vad du ska googla på och vilken källkods-stump du ska klippa och klistra var.

Min plan är att om du fortsätter läsa kommande inlägg i den här artikelserien så ska du åtminstone ha tillräcklig hum om hur man gör för att vara farlig och om jag gör mitt jobb bra så ska du till och med kunna göra någon nytta.

Och om inte annat så har jag förhoppningsvis åtminstone roat någon på vägen.

Nästa gång så tror jag att vi ger oss på antingen skillnaden mellan programmeringsspråk eller algoritmer, data och/eller funktioner beroende på i vilken ordning jag tror jag kan förklara koncepten på tydligast sätt. Häng med

Och när jag då ändå håller på med sånt jag är dålig på så kan vi ju gå vidare till nästa sak, pedagogik. Jag är notoriskt förvirrad, disträ, lättfrustrerad och dålig på att lära ut saker särskilt när det handlar om större projekt som behöver struktureras upp för att ha något värde. Ännu värre blir det när det faktiskt handlar om något jag är passionerad omkring då det plötsligt blir mycket viktigare för mig att folk förstår. Ska vi kröna bakverket av saker som krånglar till det så kan vi ju också se till att det är något som andra bryr sig relativt lite om.

Låter lite som ett recept för ett mentalt sammanbrott inte sant?

Ja men sånt är ju alltid kul!

Härmed annonserar jag då mitt åtagande att publicera en serie av artiklar/blogginlägg som ska förklara programmering för en oinsatt publik. Först och främst på en abstrakt nivå som förklarar vad programmering är och varför det fungerar som det gör. Sen vidare till att förklara begrepp som ”syntax”, ”data”, ”funktioner”, ”kompilering” osv. Lite tittar  på  olika programspråk och paradigmer och kanske till slut lite exempel på faktisk programkod som gör saker.

Är det något som ni undrar över och vill att jag förklarar vidare eller tar upp senare så lämna en kommentar. Jag ska försöka täcka ämnet så väl jag kan men räkna med viss förvirring.

Temat är alltså:

Utbränd Opedagogisk Autodidakt Datanörd Med ADHD Förklarar Grundläggande Programmering

Inte nog med att jag åtar mig detta, jag sätter dessutom som mål att posta minst ett avsnitt i veckan fram till augusti. Första inlägget bör komma senast onsdag.

Docendo discimus

Ska göra ett litet försök att blogga igen. Har en artikelserie jag vill ge ett försök bara för att kunna sluta fundera på om jag borde skriva den eller inte. Jag ger inga som helst löften om att den kommer att fullföljas eller vara användbar men jag ska se om jag inte kan få ur mig något i alla fall