Såhär när det är sommar, sol och semester så gör man bäst i att undvika frånvaron av sol genom att studera data. Det har varit mycket språk inom dataområdet under de senaste åren, med mycket influenser från funktionella språk (åtminstone om man begränsar sig till matchning och map/reduce). Själv bryr jag mig mindre om Clojure, Scala och sådant där virtuellt, och intresserar mig istället för språk som kompileras till maskinkod, som Swift, Go och Rust.
Swift ska ersätta Objective-C i iOS-värden, Go används i första hand till backend-grejer och Rust ska ersätta C++ rent allmänt. Jag valde utan någon speciellt anledning att börja med att titta närmare på Rust.
Från början kände jag en viss entusiasm, t.ex. över makron och det klasslösa samhället, men entusiasmen mattades när det började lukta för mycket Ada. Och någon typ av namn-konvention från 70-talet. Jag kan se varför någon som kommer från Ruby-hållet skulle föredra Rust framför C++, men det känns mer som ett steg på vägen mot något bättre, än som ett språk som kommer kunna dominera långnivåprogrammering i ett par decennier. Systemet för ägarskap av data känns som att det mest skulle leda till krångel i en massa fall när man inte borde behöva bry sig. Cargo, som används för att definiera projekt, bygga och hantera beroenden, känns positivt 2015, men det räcker inte.
Jag lämnar Rust bakom mig med en känsla av att jag aldrig vill skriva speciellt mycket kod i det. Glad sommar!
Visar inlägg med etikett programmering. Visa alla inlägg
Visar inlägg med etikett programmering. Visa alla inlägg
2010-11-01
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.
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.
2010-06-25
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!
2010-05-08
2010-05-02
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å.
Å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å.
2010-05-01
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:
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.
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.
2010-03-15
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:
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.
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.
2010-03-07
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å.
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å.
2010-01-03
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.
(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.
2010-01-01
Första januari
I Språkrådets nyordslista för 2009 kan man lära sig "fina ord": fiskpedikyr, fröbomba, fuldelning, grindstad, stuprörspolitik.
Farmor fyller 90.
Jag försöker fatta vad man egentligen ska göra åt att typisk objekt-orienterad design skapar farlige monster. DCI och COP är rätt abstrakt, men känns rätt. Jag går igenom en del kod jag har liggande och observerar 12 olika observer-implementationer i samma program. Jag har lärt mig att interfaces och mixins inte är samma sak.
Google Go verkar väldigt, väldigt vettigt, vilket kanske inte är så konstigt med tanke på upphovsmännen.
Farmor fyller 90.
Jag försöker fatta vad man egentligen ska göra åt att typisk objekt-orienterad design skapar farlige monster. DCI och COP är rätt abstrakt, men känns rätt. Jag går igenom en del kod jag har liggande och observerar 12 olika observer-implementationer i samma program. Jag har lärt mig att interfaces och mixins inte är samma sak.
Google Go verkar väldigt, väldigt vettigt, vilket kanske inte är så konstigt med tanke på upphovsmännen.
2009-12-09
bada
Samsung kallar bada för ett OS, men det ser mer ut att vara en applikationsmiljö som kan flyttas mellan olika OS. Det finns en massa intressant information på dev-sajten. Jag tittade igenom det de kallar för "tutorials", som snarare påminner om presentationsmaterial. De är ganska roliga, med engelska som är dålig på ett sätt så att det bara blir skojigt. Min favorit: "Can I play with data corruption and other madness?" (Svaret på frågan är nej, man kan inte leka med data-korruption och annan galenskap i bada.)
Det är lite läskigt att de verkar ha tagit starka intryck av Symbian: C++ med tvåfas-konstruktion, inget multipelt arv utom med interface-klasser, inga exceptions, all data minutiöst inkapslad etc. Man slipper visserligen leaves, active objects och 50 sträng-klasser, men den errno-liknande felhanteringen ser inte direkt smidig ut att använda.
UI-delen är väldigt konservativ, ett klassiskt "Button *b = new Button()"-API. Det finns en builder med som kan spara ut komponenter som XML. Exemplet som ges är att man gör sin komponent i buildern och skapar upp en kontroll från XML-en i C++-koden. Verkar lite knöligt, men eventuellt så kan man ladda in en XML-fil för hela UI:t, som med GTK/Glade. Vill man göra coola UI-grejer så finns det en Flash-kontroll och GLES, som överallt annars.
Annars är det mycket stöd för att hantera communities, kontakter, social nätverk, realtidswebben 3.5 etc. All ens interaktion med andra loggas automatiskt, och det finns API:er för att söka i databasen där infon lagras. Det finns även med API:er för att hantera en del special-grejer, som ansiktsigenkänning, haptics, rörelsesensor etc.
Rent allmänt ser det ganska trevligt ut, trots Symbian-vibbarna. Det skulle nog kunna vara ganska trevligt att jobba med. Och med slogans som "The platform with more opportunities" så kan man knappast misslyckas, eller hur?
Det är lite läskigt att de verkar ha tagit starka intryck av Symbian: C++ med tvåfas-konstruktion, inget multipelt arv utom med interface-klasser, inga exceptions, all data minutiöst inkapslad etc. Man slipper visserligen leaves, active objects och 50 sträng-klasser, men den errno-liknande felhanteringen ser inte direkt smidig ut att använda.
UI-delen är väldigt konservativ, ett klassiskt "Button *b = new Button()"-API. Det finns en builder med som kan spara ut komponenter som XML. Exemplet som ges är att man gör sin komponent i buildern och skapar upp en kontroll från XML-en i C++-koden. Verkar lite knöligt, men eventuellt så kan man ladda in en XML-fil för hela UI:t, som med GTK/Glade. Vill man göra coola UI-grejer så finns det en Flash-kontroll och GLES, som överallt annars.
Annars är det mycket stöd för att hantera communities, kontakter, social nätverk, realtidswebben 3.5 etc. All ens interaktion med andra loggas automatiskt, och det finns API:er för att söka i databasen där infon lagras. Det finns även med API:er för att hantera en del special-grejer, som ansiktsigenkänning, haptics, rörelsesensor etc.
Rent allmänt ser det ganska trevligt ut, trots Symbian-vibbarna. Det skulle nog kunna vara ganska trevligt att jobba med. Och med slogans som "The platform with more opportunities" så kan man knappast misslyckas, eller hur?
2009-07-25
Donald Jobs
Jag hade tänkt kommentera det här med att utvecklingsverktygen till Mac känns lite Kalle Anka ibland. Tidigare har jag berättat om de positiva aspekterna, och det jag har gnällt på har gällt hanteringen av öppna filer i Xcode, som jag har insett hur man jobbar med på ett vettigt sätt.
Men några exempel:
Xcode har inget stöd för subprojekt, vilket finns i alla andra IDE-er jag har använt: Visual Studio har det, CodeWarrior hade det, Eclipse har det. Xcode har fastnat i någon idé om att man utvecklar libs/frameworks och appar separat, och att man inte vill vara inne och gräva i lib-kod när man skriver appar. Men det är inte tillräckligt generellt, det täcker inte in alla fall. T.ex. inte min situation på jobbet, där jag har ett framework, som är det jag utvecklar, som jag har olika frontends till. För frameworket (som i sin tur består av flera libs) vill jag ha separata projektfiler, som jag kan inkludera i projekten som jag bygger frontendsarna med. Nicht gut, säger herr Jobs, innan han går över till sin Monika Danielsson-röst och säger "det _vill_ du inte göra".
Det verkar inte finnas någon riktigt vettig grafisk frontend till Subversion. Jag gjorde en utvärdering och kör sedan dess Versions, som är bättre än att använda kommandoraden, men inte har stöd för merge och inte riktigt verkar fatta externals. Det känns nästan lite som en förolämpning när Apple väljer att ge pris till utvecklarna av programmet. Hur som helst, vill jag göra en merge eller uppdatera en katalog med externals till en viss version så är det kommandoraden som gäller.
FileMerge, som är Apples eget diff/merge-verktyg, är något av ett skämt. Man kan inte editera texten manuellt, utan kan bara välja den ena eller båda text-sekvenserna som diffar. Dessutom finns det ingen information om vilka snabbtangenter man kan använda. Jag har inte listat ut hur man väljer både versionerna. Klick, klick, klickety-klick. Eventuellt finns det bättre merge-verktyg, det har jag inte haft tid att kolla upp. (Dessutom är det fult och har dålig syntax-highlighting. Låna koden från Xcode, kanske?)
På WWDC var jag på en presentation om vad som var nytt i Xcode, där fick jag lära mig att det finns en feature i Xcode som kallas Snapshot. Man kan ta snapshots av sin källkod och gå tillbaks till tidigare snapshots. Om det nu finns Kalle Anka-kodare som inte har vett nog att använda ett versionshanteringssystem, är det då bättre att ge dem ett enklare sätt att sköta lokal backup-hantering än att tala om för dem att det finns något som kallas versionshantering och som är ett mycket bättre alternativ? Eller är det så att Xcode-utvecklarna själva inte har koll på hur man använder versionshantering på ett vettigt sätt?
Det här är detaljer, men detaljer som stör om man bara vill kunna göra vettiga grejer med vettiga verktyg. Det är som om det finns någon uppfattning om att nybörjare som kodar Hello World-program är de viktigaste användarna. Men visst, samtidigt har vi DTrace, Instruments, Interface Builder och LLVM som pekar i en annan riktning. Om några år kanske allt är riktigt bra, och jag kan sluta gnälla.
Men några exempel:
Xcode har inget stöd för subprojekt, vilket finns i alla andra IDE-er jag har använt: Visual Studio har det, CodeWarrior hade det, Eclipse har det. Xcode har fastnat i någon idé om att man utvecklar libs/frameworks och appar separat, och att man inte vill vara inne och gräva i lib-kod när man skriver appar. Men det är inte tillräckligt generellt, det täcker inte in alla fall. T.ex. inte min situation på jobbet, där jag har ett framework, som är det jag utvecklar, som jag har olika frontends till. För frameworket (som i sin tur består av flera libs) vill jag ha separata projektfiler, som jag kan inkludera i projekten som jag bygger frontendsarna med. Nicht gut, säger herr Jobs, innan han går över till sin Monika Danielsson-röst och säger "det _vill_ du inte göra".
Det verkar inte finnas någon riktigt vettig grafisk frontend till Subversion. Jag gjorde en utvärdering och kör sedan dess Versions, som är bättre än att använda kommandoraden, men inte har stöd för merge och inte riktigt verkar fatta externals. Det känns nästan lite som en förolämpning när Apple väljer att ge pris till utvecklarna av programmet. Hur som helst, vill jag göra en merge eller uppdatera en katalog med externals till en viss version så är det kommandoraden som gäller.
FileMerge, som är Apples eget diff/merge-verktyg, är något av ett skämt. Man kan inte editera texten manuellt, utan kan bara välja den ena eller båda text-sekvenserna som diffar. Dessutom finns det ingen information om vilka snabbtangenter man kan använda. Jag har inte listat ut hur man väljer både versionerna. Klick, klick, klickety-klick. Eventuellt finns det bättre merge-verktyg, det har jag inte haft tid att kolla upp. (Dessutom är det fult och har dålig syntax-highlighting. Låna koden från Xcode, kanske?)
På WWDC var jag på en presentation om vad som var nytt i Xcode, där fick jag lära mig att det finns en feature i Xcode som kallas Snapshot. Man kan ta snapshots av sin källkod och gå tillbaks till tidigare snapshots. Om det nu finns Kalle Anka-kodare som inte har vett nog att använda ett versionshanteringssystem, är det då bättre att ge dem ett enklare sätt att sköta lokal backup-hantering än att tala om för dem att det finns något som kallas versionshantering och som är ett mycket bättre alternativ? Eller är det så att Xcode-utvecklarna själva inte har koll på hur man använder versionshantering på ett vettigt sätt?
Det här är detaljer, men detaljer som stör om man bara vill kunna göra vettiga grejer med vettiga verktyg. Det är som om det finns någon uppfattning om att nybörjare som kodar Hello World-program är de viktigaste användarna. Men visst, samtidigt har vi DTrace, Instruments, Interface Builder och LLVM som pekar i en annan riktning. Om några år kanske allt är riktigt bra, och jag kan sluta gnälla.
2008-11-19
Development in the ear
Idag har jag varit på Öredev och lyssnat på folk som pratat om programmering, istället för att själv sitta och programmera.
Ted Neward keynotade om att språk kommer vara den stora grejen under de närmsta 5-10 åren. Programmeringsspråk. Nya, häftiga sådana. Han förklarade varför. Han tog exempel. Jag är inte övertygad, men han sa intressanta saker.
Resten av förmiddagen la jag på en presentation av det nya JavaME-SDK:t (man kan debugga, man kan köra i emulator, man kan köra på device, man kan profilera) och en spådom av en kille från SonyEricsson om vart mobil-mjukvara är på väg: open source, öppna plattformar, webben, högnivå, konvergens. Jag fick inte höra något jag inte hört förut.
Efter lunch gick vi på en presentation av The Bug, en pluggbar hårdvaruplattform för att bygga och programmera apparater. Ganska roligt, men precis som föreläsaren påpekade så kan den inte göra speciellt mycket som en smartphone inte kan. Än. När man kan plugga in geigermätare så blir det mer intressant.
Dagens höjdpunkt var när en gammal amerikansk nörd berättade om sitt projekt, språket D. Jag blev sugen på att veta mer och att byta ut den föregående bokstaven i alfabetet mot denna. Fortsättning kanske följer.
Jeff Sutherland pratade om hur man använder Scrum i större projekt, i en föreläsning full av intressanta idéer: kodstruktur speglar organisationsstruktur, scrum som objekt-orienterad programmering etc.
Dagen avslutades med en helt värdelös presentation av Silverlight Mobile. Killen kunde inte bestämma sig för om han ville prata om Silverlight, UI:n till mobiler, allmänt om UI-design eller .NET, vilket gjorde att han egentligen inte sa någonting. Han visade lite exempel, men förklarade inte vad de skulle visa. Han skrev lite kod, vilket visade att man kan göra väldigt lite med väldigt lite kod. Jag vet inte.
Tyvärr missade jag The future of Java on mobile, som handlade om Suns motsvarande grej, JavaFX. Det var tydligen mycket bättre.
Ted Neward keynotade om att språk kommer vara den stora grejen under de närmsta 5-10 åren. Programmeringsspråk. Nya, häftiga sådana. Han förklarade varför. Han tog exempel. Jag är inte övertygad, men han sa intressanta saker.
Resten av förmiddagen la jag på en presentation av det nya JavaME-SDK:t (man kan debugga, man kan köra i emulator, man kan köra på device, man kan profilera) och en spådom av en kille från SonyEricsson om vart mobil-mjukvara är på väg: open source, öppna plattformar, webben, högnivå, konvergens. Jag fick inte höra något jag inte hört förut.
Efter lunch gick vi på en presentation av The Bug, en pluggbar hårdvaruplattform för att bygga och programmera apparater. Ganska roligt, men precis som föreläsaren påpekade så kan den inte göra speciellt mycket som en smartphone inte kan. Än. När man kan plugga in geigermätare så blir det mer intressant.
Dagens höjdpunkt var när en gammal amerikansk nörd berättade om sitt projekt, språket D. Jag blev sugen på att veta mer och att byta ut den föregående bokstaven i alfabetet mot denna. Fortsättning kanske följer.
Jeff Sutherland pratade om hur man använder Scrum i större projekt, i en föreläsning full av intressanta idéer: kodstruktur speglar organisationsstruktur, scrum som objekt-orienterad programmering etc.
Dagen avslutades med en helt värdelös presentation av Silverlight Mobile. Killen kunde inte bestämma sig för om han ville prata om Silverlight, UI:n till mobiler, allmänt om UI-design eller .NET, vilket gjorde att han egentligen inte sa någonting. Han visade lite exempel, men förklarade inte vad de skulle visa. Han skrev lite kod, vilket visade att man kan göra väldigt lite med väldigt lite kod. Jag vet inte.
Tyvärr missade jag The future of Java on mobile, som handlade om Suns motsvarande grej, JavaFX. Det var tydligen mycket bättre.
2008-09-22
Skor
Hej!
För er som inte läste veckomailet (eller inte ens jobbar på TAT), så måste jag tipsa om Shoes, ett UI-toolkit för Ruby. Det är inspirerat av Processing, webben och annat som jag inte har så bra koll på, ser sjukt högnivå ut och verkar allmänt härligt, men det är inte det som är grejen.
- Vad är det som är grejen? frågade Maja.
Det som är grejen är att dokumentationen är så härligt oseriös. Speciellt den här boken. Ser den ut som en manual för ett GUI-toolkit?
- Nej, sade Maja, det gör den verkligen inte. Men är det här något du kommer använda?
Nej, det tror jag inte.
Nu ska jag gå och lägga mig. Hejdå!
För er som inte läste veckomailet (eller inte ens jobbar på TAT), så måste jag tipsa om Shoes, ett UI-toolkit för Ruby. Det är inspirerat av Processing, webben och annat som jag inte har så bra koll på, ser sjukt högnivå ut och verkar allmänt härligt, men det är inte det som är grejen.
- Vad är det som är grejen? frågade Maja.
Det som är grejen är att dokumentationen är så härligt oseriös. Speciellt den här boken. Ser den ut som en manual för ett GUI-toolkit?
- Nej, sade Maja, det gör den verkligen inte. Men är det här något du kommer använda?
Nej, det tror jag inte.
Nu ska jag gå och lägga mig. Hejdå!
Prenumerera på:
Inlägg (Atom)