Performancemythen?

Jester

Xin schrieb:

Stimmt, wenn Du so interpretierst, wie Du grade aufgeführt hast, dann zieh auch die Konsequenzen aus Deiner Aussage und bestätige, dass jedes Assemblerprogramm objektorientiert ist. Und natürlich auch alle C Programme, die Daten in beliebiger Art (eben Objekte) verarbeiten.

Deine Art zu schließen ist nicht nur leicht unlogisch sondern völlig verquer. Du ignorierst manche Dinge, erfindest andere hinzu und belegst dadurch "zweifelsfrei" irgendwelche Dinge, die nie zur Diskussion standen. Ich bin mir allerdings noch nicht sicher, ob Du dies aus mangelndem Sachverstand tust (was man Dir natürlich nicht direkt vorwerfen kann) oder mit Absicht (was in der Tat sehr unhöflich wäre).

minhen

Tim schrieb:

Was haben wir hier eigentlich. Wir haben zwei Parteien: Die eine hat eine schwammige, unpräzise Definition von OOP, die andere eine harte, präzise. Was mich dabei aber wundert ist, dass in einem Forum mit den übelsten Pedanten, ANSI-Standard-Fetischisten und undefined-behaviour-Propheten eben die unexakte, schwammige Definition besser angenommen wird. Müssten diese nicht alle (den Matheloser Jester mal ausgenommen) den Weg der peinlichst genauen Definition gehen? Woher kommt das? Liegt es vielleicht letzten Endes doch daran, dass die präzise Definition einfach nur unbrauchbar ist, weil sie einfach zu speziell ist?
Mir kommt es so vor, als definiert jemand "Speiseeis" als "Mischung aus Wasser und Milch in festem Aggregatszustand mit Zucker und Zartbitterschokoladepartikeln mit definierter Größe", während der Pöbel das einfach nur als "na Eis halt" definiert. Bei der ersten Definition ist eindeutig, dass Stracciatella gemeint ist. Der Pöbel hingegen kann sich theoretisch die Zunge am Trockeneis einfrieren, aber sollte da nicht schon längst der "common sense" eingesetzt haben?

Der Vergleich ist ein guter Ansatz, hinkt allerdings etwas, da er unvollständig ist.
Xin definiert was ein Objekt ist und darauf aufbauend Objekt-Orientierung. Bei deinem Stracciatella-Beispiel lässt du ihn aber nur die zugrunde liegende Entität definieren - mithin also nur was ein Objekt ist. Die Definition des aufbauenden Konzepts - Objekt-Orientierung - fehlt dagegen vollständig. Der Vergleich muss aber schon vollständig sein, also:
Speiseeis (Entität) = Objekt (Entität)
Speiseeis (Konzept) = Objekt-Orientierung (Konzept)

Die korrekte Analogie lautet also "Speiseeis" ist eine "Mischung aus Wasser und Milch in festem Aggregatszustand mit Zucker und Zartbitterschokoladepartikeln mit definierter Größe" (Entität) und "dient direkt zum Verzehr" (Konzept). Wobei das Konzept etwas kürzer ausfallen kann, da es auf der Entität aufbaut. Und jetzt sieht man auch schon den Unterschied zur "mystischen" (siehe Bashar) Definition "na Eis halt". Denn mit der präzisen Definition kann man sinnvoll arbeiten.
Du bist der Meinung "Zartbitterschokoladepartikeln mit definierter Größe" sei zu speziell für Speiseeis? Kein Problem. Man renne zum nächsten Eisverkäufer und zeige auf, dass das Konzept "Speiseeis" auch von anderen Entitäten erfüllt wird, welche bis auf den Streitpunkt "Zartbitterschokoladepartikeln mit definierter Größe" den Merkmalen der definierten Entität entsprechen.

Die mystische Definition, "na Eis halt", bekommt dagegen sofort das Eis auf zugefrorenen Seen vorgeworfen und versucht sich dann mit "gesundem Menschenverstand" zu verteidigen. Letzterer ist in einer Definition allerdings inakzeptabel, da beliebig und willkürlich.
Vielleicht wird das ja für Informatiker verständlicher, wenn man sich folgenden Code durch den Kopf gehen lässt:

int main() {
   int mystik;
   return 4 + mystik;
}

Die Variabel "mystik" hat bei Ausführung des Programms (Interpretation der Definition) zwar sehr wohl einen konkreten Wert - nur welchen bei dir, welchen bei mir, welchen morgen und welchen gestern, das ist die Frage.
Das sollte jetzt sogar jemand verstehen, der nicht einmal auf die Idee kommt, dass es auch nicht-mathematische, wissenschaftliche Definitionen gibt

otze

Du bist der Meinung "Zartbitterschokoladepartikeln mit definierter Größe" sei zu speziell für Speiseeis? Kein Problem. Man renne zum nächsten Eisverkäufer und zeige auf, dass das Konzept "Speiseeis" auch von anderen Entitäten erfüllt wird, welche bis auf den Streitpunkt "Zartbitterschokoladepartikeln mit definierter Größe" den Merkmalen der definierten Entität entsprechen.

und genau das machen wir die ganze zeit, wir zeigen auf alles andere worauf das passt, und uns wird endgegengehalten: "hat keine Zartbitterschokoladenpartikel mit definierter Größe".

Zumal der Vergleich in diesem Fall lauten müsste: ein Fahrzeug ist alles, was ein lenkrad hat.
Wir verweisen im folgenden auf ein Flugzeug, das wie wir alle wissen, einen Steuerknüppel besitzt, und uns wird gesagt, dass es kein Fahrzeug sein kann, da ein Fahrzeug ein lenkrad besitzt.
Dann verweisen wir auf ein Fahrrad, und uns wird gesagt, dass es kein lenkrad hat, Schiffe haben auch kein lenkrad, also auch kein Fahrzeug.
Und der gesunde Menschenverstand sagt einem: das einzige was eigentlich wirklich damit definiert werden kann, ist ein Auto.

Ich frag mich nur was passiert, wenn wir dann ein pc-lenkrad aufführen. ist dann ein Pc ein Fahrzeug?

minhen

otze schrieb:

und genau das machen wir die ganze zeit, wir zeigen auf alles andere worauf das passt, und uns wird endgegengehalten: "hat keine Zartbitterschokoladenpartikel mit definierter Größe".

Schau dir die Analogie noch einmal genau an. Zartbitterschokoladenpartikel gehören zur Entitätsdefinition. Der Großteil des Theaters hier dreht sich aber um die Konzept-Definition welche Laufzeit-Polymorphie verlangt.

Jester

minhen schrieb:

Xin definiert was ein Objekt ist und darauf aufbauend Objekt-Orientierung.

Hm, das muß ich bis jetzt überlesen haben. Wo definiert er, was ein Objekt ist? Soweit ich das überblicke verwendet er diesen Begriff als Blackbox. Im Gegenzug haben hier einige schon erklärt was ein Objekt sein soll und das Konzept OOP dann dadurch beschrieben, dass Objekte verwendet werden. Zudem unterscheiden wir uns in der Auslegung des Begriffs "Beziehung zwischen Objekten". Für Xin muß diese Beziehung (warum auch immer) Vererbung bedeuten. Andere wollen da auch Komposition und Aggregation dazuzählen. Was ist daran nun unpräzise und mystisch?

Jester

minhen schrieb:

Der Großteil des Theaters hier dreht sich aber um die Konzept-Definition welche Laufzeit-Polymorphie verlangt.

Es geht eben gerade darum, dass sie dies nicht verlang.

otze

@minhen xin hat mich doch vor 5(?) Seiten gefragt, wieso ich denn Objekt definiere, das ist doch nicht nötig.

//edit Seite 25

Wenn Du OOP definierst, warum definierst Du dann, was ein Objekt ist und was man damit machen darf und was nicht?

Xin

skals schrieb:

Über die Jahre habe ich mir angewöhnt, Aussagen, die ich nicht begreife um so gründlicher zu lesen. Weil immer dann, wenn jemand etwas sagt was nicht in "mein" Weltbild passt könnte es dafür zwei Gründe geben: Mein Weltbild ist unzureichend oder aber die Aussage ist fehlerhaft.

skals schrieb:

Nach immerhin einem viertel Jahrhundert seid ich meine ersten Programme in Computer gehackt habe bilde ich mir nunmal ein das mein Weltbild, wenn auch streckenweise unkonventionell, insgesamt doch recht fundiert ist. (Mal abgesehen davon das ich menschlich halt ein bekanntes Arschloch hier im board bin, aber das ist ein andere Thema)

Ich kann nur 21 Jahre bieten, aber ich glaube den Ruf als Arschloch erarbeite ich mir gerade. :-\

Der Rest der nicht gequoteten Einleitung weißt aber anscheinend auf einen denkenden Menschen hin.

skals schrieb:

Betrachte ich nun Xin's missionarischen Eifer mit dem er sein Weltbild unter die Leute bringt kombiniert mit dem fast schon krankhaft anmutenden Zwang alles andere als Falsch entlarven zu müssen dann werde ich stutzig.

Mich auch ^^
Ich frage mich auch, was ich hier eigentlich tue.
Ich bin überzeugt, dass ich richtig liege. Ich habe hier nichts gelesen, was mir nicht bekannt gewesen wäre, als ich zu meiner Überzeugung kam.

Meinen Eifer sehe nicht als krankhaft an, aber inzwischen als überflüssig. Ich kämpfe gegen Windmühlenflügel an, das bringt weder den Lesern des Threads was, noch mir.
Ich habe Tutorien gegeben und mein Ziel war es, den Leuten bewußt zu machen, was sie da eigentlich tun. Die Leute hatten zuvor bereits das "übliche" Programmieren mit "üblicher OOP" gelernt haben und Zugriff auf eine große Auswahl an Fachliteratur.
Die Reaktionen auf meine Erklärungen waren äußerst positiv, eine Gruppe setzte beim Dekan durch, dass ich weiteres zusätzliches Tutorium für die Gruppe geben sollte.
Dabei wurden ebenso wie in diesem Thread Theorien geäußert und mein Job war es die Schwachstelle zu finden, um zu erklären, warum das so nicht richtig oder nicht optimal ist.
Klarer Vorteil war: Ich war der Tutor. Man versuchte mich auszufragen, aber nicht in die Defensive zu drängen. Es wurde vieles gefragt und behandelt, von abstrakten Klassen bis runter auf die Bitrepräsentation im Speicher.

Am Schluß hörte ich von einigen Leuten, dass sie in den wenigen Stunden des Tutoriums mehr gelernt und vor allem verstanden hätten als in den drei Semestern, die sie studierten.

Vielleicht daher der Eifer zu überzeugen (nicht zu überreden!).
Allerdings habe ich eigentlich keine Lust mehr - soll doch jeder glauben, was er möchte.

skals schrieb:

Zwischen den Zeilen lese ich immer eine Grundaussage, die mir sehr bekannt vorkommt weil ich selber lange gebraucht habe um diese zu überwinden. Ich meine die Einstellungen das dann, wenn man sich vom "Mainstream" unterscheidet man ja "besser" ist als der Mainstream. Man ist ja ein Vordenker weil man als einer der Wenigen, vielleicht sogar als Einziger die Wahrheit erkannt hat und alle anderen einfach noch nicht weit genug sind und es deswegen ablehnen.

Ja, je größer die Ablehnung der Anderen ist, desto mehr sieht man sich sogar in seiner eigenen Meinung bestätigt.

Ähhh... definitiv nein.

Ich vertrete sehr oft unkonventionelle Meinungen - in vielen Dingen, nicht nur in der Informatik.
Ganz ehrlich: Ich hasse es, weil es grundsätzlich ausschließt - wie hier ja auch. "Du machst Dich lächerlich", der "Forumsdepp" (o.ä.) habe ich schon gelesen. Das ist nicht mein Ziel.
Man eckt überall an, weil fast alle Menschen widersprechen müssen, Attribute "arrogant" und "ignorant" bin ich gewöhnt, das sagt Deine Formulierung letztendlich ja auch aus, wenngleich auch wesentlich freundlicher und distanzierter.

Ich habe Freunde - langjährige - die ich fragte, ob ich mit meiner Art wirklich so daneben lege, ob ich ignorant oder arrogant wäre. Einer sagte mir "Du hast nunmal meistens recht und wenn nicht, siehst Du es auch ein."
Ich brauche einen Grund, wenn ich meine Ansicht ändern soll. Und zwar einen Grund, den ich noch nicht berücksichtigt habe. Ich habe hier Punkte gelesen, die ich noch nicht berücksichtigt habe, die aber konform mit meiner Definition laufen. Ich habe keinen Punkt gelesen, der ihr widerspricht. Was das angeht, sehe ich mich dadurch tatsächlich in meiner meiner Meinung bestätigt.
Ich habe auf Seite 12 eine Frage gestellt, wo die "übliche" Definition ad absurdum geführt wird, ich habe die letzten 20 Seiten immer wieder darauf hingewiesen. Einer hat versucht die Frage zu beantworten, was sich mit "Weil das so ist" zusammenfassen lässt. Auch das sehe ich als Indiz an, dass die "übliche" Definition nicht reicht.

Im Studium habe ich mir mal angewöhnt, die Massen laufen zu lassen und nur noch korrigierend einzuwirken. Ich habe gesagt, wie ich es machen würde, dann hat man es teils wirklich absichtlich anders gemacht, um mir zu widersprechen und im Worst-Case ist nunmal genau der Worst-Case eingetreten, den ich verhindern wollte und im Best-Case hat es funktioniert.

Ich will den Worst-Case aus der Definition raus haben. Ich biete eine Definition an, die den Worst-Case rausnimmt. Ich biete eine scharfe Definition an, die - wenn man sie verstanden hat(!) - eine klare Unterscheidung zwischen OOP und nicht OOP bietet, wo man unbeschränkt in der Wahl ist des Objektes ist (okay, es darf nicht 'nichts' sein...) und die Worte "Objekt orientiert" nicht verbiegen muss, damit statische Funktionalität wie Templates oder Laufzeitfunktionalität wie Reflection da rein passt.

Was hier als OOP-Definitionen(!) angeboten wird, passt auf die gesammte Bandbreite, auf alle Aspekte der Programmierung.

skals schrieb:

Dies mag nur eine INterpretation sein, aber ich werde das Gefühl nciht los das Xin sich als einer dieser Vordenker sieht, gerade _weil_ ein Großteil der Programmierer sein Denkmodell ablehnen.

Ob ich mich als Vordenker sehe? Ja. Ich mache mir um genau dieses Thema viele Gedanken, seit 8 Jahren stecke ich wirklich viel Zeit und Geld in genau dieses Thema. Ich habe mein Studium sehr am Compilerbau und Sprachdesign ausgelegt, ich suche mir Projekte in diesem Bereich, nehme mir Auszeiten vom Job, um mich damit zu beschäftigen, ich hatte im Ausland eine Anstellung, wo ich eine visuelle Programmiersprache von Grund auf geschrieben habe, deren Sourcecode auf OOP basiert. Wenn ich irgendwo Vordenker bin, dann in genau in diesem Thema.

Weil ein Großteil der Programmierer ablehnt? Nein. Ich habe 2003 eine Umfrage zu dem Thema gemacht (inkl. Berufsbezeichnung) und war ehrlich gesagt überrascht, wie man von programmierenden Physikern und Mathematikern, Ingenieuren und Wirtschaftlern, Anfängern wie Experten regelrecht mit offenen Armen empfangen wird - wenn derjenige kein Informatiker ist. Ein Großteil der Informatiker reagierte deutlich ablehnend, vermerkte aber gleichzeitig zu Fragen "Dazu habe ich mir noch keine Gedanken gemacht".

Ich bin selber Diplom-Informatiker (FH), aber meiner Erfahrung nach, kann ich den Großteil meiner eigenen Berufsgruppe in diesem Punkt nicht ernst nehmen.

skals schrieb:

Ich bin in diesem Thread nicht der erste der darauf Hinweis das Quantität keine Aussage über den Wahrheitsgehalt einer Theorie macht. Auch wenn wir alle der gleichen Meinung sind können wir falsch liegen.

Hier wurden soviele Theorien vorgestellt, die mit "Ich finde" anfangen, hier ist kaum eine Deckung der Meinungen.
Wichtig in diesem Thread scheint mir, dass der Großteil gegen meine Definition ist.
Persönliche Angriffe und Beleidigungen folgen und werden sicherlich in anderen Threads folgen, so nach dem Motto "Du bist doch der aus /dem/ Thread. Dann muss man Dich ja nicht ernst nehmen..."

skals schrieb:

Was mich an Xin stutzig werden lässt ist das Gefühl, daß er gar nciht erst zu versuchen scheint die anderen Standpunkte verstehen zu wollen, weil für ihn ja von vorneherein klar ist das diese falsch sind. Vielmehr geht es ihm nur darum darzustellen _warum_ alle anderen Aussagen falsch und seine doch richtig ist.

Was soll ich machen, keiner hat bisher etwas vorgebracht, was meiner Definition zuwider läuft. Das meiste ist war mir vor dem Thread auch bekannt. Soll ich jetzt drei Rückfragen stellen, um so zu tun, als würde ich um ein vorhandenes Verständnis ringen?

Ganz ehrlich, mir ist nicht wichtig, dass irgendwer "meine" Definition übernimmt. Sie ist aber nicht falsch. Es ist eigentlich nichtmals meine, ich habe sie eigentlich von Stroustrup übernommen und wo der sie her hat, weiß ich nicht.

Hier wird wirklich alles in die Waagschale geworfen, Templates, "plain classes" (obwohl genug schon eingesehen haben, dass man keine Klassen braucht), UML-Beziehungen, Komplexität per O-Notation, Reflection, Polymorphie, Compileroptimierungsmöglichkeiten, "static und abstract sind kein Widerspruch", alles um daraus einen wabernden Cocktail, genannt "OOP", zu präsentieren. Sogar Partikel von Zartbitterschokoladenpartikel im Speiseeis sind im Cocktail schon enthalten.
Sorry, wie soll man so sinnvoll über OOP sprechen?

Jester stellt (mal wieder) die Behauptung auf, ich würde Dinge dazu erfinden - keine Ahnung, was ich dazu erfunden haben soll, das schreibt er ja nicht. Er sagt, ich argumentiere falsch - was soll ich darauf antworten, ich weiß ja gar nicht, was ihn stört.

Oder sowas:

Tellerrand schrieb:

Xin schrieb:

Die eine Funktion heißt "Integer::Plus", die andere "plus" und beide sind statisch.

Du willst also behaupten, weil eine Sprache wie C++ das Sprachkonstrukt intern anderst behandelt, habe dies Auswirkungen auf die Definition OO?

Meine Aussage ist klar: beides sind normale Funktionsaufrufe, die eine Funktion heißt "Integer::Plus" und die andere "plus". Es lag nie OO vor, da "Integer::Plus" nicht als virtual gekennzeichnet wurde.
Für die Masse ist es ein Argument, dass die Tatsache, dass C++ es als statischen Funktionsaufruf umsetzt (weil man das ja explit im Sourcecode gesagt hat, da man "virtual" wegläßt) bedeutet, dass "OO" nicht betroffen ist.
Hier macht der böse C++ Compiler aus dem "üblichen OO" als "übliche Funktionsaufrufe" und weil der Compiler schuld ist, bleibt das OO.
Das Sprachkonstrukt ist kein OO, weil es equivalent zu einem printf-Funktionsaufruf ist. Weder in der Sprache noch in der internen Abbildung kommt OO vor.
Dass "OO" sich nicht an C++ festlegt, haben alle schon als Argument gegen mich benutzt (obwohl ich das nie behauptet habe). OO gab's vor C++.
Die umgekehrte Frage, warum macht C++ bei "plain classes" die gleichen statische Funktionsaufrufe wie es C auch macht, obwohl es nach "üblicher" Definition OO sein soll, stellt niemand. Hat das einen Grund? Und wenn ja (denn den Grund gibt es), wo liegt der Unterschied zwischen statischen Funktionsaufrufen (wo man sich nicht um das Objekt kümmert, man könnte Plus auch mit einem void * rufen) und virtuellen Aufrufen (wo der Objekttyp angibt, welche Funktion gerufen wird)?
Kann es sein, dass dieser Unterschied - nicht um Objekte kümmern und sich am Objekt orientieren - genau das ist, was man unter objektorientierte Programmierung verstehen müsste?

"Plain Classes" sind eine Besonderheit von C++. Eine sehr positive Besonderheit, weil man eben klassenorientiert arbeiten kann und muss sich trotzdem nicht durch objektorientierte Funktionsaufrufe bremsen lassen.

Ich habe das Ende der Diskussion angeregt, was sofort "als Schwanz einziehen wenn's eng wird" gewertet wird. Bisher ist es argumentativ nie eng geworden, aber es wird wirklich alles gegen "meine" Definition angekarrt, nur um dagegen zu sein.

Spaß an der Argumentation hier habe ich schon lange nicht mehr, es geht nur noch darum, diesen Thread zu beenden, weil es eben keinen Spaß macht, weil nach mir nicht geholfen hat, Fehler in meiner Definition zu finden, und weil ich die Zeit auch für anderes brauche. Lediglich möchte ich am Ende nicht lesen "...womit bewiesen wäre, dass Xin vollkommen falsch liegt.".
Um eine Form der "Missionierung" geht's hier nicht.

Und eigentlich ist mir das inzwischen auch egal.

otze

Anmerkung: ich habe bislang nicht wirklich stichhaltige Argumente von Xins Seite gelesen, die einer allgemeineren definition entgegen laufen würden, alles was er sagt beschränkte sich nur auf *sein* Bild.

Und wie kann er denn wirkliche gegenargumente verlangen? In der OOP nach *unserer* definition kann man jedes problem mit vererbung und virtual lösen. Dagegen zu argumentieren ist schwachsinnig, denn dann würden wir unsere eigene Definition entkräften. Eigentlich ist es Xins aufgabe, unsere Definition auf einen Widerspruch zu führen, das kann er aber nicht, ohne seine definition als Bewertungsmaßstab zu führen. Ein "Diese definition deckt sich nicht mit meiner und ist deswegen falsch" ist unlogisch, aber das macht er hier.

Unsere Definition lautet: OOP ist die Modellierung der Interaktion und Abhängigkeit von Objekten. Objekt müssen wir nicht definieren, denn er verlangt keine definition.

Jester

Xin, Du magst wissen was ich mit dazuerfinden und ignorieren meine? Bitteschön:
Ich habe erklärt, was ich mit Zusammenfassung von Funktionen und Daten zu Objekten meine (weiter oben habe ich erklärt, wie ich daraus OOP ableite). Daraufhin hast Du dazuerfunden, dass es was mit dem ersten Parameter einer Funktion zu tun hätte. Dann habe ich erklärt was das unterscheidet. Das hast Du ignoriert und mich erneut darauf hingewiesen, dass es ja nur auf den ersten Parameter ankommt.

rüdiger

Eigentlich verstehe ich gar nicht, warum wir hier Xins abstruser Definition von OOP so viel Aufmerksamkeit schenken. Das ist eh kein Thema, wo wir auf Einsicht hoffen können (Kategorie: Gegen die Wand reden)! Daher werde ich nun auch weitere Beiträge von Xin und zu Xins merkwürdiger Definition ignorieren! Ich versuche mal lieber die Diskussion auf wesentlich interessantere und vielleicht auch eher zu treffende Definitionen zu lenken, die in dem Thread gefallen sind (und hoffe mal, das einige Leute da mitziehen werden):

DEvent schrieb:

OO eine Denkweise wie man Daten und Methoden gruppieren kann, dabei zeichnet sich die Gruppierung durch die Einteilung in Objekten=Daten+Methoden aus. OOP ist die implementierung von der OO denkweise, die die encapsulation, inheritance, and polymorphism Techniken benutzt.

Wie schon gesagt. Dem ersten Satz stimme ich nicht ganz zu, da es Systeme gibt, die die Methoden nicht in Objekte gruppieren. CLOS arbeitet zum Beispiel ausschließlich über Multimethoden. Beim zweiten Satz hat Apollon schon richtig angemekrt, das es OO-Systeme gibt, die ohne Vererbung, Encapsulation und Polymorphismus auskommen. (War das nicht zB JavaScript?)

overtaker schrieb:

objektorientiert ist, wenn verschiedene objekte miteinander kummunizieren, d.h. nachrichten empfangen und versenden können. <- punkt

Die Definition finde ich eigentlich ziemlich treffend. Es geht um die Kommunikation mit Nachrichten zwischen Objekten. Das schließt so einfach alles ein, was ich bisher als OOP kennen gelernt habe (und auch den Erlang OO Ansatz ;))

...

@Bashar
ha, da musst du schon früher aufstehen, um mich beim Posten von Links über Erlang zu schlagen :p

evilissimo

Ich hab den Thread schon n bisserl verfolgt, aber auch nicht ganz gelesen. Das einzige was sich für mich hier herauskristallisiert ist das Xin scheinbar OOP aus der Sicht eines Compilers beschränkt.

Auf der anderen Seite wird versucht eine Abstrakte Definition von Objekt Orientierung (bzw Objekt Orientierter Programmierung zu erstellen welche sich mit der Ansicht von Xin keines Falls vereinbaren lässt.

Ich weiß zwar nicht mehr auf welcher Seite ich das gelesen habe, und welcher Beitrag das genau war. Aber es gab einen Satz in dem Xin mit "... woher soll der Compiler wissen..." argumentiert hat.
Daraus schließe ich das Xin aus sicht des Compilers zu argumentieren versucht.

Der Thread ist aber mal wieder sehr lehrreich. Unteranderem das die Definition von OO zu einem Glaubenskrieg führen kann *g*

Gruß,
Vinzenz

Undertaker

evilissimo schrieb:

Ich hab den Thread schon n bisserl verfolgt, aber auch nicht ganz gelesen. Das einzige was sich für mich hier herauskristallisiert ist das Xin scheinbar OOP aus der Sicht eines Compilers beschränkt.

bingo!
~40 seiten nur deshalb, weil alle aneinander vorbei reden.

Xin

Jester schrieb:

Xin, Du magst wissen was ich mit dazuerfinden und ignorieren meine? Bitteschön:
Ich habe erklärt, was ich mit Zusammenfassung von Funktionen und Daten zu Objekten meine (weiter oben habe ich erklärt, wie ich daraus OOP ableite). Daraufhin hast Du dazuerfunden, dass es was mit dem ersten Parameter einer Funktion zu tun hätte. Dann habe ich erklärt was das unterscheidet. Das hast Du ignoriert und mich erneut darauf hingewiesen, dass es ja nur auf den ersten Parameter ankommt.

1. Nicht dazuerfunden. Der implizite Parameter ist nicht erfunden, er wird in der Regel mit "this" bezeichnet.
2. Mir ist keine sinnvolle Erklärung eines Unterschiedes aufgefallen.

evilissimo schrieb:

Ich hab den Thread schon n bisserl verfolgt, aber auch nicht ganz gelesen. Das einzige was sich für mich hier herauskristallisiert ist das Xin scheinbar OOP aus der Sicht eines Compilers beschränkt.

Ich bin praktisch veranlagt. Seit der technischen Umsetzung von Goto haben sich Computer im Konzept und damit in ihren Möglichkeiten nicht weiterentwickelt.

Solange sich da nichts ändert, gibt die Maschine die Möglichkeiten vor. Der Compiler übersetzt unsere Sourcecodes auf die Maschine. Ich orientiere mich an der Maschine. Programme werden objektorientiert gesteuert oder statisch.
"Plain classes" laufen statisch ab, C++-Klassen mit virtual laufen objektorientiert ab - auch auf Ebene der Maschinensprache. Das Schlüsselwort virtual schaltet die OOP-Funktionalität hinzu, das fehlen von virtual in C++ bedeutet, dass man OOP entweder selbst implementieren muss oder darauf verzichtet.

Wer "plain classes" oder "templates für plain classes" bereits als OOP bezeichnen möchte, arbeitet mit einem theoretischen Konstrukt, dass in keinem Zusammenhang mit dem steht, was auf der Maschine bearbeitet wird. Von "eurem OOP" bleibt nach der Übersetzung nichts über, was sich von einem C Programm oder Assemblerprogramm unterscheidet. "plain classes" genießen die Unterstützung von C und auch von Assembler. Meine Form von OOP ist in C oder Asm nicht unterstützt, muss man halt selbst implementiert werden.

Die Maschine ist die Realität mit der ein Entwickler klarkommen muss.
Entsprechend kann man seine Sichtweise an der Realität ausrichten oder sich etwas anderes ausdenken. Das, was man sich anderes ausdenkt, muss aber schlussendlich auf die Maschine übertragen werden und "plain classes" schaffen es nicht bis auf die Maschine.
Die vielen Definitionen, die hier beschrieben wurden und inzwischen schon als "unsere Definition" bezeichnet wird, hat mal Auswirkung auf die Maschine (wenn in C++ virtual verwendet wird), mal nicht.
Viel Spaß mit einem theoretischen Konstrukt.

Ich beende den Thread hiermit.

Ihr dürft gerne weiterdiskutieren, da es in dem Thread vorrangig darum geht gegen mich zu sein und ich aussteige, ist der Thread vorraussichtlich in 24 Stunden tot. Ihr dürft jetzt nochmal über meine Ignoranz oder Arroganz herziehen, aber dann widmen wir uns alle wieder Konstruktiverem.

Möge er in Frieden ruhen.

Apollon

Xin schrieb:

Ich beende den Thread hiermit. [...] da es in dem Thread vorrangig darum geht gegen mich zu sein...

Glaub mir, so wichtig bist Du nun auch nicht.

otze

ging der thread nicht über Performancemythen?

hustbaer

Bisher ist es argumentativ nie eng geworden, aber es wird wirklich alles gegen "meine" Definition angekarrt, nur um dagegen zu sein.

Es ist nie eng geworden weil du einfach nicht darauf eingehst was andere schreiben. Ist sehr einfach so seinen Standpunkt zu vertreten.

rüdiger

Xin schrieb:

1. Nicht dazuerfunden. Der implizite Parameter ist nicht erfunden, er wird in der Regel mit "this" bezeichnet.

Nö, wie ich schon sagte: Schau dir bitte mal mehr Programmiersprachen an. Deine Einfältigkeit stimmt einen traurig und raubt dir aus meiner Sicht jede Kompetenz eine vernünftige Definition der OO zu treffen.

Xin schrieb:

Ihr dürft gerne weiterdiskutieren, da es in dem Thread vorrangig darum geht gegen mich zu sein und ich aussteige, ist der Thread vorraussichtlich in 24 Stunden tot. Ihr dürft jetzt nochmal über meine Ignoranz oder Arroganz herziehen, aber dann widmen wir uns alle wieder Konstruktiverem.

Möge er in Frieden ruhen.

Du bist wirklich Arrogant und eingebildet Wenn du Gegenargument als persönlichen Angriff empfindest ist das einfach nur lächerlich!

Xin schrieb:

Ich bin praktisch veranlagt. Seit der technischen Umsetzung von Goto haben sich Computer im Konzept und damit in ihren Möglichkeiten nicht weiterentwickelt.

Ne, Du bist praktisch gefangen. Du klebst geradezu an bestimmten konkreten Dingen und kannst keinen Millimeter abstrahieren- daher ist es ja auch nicht verwunderlich, daß Du theoretische Informatiker als "nur theoretisch Informatiker" verhöhnst.

Xin schrieb:

Ich beende den Thread hiermit.
Ihr dürft gerne weiterdiskutieren, da es in dem Thread vorrangig darum geht gegen mich zu sein und ich aussteige, ist der Thread vorraussichtlich in 24 Stunden tot. Ihr dürft jetzt nochmal über meine Ignoranz oder Arroganz herziehen, aber dann widmen wir uns alle wieder Konstruktiverem.

Du bist so unglaublich arrogant. Nur nochmal zur Erinnerung: Du stehst hier nicht vor einem Tutorium, Du bist nicht derjenige, der "hier den Erklärbär spielen" muß. Du schätzt Deine Position völlig falsch ein und benimmst Dich ständig daneben, indem Du anderen Leuten Dummheit, Ignoranz und mehr unterstellt- das führt auch dazu, daß Dich vermutlich niemand leiden kann. Es fällt nicht vom Himmel und liegt auch nicht an Deiner Genialität, sondern Du hast angefangen, andere runterzumachen, und deswegen bist Du unbeliebt. Das ist natürlich keine gute Ausgangslage, wenn man andere überzeugen will. Das hast Du Dir ganz allein zuzuschreiben.

Ich bin übrigens kein Diplominformatiker, werde nie einer sein und finde Deine Definition trotzdem merkwürdig, falls Dich das beruhigt. Falls ich jetzt wieder mal nur von Dir abgeschrieben haben sollte, tut es mir sehr leid.

Theston

Beeindruckend, wie eine einzelne Person 40 Seiten lang so konsequent trollen kann.