Dynamic Language Programming For The Statically Typed Programmer
Upcoming SlideShare
Loading in...5
×
 

Dynamic Language Programming For The Statically Typed Programmer

on

  • 1,177 views

Un programmatore di C# (statically typed language) che usa un Dynamic Language

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

Statistics

Views

Total Views
1,177
Views on SlideShare
1,172
Embed Views
5

Actions

Likes
0
Downloads
13
Comments
0

2 Embeds 5

http://www.linkedin.com 3
http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Dynamic Language Programming For The Statically Typed Programmer Dynamic Language Programming For The Statically Typed Programmer Presentation Transcript

  • Beyond .NET Dynamic Language Programming for the Statically Typed Programmer
  • Beyond .NET? • Bisogna essere più precisi – Beyond statically typed (“traditional”, “original”) .NET – Ma .NET è sempre lì – “Dynamic” è qualcosa in più 2 Marco Parenzan
  • Confronto Static Dynamic Languages Languages Robusto Semplice e stringato Interpretato Performante (no compilazione) Strumenti “implicitamente “intelligenti” tipizzato” Migliore scalabilità Meta-programming 3 Marco Parenzan
  • 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
  • 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
  • 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
  • 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
  • Beyond .NET Python e IronPython
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Easy introspection (reflection without the pain) • dir(BinaryOp) • dir(ops[0]) • dir(ops[1]) Marco Parenzan
  • Beyond .NET Perché usare IronPython?
  • 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
  • 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
  • Beyond .NET IronPython come uno scripting Language
  • 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
  • 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
  • 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
  • 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
  • Beyond .NET Alcuni esempi pratici
  • Hosting IronPython in .NET • Esempi – Valutazione di espressioni – Esecuzione di procedure – Invocazione di oggetti (dynamic in C# 4.0!) Marco Parenzan
  • 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
  • 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
  • Scripting in WPF • Personalizzare elementi di una tipica applicazione LOB • Oltre a personalizzare i report… • …gestire gli eventi CRUD Marco Parenzan
  • Domain Specific Languages • IronPython and DLR come backend per un linguaggio “verticale”, applicativo (appunto un DSL) Marco Parenzan
  • Beyond .NET Conclusioni
  • 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
  • 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
  • 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
  • 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