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.

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

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.

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.

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 ;)

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.

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!?