Was sind Programmierparadigmen und Kontrollstrukturen?

Gründe die P-Veranstaltungen zu besuchen?

Kontrollstrukturen:

- If, Cond, case, for-Schleifen, while-schleifen usw.

Paradigmen:
- Imperatives, Deklaratives, Applikatives, Objektorientiertes Programmieren usw.

Du hast noch funktionale Programmierung vergessen.

Ganz nett zu wissen ist dazu auch noch, dass Programmiersprachen selten nur einem Paradigma folgen. Objectorientierte Programmierung zB ist in Java, Scheme oder C++ immer mit funktionalen oder imperativen Elementen versetzt.

Sprachen werden aber durchaus dafuer ausgelegt, dass man moeglichst in eindeutigen Paradigmen programmiert.

Desweiteren ist es ratsam, wenn man ein Programm schreibt, sich zu ueberlegen, nach welchem Paradigma man es machen moechte. Das macht den Code leichter lesbar.
Und man sollte natuerlich moeglichst viele Paradigmen schon einmal gesehen haben, sonst bekommt man schnell schwierigkeiten fremden code zu verstehen.

MoKrates

Du hast noch funktionale Programmierung vergessen.

Nein. Seine Aufzaehlung endete mit drei Puenktchen…

Du hast noch funktionale Programmierung vergessen.

Ganz nett zu wissen ist dazu auch noch, dass Programmiersprachen selten nur einem Paradigma folgen. Objectorientierte Programmierung zB ist in Java, Scheme oder C++ immer mit funktionalen oder imperativen Elementen versetzt.

Sprachen werden aber durchaus dafuer ausgelegt, dass man moeglichst in eindeutigen Paradigmen programmiert.

Desweiteren ist es ratsam, wenn man ein Programm schreibt, sich zu ueberlegen, nach welchem Paradigma man es machen moechte. Das macht den Code leichter lesbar.
Und man sollte natuerlich moeglichst viele Paradigmen schon einmal gesehen haben, sonst bekommt man schnell schwierigkeiten fremden code zu verstehen.

MoKrates

Java gehört als objektorientierte Sprache zur Familie der imperativen Sprachen! (Steht so zumindest im P2 Skript).

Es gibt objektorientierte imperative sprachen, objektorientierte funktionale sprachen, nicht-objektorientierte imperative und nicht-objektorientierte funktionale sprachen, sogar sprachen, die sowohl imperativ als auch funktional sind und dennoch objektorientiert, oder auch nicht objektorientiert…

Die beiden wichtigen Achsen sind dabei:

Objektorientiert vs. Prozedural
Funktional vs. Imperativ

Das sind dann auch keine binären unterscheidungen, auch wenn man als Informatiker gerne in schwarz/weiß denkt, sondern kontinuierliche Übergänge ;)

Achja, und an die ganzen freaks: Vergesst doch bitte stream-orientierte programmierung nicht, oder logik-programmierung…

Du hast noch funktionale Programmierung vergessen.

Nein. Seine Aufzaehlung endete mit drei Puenktchen…

Faleiro hat Recht. Ich habs net vergessen [img]http://www.fb18.de/gfx/6.gif[/img] Ich hatte nur keine Lust das extra noch zu sagen.
Mehr als meine Antwort war doch von der Fragestellung her auch nicht verlangt oder? [img]http://www.fb18.de/gfx/15.gif[/img]

Mehr als meine Antwort war doch von der Fragestellung her auch nicht verlangt oder? [img]http://www.fb18.de/gfx/15.gif[/img]

Keine Ahnung. Die ursprüngliche Fragestellung war so allgemein, daß ich mich leicht an RUCs Kabel erinnerte. [img]http://www.fb18.de/gfx/22.gif[/img]

Vielleicht waren ja auch keine Beispiele, sondern eine allgemeinere Erklärung gefragt, so à la "Ein Programmierparadigma ist eine Sichtweise, die einer Programmiersprache oder einem Programmierstil zugrunde liegt."

Übrigens: "while", "if" und co. werden manchmal auch als Kontrollanweisungen bezeichnet, die Kontrollstruktur besteht dann aus Kontrollanweisung und bedingt auszuführenden Befehlen.

jaja…. besserwisser [img]http://www.fb18.de/gfx/24.gif[/img]

Objektorientiert vs. Prozedural
Funktional vs. Imperativ

kann mir Jemand die unterschiede ganz kurz erläutern?
ich verstehe nun nämlich gar ncihts mehr….

Objektorientiert vs. Prozedural
Funktional vs. Imperativ

kann mir Jemand die unterschiede ganz kurz erläutern?
ich verstehe nun nämlich gar ncihts mehr….

Ich würde die oben gemachte Gegenüberstellung ("vs.") so nicht machen, will aber kurz meine Auffassungen dieser Begriffe schreiben:

Imperativ:
Man orientiert sich an dem Konzept des Von-Neumann-Rechners und hat Befehle und Speicherzellen (welche man dann noch mit einem Namen und vielleicht Typ versieht und dann "Variablen" nennt).

Funktional:
Man orientiert sich an dem mathematischen Konzept von Funktionen: Eine Funktion liefert bei den selben Eingabeparameter immer den selben Rückgabewert. Es gibt keinen intrinsischen Zustand und keine Nebenwirkungen.

Prozedural:
Man zerlegt ein Programm, indem man eine Befehlsfolge zu einer Prozedur zusammenfaßt, welche man wie einen neuen Befehl aufruft - ggf. auch mehrmals.

Objektorientiert:
Die Welt - genauer: das eigene Modell davon - besteht aus Objekten. Objekte haben Verhalten und Zustände.

Könntest du kurz erwähnen wieso du dieser Einteilung mit "vs." nicht zustimmst? Ich denke bei Imperativ vs. Funktional gibt es keine Bedenken. Deine Bedenken bei Prozedural vs. Objektorientiert würden mich interessieren.

(Smalltalk-basierte) objektorientierte Programmierung bedient sich konzeptuell an Objekten. Diese Objekte bestehen aus einem Zustand und den möglichen Operationen darauf, und kommunizieren (über Nachrichten, Methoden, etc.) miteinander. Prozedurale Programmierung verwendet Prozeduren, wie du richtig schreibst, eben keine Objekte.

Python und Java stehen zwischen diesen beiden Extremen: Beide erlauben nicht-objektgebundene Prozeduren (bei Java über static - der Klassenname wird damit zu einem reinen namespace).

Eine andere Form der Objektorientierung verfolgt CLOS in Common Lisp (und die CLOS-derivate), bei denen die Objektorientierung über generische Methoden über Parametertypen definiert wird. Im Grunde nix neues, aber ein leicht anderes Konzept mit interessanten Auswirkungen :)

Funktional:
Man orientiert sich an dem mathematischen Konzept von Funktionen: Eine Funktion liefert bei den selben Eingabeparameter immer den selben Rückgabewert. Es gibt keinen intrinsischen Zustand und keine Nebenwirkungen.

Was so in der Praxis eigentlich nicht existent ist, da man, wenn man diesem Ansatz genau folgt, nur noch Rechnungen ausfuehren kann, nicht aber ihre Ergebnisse anzeigen kann :>

Scheme (und auch Lisp im Allgemeinen) ist eine sehr funktional orientierte Sprache, allerdings Funktionen wie (display …) widersprechen natuerlich dem funktionalen Paradigma, da fuer die praktische Programmierung Nebeneffekte unabdinglich sind (Eingaben, Ausgaben, Ereignisbehandlung, etc)

MoKrates

Deine Bedenken bei Prozedural vs. Objektorientiert würden mich interessieren.

Konzeptionell sind die beiden natuerlich verschieden, aber sie sind aufeinander leichter abbildbar als zB funktional<->imperativ.

Man sehe sich zB an, wie das Interface zwischen C++ und C aussieht.

Aus C-Sicht sind Klassen aus C++ eine Verbindung einer Anzahl von Funktionen und einem "struct". Den Funktionen wird die zum entsprechenden Objekt gehoerige Datenstruktur (das struct, das halt alle Membervariablen enthaelt) als erster Parameter uebergeben. (Ich weiss nicht, ob das vom Standard vorgeschrieben wird, jedenfalls hab ich das bei einigen Implementierungen (MSVC++ & GNU C++) gesehen, bei Borland wirds aehnlich aussehen).
Hieran wird deutlich, das Methoden der OO als Prozeduren/Funktionen des imperativen Ansatzes betrachtet werden koennen. (und sich die beiden Paradigmen sich darum auch nicht ausschliessen).

MoKrates

Zunächst: Wir sprechen hier über Programmierparadigmen, nicht (nur) über Ausrichtungen von Programmiersprachen. Paradigmen sind mehr, bestimmen z.B. auch, wie man programmiert.

Nur weil man in der Garage steht ist man nicht gleich ein Auto. Nur weil man mit einer objektorientierten Sprache arbeitet, programmiert man nicht auch gleich objektorientiert - selbst wenn man Objekte verwendet.

Ich denke bei Imperativ vs. Funktional gibt es keine Bedenken.

Da habe ich insofern "Bedenken", als daß auch dort die Grenze nicht klar ist. Auch mit einer imperativen Sprache kann man - in Teilen - funktional programmieren.

Manche Sprachen - wie Lisp - vereinen funktionale und imperative Anteile auch so stark, daß man höchstgradig funktional oder imperativ damit programmieren kann.

Deine Bedenken bei Prozedural vs. Objektorientiert würden mich interessieren.

(Smalltalk-basierte) objektorientierte Programmierung bedient sich konzeptuell an Objekten. Diese Objekte bestehen aus einem Zustand und den möglichen Operationen darauf, und kommunizieren (über Nachrichten, Methoden, etc.) miteinander. Prozedurale Programmierung verwendet Prozeduren, wie du richtig schreibst, eben keine Objekte.

Python und Java stehen zwischen diesen beiden Extremen: Beide erlauben nicht-objektgebundene Prozeduren (bei Java über static - der Klassenname wird damit zu einem reinen namespace).

In Java werden Prozeduren verwendet, um Methoden zu realisieren. Ubhängig davon, ob diese an einem Objekt hängen, oder nicht.

Davon völlig unabhängig ist wieder eine prozedurable oder objektorientierte Entwurfssmethode: Orientiert man sich an Prozeduren, so geht man häufig von Algorithmen aus und zerlegt diese entsprechend. Orientiert man sich an Objekten, so bildet man eben diese heraus und lagert an diese Verhalten und Zustände an.

Funktional:
Man orientiert sich an dem mathematischen Konzept von Funktionen: Eine Funktion liefert bei den selben Eingabeparameter immer den selben Rückgabewert. Es gibt keinen intrinsischen Zustand und keine Nebenwirkungen.

Was so in der Praxis eigentlich nicht existent ist, da man, wenn man diesem Ansatz genau folgt, nur noch Rechnungen ausfuehren kann, nicht aber ihre Ergebnisse anzeigen kann :>

Wieso?

Scheme (und auch Lisp im Allgemeinen) ist eine sehr funktional orientierte Sprache, allerdings Funktionen wie (display …) widersprechen natuerlich dem funktionalen Paradigma, da fuer die praktische Programmierung Nebeneffekte unabdinglich sind (Eingaben, Ausgaben, Ereignisbehandlung, etc)

Ein-, Ausgabe und Ereignisse sind Ströme, von denen man fortlaufend liest. Natürlich muß man schon einige Verrenkungen betreiben, um in einer funktionalen Sprache wie Miranda ein Tetris zu programmieren. So unmöglich ist das aber nicht.

Was so in der Praxis eigentlich nicht existent ist, da man, wenn man diesem Ansatz genau folgt, nur noch Rechnungen ausfuehren kann, nicht aber ihre Ergebnisse anzeigen kann :>

Wieso?

gemeint wird wohl sein, dass eine Funktion in dem Sinne wie vorher beschrieben ja eben keine Nebeneffekte erzeugt, und insofern auch keine Bildschirmausgabe erzeugen kann.

Python und Java stehen zwischen diesen beiden Extremen: Beide erlauben nicht-objektgebundene Prozeduren (bei Java über static - der Klassenname wird damit zu einem reinen namespace).

Natürlich passen statische Klassen aus Java auch zu einer objektorientierten Sichtweise, man kann sie ja als die Objekte ansehen, die eine Klasse von Objekten darstellen - Objektorientierung ist halt eher eine Sichtweise als eine von der Sprache aufgezwungene Art zu programmieren.

Funktional:
Man orientiert sich an dem mathematischen Konzept von Funktionen: Eine Funktion liefert bei den selben Eingabeparameter immer den selben Rückgabewert. Es gibt keinen intrinsischen Zustand und keine Nebenwirkungen.

Was so in der Praxis eigentlich nicht existent ist, da man, wenn man diesem Ansatz genau folgt, nur noch Rechnungen ausfuehren kann, nicht aber ihre Ergebnisse anzeigen kann :>

Das, was in der Praxis eigentlich nicht existiert, nennt sich Haskell, und wird für verschiedenste Projekte verwendet (u.a. ein sehr gutes Revision Control System namens darcs). Rein funktional, I/O wird über das mathematische Konzept der Monaden realisiert.

http://www.haskell.org/

Objektorientierung ist halt eher eine Sichtweise als eine von der Sprache aufgezwungene Art zu programmieren.

Also, ich rede die ganze Zeit von Sichtweisen bzw. Problemlösungsansätze. Programmiersprachen erleichtern gewisse Ansätze oder erschweren sie, aufzwingen oder verhindern kann keine Programmiersprache etwas (Stichwort Turing-Vollständig, Interpreter-Bau (vgl. Essentials of Programming Languages))

Das, was in der Praxis eigentlich nicht existiert, nennt sich Haskell, und wird für verschiedenste Projekte verwendet (u.a. ein sehr gutes Revision Control System namens darcs). Rein funktional, I/O wird über das mathematische Konzept der Monaden realisiert.

http://www.haskell.org/

Magst Du mir erklaeren, wie man mit dem Betriebsystem kommuniziert, ohne Nebeneffekte zu haben? Ich moechte nicht unbedingt Haskell lernen muessen, um das zu verstehen…

MoKrates

Magst Du mir erklaeren, wie man mit dem Betriebsystem kommuniziert, ohne Nebeneffekte zu haben? Ich moechte nicht unbedingt Haskell lernen muessen, um das zu verstehen…

Man versteckt die nebeneffekte hinter einem mathematischen konzept (Monaden, wie oben erwähnt). Nein, ich schreibe hier kein Lehrbuch ab um dir Monaden zu erklären…

(Achja, "Cheaten! Das sind ja doch nebeneffekte!" - Wir reden über die konzeptuelle Schicht, nicht die Implementation. Für die Programmierung ist es irrelevant wie das funktioniert, es ist mathematisch sauber. Genauso wie es für den typischen Programmierer in C++ irrelevant ist, dass am Ende dann doch assembler bei rauskommt und seltsame structs mit seltsamen dispatch-tabellen)