Industriella Erfarenheter av Erlang
Innehållsförteckning
- I
- Förord
- II
- Sammanfattning
- 1
- Inledning
- 1.1
- Bakgrund
- 1.2
- Problemområde
- 1.3
- Utredningsuppdrag och syfte
- 1.4
- Mål
- 1.5
- Målgrupp
- 1.6
- Avgränsning
- 1.7
- Metod
- 1.7.1
- Projekten
- 1.7.2
- Studenterna
- 1.8
- Läsanvisning
- 2
- Perspektivanalys
- 2.1
- Föreställningar
- 2.2
- Erfarenheter
- 3
- Kunskapsanalys
- 3.1
- Kunskapsinventering
- 3.2
- Kunskapsbehov
- 4
- Programvarukrav inom telekommunikationsindustrin
- 5
- Imperativa/ deklarativa språk
- 6
- Bakgrunden till Erlang
- 7
- Beskrivning av Erlang
- 8
- Projekten
- 8.1
- EBC IsoEthernet
- 8.1.1
- Projektbeskrivning
- 8.1.2
- Erfarenheter
- 8.1.3
- Jämförelse med andra programspråk
- 8.1.4
- Programspråkets betydelse
- 8.2
- EBC/MD
- 8.2.1
- Projektbeskrivning
- 8.2.2
- Erfarenheter
- 8.2.3
- Jämförelse med andra programspråk
- 8.2.4
- Programspråkets betydelse
- 8.3
- ERA-t
- 8.3.1
- Projektbeskrivning
- 8.3.2
- Erfarenheter
- 8.3.3
- Jämförelse med andra programspråk
- 8.3.4
- Programspråkets betydelse
- 8.4
- ETX/B
- 8.4.1
- Projektbeskrivning
- 8.4.2
- Erfarenheter
- 8.4.3
- Jämförelse med andra programspråk
- 8.4.4
- Programspråkets betydelse
- 8.5
- Mobility server
- 8.5.1
- Projektbeskrivning
- 8.5.2
- Erfarenheter
- 8.5.3
- Jämförelse med andra programspråk
- 8.5.4
- Programspråkets betydelse
- 8.6
- NETSim
- 8.6.1
- Projektbeskrivning
- 8.6.2
- Erfarenheter
- 8.6.3
- Jämförelse med andra programspråk
- 8.6.4
- Programspråkets betydelse
- 9. Studenternas erfarenheter av Erlang
- 9.1
- Beskrivning av examensarbetena
- 9.2
- Erfarenheter
- 9.3
- Jämförelse med andra programspråk
- 9.4
- Programspråkets betydelse
- 10
- Analys
- 11
- Slutsatser
- 12
- Avslutande diskussion
- 13
- Källförteckning
- 14
- Ordlista
Bilagor
- intervjuguide för projektledare
- intervjuguide för programkonstruktörer
- enkätfrågor till examensarbetare
- programexempel
- Fotnoter
Denna rapport är ett avslutande arbete på den Systemvetenskapliga linjen på Linköpings universitet. Detta arbete har kommit till med många människors hjälp. Utan alla inblandade personers stöd så hade detta arbete varit svår att genomföra. Jag vill speciellt tacka min uppdragsgivare Bengt Lennartsson som har haft många visioner och varit till mycket stor hjälp i mitt arbete.
Tack även till:
Roy Bengtsson, Erlang Systems Division AB
Mike Williams, Erlang Systems Division AB/ Ellemtel
Bjarne Däcker, Ellemtel
Anders Berglund, KTH
Tomas Aronsson, CTH
Johan Grafström, CTH
Jonna Palm, Högskolan i Skövde
Anders Wennerström, Ericsson
Sist men inte minst vill jag tacka alla berörda Ericsson projekt för att de har ställt upp att dela med sig sina erfarenheter av Erlang.
Linköping den 17 Januari 1996
Johan Carleson, Johan.Carleson@nor1.wmdata.se.
Denna rapport är en redogörelse för ett examensarbete som har utförts på den systemvetenskapliga linjen vid Linköpings universitet. Rapporten är en empirisk studie där industriella erfarenheter av programspråket Erlang har samlats in och analyserats.
Denna uppsats har som syfte att besvara frågor som: Vad finns det för fördelar/nackdelar med Erlang, hur skiljer sig Erlang från andra språk, hur påverkas kodkvaliteten och utvecklingstiden, i vilka sammanhang passar Erlang bäst/sämst med etc. Ett annat syfte är att jämföra för- och nackdelar av Erlang jämfört med andra vanliga programspråk som används inom telekommunikationsindustrin idag.
För att få svar på dessa frågor genomfördes en empirisk studie av sex programutvecklingsprojekt som har använt sig av Erlang. De personer som intervjuades i projekten var främst programkonstruktörer men även en del projektledare. För att få in andra synvinklar gjordes även en mindre kompletterande enkätstudie av fyra examensarbetares erfarenheter av Erlang.
De slutsatser som kan dras av arbetet är:
Det var bara ett projekt av sex som har haft problem med införandet av Erlang. Man hänför dock dessa problem till andra faktorer än själva programspråket. Det har handlat om bristfällig utbildning och kompetens som har gjort det svårt att dra full nytta av Erlangs hela styrka.
Generellt så är alla överens om att Erlang är ett litet och kraftfullt språk som passar bl.a. för realtidssystem , telekommunikation och distribuerade system.
Språket är lätt att lära sig och har en hög abstraktionsnivå som hanterar programdesignens komplexitet på ett bra sätt. Den programkod som skrivs blir ofta kortare än programkod som skrivs i imperativa programspråk. Antalet fel i programkoden kan även minska genom att man använder Erlang som implementationsspråk.
Det finns några frågetecken om Erlangs möjlighet att fungera som gränssnitt till andra programspråk.
En annan slutsats av detta arbete är att programspråket inte har så stor betydelse för om ett projekt skall lyckas eller ej. Det finns andra faktorer som är viktigare som t.ex. utbildning, stabilitet i projektorganisationen och förhållandet mellan språk och metod.
Denna rapport är ett examensarbete utfört på den Systemvetenskapliga linjen, Universitetet i Linköping. Rapporten är en avslutande redovisning av det arbete som genomfördes under våren 1995, vilket motsvarar 10 poäng.
Arbetet är ett utredningsuppdrag från institutionen för datavetenskap (IDA), Universitetet i Linköping.
Det problemområde som detta arbete har berört, har varit både stort och delvis okänt för mig. Detta har medfört att målet blev att samla in så mycket information på området som möjligt. I arbetet har en explorativ ansats använts, för att fånga upp nya frågor och tankar som har dykt upp i arbetsprocessen.
Ett stort problem har varit att komma i kontakt med projekt som har använt sig av Erlang. Detta berodde till en viss del på att många projekt var av konfidentiell karaktär. Ambitionen var att komma i kontakt med kommersiella programutvecklingsprojekt som nyligen hade lanserat en produkt gjord med Erlang och som därmed kunde förmedla både positiva och negativa erfarenheter av detta arbete.
En annan sida av detta arbete var att jämföra Erlang med andra programspråk. För att detta skall kunna ske så behöver man antingen likartade projekt där man programmerar i olika språk eller förlita sig på programmerarnas tidigare erfarenheter med andra programspråk, för att kunna finna skillnader.
Utredningen har gjorts med stöd ifrån och på uppdrag av Institutionen för datavetenskap (IDA) Linköpings universitet. Direktiven för undersökningen gick ut på att sammanställa och analysera industriella erfarenheter av programspråket Erlang. Det som skulle undersökas var bl.a. hur valet av Erlang påverkar : implementationen, programvaruarkitekturen och programvarudesignen.
Denna uppsats har som syfte att besvara frågor som: Vad finns det för fördelar/nackdelar med Erang, hur skiljer sig Erlang från andra språk, hur påverkas kodkvalitet och utvecklingstid, vilka sammanhang passar Erlang bäst/sämst för. Ett annat syfte är att jämföra för- och nackdelar av Erang jämfört med andra vanliga programspråk som används inom telekommunikationsindustrin idag.
Målet med detta examensarbete är att förmedla samt reflektera över erfarenheter av programspråket Erlang inom telekommunikationsindustrin. Genom att utveckla denna kunskap så hoppas jag kunna tillföra viktig information om programspråkets egenskaper. Denna information skulle kunna användas som beslutsunderlag för en verksamhet eller projektgrupp som funderar på att använda sig av Erlang i ett projekt. Ett annat mål är att undersöka vad valet av programspråk har för betydelse för programutvecklingsprojekt i ett större perspektiv.
Utredningens målgrupp är först och främst min uppdragsgivare - Institutionen för datavetenskap (IDA) vid Linköpings universitet. Andra grupper som skulle kunna vara intresserade av detta arbete är programutvecklingsprojekt som står inför valet att välja Erlang som programspråk men som vet lite för lite om vad detta kommer att medföra för konsekvenser. Är man nyfiken på vad Erlang är för något kan den här rapporten också fungera som en kort introduktion eller inkörsport till språket. Förkunskaper i Erlang eller andra deklarativa språk behövs inte för att man skall kunna tillgodogöra sig innehållet i denna rapport.
De intervjuer som är gjorda omfattar endast projekt inom Ericssonkoncernen. Detta beror på att Erlang endast har funnits som en kommersiell tillämpning i två år. Det har således inte kommit igång utomstående projekt som skulle kunna vara aktuella för denna studie.
Att finna jämförbara projekt (både till storlek, tid, komplexitet och funktionalitet) är i det närmaste omöjligt. Även om man kunde finna sådana projekt så finns det många andra faktorer som kan påverka en jämförelse, exempelvis programmerarnas kompetens eller metodval. Att gallra ut egenskaper som språket besitter från andra variabler som påverkar ett projekt är därför mycket svårt.
För att samla in konkreta erfarenheter av Erlang så har jag primärt valt intervjuer som tillvägagångssätt. Jag har i första hand intervjuat programkonstruktörer i projekt som använder sig av programspråket Erlang. De berörda projekten återfinns alla inom telekommunikationsindustrin och ingår i den svenska delen av Ericssonkoncernen.
För att få kontrast och lite andra synvinklar till projektgruppernas erfarenheter gjorde jag konkreta försök att nå andra personer med erfarenheter inom området. Detta visade sig vara mycket svårt och jag var mycket nära att ge upp denna idé. I ett sent skede i arbetet kom jag dock i kontakt med ett antal studenter som höll på med sina examensarbeten om Erlang. Jag fann det därför angeläget att fånga upp även deras erfarenheter inom området. Syftet med att kontakta både projekten och studenterna var att få fram en mer nyanserad bild av programspråkets egenskaper.
Min tanke var att jag genom indelningen i dessa båda grupper skulle få in ett material som täcker in de flesta av språkets karakteristiska egenskaper. Jag skulle kanske därigenom kunna fånga upp andra typer av problem eller egenskaper som programspråket har.
Eftersom studenterna hade en begränsad erfarenhet av programspråket, avsåg jag inte att göra några större jämförelser mellan deras och projektgruppernas uppfattningar inom området. Jag valde istället att sammanställa materialet för att kunna bekräfta, ifrågasätta eller komplettera projektgruppernas uppfattningarna.
Mitt arbete bygger således i första hand på de insamlade uppgifterna från de olika projekten. I den mån de olika projekten och studentgruppen har en gemensam syn på språkets egenskaper så ser jag detta som en bekräftelse på att de uppmärksammade förhållandena stämmer. I den mån det finns avvikelser mellan dessa båda gruppers uppfattning eller inställning till språkets egenskaper, så analyserar och behandlar jag detta i den efterföljande analysdelen.
Vid sidan av arbetet med att samla in konkreta erfarenheter så har jag även gjort en genomgång av litteratur som finns att tillgå om Erlang och deklarativa språk. Syftet med denna litteraturstudie har varit att skapa ett stark grund för intervjuerna men även för att kunna redogöra för språkets struktur samt dess funktioner. Litteraturstudien har även berört imperativa och deklarativa programspråks typiska egenskaper.
För att komma i kontakt med lämpliga programutvecklingsprojekt som har använt sig av Erlang så etablerades en kontakt med Erlang Systems Division AB. Erlang Systems Division AB är leverantör av språket och känner till de projekt som har köpt och använt sig av Erlangmiljön.
Detta förfaringssätt är naturligtvis inte helt problemfritt. Den största risken är att det kan ske ett medvetet eller omedvetet urval av projekt som har specifika erfarenheter och som inte är representativa för andra projekt som har använt sig av Erlang. Min förhoppning var att denna strategi ändå skulle vara användbar. Detta grundar jag bl.a. på att Erlang Systems Division AB var mycket intresserade av att det gjordes en studie av någon utanför Ericssonvärlden och att man fick fram både bra och dåliga egenskaper hos språket. Eftersom språket fortfarande utvecklas till en viss del, så är man från Erlang Systems Division AB angelägna om att få ta del av all kritik mot språket. Många projekt har även på ett aktivt sätt kunnat påverka språkets successiva utveckling.
Hade språket haft större spridning i eller utanför Ericssonkoncernen skulle jag ha kunnat arbeta på ett mer traditionellt sätt där jag själv hade kontaktat projekten, men under de omständigheter som rådde såg jag inga andra möjligheter.
Kontakten med projekten
Valet av projektgrupper som skulle studeras gick till på följande vis.
Vid en sammankomst på Erlang Systems Division AB den 27 mars med Roy Bengtsson (VD), Bjarne Däcker (Ellemtel), Mike Williams (Ellemtel/Erlang Systems Division AB), och min uppdragsgivare Bengt Lennartsson fastställdes vilka urvalskriterier som var viktiga för urvalet av projekt till undersökningen.
Vi ansåg det vara viktigt att de utvalda projekten var av varierande storlek. Därför såg vi till att ta med små, medelstora och stora projekt bland de undersökta projekten. Små projekt är projekt med två till fem projektmedlemmar medan stora projekt har fler än 20 projektmedlemmar. Anledningen till att vi ansåg det vara väsentligt att representera dessa olika projekttyper var att vi därigenom skulle kunna isolera oss från eventuella felaktiga slutsatser som har att göra med projekstorleken.
Ett av dessa skäl är att andelen programmerare i regel är större i små projekt än vad det är i stora projekt. Stora projekt kräver mycket administrativ personal och projektstyrning medan detta är mindre viktigt i små projekt. Följaktligen kan effekten av programspråket uppmärksammas mer i små projekt än i större projekt. Man kan också tänka sig att små projekt oftast sysslar med prototyper och verkar inom forskning i större utsträckning än vad man gör i större projekt. I de större projekten sysslar man oftast med att konstruera kommersiella tillämpningar med höga krav på prestanda och funktionalitet. Dessa scenarier ställer olika krav på implementationsspråket. I små projekt kanske man eftersträvar ett flexibelt programspråk medan man i ett stort projekt eftersträvar ett stabilt och enkelt programspråk. Sammantaget kan man säga att projektstorleken bl.a. gör att projekten har olika förutsättningar. Dessa olika förutsättningar gör att man ställer olika krav på implementationsspråket.
Ett annat viktigt urvalskriterium var att vi företrädesvis valde projekt där man utvecklade någon form av kommersiell produkt. Med kommersiell avses här en produkt som inte främst var avsedd att användas internt inom den egna avdelningen utan som skulle säljas externt eller till något annat Ericssonbolag. Den främsta anledningen varför detta var ett viktigt kriterium var att det oftast ställs högre krav på en kommersiell produkt än på en produkt som främst är avsedd att användas internt. Vidare ställs även andra typer av krav på kommersiella produkter (exempelvis höga krav på prestanda och funktionalitet m.m.). När man skall konstruera en kommersiell produkt ställs man således inför andra typer av problem än vad man gör inom t.ex. forskning och utveckling.
Oftast innebär kommersiella produkter högre krav på implementationsspråket än vad som annars ställs. Det kan ställas krav som att språket skall vara lätt att lära sig samtidigt som det måste vara mycket kraftfullt. Avsikten med detta arbete var att samla in industriella erfarenheter av Erlang. Det låg således i sakens natur att vi i första hand valde projekt som ställde höga krav på implementationsspråket för att utvärderingen av Erlangerfarenheterna skulle bli så komplett och heltäckande som möjligt. Vi avsåg därför främst att kontakta projekt där man har använt sig av Erlang under så realistiska förhållanden som möjligt.
Det tredje viktiga kriteriet som ställdes upp var att vi skulle få med både projekt som hade utfallit som planerat och projekt som haft någon form av problem eller svårigheter i sitt arbete. Risken var att alltför positiva/negativa händelser i projekten skulle inverka på de upplevda erfarenheterna av programspråket. Därför ansåg vi det som ytterst väsentligt att båda dessa typer av projekt fanns representerade i undersökningen för att det skulle vara möjligt att isolera dylika fenomen.
Intervjuerna i projekten
Jag har intervjuat 12 personer i sex olika programutvecklingsprojekt som har använt sig av Erlang. Fem av dessa projekt fanns i Stockholm medan ett fanns i Linköping. Intervjuerna skedde under tiden 20/4-11/5. De personer som jag har intervjuat har främst varit programkonstruktörer som använt Erlang som implementationsspråk. Utöver denna grupp så har jag även försökt att få kontakt med projektledarna i de större projekten, för att se om det fanns delade meningar om språkets egenskaper inom respektive projekt.
Till stöd för intervjuerna utarbetades intervjuguider, vilka fungerade som en kontroll för att de frågeområden som ansågs viktiga att belysa också kom med i intervjuerna. Dessa guider återfinns sist i uppsatsen som bilaga 1 och 2.
Intervjuerna, vilka varade omkring en och en halv timme till två timmar, var direkta och ett mellanting av strukturerade och ostrukturerade. Utifrån intervjufrågorna uppmanades intervjupersonerna hela tiden att utveckla och/eller motivera sina svar. Intervjuerna skrevs ner för hand under intervjuernas gång. Utskriften sändes sedan till de intervjuade för att dessa skulle ha möjlighet att rätta eventuella missförstånd innan uppsatsen lämnades in. För att få någon uppfattning om vad som var väsentliga frågor till intervjuguiden så hade jag i förväg gjort en kortare genomgång litteraturen. De frågor som projektledarna fick skilde sig ifrån de frågor som programkonstruktörer fick. Detta berodde på att projektledarna i regel inte hade någon direkt erfarenhet av programmeringen.
Kontakten med de olika studenterna etablerades på många olika sätt. På Ericsson Infocom Consultants fick jag kännedom om en person som höll på med ett examensarbete om Erlang. Denne kände i sin tur två examensarbetare som höll på med något liknande. En fjärde person fick jag kontakt med sedan jag skickade en förfrågan om "Erlangerfarenheter" till Usenet newsgroup:en - comp.lang.functional, på internet.
Studenterna går alla på någon form av civilingenjörsutbildning och har fått sina examensarbeten i uppdrag av olika Ericssonbolag. Deras arbeten går ut på att implementera något i Erlang för att sedan skriva en rapport om detta arbete.
Alla studenterna har vidare gått på den fyra-dagarskurs som Erlang Systems AB ger och som skall utgöra den tillräckliga grund en för att man skall kunna behärska språket. De har dock inte någon längre tids praktisk erfarenhet av Erlangprogrammering. Detta gör att jag inte helt okritiskt kan använda mig av jämförelser mellan denna grupp och projektgruppen. Trots det faktum att studenterna har mindre praktisk erfarenhet och utför en avgränsad uppgift så rör det sig om kvalificerat arbete som kräver ingående kunskaper av de inblandade. Den gemensamma bakgrunden gör att de har likartade förutsättningar för att lösa sina uppgifter vad beträffar kunskap och tidigare kunskaper i programmering. Därför ser jag ingen anledning att urskilja de olika personerna redovisningen av materialet.
Intervjuerna med studenterna
Intervjuerna med denna grupp har gjorts med hjälp av enkäter med ganska öppet formulerade frågor. Enkäten innehöll 5-6 frågor och skickades ut till personerna med hjälp av elektronisk post. Anledningen till detta förfaringssätt var att det var det snabbaste och enklaste sättet att komma i kontakt med dessa personer. Jag var även i ett mycket sent skede i mitt arbete, vilket tvingade mig att få in dessa svar mycket snabbt. Frågorna skickades ut den 8 juni och kom tillbaka redan samma dag. Enkäten återfinns i bilaga 3 i slutet av uppsatsen.
Resultatet från projektintervjuerna kommer att beskrivas projektvis.
Presentationen av respektive projekt inleds med en projektbeskrivning där projektmedlemmar och projektuppgift presenteras. Efter den inledande projektbeskrivningen kommer delen med projektmedlemmarnas erfarenheter och synpunkter på Erlang. Denna del följs av en del där skillnaden mellan Erlang och andra programspråk tas upp. Avslutningsvis kommer en reflektion över programspråkets betydelse i ett mer övergripande perspektiv.
Efter presentationen av alla projekten kommer ett kapitel med studenternas erfarenheter. Redogörelsen för studenternas erfarenheter kommer att göras i en gemensam del. Anledningen till detta är att de i mångt och mycket har gemensamma faktorer som gör det lämpligt att samla ihop dessa personer till en uttalad grupp.
I detta avsnitt redovisas de föreställningar och tankar som jag hade innan jag började mitt arbete med litteraturstudien och undersökningen. Detta är av stor vikt för att jag skall kunna göra mig kritiserbar. För att möjliggöra detta är det av stor vikt att mina föreställningar och tankar utskiljs från det övriga materialet.
Den systemvetenskapliga linjen i Linköping har en verksamhetsinriktad syn på systemutvecklingen. Med detta menas att man fokuserar systemutvecklingsarbetet på hela verksamheten och inte endast dess delar. Det jag har fått med mig är således en holistisk syn på systemutvecklingen, d.v.s. att helheten är viktigare än dess delar. Detta synsätt har följaktligen präglat både mig som person samt min syn på tillvaron. Jag tror att man måste betrakta en verksamhet eller område efter dess helhet, annars finns det en uppenbar risk för att man fokuserar på oväsentliga detaljer i sammanhanget.
Min föreställning om Erlang var att det var ett ganska nytt och ännu okänt programspråk som främst används inom Ericsson. Eftersom jag inte har några direkta erfarenheter av språket kunde jag inte heller göra några uttalanden om språkets egenskaper. Jag kom dock på min praktik i kontakt med projektet NETSim som verkade ha en del positiva erfarenheter av språket. Denna bakgrund har dock inte påverkat mig i mitt arbete med att samla in empiriska erfarenheter av Erlang. Den har snarare väckt en ökad nyfikenhet för att verkligen undersöka vad som är den allmänna bilden av Erlang.
Den bakgrund och de kunskaper som jag har inom rapportens område härstammar till stor del från den systemvetenskapliga linjen och min praktik som gjordes våren 1994.
Jag har ingen stor erfarenhet av deklarativa programspråk. Det som jag visste om Erlang sedan tidigare härstammar från min praktik på Ericsson Infocom Consultants, där jag bl.a. ansvarade för testa en AXE-simulator som var skriven i Erlang. Det är dessa kunskaper och erfarenheter som utgör min referensram.
Innan undersökningen kunde börja gjorde jag en kunskapsinventering. Denna bestod i att jag aktivt sökte efter litteratur som berörde problemområdet. Den litteratur som fanns att få var främst utdrag ur olika tidskrifter m.m. Därför sökte jag även efter litteratur på internet med viss framgång.
Problemet med att finna litteratur på detta område är att det inte har skrivits särskilt mycket om erfarenheter av Erlang. Därför är mitt arbete lite av ett pionjärarbete på området.
För att skaffa mig den för-förståelse och de kunskaper som skulle behövas för att slutföra rapporten så var jag tvungen att ta hjälp av tillgänglig litteratur inom området. Den litteratur som främst avses behandlar grundläggande begrepp inom deklarativa programspråk men även strategier för att kunna utvärdera effekterna av införandet av ett programspråk.
"Telekommunikationsindustrin är högst beroende av programvara. Utvecklingen och underhållet av programvara står för en mycket stor del av ett systems kostnader.
Det är därför väsentligt att produktiviteten i programvarudesignen förbättras med den allra senaste tillgängliga teknologin."
Bjarne Däcker [ 8 ]
Telefonväxlar är komplexa och dyra installationer. Det krävs många anställda som programmerar under mycket lång tid, för att utveckla programvara till ett telekommunikationsväxelsystem. Dessa system har en unik kombination av problem/svårigheter som måste bemästras. Egenskaper hos programvara inom telekommunikationsindustrin är bl.a.:
Komplexitet
Typiska system innehåller flera miljoner rader källkod i imperativa språk .Lång utvecklingstid
Komplexiteten gör att det tar lång tid att utveckla programvara inom detta område.
Distribution
Växelsystem för telekommunikation styrs ofta av många olika processorer. Regionala processorer exekverar kritiska realtidsuppgifter medan centrala processorer hanterar komplex telefonlogik .
Samtidighet
Ett stort telefonväxelsystem kan ha flera tusen telefonsamtal igång samtidigt. Samtidigt som en telefonväxel hanterar alla telefonsamtal, skall det vara möjligt att utföra operationer och underhåll på den. Det kan vara flera tusen eller till och med hundratusen tals parallella processer i programvaran till ett växelsystem. Eftersom det är många processer samt att dessa är dynamiska så måste tiden för att skapa och avlägsna processer vara liten.
Lång livstid
Ett telefonväxelsystem är ett system som kommer att användas under lång tid.
Programkoden i ett system ändras många gånger under dess "livstid" för att bl.a. för rättning av fel men även för att möta nya krav och ny funktionalitet.
Realtid
Mycket i en telefonväxel måste utföras inom en viss tid efter det att en handling har påbörjats. Det får det inte förekomma fördröjningar i programvaran.
Öppna system
Det måste vara möjligt att lägga till andra mjukvarukomponenter till applikationerna. Vidare måste systemet fungera med andra mjukvarukomponenter som till exempel databaser, grafiska gränssnitt, kommunikation m.m.
Robusthet.
Ett telefonväxelsystem måste kunna fungera och vara driftsäkert under en lång tid. Därför måste både hård- och mjukvara vara okänsliga för fel och driftstörningar. Det måste även vara möjligt att byta programvaran i ett växelsystemet under drift utan att man behöver stoppa systemet.
Alla programspråk kan delas in i två grupper imperativa och deklarativa (se bild 1). De imperativa språken som Fortran och C, utmärks av att syntaxen består av kommandon. I de deklarativa språken formulerar programmen i stället de regler som gäller för det problem som skall lösas. Deklarativa språk delas i sin tur in i funktionella språk och logikspråk.
Bild 1: Programspråkens indelning i kategorier.
Dessa "programfamiljer" har både olika egenskaper och struktur jämfört med varandra. Problemet med imperativa språk är de repeterande och stegvisa beräkningarna som sker av variabler samt variablernas tilldelning till minnesplatserna. Många gånger finns det ingen anledning för programmeraren att befatta sig med detaljer på denna maskinnära nivå.
Imperativa språk är hårt bundna till datorns arkitektur för att kunna utföra beräkningar medan deklarativa språk i grunden bygger på en typ av matematisk formalism som inte är lika känslig för datorns arkitektur. Imperativa programspråk har därför oftast en låg abstraktionsnivå jämfört med deklarativa programspråk.Det finns även begränsningar i en del av dessa programspråk när man behöver implementera realtidssystem. Språk som C och C++ används ofta för att implementera denna typ av system, men eftersom dessa är sekventiella programspråk (d.v.s. exekveringen sker sats för sats) så måste man antingen ha ett operativsystem som stödjer samtidighet eller funktioner i programspråket som kan hantera detta.
De senaste årens diskussion om svagheterna i imperativa programspråk, har resulterat i ett tilltagande intresse för så kallade deklarativa programspråk. Dessa språk skiljer sig en hel del från de mer traditionella programspråkens7 uppbyggnad. De deklarativa språkens uppbyggnad och konstruktion medför många fördelar jämfört med imperativa språk.Exempel på fördelar som deklarativa programspråk har:
Kraftig och uttrycksfull syntax
Hög abstraktionsnivå
Parallell evaluering
Ett av de starkaste argumenten för deklarativa programspråk anses vara den automatiska minneshanteringen. Programmeraren behöver inte själv allokera minne och hålla reda på eventuella minnesläckor. Pekare existerar inte. Vad som också är utmärkande för delmängden funktionella språk är möjligheterna att skapa generella funktioner med listor som kan innehålla element av vilken typ som helst. Dessa egenskaper har gjort att man under många år forskat om programspråk inom detta område. I Sverige har detta arbete resulterat i programspråket Erlang från Ellemtel och H från Carlstedt Elektronik AB [ 4 ]. Språket H försvann så småningom medan Erlang verkar vara ett programspråk på frammarsch.
De funktionella programspråken lider dock av ett "image- problem". Länge har dessa språk ansetts som långsamma och ineffektiva, något som de fortfarande, och delvis oförtjänt, får dras med.
Utvecklingen av programvara står för den största delen av designkostnaden för Ericssons produkter. Det har exempelvis skrivits 62 miljoner rader källkod för AXE-10 [ 25 ]. Att minska kostnaderna för programvarudesignen, förbättra kvaliteten och korta ner utvecklingstiden har därför varit viktiga mål för programvaruforskningen inom Ericsson.
I strävan efter effektivare programspråk som möter de krav som finns inom telekommunikationsindustrin så har datalogilaboratoriet på Ericssons och Telias samägda bolag Ellemtel, utvecklat Erlang. Språket döptes efter den danske matematikern Agner Krarup Erlang (1878-1929), vars pionjärinsatser inom modern teletrafikteori även medverkat till att Erlang blivit en måttenhet inom telefonin, men namnet kan även tydas som en förkortning av "Ericsson Language".
Erlang förenar två olika programspråkstraditioner: deklarativa språk, som representerar utvecklingen av traditionella högnivåspråk och realtidsspråk, som representerar specialiserade språk för styrsystem i realtid.
Bild 2: Erlangs influenser.
Erlang användes först inom Ericsson projekt för att skriva realtidsprogram för styrning av bl.a. telefonväxlar. Språket riktades till telekommunikationsindustrin men är ett generellt programspråk som passar för många typer av applikationer.
Det karakteristiska för Erlang är att det är ett funktionellt språk med stöd för parallella processer. Själva koden påminner lite om Lisp utan parenteser, medan parallellismen har hämtat inspiration från språk som Ada och Modula (se bild 2). Det är processerna som utgör den bärande enheten i Erlang. Språket lämpar sig bäst för realtidstillämpningar med svarstider på 5-15 ms och stora mängder parallella processer. Processhanteringen har med andra ord prioriterats: tiden för att avbryta en process och starta en annan har hållits kort. För att inte använda mer minne än nödvändigt kan processer växa och krympa efter behov. Processerna kommunicerar med varandra genom att skicka meddelanden.
För att underlätta arbetet med programkonstruktionen så kan programkoden delas upp i moduler och även spridas ut över flera olika datorer. En egenskap som språket har är att det kan förena olika typer av hård- och mjukvara med varandra. Språket kan även kommunicera med program som är skrivna i andra programspråk [ 23 ]. Erlang har en halvintepreterande kod, d.v.s. samma binärkod kan användas i flera olika arkitekturer. Detta gör att datorer av olika märken och med olika operativsystem kan tillsammans köra samma Erlang program utan att några kodförändringar eller omkompileringar behöver göras.
En egenskap som konstruktörerna eftersträvade hos Erlang var robusthet. Därför har man försökt att eliminera vanliga orsaker till fel och minnesläckor. Destruktiva operationer är exempelvis inte tillåtna, d.v.s. en variabel som tilldelas ett värde kan inte tilldelas ett nytt värde. Språkets storlek, d.v.s. dess syntax är liten och mycket kraftfull. Alla funktioner som inte anses nödvändiga har tagits bort. Ingenting kan göras på mer än ett sätt: upprepningar måste till exempel göras rekursivt - det finns inget stöd för iteration.
Erlang är konstruerat så att det skall vara möjligt att byta ut programkod i ett program under exekvering. Detta är ett viktigt krav på ett programspråk inom telekommunikationsindustrin, där man inte kan avbryta ett exekverande system för att byta programvara. Språket stödjer även distribution av programvara som körs på olika nätverk och med olika typer av datorer. Erlang finns för ett dussintal olika programplattformar. Exempel på tillgängliga plattformar är: UNIX, DOS, Windows NT, QNX och Macintosh.
Denna studie bygger på intervjuer från sex olika projekt inom Ericsson som har använt sig av Erlang i något utvecklingsprojekt. Projekten har det gemensamt att de snart skall avslutas eller nyligen har avslutats. De är alla projekt inom telekommunikationsområdet. De sex projekten kommer att presenteras punktvis med en inledande beskrivning av verksamhetsområde, allmän information om projektgruppen samt vad det är för typ av produkt som har utvecklats. Därefter kommer en genomgång av de erfarenheter som projektet har av Erlang samt en redogörelse för i vilken grad språkets egenskaper har påverkat projektet.
Den produkt som detta projekt har utvecklat är en växel för att kunna hantera stora mängder information som skickas över bredband. Informationen kan skickas i realtid över Ethernet kopplingar. Exempel på användningsområden är bl.a. videokonferenser eller överföring av röntgenbilder mellan olika sjukhus. Projektet har c:a 28 anställda och består av tre grupper. Den grupp som arbetar med Erlang har 12-15 anställda.
Projektet startades 1993 med att ta fram en prototyp. Denna prototyp
gjordes i Erlang. Det undersökta projektet bygger på det tidiga prototyparbetet som gjordes. Det är bara i en av projektgrupperna som man har använt sig av Erlang som implementationsspråk. Utöver erlangkoden så finns det även lite C-kod i denna applikation. Den används för att matcha hårdvaran och för att komma ut utanför Erlang för att koppla ihop applikationen med andra språk.
Applikationen består av c:a 25 000-30 000 rader Erlangkod i den färdiga produkten.
Den programkonstruktör som jag intervjuade, Stefan Lundberg, har c:a 13 veckors erfarenhet av att programmera i Erlang. Tidigare har han kommit i kontakt med språk som till exempel Plex och C++.
Att skriva koden har gått väldigt fort, medan testningen har tagit lång tid. Detta har berott på bl.a. att man måste ta hänsyn till den plattform som utgjorde grunden för denna applikation. I arbetet har man varit mycket noga med att specificera gränssnittet mellan de olika programmodulerna. Trots detta har man haft en del problem med gränssnitten mellan de olika modulerna.
Detta berodde till stor del på att uppdateringen av de s.k. gränssnittsdokumenten (de dokument som specificerar programmodulernas gränssnitt) inte alltid nådde berörda personer som de skulle. Den metodik som har använts i analys- och designfaserna har varit objektorienterad. I implementationsskedet har man dock valt att inte föra över objekten från den objektorienterade designlösningen till processer i Erlang, i någon större utsträckning
Den stora fördelen med Erlang är att det är lätt att lära sig och att använda. Man kommer snabbt igång med att både skriva och prova funktioner. Andra faktorer som är viktiga är att man inte behöver deklarera datatyper och att pekare saknas. Applikationen byggs upp i flera samverkande moduler som var och en utför en avgränsad uppgift. Därigenom blir modulerna lätta att testa. Det faktum att det går snabbt att bygga upp "stubbkod" och att språket är flexibelt gör att det lämpar sig mycket bra för prototyping.
"Det går fort när det är ren Erlangkod och man inte behöver ta hänsyn till andra program plattformar".
Stefan Lundberg, EBC IsoEthernet
En annan erfarenhet av språket var att det gick så snabbt att utveckla en prototyp i Erlang, eller som Stefan sa:
" en vecka sedan var det färdigt".
Stefan Lundberg, EBC IsoEthernet
En nackdel som språket har är att syntaxfel upptäcks först vid exekveringen av applikationen. Detta hänger samman med att man inte behöver deklarera datatyperna innan man kompilerar applikationen. Kompileringen upptäcker inte om variabler ej är deklarerade. Detta upplevs stundtals som besvärligt. Man skulle vilja att enklare fel upptäcktes redan vid kompileringstillfället. Vidare var det besvärligt att koppla ihop Erlang med programkod i C.
På frågan om vilka projekt som Erlang passar bäst för säger man att Erlang har passat detta projekt bra och att man anser att projektet är av medelstorlek. För övrigt anser man att Erlang passar bra för realtidsapplikationer och att man inte kan komma på några typer av projekt eller applikationer som Erlang inte skulle passa för.
Det som skiljer Erlang från C och C++ är bl.a. att det medför ett helt annorlunda tankesätt. Data hör till en process och alla andra processer kan komma åt dessa data. En annan sak är att man inte måste deklarera de datatyper som man använder i Erlang. I C++ upptäcker man alla icke logiska fel redan vid kompileringen, på grund av det är ett starkt typat språk. Vidare får man få exekveringsfel i C++ medan man istället får fler kompileringsfel.
I Erlang är dessa förhållandena omvända. Enligt Stefan är "felen lättare att hitta vid kompileringen än vid exekveringen". Fördelen med C++ är annars att det är objektorienterat vilket Erlang inte är. Använder man sig av C++ i ett projekt så ställer det dock högra krav på styrning i stora projekt.
" Den erfarenhet vi har av Erlang är att det har fungerat bra för produkten".
Stefan Lundberg, EBC IsoEthernet
Språkets betydelse för den totala utvecklingstiden i projektet är inte så stor. Man programmerar inte så mycket jämfört med de övriga momenten i projektarbetet. Det som tar lång tid är att sätta sig in i problemet och att undersöka vad det är som skall göras.
Det går dock snabbt att skriva Erlangprogram. När man beräknade utvecklingstiden för den prototyp som man konstruerade första gången så trodde man att det skulle ta mycket längre tid än vad det i själva verket gjorde.
I de senare projekten justerade man faktorn för beräkning av utvecklingstiden så att den skulle stämma bättre överens med användandet av Erlang. På frågan om man skulle kunna tänka sig ett annat programspråk för projektet så säger Stefan att det skulle vara svårt att tänka sig eftersom man måste bygga vidare på en plattform är gjord i Erlang.
Detta projekt har utvecklat en organkortssimulator (simulator för kretskort) för att kunna testa applikationsprogramvaran i telefonväxlen MD110. Den delprodukt som har konstruerats med hjälp av Erlang heter GDS - General Deviceboard Simulator. För att lösa programvarans tekniska anpassning mot hårdvaran har man även använt sig av programspråket C. Syftet med simulatorn är i första hand att testa applikationsprogramvaran i telefonväxeln MD110 så att telefonväxeln har rätt funktionalitet och beteende mot organkorten. Produktnamnet för produkten är GDS-MDSim.
Detta är ett mindre projekt med 6-8 projektmedlemmar. Av projektmedlemmarna var det en person som programmerade på heltid i Erlang. Den delprodukt som är konstruerad i språket omfattar c:a 10 000 rader källkod och ett par hundra rader C-kod. Simulatorn är för närvarande främst avsedd för internt bruk inom Ericssonkoncernen.
En av de främsta anledningarna till att man inom projektet valde Erlang var att en av projektdeltagarna hade kommit i kontakt med språket på en kurs när han studerade på Kungliga tekniska högskolan (KTH) i Stockholm. Vidare fanns det en uttalad nyfikenhet inför detta programspråk, men även nya programspråk i största allmänhet.
Man ville testa programspråket för att se om det var möjligt att använda som implementationsspråk. Den intervjuade personen har två års erfarenhet av Erlang och har tidigare bl.a. programmerat i: Pascal, C, Assembler och lite Ada.
Språket har en mängd positiva egenskaper. En av fördelarna är att det är ett kompakt språk med en liten syntax. Vidare anser man att språkets abstraktionsnivå gör att det är nära från tanke till implementation. Detta gör att det går fort och enkelt att få ihop ett program. Detta anser man även har avspeglats i projektets arbete.
"Det har inte behövts mer än en person som jobbade med Erlang. Hade vi använt något annat implementationsspråk så hade det nog behövts mer folk" -
Anders Romin, EBC/MD
Enligt Anders så beror detta på att Erlang är ett litet språk och att man leds in på rätt spår beroende på språkets enkla syntax. En annan av erfarenheterna man hade var att den del av koden som var gjord i Erlang var mer stabil och felfri än den del som var konstruerad i programspråket C. Det har varit väldigt lite fel i programkoden och man har endast haft ett större fel sedan produkten släpptes. En annan sida av språket är att det har en mycket bra felhantering.
De negativa egenskaper som språket besitter är framförallt att det tar lång tid att starta upp programmiljön. En annan nackdel är att de applikationer som skapas behöver använda sig av programspråkets miljö för att kunna exekvera. Detta innebär att projektet även måste sälja en Erlanglicens till eventuella kunder.
Man anser att Erlangs styrka främst passar för att lösa händelseorienterade problem eller applikationer som involverar realtidskrav. Databasapplikationer, användarprogram och små applikationer passar språket mindre bra för. Däremot anser man att språket passar både för stora och små projekt. Vad beträffar programutvecklingstiden, d.v.s. den tid det tog för att konstruera applikationen så anser man att denna förmodligen har blivit kortare än om något annat språk hade använts.
De erfarenheter man har gör att man i ett framtida projekt gärna använder sig av Erlang igen. Dock skulle man kanske byta ut vissa delar som t.ex. grafikdelen och försöka göra något i Xview istället.
Den största skillnaden mellan detta programspråk och andra språk är tankesättet. I Erlang behöver man bara tänka ut vad som skall göras och inte hur detta skall gå till. Vidare så finns det inga globala variabler. Ett annat utmärkande drag är att alla variabler är "konstanter" d.v.s det går endast att tilldela en variabel ett värde en gång.
Eftersom detta projekt bygger på en plattform som är gjord i Erlang sedan tidigare så har valet av programspråk en stor betydelse. Det hade som vi ser det inte varit möjligt att använda något annat programspråk till detta projektet. Programspråket kan därför ha stor betydelse när man bygger vidare på redan befintliga plattformar. Annars har kanske valet av programspråk inte allt för stor betydelse.
Den avdelningen som Anders Danne - Ericsson Radio Systems AB arbetar på, förser olika affärsområden med mycket ny teknologi. Det handlar mycket om att utveckla system, programvara och maskinvara. Man sysslar bl.a. med att ta fram prototyper av olika slag. Anders har varit med i tre olika projekt som har använt sig av Erlang. I det första projektet så var Anders med och skrev Erlangkod, medan han i de senare har varit projektledare. Dessa projekt var:
- Cordless
Ett av de första projekten med Erlang, 1990. Erlang använder bl.a. i detta projektet för att konstruera mjukvaran som skötte styrningen av Ericssons digitala och trådlösa telefonsystem: DCT900. Prototypen konstruerades på sex månader med tre man. Arbetet inkluderade en flera omskrivningar av prototypen innan man fann den bästa lösningen.
Med hjälp av Erlang gjorde man en simulator som på ett smidigt sätt simulerade delar av hårdvaran innan denna hade kommit på plats. När väl hårdvaran kom så tog det bara två veckor att få produkten färdig. Detta hade inte gått utan Erlang.
- Codit
En slags radioväxel. Detta projekt var ett s.k. RACE projekt. - TelefoniserverEn applikation som bestod av 25 000 rader Erlangkod.Anders första kontakt med Erlang var för 10 år sedan. Det var genom TUP (tekniskt utskott för programvara) för representanter från Ericssons olika delar som han kom i kontakt med Erlang. I detta tekniska utskott satt Bjarne Däcker (en av grundarna till Erlang tillsammans med bl.a. Mike Williams, Robert Virding och Joe Armstrong) som ordförande. Allt sedan dess har han varit intresserad av språket och har de senaste fem åren aktivt propagerat för Erlang i sina projekt. Anders är för övrigt allmänt nyfiken och intresserad av ny teknologi och nya programspråk. Han har tidigare bl.a. programmerat i Prolog, Assembler, Pascal och EriPascal. Han tror att Erlang kommer att komma in och användas allt mer och mer inom Ericssonkoncernen. Anders erfarenhet är dock att det tar lång tid att föra in ny teknologi i en organisation. Enligt Anders så fanns det heller inga alternativa programspråk som han skulle kunna tänka sig att använda i dessa tre projekt.
Hans erfarenheter av språket är att det blir mindre kod att skriva jämfört med andra programspråk. Erlang är även lätt att lära sig och har en hög abstraktionsnivå. Den höga abstraktionsnivån gör att man inte behöver bekymra sig för implementationsdetaljer som leder till en massa trassel.
Att språket har en hög abstraktionsnivå ser han även som en möjlig orsak till problem. För att kunna programmera i ett språk som har en hög abstraktionsnivå så måste man kunna förstå detta tänkandet. Anders refererar till erfarenheter från IBM i USA [ 4 ] som visar att det inte alltid räcker med utbildning för att man skall lära sig ett programspråk. Dessa erfarenheter gjordes på IBM där man i mitten på åttiotalet skulle utbilda ett flertal utvecklare i Prolog. 50 procent av gruppen som genomgick utbildningen blev aldrig riktigt bra på deklarativ programmering [ 4 ]. En annan erfarenhet är att det underlättar om programspråket som man använder sig av, är konstruerat för att hantera realtid när man skall skriva realtidstillämpningar. Erlang har även en interaktiv programmiljö som är mycket smidig. Det går fort att prova ut nya saker.
Enligt Anders så har Erlang gjort projekten mer produktiva. Projekten behöver färre personer och mindre tid än tidigare eftersom man inte behöver producera lika mycket kod för att uppnå samma funktionalitet.
"Erlang är ett lyft för produktiviteten." -
Anders Danne, Era-t
Mindre kod gör också att det blir mindre fel.
"Det är nog lika många fel per antal rader som det var tidigare, dock blir det färre rader kod nu, vilket leder till att det blir färre fel totalt sett än vad det var tidigare."
Anders Danne, Era-t
De områden som passar språket bäst är telefonväxlar och applikationer för olika former av tjänster. Verktyg för att utveckla programvara och testutrustningar passar språket också mycket bra för. Vad det beträffar projektens storlek så säger Anders:
"Det finns ingen gräns för hur stora projekt som kan använda sig av Erlang, projekten blir mindre"
Anders Danne, Era-t
På frågan om vilken typ av tillämpningar som Erlang inte passar för nämner han "tvättmaskiner" med enklare logik. Med detta menar han att det måste vara lite mer komplicerade lösningar för att det skall vara lönt att använda sig av Erlang. Windowsapplikationer på PC passar inte heller så bra eftersom man inte kan få fram samma typ av gränssnitt. Personligen önskar han sig även att det fanns en bra PC/Windowsimplementering med en miljö liknande VisualBasic.
Till skillnad från t.ex. Plex så får man en mycket kortare utvecklingstid. En av nackdelarna med Erlang är att språket har sämre prestanda än vad C t.ex. har. Erlang tar även mycket mer minne än programspråket C.
Det finns saker som har större betydelse för ett projekt än vad programspråket i allmänhet har. Det är viktigt att veta vad man skall göra för att ett projekt skall slå väl ut. Tydliga krav och mål som inte förändras har också mycket stor betydelse. Programspråket är först och främst ett verktyg som man använder sig av.
Projektets mål var att experimentera för att hitta nya, snabbare vägar till att utveckla tillämpningar. Till denna uppgift valde projektet Erlang. En annan viktig del i detta arbetet var att undersöka arbetsmetodik. I sina experiment så utvecklade man en prototyp som utgick från den ATM-hårdvara som finns ute hos kunderna. Utifrån denna utvecklades ett enklare system i Erlang för att styra hårdvaran. Därefter koncentrerade man sig på införa funktionalitet så att kunderna själva skulle kunna sätta upp och tar ner förbindelser via prototypen.
Projektgruppen bestod av 4 personer som hade arbetat med Erlang i 6 månader.
Tidigare hade man bl.a. programmerat i Plex, Ada och C.
Den applikationen som man gjorde omfattade c:a 10 000 rader källkod i Erlang samt 200 rader i programspråket C. Det man kände till sedan tidigare om språket var i princip att det var ett programspråk som kom ifrån Ericssonkoncernen.
De erfarenheter som man har fått av språket är att det är lätt att utveckla program i. Detta hänger delvis samman med att man arbetar på en abstraktionsnivå där man inte behöver bekymra sig om minnesläckor, pekare och dyl.
" När man har arbetat med ett språk på hög abstraktionsnivå så vill man inte gå ner en nivå för att börja arbeta på detaljnivå igen".
Bo Bergström, ETX/B
Man säger vidare att språket lämpar sig bäst när mer abstrakta problem skall lösas. Språket är även lätt att lära sig eftersom det har en mycket begränsad syntax. Genom att gå en fyra-dagars kurs så behärskar man de viktigaste grunderna i språket. Man anser även att det har uppstått mindre fel i programvaran jämfört med erfarenheter från andra programspråk. Detta tror man bero på den begränsade syntaxen, det går inte att göra så mycket fel eftersom språket har så liten syntax. En följd av den lilla syntaxen är även att koden blir lättare att läsa. Andra viktiga egenskaper är de parallella egenskaperna som understöds i språket, mönstermatchningen, att kunna uppgradera programvara under exekvering, plattformsoberoende, korta kompileringstider och att Erlang är ett löst typat språk.
De nackdelar med språket som man anger har med processbegränsningar och kapacitet att göra. Man kan endast ha 4000 processer igång samtidigt. Man ser detta mest som lite barnsjukdomar i språket. En annan detalj är avsaknaden av felsökning under drift och att bra grafiska hjälpmedel saknas. Vidare ställer man sig lite frågande till hur Erlang kommunicerar med andra språk än C.
Erlang lämpar sig bra för projekt som finns på UNIX-plattformar och mindre bra för hårdvarunäraprogram och program som ställer höga krav på prestanda.
Man har en upplevd känsla av att kvaliteten i programkoden har blivit bättre då man inte längre har några pekarfel. Eventuellt har man även fått en kortare utvecklingstid.
"Kodningstiden är kortare men man måste fortfarande modellera"
Bo Bergström, ETX/B
Det är dock svårt att säga om man skulle välja Erlang för ett projekt idag. Det beror lite på vad man skall göra och vad det är för typ av applikation. Därför är det svårt att svara på vad man skulle ha valt idag.
Det går att göra mer i C++ och man har en större frihet. det är också större frihet att göra fel. För många imperativa språk måste deklarera alla variabler innan man skall använda dem. Detta behöver man inte göra i Erlang. Man tycker även att det är lättare att göra grafik i Erlang än vad det är i C++. Detta beror naturligtvis även på vilken typ av grafikpaket som man har i de olika miljöerna. Det grafikpaket man har använt sig av heter PXW.
Språkets betydelse är inte så stor anser man, metoden väger tyngre. Det handlar egentligen om en kombination av metod och programspråk. De svårigheterna som man hade i projektet har mest haft med metoden och göra.
"Det är metod och språk som tillsammans borgar för ett lyckat projekt"
Bo Bergström, ETX/B
Detta projektet startades 1993. Det fanns sedan tidigare en prototyp som detta projekt skulle vidareutveckla. Arbetet med att ta fram en produkt tog 112 000 mantimmar och engagerade 20 personer i Sverige och 15 personer i USA.
Den färdiga produkten består av 192 000 rader erlangkod i 450 moduler och 6700 rader C-kod i 26 C-moduler. Källkodens storlek är 5,7 Mb. Denna produkt möjliggör för kunden att skräddarsy avancerade företagstjänster. Exempel på tillämpningsområden är att stödja radioväxlar och personligt telefonnummer.
Den prototypen som man byggde sitt arbete kring var gjord i Erlang. Denna prototyp var resultatet av ett gemensamt arbete mellan EBC och Ellemtel, där EBC gjorde applikationen medan Ellemtel utvecklade Erlang. Därför var det också självklart att detta projektet skulle göras med Erlang. Man var mycket nyfiken på Erlang eftersom tidigare tester och erfarenheter hade visat på lovande resultat.
I detta projektet har jag varit i kontakt med projektledare Lennart Axelsson och programkonstruktör Rune Berg.
Rune har arbetat med Erlang i 14 månader. Han har tidigare programmerat i bl.a. Plex, C, C++, Pascal, Modula-2, Prolog, Miranda och Assembler.
Enligt projektledare Lennart Axelsson så har det varit minst problem med Erlang i projektet. De problem som man hade berodde istället på att utvecklingen delades upp mellan Sverige och USA. Detta var ett svårt politiskt beslut. Här fanns många av de problem som uppstod. Vidare så har man haft en del problem som har berott på det inköpta operativsystem som har använts. Det som har gjort detta projektet svårt är att det har funnits många nya och okända parametrar som till exempel ett nytt språk och en ny arkitektur, i projektet. Tidigare har man haft många kända parametrar. Effekten av alla dessa okända parametrar har blivit en psykologisk och kulturell chock. Vidare så var mycket av det tidigare prototyparbetet odokumenterat. Att förstå arkitekturen och underliggande delar var därför mycket svårt.
Vad beträffar utvecklingstiden så tror man att projektet skulle ha gått snabbare om man hade använt Plex istället. Detta beror bl.a. på att projektmedlemmarna har en mycket stor erfarenhet och kompetens av Plex sedan tidigare.
Lennart säger att han inte ångrar valet av Erlang som implemetationsspråk. Men han säger även att: i projektets tidiga faser hade vi inte så goda erfarenheter/kunskap som vi har idag av språket. Då hade man säkert valt något annat mer känt programspråk (men kanske inte bättre). Hans inställning är att ett programspråk är framförallt ett verktyg. Om man hade haft fundamenten färdiga från början så går det snabbare med Erlang.
Den allmänna inställningen är annars att de som tidigare arbetade med Plex gärna fortsätter med Erlang. Språket är effektivt och enkelt. Vidare så anser man att språket har en stark arkitektur och att man kan göra mycket med lite kod.
"Ett så kraftfullt språk men ändå så enkelt att använda".
Rune Berg, Mobility Server
Språket är lätt att komma igång med. Men att skriva bra kod kräver erfarenhet. det är viktigt att man inte släpper programkonstruktörer allt för fort - säger Lennart Axelsson. Det är viktigt med utbildning och att man verkligen använder sig av fördelarna med språket. Det går även fort att göra avancerade saker menar Rune. Av språkets dåliga sidor anger han bl.a. möjligheterna att använda debuggern. Enligt Lennart så är svårt att hitta fel i koden. Expertkompetens krävs menar han. Programkonstruktören säger i sin tur att han inte har så stor behov av debuggern. En annan detalj är att det är svårt att hålla reda på de specialtecken som används i satserna. I vissa situationer är det svårt att veta om det skall vara kommatecken, semikolon eller punkt i en sats. Det känns lite onödigt med tre olika tecken för samma sak.
Erlang passar annars bra för styrsystem och telekommunikationsapplikationer. Distribuerade system ned lång körtid passar också för detta språk. Däremot är det inte lämpligt för typiska PC-tillämpningar.
Om Rune hade fått välja programspråk igen så hade han valt Erlang till detta projektet. Han är mycket nöjd med språket och säger att:
"Erlang är det bästa språk som jag har programmerat i"
Rune Berg, Mobility Server
Det är en stor skillnad mot andra språk. Exempel på saker som gör skiljer Erlang från andra språk är mönstermatchningen och att rekursion används för att styra programmen och inte loopar. Vidare så kan variabler bara bindas en gång och typer och listor är inbyggda i språket.
Valet av programspråk till ett projekt är inte det viktigaste. Det viktigaste för att ett projekt skall lyckas är att det är ett litet projekt med stabila krav och att man har något stabilt att bygga på.
Det får inte enbart finnas okända faktorer. Vidare så måste utbildningen fungera i alla led samt att det finns tillräckligt med kompetenta resurser. Det är även viktigt att det inte finns känslokonflikter inom projektgruppen. Grundarbetet och helheten är det viktigaste. Man måste även tänka på att utvärdera produkter och externa leverantörer.
NETSim är en AXE-simulator som simulerar både operationer och beteende. Simulatorns främsta syfte är att prova TMOS-applikationer men även att tjäna för utbildning av TMOS-operatörer samt vid demonstration av TMOS-system.
NETSim-projektet startades i slutet av 1993 och bestod av tre personer varav två programmerade i Erlang.
Det fanns sedan tidigare en simulator som var gjord av C++ kod. Denna hade utvecklats 1991 och saknade viktig funktionalitet. I den versionen använde man inte C++ för objektorienteringens skull utan mer som en bättre C-kompilator. Vidare var C++ koden mycket rörig efter det att många personer hade varit inblandade i programmeringen. I denna typ av verksamhet så är det naturligt att dela upp problemen i processer. C++ lösning på samtidighet är att utnyttja UNIX processer. Detta gjorde man i den tidigare simulatorversionen men denna lösningen tog mycket tid. Den nya versionen som skulle konstrueras behövde även utökad funktionalitet samt kunna köras på flera olika plattformar (Solaris 1,2 och HP/UX), därför var det praktiskt att gå över till Erlang eftersom det har en halvintepreterande kod, d.v.s. samma binärkod kunde användas i alla tre arkitekturerna.
Projektledaren Bengt Tillman kom i första gången i kontakt med Erlang på en företags-presentation. Efter det blev han nyfiken på att prova på språket. Hela simulatorn är skriven i Erlang medan många av kommandona är skrivna i C++ sedan tidigare. Dessutom så finns det lite C-program som sköter X25-kommunikationen till simulatorn. Totalt omfattar simulatorn c:a 42 000 rader Erlangkod och c:a 175 000 rader C++.
Johan Garpendahl som jag intervjuade har 1 1/2 års erfarenhet av Erlang och har tidigare bl.a. programmerat i Pascal, Lisp och C++. Bengt som har 30 års erfarenhet av programmering har bl.a. programmerat i assembler, AlgolGenius, Forth, Pascal, C++, e.t.c. Conny Forsander har 1 1/2 års erfarenhet av att programmera C++kommandon till NETSim men programmerar i Erlang sedan 3 månader tillbaka.
Erlang som produkt är en mycket stabil och tillförlitlig. Under den långa tid som man har använt Erlang så har man endast råkat ut för ett enda fel. En av de stora fördelarna med Erlang är att man inte behöver deklarera alla variablerna som skall använda. Man anser även att det har uppstått färre programvarufel än vad man tidigare råkade ut för. Vad som också är utmärkande är att man inte längre får några minnesfel till skillnad från språk som C++. Eftersom det inte finns några pekare så kan man inte heller få några pekarfel.
Vad det beträffar programvarufel säger Conny Forsander:
"Jag gjorde värre fel i C++ som samtidigt var svårare att hitta"
Conny Forsander, NETSim
Andra övergripande erfarenheter är att det är enkelt att konstruera en klient/server-applikation med hjälp av Erlang. Vidare så har språket en kraftfull felhantering och bra process-styrning. En annan viktig egenskap är att man befinner sig på en mycket högre abstraktionsnivå än andra programspråk.
Det känns som man lyfter sig en nivå upp och kan koncentrera sig på att lösa problemen istället för att brottas med syntaxen.
Johan Garpendahl, NETSim
Det finns vidare sådana faktorer som både är för och nackdelar. Vad det beträffar grafik och grafiska hjälpmedel så har vi delvis saknat detta. Eftersom Erlang är ett halvintepreterande språk så gör det att alltid kommer att gå lite långsammare än andra språk. Johan Garpendahl säger även:
"Upphovspersonerna på Ellemtel hävdar att Erlang är 5 gånger så långsamt som C/C++ vid jämförelse sats för sats. Men vid kommunikation mellan processer så märker man inte att det skulle gå långsammare. Gör man bara en bra programdesign så är prestanda inga problem"
Johan Garpendahl, NETSim
En annan detalj som kan vara både bra och dålig är att allting i språket inte är färdigutvecklat. Detta ger programvarukonstruktören en möjlighet att förändra och påverka språkets utveckling.
Att ett programspråk inte är helt färdigutvecklat kan naturligtvis även ses som en nackdel i detta sammanhang. Ett problem som man har haft i projektet har varit att det inte går att öppna mer än 64 (ev 256) filer på en gång. Denna begränsningen sätts dock inte av Erlang utan beror istället på operativsystemet (UNIX).
Vad det beträffar syntaxen i språket så upplevs användningen av komma, semikolon och punkt stundtals inkonsekvent. Vidare så borde de inbyggda funktionerna vara bättre dokumenterade. Man anser vidare att Erlang kan passa till de flesta typer av applikationer bortsett från "sifftertuggande applikationer". Vad det beträffar antalet fel i programkoden så tror man att det blir mindre fel med Erlang jämfört med andra språk. Det beror bl.a. på att det är svårt att göra slarvfel i Erlang.
"En bra programmerare skriver bra kod i vilket språk som helst, en dålig programmerare skriver dålig kod i vilket språk som helst."
Johan Garpendahl, NETSim
Man har vidare en klar uppfattning om att programspråket kan påverka den totala utvecklingstiden. Den första versionen av simulatorn tog 12 månader att göra. Den andra versionen som skrevs om helt från början i Erlang tog 6 månader att göra med utökad funktionalitet.
Man fick då även en klientserverapplikation som hade stöd för flera plattformar (Solaris 1,2 och HP/UX) på köpet. Man slapp dock att jaga en massa folk som hade de rätta kunskaperna i arbetet med den andra versionen av simulatorn. Vidare så använde man sig av en del av den tidigare designen. Bortsett från detta så fick man börja om helt från början.
På frågan om Johan skulle kunna tänka sig något annat programspråk till projektet svarar han:
"Jag tror inte det, Erlang har de egenskaper som behövs i det här projektet"
Johan Garpendahl, NETSim
Erlang påminner mycket om programspråket Lisp. Det som skiljer be båda språken är syntaxen och parenteserna. Sättet att tänka är det samma. Man har liknande datatyper, listor och de är båda funktionella språk. Däremot saknas det stöd för processer i Lisp.
Det är också skillnad på arbetssättet jämfört med andra språk. När man programmerar i Erlang så behöver man oftast bara kompilera fil för fil för att sedan testa. I ett annat språk så hade man behövt kompilera, länka och starta om systemet. Detta gör att man lätt kan prova sig fram i Erlang för att se om en sak kommer att fungera, utan att det tar en massa tid. Detta är en av anledningarna till varför debuggern inte används så ofta. En annan detalj i sammanhanget är att det inte finns några h-filer (header filer) som man måste hålla reda på i Erlang. Detta har bl.a. underlättat underhållet av programkoden.
Valet av programspråk beror helt och hållet på vad som skall göras.
"Man skall välja programspråk efter vad som skall göras och inte tvärt om"
Johan Garpendahl, NETSim
I detta avsnitt kommer jag att försöka redogöra för den bild och de erfarenheterna som de examensarbetande studenterna har av Erlang. Eftersom de både har en liknande utbildningsbakgrund samt liknande förutsättningar så har jag valt att samla deras kritik på samma ställe.
Personerna i undersökningen är:
Anders Berglund, Kungliga Tekniska Högskolan (KTH), Stockholm
Johan Grafström, Chalmers Tekniska Högskola (CTH), Göteborg
Jonna Palm, Högskolan i Skövde
Tomas Aronsson, Chalmers Tekniska Högskola (CTH), Göteborg
Det examensarbete som Johan Grafström och Tomas Aronsson gör består bl.a. av att konstruera en simulator för AXE-tjänster och göra små testprogram i Erlang. Utöver detta skall även en utvärdering av detta arbete göras samt tester av simulatorns prestanda jämfört med en simulator som sedan tidigare är skriven i C++. Både Johan och Tomas går på datateknisk utbildning på Chalmers i Göteborg. De har båda kommit i kontakt med följande programspråk på sin utbildning: C, C++, Erlang, Haskell, ML, Fortran, Tcl/Tk, Ada, Simula, Pascal, Basic, z80, Cobol, Prolog, Forth och diverse assemblerspråk. Erlang har de programmerat i sedan tre månader tillbaka.
Jonna Palms examensarbete går bl.a. ut på att undersöka huruvida en simulator konstruerad i Erlang skulle kunna vara ett möjligt alternativ eller komplement till en simulator som sedan tidigare är konstruerad i Ada. Utifrån detta arbete skall de båda simulatorerna jämföras och slutsatser dras av arbetet. Jonna går på systemprogrammerarlinjen på Högskolan i Skövde. Hon har på sin utbildning bl.a. kommit i kontakt med följande programspråk: Pascal, Fortran, Prolog, C, C++, SDT/SDL, Ada, Occam2 och lite assemblerspråk. Hon programmerar även i Erlang sedan några veckor tillbaka.
Anders Berglunds examensarbete går ut på att undersöka vilka problem, metoder samt för- och nackdelar det finns med att implementera driftstödssystemet TMOS i Erlang istället för den nuvarande lösningen i C++. Anders går på Datateknisk utbildning på KTH i Stockholm. Han har tidigare kommit i kontakt med programspråken: C++, C, Plex, Prolog och Lisp.
De fördelar som finns med språket är att det går snabbt och enkelt att programmera i. Man kan koncentrera sig på det viktigaste och man slipper en massa onödiga saker på detaljnivå. Det är även skönt att slippa saker som pekare och typdefinition av variabler.
Det verkar också smidigt att kunna göra ändringar i programmet under körning fastän jag själv inte har haft användning för sådan finesser.
Jonna Palm
Vidare finns det många inbyggda funktioner (BIF) som är väldigt användbara och som sparar mycket tid för programkonstruktörer. Felhanteringen verkar fungera ungefär som i C++, vilket innebär att felen tas omhand där de sker och inte på en högre nivå i programvaran. Detta är mycket bra, speciellt när man skall debugga programvaran.
"Vi har jämfört Erlang i första hand med C++ och vi anser att Erlang är bättre på allt utom prestanda, interfacing och möjligen viss reservation för den dynamiska typningen"
Tomas Aronsson och Johan Grafström
Ett problem med Erlang är att skapa ett gränssnitt (interface) till andra programspråk. Det hade varit trevligt om det fanns ett Erlangbibliotek som man kunde länka med sin C/C++-applikation.
Något som känns lite ovant med språket är "fnuttologin" - menar Anders Berglund och Jonna Palm.
"Det är många gånger svårt att hålla isär om det skall vara punkt, komma eller semikolon vid en del tillfällen. Detta gäller då främst vid Select-satser"
Anders Berglund
Relativt andra funktionella programspråk säger sig Tomas Aronsson och Johan Grafström, sakna lambdafunktioner, högre ordningens funktioner och "lathet"16. Men detta gör Erlang lite lättare att komma in i för någon som inte har sett funktionell programmering. Dock så tappar man en del kraftfullhet.
Språket lämpar sig bl.a. för problem där man lätt kan identifiera processer. Exempel på sådana områden skulle kunna vara inom telefonivärlden samt automater av olika slag. Anders Berglund har i tidigare erlanglaborationer på KTH haft problem med resursallokeringen till en applikation som gjordes. Detta berodde bl.a. på att man inte på ett enkelt sätt kunde identifiera processer och att det var svårt att definiera tillstånd.
För övrigt är det mycket lätt att hitta de fel som uppstår genom att prova sig fram i interpretatorn.
I Erlang slipper man många av de problemet som finns i C++. Detta beror bl.a. på att Erlang saknar pekare, headers-filer och makefiler.
För att testa ett program i C++ får man många gånger skriva ett speciellt program som göra dessa tester. Dessa problem finns inte i Erlang. Erlang och Plex har det gemensamt att de är uppbyggda med moduler som skickar meddelanden till varandra. Man skulle också kunna se språket som en utvidgning av Prolog med realtid och samtidighet.
En annan erfarenhet är att:
"Man kan aldrig ge sig hän med andra programspråk, jämfört med Erlang"
Anders Berglund
Anders Berglund menar också att ett programspråk speglar och påverkar en organisation på något sätt. Använder man sig av ett objektorienterat programspråk så visar det sig bl.a. i projektgruppens sammansättning. Man måste ha mycket folk runt omkring som hanterar koden och personer som är ansvariga för applikationens objekt samt dess struktur.
De problem som jag ställs inför när jag skall analysera detta material är många. De två viktigaste uppgifterna i en analys är framför allt att vara kritisk i sitt granskande och att göra sig själv kritiserbar. Det är vidare av väsentlig karaktär att man inte bygger sina slutsatser på ogrundade uppgifter eller rena spekulationer. Allt detta förutsätter i det närmaste, att jag som forskare kan betrakta mitt material i ett större perspektiv för att på så sätt finna övergripande samband. Först därefter är det möjligt att utföra generaliseringar av det insamlade materialet. Detta är naturligtvis mycket svårt. Det ställer krav på mig som person att ordentligt redogöra för mitt resonemang och inte dra några förhastade slutsatser.
Det insamlade materialet är förmodligen den mest omfattande studie som har gjorts hittills om erfarenheter av Erlang. Gemensamt för alla intervjuade projekt är att de återfinns inom Ericssonkoncernen. Även Erlang Systems AB hör hemma här. Detta faktum har naturligtvis gjort mig extra källkritisk i mitt arbete. Hur skapar man sig då en korrekt bild av den verklighet som man observerar och hur vet man att man inte blir ett språkrör för något som inte är allmänt accepterat eller som jag inte själv anser ? Det viktigaste är nog att man är mycket källkritisk till det material man får in. Det är även viktigt att man undersöker de källor som refereras vid intervjuerna eller i litteraturen. Problemet med detta språk är att det har en relativt begränsad skara användare. Dessa användare känner i många fall även till varandra. Med dessa tankar i bakgrunden redovisar jag nu sammanställningen av projektgruppernas erfarenheter.
Materialet tyder på att alla projekten har överensstämmande erfarenheter av programspråket.
Erlang har varit ett utomordentligt stöd och tillgång i åtminstone fem av de sex projekten. Det projekt som har haft lite problem med införandet av Erlang hänför detta till andra faktorer än själva programspråket. Det har istället handlat om bristfällig utbildning och kompetens som har gjort det svårt att dra full nytta av Erlangs hela styrka. Vidare fanns det många okända parametrar i projektet som gjorde att man inte hade någon trygg bas att stå på.
Alla programvarukonstruktörer nämner hur lätt det är att programmera i Erlang. Detta beror bl.a. på att man arbetar på en högre abstraktionsnivå än man gör i andra språk. Flera av de intervjuade anger att den höga abstraktionsnivån i programspråket är en av de viktigaste egenskaperna i språket. "Abstraktionen är ett sätt att identifiera viktiga egenskaper och funktioner i det som modelleras. Man kan koncentrera sig på aspekter som är viktiga och strunta i oväsentliga detaljer."
Ghezzi och Jazayeri [ 15 ]
Ett programspråk som har en hög abstraktionsnivå kan därför sägas hantera programdesignens komplexitet på ett bra sätt.
Alla anser vidare att språkets syntax är liten och lätt att lära sig. De flesta av de intervjuade personerna ansåg att utbildningen på fyra dagar räckte för att man skulle förstå de viktigaste grunderna i språket.
Den programkod som skrivs blir ofta också mycket kortare än programkod som skrivs i imperativa programspråk. Det finns undersökningar som visar på att programkoden kan bli upp till nio gånger kortare med Erlang [ 6 ] jämfört med t.ex. Plex. Andra sidor är att man inte behöver bry sig om minneshantering, pekare eller att deklarera variabler. Detta sköter Erlang. Dessa saker betonar alla programkonstruktörerna i projekten som viktiga.
Vad beträffar språkets svaga sidor är det betydligt svårare att utskilja några tydliga mönster. Två projekt nämner att man hade önskat sig bättre grafiska hjälpmedel än de som finns idag. Ett annat projekt menar att det är lättare att göra grafik i Erlang än vad det är i C++. Vad som är viktigt i detta sammanhang är då vilken typ av grafikpaket man använder sig av. Två projekt nämner också Erlangs gränssnittshantering mot andra programspråk som ett möjligt problem.
När det gäller att utvärdera Erlangs egenskaper har det många gånger framhävts att det inte finns några tillräckligt stora projekt att utvärdera språket i. Detta är inget stort problem säger Bernt Ericsson, forskningschef på Ericsson. Det skall helt enkelt inte finnas några stora projekt. Bort med mastodontprojekten ! Allt skall brytas ner till delprojekt med högst 50 man. Vi måste lära oss att driva projekt på ett helt annat sätt än tidigare. För Ericsson kan valet av programspråk vara en ren överlevnadsfråga. Det gäller att finna lösningar som avsevärt ökar produktiviteten, d.v.s. snabbare utveckling till lägre kostnad. Därför krävs det ett genombrott på mjukvarusidan. Erlang kan vara en del av lösningen.18Inget av projekten har nämnt att man har haft något problem med prestanda hos de färdiga applikationerna. Det är dock viktigt att påpeka att inga av projekten har konstruerat applikationer som har varit extremt känsliga för prestanda. Övervägande delen av projekten har konstruerat simulatorer eller prototyper av olika slag som inte är så känsliga med avseende på prestanda. Vad beträffar prestanda så har man inte så mycket jämförande värden mellan Erlang och andra språk. Detta är ett område som jag hade önskat lite mer undersökningar om. Tomas Aronsson och Johan Grafström har dock gjort en del enklare prestandatester mellan Erlang och C++, som visar att Erlang har lite sämre prestanda. Men det är svårt att dra några direkta slutsatser av dessa tester. Programoptimering och problemtyp har mycket stor betydelse i dessa mätsammanhang.
Dåliga prestanda har annars alltid varit den tyngsta kritiken mot funktionella programspråk [ 4 ]. Jag har dock inte något konkret material som bekräftar att det skulle förhålla sig så med Erlang.
De flesta i undersökningen verkar vara överens om att programkoden är lätt att testa, i alla fall så länge man inte använder debuggern. Vad beträffar antalet fel i programkoden råder det lite olika meningar. Många hävdar att det har blivit mindre fel sedan de började använda Erlang, medan en del hävdar att det blir lika mycket fel som tidigare.
Dessa två oförenliga ståndpunkter går kanske att förklara med Anders Dannes ord:
"Det är nog lika många fel per antalet rader som det var tidigare, dock blir det färre rader kod nu, vilket leder till att det blir färre fel totalt sett än vad det var tidigare.".
Anders Danne, Era-t
Detta uttalande bekräftas delvis av Rune Berg.
"De logiska felen kommer lika ofta som tidigare".
Rune Berg, Mobility Server
Detta skulle kunna vara en rimlig förklaring till varför man svarar lite olika på denna fråga. Man gör lika många slarvfel som tidigare men kortare programkod gör att det blir mindre fel totalt sett. Om man accepterar denna förklaring så kan man slå fast att det totala antalet fel i programkoden kan minskas genom att man använder Erlang som implementationsspråk.
Vidare anger de flesta att Erlang passar för bl.a. realtidssystem , telefoni/växlar och distribuerade system. Små applikationer i Dos/Windows eller applikationer med höga krav på prestanda passar inte lika bra för Erlang, anser projekten. Applikationer som är hårdvarunära är också olämpliga för Erlang, Två av projekten nämner dock att man inte kan komma på några områden som inte skulle passa för Erlang.
Erlang som produkt upplevs även vara mycket stabil och tillförlitlig. Det är endast ett av de sex projekten som har råkat ut för något fel i programmeringsmiljön och det skedde efter mycket lång och tuff användning.
På frågan vad programspråket har för betydelse för att ett projekt skall lyckas, svarar alla genomgående att programspråket har en mycket liten betydelse. Det finns många andra faktorer som har större betydelse än programspråket. Något som betonas är bl.a. metodvalet. Det är viktigt att det programspråk man använder fungerar bra ihop med den metod man använder, och vice versa. Eller som Bo Bergström, ETX/B säger: "Det är metod och språk som tillsammans borgar för ett lyckat projekt".
Eftersom man programmerar så lite jämfört med övriga moment i utvecklingsarbetet så får programspråket inte så stor betydelse för projektet i sin helhet. Ett projekt anger dock att valet av programspråk kan påverka tiden för när ett projekt blir färdigt samt kvaliteten i programkoden.
Andra viktiga aspekter som lyfts fram är utbildning/kompetens och stabilitet.
Med stabilitet menar man bl.a. stabilitet i: programplattformar och organisationen men även att kravspecifikationen inte förändras. Vidare anger man att förarbetet och helheten är avgörande faktorer för att ett projekt skall lyckas.
Dessa åsikter bekräftas bl.a. av Bengt Lennartsson, Linköpings universitet som pekar på att kompetens och erfarenhet hos inblandade personer inklusive projektledning är viktigt. Man måste veta vad man skall göra, det räcker inte med duktig personal. Något som har stor betydelse är en konsistent målframställning.
Mycket längre ner kommer bl.a. stödsystem, resursfaktorer, lokala datastöd, kommunikationsmöjligheter och implementationsspråk. Någonstans mitt emellan kommer stabilitet och långsiktighet.
Det är även viktigt att man utvecklar och utnyttjar den entusiasm som finns hos medarbetarna. Bengt uttalar sig inte främst utifrån sina egna erfarenheter, utan ifrån en sammanvägning av vad han uppfattar att andra har för erfarenheter inom området.
Anders Wennerström, Ericsson anger att det är viktigt med en stabil industrialiserad stödmiljö. Störningar av någon formsak ger mycket turbulens och förseningar. Eftersom de inblandade individerna uppfattar detta som utanför deras kontroll, uppstår det stor frustration hos de inblandade. Det är viktigt att kunna följa de planer som man har ställt upp. Programspråket är inte så viktigt för ett enstaka projekt. Man bör istället titta på betydelsen av programspråk för olika typer av projekt. Där är det lite mer relevant att titta på programspråkets betydelse, men även här är språket klart underlägset andra parametrar av arkitekturkaraktär, till exempel hur man definierar interna plattformar och interna gränssnitt. Det vanligaste misstaget man gör är annars att man sätter igång och jobbar innan man ordentligt har klarlagt vad man vill få fram. Man slarvar även med uppläggningen av systemtesterna säger Andes vidare.
Alla dessa åsikter visar att programspråket kanske inte har så stor betydelse för om ett projekt skall lyckas eller ej. Möjligen bör man ställa frågan som: vilken betydelse har programspråket för ett system, istället. Men undersökningen har samtidigt visat att valet av programspråk kan ha mycket stor betydelse i implementationen. Där kan språket förenkla arbetet, göra källkoden kortare och underlätta i problemprocessen.
En annan viktig faktor är naturligtvis programkonstruktörernas kompetens.
Stolterman [ 20 ] nämner att en god problemlösare karakteriseras av att han är duktig på att lösa de problem som han blir tilldelad. Eftersom man vet att antalet möjliga problem och lösningar till ett problem kan vara mycket stort, så blir problemlösarens förmåga att snabbt hitta en lösning en ekonomisk fråga, t.ex. genom att korta ner söktiden. För att inte behöva göra en fullständig genomgång av alla alternativ brukar det medges att kreativ och intuitiv förmåga är bra för att korta ner söktiden.
Utöver detta så verkar det även "gå religion i programspråk". Det kan vid en första tanke kännas märkligt att ett programspråk kan ha så stor betydelse för den som använder det. Ett programspråk är ett av många verktyg som man behöver använda sig av i ett programutvecklingsprojekt. Men för att kunna använda sig av ett verktyg så krävs kompetens och "hantverksskicklighet". Använder man sig av ett verktyg som man känner att man behärskar och därigenom känner sig trygg med, så kan favoritspråk uppstå.
Har man hittat ett favoritspråk/verktyg så överger man inte detta, inte ens om det skulle finnas rationella skäl för det. Vägrar man att använda något annat programspråk så blir det nästan som en religiös tro.
Bengt Lennartsson säger att:
"Programspråk uppfattas som viktigt av implementatörerna. Så valet av programspråk i ett projekt påverkar vilka typer av personer som söker sig till projektet. Det språk ett företag väljer påverkar vilka personer som söker sig dit"
Bengt Lennartsson, Linköpings Universitet
I mitt arbete finner jag dock ingeting som skulle bekräfta att Erlang har blivit en religion. Men kommentarer som Anders Berglund ger, visar på att man känner mycket för Erlang.
"Man kan aldrig ge sig hän med andra programspråk, jämfört med Erlang"
Anders Berglund
De flesta verkar dock vara överens om att man skall välja programspråk efter vad man skall göra och inte tvärt om. Däremot finns det säkerligen förteelser kring andra programspråk som bättre skulle passa in att jämföras med religiös tro.
Den undersökning som gjordes av studenternas erfarenheter bekräftar att Erlang skulle vara lätt att lära sig och att det är enkelt att programmera i Erlang. Man arbetar på en abstraktionsnivå där man slipper fundera på en massa saker på detaljnivå.
"Vi har jämfört Erlang i första hand med C++ och vi anser att Erlang är bättre på allt utom prestanda, interfacing och möjligen med viss reservation för den dynamiska typningen"
Tomas Aronsson och Johan Grafström
Andra faktorer som upplevs som mycket viktiga är Erlangs felhantering och dess inbyggda funktioner (BIF). De instämmer även till en del av den uttalade kritiken som fanns mot Erlang. Det är bl.a. svårt att hålla isär om det skall vara kommatecken, punkt eller semikolon i en del satser. Man anger dock att detta är frågan om en vanesak och inget större problem. Det finns även en del önskemål om sk. lambdafunktioner, högre ordningens funktioner och lathet från Aronsson och Grafström. Dessa funktioner är dock inte oumbärliga. Erlang är på sätt och viss ett defunktionaliserat språk, d.v.s. man har tagit bort mycket funktioner som inte används eller behövs. Ett annat problem som återkommer är att det är svårt att skapa gränssnitt till andra programspråk från Erlang
Sammantaget visar undersökningen på att de erfarenheter som studenterna hade överensstämmer med de erfarenheter som man hade inom de olika projekten. Detta anser jag, visar på att de uppgifter som jag har ställt samman stämmer in ganska bra med de erfarenheter av programspråket som finns hos telekommunikationsindustrin idag.
De erfarenheter som programkonstruktörerna i de sex olika projekten har stämmer väl överens med studenternas erfarenheter av Erlang.
Man anser att Erlang är ett litet och mycket kraftfullt programspråk, som är lätt att lära sig. Programkoden som skrivs upplevs som kortare jämfört med C++ och Plex. En fördel med språket är dess höga abstraktionsnivå. Man behöver inte bekymra sig om pekare, minneshantering eller att deklarera variabler.
Inget projekt har haft något problem med prestanda i de färdiga applikationerna. Det finns dock tecken på att Erlang skulle ha sämre prestanda än vad t.ex. C++ har. För att verkligen besvara denna fråga krävs emellertid fler undersökningar inom området.
Något projekt och någon student nämner att man har haft problem med att få ett fungerande gränssnitt mellan Erlang och andra programspråk.
Som programspråk anser man att Erlang bl.a. passar för realtidssystem, telekommunikation och distribuerade system. Men det finns indikationer på att det även skulle gå att använda inom andra områden. Man har dock svårt att tänka sig språket för applikationer i Dos/Windows eller applikationer med höga krav på prestanda. Applikationer som är hårdvarunära kan också vara olämpliga för Erlang
Det totala antalet fel i programkoden kan minska genom att man använder Erlang som implementationsspråk. Eller som en av programkonstruktörerna nämnde:
"Det är nog lika många fel per antalet rader som det var tidigare, dock blir det färre rader kod nu, vilket leder till att det blir färre fel totalt sett än vad det var tidigare.".
Anders Danne, Era-t
Det fanns bara ett projekt av sex som har haft lite problem med införandet av Erlang. Man hänvisar dock dessa problem till andra faktorer än själva programspråket. Det har istället handlat om bristfällig utbildning och kompetens som har gjort det svårt att dra full nytta av Erlangs hela styrka.
En annan slutsats av detta arbete är att programspråket inte har så stor betydelse för om ett projekt skall lyckas eller ej. Det finns andra faktorer som är viktigare t.ex. utbildning, stabilitet och förhållandet mellan språk och metod.
Jag väljer att avsluta och delvis instämma med följande ord:
"Vi har jämfört Erlang i första hand med C++ och vi anser att Erlang är bättre på allt utom prestanda, interfacing och möjligen med viss reservation för den dynamiska typningen"
Tomas Aronsson och Johan Grafström, Chalmers
Föreliggande uppsats skall ses som ett första kvalitativt försök att redogöra för programspråket Erlangs egenskaper samt programkonstruktörernas erfarenheter av att arbeta med detta språk. Redan det nu tillgängliga materialet tillåter att man gör en del analyser av språket, även om man hade önskat sig ett bredare material för denna uppgift. Under de veckor som detta arbete har engagerat mig har jag kommit i kontakt med många nya problem. Många av dessa har jag kommit till rätta med men många frågor återstår att besvara. Utifrån detta nuvarande material ser jag ingen möjlighet att besvara alla dessa frågor. Avslutningsvis tycker jag därför att det är av stor vikt att betona frågor som har blivit obesvarade i mitt och andras arbete inom detta område.
Varför har inte Erlang slagit igenom mer än vad det redan har gjort ?
Om språket har alla dessa egenskaper som jag har redovisat ställer man sig lite frågande till varför inte fler använder detta språk både inom och utanför Ericssonkoncernen. Jag har själv ett antal hypoteser om detta:
Det finns andra viktiga faktorer som har större betydelse för valet av programspråk än de som jag har undersökt.
Programspråk är trendkänsliga.
Språk är som religioner. Har man en gång valt ett språk så byter man inte ut det.
Valet av programspråk sker inte på rationella premisser, utan man använder det som man alltid har använt utan att utvärdera andra typer av språk till sina projekt.
Man känner sig främmande för deklarativa språk samt dess tankesätt.
Det tar tid innan ny teknologi slår igenom.
Bästa lösningen vinner inte alltid, d.v.s. det finns faktorer som är viktigare än den rent tekniskt bästa lösningen. Marknadsföring av programspråk kanske skulle kunna ha betydelse i detta sammanhang.
De krav på programspråk som återfinns inom telekommunikationsbranschen återfinns inte inom någon annan bransch.
Listan skulle säkerligen kunna göras längre
Kan Erlang användas inom andra områden ?
Alla personer som jag har intervjuat anser att Erlang inte enbart lämpar sig för applikationer inom telekommunikationsindustrin, utan borde kunna användas inom andra områden också. Det finns dock mig veterligen inte några projekt utanför denna värld som har använt sig av Erlang. En intressant uppgift skulle därför vara att undersöka i vilken mån språket skulle passa för andra typer av tillämpningar. En annan frågeställning som knyter an till den första frågan är:
Vad finns det för motiv när man väljer programspråk till ett projekt ?
Ett svar på denna fråga kanske skulle kunna vara att man inte alltid har något annat val än att bygga vidare på den plattform eller miljö som man redan har. Det går kanske inte att blanda språken hur som helst.
Tryckta källor:
[ 1 ] Ahlberg I, Bauner J-O, Danne A.: Prototyping cordless by using Declarative Programming, Ericsson Review 70, 1993:2
[ 2 ] Armstrong J, Virding R, Williams M.: Concurrent Programming in ERLANG, Prentice Hall International, 1993
[ 3 ] Aronson T, Grafström J.: A draft for our master thesis projekt, Underlag till examensarbete, Ericsson Telecom AB, Mölndal, 1995
[ 4 ] Datateknik.: De tror på deklarativa språk, nr 5, s.40-41, 1995
[ 5 ] Datateknik.: Deklarativa språk -
akademiskt flum eller framtidens programspråk?, nr 8, s.8-9, 1995
[ 6 ] Datateknik.: Nio gånger kortare program med svenska Erlang,
nr 11, s. 34-35, 1994
[ 7 ] Degroot D, Lindstrom G.: Logic programming -
Functions, relations and equations. Prentice-Hall, 1986
[ 8 ] Däcker B.: Erlang - A new programming language, Ericsson Review 70, 1993:2
[ 9 ] Ericsson.: Reprint from Ericsson Review, nr 2, 1993
[ 10 ] Ericsson Infocom Consultants.: NETSim From C++ to Erlang, Mars 1995
[ 11 ] Erlang Systems Division.: Erlang -Shortcuts in every phase
[ 12 ] Erlang Systems Division.: Erlang news, September 1994
[ 13 ] Erlang Systems Division.: Erlang news, Februari 1995
[ 14 ] Fenton N.: Software Metrics.:- A rigorous approach, Chapman & Hall, 1991
[ 15 ] Ghezzi C, Jazayeri M.: Programming language concepts,
John Wiley & Sons, 1982
[ 16 ] Goldkuhl G.: Kunskapsprojektering - Kunskapande, Kompendium, Institutionen för datavetenskap, Linköpings universitet
[ 17 ] Lindgren T.: An Erlang interface to SQL, examensrapport,
LiTH-IDA-EX-9456, 1994
[ 18 ] Malone J R.: Comparative Languages, Studentlitteratur, 1987
[ 19 ] Sommerville I.: Software Engineering, Addison-Wesley, 1992
[ 20 ] Stolterman E.: Designarbetets dolda rationalitet, Report UMADP-RRIPCS,14.91, 1991
[ 21 ] Wigblad R.: Utredningsmetodik, Kompendium, Ekonomiska institutionen Tekniska högskolan i Linköping
Internet:
[ 22 ] Armstrong J.: Functional programming comes of age,
Newsgroups:comp.lang.functional
[ 23 ] Ericsson.: The new generation of programming languages,
Http://www.ericsson.se/LME/articles/erlang_ct5.94.html
[ 24 ] Eripress 93.: Global launch of Ericsson's powerful new program language,
Http://www.ericsson.se/Eripress/summ/q393.html
[ 25 ] Erlang Systems Division.: Erlang Overview,
http://www.ericsson.se/cslab/erlang/overview.html
[ 26 ] Erlang Systems Division.: History of Erlang,
http://www.ericsson.se/cslab/erlang/history.html
[ 27 ] Erlang Systems Division.: Introduction to Erlang tools,
http://www.ericsson.se/erlang/products/overview.html
[ 28 ] Erlang Systems Division.: Platforms,
http://www.ericsson.se/erlang/products/overview.html#HDR25
AXE-10
En av Ericssons mest sålda AXE-växel.
BIF
Built in functions.
DCT900
Ericssons digitala och trådlösa telefonsystem.
EriPascal
En Ericsson dialekt av Pascal som klarar att hantera processer.
H
Funktionellt programspråk utvecklat av Carlstedt Elektronik AB.
HP/UX
Hewlett Packards (HP) UNIX version.
Lambda funktioner
En notation för att mycket generellt beskriva hur funktioner appliceras på sina argument. Lambda används för att definiera procedurer på samma sätt som "define", bortsett från att inget namn anges för proceduren som definieras. Lambda kan ses som ett anonym "define".
MD110
Telefonväxel konstruerad av Ericsson.
PBX
Ett grafikpaket under UNIX.
RACE
Research into Advanced Communications in Europe.
Single assignment
Alla variabler är "konstanter". Det går inte att tilldela en variabel ett nytt värde mer än en gång.
Solaris
SUN´s nya UNIX version.
TMOS
Står för "Telecommunication Management and Operations Support" och är ett programsystem som är avsett för drift och underhåll av en AXE- växel.
TUP
Tekniskt Utskott för programvara.
XView
Ett grafikpaket under UNIX.
1. Hur kom ni i kontakt med Erlang första gången.
2. Vad fanns det för krav på programspråket till projektet.
3. Hur gick valet av programspråk till.
4. Vem gjorde valet av Erlang.
5. Vad var den främsta anledningen till att Erlang valdes.
6. Vilken betydelse var det att Erlang är deklarativt.
7. Vad kände ni till om Erlang sedan tidigare.
8. Fanns det några andra språk som var aktuella och i så fall vilka.
9. Har valet av Erlang präglat projektet på något annat sätt.
10. Har projektgruppens storlek/sammansättning påverkats genom valet av Erlang.
11. Hur upplever du att utvecklingstiden har påverkats av genom valet av Erlang
12. Har kvaliteten påverkats i koden genom valet av Erlang och i så fall hur
13. Vad anser du att valet av programspråk har för betydelse för ett projekt.
14. Om du hade gjort om detta projektet hade du valt något annat programspråk.
15. Vad är Erlangs starkaste sida.
16. Vilken typ av projekt lämpar sig Erlang bäst för.
17. Vad är Erlangs svagaste sida.
18. Vilken typ av projekt är Erlang olämplig för.
19. Vilka anser du vara Erlangs praktiska användningsområden.
20. Har förutsättningarna skilt sig i detta projekt jämfört med andra projekt.
21. När eller i vilket skede gjordes valet av programspråk.
22. Vad är viktigast för att ett projekt skall lyckas
1. Hur lång praktisk erfarenhet har du av Erlang.
2. Vilka programspråk har ni arbetat med tidigare
3. Jämför dina erfarenheter av andra programspråk med Erlang.
4. Vad anser du att valet av programspråk har för betydelse för ett projekts utgång.
5. Vilket programspråk använder du dig själv helst av.
6. Vad anser du vara Erlangs starkaste sida.
7. Vad är Erlangs svagaste sida.
8. Vilken typ av projekt lämpar sig Erlang för.
9. Vilken typ av projekt är Erlang olämplig för
10. Har programvarukvaliteten påverkats genom valet av Erlang.
11. Har utvecklingstiden påverkats av genom valet av Erlang.
12. Hur har valet av programspråk påverkat ditt arbetssätt.
13. Arbetar du på ett annat sätt med ett deklarativt språk
14. Vad är det för typ av fel som uppstår i koden.
15. Hur är koden att underhålla.
16. Om du hade gjort om detta projektet hade du valt något annat programspråk .
17. Finns det något som saknas eller har ett dåligt stöd i språket.
18. Vad tycker du är den största skillnaden mellan ett deklarativt programspråk som
Erlang från andra mer "traditionella språk".
19. Har språket gett er något extra, som ni inte hade fått med er i något annat
programspråk.
1. Vad anser du om Erlang, fördelar/nackdelar.
2. Vilka programspråk har du använt dig av tidigare.
3. Hur länge har du använt Erlang.
4. Gör en kort beskrivning av ditt arbete eller din uppgift.
module(echo).
-export([start/0, loop/0]).
start()->
spawn(echo, loop, []).
loop()->
receive
{ From, Message} ->
From ! Message,
loop()
end.
Bild 3: Programexempel i Erlang.
Den lilla modulen echo har två funktioner som kan anropas utifrån: start(), som med hjälp av Spawn-satsen startar en ny process, och Loop() - en evighetsfunktion som oupphörligen tittar efter i brevlådan för att se om det har kommit någon post.
Anta att start() anropas från en anan process med satsen Id = echo:start(). Satsen Spawn(echo, loop, []), startar då en ny process - i detta fall echos loopfunktion -och returnerar samtidigt en processidentifierare till variabeln Id. Nu går det bra att skicka meddelanden.
Med satsen Id ! {self(), hello} skickas meddelandet {self(), hello} till Id:s brevlåda. Funktionen self() är inbyggd i Erlang och ger processidentifieraren till den just nu aktuella processen, d.v.s. avsändaren.
Loop tar emot och försöker matcha meddelandet mot sina alternativ. Vid matchningen binds variabeln From till Self() och Message kommer hädanefter att betyda hello.
Loop hälsar tillbaka till den ursprungliga processen och börjar om i väntan på nya meddelanden.
1 Med programkonstruktörer avser jag personer som deltar både i analys, design och programmerings-faserna i ett projekt.
2 Med storlek tas i denna bemärkelse både hänsyn till antalet projektmedlemmar och uppgiftens omfattning.
3 Som t ex PLEX eller C. Se vidare i kapitlet "Imperativa/deklarativa språk".
4 Jag använder begreppet samtidighet som jag tycker är en bättre och mer riktig översättning av "concurrency", istället för parallellism. Parallellism är för mig förknippat med plattformar med flera processorer, och inte en processor som är multi-programmerad.
5 Jag syftar här främst på Von Neumannarkitekturen som är den idag vanligaste arkitekturen för dagens datorer och programspråk.
6 Det finns naturligtvis programspråk som är undantag från detta. Ett exempel skulle kunna vara Smalltalk som får lov att anses som ett imperativt programspråk med relativt hög abstraktionsnivå.
7 Med traditionella programspårk avser jag då imperativa programspråk.
8 Minne som har tilldelats en applikation måste göras fritt när det inte längre skall användas. Annars uppstår minnesläckor, d. v. s applikationen får till slut för lite tillgängligt minne för att kunna fortsätta exekvera.
9 Den korrekta benämningen går under "Single assignment" och innebär i princip att alla variabler är konstanter. Ett av de främsta syftet med detta är att man inte av misstag skall kunna tilldela en variabel ett felaktigt värde.
10 RACE står för Research into Advanced Communications in Europe och är ett forum som skall stimulera forskning och utveckling av hård- och mjukvara.
11 EriPascal är en vidareutveckling av Pascal som används inom Ericsson.
12 Anders syftar här på en artikel i datateknik [4 ] där begreppet "tvättmaskiner" tas upp för att exemplifiera små apparater där hårdvaran skall vara liten och billig.
13 TMOS står för: Telecommunication Management and Operations Support och är ett programsystem som är avsett för drift och underhåll av en AXE-växel.
14 Den rätta benämningen är på denna term är BIF och står för - Built In Functions.
15 Med högre ordningens funktioner avses funktioner som inte enbart kan ta värden såsom heltal, flyttal, records etc som argument, utan som också kan låta godtyckliga funktioner vara argument till andra funktioner.
16 Den korrekta benämningen är lazy evaluation. I deklarativa beskrivningar av vad en dator skall utföra finns inte någon angiven tidsordning mellan de olika operationerna. När det kommer in ny information från omvärlden till systemet så finns det olika sätt att hantera detta på. Ett sätt är att låta datorn härleda alla konsekvenser av den nya informationen genom att sätta in den i alla uttryck där den refereras. Denna strategi kallas forward chaining, datadriven evaluation. Vid lazy evaluation som är den andra extrempunkten, görs inga beräkningar alls utom de som explicit efterfrågas (d.v.s. det som krävs för att generera explicit begärd utmatning ur systemet).
17 Med "andra språk" avses huvudsakligen imperativa programspråk.
18 Det var knappast någon som nämnde att han använde Erlangs debugger för att hitta fel i programkoden. Oftast behövdes den inte för att hitta felen eftersom det upplevs som ganska lätt att hitta dessa. I de fall där man hade använt debugger var man inte helt nöjd med denna. Ett välkänt faktum är annars att det är mycket svårt att testa programkod med parallellism. Detta beror delvis på att det är svårt att föja programmets "flöde".