Diskussion:Programmierparadigma

erster Satz...

Hallo, ich habe keine Ahnung von dem Thema, kann insofern inhaltlich nicht viel beitragen, aber nach dem ersten Satz (Programmierparadigma ist ein anderes Wort für Programmierstil.) fragt man sich als Laie doch, warum es dann zwei Artikel gibt. Und bei genauerem Hinsehen stellt man fest das in diesen auch noch ziemlich unterschiedliche Dinge stehen... Auch wenn dieser Satz als einziger im Artikel einen Einzelnachweis bekommen hat, macht er so für mich einfach mal gar keinen Sinn. Ich werd da nicht dran rumeditieren, ich wollte es nur angemerkt haben. -- kris242 16:29, 19. Aug. 2010 (CEST)

Der erste Satz ist definitiv falsch, auch wenn er von einem C++ Guru stammt. Ich lösche ihn mal. --Sebastian.Dietrich ✉ 21:07, 19. Aug. 2010 (CEST)

Es steht leider noch immer als erstes der Satz: "Ein Programmierparadigma ist ein fundamentaler Programmierstil." Das trifft den Kern nicht und ist in der Tat eher verwirrend als hilfreich. Ich habe keine "druckreife" Formulierung zur Hand, aber es geht bei der Frage nach dem Programmierparadigma vielmehr darum, mit Hilfe welches Grundprinzips man überhaupt einen Computer dazu bringt, eine bestimmte Aufgabe automatisch zu erledigen; bzw. auf Basis welches Funktionsprinzips eine Programmiersprache in ihren wesentlichen Grundzügen arbeitet. Man könnte es auch die Logik einer Programmiersprache nennen, wobei "Logik" hier in einem überaus allgemeinen, eher schon philosophischen Sinn gemeint ist. Man könnte es auch die Philosophie nennen, die eine bestimmte Programmiertechnik oder -methode ausmacht. Man könnte auch formulieren, dass eine bestimmte Programmierphilosophie von einer bestimmten Programmiersprache mehr oder weniger gut unterstützt wird. --michaelsy (Diskussion) 00:46, 8. Okt. 2014 (CEST)

Datenstromorientierte Programmierung?

Ich kenne von funktionalen Sprachen das Programmieren mit Streams, wobei hier eher unendliche Folgen gemeint sind. Liegt hier vielleicht eine falsche Deutung vor?

Wir haben jetzt eine wilde Liste, von denen einige Paradigmen sehr exotisch wirken. Vielleicht reift der Artikel ja noch..

--Marc van Woerkom 12:16, 10. Okt 2004 (CEST)

Nein, datenstromorientierte Programmierung ist ein eigenstaendiger Konzept mit eigenen Programmiersprachen; (nur) die einfachste Version liesse sich wahrscheinlich ziemlich einfach simulieren mit dem Programmieren mit Streams in funktionalen Sprachen. --132.231.54.1 20:53, 13. Aug 2006 (CEST)

Kategorien

Die Aufgliederung in sich gegeneinander ausschließende Paradigmen in der englischen Wikipedia: Programming paradigm finde ich wesentlich aussagekräftiger und sollte für die deutsche Seite übernommen werden. Die Kurzbeschreibungen gehören zu den Artikeln selbst.

was fehlt?

ich faende eine auflistung, wann welches paradigma definiert wurde ganz hilfreich (und welches paradigma welches abgeloest hat) Elvis untot 12:53, 1. Feb 2005 (CET)

Dem kann ich mich nur anschließen. Eine logische Darstellung erster Anfänge wie Prozudkonzept, Modulkonzept und ADTs bis hin zu modernen Ansätzen wie AOP sollte angestrebt werden. Die Wiederholung der Unterartikel empfinde ich als störend, vielmehr sollte das Wesen eines jeden Paradigmas durch die Entwicklung aus anderen und Abgrenzung gegen andere beschrieben werden. --guwac

Ich möchte noch anmerken, dass es dem Artikel eventuell guttun würde, wenn auch etwas zum modus der Entstehung dieser Paradigmen stehen würde. Im Moment ließt sich der Artikel so, als ob sich in der Informatik jemand ein konzept ausdenkt, dass er für toll hält und dann wild drauf los definiert, das kann es ja wohl nicht sein, oder??91.12.32.192 16:18, 13. Feb. 2008 (CET)

Alle Paradigmen in einem Artikel

Alle Paradigmen in einem Artikel erschöpfend behandeln zu wollen, ist unsinnig. Daher habe ich Links auf die Hauptartikel zu den jeweiligen Ansätzen eingebaut. In diesem Übersichtsartikel sollten nur kurz die wesentlichen Ideen der einzelnen Paradigmen beschrieben werden. --jpp ?! 09:38, 21. Feb 2006 (CET)

solange in denen nicht mehr drinsteht sind hauptartikel unsinnig. sonst gilt was guwac geschrieben hat. --141.35.17.32 21:28, 21. Feb 2006 (CET)

Das ist deine persönliche Meinung. Bevor du solche fundamentalen Änderungen durchführst und ganze Artikel durch Weiterleitungsseiten ersetzt, solltest du dich wirklich mit deren Autoren abstimmen. Dein Verhalten ist ziemlich unkooperativ, also wundere dich nicht, wenn deine Änderungen revertiert werden. „Mit dem Kopf durch die Wand“ ist keine Wikipedia-kompatible Kooperationsstrategie. --jpp ?! 09:15, 22. Feb 2006 (CET)

PS: Tut mir leid, dass ich dich als „Paradigmavandale“ bezeichnet habe, das war nicht angemessen.

ich muß jpp zustimmen. deine bemühungen in allen ehren aber solche umwälzungen ohne eventuelle rücksprache mit anderen hauptautoren vorzunehmen ist nicht im sinne der wikipedia. deine begründung „solange in denen nicht mehr drinsteht als im hauptartikel“ ist haltlos, da im konkreten fall (Deklarative Programmierung) einfach der inhalt in den hauptartikel kopiert wurde. gruß--Murkel ^(anmurkeln) 13:22, 22. Feb 2006 (CET)

tja dann rumquatschen kann ich auch woanders, ihr seid echt reaktionär. hab von 3 der 4 artikel selbst ein großteil bearbeitet, aber wenn euch was aufgeblasenes und inkonsitentes lieber ist.. ich lass es so, viel spass.

es ist schade, daß du bei dieser diskussion nicht sachlich bleibst. offensichtlich interessiert dich das themenfeld, warum baust du die bestehenden artikel nicht weiter aus? ab einer bestimmten größe macht es einfach keinen sinn, alles in einem hauptartikel zusammenzufassen. deine vorwürfe „rumquatschen“, „aufgeblasen“ bzw. „inkonsistent“ ignoriere ich einfach mal. sicher hast du bemerkt, das der artikel Deklarative Programmierung komplett von mir erstellt wurde. gruß --Murkel ^(anmurkeln) 15:03, 23. Feb 2006 (CET)

ja das scheint ein problem zu sein da es keinen eigenen artikel im jetzigen zustand rechtfertigt (auch wenn er von dir stammt), schau dir andere artikel an da wird auch nicht nei jeder unterüberschrift ein hauptartikel draus gemacht und hier wird halt semntisches zusammengefügt. und um paradigmen einheitlich darzustellen ist was zerpflücktes nicht geeignet, schließlich soll das hier ein lexikon sein und kein glossar für fachbegriffe? aufgeblasen = artikel doppelt. inkonsistent = resultat von aufgeblasen. mein anspruch ist zusammenhänge dargestellt zu bekommen /darzustellen und das nicht nur per Link. Nachtrag: quatschen = lieber über vorgehen reden statt inhalte liefern.

Ada / deklarative Programmierung

Zur Tabelle Programmierparadigmen (wie auch immer man sie aendert): Wodurch unterstuetzt Ada denn deklarative Programmierung? Ada ist doch rein imperativ, ohne funktionale, logische oder Constraint-Konzepte!? --132.231.54.1 20:59, 13. Aug 2006 (CEST)

OO vs. imperative Programmierung

Nachdem kürzlich ein Prüfling "Smalltalk" als Beispiel für eine imperative Programmiersprache aufgeführt hat und Wikipedia als Referenz aufgeführt hat, möchte ich anregen diesen Artikel wieder auf den Boden zu holen und den üblichen Sprachgebrauch hier wiederzugeben. --R.K.A.L. 18:29, 11. Mai 2007 (CEST)

Generell fehlen uns noch Einzelnachweise für die unterschiedlichen Definitionen. Wenn du da etwas liefern könntest, wäre dem Artikel sehr geholfen. Der „übliche“ Sprachgebrauch ist nämlich leider nicht belegbar und deswegen recht willkürlich auslegbar. --jpp ?! 21:58, 11. Mai 2007 (CEST)

In den Lehrbüchern, die ich verwende, wird die imperative Programmierung von der objektorientierten abgegrenzt (z.B. Applelrath:Skriptum Informatik. Teubner 1995). Mag sein, dass es mittlerweile andere Lehrbücher gibt, die das anders definieren, aber dann müsste in diesem Artikel stehen, dass es unterschiedliche Sichtweisen gibt. Die Objektorientierung grundsätzlich unter den imperativen Sprachen zu subsumieren halte ich für sehr gewagt (gelinde gesagt). --R.K.A.L. 23:19, 11. Mai 2007 (CEST)

Könntest du dann entsprechende Einzelnachweise in den Artikel einfügen? Das würde m. E. für mehr Objektivität im Artikel sorgen. Solche Klassifikationen sind nach meinen bisherigen Erfahrungen oft sehr beliebig, dennoch halte ich sie für sehr wichtig. Ich denke, dass die objektorientierte Programmierung mit der imperativen jedenfalls deutlich mehr Gemeinsamkeiten hat als mit der deklarativen (funktionalen). Habe allerdings leider momentan auch keine zitierfähigen Definitionen zur Hand. --jpp ?! 14:07, 12. Mai 2007 (CEST)

sehr guter Artikel

In meinen Augen ist das ein gelungener Artikel/Überblick. Bestimmt muss noch hier und da gefeilt werden, das müssen andere sagen, aber insgesamt => "lesenswert". IMO ist es eine Erwähnung wert, dass deklarative und OO Programmierung auf lange Sicht letztendlich imperativ sind (ähnl. Bradshaw zu autonomen Agenten)... 195.4.114.43 13:07, 9. Aug. 2007 (CEST)

Konsistenz?

Zitat 1: Pascal ist eine typische imperative Programmiersprache.

Zitat 2: Als die klassische strukturierte Programmiersprache gilt Pascal.

(nicht signierter Beitrag von 62.2.231.98 (Diskussion) )

Die IP hat da durchaus Recht. Ein besseres Beispiel für eine imperative Programmiersprache wäre eine nicht strukturierte, beispielsweise BASIC. --j ?! 10:06, 16. Mai 2008 (CEST)

Ich verstehe das Problem nicht: Bei Programmiersprachen hat imperativ und strukturiert sowenig miteinander zu tun, wie zum Beispiel die Farbe eines Fahrzeugs mit dessen Antriebstechnik. Mit anderen Worten: Pascal ist sowohl der Musterknabe einer imperativen, als auch einer strukturierten Programmiersprache, auch wenn die ursprüngliche Version bei weitem nicht mehr dem Stand der Technik entspricht. Eine der ersten und gleichzeitig sehr bekannten imperativen Programmiersprachen war FORTRAN. Eine der ersten strukturierteren Programmiersprachen war Algol 68, das aber wegen seiner technischen Unzulänglichkeiten keinen Bestand hatte. Nichtsdestotrotz war diese der Vorgänger von Pascal. Membeth 11:24, 16. Mai 2008 (CEST)

Das Problem besteht darin, dass die zurzeit aufgeführten Beispiele dem Leser nicht dabei helfen, zu verstehen, was strukturierte von imperativen Sprachen unterscheidet. Fortran wäre als Beispiel für imperative Sprachen auch geeignet, da es ebenfalls keinem der übrigen Paradigmen angehört. --j ?! 15:04, 16. Mai 2008 (CEST)

Ich hoffe, die Missverständnisse mit meiner Ergänzung und der Grafik in der Einleitung beseitigt zu haben: Aus Sicht einer Sprache (und auch eines Programms) sind die Paradigmen nicht disjunkt. --VÖRBY 09:20, 22. Apr. 2011 (CEST)

Widerspruch

unter imperativer programmierstil: "Pascal ist eine typische imperative Programmiersprache."

und dann noch mal unter strukturierter programmierstil: "Als die klassische strukturierte Programmiersprache gilt Pascal."

das sind auch keine teilmengen, weil imperativer und strukturierter programmierstil gegenseitig einschränkende punkte haben. vielleicht wäre besser: "Pascal eignet sich für das imperative/strukturierte Programmierparadigma" (nicht signierter Beitrag von Beinemann (Diskussion | Beiträge) 18:14, 10. Mai 2009 (CEST))

Dass die Paradigmen keine 'disjunkten' Begriffe sind und Programmiersprachen mehrere Paradigmen unterstützen können (und umgekehrt) ist im Einleitungskapitel beschrieben und auch grafisch erläutert.--VÖRBY 10:12, 13. Dez. 2011 (CET)

prozedurale / funktionale Programmierung

Die Aussage unter 'prozedural', der Unterschied zu 'funktional' sei 'kein Rückgabewert', halte ich für unhaltbar und inkonsistent: Ja, es gibt Quellen, nach denen 'Prozeduren' als 'Funktionen ohne Rückgabewert' definiert werden. Solche Festlegungen dienen dort aber lediglich definitorisch der Begriffsklarheit. Dagegen wird HIER im Artikel die 'funktionale Programmierung' als total anderes Paradigma definiert und deshalb auch - berechtigterweise - unter den deklarativen Paradigmen eingeordnet. Mir scheint, hier in den Artikeln dieses Fachgebiets ist Vieles durcheinander geraten; viele Köche verderben den Brei. --VÖRBY 09:51, 17. Mär. 2011 (CET)

Volle Zustimmung. Der Artikel Funktionale Programmierung stellt sich auch ganz anders dar als nur als "Programmieren mit Rückgabewerten". Ich vermute, dass man imperative Programmierung mit Funktionen auch prozedural nennen kann. Man kann auch mit Objekten strukturiert programmieren, ohne objektorientiert zu programmieren. Die verfügbaren Mittel erzwingen nicht das entsprechende Programmierparadigma. Bei der Quellenlage hier im Artikel muss man sich aber sowieso fragen, wieviel vom Artikel überhaupt zutrifft. Ist z.B. "Programmieren mit abstrakten Datentypen" wirklich ein Paradigma? --Zahnradzacken 19:10, 17. Mär. 2011 (CET)

Das werde ich also demnächst bereinigen. Magst Du vielleicht auch nochmal die beiden letzten Teilkapitel von Diskussion:Prozedurale Programmierung mit ansehen? Da gibt es auch gewaltige Diskrepanzen. Avron und Sebastian.Dietrich haben da schon mitdiskutiert. Ich hoffe, auch mit mehreren Autoren kommen wir da noch zu einer guten Lösung. Grüße von --VÖRBY 19:51, 17. Mär. 2011 (CET)

Paradigmen nicht disjunkt

Einige der vorangegangenen Diskussionen haben ihren Ursprung im Missverständnis, dass die Paradigmen nur "reinrassig" auftreten: In bestimmten Programmiersprachen oder in einem konkreten Programm. Dies ist jedoch nicht so. Ich schlage deshalb vor, den folgenden Text als Schluss der Einleitung einzustellen. Leider habe ich dazu nicht direkt eine 'Quelle', sondern fand entsprechende Aussagen fragmentarisch an vielen Stellen. Wenn das auch andere Autoren für gut finden, könnte 'man' den Text in den Artikel kopieren.

Die verschiedenen Paradigmen sind, bezogen auf einzelne Computerprogramme oder einzelne Codeteile, nicht als komplementäre bzw. alternative Programmierstile zu verstehen. Vielmehr ist - auch bei Nutzung nur einer (1) Programmiersprache - das Programmieren gleichzeitig nach mehreren Paradigmen möglich.

Beispiel: In einer unter MS Access und mit VBA entwickelten Anwendung werden die funktionalen Komponenten ereignis- und objekt-orientiert (Bsp.: open Formular X) angesteuert. Der VBA-Code ist modular, denn er besteht aus Modulen, Makros, Prozeduren etc. Da der Code 'Befehle' enthält, ist er imperativ. Und prozedural ist er, weil diese Befehle (innerhalb der Prozeduren ...) exakt in der codierten Folge ausgeführt werden. Die Formulare und Berichte sowie die SQL-Aufrufe sind deklarativ programmiert, weil hier nur das Was und nicht das Wie definiert wird.

Trotzdem werden Programmiersprachen häufig - nach ihrer Grund-Charakteristik - z. B. als objektorientierte, prozedurale oder deklarative Sprache bezeichnet. Die ein Paradigma bestimmenden Merkmale beruhen überwiegend auf den Eingenschaften der angewendeten Programmiersprachen (wie z. B. bei OOP, deklarativ ...), zum Teil aber auch auf dem individuellen Stil, der beim Programmieren praktiziert wird (z. B. strukturiert, modular, prozedural).

Erstellung:--VÖRBY 13:02, 17. Apr. 2011 (CEST), aktuell: --VÖRBY 12:50, 18. Apr. 2011 (CEST); Grafik hinzugefügt: --VÖRBY 18:49, 18. Apr. 2011 (CEST); Beispiel ergänzt: --VÖRBY 21:37, 18. Apr. 2011 (CEST); SQL ergänzt: --VÖRBY 08:51, 19. Apr. 2011 (CEST); umtexten: --VÖRBY 12:51, 20. Apr. 2011 (CEST)

Habe heute den Artikel entsprechend ergänzt; Grafik hier aus der Disk. entfernt.--VÖRBY 12:38, 21. Apr. 2011 (CEST)

Quellenangabe (für die Grundaussage, nicht für das Beispiel) ist zwischenzeitlich ebenfalls nachgetragen.
ERLEDIGT: --VÖRBY 10:06, 14. Dez. 2011 (CET)

Generative Programmierung?

Das ist ja wohl kein Paradigma im Sinne eines Programmierstils. Weg damit! (nicht signierter Beitrag von 141.64.14.10 (Diskussion) 12:50, 7. Nov. 2011 (CET))

Warum soll das kein PD sein? Ist ja wohl eine Variante von "fundamentaler Programmierstil". Und der Hauptartikel beschreibt das auch gut, wenn auch i.W. aus Sicht von Generatoren und als "Überbegriff". M.E. ist das nicht unpassend, wenn auch vielleicht nicht sehr bedeutend.

Wichtiger wäre m.E. ein Aufräumen bei den vielen Einträgen der ersten Kapitelstufe. Da könnte man doch sicher irgendwie Übergruppen bilden - was aber - bei den vielen Überschneidungen der einzelnen 'Paradigmen' - schwierig sein könnte. Kennt jemand eine wirklich systematische Darstellungsweise? Dabei sollten jeweils die KRITERIEN, die für ein bestimmtes PD gelten, deutlich sichtbar sein. --VÖRBY 16:42, 7. Nov. 2011 (CET)

Imperativ : Mikrocode etc

Im Kapitel 'Imperative Paradigmen' steht u.a.: „Durch den Mikrocode wird auf Prozessorebene angegeben, wie der Computer mit welchen Daten (die zu verarbeitenden Werte) zu verfahren hat. Dieses Konzept wird durch Befehle realisiert.“ Dies halte ich für zumindest missverständlich; denn wenn Mikrocode = Maschinencode ist, gilt dies für jede Art von Programm(ierung). Insofern kann das kein Merkmal für die iP sein. Besser wäre die Aussage, dass bei imperativer Programmierung der programmierte Code (Quelltext) vollständig die spätere Ausführungsfolge im Prozessor bestimmt ("First do this, then do that").
Dass die Programmiersprachen diese Architektur abbilden, scheint mir auch zweifelhaft; vielmehr es sind die damit geschaffenen Programme (als Quellcode verstanden).
Auch halte ich den Link auf Mikrocode für unglücklich: Darunter wird (lt Link) ein Spezialfall von Maschinencode (Festwertspeicher, Mikroprogrammierung, Mikrocodesimulator, EPROM, BIOS etc.) behandelt. 'Maschinencode' wäre wohl neutraler. --VÖRBY 12:27, 4. Dez. 2011 (CET) Das Sort-Beispiel passt m.E. besser in den Detailartikel als hierher.
Auch wäre zu überlegen, ob die rel. ausführliche Beschreibung zu von Neumann hierher passt oder besser in den Detailartikel.

Überhaupt halte ich es für sinnvoll, HIER im Überblick-Artikel nur einen kurzen Definitionssatz zu übernehmen und den Rest zu löschen; es existiert ja ein Verweis zum Teilthema (= 'Hauptartikel'). Das wurde auch bei den anderen Paradigmen so gehalten und minimiert das Risiko, dass die beiden Beschreibungen inkonsistent werden.
Meinungen dazu? --VÖRBY 12:59, 8. Dez. 2011 (CET), zuletzt: --VÖRBY 10:06, 13. Dez. 2011 (CET)

Kein Feedback; habe den Text gekürzt, die entfernten Details (z.T. fraglich, s.o.) gehören in den oder stehem im Hauptartikel - wie dies auch in früheren Disk.Punkten empfohlen wurde. --VÖRBY 14:06, 14. Dez. 2011 (CET)

Uneinheitliche Bezeichnungen

In Rahmen kürzlich erfolgter Diskussionen wurde festgestellt, dass in der Literatur die Paradigmen nicht einheitlich bezeichnet werden. Ich halte es deshalb für sehr zweckmäßig, im Einleitungsabsatz hierauf hinzuweisen. Zahlreiche Diskussionsbeiträge der Vergangenheit beruhen auf Missverständnissen, die auf diese Uneinheitlichkeit zurückzuführen sind. Empfohlener Ergänzungstext:

Hinweis: In der Literatur werden die Paradigmen nicht mit einheitlichen Bezeichnungen beschrieben. Zum Teil werden sogar Bezeichnungen verwendet, mit denen an anderen Stellen andere Paradigmen beschrieben werden. So etwa finden sich Veröffentlichungen für 'imperativ' u.a. mit den Bezeichnungen 'algorithmisch', 'prozedural', 'imperativ/prozedural' oder 'zustandsorientiert'; die Bezeichnungen 'strukturiert', 'prozedural' oder 'modular' werden zum Teil für identische Sachverhalte benutzt, ebenso z. B. 'deklarativ' und 'funktional'.

Erbitte Stellungnahmen dazu. --VÖRBY 14:45, 14. Dez. 2011 (CET)

...nur wenige Jahre später...: Grundsätzlich finde ich es immer gut, und auch in diesem Fall, darauf hinzuweisen, wenn Begriffe selbst in der Fachliteratur uneinheitlich definiert bzw. umschrieben werden. Den vorgeschlagenen Hinweistext finde ich für die Einleitung allerdings etwas zu umfangreich. In der Einleitung kurz den Umstand umreißen und weiter unten das Problem dann unter eigener Überschrift detaillierter beschreiben. Das wäre jedenfalls mein Vorschlag. --michaelsy (Diskussion) 12:59, 28. Mär. 2015 (CET)

Fehler im dritten Absatz

Der dritte Absatz lautet: Grundlegend für den Entwurf von Programmiersprachen sind die Paradigmen der imperativen und der deklarativen Programmierung. Beim letzteren sind als wichtige Ausprägungen die Paradigmen der funktionalen Programmierung und der logischen Programmierung zu nennen.

Müßte es nicht heißen: "Beim Ersteren ...", da funktionale und logische Programmierung imperative Paradigmen sind? --Weekeebit (Diskussion) 12:18, 6. Dez. 2012 (CET)

Kritik am Begriff der "deklarativen Programmiersprache"

Robert Harper schrieb kürzlich zum Begriff "deklarativ":

"The term "declarative" never meant a damn thing, but was often used, absurdly, to somehow lump together functional programming with logic programming, and separate it from imperative programming. It never made a lick of sense; it's just a marketing term."

Gibt es dazu schon in irgendeinem Artikel einen Abschnitt über diese Kontroverse? --Mitja 42? 14:10, 26. Apr. 2013 (CEST)

Ich denke nicht & wenn dann brauchts mehr als eine Mail von Robert Harper um etwas als Kontroverse in eine WP Artikel einzutragen. --Sebastian.Dietrich ✉ 17:42, 26. Apr. 2013 (CEST)

Subjektorientierte Programmierung

Noch nie gehört und unbequellt. Google hat dazu gerade mal 1.620 Treffer, die meisten davon aus Übersetzungsprogrammen. Interessant sind [1] und [2]. Ob das aber jemals aus den IBM Labors rausgekommen ist wage ich zu bezweifeln. --Sebastian.Dietrich ✉ 17:50, 26. Apr. 2013 (CEST)

Habs jetzt (nach 9 Jahren) entfernt... --Sebastian.Dietrich  ✉  09:01, 26. Sep. 2022 (CEST)

Prozedurale Programmierung: Die gab es auch im Assembler bzw. im Maschinencode

Ich finde, dieser Satz hier "Die Entwicklung prozeduraler Programmiersprachen und -techniken waren ein wesentlicher Schritt zwischen Assemblersprache und Hochsprachen, ..." hört sich so an, als wollte man sagen, dass der Schritt VON Assembler hin zu gewissen Hochsprachen erst die prozedurale Programmierung ermöglichte. Vielleicht nur schlecht ausgedrückt, auf jeden Fall ist das ja falsch. Ob Commodore Maschinencode oder was auch immer: Subroutinen aufrufen und mit RET zurück springen ist ja genau das. Der einzige Unterschied zwischen ASM und z.B. C: Die Parameter-Übergabe muss per Vereinbarung über Register oder dem Stack erfolgen, Rückgabe erfolgt auch z.B. über Register.

Ich versuche einen Gegenvorschlag:

Die Entwicklung prozeduraler Programmiersprachen und -techniken waren ein wesentlicher Schritt in Hochsprachen, indem sie Abstraktion und Zerlegung von Algorithmen ermöglichen. Im einfachsten Fall kann auch in Assemblersprache eine Unterroutine per Namen aufgerufen werden und in Maschinencode per Adresse, aber die Verwendung des Begriffs prozedurale Programmierung ist nur bei Hochsprachen üblich.

--212.8.151.116 23:39, 16. Nov. 2024 (CET)

+1 --Sebastian.Dietrich  ✉  08:45, 17. Nov. 2024 (CET)