Diskussion:Imperative Programmierung

Erste Kommentare

Ich bin absolut überzeugt, dass weder C noch Pascal imperative Programmiersprachen sind und entferne sie aus dem Artikel. Sollte es Argumente dagegen geben, lasse ich mir an dieser Stelle gern überzeugen ;) --Jon Kowal 18:07, 5. Okt 2005 (CEST)

Wie leichtsinnig... Aber man kann sich ja auch 'mal irren: [10], um nur einen zu nennen. Ansonsten hilft auch hier Google ungemein weiter. --Frank. 18:22, 5. Okt 2005 (CEST)

Befehle -> Anweisungen

Befehle sind die Arbeitsschritte eines Prozessors. Die meisten imperativen Programmiersprachen arbeiten nicht auf der Ebene von Befehlen, sondern von Anweisungen. Deswegen nannte man sie eine Weile "hoehere Programmiersprachen", bis das ein Pleonasmus wurde.

(Auch imperative Programmiersprachen haben uebrigens Deklarationen.)

Aufgrund dessen nehme ich die Sprache C wieder bei den Beispielen auf. --Freak 1.5 14:44, 26. Sep 2006 (CEST)

Erledigt; im Artikel wird nun einheitlich der Begriff 'Anweisung' verwendet. --Gms 20:31, 29. Mär. 2009 (CEST)

Imperative Programmierung versus Prozedurale Programmierung

Meiner Meinung nach ist prozedurale Programmierung ein Spezialfall der imperativen Programmierung und nicht mit dieser identisch. Ich wollte aber die letzte Änderung von R.K.A.L. auch nicht einfach revertieren und bitte um eine Stellungnahme. Auf jeden Fall fehlt dem Artikel mindestens ein Einzelnachweis für die konkrete Definition des Begriffs. --jpp ?! 21:52, 11. Mai 2007 (CEST)

Die Begriffe werden häufig synonym verwendet (vgl. auch http://en.wiki.x.io/wiki/Imperative_programming) aber bei differenzierter Betrachtung würde ich die Prozedurale Programmierung als einen charakteristischen Aspekt der Imperativen Programmierung auffassen. --R.K.A.L. 23:32, 11. Mai 2007 (CEST)

Also ist beides nicht synonym. Dann baue ich mal wieder den Verweis auf den anderen Artikel ein. --jpp ?! 14:12, 12. Mai 2007 (CEST)

ok--R.K.A.L. 14:56, 12. Mai 2007 (CEST)

Fortsetzung Dez 2012

Dieser Disk-Beitrag geht zurück auf die 'Mega-Diskussion' unter Prozedurale Programmierung, die bereits zum zweiten Mal erfolglos, weil ohne Konsens, abgebrochen wurde. Dabei wurde aus meiner Sicht folgender Status erreicht:

• Der Begriff 'prozedurale Programmierung' wird in den Medien mit zwei verschiedenen Bedeutungen behandelt.
• Eine davon (= programmieren mit Prozeduren; in der Disk. pP1 genannt) wird im gleichnamigen Artikel von Wikipedia beschrieben.
• Die andere, umfassendere Definition (pP2) gilt nach verschiedenen Quellen als Synonym für 'imperative Programmierung' .
• Die Merkmale dieser pP2-Bedeutung sind bisher aber weder im Artikel iP noch in pP umfassend beschrieben und nicht mit Quellen belegt.

Deshalb sollte 'iP' um die entsprechenden Angaben ergänzt werden. In beiden Artikeln sollte darauf hingewiesen werden, dass dieser Ausdruck 'prozedural' jeweils auch im anderen Sinn gebraucht wird.

Demnach wäre pP (nach der pP2-Interpretation) doch wieder Synonym zu iP - im Gegensatz zu den obigen Feststellungen - in denen ja nicht definiert wurde, was man darunter versteht. Leider ist die Quellenlage sehr heterogen. Da kann man in WP nichts anderes tun, als explizit auf solche Unterschiede hinzuweisen.

Ich stelle deshalb zunächst und unter der Annahme, dass der 'Synonym'-Sachverhalt zutrifft, temporär HIER den neuen Text ein, der auf den genannten Referenzen basiert.

Kommentarabschnitt aktualisiert: --VÖRBY 11:41, 5. Dez. 2011 (CET)

Neuer Text

(Einrückungen etc. bei Übernahme in den Artikel entsprechend anpassen)

EINLEITUNG:

Imperative Programmierung ist ein Programmierparadigma. Danach „besteht ein [Quell-] Programm aus einer Folge von Befehlen, die vorgeben, in welcher Reihenfolge was vom Computer getan werden soll “.

Die imperative Programmierung ist das bekannteste Programmierparadigma. Diese Vorgehensweise war, bedingt durch den Sprachumfang früher Programmiersprachen, ehemals die klassische Art des Programmierens und wird heute noch praktiziert. Sie liegt zum Beispiel dem Entwurf von ALGOL, Fortran, Pascal, ADA, PL/I, C und allen Assemblersprachen zugrunde (nach ).

Das dem imperativen Paradigma zugrunde liegende abstrakte Ausführungsmodell ist nah verwandt mit der Ausführung von Maschinencode auf einem konkreten Computer, der die vorherrschende Von-Neumann-Architektur implementiert. Es existieren beispielsweise bedingte und unbedingte Sprunganweisungen. Der Status des Rechners setzt sich aus dem Arbeitsspeicherinhalt und dem Zustand von Systemvariablen (z. B. Register, Befehlszähler ...) zusammen. „Die meisten normalen Programmiersprachen, darunter auch OOP-Sprachen wie C#, Visual Basic, C++ und Java, unterstützen in erster Linie [auch] die imperative (prozedurale) Programmierung“ .

Abweichende Bezeichnungen: In der Literatur wird diese Vorgehensweise zum Teil auch 'imperativ/prozedural', 'algorithmisch' oder 'prozedural' genannt. Der Ausdruck 'prozedurale Programmierung' wird jedoch zum Teil auch mit einer abweichenden Bedeutung benutzt, nämlich (siehe Prozedurale Programmierung) als Programmieren unter Verwendung von Prozeduren (was in auch 'strukturiertes, prozedurales Programmieren' genannt wird).

DETAILS (Merkmale)

Die besonderen Merkmale dieser Art des Programmierens sind (nach und ):

• Im Quellcode wird festgelegt, was in welcher Reihenfolge und wie zu tun ist: „First do this and next do that“ = schrittweises 'Fortschreiten' der Befehle; „viewed as sequence of things to be done“ = dargestellt als Folge von Anweisungen).
• Der Entwickler verwendet Kontrollstrukturen (z. B. Sequenz, Schleife, Verzweigung) zur Steuerung der Befehlsausführung.

Ebenfalls als tpyisch für diese Art des imperativen/prozeduralen Programmierens, aber nicht ausschließlich dort angewendet, gelten die nachfolgenden Merkmale (nach , ):

• Die Aufgabenstellung wird im Wesentlichen durch Bilden von Prozeduren, Funktionen oder Subroutinen implementiert (Konzept der Abstraktion. Dabei entsteht eine Hierarchie von Funktionen, die in ihrer Gruppierung nach beliebigen logischen Prinzipien gebildet werden kann. Der Startpunkt des Programms liegt in der Hauptprozedur - von der aus die Teilfunktionen aufgerufen werden. Bestimmte Befehle unterstützen das Durchleiten und die Rückgabe von Parameterwerten.
• Datenwerte werden als benannte Variablen definiert und über ihre Namen angesprochen" , sie werden von den Funktionen verändert und transformiert, Zugriff ist grundsätzlich von allen Anweisungen des Programms aus möglich.
• Diesen Variablen sind Datentypen zugeordnet, die jeweils nur bestimmte Instruktionen erlauben.
• Der Quelltext wird durch Compilierung und Einbindung zusätzlicher Funktionskomponenten (sprach- und/oder aufgabenspezifisch) zum ausführbaren Programm.

ABGRENZUNG:

Als Gegensatz zur imperativen Programmierung wird das Paradigma Deklarative Programmierung verstanden. Darin wird beschrieben, was das Programm erarbeiten/berechnen soll, aber nicht wie.

Wesentliche Unterschiede bestehen zum Beispiel auch zur objektorientierten Programmierung, wo die Anweisungen und der Code nach Objekten zusammengefasst sind. Das Prinzip der Datenkapselung (Information Hiding) wird in imperativen Sprachen oft dadurch umgesetzt, dass Prozeduren, die eine logische Einheit bilden, in Modulen oder Paketen zusammengefasst werden.

Einige imperative Programmiersprachen wie z. B. C++ und Java bieten neben imperativen/prozeduralen Merkmalen auch zusätzliche Sprachmittel, um andere Prinzipien wie z. B. die objektorientierte Programmierung zu unterstützen.

Nicht maßgeblich für die Einstufung als 'imperativ' ist die Tatsache, dass bei der physischen Ausführung von Computerprogrammen (im Prozessor) die einzelnen Befehle des Maschinencodes "Befehl für Befehl" ausgeführt werden; denn dies ist unabhängig vom praktizierten Paradigma immer so. Vielmehr setzt 'imperativ' voraus, dass „ein Entwickler Code erstellt, der detailliert die Schritte beschreibt, die der Computer zur Erfüllung der Aufgabe ausführen muss“ . Deklarativ erstellte Anweisungen etwa werden von übergeordneten/eingebundenen Systemkomponenten – nur 'basierend' auf dem Quellcode – in ausführbare Maschinenbefehle umgeformt (Beispiel 'SQL-Kommandos': Das DBMS interpretiert sie, bildet Maschinencode und lässt diesen ausführen).

Diskussion darüber

Abweichende Bezeichnungen: In der Literatur wird diese Vorgehensweise zum Teil auch 'imperativ/prozedural', 'algoritrhmisch' oder 'prozedural' genannt Wo wird die imperative Vorgehensweise prozedural genannt? (in und und in en:procedural programming als synonym.)

Ebenfalls als tpyisch für diese Art des imperativen/prozeduralen Programmierens, aber nicht ausschließlich dort angewendet, gelten die nachfolgenden Merkmale... Quatsch, wenn es dir bei prozeduraler Programmierung nicht gelingt willst du es hier probieren? Was imperativ bedeutet ist glasklar belegt; du musst es halt mal irgendwann akzeptieren. was passt da nicht? alles geht auf die genannten Quellen zurück.

Wesentliche Unterschiede bestehen zum Beispiel auch zur objektorientierten Programmierung, wo die Anweisungen und der Code nach Objekten zusammengefasst sind. Quatsch. Ein Programm welches auf Benutzereingabe wartet soll auf einmal nicht imperativ sein. Da verwechselst du wieder Stapelverarbeitung und Dialogverarbeitung. Auch hier rate ich dir mal die Literatur richtig zu lesen. was hat das mit Benutzereingabe zu tun? Das Merkmal (Daten/Funktionen) hast doch auch du für OOP hervorgehoben. Außerdem: Dies ist keine 'Gegenteil-Aussage' mehr. 'Benutzereingabe' ist ein sehr gutes Beispiel: Setzt der Quellcode diesen Eingabebefehl ab und wartet auf die Eingabe, dann ist das (exakt an dieser Stelle) klar imperativ; bestimmt der Benutzer, welche Eingabe wann gemacht wird, ist das 'hier' ereignisorientiert (der Quellcode bestimmt nicht die Reihenfolge) - unabhängig davon, dass z.B. der diese Eingabe dann behandelnde Code wieder imperativ sein kann.

Als Gegensatz zur imperativen Programmierung wird das Paradigma Deklarative Programmierung verstanden. Darin wird beschrieben, was das Programm erarbeiten/berechnen soll, aber nicht wie. Wesentliche Unterschiede bestehen zum Beispiel auch zur objektorientierten Programmierung, wo die Anweisungen und der Code nach Objekten zusammengefasst sind Da merkt man dass es schon mal logisch nicht stimmt. Es gibt entweder imperativ oder deklarativ; auf der Stufe gibt es nichts anderes. Das sind elementarste Grundlagen der Informatik. deklarativ: 'entweder/oder' bedeutet in Deutsch dasselbe wie 'Gegensatz'.

... oder den Code abhängig vom Eintritt bestimmter Ereignisse (gesteuert vom Eventhandler) ausführt. Die Paradigma-Zuordnung gilt insofern jeweils nur für den Quelltext von Programmen.. Ist es wirklich dein ernst? Das ist ja was fürs Humorarchiv. was soll da nicht mein Ernst sein? Es geht um 'Programmieren' - und da ist der Quellcode (in welcher Form auch immer) die Grundlage, die das Paradigma (bzw. mehrere) bestimmt (bzw. umgekehrt). Wenn du das pauschal anders siehst, wundert mich nicht, dass wir so weit auseinander liegen.

Du wechselst munter die Ebenen, Programmierung und Software, verwechselst ereignisorientierte Progammierung mit Dialogverarbeitung, verwechselst imperative und objektorientierte Programmierung, mischst noch kräftig prozedurale Programmierung darunter und schüttelst kräftig alles um dass es einem schlecht wird. Auf diesem Niveau kann man nicht diskutieren. Wenn du diesen Artikel in diese private Theorie-Richtung änderst, werde ich ihn revertieren. --Avron 20:43, 5. Dez. 2011 (CET)

---

Danke gleichfalls: Ich habe Antworten zu deinen Anmerkungen oben small eingesetzt und werde in meinem Text noch weitere Quellenreferenzen anlegen. Wenn du was nicht akzeptierst, musst du schon sagen, welche Aussage (aus welcher Quelle) du für nicht korrekt hältst.

Ich denke, dass du es bist, der bestimmte Dinge nur 'eindimensional' sieht, d.h.: Du berücksichtigst nicht, dass ein Paradigma einfach nur ein Stil ist, der sich durch bestimmte Merkmale auszeichnet, dass diese Merkmale und damit der Stil von mehreren Sprachen unterstützt werden können - und vor allem, dass die einzelne Programmiersprache und Entwicklungsumgebung damit mehreren Paradigmen entsprechen kann (weil eben deren Merkmale unterstützt werden). Und genau deshalb kann ein Programm auch mehreren Paradigmen gleichzeitig entsprechen. Wir sollten hier nicht Sprachen beschreiben, sondern nur jeweils das Paradigma. Dass in der Literatur diesbezüglich auch Ausdrücke und ihre Inhalte unterschiedlich oder synonym gebraucht werden, müssen wir auch akzeptieren - und nicht auf einem Standpunkt beharren, sondern sachlich darauf hinweisen. --VÖRBY 10:42, 6. Dez. 2011 (CET), aktuell: --VÖRBY 16:45, 8. Dez. 2011 (CET)

Ich habe die Text nochmal geringfügig angepasst und mit z.T. Quellenangaben versehen. In dieser Richtung müsste m.E. der Sachverhalt beschrieben werden; bisher gab es kaum Quellen und die Beschreibung war unvollständig. Allerdings basiert dieser Text nun auf der Annahme, dass iP und pP(2) dasselbe sind - was ja in den Quellen auch mehrfach so genannt ist. Persönlich würde ich für iP auch lediglich den Aspekt 'WIE / first this next that' als einziges Kriterium sehen. Die anderen, lt. Quellen weiteren relevanten Merkmale (zu pP2) wären dann aber nirgends zu finden. Dass diese zu einem Paradigma gehören und sie nicht nur 'die (frühere) klassische Programmierung' beschreiben oder nur als Gegensatz zu OOP dargestellt werden dürfen, steht für mich außer Frage. --VÖRBY 10:37, 7. Dez. 2011 (CET)

Beachte den Diskussionsbeitrag von mir und von heute in Diskussion:prozedurale Programmierung: Die Entwürfe nähern sich m.E. wieder an.--VÖRBY 18:24, 7. Dez. 2011 (CET)

Neuer Text (ohne Prozedural-Synonym)

(Einrückungen etc. bei Übernahme in den Artikel entsprechend anpassen) (Restliche Kapitel lt. Artikel übernehmen)

EINLEITUNG:

Imperative Programmierung ist ein Programmierparadigma; danach „besteht ein Programm (Anm.: der Quellcode) aus einer Folge von Befehlen, die vorgeben, in welcher Reihenfolge was vom Computer getan werden soll “. Die Bezeichnung geht auf lateinisch 'imperare' = 'anordnen, befehlen' zurück - inkl. der Bedeutung, dass Befehle (exakt) auszuführen sind.

Die imperative Programmierung ist das am längsten bekannte Programmierparadigma. Diese Vorgehensweise war, bedingt durch den Sprachumfang früher Programmiersprachen, ehemals die klassische Art des Programmierens und liegt zum Beispiel dem Entwurf von ALGOL, Fortran, Pascal, ADA, PL/I, C und allen Assemblersprachen zugrunde (nach ).

„Die meisten [...] Programmiersprachen, darunter auch OOP-Sprachen wie C#, Visual Basic, C++ und Java, unterstützen in erster Linie [auch] die imperative [...] Programmierung“ .

Abweichende Bezeichnungen: In der Literatur wird diese Vorgehensweise zum Teil auch 'imperativ/prozedural', 'algorithmisch' oder auch 'zustandsorientiert' genannt.

DETAILS (Merkmale)

(aus dem bisherigen Text verwendet): Das dem imperativen Paradigma zugrunde liegende abstrakte Ausführungsmodell ist eng angelehnt an die Ausführung von Maschinencode auf Computern, die nach der Von-Neumann-Architektur implementiert sind. Es existieren beispielsweise bedingte und unbedingte Sprunganweisungen. Der Status des Rechners bzw. des Programms ergibt sich aus dem Arbeitsspeicherinhalt und dem Zustand von Systemvariablen (z. B. Register, Befehlszähler ...).

Die besonderen Merkmale dieser Art des Programmierens sind (nach und ):

• Im Quellcode wird festgelegt, was in welcher Reihenfolge und wie zu tun ist: „First do this and next do that“ = schrittweises 'Fortschreiten' der Befehle; „viewed as sequence of things to be done“ = dargestellt als Folge von Anweisungen).
• Zur Steuerung der Befehlsausführung verwendet der Entwickler Kontrollstrukturen (z. B. Sequenz, Schleife, Verzweigung).

ABGRENZUNG:

Als Gegenentwurf zur imperativen Programmierung gilt das Paradigma Deklarative Programmierung. Darin wird vom Entwickler im Quellcode definiert, was das Programm erarbeiten/berechnen soll, aber nicht wie.

Nicht maßgeblich für die Einstufung als 'imperativ' ist die Tatsache, dass bei der physischen Ausführung von Computerprogrammen (im Prozessor) die einzelnen Befehle des Maschinencodes "Befehl für Befehl" ausgeführt werden; denn dies ist unabhängig vom praktizierten Paradigma immer so. Vielmehr setzt 'imperativ' voraus, dass „ein Entwickler Code erstellt, der detailliert die Schritte beschreibt, die der Computer zur Erfüllung der Aufgabe ausführen muss“ . Deklarativ erstellte Anweisungen etwa werden von übergeordneten/eingebundenen Systemkomponenten – und nur 'basierend' auf dem Quellcode – in ausführbare Maschinenbefehle umgeformt; Beispiel 'SQL-Kommandos': Komponenten der Systemsoftware des DBMS interpretieren sie, erzeugen daraus Maschinencode und lassen diesen ausführen.

Verständlichkeit des Artikels

Der Artikel ist verständlich, aber ihm fehlt die Anschaulichkeit. Es wäre gut, wenn jemand an einem Beispiel verdeutlichen könnte, was imperativ in Bezug auf eine Programmiersprache heißt. --Jan Mathys 18:21, 17. Dez. 2008 (CET)

Erledigt; ich habe ein Beispiel ergaenzt. --Gms 20:32, 29. Mär. 2009 (CEST)

Ob das ein gutes Beispiel ist? Beide Codes liegen m.E. so nahe beisammen, dass man sie nur als andere Dialekte bezeichnen könnte - die beide dem gleichem Paradigma folgen. Das Sort-Beispiel in Programmierparadigma wäre besser geeignet - wenn jemand den entsprechenden deklarativen Ausdruck ergänzen könnte.

Was man aber auch daraus erkennt: Wenn gesagt wird, imperativ beschreibe das WIE, deklarativ das WAS, dann wäre es wichtig festzustellen, auf welcher Detaillierungsstufe diese Aussage gilt. Zum Beispiel beschreibt die Formel 'A=B-C*D' mit Sicherheit nicht, wie das als Code im Detail abläuft (Punkt-vor-Strich etc.); dazu wird eine Art Plugin der Pr-Sprache aufgerufen - was technisch nichts anderes ist als ein Unterprogramm. Wo wäre aber dann die Grenze? Theoretisch beschreibt ja auch ein Move-long nicht genau, wie 'es geht' - aber das muss ja sicher noch als imperativ gelten, vielleicht auch die Formel. M.E. wird die 'imperative Schiene' dann verlassen, wenn der Quellcode nicht mehr bestimmt, "wo es weiter geht"; eingeschobene Funktionsauflösungen würden demnach nicht dazu gehören. Dann wäre aber auch das Beispiel zu deklarativ ggf. wieder imperativ. Auch müsste/könnte das heißen, dass es unterschiedliche Ebenen gibt, für die 'imperativ' bzw. 'deklarativ' gilt: einzelne Anweisung (s. Formel), Codeabschnitt (Prozedur?), ganzes Programm. Wer kennt hierzu 'belastbare' Definitionen?--VÖRBY 17:05, 8. Dez. 2011 (CET), zuletzt: --VÖRBY 11:24, 9. Dez. 2011 (CET)

M.E. wird die 'imperative Schiene' dann verlassen, wenn der Quellcode nicht mehr bestimmt, "wo es weiter geht"; eingeschobene Funktionsauflösungen würden demnach nicht dazu gehören. Dann wäre aber auch das Beispiel zu deklarativ ggf. wieder imperativ. Richtigerweise sagst du dass es dein Erachten ist. Nun steht aber die ganze Theorie der Informatik gegen dein Erachten.

Auch müsste/könnte das heißen, dass es unterschiedliche Ebenen gibt, für die 'imperativ' bzw. 'deklarativ' gilt: einzelne Anweisung (s. Formel), Codeabschnitt (Prozedur?), ganzes Programm. Wer kennt hierzu 'belastbare' Definitionen Ein Programm ist das Endprodukt, es ist ihm egal mit was für Paradigmen es programmiert wurde. Auch ein deklarative Programmiersprache übersetzt irgedwann in Maschinensprache. Diese Ebene die du einführen willst, gibt es nicht. Was es gibt ist ein "Paradigmenwechsel" z. B. bei Datenbankzugriffen wenn man z. B. mit Java eine Datenbank ausliest. Die Abfrage für die Datenbank ist in SQL, also so was wie deklarativ, geschrieben. Für das imperative Java ist das lediglich ein ganz normaler String. Wobei SQL keine wirkliche Programmiersprache ist...

Wie gesagt, wenn du Grundlagen der Informatik anders auslegst, sehe ich keinen Anlass für weitere Diskussion. 1+1 ist nun mal 2 und nicht 3. Es gibt auch kein Kompromiss auf 2,5. --Avron 22:43, 9. Dez. 2011 (CET)

---

Mit deiner wieder mal 'pampigen' Antwort stellst du dir kein gutes Zeugnis aus:

1. Ich hatte die Eignung des Beispiels hinterfragt. Hierzu hast du keinen Lösungsbeitrag eingestellt.
2. Ich hatte nach Quellen gefragt, die die erfragten Details belegen. Du schreibst nur wieder von der 'ganzen Theorie der Informatik' - das ist keine Quellenangabe, und schon gar nicht für dieses Detail.
3. Wenn imperativ i.W. 'das WIE beschreibende Befehle' bedeutet, dann ist zunächst nicht wirklich klar, was damit gemeint ist. Jedenfalls halte ich die Fragestellung für erlaubt. Das Paradigma heißt 'ProgrammierUNG', da ist ein 'Programm' nur eine (1) Ergebnis-Ausprägung davon - mit vielen unterschiedlichen Ebenen; du nennst es 'Paradigmenwechsel', wo wäre der Unterschied?
4. Dass SQL 'deklarativer PrograqmmierUNG' entspricht, kannst du überall selbst nachlesen.

In diesem Stil will jedenfalls auch ich nicht (mit Dir) weiter diskutieren. --VÖRBY 13:01, 10. Dez. 2011 (CET)

Meine Antworten sind nicht mehr so freundlich weil die extrem langen Diskussionen bisher so gut wie nichts erbracht haben. Auch hier jagst du wieder irgendwelchen unverständlichen Phantomen nach.

1. Man könnnte ein anderes Beispiel nehmen, aber das jetzige ist auch gut.
2. Was für Quellen für welche Details? Programmierung hört dort auf wo eine Black Box anfängt.
3. Ich verstehe nicht was daran nicht klar sein sollte was imperativ ist. Das halt das Grundproblem welches du hast. Wie willst du den Artikel verändern wenn du mit einem Begriff auf dem Kriegsfuß bist? Nochmals, einem (kompilierten) Programm ist es egal was für Paradigmen zugrunde liegen weil man daraus in der Regel nur eingeschränkt (Decompiler) den Quellcode generieren kann.
4. ??? SQL ist keine Programmiersprache, es ist eine Abfragesprache. Haskell ist Programmiersprarche.--Avron 17:22, 10. Dez. 2011 (CET)

---

VÖRBY hat mich um eine Stellungnahme gebeten. Unglücklicherweise kann ich keine deklarative Sprache (außer natürlich SQL, aber das sehe ich auch nicht als Pgm.sprache). Ich habe aber schon ein gewisses Verständnis, um was es geht. Den derzeitigen dt. Artikel halte ich wirklich für ausgesprochen schlecht, der englische ist besser, aber auch nicht das gelbe vom Ei, auch hier ist es mir (wie so oft bei "Paradigmen") zu dogmatisch. Ein paar Gedanken:

• der Begriff "imperativ" macht nur als Gegenstück zu "deklarativ" wirklich Sinn,
• man sollte die Abstraktionsebene nicht wechseln, wenn man den Begriff verwendet (Maschinencode ist immer imperativ), wie es z.B. der Abschnitt "Details" so ausgiebig tut (z.B. "Der Status des Rechners setzt sich aus dem Arbeitsspeicherinhalt und den Registerinhalten zusammen". Die Entfernung dieses pseudobedeutungsschweren Satzes hielte ich für einen nicht zu unterschätzenden Gewinn).
• die Grenze zwischen imperativ und deklarativ ist ausgesprochen unscharf. Imperative Sprachen haben deklarative Elemente und umgekehrt. Beispielsweise kann man das dynamische Binden (virtuelle Funktionen, Polymorphismus) (imperativer) objektorientierter Sprachen kaum als imperativ bezeichnen.
• das Prinzip: Imperative Sprachen haben vorwiegend das Ziel, dem System möglichst unzweideutig zu beschreiben, auf welche Weise es Schritt für Schritt was zu erledigen hat. Deklarative Sprachen definieren tendenziell Ausgangspunkt und Ergebnis einer gewünschten Operation, ohne das Verfahren genau zu spezifizieren.
• Letzteres kann man ganz gut an SQL erläutern. Bei einem Join (das Ergebnis) wird lediglich die Ausgangsbasis (die Tabellen und die Join-Spalten) definiert, nicht aber wie vorzugehen ist (siehe Joinalgorithmen).
• An letzterem Beispiel sieht man auch gut, dass beides seine Vor- und Nachteile hat: Der Optimizer kann abhängig von den Datenmengen in den Tabellen entscheiden, wie er vorgeht. Manchmal liegt er aber falsch und dann wird es schwierig, ihn durch Anlegen irgendwelcher Indizes auf den richtigen Weg zu zwingen.

Hoffe, das befruchtet Eure Diskussion ein wenig.--Cactus26 11:13, 11. Dez. 2011 (CET)

---

Hallo Cactus26, danke für deine Stellungnahme. Magst Du bitte nochmal konkret zwei Dinge in Augenschein nehmen und kurz kommentieren?

• Den 3. Absatz hier in diesem Abschnitt: Beispiel-Eignung und Fragestellung zu Ebenen von Pgm-Code. Sind das 'dumme Fragen' (die es ja angeblich nicht gibt)?
• Den neuen Textvorschlag zu 'imperative Programmierung' hier. Er beseitigt einiges von dem, was du für den Originaltext moniert hast - auf der Basis der genannten Quellen.

Grüße von --VÖRBY 11:02, 12. Dez. 2011 (CET)

Eins vorab: Wirklich fundiert sind meine Aussage hier nicht, ich habe nicht sonderlich recherchiert, es sind mehr persönliche Einschätzungen. Ich bin tats. der Auffassung, dass solche Fragestellungen nicht nötig sind, da der Begriff nicht scharf ist. Ich sehe es so: Das "Typusexemplar" von imperativ ist Maschinencode. Alle Sprachen, die von der Struktur her sich stark daran anlehnen, bezeichnet man als imperativ, eigentlich nur, um sie von deklarativen Sprachen abgrenzen zu können. Deklarative Sprachen lassen dem System tendenziell mehr Entscheidungsspielraum bei der Umsetzung des mittels der Sprache spezifizierten Programms. Und ich fände genau das wichtig, als erstes im Artikel klarzustellen. Die jetzige Einleitung (und auch Dein Vorschlag) lässt einen mehr dahinter vermutet, als tats. dahinter streckt.--Cactus26 08:02, 13. Dez. 2011 (CET)

Danke. 'Unschärfe' ist ein Problem für eine Enzyklopädie: Wenn man sagt etwas "lehne sich von der Struktur her stark an ... an" - was heißt das dann konkret? Insofern halte ich die belegten Definitionen (in der Einleitung und unter Details - mit der Grundaussage 'Reihenfolgefestlegung durch den Entwickler, d.h. im Quellcode') schon für einigermaßen klar; meine Fragestellungen (inkl. der nach Belegen) waren ein Versuch, das noch präziser festzustellen. Ich wünsch Dir eine gute Zeit: --VÖRBY 09:13, 13. Dez. 2011 (CET)

Änderung an der Geschichte

Plankalkül ist die älteste hohe Programmiersprache und nicht Fortran !! Fortran ist die älteste "NOCH IM GEBRAUCH" befindliche hohe Programmiersprache, nicht die Älteste ! (nicht signierter Beitrag von 84.175.199.252 (Diskussion) 15:23, 21. Sep. 2010 (CEST))

Etymologie

Der erste Bestandteil des Lemmas leitet sich vermutlich vom lateinischen imperare ab, was „befehlen“, „beherrschen“, „gebieten“, „herrschen“ bedeuten kann. Ich bin mir nicht sicher, habe auch keine mögliche Quelle. Allerdings könnte ein plumpes „befehlen“ richtig sein, schließlich ist die programmiererische Anweisung eine Art von Befehl. Die erklärende, etymologische Angabe wirkt ergänzend und hilft oft beim raschen Verständnis. Könnte man also mal andenken. -- Gohnarch^░ 23:43, 9. Mär. 2011 (CET)

Quelle für Aussage: deklarative Anweisung

In einer deklarativen Anweisung werden die zur Sortierung erforderlichen Angaben (Feldnamen etc.) als Parameter spezifiziert, z.B. "SORT (x,i,j)".

Quelle angeben oder diese Aussage gelöscht werden müssen.--Avron 16:16, 14. Dez. 2011 (CET)

unverständlich

Deklarativ programmiert werden – je nach verwendeter Entwicklungsumgebung / -Sprache – die Sortiervorgaben zum Beispiel über 'Eigenschaften' des jeweiligen Informationsmediums (bei 'Berichten' mit MS Access) oder als Parameter/Argument der 'SORT-BY'-Anweisung (etwa bei SQL) 'eingestellt'.

1. Was hat das mit Entwicklungsumgebung zu tun?
2. für mich unverständlich was damit gemeint ist?
3. warum ist das unter dem Beispiel Quicksort?
4. ist diese Änderung [11] überhaupt bezwecken? Ich sehe keine Verbesserung.--Avron 17:29, 14. Dez. 2011 (CET)

---

Ich habe deine Punkt nummeriert.

1. Vielleicht sollte man besser 'Entwicklungswerkzeug' sagen - das ist alles, womit 'programmiert' wird.
2. Gezeigt werden soll das deklarative Programmieren zum Beispiel bei Access-Reports oder mit SQL-Ausdrücken - was ja beides als deklarative Entwicklung gilt.
3. Das zeigt (als 'Beispiel'), dass man Daten bei imperativer Programmierung erforderlichenfalls explizit sortieren muss (das WIE im Vorgehen) und dass dieses bei deklarativer Entwicklung einfach nur 'deklariert' wird (das WAS).
4. Mit der Übernahme des Beispiels in den Detailartikel wird der übergeordnete Übersichtsartikel gestrafft und das dort schon vorhandene Beispiel um ein weiteres ergänzt.

Aus meiner Sicht können wir dieses Beispiel auch ganz rausnehmen; ich wollte es nur nicht einfach löschen. Aber es ist auf jeden Fall besser als das erste mit den Quadratzahlen. --VÖRBY 17:44, 14. Dez. 2011 (CET)

Ich habe den Edit zurückgesetzt, weil es keine sinnvolle Verbesserung des Artikels war. Ein Beispiel imperativ/deklarativ gibt es schon. Der Rest ist unverständlich bzw. nicht belegt und auch in falscher Form. Wenn hier was Verbessern ist, dann soll man das vorher verständlich machen was zu verbessern ist.--Avron 20:19, 14. Dez. 2011 (CET)

Bin einverstanden mit der Löschung, nicht aber mit deinen Argumenten: Dass Entwicklungswerkzeuge wie Reportgeneratoren, SQL-Abfragesprachen, auch Excel etc. zu den 'deklarativen' Instrumenten ('Sprachen') gehören, ist unbestritten (z.B. nach [12] oder [13] - was du vielleicht wieder als ungültige Quelle bezeichnen wirst).

Ein Beispiel sollte tatsächlich genügen. Nochmal: Ob das erste Beispiel ein gutes ist, bezweifle ich nach wie vor - denn in beiden Fällen wird die Lösung nach einer ähnlichen Syntax definiert. Aber lassen wir das. --VÖRBY 10:00, 15. Dez. 2011 (CET)

SQL gilt als deklarativ, manches andere kann man auch so bezeichnen. Das passt aber besser zu Deklarative Programmierung aber nicht als Beschreibung hier bei einem Beispiel.--Avron 12:11, 15. Dez. 2011 (CET)

schlechtes Codebeispiel

Die for()-Schleife in C ist ein schlechtes Beispiel für prozedurale Notation. Weil beim for() der Klammereinhalt nur deklariert, welches Schleifenverhalten gewünscht ist. Besser wäre, es mit while() auszuschreiben.

~~ -andy- (Diskussion) 16:47, 18. Okt. 2018 (CEST)

Imperative Programmierung versus algorithmische Programmierung

Imperative Programmierung und algorithmische Programmierung sind nicht synonym. COBOL-74 ist imperativ, aber nicht algorithmisch (keine Funktionen), im Prinzip noch nicht einmal prozedural: Es gibt nur PERFORM, ohne Übergabe von Parametern, und freier Auswahl, und was genau PERFORMed wird, bestimmt der Aufrufer (PERFORM xxx THRU yyy). --Jost Riedel (Diskussion) 12:37, 2. Jun. 2020 (CEST)