@FT: The last real programmer

[griffin]

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

Och ja, det är sant alltihop. Står det på nätet. måste det ha hänt - så är det!

[ft]

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.

[Horizon]

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

[griffin]

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...

[Horizon]

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?

[griffin]

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å.

[Horizon]

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?

[griffin]

Skulle styrsystem till avancerade flygplan skrivas i maskinkod hade vi haft betydligt fler krascher.

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.