Sammanfattning: Min första kontakt med en dator var med en FACIT EDB, kopia av BESK, 1963. Sedan har jag prövat Vegematic, jobbat många år med IBM 7090, IBM 360/75 och DECsystem-10. För DECsystem-10 var jag med och utvecklade tidiga ordbehandlingssystem, system för datorstödd undervisning, forumsystem och en Simula-kompilator under 1970-talet.
Anmärkning: Det jag skriver nedan är nedtecknat ur minnet, inte ur skriftliga källor. Det kan därför vara så att enstaka siffror inte helt stämmer. Jag har markerat sådana ställen med ett frågetecken inom parentes: "(?)". Om någon läsare har säkrare uppgifter, meddela mig så rättar jag i texten.
När jag var 15 år (1956) kallades datamaskiner för matematikmaskiner och var ett helt okänt begrepp för mig. Men jag hade en modelljärnväg hemma, som styrdes av elektriska signaler för att vända på växlar, fälla upp och ner semaforer m.m. Då köpte jag en mässingstrumma, som långsamt snurrade driven av en elmotor. Mot ytan på trumman låg ett antal mässingsfjädrar, så att det blev kontakt mellan trumman och fjädrarna. På trumman klistrade jag tejp, så att när trumman roterade så att en fjäder passerade tejpen, bröts strömmen. Strömmen från fjädrarna styrde därefter tåget, så att en serie komplicerade manövrer kunde göras, styrt av tejpbitarna på trumman. Jag insåg inte förrän långt senare att vad jag gjort var mitt livs första program.
När jag var arton år (1959) fick alla eleverna vid läroverket tala med en studievägledare. Jag sa till studievägledarna att jag var intresserad av matematikmaskiner (det som numera kallas för datorer) och psykologi, och frågade om det fanns något yrke där man kunde kombinera dessa ämnen. Studievägledaren sa: Nej, några sådana yrken finns inte! Intressant med tanke på hur viktig forskning om psykologi och datorer är numera!
1963 erbjöd KTH, där jag studerade elektroteknik (någon datalinje fanns inte ännu) en kurs i datorprogrammering. Vi skrev program i Algol som vi stansade på en hålremsa, som matades in till en dator av typ Facit EDB (vilken liksom TRASK var en transistoriserad kopia av elektronrörsdatorn BESK). Datorn läste in hålremsan, körde programmet och skrev ut resultatet. Om det var något fel i programmet, fick man stansa en helt ny hålremsa. Ett undantag var att man kunde ta bort tecken från hålremsan genom att stansa ut samtliga hål. Om det är någon som undrar varför ASCII-alfabetets tecken nummer 127 (sju ettor) betyder DELETE så har man förklaringen i att man på det sättet kunde radera ett tecken på en hålremsa utan att behöva skriva om hela remsan. DELETE betydde alltså från början "NULL" och inte som numera "radera". Att DELETE numera betyder "radera" beror på att detta tecken fanns på tangentbordet och då var det naturligt att använda denna lätt tillgängliga tangent för något man ofta behövde göra. Detta är ett bland många exempel på att standarder inte används på det sätt de från början var avsedda att användas.
KTH hade också en dator av typ Alvac-Vegematic från Axel Wennergrens försök att ge sig in i datorbranschen. Dess primärminne var en magnetiserad trumma med en accesstid på fyra (?) millisekunder (en modern dator år 2007, när detta skrivs, har mer än en miljon gånger snabbare primärminne). Några spår på trumman upprepades dock fyra gånger runt trumman, och gav därmed ett litet snabbminne med en accesstid på en (?) millisekund. Vegematic var byggd av elektronrör, och det blev ofta fel på dessa, så datorn fungerade i medeltal 30 sekunder efter uppstart innan det blev fel i något elektronrör. Jag lyckades därmed aldrig få något program att helt fungera på den datorn. Troligen fanns det bättre skötta Vegematic-maskiner på annat håll. Mer om Vegematic se [Jacobsson-Moberg 1999].
Något verkligen fascinerande var att det för dessa små tidiga datorer fanns kompilatorer för det komplicerade och avancerade programmeringsspråket Algol, ett språk med så avancerade funktioner som dynamiska proceduranrop, med parametrarna på en stack, så att en procedur kunde anropa sig själv rekursivt. Jag är full av beundran för de som utvecklade Algol-kompilatorer för dessa datorer. På grund av det lilla minnet måste kompileringen utföras i många steg där koden successivt omvandlades mellan olika mellanformat till den slutliga exekverbara maskinkoden.
När jag var nära slutet på mina KTH-studier frågade jag 1963 min professor, Germund Dahlqvist, var man kan få jobb där man kan arbeta med avancerad databehandling. Det finns bara två alternativ, sa Germund Dahlqvist, FOA (Försvarets forskningsanstalt) eller IBM. Jag valde FOA där jag sedan jobbade fram till 1982. FOA hade 1961 (?) köpt den tidens superdator, en IBM 7090 för 13 (?) miljoner kronor i den tidens penningvärde, motsvarar ca 130 miljoner kronor i 2007 års penningvärde. Den hade ett primärminne på 32 K ord med 36 bitar per ord, alltså ca 128 KB, ca en tiotusendel av vad en typisk persondator har idag (2007). Processorcykeltiden ca 2,28 mikrosekunder, alltså 0,44 Mhz, femtusen gånger långsammare än en typisk vanlig persondator år 2007.
Officiellt sa man att FOA köpt datorn för att kunna utveckla bättre skydd mot fientliga atomvapen genom att kunna göra simuleringar av kärnladdningar m.m. Många påstod att det var helt andra skäl till att svenska försvaret ville göra beräkningar av kärnladdningar. ÖB hade ju 1958 uttalat att försvaret borde utrustas med små, s.k. taktiska kärnladdningar.
7090 hade inget trumminne eller skivminne tillgängligt för vanliga användare (man kunde köpa till en liten trumma för operativsystemet, men jag tror inte den svenska 7090-datorn hade något sådant), utan alla data lagrades på magnetband. Eftersom datorn var så dyr och värdefull, måste man utnyttja dess kapacitet maximalt. Det gjorde man genom att skriva sina program på hålkort. Ett hålkort rymde 80 tecken. En skillnad mot hålremsorna för Facit EDB var alltså att man bara behövde stansa om de hålkort som innehöll felaktiga satser, före nästa exekvering. En tjock bunt hålkort från många användare lästes över till ett magnetband av en preprocessor av typ IBM 1401, och IBM 7090 exekverade sedan programmen från dessa magnetband. Denna omständliga procedur innebar att det tog 3-4 timmar från det man lämnade in sitt program (hålkortsbunt) till dess man fick resultaten. En programmerare kunde hålla sig sysselsatt genom att parallellt utveckla flera olika program, så att man gick igenom utskrifterna från ett program medan ett annat program låg i kö för körning på 7090-datorn.
I slutet på 60-talet byttes 7090 ut mot en IBM 360/75. Även för den gjorde man i ordning indata i form av en hålkortsbunt, men man fick resultaten efter fem minuter istället för fyra timmar. En fantastisk förbättring tyckte vi programmerare! Detta gällde dock bara program som inte krävde mer än 208 Kbyte primärminne, större program kördes bara över natten med resultat nästa dag. Detta var ett skäl till att vi inte använde LISP, det språket krävde på den datorn mer än 208 KByte primärminne. Att använda LISP med ett dygns omloppstid är inte det roligaste!
Eftersom försvaret skall förbereda för ovanliga och oönskade händelser, har "krigsspel" alltid varit en viktig del av arbetet. Detta har sin motsvarighet i datorsimuleringar, där man avbildar verkliga processer i en dator. Vid FOA arbetade jag mycket med sådana simuleringar av luftvärn mot lågt flygande fientliga bombplan. Att flyga mycket lågt är en metod att undvika luftvärnet. I våra simuleringar avbildas flyg, terräng och luftvärn och datorn räknar ut hur flygplanet och luftvärnsraketerna rör sig och om luftvärnet träffar eller missar på grund av att flygplanet försvunnit bakom terränghinder. Vi gjorde analyser av hur utfallet varierade med olika inparametrar. Denna analys ledde till att en enda inparameter var viktigare än någon annan. Den parametern var hur nära marken som de anfallande flygplanen kunde flyga. En del militära experter sa att planen inte kunde flyga lägre än 50 meter över topparna i terrägen (och högre upp över dalgångar), andra att planen kunde flyga så lågt som 10 meter över topparna. Flygvapenfolk sa 10 meter, armefolk sa 50 meter. Eftersom denna enda parameter hade så stor effekt på luftvärnets effektivitet gjorde vi verkliga mätningar på verkligt flyg, och det visade sig att i ideala förhålanden kunde flyget flyga så lågt som 10 meter över marken.
En viktig sak jag lärde mig var att för att få de militära experterna att tro på simuleringar, måste dessa göras så verklighetsnära att experterna kunde se av resultaten att dessa stämde med realistiska resultat. Således var det viktigare med enkla simuleringar av ett fåtal terrängformationer, där man kunde visa upp och åskådliggöra simuleringens resultat, än simuleringar över många olika terrängavsnitt och beräkning av medelvärden. Detta anknyter till vår moderna syn på människa-dator-interaktion, men var en insikt jag fick långt innan HMI blev ett känt begrepp.
7090-programmen på 1960-talet skrev vi i programmeringsspråket Fortran. Först Fortran II, vars enda IF-sats var en sats som hoppade till tre olika ställen i koden beroende på om ett heltal var mindre än 0, 0 eller större än 0. Det blev många hoppsatser i den dagens datorprogram, jämfört med idag där man ju praktiskt taget aldrig använder explicita hoppsatser i sina program.
Senare kommer Fortan IV, med logiska hoppsatser, som utvärderade ett Booleskt uttryck för att avgöra om man skall hoppa eller inte. Redan då fanns ju bättre programmeringsspråk, som Algol med "begin...end" och satser av typen
if <boolesktuttryck> then begin ... end else begin ... end;
Detta minskar behovet av hoppsatser i programmen enormt, men sådana nymodigheter tillhandahöll inte IBM till 60-talets datorer.
Fortran II hade andra märkvärdiga egenskaper. Subrutinerna (motsvarar det som senare kallades procedur och senare döptes om till metoder) var inte rekursiva. Om man anropade en subrutin med en numerisk konstant som parameter, visades denna konstant som en variabel i subrutinen. Ändrade man då värde på denna variabel, då ändrades en konstant i det anropande programmet. Alltså om man skrev så här:
K=2 CALL MYRUTIN(2) J=2 SUBROUTINE MYRUTIN(I) I=4 END
Så fick variabeln K värdet 2, men J fick värdet 4 och inte 2!
En stor skräck drabbade många av våra programmerare när vi 1970 (?) upptäckte att en ny optimerande Fortrankompilator för 360/75 kallad Fortran H gjorde att många av våra program slutade att fungera. Förklaringen visade sig vara att lokala variabler i subrutiner inte behöll de värden de fått vid en tidigare exekvering, nästa gång subrutinen anropades. Detta som ju numera är självklart för alla programmerare var inte självklart för oss i den statiska miljön från tidigare Fortrankompilatorer under 1960-talet.
Fortran H hade andra egenskaper som fick program att fungera annorlunda. T.ex. använde jag satsen IF(I/50*50.eq.I) för att ta ny sida var 50e rad. Men Fortran H optimerade detta Booleska uttryck till IF(I = I) så att programmet felaktigt tog ny sida för varje rad i tabellen!
De programmeringsspråk som fanns på denna tid saknade de objektorienterade egenskaper som numera är självklara hos alla programmeringsspråk. Enda undantaget var Simula 67, utvecklat av Kristen Nygaard och Ole Johan Dahl vid Norsk Regnesentral i Oslo. Simula 67 hade redan i början på 1970-talet nästan allt vad moderna programmeringsspråk har numera. Undantag var att det inte hade arrayer vars storlek kunde ändras dynamiskt och att det inte hade något inbyggt DBMS. Jag gjorde en utvärdering som visade att Simula 67 skulle halvera arbetet med att skriva simuleringsprogram, och FOA beslöt att tillsammans med Norsk Regnesentral i Oslo utveckla en Simula-kompilator för IBM 360. Från FOA deltog Lars Enderin och Stefan Arnborg i utvecklingsarbetet, själv gjorde jag bara kvarspecifikation och tester. Vi bidrog också med att utvidga Simula 67 med satserna HIDDEN och PROTECTED som gjorde Simula 67 till ett fullvärdigt modernt objektorienterat programmeringsspråk [Palme 1973]. Kompilatorn skrevs huvudsakligen i PL360, ett maskinnära programmeringsspråk liknande C, fast mycket enklare. PL360 hade utvecklats av Niklaus Wirth, samma man som skapade programmeringsspråket Pascal.
I början av 70-talet tillsatte FOA en arbetsgrupp som skulle göra en prognos för framtidens databehandling. Det enkla och naturliga sättet att göra en prognos var att förutspå ökad användning av det som redan fanns, t.ex. bättre väderleksprognoser när datorerna blev snabbare. Men vi insåg att detta inte var tillräckligt. Tvärtom, när datorerna blir snabbare och billigare, kommer ökningen att bli på sådan användning som tidigare inte varit lönsam, alltså datoranvändning där kostnads/nytto-kvoten var för hög för användning när prognosen gjordes. Vi gjorde därmed den korrekta förutsägelsen att bearbetning av text skulle bli den allra viktigaste datoranvändningen i framtiden. Vi insåg däremot inte vilken stor betydelse grafisk databehandling skulle få, trots att detta är ett utmärkt exempel på sådant som 1973 hade för hög kostnads/nytto-kvot för att vara lönsamt. De flesta datorer på den tiden lagrade text med bara sex bitar, vilket inte räcker till både små och stora bokstäver.
Fram till 1973 använde nästan alla programmerare vid FOA den ovan beskrivna metoden med att lämna in hålkortsbunt, vänta först 3-4 timmar, senare 5-10 minuter, och få resultat. Denna metod att interagera med en dator kallades för satsvis bearbetning (batch processing). Det som alla programmerare gör idag, får omedelbara felutskrifter och kan interaktivt avlusa sina program genom att observera dem under exekveringen, hade vi inte möjlighet till. Datorerna var för dyra för att ge varje programmerare en egen dator. Ett fåtal programmerare hade en egen dator, men då en sådan dator kostade mer än 100 000 kronor i den tidens penningvärde (en halv miljon kronor i 2007 års penningvärde), skulle man ha mycket speciella skäl för att få köpa en sådan.
Men vi hörde rykten om något som skulle kunna ge oss möjligheten att direkt interaktivt använda datorer. Det var något som kallades för time sharing. Med time sharing menas att många användare kan köra mot samma dator samtidigt, och var och en uppleva sig vara ensam om datorn genom att prosessorkraften delas mellan användarna. Vi skaffade material och testade några sådana system. Det fanns i huvudsak två typer av time-sharing-system. Den ena typen tillät bara time-sharing för program skrivna i ett enda programmeringsspråk, vanligen Basic. Med den andra typen kunde man köra vilka program som helst. Tidiga exempel på denna senare typ var PDP-10, Unix och Multics. FOA utredde och beslöt köpa en sådan dator, främst för interaktiva simuleringar/spel.
Bild av mig 1974 sittande vid en terminal till DECsystem-10 |
Vi begärde in offerter från maskinleverantörer och beslöt att köpa en DECsystem-10 (f.d. PDP-10). Den kostade ca 5 miljoner kronor i 1973 års penningvärde, hade 96 Mbyte primärminne och kunde klara ca 20 samtidiga användare. Unix var tyvärr inte tillräckligt känt och moget då och vi fick ingen offert på Unix. Hade vi vetat vad vi vet idag hade vi antagligen försökt skaffa en Unix-dator istället. Men 1973 var PDP-10 ett säkrare kort, som vi då trodde. Först i början på 1980-talet beslutade tillverkaren att lägga ner vidare utveckling av DECsystem-10. |
De offerter vi fick in från maskinleverantörer var nästan alla den typ av begränsade time-sharing system som bara tillät time-sharing för ett enda programmeringsspråk. De enda datorer utom DECsystem-10 som var möjliga alternativ för oss var två olika IBM-system, men de var mycket dyrare i förhållande till prestanda än PDP-10. IBM och PDP-10 var också de enda offererade datorerna som hade mer än sex bitar per tecken, så att man kunde använda text med både små och stora bokstäver, något som vi ansåg viktigt vid valet av dator.
Inköpet av DECsystem-10 blev start för en mängd spännande utvecklingsprojekt vid FOA, som beskrivs var för sig nedan.
FOA beslöt utveckla Simula 67 för DECsystem-10. Det blev det första moderna Simula-systemet med möjlighet till interaktivitet med användare under körningen och interaktiv debugging. Flera olika användare av samma DECsystem-10-dator kunde interagera med ett och samma Simula-program under exekveringen. Självklara saker idag, men nytt och spännande 1973.
Utvecklingen av Simula 67 för Decsystem-10 gjordes av ENEA med medverkan av två programmerare från FOA, Lars Enderin och Stefan Arnborg, som kunde överföra den kompetens de utvecklat när de var med att göra Simula 67 för IBM 360.
Simula-67-systemet för DECsystem-10 blev epokgörande i sitt slag genom att för första gången kombinera de flesta egenskaper moderna programmeringssystem numera har: Objektorienteirng, liststrukturer, garbage collection, interaktiv exekvering och debugging. I de flesta nu använda programmeringsspråk hittar man likheter med delar av Simula 67. Därutöver hade Simula 67 också stöd för händelsestyrda simuleringar, vilket var viktigt för FOA.
Innan Simula 67 var klart, utvecklade jag ett system GNOSIS för datorstödd undervisning. Det byggde på den föraktade modellen där användarna får växlande läsa information och svara på testfrågor. GNOSIS kompilerade sin källkod till Algol-60-kod, som sedan kompilerades med Algol-60-kompilatorn för DECsystem-10. Därigenom kunde man spränga in ren Algol-60-kod i GNOSIS-koden om man ville göra saker som GNOSIS inte klarade.
Med hjälp av Gnosis utvecklade jag en nybörjarkurs i användning av DECsystem-10 inklusive användning av texteditorn TECO (den tidens Emacs). Peter Olofsson skrev en kurs i användning av den alternativa textredigeraren SOS. Denna kurs blev en stor framgång och användes av nästan alla nya användare av DECsystem-10. TECO-kursen blev också internationellt spridd och populär.
GNOSIS loggade allt vad användarna skrev av felaktiga och riktiga kommandon när de besvarade frågorna i lektionerna. Jag ändrade successivt programmet, baserat på dessa loggfiler, så att programmet gav förklaringar för varje felaktigt kommando i loggfilerna, som talade om varför det var fel. När jag hade gjort detta för 100 användare, uppstod ett intressant fenomen. Folk som använde kursen sa till mig att "det är märkvärdigt hur intelligent datorn är" (på att förklara felaktiga kommandon). Och den enda intelligensen i programmet var att det manuellt hade försetts med förklaringar för alla fel som 100 användare av kursen skrivit. Det gav mig en ny insikt i begreppet artificiell intelligens!
Baserat på Simula-67 utvecklade vi ett flertal spännade program. Ett av dem var VIDED, ett av världens första ordbehandlingsysstem. VIDED kunde användas interaktivt med en delvis WYSIWYG-dialog. Dock kunde inte olika typstorlekar visas på skärmen, utan de simulerades med enkla HTML-liknande kommandon i texten. Till skillnad mot HTML hade vi en struktur där kommandona och texten tydligare skildes åt så att texten blev enklare att läsa.
VIDED blev mycket populärt bland DECsystem-10s användare. En onödigt infekterad strid uppstod i början av 80-talet när en grupp utvecklade en EMACS-klon (AMIS) för DECsystem-10 och skulle racka ner på VIDED för att visa fördelen med deras eget system. Deras system var dock en ren texteditor och inte som VIDED ett ordbehandlingsystem med möjlighet att t.ex. ha rubriker i större stil över text i normal stil.
I mitten av 1970-talet fick Sverige besök av Murray Turoff, (inbjuden av Tomas Ohlin) och han berättade om sin syn på datorer. Turoff och Roxanne Hiltz var pionjärer för datorbaserad gruppkommunikation. Datorer är som en bok med blanka blad, sa han, där vem som helst kan skriva vad de vill och vem som helst kan läsa det andra skrivit på sina sidor. Tre personer som lyssnade på Murray Turoff var jag (Jacob Palme), Torgny Tholerus och Tomas Ohlin.
Turoffs syn på datorer var för sin tid epokgörande. Vi som lyssnade blev fascinerade, och bidrog var och en till att ett system baserat på Turoffs idéer utvecklades i Sverige. Tomas Ohlin motiverade Styrelsen för Teknisk Utveckling (STU) att finansiera inköp av ett rudimentärt amerikanskt system Planet-Forum, som vi testade och som gav oss förståelse för behovet. Jag övertygade FOA att betala för utvecklingen, Torgny Tholerus gjorde utvecklingen. Första versionen av forumsystemet KOM togs i drift 1978 [Palme 1990]. Datainspektionen förbjöd systemet kort efter start med motiveringen att datalagen inte tillåter folk att skriva vilken text de vill på "blanka sidor i datorn" och låta vem som helst läsa vad de skrivit. Enligt datainspektionen tillät datalagen bara att man i datorn hade namngivna fält där de kunde skriva i tillståndsbeslutet vilken information vaje fält i datorn fick innehålla. Jag hade tidigare haft debatter med Jan Freese, en av datalagens skapare, där jag kritiserade denna idé och hävdade att det innebär en kränkning av den grundlagsskyddade yttrandefriheten att inte tillåta fri kommunikation via datorer. Bidragande till datainspektionens beslut var också stark kritik från LO och TCO, som trodde att datorerna skulle ge ytterligare större inflytande åt ett fåtal informationsrika personer och minska jämlikheten i tillgång till information. Speciellt rabiat motståndare var TCO. Detta är intressant att notera, därför att TCO under 90-talet istället varit mycket aktiv för att stärka yttrandefriheten på Internet, alltså rakt motsatt åsikt mot 1978.
Mina chefer vågade inte överklaga Freeses beslut hos regeringen. Risken var stor att den tidens regering inte förstod de möjligheter för yttrandefrihet som datorer erbjuder och att de skulle avslå ett överklagande. Istället förhandlade FOA och datainspektionen fram en kompromiss, innebärande:
|
Jag har senare beskrivit datainspektionens nya beslut genom att säga att man förbjuder just det som den svenska grundlagen speciellt vill skydda, nämligen yttrandefriheten ifråga om politik och religion, och att reglerna om radering av alla meddelanden är jämförbara med om man lagstiftade att alla böcker i biblioteken måste brännas efter två år. Jan Freese har, gissar jag, många gånger ångrat att han genomdrivit ett sådant demokratifientligt avtal i strid med den svenska grundlagen.
Man kan lägga till att vi aldrig implementerade raderingen efter ett visst antal år, och några av mötena i KOM finns fortfarande kvar och kan läsas på webben [KOM 1978-1987]. Dock raderade vi alla skyddade möten i systemet efter ca 5 månader. Jag väntar fortfarande på att datainspektionen skall åtala mig för detta brott mot deras instruktioner och för att jag tvärtemot deras intentioner har publicerat KOM-mötena på webben så att vem som helst kan läsa dem, långt efter den två-årsfrist där datainspektionen krävde att vi raderade all information.
Mer om KOM-systemet på engelska finns i [Palme 1990].
Datainspektionens beslut om att vi skulle utvärdera nyttan med systemet ledde till att FOA satsade resurser på en grundlig utvärdering av effekterna av systemet. Denna utvärdering innebar en tidig forskning om effekter av datorstött samarbete [Palme 1981].
De två allra första kopplingarna till Internet gjordes oberoende av varandra i början på 1980-talet dels av oss, dels av Björn Eriksen. Vi utvecklade en koppling mellan KOM-systemet och Mailnet. Björn Eriksen utvecklade en koppling mellan Usenet i svenska och utländska värddatorer. Båda tjänsterna erbjöd epost och gruppdiskussion via forum eller mailinglistor. Fullständigt Internet med alla tjänster kom först 1988 till Sverige.
De programvaror, Simula, Vided, KOM m.m. som vi utvecklade för DECsystem-10, fick vid spridning och implementerades på hundratals servrar över hela världen, och hade sannolikt tusentals användare. Det var mycket på den tiden! De blev också mönsterbildande för många andra datorprogram som byggde på idéerna i våra system. Simula porterades av Lars Enderin även till DECSYSTEM-20, en modernare version av DECsystem-10 och mera lik Unix. Jag minns att Bengt Olsen sa om mig att "allt du rör vid blir guld". Tyvärr stämde inte denna prognos så bra in på vad jag senare kom att göra under åren 1985-2002. Först 2003 lyckades jag återigen skapa "guld" igen med Web4Health.
Den allmänna synen på datorer i samhällsdebatten under 1970-talet var helt annorlunda än idag. Då ansåg man att datorer främst hade följande egenskaper [Palme 2000]:
|
Att datorer skulle kunna användas för att vidga yttrandefriheten och öka tillgången till information för många människor, var något som några få av oss hävdade men inte lyckades få något stöd av i den allmänna debatten.
[Jacobsson-Moberg 1999]: När datorerna ännu var matematikmaskiner av Åke Jacobsson och Rune Moberg., PVarv 1999. http://web.telia.com/~u30207596/v99sid20-22.htm
[KOM 1978-1987]: Dokument ur den svenska datorhistorien - ur KOM-systemet vid QZ 1978-1987. Diskussioner om bl.a. kärnkraft, jämställdhet, konstiga fenomen, standarder, textredigerare. http://people.dsv.su.se/jpalme/qzkom/.
[Palme 1973]: Protected program modules in Simula 67. Modern Datateknik, no. 12 p 8.
[Palme 1981]: Experience with the use of the COM computerized conferencing system. http://dsv.su.se/jpalme/reports/c10166.pdf.
[Palme 1990]: History of the COM computer conferencing system. http://dsv.su.se/jpalme/s1/history-of-KOM.html.
[Palme 2000]: A personal history of CMC. In honorary publication dedicated to Yvonne Waern. http://people.dsv.su.se/~jpalme/s1/a-personal-history-of-CMC.pdf.
[Palme 2006]: Before the Internet. I ICT for people, 40 years of academic development in Stockholm, pp 179-183. ISBN 13: 978-91-631-9588-4, ISBN 10: 91-631-9588-7.