Lehrstuhl Informatik II   
Sprachen und Beschreibungsstrukturen      
   Home Lehre Wintersemester 14/15 Seminare Höllische Programmiersprachen login

Höllische Programmiersprachen

Dozent:Dr. Michael Petter
Ort/Zeit:19,/20. Januar 2015
ModulNummer:IN0013 IN0014 IN2107
Beschreibung:    In diesem Proseminar/Seminar werden diverse Programmierkonzepte betrachtet. Dabei sollen die Charakteristiken und v.a. die "höllische" Umsetzung einiger Programmierkonzepte in einzelnen Sprachen herausgearbeitet werden.

Vorbesprechung: 30. Juni 2014 14:00 in Raum MI 02.07.034

Vorbereitungstreffen am 13.10.2014 um 16:00 in Raum MI 02.07.014 -> Aufzeichnung

 

Vorbemerkung

Generell ist diese Durchführung dieses Seminar so organisiert, dass Sie einen Eindruck vom Ablauf bei Konferenzen in Theoretischer Informatik bekommen. Das bedeutet, dass wir hier zuerst den Aufsatz anfertigen. Dieser Aufsatz wird im nächsten Schritt von ihrem Betreuer und zwei ihrer Mitstudenten einem Review-Prozess unterzogen, bei dem Sie Feedback zur Verbesserung ihres Aufsatzes erhalten. Mit diesen Verbesserungen werden Sie dann ihre Folien vorbereiten, die wir dann alle gemeinsam an 2 aufeinanderfolgenden Tagen präsentieren können.

Als kleiner Anreiz wird es zwischen beiden Tagen voraussichtlich einen Kaminabend im Stil eines Konferenz-Dinners geben, bei dem Gelegenheit besteht, mit ihren Kollegen, den Betreuern und interessierten externen Industrie-Partnern über die Themen des Tages und weiterführendes zu unterhalten.

Themenliste

Die Themen dieses Seminars sind jeweils Phänomene, so wie sie in verschiedenen praktischen Programmiersprachen vorkommen, und die in der Praxis teilweise erhebliche Auswirkungen auf Wartbarkeit, langfristige Betreuung der Sprachplattform und Neuentwicklung von Werkzeugen haben. Zu jedem dieser Phänomene gibt es mindestens eine Sprache, aus der man sich für Beispiele bedienen kann.

vorläufige Themen:
  1. Union/Redefine
    Sprachmechanismus zur Konvertierung und/oder Selektion von struturierten Daten; es ergeben sich Probleme mit der Analyse von Seiteneffekten, Aliasing und toten Bereichen.
    tritt auf in Cobol, PL/1, Natural und C
  2. Multistage Programming via Präprozessor
    Multistage Programming erlaubt es Programmcode mit Hilfe von Programmen zu erstellen, die konzeptuell eine Stufe (Stage) über dem Ursprungsprogramm angesiedelt sind.
    tritt auf in PL/1 und C
  3. Keyword-Identifier / Type-Identifier Mischung
    IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF;
    tritt auf in PL/1 und C
  4. API als Syntax vs. Bibliotheken
    Sprachdesign kann grundlegende Funktionen entweder direkt als Sprachkonstrukte vorsehen, oder einen generischen Mechanismus zum Auslagern dieser Funktionen in Bibliotheken vorsehen. Legacy Sprachen gehen oft den Weg über direkte Sprachkonstrukte - teilweise sogar mit Funktionsaufrufen auf der linken Seite der Zuweisungen!!!???
    tritt auf in Cobol,ABAP, PL/1
  5. Piggy-Backing Sprachen
    Verweben von verschiedenen Sprachen zu einer Anwendung bietet Raum für eine Vielzahl an Problemen
    tritt auf in EJB, PHP/HTML/CSS/JavaScript, EmbeddedSQL
  6. Typsystem vs. Laufzeitimplementation
    Oft bestimmt in einer Hochsprache das Typsystem die verwendbaren Programmiertechniken - in manchen Fällen jedoch kann das Laufzeitsystem dieses Niveau nicht mithalten, was sich dann an manchen stellen wieder hässlich auf die Hochsprachenmöglichkeiten auswirkt.
    tritt auf in Cobol, Java, Scala
  7. Error-Handling mit Sprachkonstrukten
    Longjumps, on-Handlers, Exceptions, Options/Maybe im Vergleich
    tritt auf in PL/1, C und C++
  8. Sprachevolution vs. Konsistenz
    Über die Jahre hinweg wachsen Sprachen um Features an, oder werden von Compiler zu Compiler in unterschiedlichen Dialekten interpretiert. Dies bewirkt oft Veränderungen im Konzept dieser Sprachen. Abwärtskompatibilität mit früheren Versionen dieser Sprachen erzwingt bei solchen Paradigmen dann oft Inkonsistenzen, die Programmierer im besten Fall irritieren, im schlimsten Fall eine erhebliche Fehlerquelle darstellen.
    tritt auf in C, C++, Java, Cobol, PHP
  9. Callbacks & Event Handlers
    Callbacks sind gerade in GUI-Programmen, aber z.B. auch in DOM-Parsern oder z.B. in Node.js ein beliebtes Strukturierungsmittel. Oftmals kaskadieren diese Handler-lastigen Konstrukte, so dass das Programmieren mehr den guten alten GOTOs als wirklich strukturieren Programmiersprachen entspricht, und der Code zur "Callback-Hell" mutiert. Ein Lösungsansatz könnte Functional Reactive Programming sein?
    tritt auf in vielen Sprachen, C(++), Java, etc ... Neuer Vorschlag: Elm
  10. Semicolons
    Semicolons sind ein weit verbreiteter Mechanismus um Statements eindeutig zu trennen. Viele Sprachen machen Semicolons allerdings optional, was immer weider Verwirrung stiftet. Manche Sprachplattformen bieten dabei aber Unterstützung, in dem z.B. Normalisierungstools angeboten werden, und Strichpunkte automatisch ergänzt werden...
    tritt auf in BCPL, Cobol, JavaScript und Go
  11. Speichermanagement
    Garbage Collection, Reference-Counting und Manual memory management sind verschiedene Abstraktionsstufen für die Verwaltung von freiem und benutztem Speicher in Programmiersprachen. Die Auswirkungen der verschiedenen Management-Paradigmen beeinflußen die Eigenschaften von Programmiersprachen enorm, von Laufzeitverhalten, Entwicklungsgeschwindigkeit bis hin zur Robustheit.
    tritt auf in C/C++,Objective-C, Java
  12. Statisches vs. konfigurierbares Dispatching
    Methodenaufrufe funktionieren in fast allen Sprachen über den Bezeichner dieser Methode - doch was sich hinter diesem Bezeichner verbirgt, wird bei verschiedenen Programmiersprachen unterschiedlich bestimmt. Von Pointerarithmetik über virtuelle Methoden, Dispatch-Tabellen und frei überschreibbare Dispatching-Methoden reicht das Angebot sehr weit; und damit auch die Möglichkeiten für Fehler und Komplikationen bei der Analyse solcher Programme...
    tritt auf in C++, Objective-C,Lua
  13. Typen in JavaScript
    Typen in Sprachen wie JavaScript sind rein optional - warum also Typen verwenden, wenn man sich dazu Gedanken machen muss?
    tritt auf bei JavaScript, Emscripten/C
  14. Mutable vs. Immutable Types, Pure vs. Impure
    Für Java-Programmierer erscheinen im ersten Eindruck immutable Typen (wie z.B. Strings) umständlich und fehlerträchtig - warum also immutable Datentypen? Und wie sinnvoll ist eine Programmiersprache wie Clojure, deren Grundprinzip ist, dass alle Objekte immutable sind?
    tritt auf bei z.B. Java vs. Clojure, Software Transactional Memory
  15. Das Liskov-Substitutionsprinzip und verhaltensbasierte Vererbungsrelationen
    Invarianten in Typen und Grenzen der herkömmlichen Typhierarchien in objektorientierten Sprachen, Design-By-Contract und
    tritt zum Beispiel auf bei Java, D, Eiffel, Ada 2012
  16. Parallelität mit Aktoren
    Herkömmliche Parallelprogrammierung mit Threads und Locks, Semaphoren und Monitoren ist nicht nur komplex und Fehlerträchtig, sondern auch mühsam für manche Anwendungszwecke. Auswege für hochparallele Systeme versprechen aktorenbasierte Sprachen wie Erlang oder Akka!
    tritt auf bei Erlang/Akka
  17. Determinismus und Verlässlichkeit bei paralleler Programmierung
    Bei herkömmlichen parallelen Programmen entstehen durch Races schwer zu findende Fehler - wenn man verlässliche Ergebnisse erhalten möchte sind daher Threads und gemeinsamer Speicher nur bedingt geeignet. Ein Ausweg aus dieser Klemme bieten neue Ideen wie z.B. LVars, bei denen spekulativ parallelisiert wird, und durch gemeinsame LVars/LVish sichergestellt wird, dass nur Berechnungen ohne Races als valide Ergebnisse interpretiert werden.
    tritt auf bei Haskell/LVars
  18. Das Debugging-Dilemma
    Fehler können bei der Softwareentwicklung nicht ausgeschlossen werden; selbst der beste Programmierer hat einfach nur eine statistisch kleine Fehlerquote, die dennoch nicht 0 ist. Die gängige Praxis, Fehler durch einen einfachen Test oder Debugger zu entdecken ist aber in Settings wie Lazy-Evaluation, parallelen Programmen und generell nicht-deterministischen Linearisierungen von Programmen ungeschickt, da die Chance, den Fehler auf dem quasi-zufälligen Ausführungspfad zu finden eher gering ist. Um daher systematisch Fehler auszuschließen sind andere Maßnahmen eher adäquat.
    tritt auf in allen Programmiersprachen, wird angegriffen von Unit-Tests, Integration Tests, Coverage-Analysen, Whitebox-Fuzzing, algorithmic/declarative Debugging, statische Analyse und formale Verifikation, Model-Checking, uvm

Sem.-Thema Student Betreuer Sem.-Thema Student Betreuer
1. Union/Redefine...
Hefele  Müller 2. Multistage... Somogyl
Müller
3. Keyword-Identifier....
Höschl
Schlegel
4. API vs Bib .... Siglreithmaier
Schlegel
5. Piggybacking....
fällt aus
Schulze Frielinghaus
8. Sprachevolution vs. Konsistenz.... Schneider
Petter
11. Speichermanagement... Haslbeck Palenta
7. Error-Handling... Urban
Herz
6. Typsystem vs. Runtime....
Müller Vogler
10. Semicolons... Reindl Petter
9. Callbacks & Events.... Robl Mihaila  




 

 

Mastersem.-Thema Student Betreuer Mastersem.-Thema Student Betreuer
16. Aktoren
fällt aus
Herz
17. LVars
Arias
Palenta
18. Debugging Dausch
Mihaila
14. Immutable & Pure
Heckmeier
Schulze Frielinghaus
15. Verhaltensvererbung
Roith
Petter
13. Optionale Typen
Lux
Vogler



12. Dispatching.... Vogl
Petter







Vorläufige Termine
  • direkt nach der Themenvergabe: Einarbeitung, Literatur-/Dokumentationsrecherche
  • regelmässige Treffen mit dem Betreuer, um Gliederung, Ausarbeitung und Vortrag zu erstellen
  • Milestone 27.10.2014: Gliederung der Ausarbeitung an den Betreuer senden
  • Milestone 18.12.2014: fertige Fassung der Ausarbeitung (ca. 10 Seiten) an den Betreuer senden
  • Milestone 24.12.2014: Abgabe der Reviews
  • Milestone 16.01.2015: endgültige Fassung der Vortragsfolien an den Betreuer senden
  • Anwesenheitspflicht!
  • Wir erwarten neben dem Vortrag und der Anfertigung der Ausarbeitung auch die aktive Beteiligung an den Diskussionen im Anschluß an die Vorträge!
Vorlagen


angehängte Dateien:

    vortrag.pdf
    01unionRedefine.pdf
    02multistage.pdf
    03keywordIdentifier.pdf
    04apiVsBib.pdf
    06typsysteme.pdf
    07errorHandling.pdf
    08sprachevolutionKonsistenz.pdf
    09callbacks.pdf
    10semicolons.pdf
    11speichermanagement.pdf
    12dynamischesDispatching.pdf
    14immutablePure.pdf
    15verhaltensvererbung.pdf
    18debugging.pdf
    13optionaleTypen.pdf
    17lvars.pdf

TUM - Lehrstuhl Informatik II (Sprachen und Beschreibungsstrukturen) Thanks: Tango and TinyMCE     Generationszeit: 10 ms