Forgive me father, for I have sinned.
Nu är jag tillbaka på nosig, och jag ger FT all credit för det! Och som tack, en historia om den siste riktiga programmeraren!
/Jens aka Griffin
http://www.cs.utah.edu/~elb/folklore/mel.html (http://www.cs.utah.edu/~elb/folklore/mel.html)
Och ja, det är sant alltihop. Står det på nätet. måste det ha hänt - så är det!
Jag tar på mig det fulla ansvaret för ditt återvändande!
Haha, den där hade jag läst ja. Underbar! Jag har i många år haft en dröm om att en dag bygga en trumdator med mekaniskt minne, med någon sorts fysiska bitar. Vore så kul att ha den stående i ett hörn och klicka runt. Givetvis med självmodifierande kod körande! Borde inte vara så svettigt om man begränsar sig lite. Fyrabitars ord och så där. Sedan kan man ju göra instruktionssetet så att vettig kod bildar snygga mönster. :)
Tror det kom sig av när jag läste i Flight of the Intruder att de sparkade på trumminnesnavdatorn för att få den med i matchen igen.
Hej Jens! :)
P.s. Jag behöver en översättning till den där historien om programmeraren. Jag förstår att det var något speciellt han hade gjort, men inte vad. Men så är ju mina programmeringskunskaper begränsade till BASIC till Commodore 64 och saker som
10 "PRINT "HORIZON"
20 GOTO 10
:)
Well. Den är ganska svåröversatt, men det går i stort ut på att han utnyttjade hårdvaran (för på den tiden var hård- och mjukvara i princip samma sak) på ett sätt som det definitivt inte var tänkt att göra. Genom att förstå och utnjyttja hur mekaniken rörde sig kunde han "handoptimera" på ett sätt som inga program eller andra kollegor förstod sig på - med resultatet att hans program kickade övriga i prestanda. Och han var så bra på det att ingen annan förstod ens hur han gjorde det, än mindre kunde rå på att ändra något. Och när berättaren väl förstod "storheten" i vad (eller snarare HUR) Mel åstakommit så tyckte han det var bäst att låta bli att ändra något.
I dag när vi programmerar använder vi en hel uppsjö av program, landvinningar och idéer, baserade på mångårigt arbete och forskning. Det enklaste datorprogrammet använder sig av mångas arbete. Men då, då programmerade man direkt på hådvaran. Ville man att "datorn" skulle göra något, fick man lära sig maskinkod och prata direkt med datorn. Hantverket var i någon mening lite större då (samtidigt mer primitivt).
Så hela historien kan översättas/sammanfattas med titeln "Mannen som kunde tala med datorer" i nördtappning. Grejen är den, att även om vi idag sitter och gör i mångt och mycket mer avancerade grejer tack vare att vi har mer avancerade verktyg än vad han förfogade över - finns det ändå en Mel nånstans i varje programmerares krets. I princip. Som väljer sina egna vägar, vars geni kanske går att ifrågasätta men man kan ändå inte låta bli att fascineras av val av lösningar och effekten de har. Och får jobba med att förstå det hela. :) Och detta går väl att applicera på mer än datorer och datavetenskap. Faktum är att Mel finns någon i de flesta gebiten om man tänker efter...
Får man inte ganska mycket bättre prestanda i programmen om man programmerar "direkt" idag? Alltså maskinkod eller vad det kallas. Ettor och nollor. Eller är processorerna och annan hårdvara så snabba att man inte vinner så mycket?
Vet inte om hastighet på dagens datorer är en faktor, men förutom att försöka svara på din fråga:
I teorin borde det bli snabbare med hand knackade även idag. I praktiken tror jack det blir svårt är en förutsättning någon riktigt begåvad typ med. Det är helt enkelt så komplicerad hårdvara i jämförelse med dåtidens, samtidigt som det har skett massor i forskningen kring kompilatorer (de program som översätter programmerarens önskemål till maskinkod).
Däremot finns det programmeringsspråk och miljöer som tillåter Meltyper att leva ut men då på en annan nivå.
Kan tänka mig att militär hårdvara programmeras så enkelt som möjligt för att felen ska bli så få (eller inga) som möjligt. Undrar just vad för typ av datorer som sitter i Gripen och vilket programspråk de är programmerade i?
Skulle styrsystem till avancerade flygplan skrivas i maskinkod hade vi haft betydligt fler krascher. :D
Hela poängen med att tillämpa mångårig forskning i kompilatorer är att vi kan automatisera mycket som ja, i begränsad skala kan göras bra av specifika personer, men det finns helt enkelt inte tillräckligt många "Mel" för att täcka behovet.
Militär eller civil hårdvara, självklart är tillförlitligheten a och o. Därför bör man inte lämna det åt mänskliga faktorn - som bekant står för ganska många katastrofer. Däremot bör inte heller systemen som du säger vara för komplexa heller - för då finns återigen fler felkällor. Men det handlar nog mer om prestanda egentligen. Mer beräkningar -> sämre prestanda. Något man i vissa lägen måste väga mot annat. Ett bra system måste nog framför allt vara *testbart*. Det måste gå att verifiera kodens (och maskinvarans) beteende, vare sig det är man eller maskin som åstadkommit den.
En inte helt grundlös gissning är att vi finner Ada, Fortran och kanske en del C i många flygplan. Och bilar med för den delen. När det gäller hårdvaran så är väl de som har tekniska kunnandet att svara på det belagda med munkavle. Men jag tror Gripen i större utsträckning än sina föregångare använder "standardkomponenter" för att hålla nere kostnaden. Tror dock inte vi hittar överdrivet många i7:or med nVidia kort i den ändå. :)
Det finns flera exempel (vissa verifierat sanna, andra mer mytbetonade) på detta. Ett exempel är Arianeraketen som kraschade på grund av dålig testning av programvara. Kortkort: man gjorde felaktiga antaganden istället för att testa och verifiera. Ett annat exempel är Eriksson, som använde "lågnivå"-språket C++ för ett jätteprojekt (typ AXE-växeln eller nåt liknande). Det projektet höll på att haverera för att det gick inte att ro ihop ett projekt av den magnituden med ett språk som C++ med så många personer. Det blev för rörigt. Man fick uppfinna ett nytt språk som löste uppgiften och var så pass enkelt att man kunde ha så många personer inblandade. Ett språk som var lätt att förstå och programmera men tillräckligt snabbt och bra för att lösa uppgiften helt enkelt. Detta är dock något av en myt, men det finns med all sannolikhet en hel del sanning bakom med. Språket blev Erlang, som idag används för "mjuka realtidssystem". Och det vet jag, för jag har jobbat med det.
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? :)
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 =)
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. =)
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!
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.
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.
Det var en bra utläggning några poster ovan, Jens.
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).
Jag skulle precis till att fråga vilket språk som passar bäst för att lära sig lite grunder. Ska kolla upp C-skarpt.
Ett annat tips om man är helt novis inom programmering och vill börja känna på och lära sig lite grundläggande tänk är att göra lite scripts i ofp/arma, då har man också fördelen att man får väldigt direkt feedback på om/hur scriptet funkar. BIS scriptspråk är ju inte helt olikt hur många programmeringsspråk är uppbyggda.
Ok, tack Subroc. Fluff tipsade mig även om php och vi letade reda på en tutorial, men jag blev lite modfälld då första meningen i den gjorde att jag kliade mig i huvudet.
In this tutorial we assume that your server has activated support for PHP and that all files ending in .php are handled by PHP.
Fattar nada. :D
Ja ja, det blir nog bra till slut.
PHP m fl har den stora nackdelen att man måste lista ut var man skall skriva sakerna. Att arbeta i en färdiginstallerad IDE (Integrated Development Environment, integrerad utvecklingsmiljö) har absolut sina fördelar. Man slipper fastna i märkliga konfigurationsfinesser, det som fungerar i den tutorial man hittat fungerar även när man provar själv. Lätt frustrerande när man gör allt som det är skrivet men det ändå inte fungerar eftersom något helt annat är konfigurerat annorlunda.
Just tillbringat rätt mycket tid studsandes mellan olika kompilatorversioner, bara som ett exempel... :)
Har precis gjort mitt första riktiga projekt i PHP och det är definitivt inget bra nybörjarspråk. Man kan göra lite hur som helst utan att det riktigt framgår varför och möjligheten till att debugga är minimal. Dessutom måste man, förutom att förstå PHP också kunna grundläggande HTML samt förstå hur en webbserver fungerar. Dåligt med "förlåtande" språk, varför.? Språk som sväljer inkonsekvens eller fel lämnar lite utrymme för förståelse och insikt i hur det funkar.
C# är en bra kandidat. Gratis utvecklingsmiljö, mycket med exempel online, ett hyfsat enkelt språk i sig med en mycket enkel men kraftfull editor., Jag kan gräva fram några bra länkar.
Dessutom har undertecknad jobbat med det de närmaste 6 åren så hjälpen är nära.
Fluff, vad har du att säga till ditt försvar? Försöka leda mig på villovägar på det där viset! ;)
Hehe!
PHP har sina riktigt trevliga sidor med. Vill man enkelt skapa dynamiska hemsidor är det ett jättetrevligt verktyg. Kraftfullt och lätt att jobba med.
Men lätt, förutsatt att man har lite koll på programmering :)
Som skolspråk däremot, nej. Det finns nog de som inte håller med.
Bah!
Lyssna inte på griffin och ft! Alla vet ju att det var tack vare C# som nazisterna kom till makten. (fegissmiley här :))
Allvarligt talat så tror jag php (eller om man vill ha lite roligare, Perl) kan funka alldeles utmärkt för grundläggande programmering. Dvs för att få kläm på loopar, villkor, olika datastrukturer och sånt. Det enda som behövs sedan php-paketet är installerat är då en editor. Min erfarenhet av IDE:er är att man kan få en rätt lång startsträcka innan man får ut så mycket som ett "Hello world". Sedan behöver man ingen webserver för att komma igång med php, mycket utav grunderna kan man lära sig genom att köra i command line-läge (se http://php.net/manual/en/install.windows.commandline.php (http://php.net/manual/en/install.windows.commandline.php)) . När man sedan känner sig mogen kan man ex.v be baloo om ett konto på hans Raspberry Pi så kan man sjösätta sina revolutionerande egenkonstruerade webapplikationer där.
Och redan i första paragrafen om PHP är vi inne på termer som CLI och att sjösätta sina Hello World via nätverk mot en Raspberry... samt har aktiverat Godwin's lag! :D
Perl tycker jag. Du kan leka loss på raspberryn om du vill eller så installera Strawberry Perl i Windows och kör lokalt. Oavsett om du väljer Perl, C# eller något annat trevligt språk så kommer du inte undan behovet att förstå utvecklingsmiljön. Kör du Perl så slipper du fundera över kompileringsbiten iaf. Såhär skulle din första session kunna se ut efter installationen av Strawberry perl http://strawberryperl.com/ (http://strawberryperl.com/)
Starta kommandotolken
Skriv in
perl -e "print 'Hello World!';"
och tryck sen retur för att se texten Hello World! skrivas ut i fönstret.
Vad ni pratar om är att lösa specifika problem. PHP och Perl är jättebra för den typen av problem. Men skolspråk? Nej. Varför?
Några lösryckta problem med det:
- Hur lära ut vad en datatyp är och innebär när man kan göra saker som '$x="1"; $y=1+$x'
- Hur lära ut vad skillnaden mellan syntaktiskt fel, körfel eller tolka felmeddelanden när man får resultatet "Internal Server Error" som ända ledtråd (innan man vet var man skall kika då)
- Hur lära ut vad skillnaden mellan HTML och PHP går, när man kan blanda dem friskt i koden. PHP genererar HTML och är grymt på att autoatisera array och stränghantering eftersom det är vad man som mest behöver göra när man genererar HTML.
- Hur lära ut datatyper och strukturer när man aldrig behöver deklarera några eller knappt ta hänsyn till dem.
- Hur lära ut arv när objektorienteringsbiten i PHP helt kan ignoreras. Det känns som mer av en kul grej de pitchade in för att det är poppis med OOP.
Jag räknade till 7 klick/tryck för att skriva, kompilera och exekvera Hello World som en "fullt fungerande" Windows applikation, efter att Visual Studio startats. Exklusive att skriva texten Hello. World. Kan inte se hur en IDE ställer till det?
Återigen, allt handlar om vad man vill göra. Och framför allt hur man definierar "att lära sig programmera". Jag har väl en lite mer "old school" inställning där. Samtidigt ganska pragmatisk. Om man har en Raspberry P och vill leka med den, kan PHP eller Perl kanske vara perfekta val för att göra det man vill med sin dator. Och givet att man har koll på hur man får igång Raspberryn och hanterar den biten, behöver stegen till att lösa sina första problem i PHP eller Perl inte vara överdrivet många. Men har man lärt sig att programmera på det? Inte om ni frågar mig. Löst problem, lärt sig saker. Ja. Programmerat? Ja, absolut. Men lärt sig programmera? Nej. Typ :) Kan man programmera utan att lära sig att programmera? Hmm.
Det finns för och nackdelar med att integrera språk och utvecklingsmiljö. Jag har jobbat med båda varianterna. En integrerad miljö kan göra saker åt dig - till priset att du kanske inte förstår allt som sker. Samtidigt tar det fokus bort från det som inte har att göra med den problemlösning du skall göra. Exempel: det tog mig många timmar när jag lärde mig PHP att få till ett bra arbetsflöde för att förstå, hitta och åtgärda fel när jag programmerade. Tid som jag t.ex. Visual Studio inte behövt lägga, då felmeddelandet hade tryckts upp i fejset på mig.
Jag lärde mig programmera två gånger. Först själv sen på universitetet. Själv använde jag IDE (Turbo Pascal någon?) och på universitetet genom tolkat språk (SML), och sedan genom att själv kompilera och länka. Nu jobbar jag med att använda en IDE som är oerhört komplicerad (Visual Studio och Eclipse). Det är svårt att rekommendera något utan att veta vad den som vill lära sig något faktiskt vill göra och åstakomma. Valen är så många!
Vad mycket enklare det var när det endast fanns Basic eller Amiga Basic. :)
Jag läser och försöker förstå det ni skriver, men det tar inte många rader innan ni börjar prata om saker som jag inte fattar ett dugg av, t.ex. länka, kompilera, utvecklingsmiljö, datatyp, autoatisera, stränghantering, arv osv osv. Man blir helt snurrig. Om jag säger så här: Jag vill gå en kurs i "Programmering för nybörjare". Var börjar jag? Finns det inte någonstans där man startar en liknande kurs på t.ex. gymnasiet? Jag får höra mig för lite med lärarkollegor.
Jag lovade skaka fram lite länkar och läsning, det skall ordnas!