Dynamische Programmiersprachen. David Schneider STUPS

Transkript

1 Dynamische Programmiersprachen David Schneider STUPS

2 Organisatorisches Aufbau: Vorlesung 2 SWS Übung Kurzreferat Projekt Prüfung

3 Übung wöchentliches Aufgabenblatt in 2er Gruppen zu bearbeiten (Pair-Programming) keine Pflichtabgaben jede Gruppe muss mind. 1 Lösung vorstellen Terminfindung

4 Kurzreferat Kurzreferat über eine Dynamische Programmiersprache Gruppen aus der Übung Themenverteilung nächste Vorlesung 10min Intro, Features Warum ist diese Sprache eine Dynamisches Sprache?

5 Projekt baut auf dem Interpreter aus den Übungen auf im Team zu bearbeiten Kriterien wie Testing, Dokumentation, Code- Qualität, Verwendung von DVCS, etc. werden bewertet. in der Vorlesungsfreien Zeit 20% der Note

6 Prüfung am Ende der vorlesungsfreien Zeit (Ende September) Form je nach Teilnehmerzahl

7 Überblick Dynamische Sprachen Außen Python, Smalltalk Objektorientierung Meta-Programmierung Innen Interpreter AST/Bytecode Garbage Collection

8 Ziel Eigenschaften von Dynamischen Sprachen lernen und verstehen Einblick in verschiedene Sprachen Lernen, wie Interpreter und VMs aufgebaut sind soziale Aspekte Dynamischer Sprachen kennen lernen

9 Why?

10 Sapir Whorf Hypothesis

11 Dynamic Languages

12 Dynamic Languages "The term dynamic programming language describes a class of programming languages that share a number of common runtime characteristics that are available in static languages only during compilation, if at all.[ ] T. Mikkonen and A. Taivalsaari, Using JavaScript as a real programming language 2007.

13 Dynamic Languages [ ]These behaviors can include the ability to extend the currently running program [ ] even by modifying the internals of the language itself, all during program execution. While these behaviors can be emulated in almost any language [ ] such behaviors are integral, built-in characteristics of dynamic languages. T. Mikkonen and A. Taivalsaari, Using JavaScript as a real programming language 2007.

14 Interactive (Some) Properties of Dynamic Languages Everything is an object Dynamic Typing Most things changeable at run-time Reflection Late-Bound Everything

15 (Some) Properties of Implementations Garbage Collected Interactive Interpreted

16 Interactive REPL (Read-Evalutate-Print-Loop) Type and immediately execute parts of programs

17 Everything is an Object Numbers, functions, classes, instances, lists, modules, etc. No distinction between primitives and "objects" All objects are manipulated the same way

18 Dynamic Typing Types not declared Types attached to values at run-time a = 1 a = "lorem ipsum" a = [1, 'a', 1.0] a = {'a': 1, 2: [1,2]}

19 Most Things Changeable at Run-Time Most things changeable at run-time, e.g.: The bindings All objects (classes, methods, modules ) Reflection: The way in which we can inspect (and change) the running program from within itself Non-modifying reflection is sometimes called introspection.

20 Late-Bound Everything Late Binding: The object that a variable name references can only be determined at run-time.

21 Garbage Collected Garbage Collection: No manual memory management

22 Interpretation Interpreter: Executes a program written in a language without compilation step AST/Bytecode

23 So What Defines a Dynamic Language? Dynamic Typing Everything is an object Interactive Runtime everything Interpreted Virtual machines Late binding Reflection Garbage Collected Duck typing

24 Technical and Social Rapid prototyping Consequences Ease of development Encourage testing Easy to use Simple deployment Coding to interfaces rather than to implementations

25 Examples Lua Python Javascript Perl Ruby Smalltalk Web-Applications Games/Scripting Automation Prototyping... PHP

26 How About? Prolog Java, C# Assembler Haskell, C++, Ada, ML, Pascal, Fortran, Cobol...

27

28 First release in 1991 Guido van Rossum Two relevant versions 2.7 and 3.4 Many Implementations: Reference CPython Alternative Jython, IronPython, PyPy

29 The Zen of Python (Extract) Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Readability counts. There should be one and preferably only one obvious way to do it. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. >>> import this

30 Tools for This Semester Python Documentation PIP: Virtualenv: DVCS: git: mercurial: