Anscheinend habe ich einen Teil des alten Beitrages mit dem neuen überschrieben, so dass der neue Beitrag teilweise doppelt auftauchte und der alte vollkommen unsinnig geworden ist. Ich habe den ursprünglichen alten Beitrag wieder hergestellt. Entschuldige bitte! Auch für die Vermutung, dass du dich nicht mit Fortran auskennst, möchte ich mich entschuldigen. Das sollte keine persönliche Beleidigung sein, sondern dir klar machen, dass wir unterschiedliche Sprachen gewöhnt sind und daher die Kommunikation einfacher fallen würde, wenn du versuchen würdest dich in einen Fortran Programmierer hineinzuversetzen, so wie ich versuche, mich in einen C/C++ Programmierer ?? hineinzuversetzen. Ich hatte das Gefühl, dass du meine Beiträge nicht versuchst zu verstehen...aber das gleiche Gefühl hast du anscheinend auch von mir und wir sollten nicht aggressiv werden. Ich stimme dir zu, dass diese Diskussion hier so nicht hingehört. Ich habe versucht, die Kritik an Python etwas besser auf den Punkt zu bringen, was aber durchaus so explizit (soweit ich weiß) nirgends steht. Es geht in der Wikipedia nicht um persönliche Meinungen, daher denke ich, dass wir uns recht strikt an Quellen halten sollten und etwa so etwas in den Artikel unter "Kritik" gehört: Das Verhalten beim kopieren von Daten wird als "ungewöhnlich im Vergleich zu anderen Programmiersprachen" kritisiert, was zu "verblüffenden und verwirrenden Erfahrungen" beim programmieren führen kann https://www.python-kurs.eu/python3_deep_copy.php. Zum Beispiel führt a=[1,2]; b=a; a[0]=0; zu b=[0,2]. Durch dieses Verhalten kann es auch zu ungewollten Seiteneffekten bei Funktionsaufrufen kommen https://www.python-kurs.eu/python3_parameter.php. Ich habe noch einmal mit Arbeitskollegen (meist promovierte theor. Physiker) geredet, die mir bestätigt haben, dass sie zu Beginn auch Programmfehler aufgrund des standardmäßigen flachen kopierens hatten und dies als deutlich unintuitives Verhalten ansehen. Dies ist eine konkrete, hilfreiche und von verschiedenen Seiten geäußerte Kritik, die den typischen Leser (wohl ein Python-Anfänger?!) des Wiki-Artikels interessieren wird. Zu deiner Antwort: Ja, es gibt auch in Fortran Pointer, aber diese gelten dort meist als unschön und sollten vermieden werden! Und ja, ich befürchte du hast recht: Ich hänge an den "alten" Programmierparadigmen der strikten Datenkapselung. Die Frage ist allerdings, ob hier "alt" nicht eher durch "vergessen" oder "vernachlässigt" ersetzt werden müsste. Aus meiner Sicht hat sich bezüglich Datenkapselung ein schlechter Standard durchgesetzt, der mit Python durch das standardmäßige flache kopieren aus reinen Performancegründen (was eigentlich nicht zu Python passt) noch ein Stück weiter heruntergezogen wird. Natürlich haben Sprachen die zum neuen Standard werden häufig weit mehr Vorteile als Nachteile, das sehe ich auch bei Python. Aber die Nachteile sollten klar kommuniziert werden! Was hat flaches kopieren mit Datenkapselung zu tun? Durch flaches kopieren b=a werden aus einer Variable a, über die der Programmierer auf EINEN Speicherbereich zugreifen kann, nun (standardmäßig) zwei Variablen a und b. Es wird doppelt so aufwändig nachzuvollziehen, was mit dem Wert auf dem EINEN Speicherplatz passiert und es kann eventuell von sonst vollständig unabhängigen Programmabschnitten auf den EINEN Speicherplatz zugegriffen werden. Solch eine fehlende Kapselung gibt es sonst nur bei Pointern die typischerweise speziell gekennzeichnet und behandelt werden (und natürlich ähnlich aber nicht so unübersichtlich bei globalen Variablen). Standardobjekte (wie arrays) zeigen typischerweise immer auf einen eigenen Speicherplatz (jedenfalls soweit der Programmierer das bei Kopiervorgängen usw mitbekommt). Was ich sagen will ist, dass Datenkapselung vermutlich DAS wichtigste Konzept neben der Vermeidung von GOTO usw ist um ein strukturiertes, wartbares und fehlerfreies Programm zu erstellen. Und dieses Konzept wird in modernen Programmiersprachen mit Füßen getreten und Kritik wird hier mit der Begründung abgetan: Das machen doch fast alle "modernen" Programmiersprachen so. Naja. --(nicht signierter Beitrag von 23:52, 5. Feb. 2018 (CET) )