@FT: The last real programmer

[Horizon]

Tackar för ett utförligt svar! Jag skulle verkligen vilja jobba med programmering (eller åtminstone kunna leka med det på fritiden), men det ligger liksom inte för mig. Jag är dålig på att skapa den typen av "saker", är mer av en end user när det gäller datorvärlden. Däremot är jag bra på att skapa lärande hos elever, undrar om det finns någon koppling som man kan utnyttja?

[griffin]

Det tror jag! Att skapa lärande är en gåva i sig och något som tyvärr många av dina kollegor verkar sakna eller ha förlorat på vägen.

En sak du direkt kan tillämpa som "end user" av rang är vikten av att vara kritisk (gäller ju iofs allt) på ett konstruktivt sätt. Ställa frågor. Inte nöja sig med ett svar om det inte verkar vettigt eller förståeligt.

Programmering, i min värld åtminstone, handlar om problemlösning. Det är lite som attt bygga lego. Man har en låda med bitar och man har något man vill bygga. Sen gäller det att inte bara hitta rätt bitar (vilka ÄR rätt bitar?) utan sätta ihop dem på ett sätt så att resultatet blir det önskade (och vad är det?). Som yrkesverksam programmerare så bygger man saker andra vill ha istället. Och oftast utan att de kan beskriva vad de vill ha, bara vad de inte vill ha - i bästa fall.

Programmeringsspråk är just vad de låter som. Språk. Med syntax och grammatik. Däremot, till skillnad från talade språk, är deras syntax och semantik striktare, mer begränsad och lämnar lite eller inget utrymme för "utsvävningar". Många som vill programmera fokuserar för mycket på språket och för lite på vad det är för problem man ska lösa. Om problemet är att någon vill ha en kopp kaffe, kanske inte lösningen är att bygga en kaffebryggare utan köpa en kopp kaffe i fiket? Eller blanda lite snabbkaffe eftersom det finns i skåpet? Ser så många exempel där man förespråkar sitt "favoritspråk" för det har fördel X eller Y. Och det är bra: har man ett favoritspråk kanske man också är bra på det. Och hellre lösa ett problem med verktyg man är van vid än att göra ett sämre jobb med verktyg man inte kan (alls). Samtidigt måste man som programmerare våga ifrågasätta valet av verktyg ibland också.

En sak du definitivt kan ta med dig till dina elever om de är intresserade av programmering är följande (och ta det från en som undervisat i programmering och gjort datorspel professionellt): vill man lära sig programmering ska man välja ett språk som är någorlunda enkelt att förstå sig på, utan att det för den skull gör "allt" jobb åt en (då lär man sig ju inte heller). Ser så många tragiska exempel på folk som i sin iver att göra t.ex. häftiga spel börjar med C++, som är det vanligaste språket för 3D-spel av rang. Det är helt absurt. Det är som att sätta nån som är intresserad av att lära sig köra bil i en Formel-1 bil, ge dom en klapp på ryggen och säga åt dem att dra tre varv på Monza. C++ och 3D-spel kräver något av en formel-1-förare för att inte sluta i en krasch, faktiskt. Och några blir bra formel-1-förare men de började med enklare prylar först...

Nej, att börja programmera handlar om att lära sig lösa små problem först. Att lära sig att val av verktyg är en del av programmeringen. Att man kan lösa samma problem på många olika sätt, där vissa är långsamma, andra är enkla att underhålla och några är kanske fula/dåliga men tillräckliga för den uppgift de är tänkta att lösa. Etc etc. När jag pluggade datavetenskap nötte vi mycket att se programmeringen som just problemlösning och sen på labbtid fick vi tillämpa det på olika programmeringsspråk. Men då var de just verktyg. Många jämställer programmering och programmeringsspråk men då lurar man sig själv lite.


Lång utläggning men det är något jag brinner för. Undervisning och programmering. Kanske därför jag jobbar med båda dessa saker =)

[griffin]

Apråpå verktyg. För att fortsätta använda liknelser. En mekaniker måste ju förvisso någon gång lära sig hur man använder t.ex. en skiftnyckel eller en ODB-läsare. Men viktigare är att lära sig att förstå NÄR han eller hon behöver använda den och varför. Att sen lära sig handgreppet är i sammanhanget en "småsak". Så vill man bli mekaniker är det inte rätt väg att gå genom att signa upp sig på kurseb "praktisk skiftnyckelsanvändning" och sen tro att man är mekaniker.

Problemet är ju att många erbjuder den typen av kurser och får folk att tro att då är allt grönt. =)

[ft]

Inget att tillägga, förutom att det var rätt gissat på programspråken och att det där var väldigt trevlig läsning!

[Lupson]

Trevlig läsning! Är också något av en programmeringsnörd, även om jag är rätt dassig på old-school grejerna såsom C och sånt. Saker som kan exekvera på en JVM är mer min pryl samt 3D-grafik, nuförtiden på handhållna enheter.

Hörde en föreläsning i våras som tog upp just Ariane-raketen. Den felande koden visades upp. Minns inte exakt hur det var, men vill minnas något i stil med att man döpt en variabel till typ "int_speed" när typen i själva verket var en double. Sedan tilldelades denna double till en int vilket gjorde att halva talet försvann vilket sedemera resulterade i en krasch av det mer spektakulära slaget. Minns inte språket (Ada?) Går säkert att googla fram det exakt.

[griffin]

Kul!

Ja, Ariane är intressant exempel. Sen kraschade den inte, man valde att spränga den när man konstaterade att man inte hade kontroll över den. Alla (?) raketer har den möjligheten - bättre spränga den när man själv väljer det än att låta den åka lite som den själv vill och sen landa på någons stortå.

Finns andra intressanta exempel på problem och problemlösning inom programmering. Hörde nån gång att Saab (tror jag) hade problem med en bugg i mjukvaran för ABS-systemet. ABS-systemet är (rimligtvis) ett realtidssystem där livscykeln för vad programmen gör är väldigt väldigt kort. Man noterade att buggen uppstod efter en "tids körning". Den mest kostnadseffektiva lösningen på problemet var att starta om operativsystemet som körde ABS-programvaran X gånger i sekunden så att det aldrig hann köras så länge att buggen uppstod. Uppstartstid av operativsystemet var uppenbarligen inget problem. Fult? Dumt? Smart? Well, jag vet till att börja med hur sant det är, än mindre vad som faktiskt gällde. Men om vi leker med tanken att det är sant. Jag tycker det är en öppen fråga. Som programmerare tycker jag självklart inte om lösningen, men om man är lite pragmatisk... kanske?...

En sak som dagens mer avancerade/funktionella utvecklingsmiljöer ger är faktiskt sämre programmerare. Nu talar jag tyvärr för mig själv. Jag har blivit så van vid att kunna debugga kod att jag hellre gör det när nåt inte funkar än att jag varken före eller efter buggen skrivits funderar på *varför* det kan vara fel. Lättare att bara starta en debugsession och sätta en brytpunkt och se vad variabeln får för värde än att tänka efter.

Samtidigt finns det många system, hemsidor och program som inte skulle vara hälften så stabila och funktionella (om de alls fanns) om inte kompilatorer och utvecklingsverktyg har utvecklats och förfinats över åren. Mels situation är som sagt inte längre applicerbar på hårdvara längre (i de flesta fall) men väl på verktyg och programmeringsspråk.

Sitter med handhållna enheter på jobbet. Det ironiska är att med det har man tagit några steg bakåt. Minne, begränsad upplösning på skärmen etc är återigen en faktor Däremot är verktygen för att hantera detta klart mer mogna nu än för 10-20 år sen.

[Horizon]

Det var en bra utläggning några poster ovan, Jens.

[ft]

En gång i tiden var det enkelt att börja programmera. Man startade en C64/ZX81/ZX48 och kunde sätta igång och hacka BASIC direkt. Det var begränsat, men tröskeln var väldigt låg. Sedan har tröskeln stegrats och stegrats, i och med att programmeringen gömts längre och längre in. Halvgrafiska verktyg där koden doldes så mycket som möjligt var länge lösningen, och gjorde att det hela blev ännu mer abstrakt. Att faktiskt sätta igång och sätta sig in i vad kod gjorde blev rätt svårt. Man fick ta sig igenom rätt mycket bös, märkliga utvecklingsmiljöer och annat innan man faktiskt kunde få skriva ut en textrad på skärmen.

Nu tycker jag utvecklingen gått lite åt motsatt håll. Lättanvända färdiga utvecklingsmiljöer och nya språk har minskat tröskeln kraftigt. Man kan vara igång och hacka sina första rader egen kod på en kväll, som total novis.

Horizon, vill du uppleva känslan i att ta makten över en dator rekommenderar jag att du hittar en C#-tutorial på nätet (eller skaffar en billig bok) och installerar Microsofts C# Express (gratis).