Industriella Erfarenheter av Erlang


Inneh&aringllsf&oumlrteckning

I
F&oumlrord
II
Sammanfattning
1
Inledning
1.1
Bakgrund
1.2
Problemomr&aringde
1.3
Utredningsuppdrag och syfte
1.4
M&aringl
1.5
M&aringlgrupp
1.6
Avgr&aumlnsning
1.7
Metod
1.7.1
Projekten
1.7.2
Studenterna
1.8
L&aumlsanvisning

2
Perspektivanalys
2.1
F&oumlrest&aumlllningar
2.2
Erfarenheter

3
Kunskapsanalys
3.1
Kunskapsinventering
3.2
Kunskapsbehov

4
Programvarukrav inom telekommunikationsindustrin

5
Imperativa/ deklarativa spr&aringk

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&aumlmf&oumlrelse med andra programspr&aringk
8.1.4
Programspr&aringkets betydelse
8.2
EBC/MD
8.2.1
Projektbeskrivning
8.2.2
Erfarenheter
8.2.3
J&aumlmf&oumlrelse med andra programspr&aringk
8.2.4
Programspr&aringkets betydelse
8.3
ERA-t
8.3.1
Projektbeskrivning
8.3.2
Erfarenheter
8.3.3
J&aumlmf&oumlrelse med andra programspr&aringk
8.3.4
Programspr&aringkets betydelse
8.4
ETX/B
8.4.1
Projektbeskrivning
8.4.2
Erfarenheter
8.4.3
J&aumlmf&oumlrelse med andra programspr&aringk
8.4.4
Programspr&aringkets betydelse
8.5
Mobility server
8.5.1
Projektbeskrivning
8.5.2
Erfarenheter
8.5.3
J&aumlmf&oumlrelse med andra programspr&aringk
8.5.4
Programspr&aringkets betydelse
8.6
NETSim
8.6.1
Projektbeskrivning
8.6.2
Erfarenheter
8.6.3
J&aumlmf&oumlrelse med andra programspr&aringk
8.6.4
Programspr&aringkets betydelse

9. Studenternas erfarenheter av Erlang
9.1
Beskrivning av examensarbetena
9.2
Erfarenheter
9.3
J&aumlmf&oumlrelse med andra programspr&aringk
9.4
Programspr&aringkets betydelse

10
Analys

11
Slutsatser

12
Avslutande diskussion

13
K&aumlllf&oumlrteckning

14
Ordlista

Bilagor
  1. intervjuguide f&oumlr projektledare
  2. intervjuguide f&oumlr programkonstrukt&oumlrer
  3. enk&aumltfr&aringgor till examensarbetare
  4. programexempel
  5. Fotnoter





F&oumlrord

Denna rapport &aumlr ett avslutande arbete på den Systemvetenskapliga linjen på Link&oumlpings universitet. Detta arbete har kommit till med m&aringnga m&aumlnniskors hj&aumllp. Utan alla inblandade personers st&oumld så hade detta arbete varit sv&aringr att genomf&oumlra. Jag vill speciellt tacka min uppdragsgivare Bengt Lennartsson som har haft m&aringnga visioner och varit till mycket stor hj&aumllp i mitt arbete.

Tack &aumlven till:

  • Roy Bengtsson, Erlang Systems Division AB
  • Mike Williams, Erlang Systems Division AB/ Ellemtel
  • Bjarne D&aumlcker, Ellemtel
  • Anders Berglund, KTH
  • Tomas Aronsson, CTH
  • Johan Grafstr&oumlm, CTH
  • Jonna Palm, H&oumlgskolan i Sk&oumlvde
  • Anders Wennerstr&oumlm, Ericsson


  • Sist men inte minst vill jag tacka alla ber&oumlrda Ericsson projekt f&oumlr att de har st&aumlllt upp att dela med sig sina erfarenheter av Erlang.


    Link&oumlping den 17 Januari 1996
    Johan Carleson, Johan.Carleson@nor1.wmdata.se.





    Sammanfattning

    Denna rapport &aumlr en redog&oumlrelse f&oumlr ett examensarbete som har utf&oumlrts på den systemvetenskapliga linjen vid Link&oumlpings universitet. Rapporten &aumlr en empirisk studie d&aumlr industriella erfarenheter av programspr&aringket Erlang har samlats in och analyserats.

    Denna uppsats har som syfte att besvara fr&aringgor som: Vad finns det f&oumlr f&oumlrdelar/nackdelar med Erlang, hur skiljer sig Erlang fr&aringn andra spr&aringk, hur p&aringverkas kodkvaliteten och utvecklingstiden, i vilka sammanhang passar Erlang b&aumlst/s&aumlmst med etc. Ett annat syfte &aumlr att j&aumlmf&oumlra f&oumlr- och nackdelar av Erlang j&aumlmf&oumlrt med andra vanliga programspr&aringk som anv&aumlnds inom telekommunikationsindustrin idag.

    F&oumlr att få svar på dessa fr&aringgor genomf&oumlrdes en empirisk studie av sex programutvecklingsprojekt som har anv&aumlnt sig av Erlang. De personer som intervjuades i projekten var fr&aumlmst programkonstrukt&oumlrer men &aumlven en del projektledare. F&oumlr att få in andra synvinklar gjordes &aumlven en mindre kompletterande enk&aumltstudie av fyra examensarbetares erfarenheter av Erlang.

    De slutsatser som kan dras av arbetet &aumlr:
    Det var bara ett projekt av sex som har haft problem med inf&oumlrandet av Erlang. Man h&aumlnf&oumlr dock dessa problem till andra faktorer &aumln sj&aumllva programspr&aringket. Det har handlat om bristf&aumlllig utbildning och kompetens som har gjort det sv&aringrt att dra full nytta av Erlangs hela styrka.

    Generellt så &aumlr alla &oumlverens om att Erlang &aumlr ett litet och kraftfullt spr&aringk som passar bl.a. f&oumlr realtidssystem , telekommunikation och distribuerade system.
    Spr&aringket &aumlr l&aumltt att l&aumlra sig och har en h&oumlg abstraktionsnivå som hanterar programdesignens komplexitet på ett bra s&aumltt. Den programkod som skrivs blir ofta kortare &aumln programkod som skrivs i imperativa programspr&aringk. Antalet fel i programkoden kan &aumlven minska genom att man anv&aumlnder Erlang som implementationsspr&aringk.

    Det finns n&aringgra fr&aringgetecken om Erlangs m&oumljlighet att fungera som gr&aumlnssnitt till andra programspr&aringk.

    En annan slutsats av detta arbete &aumlr att programspr&aringket inte har så stor betydelse f&oumlr om ett projekt skall lyckas eller ej. Det finns andra faktorer som &aumlr viktigare som t.ex. utbildning, stabilitet i projektorganisationen och f&oumlrh&aringllandet mellan spr&aringk och metod.





    1. Inledning


    1.1 Bakgrund

    Denna rapport &aumlr ett examensarbete utf&oumlrt på den Systemvetenskapliga linjen, Universitetet i Link&oumlping. Rapporten &aumlr en avslutande redovisning av det arbete som genomf&oumlrdes under v&aringren 1995, vilket motsvarar 10 po&aumlng.

    Arbetet &aumlr ett utredningsuppdrag fr&aringn institutionen f&oumlr datavetenskap (IDA), Universitetet i Link&oumlping.

    1.2 Problemomr&aringde

    Det problemomr&aringde som detta arbete har ber&oumlrt, har varit b&aringde stort och delvis ok&aumlnt f&oumlr mig. Detta har medf&oumlrt att m&aringlet blev att samla in så mycket information på omr&aringdet som m&oumljligt. I arbetet har en explorativ ansats anv&aumlnts, f&oumlr att f&aringnga upp nya fr&aringgor och tankar som har dykt upp i arbetsprocessen.

    Ett stort problem har varit att komma i kontakt med projekt som har anv&aumlnt sig av Erlang. Detta berodde till en viss del på att m&aringnga projekt var av konfidentiell karakt&aumlr. Ambitionen var att komma i kontakt med kommersiella programutvecklingsprojekt som nyligen hade lanserat en produkt gjord med Erlang och som d&aumlrmed kunde f&oumlrmedla b&aringde positiva och negativa erfarenheter av detta arbete.

    En annan sida av detta arbete var att j&aumlmf&oumlra Erlang med andra programspr&aringk. F&oumlr att detta skall kunna ske så beh&oumlver man antingen likartade projekt d&aumlr man programmerar i olika spr&aringk eller f&oumlrlita sig på programmerarnas tidigare erfarenheter med andra programspr&aringk, f&oumlr att kunna finna skillnader.

    1.3 Utredningsuppdrag och syfte

    Utredningen har gjorts med st&oumld ifr&aringn och på uppdrag av Institutionen f&oumlr datavetenskap (IDA) Link&oumlpings universitet. Direktiven f&oumlr unders&oumlkningen gick ut på att sammanst&aumllla och analysera industriella erfarenheter av programspr&aringket Erlang. Det som skulle unders&oumlkas var bl.a. hur valet av Erlang p&aringverkar : implementationen, programvaruarkitekturen och programvarudesignen.

    Denna uppsats har som syfte att besvara fr&aringgor som: Vad finns det f&oumlr f&oumlrdelar/nackdelar med Erang, hur skiljer sig Erlang fr&aringn andra spr&aringk, hur p&aringverkas kodkvalitet och utvecklingstid, vilka sammanhang passar Erlang b&aumlst/s&aumlmst f&oumlr. Ett annat syfte &aumlr att j&aumlmf&oumlra f&oumlr- och nackdelar av Erang j&aumlmf&oumlrt med andra vanliga programspr&aringk som anv&aumlnds inom telekommunikationsindustrin idag.

    1.4 M&aringl

    M&aringlet med detta examensarbete &aumlr att f&oumlrmedla samt reflektera &oumlver erfarenheter av programspr&aringket Erlang inom telekommunikationsindustrin. Genom att utveckla denna kunskap så hoppas jag kunna tillf&oumlra viktig information om programspr&aringkets egenskaper. Denna information skulle kunna anv&aumlndas som beslutsunderlag f&oumlr en verksamhet eller projektgrupp som funderar på att anv&aumlnda sig av Erlang i ett projekt. Ett annat m&aringl &aumlr att unders&oumlka vad valet av programspr&aringk har f&oumlr betydelse f&oumlr programutvecklingsprojekt i ett st&oumlrre perspektiv.

    1.5 M&aringlgrupp

    Utredningens m&aringlgrupp &aumlr f&oumlrst och fr&aumlmst min uppdragsgivare - Institutionen f&oumlr datavetenskap (IDA) vid Link&oumlpings universitet. Andra grupper som skulle kunna vara intresserade av detta arbete &aumlr programutvecklingsprojekt som st&aringr inf&oumlr valet att v&aumllja Erlang som programspr&aringk men som vet lite f&oumlr lite om vad detta kommer att medf&oumlra f&oumlr konsekvenser. &Aumlr man nyfiken på vad Erlang &aumlr f&oumlr n&aringgot kan den h&aumlr rapporten också fungera som en kort introduktion eller ink&oumlrsport till spr&aringket. F&oumlrkunskaper i Erlang eller andra deklarativa spr&aringk beh&oumlvs inte f&oumlr att man skall kunna tillgodog&oumlra sig inneh&aringllet i denna rapport.

    1.6 Avgr&aumlnsning

    De intervjuer som &aumlr gjorda omfattar endast projekt inom Ericssonkoncernen. Detta beror på att Erlang endast har funnits som en kommersiell till&aumlmpning i två &aringr. Det har s&aringledes inte kommit ig&aringng utomst&aringende projekt som skulle kunna vara aktuella f&oumlr denna studie.

    1.7 Metod

    Att finna j&aumlmf&oumlrbara projekt (b&aringde till storlek, tid, komplexitet och funktionalitet) &aumlr i det n&aumlrmaste om&oumljligt. &Aumlven om man kunde finna s&aringdana projekt så finns det m&aringnga andra faktorer som kan p&aringverka en j&aumlmf&oumlrelse, exempelvis programmerarnas kompetens eller metodval. Att gallra ut egenskaper som spr&aringket besitter fr&aringn andra variabler som p&aringverkar ett projekt &aumlr d&aumlrf&oumlr mycket sv&aringrt.

    F&oumlr att samla in konkreta erfarenheter av Erlang så har jag prim&aumlrt valt intervjuer som tillv&aumlgag&aringngss&aumltt. Jag har i f&oumlrsta hand intervjuat programkonstrukt&oumlrer i projekt som anv&aumlnder sig av programspr&aringket Erlang. De ber&oumlrda projekten &aringterfinns alla inom telekommunikationsindustrin och ing&aringr i den svenska delen av Ericssonkoncernen.

    F&oumlr att få kontrast och lite andra synvinklar till projektgruppernas erfarenheter gjorde jag konkreta f&oumlrs&oumlk att nå andra personer med erfarenheter inom omr&aringdet. Detta visade sig vara mycket sv&aringrt och jag var mycket n&aumlra att ge upp denna idé. I ett sent skede i arbetet kom jag dock i kontakt med ett antal studenter som h&oumlll på med sina examensarbeten om Erlang. Jag fann det d&aumlrf&oumlr angel&aumlget att f&aringnga upp &aumlven deras erfarenheter inom omr&aringdet. Syftet med att kontakta b&aringde projekten och studenterna var att få fram en mer nyanserad bild av programspr&aringkets egenskaper.
    Min tanke var att jag genom indelningen i dessa b&aringda grupper skulle få in ett material som t&aumlcker in de flesta av spr&aringkets karakteristiska egenskaper. Jag skulle kanske d&aumlrigenom kunna f&aringnga upp andra typer av problem eller egenskaper som programspr&aringket har.

    Eftersom studenterna hade en begr&aumlnsad erfarenhet av programspr&aringket, avs&aringg jag inte att g&oumlra n&aringgra st&oumlrre j&aumlmf&oumlrelser mellan deras och projektgruppernas uppfattningar inom omr&aringdet. Jag valde ist&aumlllet att sammanst&aumllla materialet f&oumlr att kunna bekr&aumlfta, ifr&aringgas&aumltta eller komplettera projektgruppernas uppfattningarna.

    Mitt arbete bygger s&aringledes i f&oumlrsta hand på de insamlade uppgifterna fr&aringn de olika projekten. I den m&aringn de olika projekten och studentgruppen har en gemensam syn på spr&aringkets egenskaper så ser jag detta som en bekr&aumlftelse på att de uppm&aumlrksammade f&oumlrh&aringllandena st&aumlmmer. I den m&aringn det finns avvikelser mellan dessa b&aringda gruppers uppfattning eller inst&aumlllning till spr&aringkets egenskaper, så analyserar och behandlar jag detta i den efterf&oumlljande analysdelen.

    Vid sidan av arbetet med att samla in konkreta erfarenheter så har jag &aumlven gjort en genomg&aringng av litteratur som finns att tillgå om Erlang och deklarativa spr&aringk. Syftet med denna litteraturstudie har varit att skapa ett stark grund f&oumlr intervjuerna men &aumlven f&oumlr att kunna redog&oumlra f&oumlr spr&aringkets struktur samt dess funktioner. Litteraturstudien har &aumlven ber&oumlrt imperativa och deklarativa programspr&aringks typiska egenskaper.


    1.7.1 Projekten
    F&oumlr att komma i kontakt med l&aumlmpliga programutvecklingsprojekt som har anv&aumlnt sig av Erlang så etablerades en kontakt med Erlang Systems Division AB. Erlang Systems Division AB &aumlr leverant&oumlr av spr&aringket och k&aumlnner till de projekt som har k&oumlpt och anv&aumlnt sig av Erlangmilj&oumln.
    Detta f&oumlrfaringss&aumltt &aumlr naturligtvis inte helt problemfritt. Den st&oumlrsta risken &aumlr att det kan ske ett medvetet eller omedvetet urval av projekt som har specifika erfarenheter och som inte &aumlr representativa f&oumlr andra projekt som har anv&aumlnt sig av Erlang. Min f&oumlrhoppning var att denna strategi &aumlndå skulle vara anv&aumlndbar. Detta grundar jag bl.a. på att Erlang Systems Division AB var mycket intresserade av att det gjordes en studie av n&aringgon utanf&oumlr Ericssonv&aumlrlden och att man fick fram b&aringde bra och d&aringliga egenskaper hos spr&aringket. Eftersom spr&aringket fortfarande utvecklas till en viss del, så &aumlr man fr&aringn Erlang Systems Division AB angel&aumlgna om att få ta del av all kritik mot spr&aringket. M&aringnga projekt har &aumlven på ett aktivt s&aumltt kunnat p&aringverka spr&aringkets successiva utveckling.
    Hade spr&aringket haft st&oumlrre spridning i eller utanf&oumlr Ericssonkoncernen skulle jag ha kunnat arbeta på ett mer traditionellt s&aumltt d&aumlr jag sj&aumllv hade kontaktat projekten, men under de omst&aumlndigheter som r&aringdde s&aringg jag inga andra m&oumljligheter.

    Kontakten med projekten
    Valet av projektgrupper som skulle studeras gick till på f&oumlljande vis.

    Vid en sammankomst på Erlang Systems Division AB den 27 mars med Roy Bengtsson (VD), Bjarne D&aumlcker (Ellemtel), Mike Williams (Ellemtel/Erlang Systems Division AB), och min uppdragsgivare Bengt Lennartsson fastst&aumllldes vilka urvalskriterier som var viktiga f&oumlr urvalet av projekt till unders&oumlkningen.

    Vi ans&aringg det vara viktigt att de utvalda projekten var av varierande storlek. D&aumlrf&oumlr s&aringg vi till att ta med små, medelstora och stora projekt bland de unders&oumlkta projekten. Små projekt &aumlr projekt med två till fem projektmedlemmar medan stora projekt har fler &aumln 20 projektmedlemmar. Anledningen till att vi ans&aringg det vara v&aumlsentligt att representera dessa olika projekttyper var att vi d&aumlrigenom skulle kunna isolera oss fr&aringn eventuella felaktiga slutsatser som har att g&oumlra med projekstorleken.
    Ett av dessa sk&aumll &aumlr att andelen programmerare i regel &aumlr st&oumlrre i små projekt &aumln vad det &aumlr i stora projekt. Stora projekt kr&aumlver mycket administrativ personal och projektstyrning medan detta &aumlr mindre viktigt i små projekt. F&oumlljaktligen kan effekten av programspr&aringket uppm&aumlrksammas mer i små projekt &aumln i st&oumlrre projekt. Man kan också t&aumlnka sig att små projekt oftast sysslar med prototyper och verkar inom forskning i st&oumlrre utstr&aumlckning &aumln vad man g&oumlr i st&oumlrre projekt. I de st&oumlrre projekten sysslar man oftast med att konstruera kommersiella till&aumlmpningar med h&oumlga krav på prestanda och funktionalitet. Dessa scenarier st&aumlller olika krav på implementationsspr&aringket. I små projekt kanske man efterstr&aumlvar ett flexibelt programspr&aringk medan man i ett stort projekt efterstr&aumlvar ett stabilt och enkelt programspr&aringk. Sammantaget kan man s&aumlga att projektstorleken bl.a. g&oumlr att projekten har olika f&oumlruts&aumlttningar. Dessa olika f&oumlruts&aumlttningar g&oumlr att man st&aumlller olika krav på implementationsspr&aringket.

    Ett annat viktigt urvalskriterium var att vi f&oumlretr&aumldesvis valde projekt d&aumlr man utvecklade n&aringgon form av kommersiell produkt. Med kommersiell avses h&aumlr en produkt som inte fr&aumlmst var avsedd att anv&aumlndas internt inom den egna avdelningen utan som skulle s&aumlljas externt eller till n&aringgot annat Ericssonbolag. Den fr&aumlmsta anledningen varf&oumlr detta var ett viktigt kriterium var att det oftast st&aumllls h&oumlgre krav på en kommersiell produkt &aumln på en produkt som fr&aumlmst &aumlr avsedd att anv&aumlndas internt. Vidare st&aumllls &aumlven andra typer av krav på kommersiella produkter (exempelvis h&oumlga krav på prestanda och funktionalitet m.m.). N&aumlr man skall konstruera en kommersiell produkt st&aumllls man s&aringledes inf&oumlr andra typer av problem &aumln vad man g&oumlr inom t.ex. forskning och utveckling.

    Oftast inneb&aumlr kommersiella produkter h&oumlgre krav på implementationsspr&aringket &aumln vad som annars st&aumllls. Det kan st&aumlllas krav som att spr&aringket skall vara l&aumltt att l&aumlra sig samtidigt som det m&aringste vara mycket kraftfullt. Avsikten med detta arbete var att samla in industriella erfarenheter av Erlang. Det l&aringg s&aringledes i sakens natur att vi i f&oumlrsta hand valde projekt som st&aumlllde h&oumlga krav på implementationsspr&aringket f&oumlr att utv&aumlrderingen av Erlangerfarenheterna skulle bli så komplett och helt&aumlckande som m&oumljligt. Vi avs&aringg d&aumlrf&oumlr fr&aumlmst att kontakta projekt d&aumlr man har anv&aumlnt sig av Erlang under så realistiska f&oumlrh&aringllanden som m&oumljligt.

    Det tredje viktiga kriteriet som st&aumllldes upp var att vi skulle få med b&aringde projekt som hade utfallit som planerat och projekt som haft n&aringgon form av problem eller sv&aringrigheter i sitt arbete. Risken var att alltf&oumlr positiva/negativa h&aumlndelser i projekten skulle inverka på de upplevda erfarenheterna av programspr&aringket. D&aumlrf&oumlr ans&aringg vi det som ytterst v&aumlsentligt att b&aringda dessa typer av projekt fanns representerade i unders&oumlkningen f&oumlr att det skulle vara m&oumljligt att isolera dylika fenomen.


    Intervjuerna i projekten
    Jag har intervjuat 12 personer i sex olika programutvecklingsprojekt som har anv&aumlnt sig av Erlang. Fem av dessa projekt fanns i Stockholm medan ett fanns i Link&oumlping. Intervjuerna skedde under tiden 20/4-11/5. De personer som jag har intervjuat har fr&aumlmst varit programkonstrukt&oumlrer som anv&aumlnt Erlang som implementationsspr&aringk. Ut&oumlver denna grupp så har jag &aumlven f&oumlrs&oumlkt att få kontakt med projektledarna i de st&oumlrre projekten, f&oumlr att se om det fanns delade meningar om spr&aringkets egenskaper inom respektive projekt.

    Till st&oumld f&oumlr intervjuerna utarbetades intervjuguider, vilka fungerade som en kontroll f&oumlr att de fr&aringgeomr&aringden som ans&aringgs viktiga att belysa också kom med i intervjuerna. Dessa guider &aringterfinns 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&aringn intervjufr&aringgorna uppmanades intervjupersonerna hela tiden att utveckla och/eller motivera sina svar. Intervjuerna skrevs ner f&oumlr hand under intervjuernas g&aringng. Utskriften s&aumlndes sedan till de intervjuade f&oumlr att dessa skulle ha m&oumljlighet att r&aumltta eventuella missf&oumlrst&aringnd innan uppsatsen l&aumlmnades in. F&oumlr att få n&aringgon uppfattning om vad som var v&aumlsentliga fr&aringgor till intervjuguiden så hade jag i f&oumlrv&aumlg gjort en kortare genomg&aringng litteraturen. De fr&aringgor som projektledarna fick skilde sig ifr&aringn de fr&aringgor som programkonstrukt&oumlrer fick. Detta berodde på att projektledarna i regel inte hade n&aringgon direkt erfarenhet av programmeringen.


    1.7.2 Studenterna
    Kontakten med de olika studenterna etablerades på m&aringnga olika s&aumltt. På Ericsson Infocom Consultants fick jag k&aumlnnedom om en person som h&oumlll på med ett examensarbete om Erlang. Denne k&aumlnde i sin tur två examensarbetare som h&oumlll på med n&aringgot liknande. En fj&aumlrde person fick jag kontakt med sedan jag skickade en f&oumlrfr&aringgan om "Erlangerfarenheter" till Usenet newsgroup:en - comp.lang.functional, på internet.

    Studenterna g&aringr alla på n&aringgon form av civilingenj&oumlrsutbildning och har f&aringtt sina examensarbeten i uppdrag av olika Ericssonbolag. Deras arbeten g&aringr ut på att implementera n&aringgot i Erlang f&oumlr att sedan skriva en rapport om detta arbete.
    Alla studenterna har vidare g&aringtt på den fyra-dagarskurs som Erlang Systems AB ger och som skall utg&oumlra den tillr&aumlckliga grund en f&oumlr att man skall kunna beh&aumlrska spr&aringket. De har dock inte n&aringgon l&aumlngre tids praktisk erfarenhet av Erlangprogrammering. Detta g&oumlr att jag inte helt okritiskt kan anv&aumlnda mig av j&aumlmf&oumlrelser mellan denna grupp och projektgruppen. Trots det faktum att studenterna har mindre praktisk erfarenhet och utf&oumlr en avgr&aumlnsad uppgift så r&oumlr det sig om kvalificerat arbete som kr&aumlver ing&aringende kunskaper av de inblandade. Den gemensamma bakgrunden g&oumlr att de har likartade f&oumlruts&aumlttningar f&oumlr att l&oumlsa sina uppgifter vad betr&aumlffar kunskap och tidigare kunskaper i programmering. D&aumlrf&oumlr ser jag ingen anledning att urskilja de olika personerna redovisningen av materialet.


    Intervjuerna med studenterna
    Intervjuerna med denna grupp har gjorts med hj&aumllp av enk&aumlter med ganska &oumlppet formulerade fr&aringgor. Enk&aumlten inneh&oumlll 5-6 fr&aringgor och skickades ut till personerna med hj&aumllp av elektronisk post. Anledningen till detta f&oumlrfaringss&aumltt var att det var det snabbaste och enklaste s&aumlttet att komma i kontakt med dessa personer. Jag var &aumlven i ett mycket sent skede i mitt arbete, vilket tvingade mig att få in dessa svar mycket snabbt. Fr&aringgorna skickades ut den 8 juni och kom tillbaka redan samma dag. Enk&aumlten &aringterfinns i bilaga 3 i slutet av uppsatsen.

    1.8 L&aumlsanvisning

    Resultatet fr&aringn projektintervjuerna kommer att beskrivas projektvis.
    Presentationen av respektive projekt inleds med en projektbeskrivning d&aumlr projektmedlemmar och projektuppgift presenteras. Efter den inledande projektbeskrivningen kommer delen med projektmedlemmarnas erfarenheter och synpunkter på Erlang. Denna del f&oumlljs av en del d&aumlr skillnaden mellan Erlang och andra programspr&aringk tas upp. Avslutningsvis kommer en reflektion &oumlver programspr&aringkets betydelse i ett mer &oumlvergripande perspektiv.

    Efter presentationen av alla projekten kommer ett kapitel med studenternas erfarenheter. Redog&oumlrelsen f&oumlr studenternas erfarenheter kommer att g&oumlras i en gemensam del. Anledningen till detta &aumlr att de i m&aringngt och mycket har gemensamma faktorer som g&oumlr det l&aumlmpligt att samla ihop dessa personer till en uttalad grupp.




    2. Perspektivanalys

    I detta avsnitt redovisas de f&oumlrest&aumlllningar och tankar som jag hade innan jag b&oumlrjade mitt arbete med litteraturstudien och unders&oumlkningen. Detta &aumlr av stor vikt f&oumlr att jag skall kunna g&oumlra mig kritiserbar. F&oumlr att m&oumljligg&oumlra detta &aumlr det av stor vikt att mina f&oumlrest&aumlllningar och tankar utskiljs fr&aringn det &oumlvriga materialet.

    2.1 F&oumlrest&aumlllningar

    Den systemvetenskapliga linjen i Link&oumlping 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&aringtt med mig &aumlr s&aringledes en holistisk syn på systemutvecklingen, d.v.s. att helheten &aumlr viktigare &aumln dess delar. Detta syns&aumltt har f&oumlljaktligen pr&aumlglat b&aringde mig som person samt min syn på tillvaron. Jag tror att man m&aringste betrakta en verksamhet eller omr&aringde efter dess helhet, annars finns det en uppenbar risk f&oumlr att man fokuserar på ov&aumlsentliga detaljer i sammanhanget.
    Min f&oumlrest&aumlllning om Erlang var att det var ett ganska nytt och &aumlnnu ok&aumlnt programspr&aringk som fr&aumlmst anv&aumlnds inom Ericsson. Eftersom jag inte har n&aringgra direkta erfarenheter av spr&aringket kunde jag inte heller g&oumlra n&aringgra uttalanden om spr&aringkets egenskaper. Jag kom dock på min praktik i kontakt med projektet NETSim som verkade ha en del positiva erfarenheter av spr&aringket. Denna bakgrund har dock inte p&aringverkat mig i mitt arbete med att samla in empiriska erfarenheter av Erlang. Den har snarare v&aumlckt en &oumlkad nyfikenhet f&oumlr att verkligen unders&oumlka vad som &aumlr den allm&aumlnna bilden av Erlang.

    2.2 Erfarenheter

    Den bakgrund och de kunskaper som jag har inom rapportens omr&aringde h&aumlrstammar till stor del fr&aringn den systemvetenskapliga linjen och min praktik som gjordes v&aringren 1994.
    Jag har ingen stor erfarenhet av deklarativa programspr&aringk. Det som jag visste om Erlang sedan tidigare h&aumlrstammar fr&aringn min praktik på Ericsson Infocom Consultants, d&aumlr jag bl.a. ansvarade f&oumlr testa en AXE-simulator som var skriven i Erlang. Det &aumlr dessa kunskaper och erfarenheter som utg&oumlr min referensram.




    3. Kunskapsanalys


    3.1 Kunskapsinventering

    Innan unders&oumlkningen kunde b&oumlrja gjorde jag en kunskapsinventering. Denna bestod i att jag aktivt s&oumlkte efter litteratur som ber&oumlrde problemomr&aringdet. Den litteratur som fanns att få var fr&aumlmst utdrag ur olika tidskrifter m.m. D&aumlrf&oumlr s&oumlkte jag &aumlven efter litteratur på internet med viss framg&aringng.
    Problemet med att finna litteratur på detta omr&aringde &aumlr att det inte har skrivits s&aumlrskilt mycket om erfarenheter av Erlang. D&aumlrf&oumlr &aumlr mitt arbete lite av ett pionj&aumlrarbete på omr&aringdet.

    3.2 Kunskapsbehov

    F&oumlr att skaffa mig den f&oumlr-f&oumlrst&aringelse och de kunskaper som skulle beh&oumlvas f&oumlr att slutf&oumlra rapporten så var jag tvungen att ta hj&aumllp av tillg&aumlnglig litteratur inom omr&aringdet. Den litteratur som fr&aumlmst avses behandlar grundl&aumlggande begrepp inom deklarativa programspr&aringk men &aumlven strategier f&oumlr att kunna utv&aumlrdera effekterna av inf&oumlrandet av ett programspr&aringk.




    4. Programvarukrav inom telekommunikationsindustrin

    "Telekommunikationsindustrin &aumlr h&oumlgst beroende av programvara. Utvecklingen och underh&aringllet av programvara st&aringr f&oumlr en mycket stor del av ett systems kostnader.
    Det &aumlr d&aumlrf&oumlr v&aumlsentligt att produktiviteten i programvarudesignen f&oumlrb&aumlttras med den allra senaste tillg&aumlngliga teknologin."
    Bjarne D&aumlcker [ 8 ]


    Telefonv&aumlxlar &aumlr komplexa och dyra installationer. Det kr&aumlvs m&aringnga anst&aumlllda som programmerar under mycket l&aringng tid, f&oumlr att utveckla programvara till ett telekommunikationsv&aumlxelsystem. Dessa system har en unik kombination av problem/sv&aringrigheter som m&aringste bem&aumlstras. Egenskaper hos programvara inom telekommunikationsindustrin &aumlr bl.a.:

    Komplexitet
    Typiska system inneh&aringller flera miljoner rader k&aumlllkod i imperativa spr&aringk .L&aringng utvecklingstid
    Komplexiteten g&oumlr att det tar l&aringng tid att utveckla programvara inom detta omr&aringde.

    Distribution
    V&aumlxelsystem f&oumlr telekommunikation styrs ofta av m&aringnga olika processorer. Regionala processorer exekverar kritiska realtidsuppgifter medan centrala processorer hanterar komplex telefonlogik .

    Samtidighet
    Ett stort telefonv&aumlxelsystem kan ha flera tusen telefonsamtal ig&aringng samtidigt. Samtidigt som en telefonv&aumlxel hanterar alla telefonsamtal, skall det vara m&oumljligt att utf&oumlra operationer och underh&aringll på den. Det kan vara flera tusen eller till och med hundratusen tals parallella processer i programvaran till ett v&aumlxelsystem. Eftersom det &aumlr m&aringnga processer samt att dessa &aumlr dynamiska så m&aringste tiden f&oumlr att skapa och avl&aumlgsna processer vara liten.

    L&aringng livstid
    Ett telefonv&aumlxelsystem &aumlr ett system som kommer att anv&aumlndas under l&aringng tid.
    Programkoden i ett system &aumlndras m&aringnga g&aringnger under dess "livstid" f&oumlr att bl.a. f&oumlr r&aumlttning av fel men &aumlven f&oumlr att m&oumlta nya krav och ny funktionalitet.

    Realtid
    Mycket i en telefonv&aumlxel m&aringste utf&oumlras inom en viss tid efter det att en handling har p&aringb&oumlrjats. Det f&aringr det inte f&oumlrekomma f&oumlrdr&oumljningar i programvaran.

    &Oumlppna system
    Det m&aringste vara m&oumljligt att l&aumlgga till andra mjukvarukomponenter till applikationerna. Vidare m&aringste systemet fungera med andra mjukvarukomponenter som till exempel databaser, grafiska gr&aumlnssnitt, kommunikation m.m.

    Robusthet.
    Ett telefonv&aumlxelsystem m&aringste kunna fungera och vara drifts&aumlkert under en l&aringng tid. D&aumlrf&oumlr m&aringste b&aringde h&aringrd- och mjukvara vara ok&aumlnsliga f&oumlr fel och driftst&oumlrningar. Det m&aringste &aumlven vara m&oumljligt att byta programvaran i ett v&aumlxelsystemet under drift utan att man beh&oumlver stoppa systemet.




    5. Imperativa/ deklarativa spr&aringk

    Alla programspr&aringk kan delas in i två grupper imperativa och deklarativa (se bild 1). De imperativa spr&aringken som Fortran och C, utm&aumlrks av att syntaxen best&aringr av kommandon. I de deklarativa spr&aringken formulerar programmen i st&aumlllet de regler som g&aumlller f&oumlr det problem som skall l&oumlsas. Deklarativa spr&aringk delas i sin tur in i funktionella spr&aringk och logikspr&aringk.


    Bild 1: Programspr&aringkens indelning i kategorier.

    Dessa "programfamiljer" har b&aringde olika egenskaper och struktur j&aumlmf&oumlrt med varandra. Problemet med imperativa spr&aringk &aumlr de repeterande och stegvisa ber&aumlkningarna som sker av variabler samt variablernas tilldelning till minnesplatserna. M&aringnga g&aringnger finns det ingen anledning f&oumlr programmeraren att befatta sig med detaljer på denna maskinn&aumlra nivå.

    Imperativa spr&aringk &aumlr h&aringrt bundna till datorns arkitektur f&oumlr att kunna utf&oumlra ber&aumlkningar medan deklarativa spr&aringk i grunden bygger på en typ av matematisk formalism som inte &aumlr lika k&aumlnslig f&oumlr datorns arkitektur. Imperativa programspr&aringk har d&aumlrf&oumlr oftast en l&aringg abstraktionsnivå j&aumlmf&oumlrt med deklarativa programspr&aringk.Det finns &aumlven begr&aumlnsningar i en del av dessa programspr&aringk n&aumlr man beh&oumlver implementera realtidssystem. Spr&aringk som C och C++ anv&aumlnds ofta f&oumlr att implementera denna typ av system, men eftersom dessa &aumlr sekventiella programspr&aringk (d.v.s. exekveringen sker sats f&oumlr sats) så m&aringste man antingen ha ett operativsystem som st&oumldjer samtidighet eller funktioner i programspr&aringket som kan hantera detta.

    De senaste &aringrens diskussion om svagheterna i imperativa programspr&aringk, har resulterat i ett tilltagande intresse f&oumlr så kallade deklarativa programspr&aringk. Dessa spr&aringk skiljer sig en hel del fr&aringn de mer traditionella programspr&aringkens7 uppbyggnad. De deklarativa spr&aringkens uppbyggnad och konstruktion medf&oumlr m&aringnga f&oumlrdelar j&aumlmf&oumlrt med imperativa spr&aringk.Exempel på f&oumlrdelar som deklarativa programspr&aringk har:
  • Kraftig och uttrycksfull syntax
  • H&oumlg abstraktionsnivå
  • Parallell evaluering

  • Ett av de starkaste argumenten f&oumlr deklarativa programspr&aringk anses vara den automatiska minneshanteringen. Programmeraren beh&oumlver inte sj&aumllv allokera minne och h&aringlla reda på eventuella minnesl&aumlckor. Pekare existerar inte. Vad som också &aumlr utm&aumlrkande f&oumlr delm&aumlngden funktionella spr&aringk &aumlr m&oumljligheterna att skapa generella funktioner med listor som kan inneh&aringlla element av vilken typ som helst. Dessa egenskaper har gjort att man under m&aringnga &aringr forskat om programspr&aringk inom detta omr&aringde. I Sverige har detta arbete resulterat i programspr&aringket Erlang fr&aringn Ellemtel och H fr&aringn Carlstedt Elektronik AB [ 4 ]. Spr&aringket H f&oumlrsvann så sm&aringningom medan Erlang verkar vara ett programspr&aringk på frammarsch.

    De funktionella programspr&aringken lider dock av ett "image- problem". L&aumlnge har dessa spr&aringk ansetts som l&aringngsamma och ineffektiva, n&aringgot som de fortfarande, och delvis of&oumlrtj&aumlnt, f&aringr dras med.




    6. Bakgrunden till Erlang

    Utvecklingen av programvara st&aringr f&oumlr den st&oumlrsta delen av designkostnaden f&oumlr Ericssons produkter. Det har exempelvis skrivits 62 miljoner rader k&aumlllkod f&oumlr AXE-10 [ 25 ]. Att minska kostnaderna f&oumlr programvarudesignen, f&oumlrb&aumlttra kvaliteten och korta ner utvecklingstiden har d&aumlrf&oumlr varit viktiga m&aringl f&oumlr programvaruforskningen inom Ericsson.

    I str&aumlvan efter effektivare programspr&aringk som m&oumlter de krav som finns inom telekommunikationsindustrin så har datalogilaboratoriet på Ericssons och Telias sam&aumlgda bolag Ellemtel, utvecklat Erlang. Spr&aringket d&oumlptes efter den danske matematikern Agner Krarup Erlang (1878-1929), vars pionj&aumlrinsatser inom modern teletrafikteori &aumlven medverkat till att Erlang blivit en m&aringttenhet inom telefonin, men namnet kan &aumlven tydas som en f&oumlrkortning av "Ericsson Language".

    Erlang f&oumlrenar två olika programspr&aringkstraditioner: deklarativa spr&aringk, som representerar utvecklingen av traditionella h&oumlgniv&aringspr&aringk och realtidsspr&aringk, som representerar specialiserade spr&aringk f&oumlr styrsystem i realtid.


    Bild 2: Erlangs influenser.


    Erlang anv&aumlndes f&oumlrst inom Ericsson projekt f&oumlr att skriva realtidsprogram f&oumlr styrning av bl.a. telefonv&aumlxlar. Spr&aringket riktades till telekommunikationsindustrin men &aumlr ett generellt programspr&aringk som passar f&oumlr m&aringnga typer av applikationer.




    7. Beskrivning av Erlang

    Det karakteristiska f&oumlr Erlang &aumlr att det &aumlr ett funktionellt spr&aringk med st&oumld f&oumlr parallella processer. Sj&aumllva koden p&aringminner lite om Lisp utan parenteser, medan parallellismen har h&aumlmtat inspiration fr&aringn spr&aringk som Ada och Modula (se bild 2). Det &aumlr processerna som utg&oumlr den b&aumlrande enheten i Erlang. Spr&aringket l&aumlmpar sig b&aumlst f&oumlr realtidstill&aumlmpningar med svarstider på 5-15 ms och stora m&aumlngder parallella processer. Processhanteringen har med andra ord prioriterats: tiden f&oumlr att avbryta en process och starta en annan har h&aringllits kort. F&oumlr att inte anv&aumlnda mer minne &aumln n&oumldv&aumlndigt kan processer v&aumlxa och krympa efter behov. Processerna kommunicerar med varandra genom att skicka meddelanden.

    F&oumlr att underl&aumltta arbetet med programkonstruktionen så kan programkoden delas upp i moduler och &aumlven spridas ut &oumlver flera olika datorer. En egenskap som spr&aringket har &aumlr att det kan f&oumlrena olika typer av h&aringrd- och mjukvara med varandra. Spr&aringket kan &aumlven kommunicera med program som &aumlr skrivna i andra programspr&aringk [ 23 ]. Erlang har en halvintepreterande kod, d.v.s. samma bin&aumlrkod kan anv&aumlndas i flera olika arkitekturer. Detta g&oumlr att datorer av olika m&aumlrken och med olika operativsystem kan tillsammans k&oumlra samma Erlang program utan att n&aringgra kodf&oumlr&aumlndringar eller omkompileringar beh&oumlver g&oumlras.

    En egenskap som konstrukt&oumlrerna efterstr&aumlvade hos Erlang var robusthet. D&aumlrf&oumlr har man f&oumlrs&oumlkt att eliminera vanliga orsaker till fel och minnesl&aumlckor. Destruktiva operationer &aumlr exempelvis inte till&aringtna, d.v.s. en variabel som tilldelas ett v&aumlrde kan inte tilldelas ett nytt v&aumlrde. Spr&aringkets storlek, d.v.s. dess syntax &aumlr liten och mycket kraftfull. Alla funktioner som inte anses n&oumldv&aumlndiga har tagits bort. Ingenting kan g&oumlras på mer &aumln ett s&aumltt: upprepningar m&aringste till exempel g&oumlras rekursivt - det finns inget st&oumld f&oumlr iteration.
    Erlang &aumlr konstruerat så att det skall vara m&oumljligt att byta ut programkod i ett program under exekvering. Detta &aumlr ett viktigt krav på ett programspr&aringk inom telekommunikationsindustrin, d&aumlr man inte kan avbryta ett exekverande system f&oumlr att byta programvara. Spr&aringket st&oumldjer &aumlven distribution av programvara som k&oumlrs på olika n&aumltverk och med olika typer av datorer. Erlang finns f&oumlr ett dussintal olika programplattformar. Exempel på tillg&aumlngliga plattformar &aumlr: UNIX, DOS, Windows NT, QNX och Macintosh.




    8. Projekten

    Denna studie bygger på intervjuer fr&aringn sex olika projekt inom Ericsson som har anv&aumlnt sig av Erlang i n&aringgot utvecklingsprojekt. Projekten har det gemensamt att de snart skall avslutas eller nyligen har avslutats. De &aumlr alla projekt inom telekommunikationsomr&aringdet. De sex projekten kommer att presenteras punktvis med en inledande beskrivning av verksamhetsomr&aringde, allm&aumln information om projektgruppen samt vad det &aumlr f&oumlr typ av produkt som har utvecklats. D&aumlrefter kommer en genomg&aringng av de erfarenheter som projektet har av Erlang samt en redog&oumlrelse f&oumlr i vilken grad spr&aringkets egenskaper har p&aringverkat projektet.


    8.1 EBC IsoEthernet


    8.1.1 Projektbeskrivning
    Den produkt som detta projekt har utvecklat &aumlr en v&aumlxel f&oumlr att kunna hantera stora m&aumlngder information som skickas &oumlver bredband. Informationen kan skickas i realtid &oumlver Ethernet kopplingar. Exempel på anv&aumlndningsomr&aringden &aumlr bl.a. videokonferenser eller &oumlverf&oumlring av r&oumlntgenbilder mellan olika sjukhus. Projektet har c:a 28 anst&aumlllda och best&aringr av tre grupper. Den grupp som arbetar med Erlang har 12-15 anst&aumlllda.

    Projektet startades 1993 med att ta fram en prototyp. Denna prototyp
    gjordes i Erlang. Det unders&oumlkta projektet bygger på det tidiga prototyparbetet som gjordes. Det &aumlr bara i en av projektgrupperna som man har anv&aumlnt sig av Erlang som implementationsspr&aringk. Ut&oumlver erlangkoden så finns det &aumlven lite C-kod i denna applikation. Den anv&aumlnds f&oumlr att matcha h&aringrdvaran och f&oumlr att komma ut utanf&oumlr Erlang f&oumlr att koppla ihop applikationen med andra spr&aringk.

    Applikationen best&aringr av c:a 25 000-30 000 rader Erlangkod i den f&aumlrdiga produkten.
    Den programkonstrukt&oumlr som jag intervjuade, Stefan Lundberg, har c:a 13 veckors erfarenhet av att programmera i Erlang. Tidigare har han kommit i kontakt med spr&aringk som till exempel Plex och C++.


    8.1.2 Erfarenheter
    Att skriva koden har g&aringtt v&aumlldigt fort, medan testningen har tagit l&aringng tid. Detta har berott på bl.a. att man m&aringste ta h&aumlnsyn till den plattform som utgjorde grunden f&oumlr denna applikation. I arbetet har man varit mycket noga med att specificera gr&aumlnssnittet mellan de olika programmodulerna. Trots detta har man haft en del problem med gr&aumlnssnitten mellan de olika modulerna.
    Detta berodde till stor del på att uppdateringen av de s.k. gr&aumlnssnittsdokumenten (de dokument som specificerar programmodulernas gr&aumlnssnitt) inte alltid n&aringdde ber&oumlrda personer som de skulle. Den metodik som har anv&aumlnts i analys- och designfaserna har varit objektorienterad. I implementationsskedet har man dock valt att inte f&oumlra &oumlver objekten fr&aringn den objektorienterade designl&oumlsningen till processer i Erlang, i n&aringgon st&oumlrre utstr&aumlckning

    Den stora f&oumlrdelen med Erlang &aumlr att det &aumlr l&aumltt att l&aumlra sig och att anv&aumlnda. Man kommer snabbt ig&aringng med att b&aringde skriva och prova funktioner. Andra faktorer som &aumlr viktiga &aumlr att man inte beh&oumlver deklarera datatyper och att pekare saknas. Applikationen byggs upp i flera samverkande moduler som var och en utf&oumlr en avgr&aumlnsad uppgift. D&aumlrigenom blir modulerna l&aumltta att testa. Det faktum att det g&aringr snabbt att bygga upp "stubbkod" och att spr&aringket &aumlr flexibelt g&oumlr att det l&aumlmpar sig mycket bra f&oumlr prototyping.

    "Det g&aringr fort n&aumlr det &aumlr ren Erlangkod och man inte beh&oumlver ta h&aumlnsyn till andra program plattformar".
    Stefan Lundberg, EBC IsoEthernet

    En annan erfarenhet av spr&aringket var att det gick så snabbt att utveckla en prototyp i Erlang, eller som Stefan sa:

    " en vecka sedan var det f&aumlrdigt".
    Stefan Lundberg, EBC IsoEthernet

    En nackdel som spr&aringket har &aumlr att syntaxfel uppt&aumlcks f&oumlrst vid exekveringen av applikationen. Detta h&aumlnger samman med att man inte beh&oumlver deklarera datatyperna innan man kompilerar applikationen. Kompileringen uppt&aumlcker inte om variabler ej &aumlr deklarerade. Detta upplevs stundtals som besv&aumlrligt. Man skulle vilja att enklare fel uppt&aumlcktes redan vid kompileringstillf&aumlllet. Vidare var det besv&aumlrligt att koppla ihop Erlang med programkod i C.
    På fr&aringgan om vilka projekt som Erlang passar b&aumlst f&oumlr s&aumlger man att Erlang har passat detta projekt bra och att man anser att projektet &aumlr av medelstorlek. F&oumlr &oumlvrigt anser man att Erlang passar bra f&oumlr realtidsapplikationer och att man inte kan komma på n&aringgra typer av projekt eller applikationer som Erlang inte skulle passa f&oumlr.


    8.1.3 J&aumlmf&oumlrelse med andra programspr&aringk
    Det som skiljer Erlang fr&aringn C och C++ &aumlr bl.a. att det medf&oumlr ett helt annorlunda tankes&aumltt. Data h&oumlr till en process och alla andra processer kan komma &aringt dessa data. En annan sak &aumlr att man inte m&aringste deklarera de datatyper som man anv&aumlnder i Erlang. I C++ uppt&aumlcker man alla icke logiska fel redan vid kompileringen, på grund av det &aumlr ett starkt typat spr&aringk. Vidare f&aringr man få exekveringsfel i C++ medan man ist&aumlllet f&aringr fler kompileringsfel.

    I Erlang &aumlr dessa f&oumlrh&aringllandena omv&aumlnda. Enligt Stefan &aumlr "felen l&aumlttare att hitta vid kompileringen &aumln vid exekveringen". F&oumlrdelen med C++ &aumlr annars att det &aumlr objektorienterat vilket Erlang inte &aumlr. Anv&aumlnder man sig av C++ i ett projekt så st&aumlller det dock h&oumlgra krav på styrning i stora projekt.

    " Den erfarenhet vi har av Erlang &aumlr att det har fungerat bra f&oumlr produkten".
    Stefan Lundberg, EBC IsoEthernet


    8.1.4 Programspr&aringkets betydelse
    Spr&aringkets betydelse f&oumlr den totala utvecklingstiden i projektet &aumlr inte så stor. Man programmerar inte så mycket j&aumlmf&oumlrt med de &oumlvriga momenten i projektarbetet. Det som tar l&aringng tid &aumlr att s&aumltta sig in i problemet och att unders&oumlka vad det &aumlr som skall g&oumlras.
    Det g&aringr dock snabbt att skriva Erlangprogram. N&aumlr man ber&aumlknade utvecklingstiden f&oumlr den prototyp som man konstruerade f&oumlrsta g&aringngen så trodde man att det skulle ta mycket l&aumlngre tid &aumln vad det i sj&aumllva verket gjorde.

    I de senare projekten justerade man faktorn f&oumlr ber&aumlkning av utvecklingstiden så att den skulle st&aumlmma b&aumlttre &oumlverens med anv&aumlndandet av Erlang. På fr&aringgan om man skulle kunna t&aumlnka sig ett annat programspr&aringk f&oumlr projektet så s&aumlger Stefan att det skulle vara sv&aringrt att t&aumlnka sig eftersom man m&aringste bygga vidare på en plattform &aumlr gjord i Erlang.


    8.2. EBC/MD


    8.2.1 Projektbeskrivning
    Detta projekt har utvecklat en organkortssimulator (simulator f&oumlr kretskort) f&oumlr att kunna testa applikationsprogramvaran i telefonv&aumlxlen MD110. Den delprodukt som har konstruerats med hj&aumllp av Erlang heter GDS - General Deviceboard Simulator. F&oumlr att l&oumlsa programvarans tekniska anpassning mot h&aringrdvaran har man &aumlven anv&aumlnt sig av programspr&aringket C. Syftet med simulatorn &aumlr i f&oumlrsta hand att testa applikationsprogramvaran i telefonv&aumlxeln MD110 så att telefonv&aumlxeln har r&aumltt funktionalitet och beteende mot organkorten. Produktnamnet f&oumlr produkten &aumlr GDS-MDSim.

    Detta &aumlr ett mindre projekt med 6-8 projektmedlemmar. Av projektmedlemmarna var det en person som programmerade på heltid i Erlang. Den delprodukt som &aumlr konstruerad i spr&aringket omfattar c:a 10 000 rader k&aumlllkod och ett par hundra rader C-kod. Simulatorn &aumlr f&oumlr n&aumlrvarande fr&aumlmst avsedd f&oumlr internt bruk inom Ericssonkoncernen.
    En av de fr&aumlmsta anledningarna till att man inom projektet valde Erlang var att en av projektdeltagarna hade kommit i kontakt med spr&aringket på en kurs n&aumlr han studerade på Kungliga tekniska h&oumlgskolan (KTH) i Stockholm. Vidare fanns det en uttalad nyfikenhet inf&oumlr detta programspr&aringk, men &aumlven nya programspr&aringk i st&oumlrsta allm&aumlnhet.
    Man ville testa programspr&aringket f&oumlr att se om det var m&oumljligt att anv&aumlnda som implementationsspr&aringk. Den intervjuade personen har två &aringrs erfarenhet av Erlang och har tidigare bl.a. programmerat i: Pascal, C, Assembler och lite Ada.


    8.2.2 Erfarenheter
    Spr&aringket har en m&aumlngd positiva egenskaper. En av f&oumlrdelarna &aumlr att det &aumlr ett kompakt spr&aringk med en liten syntax. Vidare anser man att spr&aringkets abstraktionsnivå g&oumlr att det &aumlr n&aumlra fr&aringn tanke till implementation. Detta g&oumlr att det g&aringr fort och enkelt att få ihop ett program. Detta anser man &aumlven har avspeglats i projektets arbete.

    "Det har inte beh&oumlvts mer &aumln en person som jobbade med Erlang. Hade vi anv&aumlnt n&aringgot annat implementationsspr&aringk så hade det nog beh&oumlvts mer folk" -
    Anders Romin, EBC/MD

    Enligt Anders så beror detta på att Erlang &aumlr ett litet spr&aringk och att man leds in på r&aumltt sp&aringr beroende på spr&aringkets enkla syntax. En annan av erfarenheterna man hade var att den del av koden som var gjord i Erlang var mer stabil och felfri &aumln den del som var konstruerad i programspr&aringket C. Det har varit v&aumlldigt lite fel i programkoden och man har endast haft ett st&oumlrre fel sedan produkten sl&aumlpptes. En annan sida av spr&aringket &aumlr att det har en mycket bra felhantering.
    De negativa egenskaper som spr&aringket besitter &aumlr framf&oumlrallt att det tar l&aringng tid att starta upp programmilj&oumln. En annan nackdel &aumlr att de applikationer som skapas beh&oumlver anv&aumlnda sig av programspr&aringkets miljö f&oumlr att kunna exekvera. Detta inneb&aumlr att projektet &aumlven m&aringste s&aumllja en Erlanglicens till eventuella kunder.

    Man anser att Erlangs styrka fr&aumlmst passar f&oumlr att l&oumlsa h&aumlndelseorienterade problem eller applikationer som involverar realtidskrav. Databasapplikationer, anv&aumlndarprogram och små applikationer passar spr&aringket mindre bra f&oumlr. D&aumlremot anser man att spr&aringket passar b&aringde f&oumlr stora och små projekt. Vad betr&aumlffar programutvecklingstiden, d.v.s. den tid det tog f&oumlr att konstruera applikationen så anser man att denna f&oumlrmodligen har blivit kortare &aumln om n&aringgot annat spr&aringk hade anv&aumlnts.

    De erfarenheter man har g&oumlr att man i ett framtida projekt g&aumlrna anv&aumlnder sig av Erlang igen. Dock skulle man kanske byta ut vissa delar som t.ex. grafikdelen och f&oumlrs&oumlka g&oumlra n&aringgot i Xview ist&aumlllet.


    8.2.3 J&aumlmf&oumlrelse med andra programspr&aringk
    Den st&oumlrsta skillnaden mellan detta programspr&aringk och andra spr&aringk &aumlr tankes&aumlttet. I Erlang beh&oumlver man bara t&aumlnka ut vad som skall g&oumlras och inte hur detta skall gå till. Vidare så finns det inga globala variabler. Ett annat utm&aumlrkande drag &aumlr att alla variabler &aumlr "konstanter" d.v.s det g&aringr endast att tilldela en variabel ett v&aumlrde en g&aringng.


    8.2.4 Programspr&aringkets betydelse
    Eftersom detta projekt bygger på en plattform som &aumlr gjord i Erlang sedan tidigare så har valet av programspr&aringk en stor betydelse. Det hade som vi ser det inte varit m&oumljligt att anv&aumlnda n&aringgot annat programspr&aringk till detta projektet. Programspr&aringket kan d&aumlrf&oumlr ha stor betydelse n&aumlr man bygger vidare på redan befintliga plattformar. Annars har kanske valet av programspr&aringk inte allt f&oumlr stor betydelse.


    8.3. ERA-t


    8.3.1 Projektbeskrivning
    Den avdelningen som Anders Danne - Ericsson Radio Systems AB arbetar på, f&oumlrser olika aff&aumlrsomr&aringden 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&aumlnt sig av Erlang. I det f&oumlrsta projektet så var Anders med och skrev Erlangkod, medan han i de senare har varit projektledare. Dessa projekt var:

    - Cordless
    Ett av de f&oumlrsta projekten med Erlang, 1990. Erlang anv&aumlnder bl.a. i detta projektet f&oumlr att konstruera mjukvaran som sk&oumltte styrningen av Ericssons digitala och tr&aringdl&oumlsa telefonsystem: DCT900. Prototypen konstruerades på sex m&aringnader med tre man. Arbetet inkluderade en flera omskrivningar av prototypen innan man fann den b&aumlsta l&oumlsningen.

    Med hj&aumllp av Erlang gjorde man en simulator som på ett smidigt s&aumltt simulerade delar av h&aringrdvaran innan denna hade kommit på plats. N&aumlr v&aumll h&aringrdvaran kom så tog det bara två veckor att få produkten f&aumlrdig. Detta hade inte g&aringtt utan Erlang.

    - Codit
    En slags radiov&aumlxel. Detta projekt var ett s.k. RACE projekt. - TelefoniserverEn applikation som bestod av 25 000 rader Erlangkod.Anders f&oumlrsta kontakt med Erlang var f&oumlr 10 &aringr sedan. Det var genom TUP (tekniskt utskott f&oumlr programvara) f&oumlr representanter fr&aringn Ericssons olika delar som han kom i kontakt med Erlang. I detta tekniska utskott satt Bjarne D&aumlcker (en av grundarna till Erlang tillsammans med bl.a. Mike Williams, Robert Virding och Joe Armstrong) som ordf&oumlrande. Allt sedan dess har han varit intresserad av spr&aringket och har de senaste fem &aringren aktivt propagerat f&oumlr Erlang i sina projekt. Anders &aumlr f&oumlr &oumlvrigt allm&aumlnt nyfiken och intresserad av ny teknologi och nya programspr&aringk. Han har tidigare bl.a. programmerat i Prolog, Assembler, Pascal och EriPascal. Han tror att Erlang kommer att komma in och anv&aumlndas allt mer och mer inom Ericssonkoncernen. Anders erfarenhet &aumlr dock att det tar l&aringng tid att f&oumlra in ny teknologi i en organisation. Enligt Anders så fanns det heller inga alternativa programspr&aringk som han skulle kunna t&aumlnka sig att anv&aumlnda i dessa tre projekt.


    8.3.2 Erfarenheter
    Hans erfarenheter av spr&aringket &aumlr att det blir mindre kod att skriva j&aumlmf&oumlrt med andra programspr&aringk. Erlang &aumlr &aumlven l&aumltt att l&aumlra sig och har en h&oumlg abstraktionsnivå. Den h&oumlga abstraktionsniv&aringn g&oumlr att man inte beh&oumlver bekymra sig f&oumlr implementationsdetaljer som leder till en massa trassel.

    Att spr&aringket har en h&oumlg abstraktionsnivå ser han &aumlven som en m&oumljlig orsak till problem. F&oumlr att kunna programmera i ett spr&aringk som har en h&oumlg abstraktionsnivå så m&aringste man kunna f&oumlrstå detta t&aumlnkandet. Anders refererar till erfarenheter fr&aringn IBM i USA [ 4 ] som visar att det inte alltid r&aumlcker med utbildning f&oumlr att man skall l&aumlra sig ett programspr&aringk. Dessa erfarenheter gjordes på IBM d&aumlr man i mitten på &aringttiotalet 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 &aumlr att det underl&aumlttar om programspr&aringket som man anv&aumlnder sig av, &aumlr konstruerat f&oumlr att hantera realtid n&aumlr man skall skriva realtidstill&aumlmpningar. Erlang har &aumlven en interaktiv programmiljö som &aumlr mycket smidig. Det g&aringr fort att prova ut nya saker.

    Enligt Anders så har Erlang gjort projekten mer produktiva. Projekten beh&oumlver f&aumlrre personer och mindre tid &aumln tidigare eftersom man inte beh&oumlver producera lika mycket kod f&oumlr att uppnå samma funktionalitet.

    "Erlang &aumlr ett lyft f&oumlr produktiviteten." -
    Anders Danne, Era-t

    Mindre kod g&oumlr också att det blir mindre fel.

    "Det &aumlr nog lika m&aringnga fel per antal rader som det var tidigare, dock blir det f&aumlrre rader kod nu, vilket leder till att det blir f&aumlrre fel totalt sett &aumln vad det var tidigare."
    Anders Danne, Era-t

    De omr&aringden som passar spr&aringket b&aumlst &aumlr telefonv&aumlxlar och applikationer f&oumlr olika former av tj&aumlnster. Verktyg f&oumlr att utveckla programvara och testutrustningar passar spr&aringket också mycket bra f&oumlr. Vad det betr&aumlffar projektens storlek så s&aumlger Anders:

    "Det finns ingen gr&aumlns f&oumlr hur stora projekt som kan anv&aumlnda sig av Erlang, projekten blir mindre"
    Anders Danne, Era-t

    På fr&aringgan om vilken typ av till&aumlmpningar som Erlang inte passar f&oumlr n&aumlmner han "tv&aumlttmaskiner" med enklare logik. Med detta menar han att det m&aringste vara lite mer komplicerade l&oumlsningar f&oumlr att det skall vara l&oumlnt att anv&aumlnda sig av Erlang. Windowsapplikationer på PC passar inte heller så bra eftersom man inte kan få fram samma typ av gr&aumlnssnitt. Personligen &oumlnskar han sig &aumlven att det fanns en bra PC/Windowsimplementering med en miljö liknande VisualBasic.


    8.3.3 J&aumlmf&oumlrelse med andra programspr&aringk
    Till skillnad fr&aringn t.ex. Plex så f&aringr man en mycket kortare utvecklingstid. En av nackdelarna med Erlang &aumlr att spr&aringket har s&aumlmre prestanda &aumln vad C t.ex. har. Erlang tar &aumlven mycket mer minne &aumln programspr&aringket C.


    8.3.4 Programspr&aringkets betydelse
    Det finns saker som har st&oumlrre betydelse f&oumlr ett projekt &aumln vad programspr&aringket i allm&aumlnhet har. Det &aumlr viktigt att veta vad man skall g&oumlra f&oumlr att ett projekt skall slå v&aumll ut. Tydliga krav och m&aringl som inte f&oumlr&aumlndras har också mycket stor betydelse. Programspr&aringket &aumlr f&oumlrst och fr&aumlmst ett verktyg som man anv&aumlnder sig av.


    8.4. ETX/B


    8.4.1 Projektbeskrivning
    Projektets m&aringl var att experimentera f&oumlr att hitta nya, snabbare v&aumlgar till att utveckla till&aumlmpningar. Till denna uppgift valde projektet Erlang. En annan viktig del i detta arbetet var att unders&oumlka arbetsmetodik. I sina experiment så utvecklade man en prototyp som utgick fr&aringn den ATM-h&aringrdvara som finns ute hos kunderna. Utifr&aringn denna utvecklades ett enklare system i Erlang f&oumlr att styra h&aringrdvaran. D&aumlrefter koncentrerade man sig på inf&oumlra funktionalitet så att kunderna sj&aumllva skulle kunna s&aumltta upp och tar ner f&oumlrbindelser via prototypen.

    Projektgruppen bestod av 4 personer som hade arbetat med Erlang i 6 m&aringnader.
    Tidigare hade man bl.a. programmerat i Plex, Ada och C.
    Den applikationen som man gjorde omfattade c:a 10 000 rader k&aumlllkod i Erlang samt 200 rader i programspr&aringket C. Det man k&aumlnde till sedan tidigare om spr&aringket var i princip att det var ett programspr&aringk som kom ifr&aringn Ericssonkoncernen.


    8.4.2 Erfarenheter
    De erfarenheter som man har f&aringtt av spr&aringket &aumlr att det &aumlr l&aumltt att utveckla program i. Detta h&aumlnger delvis samman med att man arbetar på en abstraktionsnivå d&aumlr man inte beh&oumlver bekymra sig om minnesl&aumlckor, pekare och dyl.

    " N&aumlr man har arbetat med ett spr&aringk på h&oumlg abstraktionsnivå så vill man inte gå ner en nivå f&oumlr att b&oumlrja arbeta på detaljnivå igen".
    Bo Bergstr&oumlm, ETX/B

    Man s&aumlger vidare att spr&aringket l&aumlmpar sig b&aumlst n&aumlr mer abstrakta problem skall l&oumlsas. Spr&aringket &aumlr &aumlven l&aumltt att l&aumlra sig eftersom det har en mycket begr&aumlnsad syntax. Genom att gå en fyra-dagars kurs så beh&aumlrskar man de viktigaste grunderna i spr&aringket. Man anser &aumlven att det har uppst&aringtt mindre fel i programvaran j&aumlmf&oumlrt med erfarenheter fr&aringn andra programspr&aringk. Detta tror man bero på den begr&aumlnsade syntaxen, det g&aringr inte att g&oumlra så mycket fel eftersom spr&aringket har så liten syntax. En f&oumlljd av den lilla syntaxen &aumlr &aumlven att koden blir l&aumlttare att l&aumlsa. Andra viktiga egenskaper &aumlr de parallella egenskaperna som underst&oumlds i spr&aringket, m&oumlnstermatchningen, att kunna uppgradera programvara under exekvering, plattformsoberoende, korta kompileringstider och att Erlang &aumlr ett l&oumlst typat spr&aringk.

    De nackdelar med spr&aringket som man anger har med processbegr&aumlnsningar och kapacitet att g&oumlra. Man kan endast ha 4000 processer ig&aringng samtidigt. Man ser detta mest som lite barnsjukdomar i spr&aringket. En annan detalj &aumlr avsaknaden av fels&oumlkning under drift och att bra grafiska hj&aumllpmedel saknas. Vidare st&aumlller man sig lite fr&aringgande till hur Erlang kommunicerar med andra spr&aringk &aumln C.

    Erlang l&aumlmpar sig bra f&oumlr projekt som finns på UNIX-plattformar och mindre bra f&oumlr h&aringrdvarun&aumlraprogram och program som st&aumlller h&oumlga krav på prestanda.

    Man har en upplevd k&aumlnsla av att kvaliteten i programkoden har blivit b&aumlttre då man inte l&aumlngre har n&aringgra pekarfel. Eventuellt har man &aumlven f&aringtt en kortare utvecklingstid.

    "Kodningstiden &aumlr kortare men man m&aringste fortfarande modellera"
    Bo Bergstr&oumlm, ETX/B

    Det &aumlr dock sv&aringrt att s&aumlga om man skulle v&aumllja Erlang f&oumlr ett projekt idag. Det beror lite på vad man skall g&oumlra och vad det &aumlr f&oumlr typ av applikation. D&aumlrf&oumlr &aumlr det sv&aringrt att svara på vad man skulle ha valt idag.


    8.4.3 J&aumlmf&oumlrelse med andra programspr&aringk
    Det g&aringr att g&oumlra mer i C++ och man har en st&oumlrre frihet. det &aumlr också st&oumlrre frihet att g&oumlra fel. F&oumlr m&aringnga imperativa spr&aringk m&aringste deklarera alla variabler innan man skall anv&aumlnda dem. Detta beh&oumlver man inte g&oumlra i Erlang. Man tycker &aumlven att det &aumlr l&aumlttare att g&oumlra grafik i Erlang &aumln vad det &aumlr i C++. Detta beror naturligtvis &aumlven på vilken typ av grafikpaket som man har i de olika milj&oumlerna. Det grafikpaket man har anv&aumlnt sig av heter PXW.


    8.4.4 Programspr&aringkets betydelse
    Spr&aringkets betydelse &aumlr inte så stor anser man, metoden v&aumlger tyngre. Det handlar egentligen om en kombination av metod och programspr&aringk. De sv&aringrigheterna som man hade i projektet har mest haft med metoden och g&oumlra.

    "Det &aumlr metod och spr&aringk som tillsammans borgar f&oumlr ett lyckat projekt"
    Bo Bergstr&oumlm, ETX/B


    8.5. Mobility server


    8.5.1 Projektbeskrivning
    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&aumlrdiga produkten best&aringr av 192 000 rader erlangkod i 450 moduler och 6700 rader C-kod i 26 C-moduler. K&aumlllkodens storlek &aumlr 5,7 Mb. Denna produkt m&oumljligg&oumlr f&oumlr kunden att skr&aumlddarsy avancerade f&oumlretagstj&aumlnster. Exempel på till&aumlmpningsomr&aringden &aumlr att st&oumldja radiov&aumlxlar 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&aumlr EBC gjorde applikationen medan Ellemtel utvecklade Erlang. D&aumlrf&oumlr var det också sj&aumllvklart att detta projektet skulle g&oumlras 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&oumlr Rune Berg.

    Rune har arbetat med Erlang i 14 m&aringnader. Han har tidigare programmerat i bl.a. Plex, C, C++, Pascal, Modula-2, Prolog, Miranda och Assembler.


    8.5.2 Erfarenheter
    Enligt projektledare Lennart Axelsson så har det varit minst problem med Erlang i projektet. De problem som man hade berodde ist&aumlllet på att utvecklingen delades upp mellan Sverige och USA. Detta var ett sv&aringrt politiskt beslut. H&aumlr fanns m&aringnga av de problem som uppstod. Vidare så har man haft en del problem som har berott på det ink&oumlpta operativsystem som har anv&aumlnts. Det som har gjort detta projektet sv&aringrt &aumlr att det har funnits m&aringnga nya och ok&aumlnda parametrar som till exempel ett nytt spr&aringk och en ny arkitektur, i projektet. Tidigare har man haft m&aringnga k&aumlnda parametrar. Effekten av alla dessa ok&aumlnda parametrar har blivit en psykologisk och kulturell chock. Vidare så var mycket av det tidigare prototyparbetet odokumenterat. Att f&oumlrstå arkitekturen och underliggande delar var d&aumlrf&oumlr mycket sv&aringrt.
    Vad betr&aumlffar utvecklingstiden så tror man att projektet skulle ha g&aringtt snabbare om man hade anv&aumlnt Plex ist&aumlllet. Detta beror bl.a. på att projektmedlemmarna har en mycket stor erfarenhet och kompetens av Plex sedan tidigare.

    Lennart s&aumlger att han inte &aringngrar valet av Erlang som implemetationsspr&aringk. Men han s&aumlger &aumlven att: i projektets tidiga faser hade vi inte så goda erfarenheter/kunskap som vi har idag av spr&aringket. Då hade man s&aumlkert valt n&aringgot annat mer k&aumlnt programspr&aringk (men kanske inte b&aumlttre). Hans inst&aumlllning &aumlr att ett programspr&aringk &aumlr framf&oumlrallt ett verktyg. Om man hade haft fundamenten f&aumlrdiga fr&aringn b&oumlrjan så g&aringr det snabbare med Erlang.

    Den allm&aumlnna inst&aumlllningen &aumlr annars att de som tidigare arbetade med Plex g&aumlrna forts&aumltter med Erlang. Spr&aringket &aumlr effektivt och enkelt. Vidare så anser man att spr&aringket har en stark arkitektur och att man kan g&oumlra mycket med lite kod.

    "Ett så kraftfullt spr&aringk men &aumlndå så enkelt att anv&aumlnda".
    Rune Berg, Mobility Server

    Spr&aringket &aumlr l&aumltt att komma ig&aringng med. Men att skriva bra kod kr&aumlver erfarenhet. det &aumlr viktigt att man inte sl&aumlpper programkonstrukt&oumlrer allt f&oumlr fort - s&aumlger Lennart Axelsson. Det &aumlr viktigt med utbildning och att man verkligen anv&aumlnder sig av f&oumlrdelarna med spr&aringket. Det g&aringr &aumlven fort att g&oumlra avancerade saker menar Rune. Av spr&aringkets d&aringliga sidor anger han bl.a. m&oumljligheterna att anv&aumlnda debuggern. Enligt Lennart så &aumlr sv&aringrt att hitta fel i koden. Expertkompetens kr&aumlvs menar han. Programkonstrukt&oumlren s&aumlger i sin tur att han inte har så stor behov av debuggern. En annan detalj &aumlr att det &aumlr sv&aringrt att h&aringlla reda på de specialtecken som anv&aumlnds i satserna. I vissa situationer &aumlr det sv&aringrt att veta om det skall vara kommatecken, semikolon eller punkt i en sats. Det k&aumlnns lite on&oumldigt med tre olika tecken f&oumlr samma sak.
    Erlang passar annars bra f&oumlr styrsystem och telekommunikationsapplikationer. Distribuerade system ned l&aringng k&oumlrtid passar också f&oumlr detta spr&aringk. D&aumlremot &aumlr det inte l&aumlmpligt f&oumlr typiska PC-till&aumlmpningar.
    Om Rune hade f&aringtt v&aumllja programspr&aringk igen så hade han valt Erlang till detta projektet. Han &aumlr mycket n&oumljd med spr&aringket och s&aumlger att:

    "Erlang &aumlr det b&aumlsta spr&aringk som jag har programmerat i"
    Rune Berg, Mobility Server


    8.5.3 J&aumlmf&oumlrelse med andra programspr&aringk
    Det &aumlr en stor skillnad mot andra spr&aringk. Exempel på saker som g&oumlr skiljer Erlang fr&aringn andra spr&aringk &aumlr m&oumlnstermatchningen och att rekursion anv&aumlnds f&oumlr att styra programmen och inte loopar. Vidare så kan variabler bara bindas en g&aringng och typer och listor &aumlr inbyggda i spr&aringket.


    8.5.4 Programspr&aringkets betydelse
    Valet av programspr&aringk till ett projekt &aumlr inte det viktigaste. Det viktigaste f&oumlr att ett projekt skall lyckas &aumlr att det &aumlr ett litet projekt med stabila krav och att man har n&aringgot stabilt att bygga på.
    Det f&aringr inte enbart finnas ok&aumlnda faktorer. Vidare så m&aringste utbildningen fungera i alla led samt att det finns tillr&aumlckligt med kompetenta resurser. Det &aumlr &aumlven viktigt att det inte finns k&aumlnslokonflikter inom projektgruppen. Grundarbetet och helheten &aumlr det viktigaste. Man m&aringste &aumlven t&aumlnka på att utv&aumlrdera produkter och externa leverant&oumlrer.


    8.6. NETSim


    8.6.1 Projektbeskrivning
    NETSim &aumlr en AXE-simulator som simulerar b&aringde operationer och beteende. Simulatorns fr&aumlmsta syfte &aumlr att prova TMOS-applikationer men &aumlven att tj&aumlna f&oumlr utbildning av TMOS-operat&oumlrer 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&aumlnde man inte C++ f&oumlr objektorienteringens skull utan mer som en b&aumlttre C-kompilator. Vidare var C++ koden mycket r&oumlrig efter det att m&aringnga personer hade varit inblandade i programmeringen. I denna typ av verksamhet så &aumlr det naturligt att dela upp problemen i processer. C++ l&oumlsning på samtidighet &aumlr att utnyttja UNIX processer. Detta gjorde man i den tidigare simulatorversionen men denna l&oumlsningen tog mycket tid. Den nya versionen som skulle konstrueras beh&oumlvde &aumlven ut&oumlkad funktionalitet samt kunna k&oumlras på flera olika plattformar (Solaris 1,2 och HP/UX), d&aumlrf&oumlr var det praktiskt att gå &oumlver till Erlang eftersom det har en halvintepreterande kod, d.v.s. samma bin&aumlrkod kunde anv&aumlndas i alla tre arkitekturerna.

    Projektledaren Bengt Tillman kom i f&oumlrsta g&aringngen i kontakt med Erlang på en f&oumlretags-presentation. Efter det blev han nyfiken på att prova på spr&aringket. Hela simulatorn &aumlr skriven i Erlang medan m&aringnga av kommandona &aumlr skrivna i C++ sedan tidigare. Dessutom så finns det lite C-program som sk&oumlter 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 &aringrs erfarenhet av Erlang och har tidigare bl.a. programmerat i Pascal, Lisp och C++. Bengt som har 30 &aringrs erfarenhet av programmering har bl.a. programmerat i assembler, AlgolGenius, Forth, Pascal, C++, e.t.c. Conny Forsander har 1 1/2 &aringrs erfarenhet av att programmera C++kommandon till NETSim men programmerar i Erlang sedan 3 m&aringnader tillbaka.


    8.6.2 Erfarenheter
    Erlang som produkt &aumlr en mycket stabil och tillf&oumlrlitlig. Under den l&aringnga tid som man har anv&aumlnt Erlang så har man endast r&aringkat ut f&oumlr ett enda fel. En av de stora f&oumlrdelarna med Erlang &aumlr att man inte beh&oumlver deklarera alla variablerna som skall anv&aumlnda. Man anser &aumlven att det har uppst&aringtt f&aumlrre programvarufel &aumln vad man tidigare r&aringkade ut f&oumlr. Vad som också &aumlr utm&aumlrkande &aumlr att man inte l&aumlngre f&aringr n&aringgra minnesfel till skillnad fr&aringn spr&aringk som C++. Eftersom det inte finns n&aringgra pekare så kan man inte heller få n&aringgra pekarfel.

    Vad det betr&aumlffar programvarufel s&aumlger Conny Forsander:

    "Jag gjorde v&aumlrre fel i C++ som samtidigt var sv&aringrare att hitta"
    Conny Forsander, NETSim

    Andra &oumlvergripande erfarenheter &aumlr att det &aumlr enkelt att konstruera en klient/server-applikation med hj&aumllp av Erlang. Vidare så har spr&aringket en kraftfull felhantering och bra process-styrning. En annan viktig egenskap &aumlr att man befinner sig på en mycket h&oumlgre abstraktionsnivå &aumln andra programspr&aringk.

    Det k&aumlnns som man lyfter sig en nivå upp och kan koncentrera sig på att l&oumlsa problemen ist&aumlllet f&oumlr att brottas med syntaxen.
    Johan Garpendahl, NETSim

    Det finns vidare s&aringdana faktorer som b&aringde &aumlr f&oumlr och nackdelar. Vad det betr&aumlffar grafik och grafiska hj&aumllpmedel så har vi delvis saknat detta. Eftersom Erlang &aumlr ett halvintepreterande spr&aringk så g&oumlr det att alltid kommer att gå lite l&aringngsammare &aumln andra spr&aringk. Johan Garpendahl s&aumlger &aumlven:

    "Upphovspersonerna på Ellemtel h&aumlvdar att Erlang &aumlr 5 g&aringnger så l&aringngsamt som C/C++ vid j&aumlmf&oumlrelse sats f&oumlr sats. Men vid kommunikation mellan processer så m&aumlrker man inte att det skulle gå l&aringngsammare. G&oumlr man bara en bra programdesign så &aumlr prestanda inga problem"
    Johan Garpendahl, NETSim

    En annan detalj som kan vara b&aringde bra och d&aringlig &aumlr att allting i spr&aringket inte &aumlr f&aumlrdigutvecklat. Detta ger programvarukonstrukt&oumlren en m&oumljlighet att f&oumlr&aumlndra och p&aringverka spr&aringkets utveckling.

    Att ett programspr&aringk inte &aumlr helt f&aumlrdigutvecklat kan naturligtvis &aumlven ses som en nackdel i detta sammanhang. Ett problem som man har haft i projektet har varit att det inte g&aringr att &oumlppna mer &aumln 64 (ev 256) filer på en g&aringng. Denna begr&aumlnsningen s&aumltts dock inte av Erlang utan beror ist&aumlllet på operativsystemet (UNIX).

    Vad det betr&aumlffar syntaxen i spr&aringket så upplevs anv&aumlndningen av komma, semikolon och punkt stundtals inkonsekvent. Vidare så borde de inbyggda funktionerna vara b&aumlttre dokumenterade. Man anser vidare att Erlang kan passa till de flesta typer av applikationer bortsett fr&aringn "sifftertuggande applikationer". Vad det betr&aumlffar antalet fel i programkoden så tror man att det blir mindre fel med Erlang j&aumlmf&oumlrt med andra spr&aringk. Det beror bl.a. på att det &aumlr sv&aringrt att g&oumlra slarvfel i Erlang.

    "En bra programmerare skriver bra kod i vilket spr&aringk som helst, en d&aringlig programmerare skriver d&aringlig kod i vilket spr&aringk som helst."
    Johan Garpendahl, NETSim

    Man har vidare en klar uppfattning om att programspr&aringket kan p&aringverka den totala utvecklingstiden. Den f&oumlrsta versionen av simulatorn tog 12 m&aringnader att g&oumlra. Den andra versionen som skrevs om helt fr&aringn b&oumlrjan i Erlang tog 6 m&aringnader att g&oumlra med ut&oumlkad funktionalitet.

    Man fick då &aumlven en klientserverapplikation som hade st&oumld f&oumlr flera plattformar (Solaris 1,2 och HP/UX) på k&oumlpet. Man slapp dock att jaga en massa folk som hade de r&aumltta kunskaperna i arbetet med den andra versionen av simulatorn. Vidare så anv&aumlnde man sig av en del av den tidigare designen. Bortsett fr&aringn detta så fick man b&oumlrja om helt fr&aringn b&oumlrjan.

    På fr&aringgan om Johan skulle kunna t&aumlnka sig n&aringgot annat programspr&aringk till projektet svarar han:
    "Jag tror inte det, Erlang har de egenskaper som beh&oumlvs i det h&aumlr projektet"
    Johan Garpendahl, NETSim


    8.6.3 J&aumlmf&oumlrelse med andra programspr&aringk
    Erlang p&aringminner mycket om programspr&aringket Lisp. Det som skiljer be b&aringda spr&aringken &aumlr syntaxen och parenteserna. S&aumlttet att t&aumlnka &aumlr det samma. Man har liknande datatyper, listor och de &aumlr b&aringda funktionella spr&aringk. D&aumlremot saknas det st&oumld f&oumlr processer i Lisp.
    Det &aumlr också skillnad på arbetss&aumlttet j&aumlmf&oumlrt med andra spr&aringk. N&aumlr man programmerar i Erlang så beh&oumlver man oftast bara kompilera fil f&oumlr fil f&oumlr att sedan testa. I ett annat spr&aringk så hade man beh&oumlvt kompilera, l&aumlnka och starta om systemet. Detta g&oumlr att man l&aumltt kan prova sig fram i Erlang f&oumlr att se om en sak kommer att fungera, utan att det tar en massa tid. Detta &aumlr en av anledningarna till varf&oumlr debuggern inte anv&aumlnds så ofta. En annan detalj i sammanhanget &aumlr att det inte finns n&aringgra h-filer (header filer) som man m&aringste h&aringlla reda på i Erlang. Detta har bl.a. underl&aumlttat underh&aringllet av programkoden.


    8.6.4 Programspr&aringkets betydelse
    Valet av programspr&aringk beror helt och h&aringllet på vad som skall g&oumlras.

    "Man skall v&aumllja programspr&aringk efter vad som skall g&oumlras och inte tv&aumlrt om"
    Johan Garpendahl, NETSim




    9. Studenternas erfarenheter av Erlang

    I detta avsnitt kommer jag att f&oumlrs&oumlka redog&oumlra f&oumlr den bild och de erfarenheterna som de examensarbetande studenterna har av Erlang. Eftersom de b&aringde har en liknande utbildningsbakgrund samt liknande f&oumlruts&aumlttningar så har jag valt att samla deras kritik på samma st&aumllle.

    Personerna i unders&oumlkningen &aumlr:
  • Anders Berglund, Kungliga Tekniska H&oumlgskolan (KTH), Stockholm
  • Johan Grafstr&oumlm, Chalmers Tekniska H&oumlgskola (CTH), G&oumlteborg
  • Jonna Palm, H&oumlgskolan i Sk&oumlvde
  • Tomas Aronsson, Chalmers Tekniska H&oumlgskola (CTH), G&oumlteborg



  • 9.1 Beskrivning av examensarbetena

    Det examensarbete som Johan Grafstr&oumlm och Tomas Aronsson g&oumlr best&aringr bl.a. av att konstruera en simulator f&oumlr AXE-tj&aumlnster och g&oumlra små testprogram i Erlang. Ut&oumlver detta skall &aumlven en utv&aumlrdering av detta arbete g&oumlras samt tester av simulatorns prestanda j&aumlmf&oumlrt med en simulator som sedan tidigare &aumlr skriven i C++. B&aringde Johan och Tomas g&aringr på datateknisk utbildning på Chalmers i G&oumlteborg. De har b&aringda kommit i kontakt med f&oumlljande programspr&aringk på sin utbildning: C, C++, Erlang, Haskell, ML, Fortran, Tcl/Tk, Ada, Simula, Pascal, Basic, z80, Cobol, Prolog, Forth och diverse assemblerspr&aringk. Erlang har de programmerat i sedan tre m&aringnader tillbaka.

    Jonna Palms examensarbete g&aringr bl.a. ut på att unders&oumlka huruvida en simulator konstruerad i Erlang skulle kunna vara ett m&oumljligt alternativ eller komplement till en simulator som sedan tidigare &aumlr konstruerad i Ada. Utifr&aringn detta arbete skall de b&aringda simulatorerna j&aumlmf&oumlras och slutsatser dras av arbetet. Jonna g&aringr på systemprogrammerarlinjen på H&oumlgskolan i Sk&oumlvde. Hon har på sin utbildning bl.a. kommit i kontakt med f&oumlljande programspr&aringk: Pascal, Fortran, Prolog, C, C++, SDT/SDL, Ada, Occam2 och lite assemblerspr&aringk. Hon programmerar &aumlven i Erlang sedan n&aringgra veckor tillbaka.

    Anders Berglunds examensarbete g&aringr ut på att unders&oumlka vilka problem, metoder samt f&oumlr- och nackdelar det finns med att implementera driftst&oumldssystemet TMOS i Erlang ist&aumlllet f&oumlr den nuvarande l&oumlsningen i C++. Anders g&aringr på Datateknisk utbildning på KTH i Stockholm. Han har tidigare kommit i kontakt med programspr&aringken: C++, C, Plex, Prolog och Lisp.


    9.2 Erfarenheter

    De f&oumlrdelar som finns med spr&aringket &aumlr att det g&aringr snabbt och enkelt att programmera i. Man kan koncentrera sig på det viktigaste och man slipper en massa on&oumldiga saker på detaljnivå. Det &aumlr &aumlven sk&oumlnt att slippa saker som pekare och typdefinition av variabler.

    Det verkar också smidigt att kunna g&oumlra &aumlndringar i programmet under k&oumlrning fast&aumln jag sj&aumllv inte har haft anv&aumlndning f&oumlr s&aringdan finesser.
    Jonna Palm

    Vidare finns det m&aringnga inbyggda funktioner (BIF) som &aumlr v&aumlldigt anv&aumlndbara och som sparar mycket tid f&oumlr programkonstrukt&oumlrer. Felhanteringen verkar fungera ungef&aumlr som i C++, vilket inneb&aumlr att felen tas omhand d&aumlr de sker och inte på en h&oumlgre nivå i programvaran. Detta &aumlr mycket bra, speciellt n&aumlr man skall debugga programvaran.

    "Vi har j&aumlmf&oumlrt Erlang i f&oumlrsta hand med C++ och vi anser att Erlang &aumlr b&aumlttre på allt utom prestanda, interfacing och m&oumljligen viss reservation f&oumlr den dynamiska typningen"
    Tomas Aronsson och Johan Grafstr&oumlm

    Ett problem med Erlang &aumlr att skapa ett gr&aumlnssnitt (interface) till andra programspr&aringk. Det hade varit trevligt om det fanns ett Erlangbibliotek som man kunde l&aumlnka med sin C/C++-applikation.
    N&aringgot som k&aumlnns lite ovant med spr&aringket &aumlr "fnuttologin" - menar Anders Berglund och Jonna Palm.

    "Det &aumlr m&aringnga g&aringnger sv&aringrt att h&aringlla is&aumlr om det skall vara punkt, komma eller semikolon vid en del tillf&aumlllen. Detta g&aumlller då fr&aumlmst vid Select-satser"
    Anders Berglund

    Relativt andra funktionella programspr&aringk s&aumlger sig Tomas Aronsson och Johan Grafstr&oumlm, sakna lambdafunktioner, h&oumlgre ordningens funktioner och "lathet"16. Men detta g&oumlr Erlang lite l&aumlttare att komma in i f&oumlr n&aringgon som inte har sett funktionell programmering. Dock så tappar man en del kraftfullhet.

    Spr&aringket l&aumlmpar sig bl.a. f&oumlr problem d&aumlr man l&aumltt kan identifiera processer. Exempel på s&aringdana omr&aringden skulle kunna vara inom telefoniv&aumlrlden 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&aumltt kunde identifiera processer och att det var sv&aringrt att definiera tillst&aringnd.
    F&oumlr &oumlvrigt &aumlr det mycket l&aumltt att hitta de fel som uppst&aringr genom att prova sig fram i interpretatorn.


    9.3 J&aumlmf&oumlrelse med andra programspr&aringk

    I Erlang slipper man m&aringnga av de problemet som finns i C++. Detta beror bl.a. på att Erlang saknar pekare, headers-filer och makefiler.

    F&oumlr att testa ett program i C++ f&aringr man m&aringnga g&aringnger skriva ett speciellt program som g&oumlra dessa tester. Dessa problem finns inte i Erlang. Erlang och Plex har det gemensamt att de &aumlr uppbyggda med moduler som skickar meddelanden till varandra. Man skulle också kunna se spr&aringket som en utvidgning av Prolog med realtid och samtidighet.

    En annan erfarenhet &aumlr att:

    "Man kan aldrig ge sig h&aumln med andra programspr&aringk, j&aumlmf&oumlrt med Erlang"
    Anders Berglund


    9.4 Programspr&aringkets betydelse

    Anders Berglund menar också att ett programspr&aringk speglar och p&aringverkar en organisation på n&aringgot s&aumltt. Anv&aumlnder man sig av ett objektorienterat programspr&aringk så visar det sig bl.a. i projektgruppens sammans&aumlttning. Man m&aringste ha mycket folk runt omkring som hanterar koden och personer som &aumlr ansvariga f&oumlr applikationens objekt samt dess struktur.




    10. Analys

    De problem som jag st&aumllls inf&oumlr n&aumlr jag skall analysera detta material &aumlr m&aringnga. De två viktigaste uppgifterna i en analys &aumlr framf&oumlr allt att vara kritisk i sitt granskande och att g&oumlra sig sj&aumllv kritiserbar. Det &aumlr vidare av v&aumlsentlig karakt&aumlr att man inte bygger sina slutsatser på ogrundade uppgifter eller rena spekulationer. Allt detta f&oumlruts&aumltter i det n&aumlrmaste, att jag som forskare kan betrakta mitt material i ett st&oumlrre perspektiv f&oumlr att på så s&aumltt finna &oumlvergripande samband. F&oumlrst d&aumlrefter &aumlr det m&oumljligt att utf&oumlra generaliseringar av det insamlade materialet. Detta &aumlr naturligtvis mycket sv&aringrt. Det st&aumlller krav på mig som person att ordentligt redog&oumlra f&oumlr mitt resonemang och inte dra n&aringgra f&oumlrhastade slutsatser.
    Det insamlade materialet &aumlr f&oumlrmodligen den mest omfattande studie som har gjorts hittills om erfarenheter av Erlang. Gemensamt f&oumlr alla intervjuade projekt &aumlr att de &aringterfinns inom Ericssonkoncernen. &Aumlven Erlang Systems AB h&oumlr hemma h&aumlr. Detta faktum har naturligtvis gjort mig extra k&aumlllkritisk 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&aringkr&oumlr f&oumlr n&aringgot som inte &aumlr allm&aumlnt accepterat eller som jag inte sj&aumllv anser ? Det viktigaste &aumlr nog att man &aumlr mycket k&aumlllkritisk till det material man f&aringr in. Det &aumlr &aumlven viktigt att man unders&oumlker de k&aumlllor som refereras vid intervjuerna eller i litteraturen. Problemet med detta spr&aringk &aumlr att det har en relativt begr&aumlnsad skara anv&aumlndare. Dessa anv&aumlndare k&aumlnner i m&aringnga fall &aumlven till varandra. Med dessa tankar i bakgrunden redovisar jag nu sammanst&aumlllningen av projektgruppernas erfarenheter.

    Materialet tyder på att alla projekten har &oumlverensst&aumlmmande erfarenheter av programspr&aringket.

    Erlang har varit ett utomordentligt st&oumld och tillg&aringng i &aringtminstone fem av de sex projekten. Det projekt som har haft lite problem med inf&oumlrandet av Erlang h&aumlnf&oumlr detta till andra faktorer &aumln sj&aumllva programspr&aringket. Det har ist&aumlllet handlat om bristf&aumlllig utbildning och kompetens som har gjort det sv&aringrt att dra full nytta av Erlangs hela styrka. Vidare fanns det m&aringnga ok&aumlnda parametrar i projektet som gjorde att man inte hade n&aringgon trygg bas att stå på.
    Alla programvarukonstrukt&oumlrer n&aumlmner hur l&aumltt det &aumlr att programmera i Erlang. Detta beror bl.a. på att man arbetar på en h&oumlgre abstraktionsnivå &aumln man g&oumlr i andra spr&aringk. Flera av de intervjuade anger att den h&oumlga abstraktionsniv&aringn i programspr&aringket &aumlr en av de viktigaste egenskaperna i spr&aringket. "Abstraktionen &aumlr ett s&aumltt att identifiera viktiga egenskaper och funktioner i det som modelleras. Man kan koncentrera sig på aspekter som &aumlr viktiga och strunta i ov&aumlsentliga detaljer."
    Ghezzi och Jazayeri [ 15 ]

    Ett programspr&aringk som har en h&oumlg abstraktionsnivå kan d&aumlrf&oumlr s&aumlgas hantera programdesignens komplexitet på ett bra s&aumltt.

    Alla anser vidare att spr&aringkets syntax &aumlr liten och l&aumltt att l&aumlra sig. De flesta av de intervjuade personerna ans&aringg att utbildningen på fyra dagar r&aumlckte f&oumlr att man skulle f&oumlrstå de viktigaste grunderna i spr&aringket.


    Den programkod som skrivs blir ofta också mycket kortare &aumln programkod som skrivs i imperativa programspr&aringk. Det finns unders&oumlkningar som visar på att programkoden kan bli upp till nio g&aringnger kortare med Erlang [ 6 ] j&aumlmf&oumlrt med t.ex. Plex. Andra sidor &aumlr att man inte beh&oumlver bry sig om minneshantering, pekare eller att deklarera variabler. Detta sk&oumlter Erlang. Dessa saker betonar alla programkonstrukt&oumlrerna i projekten som viktiga.

    Vad betr&aumlffar spr&aringkets svaga sidor &aumlr det betydligt sv&aringrare att utskilja n&aringgra tydliga m&oumlnster. Två projekt n&aumlmner att man hade &oumlnskat sig b&aumlttre grafiska hj&aumllpmedel &aumln de som finns idag. Ett annat projekt menar att det &aumlr l&aumlttare att g&oumlra grafik i Erlang &aumln vad det &aumlr i C++. Vad som &aumlr viktigt i detta sammanhang &aumlr då vilken typ av grafikpaket man anv&aumlnder sig av. Två projekt n&aumlmner också Erlangs gr&aumlnssnittshantering mot andra programspr&aringk som ett m&oumljligt problem.

    N&aumlr det g&aumlller att utv&aumlrdera Erlangs egenskaper har det m&aringnga g&aringnger framh&aumlvts att det inte finns n&aringgra tillr&aumlckligt stora projekt att utv&aumlrdera spr&aringket i. Detta &aumlr inget stort problem s&aumlger Bernt Ericsson, forskningschef på Ericsson. Det skall helt enkelt inte finnas n&aringgra stora projekt. Bort med mastodontprojekten ! Allt skall brytas ner till delprojekt med h&oumlgst 50 man. Vi m&aringste l&aumlra oss att driva projekt på ett helt annat s&aumltt &aumln tidigare. F&oumlr Ericsson kan valet av programspr&aringk vara en ren &oumlverlevnadsfr&aringga. Det g&aumlller att finna l&oumlsningar som avsev&aumlrt &oumlkar produktiviteten, d.v.s. snabbare utveckling till l&aumlgre kostnad. D&aumlrf&oumlr kr&aumlvs det ett genombrott på mjukvarusidan. Erlang kan vara en del av l&oumlsningen.18Inget av projekten har n&aumlmnt att man har haft n&aringgot problem med prestanda hos de f&aumlrdiga applikationerna. Det &aumlr dock viktigt att p&aringpeka att inga av projekten har konstruerat applikationer som har varit extremt k&aumlnsliga f&oumlr prestanda. &Oumlverv&aumlgande delen av projekten har konstruerat simulatorer eller prototyper av olika slag som inte &aumlr så k&aumlnsliga med avseende på prestanda. Vad betr&aumlffar prestanda så har man inte så mycket j&aumlmf&oumlrande v&aumlrden mellan Erlang och andra spr&aringk. Detta &aumlr ett omr&aringde som jag hade &oumlnskat lite mer unders&oumlkningar om. Tomas Aronsson och Johan Grafstr&oumlm har dock gjort en del enklare prestandatester mellan Erlang och C++, som visar att Erlang har lite s&aumlmre prestanda. Men det &aumlr sv&aringrt att dra n&aringgra direkta slutsatser av dessa tester. Programoptimering och problemtyp har mycket stor betydelse i dessa m&aumltsammanhang.

    D&aringliga prestanda har annars alltid varit den tyngsta kritiken mot funktionella programspr&aringk [ 4 ]. Jag har dock inte n&aringgot konkret material som bekr&aumlftar att det skulle f&oumlrh&aringlla sig så med Erlang.

    De flesta i unders&oumlkningen verkar vara &oumlverens om att programkoden &aumlr l&aumltt att testa, i alla fall så l&aumlnge man inte anv&aumlnder debuggern. Vad betr&aumlffar antalet fel i programkoden r&aringder det lite olika meningar. M&aringnga h&aumlvdar att det har blivit mindre fel sedan de b&oumlrjade anv&aumlnda Erlang, medan en del h&aumlvdar att det blir lika mycket fel som tidigare.
    Dessa två of&oumlrenliga st&aringndpunkter g&aringr kanske att f&oumlrklara med Anders Dannes ord:

    "Det &aumlr nog lika m&aringnga fel per antalet rader som det var tidigare, dock blir det f&aumlrre rader kod nu, vilket leder till att det blir f&aumlrre fel totalt sett &aumln vad det var tidigare.".
    Anders Danne, Era-t

    Detta uttalande bekr&aumlftas delvis av Rune Berg.

    "De logiska felen kommer lika ofta som tidigare".
    Rune Berg, Mobility Server

    Detta skulle kunna vara en rimlig f&oumlrklaring till varf&oumlr man svarar lite olika på denna fr&aringga. Man g&oumlr lika m&aringnga slarvfel som tidigare men kortare programkod g&oumlr att det blir mindre fel totalt sett. Om man accepterar denna f&oumlrklaring så kan man slå fast att det totala antalet fel i programkoden kan minskas genom att man anv&aumlnder Erlang som implementationsspr&aringk.

    Vidare anger de flesta att Erlang passar f&oumlr bl.a. realtidssystem , telefoni/v&aumlxlar och distribuerade system. Små applikationer i Dos/Windows eller applikationer med h&oumlga krav på prestanda passar inte lika bra f&oumlr Erlang, anser projekten. Applikationer som &aumlr h&aringrdvarun&aumlra &aumlr också ol&aumlmpliga f&oumlr Erlang, Två av projekten n&aumlmner dock att man inte kan komma på n&aringgra omr&aringden som inte skulle passa f&oumlr Erlang.

    Erlang som produkt upplevs &aumlven vara mycket stabil och tillf&oumlrlitlig. Det &aumlr endast ett av de sex projekten som har r&aringkat ut f&oumlr n&aringgot fel i programmeringsmilj&oumln och det skedde efter mycket l&aringng och tuff anv&aumlndning.

    På fr&aringgan vad programspr&aringket har f&oumlr betydelse f&oumlr att ett projekt skall lyckas, svarar alla genomg&aringende att programspr&aringket har en mycket liten betydelse. Det finns m&aringnga andra faktorer som har st&oumlrre betydelse &aumln programspr&aringket. N&aringgot som betonas &aumlr bl.a. metodvalet. Det &aumlr viktigt att det programspr&aringk man anv&aumlnder fungerar bra ihop med den metod man anv&aumlnder, och vice versa. Eller som Bo Bergstr&oumlm, ETX/B s&aumlger: "Det &aumlr metod och spr&aringk som tillsammans borgar f&oumlr ett lyckat projekt".
    Eftersom man programmerar så lite j&aumlmf&oumlrt med &oumlvriga moment i utvecklingsarbetet så f&aringr programspr&aringket inte så stor betydelse f&oumlr projektet i sin helhet. Ett projekt anger dock att valet av programspr&aringk kan p&aringverka tiden f&oumlr n&aumlr ett projekt blir f&aumlrdigt samt kvaliteten i programkoden.
    Andra viktiga aspekter som lyfts fram &aumlr utbildning/kompetens och stabilitet.

    Med stabilitet menar man bl.a. stabilitet i: programplattformar och organisationen men &aumlven att kravspecifikationen inte f&oumlr&aumlndras. Vidare anger man att f&oumlrarbetet och helheten &aumlr avg&oumlrande faktorer f&oumlr att ett projekt skall lyckas.

    Dessa &aringsikter bekr&aumlftas bl.a. av Bengt Lennartsson, Link&oumlpings universitet som pekar på att kompetens och erfarenhet hos inblandade personer inklusive projektledning &aumlr viktigt. Man m&aringste veta vad man skall g&oumlra, det r&aumlcker inte med duktig personal. N&aringgot som har stor betydelse &aumlr en konsistent m&aringlframst&aumlllning.
    Mycket l&aumlngre ner kommer bl.a. st&oumldsystem, resursfaktorer, lokala datast&oumld, kommunikationsm&oumljligheter och implementationsspr&aringk. N&aringgonstans mitt emellan kommer stabilitet och l&aringngsiktighet.

    Det &aumlr &aumlven viktigt att man utvecklar och utnyttjar den entusiasm som finns hos medarbetarna. Bengt uttalar sig inte fr&aumlmst utifr&aringn sina egna erfarenheter, utan ifr&aringn en sammanv&aumlgning av vad han uppfattar att andra har f&oumlr erfarenheter inom omr&aringdet.

    Anders Wennerstr&oumlm, Ericsson anger att det &aumlr viktigt med en stabil industrialiserad st&oumldmiljö. St&oumlrningar av n&aringgon formsak ger mycket turbulens och f&oumlrseningar. Eftersom de inblandade individerna uppfattar detta som utanf&oumlr deras kontroll, uppst&aringr det stor frustration hos de inblandade. Det &aumlr viktigt att kunna f&oumllja de planer som man har st&aumlllt upp. Programspr&aringket &aumlr inte så viktigt f&oumlr ett enstaka projekt. Man b&oumlr ist&aumlllet titta på betydelsen av programspr&aringk f&oumlr olika typer av projekt. D&aumlr &aumlr det lite mer relevant att titta på programspr&aringkets betydelse, men &aumlven h&aumlr &aumlr spr&aringket klart underl&aumlgset andra parametrar av arkitekturkarakt&aumlr, till exempel hur man definierar interna plattformar och interna gr&aumlnssnitt. Det vanligaste misstaget man g&oumlr &aumlr annars att man s&aumltter ig&aringng och jobbar innan man ordentligt har klarlagt vad man vill få fram. Man slarvar &aumlven med uppl&aumlggningen av systemtesterna s&aumlger Andes vidare.

    Alla dessa &aringsikter visar att programspr&aringket kanske inte har så stor betydelse f&oumlr om ett projekt skall lyckas eller ej. M&oumljligen b&oumlr man st&aumllla fr&aringgan som: vilken betydelse har programspr&aringket f&oumlr ett system, ist&aumlllet. Men unders&oumlkningen har samtidigt visat att valet av programspr&aringk kan ha mycket stor betydelse i implementationen. D&aumlr kan spr&aringket f&oumlrenkla arbetet, g&oumlra k&aumlllkoden kortare och underl&aumltta i problemprocessen.
    En annan viktig faktor &aumlr naturligtvis programkonstrukt&oumlrernas kompetens.

    Stolterman [ 20 ] n&aumlmner att en god probleml&oumlsare karakteriseras av att han &aumlr duktig på att l&oumlsa de problem som han blir tilldelad. Eftersom man vet att antalet m&oumljliga problem och l&oumlsningar till ett problem kan vara mycket stort, så blir probleml&oumlsarens f&oumlrm&aringga att snabbt hitta en l&oumlsning en ekonomisk fr&aringga, t.ex. genom att korta ner s&oumlktiden. F&oumlr att inte beh&oumlva g&oumlra en fullst&aumlndig genomg&aringng av alla alternativ brukar det medges att kreativ och intuitiv f&oumlrm&aringga &aumlr bra f&oumlr att korta ner s&oumlktiden.

    Ut&oumlver detta så verkar det &aumlven "gå religion i programspr&aringk". Det kan vid en f&oumlrsta tanke k&aumlnnas m&aumlrkligt att ett programspr&aringk kan ha så stor betydelse f&oumlr den som anv&aumlnder det. Ett programspr&aringk &aumlr ett av m&aringnga verktyg som man beh&oumlver anv&aumlnda sig av i ett programutvecklingsprojekt. Men f&oumlr att kunna anv&aumlnda sig av ett verktyg så kr&aumlvs kompetens och "hantverksskicklighet". Anv&aumlnder man sig av ett verktyg som man k&aumlnner att man beh&aumlrskar och d&aumlrigenom k&aumlnner sig trygg med, så kan favoritspr&aringk uppstå.

    Har man hittat ett favoritspr&aringk/verktyg så &oumlverger man inte detta, inte ens om det skulle finnas rationella sk&aumll f&oumlr det. V&aumlgrar man att anv&aumlnda n&aringgot annat programspr&aringk så blir det n&aumlstan som en religi&oumls tro.


    Bengt Lennartsson s&aumlger att:

    "Programspr&aringk uppfattas som viktigt av implementat&oumlrerna. Så valet av programspr&aringk i ett projekt p&aringverkar vilka typer av personer som s&oumlker sig till projektet. Det spr&aringk ett f&oumlretag v&aumlljer p&aringverkar vilka personer som s&oumlker sig dit"
    Bengt Lennartsson, Link&oumlpings Universitet

    I mitt arbete finner jag dock ingeting som skulle bekr&aumlfta att Erlang har blivit en religion. Men kommentarer som Anders Berglund ger, visar på att man k&aumlnner mycket f&oumlr Erlang.

    "Man kan aldrig ge sig h&aumln med andra programspr&aringk, j&aumlmf&oumlrt med Erlang"
    Anders Berglund

    De flesta verkar dock vara &oumlverens om att man skall v&aumllja programspr&aringk efter vad man skall g&oumlra och inte tv&aumlrt om. D&aumlremot finns det s&aumlkerligen f&oumlrteelser kring andra programspr&aringk som b&aumlttre skulle passa in att j&aumlmf&oumlras med religi&oumls tro.

    Den unders&oumlkning som gjordes av studenternas erfarenheter bekr&aumlftar att Erlang skulle vara l&aumltt att l&aumlra sig och att det &aumlr enkelt att programmera i Erlang. Man arbetar på en abstraktionsnivå d&aumlr man slipper fundera på en massa saker på detaljnivå.

    "Vi har j&aumlmf&oumlrt Erlang i f&oumlrsta hand med C++ och vi anser att Erlang &aumlr b&aumlttre på allt utom prestanda, interfacing och m&oumljligen med viss reservation f&oumlr den dynamiska typningen"
    Tomas Aronsson och Johan Grafstr&oumlm

    Andra faktorer som upplevs som mycket viktiga &aumlr Erlangs felhantering och dess inbyggda funktioner (BIF). De inst&aumlmmer &aumlven till en del av den uttalade kritiken som fanns mot Erlang. Det &aumlr bl.a. sv&aringrt att h&aringlla is&aumlr om det skall vara kommatecken, punkt eller semikolon i en del satser. Man anger dock att detta &aumlr fr&aringgan om en vanesak och inget st&oumlrre problem. Det finns &aumlven en del &oumlnskem&aringl om sk. lambdafunktioner, h&oumlgre ordningens funktioner och lathet fr&aringn Aronsson och Grafstr&oumlm. Dessa funktioner &aumlr dock inte oumb&aumlrliga. Erlang &aumlr på s&aumltt och viss ett defunktionaliserat spr&aringk, d.v.s. man har tagit bort mycket funktioner som inte anv&aumlnds eller beh&oumlvs. Ett annat problem som &aringterkommer &aumlr att det &aumlr sv&aringrt att skapa gr&aumlnssnitt till andra programspr&aringk fr&aringn Erlang

    Sammantaget visar unders&oumlkningen på att de erfarenheter som studenterna hade &oumlverensst&aumlmmer med de erfarenheter som man hade inom de olika projekten. Detta anser jag, visar på att de uppgifter som jag har st&aumlllt samman st&aumlmmer in ganska bra med de erfarenheter av programspr&aringket som finns hos telekommunikationsindustrin idag.




    11. Slutsatser

    De erfarenheter som programkonstrukt&oumlrerna i de sex olika projekten har st&aumlmmer v&aumll &oumlverens med studenternas erfarenheter av Erlang.

    Man anser att Erlang &aumlr ett litet och mycket kraftfullt programspr&aringk, som &aumlr l&aumltt att l&aumlra sig. Programkoden som skrivs upplevs som kortare j&aumlmf&oumlrt med C++ och Plex. En f&oumlrdel med spr&aringket &aumlr dess h&oumlga abstraktionsnivå. Man beh&oumlver inte bekymra sig om pekare, minneshantering eller att deklarera variabler.

    Inget projekt har haft n&aringgot problem med prestanda i de f&aumlrdiga applikationerna. Det finns dock tecken på att Erlang skulle ha s&aumlmre prestanda &aumln vad t.ex. C++ har. F&oumlr att verkligen besvara denna fr&aringga kr&aumlvs emellertid fler unders&oumlkningar inom omr&aringdet.

    N&aringgot projekt och n&aringgon student n&aumlmner att man har haft problem med att få ett fungerande gr&aumlnssnitt mellan Erlang och andra programspr&aringk.

    Som programspr&aringk anser man att Erlang bl.a. passar f&oumlr realtidssystem, telekommunikation och distribuerade system. Men det finns indikationer på att det &aumlven skulle gå att anv&aumlnda inom andra omr&aringden. Man har dock sv&aringrt att t&aumlnka sig spr&aringket f&oumlr applikationer i Dos/Windows eller applikationer med h&oumlga krav på prestanda. Applikationer som &aumlr h&aringrdvarun&aumlra kan också vara ol&aumlmpliga f&oumlr Erlang

    Det totala antalet fel i programkoden kan minska genom att man anv&aumlnder Erlang som implementationsspr&aringk. Eller som en av programkonstrukt&oumlrerna n&aumlmnde:

    "Det &aumlr nog lika m&aringnga fel per antalet rader som det var tidigare, dock blir det f&aumlrre rader kod nu, vilket leder till att det blir f&aumlrre fel totalt sett &aumln vad det var tidigare.".
    Anders Danne, Era-t

    Det fanns bara ett projekt av sex som har haft lite problem med inf&oumlrandet av Erlang. Man h&aumlnvisar dock dessa problem till andra faktorer &aumln sj&aumllva programspr&aringket. Det har ist&aumlllet handlat om bristf&aumlllig utbildning och kompetens som har gjort det sv&aringrt att dra full nytta av Erlangs hela styrka.
    En annan slutsats av detta arbete &aumlr att programspr&aringket inte har så stor betydelse f&oumlr om ett projekt skall lyckas eller ej. Det finns andra faktorer som &aumlr viktigare t.ex. utbildning, stabilitet och f&oumlrh&aringllandet mellan spr&aringk och metod.
    Jag v&aumlljer att avsluta och delvis inst&aumlmma med f&oumlljande ord:

    "Vi har j&aumlmf&oumlrt Erlang i f&oumlrsta hand med C++ och vi anser att Erlang &aumlr b&aumlttre på allt utom prestanda, interfacing och m&oumljligen med viss reservation f&oumlr den dynamiska typningen"
    Tomas Aronsson och Johan Grafstr&oumlm, Chalmers




    12. Avslutande diskussion

    F&oumlreliggande uppsats skall ses som ett f&oumlrsta kvalitativt f&oumlrs&oumlk att redog&oumlra f&oumlr programspr&aringket Erlangs egenskaper samt programkonstrukt&oumlrernas erfarenheter av att arbeta med detta spr&aringk. Redan det nu tillg&aumlngliga materialet till&aringter att man g&oumlr en del analyser av spr&aringket, &aumlven om man hade &oumlnskat sig ett bredare material f&oumlr denna uppgift. Under de veckor som detta arbete har engagerat mig har jag kommit i kontakt med m&aringnga nya problem. M&aringnga av dessa har jag kommit till r&aumltta med men m&aringnga fr&aringgor &aringterst&aringr att besvara. Utifr&aringn detta nuvarande material ser jag ingen m&oumljlighet att besvara alla dessa fr&aringgor. Avslutningsvis tycker jag d&aumlrf&oumlr att det &aumlr av stor vikt att betona fr&aringgor som har blivit obesvarade i mitt och andras arbete inom detta omr&aringde.

    Varf&oumlr har inte Erlang slagit igenom mer &aumln vad det redan har gjort ?

    Om spr&aringket har alla dessa egenskaper som jag har redovisat st&aumlller man sig lite fr&aringgande till varf&oumlr inte fler anv&aumlnder detta spr&aringk b&aringde inom och utanf&oumlr Ericssonkoncernen. Jag har sj&aumllv ett antal hypoteser om detta:

  • Det finns andra viktiga faktorer som har st&oumlrre betydelse f&oumlr valet av programspr&aringk &aumln de som jag har unders&oumlkt.
  • Programspr&aringk &aumlr trendk&aumlnsliga.
  • Spr&aringk &aumlr som religioner. Har man en g&aringng valt ett spr&aringk så byter man inte ut det.
  • Valet av programspr&aringk sker inte på rationella premisser, utan man anv&aumlnder det som man alltid har anv&aumlnt
  • utan att utv&aumlrdera andra typer av spr&aringk till sina projekt.
  • Man k&aumlnner sig fr&aumlmmande f&oumlr deklarativa spr&aringk samt dess tankes&aumltt.
  • Det tar tid innan ny teknologi sl&aringr igenom.
  • B&aumlsta l&oumlsningen vinner inte alltid, d.v.s. det finns faktorer som &aumlr viktigare &aumln den rent tekniskt b&aumlsta
  • l&oumlsningen. Marknadsf&oumlring av programspr&aringk kanske skulle kunna ha betydelse i detta sammanhang.
  • De krav på programspr&aringk som &aringterfinns inom telekommunikationsbranschen &aringterfinns inte inom n&aringgon annan bransch.

  • Listan skulle s&aumlkerligen kunna g&oumlras l&aumlngre

    Kan Erlang anv&aumlndas inom andra omr&aringden ?

    Alla personer som jag har intervjuat anser att Erlang inte enbart l&aumlmpar sig f&oumlr applikationer inom telekommunikationsindustrin, utan borde kunna anv&aumlndas inom andra omr&aringden också. Det finns dock mig veterligen inte n&aringgra projekt utanf&oumlr denna v&aumlrld som har anv&aumlnt sig av Erlang. En intressant uppgift skulle d&aumlrf&oumlr vara att unders&oumlka i vilken m&aringn spr&aringket skulle passa f&oumlr andra typer av till&aumlmpningar. En annan fr&aringgest&aumlllning som knyter an till den f&oumlrsta fr&aringgan &aumlr:

    Vad finns det f&oumlr motiv n&aumlr man v&aumlljer programspr&aringk till ett projekt ?

    Ett svar på denna fr&aringga kanske skulle kunna vara att man inte alltid har n&aringgot annat val &aumln att bygga vidare på den plattform eller miljö som man redan har. Det g&aringr kanske inte att blanda spr&aringken hur som helst.




    13. K&aumlllf&oumlrteckning

    Tryckta k&aumlllor:

    [ 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&oumlm J.: A draft for our master thesis projekt, Underlag till examensarbete, Ericsson Telecom AB, M&oumllndal, 1995

    [ 4 ] Datateknik.: De tror på deklarativa spr&aringk, nr 5, s.40-41, 1995

    [ 5 ] Datateknik.: Deklarativa spr&aringk -
    akademiskt flum eller framtidens programspr&aringk?, nr 8, s.8-9, 1995

    [ 6 ] Datateknik.: Nio g&aringnger 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&aumlcker 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&oumlr datavetenskap, Link&oumlpings 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&oumlgskolan i Link&oumlping


    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




    14. Ordlista

    AXE-10
    En av Ericssons mest s&aringlda AXE-v&aumlxel.

    BIF
    Built in functions.

    DCT900
    Ericssons digitala och tr&aringdl&oumlsa telefonsystem.

    EriPascal
    En Ericsson dialekt av Pascal som klarar att hantera processer.

    H
    Funktionellt programspr&aringk utvecklat av Carlstedt Elektronik AB.

    HP/UX
    Hewlett Packards (HP) UNIX version.

    Lambda funktioner
    En notation f&oumlr att mycket generellt beskriva hur funktioner appliceras på sina argument. Lambda anv&aumlnds f&oumlr att definiera procedurer på samma s&aumltt som "define", bortsett fr&aringn att inget namn anges f&oumlr proceduren som definieras. Lambda kan ses som ett anonym "define".

    MD110
    Telefonv&aumlxel konstruerad av Ericsson.

    PBX
    Ett grafikpaket under UNIX.

    RACE
    Research into Advanced Communications in Europe.

    Single assignment
    Alla variabler &aumlr "konstanter". Det g&aringr inte att tilldela en variabel ett nytt v&aumlrde mer &aumln en g&aringng.

    Solaris
    SUN´s nya UNIX version.

    TMOS
    St&aringr f&oumlr "Telecommunication Management and Operations Support" och &aumlr ett programsystem som &aumlr avsett f&oumlr drift och underh&aringll av en AXE- v&aumlxel.

    TUP
    Tekniskt Utskott f&oumlr programvara.

    XView
    Ett grafikpaket under UNIX.





    Bilaga 1: intervjuguide projektledare

    1. Hur kom ni i kontakt med Erlang f&oumlrsta g&aringngen.
    2. Vad fanns det f&oumlr krav på programspr&aringket till projektet.
    3. Hur gick valet av programspr&aringk till.
    4. Vem gjorde valet av Erlang.
    5. Vad var den fr&aumlmsta anledningen till att Erlang valdes.
    6. Vilken betydelse var det att Erlang &aumlr deklarativt.
    7. Vad k&aumlnde ni till om Erlang sedan tidigare.
    8. Fanns det n&aringgra andra spr&aringk som var aktuella och i så fall vilka.
    9. Har valet av Erlang pr&aumlglat projektet på n&aringgot annat s&aumltt.
    10. Har projektgruppens storlek/sammans&aumlttning p&aringverkats genom valet av Erlang.
    11. Hur upplever du att utvecklingstiden har p&aringverkats av genom valet av Erlang
    12. Har kvaliteten p&aringverkats i koden genom valet av Erlang och i så fall hur
    13. Vad anser du att valet av programspr&aringk har f&oumlr betydelse f&oumlr ett projekt.
    14. Om du hade gjort om detta projektet hade du valt n&aringgot annat programspr&aringk.
    15. Vad &aumlr Erlangs starkaste sida.
    16. Vilken typ av projekt l&aumlmpar sig Erlang b&aumlst f&oumlr.
    17. Vad &aumlr Erlangs svagaste sida.
    18. Vilken typ av projekt &aumlr Erlang ol&aumlmplig f&oumlr.
    19. Vilka anser du vara Erlangs praktiska anv&aumlndningsomr&aringden.
    20. Har f&oumlruts&aumlttningarna skilt sig i detta projekt j&aumlmf&oumlrt med andra projekt.
    21. N&aumlr eller i vilket skede gjordes valet av programspr&aringk.
    22. Vad &aumlr viktigast f&oumlr att ett projekt skall lyckas




    Bilaga 2: Intervjuguide f&oumlr programkonstrukt&oumlrer

    1. Hur l&aringng praktisk erfarenhet har du av Erlang.
    2. Vilka programspr&aringk har ni arbetat med tidigare
    3. J&aumlmf&oumlr dina erfarenheter av andra programspr&aringk med Erlang.
    4. Vad anser du att valet av programspr&aringk har f&oumlr betydelse f&oumlr ett projekts utg&aringng.
    5. Vilket programspr&aringk anv&aumlnder du dig sj&aumllv helst av.
    6. Vad anser du vara Erlangs starkaste sida.
    7. Vad &aumlr Erlangs svagaste sida.
    8. Vilken typ av projekt l&aumlmpar sig Erlang f&oumlr.
    9. Vilken typ av projekt &aumlr Erlang ol&aumlmplig f&oumlr
    10. Har programvarukvaliteten p&aringverkats genom valet av Erlang.
    11. Har utvecklingstiden p&aringverkats av genom valet av Erlang.
    12. Hur har valet av programspr&aringk p&aringverkat ditt arbetss&aumltt.
    13. Arbetar du på ett annat s&aumltt med ett deklarativt spr&aringk
    14. Vad &aumlr det f&oumlr typ av fel som uppst&aringr i koden.
    15. Hur &aumlr koden att underh&aringlla.
    16. Om du hade gjort om detta projektet hade du valt n&aringgot annat programspr&aringk .
    17. Finns det n&aringgot som saknas eller har ett d&aringligt st&oumld i spr&aringket.
    18. Vad tycker du &aumlr den st&oumlrsta skillnaden mellan ett deklarativt programspr&aringk som
    Erlang fr&aringn andra mer "traditionella spr&aringk".
    19. Har spr&aringket gett er n&aringgot extra, som ni inte hade f&aringtt med er i n&aringgot annat
    programspr&aringk.




    Bilaga 3: enk&aumltfr&aringgor till examensarbetare

    1. Vad anser du om Erlang, f&oumlrdelar/nackdelar.
    2. Vilka programspr&aringk har du anv&aumlnt dig av tidigare.
    3. Hur l&aumlnge har du anv&aumlnt Erlang.
    4. G&oumlr en kort beskrivning av ditt arbete eller din uppgift.




    
    

    Bilaga 4: Programexempel


    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&aringn: start(), som med hj&aumllp av Spawn-satsen startar en ny process, och Loop() - en evighetsfunktion som oupph&oumlrligen tittar efter i brevl&aringdan f&oumlr att se om det har kommit n&aringgon post.

    Anta att start() anropas fr&aringn 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&aringr det bra att skicka meddelanden.

    Med satsen Id ! {self(), hello} skickas meddelandet {self(), hello} till Id:s brevl&aringda. Funktionen self() &aumlr inbyggd i Erlang och ger processidentifieraren till den just nu aktuella processen, d.v.s. avs&aumlndaren.

    Loop tar emot och f&oumlrs&oumlker matcha meddelandet mot sina alternativ. Vid matchningen binds variabeln From till Self() och Message kommer h&aumldanefter att betyda hello.
    Loop h&aumllsar tillbaka till den ursprungliga processen och b&oumlrjar om i v&aumlntan på nya meddelanden.





    Fotnoter

    1 Med programkonstrukt&oumlrer avser jag personer som deltar b&aringde i analys, design och programmerings-faserna i ett projekt.




    2 Med storlek tas i denna bem&aumlrkelse b&aringde h&aumlnsyn till antalet projektmedlemmar och uppgiftens omfattning.




    3 Som t ex PLEX eller C. Se vidare i kapitlet "Imperativa/deklarativa spr&aringk".




    4 Jag anv&aumlnder begreppet samtidighet som jag tycker &aumlr en b&aumlttre och mer riktig &oumlvers&aumlttning av "concurrency", ist&aumlllet f&oumlr parallellism. Parallellism &aumlr f&oumlr mig f&oumlrknippat med plattformar med flera processorer, och inte en processor som &aumlr multi-programmerad.




    5 Jag syftar h&aumlr fr&aumlmst på Von Neumannarkitekturen som &aumlr den idag vanligaste arkitekturen f&oumlr dagens datorer och programspr&aringk.




    6 Det finns naturligtvis programspr&aringk som &aumlr undantag fr&aringn detta. Ett exempel skulle kunna vara Smalltalk som f&aringr lov att anses som ett imperativt programspr&aringk med relativt h&oumlg abstraktionsnivå.




    7 Med traditionella programsp&aringrk avser jag då imperativa programspr&aringk.




    8 Minne som har tilldelats en applikation m&aringste g&oumlras fritt n&aumlr det inte l&aumlngre skall anv&aumlndas. Annars uppst&aringr minnesl&aumlckor, d. v. s applikationen f&aringr till slut f&oumlr lite tillg&aumlngligt minne f&oumlr att kunna forts&aumltta exekvera.




    9 Den korrekta ben&aumlmningen g&aringr under "Single assignment" och inneb&aumlr i princip att alla variabler &aumlr konstanter. Ett av de fr&aumlmsta syftet med detta &aumlr att man inte av misstag skall kunna tilldela en variabel ett felaktigt v&aumlrde.




    10 RACE st&aringr f&oumlr Research into Advanced Communications in Europe och &aumlr ett forum som skall stimulera forskning och utveckling av h&aringrd- och mjukvara.




    11 EriPascal &aumlr en vidareutveckling av Pascal som anv&aumlnds inom Ericsson.




    12 Anders syftar h&aumlr på en artikel i datateknik [4 ] d&aumlr begreppet "tv&aumlttmaskiner" tas upp f&oumlr att exemplifiera små apparater d&aumlr h&aringrdvaran skall vara liten och billig.




    13 TMOS st&aringr f&oumlr: Telecommunication Management and Operations Support och &aumlr ett programsystem som &aumlr avsett f&oumlr drift och underh&aringll av en AXE-v&aumlxel.




    14 Den r&aumltta ben&aumlmningen &aumlr på denna term &aumlr BIF och st&aringr f&oumlr - Built In Functions.




    15 Med h&oumlgre ordningens funktioner avses funktioner som inte enbart kan ta v&aumlrden s&aringsom heltal, flyttal, records etc som argument, utan som också kan l&aringta godtyckliga funktioner vara argument till andra funktioner.




    16 Den korrekta ben&aumlmningen &aumlr lazy evaluation. I deklarativa beskrivningar av vad en dator skall utf&oumlra finns inte n&aringgon angiven tidsordning mellan de olika operationerna. N&aumlr det kommer in ny information fr&aringn omv&aumlrlden till systemet så finns det olika s&aumltt att hantera detta på. Ett s&aumltt &aumlr att l&aringta datorn h&aumlrleda alla konsekvenser av den nya informationen genom att s&aumltta in den i alla uttryck d&aumlr den refereras. Denna strategi kallas forward chaining, datadriven evaluation. Vid lazy evaluation som &aumlr den andra extrempunkten, g&oumlrs inga ber&aumlkningar alls utom de som explicit efterfr&aringgas (d.v.s. det som kr&aumlvs f&oumlr att generera explicit beg&aumlrd utmatning ur systemet).




    17 Med "andra spr&aringk" avses huvudsakligen imperativa programspr&aringk.




    18 Det var knappast n&aringgon som n&aumlmnde att han anv&aumlnde Erlangs debugger f&oumlr att hitta fel i programkoden. Oftast beh&oumlvdes den inte f&oumlr att hitta felen eftersom det upplevs som ganska l&aumltt att hitta dessa. I de fall d&aumlr man hade anv&aumlnt debugger var man inte helt n&oumljd med denna. Ett v&aumllk&aumlnt faktum &aumlr annars att det &aumlr mycket sv&aringrt att testa programkod med parallellism. Detta beror delvis på att det &aumlr sv&aringrt att f&oumlja programmets "fl&oumlde".