Benutzer Diskussion:PaterMcFly/Vergleich objektorientierter Programmiersprachen

Dekorator-Pattern

Kann mir bitte mal jemand erklären, warum bei C++ steht, Dekoration ginge nicht? Dekoration ist ein objektorientiertes Entwurfsmuster, keine Eigenschaft der Sprache, und es reicht wenn die Sprache Polymorphie und Vererbung beherrscht. Ich kann gerne das C#-Beispiel im entsprechenden Artikel nach C++ konvertieren. --Kilessan 22:18, 28. Sep. 2007 (CEST)

Ich habe im Decorator-Artikel ein C++-Beispiel eingefügt. Ich wage zu behaupten daß ich auch in objektorientiertem Pascal ein Beispiel finden kann (wobei das eigentlich sinnlos ist aufgrund der vielen Dialekte, siehe Free Pascal, Delphi etc.). Da Dekoration wie gesagt lediglich ein objektorientiertes Entwurfsmuster ist und keine "Eigenschaft" der Programmiersprache, ist der Vergleichspunkt aber wertlos. Es sei denn eine Sprache böte besondere Unterstützung für Dekoration, und das ist zumindest weder in Java noch C++ noch C# der Fall. Schlage hiermit vor, zumindest den Punkt "Dekoration" ersatzlos zu streichen. --Kilessan 16:39, 29. Sep. 2007 (CEST)

Guter Punkt. Ich würde diesen Eintrag auch streichen. --PaterMcFly _Diskussion ^Beiträge 17:04, 29. Sep. 2007 (CEST)

Parameterübergabe bei Java

Hm, Objekte werden bei Java nur über Objektreferenzen angesprochen. Okay, diese Referenzen werden nun als "Wert" übergeben. Trotzdem modifiziert man ja das Ursprungsobjekt über diese Referenz, was viele Java-Neulinge verwirrt. Ich denke, da fehlt eine klärende Fußnote: "Objekte stets über Referenzparameter, Primitive stets über Wertparamater". Was denkst du? --RokerHRO 09:44, 30. Mär 2006 (CEST)

Eine solche Formulierung stünde in Widerspruch mit der Java Language Spec. Aber ich bin mir sicher, dass wir eine gute Formulierung finden werden. --ChristianHujer 23:52, 30. Mär 2006 (CEST)

Die Mißverständnisse entstehen durch die informelle Benutzung des Begriffs "Referenz" C++-Referenzen haben mit den Java-Referenzen gemeinsam, daß Änderungen am referenzierten Objekt auch im Kontext des Aufrufers sichtbar sind. Das gilt auch für Änderungen an primitiven Daten, was aber nicht vergleichbar, weil in Java unmöglich ist. Ändert man die Referenz selber, so ändert sich im Kontext des Aufrufers nichts, was aber wiederum nicht vergleichbar, weil diesmal in C++ unmöglich ist.

C/C++ Pointer dagegen sind ein eigener Datentyp, den man gar nicht heranziehen sollte, weil es ihn in Java sowieso nicht gibt. Einen Pointer kann man selbst ebenfalls entweder per Referenz oder per Value übergeben, was für das durch den Pointer referenzierte Objekt keinen Unterschied macht. Nur für den Pointer selber, den man dabei als primitiven Datentyp betrachten sollte.

Erwähnen sollte man hier, daß es in Java ein null-Objekt gibt, das nicht mit C++-NULL-Pointern verglichen werden kann, auch wenn es eine Java-Exception mit einem entsprechenden irreführenden Namen gibt. C++-Referenzen können nicht auf ein solches kanonisches Objekt gesetzt werden, das zu jedem Referenz-Typ kompatibel wäre.

Referenzen in Java sind eher mit Zeigern in C/C++ verwandt, als mit Referenzen in C++. Es ist ein weit verbreiteter Denkfehler, C++-Referenzen als C++-Äquivalent zu Java-Referenzen anzusehen. In C++ sind Referenzen einfach nur Aliasnamen, mehr nicht.

Im Übrigen ist es sehr wohl möglich, eine Referenz auf "Adresse nirgends" (also die Adresse, auf die ein Nullzeiger zeigt) anzulegen:

void foo(Foo* f) { Foo& fr = *f; fr.blub(); }. Wenn man nun foo(0) aufruft, wird die Funktion einen segfault auslösen, sobald sie versucht, auf fr.blub() zuzugreifen, da fr auf einer illegalen Adresse liegt. --RokerHRO 14:26, 13. Jun 2006 (CEST)

Es geht nicht darum, ob man C++ dazu bringen kann, einen SegFault zu produzieren. Das ist wohl zu einfach. Und runtime-typecasts mit einem Java-null Objekt erzeugen keine exceptions oder gar SegFaults.

Ja, C++ Referenzen kann man als Aliasnamen auffassen, auch wenn das bei einem übergebenen Parameter nicht wirklich hilfreich ist. Aber wieso sollte man Referenzen in Java anders auffassen? Beides sind handles (um mal ein anderes, nicht vorbelastetes Wort zu verwenden) zu einem Objekt. Und welche pointer-Operation kann man mit Java-Referenzen durchführen, die mit C++-Referenzen nicht geht (außer den erwähnten re-assignment oder der null Referenz)?

letztendlich ging es um die Frage ob es sich um call-by-value oder call-by-reference handelt. Und die kann man eigentlich nur an den entscheidenden Fragen festmachen: Gibt es ein referenziertes Objekt(im weiteren Sinne)? und Kann man am referenzierten Objekt Änderungen, die in einem weiteren Scope als dem der lokalen Referenz-Variablen sichtbar werden, durchführen?

---

Referenz oder nicht Referenz - wenn man von Java spricht, und meint dass Objekte über Referenzen addressiert werden, meint man einfach, dass die Variable Object o = new .... die Referenz auf die Instanz enthält. D.h. irgendwoanders ist dann noch Speicher fuer die Objekt-Daten selbst reserviert wurden. Des weiteren kann man dann noch die Parameterübergabe bei Java-Methoden betrachten - und man wird feststellen, dass diese sich in Java ausschliesslich wie call-by-value Aufrufe verhalten. D.h. ich kann NICHT eine Referenz auf eine Variable uebergeben. Dass diese Variable allerdings selbst eine sog. Referenz auf ein Objekt sein kann (was sie in Java in den meisten Fällen sein wird) ist ein anderes Thema - diese Objekt-Referenz ist in Java nicht änderbar - was ja das Wesen eines call-by-ref Aufrufs darstellen wuerde -> also NICHT Möglich.

---

Wenn man mit der Unterscheidung von call-by-value und call-by-reference nicht diese Fragen beantworten kann, ist sie akademisch, bzw. eigentlich sinnlos. Egal, wie es in einer Spec definiert wurde.

---

Die Parameterübergabe ist immer ein Wertparameter und nie ein Referenzparameter. Auch wenn es den Anfänger irritiert, in der Wiki sollte nichts falsches stehen. --Grim.fandango 11:34, 26. Jan. 2007 (CET)

Man kann bei Java aber keine Objekte als Wertparameter übergeben, nur Objektreferenzen. Ob man das nun als "Referenz, die als Wert übergeben wird" oder als "Objekt, das als Referenzparameter übergeben wird" bezeichnet, ist sophistisch und bringt uns hier nicht weiter. Ein Objekt aber als Wertparameter an eine Funktion zu übergeben, ist bei Java nicht möglich, ebensowenig, wie man einen primitiven Datentyp als Referenzparameter übergeben kann. --RokerHRO 16:45, 26. Jan. 2007 (CET)

Es ist wichtig, zu wissen, das die Referenz als Wert übergeben wird bzw. das alles als Wert übergeben wird. Würde Referenzübergabe möglich sein, könnte man auch Referenzen als Referenz ("Zeiger, der auf einen Zeiger zeigt") übergeben, so wie das bei C++ oder früher bei Turbo-Pascal der Fall ist. Damit lassen sich einige Zeilen an Programmcode einsparen, auch wenn es für Anfänger unverständlicher wird. Deinem letzten Satz stimme ich zu, Objekte direkt als Wert geht nicht. --Grim.fandango 17:02, 26. Jan. 2007 (CET)

Präprozessoren für Java

Zur eigentlichen Sprachdefinition von Java gehört kein Präprozessor. Man kann dieses Feature - wie so oft - natürlich über Zusatzsoftware nachrüsten. Die Aufzählung, mit welcher Software man welches Sprachfeature nachrüsten kann, würde IMHO aber zu weit führen. Oder aber man fügt bei jeder Fußnote an, mit welcher Software man welches Feature nachrüsten kann. :-/ --RokerHRO 09:49, 30. Mär 2006 (CEST)

Sämtliche Software wohl nicht, aber ich denke, dass es schon hilfreich ist, wenn die Leser zumindest auf die am häufigsten eingesetzte Software hingewiesen werden. Als Java-Präprozessor wäre das Velocity (hehe, hab's gemerkt, der Link war peinlich falsch ;-), und als C/C++-Dokumentationswerkzeug wäre dass Doxygen - zumindest meines Wissens nach. --ChristianHujer 23:53, 30. Mär 2006 (CEST)

Also für meinen Geschmack sind das eh schon zu viele Fußnoten. Es läuft offenbar wirklich darauf hinaus, daß zu jedem Sprachfeature eine Fußnote kommt, die auf die Möglichkeit einer Nachrüstung hinweist. Entweder diese Seite dient dem Vergleich der Programmiersprachen oder einer Anhäufung von Beispielen für die triviale Erkenntnis, daß man jedes Feature mit mehr oder weniger Aufwand in jeder Programmiersprache nachbilden kann.

Wo wir schon bei den Fußnoten sind:

Die wenigen Fußnoten, die nicht "kann über xyz nachgerüstet werden" lauten, sollten vielleich auch nochmal überdacht, wenn nicht sogar weggelassen werden:

1: Referenzvariablen werden bei C als Zeiger übergeben, bei C++ existieren zusätzlich separate Referenz-Typen Wieso wird hier erwähnt, was in C gemacht wird, wenn es um C++ geht? In C++ lautet die Empfehlung, Referenzen zu benutzen, wo Referenzen gemeint sind, also insb. bei call-by-reference. Pointer dagegen da, wo wirklich manuelle Speicherverwaltung oder Pointerarithmetik (für hartgesottene) gemeint sind.

4: Es existieren betriebssystemspezifische Funktionen zum dynamischen Linken zur Laufzeit Das statische Linken ist genauso plattformspezifisch. Nirgendwo wird eines von beiden erzwungen. Wenn es dagegen um die Frage der frühen oder späten Bindung geht, wird diese ja schon bei "Polymorphie" beantwortet. Damit erledigt sich dann auch Fußnote 6, die einen Nachtrag zu objektive-C darstellt, der ohne Fußnote komplett falsch wäre, mit Fußnote dagegen einen Unterschied zwischen Sprache und Standardbibliothek macht, der bei Java dagegen nicht gemacht wird.

Java Abstammung

Stammt Java wirklich von C++ ab? Die Gemeinsamkeiten von C sind natürlich klar sichtbar. Aber welche Gemeinsamkeiten mit C++ gibt es? Sowohl auf syntaktischer, als auch auf semantischer Ebene unterscheiden sich beide Programmiersprachen.

Außerdem sollten wohl Simula und Smalltalk in der Auflistung nicht fehlen. Immerhin sind das die Ursprungs OOP Sprachen. --Kingruedi

Ich habe mich dabei nach den Angaben im Artikel Java (Programmiersprache) gerichtet: "Sun hat sich jedoch für die C++-Syntax entschieden und gleichzeitig verlauten lassen, Java würde von C++ abstammen." und "Java lehnt seine Syntax an die der Programmiersprache C++ an.". --Florian Keßeler 15:51, 30. Mär 2006 (CEST)

Gemeinsamkeiten zw. Java und C++ sind so Schlüsselworte wie "class", "public", "protected", "private", "new"; die Tatsache, dass Konstruktoren wie die Klasse heißen; die Freiheit, Variablen überall in einem Block definieren zu können und sicher noch einiges mehr. --RokerHRO 22:00, 30. Mär 2006 (CEST)

Vielleicht sollten wir zwischen syntaktischer und semantischer Abstammung differenzieren. --ChristianHujer 23:54, 30. Mär 2006 (CEST)

Ist zwar eine gute Idee, aber ich glaube, dass man das an einigen Punkten nicht ganz sauber trennen kann. Objective-C zum Beispiel erbt Semantik und Syntax gleichermaßen von C und Smalltalk (C-Syntax und Semantik: alles außer Nachrichten und Klassendeklaration/definition, Smalltalk-Syntax und Semantik: Nachrichten und Klassendeklarationen/definitionen) --Florian Keßeler 00:53, 31. Mär 2006 (CEST)

Speichermanagement

Die Unterscheidungskriterien "Objekterzeugung" und "Objektzerstörung" halte ich schon vom Namen her für nicht gelungen. Zum anderen kommt hinzu, daß die resultierende Einteilung Begriffe wie Stack und Heap benutzt, die nicht nur nicht erklärt werden, sondern auch im jeweils anderen Kontext etwas anderes bedeuten können.

Zur Vereinfachung kann man sagen, daß Java und C# ein Speichermanagement besitzen, das sich um den Speicherort und auch den Zeitpunkt der Freigabe selbst kümmert und (zumind. bei Java) auch einen manuellen Einfluß des Programmierers ausschließt. Daß dieser verwaltete Speicher auch oftmals heap genannt wird, ist ein technisches Detail, das hier nicht weiter hilft und deshalb wegfallen sollte. Garbage Collection ist nur ein Aspekt des Speichermanagements und in der meist damit assoziierten Form (mark-sweep) ein Implementierungsdetail. Theoretisch könnte ein Speichermanager auch einen Objekt-Stack besitzen, wenn er in der Lage ist, durch Code-Analyse geeignete Objekte mit begrenzten Scope zu finden.

Dagegen setzen kann man, daß C++ manuelle Speicherverwaltung besitzt, bei der der Programmierer entscheiden muß, ob ein Objekt sofort beim Verlassen des Variablenscopes (Stack-Variablen) oder explizit zu einem vom Programmierer selbst bestimmten Zeitpunkt (heap-Variablen) freigegeben werden sollen.

Wenn man stack und heap an diesen für den Programmierer wesentlichen Kriterien erklärt, wird auch klar, warum es kontroproduktiv ist, bei Java oder C# von einem heap zu sprechen.

Stimmt. Insbesondere legt der ISO-Standard von C++ gar nicht fest, wo der Speicher für Variablen angelegt werden soll. Er trifft nur Aussagen über die sogenannte Lebensdauer von Variablen (static, automatic und dynamic storage duration). Für eine effiziente Implementierung ist damit auf den meisten Rechnerarchitekturen der Speicherort klar, aber das ist eine Eigenschaft dieser Architekturen. Mir sind auch keine praktisch relevanten Architekturen bekannt, die das anders implementieren, aber IMHO ist das trotzdem keine Eigenschaft der Sprache, sondern ihrer Implementierungen. Es mag pedantisch klingen, aber ich unterscheide da nunmal recht genau. --RokerHRO 09:56, 16. Mär. 2008 (CET)

Andere Sprachen

Wieso werden hier nur die Sprachen C#,C++,Java und Objective-C angesprochen? Wie diese Liste zeigt gibt es bei weitem mehr solcher Sprachen, die zum Teil auch stärker verbreitet sind als das aufgeführte Objective-C. Ich denke da beispielsweise an Delphi, Python, PHP5, VB, ... Außerdem finde ich die Aneinanderreihung der ganzen "?" bei C# lächerlich. Wenn über diese Sprache so wenig bekannt ist, sollte sie nicht angeführt werden, bzw. erst nach ausreichender Recherche eingefügt werden. -- 129.27.157.24 10:02, 29. Jun 2006 (CEST)

{{NurListe}}

Es ist richtig, dass eine Liste oder Tabelle allein keinen Artikel ersetzen kann. In diesem Falle soll die Tabelle auch keinen Artikel ersetzen, sondern mehrere Artikel ergänzen, um dort unnötige Wiederholungen zu vermeiden. Man könnte daraus auch eine Vorlage machen und diese in die betreffenden Programmiersprachen-Artikel einfügen. Aber das bläht jene Artikel nur weiter auf.

Auch in gedrukten Enzyklopädien werden gewisse Sachverhalte oft in Form einer Tabelle übersichtlich dargestellt und diese auf Tabelle dann von einzelnen Artikeln aus verwiesen. Bisweilen finden sich sogar ganze Tabellenwerke im Anhang oder Ähnliches. Ich sehe also kein Problem, warum man keine solchen "nur-Tabellen"-Lemmata in der Wikipedia gestatten sollte.

Die Vorlage {{NurListe}} bezieht sich auf Artikel-Stubs, wo Fakten in einer Liste aufgezählt werden, welche besser zu Sätzen ausformuliert werden sollen. Dies ist bei einer Übersichtstabelle wie in diesem Lemma aber nicht der Fall. Ich habe den Baustein daher wieder entfernt.

--RokerHRO 12:25, 30. Jul 2006 (CEST)

Stimme voll überein. Deshalb hatte ich ihn auch schon entfernt. --Florian Keßeler 15:04, 30. Jul 2006 (CEST)

Java

Hallo,

ich hätt ein paar Anmerkungen zu Java

Also Klassenobjekte gibt es in Java durchaus ( http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#getClass() )

--- Das was man z.B. in Delphi als "Klassenobjekte" versteht gibt es in Java nicht. Nämlich sog. Metaklassen deren Variablen ***typensicher*** Klassen aufnehmen koennen und zudem zum Erzeugen von Instanzen der in dieser Variable liegenden Klasse benutzt werden koennen -> ganz ohne Reflection.

Sicher nicht leicht zu verstehen wenn man sowas noch nicht gesehen oder verwendet hat. Das wird wohl in eine ähnlich Sinnlose Diskussion ausarten wie weiter oben die verwirrwitzte Diskussion um "Referenzen" in Java. Da wird der Begriff Referenz aus ganz unterschiedlichen Kontexten (?) vermischt.

Steffen ---

Dynamisches Binden: Bei Java wird immer dynamisch gebunden(es wird immer die Methode des Objektes aufgerufen), es sei denn eine Methode wird als static deklariert, oder sie wird als final deklariert (bzw. die Klasse), welches das Überschreiben dieser Methode an sich unterbindet.

Ich denke auch, es wäre beim Vergleich zwischen Programmiersprachen interessanter, deren besondere Vorzüge und Nachteile kennenzulernen, statt zu wissen, ob sie z.b. Key-Value-Observing erlauben.

DoxyGen nicht Bestandteil der Sprache

Der C++-Standard definiert keinen Dok-Standard (von Kommentarzeichen mal abgesehen ;-) ); so gut DoxyGen als Tool auch sein mag, tendiere ich dazu, an dieser Stelle C++ ein klares Nein zu verpassen. Was meint Ihr ?

Dann müsste man Objective-C erst recht ein klares Nein verpassen (überhaupt ist die Frage, was diese Sprache hier soll). Im Prinzip muss man aber sagen, dass auch bei Java und C# die Dok-Systeme nicht direkt zur eigentlichen Sprache gehören, wenn auch das Dok-System bei Java viel näher bei der Sprache ist. Bei C# kann ich es nicht beurteilen. Es ist halt die Frage, wie die Zeile gemeint ist. (a. Es existiert ein Dok-System; b. ein Dok-System gehört zur Sprache). Mein Vorschlag: Ich würde das "ja" in dieser Zeile weglassen, dann bei C++ und Objective C ein "z.B." davorsetzen, da es kein eigentliches Dok-System gibt. Etwas irreführend finde ich auf die Verlinkung von Dokumentationssystem. Dieser Artikel hat IMO nichts mit dem hier dargestellten Sachverhalt zu tun. --Cactus26 09:54, 27. Jul. 2007 (CEST)

Unter Pascal steht noch vieles Falsch

Meta-Daten und Programmierung ist auch unter Objekt-Pascal (Delphi) schon seit jeher (eingeschränkt) möglich. Bei anderen Sprachen ist man mit dem Zusatz "eingeschränkt" ja auch nicht zimperlich. Ebenfalls die Mehrfachvererbung -> für Interfaces funktioniert das auch unter Delphi (Object-Pascal). Weiterhin das Überladen von Methoden ist mindestens seit Delphi version 4 auch möglich. Selektoren (Methodenzeiger ?) gibt es ebenfalls in Delphi (Object-Pascal) .. und und und .. man kann sogar Methoden ueber ihren Namen aufrufen was rudimentär wie Reflection anmutet ... aber da besteh ich nun nicht drauf :o)

Delphi ist nicht Pascal. Die Borland-Pascal-Varianten (wozu auch Delphi) gehört, enthalten teilweise massive Erweiterungen gegenüber der ursprünglichen Pascal-Variante. Was hier steht ist daher eigentlich schon fast einen Schritt zu weit, es beschreibt in etwa den Stand von Borland Pascal 7, das in etwa der Verbreitendste Pascal-Dialekt war. Pascal (in der Urform nach Niklaus Wirth) selbst kennt grundsätzlich überhaupt kein OO, also auch keine Vererbung etc. Ich habe diese hier trotzdem aufgeführt, weil sie heute in fast allen Pascal-Dialekten (Delphi, Oberon usw) eingesetzt werden. Aber vielleicht zeigt sich hier ein grosses Problem von Pascal: Es wurde (im Gegensatz zu C oder C++) nie standardisiert und hat sich daher in verschiedene Richtungen weiterentwickelt. Borland war dabei klar die treibende Kraft, aber eben inoffiziell. So ist die Sprache an der ETH Zürich, wo sie herkommt, mit Oberon weiterentwickelt worden, das einige paralellen zu Borland Pascal aufweist, sich aber in anderen Punkten massiv unterscheidet. --PaterMcFly _Diskussion ^Beiträge 18:36, 8. Jan. 2008 (CET)

Klassenbaum

Bei den Fußnoten steht "C++ erlaubt Polymorphie nur innerhalb des Klassenbaumes und weist bereits zur Übersetzungszeit einen Methodenindex zu." Was ist damit gemeint? --Nowgorod 05:26, 16. Mär. 2008 (CET)

Vielleicht, dass bei C++ die Vererbungshierarchie zur Übersetzungszeit feststeht und man diese nicht zur Laufzeit ändern kann, etwa die Vaterklasse austauschen oder Methoden hinzufügen oder sowas. – Sowas geht meines Wissens aber bei Java z.B. auch nicht (ich lasse mich da aber gerne eines besseren belehren). --RokerHRO 09:46, 16. Mär. 2008 (CET)

QS nach LA

Nachdem der LA nun abgewendet wurde, sollten wir die Tabelle grundlegend überarbeiten, denn die im LA genannten Löschgründe sind ja doch als Kritikpunkte an dem Artikel weiterhin relevant.

Meine Vorschläge:

1. Welche Sprachen sollen denn miteinander verglichen werden? Wirklich nur OO-Sprachen? IMHO wäre es schon sinnvoller, miteinander verwandte Sprachen zu vergleichen, da man so sehr schnell z.B. die Unterschiede zw. C und C++ und Java (um mal eine Auswahl zu nehmen) erkennen kann. Natürlich müsste das Lemma dann ggf. umbenannt werden, wenn wir nicht-oo Sprachen mit aufnehmen, aber das ist ja das kleinere Übel, denke ich.
2. Die "Sprachelemente" (wer findet einen bessren/passenderen Begriff dafür?) sollten vor der Tabelle kurz erklärt werden, damit klar ist, was genau damit gemeint ist. Ein bis zwei kleine Sätze zu jedem Begriff können sicher nicht schaden, wenns mehr dazu zu sagen gibt, sollte es ja einen eigenen Artikel dazu geben, auf den dann verwiesen wird.
3. Sämtliche Aussagen sollten mit Quellen belegt werden, etwa über die Kapitel/Abschnittnummer im Sprachstandard
4. Zu schwammige Kategorien wie "Einflüsse" sollten entweder präzisiert oder aber gelöscht werden.
5. Insbesondere bei dem Stichpunkt "Dokumentationssystem" gab es hier ja schon kontroverse Diskussionen. Ich denke, bei diesem und bei anderen Punkten sollte unterschieden werden, ob dieses Feature zwingend zum Sprachstandard gehört oder optional ist oder über Fremdsoftware nachgerüstet werden kann. Ein simples "Ja"/"Nein" ist da zu unklar.

Was denkt ihr? --RokerHRO 00:00, 29. Mär. 2008 (CET)

Den Punkten kann ich zustimmen.

Zu 1: Dazu müssten dann aber vermutlich mehrere Tabellen her. Etwa eine, die die "alten" Sprachen C, Cobol, Fortran, Pascal (Lisp, Prolog??) miteinander vergleicht, und eine, die sich auf OO-Features beschränkt und dann C++, Java, C# etc. enthält. Die modernen Web-Sprachen Perl, PHP etc. sollten auch nicht vergessen werden (da habe ich allerdings zuwenig Ahnung von).

Zu 2: Das muss vielleicht präzisiert werden, aber die meisten dieser "Sprachelemente" (nein, fällt mir auch im Moment nichts besseres ein), haben ja einen eigenen Artikel, wo es erklärt wird.

Zu 3: Währe gut, ist aber vermutlich schwierig, da es z.B. für Pascal gar kein Sprachstandard-Dokument gibt.

Zu 4: Das halte ich für lösbar, ja.

Zu 5: Und noch ein paar Fussnoten - gibt ja fast keine in diesem Artikel ;-)

PS: Habe zur einfacheren Referenzierung mal Nummern davor gesetzt--PaterMcFly _Diskussion ^Beiträge 09:53, 29. Mär. 2008 (CET)

Linken

Diese "Eigenschaft" hat meiner Meinung nichts mit der Programmiersprache zu tun. Hängt doch eher vom Compiler bzw. Linker ab. Java kann ich mit einem nativen Compiler doch auch zur "Compilezeit" (auch eine nicht besonders treffender Begriff) möglich, oder? --Thornard, ^Diskussion, 18:33, 30. Mär. 2008 (CEST)

Grundsätzlich gebe ich dir recht, es ist ein Compiler- und kein Sprachfeature. Eigentlich müsste man genauer sagen: Ein Feature des Laufzeitsystems, nicht der Sprache. Einige Sprachen (darunter Java und C#) sind aber ziemlich eng an ihr Laufzeitsystem gebunden. In die gleiche Kategorie gehörte nämlich zum Beispiel auch die Garbage-Collection. Die Frage wäre, ob die Sprache erzwingt oder zumindest empfielt, dass das Laufzeitsystem das Feature unterstützen sollte. Bei C# ist es eigentlich Teil der Sprache, dass (mittels Reflection), dynamisch Module hinzugeladen werden, daher muss das Laufzeitsystem dynamisches Binden erlauben. Bei Java bin ich nicht sicher. --PaterMcFly _Diskussion ^Beiträge 19:59, 30. Mär. 2008 (CEST)

Nein, das stimmt so nicht. Eine Sprache kann von sich aus (also im Sprachkern bzw. ihrer Standardbibliothek) Unterstützung für dynamisches Binden mitbringen oder eben nicht. C und C++ bringen so etwas nicht mit, dass das über betriebssystemabhängige Bibliotheken trotzdem geht, ist dabei nicht von belang, da das eben nicht zur Sprache gehört. Siehe obigen Punkt 5 meiner Kritikliste. :-) --RokerHRO 22:45, 30. Mär. 2008 (CEST)

Dynamisches Binden

IMHO ist das eine Eigenschaft sämtlicher Sprachen, die (Laufzeit-)Polymorphie beherrschen, oder sehe ich das falsch? Es geht daher aus der Eigenschaft "Polymorphie" hervor, und ist daher überflüssig. Da außerdem sämtliche erwähnten Sprachen hier ein "Ja" zu stehen haben, ist es erst recht überflüssig. Kann diese Zeile also raus? --RokerHRO 22:49, 30. Mär. 2008 (CEST)

Ich denke ja. Vielleicht sollte man den Begriff (und damit den Verweis auf den Artikel Dynamisches Binden aber irgendwo noch reinbauen - muss aber nicht sein. Ist mehr eine persönliche Idee, da ich darunter immer zunächst dasselbe wie unter Dynamisches Linken verstehe... --PaterMcFly _Diskussion ^Beiträge 22:58, 30. Mär. 2008 (CEST)

Ich seh grad: Du hast im Abschnitt darüber auch "Dynamisches Binden" verwendet, wo es um "dynamisches Linken" geht. Aber "Binden" ist der deutsche Ausdruck für "Linken" - also herrje... Das muss klarer formuliert werden. --PaterMcFly _Diskussion ^Beiträge 23:01, 30. Mär. 2008 (CEST)

Turing-Vollständigkeit

Ich weiß nicht, ob es relevant genug ist, ob eine Sprache echt turingvollständig ist oder nicht. IMHO ist C++ dies nämlich nicht, da es verlangt, dass in einem C++-Programm verschiedene Objekte an verschiedenen Adressen liegen, jede Adresse aber in einem void* passen muss, der ebenfalls zwingend eine fixe Größe haben muss. Damit ist der Adressraum und damit auch der Zustandsraum eines C++-Programms stets endlich. Echte Turing-Vollständigkeit, also mit unbegrenztem Zustandsraum, erreicht man in C++ nur über Template-Metaprogrammierung, da dort die Zustände im Compiler liegen, und der Sprachstandard sagt nichts darüber aus, dass der Compiler nur endlich viele interne Zustände haben darf. --RokerHRO 23:04, 30. Mär. 2008 (CEST)

Also gemäss dem Artikel Turing-Vollständigkeit gehören diese Programmiersprachen (auch C++) in diese Kategorie - es steht sogar explizit dort. In der Praxis gibt es offensichtlich (leider) keine Rechner mit unendlichem Adressraum, das ist aber keine Eigenschaft der Sprache an sich. Die Sprache definiert ja den Umfang des Adressbereichs nicht. Ob jetzt ein void-Zeiger 32 oder 64 oder Hundert Millionen Bit umfasst, ist eine Implementierungssache, kein Sprachfeature. --PaterMcFly _Diskussion ^Beiträge 08:16, 31. Mär. 2008 (CEST)

Jain. Wenn eine Implementierung einmal die Größe eines void* festgelegt hat, ist diese zur Laufzeit nicht mehr änderbar. Bei anderen Sprachen, wo die Größe von Speicherreferenzen/Zeigern nicht für das Programm sichtbar ist, etwa bei diversen VMs, ließe sich diese dynamisch anpassen, sobald der Speicher erschöpft ist und der mögliche Zustandsraum damit zur Laufzeit des Programms potentiell beliebig erweitern. Siehe auch meinen Diskussionsbeitrag dazu. --RokerHRO 10:38, 31. Mär. 2008 (CEST)

Beide Artikel, Turing-Vollständigkeit und Turingmaschine erwähnen, dass für die meisten Betrachtungen ausser Acht gelassen wird, dass der Speicher nicht unendlich gross ist. ... wird der Begriff Turing-vollständig bei gängigen Programmiersprachen und Computern angewandt, die universell wären, wenn sie unbegrenzten Speicher besäßen. Selbst in der Theorie wird da die Einschränkung darauf gemacht, dass der Speicher für das zu lösende Problem ausreichend sein muss. Und da wir hier ja von praktischen Anwendungen der Sprachen reden (und es effektiv keine Rechner mit unendlichem Speicher gibt), können wir wohl mit dieser Einschränkung hier leben. Wenn Du aber eine bessere Formulierung für die Einleitung findest - bitte. Auch das Halteproblem kann natürlich keine dieser Sprachen entscheiden, denn unendlich Zeit haben wir auch nicht... --PaterMcFly _Diskussion ^Beiträge 20:09, 31. Mär. 2008 (CEST)

Ich finde, es ist schon ein Unterschied, ob eine Sprache eine Implementierung mit einem unendlichen Zustandsraum erlaubt und damit echt Turing-vollständig sein kann, oder eben nicht. Ob die existierenden Implementierungen nur einen endlichen Zustandsraum können, ist ja eine Eigenschaft der Implementierungen, nicht der Sprache. --RokerHRO 18:13, 2. Apr. 2008 (CEST)

Aha, jetzt verstehe ich Deine Argumentation. Allerdings fällt mir auf, dass das bei den genannten Sprachen ja gar kein Problem ist. Du hast oben die Grösse von void* als Limite angenommen, aber dem ist ja gar nicht so. Die Turing-Vollständigkeit sagt ja nicht, auf welche weise der Speicher adressiert werden muss. Und (um ein praktisches Beispiel zu nennen) ich kann ja Daten einfach auf eine Festplatte auslagern, wenn mir der Speicher ausgeht. Und wenn er immer noch nicht reicht, nehme ich noch eine. Mit allen diesen Sprachen ist es mögliche, solche Algorithmen zu implementieren. --PaterMcFly _Diskussion ^Beiträge 18:37, 2. Apr. 2008 (CEST)

Konzept

Hallo PaterMcFly & Co.

Habe nochmals einen Beitrag zur Löschprüfung geschrieben. Was haltet ihr von diesem Vorschlag?

--Chiccodoro 09:56, 31. Mär. 2008 (CEST)

Kopiere das mal hierher, wir sollten nicht noch länger in der LP herumdiskutieren.

Hallo zusammen. Also die Diskussion ist eigentlich bis heute sehr kontrovers geblieben. Mir ist da noch eine neue Idee quasi als Kompromiss in den Sinn gekommen. Auf der Löschdiskussion wurde ja mal argumentiert, dass der Artikel Redundanzen auf den Artikeln zu den einzelnen Sprachen verhinderen solle. Andererseits wird eine "NPOV-Vollständigkeit" vermutlich nie möglich sein, und der Artikel wurde nun gründlich hinterfragt. Eine Art Gegenüberstellung, die einen Vergleich ermöglicht und doch nicht suggeriert, vollständig zu sein, wäre ein Textbaustein mit einer Tabelle, der dann bei jedem Artikel eingefügt würde. Die Tabelle entspräche dann einer Spalte von Benutzer:PaterMcFly/Vergleich objektorientierter Programmiersprachen und sähe etwa so aus:

Eigenschaft / Konzept	C++
explizite Zeigerdatentypen	ja
Parameterübergabe	Wert oder Referenz
Speicherbereich für Objekte	Stack oder Heap oder im globalen Datensegment
Speicherfreigabe	automatisch (scope-basiert) oder manuell
Typparametrisierung	Templates (Metaprogrammierung)
Metaprogrammierung	ja (Templates und Makros)
Polymorphie	mehrfach, explizit
Mehrfachvererbung	ja
Überladen von Methoden	ja
Überladen von Operatoren	ja
Metadaten	nein
Präprozessor	ja
Methodenzeiger	ungebunden
Closures	nein
Dynamisches Binden	ja
Linken	Compilezeit
Dokumentationssystem	ja (Doxygen)

Optional könnte man noch eine Vorlage einbinden, die Links zu allen Programmiersprachenartikeln beinhaltet, die diese Tabelle einbinden.

Vorteile:

• Die Tabelle wird kürzer, weil in der Breite mehr Platz hat.
• Die Tabelle wird leichter, weil nur eine Spalte aufs Mal da ist.
• Man sieht, falls es darum geht, eine Sprache für sein Problem zu wählen, dennoch jeweils, was die Sprache kann und was nicht.
• Die Arbeit am Artikel war nicht umsonst.
• Die Argumente beider Parteien sind vereint.
• Ich konnte auch noch meinen Senf dazugeben :-)

Gruss --Chiccodoro 09:52, 31. Mär. 2008 (CEST)

Ich weiss nicht... Die Vergleichbarkeit würde zumindest darunter leiden - was ja das Ziel des Artikels ist. Ausserdem würde man sich dem seligen Infobox-Problem aussetzen. Und Redundanz ist eigentlich bei einer Liste, die klar eine Übersicht gibt, normalerweise toleriert, ja sogar gewünscht. Jedes Element einer Liste soll kurz und bündig den Inhalt zusammenfassen, so ist das auch bei Personenlisten, Geografischen Listen, etc. Und schliesslich wäre die Wartung noch schwieriger. --PaterMcFly _Diskussion ^Beiträge 11:33, 31. Mär. 2008 (CEST)

Das Problem ist, dass sich die Auswahl der aufgeführten Features immer noch auf kein nachvollziehbares Kriterium gründet. Ich würde anders vorgehen. Ich würde zuerst einen Artikel schreiben und den dann ggf. um eine dazu passende Tabelle ergänzen. Die große Menge der Fußnoten zeigt schon, dass eine Tabelle hier nicht die geeignete Präsentationsform darstellt. Vielleicht als Ergänzung. Ziel sollte aber nicht sein, auf Biegen und Brechen die Tabellendarstellung zu retten. --Wladislaw 19:03, 1. Apr. 2008 (CEST)

Das ist klar. Als erstes muss klar werden, welche Kriterien da rein kommen. Ich denke schon, dass sich da Quellen dazu finden lassen (solche Vergleiche stehen ja in vielen Lehrbüchern). Die Darstellung ist dann sekundär. Vielleicht hast Du durchaus recht, dass man das dann besser als Fliesstext formuliert. --PaterMcFly _Diskussion ^Beiträge 19:27, 1. Apr. 2008 (CEST)

Da wäre ich mir allerdings wiederum nicht so sicher. Ein Fließtext gibt keine Übersicht und ist für eine Gegenüberstellung m.E. ungeeignet. Da würde ich dann wenn schon jeden Prog.-Sprachen-Artikel um entsprechenden Fließtext ergänzen. Mich dünkt, man sollte wahrscheinlich, bevor wir hier weiterdiskutieren, überhaupt mal festlegen, was eigentlich das Ziel/der Zweck des Artikels ist:

1. Soll man sehen, was die einzelnen Sprachen können? Dann würde ich auf meinen obigen Vorschlag zurückkommen: Man sieht im entsprechenden Sprachenartikel auf einen Blick, was die Sprache kann.
2. Soll man die Sprachen vergleichen können ("welche ist besser")? Dann treffen die vielen Argumente bezüglich POV und Unvollständigkeit zu, und ich frage mich, ob das dem Zweck von Wikipedia entspricht. Ich frage mich auch, ob man das in der Praxis wirklich braucht. Normalerweise will man doch einfach wissen, welche Sprache für ganz bestimmte Anforderungen geeignet ist, also:
3. Soll man nachschlagen können, welche Sprachen ein bestimmtes Konzept unterstützen? Dann könnte man vielleicht hier pro Konzept eine Überschrift machen und darunter jeweils alle Sprachen auflisten, die es unterstützen, jeweils mit Erläuterungen, wie es unterstützt wird. (Also nicht tabellarische Form).

Die Unterschiede zwischen den obigen Punkten sind folgende: (1) ist sozusagen ein "features = lookup(sprache)". (3) ist "sprachen = lookup(feature)". (1) braucht man, um zu sehen ob eine bestimmte Sprache für die Situation geeignet ist. (3) braucht man, um Sprachen zu finden, die in Frage kommen. (2) hingegen ist sowas wie eine Bewertungstabelle, die deshalb vielleicht nie NPOV sein kann. Wenn (1) *und* (3) erzielt werden soll, könnten vielleicht auch sowohl der Vorschlag zu (1) wie auch zu (3) ausgeführt werden. Allerdings ist das wiederum mit Redundanzen verbunden...

Das waren nur mal paar Gedanken. Aber eine klare Zielsetzung könnte für all die Fragen wohl durchaus nützlich sein. --Chiccodoro 10:53, 2. Apr. 2008 (CEST)

Wenn ihr euch über die Struktur einig geworden seid, sehe ich mir gerne nochmal an was es dazu zu Java zu sagen gibt.

Zur Struktur selbst etwas beizutragen fehlt mir, ehrlich gesagt, die Lust. Nachdem der Artikel auf Behalten entschieden wurde und dann im Hinterhof doch noch gelöscht wurde, und ich das nicht zeitgerecht mitgekriegt habe, um mich dort auch zu Wort zu melden). --Geri, 03:45, 20. Apr. 2008 (CEST)

Werde mich demnächst wieder um diesen Artikel kümmern, aber im Moment brennt es an einigen anderen Stellen auch noch... Zu Ciccodoros Punkten: Ich sehe auch im grossen und ganzen diese drei Möglichkeiten, mit Präferenz auf 1 und 3, dürfte aber noch davon abhängen, wie die Struktur ausfällt. --PaterMcFly _Diskussion ^Beiträge 19:32, 20. Apr. 2008 (CEST)

Die Sache ist doch komplizierter, als ich dachte. Bisher hat meine Recherche nur Arbeiten zu Tage gebracht, die entweder konkret zwei Programmiersprachen vergleichen, dabei allerdings die Praxis und nicht die Konzepte in den Vordergrund stellen, oder dann die Sprachen empirisch vergleichen, also mit konkreten Implementationen für ein bestimmtes Problem. Eine einzige, allerdings nur tabellarische, Zusammenstellung entsprechend einem geeigneten Konzept habe ich bisher gefunden. --PaterMcFly _Diskussion ^Beiträge 07:01, 2. Mai 2008 (CEST)