Programmeringsbloggen
Du må beherske et dynamisk språk
Skriv en kommentar
Jeg vil si det så sterkt: Hvis du ikke behersker et dynamisk programmeringsspråk, slik at du er i stand til å designe fullverdige software-løsninger i det, da er du ikke en ferdig utdannet utvikler! [1]
Det har vært mye buzz rundt dynamiske språk de siste årene, og mange utviklere, spesielt i Agile-miljøer, migrerer over fra statiske språk til dynamiske. For å forstå hvorfor dette skjer er det viktig å vite hva vi mener med et dynamisk språk, og hvilke fordeler og ulemper det bringer med seg. Denne artikkelen er en god start for deg som ikke vet så alt for mye om temaet.
Hva mener vi med Dynamic?
Når vi sier at noe er STATIC mener vi at ting er definert og avgjørelser tas ved compile-time, mens DYNAMIC impliserer at det samme skjer i runtime. Det er derimot ingen språk som er fullstendig statiske, og heller ingen som er fullstendig dynamiske – de fleste språk befinner seg et sted mellom disse ytterpunktene.
Egenskaper som gjør et språk dynamisk er ting som dynamisk typing, dynamisk dispatch, introspection, dynamisk kompilering og dynamisk loading. I språk som er mer dynamiske kan man f.eks. gjøre ting som å endre hvordan typer ser ut – legge til metoder o.l. – mens programmet kjører.
De dynamiske spåkene begynte for alvor å vokse frem på 80-tallet – og språk som Larry Wall’s Perl og Guido van Rossum’s Python hadde stor betydning for internetts vekst på 90-tallet. De dynamske egenskapene hadde derimot en ulempe: Dårlig performance! Grunnen til at de dynamiske språkene har blitt mer populære de siste 10 årene er at vi nå har fått raskere og bedre maskinvare, som gjøre at vi i mange sammenhenger kan se bort fra at programmene kjører noe tregere relativt til kompilert, statisk kode.
Mange språk utvikler seg i dynamisk retning
Programmeringsspråk utvikler seg hele tiden. De som ikke gjør det er i praksis døde. Og samtidig som dynamiske språk som Perl, Python og Ruby har blitt mer populære, har andre språk beveget seg i en mer dynamisk reting.
C# har for eksempel en rekke dynamiske egenskaper. Du lager dynamiske programmer om du bl.a. benytter deg av reflection (introspection). Det er bare det at reflection er mye enklere i språk som i utgangspunktet er designet for det. Generics er også en nokså dynamisk feature, som gir inntrykk av løsere typing i koden. Type inference – bruk av “var” – gir C# en dynamisk følelse. Og sist men ikke minst innfører man i .NET 4.0 Dynamic, en type hvor metodekall ikke evalueres før runtime (dynamic dispatch), slik at C# bedre kan kommunisere med mere dynamiske språk.
Ved å beherske et dynamisk språk vil man lære seg teknikker som gjør en til en bedre utvikler også når man jobber i mere statiske språk.
PS: Det dynamiske språktreet er ikke komplett, men viser de mest sentrale språkene, og hvordan de i hovedsak har påvirket hverandre.
Fordeler ved dynamiske språk
Jeg mener vi må innse at både statiske og dynamiske språk er viktige. Statiske språk gir en høy grad av kontroll – det er lettere å analysere koden og forutse hva som vil skje i runtime. Det er derimot vist gjentatte ganger at dynamiske språk gjør deg mere produktiv; man kan implementere mer funksjonalitet raskere, og med mindre kode.
Dynamiske språk er også mer fleksible, smidige om du vil, og egner seg til problemer hvor løsning i utgangspunktet er ukjent. Flere velger derfor å prototype i dynamiske språk, for så å implementere endelig løsning i et mere statisk språk om performance og sikkerhet er viktig.
En annen ting man oppdager når man går fra statisk til dynamisk programmering er at skillet mellom data og kode opphører – data og funksjonalitet smelter bedre sammen. Det er litt vanskelig å forklare dette uten et dypdykk, så jeg tror det må bli en fremtidig blogpost.
Et siste område hvor dynamiske språk egner seg spesielt godt er embedding. Sett at du skal utvikle et system hvor det meste skal være fast, og egner seg for et statisk språk. Men du ser at det kan bli behov for å kunne endre visse forretningsregler etter at systemet er tatt i bruk. Tradisjonelt vil man forsøke å forutse disse endringene, og lage et innfløkt konfigurasjonssystem for å dekke behovet. I stedet kan man utvikle selve systemet i C#, men kode forretningsreglene i et dynamisk språk. Den dynamiske koden vil evalueres når den behøves, og kan når som helst endres og utvides uten at man behøver å rekompilere og publisere en ny versjon.
I ytterste konsekvens kan man eksponere et API internt i applikasjonen som de dynamiske kodesnuttene kan få tilgang til – man har da laget et scriptbart system, og man kan lene seg tilbake og se på mens tredjepartsutviklere utvider funksjonaliteten i systemet ditt i retninger du selv ikke kunne ha forrutsett.
Er dynamisk kode bedre enn statisk?
Det kan hevdes at dynamiske språk oppfordrer deg som utvikler til å skrive bedre kode. Et sentralt poeng er at man ikke har en kompilator å støtte seg på, og viktigheten av enhetstester er derfor mye større. I “de dynamske miljøene” er man også mer opptatt av eleganse og enkel kode. Gjennom å praktisere dynamisk kode vil du øke forståelsen av hva kvalitet er for noe, og det vil forbedre din statiske kode også.
Den andre siden av dette er at man ikke lenger har tilgang på mange av de verktøyene man har vendt seg til som f.eks. C#-utvikler: intellisense, god refakturerings-støtte, statisk analyse osv. Visual Studio, ReSharper o.l. gjør oss produktive, og det er en viss overgang å ikke ha disse lengre – man kan føle seg litt naken en stund.
Videre lesing
Til slutt har jeg funnet frem et par “research papers” for dem som er interessert i utviklingen av dynamiske språk.
The End of the Cold War Between Programming Languages:
“Static typing is a powerful tool to help programmers express their assumptions about the problem they are trying to solve and allows them to write more concise and correct code. Dealing with uncertain assumptions, dynamism and (unexepected) change is becoming increasingly important in a loosely couple distributed world. Instead of hammering on the differences between dynamically and statically typed languages, we should instead strive for a peaceful integration of static and dynamic aspect in the same language. Static typing where possible, dynamic typing when needed!”
On the Revival of Dynamic Languages:
“The programming languages of today are stuck in a deep rut that has developed over the past 50 years. Although we are faced with new challenges posed by enormous advances in hardware and internet technology, we continue to struggle with old-fashioned languages based on rigid, static, closed-world file-based views of programming.”
Fotnote:
[1] Jeg hevder ikke at jeg vet når du kan kalle deg ferdig utdannet – bare at det å beherske et dynamisk språk må inngå i den definisjonen. Joe Armstrong, utvikleren av Erlang, sier f.eks. at det tar 30 år å lære å programmere (i boken Coders at Work).
Referanse:
Randal exploring dynamism (InfoQ)
Kategorier: .net ninja, Polyglot.
RSS feed for kommentarene.
Tilbaketråkk.
March 3rd, 2010 at 10:28 am
En kommentar til dette: “…behov for å kunne endre visse forretningsregler etter at systemet er tatt i bruk.”
Du vil ha et problem med sikkerhet når du legger forretningsregler i et dynamisk språk. Det er ingenting som stopper en som vil “hacke” forretningsreglene!?
March 3rd, 2010 at 10:52 am
Muligheter == Mulighet for missbruk. Ta f.eks. Excel, som er en scriptbar applikasjon. De fleste vet at man ikke skal åpne regneark som inneholder scripts fra kilder som man ikke stoler på – det kan få følger..
Mye av arbeidet man normal gjør når man skal embedde scipting-mulighet i en app er å begrense hva scriptene får lov til å gjøre. Man definerer opp et begrenset API, og lar sciptene leve i en sandbox, slik at de ikke kan gjøre for mye galt. Scriptene kan også parses og valideres. Men om systemet skal være fleksibelt må man heller ikke begrense for mye.
Poenget er at man gir kvalifisert personell, og ikke hvem som helst, tilgang til å omdefinere forretningsreglene. Hvem det er avhenger av hva det er for en app.
March 3rd, 2010 at 10:57 am
Veldig bra og lærerik blog, T-man! Skal videreformidle budskapet her.
DOG: Interessant nok er den gode gamle debatten om “separere forretningsreglene fra applikasjonen” debatten fortsatt sterkt levende. I management consulting bransjen skal dette løses med BPM (Business Process Management), hvor verktøy tillater forretningsutviklere å dra opp forretningsreglene. når forretningsreglene er lagret, kan utviklere koble seg til de forretningsreglene som er laget og integrere forretningsreglene til resten av applikasjonen. MAO et rent alternativ til det du skriver at dynamiske språk kan gjøre.
Jeg liker veldig godt tanken, spesielt i store produksjonsmiljøer, og ha evnen til raskt kunne endre viktige forretningsregler eller forretningsparametre, gjerne som en del av en læringsprosess (“hvor mye selger vi hvis vi tilbyr DETTE sammen med DETTE”?) uten å måtte gå gjennom store produksjonssettinger umiddelbart.
Men hold et øye åpent på at flere sider i IT bransjen vil prøve å løse samme utfordring på vidt forskjellige måter, og utviklerne og prosjektlederne vil nok en gang havne i kryssilden fordi en uviten ekstern konsulent har anbefalt ledelsen å gå en helt annen vei ;)
March 3rd, 2010 at 11:13 am
“MAO et rent alternativ til det du skriver at dynamiske språk kan gjøre”
Tja, eller BPM er et eksempel på et dynamisk system – som kan la seg implementere i språk som er mer eller mindre dynamiske, og hvor det vil være enklest å bruke et mer dynamisk.
Som jeg forsøkte å påpeke er det ingen harde definisjoner her, men glidende overganger. Vi skiller f.eks. ofte mellom kompilerte språk og tolkede (interpreted) språk, men heller ikke her er det så svart/hvitt. C# f.eks. kompileres først til CIL-kode, som så tolkes (JIT-kompileres) i den virtuelle maskinen (som i praksis er en interpreter).
På samme måte kan man betrakte et statisk program som tolker forretningsregler i form av konfigurasjon/data som en interpreter for det “språket” som konfigurasjonen utgjør.
March 5th, 2010 at 10:36 am
[...] Sett at jeg har overtalt deg til å lære dynamisk programmering, f.eks. da du leste artikkelen om at du MÅ beherkse et dynamisk språk. Spørsmålet du stiller deg da er: Hvilket språk skal jeg velge? Og jeg hjelper deg gjerne med det også. [...]
March 5th, 2010 at 10:51 am
Nok en flott blog post!
Ang. embedding av dynamiske språk for å legge til støtte for skripting/rask endring av forretningsregler så syns jeg dette er en veldig god use-case. Alt for ofte vil papirarkitekter kjøpe dyre løsninger som BizTalk og regelmotorer for å løse noe som enkelt kunne vært gjort ved hjelp av dynamisk lasting av skript. I organisasjonen jeg jobber i nå er dessverre ikke tiden det tar å endre reglene som er utfordringen, men tiden det tar å få akseptsansetestet og rullet ut endringene. Men det er et problem med organisasjonen, ikke teknikken.
Pga. enkelheten til å endre, og enkelheten til å implementere DSL’er gjør og at dynamiske språk er mye brukt i finansverden (aksjetrading), og jeg at blant annet JP Morgan kjører systemer for automatisk kjøp/slag basert på Python kode.
Når det gjelder sikkerhet er ikke utfordringene her særlig annerledes enn generelle sikkerhetsutfordringer. Har du en regelmotor må du sikre hvem som har tilgang til å laste opp nye regler. Leser du konfigurasjon av logikk fra databasen må databasen sikres. Brukes du BizTalk må BizTalk serveren sikres. Dessuten gir .NET deg en “falsk sikkerhet” om du tror .NET assemblies ikke kan endres. Dersom du ikke signerer koden din (strong naming) kan du enkelt dekompilere en .NET assembly, endre koden, rekompilere, legge DLL’en tilbake i BIN mappa og vips vil den lastes under kjøring av applikasjonen. Så er du bekymret for dette så må du huske å signere koden din!
Ang “Det kan hevdes at dynamiske språk oppfordrer deg som utvikler til å skrive bedre kode”, og “I “de dynamske miljøene” er man også mer opptatt av eleganse og enkel kode.” er nok en sannhet med modifikasjoner. Det avhenger helt hvilken del av miljøet du følger med på, og hvem du snakker med. I det siste har mange begynt å snuse på dynamiske språk pga. elegansen til Ruby og rammeverk som Rails, og pga. mange “superstjerner” som Robert Martin anbefaler språk som Ruby på det sterkeste. Men som du selv poengterer finnes der mange språk. Tar du f.eks PHP finnes der enorme mengder kode som vil få mang en programmerer til å gråte, og det samme gjelder JavaScript. Et godtordtak er at “du trenger ikke sterk typing, du trenger sterk testing”, og at “kompilatoren er bare en av mange enhetstester”. Så fokus på TDD gjør det mulig å skrive større kodebaser i dynamiske språk uten å samtidig introdusere mer feil enn i en statisk kodebase. Så i det henseende er det et gyldig poeng at du blir en bedre utvikler, siden du nesten blir “tvunget” til å gjøre TDD (den kanskje viktigste praksisen vi har som utviklere).
En annen utfordring med dynamiske språk er navigering i store kodebaser. Dette gjelder ikke alle språk, men f.eks JavaScript er notorisk vanskelig når du får stort volum. Av den grunn skriver f.eks både Microsoft og Google kode i Script# (C#) og Google Web Toolkit (Java) hvor du skriver koden din i statisk Java/C# (pga. oversikt, TDD, refaktorering) og så kompilerer koden ned til JavaScript.
December 8th, 2011 at 2:04 pm
Vent litt… Ga Lisp opphav til PERL?
De er jo litt… Forskjellige skal man si?
Uansett, ville bare nevne at selv om C# lar deg bruke dynamisk typing finnes det også språk som går andre veien. Common Lisp lar deg for eksempel type variablene.
Fant bare en kjapp pdf som viser eksempler på dette, og jeg advarer at filen inneholder spor av parenteser. :)
http://www.iaeng.org/IJCS/issues…/IJCS_32_4_19.pdf
December 8th, 2011 at 2:24 pm
Haakon, Lisp har vel strengt påvirket alle språk som har kommet til siden. Lisps innflytelse er uten sidestykke etter min oppfattelse. Men det er selvsagt mange andre språk som også har vært med på å “skape” Perl. F.eks. burde det kanskje ha gått en pil ned fra Smalltalk til Perl også…
Får en 404 på linken din. Men det samme finner du f.eks. i Clojure (type hints), hvor man normalt ikke spesifiserer type, men har mulighet til det – typisk for å øke performance.