Un programmatore di C# (statically typed language) che usa un Dynamic Language http://codeisvalue.wordpress.com/2010/01/23/post-ugi-alt-net-conference/

1. Beyond .NET
Dynamic Language Programming
for the Statically Typed Programmer

2. Beyond .NET?
• Bisogna essere più precisi
– Beyond statically typed (“traditional”, “original”)
.NET
– Ma .NET è sempre lì
– “Dynamic” è qualcosa in più
2
Marco Parenzan

3. Confronto
Static Dynamic
Languages Languages
Robusto Semplice e stringato
Interpretato
Performante
(no compilazione)
Strumenti “implicitamente
“intelligenti” tipizzato”
Migliore scalabilità Meta-programming
3
Marco Parenzan

4. Le peculiarità di un Dynamic Language
• Semplice e stringato
– È una scelta tipica di chi ha sviluppato questi linguaggi
– Sintassi leggera
– Molte funzioni lasciate in API in linguaggi statici sono
implementate nel linguaggio
• Interpretato
– È la diretta conseguenza della semplicità, evitando la
“complicazione” di un processo di compilazione
• Implicitamente tipizzato
– Il tipo è associato ai valori, non alle variabili
– Non permettono di verificare e notificare gli errori di tipo
se non quando vanno in esecuzione
4
Marco Parenzan

5. Metaprogramming
• Il metaprogramming è la scrittura di un
programma in grado di scrivere o manipolare altri
programmi o se stesso
• Un metaprogramma effettua a tempo di
esecuzioni operazioni che sarebbero, in
condizioni normali, effettuate a tempo di
compilazione
• L'obiettivo del metaprogramming è quello di
produrre programmi in grado di adattarsi
dinamicamente ad una configurazione che
cambia nel tempo, senza intervento umano
5
www.xedotnet.org
Marco Parenzan

6. Alune definizioni
• Metaprogramma: il prodotto dell'atto di
metaprogramming
• Metalinguaggio: linguaggio utilizzato per
scrivere il metaprogramma
• Se il metalinguaggio ed il linguaggio di
programmazione coincidono, l'attività di
metaprogramming prende il nome di
reflection
6
www.xedotnet.org
Marco Parenzan

7. Quale scegliere?
• Due “generazioni” di linguaggi
– Nativi (con virtual machine proprietaria)
– Su Runtime (.NET o JVM)
• Alcuni
– Python (IronPython, Jython)
– Ruby (IronRuby, JRuby)
• Perché portare Python o Ruby su .NET o JVM?
– Py o Rb usano il runtime
– Py o Rb sono accessibli dal runtime (e questo è il
nostro caso)
7
Marco Parenzan

8. Beyond .NET
Python e IronPython

9. Cos’è Python?
• Un linguaggio di programmazione general purpose
• Sviluppato da Guido van Rossum nel 1991
• Un linguaggio dinamico usato spesso come linguaggio di scripting
• Supporta diversi paradigmi di programmazione:
– Object Oriented
– Imperative
– Functional
• È stato creato con questi obiettivi in mente:
– Leggibilità del codice
– Sintassi minimalista
– Un esteso set di librerie
– Duck Typing
9
Marco Parenzan

10. Cos’è IronPython?
• È una implementazione del linguaggio Python su piattaforma .NET
– IronPython è scritto interamente in C#
• Creato da Jim Hugunin
– sviluppatore anche di Jython (Python su JVM)
• Voleva scrivere un paper dal titolo “Why .NET is a Terrible Platform for
Dynamic Languages”
– “It was a little less than a year ago that I first started investigating the Common
Language Runtime (CLR). My plan was to do a little work and then write a short pithy
article called, "Why .NET is a terrible platform for dynamic languages”"
http://www.ironpython.com/old.html
• Nel settembre del 2004 iniziava a lavorare in Microsoft
– “My plans changed when I found the CLR to be an excellent target for the highly dynamic
Python language. Since then I've spent much of my spare time working on the
development of IronPython” http://www.ironpython.com/old.html
– http://www.python.org/community/pycon/dc2004/papers/9/
– http://conferences.oreillynet.com/presentations/os2004/hugunin_jim_up.ppt
10
Marco Parenzan

11. IronPython Performances (2004)
Test Descrizione Prestazione
parser (b0) heavy OO plus meta programming x1.1 faster
stacks (b1) handling of stack overflow x2.1 faster
PI (b2) using generators to compute π same
sorting (b3) many different comparsions and sorting x1.5 faster
parser2 (b4) reprise of parser with different input x1.2 slower
builtins (b5) testing unicode, complex numbers, … x2.3 slower
iterators (b6) – looping and overflow from int to long x1.2 faster
Python-2.3
OSCon 2004 – IronPython 0.6
1.7x faster than Python-2.3 on
IronPython
pystone
IronPython (Mono)
0 1 2 3 4 5 6 7 8 9 10 11 12
time (seconds)
b0 b1 b2 b3 b4 b5 b6
11
Marco Parenzan

12. Performances (2009)
• Performance Comparisons Test CPy2.6.1 IPy2.6
– http://ironpython.codeplex.com/wikipage Hello World 0.0655611s 2.1076478s
?title=IronPython%20Performance
• IronPython 2.6 Final PyStone 1.1 39239.6pys/s 55765.7 pys/s
– http://ironpython.codeplex.com/wikipage Richards 611.8 1400.05
?title=IP26FinalVsCPy26Perf&referringTitle
=IronPython%20Performance
12
Marco Parenzan

13. Performances (2009)
PyBench 2.0
Test IPy2.6 CPy2.6.1 Δ Test IPy2.6 CPy2.6.1 Δ
BuiltinFunctionCalls: 403ms 1737ms -76.8% Recursion: 559ms 2214ms -74.8%
BuiltinMethodLookup: 606ms 1835ms -67.0% SecondImport: 966ms 1248ms -22.6%
CompareFloats: 28ms 1075ms -97.4% SecondPackageImport: 1059ms 1313ms -19.3%
CompareFloatsIntegers: 403ms 1354ms -70.2% SecondSubmoduleImport: 1496ms 1724ms -13.2%
CompareIntegers: 27ms 853ms -96.9% SimpleComplexArithmetic: 605ms 1324ms -54.3%
CompareInternedStrings: 395ms 1237ms -68.1% SimpleDictManipulation: 2072ms 1094ms 89.4%
CompareLongs: 29ms 1071ms -97.3% SimpleFloatArithmetic: 495ms 1475ms -66.4%
CompareStrings: 477ms 1428ms -66.6% SimpleIntFloatArithmetic: 558ms 760ms -26.6%
CompareUnicode: 400ms 1188ms -66.3% SimpleIntegerArithmetic: 542ms 757ms -28.4%
ComplexPythonFunctionCalls: 2149ms 2574ms -16.5% SimpleListManipulation: 1384ms 911ms 51.9%
ConcatStrings: 5129ms 3004ms 70.7% SimpleLongArithmetic: 1075ms 1197ms -10.2%
ConcatUnicode: 3040ms 2602ms 16.8% SmallLists: 1464ms 1623ms -9.8%
CreateInstances: 839ms 2035ms -58.8% SmallTuples: 871ms 1429ms -39.1%
CreateNewInstances: 1121ms 1552ms -27.8% SpecialClassAttribute: 3210ms 1103ms 190.9%
CreateStringsWithConcat: 2880ms 1113ms 158.8% SpecialInstanceAttribute: 3865ms 1198ms 222.7%
CreateUnicodeWithConcat: 809ms 1250ms -35.3% StringMappings: 3055ms 2353ms 29.8%
DictCreation: 2276ms 1052ms 116.3% StringPredicates: 1346ms 1798ms -25.1%
DictWithFloatKeys: 2070ms 2956ms -30.0% StringSlicing: 1414ms 1522ms -7.1%
DictWithIntegerKeys: 1818ms 851ms 113.8% TryExcept: 260ms 573ms -54.6%
DictWithStringKeys: 1990ms 1043ms 90.7% TryFinally: 949ms 1808ms -47.5%
ForLoops: 562ms 658ms -14.6% TryRaiseExcept: 63930ms 1083ms 5805.3%
IfThenElse: 291ms 838ms -65.3% TupleSlicing: 2090ms 1517ms 37.8%
ListSlicing: 3713ms 1493ms 148.7% UnicodeMappings: 2059ms 949ms 117.0%
NestedForLoops: 640ms 1054ms -39.3% UnicodePredicates: 1391ms 1297ms 7.2%
NormalClassAttribute: 2961ms 1124ms 163.4% UnicodeSlicing: 1399ms 1737ms -19.5%
NormalInstanceAttribute: 3710ms 1030ms 260.3% WithFinally: 652ms 2199ms -70.4%
PythonFunctionCalls: 325ms 1647ms -80.3% WithRaiseExcept: 71699ms 1681ms 4164.4%
PythonMethodCalls: 3556ms 1866ms 90.6%
13
Marco Parenzan

14. Aggiornamento IronPython
al 23 gennaio 2010
• http://ironpython.codeplex.com/
• .NET 3.5sp1
– IronPython 2.6
• 11 dicembre 2009
• http://ironpython.codeplex.com/Release/ProjectReleases.as
px?ReleaseId=12482
• .NET 4.0 Beta 2
– IronPython 2.6 CTP for .NET 4.0 Beta 2
• 21 ottobre 2009
• http://ironpython.codeplex.com/Release/ProjectReleases.as
px?ReleaseId=28125
14
Marco Parenzan

15. Michael Foord
autore di IronPython in Action
• “Why IronPython?”
http://ironpython-urls.blogspot.com/2009/12/why-ironpython.html
– No type declarations
– First class and higher order functions
– No need for generics, flexible container types instead
– Protocols and duck-typing instead of compiler enforced interfaces
– First class types and namespaces that can be modified at runtime
– Easy introspection (reflection without the pain)
15
Marco Parenzan

16. No type declarations
• a = 10
• b = "10"
• a+b #fail
• a+int(b) #ok 20
• str(a)+b #ok '1010'
• a = "10" #ok
• a+b #ok '1010'
Marco Parenzan

17. First class and higher order functions
• def Somma(a, b):
• return a+b
• Somma(4,5) # = 9
• s = Somma
• s(4,5) # = 9
Marco Parenzan

18. No need for generics, flexible
container types instead
• class BinaryOp:
• def __init__(self, a, b):
• self.a = a
• self.b = b
• def Somma(self):
• return a+b
• ops = []
• ops.append(BinaryOp(2,4))
• ops.append(BinaryOp(5,5))
• ops.append(BinaryOp(8,2))
• for op in ops:
• print op.Somma()
Marco Parenzan

19. Protocols and duck-typing instead of
compiler enforced interfaces
• class CustomOps:
• def __iter__():
• yield new BinaryOp(3,5)
• yield new BinaryOp(4,3)
• yield new BinaryOp(2,5)
• for op in ops:
• print op.Somma()
Marco Parenzan

20. First class types and namespaces that
can be modified at runtime
• ## aggiungere un metodo alla classe
• def Differenza(self):
• return a-b
• BinaryOp.Differenza = Differenza
• ## aggiungere un metodo ad una specifica istanza
• import new
• def Moltiplica(self):
• return a*b
• ops[0].Moltiplica = new.instancemethod(Moltiplica, ops[0],
BinaryOp)
Marco Parenzan

21. Easy introspection
(reflection without the pain)
• dir(BinaryOp)
• dir(ops[0])
• dir(ops[1])
Marco Parenzan

22. Beyond .NET
Perché usare IronPython?

23. Bisogna accontentare il cliente
• Scrivere codice dopo il deployment
– On site
– Magari senza aprire Visual Studio
• Modifiche/personalizzazioni continue
• Il deployment è un problema
– Non siamo a “velocità ingegneristiche”
(tipicamente lente)
– Rilasci “non controllati”
23
Marco Parenzan

24. Specifiche (1)
• Complessità relativamente bassa
– Non si vuole sostituire il C# (Non me ne voglia la community dei
Dynamic Languages)
• Sostituire solo alcuni pezzi
– Mansioni accessorie e molto specifiche
• Mancanza di una propria interfaccia grafica
– Qui si può disquisire
– WPF è scripting
• Una certa linearità
– Il flusso di esecuzione viene sempre implementato nel core scritto in
C#
• Quando realmente serve?
– Formule, Codice di calcolo, Report (io uso librerie PDF), Import/Export
• Non siamo in condizioni di criticità per le performances
24
Marco Parenzan

25. Beyond .NET
IronPython come uno scripting
Language

26. IronPython DLR
• IronPython 1.0 ha “risolto” l’implementazione
del Python su .NET
• IronPython 2.0 ha “risolto” problematiche
valide per “tutti” i Dynamic Languages
implementabili
26
Marco Parenzan

27. Dynamic Languages on .NET
IronPython IronRuby C# VB.NET Others…
Dynamic Language Runtime
Expression Trees Dynamic Dispatch Call Site
Object JavaScript Python Ruby COM
binder binder binder binder binder

28. Aggiornamento IronRuby
al 23 gennaio 2010
• http://ironruby.codeplex.com/
• .NET 3.5sp1
– IronRuby 1.0 RC1 (0.9.3.0)
• 20 novembre 2009
• http://ironruby.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=35312
– IronPython binaries for ironruby-1.0 RC1 interop (0.9.3.0)
• 20 dicembre 2009
• http://ironruby.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=35312
#DownloadId=97919
• .NET 4.0 Beta 2
– IronRuby CTP for .NET 4.0 Beta 2
• 21 ottobre 2009
• http://ironruby.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=35312
#DownloadId=97919
28
Marco Parenzan

29. Aggiornamento DLR
al 23 gennaio 2009
• http://dlr.codeplex.com/
• .NET 3.5sp1 e .NET 4.0 Beta 2, solo src
– 22 ottobre 2009
– http://dlr.codeplex.com/Release/ProjectReleases.
aspx?ReleaseId=34834
29
Marco Parenzan

30. Beyond .NET
Alcuni esempi pratici

31. Hosting IronPython in .NET
• Esempi
– Valutazione di espressioni
– Esecuzione di procedure
– Invocazione di oggetti (dynamic in C# 4.0!)
Marco Parenzan

32. Querying with IronPython
• Interrogare un database tramite IronPython
• EntityFramework può venire in aiuto
• Può essere utile come file batch per fare
import/export di dati
Marco Parenzan

33. Reports with IronPython
• Preferisco usare librerie PDF invece di
reporting services
• Aggiungere un campo in un report è una cosa
comune
• Farlo “on-site” senza aprire Visual Studio è
meglio
Marco Parenzan

34. Scripting in WPF
• Personalizzare elementi di una tipica
applicazione LOB
• Oltre a personalizzare i report…
• …gestire gli eventi CRUD
Marco Parenzan

35. Domain Specific Languages
• IronPython and DLR come backend per un
linguaggio “verticale”, applicativo (appunto un
DSL)
Marco Parenzan

36. Beyond .NET
Conclusioni

37. Conclusioni
• Necessità dello scripting
– Risolvere il problema delle personalizzazioni c/o il cliente
• Risolto?
– È un gran bel passo avanti
– Ma è probabilmente meglio un DSL (con backend il DLR)
• Credenza di fondo
– Scelgo di usare ANCHE un altro linguaggio
• “Polyglot programmer”
– Accetto il “compromesso” del “dinamico”
• Attingere ad un parco di implementazioni (tutte open
source) eccezionale in maniera nativa (non interop)
– Ruby on Rails
37
Marco Parenzan

38. Il team che lavora sul DLR e dintorni
• Jim Hugunin (DLR) » Dave Fugate (IronPython)
– Blog: http://blogs.msdn.com/hugunin/ • Blog: http://knowbody.livejournal.com/
• Dino Viehland (IronPython) • Twitter: http://twitter.com/davefugate
– Blog: » Harry Pierson (Evangelist)
http://blogs.msdn.com/dinoviehland/
• Blog: http://www.devhawk.net/
– Twitter:
http://twitter.com/DinoViehland • Twitter: http://twitter.com/DevHawk
• Jimmy Schementi (Silverlight » Seo Sanghyeon (IronPython)
integration) • Blog: http://fepy.blogspot.com/
– Blog: http://blog.jimmy.schementi.com/ • Twitter: http://twitter.com/sanxiyn
– Twitter: http://twitter.com/jschementi » Jim Deville (IronRuby)
• John Lam (IronRuby) • Blog: http://blog.jredville.com/
– Blog: http://www.iunknown.com/ • Twitter: http://twitter.com/jredville
– Twitter: http://twitter.com/john_lam/ » Shri Borde (IronRuby)
• Curt Hagenlocher (IronPython) • Blog: http://blogs.msdn.com/shrib/
– Blog: http://blogs.msdn.com/curth/ » Tomas Matousek (IronRuby)
• Blog: http://blog.tomasm.net/
38
Marco Parenzan

39. Autori
• Michael Foord
– Libro: http://www.manning.com/foord/
– Blog: http://www.voidspace.org.uk/python/weblog/index.shtml
– Twitter: http://twitter.com/Voidspace
• Ivar Porto Carrero
– Libro: http://www.manning.com/carrero/
– Blog: http://flanders.co.nz/
– Twitter: http://twitter.com/casualjim
39
Marco Parenzan

40. Grazie
Q&A
blog: http://blog.codeisvalue.com/
email: marco.parenzan@libero.it
web: http://www.codeisvalue.com/
Skype: marco.parenzan
Messenger marco.parenzan@live.it
Twitter: marco_parenzan 40