« Crowd + skatt, hur går det? | Main | Positiv kritik - vem behöver det? »

05 december 2011

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Jag tycker det här verkar handla om ett par olika saker. Din inledningen talar, om jag förstår dig rätt, om ett xml-format som beskriver sin omgivning på ett, från din synpukt, klumpigt sätt. Jag är inte bekant med just dspl, så jag kan inte säga om det är illa definierat eller om det följer någon elegant och kraftfull modell som du inte ser. I vilket fall som helst undrar jag om det har så mycket att göra med hur programmerare tänker. Den eller de som definierat formatet har ju inte i första hand gjort det i egenskap av programmerare. Det är i alla fall fruktansvärt svårt att definiera dylika modeller som ska fungera väl i sina domäner. Evolutionen går dessutlom långsamt eftersom man tenderar att fastna i standarder, eller de facto-standarder, där användarna tvingas anpassa sig till deras konstruktioner, och därmed efter hand kommer att uppfatta även illa valda konstuktioner som naturliga. De riskerar därmed att trots allt följa med till nästa steg i utvecklingen.

Vad gäller hur programmerar tänker när de skapar program, är det åtminstone för mig väldigt mycket en övning i att formulera sig. Att skriva programkod ligger nära att uttrycka ett precist argument, en förklaring, eller till och med ett poem. Det gäller att hitta rätt abstraktioner och metaforer för att åstadkomma en beskrivning där objekten/funktionerna/gränssnitten/etc. förefaller naturliga för det man behöver uttrycka. Man bygger hela tiden gränssnitt i lager på lager, för att användas av en en själv eller andra (oftast bara en själv). Idén med ett lager och ett gränssnitt är att det låter en avgränsa sitt tänkande till ett lager i taget. Får man till rätt operationer i gränssnittet fungerar det så att man kan arbeta inom sitt lager på ett okomplicerat sätt, samtidigt som det griper in i nästa lager utan en massa gnissel och skrammel. En enkel och intuitiv uppsättning operationer gynnar kreativiteten. En klumpig modell, kanske vald på ett alltför tidigt stadium, måste man hela tiden ta sig förbi, vilket både hämmar tänkandet och ger krånglig kod, full med buggar. Det är ett typiskt nybörjarfel att försöka lösa problem genom att ösa på med mycket och komplex kod istället för att formulera om och förenkla.

Jag undrar över meningen "om jag berättar om plattformen för nån som programmerat liknande applikationer för tjugo år sen, eller bara tio, kan jag inte förmedla lättheten i att slippa skriva all maskinkod och hantera kommunikationsprotokoll". Saknas det ett "inte" där möjligen? Det är rimligtvis svårt för någon som upplevt det där med maskinkod och annat lågnivåtjafs att inte fröjdas över hur dagens programmeringsmiljöer låter en slippa det. Jag blir nästan illamående när jag tänker på allt man var tvungen att när man programmerade på 1980-talet.

Hej. Jag tipsade om två böcker som är rätt nya. Utkomna under 2000-talet. Eminent uppsökliga.

De består av frågor till programmerare ur olika generationer. Gemensamt har de Stora Insatser på Området.

Genom att berätta hur de börjat sina karriärer, vilket ofta skett innan yrkeslivet, ger de en bild av hur man tänkte då. Ett skifte som tas upp är: Mikrodatorerna tog optimeringen tillbaka till yrket som lite hade kunnat sluta proppa in ett program på storleken av ett hålkort. Lite samma roll som mobiler har haft nu.

Kring uttrycksfullhet: kolla på hur rörelsen Software Craftsmanship talar om namngivning. Litterärt, nästan.

@olleolleolle Ursäkta! Din tweet indikerade annorlunda. Nu när jag läser om den förstår jag mitt missförstånd! Ska uppdatera inlägget.

@avadeaux Jovisst handlar texten om lite disparata saker -- den är ju också lite ett uttryck för min egen frustration. Exemplet med DSPL handlar ju just om min blindhet för den modell som jag tror måste finnas, men som jag inte ser.

Intressant med det här med lager på lager. Jag förstår att det behöver vara så, men samtidigt blir det här med "objekt" och deras motsvarighet i den verkliga världen ännu mer av en abstrakt metafor. Jag kan hitta ett mjukvarulager som mer känns som den där jobbiga hinnan på löken som bara halkar omkring under fingrarna på mig.

Och nej, meningen om att förklara Arduino-plattformen var nog tyvärr korrekt -- men det finns förstås programmerare som genast förstår det nya sättet att tänka. De som jag har mött har dock varit fast i det gamla...

Tack för intressanta tankar.

Ja, det är ju svårt att få till metaforer som är så naturliga att man kan se modellen direkt i en applikation. Du behöver en beskrivning av den. Annars blir det som att lära sig ett främmande språk bara genom att titta på texter, utan tillgång till vare sig lexikon eller grammatik. Det går väl förvisso, men det är onödigt svårt.

Men om vi tar Google docs som exempel så har dom en massa dokumentation, fast den börjar på fel ställe, och är skriven för programmerare (föga förvånande). Jag hade velat ha en mer grundläggande text om hur de ser på sina spreadsheets, vad man kan göra med dem, och vad man ska kalla de olika delarna (och varför). Lite mer av en guidebok...

The comments to this entry are closed.

  • "En läsvärd blogg om informationsanvändning och hur ny teknik förändrar vår verklighet och vår kultur." -- Urban Lindstedt, Internetworld nr 7, 2006

Böcker

Blog powered by Typepad
Member since 12/2003