Programmier Paradigmen / Thesen
 
StartSeite | ProgrammierParadigmen/ | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Im Folgenden einige Thesen im Zusammenhang mit den in ProgrammierParadigmen/Begriffe erwähnten Begriffen, die die Verbindung derselben erläutern und klären helfen sollen:

Ganz spontan, ad hoc, würde ich jetzt zustimmen

Wie "applikativ" jetzt definiert ist, weiß ich -ehrlich gesagt- gar nicht. Aber ich denke, das wird schon passen, so wie Du das sagt. Allgemein scheint es so zu sein, dass funktionale Sprachen als "applikativ" gelten.

Das ist eben gerade nicht so! Applikative Sprachen sind eine echte Teilmenge der funktionalen Sprachen.

Hmmm... Hmmm... Dieser Punkt wäre dann noch zu klären. Spielt aber für mein Schema keine so wichtige Rolle. Ich werde mich darauf beschränken : funktional ("applikativ") zu schreiben. Womit angedeutet werden soll, dass "applikativ" "schwächer" als "funktional" ist.

Sehr hübsch hat das jemand im englischen Wiki gesagt:

"You cannot define a function in Prolog, or apply a function to its arguments. Prolog is not about functions, it is about predicates."

Oh, danke, ich fühle mich geschmeichelt - das war ein Beitrag von mir! Du scheinst ein Talent dafür zu haben aus den beiden Wikis Zitate von mir zusammenzutragen. :-)

Allerdings war das eine Aussage speziell zu Prolog, nicht zu prädikativen Sprachen allgemein. Natürlich können in einem Prädikat Ausdrücke enthalten sein, in denen Funktionen auf ihre Argumente angewendet werden. Es gibt prädikative Sprachen, in denen man Funktionen definieren kann. Es ist eine spezielle Schwäche von Prolog, dass es dort nicht geht.

Ja, klar, weil Prolog eben eine REIN prädikative Sprache ist! [Das Strukturschema oben ist natürlich am "hilfreichsten", wenn man es auf REINE Vertreter der jeweiligen Paradigmen anwendet...]

Schön wäre es! Prolog hat aber leider sehr starke imperative Elemente (Cut-Operator, Manipulation der Klauseldatenbank, IO-Operationen). SpracheMercury? versucht diese Schwächen zu überwinden - und hat Funktionen.

I see... :-) - Ursprünglich (hab ich wo gelesen) war Prolog allerdings wesentlich "reiner"...

Jep... Aber eben... machen das nicht ALLE Sprachen letztlich...? // Die etwas umfassendere Sichtweise ist offenbar, dass alle oben zitieren "Paradigmen" auch bestimmte Algorithmenbegriffe zugrunde liegen... Dazu ein andermal mehr.

Ja, hier ist eine Inpräzision. Es geht darum, ob ein Algorithmus explizit oder implizit beschrieben wird.

Ja.

Mag sein, ja. Auf alle Fälle findet sich häufig der Ausdruck: "prozedural-imperativ", was diese Ansicht nahe legt. ;-)

Ganz im Gegenteil. Wenn ich sage "prozedural-imperative Sprachen" könnte ich meinen "prozedurale Sprachen und imperative Sprachen", oder ich könnten meinen "Sprachen, die sowohl prozedural oder imperativ sind". Da die prozeduralen Sprachen eine Teilmenge der imperativen sind, ist beides nicht sonderlich sinnvoll. Genau das gleiche Problem haben die Begriffe "funktional-applikativ" und "logisch-prädikativ".

Ich würde das NICHT als Problem ansehen, sondern als einen Punkt der dann eben noch entsprechend geklärt werden muss. Mit der Aussage "die prozeduralen Sprachen sind eine Teilmenge der imperativen" habe ich KEINERLEI Probleme, im Gegenteil. Ich halte das für eine bemerkenswerte Verfeinerung und differenzierung des Schemas von oben.

Ebenso "Applikative Sprachen sind eine echte Teilmenge der funktionalen Sprachen." Und dassebe gilt für logisch-prädikativ...

Was sich daraus nämlich zwangsläufig ergibt, ist GENAU das Schema auf das ich letztlich auch hinaus will... :-) // Top-Level-Begriffe: imperativ; deklarativ: funktional, logisch; objektorientiert.

Ja, Beispiel C++.

Es gibt aber Sprachen, die man wohl kaum mehr als "imperativ" bezeichnen kann: Smalltalk z.B.

Irrtum. Smalltalk ist ganz eindeutig eine imperative Sprache. Sie hat zwar mehr funktionale Elemente als gängigerere Sprachen, aber sie ist auf keinen Fall funktional. Smalltalk-Code ist im Wesentlichen eine Sequenz von Anweisungen. In Smalltalk werden Nachrichten an Objekte versandt mit dem Ziel, Seiteneffekte zu erzielen. Das ist ganz klar imperativ.

Aha... Hmmm... Da muss ich drüber nachdenken, aber das von Dir Gesagte macht schon Sinn..., ja.

Aber: Smalltalk ist keine prozedurale Sprache, weil Smalltalk Programme nicht hauptsächlich durch die Aufteilung in Prozeduren strukturiert werden, sondern durch die Aufteilung in Klassen!

Das ist IMHO nicht ganz richtig. Natürlich hat Smalltalk auch "Prozeduren" - nur heißen die dort Methoden... Und das "Schicken einer Nachricht" an ein Objekt, kann im wesentlichen auch als das Aufrufen einer Prozedur aufgefasst werden... [Denke nur an die Art und Weise, WIE C++ OO umgesetzt hat!]

Ich habe nicht gesagt, dass es in Smalltalk keine Prozeduren gibt, sondern dass sie nicht das Hauptmittel zur Strukturierung von Programmen sind. Das Senden einer Nachricht ist in imperativen Sprachen gleichbedeutend mit dem Aufrufen einer Prozedur, in funktionalen Sprachen gleichbedeutend mit dem Anwenden einer Funktion. (Von objektorientierten prädikativen Sprachen habe ich keine Ahnung.)

Gut, dann sind wir ja einer Meinung. (D i e s ist eben auch der Grund, weshalb ich es für korrekt halte, die OO als eigenes Paradigma den anderen hinzuzufügen - trotz der Orthogonalität, die zweifelsfrei vorhanden ist.)

Anders sieht der Fall bei einer Hybridsprache wie C++ aus. Ich denke, dass man sagen kann, dass in C++ beide Programmierparadigmen (imperativ und OO) "umgesetzt" sind: da -wie Du weiter unten sagst, diese Paradigmen "orthogonal" sind, ist das ja auch leicht möglich, und relativ "unproblematisch". Trotzdem scheint man auch für C++ die Charakterisierung OO zu verwenden; und irgendwie stimmts ja, sie ist sicher Objekt orientiert... ;-)

Also:

Achselzuck. Wenn Du das so siehst... klingt für mich "glaubhaft". (Ich denke, Du weißt wovon Du redest.)

Ja, ich denke, dass man das so sehen kann/muss. Wenn man sich auch davor hüten sollte, hier mit "rein/unrein" bestimmte Konnotationen zu verbinden...

Ich habe hier einfach die im englischen üblichen Begriffe "pure functional" und "impure functional" übersetzt. Bessere Vorschläge?

Nie, passt schon. // Scheme -als Lisp-Dialekt- ist auch ein "Mischtyp: vergleiche SpracheScheme (!)

LISP hat als URMUTTER aller funktionalen Sprachen eine wichtige Rolle gespielt. Man sollte das würdigen und gut sein lassen. Wenn Haskell mit einem besseren (weil "reineren") Konzept auftritt, um so besser.

Ich denke schon, ja.

Hmmm... Ich halte die beiden Begriffe für mehr oder weniger Synonym in der Praxis. ALLZU VIELE logische Sprachen kenne ich ohnehin nicht, und DIE sind auch "prädikativ". Z.B. Prolog... // Aber ich glaube zu verstehen, worauf Du abzielst und stimme Dir zu...

Muss zugeben, dass ich hier nur wiedergebe, was ich gelesen habe, ohne es verstanden zu haben.

Nun es gibt ja auch noch andere "Logiken" - nicht nur prädikative! So würde ich das sehen wollen. Aber wirklich bekannt ist ja eigentlich nur Prolog, und DA stehen halt "Prädikate" im Vordergrund.

Ja. Und wohl auch OO-orientierte Sprachen. Es gibt nicht den geringsten Grund, Smalltalk z.B. als Nicht-algorithmisch anzusehen... ;-)

Es gibt keinen Gegensatz zwischen imperativ und funktional auf der einen Seite und objektorientiert auf der anderen. Die Konzepte sind orthogonal.

Ja, das ist eine mögliche (und sicher richtige) Sichtweise. Ich ziehe es aber vor, das PARADIGMA der OO-Programmierung den Paradigmen der imperativen und funktionalen Programmierung zur Seite zu stellen; wie man es auch (sehr oft) in der Literatur findet. DE FAKTO wird ja auch von den Sprachen in genau gleicher Weise gesprochen, ALS ob der Begriff "objektorientiert" dem selben logischen-semantischen Feld entsprechen würde, wie "funktional" oder "imperativ"...: das ist ja gerade der Witz dabei: Du sagst eben so leichthin "diese Sprache ist eine rein objektorientierte Sprache", wie "diese Sprache ist rein funktional". (!) // D.h. in der alltäglich verwendeten Sprache ist von dieser "Orthogonalität" nichts zu finden... ZUDEM habe ich hier auch ein sehr schönes Buch über Algorithmen, wo eben aus dem Algorithmusbegriff heraus die Unterscheidung der 4 Paradigmen: imperativ, logisch, funktional und objektorientiert vorgenommen wird. Ich fand/finde das sehr schlüssig und nachvollziehbar...: DENN daraus angeschlossen ist ja auch unmittelbar die Redeweise von den Programmierstilen: die dann eben imperativ, logisch, funktional und OO sein können. (Irgendwie nachvollziehbar?)

Nachtrag, was ich damit sagen will: dass eben ein "klassischer" (und "reiner") Vertreter des "(imperativ-)prozeduralen" Paradigmas keine OO Sprache ist/war (und auch keine solche Strukturen vorzuweisen hat/hatte). Ähnliches gilt für die funktionalen Sprachen. (...) Andererseits sehen wir eben schon seit einiger Zeit einen Trend *alle möglichen* Sprachen mit OO-Features "nachzurüsten". Aufgrund der von Dir angesprochenen "Orthogonalität" geht das ja zumindest bei imperativen Sprachen (relativ) leicht.

Die Orthogonalität sagt leider nicht viel darüber aus wie leicht oder schwierig die Konzepte sauber zu integrieren sind, und schon gar nicht darüber wie leicht oder schwierig sie zu implementieren sind. Tatsächlich läßt sich Objektorientierung nur in imperative Sprachen leicht integrieren. Die Kombination von deklarativen und objektorientierten Konzepten ist seit langem Gegenstand aktueller Forschung, und einige haben den Versuch bereits aufgegeben. Das Problem besteht darin, Zustände von Objekten in effizienter Art und Weise zu verändern, und dabei gleichzeitig ihre Identität und die referenzielle Integrität zu wahren.

Genau dieses Problem ist der Hauptgrund, warum viele Anhänger der deklarativen Programmierung OO nicht mögen. (Mein Problem ist, dass ich auf beide Konzepte nicht verzichten möchte, und es keine professionelle Entwicklungsumgebung gibt, in der man beides gleichzeitig haben könnte.)


Zusammenfassung

Also ich habe den Eindruck, dass die hier vorgeschlagenen Leitsätze als solche durchaus Sinn machen und wichtige Aussagen treffen.

Danke.

Ich würde sie dann aber (trotzdem) als "THESEN" bezeichnen und in den Diskussionsbereich einer Seite aufnehmen wollen, in deren Inhaltsteil die oben vorgeschlagene Kategorisierung gegeben wird. (vgl. ProgrammierParadigmen)

Momentan sind es Thesen. Wenn wir einen Konsens finden, kann man davon ausgehen, dass sie allgemein annerkanntes Wissen darstellen, und können sie in den Artikelbereich übernehmen. Sie stellen dann die Beschreibung der Kategorisierung dar.

Ja, schon... Dennoch bieten sie eben m.E. eine ganze Menge an INHALTLICH begründeten Diskussionsmöglichkeiten. Während das Schema -als solches- ja erst mal nur eine Begriffsschema ist. Und als solches weder "wahr" noch "falsch", sondern bestenfalls "anmessen" oder "nicht angemessen" und/oder "In Übereinstimmung" mit gängigen Darstellungen oder "nicht in Übereinstimmung" dazu...

Also um mich hier zu präzisieren: ich würde diese THESEN als Block unmittelbar nach der von mir geplanten Darstellung der Paradigmen stehen haben wollen, und daran schließt sich dann der Diskussionsbereich an. So war das gemeint!



StartSeite | ProgrammierParadigmen/ | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 2. Juli 2002 4:13 (diff))
Suchbegriff: gesucht wird
im Titel
im Text