Diskussion:Prozedurale Programmierung

Kritik: COBOL, funktional vs. imperativ, C-Sprechweise

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 17:41, 14. Nov. 2012 (CET)

Sorry, aber COBOL als typische prozedurale Programmiersprache zu bezeichnen ist ein wenig übertrieben. Heutzutage geht das zwar, aber ursprünglich war das überhaupt nicht vorhanden, und man sieht auch daß das nachträglich aufgepfropft wurde. Somit ist es vielleicht eine prozedurale Programmiersprache, aber keineswegs eine typische.

Funktionale Programmierung ist ein gegensatz zu imperativen Programmiersprachen, nicht zu prozeduralen. --129.199.118.119 18:15, 9. Dez. 2006 (CET)

Zitat: »In vielen Programmiersprachen (z. B. alle Derivate der Programmiersprache C) ist das einleitende Schlüsselwort für eine Prozedur irreführenderweise „Funktion“.«

In den Meisten C-Derivaten gibt es meistens gar kein Schlüsselwort für eine Prozedur. Eine der wenigen Spracen, die das macht ist z.B. PHP. Diese ist aber kein C-Derivat im eigentlichen Sinne, sondern nur der C-Syntax angepass.

int main (int argc, char* argv[])

Dies wird zwar Funktion genannt, aber hier taucht das Schlüsselwort "Funktion" nicht auf.

Java

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 17:41, 14. Nov. 2012 (CET)

Java als Beispiel für prozedurale Programmiersprachen ist meiner Ansicht nach falsch, deshalb würde ich es gerne entfernen. Man kann in Java keine Prozeduren schreiben, sondern nur Methoden. Michi133 15:46, 30. Sep. 2007 (CEST)

Es ist nicht die Frage, wie die Dinger heißen, sondern dass solche 'Unterobjekte' gebildet und benutzt werden können. --VÖRBY 19:32, 22. Mär. 2011 (CET)

C#

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 17:41, 14. Nov. 2012 (CET)

Im C#-Artikel wird die sprache als objektorientiert beschrieben - herrscht da Uneinigkeit? (nicht signierter Beitrag von 77.180.118.239 (Diskussion) )

Hi. Um Diskussionen nachvollziehbar zu machen, ist es sinnvoll, Diskussionsbeiträge mit vier Tilden („~~~~“) zu unterschreiben. Die werden dann zu Benutzername/IP-Adresse und Zeitstempel expandiert. Zur Sache: Natürlich ist C# objektorientiert. Wo vermutest du Uneinigkeit? --j ?! 17:01, 15. Jan. 2008 (CET)

Objekt-orientiert und prozedural

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 17:41, 14. Nov. 2012 (CET)

Die Einordnung von OO unter den prozeduralen Ansatz ist meiner Meinung nach die falsche Sicht auf die OO. Objekt-orientierung verwendet eben nicht die Zerlegung in Prozeduren, sondern in Objekte mit eigenständigem Verhalten. Beides sind imperative Ansätze, die sich aber widersprechen. Dass Objekte Methoden verweden, die einzelne Fähigkeiten der Objekte isolieren, hat nichts mit dem prozeduralen Ansatz zu tun.

MWinckler 18:32, 21. Jun. 2010 (CEST)

Ich sehe das genau so. Wenn im Artikel steht "Prozeduren ermöglichen lediglich die Abstraktion und Zerlegung ausführbaren Codes, während der objektorientierte Ansatz Daten und Code in logischen Einheiten zusammenfasst.", so halte ich das nicht für korrekt:

• Mit 'Prozeduren' i.S. von Codegruppen hat das m.E. wenig zu tun; übrigens praktizierte man das auch schon mit Assembler (wo man Unterroutinen mit BAL oder BALR aufrief). Außerdem könnte das 'lediglich' bedeuten, dass das Prozedurbilden gerade nicht spezifisch für den Begriff ist, sondern 'lediglich' der Zerlegung dient.
• Vielmehr meint 'prozedural' m.E., dass der Entwickler die Ablaufreihenfolge selbst und beliebig festlegt ("fortschreiten"). Auch aus dem lat. Wortstamm ergibt sich nur dieses 'fortschreiten', in keiner Weise ein Aspekt von 'Gruppenbildung'.

Man könnte also bestenfalls sagen: "Prozedurales Programmieren ermöglicht die Abstraktion und Zerlegung ausführbaren Codes in beliebiger - und sogar ohne - Struktur, während der objektorientierte Ansatz Daten und Code in logische, an Objekten orientierten Einheiten zusammenfasst und die Reihenfolge der Verarbeitung vom Eintritt der (objekt-orientierten) Ereignisse bestimmt wird."

Durch diese Zweideutigkeit entstand wohl auch die Aussage, dass durch das prozedurale Programmieren der Quellcode mehrfach verwendbar werde; sie bezieht sich wieder auf den Begriff 'Prozedur' i.S. von Unterprogramm. Das Ziel 'Mehrfachverwendbarkeit' wird jedoch in allen Programmier-Paradigmen angestrebt und mit ähnlichen Mitteln (Module, Proc's, Makros etc.) unterstützt.

Fazit: 'Fortschreiten' und 'Gruppenbildung' sind disjunkte Begriffe. Prozedurale Programmierung meint m.E. Ersteres. Möglicherweise könnte man feststellen, dass mit pP zwei unterschiedliche Dinge gemeint sind.

--VÖRBY 18:55, 7. Mär. 2011 (CET), aktuell: --VÖRBY 09:29, 10. Mär. 2011 (CET)

Habe mal gegoogelt.

• Die meisten Unterlagen aus Uni's scheinen den Ursprung dieses Begriffs bei den 'Prozeduren' zu sehen - was mich wundert; denn wohl in allen Sprachen kennt man sowas - wenn auch unter anderen Begriffen. Haben die alle voneinander abgeschrieben  ;-) und die Begriffsverwechslung nicht bemerkt?
• 'Prozedural' i.S. von seriell kommt aber auch vor. Als Wesensmerkmale werden genannt: algorithmische Sichtweise steht im Vordergrund; am Ablauf orientiert; Fokus liegt auf Verarbeitungsschritten; Trennung von Daten und Funktionen; bestimmte Sprachkonstrukte. Dabei Dabei werden diese Kriterien als Wesensmerkmale der prozeduralen Programmierung aufgezählt.

Zu 'Prozeduren sagen diese Beiträge (z.B. ein 'Handbuch der Informatik') u.a.: "Prozeduren sind hierbei ein wichtiges Mittel zur Modularisierung". Dies wird aber nicht als kennzeichnend für den Begriff bezeichnet.

Fazit: Es kursieren unterschiedliche Definitionen - von denen ich nach wie vor die eine für falsch halte. --VÖRBY 18:46, 9. Mär. 2011 (CET), aktuell: --VÖRBY 09:29, 10. Mär. 2011 (CET)

Wenn das Bilden von Prozeduren (i.S. von Codegruppen) das zentrale Wesensmerkmal der prozeduralen Programmierung wäre, dann wäre sie identisch mit der modularen Programmierung. Das trifft aber m.E. absolut nicht zu! Insofern MUSS der Artikel aus meiner Sicht redigiert werden!
--VÖRBY 09:57, 10. Mär. 2011 (CET)

Kommt pP nur von Prozedur?

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 17:41, 14. Nov. 2012 (CET)

Die Frage,

• ob die bisherige Defintion von pP korrekt ist (i.W.: weil in Prozeduren programmiert wird)
• oder ob es auch eine andere Definition gibt (fortschreitend, viele andere Merkmale, siehe Texte),

entfachte eine größere Diskussion, die in den Unterkapiteln hier gegliedert ist:
Struktur neu gegliedert: --VÖRBY 13:36, 9. Apr. 2011 (CEST)

Neuer Text - Entwurf

Bearbeitungsbemerkungen

Hallo zusammen, den nachfolgenden Text möchte ich im Artikel einstellen und den alten ersetzen, weil er m.E. den Begriff falsch oder zumindest unvollständig definiert. Einwände bitte direkt im Text einarbeiten; über die Beobachtungsliste erkennt man die Veränderungen. Nach einigen Tagen werde ich dann die Ersetzung vornehmen. Gruß --VÖRBY 16:00, 13. Mär. 2011 (CET)

Achtung, der Text wurde zwischenzeitlich (vereinbarungsgemäß) mehrfach verändert. Ursprüngliche / alte Fassungen können ggf. über die Versionsgeschichte rekonstruiert werden. --VÖRBY 10:24, 14. Mär. 2011 (CET), aktuell: --VÖRBY 20:07, 17. Mär. 2011 (CET)

Neu gefasst: --VÖRBY 17:35, 20. Mär. 2011 (CET)
Div. Detailüberarbeitungen, Links: --VÖRBY 09:31, 21. Mär. 2011 (CET) Zusammenhang 'Beschreibungen entstanden erst mit der OOP' unter 'Geschichte':--VÖRBY 09:22, 25. Mär. 2011 (CET)
Definitionen erweitert und dann umgedreht: --VÖRBY 14:08, 25. Mär. 2011 (CET)
Umschreiben auf zwei unabhängige 'Begriffe' für den selben 'Terminus'--VÖRBY 17:55, 7. Apr. 2011 (CEST)
Vereinigen der beiden Beschreibungen: --VÖRBY 18:58, 8. Apr. 2011 (CEST)
Änderen der Beschreibung auf zwei unterschiedliche Begriffe; Quellenangaben nur zur Dokumentation, nicht unbedingt für den Artikel geeignet. --VÖRBY 13:25, 17. Jun. 2011 (CEST)
Texte nach aktueller Diskussion nochmal auf konkrete Quellen angepasst - und jene genannt.--VÖRBY 13:57, 23. Nov. 2011 (CET)
Texte nach Google-books (Quelle#2 von Zahnradzacken) überarbeitet: --VÖRBY 13:12, 25. Nov. 2011 (CET)
Merkmale aus Quelle#3 eingearbeitet; siehe auch Versionsgeschichte der Diskussion: --VÖRBY 19:13, 29. Nov. 2011 (CET)
Text gem. der übereinstimmenden Erkenntnis '2 Bedeutungen' nochmal/wieder umgestellt: --VÖRBY 17:26, 30. Nov. 2011 (CET)
'Paradigma' vermieden, Quellen etc. ergänzt: --VÖRBY 12:41, 1. Dez. 2011 (CET)

Einleitungstext

Alle Überschriften sollten bei Übernahme in den Artikel entsprechend angepasst werden, EINLEITUNG also entfernt etc.

Die nachfolgende Einleitung kann entfallen; sie ist in pP bereits enthalten und sollte dort aktualisiert werden; siehe unten.--VÖRBY 21:28, 1. Dez. 2011 (CET)

Prozedurale Programmierung ist eine bestimmte Art und Weise, Computerprogramme zu entwickeln. Der Ausdruck wird in der Literatur sehr unterschiedlich beschrieben und steht im Wesentlichen für die beiden folgenden Bedeutungen:

1. 'Prozedurale Programmierung' wird als grundlegender Programmierstil verstanden, nach dem – als wesentliches Merkmal – das WIE der Problemlösung im Vordergrund steht: Ein Programm schreitet sozusagen von Anweisung zu Anweisung voran, was dem lateinischen Wort „procedere“ – voranschreiten – entspricht. Dieses Vorgehen war in den Zeiten früherer Programmiersprachen die 'klassische' Art der Programmentwicklung. So interpretiert wird dieser Ausdruck zum Teil auch als Synonym für 'imperative Programmierung' oder 'algorithmische Programmierung' etc. benutzt oder auch der Terminus 'imperativ/prozedural' verwendet.
2. Nach einer engeren Interpretation wird der Ausdruck - wörtlich genommen - als das Programmieren unter Verwendung von Prozeduren verstanden. Auch hierzu liefert die Literatur auch alternative Ausdrücke wie 'modulare Programmierung', 'strukturierte Programmierung', 'prozedurale/modulare Programmierung' oder ähnlich, Ausdrücke, die jedoch auch mit anderen Bedeutungen belegt sind.

Ansatz pP2 'Sequentielle Anweisungsfolge

Details dieses Abschnitts sollten nach aktuellem Stand (1.12.11) im Lemma Imperative Programmierung eingestellt und entsprechend angepasst werden. --VÖRBY 21:28, 1. Dez. 2011 (CET)

Diese Art der Entwicklung war, bedingt durch den Sprachumfang früher Programmiersprachen, ehemals die klassische Art des Programmierens. Doch sind auch bestimmende Eigenschaften der prozeduralen Entwicklung teilweise noch in neueren Programmiersprachen anwendbar.

Die besonderen Merkmale dieser Art des Programmierens sind (abgeleitet aus und (temporär in English) ):

• Ausschließlich im Quellcode wird festgelegt, was in welcher Reihenfolge und wie zu tun ist ("First do this and next do that"; "viewed as sequence of things to be done").
• Hierzu wendet der Entwickler Kontrollstrukturen an (z. B. Sequenz, Schleife, Verzweigung) zur Steuerung der Befehlsausführung. Bestimmte Befehle Unterstützen das Aufrufen von Prozeduren und das Durchleiten und die Rückgabe von Parameterwerten.
• The [global] data in the programm can be accessed by any function in the program; data move openly around the system from function to function. Functions transform data from one form to another.)

Ebenfalls als tpyisch für diese Art prozeduralen Programmierens, aber nicht ausschließlich dort angewendet, gelten – ebenfalls nach den o.g. Referenzen – die nachfolgenden Merkmale:

• Die Aufgabenstellung wird hauptsächlich durch Bilden von Prozeduren, Funktionen oder Subroutinen implementiert (Konzept der Abstraktion). Dabei entsteht eine Hierarchie von Funktionen, die jeweils sequentiell abgearbeitet werden. Die Gruppierung und Hierarchie kann beliebigen logischen Prinzipien entsprechen. Der Startpunkt des Programms liegt in der Hauptprozedur - von der aus die Teilfunktionen aufgerufen werden. "devided into number of functions".
• Datenwerte werden als benannte Variablen definiert und über ihre Namen angesprochen.
• Diesen Variablen sind Datentypen zugeordnet, die jeweils nur bestimmte Instruktionen erlauben.
• Der Quelltext wird durch Compilierung und Einbindung zusätzlicher Funktionskomponenten (sprach- und/oder aufgabenspezifische) zum ausführbaren Programm.

Als typische Vertreter prozeduraler Programmiersprachen gelten Fortran, BASIC, COBOL, ALGOL, C und Pascal.

Geschichte:
Die Entwicklung prozeduraler Programmiersprachen und -techniken basiert auf der von-Neumann-Architektur, beginnend mit den Assemblersprachen weiter entwickelt in den späteren Hochsprachen. In zahlreichenden Programmiersprachen sind inzwischen Merkmale unterschiedlicher Paradigmen, vor allem des objektorientierten Ansatzes (als Erweiterungen oder alternativ) verfügbar (z. B. in Java, VBA, PHP, SQL ...).

Bei der physischen Ausführung von Computerprogrammen (im Prozessor) werden die einzelnen Befehle (= Maschinenbefehle) immer, unabhängig vom praktizierten Paradigma, "Befehl für Befehl" ausgeführt. Nicht prozedural entwickelte Codeteile sind dabei einer übergeordneten Systemebene unterstellt, die die codierten Anweisungen zum Beispiel in Maschinenbefehle umwandelt (etwa bei SQL-Kommandos das DBMS) oder den Code abhängig vom Eintritt bestimmter Ereignisse ausührt. Die Paradigma-Zuordnung gilt insofern jeweils nur für die Programm-Ebene, für die man programmierten Code betrachtet.

Ein Gegensatz zur prozeduralen Programmierung ist z.B. die objektorientierte Programmierung, wo die Anweisungen den Objekten zugeordnet/unterstellt sind und die Reihenfolge der Verarbeitung in der Regel vom Eintritt gewisser (externer) Ereignisse gesteuert wird. Bei der deklarativen Programmierung spezifiziert der Entwickler nicht das WIE, sondern nur das WAS; die Lösungsanweisungen werden sprachintern generiert.

Ansatz pP1 'Programmieren mit Prozeduren'

Dieser Ansatz ist im derzeitigen Stand des Artikels pP dokumentiert.

• Die Sätze zu 'procedere' und zu 'Reihenfolge' müssten entfallen - gehören zu pP2, also zu iP.
• Hinweis aufnehmen, dass pP auch als Synonym für 'imperative Programmierung' gebraucht wird oder auch 'algorithmische Programmierung' oder 'imperativ/prozedural' (jeweils mit Quellen, s.o.) genannt wird.

--VÖRBY 21:28, 1. Dez. 2011 (CET)

Weitere Texte

(Nur Textkonserven, die i.Z. mit der Überarbeitung der Einleitung i.W. nicht aktualisiert wurden.) --VÖRBY 13:25, 17. Jun. 2011 (CEST)
noch zu entscheiden, ob diese auch übernommen werden: --VÖRBY 13:12, 25. Nov. 2011 (CET)
Entfernt - nach tw. Übernahme nach oben. --VÖRBY 17:26, 30. Nov. 2011 (CET)

Einzelnachweise

Die Quellenangaben sollten noch durch 'offiziellere' Belege ersetzt bzw. formal auf funktionierende Links umgestellt werden.

Diskussionen über den neuen Text

Jeweils aktuelle Textform siehe Versionsgeschichte --VÖRBY 17:38, 20. Mär. 2011 (CET)

Gefällt mir nicht wirklich. Wobei ich noch selbst einige Werke wälzen muss wie das definiert ist. Vor allem verstehe ich nicht was die algorithmische Sichtweise mit der prozedurallen Programmierung zu tun hat. Würde das bedeuten dass das komplementäres Paradigma, die objektorientierte Programmierung, nicht der algorithmischen Sichtweise folgt?

Siehe auch Algorithmus (...Schritte); deshalb hatte ich zusätzlich "die Abläufe" mit reingenommen. Im Ggs. zu OO wird der Ablauf - wie beschrieben - ausschließlich vom Programm bestimmt, bei der OOP ist das natürlich auch der Fall, aber nur innerhalb von Methoden, die über die Klassen und deren Ereignisse angesteuert werden.--VÖRBY 10:24, 14. Mär. 2011 (CET)

Ich finde den aktuellen Ersten Satz ziemlich richtig und klar beschrieben. Prozedurale Programmierung ist der Ansatz, Computerprogramme aus kleineren Teilproblemen (oder genauer: Aufgaben), die als Prozeduren bezeichnet werden, aufzubauen.

Darin liegt ja wohl das Problem, es gibt da wohl unterschiedliche Ansichten.--VÖRBY 10:24, 14. Mär. 2011 (CET)

Es ist auch kein guter Stil mitten im Artikel auf einmal mit einer anderen Definition neu zu beginnen.

Wenn es aber unterschiedliche Definitionen gibt, darf und sollte man m.E. darauf hinweisen. --VÖRBY 10:24, 14. Mär. 2011 (CET)

Meiner Meinung nach ist die prozeduralle Programmierung das konsequente Nutzen von Unterprogrammen anstatt Sprunganweisungen damit es nicht zu Spaghetticode kommt. Wie gesagt, ich schaue mal nach was andere Werke sagen.--Avron 20:47, 13. Mär. 2011 (CET)

Ein paar Quellen auf die schnelle, die meine Meinung belegen: [5], [6], [7], [8]

Diese Links kann ich leider nicht öffnen, sie zeigen leere Seiten an.--VÖRBY 12:26, 14. Mär. 2011 (CET)

Einen guten Gesamtüberblick habe ich hier [9] gefunden. Demanch ist die Struktur:

• Imperative Programmierung
  • unstrukturierte Programmierung
  • Strukturierte Programmierung
  • Prozedurale Programmierung
  • Funktionale Programmierung Begriffsverwirrung: obwohl es funktionen auch in imperativen Sprachen gibt, wird der Begriff eher für deklarative Programmierung verwendet
  • Modulare Programmierung
  • Objektorientierte Programmierung
• Deklarative Programmierung

Eigentlich müssten wir erst "Imperative Programmierung" angehen...--Avron 21:08, 13. Mär. 2011 (CET)

Halte das prinzipiell für eine gute Idee. Der Artikel so wie er jetzt ist, ist schwer lesbar, nicht mit Quellen belegt, vermutlich POV und recht kurz. Meine Änderungen am Vorschlag hab ich mal eingearbeitet (stilistische Änderungen, links auf en:wikipedia raus (selbstlink), link auf :8080 raus (kein "gültiger" weblink), modulare Programmierung ist mehr als Aufteilen in Prozeduren - Module liegen über Prozeduren, prozedural kommt garantiert von procedure (engl) und nur indirekt von procedere (lat) was lässt dich so sicher sein? --VÖRBY 12:26, 14. Mär. 2011 (CET), Vergleich mit OO raus (wenn dann unten ein Abschnitt [halte ich auch für gut] "vergleich zu anderen Programmierparadigmen"))... --Sebastian.Dietrich ✉ 21:53, 13. Mär. 2011 (CET)

Mein Hinweis auf 'Module und Modulare P.' sollte nicht die ganze mP beschreiben, sondern nur darauf hinweisen, dass die Eigenschaft 'Modulbildung' nicht DAS einzige Kriterium für prozedurale P. sein kann. Schließlich könntest du dir ein Programm vorstellen, das keinerlei "Funktion, Modul, Prozedur ..." enthält, sondern nur aus unstrukturiertem Code und ggf. einigen Rückverzweigungen (goTo ...) besteht. Wäre das dann nicht 'prozedural'? Was dann? Jedenfalls wären die Befehle 'fortschreitend'. --VÖRBY 10:24, 14. Mär. 2011 (CET)

Wenn ich mir jetzt den gekürzten Vorschlag noch mal durchlese, bin ich nach wie von der Meinung, dass es keine Verbesserung des Artikels ist. algorithmische Sichtweise und die Abläufe im Mittelpunkt sind das Wesen der imperativen Programmierung. Bestimmte Sprachkonstrukte werden genutzt und von der Programmiersprache unterstützt, z.B.: Sequenzen, Blöcke, If-then-else (Verzweigungen), Schleifen (While ...). sind ein Wesen der strukturierten Programmierung. Wenn ich alles steichen würde was ich für falsch halte, würde nicht vom Vorschlag übrig bleiben. Ich vermute stark das bei dem Vorschlag Prozedurale Programmierung als Synonym für Imperative Programmierung angenommen wurde.

Nein, wenn WP richtig definiert (auch ist die o.g. Aufzählung ein Beweis dafür), dann ist die imperative Programmierung ein "sehr großer Überbegriff" für alles, wass nur irgendwie Code-Folgen enthält - und das Komplement zu 'deklarativ'. Deshalb wird sowohl die OOP also auch die pP als imperativ geführt. Hier im Artikel geht es aber um die Definition und Erläuterung von 'prozedural' - und dabei können i.W. die Gegensätze zu OOP dienen; nicht zufällig erscheinen bei Google für den Suchbegriff 'prozedural' jede Menge Artikel, die eigentlich die OOP beschreiben, die sie aber über die Unterschiede zur "prozeduralen P." (nicht zur imperativen - was auch sinnlos wäre, weil OOP auch i. ist) erläutern; und da gehört die Proozedurbildung nicht als begriffsbildendendes Kriterium dazu. --VÖRBY 10:45, 14. Mär. 2011 (CET)

--Avron 22:48, 13. Mär. 2011 (CET)

Hallo zusammen, danke für die engagierte Mitdiskussion. Auch sie zeigt, wie das "ganze Internet", dass es hier unterschiedliche Definitionen zu geben scheint, evtl. auch dialektisch begründet. Hier müsste man also zunächst ansetzen. Dabei sehe ich folgende Möglichkeiten:

• prozedural ist deutlich mehr als 'Prozedur'-orientiert: Dann sollte man den Artikel in meinem Sinn ändern und auf eine zweite, engere Definition (Prozeduren) hinweisen.
• Prozedural geht lediglich auf 'Prozudur' zurück geht: Dann passt die bisherige Beschreibung annähernd. Allerdings wäre das dann m.E. kein 'Paradigma', sondern lediglich ein Programmierstil. Kennt Ihr eine P-Sprache, bei der man keine Prozeduren (oder wie immer man das nennen mag) verwendet? Insofern wäre dann ein Hinweis auf die Nähe zu 'modulare P' angebracht.
• Es gibt zwei Definitionen; dnan muss das im Artikel dargestellt werden.

Wie die Definition auch ist: Man sollte sie zum Maßstab zur Feststellung benutzen können, ob eine Programmierung prozedural ist oder nicht - und warum; s.a. Definition#Definitionsregeln und -Anforderungen. Weitere Anmerkungen habe ich in Euren Texten eingestreut. Wollt Ihr Euch bitte meine Antworten nochmal ansehen und mitteilen, wofür Ihr plädiert? Danke. Viele Grüße--VÖRBY 10:24, 14. Mär. 2011 (CET), aktuell --VÖRBY 12:26, 14. Mär. 2011 (CET)

Ich verstehe noch nicht welche um welche verschiedenen Definitionen es geben soll. Kannst du das noch mal erläutern? Sonst habe ich das Gefühl dass wir nicht vom Gleichen reden.--Avron 14:03, 14. Mär. 2011 (CET)

Hallo Avron, die von mir monierte Diskrepanz ist folgende:

1. Die derzeitige Definition sagt i.W., dass prozedurale Programmierung dann vorliegt, wenn ein Programm in 'Prozeduren' gegliedert ist. Weitere Kritereien scheint es nicht zu geben.
2. Nach meiner Auffassung gibt es für prozedurale Programmierung andere Kriterien; I.W.: wenn in einem Programm die gesamte Verarbeitung, auch bezüglich der Reihenfolge, im Code festgelegt ist, "Schritt für Schritt" auszuführen; wenn Daten und Funktionen getrennt sind (siehe 'Merkmale'). Prozeduren können dabei natürlich verwendet werden, sind aber nicht das begriffsbestimmende Kriterium.

In vielen Netzbeiträgen wird die prozedurale Programmierung als Gegenstück zur OOP beschrieben; siehe auch meine ursprünglichen Links. Als wesentlicher Unterschied wird dabei darauf hingewiesen, dass in OO- und ereignis-orientierten Programmiersprachen Daten und Funktionen eine Einheit bilden und der Zeitpunkt der Verarbeitung von externen Ereignissen abhängt, also keine Vorgangs-/funktionsbezogene Verarbeitung stattfindet, sondern eine objektbezogene. Grüße von --VÖRBY 19:21, 14. Mär. 2011 (CET)

Zumindest die Verarbeitung "Schritt für Schritt" ist das Wesen der Imperative Programmierung, von daher kann es nicht eine Besonderhein der Prozeduralen Programmierung sein. Natürlich wird die prozedurale Programmierung auch Schritt für Schritt ausgeführt aber das deswegen weil es eine imperative Programmierung ist. Auch in der objektorientieren Programmierung passiert die Verarbeitun Schritt für Schritt.

Aber nicht vom Anfang des 'Programms' bis zum Ende, sondern immer nur innerhalb eines Objekts / Ereignisses - während ein prozedural geschriebenes Programm vollständig die Kontrolle über die Verarbeitungsfolge hat. Das ist bei der imperativen P. jedoch nicht von Bedeutung; hier geht es nur darum, dass es überhaupt "Befehle" (imperare) gibt, nicht jedoch darum, wann und in welcher Weise diese ausgeführt werden. Auch werden Mechanismen der OOP wie Vererbung ... nicht vom Programmierer als Sequenz 'programmiert', sondern nur irgendwo (nicht Schritt für Schritt) definiert und von den Sprachenkomponenten ausgeführt. --VÖRBY 20:08, 14. Mär. 2011 (CET)

Ich glaube so langsam vertehe ich wo dir der Schuh drückt. Bei der prozeduralen Programmierung hat man die vollständige Kontrolle über die Verarbeitungsfolge, bei OOP nicht (im Wesentlichen ja; siehe jedoch 'Merkmale'; --VÖRBY 08:26, 15. Mär. 2011 (CET)). Auf der anderen Seite ist das bei der strukturierten oder modularen Programmierung auch so. Ja, deine Aufzählung nennt verschiedene Programmierstile; diese können aber nicht gegeneinander abgegrenzt werden - vielleicht auch ein WP-Definitionsproblem. --VÖRBY 08:26, 15. Mär. 2011 (CET) Und jetzt komme ich zum Punkt: In der Literatur, vor allem zur praktischen Programmierung, wird oft nur von prozeduralen und der objektorientierten Programmierung als den grundsätzlich zwei möglichen Konzepten gesprochen. Das sind wohl auch die bedeutendsten und die, die sich am stärksten unterscheiden - aber nur nach 'meiner' ;-) Definition; nach der bisherigen wären sie überhaupt nicht disjunkt.--VÖRBY 08:26, 15. Mär. 2011 (CET) In der Informatik-Theorie sind die prozedurale und objektorientierte Programmierung Paradigmen unter weiteren. Ich denke, all diese Varianten kann man irgendwie als Paradigmen bezeichnen.--VÖRBY 08:26, 15. Mär. 2011 (CET) Habe ich deine Intention verstanden? Wenn dem so ist, eine Lösung habe ich, zumindest aktuell, nicht parat, da müsste ich noch mal in mich gehen.--Avron 20:24, 14. Mär. 2011 (CET)

Bei der Trennung von Daten und Funktionen stimme ich dir zu, das scheint ein Wesen der prozeduralen Programmierung zu sein. Sollte man aber besser belegen und herausarbeiten.--Avron 19:41, 14. Mär. 2011 (CET)

Guten Morgen Avon. Mein Vorschlag: Man muss darauf hinweisen, dass es es unterschiedliche Definitionen gibt - wie das in zahlreichen anderen WP-Artikeln auch geschieht. Dabei müssen beide jedoch klar auseinander gehalten werden. Viele Grüße--VÖRBY 08:26, 15. Mär. 2011 (CET)

Hallo Vörby, die Diskussion wird etwas unübersichtlich. Meine Meinung dazu ist: Es gibt keine unterschiedliche Definitionen, allerdings werden die verschiedenen Definitionen der imperativen Programmierungen in die zwei Paradigmen (prozedurale und objektorientierte) subsumiert. Das eine ist der akademische Ansatz, das andere wie das in der Praxis erklärt wird.--Avron 11:36, 15. Mär. 2011 (CET)

@Avron: Ja, in Wikipedia gibt es keine unterschiedlichen Definitionen. Aber die Literatur, auch im Internet, kommt zu sehr unterschiedlichen Aussagen: Ein Teil davon (haben die aus Wikipedia 'abgekupfert'?) verwenden die triviale, m.E. unzulässige Ableitung (u.a. weil nicht komplementär zu OO) von 'Prozedur' anstelle der Ableitung von 'procedere = fortschreiten'. Viele andere Artikel zeigen gänzlich andere Kriterien auf: Vor allem dann, wenn OO und pP als gegensätzliche Paradigmen beschrieben werden, ist unter pP viel mehr gemeint als einfach das Bilden von Prozeduren. Für mich ist das eine total andere Definition!
Du meintest unter deiner 'subsummiert'-Aussage wahrscheinlich "unterschiedliche Ausprägungen der imperativen Programmierung"; gemäß Deiner Auflistung sind das aber nicht nur die OO und die pP. Und wie oben schon festgestellt, hilft uns das auch nicht weiter, weil beide als imperativ gelten.
Ich möchte deshalb demnächst den Artikel entsprechend ergänzen und eine zweite Definition (mit den ursprünglichen Quellenverweisen) einstellen und zusätzlich die schon getexteten 'Merkmale' einstellen. Danke für die Mitarbeit. --VÖRBY 12:50, 15. Mär. 2011 (CET)

Was ich soeben feststellte: In Programmierparadigma wird die 'OO' als eigene Kagtegorie unter 5 Paradigmagruppen aufgeführt, also nicht als Ausprägung der imperativen Programmierung. Und auch 'prozedurale Programmierung' wird dort wiederum anders definiert, als 'Funktionen ohne Rückgabewert'. Jetzt wird es total konfus! Wikipedia-Praxis? Viele Grüße: --VÖRBY 09:29, 17. Mär. 2011 (CET)

Ich habe zuletzt kein Feedback mehr erhalten und deshalb den o.g. Textentwurf nach den HIER zuletzt beschriebenen Erkenntnissen angepasst. Übernahme in den Artikel "demnächst". --VÖRBY 17:35, 20. Mär. 2011 (CET)

Gefällt mir nach wie vor nicht. Die angegeben Quellen sind leider nicht verwendenswert.--Avron 08:17, 24. Mär. 2011 (CET)

Gefällt nicht: Warum? 'Ziehen' die von mir genannten Argumente nicht? Welche konkret? Oder dass es zwei Definitionen zu geben scheint?

Quellen: Warum sollten die nicht vewendbar sein? Außer 'Wiki' (wäre auch Wikipedia keine verwendbare Quelle?) halte ich die anderen für etabliert.

Gruß von --VÖRBY 08:53, 24. Mär. 2011 (CET)

Gefällt nicht ist natürlich zu flapsig. Wie besprochen: es its nicht richtig dargelegt, es ist nicht logisch, es ist nicht belegt bzw. was anderes ist belegt. Du stützt dich auf 3 sehr schwach Quellen. Das eine ist ein Wiki, die zweite ist eine Mustervorlage(?) die dritte ist zur Zeit nicht erreichbar wohl auber auch nicht sehr überzeugend.--Avron 10:09, 24. Mär. 2011 (CET)

Ich glaube langsam, das ist ein Glaubenskrieg. Jedenfalls halte ich diese triviale "Definition", die einen Sachverhalt nennt, den es in allen Paradigmen gibt, nicht für plausibel; aus meiner Sicht ist DAS "nicht logisch". Habe oben wichtige Argumente zu meiner Ansicht nochmal fett hervorgehoben, und ich werden nochmal validere Quellen eruieren.

--VÖRBY 13:39, 24. Mär. 2011 (CET)

Vörby, es ist bestimmt kein Glaubenskrieg. Dass der Begriff Prozedurale Programmierung in verschiedenen Facetten verwendet wird, haben wir schon diskutiert. Vor allem dass es in der Praxis seit den 90ern nur um die Unterschiede zwischen prozeduralen und objektorientierten ankommt, dieser Aspekt wird nicht im Artikel nicht erklärt. Da habe ich dir ja auch zugestimmt. Aber der aktuelle Vorschlag geht so nicht. Ich dachte wir haben darüber diskutiert, aber du hast den Vorschlag nicht dem Diskussionsstand angepasst. Der aktuelle Stand des Artikels erklärt den Begriff immer noch besser, und ist durch klare Quellen belegt.

Bei der prozeduralen Programierung wird ein Program in Unterprograme (Prozeduren, Funktionen) aufgeteilt. (Softwaresanierung) [10]

In einer prozeduralen Programmiersprache werden Teile der Lösung durch einzelne Prozeduren implementiert. Diese können im selben oder in andere Projekten wiederverwendet werden.(Taschenbuch Programmiersprachen)[11]--Avron 15:05, 24. Mär. 2011 (CET)

@Avron: Den Zusammenhang "OOP vs. pP" nehme ich noch unter 'Geschichte' auf. Auf Deine Fragestellungen habe ich doch immer Antworten / Argumente eingefügt - auf die DU aber nicht oder kaum eingegangen bist - vor allem nicht auf die Tatsache, dass man 'Prozeduren' (o.ä. genannte Konstrukte) in allen Programmiersprachen kennt und benutzt - und dass dieses 'Prozedurbilden' deshalb nicht das einzige Kriterium für den Begriff sein kann. M.E. geht es nicht darum, dass der alte Stand den Begriff 'immer noch besser erklärt', sondern dass er etwas anderes definiert als das was den tiefer differenzierenden Definitionen entspricht. Insofern bestehe ich nicht darauf, diese Definition sei falsch (obwohl sie v.a. in den OO-Gegenüberstellungen praktisch nicht verwendet wird), sondern zugestehen, es gebe eine zweite Definition. Das ist im Entwurf auch so dargestellt. Ich denke, die neuen Quellen sind etwas 'verbindlicher'; vor allem die Arbeit von Dr. P. Böhme setzt sich sehr ausführlich und systematisch mit der pP (auch im Gegensatz zu anderen Paradigmen) auseinander. Letztlich: Die pP würde niemals so intensiv als UNTERSCHIEDLICH zur OOP beschrieben werden, wenn es nur um das Programmieren in Prozeduren ginge.
Mehr Argumente kann ich leider nicht mehr liefern; wir wiederholen uns auch schon oft genug. Vielleicht könntest du noch helfen, die Verweise so zu gestalten, dass sie von WP nicht als 'gefährlich' abgewiesen werden. Vielen Dank. Ich grüße dich: --VÖRBY 08:58, 25. Mär. 2011 (CET)

Ich verstehe die ganze Diskussion nicht wirklich. Letzendlich gibt es zwei Sachverhalte die man erklären soll

• Der Ursprung der Bezeichnung ist ein neues Paradigma in dern 1950ern: Bei der prozeduralen Programierung wird ein Prog:ram in Unterprograme (Prozeduren, Funktionen) aufgeteilt. Vorher kam es noch ein Paradigme, die strukturierte Programmierung, welches Schleifen mitgebracht hatte. Dieses mag jetzt trivial anmuten da, wie du auch schreibst, haben jetzt alle Programmiersprachen Schleifen, Unterprogramme u.ä. Wie gesagt, in den 50ern war das aber eine Revolution.
• Der Begriff PP hat sich im Laufe der Zeit als ein Synonym für, sagen wir mal, "klassische Programmierung" eingebürgert. Deswegen wird auch so viel als PP im Gegensatz zu OOP geschrieben.

Ich dachte wir haben dieses so geklärt und das sollte auch so im Artikel beschieben werden. Noch mal: Du kannst natürlich den Aspekt PP als "Gegensatz" zu OOP beschreiben, aber verwässere nicht die eigentliche Bedeutung des Begriffs. Vielleicht wäre ein Artikel a la Klassische Programmierung oder nicht objektorientierte Programmierung (es gibt eben keinen passenden Begriff) eigentlich das was du willst. --Avron 09:30, 25. Mär. 2011 (CET)

Vorschlag für die Einleitung:

Ursprünglich ist die Prozedurale Programmierung ist der Ansatz Computerprogramme aus kleineren Unterprogrammen (Prozeduren, Funktionen) aufzubauen. Dieses Paradigma wurde in alle gängigen Programmiersprachen übernommen und prozedurale Programmierung wird seit dem als Sammelbegriff für die vorherrschende Programmierweise vor der ereignis- und objektorientierter Programmierung bezeichnet.

--Avron 10:43, 25. Mär. 2011 (CET)

Danke nochmal. Aber was wäre dann mit den 'PP-Merkmalen', die in den zahlreichen OOP-Gegenüberstellungen und in 'meinen' Quellen behandelt und genannt werden? Die haben doch nichts mit 'kleineren Unterprogrammen ...' zu tun! Und: All die Schleifen etc. hat 'man' schon in Assembler programmiert (BC, BAL, BALR, BXLE ...) - nur eben nicht von speziellen Sprachkonstrukten unterstützt. Ja, PP ist ein weitgehend nachträglich gebildeter Begriff für die 'klassiche Programmierung' - aber eben nicht nur deshalb, weil man Unterprogramme verwendet(e) sondern ... siehe Merkmale. Und einzig darum geht es mir!!

Ich grüße Dich: --VÖRBY 11:02, 25. Mär. 2011 (CET)

Ich verstehe dich einfach nicht: Aber was wäre dann mit den 'PP-Merkmalen', die in den zahlreichen OOP-Gegenüberstellungen und in 'meinen' Quellen behandelt und genannt werden? Die haben doch nichts mit 'kleineren Unterprogrammen ...' zu tun! Das eine ist der Ursprung des Begriffes und die akademeische Bezeichnung des Paradigmas, das andere wie der Begriff jahrzehnte später als Vorgänger von OOP verwendet wird. Ich weiss einfach nicht worauf du hinaus willst.--Avron 11:27, 25. Mär. 2011 (CET)

Beziehst du dich etwa darauf dass ich nicht nicht die von dir genannten Merkmale genannt habe? Die kannst du natürlich in einem Abschnitt a la Prozedurale Programmierung als klassische Programmierung aufnehmen. Es sollte dann noch einen Abschnitt Prozedurale Programmierung als Paradigma geben, welches die ursprüngliche Geschichte klärt.--Avron 11:41, 25. Mär. 2011 (CET)

Nicht dass DU diese Merkmale nicht genannt hast, ist mein Problem, sondern dass die 'Definition' (in Form des Einleitungssatzes) einfach nur von Unterprogrammen redet, obwohl konkret etwas ganz anderes gemeint ist. Das ist doch eine kapitale Verletzung des Begriffs 'Definition' - oder? Die PP (mit ihren Grundsätzen / Merkmalen) gab es schon immer, eine Inkonsistenz zwischen dem Begriff PP und der tatsächlichen Bedeutung sehe ICH da nicht. Falls du meinst, die 'Unterprogramm-Theorie' sei die "akademische Version", dann ist dies (gemessen an der [schon immer bestehenden] Realität) entweder falsch oder es ist einfach eine andere Definition - worauf man aber dann explizit hinweisen muss.

Ich sehe auch keinerlei Unterschied zwischen 'klassische Programmierung' (die hat(te) eben ihre 'Merkmale', und die sind deutlich mehr als UP-Bildung) und dem 'Paradigma PP'.

Dass 'PP' erst später i.Z. mit OOP häufiger zitiert und erläutert wurde, habe ich versucht, unter 'Geschichte' zu behandeln, vielleicht gehts noch etwas deutlicher.

--VÖRBY 12:32, 25. Mär. 2011 (CET)

sondern dass die 'Definition' (in Form des Einleitungssatzes) einfach nur von Unterprogrammen redet, obwohl konkret etwas ganz anderes gemeint ist. Das ist doch eine kapitale Verletzung des Begriffs 'Definition' - oder? Sorry Vörby, aber ich verstehe einfach nicht wovon du sprichst. Die Definition dass PP vom Grundsatz eine Teilung in Unterprogramme bedeutet ist 100% richtig. Auch deinem Neusten Versuch stimme ich nicht zu. Es wird nicht besser weil du nicht die Einleitung, ähnlich wie ich vorgeschlagen habe, nutzen willst. Die Einleitung, so wie du sie trotz der langen Diskussion immer noch vorschlägst, ist schlichtweg falsch. Solange nur deine Sichtweise in der Einleitung vorgeschlagen ist, werde ich diese ablehnen.--Avron 13:00, 25. Mär. 2011 (CET)

Vörby, du weisst das ich viel von dir halte, aber auch der letzte Entwurft ist sachlich falsch, voll undbelegter eigener Theorien (WP:Theoriefindung) und dazu mit ungültigen quellen "belegt". Leider werde ich nicht das Gefühl los dass du dir die ganze Diskussion egal war. So habe ich mich z. B. sehr deutlich ausgedrückt dass die von dir gebrachten Quellen im Sinne von WP:Quellen nicht zulässig sind. Doch das und vieles mehr ist einfach abgeperlt...--Avron 23:21, 1. Apr. 2011 (CEST)

Guten Morgen Avron, ich nehme deine Bedenken schon ernst, habe jedoch auch eine sichere eigene Meinung - und die wird durch die zweite 'Definition' und die von dir abgelehnten Quellen (warum eigentlich? Sind das formale Gründe?) widergegeben. Lass mich dir noch einmal antworten, ich habe aber jetzt schlecht Zeit, bitte also noch um etwas Geduld. Glaub mir, ich will auch richtig gute Artikel in Wikipedia. Schönes Wochenende! --VÖRBY 09:49, 2. Apr. 2011 (CEST)

Hallo zusammen. Nach einigen Tagen Beruhigung in der Diskussion, einer neuen liguistischen Erkenntnis (zwei Begriffe und der Einschaltung eines anderen Autors habe ich einen neuen Versuch unternommen und das 'Lemma' (= Terminus) mit zwei unterschiedlichen Texten ('Definitionen'?) unterlegt. Vielleicht kommen wir nun auch 'prozedural' (Schritt für Schritt) voran.--VÖRBY 18:07, 7. Apr. 2011 (CEST)

Nach deiner Meldung von gestern keimte in mir Hoffnung auf, aber das was ich sehe sind etwas andere Formulierungen mit identischer Aussagekraft.

• Die liguistische Erkenntnis, ist nicht erkennbar

... dass es zwei Begriffe gibt und nur einen Terminus - du hattest dem zugestimmt.

• ungülitige Quellen (Wikis) werden trotz mehrfachem Hinweis auf WP:Belege immer noch genannt. Statt dessen fügst du zusätzliche ungültige Quellen ein. z. B. [http:// www.uni-protokolle.de/Lexikon/Objektorientiert/prozedural.html] welches eine Kopie eines gelöschten Wikipedia-Artikels ist: [12]. Es fällt mir deswegen immer schwerer deinen Recherche glauben zu schenken.

Ich habe einfach in sehr vielen Artikeln die genannten Aussagen gefunden - und bin der Meinung, dass diese nicht einfach 'erfunden' wurden; schließlich sind auch einige Uni's dabei. Wo 'gültige' Quellen zu finden sind, weiß ich leider nicht; bei vielen Google-Ergebnissen in Buchform werden von meinem Browser nur wenige Seiten mit Inhalt angezeigt.

• Aussagekräftige Quellen, die sich mit Programmierparadigmen beschäftigen und deine "Definition" bestätigen, glänzen weiterhin durch Abwesenheit.

Deine Aussage ist destruktiv. Suche selbst nach 'prozedural' - und du wirst ebenso viele Artikel mit der einen wie mit der anderen Bedeutung finden. Leider habe ich (wir?) die richtigen Quellen noch nicht gefunden. Hast du eigentlich mal danach gesucht? Oder willst du andere Definitionen einfach nicht haben.

• Es wird immer noch ohne Quelle behauptet deine Definition wäre eine Programmierparadigma

Sonst gäbe es nicht so viele Texte, die pP als Gegenentwurf zu OOP (und mit anderen Aussagen als 'Prozedur') beschreiben. Ist halt einfach eine andere, zweite Bedeutung. Hältst du die Autoren der vielen von mir genannten Quellen für Schwachköpfe oder Phantasten?

• Immer noch wird behauptet ein "Voranschreiten" wäre nur ein Wesen deiner Definition

In der einfachen Definition kommt dieses Merkmal aber nicht vor, sondern nur der Begriff 'Prozedur'. Wir können das aber gerne auch umformulieren und für beide Versionen 'unterlegen'.

Im Westen nichts Neues. Ich habe aber auch so langsam keine Hoffnung auf Besserung. Bevor jedoch etwas Falsches in den Artikel aufgenommen wird, ist es besser er bleibt so wie er ist. --Avron 20:05, 7. Apr. 2011 (CEST)

Guten Abend Avron, siehe eingerückte Anmerkungen unter Deinen jeweiligen Punkten. Alles spricht dafür, dass hier zwei unterschiedliche Bedeutungen vorliegen, berechtigt oder nicht. Und ich möchte deshalb den Artikel 'verbessern'. --VÖRBY 20:53, 7. Apr. 2011 (CEST)

Ich habe bereits einen Vorschlag der Einleitung gemacht in welche Richtung es gehen könnte; du bist damit nicht einverstanden. Ich weise dich immer wieder daruaf hin aussagekräftige Belege im Sinne von Wikipedia zu zeigen; du bringst aber immer wieder irgend etwas aus dem weiten Internet und ignorierst immer wieder so die Regeln der Wikipedia. Was soll eine Diskussion noch bringen?--Avron 21:02, 7. Apr. 2011 (CEST)

Hallo, diese erste Definition ist doch DEIN TEXT. Oder habe ich mich da getäuscht? Bei den Quellen haben wir noch ein Dilemma, ok, das heißt aber doch nicht, dass das Ganze eine Erfindung ist. --VÖRBY 21:10, 7. Apr. 2011 (CEST)

Es geht aber darum dass DU den Artikel um eine andere Begriffsverwendung erweitern möchtest. Ich habe gezeigt wie man die beiden Begriffsverwendugen in Relation setzen könnte, aber du weigerst dich und bestehst ohne Quellen darauf dass DEINE Interpretation auch ein Programmierparadigma ist. Die beiden Begriffe befinden sich nicht auf der gleichen Ebene. Es ist so ähnlich wie Schloss (Architektur) und Schloss (Technik). Ich habe gehofft dass du das endlich erkannt hast als du nun doch vom selben Terminus für verschiendene Begriffen gesprochen hast. Es hat sich aber rein gar nichts geändert.--Avron 21:22, 7. Apr. 2011 (CEST)

Um das mit der Einschaltung eines anderen Autors zu erklären: Es gab auch noch eine kurze E-Mail-Korrespondenz zwischen mir und VÖRBY, die stattfand, um die Diskussionseite nicht noch weiter aufzublähen. Dort stelle ich mein Argument dar, warum auch ich meine, dass OOP nicht als absolut disjunkter Gegenentwurf zur pP aufgefasst werden muss. Strukturelle Programmierung war ja auch ein "Gegenentwurf" zur unstrukturierten Programmierung – es war kein Gegenentwurf zum Prinzip, imperativ zu programmieren. Also teilen auch diese beiden Ansätze eine Gemeinsamkeit (mehr sogar). Übrigens sollte ja klar sein, dass irgendwelche Internetdokumente auch ein 11-Jähriger geschrieben haben könnte, oder ein 30-Jähriger mit vergleichbarem Qualitätsanspruch an seinen Text: ein Aufsatz, ein Tagebucheintrag, eine Meinung ohne jegliche Faktengrundlage. Insofern könnte das Gegenentwurf-Argument noch so stimmig sein (was es ja nicht ist); spätestens wenn jemand eine Behauptung anzweifelt, muss eine Quelle geliefert werden, ansonsten ist die Information unzuverlässig. Die Quellen sind also nicht das einzig verbleibende Dilemma, sondern Schritt #1 auf dem Weg zur Verbesserung. Meine Suche ergab übrigens zwei Varianten: (1) pP = Aufteilung in Prozeduren, (2) pP=imperative P [13]. --Zahnradzacken 17:31, 8. Apr. 2011 (CEST)

Das Problem ist dass der Begriff in verschiedenen Kontexten gebraucht wird. Einmal als reines, "akademisches" Programmierparadigma und einmal als ein Oberbegriff für die "klassische" nicht-objektorientierte Programmierung. In keiner Quelle die mir bekannt ist, wird die prozedurale Programmierung so definiert wie Vörby das hier will. Die Wesensmerkmale die er beschreiben will (z. B. Prinzip der Datentypisierung) vereinbaren sich mit der reinen Definition von Aufteilung der Aufgabe in Unterprogramme. Aber egal was ich schreibe, es kommt einfach nicht an.--Avron 20:27, 8. Apr. 2011 (CEST)

Hallo zusammen,
Wenn ich mir den bisherigen Text nochmal anschaue (der allerdings auch nicht belegt war), wären wir evtl. gar nicht so weit auseinander - wenn man die Aussagen irgendwie kombinieren würde - etwa nach dem jetzt neuen Vorschlag von mir. Als Zusatzangaben passen dann die 'Merkmale'. Wäre das inhaltlich ok? Mit den Quellen müsste man noch nacharbeiten; bei dieser Fülle (Unis etc.) müsste es doch auch "richtige" geben.
--VÖRBY 17:55, 8. Apr. 2011 (CEST)

Dein aktueller Vorschlag ist schlimmer als der vorherige. Jetzt wird richtig alles in einen Topf geschmissen und kräftig umgerührt. Ich habe das Gefühl dass jede weitere Diskussion zwecklos ist. Kein bischen von der Mega-Diskussion kommt bei dir an.--Avron 20:12, 8. Apr. 2011 (CEST)

---

Mit DIESEM Eintrag melde ich mich aus der Diskussion ab. Mein Bemühen, den Artikel zu verbessern, scheiterte kläglich: Mit zunehmender Dauer wurde die Diskussion zwischen mir und Avron konfuser und verbohrter - womit ich keine "Schuld"-Aussage verbinden will. Dass wir gültige Belege bräuchten, sehe ich ein, ICH fand leider nur 'ungültige', was jedoch deren Inhalte m.E. nicht irrelevant macht.

Und: Meine letzte Änderung (s. neuer Text) war ein Versuch, die beiden Ansätze zusammenzubringen; ich habe dazu lediglich die im Artikel schon vorhandene Aussage Der Programmierer befiehlt dem Computer durch das Programm, was er in welcher Reihenfolge zu tun hat mit der 'Prozedur-Aussage' verbunden, etwas umformuliert und durch die (von mir gefundenen) Wesensmerkmale ergänzt. Damit entsteht keine neue Aussage, sondern nur eine präzisere (durch das "wobei") und detailliertere ("was bedeutet 'befiehlt dem Computer'?). Doch auch das blieb unverstanden. Dann soll's so bleiben wie es ist! Qualität ist das m.E. nicht!

Dass die Informatikpraxis nicht nur die 'Prozedur-Theorie' kennt und lehrt, zeigen die vielen unterschiedlichen Beschreibungen.

Eigentlich hatte ich auch auf Beteiligung anderer "schlauer Leute" gehofft, die mit ihrem Wissen zu diesem Thema zu einer guten Lösung hätten beitragen können.
--VÖRBY 13:36, 9. Apr. 2011 (CEST)

Vörby, ich bedaure wirklich dass die Diksussion nicht zu einer Verbesserung des Artikels geführt hat. Wenn man den Artikel ändern will soll das aber auch eine wirkliche Verbesserung werden und nicht eine unklare, unbelegte Verschlimmbesserung. In der Diskussion und in Quellen wurde eine weitere Bedeutung des Begriffes deutlich, aber leider haben wir es nicht geschafft uns auf einen gemeinsamen Nenner zu einigen erstens wie die andere Bedeutung überhaupt zu deffinieren ist und zweitens wie die beiden Begriffe im Kontext miteinander stehen. Irgendwann haben sich die Argumente nur noch wiederholt aber es gab keinen Fortschritt. Ich kann es nicht sagen woran es liegt, andere Diskussionen zwischen uns waren erfolgreich. Ich kann nur anbieten dass ich mir irgendwann Gedanken über das Thema mache und selber einen Vorschlag vorlege.--Avron 16:49, 9. Apr. 2011 (CEST)

Hallo Avron, mir tut es ebenfalls sehr leid - und ich kann die Missverständnisse nur damit erklären, dass wir doch typische Methodiker und keine Terroristen sind; denn mit denen ließe sich verhandeln. ;-) Und noch ein Trost: Die Aussage "Nur meine Religion ist die einzig wahre" hat auch schon beim Papst nicht wirklich zu Verbesserungen (der Beziehungen) geführt.

Beim Überarbeiten des Artikels wirst du feststellen, dass unsere beiden Aussagen schon im alten Text enthalten sind, nur ist der Aspekt "Programmierer befiehlt ... Reihenfolge ..." noch hinreichend unklar: Der Leser könnte fragen, ob das nicht immer so ist oder was das konkret bedeutet. Und sowas könnte man erläutern.

Damit will ich es aber nun belassen und grüße dich: --VÖRBY 09:20, 10. Apr. 2011 (CEST)

Finaler Nachtrag: Ich habe mich nochmal mit diesem 'Spezialthema' befasst. Auch nach Konsultation eines Kollegen, der hierüber vor Jahren mal eine Dissertation geschrieben hat, erscheint es mir so, dass dieser Terminus für zwei verschiedene Sachverhalte (Begriffe) verwendet wird. So sah das am 8APR2011 wohl auch Benutzer:Zahnradzacken. Daneben fiel mir auf, dass Aussagen aus der jetzigen Form des Artikels manchmal auf die eine, manchmal auf die andere Definition ausgerichtet sind. Deshalb habe ich, um den aus meiner Sicht letzten Stand hier zu hinterlegen, den vorgeschlagenen Einleitungstext auf die zwei Versionen abgeändert - unabhängig davon, was dann jemals in den Artikel "wandert". Trotzdem soll die Diskussion hier vorläufig als beendet betrachtet werden - bis evtl. jemand neuere Erkenntnisse und Eingebungen hätte. --VÖRBY 13:25, 17. Jun. 2011 (CEST)

Sammlung 'Fakten und Argumente'

Zu der diskutierten Fragestellung (eine oder zwei Definitionen) wurden die nachfolgenden Punkte gebildet, damit die Diskussion darüber nicht in den einzelnen Prosatexten verschwindet, sondern jeweils an einer Stelle zusammengefasst bleibt. --VÖRBY 13:36, 9. Apr. 2011 (CEST)

Bitte jeweils direkt unter dem einzelnen Punkt diskutieren, sonst verliert sich das Wesentliche nochmal in zahllosen Frage-Antwort-Sequenzen. Jeweilige Ergänzung bitte eingerückt, kurz und mit Namenskürzel (oder Signatur) einstellen.

• Die bisherige und die von mir jetzt eingebrachte Bedeutung sind zwei unterschiedliche Aussagen / Definitionen.

Av: Das eine ist eine belegte Definition für ein Programmierparadigma. Das andere ist eine unscharfe Verwendung des Begriffs im Sinne von "klassische Programmierung".

VÖ: Die Aussagen sind zunächst mal unterschiedlich / disjunkt. Ja 'klassisch' und 'prozedural' sind (in vielen Artikeln feststellbar) Synonyme - früher gab es nichts anderes. Andere Quellen beschreiben das Paradigma pP halt anders. Deshalb diskutieren wir ja hier. So lange sollten wir schon beide zugestehen, dass es um 'das Paradigma pP' geht.

Av: Du hast keine wirklichen Quellen genannt. Deine Begriffsverwendung beschreibt kein Programmierparadigma.

VÖ: Quellen liefere ich nach. Du bist es, der nicht einsehen kann, dass dieser 'weit verbreitete, früher einzige' Programmierstil, der aber viel mehr beinhaltet als dein 'Prozedurbilden', ein 'Paradigma' ist.

Vö: Nach weiterem Nachdenken halte ich die beiden 'Definitionen' für so unterschiedlich, dass wir möglicherweise nur den selben Terminus für zwei unterschiedliche Begriffe (beachte den Unterschied!) verwenden - was linguistisch gesehen eine Verletzung der 'Terminologischen Präzision' wäre. Insofern können wir gar nicht 'zusammenkommen'. Eine Enzyklopädie kann in solchen Fällen entweder mehrere Beschreibungen (1.xxx, 2. yyy etc.) liefern oder (in der Wikipedia häufig angewendet) einen Zusatz zum Terminus führen.

Genau das vermute ich auch: Es gibt den selben Terminus für zwei unterschiedliche Begriffe Erschwerend kommt hinzu dass auch in der Literatur oft mit dem Terminus flapsig umgegangen wird.--Avron 20:27, 5. Apr. 2011 (CEST)

Das würde darauf hinauslaufen, zwei Sachverhalte getrennt zu beschreiben (zu definieren). Klar sollten die Quellen einigermaßen valide sein. Ich arbeite daran.--VÖRBY 20:58, 5. Apr. 2011 (CEST)

• Ebenfalls einig sind wir darin, dass die Definition(en) (hier in der Einleitung) möglichst präzise und vollständig sein soll(en).

Av: Eine präzise Definition ist bisher nur für das Programmierparadigma belegt. Die Ausssage Nach enger definierten Kriterien ist die prozedurale Programmierung ein Programmierparadigma.. ist falsch bzw. nicht belegt.

VÖ: Die zweite Definition wäre ja gerade im Entstehen; die Kriterien kann man evtl. noch präzisieren. Präzise heißt, wenn das Kriterium zutrifft, dann gilt ein Ausdruck als 'der Definition entsprechend'. Dass die pP ein Paradigma ist, ist wohl unstrittig, du akzeptierst nur die 'engeren Kriterien' nicht.

Av: Nochmal: Deine Begriffsverwendung beschreibt kein Programmierparadigma.

VÖ: ... lasse ich nicht gelten, s.u.

• Imperativ (befehlsorientiert) ist eine Übermenge, kein Synonym für 'prozedural' und schließt auch OOP und anderes ein.

Av: Naja. Das ist ein Punkt den ich ganz am anfang der Diskusion nicht verstanden habe. Nach umfangreicher Recherche hoffe ich dass ich es nun verstanden habe, zumindest ist es für mich jetzt logisch. Imperativ bedeutet erst mal nur befehlsorientiert. Eine Übermenge gibt es bei Paradigmen nicht. Es könnte auch imperative objektorienterte Programmiersprachen geben. Das ganze wird aber manchmal (oder sogar oft) fälschlicherweise beschrieben, z. B. [14]

VÖ: In deiner und auch anderen Aufzählungen wird PP 'unter' der Überschrift 'imperativ' geführt, daraus leite ich 'Untermenge' ab.

Av: Du hast geschrieben dass imperativ OOP einschliesst, das ist falsch.

VÖ: Auch die OOP verwendet 'Befehle' - was ist dann falsch? Ist aber für die Disk. hier irrelevant

• Prozeduren werden in allen Sprachen angewendet; dieses Kriterium (als einziges) kann also den Begriff PP nicht korrekt definieren.

Av:Vielleicht meinst du es anders, aber so wie du es schreibst macht die Aussage wenig Sinn. Prozedurale Programmierung als Programmierparadigma bedeutet die Aufteilung in Unterprogramme. Nicht mehr und nicht weniger.

Vö: Ich meine es so: Wenn man in allen Sprachen 'Prozeduren' (etc.) bilden kann und die Definition für pP das 'Prozedurbilden' ist, dann sind alle Sprachen 'prozedural'. Dein Nicht mehr und nicht weniger klingt für mich so, dass du andere Argumente nicht anerkennen willst; schade.

Av: Wenn man in Programmiersprachen Unterprogramme bilden kann dann sind diese prozedural: Stimmt. Ansonsten: Deine Begriffsverwendung beschreibt kein Programmierparadigma.

VÖ. Dann gäbe es also kein Gegenteil von pP, insbesondere nicht bei der OOP. Hier "zieht" also die bisherige Definition nicht.

• PP ist ein Gegenentwurf zu OOP bzw. umgekehrt. Deshalb wird die PP auch so oft als Gegenstück zur OOP (mit mehr oder weniger vielen - differierenden - Merkmalen) beschrieben.

Av: Sagen wir es mal konkreter: Der Begriff "Prozedurale Programmierung" wird im Sinne von "klassische Programmierung" als Gegenentwurf zu OOP verwendet. Jedoch hat das mit dem Programmierparadigma wenig zu tun.

Vö: 'Klassische Programmierung' gibt es als 'P-Paradigma' nicht; das haben die Leute dann 'prozedurale P.' genannt. Die vielen Gegenüberstellungen beweisen, dass das in etwa 'gleich-gewichtige', aber eben andere Entwürfe sind.

Av: Klassische Programmierung' gibt es als 'P-Paradigma' nicht weil es kein Programmierparadigma ist. Das sind überhaupt nicht zwei "gleich-gewichte" Entwürfe, deien Aussage ist falsch.

VÖ: Wenn der OOP (als Paradigma) immer wieder dieser 'bisherige Programmierstil' gegenübergestellt wird, dann beweist das, dass damit ebenfalls nur ein Paradigma gemeint sein kann, das eben m.E. 'pP' genannt wurde.

Das einzige interessante Argument in der Diskussion; hier versuchst du Äpfel mir Birnen verglichen. Der "moderne Stil" enthält zumindes zwei Programmierpardigmen, die objektorientierte und die ereignisorientierte Programmierung. Es wird im Grunde genommen der5 "alte Stil" mit dem "modernen Stil" verglichen. Auf diesen Sprachlichen Ungenauigkeiten versuchst du nun deine Theorie aufzubauen.

• Wäre eine Programmierung ohne 'Prozeduren' (Module etc.), sondern nur mit 'Spaghetti-Code' und rückverweisenden GoTo's "prozedural"?

Av: halb richtig, des eigentliche Paradigma um den Spaghetti-Code in den Griff zu bekommen ist die "Strukturierte Programmierung". "Prozedurale Programmierung" ergänzt den Entwurf.

VÖ: Ja, auch die 'str. Pr.' ist auch ein Paradigma; auf einen Pgm-Code können also mehrere Paradigmen zutreffen. Eine solche Programmierung wäre also unzweifehlhaft weder strukturiert noch (nach der einfachen Definition) 'prozedural'. Gerade sowas (gab's früher häufig) ist aber 'prozedural'.

Av: Anfangs Zustimmung, dann kommt allerdings: Gerade sowas (gab's früher häufig) ist aber 'prozedural'. Unlogische Aussage.

VÖ: Das ist nur für dich unlogisch. Genau das war doch der 'alte Stil', der nur ein 'Fortschreiten' kannte. Ja, dann kam 'strukturiert' oder 'modular', ebenfalls Paradigmen - die auch nur durch ihre Merkmale (Struktur, Modul) definiert wurden. Beides würde aber auf mein Beispiel nicht zutreffen, wohl aber das 'procedere'. Mein einfaches Bsp. soll nur beweisen, dass es 'fortschreitend' auch ohne Prozeduren gibt. Auch hier "zieht" also die einfache Definition nicht.

Das ist ja zum Kopfschütteln: Etwas beweisen wollen aus der lateinischen Wortbedeutung heraus

• Auch in OOP und anderen Paradigmen gibt es Prozeduren.

Av: Seltsame Wortwahl, vielleicht ist es aber wesentlich. Programmierparadigmen stehen (in der Regel) jeweils für sich alleine d.h. in Paradigmen stecken keine weitere Paradigmen. Programmiersprachen hingegen sind auf vielen Programmierparadigmen aufgebaut. So stehen die Paradigmen objektorientierte und ereignisorientierte Programmierung erst mal für sich alleine. In Programmiersprachen, die ich kenne, sind diese aber immer zusammen implementiert.

VÖ: Genau, deshalb heißt das Paradigma auch 'p. ProgrammieRUNG' und nicht 'p. Progr-SPRACHE'. Insofern kennt auch die OOP Elemente von 'prozedural'. Aber: Gerade in der OOP sind doch wohl ALLE Klassen, Methoden etc. als 'Prozeduren ...' angelegt. Dann wären (nach der einfachen Definition) alle Teile 'prozedural'. Das scheint aber nicht so zu sein, sonst wäre OOP kein Gegenentwurf zu pP.

Av: Du verwechselst Programmierung und Programmiersprache: Insofern kennt auch die OOP Elemente von 'prozedural'

VÖ: Das sagte ich ja auch schon. Aber es ist ein Unterschied, ob es darin "Elemente gibt", oder ob die Programmierung vollständig prozedural ist. Denn dann wäre (nach der einfachen Definition) die OOP immer und vollständig prozedural - ohne jeglichen Gegensatz zu pP; paradox.

• Welche meiner Ausführungen sollen "unbelegten eigenen Theorien" sein? Sie stammen alle aus im Netz verfügbaren Quellen.

Av: Die einzige halbwegs akzeptable, allerdings sehr schwache, Quelle ist der C++ Kurs. Dort geht es um die Steuerung des Programmflusses. Der Begriff wird, wie oben beschrieben, für "imperative, nicht-ereignisorientierte" Programmierung benutzt. Nicht alles was im Internet zu finden ist, ist auch für die Wikipedia geeignet, siehe WP:Quellen. Am aussagekräftigsten sind Bücher.

VÖ: Ich habe nicht alle Quellen, die ich fand, aufgeführt, das waren viele:

VÖ: Es gibt noch mehrere Uni-Quellen, die man auch noch bei den einzelnen 'Merkmalen' ergänzen könnte, etwa 'Datendienen der Komm' (Uni Ulm) ...

VÖ: Eine Oldenbourg-Enzyklopädie ist eine 'schwache Quelle'? Ablauf-orientiert = prozedural.

VÖ: Dr. Böhme, IMB Jena, liefert mit am eindeutigsten, was gemeint ist: nur innerhalb des programmierten Spielraums ...

VÖ: Ich nenne das nicht 'schwachen Quellen'. Werde versuchen, noch einige Quellen zu ergänzen.

Av: siehe WP:Quellen.

• Worauf stützt sich deine Behauptung, die bisherige Definition sei 100% richtig?

Av: Auf viele von mir im laufe der Diskussion genannten aussagekräftigen Quellen.

VÖ: Wir haben schon festgestellt, dass es mehrere Beschreibungen gibt. Genau so könnten die anderen Quellen '100% richtig' sein. Da das aber 200% wären, muss es mehrere Definitionen geben.

siehe WP:Quellen.

• Was ist am neuen Entwurf "sachlich falsch"?

Av: Vor allem dass die Verwendung des Begriffs als "klassische Programmierung" als eine zweite Definition eines Programmierparadigmas dargestellt wird. Dann wird diese Aussage Das Programm schreitet sozusagen von Anweisung zu Anweisung voran, was dem lateinischen Wort „procedere“ – voranschreiten – entspricht. nun so beschrieben, dass sie anscheinend nicht mehr für die Definition der Programmierparadigmas gilt. Das ist aber falsch, siehe z. B. C++ für Ingenierue [15])

VÖ: Es gibt kein 'klassische Programmierung' genanntes Paradigma; das hat man 'proz. P.' genannt (vielleicht auch erst, nachdem es andere gab). Genau dieses Voranschreiten wird - nach der von mir präferierten Definition (des Paradigmas!) - als 'prozedural' beschrieben, nicht das (triviale) Prozedur bilden.

Av: Es gibt kein 'klassische Programmierung' genanntes Paradigma; Das behauptet auch keiner. Was ich behaupte und du nicht belegen kannst ist: Deine Begriffsverwendung beschreibt kein Programmierparadigma. Genau dieses Voranschreiten wird - nach der von mir präferierten Definition (des Paradigmas!) - als 'prozedural' beschrieben, nicht das (triviale) Prozedur bilden . Sorry, aber genau das ist pure Theoriefindung

VÖ: Dann sind die Aufzählungen der Paradigmen also unvollständig? Und sie enthalten eines der wesentlichen, auch heute noch geltenden (in Teilen) Paradigmen nicht?

• Was ist an den von mir genannten Quellen nicht passend?

Av: siehe oben

Vö: Ich werde sie alle noch ergänzen; was dann 'schwach' ist, muss jeder selbst entscheiden.

Av: siehe WP:Quellen.

VÖ: Lt. WP:Quellen: "Systematische Übersichtsarbeiten, die für das Fachgebiet des jeweiligen Lemmas relevant sind, zu bevorzugen." Da gehören viele meiner Verweise dazu. "Zuverlässig" sollten Unis etc. m.E. auch sein. Und: Du benutzt dies als Ausrede, um dich nicht mit den inhaltlichen Argumenten auseinandersetzen zu mäüssen.

Eingestellt: --VÖRBY 10:54, 3. Apr. 2011 (CEST)

Beantwortet.--Avron 21:29, 3. Apr. 2011 (CEST)

Ergänzt: --VÖRBY 09:44, 4. Apr. 2011 (CEST) Brauchen wir einen Schiedsrichter?

Av: Die Diskussion wird sinnlos. Du bist der Meinung dass "deine" Begriffsverwendung ein Programmierparadigma ist. Das hast du weder belegt, noch ist es logisch. Vielfach argumentierst du ungenau und nur aus der Praxis heraus. Ich sage "deine" Begriffsverwendung ist kein Programmierparadigma sondern eine ungenaue Sammelbezeichnung für "klassische Programmierung". Zudem weigerst du dich Grundlagen der Wikipedia anzuerkennen: WP:Quellen --Avron 10:14, 4. Apr. 2011 (CEST)

VÖ: Ergänzt: Deine wiederholten Aussagen "... beschreibt kein Paradigma" sind aus meiner Sicht nicht zulässig. Denn genau darüber diskutieren wir, da kannst du nicht behaupten, das würde kein Paradigma beschreiben. Sorry, das kommt mir vor, wie wenn man einem nur zweidimensional denkenden Wesen den Begriff 'Höhe' erklären möchte; dieses würde auch sagen, es sei "unlogisch". Die Quellen ergänze ich noch. Auch ich fürchte, die Diskussion macht keinen Sinn mehr. Schade. --VÖRBY 12:57, 4. Apr. 2011 (CEST)

Du legst eine selektive Wahrnehmung der Fakten an den Tag. Kaum findest du etwas im Internet mit dem Begriff Prozedurale Programmierung schon biegest du dir es so lange zu rechte, dass es zu deinem Konzept passt. Bringe aussagekräftige Quellen, (keine Mustervorlagen, Wikis, ...), die sich mit dem Thema Programmierparadigmen umfänglich beschäftigen und deine Sichtweise belegen. So lange sehe ich keine Grund hier weiter zu diskutieren.--Avron 13:13, 4. Apr. 2011 (CEST)

Ich bin leider erst jetzt wieder auf die Diskussion gekommen und finde es zu mühsam, die ganze Argumentation zu lesen. Da sowohl dieser Artikel als auch der Artikel Programmierparadigma kaum Quellen enthält, wäre es aber vermutlich sinnvoll, erstmal für eine ordentliche Quellenlage zu sorgen, und sich dann auf einen einheitlichen Umgang mit den Wörtern zu einigen. Ich befürchte aber, dass es sich auch mit Quellen einfach nicht einheitlich behandeln lässt. Dieser Link grenzt die PP nachvollziehbar von der OOP ab (ohne sich auf Gegensätze einzuschießen). Die einzige Quelle der en-WP zählt aber auch LISP zu den prozeduralen Programmiersprachen. Nicht besser kann es da beim Programmierparadigma aussehen, was Stroustrup als protzigeres Wort für "Programmierstil" hält (und das Dokument, in dem er das sagt, wird dummerweise derzeit als "Quelle" für die aus dem Zusammenhang gerissene Interpretation des Wortes als "fundamentales Programmierparadigma" genutzt). Wenn diese Wörter nur salopp verwendet werden, kann man einfach relativ vielseitig interpretieren.

Sieht man von der Quellenlage ab (und dem Fass von unten), finde ich den derzeitigen Artikelzustand aber nicht schlecht. --Zahnradzacken 21:46, 4. Apr. 2011 (CEST)

Programmierung oder Programmiersprachen?

Ich mache noch ein "neues Fass" auf: Unter Einordnung wird auf den Zusammenhang zwischen prozeduraler und imperativer Programmierung eingegangen. Dabei ist jedoch nicht von 'Programmierung', sondern von 'Programmiersprachen' die Rede. Hierzu merke ich an:
Wenn 'imperativ' das Formulieren einzelner Befehle ist (im Gegensatz zu deklarativ), so kann man m.E. nicht ganze Programmiersprachen in die eine oder die andere "Schublade" stecken, sondern viele Sprachen unterstützen beides: Wenn ich mir VBA anschaue, dann kann ich dort Befehle einzeln codieren. Gleichzeitig kann ich z.B. Formeln hinterlegen, die nach meinem Verständnis der Definition in Imperative Programmierung deklaratives Programmieren wären.
Sollte man insofern nicht besser ... Programmierung sagen als Programmiersprachen? Ähnliches gilt auch für die Frage nach 'prozedural' und 'objektorientiert': Nach vielen Literaturbeiträgen ist beides eigentlich komplementär, viele Programmiersprachen bieten aber ein "sowohl als auch". Also auch hier: Diese Paradigmen gelten für die ProgrammierUNG, nur bedingt aber für die ProgrammierSPRACHE (wobei es wohl so ist, dass OO-(geeignete) Sprachen wohl immer auch prozedural benutzt werden können, prozedurale aber nur manchmal oder eingeschränkt objektorientiert).
Diesen Aspekt (gemische Zuordnungen) könnte man also sowohl zu 'prozedurale ...' als auch zu 'imterative Programmierung' in den Artikeln aufzeigen, um beim Leser nicht den Eindruck zu erwecken, es gäbe in den Programmiersprachen nur Reinformen dieser Paradigmen. Oder liege ich da falsch?
--VÖRBY 19:14, 15. Mär. 2011 (CET)

Noch ein Fass, darauf trinken wir einen;-) Ich halte Programmierung erst mal für den richtigen Begriff, wenn nur das Prinzip erklärt wird. Auf eine konkrete Programmiersprache bezogen kann man dann auch von z.B. deklarativen Programmiersprache sprechen.

Ich weiss nich ob eine Formel in VBA eine deklarative Programmierung ist. Wie so Viele die mit Programmierung vertraut sind, kenne ich die deklarative Programmierung nur von der Theorie, weil diese in der Praxis kaum eine Stellenwert hat.--Avron 20:39, 16. Mär. 2011 (CET)

Guten Morgen, öffnen sich uns so nach und nach die "Geheimnisse der Programmiererkunst"? Nach allem, was wir jetzt diskutiert haben, sehe ich es so, dass die 'Paradigmen' einfach 'Stile' sind, in denen man 'programmieren' kann. Ob diese dann in einem bestimmten Programm (Modul, Prozedur ...) reinrassig angewendet werden oder gemischt, ist damit nicht gesagt. Genau so verhält es sich mit den Programmiersprachen: Sie können u.U. mehrere dieser Paradigmen unterstützen; und wenn z.B. von OO-Sprache die Rede ist, dann erfüllt diese Sprache bestimmte Voraussetzungen für die OO, kann aber evtl. auch (partiell oder alternativ) z.B. prozedural eingesetzt werden. Schönen Tag! --VÖRBY 09:24, 17. Mär. 2011 (CET)

Kommentare Ende November 2011

Nach den letzten kleinen Änderungen und dem Wiederaufleben der Diskussion hier mein Kommentar:

1. Ich finde, die Einordnung und Erklärung der anderen Paradigmen ist besser im Hauptartikel Programmierparadigma aufgehoben. Sonst findet man hier am Ende mehr über den Zusammenhang als dort (und damit rechnet keiner, der einen Überblick sucht). _{>>>Um eine Aussage (oder auch 2) zu unterstreichen, halte ich die beiden kurzen Aussagen für ggf. nützlich.} --VÖRBY 17:22, 23. Nov. 2011 (CET)
2. Die Erläuterungen zu Bedeutung 2 würde ich bestenfalls im Artikel Imperative Programmierung aufschreiben und hier nur in der Einleitung erwähnen, dass eine zweite Begriffsauffassung existiert, nach der die beiden Wörter das gleiche bedeuten. Denn wenn sie das gleiche bedeuten, muss man es nicht sowohl hier als auch dort erklären. _{>>>Sie werden eben nur in einigen Quellen als Synonym bezeichnet. I, Text zu P-Paradigma gilt pP als Untermenge von iP.}
3. Ich finde aber, dass einige Kommentare stark überarbeitet werden müssten, bevor sie irgendwo eingearbeitet würden.
   • Du zitierst den "linearen Fluss der Daten", verschweigst aber den größeren Zusammenhang. Einerseits steht da auch "Damit sind Anweisungen und Funktionen die beherrschenden Elemente" – was das Begriffsverständnis 1) stärkt. Andererseits steht da nach dem Satz über den linearen Fluss: "Dieser kann nur durch Kontrollstrukturen wie Schleifen und if/else-Verzweigungen unterbrochen [werden]." Dass du also den Satz über den lineare Fluss herauspickst, stellt ihn ins falsche Licht. _{>>>ich sah diese Aussage als den hier passenden Kern. Und unterstreicht den 'linearen' Charakter der Befehle - im Ggs. zur reinen Aussage 'Code in Prozeduren bündeln'. Und das ist ja gerade der Unterschied.}
   • Das nachfolgende Zitat ist ziemlicher mehrdeutiger Unsinn. "Das Programm beschreibt in sequentieller Form" ... jedes Programm, das als Textdatei vorliegt, ist in sequentieller Form. Wenn zudem, wie in der "Quelle", diese sequentielle Form der Kontrast zu deklarativer und ereignisorientierter Programmierung sein soll, dann ist mit "sequentiell" so ziemlich alles gemeint, was imperativ geht. Den Satz kann man also kaum als Definition heranziehen (die Quelle auch nicht). _{>>>Sorry, die Quelle schreibt das so. Es soll wohl gesagt werden, dass nur in der pP die Befehle auch ausschließlich durch die Reihenfolge im Code angesteuert werden, bei OO durch Objektaufrufe/Ereignisse und bei dP werden die Befehle gar nicht 'programmiert'.}
   • Schließlich zitierst du "Daten und Anweisungen sind voneinander getrennt" falsch. Dieser Satz ist für sich betrachtet unverständlich und im Original heißt er "Datenstrukturen und Anweisungen sind getrennt voneinander". Dieser Satz ist wiederum mehrdeutig und kann ohne Zusammenhang (den das Original auch nicht liefert) nicht als Definition herangezogen werden. Zudem nennt diese "Quelle" die Wikipedia als "Quelle" und ist damit zu verwerfen. _{>>>Zahlreiche Quellen betonen dieses Merkmal. Es ist wohl gemeint, dass zwischen Code und Daten kein direkter Zusammenhang besteht - wie z.B. bei der OO.}
   • Später nennst du noch mehrere Merkmal, teils ohne Quelle, teils mit fragwürdiger Quelle: Beispielsweise ein anderes Wiki [16], das uns weismachen will, dass Datentypisierung das wichtigste Merkmal der prozeduralen Programmiersprachen sei. _{>>>Diese Merkmale stammen noch von früher und sind jetzt z.T. redundant zum Text oben. Ich könnte darauf verzichten; nur bei sehr genauer Beschreibung von pP(2) wäre das evtl. nützlich.}

Bei so viel zitierter Ungenauigkeit und ungenauen Zitaten bitte ich abschließend: Die Belege, die auf pP=iP hindeuten, im Artikel zur iP einarbeiten. Alles Andere wäre in diesem Zustand eine Verschlechterung des Artikels. --Zahnradzacken 16:38, 23. Nov. 2011 (CET)

Danke für Deine Mühe. Kurze und letzte Stellungnahmen habe ich _>>>small eingearbeitet. Zusammenfassend will ICH den Artikel aber (nochmal) beim status quo belassen. Wie gut oder wie schlecht die Texte(2) auch immer sein mögen, die vielen Quellen zeigen, dass pP (auch) deutlich anders interpretiert wird. Bei meiner Meinung zur Definition 1 bleibe ich auch: Dies ist eine Trivialdefinition und zeigt keine zur Identifikation/Definition von pP geeigneten Kriterien, weil praktisch immer und mit allen Programmiersprachen 'Prozeduren' gebildet und aufgerufen werden (können); also wäre alles pP.

Grüße von --VÖRBY 17:22, 23. Nov. 2011 (CET)

Deine Meinung zu 1) vermischt Programmierstil mit Programmiersprache. Geht es um den Stil, lautet das Paradigma: verwende Prozeduren!. Ginge es darum, was in der Sprache geht, könnte man sich kaum festlegen, denn mit LISP kann man auch Schleifen und Objekte nachbauen. --Zahnradzacken 21:56, 23. Nov. 2011 (CET)

Wir haben jetzt schon zig mal um die Ecke argumentiert. Dabei ging es immer mehr um die Frage, ob pP einzig und allein durch das Kriterium "Programmieren in Prozeduren" definiert werden kann. Hierzu hatte ich meine Bedenken - was ja auch die zahlreichen "anderen" Quellen so sehen. Wenn ich mir aber die aktuelle Einleitung im Artikel ansehe, so wird ein Teil der Kriterien für 2) dort bereits genannt - inkl. der Aussage, dass das kleine p von pP von 'procedere' kommt; allerdings das Ganze auch ohne Beleg(e). Zusammenfassend würde ich jetzt sagen: Die Definition ist als gemeinsame Definition gar nicht so schlecht, enhält aber 2 Schwächen:

• Der erste und der letzte Satz der Einleitung (quasi die Klammer) lassen vermuten, dass das Merkmal 'Prozeduren' das einzige Kriterium für diesen Begriff sind.
• Die nach "Sicht 2" relevanten Kriterien sind lediglich im Mittelteil angedeutet, aber unvollständig und ungenau (Anweisung für Anweisung gilt ja quasi immer, nur wird es bei pP(2) einzig und allein vom Programmierer festgtelegt).

Insofern könnte eine einfache Lösung sein, den derzeitigen Text geringfügig anzupassen - was aber im Verlauf der bisherigen riesigen Diskussion nicht gelungen war. Wikipedia-Syndrom? --VÖRBY 10:13, 24. Nov. 2011 (CET)

Es stimmt, dass auch die aktuelle Version keine Belege anführt. Und auch ich finde die Formulierung ungenau. Die Diskussion zur Verbesserung finde ich deshalb sinnvoll. Was wir aber am dringendsten brauchen, sind nicht Zitate von Meinungen oder plausible Korrekturen am Text, sondern belastbare Quellen. Deshalb teile ich auch nicht deine Meinung, dass zahlreiche Quellen deine Bedenken bestätigen. Wir brauchen Quellen, bei denen wir sicher sein können, dass sie nicht aus Wikipedia abgeschrieben sind, und die eine Lehrmeinung und keine Privatmeinung darstellen. Wenn jemand in einem Blog, einem Wiki oder einer privaten Website erklären würde, das Hauptmerkmal von pP sei, dass der Quellcode weniger Klammern als Semikolons und Gleichheitszeichen enthält, dann muss man das ebenso anzweifeln, wie eine Behauptung, die sehr plausibel klingt. Wenn es um etwas Grundlegendes wie die Bedeutung eines Jargon-Wortes geht, sollten wir nicht unüberprüfte Deutungen übernehmen. Sonst entstehen Mythen, wie etwa bei den Vermutungen über die Herkunft des Worts Foo. (Siehe auch Volksetymologie und wie aus Quentchen das Quäntchen wurde).

Mein letzter Versuch endete damit, dass ich Quellen fand, die prozedural mit imperativ gleichsetzten (ohne dass ich eine Begründung dafür fand), und solche, die das Aufteilen in Prozeduren in den Vordergrund stellten. Möchtest du konkretere Informationen verwenden, bitte ich dich um WP:Belege. --Zahnradzacken 16:28, 24. Nov. 2011 (CET)

In den ca. 50.000 Google-Suchergebnisse zu pP finden sich, sofern relevant, beide Standpunkte - das hast du wohl auch festgestellt. Wobei auch ich den Verdacht habe, dass in Web-Lexika häufig voneinander abgeschrieben oder sogar verlinkt wurde. Die von mir ausgewählten und zitierten Quellen sind u.a. 4 Universitäten; siehe die angeführten Referenzen. Wenn das nicht genügt, kann ICH den Artikel auch nicht verbessern.

Übrigens findet sich unter Programmierparadigma zu pP nur das 'Prozedur'-Kriterium - nach der ja de facto jede OO- und jede Ereignisprozedur prozedural sein müsste (weil es eben Prozeduren sind) - und andererseits ein Programm mit 'flachem' Code ohne Prozeduren, der nur einfach 'durchläuft' (z.B. mit Schleifen oder meinetwegen auch mit GoTo), nicht prozedural wäre. Alleine dieser Kriterien-'Test' sollte klar machen, dass da was faul ist. Vielleicht findest Du bessere Quellen oder Formulierungen, viel Glück. --VÖRBY 18:39, 24. Nov. 2011 (CET)

Falls du mit den Uni-Quellen diese, diese und diese Seiten meinst, dann ja: das genügt nicht. Die kurze Antwort ist, dass es sich nicht um wissenschaftliche Publikationen handelt. Es handelt sich vermutlich nicht einmal um recherchierte Erkenntnisse, sondern meinem Eindruck nach um Brainstorming.

Die lange Antwort. Erstens: Der erste Link erwähnt genau zweimal "prozedural", nämlich einmal dafür, dass Python das "prozedurale/imperative" Paradigma unterstützt, und zweitens in einem Code-Beispiel dazu. Zweitens: Was hat, im zweiten Link, eine private Seite eines Mitarbeiters der "Gruppe IT Service" am Jenaer Leibniz-Institut für Altersforschung für eine Aussagekraft? Drittens: Die Quelle des dritten Links könnte man oberflächlich ernst nehmen, da es sich um das Skript zu "Programmieren 1" eines Professors für Software Engineering und Wirtschaftsinformatik handelt. Aber ein Skript kann auch nicht ohne Weiteres zu einem Buch oder Aufsatz werden. Vor allem dieses Skript, von dem nur ein paar der 14 Kapitel noch online sind, und wo man Sätze wie "In jedem Programm ist es notwendig Entscheidungen zu treffen", Rechtschreibfehler wie "Modulare Programimerung" und haufenweise Fragen an die notierenden Studenten findet. Es ist doch offensichtlich, dass hier auf intuitiver Ebene "C" beigebracht werden soll und ein bisschen drumherum geschwafelt wird: "Prinzipiell ergibt sich einr Wechselwirkung zwischen der zu realisierenden Aufgabe, der Komplexität und der verwendeten Programmiersprache" oder "Die komplexität der Aufgaben die mit modernen Rechnersystemen gelöst werden sollen ist permanent gestiegen." [17] Schön ist auch die Grafik, die vorgaukelt, zwischen 1950 und 1970 hätte man mit Rechnern nur einfache Rechenoperationen und Stammdatenverwaltung durchführen wollen.

Zu deinem zweiten Punkt: Ich glaube nicht, dass der Begriff "Programmierparadigma" je wissenschaftlich betrachtet wurde, und so kursieren natürlich viele Interpretationen davon. Nach meinem Verständnis macht eine Prozedur ein Programm noch nicht prozedural und das wird auch nirgends behauptet. Aber Prozeduren als erste Dimension der Strukturierung eines Programms zu wählen, ist paradigmatisch. Ein flaches Programm ohne Prozeduren erfüllt dagegen tatsächlich nicht das Paradigma, prozedural zu strukturieren. [ aw: Wieso sollten Prozeduren gebildet werden wenn das ganze Pgm einfach ein (1) Algorithmus wäre, der keine Subroutinen braucht, der aber eben "Schritt für Schritt" arbeitet, inkl. Schleifen? (VÖRBY)] Das klingt für mich nicht faul, sondern richtig. Da ich aber selbst sagte, dass Plausibilität kein Argument ist, hier Belege: [18], [19] und [20].

Falls du mit diesen Belegen einverstanden bist (zwei der drei setzen ja ebenfalls prozedural mit imperativ nahezu gleich), können wir sie als Grundlage für Veränderungen heranziehen. --Zahnradzacken 23:45, 24. Nov. 2011 (CET)

Zwischennachricht in Kürze: Danke, ich versuche einen neuen Text auch aus den 'neuen' Quellen abzuleiten und stelle den dann oben bei "(Entwurf)" ein. Er wird "pP1 und pP2" zusammenführen. Große Hochachtung vor Deinen sorgfältigen Recherchen und Deiner objektiven Sicht auf die Dinge! Gruß --VÖRBY 09:39, 25. Nov. 2011 (CET)

Guten Tag, "Zahnradzacken", und vielen Dank für deine ausführlichen und fundierten Ausführungen. Ich verstehe Deine Bedenken bezüglich 'beliebiger' Quellen, fand aber selbst keine anderen. Da ich dieses (und ähnliche) Themen nicht aus der Wissenschaft, sondern aus der Praxis kenne, erscheinen/erschienen mir die zahlreichen 'Schnipsel' Beweis genug dafür, dass die Definitionen andere sein müssen als nur dieses platte 'Prozedurenbilden'.

Ich glaube, mit den zitierten Beispielen gehst Du zu kleinlich um (1950 - 1970 - wenn das als Beispiel bezeichnet wird, mag sowas doch ok sein). Trotzdem:

Die von Dir eingestellten Quellen mögen diesbezüglich valider sein. Und ich denke, dass man daraus eine "richtige" Bechreibung erstellen kann - die die bisherigen Aussagen zu pP1 und pP2 vereinigt. Das Problem mit den Zitaten entfällt dabei - weil die Texte Englisch sind. Ja diese pP(1)-Definition findet man auch woanders: Wer da von wem kopiert hat, lässt sich natürlich nicht mehr nachvollziehen. Außerdem wird in anderen Zusammenhängen diese pP1-Definition auch 'modular' genannt; diese Diskussion möchte ich aber jetzt nicht auch noch anstoßen.

Ja, es scheint so, dass der Komplex "Programmierparadigmen" mit der IT-Entwicklung gewachsen ist und entsprechend hetorogen in Erscheinung tritt. Es ist ja auch ein eher theoretischer Begriff, der für jemanden, der in einer bestimmten Umgebung programmieren muss, kaum von Bedeutung ist. Deshalb - und auch, weil es da zahlreiche Überschneidungen gibt - bleiben wohl nachbetrachtende Versuche der Klassifizierung immer nur Ansätze, die von der Entwicklung schnell eingeholt werden.

Als neuen Versuch meinerseits habe ich den Entwurf oben neu gefasst. Wenn Du das besser/korrekter formulieren kannst, wäre ich Dir dankbar, das direkt zu tun - anstelle weiterer Diskussionen. Danke, vielleicht schaffen wir diese Sisyphos-Arbeit doch noch - und ich hoffe, auch Du, @Avron, kannst da zustimmen. --VÖRBY 13:18, 25. Nov. 2011 (CET)

Trotz verbesserterter Ansätze ist die Einleitung zum Teil falsch bzw. am Thema vorbei. Es gibt noch keine Struktur anhand die die verschiedenen Bedeutungen erklärt werden. Es fehlt also noch einiges. Ich bin dabei etwas in meinem BNR zu basteln: Benutzer:Avron/Prozedurale Programmierung. Sobald es einen vorzeigbaren Stand hat, werde ich es hier vorstellen. Leider habe ich momentant wenig Zeit.--Avron 21:05, 26. Nov. 2011 (CET)

Die Merkmale sind jetzt exakt die (wichtigsten!?) Kriterien aus der zitierten Quelle (von Zahnradzacken gefunden). Daraus ergibt sich m.E. das, was in der Einleitung steht. Andere Quellen mögen andere Sichten haben, aber darum haben wir lange genug gerauft. --VÖRBY 09:48, 27. Nov. 2011 (CET)

Was man aus den Quellen extrahiert, ist natürlich immer noch subjektiv und der Aufbereitung des Autors unterworfen. Zudem müssen wir andere akzeptable Quellen ja nicht ausschließen. Wieso schaust du dir nicht an, was Avron bisher im BNR entworfen hat? Falls dir die Quellen unglaubwürdig vorkommen, so wie ich deine nicht gut fand, kannst du das genauso diskutieren. Mir gefällt der Entwurf bisher. Mangels Zeit würde ich aber momentan weder deinen Entwurf überarbeiten, noch wesentlich in Avrons Entwurf reinpfuschen. --Zahnradzacken 15:28, 27. Nov. 2011 (CET)

Vörby, die einzige Qulle die du jetzt in deinem Vorschlag vorbringst, setzt die prozedurale Programmierung der Imperative Programmierung gleich. Damit lässt sich dein Vorschlag nicht argumentieren sondern eine Weiterleitung nach Imperative Programmierung.--Avron 20:34, 27. Nov. 2011 (CET)

Imperativ vs. prozedural

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 17:41, 14. Nov. 2012 (CET)

Im Artikel Imperative_Programmierung#Abgrenzung steht folgendes Der Begriff der prozeduralen Programmierung wird oft synonym gebraucht, setzt aber die Verwendung von Prozeduren voraus, was nicht für jede imperative Programmiersprache gelten muss, während hier in diesem Artikel folgendes steht Prozedurale Programmiersprachen bilden eine Untermenge der imperativen Programmiersprachen.. Frage, wie kann die prozedurale Programmiersprache eine Untermenge der imperativen Programmiersprachen sein, wenn die imperativen Programmiersprachen die prozedurale Programmiersprache gar nicht vorraussetzen? Hier liegt also, auch wenn einige Programmiersprachen das unter einen Hut bringen, ein Widerspruch vor. Man sollte dies klarer ausformulieren. --84.58.249.153 07:44, 22. Nov. 2011 (CET)

Hallo IP-User, zunächst halte ICH diese beiden Formulierungen nicht für inkonsistent, denn nach beiden Aussagen gilt die IP als Übermenge - was Du vielleicht aufgrund der Nennungsreihenfolge (erst PP dann IP) verwechselt hast. Nach a) ist dann PP die Teilmenge, bei der "in Prozeduren programmiert" wird. Nach b) wird die Teilmengeneigenschaft der PP einfach bestätigt.

Recht hast Du trotzdem, weil in PP auch zusätzlich steht Praktisch alle imperativen Programmiersprachen enthalten den prozeduralen Ansatz. Das kommt aber m.E. daher, weil der Terminus PP uneinheitlich definiert und beschrieben ist: Die derzeitige PP-Definition leitet ihn einfach aus "dem Programmieren in Prozeduren" ab, während PP an anderen Stellen (wahrscheinlich auch im hier genannten Zusammenhang) von "procedere - fortschreiten" (den Code also Schritt für Schritt definieren) abgeleitet wird. Hierzu führte ich ein sehr lange Diskussion; siehe oben. Da wir uns aber nicht einig werden konnten, blieb der Text in der alten Fassung so stehen. Eine neue Fassung hätte m.E. so ausgesehen.

Außerdem sollte beachtet werden, dass die Paradigmen nicht in erster Linie auf die Programmiersprachen zu beziehen sind, sondern auf den Programmierstil, der jeweils angewendet wird; dies ist hier beschrieben, aber ebenfalls nicht in den Artikel eingeflossen.

Grüße von --VÖRBY 10:33, 22. Nov. 2011 (CET)

(BK):Frage, wie kann die prozedurale Programmiersprache eine Untermenge der imperativen Programmiersprachen sein, wenn die imperativen Programmiersprachen die prozedurale Programmiersprache gar nicht vorraussetzen? Flugzeuge sind auch eine Untermenge von Luftfahrzeugen, obwohl Luftfahrzeuge keine Tragflächen vorraussetzten. Ich sehe erst mal keinen Widerspruch. --Avron 10:40, 22. Nov. 2011 (CET)

@VÖRBY: Der Begriff PP wird in der Tat vielfältig verwendet. Die beiden Bedeutungen in einem Artikel zu verbinden ist nicht so gelungen. Vielleicht wäre es besser zwei getrennte Lemmas machen, aber wie würden die Klammerlemmas aussehen? In einem Punkt bin ich jedoch nicht deiner Meinung. Die zweite Bedeutung von PP ist die Zusammenfassung der "klassischen" Programmierung" als Gegensatz zu der objektorientierten Programmierung; es hat mit "fortschreiten" nichts zu tun.--Avron 10:56, 22. Nov. 2011 (CET)

Ein Paradigma mit dieser Bezeichnung ('kl.P.') gibt es nicht - obwohl dieser Programmierstil ein sehr bedeutender und weit verbreiteter ist/war! Daraus müsste man schließen: Dieser Stil wurde später (als es andere Stile gab) 'PP' genannt. Wir sollten das aber hier nicht nochmal aufkochen. --VÖRBY 12:04, 22. Nov. 2011 (CET)

Es geht mir nicht ums Aufkochen, aber ich glaube wir sind uns schon einig, dass die Sachverhalte zu PP besser dargestestellt werden sollten. Wir waren uns aber nicht einig wie das getan werden soll. Ob in einem oder zwei Artikeln, vielleicht sollten wir einen zweiten Versuch wagen.--Avron 13:58, 22. Nov. 2011 (CET)

Das mit zwei Artikeln ist insofern unpraktisch, weil exakt dieser eine Terminus offensichtlich mit zwei unterschiedlichen Begriffen belegt ist - so weit waren wir ja schon mal. Ich denke aber, sowas gibts in WP häufig - und für den Leser ist es wohl das Beste, wenn dann ein solches Lemma (= Terminus) die zwei Bedeutungen (ähnlich 1. und 2. im Entwurfstext?) beschreibt. Eine BKL vorzuschalten scheint mir nicht das Richtige zu sein - weil in beiden Fällen ja wohl ein Programmierstil gemeint ist. Und PP(xx) und PP(yy) gefällt mir auch nicht. Grüße von --VÖRBY 16:01, 22. Nov. 2011 (CET)

Zur BKL-Frage gibt es verschiedene Ansichten. Unter WP:BKL findet man einige Verfechter der Strategie "ein Artikel pro Begriff" (und Begriff $\neq$ Wort). Zu aller erst muss aber die Faktenlage stimmen. Welche Quellen bestätigen die Auffassung, dass prozedural von procedere und nicht von Prozedur kommt? --Zahnradzacken 16:36, 22. Nov. 2011 (CET)

Selbst wenn es irgendwo stünde dass prozedural von procedere kommt was würde es beweisen? Ich habe zu dem Thema viel gelesen, da war viel Schlechtes dabei. Ich meine auch das gelesen zu haben, wo bei ich das für falsch, weil nicht logisch, halte. Selbst wenn es schlüssig erklärt würde, es würde mehr Komplexität in das Thema reinbringen. Es würde nicht helfen die hier bisher diskutierten Bedeutungen "Zerlegung des Problems durch Prozeduren" und "klassische Programmierung als Gegensatz zu objektorientierter Programmierung" zu vereinbaren, sonder vielmehr als dritte Bedeutung im Raum stehen.--Avron 16:58, 22. Nov. 2011 (CET)

@Zahnradzacken: In den WP-spezifischen Strukturfragen bin ich nicht so firm, meine aber, dass hier eine BKL irgendwie nicht passt (wie z.B. bei Schloss oder Strom). HIER liegt der Fall ähnlich wie bei Software; auch dort gibt es unterschiedliche Interpretationen, und die sind im Artikel einfach beschrieben - häufig mit dem Zusatz 'in engerem Sinn' oder ähnlich. Damit trägt man der Tatsache Rechnung, dass es eben keine 'heile Welt' gibt (hier: eindeutige Termini/Begriffe), sondern es gerade auch in der IT/Informatik häufig abweichende Auslegungen gibt. Gründe dafür mögen sein, dass sich hier die Welt besonders schnell ändert. Ähnliche Phänomene gibt es ja auch in der Sprache - wo Wörter irgendwann im Zeitverlauf mal was anderes bedeuten. Ein Duden z.B. führt dann auch ein 1.) und 2.) etc. auf. Also: M.E. keine zwei Artikel.
Zu Quellen: Das waren die, die im Verlauf der o.g. Diskussion schon zitiert und ausgetauscht wurden - und nach denen praktisch Merkmale der 'klassischen Programmierung' beschrieben (und PP genannt) werden, etwa im Gegensatz zu neueren Paradigmen. Wer setzt jetzt eigentlich "den Hut" auf? Grüße von --VÖRBY 17:27, 22. Nov. 2011 (CET)

Ich bin hier auch gegen BKL, aber man sollte im Hinterkopf haben, dass nicht ästhetische Gründe (Missfallen von Klammerlemmata) entscheidend sind.

Ich habe vorhin versucht, deine alten Quellen nach dieser Bedeutung abzuklappern, habe aber nur eine einzige gefunden. Es müsste natürlich schon eine bessere Quelle sein, um das hier aufzunehmen. Insofern finde ich @Avrons Einwand nicht so nachvollziehbar: Wenn es reputable Quellen gibt, dann gehört die Info hier rein. Finden wir nur private Websites und Print-on-demand Bücher, bleibt die "Info" draußen. Als dritte Meinung zusätzlich zur bisherigen Diskussion sehe ich das aber nicht, weil die Meinung erstens schon oft (und vorhin erst wieder) eingebracht wurde und weil zweitens die ersten beiden sich nur wenig unterscheiden. Als dritte Meinung im Artikel hat es aber seine Berechtigung, sofern es dafür ernsthafte Quellen gibt. --Zahnradzacken 17:45, 22. Nov. 2011 (CET)

Hmm, wieder, wie so manchmal bei der ersten Diskussion, kann ich nicht folgen worum es eigentlich geht. Geht es nun um "klassischen Programmierung" oder um "prozedural=fortschreiten" oder um BKL ja/nein oder was anderes? Zur BKL und Beispiel Software folgendes: Bei Software sind die Bedeutungen zwar nicht deckungleiche aber wenigstens so ähnlich dass man eine gemeinsame Einleitung schreiben kann. Hier sind die Bedeutungen "Zerlegung des Problems durch Prozeduren" und "klassische Programmierung als Gegensatz zu objektorientierter Programmierung" so verschieden dass wir bisher an einer gemeinsamen Einleitung gescheitert sind. Der bisheriger Vorschlag (Prozedurale Programmierung ist ein Programmierparadigma, nach dem Computerprogramme entwickelt werden können. In der Literatur finden sich zu diesem Terminus unterschiedliche, inhaltlich voneinander abweichende Definitionen und Beschreibungen:) ist keine gemeinsame Einleitung sondern eine BKL mal abgesehen davon dass bisher nicht belegt wurde dass die Bedeutung "klassische Programmierung als Gegensatz zu objektorientierter Programmierung" überhaupt ein Paradigma ist.--Avron 08:25, 23. Nov. 2011 (CET)

Habe nochmal Quellenreferenzen eingestellt und Texte zu PP⁽²⁾ ;-) entsprechend an die Quellen angepasst. Unabhängig von diesem unseren Hauptthema ist die ursprüngliche Fragestellung des Anfragers (beim alten Text) auch noch offen. Siehe oben - "Recht hast du trotzdem ...".--VÖRBY 14:06, 23. Nov. 2011 (CET)

Irgendwie ist das wir rumgestochere im Nebel. Ich erkenne in den Zitat-Schnipseln <<<(das kommt vom Zwang, alles belegen zu wollen/müssen>>>) leider immer noch kein Konzept. Was hat „Daten und Anweisungen sind voneinander getrennt“ damit zu tun dass Prozedurale Programmierung auch als Synonym zu Imperative Programmierung gebraucht wird? <<<(Das gehört nicht mehr zur Aussage 'Synonym')>>>. Übrigens, wo sind Daten und Anweisungen nicht voneinander getrennt? <<<Bei OO sind sie total eng miteinander verwoben.>>> Später: Beim deklarativen Programmieren definiert man grundsätzlich das 'WAS' und nicht das 'WIE', die [...] Problemlösungsschritte werden automatisch erzeugt“ . Die Aussage zu deklarativen Programmieren ist richtig nur was sie hier für einen Mehrwert? <<<Das Gegenteil von pP - zur Verstärkung des Verstehens.>>> --Avron 15:57, 23. Nov. 2011 (CET)

Danke, Antworten in <<<Kleinschrift>>> in Deinem Text. Lassen wir's wieder! Vielleicht kannst Du dem Anfrage noch - nach der Definition von pP(1)- das 'Mengenproblem' noch auflösen, das oben unter "Recht hast du trotzdem" angedeutet ist (Untermenge vs. 'praktisch alle ...'). Grüße von --VÖRBY 19:14, 23. Nov. 2011 (CET)

Das Mengenproblem hast du bereits beantwortet. Ansonsten bedaure ich, dass die Kooperation bei dir zu einer leichten Trotzreaktionen führt. Deine Zitatschnipsel sind willkürlich und nicht die Folge der Belegpflicht. Man kann referenzieren, ohne zu zitieren. Aber in der Referenz muss die Aussage dann auch gestützt werden und: egal, wie man es tut, die Aussagen sollten einen Zusammenhang ergeben.

Deine bisherige Strukturierung des Texts ist nur so zu verstehen, dass es 1) (pP $\subsetneq$iP) und 2) (pP=iP) gibt; und das Zitat zu von Daten getrennten Anweisungen findet sich bei 2). Diese Aussage über von Anweisungen getrennten Daten kann man kaum diskutieren, weil sie so generisch ist, dass jeder etwas Anderes darunter verstehen kann. Das müsste präziser sein. Die Abgrenzung zu deklarativem Programmieren könnte man so umformulieren, dass der Zusammenhang deutlicher wird, und dann in der Einleitung verwenden. Andernfalls finde ich es aber auch sinnvoll, es zu belassen, denn die Hauptaufgabe wäre das Aufweisen von zitierfähigen Quellen. --Zahnradzacken 21:49, 23. Nov. 2011 (CET)

Einzelnachweise (lokal)

Avron's Vorschlag

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 17:41, 14. Nov. 2012 (CET)

Wie schon oben angedeutet, habe ich etwas zusammengebastelt: Benutzer:Avron/Prozedurale Programmierung. Der Vorschlag hat jetzt m.E. einen vorzeigbaren Stand und würde gerne Meinungen einholen. Es geht mir nicht um genaue Formulierungen sondern um das Konzept. Ich habe eine vielzahl von Büchern verwendet die google heregibt, um die vielfalt der Bedeutungen und Verwendungen zu unterstreichen. Guten Abend.--Avron 21:30, 27. Nov. 2011 (CET)

---

Hallo Avron, zu deinem Entwurf habe ich i.W. folgende Anmerkungen:

• 1. Wir sollten aus den zwei Bedeutungen nicht vier machen: Ich denke, dass man zur ersten Aussage auch die 3. hinzunehmen kann (dass diese Bedeutung ähnlich den Begriffen 'strukturierte' bzw. 'modulare Programmierung verwendet wird).
• 2. Ebenso gehören 4 und 2 zusammen - dass diese Vorgehensweise als Synonym zu 'imperativ' gebraucht wird oder auch proz/imperative Programmierung genannt wird.
• 3. Die Kurzbeschreibung oben für pP(2) sollte (wie auch für pP(1) kurz aussagen, was konkret gemeint ist - wobei mir hier die Aussage "i.W.: algorithmische Lösungsbeschreibung' (Schritt für Schritt, 'First this then that' o.ä." genügen würde. Was 'klass. nicht OOP' bedeutet, weiß nicht jeder.
• 4. 'Zerlegung in Teilprobleme' für pP(1) halte ich für unpassend; es sind eher ~Teillösungen
• 5. In der Detailbeschreibung pP1 halte ich die ausführlichen Aussagen zu lokalen und globalen Variablen für unpassend; das hat nichts mit pP zu tun, sondern geht in manchen Programmiersprachen, in anderen nicht.
• 6. Im Detailabschnitt zu pP(2) wird bisher nicht wirklich beschrieben werden, was pP(2) ist, d.h. die Merkmale (siehe alter Entwurf) sollten aufgeführt werden, der Aspekt ~Daten ist nur eines davon. Bisher beschreibt Dein einleitender Text hier i.W., was pP(2) nicht ist.
• 7. Die Überschrift dazu sollte nicht 'klassische, nicht-oo..' heißen, sondern z.B. 'Liniearer Fluss der Anweisungen'. Dass pp2 ein Sammelbegriff für "ungleich OO" ist, halte ich für falsch: Es ist einfach ein anderes Paradigma und unterscheidet sich von allen anderen, nicht nur von der OO.

Weitere Details würde ich gerne erst überprüfen, wenn die o.g. grundsätzlichen Anmerkungen berücksichtigt wären. Vor allem finde ich die Aussagen zu OO in diesem Text für zu umfangreich; die pP gab es schon lange vor der OO - und sollte deshalb auch unabhängig von ihr beschrieben werden (können). Und: Mein Hauptargument, dass fast überall, auch in der OO, mit Prozeduren gearbeitet wird, bleibt nach wie vor logisch ungelöst: Ist pP(nach 1) dann ein Unter-Paradigma für all jene Paradigmen?. Schau'n mer mal!?!? --VÖRBY 13:02, 28. Nov. 2011 (CET)

(Hab's nummeriert um Besser antworten zu könnnen)

• • 1. Nicht wir machen die Bedeutungen, sondern die Autoren der Bücher. Gerade weil der Begriff PP so unterschiedlich interpretiert wird, müssen alle Verwendungen offengelegt werden. Strukturierte Programmierung wird nun mal von Zerlegung des Algorithmus unterschieden.
  • 2. Genausowenig sollten imperative Programmierung und "klassische nicht-objektorientierte" Programmierung zusammen vermengt werden. Es sind zwei verschiede Dinge und sollen auch so erklärt werden.
  • 3. Die Kurzbeschreibung oben für pP(2) sollte (wie auch für pP(1) kurz aussagen, was konkret gemeint ist das sollte sie, ich bin für Vorschläge dankbar. wobei mir hier die Aussage "i.W.: algorithmische Lösungsbeschreibung' (Schritt für Schritt, 'First this then that' o.ä." genügen würde. Das ist aber nicht das Wesen der PP sondern der imperativen Programmierung, deswegen geht das gar nicht.
  • 4. klar, kann man machen
  • 5. Die Sichtbarkeit der Variablen geht einher mit dem Konzept der PP. Zumindest sehen das die Quellen so.
  • 6. Wenn es Quellen gibt, die besser und präziser eklären was PP ist, dann werden sie aufgenommen.
  • 7. Wenn jemand einen besseren Vorschlag für die Umschreibung hat, dann bitte her damit aber 'Liniearer Fluss der Anweisungen' geht gar nicht, denn das ist imperativen Programmierung und wird von den Quellen auch so nicht belegt.

Mein Hauptargument, dass fast überall, auch in der OO, mit Prozeduren gearbeitet wird, bleibt nach wie vor logisch ungelöst: Ist pP(nach 1) dann ein Unter-Paradigma für all jene Paradigmen? PP (Zerlegung des Algorithmus) ist natürlich auf für OO gültig.--Avron 20:58, 28. Nov. 2011 (CET)

---

Hallo Avron, wir stecken wieder mitten drin im Schlamassel und finden da wohl nicht mehr raus. Vor allem deine Fixierung auf die objektorientierte Programmierung (zur Beschreibung der pP) stört mich erheblich. Ich antworte deshalb wieder nur knapp:

• Zu 1: Man darf aber die Leser nicht verwirren, sondern sollte Aspekte, die sehr nahe beisammen liegen, auch besser als 'zusammengehörend oder ähnlich' darstellen. Wenn schon 4 Bedeutungen, dann müssten die auch jeweils im Deteil beschrieben werden. M.E. sind das aber lediglich sprachliche Unterschiede (Synonyme, ggf. auch aus Übersetzungen falsch abgeleitet), z.B. wenn das mit prozedural (nach pp1), modular, strukturiert bezeichnet wird.
• Zu 3/6: In 'meinem' Text (auf der Grundlage der Quelle von Zahradzacken) stehen die wichtigsten dieser Merkmale.
• Zu 5.: Dazu muss man aber dieses Thema (Variable) nicht so ausführlich beschreiben.
• Zu 7: L.F. ist auch eine Umschreibung von 'Anweisung für Anweisung' - oder wie auch immer. Außer nach pP1 wird dies eindeutig und überwiegend (es gibt leider zu viele, v.a. im Detail unterschiedliche Quellen) als das wesentlichste Merkmal der pP beschrieben - selbst wenn das dann z.T. unter 'imperativ-prozedural' o.ä. steht.

Ich bin mit meinem "Latein am Ende". Schöne Zeit!--VÖRBY 09:52, 29. Nov. 2011 (CET)

Ich sehe das nicht so pessimistisch. Seit langem sehe ich einen Weg wie wier aus dem Schlamassel raus können. Zu den einzelnen Punkten:

• • Zu 1: Die Dinge mögen ähnlich sein, sind aber nun mal nicht gleich. Wenn 2 von 4 Bedeutungen synonyme sind, dann haben sie keine eigene Aussagekraft und wären nur redundant zu den anderen Artikeln. M.E. sind das aber lediglich sprachliche Unterschiede (Synonyme, ggf. auch aus Übersetzungen falsch abgeleitet), z.B. wenn das mit prozedural (nach pp1), modular, strukturiert bezeichnet wird. Meines Erachtens auch, aber das müssen die Autoren der Bücher verantworten. In dem Thema gibt es nun mal kein eindeutiges "falsch" oder "richtig" deswegen sind wir angehalten die Tendenzen in den Quellen zu beschreiben.
  • Zu 3/6: 'Dein' Text verwendet eine einzig Quelle: [21] Der Erste Abschnitt Imperative or proceduall programming ... beschreibt die imperative Programmierung und hier wird auch prozedural als Synonym benutz. Der zweite Abschnitt Also, a procedurall paradigm... hingegen beschreibt die Zerlegung des Programms in Teile. Was anderes belegt die Quelle nicht, von daher ist ein großteil deines Textes nicht belegt.
  • Zu 5.: Ich bitte dich, es gibt zwei Sätze dazu. Bei Bedarf kann man das aber straffen.
  • Zu 7.: ...selbst wenn das dann z.T. unter 'imperativ-prozedural' o.ä. steht. dann geht es auch um eine andere Bedeutung. Welche Quellen meinst du?

--Avron 11:45, 29. Nov. 2011 (CET)

Quellen: In den Beschreibungen zu pP2 hatte ich zahlreiche Quellen und die von ihnen genannten Merkmale aufgeführt. Selbst wenn sie als nicht valide bezeichnet wurden, haben sich diese Leute (u.a. aus 4 Uni's) sowas bestimmt nicht "aus den Fingern gesaugt". Die 'neue' Quelle nennt i.W. die selben Markmale - und nennt das dann imperativ-prozedural. Diese vielen unterschiedlichen Bezeichnungen sind wohl auch unser Hauptproblem. Und wir können jetzt nicht sagen, dass das, was imp-proz genannt wird, nur imperativ sei; denn dann müssen wir uns auch mit jenem Ausdruck und seinen Unterklassifizierungen noch rumschlagen - wie du (i.Z. mit Sebastian Dietrich) ja ganz am Anfang schon gemeint hattest. WP hat da wohl noch viele Baustellen.

Ich komme aber nochmal auf die Sache zurück, dass Prozeduren quasi überall benutzt werden: Wenn ein P-Paradigma ein fundamentaler Programmierstil ist, wieso sollte dann ein Vorgehen, dessen einziges Merkmal in praktisch allen anderen Paradigmen/Sprachen auch angewendet wird (und das ein relativ trivialer Sachverhalt ist), ein eigenes Paradigma sein? Das noch dazu überwiegend als Vorläufer neuerer P. (inkl. OO) gilt. Ich sehe das zwischenzeitlich so, dass pP natürlich auch als 'Programmieren in Prozeduren' zu verstehen ist; das steckt ja zweifelsfrei im Wort drin. Das Paradigma wäre aber nach meinem Verständnis die 'breitere Definition' nach pP2 - inkl. Prozedurbildung. So bezeichnet z.B. auch die Quelle [22] (valide oder nicht?) dieses sinnvolle Bilden von 'Unterprogrammen' (sie spricht nicht vom Paradigmen!) mit 'Dies ist prozedurale Programmierung im engeren Sinne.' Es scheint also eine weitere und eine engere Definition zu geben. Der Artikel soll aber wohl das Paradigma beschreiben. Unsere Quellen jedenfalls scheinen uns hier nicht weiter zu bringen; sie berwenden zu unterschiedliche Bezeichnungen und beschreiben zu unterschiedliche 'Begriffe'; leider. Zahnradzacken scheint Recht zu haben: Das hat wohl noch niemand so richtig wissenschaftlich behandelt. Und jeder interpretiert 'frei Schnauze' - inkl. "Plagiatismus". WP kann aus diesem Wirrwarr nicht selbst eine neue Ordnung schaffen. Deshalb kann man hier lediglich auf die Vielfalt hinweisen und irgendwie einen gemeinsamen Nenner (oder zwei) beschreiben. --VÖRBY 13:36, 29. Nov. 2011 (CET)

...und nennt das dann imperativ-prozedural Das ist doch mal eine gute Erkenntniss. Der Artikel heisst aber nicht "imperativ-prozedurale Programmierung" sondern "prozedurale Programmierung" und imperative Programmierung gibt es schon als Artikel. Klar, es hängt vieles zusammen aber es ist eben nicht das gleiche.

Und die Gegenfrage: ist die Objektorientierte Programmierung wie sie in Java, C++ usw. angewendet wird etwa nicht imperativ?

Wenn ein P-Paradigma ein fundamentaler Programmierstil ist, wieso sollte dann ein Vorgehen, dessen einziges Merkmal in praktisch allen anderen Paradigmen/Sprachen auch angewendet wird (und das ein relativ trivialer Sachverhalt ist), ein eigenes Paradigma sein? Alles was ich bisher gelesen habe weist für micht darauf hin dass Paradigma nicht definiert wird. Jeder kann eine Art des Programmierens als Paradigma bezeichnen.

Es scheint also eine weitere und eine engere Definition zu geben. So sehe ich das auch.

Der Artikel soll aber wohl das Paradigma beschreiben. Der Artikel beschreibt das Lemma und das ist nun mal "prozedurale Programmierung". Was ein Paradigma ist das ist eine andere Frage, die wir nicht lösen werden, weil es da an einer genauen Definition mangelt.

WP kann aus diesem Wirrwarr nicht selbst eine neue Ordnung schaffen. WP kann keine neue Definition aufstellen, aber eine durch eine sturkturierte Übersich kann sie schon zu Ordnung beitragen.

Sind wir noch wirklich weit auseinander? Ich verstehe nicht so wirklich was du noch als Probleme ansiehst... --Avron 09:02, 30. Nov. 2011 (CET)

Hallo Avron, mal wieder ein Lichtblick? Aus meiner Sicht solle dieses Lemma schon immer den 'größeren Zusammenhang' (~das 'Paradigma') beschreiben. So ist der Artikel i.W. auch verlinkt und der entsprechenden WP-Kategorie zugeordnet. Dass wir zwei Bedeutungen haben, wissen wir schon länger. Trotzdem meine ich, dass jemand, der nach diesem Stichwort (nicht 'Begriff') sucht, dann auch die beiden Bedeutungen finden sollte; also keine 2 Lemmas. Ich habe diesem 'Tenor' entsprechend 'meinen' Text nochmal umgeschrieben. Die Bedeutung von pP(1) (wird langsam zum geflügenlten Wort) habe ich aber noch weggelassen; wir sind uns hierzu ja einig.

Mir scheint, dass es jetzt lediglich noch darum gehen könnte, ob man die Details von pP(2) nun bei imperativ einstellen sollte und HIER kürzen. Das erscheint mir aber derzeit nicht vernünftig, weil auch im Sinn von pP2 der Terminus 'pP' der geläufigere zu sein scheint. Außerdem möchte ich JETZT nicht in die Diskussion einsteigen, ob das wirklich nur Synonym ist oder nicht; in vielen Veröffentlichungen gilt iP als Überbegriff. Vielleicht schaffen wir es ja, deine (sie stehen ja noch unverändert) und meine Texte zu einem neuen zusammenzubringen. Grüße von --VÖRBY 17:41, 30. Nov. 2011 (CET)

Postiv finde ich dass du die Existenz von verschiedenen Bedeutungen akzeptierst. Der zwei ersten Sätze der Einleitung sind in Ordnung aber dann ansonsten sehe ich kaum Fortschritt bei deinem Vorschlag. Entweder man benutzt Paradigma für beide Sachverhalte oder gar nicht. Es gibt Quellen welche unter der Bedeutung "Zerlegung des Algorithmus" ebefalls von Paradigma sprechen. Dabei steht im Wesentlichen das WIE der Problemlösung im Vordergrund: Ein Programm schreitet sozusagen von Anweisung zu Anweisung voran, was dem lateinischen Wort „procedere“ – voranschreiten – entspricht Das ist imperative Programmierung. Auf meine Gegenfrage oben ist die Objektorientierte Programmierung wie sie in Java, C++ usw. angewendet wird etwa nicht imperativ? habe aber noch keine Antwort bekommen. Die Einleitung für diese Bedeutung ist also immer noch falsch, denn der Unterschied zwischen PP und OP ist der Zusammnehalt der Daten und Methoden in Objekten bei OOP. Beide sind imperativ. Auss Assembler hangelt sich von Anweisung zu Anweisung.

Der Rest ab Ebenfalls als tpyisch für das prozedurale Paradigma... ist noch weit von "rund" aber das ist nicht das Hauptproblem.--Avron 09:04, 1. Dez. 2011 (CET)

---

Hallo Avron, harte Sache, was?

• Die zwei Bedeutungen standen nie in Zweifel.
• Ich habe jetzt mal 'Paradigma' aus dem Text entfernt.
• Ich denke nicht, dass man für jede kleine Variante von Stil 'Paradigma' sagen kann, denn das ist mit 'fundamentaler Programmierstil' definiert. Sonst gäbe es ja wohl hunderte davon. Ich denke, dass dies der Unterschied zwischen Programmierstil und Programmierparadigma ist. Aber lassen wir das mal.
• Häufiger als untr imp.P. werden diese Merkmale (von pP2) unter 'prozedural' beschrieben. Meine Anm. zu iP habe ich oben schon gemacht.
• Dass die Programmiersprachen unterschiedliche Paradigmen unterstützen, ist ja bereits beschrieben. Insofern kann auch C++ und Java etc. sowohl imperativ (es gibt ja 'Befehle') als auch prozedural benutzt werden, nach pP1 sowieso (weil ~Prozeduren gebildet werden) und auch nach pP2 (aber nur die einzelnen sequentielle Module betreffend) benutzt werden. Eine etwa ereignisorientierte 'Anwendung' kann nach pP2 nicht als prozedural gelten. Was Daten betrifft: Ist oben im Text so beschrieben.

Wieviele Runden noch? Gruß --VÖRBY 11:33, 1. Dez. 2011 (CET), aktuell: --VÖRBY 12:41, 1. Dez. 2011 (CET)

Ansatz 'Sequentielle Anweisungsfolge' ist immer noch falsch und da hat sich nichts gebessert. Prozedurale Programmierung wird als grundlegender Programmierstil verstanden, nach dem – als wesentliches Merkmal – das WIE der Problemlösung im Vordergrund steht: Ein Programm schreitet sozusagen von Anweisung zu Anweisung voran, was dem lateinischen Wort „procedere“ – voranschreiten – entspricht Das ist die Erklärung für Imperative Programmierung. Wenn du über Imperative Programmierung schreiben willst, dann tue es bitte dort. So ist dein Vorschlag nicht zu gebrauchen. Es ärgert mich wirklich, das ist anscheinend keine Diskussion die weiterführt. Ich überlege ernsthaft die Diskussion zu beenden, meinen Vorschlag fertigzustellen und in den Atikel, auch ohne Konsens mit dir, einzustellen. --Avron 13:54, 1. Dez. 2011 (CET)

Wir ignorieren also all die Quellen, die die pP2-Merkmale als pP bezeichnen und ergänzen diese Merkmale bei iP. In pP muss dann aber noch deutlich klargestellt werden, dass dieser Ausdruck zum Teil auch als Synonym zu iP verwendet wird - und in ip in umgekehrter Form. Ob das dann wirklich richtig ist, sei dahingestellt, jedenfalls wären die WP-Artikel konsistent. Viel müsste man also gar nicht ändern. Wäre das ok für dich? In 'meinem' Text mache ich dazu noch die entsprechenden Vorschläge. --VÖRBY 19:26, 1. Dez. 2011 (CET)

Wir dürfen keine Quellen ignorieren. PP im Sinne der "klassischen Programmierung" ist naürlich imperativ, genauso wie Assembler und die OOP. Das soll man natürlich schreiben. Aber ein wesentliches Merkmal ist es nicht. Das wäre so als würde man Fahrzeuge beschreiben und bei PKW sagen "Das wesentliche Merkmal eines PKWs sind Räder" Natürlich hat ein PKW Räder, genauso wie ein LKW, Motorrad oder Fahrrad; das gilt eben für alle anderen Radfahrzeuge auch. Auch kann man schreiben dass Kontrollstrukturen verwendet werden, Datenwerte als Variablen definiert werden, welche einen bestimmten Datentyp haben, u.s.w... Das ist ja alles so weit richtig. Nur wenn es um das wesentlichte Merkmal geht, dann vegleichen so gut wie alle Quellen PP mit OOP und der Unterschied ist nun mal der Zusammnehalt der Daten und Methoden in Objekten bei OOP, während es bei PP diese nicht gibt.

Noch meine Antwort zu: Insofern kann auch C++ und Java etc. sowohl imperativ (es gibt ja 'Befehle') als auch prozedural benutzt werden, nach pP1 sowieso (weil ~Prozeduren gebildet werden) und auch nach pP2 (aber nur die einzelnen sequentielle Module betreffend) benutzt werden. Eine etwa ereignisorientierte 'Anwendung' kann nach pP2 nicht als prozedural gelten C++ und Java sind immer imperativ; das Gegenteil ist deklarativ. Ereignisorientierte Programmierung hat im Kern weder mit OOP noch mit PP etwas zu tun. Hybridsprachen unterstützen PP im Sinne der klassischen Programmierung wie auch OOP.

Ich habe meinen Vorschlag weiterverfolgt: Benutzer:Avron/Prozedurale Programmierung

--Avron 10:10, 2. Dez. 2011 (CET)

Ich hatte die letzten Disk-Shritte so verstanden, dass im Lemma pP die Bedeutung von pP1 bleibt und bezüglich pP2 lediglich die Synonym-Tatsache (i=p) erwähnt und ein Link nach iP erscheinen sollte. Die Details zu pP2 (belegt mit den genannten Referenzen) würden dann in iP aufgenommen. Letzteres kann ich schon mal vorbereiten, pP änderst du. Ok?
Die intensiven Bezugnahmen zu OOP im Text zu pP2 (das hätte sich aber jetzt erledigt) hielte ich nach wie vor für nicht angebracht, weil ein Paradigma durch seine Merkmale beschrieben werden sollte und nicht durch die Unterschiede zu anderen. Auch zu C++ und Java etc. sind wir nicht voll deckungsgleich: Einzelne Codeteile mögen wohl i/p erstellt werden können, eine so erstellte ganze ANWENDUNG ist aber nicht iP, weil hierzu im Code nicht vollständig das "first do this then do that" festlegt wird. Lassen wir's aber dabei. --VÖRBY 12:43, 2. Dez. 2011 (CET)

Den ersten Satz verstehe ich nicht, kann deswegen nicht darauf wirklich antworten. Die Details zu pP2 (belegt mit den genannten Referenzen) würden dann in iP aufgenommen Keine Ahnung welche Details du meinst, auch habe ich keine Ahnung was bei imperative Programmierung fehlen sollte. Imperative_Programmierung#Abgrenzung erklärt den Sachverhalt zur genüge. Also ganz und gar nicht OK!!!

Die intensiven Bezugnahmen zu OOP im Text zu pP2 (das hätte sich aber jetzt erledigt.. Das erledigt sich ganz und gar nicht. Das ist was die Quellen beschreiben. Nimm das doch endlich zur Kenntniss.

Auch zu C++ und Java etc. sind wir nicht voll deckungsgleich: Einzelne Codeteile mögen wohl i/p erstellt werden können, eine so erstellte ganze ANWENDUNG ist aber nicht iP Quatsch: JAVA und C++ sind 100% imperativ. Ich habe keine Ahnung was du für imperative Programmierung hälst. Weder in Java noch in C++ programmiert man deklarativ.--Avron 13:45, 2. Dez. 2011 (CET)

---

Ich steig aus. Die Zusammenhänge in den Begriffen/Termini (Programmiersprache, Anwendung, Merkmale, Synonym oder nicht ...) sind zu komplex, als dass wir beide auf diesem Weg zusammenkommen. Soll's so bleiben wie es ist. Am besten löschen wir auch die ganze Diskussion, sonst denkt jemand, da sind Irre am Werk. --VÖRBY 14:27, 2. Dez. 2011 (CET)

Einfach ist es nicht, aber das ist kein Grund. Es gibt viele Artikel zu komplexeren Themen die auch mehrdeutig sind. Mann muss sich halt mit dem auseinandersetzen was die Quellen schreiben. Ich werde meinen Vorschlag ausarbeiten und ihn dann einsetzen.--Avron 00:01, 3. Dez. 2011 (CET)

... und ich mache die Ergänzungen in 'iP' - wie Du vorgeschlagen hattest und inhaltlich nach den beiden angeführten Quellen.

PS: In meiner Aussage zu 'komplex' lag der Schwerpunkt auch auf 'wir beide' - was ja wohl bewiesen ist. Grüße von --VÖRBY 10:56, 3. Dez. 2011 (CET)

Ich habe nicht vorgeschlagen dass du irgend etwas von dieser Diskussion auf IP schreiben sollst. Ich habe lediglich gesagt, wenn du über IP schreiben willst dann tue es dort. Ich habe keine Ahnung was du schreiben willst, aber schreib bitte nichts unlogisches & unbelegtes. Zuletzt wurde in der Diskussion deutlich dass du eine seltsame Vortellung von imperativer Programmierung hast. Auch zu C++ und Java etc. sind wir nicht voll deckungsgleich: Einzelne Codeteile mögen wohl i/p erstellt werden können, eine so erstellte ganze ANWENDUNG ist aber nicht iP... Das ganze ist schon ironisch, weil der Benutzer der diese Diksussion ins Rollen brachte [23] richtigerweise auch sagt dass PP und OOP imperative Ansätze sind. --Avron 20:56, 4. Dez. 2011 (CET)

Zwischenzeitlich Weiterführung unter Diskussion:imperative Programmierung#Fortsetzung Dez 2012; siehe dort. --VÖRBY 18:20, 7. Dez. 2011 (CET)

Hallo Avron, habe erst jetzt gesehen, dass Du in 'deinem' Entwurf große Teile der Texte von 'mir' (i.W. die Merkmale) aufgenommen hast. Insofern sind wir mal wieder nicht mehr weit auseinander - und ich halte es auch für besser, diese pP2-Aspekte hier in pP - als zweite Bedeutung - zu veröffentlichen. Vorschlag: Ich könnte meinen Entwurf unter iP um diese pP2-Aspekte reduzieren; dabei würde ich sehen, was davon m.E. ggf. noch bei Dir rein sollte. Trotzdem würde ich einige Aspekte zu iP dort ändern wollen und vor allem die Hinweise zu unterschiedlichen Bezeichnungen dort unterbringen. Was meinst Du? --VÖRBY 18:20, 7. Dez. 2011 (CET), aktuell: --VÖRBY 16:39, 8. Dez. 2011 (CET)

Schau Dir mal den ersten Satz in en:Procedural programming an. Auch dort wird gesagt, pP werde 'sometimes' als Synonym zu iP benutzt. Im Article wird dann aber (explizit so bezeichnet) nur auf pP1 abgestellt. Mit diesem Verweis halte ich das für ok. Wenn wir das auch so machen würden, bliebe lediglich offen, an welcher Stelle die 'Detailmerkmale' beschrieben werden, die über das 'Schritt für Schritt' in iP hinausgehen - und die m.E. schon wichtig sind für diese Sicht. Mein Vorschlag: Wie vorgesehen als 2. Definitionsblock in pP (ggf. nach dem Synonym-Hinweis als 'ergänzende Merkmale' beschreiben). Für gut halte ich in en:WP auch, dass in manchen Paradigmen die Unterschiede zu anderen kurz dargestellt sind (nicht als Definition, sondern nur erläuternd). --VÖRBY 16:39, 8. Dez. 2011 (CET)

---

Guten Morgen Avron, deine Überarbeitung ist ja i.W. gut gelungen. Je nach den verwendeten Quellen kommt man halt zu anderen Ergebnissen. Zu folgenden Aspekten (in pP2) habe ich aber noch letzte Anmerkungen:

• Für unglücklich halte ich die Abschnitts-Bezeichnung '... nicht obj-Orientierte ..'; denn wie häufig beschrieben ist, sind 'imperativ/prozedural' und 'obj-orientiert' keine disjunkten Bedeutungen, sondern werden oft gemeinsam ngewendet. Deine Bezeichnung (z.T. auch die Texte) lassen aber einen Gegensatz vermuten. 'Klassische imperative Programmierung' oder 'imperativ/prozedural' wäre m.E. besser, es ist ja nicht der Terminus, sondern nur die Bedeutung.
• Überhaupt halte ich die Überbetonung der ooP nicht für angebracht: Die pP2 Bedeutung kam jahrelang ohne die OOP aus - und sollte das deshalb auch hier im Text (weitgehend) können.
• Dass diese Bedeutung z.T. mit 'imperativ' oder 'imp/prozedural' gleichgesetzt und synonym benutzt wird, sollte im ersten Absatz m.E. erwähnt und damit klargestellt werden. Zusätzlich 'algorithmisch' ist ja ebenfalls belegt.
• Das wichtigste Merkmal dieser pP2-Sicht (und für den Synonym-Fall 'imperativ' zutreffend) sollte auch hier im Text (nicht nur unter imp.Progr) genannt werden: Dass der programmierte Code die Reihenfolge in der Ausführung bestimmt. Insofern sollte dies das erste Merkmal sein, die 'definierten Zustandsübergänge' wären im Absatz 'Neumann' besser untergebracht.

Unsere Disk hat sich zig-mal gedreht, trotz der letzten Erkenntnisse (Synonym etc.) sind wir anscheinend immer noch in Details (siehe Beispiele bei imperativ) "anders gepolt". Trotzdem beschreibt das Lemma jetzt wenigstens die zwei Bedeutungen, meine o.g. Anmerkungen sollten da eigentlich noch reinpassen - falls da nicht wieder 'Paradigmen' dazwischen liegen. Eine kurze Sichtung durch Zahnradzacken oder andere Autoren könnte vielleicht nochmal 'vermitteln'. 'Nichts für ungut' und bis bald mal wieder. Den Text in 'Imperativ' werden ich dann aktualisieren. Grüße von --VÖRBY 10:40, 18. Dez. 2011 (CET)

Auch von mir ein Lob an Avron für den neuen Text. Ein paar Anmerkungen folgen auf meine Antwort auf VÖRBY.

• Die Bedeutung, nach der imperativ/prozedural und OOP nicht disjunkt sind, wird doch mit dem Artikel imperative Programmierung abgedeckt. Hier wird also nur das behandelt, was nicht schon woanders steht.
• Ich vermute, wir sollten die Klassifikation in pp1 und pp2 nach der Recherchearbeit von Avron neu aufstellen: pp1 ist "Programmieren durch Aufteilen", pp2 ist "klassisch imperativ ohne OOP", pp3 ist "strukturierte Programmierung" und pp4 ist "imperativ, ohne Ausschluss der OOP". Die Zahlenreihenfolge entspricht der ersten Erwähnung im Artikel. Da du pp4 bisher als pP2 benannt hast, verwende ich nebenbei auch pp2* für pp4.

Von den vier Bedeutungen haben pp3 und pp4(pp2*) ihre eigenen Artikel, deshalb müssen nur pp1 und pp2 hier behandelt werden. Dass OOP zur Abgrenzung von pp2 zu OOP dann erwähnt werden muss, ist nur natürlich.

• Deinen Punkt, pp4(pp2*) würde mit pp2 gleichgesetzt, verstehe ich nicht. Hier wird doch gerade ein Wort mit vier Bedeutungen nach seinen Bedeutungen getrennt erklärt. Hier jetzt nochmal Querverbindungen zwischen zwei der Deutungen herzustellen, halte ich für verwirrend.
• In der Einleitung steht, dass PP synonym zu imperativ verwendet wird, das muss man nicht bei der Erklärung einer der anderen Bedeutungen wiederholen.
• Dein "wichtigstes Merkmal" finde ich etwas schwammig, aber ich schlage folgende Ergänzung vor:

Aufzählungspunkt 2 bei pp2 könnte man ergänzen zu: "Kontrollstrukturen (z. B. Sequenz, Schleife, Verzweigung) zur Steuerung der ansonsten sequenziellen Befehlsausführung."

Jetzt noch meine Kritikpunkte am neuen Text:

• Die Bedeutung von pp1 klingt für mich nach einem Analyseverfahren, nicht nach einem Programmierparadigma. Gibt es noch einen Unterschied zu Divide and conquer, so wird er nicht klar.
• Das Prinzip von pp1 scheint der Beschreibung nach auch auf funktionale Programmiersprachen anwendbar zu sein. Globale Variablen gibt es dort aber nicht, lokale Variablen haben eine andere Bedeutung als bei imperativer Programmierung. Eine der beiden Quellen, die du für den Satz "zusammen mit strukturierter Programmierung ..." angibst, nennt strukturierte Programmierung nicht als komplementär, sondern als Teilprinzip (innerhalb der Prozeduren). Damit wäre funktionale Programmierung ausgeschlossen und pp1 ein Spezialfall der imperativen Programmierung. Leider muss man wohl pp1 auch nochmal aufteilen.
• Der letzte Satz bei pp1 soll wohl einen Widerspruch zu einer Aussage darstellen, die ich so nicht im Text finde.
• Bei pp2 würde ich im zweiten Absatz nicht eine Vermischung von pp2 und OOP erwarten, sondern im Gegenteil eine Erklärung, warum pp2 von OOP abgegrenzt wird (nicht unbedingt inhaltlich, aber vielleicht "historisch"). Eine Vermischung von Paradigma und Sprache macht das Verständnis noch etwas schwieriger.

Aber soweit schon vielen Dank für die bisherige Arbeit. --Zahnradzacken 12:00, 18. Dez. 2011 (CET)

Hallo und Danke für die Stellungnahme. Nochmal kurz zu pp:

Wir kämpfen mit dem Problem, dass die Termini und ihre Bedeutungen bei den vielen Quellen unterschiedlich beschrieben werden und dass - unabhängig davon - die Bedeutungen nicht disjunkt sind. Da kann wohl niemand eindeutig strukturieren. Trotzdem meine ich, wir brauchen hier in pp nur die beiden grundlegenden Bedeutungen zu 'prozedural'; dass auch andere Bezeichnungen vorkommen (die aber in WP anderen Bedeutungen entsprechen), sollte da (wie geschehen) genügen. Im Einzelnen:

• Die Zusammenhänge zu OOP erscheinen einfach zu dominant: pp2 war nicht nur bis zur Praxistauglichkeit der OOP die klassische Vorgehensweise, sondern einfach vor der Entwicklung/Verfügbarkeit späterer/neuerer Programmiermöglichkieiten/-Sprachen - z.B. neben OOP auch deklarativ, funktional, logisch, ereignisorientiert etc. pp2 und pp4 in der Klassifikation zu unterscheiden, würde OOP hier zusätzlich, aber unberechtigterweise untermauern; denn da könnte man genauso die Unterschiede zu 'funktional' (z.B.) aufführen. OOP-Unterschiede als Beispiel (nicht in der Klassifikation) sollten da (wie geschehen) genügen.
• Dieses 'schwammige' war auch nur angedeutet und lautet konkret bei einer Quelle: „ein Programm besteht aus einer Folge von Befehlen, die vorgeben, in welcher Reihenfolge was vom Computer getan werden soll“. Dda wir hier pp2 ja näherungsweise als Synonym für iP beschreiben, sollte auch diese grundlegende (m.E. die wichtigste) Aussage für iP hier nochmal kurz erscheinen stehen. Jedenfalls ist dies in den Quellen häufiger und früher genannt als die 'definierten Zustandsübergänge'.

Ich denke, Avron kann das jetzt zu Ende bringen. Schöne Adventszeit wünscht --VÖRBY 18:07, 18. Dez. 2011 (CET)

Hallo, wie auch früher fällt mir eine Antwort schwer weil mir klar ist worum es im Kern geht. Aber ich versuche es mal:

• Häufiges Erwähnen von "objektorientierte Programmierung": Die Quellen nennen nun mal objektetorientierte Programmierung entweder im selben oder im nächsten Atemzug. In den Quellen geht es nun mal um die Unterschiede wie sieht die nicht-objektorientierte aus und wie sieht die objektorientierte Programmierung aus. Damit beschreiben sie auch eine Art Gegenteil, wobei sie auch beschreiben dass die die meisten Prinzipien der klassischen Programmierung auch für die objektorientierte Programmierung gelten. Das anders zu beschreiben wäre Verfälschung der Quellen. Wie schon mal geschrieben, habe ich dei Vermutung dass sich der Begriff "prozeduralle Programmierung" für die klassische Programmierung wohl erst etabliert als die objektorientierte Programmierung hochkam. Aber das ist meine Privattheorie die ich im Artikel nicht erwähne.
• Abschnittsbenennung "imperative, nicht objektorientierte Programmierung": Ich habe lange überlegt wie man den Abschnitt bennenen sollte, bin dann aber doch davon abgekommen es "klassisch" zu nennen. Einfach aus dem Grund weil sonst jemand kommt und meckert was "klassisch" ist relativ also unverständlich. "imperativ/prozedural" habe ich ebenfalls nicht erwähnt weil es eine Rekursion wäre (Begriff mit dem gleichen Begriff erklären) die ebenfalls nicht verständlich ist.
• Es gibt imperative Programmierung und als Gegenteil deklarative Programmierung. Prozeduralle und objektorientierte Programmierung sind beide imperativ. Das sind eigentlich einfache Zusammenhänge; ich verstehe nicht warum man die ohnehin komplizierte Begriffsbeschreibung zu "prozeduralle Programmierung" noch verkompliezieren sollte, wenn man alles in einen Topf wirft.
• Teile und herrsche (Informatik), wie auch Don’t repeat yourself sind sehr allgemeine Prinzipien, "Prozedurale Programmierung" ist die Anwendung davon. Zumindest ist es das was ich aus den Quellen interpretiere. z. B. "Fundamentals of Programming": [[24]] PP is characterized as a problem solving technique that follows a "divide and conquer" approach
• Abgrenzung zu Funktionale Programmierung: In der Tat kann das Prinzip der Aufteilung in Unterprogramme auch für die funktionale Programmierung zutreffen. Nur habe ich davon sehr wenig Ahnung und die Quellen geben nicht viel her.

--Avron 21:10, 18. Dez. 2011 (CET)

Deine Erklärung, warum dir eine Antwort schwer fällt, verstehe ich nicht ganz. Jedenfalls verstehe ich deinen vierten und fünften Punkt als Antwort auf meinen Beitrag und antworte deshalb nur darauf:

• Es stimmt, dass die beiden genannten Prinzipien sehr allgemein sind. Genauso allgemein wird pP aber zurzeit im Artikel beschrieben. Die Aussage aus deiner Quelle, die pP als Technik von "divide and conquer" einordnet, klingt aufschlussreich. Könnte man einarbeiten.
• Du sagst selbst (bei Punkt 3), dass pP imperativ ist. Damit wäre mMn funktionale Programmierung ausgeschlossen. Da ich keine Quelle kenne, die funktionale Programmierung als imperativ bezeichnet, bin ich dafür, diese Abgrenzung zu verdeutlichen. Damit wäre klar, dass pp1 als Prinzip innerhalb der imperativen Programmierung gemeint ist.

--Zahnradzacken 23:03, 18. Dez. 2011 (CET)

OOP / imperativ

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 17:41, 14. Nov. 2012 (CET)

Eigentlich hab' ich zwar keine Lust, mich in die aktuelle obige Disku einzumischen, nur hatt' ich beim Überfliegen den Eindruck, dass OOP festgelegt wird auf "imperativ". Ich hab' im Studium gelernt, wie man mit Scheme und Common Lisp objektorientiert programmiert - das sind nicht-imperative Sprachen mit OOP. Nur als Anmerkung, vielleicht ist's in eurem obigen Entwurf ja auch schon drin.

Schöne Weihnachten! --arilou 23:54, 18. Dez. 2011 (CET)

Ich weiß nicht, was du gelernt hast, vielleicht das Nachbauen bestimmter OOP-Konzepte, etwa wie hier? Andererseits wird hier Scheme zugesprochen, einige OOP-Konzepte zu beherrschen. So oder so, es geht hier nicht um Sprachen, die ja mehrere Paradigmen umsetzen können, sondern um das, was das einzelne Paradigma auszeichnet. --Zahnradzacken 00:54, 19. Dez. 2011 (CET)

Meine eigene Meinung zu dem Thema ist ziemlich das was auch Arilou schreibt, das habe ich auch schon mal geschrieben.

Es gibt die Paradigmen imperativ / deklarativ: die erste beschreibt den Algorithmus die zweite das Problem genau

Es gibt die Paradigmen prozedural bzw. funktional / objektorientiert. Die ersten beiden beschreiben die modularisieung des Codes, das zweite die Verbindung Code zu Daten.

Nun gibt es alle möglichen Kombinationen. d.h. imperativ-prozedural, imperativ-objektorientiert, deklarativ-funktional und deklarativ-funktional-objektorientiert

Jetzt kommen wir zum Grundproblem: Das ist etwas was ich nicht belegen kann. Ich habe bisher keine wissenschaftliche Quelle gefunden die so eine Matrix aufstellt. So gut wie alle Quellen behandeln nur die imperativen Konzepte. Meiner Meinung nach schreibt so mancher Autor ziemlichen Quatsch, weil er das Konzept nicht verstanden hat. Aber was soll man manchen, es scheint in dem Bereich nicht viel falsch/richtig zu geben. Deswegen habe ich versucht den Stand wiederzugeben, wie er in der Literatur beschrieben wird, auch wenn es nicht immer meine Meinung ist.--Avron 08:59, 19. Dez. 2011 (CET)

---

Diese Art von Missverständnissen hatte ich als Folge der intensiven Bezugnahme auf OOP (inkl. Abschnitt-Titel) befürchtet; Arilou meinte daraus abzuleiten, OOP würde als immer imperativ beschrieben; genauso könnte jemand (aufgrund der Überschrift 'imperativ, nicht-OO') ableiten, OO sei ein Gegensatz zu imperativ. Der Hinweis von Zahnradzacken, dass es um die Programmierart, nicht in erster Linie um die Sprache geht, ist diesbezüglich ja schon mal nützlich.
Dass bei der Suche nach 'prozedural' oder 'imperativ' häufig OO-Dokumente gefunden werden (die Unterschiede herausstellen), ist kein Grund dafür, die Definitionen/Merkmale von imperativ/prozedural auf OO zu stützen (wie es in den jetzigen Texten den Anschein hat). Ebenso ließen sich Dokumente finden, in denen die iP/pP als Gegensatz (und erläuternd) zu deklarativ behandelt wird. D.h.: Jeder Paradigma-Begriff (wie auch immer es tatsächlich genannt wird) hat bestimmte, eindeutige Definitionsmerkmale, so auch iP, pP (nach 1 oder 2), OOP und alle anderen. Abgrenzend/erklärend kann man Unterschiede zu anderen Paradigmen ja behandeln, im Definitions- und Beschreibungsteil aber ist das kontraproduktiv und führt (bei der komplexen Begriffslage) eher zu Verwirrungen. --VÖRBY 10:05, 19. Dez. 2011 (CET)

Revert 6.Nov.2012

Siehe diese Löschung.

Die getroffenen Aussagen sind belegt, dass da draußen manche Leute "prozedural" synonym verwenden zu "strukturierte Programmierung" sowie "imperative Programmierung". Ob das thematisch falsch oder richtig ist, ist ein anderer Punkt.

--arilou (Diskussion) 16:40, 6. Nov. 2012 (CET)

Das Problem ist das folgende: Wenn man darauf hinweist, dass manche Leute diese Ansicht vertreten, hat das die Konnotation, dass es sich dabei um eine allgemein vertretbare Meinung handelt, was aber nicht der Fall ist -- weil es falsch ist. Man darf nicht den Eindruck erwecken, das wäre eine völlig akzeptable informatische Meinung. Man muss also aufpassen, welche Konnotationen und Implikationen man sprachlich in die Aussagen reinbringt.

Natürlich will ich nicht TF betreiben. Die Sache ist in diesem Fall aber recht klar: Die Autoren, die "prozedural = imperativ" behaupten, haben offensichtliche Fehler gemacht, deswegen ist es keine TF, das auch so zu sagen. Man kann das sogar beweisen, das tue ich auch gerne, wenn gewünscht. Es geht hier also nicht um eine bloße Ansicht.

Ganz allgemein möchte ich noch folgendes sagen: Man kann für fast jede Aussage Quellen auftreiben. Irgendein Professor wird in irgendeinem Buch mal nicht aufgepasst haben, und schon hat man einen Beleg für Unsinn. Damit will ich sagen, dass die Existenz einer Quelle allein nicht reicht, man muss sie durchaus auf Vernunft prüfen. ʘχ (Diskussion) 17:24, 6. Nov. 2012 (CET)

@ʘx: Bevor ich mich weiter in dieser Angelegenheit äußere, würde ich doch zu gerne diesen Beweis mal zu sehen bekommen. --PerfektesChaos 17:33, 6. Nov. 2012 (CET)

Das ist recht unspektakulär: Man konstruiere eine imperative Sprache, die nicht prozedural ist. Die Mühe des Konstruierens wurde uns glücklicherweise bereits vor Urzeiten abgenommen, ein berühmtes Beispiel ist BASIC. (Damit meine ich die alten BASICs. Die neueren Dialekte sind natürlich alle prozedural.) Auch die meisten Assemblersprachen darf man im weiteren Sinne als imperativ, aber nicht prozedural auffassen. ʘχ (Diskussion) 17:44, 6. Nov. 2012 (CET)

@ʘx: Es ist eine Sache, ob es richtig oder falsch ist, prozedural==imperativ anzusetzen. (Ich bin auch der Meinung, dass das recht eindeutig "falsch" ist.) Aber(!) wenn das oft gemacht wird, darf doch zumindest im Artikel stehen, dass es oft (fälschlicherweise) gleichgesetzt wird. Dann brauchen wir noch einen Beleg für das "fälschlicherweise", und schon ist die Kuh vom Eis. Im Moment fällt mir keine entsprechende Abhandlung ein - ich würde es sehr begrüßen, wenn jemand eine fände. Im Artikel steht dann am Ende etwas à la

"Mitunter wird „prozedural“ gleichgesetzt mit „imperativ“(ref1,ref2,ref3). Dies ist jedoch falsch.(ref4)"

Diese ref4 ist dringend gesucht. --arilou (Diskussion) 09:18, 7. Nov. 2012 (CET)

Diese Vorgehensweise ist im Allgemeinen natürlich korrekt. Hier aber denke ich folgendes:

• a) Im vorliegenden Fall halte ich ref4 für nicht notwendig, weil direkt die Falschheit der Aussage gezeigt werden kann (wenn z.B. irgendwo 1+1=3 bzgl. der üblichen Arithmetik in den nat. Zahlen behauptet wird, braucht man auch keine Quelle, um das als falsch zu identifizieren, weil es beweisbar falsch ist).
• b) Nicht immer ist es möglich, diese ref4 zu finden. Denn das setzt ja voraus, dass irgendein Autor bereits auf die Idee kam, die Aussage als falsch zu bezeichnen, und das ist nicht selbstverständlich. Aus diesem Grund halte ich es für angemessen und richtig, im Falle einer eindeutigen Falschaussage nicht von der Existenz einer ref4 abzuhängen. ʘχ (Diskussion) 09:34, 7. Nov. 2012 (CET)

@arilou +1

Als ich nach dem Beweis fragte, wollte ich den Beweis sehen, dass man prozedural nicht in dieser Bedeutung verwenden dürfe, und dass diese Begrifflichkeit nicht existiere.

Vieles Vokabular hat sich über ein halbes Jahrhundert entwickelt, viele Begrifflichkeiten haben sich erst im Lauf der Zeit herauskristallisiert und abgegrenzt. Millionen von Fachleuten haben sich über Jahrzehnte in vielen Ländern und Sprachen mit irgendwelchen Wörtern auszudrücken versucht.

Zulässig sind in solchen Fällen nur Aussagen der Form: „Heute wird dieser Begriff nur noch …“ oder „Im engeren Sinne …“ oder „Präziser …“ oder dergleichen.

@ʘx – du bist mir schon des öfteren aufgefallen damit, dass du nur eine einzige Begrifflichkeit kennst und alles, was nicht in dein persönliches Vokabular passt, von dir ersatzlos gelöscht wird. Selbst wenn du für den deutschen Sprachraum die im Moment einzig „richtige“ Formulierung kennen solltest, ist es gleichwohl für die Leser wichtig, die Abgrenzung zu anderen kursierenden Bedeutungen zu erfahren. Im Übrigen gibt es für sehr viele Begriffe der IT keinen verbindlichen Standard, weder ISO noch DIN, die exakt definieren würden, welche Bedeutung welche Vokabel hätte und welcher Sachverhalt noch dazugehören würde und welcher schon nicht mehr.

Ich fasse also zusammen: Du bleibst uns den Beweis schuldig, dass die von dir benutzte Verwendung die einzig richtige sei, dass es keine andere Verwendung der Vokabeln gäbe, und du löscht ordnungsgemäß belegte Aussagen ohne selbst irgendeinen Beleg aufbieten zu können.

VG --PerfektesChaos 09:48, 7. Nov. 2012 (CET)

• Als ich nach dem Beweis fragte, wollte ich den Beweis sehen, dass man prozedural nicht in dieser Bedeutung verwenden dürfe, und dass diese Begrifflichkeit nicht existiere. Welche Begrifflichkeit soll da nicht existieren? Es geht hier nicht um sprachliche Willkür, sondern um informatische Inhalte, und die sind klar. Über richtig und falsch entscheidet in der Informatik grundsätzlich nicht eine Analyse der Sprachverwendung. Eine solche Denkweise wäre der Informatik völlig fremd.
• du bist mir schon des öfteren aufgefallen damit, dass du nur eine einzige Begrifflichkeit kennst Wie bitte? Aus der Tatsache, dass ich eine bestimmte "Begrifflichkeit" für korrekt erkläre, folgt, dass ich andere nicht kenne? Diese Denkweise deutet eher darauf hin, dass du meine Argumentation nicht nachvollziehen kannst und daraus folgerst, ich hätte irgendwas anderes ignoriert. Dieser Schluss ist weder logisch zulässig noch irgendwie sonst rational.
• Du bleibst uns den Beweis schuldig, dass die von dir benutzte Verwendung die einzig richtige sei Ich wiederhole es: Über richtig und falsch entscheidet in der Informatik grundsätzlich nicht eine Analyse der Sprachverwendung. Und es geht hier auch nicht um Sprachverwendung. Mittlerweile stellt sich bei mir der Eindruck ein, dass es hier im Bereich der Praktischen Inf. eine Fraktion von Leuten gibt, die allergisch auf absolute Aussagen sind wie "das ist falsch/richtig", und entsprechend, wenn sowas passiert, nicht mit informatischen Gegenargumenten kommen (denn das wäre ja wieder absolut), sondern mit einer Art von relativistischer Sprachkeule, ganz so, als ob wir hier eine Art von Geisteswissenschaft machen würden, die Begriffe untersucht. Erstens ist das aber uninformatisch und daher aus Sicht eines Informatikers nicht qualifiziert, um diskutiert zu werden, und zweitens kann ich mich da natürlich auch des Eindrucks nicht erwehren, dass diese Leute nicht aus der Informatik kommen und deswegen nicht wissen, wie die informatische Methodik ist. (Ich mache da zur Zeit einige unangenehme Erfahrungen, deswegen bin ich da jetzt sensibel.) Informatik ist aber grundsätzlich eine exakte Wissenschaft, und die Teile von ihr, die es noch nicht sind, versuchen, es zu werden.
• Zulässig sind in solchen Fällen nur Aussagen der Form: „Heute wird dieser Begriff nur noch …“ oder „Im engeren Sinne …“ oder „Präziser …“ oder dergleichen. Tja, die Hinweise verdichten sich, dass meine Vermutung mit der Geisteswissenschaft richtig sein könnte. Wir machen hier aber keine Begriffsgeschichte.
• Ok, jetzt lass ich diesen Thread besser mal, denn das erinnert mich doch zu sehr an eine gewisse andere Debatte, die gerade läuft. ʘχ (Diskussion) 10:57, 7. Nov. 2012 (CET)

Genau dieser Aspekt wurde schon sehr ausführlich diskutiert. Mit dem (belegten) Ergebnis, dass der Ausdruck 'prozedurale Programmierung' in der Fachliteratur (und nicht nur 'von gewissen Leuten') mit unterschiedlichen Bedeutungen verwendet wird. Dies ist gerade in der jungen Wissenschaft Informatik (auf Grund ihrer rasanten Entwicklung) sehr oft der Fall und soll, ja muss sogar, in einer Enzyklopädie berücksichtigt werden. Das hat nichts mit 'Wahrheit' zu tun, sondern mit Tatsachen. Es ist also nur gut, wenn "ʘx diesen Thread besser mal lässt". --VÖRBY (Diskussion) 14:26, 10. Nov. 2012 (CET)

Ja, am besten wieder ignorieren, was andere vorgebracht haben. Ich sagte bereits, dass die Begriffsverwendung in weiten Teilen irrelevant ist für die informatische Begriffsbildung. Begriffe werden in der Informatik nicht erst verwandt und dann gemäß der Verwendung definiert, sondern ERST definiert und dann verwandt. Ist das wirklich so schwer?

Noch dazu sind Vorlesungsskripte keine sogenannten "reputablen Quellen". Vorlesungsskripte sind in aller Regel nicht begriffsbildend und unterliegen oft starken Ungenauigkeiten.

Ich lasse nicht diese ganze Diskussion, sondern nur den obigen Thread, den PerfektesChaos aufgemacht hatte. ʘχ (Diskussion) 20:31, 10. Nov. 2012 (CET)

... und der hier genau meine Meinung auch teilt, wie auch Arilou und viele Literaturquellen. Wer "ignoriert da wieder, was andere vorgebracht haben"? Du ignorierst "wieder", dass sich auch Begriffe und ihre Bedeutung 'entwickeln'. --VÖRBY (Diskussion) 07:40, 11. Nov. 2012 (CET)

Arilou ist deiner Meinung? Wieso schreibt er dann das hier? Ich bin auch der Meinung, dass das recht eindeutig "falsch" ist.

dass sich auch Begriffe und ihre Bedeutung 'entwickeln' Ja, wenn es denn so wäre! Aber die Begriffe, um die es hier geht, haben sich nicht weiter entwickelt, die haben immer noch dieselbe Bedeutung wie schon früher. ʘχ (Diskussion) 10:07, 11. Nov. 2012 (CET)

1. Begriffe werden in der Informatik nicht erst verwandt und dann gemäß der Verwendung definiert, sondern ERST definiert und dann verwandt. Ist das wirklich so schwer?
   • Au fein. Wir waren jetzt sehnsüchtig auf die Belegstelle, wo weltweit verbindlich für die gesamte IT die Begrifflichkeit definiert wird; mit Angabe des Zeitpunkts, ab dem nur noch diese Begrifflichkeit verwendet werden darf.
2. Informatik ist aber grundsätzlich eine exakte Wissenschaft
   • Die Gegenstände der Informatik sind exakt.
   • Die Begriffsbildung für neue Gegenstände ist aber ein sozialer Prozess und leitet sich von verbreiteter Verwendung her, insbesondere wenn anerkannte normative Dokumente dazu entstehen.
3. Aus der Tatsache, dass ich eine bestimmte "Begrifflichkeit" für korrekt erkläre (10:57, 7. Nov. 2012)
   • Das ist das Problem. Du erklärst eine Begrifflichkeit für korrekt. Heißt du ISO? Wo sind deine Belege? Inwiefern wären diese allgemeinverbindlich, falls existierend, und deklarieren sie als einzig möglichen Bedeutungen?
4. haben sich nicht weiter entwickelt, die haben immer noch dieselbe Bedeutung wie schon früher
   • Beleg? Dass sie „wie schon früher“ und Jahrzehnte zurück „immer noch dieselbe Bedeutung“ hätten?
5. Arilou zielte darauf ab, dass er die Verwendung für unangemessen hält.
   • Das ist etwas anderes als „Diese Verwendung hat niemals existiert.“; ersteres ist unproblematisch, das kann man ja so einordnen.
6. Zusammengefasst: Du hast selbst null Belege, löscht aber belegte Fakten.

--PerfektesChaos 10:30, 11. Nov. 2012 (CET)

Die Gegenstände der Informatik sind exakt. Nein, nicht alle. Ich habe nicht ohne Grund von denjenigen Teilen gesprochen, die erst noch exakt werden wollen.

Du erklärst eine Begrifflichkeit für korrekt. Heißt du ISO? Es sollte eigentlich klar sein, was der Satz bedeutet, den ich geschrieben habe. Wenn man etwas "erklärt", heißt das nicht, dass man es definiert.

Heißt du ISO? Schon wieder sowas Uninformatisches. Die ISO besitzt keinerlei Definitionsmacht in der Informatik. ʘχ (Diskussion) 10:49, 11. Nov. 2012 (CET)

Ich bin der Meinung, die synonymen Bedeutungen für prozedurale Programmierung müssen im Artikel bleiben, ein 'richtig' oder 'falsch' gibt es hier nicht. Für die Grundvarianten - a) Programmieren in Prozeduren b) imperativ / fortschreitende Befehle - lassen sich Hunderte von Belegen finden. Dritte Meinungen nachfolgende erwünscht.

• Diskussion beenden: --VÖRBY (Diskussion) 11:04, 11. Nov. 2012 (CET)

Die Unterscheidung von Programmiersprachen in imperativ und prozedural (u. a.) ist allgemein anerkannt. Und dieser Unterscheidung folgt auch die Wikipedia. Ein Professor hat das Wort jetzt anders benutzt (was soll egtl. dieses „John-von-Neumann-Prinzip“ sein?). Inwiefern ist das jetzt relevant? Dieser Artikel hier soll prozedurale Programmierung erklären, nicht Studien über Wortverwendungen anstellen. Prozedurale Programmierung und imperative Programmierung sind jedenfalls unterschiedliche Dinge, daran ist nicht zu rütteln. --Chricho ¹ ² ³ 13:40, 11. Nov. 2012 (CET)

Ist jetzt wieder der "Schatten" von Ox dran? Mit dem bekannten "Weil es so ist" - auch wenn hundert Quellen was anderes sagen. Wurde alles schon diskutiert - inkl. der Feststellung, dass es nicht um Pr-'Sprachen', sondern um 'ProgrammieRUNG' geht. Deshalb für mich EOD. --VÖRBY (Diskussion) 15:11, 11. Nov. 2012 (CET)

In einem Buch über Wirtschaftsinformatik stehen vollkommen unsinnige Einordnungen (was da über prozedurale und funktionale Programmierung steht ist grottig). Von 100en Quellen kann keine Rede sein. Ich habe das nun WP:NPOV folgend (Umgang mit Mindermeinungen) aus der Einleitung nach unten verschoben. --Chricho ¹ ² ³ 16:03, 11. Nov. 2012 (CET)

Hallo zusammen! Die Unterbringung des hier diskutierten Synonym-Hinweises unter 'Siehe auch' kann ein Kompromiss zur aktuellen Diskussion sein. Folgendes ist dabei jedoch zu beachten:

• Formal genügt dieser Textstring wohl nicht den Festlegungen für Links unter 'Siehe auch'. In anderen Fällen wurden solche Texte auf die darin genannten Lemmas reduziert - wodurch die beabsichtigte Wirkung verloren ginge. Vorausschauend wäre deshalb eine andere Textanordnung empfehlenswert.
• Durch die Verschiebung wird dem Wikipedia-Leser die Information vorenthalten, dass der Ausdruck 'prozedurale Programmierung' (pP) begrifflich auch mit weiteren Paradigma-Bezeichnungen gleichgesetzt oder verglichen wird.
• Der eigentliche Kern der hier geführten Diskussion war, ob oder dass pP in der Literatur auch als Synonym zu "imperative Programmierung" (bzw. diesem Paradigma sehr verwandt) bezeichnet wird.

Mein Fazit:

• Mit der letzten Artikelkorrektur kann diese Teildiskussion m.E. als abgeschlossen gelten.
• Der Artikel beschreibt nach wie vor (in der Einleitung und mit eigenen Hauptkapiteln), dass der Ausdruck 'prozedurale Programmierung' für zwei grundsätzlich unterschiedliche Bedeutungen verwendet wird. Dies wird im Artikel mit Einzelnachweisen belegt und entspricht dem Ergebnis der vorangegangenen Diskussionen.
• Ob dabei die Bezugnahme auf die OOP geschickt oder gar korrekt ist, will ich hier nicht nochmal erörtern; siehe dazu die Ursprungsdiskussion und diese nachfolgende Diskussion.

--VÖRBY (Diskussion) 10:20, 12. Nov. 2012 (CET)

.. folgt dem Programmablauf (auf) der Hardware?

Zuletzt wurde das 'auf' herausgenommen. Ob das korrekter ist, bezweifle ich, 'auf' war allerdings sprachlich auch nicht besonders elegant. Aber: Beide Sprachversionen sind m.E. falsch, denn die 'prozedurale Programmierung' FOLGT nicht dem Ablauf (auf/in) der Hardware, sondern sie ENTSPRICHT ihm vielleicht. Der Text will eigentlich (umgekehrt) sagen, dass der Programmierer (bzw. der Programmcode) festlegt, in welcher Folge die Befehle physisch ausgeführt werden. --VÖRBY (Diskussion) 18:04, 2. Dez. 2014 (CET)

• Erstmal würde ich als Formulierung gehen in Richtung:

  Während der prozedurale Ansatz den Abläufen in der Hardware ähnelt

• Gemeint ist aber etwas anderes:
  • Bei der sogenannten prozeduralen Programmierung haben die physischen Abläufe und die Programmiersprache die gleiche (elementare) Konzeption: Schritt für Schritt, Anweisung für Anweisung, Verzweigung hier wie da.
  • Bei objektorientierten und noch abstrakteren Programmierungskonzepten wird die Vorschrift für den Rechner in einer sehr viel abstrakteren und impliziteren Form ausgedrückt. Der resultierende Ablauf Schritt für Schritt, Anweisung für Anweisung ist nicht direkt ablesbar und wird erst generiert.

VG --PerfektesChaos 18:27, 2. Dez. 2014 (CET)

Ah, sorry, ich bin gerade meine BEO durchgegangen und habe diese Änderung revertiert, bevor ich die (jüngeren) Disk-Beiträge gesehen habe.

Die Formulierungsvorschläge von euch beiden können wir gerne weiter diskutieren. Allerdings ist es ein übliche fachsprachliche Bezeichnung, dass zB. ein Programm auf etwas (zB. auf einer bestimmten Hardware) ausgeführt wird. Das "auf" kommt daher, dass es nicht die (alleinige) Funktionalität der ausführenden Hardware ist, sondern diese eine Plattform für (verschiedene) Funktionalitäten/Programme bietet. Ohne das "auf" würde "die Programmierung der Hardware" folgen, da die Hardware aber mehr kann, als ein spezifisches Programm ausführen, ist das so nicht korrekt.--Plankton314 (Diskussion) 22:22, 2. Dez. 2014 (CET)