David Schneider STUPS

Dynamische
Programmiersprachen
David Schneider
[email protected]
STUPS - 25.12.02.50
Organisatorisches
•
Aufbau:
•
Vorlesung 2 SWS
•
Übung
•
Kurzreferat
•
Projekt
•
Prüfung
Übung
•
wöchentliches Aufgabenblatt
•
in 2er Gruppen zu bearbeiten (Pair-Programming)
•
keine Pflichtabgaben
•
jede Gruppe muss mind. 1 Lösung vorstellen
•
Terminfindung
Kurzreferat
•
Kurzreferat über eine Dynamische
Programmiersprache
•
Gruppen aus der Übung
•
Themenverteilung nächste Vorlesung
•
10min
•
Intro, Features
•
Warum ist diese Sprache eine Dynamisches Sprache?
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
Prüfung
•
am Ende der vorlesungsfreien Zeit (Ende
September)
•
Form je nach Teilnehmerzahl
Überblick
•
Dynamische Sprachen
•
Außen
•
•
Python, Smalltalk
•
Objektorientierung
•
Meta-Programmierung
•
…
Innen
•
Interpreter
•
AST/Bytecode
•
Garbage Collection
•
…
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
Why?
“Sapir–Whorf Hypothesis”
Dynamic Languages
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.
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.
(Some) Properties of
Dynamic Languages
•
Interactive
•
Everything is an object
•
Dynamic Typing
•
Most things changeable at run-time
•
Reflection
•
“Late-Bound Everything”
(Some) Properties of
Implementations
•
Garbage Collected
•
Interactive
•
Interpreted
Interactive
•
REPL (Read-Evalutate-Print-Loop)
•
Type and immediately execute parts of programs
Everything is an Object
•
Numbers, functions, classes, instances, lists,
modules, etc.
•
No distinction between primitives and "objects"
•
All objects are manipulated the same way
Dynamic Typing
•
Types not declared
•
Types attached to values at run-time
a
a
a
a
=
=
=
=
1
"lorem ipsum"
[1, 'a', 1.0]
{'a': 1, 2: [1,2]}
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.
“Late-Bound Everything”
•
Late Binding:
•
The object that a variable name references can
only be determined at run-time.
Garbage Collected
•
Garbage Collection:
•
No manual memory management
Interpretation
•
Interpreter:
•
Executes a program written in a language without
compilation step
•
AST/Bytecode
So What Defines a
Dynamic Language?
Runtime everything
Dynamic Typing
Interactive
Everything is an object
Virtual machines
Interpreted
Late binding
Garbage Collected
Reflection
Duck typing
Technical and “Social”
Consequences
•
Rapid prototyping
•
Ease of development
•
Encourage testing
•
Easy to use
•
Simple deployment
•
Coding to interfaces rather than to implementations
Examples
•
•
Lua
•
Web-Applications
•
Games/Scripting
Python
•
Javascript
•
Perl
•
Automation
•
Ruby
•
Prototyping
•
Smalltalk
•
...
•
PHP
How About?
•
Prolog
•
Java, C#
•
Assembler
•
Haskell, C++, Ada, ML, Pascal, Fortran, Cobol...
•
First release in 1991
•
Guido van Rossum
•
Two relevant versions 2.7 and 3.4
•
Many Implementations:
•
Reference CPython
•
Alternative Jython, IronPython, PyPy
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
Tools for This Semester
•
Python Documentation
•
https://docs.python.org/3/
•
https://docs.python.org/2/
•
PIP: https://pip.readthedocs.org/
•
Virtualenv: http://www.virtualenv.org/
•
DVCS:
•
git: http://git-scm.com
•
mercurial: http://mercurial.selenic.com