Gott och blandat

Det kan vara så att det bästa med Susanna Clarkes "Jonathan Strange and Mr. Norrell" är att den känns så lik en genuin 1800-talsroman. När sämre författare försöker uttrycka sig ålderdomligt blir det bara löjligt, men Clarke har koll. Det är inte bara språket som gör det, utan även det ryckiga tempot, där ett helt kapitel kan ägnas åt en konversation som inte tar handlingen någonstans, och det dickenska persongalleriet. Mina tankar går till Umberto Eco när han är som mest lyckad, som i "Rosens namn" och "Baudolino", och naturligtvis till Charles Dickens och systrarna Bronte. Välskriven fantasy, det är inte varje decennium. Rekommenderas!

Att kopiera 46000 små filer till ett MicroSD tar enligt min dator 6 timmar. Jag hade glömt bort hur sjukt långsamma flash-minnen kan vara. Har man en massa zip-filer i en katalog-struktur och vill packa upp dem till samma katalogstruktur och bli av med zip-filerna så kan man göra såhär:

yes | for i in `find . -iname *.zip`; do echo $i; unzip $i -d `dirname $i`; rm $i; done

Inte helt klockrent, men det allra mesta blev rätt. Syftet med hela grejen är att lägga över allt relevant innehåll från ftp.scs-trc.net/pub/c64 på min 1541 Ultimate som levererades under veckan. Jag är fullt medveten om att det här inte är att räkna som sjukt nördigt, utan snarare patologiskt. Det är okej.


På spellistan just ju: Dr. Vector, Off!, Antonio Aguilar (tack, Mattias!), Blur.

Jag köpte en ny väckar-lampa, eftersom min förra pajade och jag vaknar så mycket bättre av ljuset än av ilskna signaler från en väckarklocka. Precis som den förra så har den ett användargränssnitt från helvetet. Jag försökte ställa klockan utan att läsa manualen. FAIL. RTFM. LOL.

Om ointressanta grejer

Plötsligt sitter jag på jobbet och debuggar C#-kod. På en lånad Windows-dator. Vad i helvete är det som händer här?

Jag tror inte att det är idealiskt att lära sig ett nytt språk och framework genom att debugga i en stor och komplex app, men med tanke på att jag efter att ha fixat den här buggen kanske aldrig mer behöver använda skiten så lägger jag väldigt liten möda på att lära mig någonting.

Tänk om det hade varit något intressant istället, något som går att använda utanför Windows, något som jag kunde ha nytta av! Kanske något språk som är intressant på något sätt, och inte bara Microsofts klon av 00-talets Cobol. Då hade jag försökt lära mig någonting. Att tänka annorlunda. Nu är det bara lite obekvämt och ointressant. Fast inte värdelöst, för det är i alla fall lite utmanande.

Nästa gång jag gör den här typen av grej så hoppas jag att det är skrivet i Scheme, Haskell, Prolog, Brainfuck eller Intercal istället.

The Final Showdown

Hej!

Som trogna läsare säkert minns så köpte jag en Macintosh-dator för ett och ett halvt år sedan, för att se om det skulle passa mig. Nu känner jag att jag kan komma med ett svar. Svaret är att jag är gammal och lat och att Mac är bättre på vissa sätt, medan Linux är bättre på andra sätt. Till och med Windows har sina fördelar, även om de är få.

Det som är bra med Mac är att saker funkar. Operativsystemet stöder hårdvara. Man kan koppla in en projektor och det bara funkar. Jag kan använda Apples egen mailprogram på jobbet för att koppla upp mig mot det notoriskt inkompatibla Exchange. Jag kan skriva kod till min iPhone.

Det som är bra med Linux är att det funkar. På andra områden. Det är genomskinligt, även om det kan vara dimmigt. Fönsterhanteringen kan ställas in så att det känns som om den funkar, i motsats till Mac, där allt är som Steve har bestämt att det ska vara. Pakethanteringen funkar, i motsats till MacPorts som ställer till med en massa problem.


Det som gör att jag fortsätter köra Mac är att det trots allt funkar ganska mycket som Linux. Det sätter käppar i hjulen, men inte lika brutala som de hårda Linux-käpparna. När jag blir rik ska jag anställa en egen sysadmin, så att jag kan köra Linux igen.

Hejdå!

Prata lite

Jag läste den här boken som heter Coders at Work, där Peter Seibel intervjuar stjärn-programmerare. Den är stundtals ganska tråkig, stundtals ganska rolig. Första intervjun, med Jamie Zawinski, är mest tråkig, fast det är intressant att höra hur Netscape kördes ner i skiten av ledningen. Brad Fitzpatrick, som startade LiveJournal, var mycket roligare. Sen blir det mest en massa gamla gubbar (och en gumma). De flesta har vunnit Turing-priset och började programmera på 50-talet, eftersom det råkade finnas en IBM-dator på deras high school. Därför har de lite annorlunda perspektiv på saker mot vad man är van vid, och kan säga ganska udda grejer. Och de har inte nödvändigtvis så mycket koll som man skulle kunna tro, vilket någon också beklagar sig över. På 70-talet kunde man fortfarande förstå hela systemet man jobbade med, nu jobbar man mot web services och använder hundratals libbar som andra skrivit, som man inte kan ändra i om man skulle vilja.

Jag rekommenderar, men inte på ett översvallande sätt.

CEnhet

Jag ville använda unit-tester till ett Cocoa-projekt.

Dum som jag är så gjorde jag ett nytt försök med OCUnit, vilket jag skrivit om tidigare. Jag vet inte varför jag ens brydde mig. Det suger inte bara för att Steve Jobs har bestämt att man ska använda det på ett idiotiskt sätt, utan även för att det saknar dokumentation, saknar ett uppenbart sätt att köra sina unit-tester programmatiskt och presenterar sina resultat på ett dåligt sätt.

Nästa steg var att testa med Google C++ Testing Framework, som vi kör på jobbet. Det funkar ganska exakt som man vill att det ska göra, letar automatiskt upp ens testfall, kör dem och ger vettig output. Google Test är dock C++, och även om det går bra att blanda C och C++ så ska man tydligen inte försöka blanda C, C++ och Objective-C. Nitlott igen.

Samtidigt som Björn Skifs och Arne Hegerfors hoppade fram och vrålade "TREDJE GÅNGEN GILLT" i örat på mig (det piper fortfarande), så drog jag ner CUnit. Jag säger som Neal: "Aaaaah..." Det är lite mer jobb än med Google Test, eftersom C inte har RTTI, så man får snällt registrera sina testfall, men det som är trevligt med CUnit är att det går att använda på ett vettigt sätt. Och med lite snabbt hopkokad hjälpkod så är den extra ansträngningen för att registrera testsviter och testfall minimal.

CUnit får 3 sälar på den grönländska betygsskalan.

Skriv om, skriv rätt!

Jag har hållit på och läst "Working Effectively with Legacy Code" av Martin C. Feathers ett tag, och blev klar med den igår. Den tog inte tid för att den var tråkig, utan för att jag ville smälta delarna ordentlig. (Jag väljer att inte ta matsmältnings-metaforen vidare, det skulle bli obehagligt.)

Det är en bok som alla programmerare borde läsa, åtminstone de som inte kör test-driven utveckling av trivsel och ohejdad vana. Den här boken visar inte bara med väldigt konkreta exempel hur man inkrementellt förbättrar rutten kod, utan illustrerar även väldigt tydligt varför unit-tester är ett måste.

Författaren har uppenbarligen högt ställda krav. Han definierar legacy code som kod som saknar testfall. Det kan låta lite hårt, men han visar varför det är vettigt.

Om du någonsin har blivit irriterad på svårförståelig kod och det har känts jobbigt att fixa den, läs den här boken!

Programmering

Om att skriva en app till Boxee, del 2

Efter ett andra ryck med SVTPlay-appen så har jag nu något som det funkar att använda. Åtminstone delvis. Jag återkommer till det. Så här kan det se ut:



Åh, snyggt UI! Och så står det "Hello, how are you?", så sympatiskt! Lite grejer att välja på: Barn, Drama, Nyheter... Nej, vet du vad, jag vill se något underhållande! Kultur och nöje låter som min grej!



Här fanns det både roliga och tråkiga grejer, ser det ut som: Babel, Fy Bubblan, Cirkus, det låter som värsta skiten. Jag vill se Det kungliga bröllopet!



Fyra hela avsnitt, på SVT snålas det inte! Jag tror att jag vill se Det Senaste(tm), så jag plockar det...



Ahhhh... Kunglig underhållning!

Vissa brister i appen framgår redan av bilderna ovan. UI:t är inte helt perfekt. Typ det är fult som fan. Det går det nog att fixa. Webbskrapningskoden buggar ur här och där, så ibland kanske ett avsnitt inte heter någonting. Det går nog också att fixa. Bara de program som räknas upp på den första webb-sidan dyker upp. Det tänkte jag fixa. Det finns inte med några beskrivningar eller bilder. Det tänkte jag också fixa.

Det börjar kännas ganska trevligt med webb-programmering. Det går fort och är enkelt, även om man inte vet vad man sysslar med eller har några vidare verktyg att jobba med. Förutom det här skrapandet då, det känns mest hemskt, och jag försöker att inte tänka på det. SVTPlay behöver ett publikt API. Alla borde ha det. Tänk så enkelt allt skulle vara då.

Om att skriva en app till Boxee

Det stör mig lite att det inte finns någon SVTPlay-app till Boxee, så jag tänkte att jag skulle skriva en. Det finns en till Plex, så jag tänkte att det inte borde vara så svårt att porta den. Det visade sig vara lite svårare än vad jag hade tänkt.

Boxee har ett eget API för att skriva appar: man specificerar sitt UI i XML och drar in lite Python-kod här och där för att göra saker, t.ex. skrapa info från SVTPlays HTML. XML-en i sig är ganska knölig att jobba med. En enkel kontroll kan se ut så här:

<control type="image">
    <posx>0</posx>
    <posy>0</posy>
    <width>1280</width>
    <height>720</height>
    <texture>background.png</texture>
</control>

Det blir ganska mycket XML. Det kan man klara, även om XML:en blir ganska rörig. Ännu rörigare blir det när man börjar embedda Python-kod i den.

SVTPlay-appen till Plex är skriven helt i Python. Jag måste alltså plocka ut delar ut Plex-appen och använda i min. Där dyker nästa problem upp. I Plex finns det Python-API:er för att manipulera XML, t.ex. så finns xpath implementerat. Boxee har inget sådant, och dessutom så kör Boxee Python 2.4, som inte har stöd för xpath. Så jag får skriva om all kod från Plex-appen och gjorde en egen ful-implementation av xpath. Jag läser in HTML:en från SVTPlay som ett DOM-träd och söker själv igenom det.

Det här kanske hade varit enkelt om jag hade kunnat Python, men det gör jag ju inte. Så efter ett par timmars kodande så har jag slutligen klarat av nummer ett på min TODO-lista, att kunna visa upp en lista med program-kategorierna (Barn, Nyheter, Live etc.). Förhoppningsvis går det lite lättare nu när jag har lärt mig hantera DOM-trädet, unicode etc.

Med lite mer vana så borde det vara ganska smidigt att skriva sådana här appar, fast det kommer nog vara uppförsbacke ett tag till.

Interaktionsdesign med mera

Jag har aldrig läst interaktionsdesign (om man bortser från trepoängaren "Människa-maskin-interaktion"), men jag kan föreställa mig hur det ser ut när man kommer till den första föreläsningen på A-kursen. Föreläsaren inleder antagligen med något i stil med:

"Välkomna till A-kursen i interaktionsdesign. Det här är första föreläsningen, så jag ska gå igenom lite om administration, upplägget på kursen och så vidare... Men först tänkte jag lära er den viktigaste grundprincipen i alla interaktionsdesign: listor som wrappar är VERBOTEN. Och när jag säger 'wrappar' så menar jag inte en listjävel som hoppar tillbaks till första elementet när man står på det sista och trycker på neråt-pilen. Jag menar listor som gör det utan att hoppa, som låtsas som att de är oändliga, så att du inte märker någon skillnad mellan att hoppa från det sista till det första elementet och att gå från det första till det andra. Blunda och håll den tanken medan jag lägger 5 minuter på att gå igenom var ni hittar kurslitteraturen och vilka frågor som kommer på tentan och vad den hjärndöda labbassen heter, så kommer jag tillbaks till den och lägger resterande 83 minuter på att förklara varför wrappande listor är hjärndödare än labbassen."

Jag testade det här Plex, som är som Boxee eller XBMC, fast ett mellanting. Lite mindre open sourcigt än XBMC, men UI:t ser ut som XBMC. Fast med en wrappande jävla lista i huvudmenyn. Så sjukt störande. "Oj, så många alternativ det finns i huvudmenyn", tänker jag när jag har scrollat ner ganska många steg. Sen upptäcker jag att det är för att den wrappar utan att varna på något sätt. Där var jag nära att ge upp. Sen kollade jag om den kunde scrobbla musik. Det kunde den. Sweet, den ena killer-featuren på plats. (Vän av tempus stör sig eventuellt på blandningen av imperfekt och presens. I så fall hänvisar jag vänligen men bestämt till "Markens gröda" av Knut Hamsun, där tempus-blandningen var/är en del av det som ger/gav en sådan skjuts i språket och som ger/gav honom Nobelpriset.)

Sen kollade jag på apparna. Där börjar sirenerna gå igen: apparna är indelade i något som ser ut som kategorier, men visar sig överlappa. Det vill säga, det är taggar snarare än kategorier. Så om jag vill leta upp en viss app så kan den finnas i någon av avdelningarna, eller i tre av dem. Och vissa av avdelningarna verkar ha i stort sett samma innehåll. Okej, det är en arbetsskada, men i kombination med den wrappande huvudmenyn så klarar jag inte av det. Goodbye plexophiliacs, jag stannar hos Boxee, vars UI jag också skulle kunna ranta om en hel del, men jag slipper i alla fall de mest hjärndöda egenskaperna hos Plex.

Nördigt nyspråk

Dagens Arne Hegerfors-doftande ordvits: nightware.

Da Scrumci-koden

Sedan urminnes tider har taskigt skrivna arkeologer spelade av Tom Hanks sökt den heliga graalen inom agile development-arkeologin: svaret på gåtan varför Scrum har trängt undan Extreme Programming. Givetvis handlar det om trender hitan och ditan, att IDG inte kan skriva om mer än tre saker i taget, men jag har under mystiska seanser fört samtal med andar, besökt idévärlden och ritat sanningstabeller och nått ett svar på gåtan.

Scrum är helt enkelt enklare att bända in i ett företag, eftersom det ser så harmlöst ut för de som bestämmer, d.v.s. de som har slips på sig och tänker med plånboken. "Visst, sure, ni utvecklare kan ju köra era iterationer och ha lite möten, det påverkar ju inte mig." Extreme Programming har inte bara ett lite läskigt namn (som dock kan låta lite hippt och edgy, vilket också har sina fördelar), utan ser ut budget-perspektiv livsfarligt ut. Par-programmeringen drar enligt enkel matematik ner produktiviteten till hälften, och kör man test-driven utveckling så lägger man lika mycket tid på att skriva testfall som att utveckla kod, vilket halverar produktiviteten en gång till.

Inget sådant i Scrum! Scrum ställer inga sådana krav på vad utvecklarna ska göra (parprogrammering och test-driven utveckling är dessutom bara en liten del av Extreme Programming, där finns en del som kan få slipsen att hicka till). Dessutom är det lätt att fuska med Scrum: finns det ingen på plats som förstår vad det handlar om så kan man lätt hoppa över retrospectives, reviews och till och med scrum, fippla med sprint-backloggen under pågående sprint, strunta i att ha produktägare eller scrum master, ha chefer som projektleder så att gruppen inte kan organisera sig själv etc.

Risken är dessutom stor att motståndet ökar om man inte kan få igenom förståelse för fördelarna med lättrörliga processer, vilket tvingar fram kompromisser. Grunden i Agile och Lean är att man förändrar saker som inte funkar som de borde. Förändring möter alltid motstånd. Motståndet kan leda till att Scrum-processen kvävs. Men man kan i alla fall skriva på företagets webbsida att man kör Scrum och att man har certifierat folk, så låter det som att man fattar vad som pågår.

De gamla rävarna som var med under den grå forntiden, för sådär 10 år sedan, får något nästan religiöst i blicken när de berättar om hur bra allt var när man körde Extreme Programming. Och jag tror att det finns goda anledningar till det: Scrum verkar enklare och möter mindre motstånd, men är svårare att lyckas med.

Följer man reglerna för Extreme Programming så får man mycket mer hjälp med det dagliga arbetet. Det går naturligtvis att kombinera Scrum och Extreme Programming, men det är inte så vanligt som det borde vara.

Sen kan man inte skylla allt på cheferna heller. Väldigt många utvecklare känner antingen inte till eller är skeptiska till refactoring, testdriven utveckling och parprogrammering. Men även om UML-nördarna kan dra sitt strå till stacken för att skjuta ner Extreme Programming så är jag övertygad om att det är Scrums falska smidighet som gör det så populärt.

Botnät på iPad

Sjukt nördig helg-läsning om att simulera botnät på superdatorer. Perfekt för att läsa på iPadden i hängmattan på tomten, det säger jag nu yo!

Träd, gräs och stenar

Det blir en del programmering här just nu, men jag kanske är periodare. Eftersom jag är periodare så skriver jag inte kod tillräckligt ofta för att vara speciellt bra på det. Därför kan jag bli entusiastisk över idéer som smarta människor, som DU, tycker är bisarrt uppenbara.

Idag skulle jag skriva en funktion för att kolla hur djupt och brett ett träd är, där varje nod i trädet kan ha ett godtyckligt antal barn. Enligt KISS-principen så delade jag upp den i två, och skrev den enklaste först. Det enklaste är djupet, där man helt enkelt gör en rekursiv djupet-först-sökning (ah, direktöversättningar av datatermer, jag borde söka jobb på IDG) och adderar ett till djupet för varje steg i rekursionen och returnerar det största värdet.

Sen skulle jag göra bredd-funktionen (the bread function), och då tänkte jag först breadth first search. Det är lite jobbigt, man måste hålla i listor med noder så att man inte doppar tårna för djupt innan man har promenerat igenom alla syskon, kusiner, sysslingar, bryllingar, tremänningar etc. Och loopar i koden, känns inte det som att det ökar den cyklomatiska komplexiteten och är allmänt 60-tal sådär? Jo.

Alltså gjorde jag så här istället: jag skrev en rekursiv djupet-först-funktion, till vilken jag skickade med en noll-initialiserad int-array och det aktuella djupet. För varje nod som besöks så ökar jag numret på djupets index i arrayen med ett, och för varje rekursivt anrop så ökar jag djupet med ett. När det första rekursiva anropet returnerar så har jag en array med antalet noder på varje djupnivå, så det är bara att gå igenom den och plocka det största numret i arrayen, som är trädets största bredd. Eller på ren svenska:

void checkBreadthRec(Node node, int currDepth, int breadths[])
    Node curr = GetFirstChild(node)
    
    breadths[currDepth]++    

    while(curr)
        checkBreadthRec(curr, currDepth+1, breadths)
        curr = GetNextSibling(curr)

Det mest komplicerade i den här funktionen är typ att jag använde ordet "breadth" som det är lite jobbigt att skriva och uttala. Om jag har gjort något misstag i pseudo-koden så blir det extra pinsamt, eftersom det här är så sjukt enkelt.

Objekt och abstrakta datatyper

Jag har funderat lite mer på det här med objekt-orienterad programmering. När jag lärde mig att programmera på riktigt så tog det ganska lång tid innan jag såg fördelarna med objekt-orientering, trots att folk försökte övertyga mig. När jag läste eller skrev objekt-orienterad kod så kände jag att den blev krånglig och svår att följa.

Men eftersom det är allmänt erkänt att objekt-orientering är bra, och att det faktiskt är ett enkelt sätt att strukturera kod man skriver på, så lät jag mig övertygas. Att abstrakta datatyper är vettigt kan alla vara överens om, och det är lätt att tro att objekt-orientering i första hand handlar om att strukturera sin data i abstrakta datatyper. Men en abstrakt datatyp ska inte vara mer än inkapslad data. I typisk objekt-orienterad programmering blir datatyperna mycket fetare än vad de borde vara, eftersom man måste klämma in all funktionalitet i dem, även om den inte hör hemma där.

De största problemen jag ser med typisk objekt-orienterad design är:

1. Kontrollflödet blir svårt att följa, eftersom det sprids ut över en massa klasser. Algoritmer passar inte in i objekt-orienterad programmering.

2. Det är lätt att hemfalla åt bristfälliga vanor, där medlemsvariabler används istället för metodparametrar. Att använda medlemsvariabler på det här sätter är i stort sett lika illa som att använda globala variabler: metoder tenderar att ha sidoeffekter i onödan.

Den gemensamma roten till båda de här problemen är att objekt-orienterad programmering prioriterar data över algoritmer på ett sätt som gör att man måste använda skohorn för att få in algoritmerna i objekten. Algoritmer hör typiskt inte till ett visst objekt, utan sprids ut på ett mer eller mindre godtyckligt sätt mellan olika klasser. En viss bit funktionalitet hamnar i en viss klass för att den verkar höra hemma där mer än i någon annan klass, även om den inte egentligen hör hemma där.

Klasser blir typiskt mycket tyngre än de hade varit om metoder bara hade använts till vad de är menade att göra: att manipulera lokal data i det objekt de tillhör. Men algoritmerna måste in i något objekt, även om de egentligen inte hör hemma i något objekt, vilket gör att en klass som kanske egentligen skulle ha haft 10 vettiga metoder, kommer bestå av 10 vettiga metoder och 40 ovettiga.

Jag tror att det i de flesta fall är mer vettigt att dela upp sin kod i abstrakta datatyper, som man kan kalla för klasser om man vill, och gammal god strukturerad imperativ kod, som inte tillhör en viss klass. Då får man klasser som är enkla att förstå, eftersom de inte gör mer än vad de borde göra, och kontrollflöden som är enkla att förstå, eftersom de inte är utspridda över 10 olika klasser.

Enligt det här resonemanget så är språk som Objective C, Python och C++ mer vettiga än t.ex. Java, där allt är objekt. För allt är inte ett objekt. Sen finns det givetvis problem där objekt-orientering kan hjälpa, typiskt för att arv är bra i vissa situationer.

Bygger man stora system ska man titta närmare på t.ex. Component Oriented Programming, som ser ut att vara ett sätt att avhjälpa ovan nämnda problem, på ett sätt som känns överdrivet i små eller medelstora program.

Vill man läsa mycket text om det här och andra relaterade problem så finns det en hel del schyssta rants på den här sidan. Geocities, yo! Jag gillar t.ex. avsnitten under rubrikerna Granularity Problem och Do the Noun Shuffle. Kommunist-analogin är väldigt söt också.

Konkret syntax från abstrakt syntax

Tittade lite på ast-modulen i Python, där ast står för Abstract Syntax Tree. Man kan använda den för att parsa Python-kod och analysera eller modifiera parse-trädet. Rätt coolt. Så här kan det se när en Python-n00b använder ast för att leta upp och skriva ut en funktion i en källkodsfil:

import ast

def find_last_line(func):
    last_line = 0

    for n in ast.walk(func):
        if isinstance(n, ast.stmt) and n.lineno > last_line:
            last_line = n.lineno

    return last_line

def find_func(func_name, parse_tree):
    for n in ast.iter_child_nodes(parse_tree):
        if isinstance(n, ast.FunctionDef) and n.name == func_name:
            return n

def read_file(filename):
    f = open(filename, 'r')
    text = f.read()
    f.close()

    return text

source = read_file('test_ast.py')
lines = source.split('\n')

p = ast.parse(source)

func_node = find_func('find_func', p)
last_line = find_last_line(func_node)

for l in lines[func_node.lineno-1:last_line]:
    print l

Kanske inte världens mest solida kod, men vafan. Funkar det då? Ja, det är väl för i helvete klart att det funkar:

Olsson:testo linusakerlund$ python test_ast.py
def find_func(func_name, parse_tree):
    for n in ast.iter_child_nodes(parse_tree):
        if isinstance(n, ast.FunctionDef) and n.name == func_name:
            return n
Olsson:testo linusakerlund$ 

Sensmoral: det är trevligt med högnivåspråk ibland.

Om flödet och trädet

Jag tänker inte bara på Lars Leijonborg, ibland tänker jag också på objekt-orienterad programmering, hur den presenteras och vilka problemen är. Det jag tyckte redan från början, och det handlar om något så okontroversiellt som att bygga upp sitt program av en samling abstrakta datatyper, är att koden blir svår att följa. Det är svårt att förstå ett skeende. Läser man koden så kan man sätta sig in i en modul i taget, annars blir det bara ett hattande fram och tillbaka. Det illustreras ganska tydligt om man sätter en brytpunkt och tittar på callstacken: även i ett mindre komplext program innehåller den tiotals rader, med antalet moduler i samma storleksordning.

(Reenskaug och Coplien säger samma sak i DCI-artikeln. Objekt-orienterad programmering fångar inte beteendet.)

Objekt-orientering löser en del problem (inte alla, No Silver Bullet av Fred Brooks är väldigt grundläggande, men var nog bland det bästa jag gavs att läsa när jag pluggade), och skapar andra. Borde man inte kunna förbättra kodens läsbarhet genom att visualisera koden på ett bättre sätt? Måste den presenteras som en uppsättning textfiler bara för att den alltid har gjort det? De verktyg som finns för att visualisera kod verkar mest visa klass-hierarkier. Intressant i vissa fall, men det är inte datarepresentationen jag är ute efter, utan algoritmerna.

Det här är ett problem även i mindre, rent imperativa program. När man är uppe i ett 20-tal funktioner så representerar den linjära textfilen det som egentligen är ett träd (eller en graf, för att vara korrekt) på ett oöverskådligt sätt. Jag sorterar alltid funktionerna så att funktion B, som anropas av funktion A, står ovanför funktion A i källkodsfilen. Det hjälper till viss del, men det är en partiell ordning, så det finns en stor mängd korrekta linjära ordningar enligt det kriteriet. Jag kan inte se på funktion A var jag hittar funktion B.

Så om jag vill följa ett flöde genom koden så kan jag använda mitt IDE för att "Jump to definition" när jag ser ett anrop till en funktion som jag vill veta vad den gör. Det tar mig någon annanstans i samma fil eller till en helt annan fil. Därifrån kanske jag gör en "Jump to definition" någon annanstans, och snart har jag tappat bort mig.

Tänk om man kunde koppla loss det här från den ursprungliga textfilen och visa anropen grafiskt. Ungefär så här, fast med källkoden på plats, och inte allt på en gång, och med zoomning och möjlighet att surfa från låda till låda, Exposé-stylee. Fan vad awesome det vore. Inte för att det skulle lösa alltför många världsproblem, men det skulle hjälpa till med vissa.

En annan sak är naturligtvis att folk borde skriva bättre kod, genom att inte blanda alltför friskt med abstraktionsnivåer i en och samma funktion. Det är svårt, men eftersom många inte ens verkar känna till problemet så ser det ofta värre ut än vad det borde göra. Om man inte riktigt fattar poängen med funktionell abstraktion så drar man helt enkelt godtyckliga linjer genom koden och delar upp i funktioner efter dem, eftersom någon har sagt åt en att man ska skriva kortare funktioner. Det gör det svårt att få någon överblick genom att läsa koden, även om man skulle ha Awesome Turbo Code Surfer 3000.

Verklighetsbruset

När jag tidigare idag satt och läste kommentarerna på mobil.se (antingen så är det jag som aldrig lär mig, eller jag som måste störa ut de konstiga tankarna med lite brus ibland) så reagerade jag på hur oduktiga människor som vill framstå som duktiga kan ta åt sig duktiga människors tankar och återanvända dem för att få sig själva att framstå som duktiga.

Puh, efter den långa meningen måste jag pusta ut ett tag.

Efter att ha pustat ut så känner jag att jag måste precisera vad det gällde om i det aktuella fallet: iPhone kan tydligen inte tillåta att tredjepartsprogram kan köra i bakgrunden, med motiveringen att batteritiden skulle sänkas på nolltid om man körde flera program samtidigt.

Oj, efter den idiottanken måste jag svalka av mig i tre sekunder.

Nu har det gått tre sekunder och jag kan komma till det tekniska resonemang som lägger grunden för slutdiskussionen, där det tekniska är följande: ett flertal mobila operativsystem har under de senaste 8 åren tillåtit både första-, andra- och tredjepartsprogram att köra i både för-, bak- och mellan-grunden och haft både sämre och bättre batteritid än iPhone och gPhone. Vi tar en mening till i det här stycket, eftersom de hör ihop: iPhone kör ett multitaskande operativsystem, även om de av någon anledning inte vill att tredjepartsappar ska köra i bakgrunden, av någon anledning som troligtvis fuckar upp Steve Jobs lever, precis som Windows Mobile är multitaskande, precis som Linux (Android) är multitaskande, precis som Symbian är multitaskande, precis som till och med systemen i gamla muggiga features-telefonerna från Sony-Ericsson och Nokia är multitaskande.

Vila nu upp dig i den svala skuggan från följande tekniska faktum: singeltaskande system spar batteri ungefär på samma sätt som autister spar kalorier. Kategorierna har inget med varandra att göra.

Därför blir det så roligt när man läser kommentarer från självutnämnda experter (så kallade internet-användare) som baserat på någon förflugen kommentar från Steve Jobs njurar försöker överträffa varandra i besserwisseritet genom att slå varandra i huvudet med kommentarer om att iPhone suger för att multitasking är framtiden (vilket det kanske var på 50-talet) eller att multitasking kör slut på batteriet på nolltid (vilket det kanske gör i landet Xplotrikovikanienmedmuminochallahattifnatteri-jävlarna, vilket jag inte tror att det finns ett land som heter, men om det gör det så antar jag att kontext-switchar där är bensindrivna eller något).

Nu ska jag sjunka tillbaks i soffan och bara andas.

Dagens awesome

UASSO

Detta har hänt

Dear reviewer, wondering what new...

Matthew Garrett berättar om vad han hittar i en ROM-image från en Palm Pre. När vi försökte köpa en Pre så var den slut-slut-slut och kö-kö-kö och vänta-en-vecka-vänta-en-vecka-vänta-en-vecka. And also: livejournal wtf?

På Symbian Foundation-bloggen rapporteras det från deras event vid WWDC. Info som det är intressant att den fattas: hur många som egentligen dök upp.

På samma blogg skriver de också om hur ST-Ericsson och ARM har kört en SMP-variant av Symbian.

Techcrunch berättar om en i detaljerna ganska kontroversiell rapport om sålda exemplar kontra profit bland mobiltillverkarna. Det är dock knappast speciellt kontroversiellt att dyra telefoner ger mer vinst per sålt exemplar, så att Apple och RIM, som håller sig undan från massmarknaden, tjänar mycket pengar är inte överraskande. Perspektivet är intressant i kontrast till den återkommande rapporteringen av försäljningssiffror. Företag är trots allt till för att tjäna pengar.

Fan vad trött jag är på den här skittrista postningen nu. Jag lyssnar på Vomitory istället.