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

Folgende Begriffe werden als Bezeichnungen für Attribute von Paradigmen in der Programmierung verwendet.


Man kann diese Begriffe aber sehr leicht in eine (vorläufige) Ordnung bringen, die allgemein anerkannt ist. (Natürlich wird nicht *überall* die selbe Terminologie verwendet, klar...; aber es deckten sich doch sehr viele Ansichten/Darstellungen in diesem Bereich.

Das ist eine gängige "Zusammenfassung":


zum Begriff "algorithmisch"

Gelegentlich werden dann auch noch typische Vertreter der "prozedural-imperativen" Sprachen als "algorithmisch" bezeichnet; das ist aber eher geschichtlich bedingt und nicht wirklich "sachlich" gerechtfertigt m.E.

Allerdings. Funktionale Sprachen sind auch algorithmische Sprachen.

ALGOL war halt die Urmutter praktisch aller nachfolgenden "prozedural-imperativ" bzw. "algorithmischen" Sprachen.

Würde ich so nicht stehen lassen wollen, wie wär's mit:
"ALGOL ist die Urmutter aller heute gebräuchlichen imperativen Sprachen."

Hmmm... Dem würde ich zwar AUCH zustimmen, trifft aber nicht wirklich das, was ich sagen wollte...: Was ich sagen wollte ist, dass einer der wichtigsten Vertreter der "prozedural-imperativen" Sprachenfamilie auch noch "Algorithmic Language" heißt/hieß, hat wohl auch dazu beigetragen, dass man Sprachen aus diesem Zweig oft -etwas ungenau- als die algorithmischen ansieht. Anderer Ansicht?

An dieser Formulierung ist nichts, dem ich widersprechen würde (außer der Verwendung des IMO inkorrekten zusammengesetzten Begriffs "prozedural-imperativ"). Dann scheint mir deine ursprüngliche Formulierung aber doch zu missverständlich.

Einschub: ALGOL (ALGOrithmic Language) is one of several high level languages designed specifically for programming scientific computations. It started out in the late 1950's, first formalized in a report titled ALGOL 58, and then progressed through reports ALGOL 60, and ALGOL 68. It was designed by an international committee to be a universal language. Their original conference, which took place in Zurich, was one of the first formal attempts to address the issue of software portability. ALGOL's machine independence permitted the designers to be more creative, but it made implementation much more difficult. Although ALGOL never reached the level of commercial popularity of FORTRAN and COBOL, it is considered the most important language of its era in terms of its influence on later language development. ALGOL’s lexical and syntactic structures became so popular that virtually all languages designed since have been referred to as "ALGOL - like"; that is they have been hierarchical in structure with nesting of both environments and control structures.

Offensichtlich sind hier mit "all languages designed since" eben die typischen Vertreter der (prozedural-)imperativen "Sprachfamilie" gemeint; spontan fallen mir da ein: C, Pascal,...

Bei den (prozedural-)imperativen Sprachen sind (oder waren) wohl nur BASIC als ein "Kind" von FORTRAN und COBOL nicht (mehr oder weniger direkt) beeinflusst von Algol.

TATSACHE ist aber, dass *alle* Programmiersprachen letztlich "algorithmisch" sind: alle Sprachen dienen dazu, Algorithmen zu implementieren. Nur die Ansätze, WIE sie das tun, sind zum Teil recht unterschiedlich: hier kommt dann die Redeweise von den ProgrammierParadigmen ins Spiel...

Das kann man so sehen, muss man aber nicht. Algorithmische Sprache wird oft als Bezeichnung für Sprachen benützt, die einen Algorithmus explizit beschreiben. Logische Sprachen beschreiben Algorithmen implizit.

Ja, das ist eine sehr guter Punkt, den man eigens ansprechen muss. Ich würde dann hierfür eben (der methodischen Sauberkeit wegen) vorschlagen, dass man besser von (prozedural-)imperativen Sprachen spricht, wenn man sich diesbezüglich von deklarativen Sprachen abgrenzen will.

Natürlich ist mir der tiefere Grund klar, warum sich hier die Bezeichnung "algorithmische Sprache" aufdrängt, weil man eben bei einer (prozedural-)imperativen Sprache wirklich den Algorithmus (explizit) beschreibt bzw. beschreiben muss... [...]

Auch funktionale Sprachen beschreiben Algorithmen explizit (Ausnahme: Pattern Matching). Nur logische Sprachen beschreiben Algorithmen implizit. Algorithmisch in obigem Sinn ist also nicht ein Gegensatz zu deklarativ.

Wie gesagt: Ich fasse "algorithmisch" ohnehin etwas allgemeiner auf.

D.h. eine (vorläufige) Darstellung könnte dann auch so aussehen:

algorithmisch:

Das ist erst mal nur der Ausgangspunkt, auf dem man nun aufbauen kann... (Besser als eine ungeordnete Liste von unverbundenen Begriffen ist es aber m.E. allemal... ;-)

Bemerkung: Da aber "algorithmisch" nicht im eigentlichen Sinne zu den ProgrammierParadigmen zu zählen ist, sollte man es besser bei einer Darstellung derselben weglassen. Es erscheint mir im Gegenteil sogar sinnvoll(er) hier [im erklärenden Bereich dann] die von Dir -her- vorgeschlagene Differenzierung in "explizit algorithmisch" und "implizit algoritmisch" vorzunhmen, wenn es um eine deteiliertere Charakterisierung bestimmter Ansätze (ProgrammmierParadigmen?, -Sprachen und -Stile) geht!

ja.

Überreste einer Einleitung

Hier bitte nicht als Überschrift "Kritik" oder "Bedenken" oder etwas ähnliches drüberschreiben. Das wäre einfach sinnverzerrend. Das Untenstehende ist ja nicht die Antwort auf das Obenstehende, sondern umgekehrt. Das was folgt sind die Überreste einer Einleitung zu einem inzwischen zerpflückten Artikel.

Ok, sorry, hast recht. Das würde Deiner ursprünglichen Intention offensichtlich zuwiderlaufen; das war nicht meine Absicht. [Vielleicht würde es "Diskussion unterschiedlicher Standpunkte" noch am besten treffen...]

Die wenigsten dieser Begriffe können als allgemein gültig und eindeutig definiert angesehen werden und manche der Begriffe werden in der Literatur sehr unterschiedlich verwendet. Man kann davon ausgehen, dass zwar bei genauer Betrachtung keine 2 der genannten Begriffe absolut synonym sind, es aber Überschneidungen gibt, und jede existierende Programmiersprache über mindestens 2 (oder sogar 3?) der genannten Attribute verfügt.

Sicher mag das bei GENAUER Betrachtung so sein... Dennoch macht eine derartige Kategorisierung SINN, als das was es ist...: ein gängiges Hilfsmittel um Sprachen zu "kategorisieren". (Das ist eine GÄNGIGE Praxis...) Was ich nun gerne machen würde, ist, diese PRAXIS auch im DSE *explizit* "abzubilden" bzw. zu repräsentieren... ;-) - So dass man auch darüber dann hier (im Diskussionsbereich) reflektieren kann.

Ich habe doch nie gesagt, etwas gegen die Verwendung der Begriffe zu haben - ich selbst verwende sie doch laufend! Ich habe etwas dagegen, wenn man so tut als ob alle darunter das gleiche verstehen würden, oder also ob sie so scharf definiert wären, dass man daraus eine exakte Klassifikation aufbauen könnte.

Mir genügt es wenn ich ein BRAUCHBARES Schema erhalte..., das a) zudem noch auf einen breiten Konsens "hoffen" kann, und b) sich auch wirklich oft in der Literatur wiederfindet (in mehr oder weniger gleicher Form...)

Wenn man D A S einmal hat, kann man ja *darauf bezogen* auch alternative/abweichende Ansichten diskutieren (und sogar in gewisser Weise "bewerten"). Verstehst Du meinen "Punkt"? Es geht hier darum, *überhaupt* einmal einen Bezugspunkt zu schaffen... (Allerdings nicht willkürlich sondern schon mit "aller Vorsicht" und "intellektuellen Redlichkeit". Dazu gehört eben das gerade im letzten Absatz Gesagte...)

Ich will mal die RELEVANZ eines solchen Schemas anhand von einigen Beispielen erläutern: Man klicke einfach mal die folgenden Links an, und lese aufmerksam die ersten Sätze..., immer mit dem eben Gesagten im Hinterkopf...

4 von den 7 Zitaten stammen von mir! Und wenn ich sie mir so anschaue stelle ich fest, dass ich seit ich sie geschrieben habe noch nicht soviel dazu gelernt habe, dass ich etwas an ihnen ändern würde. :-)

SpracheHaskell:
Haskell ist ein polymorph getypte, rein funktionale Programmiersprache

SpracheCee:
C ist eine prozedurale Programmiersprache

SpracheEiffel:
Eine der bedeutendsten OO-Sprachen

SpracheErlang:
Deklarative Programmiersprache.

SpracheSimula:
Älteste OO-Sprache

SpracheSuneido
vorwiegend objektorientiert mit eingeschränkter Unterstützung für funktionalen Programmierstil

SpracheRuby:
Ruby ist eine einfache, vollständig objektorientierte Scriptsprache

Was ich damit aufzeigen möchte...: die oben vorgeschlagene Kategorisierung ist also eine gängige Praxis, ganz gleich, ob man sich dessen nun bewusst ist, oder nicht, oder ob man das nun ablehnt oder nicht.

Du rennst offene Türen ein.

Der Punkt ist doch der...: Die Leute die all die oben zitierten Sätze formuliert haben, haben hier ABSOLUT gängige, Aussagen formuliert, die zweifellos auch eine BEDEUTUNG tagen... : also tatsächlich eine AUSSAGE machen.

Das will ich doch wohl hoffen.

Wenn Du -her- mit Deiner Kritik recht hättest, wäre ja diese Aussagen "redundant"... und ich glaube nicht, dass es irgendjemanden gibt, der das ernsthaft behaupten möchte...

Hoffentlich siehst du jetzt, dass die Kritik, die du zu lesen geglaubt hast, gar nicht existiert hat.

Es wird immer wieder versucht, unterschiedliche Teilmengen obiger Begriffe dazu zu verwenden, eine Klassifikation von Programmiersprachen aufzubauen. Obwohl so eine Klassifikation helfen kann, einen Überblick zu bekommen, ist sie immer mit so erheblichen Vereinfachungen verbunden, dass man über deren Zulässigkeit leicht geteilter Meinung sein kann.

Zum einen gilt für die meisten Programmiersprachen, dass es verschiedene Konstrukte in ein- und der gleichen Sprache gibt, die aber unterschiedlichen Paradigmen zuzurechnen sind.

Ja, das stimmt natürlich. Bei manchen Sprachen ist das allerdings trotzdem VÖLLIG klar, welchem "Paradigma" sie zuzuordnen sind. (Ich denke nicht, dass jemand allen ernstes C oder Pascal -in ihren Urformen- als im eigentlichen Sinne OO bezeichnen möchte. Und Lisp/Scheme/Haskell würde ich jetzt auch nicht unbedingt als "(prozedural-)imperative" Programmiersprachen ansehen wollen; auch dann nicht, wenn man derartige Konstrukte (natürlich) auch in diesen Sprachen nutzen kann!

Stimme ich zu.

Unabhängig davon gibt es natürlich ECHTE "Multiparadigmen"-Sprachen... Aber allein *dieser Begriff* setzt ja schon voraus, dass ich die Paradigmen erst mal einzeln identifiziert und "ausgezeichnet" habe!!!

C++ wird z.B. üblicherweise als Hybridsprache bezeichnet, weil beide Elemente deutlich genug ausgeprägt sind: die OO und die (prozedural-)imperative "Basissprache" (C eben...).

Einverstanden.

Hier würde ich mir dann eine konstruktive und produktive Diskussion wünschen. Es besteht ja keinesfalls eine NOTWENDIGKEIT jede Sprache genau einer Kategorie zuzuordnen, auch macht es nichts, wenn eine Sprache sich diesem Schema generell entzieht, oder unklar bleibt, wie sie eingeordnet werden soll/kann. [...]

Das entschärft die Sache etwas.

Das ist doch "selbstverständlich" m.E. Aber vielfach ist die Sache eben auch wirklich klar. (Oder "einfach".)

Zum anderen ist nicht abzusehen, dass es gelingen könnte, für alle genannten Attribute von Sprachen einen allgemeinen Konsens darüber zu erzielen, über welche Features eine Programmiersprache verfügen muss, damit ihr das Attribut zuerkannt werden darf, und welche Features in diesem Zusammenhang verboten sind.

Ja, ja. man kennt das ja... Aber ich denke, dass man das in einer konstruktiven Diskussion durchaus klären kann. Und schlimmstenfalls gibt es dann da unterschiedliche Ansichten. Was ich auch nicht für so schlimm halte, diesbezüglich...

Anhänger einer bestimmten Kombination von Programmiersprachen-Features tendieren dazu einen der Begriffe für diese von ihnen favorisierte Kombination zu beanspruchen und nur eine geringe Toleranz gegenüber Abweichungen zuzulassen. Beispiele sind Smalltalk-Programmierer, die CLOS als nicht objektorientiert bezeichnen

Achselzuck... : Um ehrlich zu sein, mit derartigen Feinheiten kenne ich mich nicht aus... Und da möchte ich mich auch gar nicht erst drauf einlassen. [Bzw. sollte man an anderem Ort ausdiskutieren...]

Sobald man versucht zu erklären, was Objektorientierung ist, wird man wieder auf das Problem stoßen.

oder ML-Programmierer, die denken, Lisp wäre nicht funktional.

Tja, so was gibt's natürlich... Ich möchte mich hier doch über ein derartiges Niveau erheben, und ich denke mit eurer Hilfe... Auch Deiner -her- wird das schon klappen. ;-)

Ok, versuchen wir, diesen Teil abzuhaken.

Also noch mal meine diesbezügliche Meinung: es gibt doch gemäßigte - "vernünftige" Ansichten... Ich habe z.B. gerade mal einen Blick ins Internet geworfen, Stichwort "Functional Programming", und da findet man dann z.B.:

"LISP, FP, Scheme, ML, Miranda and Haskell are just some of the languages to implement this elegant computational paradigm."

Also ich sehe da wirklich kein Problem mit! AUCH ICH hätte jetzt LISP, Scheme, ML und Haskell als "funktionale Programiersprachen" bezeichnet. (Siehe DeklarativeProgrammierung. :-) )


Was aber mir aber noch wichtig ist in dem Zusammenhang: Es wäre jetzt natürlich verfehlt/falsch, wenn man versuchen wollte, "alles und jedes" (also jeden Ansatz und jede Sprache) in das bekannte Schema der ProgrammierParadigmen pressen zu wollen. Gut möglich, dass man das bei bestimmten Sprachen nicht (zumindest nicht in sinnvoller Weise) kann. Und -ein weiterer Gedanke- es ist für mich noch keineswegs "ausgemacht", dass die dort angeführten Paradigmen die einzig "möglichen" wären...; derzeit handelt es sich vielleicht um ein bewährtes Schema..., aber wer kann ausschließen, dass sich nicht eines Tages eine neue Sichtweise/ein neues Paradigma herausbildet...?

Vielleicht ist z.B. die SpracheLava schon eine Vertreterin eines solchen neuen Paradigmas?


Ich möchte folgenden Vorschlag zur Diskussion stellen:

-- HelmutLeitner



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