Performancemythen?

Helium

Shade Of Mine schrieb:

Warum sind Klassen ein sinnvollerer OO Ansatz als Prototypes?

Stell ihm erstmal die Frage, ob er Prototyp-Basierte OO kennt.

--------

Für mich ist der Unterschied zwischen OO und nicht OO hauptsächlich der Denkansatz.
Habe ich Funktionen, die ich mit Objekten füttere oder sage ich den Objekten, was sie machen sollen. Einmal werden die Objekte an die Funktionen geschickt, einmal die Nachricht, was zu tun ist, an das Objekt.

DEvent schrieb:

Zu der Konstante: Es spielt keine Rolle ob ein Algorithmus k langsamer ist als ein anderer. Vielleicht vor 20 Jahren, aber doch nicht heute. Lernt man im ersten Semester bei Komplexistaetslehre (oder halt ein aehnliches Fach).

Dann stelle ich dir mal eine Frage die du mir sicher beantworten kannst, da du das ja offensichtlich im Studium gelernt hast, ich aber nicht. Mit welchem Sortieralgorithmus kann ich 4000000, 4000, 40 und 4 Werte jeweils (im Mittel) am schnellsten sortieren? Quicksort oder Bubblesort? Den radix-sort lassen wir mal weg, wäre doch etwas zu komplex jetzt...

Xin

DEvent schrieb:

Xin, das ist die beste definition von OOP die ich jemals gehoert habe.

Häh? Wow...ich bin total perplex, sowas erwartete ich in diesem Thread überhaupt nicht mehr, ich freue mich ja schon über ein "es mag schlüssig sein".

Allerdings kannst Du nun davon ausgehen, dass eine andere Meinung als die Masse zu haben, bedeutet, dass die Masse dich für bekloppt erklärt.

Jester schrieb:

Liebes Kind DEvent. Bitte sei doch ruhig wenn sich Diplominformatiker über Dinge unterhalten von denen Du offensichtlich keine Ahnung hast. -- Danke!

Devent, tröste Dich, die Wissenden stehen über den Dingen.
Jester ist auf mein Posting von gestern nicht mehr eingegangen, das bedeutet natürlich, dass er mich ignoriert und auf gar keinen Fall, dass ich den "üblichen" wunden Punkt getroffen habe.
Wie sieht's aus, Jester? Weißt Du, warum OOP objektorientiert heißt?

DEvent schrieb:

Sprache         250MHz R1000         400 MHz Pentium II      Athlon 64 3200 
C               0,36s                 0,30s                  0,054s 
C++/STL/deque   2,60s (*7,22)        11,20s (*37,33)         0,395s (*7,31) 
C++/STL/list    1,70s (*4,72)         1,50s (* 5,00)         0,247s (*4,57)

Hast du auch die deque und list mit all ihren Moeglichkeiten in C nachgebildet?

Unwahrscheinlich, da man deque und list lediglich austauschte. Ich habe die Sourcen aus dem Buch genommen.
Ich habe das Programm nicht abgeschrieben. Andererseits wird hier auch mit Austauschbarkeit argumentiert, von daher habe ich hier keine Skrupel, das auch zu nutzen.

Einen Faktor von 4,5 kann man mit ein wenig Trickserei aber auch nicht mehr kleinhauen. Dafür muss man viel optimieren und kommt an Schluss bei C an, dann gilt aber der Vergleich OOP gegen Nicht-OOP auch nichts mehr.

Ich fänds super, wenn Du nicht nur "quote" schreiben würdest, sondern auch, von wem Du quotest.

Shade Of Mine schrieb:

DEvent schrieb:

Achja und es gibt sehr wohl Vererbung in Javascript.

erklär mal bitte wie

Genauso, wie in C. Wenn Du JavaScript lernen möchtest, würde ich Dir raten Tutorials zu suchen und das nicht auch noch hier rein zu packen.

Cpt. Nukem schrieb:

Datenkapselung ist halt "Anfänger OOP" und Laufzeit-Polymorphie mehr "Experten OOP".

Willkommen in meiner Zitatesammlung. Der war gut.
Sollte ich nochmals C++ unterrichten, bist Du (anonymisiert) dabei.

Cpt. Nukem schrieb:

Xin schrieb:

[...Faktor 5-10...]Es liegt auch nicht vorrangig an OOP, sondern an der Tatsache, dass C++ Compiler aufwendiger sind als C-Compiler, entsprechend auch die Optimierung aufwendiger wird.

Und ohne Compiler unterschied? Wieviel machen diese paar Befehle mehr für nen virtuellen Methodenaufruf aus, im Vergleich zum restlichen Programm?

Habe ich auch schon geschrieben. Ein virtueller Funktionsaufruf kostet genau 2x Dereferenzieren und einmal addieren. Viele Funktionsaufrufe enthalten dann "return Zahl", was einem "Move" und eventuell einer Addition entspricht. Das allein macht bei derartigen Dingen bereits ein Verhältnis 5:2 aus.
Dazu kommt der Aufwand, überhaupt eine Funktion aufzurufen, wo ein C-Programmierer sich sagt, für ein "return Zahl;" rufe ich keine Funktion auf. Bei der Methode bedeutet das zusätlich Stack aufbauen, Stack beschreiben, CPU-Pipe verlassen (bei alten CPUs sehr teuer, heutige Pipes handeln Funktionsaufrufe mit), Pipe wieder aufbauen, Stack auslesen, die Addition ausführen, mit "move" Zahl auf den Stack kopieren, CPU-Pipe verlassen und wieder aufbauen, Stack auslesen (Zahl aus Stack zum Ziel kopieren), Stack abbauen und endlich weiter im Programm.
Der C-Programmierer nimmt sich die Variable aus dem aus dem Objekt, die er entsprechend dafür aufbaut. Das ist das Move und die Addition, die beiden preiswertesten Anweisungen, die hier auftauchen.
Bevor das C++ Programm weiß, wohin es überhaupt springen soll, ist der C-Programmierer schon weiter im Programm.

otze schrieb:

Xin schrieb:

Wo ist der Unterschied zu "tier_Funktion( Tier *, typ )?

gibt keinen. die letztere Funktion würde man in C für genau diesen Fall nutzen.

Mir erzählt doch hier jeder, dass die eine OOP ist und die andere nicht. Du bestätigst mich jetzt darin, dass es hier keinen Unterschied gibt? Sehe ich das richtig?

Seit x Seiten warte ich auf eine Erklärung, wie die "übliche" Definition von "OOP" begründet, dass ein Algorithmus, der sich nicht am Objekt orientiert, "objektorientiert" genannt wird. Keiner meldet sich und sagt dazu was. otze bestätigt mich, DEvent meint, ich hätte die beste Definition, gebracht, die er je gehört hat.
Fällt irgendjemanden auf, dass die "übliche" Definition von "OOP" hakt?

Aber, otze, es ist gut, dass Du es wenigstens nicht als Paradigma bezeichnestest, wenn Du es schon als Programmierstil bezeichnest:

otze schrieb:

OOP ist für mich ein Programmierstil, bei dem sich Objekte gegenseitig Informationen zuschieben und diese dann verarbeiten.

"Für Dich"? Hier sind C++ Experten, in diesem Forum steckt soviel Know-How, hier darf jeder eine eigene Vorstellung von OOP haben.

Oder hier:

Hellium schrieb:

Für mich ist der Unterschied zwischen OO und nicht OO hauptsächlich der Denkansatz.
Habe ich Funktionen, die ich mit Objekten füttere oder sage ich den Objekten, was sie machen sollen. Einmal werden die Objekte an die Funktionen geschickt, einmal die Nachricht, was zu tun ist, an das Objekt.

"Für mich..."?
Der Denkansatz wird hier aber mehr betont. Der ist in C genauso umzusetzen, wie in C++ und wird sogar identisch kompiliert. Der Unterschied ist zwischen OO und nicht OO ist also, dass beides identisch ist.
Ist ja im Prinzip ähnlich zu otze, hier wird nur geschickt und nicht geschoben.

Rexx (prozedural) verschickt echte Nachrichten über das OS, darin steht, was getan werden soll. Das sind in der Regel ASCII-Texte und Rexx-kompatible Objekte - laufende Programme - lesen sich das durch und machen das dann.
C++ ruft objektorientiert Methoden. (benutzt man Fachwörter sind es nämlich Methoden, keine bösen Funktionen)
Nach Deiner Definition ist Rexx objektorientiert und C++ nicht.

Vielleicht ist C++ stilvolle Rexx-Programmierung?
Oder ist Rexx Anfänger OOP und C++ kein Experten OOP?

Ich könnte auch weiter ein paar Seiten zurück gehen, da finde ich sicherlich auch noch schöne Meinungen.
Je länger der Thread wird, desto mehr Meinungen kommen ja zusammen.
Ich bitte zu entschuldigen, dass ich hier die Vorstellungen von OOP so respektlos kombiniere, aber... scnr.

Fällt irgendjemanden auf, wieviele unterschiedliche Definitionen (Zitat) *die* (/Zitat) "übliche" Definition "bereichert" - oder wie es Mr.N sagte - "schwammig" macht. Und schwammig ist hier sehr höflich, weil die ganzen unterschiedlichen Meinungen, die hier als die "übliche" ankommen überhaupt nicht zusammen passen, weil jeder unter OOP was anderes versteht.
Soviele mögliche Meinungen, aber keiner konnte meine bisher kleine Frage an hustbaer bisher beantworten?

In den letzten Postings klammert man sich an Nachrichten. Bemerkt denn niemand, dass "Nachrichten" ein theoretischer Ansatz zur OOP ist und überhaupt nichts mit der Realität zu tun hat, die in C++, C#, Java stattfindet?
Da hat man was zu erzählen in der Vorlesung - um mehr geht es hier nicht. Fachwissen. Jede neue Technik bracht neue Vokabeln, damit man sich von anderen Techniken abgrenzen kann. Und in dem Fall grenzt man sich von Dingen ab, von denen man sich nicht abgrenzen müsste. Die Inforamtik ist voll von sinnlosen Fachbegriffen. Wenn ich Projektbeschreibungen durchgehe, suche ich im Internet Übersetzungen für belanglose Techniken, die sich aber furchtbar wichtig anhören.
Für unseren JS-Freund zum Beispiel "AJAX". Stinknormales JS gepaart einem Funktionsaufruf, um Informationen nachträglich anzufordern. Die Existenz einer Funktion zu kennen, macht einem zum AJAX Experten, als reiner JavaScript Entwickler kann man vielleicht OOP in JS, aber gegen eine AJAX-Experten kann man damit nicht mitziehen.
Methoden sind Funktionen. Nachrichten sind Funktionsaufrufe.
Und wer's nicht weiß, ist kein Fachmann, weil der unter Nachricht und Methode in einem anderem Kontext versteht.

Rexx schreibt Nachrichten, verpackt die und schickt die durch die Weltgeschichte, wo ein anderes Objekt sie annimmt, auspackt, liest und dann handelt. Rexx war eine Supersprache. Programmiert irgendwer hier Algorithmen in Rexx?
Apples Version davon heißt AppleScript. Microsofts Version ist VBA.
Wenn nicht, warum nicht? Weil Rexx aus einen aktuellen P4 zu einem 486er macht, wenn man damit ernsthaft programmiert.

DEvent - dem Student, dessen Job es ist, sein Wissen in Frage zu stellen - ist offenbar gelungen, sein "Wissen" in Frage zu stellen. Ich habe mal eine Umfrage zum Thema Programmiersprachen gemacht und fragte auch nach der Berufsgruppe. Diplom-Informatiker war auffälligst die Gruppe, die ihre Konzepte und Werkzeuge überhaupt nicht in Frage stellten. Zitat: "Habe ich mir ehrlich gesagt nie Gedanken drum gemacht."
Im Gegenteil, jede Möglichkeit etwas anders zu sehen, wurde absolut abgelehnt.
Mit Projektleitern, Mathematikern, Physikern usw. hatte ich durch die Umfrage teils interessante und inspirierende Diskussionen.

Undertaker

Xin schrieb:

Im Gegenteil, jede Möglichkeit etwas anders zu sehen, wurde absolut abgelehnt.

das ist auch hier normal und ich bewundere deine hartnäckigkeit, mit der du versuchst dagegen anzugehen.
aber ich glaube, leider wirst du nicht viel erfolg damit haben...

Jester

Xin schrieb:

Wie sieht's aus, Jester? Weißt Du, warum OOP objektorientiert heißt?

Ja, ich bevorzuge die Standard-Definition. Warum gibst Du dem was Du machst nicht auch nen eigenen Namen? Dann würde das nicht so durcheinanderlaufen. Man würde auf einen Blick sehen, dass Du nicht von OOP redest sondern eben von dem was Du da, ich sag mal, erfunden hast. Dann könnten wir da auch mal vernünftig drüber reden (wobei mich's ehrlich gesagt nicht sooo brennend interessiert, aber es wäre sicher ne gute Basis für weitere Diskussionen).

Ist ja auch niedlich, dass Du DEvent hier jetzt in Schutz nimmst (immerhin hat er Dir ja auch zugestimmt). Aber er hat nunmal unqualifiziert einfach irgendwo reingeplappert. Was inhaltlich teilweise richtig ist geht dennoch völlig am Inhalt dessen worauf er sich bezieht vorbei. Es hat nie jemand behauptet man könne die Laufzeitkomplexität vernachlässigen... aber gerade Dir Xin sollte es doch eigentlich gegen den Strich gehen, wenn er mir verbietet für die Praxis die Konstanten doch noch für wichtig zu halten, weil damit das theoretische Werkzeug eben überreizt wird. In realen Systemen geht es eben nicht nur um Asymptotik (Achtung: ich sage nicht asymptotische Laufzeiten seien unwichtig(!)). Da zählen eben auch die konstanten Faktoren (Achtung: ich schrieb "auch" und *nicht* "nur"). Das ist der Punkt an dem man seine Werkzeuge gelegentlich mal hinterfragen sollte, um's mit Deinen Worten zu sagen. Aber statt das zu tun ranzt er mich mit irgendwelchen Trivialitäten an.

Und den Teil mit dem k braucht man wohl nicht zu kommentieren: O(k+...) = O(...) ist zwar richtig (wenn man vielleicht noch voraussetzt, dass k ne Konstante ist), aber O(k*...) = O(...) ist dann genauso richtig. Zudem trifft letzteres die Situation die wir gerade besprechen deutlich besser.

Diese Vergleichswerte con C und C++-Implementierungen interessieren mich jetzt doch mal. Kannst Du nochmal sagen wo die her waren (der Thread ist recht unübersichtlich geworden). Gibt's den Code evtl. online? Wobei mir da auch die Stoßrichtung Deiner Argumentation noch nicht klar ist. Du sagst doch OOP ist teuer, das sieht man daran, dass die STL hier Faktor 5-10 langsamer ist die C-Version. Nur dass nach Deiner Definition (gib ihr bitte nen eigenen Namen) die STL ja garnicht objekt-orientiert ist. Kannst Du da etwas Klarheit schaffen?

Xin

Undertaker schrieb:

Xin schrieb:

Im Gegenteil, jede Möglichkeit etwas anders zu sehen, wurde absolut abgelehnt.

das ist auch hier normal und ich bewundere deine hartnäckigkeit, mit der du versuchst dagegen anzugehen.
aber ich glaube, leider wirst du nicht viel erfolg damit haben...

Wenn DEvent einen Denkanstroß hatte, halte ich das für einen Erfolg und wenigstens ein Teil der Leute, wird mehr und mehr Erfahrungen sammeln und ihre Definitionen schärfen. Dem nächsten können sie nicht mehr erzählen, sie hätten es noch nie gehört.

Die freundlichen Kommentare oder dass ich das heute schon hier sagte, wird man bis dahin vergessen haben und mich weiterhin als den komischen Kerl ansehen, der sich aus unerfindlichen Gründen nicht an die Massen anpasst. Mein Verständnis hilft mir allerdings im Job, was sich in guten Zeugnissen wiederfindet, was wichtiger ist, als dass man mich im C++-Forum respektiert.

Auch wenn man heute mit Klassen programmiert und C# und Java OOP als Default-Vorgabe verwenden, ist OOP noch nicht lange wirklich im Einsatz. Auch in Java finden sich noch viele eher strukturiert aufgebaute Programme, das dauert nochmal 10 Jahre.

OOP gibt es seit Jahrzehnten, aber die Masse bemerkte das erst Ende der 90er. Die Lehre von OOP ist noch jung und verwirrt die Studenten mehr. Das habe ich in den Tutorien semester für semester erlebt.

Heutzutage gibt es generische Programmierung, aspektoriente Programmierung usw., aber bis das die Massen erreicht wird das noch was dauern. In Sachen generischer Programmierung hat man da in C++ ja wenigstens einen Vorteil.

Um dagegen anzugehen, muss ich nicht hartnäckig sein - bisher konnte niemand etwas anbringen, was sich durch mein Verständnis von OOP nicht problemlos erklären lässt, wohingegen Jester auch im nächsten Posting keine Antwort auf meine kleine Frage liefert.

Das einzige Risiko ist, dass irgendwo in der Eile mal versehentlich etwas falsches schreibe und mir selbst widerspreche. Darauf würde sich jeder stürzen und behaupten, dass ich ja nicht wüßte, was ich so erzähle. Bisher scheint niemand etwas gefunden haben. Obwohl Jesters Behauptung, ich hätte eine Aussage gemacht, die aufgrund ihrer Allgemeinheit falsch wäre, sich zum Glück nicht bewahrheitete.
Fehler darf man sich halt nicht erlauben, sonst hat man direkt verloren - unabhängig davon, ob man richtig liegt oder nicht.
Bisher waren derartige Argumente bestenfalls aus dem Kontext gerissen, sowas wie "Arrays sind schneller als Listen.".

Jester schrieb:

Xin schrieb:

Wie sieht's aus, Jester? Weißt Du, warum OOP objektorientiert heißt?

Ja, ich bevorzuge die Standard-Definition.

"Ich finde... Punkt" und wieder kein "warum".

Jester schrieb:

Warum gibst Du dem was Du machst nicht auch nen eigenen Namen? Dann würde das nicht so durcheinanderlaufen. Man würde auf einen Blick sehen, dass Du nicht von OOP redest sondern eben von dem was Du da, ich sag mal, erfunden hast.

Ich habe nichts erfunden, ich spreche von OOP. Du sprichst davon, was Du findest und bisher nicht begründet hast, warum Deine Definition gegen meine Frage besteht.

Jester schrieb:

Dann könnten wir da auch mal vernünftig drüber reden (wobei mich's ehrlich gesagt nicht sooo brennend interessiert, ...).

Du hast Dich hiermit als Diplom Informatiker entsprechend meiner Umfrage qualifiziert.

Jester schrieb:

Ist ja auch niedlich, dass Du DEvent hier jetzt in Schutz nimmst (immerhin hat er Dir ja auch zugestimmt). Aber er hat nunmal unqualifiziert einfach irgendwo reingeplappert.

Er ist Student, er darf noch Fehler machen. Der Umkehrschluss bedeutet ja nicht, dass Studenten alles falsch machen.
In die Frage der Komplexität habe ich mich nirgendwo eingemischt, weil sie nichts mit dem Thema zu tun hat. n ist konstant, da es sich um den identischen Algorithmus handelt, und k nervt den Anwender, mehr gibt's dazu nicht zu sagen.
Ergo werde ich mich da auch nicht weiter einmischen.

Jester schrieb:

Diese Vergleichswerte con C und C++-Implementierungen interessieren mich jetzt doch mal. Kannst Du nochmal sagen wo die her waren (der Thread ist recht unübersichtlich geworden). Gibt's den Code evtl. online?

Das Buch heißt "Programmierpraxis" von Brian Kernigham und Robert Pike, die Sourcecodes kannst Du bei Addison Wesley runterladen.

Jester schrieb:

Wobei mir da auch die Stoßrichtung Deiner Argumentation noch nicht klar ist. Du sagst doch OOP ist teuer

BITTE meine Aussagen genau lesen.
Aus meinem Posting von Seite 8:

Es geht um C++, nur bedingt um OOP:

Xin schrieb:

Man geht davon aus, dass ein C++ Programm 5-10mal langsamer läuft als ein entsprechndes C Programm.
Das ist aber sehr programmabhängig, die Zahlen sind also bestenfalls wage Anhaltspunkte, ich habe sie aber schon in verschiedenen Büchern zu dem Thema gesehen. Es liegt auch nicht vorrangig an OOP, sondern an der Tatsache, dass C++ Compiler aufwendiger sind als C-Compiler, entsprechend auch die Optimierung aufwendiger wird. Doch auch die C++ Compiler werden immer besser. Die Qualität der C++-Übersetzungen wird sich mehr und mehr an C annähern, genauso wie sich C an Assembler weiter annähern wird. Trotzdem kann man davon ausgehen, dass C++-Programme langsamer bleiben als C-Programme, weil irgendeine Ungeschicktheit findet sich vermutlich in jedem C++-Programm.

Das der Faktor 5-10 noch aktuell ist, habe ich ja bereits belegt. Das OOP, wie in C++ umgesetzt, Programme im Vergleich zu einer schlechten selbstgefrickelten OOP-Implementierung auch beschleunigen kann, habe ich ebenfalls geschrieben. Also bitte lesen, wogegen argumentiert wird.

Jester schrieb:

das sieht man daran, dass die STL hier Faktor 5-10 langsamer ist die C-Version. Nur dass nach Deiner Definition (gib ihr bitte nen eigenen Namen) die STL ja garnicht objekt-orientiert ist. Kannst Du da etwas Klarheit schaffen?

Sofern die Template-Klassen nicht virtual nutzen, nutzen sie auch nicht die Technik "OOP".
Deine Schlussfolgerung ist damit vollkommen korrekt.
Templates sind eine andere Baustelle, können aber - wenn sie mit virtual arbeiten - mit OOP kombiniert werden.

asc

Xin schrieb:

...Das der Faktor 5-10 noch aktuell ist, habe ich ja bereits belegt. Das OOP, wie in C++ umgesetzt, Programme im Vergleich zu einer schlechten selbstgefrickelten OOP-Implementierung auch beschleunigen kann, habe ich ebenfalls geschrieben...

Zeig bitte mal den Code und die Aufgabe die dahinter steht. Damit es realistisch ist muss es zumindest ein Programm sein was eine sinnvolle Aufgabe hat.

Weshalb ich auf den Code rumreite kann ich auch gerne sagen: Ich habe schon mal die "Demonstration" gesehen das Java fast genauso schnell wie C++ ist. Die Demonstration war sehr interessant und zeigt, das Verlage wie z.B. heise (war ein Artikel aus der ct oder ix) auch schlechte Artikel verfassen. Auf Javaseite hat man optimiert, auf C++ Seite hat man eine stupide Lösung hingeschrieben die jeder der wenigstens etwas C++ Ahnung besitzt, besser hätte machen können (Ich sag nur sowas wie Wertübergaben kontra Referenzübergaben...).

cu André

Xin

asc schrieb:

Xin schrieb:

...Das der Faktor 5-10 noch aktuell ist, habe ich ja bereits belegt. Das OOP, wie in C++ umgesetzt, Programme im Vergleich zu einer schlechten selbstgefrickelten OOP-Implementierung auch beschleunigen kann, habe ich ebenfalls geschrieben...

Zeig bitte mal den Code und die Aufgabe die dahinter steht. Damit es realistisch ist muss es zumindest ein Programm sein was eine sinnvolle Aufgabe hat.

Die Quelle ist bekannt: Addison Wesley, das Buch heißt Programmierpraxis.
Google ist Dein Freund, Addison Wesley hat afair awp.com. Ich habe die exakte URL nicht auf'm Laptop.

asc schrieb:

Weshalb ich auf den Code rumreite kann ich auch gerne sagen: Ich habe schon mal die "Demonstration" gesehen das Java fast genauso schnell wie C++ ist. Die Demonstration war sehr interessant, und zeigt das Verlage wie z.B. heise [war ein Artikel aus der ct oder ix) schlechte Artikel verfassen. Auf Javaseite hat man optimiert auf C++ Seite hat man eine stupide Lösung hingeschrieben, die jeder der wenigstens etwas C++ Ahnung besitzt besser hätte machen können (Ich sag nur sowas wie Wertübergaben kontra Referenzübergaben...).

Jow, das habe ich auch gelesen, muss ein Experte gewesen sein.

Die Codes habe ich nicht gelesen, ich wollte nur den Vergleich zu den alten Zahlen. Ich gehe davon aus, dass Kerningham und Pike in der Lage sind halbwegs brauchbare Codes zu schreiben, zumal Programmierpraxis nur die erste Quelle für den Faktor 5-10 war, der mir eingefallen ist und den nich nicht groß suchen muss. Wenn andere ebenfalls zu dem Ergebnis gekommen sind und die Begründung "aufwendigere Optimierung" logisch ist, ist die Wahrscheinlichkeit groß, dass die Codes praxisorientiert umgesetzt wurden.

Shade Of Mine

Xin schrieb:

Shade Of Mine schrieb:

DEvent schrieb:

Achja und es gibt sehr wohl Vererbung in Javascript.

erklär mal bitte wie

Genauso, wie in C. Wenn Du JavaScript lernen möchtest, würde ich Dir raten Tutorials zu suchen und das nicht auch noch hier rein zu packen.

Danke, ich kann wohl doch besser JavaScript als du
So ein Ansatz macht aber 0 Sinn - allein der Vorschlag ist lächerlich.

Weißt du was Prototype Sprachen sind?

Warum ist Vererbung besser als das Prototype basierte Objekt klonen?

In den letzten Postings klammert man sich an Nachrichten. Bemerkt denn niemand, dass "Nachrichten" ein theoretischer Ansatz zur OOP ist und überhaupt nichts mit der Realität zu tun hat, die in C++, C#, Java stattfindet?

Und genau das ist dein Fehler. C++, C# und Java bieten dir nur einen eingeschränkten Blickwinkel auf OOP.

Beantworte mir also bitte die Frage:
warum ist Lisp kein OO? Warum sind Klassen und Vererbung besser als Prototypes und Objekt klonen? Warum sind virtuelle Funktionen besser als Multimethods?

Solange du das nicht beantworten kannst - ist deine OO Argumentation Fehlerhaft, weil sie viele Aspekte einfach ignoriert.

Der Ausdruck mit Nachrichten ist nichts anderes als eine Formulierung um zu betonen dass es um die Objekte geht die das Verhalten bestimmen. Es hat nichts mit SMS oder sonstigen Nachrichten zu tun. Helium, otze, MrN und ich (sicher noch einige andere) sehen die OOP ziemlich ähnlich. Aber der Punkt ist ja: wir behaupten man kann sie nicht genau definieren weil sie eine denkweise ist und klammerst dich an C++ und Java um OOP zu definieren. Dabei ignorierst du, dass es komplett andere Sprachen gibt die ebenfalls OOP Konzepte anbieten.

In C++ und Java sieht man eben nur einen kleinen Teil der OOP. Wobei du halt auch dort Teile der OOP die sich nicht miteinander schneiden ignorierst. zB statische Polymorphie - aber wo trennt man da?

Ist statische Polymorphie keine echte Polymorphie weil zur Laufzeit nichts geänedert werden kann? Aber Java geht noch weiter: man kann die Klassen zur Laufzeit erst _erstellen_. Etwas das in C++ nicht geht. Ist jetzt die dynamische Polymorphie in C++ weniger Polymorph als in Java? Denn Java bietet eine deutlich bessere Laufzeit Polymorphie was die dynamik betrifft. Wo genau trennt man da?

Gregor

asc schrieb:

Weshalb ich auf den Code rumreite kann ich auch gerne sagen: Ich habe schon mal die "Demonstration" gesehen das Java fast genauso schnell wie C++ ist. Die Demonstration war sehr interessant und zeigt, das Verlage wie z.B. heise (war ein Artikel aus der ct oder ix) auch schlechte Artikel verfassen. Auf Javaseite hat man optimiert, auf C++ Seite hat man eine stupide Lösung hingeschrieben die jeder der wenigstens etwas C++ Ahnung besitzt, besser hätte machen können (Ich sag nur sowas wie Wertübergaben kontra Referenzübergaben...).

An den Artikel erinnere ich mich auch. Ich kann Dir da aber nur halb Recht geben. Der Autor hatte offensichtlich kein besonders tiefgehendes Verständnis von C++, das sehe ich auch so. In dem C++ Code hätte man eine ganze Menge besser machen können. Aber was die C++-Seite bei diesem Artikel gerne übersieht, ist die Tatsache, dass der Javacode auch nicht gerade optimiert war. Da wurde auch ne ganze Menge Mist gebaut. Ich erinnere mich daran, dass da an irgendeiner Stelle ein String statt einem StringBuffer oder einem StringBuilder genutzt wurde, was an der entsprechenden Stelle zu einem sehr großen Unterschied geführt hat. Der Autor wollte damals glaube ich C# als die tolle, neue Sprache von MS darstellen. Und C# wird auch genau sein Hintergrund gewesen sein.

Ein weiterer Punkt bezüglich dieses Artikels ist allerdings, dass C++ im Vergleich zu Java oder C# deutlich mehr Verständnis erfordert, um damit akzeptablen Code prduzieren zu können. Man kann da in viel mehr "Performancefallen" und auch "Designfallen" hineinlaufen. Diesbezüglich sollte man sich die Frage stellen, wie realistisch perfekter Code in einem Projekt ist. Vielleicht ist es gar nicht so unrealistisch, anzunehmen, dass Leute kein wirklich tiefgehendes Verständnis der genutzten Programmiersprache und der Funktionsweise von Computern im Allgemeinen haben.

Jester

Xin schrieb:

Obwohl Jesters Behauptung, ich hätte eine Aussage gemacht, die aufgrund ihrer Allgemeinheit falsch wäre, sich zum Glück nicht bewahrheitete.

Doch, natürlich. Du redest von OOP und tätigst aussagen, die nur nach Deiner Definition zutreffen, für die normale Definition aber falsch sind. (Siehe auch nochmal das 2+2-Beispiel oder mach 1+1 draus, wenn das einfacher ist ;)).

Ich habe nichts erfunden, ich spreche von OOP.

Aber nicht in der Standardbedeutung. Das wovon Du redest ist demnach nicht OOP, weil OOP eben schon eine andere Definition hat. Und nein, wir nennen Deine Birne jetzt nicht Apfel!

Jester schrieb:

Dann könnten wir da auch mal vernünftig drüber reden (wobei mich's ehrlich gesagt nicht sooo brennend interessiert, ...).

Du hast Dich hiermit als Diplom Informatiker entsprechend meiner Umfrage qualifiziert.

Danke, aber das ist nicht nötig -- ich kann meine Qualifikation bereits anderweitig nachweisen.
Mich betrifft das Thema übrigens nur sehr sekundär (Informatiker müssen ja wie wir wissen nicht automatisch Software entwickeln). Ich beschäftige mich in erster Linie mit anderen Dingen. Warum sollte ich mich jetzt also so brennend dafür interessieren? Bloß weil Du irgendwas abgelassen hast? Ich sehe hier ehrlich gesagt nicht die Chance viel neues zu lernen.

Jester

Gregor schrieb:

Aber was die C++-Seite bei diesem Artikel gerne übersieht, ist die Tatsache, dass der Javacode auch nicht gerade optimiert war.

Das stimmt zwar, aber die da Strings in Java ja nie by-value übergeben werden, war wenigstens dieses Problem im Java-Code ausgeschlossen. -- Und das waren ne Menge Aufrufe.

Klar, man mag jetzt sagen, dass C++ halt schwieriger ist (so hieß es doch damals nach Beschwerden auch: "mag ja sein, aber Java macht sowas halt automatisch"), aber das sind nunmal absolute Basics. Die müssen sein. Wenn man das nicht kann, dann darf man halt auch keinen Vergleich machen.

edit: C++ hatte zusätzlich noch das Problem, dass immer sowas wie x = x + ... dastand. Daraus ein += zu machen brachte auch einiges. Das dürfte durchaus in ne ähnliche Kategorie fallen wie der StringBuffer-Fehler.

DEvent

Er ist Student, er darf noch Fehler machen. Der Umkehrschluss bedeutet ja nicht, dass Studenten alles falsch machen.
In die Frage der Komplexität habe ich mich nirgendwo eingemischt, weil sie nichts mit dem Thema zu tun hat. n ist konstant, da es sich um den identischen Algorithmus handelt, und k nervt den Anwender, mehr gibt's dazu nicht zu sagen.

Yo lassen wir das, ich geb mich geschlagen. Gibt halt 2 Typen von Programmiern, den einen ist das k egal, weil die schreiben lieber schneller Programme, die portabel sind und lassen das k den Compilerschreibern. Die zweite Sorte investiert Jahre der Forschung um das k gegen Null zu bekommen und wundert sich wieso keiner ihre Programme verwendet (es seih den sie sind zufaellig Compilerschreiber).

Danke, ich kann wohl doch besser JavaScript als du
So ein Ansatz macht aber 0 Sinn - allein der Vorschlag ist lächerlich.

Weißt du was Prototype Sprachen sind?

Warum ist Vererbung besser als das Prototype basierte Objekt klonen?

Habe ich nicht vorhin ein Beispiel fuer Vererbung bei JS geschrieben?

function Basisklasse(eigenschaft)
{
    this.eigenschaft = eigenschaft;
    this.macheWas = basisklasseMacheWas;
}

function basisklasseMacheWas()
{
    alert(this.eigenschaft);
}

function Katze(eigenschaft)
{
    this.constructor(eigenschaft);
    this.macheWas = new function()
        {
            alert("katze hat: " + this.eigenschaft);
        }
}
Katze.prototype = new Basisklasse();

katze = new Katze("Beine");

Ist das keine Vererbung?

asc

Jester schrieb:

edit: C++ hatte zusätzlich noch das Problem, dass immer sowas wie x = x + ... dastand. Daraus ein += zu machen brachte auch einiges. Das dürfte durchaus in ne ähnliche Kategorie fallen wie der StringBuffer-Fehler.

Mal davon Abgesehen das auch in C++ das "StringBuffer"-Problem bestand. Den bei vielen Stringadditionen nutzt man auch unter C++ eher ein entsprechendes Streamobjekt.

Sagen wir einfach: Wer auch immer den Artikel verfasst hat, hat keine Ahnung von der Materie gehabt, oder "seine" Sprache einfach gut darsellen wollen.

cu André

Jester

DEvent schrieb:

Yo lassen wir das, ich geb mich geschlagen. Gibt halt 2 Typen von Programmiern, den einen ist das k egal, weil die schreiben lieber schneller Programme, die portabel sind und lassen das k den Compilerschreibern. Die zweite Sorte investiert Jahre der Forschung um das k gegen Null zu bekommen und wundert sich wieso keiner ihre Programme verwendet.

Du hast es immer noch nicht verstanden. Aber vielleicht erklärst Du mir mal, warum immer noch zur linearen Optimierung der Simplex-Algorithmus (exponentielle Laufzeit) verwendet wird, obwohl es Algorithmen mit polynomialer Laufzeit gibt? Woran könnte das denn liegen?

Es geht nicht darum nur noch das k zu betrachten. Aber in der Realität das k vollständig außen vorzulassen ist realitätsfern (zumal es im betrachteten Fall ja um einen Faktor k, keine additive Konstante ging). In manchen Fällen ist auf Grund der großen Konstanten tatsächlich ein theoretisch schnelleres Verfahren in der Praxis langsamer. Zudem kann man auch wenn man einen tollen Algorithmus implementiert durch geschickte Datenstrukturen oft noch einen Faktor 10 oder mehr rausholen. Das zu ignorieren wäre doch doof. Wie gesagt, es macht den Unterschied zwischen 10s und 100s Berechnung. Während das eine noch gut geht ist das andere schon am Rande des erträglichen für den interaktiven Betrieb.

Aber wenn Du weiterdiskutieren willst, dann schreib doch mal ausführlich Deine Kritikpunkte an meinen Aussagen. Bitte hebe dabei insbesondere hervor, wo ich das genau gesagt habe. Wo ich gesagt haben soll, dass ein O(n^2)-Algo besser sei als ein O(n)-Algo habe ich nämlich nicht finden können. Ich habe lediglich nahegelegt, dass man sich auch die Konstanten bei Gelegenheit mal anschaun sollte. Lies die Beiträge vielleicht einfach nochmal unter diesem Gesichtspunkt. Und wenn Du Zeit hast, google mal nach "Algorithm Engineering"... eine relativ neue Forschungsrichtung (oder sind die alle fehlgeleitet? ;))

Xin

DEvent schrieb:

Er ist Student, er darf noch Fehler machen. Der Umkehrschluss bedeutet ja nicht, dass Studenten alles falsch machen.
In die Frage der Komplexität habe ich mich nirgendwo eingemischt, weil sie nichts mit dem Thema zu tun hat. n ist konstant, da es sich um den identischen Algorithmus handelt, und k nervt den Anwender, mehr gibt's dazu nicht zu sagen.

Yo lassen wir das, ich geb mich geschlagen.

f(x) = ax+b.
Unabhängig davon, ob man a=k setzt oder b=k, die Funktion bleibt linear von x abhängig ist. Darum geht's bei der O-Notation. Kommen mehr Daten hinzu, ändert sich das Laufzeitverhalten nicht n^2 oder n log n oder sonst was.
O( n ) = O( a*n ) = O( n+b ) = O( a*n+b ).
Pro Datensatz steigt die Laufzeit linear. Fertig.

Davon unabhängig bedeutet k aber, dass der Anwender k * länger pro Datensatz warten muss. Den wird das schon nerven und er wird sich für das Produkt entscheiden, dass die Antwort schneller findet.

Danke, ich kann wohl doch besser JavaScript als du

Ich schreibe Compiler, keine Websites. Ich hoffe für Dich, dass Du JS besser kannst als ich.

Shade Of Mine schrieb:

In den letzten Postings klammert man sich an Nachrichten. Bemerkt denn niemand, dass "Nachrichten" ein theoretischer Ansatz zur OOP ist und überhaupt nichts mit der Realität zu tun hat, die in C++, C#, Java stattfindet?

Und genau das ist dein Fehler. C++, C# und Java bieten dir nur einen eingeschränkten Blickwinkel auf OOP.

Begründe das.

Shade Of Mine schrieb:

Beantworte mir also bitte die Frage:
warum ist Lisp kein OO? Warum sind Klassen und Vererbung besser als Prototypes und Objekt klonen? Warum sind virtuelle Funktionen besser als Multimethods?

Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.

Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.

Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.
Lass es mich anders ausdrücken. Virtuelle Funktionen sind besser als Multimethoden aus dem gleichen Grund warum Steine besser als Hosen sind. Beides hat nichts miteinander zu tun.

Shade Of Mine schrieb:

Solange du das nicht beantworten kannst - ist deine OO Argumentation Fehlerhaft, weil sie viele Aspekte einfach ignoriert.

Fragen beantwortet, obwohl sie teils "Warum ist es nachts kälter als draußen?" Charakter haben. Hast Du noch mehr Fragen?

Shade Of Mine schrieb:

Der Ausdruck mit Nachrichten ist nichts anderes als eine Formulierung um zu betonen dass es um die Objekte geht die das Verhalten bestimmen.

...der nächste, der abschreibt, was ich sage und es als Argument verwenden möchte... Du bist #4 in diesem Thread, denkt euch doch mal was neues aus.

Shade Of Mine schrieb:

Aber der Punkt ist ja: wir behaupten man kann sie nicht genau definieren weil sie eine denkweise ist und klammerst dich an C++ und Java um OOP zu definieren. Dabei ignorierst du, dass es komplett andere Sprachen gibt die ebenfalls OOP Konzepte anbieten.

Die übliche Definition ist also Deiner Aussage nach, dass es nicht genau zu definieren ist. Und damit ist die Mehrzahl dann zufrieden?
Klasse Definition.
Sprachen neben C++ oder Java machen mir keine bisher Probleme. Mal eben "LISP" einzuwerfen ohne etwas konkretes zu aufzeigen, was meiner Aussage widerspricht, ist dafür etwas wenig.
Zumal Du erstmal Deine Definition an C++ belegen darfst - ich erinnere an die immernoch nicht beantwortete Frage von mir.
Wenn meine Definition auf LISP nicht passen würde, dann wäre das schlecht, aber die "Standard"-Definition passt nichtmals auf C++.

Shade Of Mine schrieb:

In C++ und Java sieht man eben nur einen kleinen Teil der OOP. Wobei du halt auch dort Teile der OOP die sich nicht miteinander schneiden ignorierst. zB statische Polymorphie - aber wo trennt man da?

Überladene Funktionen sind Funktionen gleichen Namens aber unterschiedlicher Signatur. Sie sind damit vom Compiler problemlos zu unterscheiden. Statische Funktionen sind grundsätzlich nicht objektorientiert, sie sind eben statisch. Und sie bleiben statisch, wenn sie in einem anderen Namespace liegen. Ich sehe da eine ganz klare Grenze, die absolut keine Frage läßt: nicht OOP.

Shade Of Mine schrieb:

Ist statische Polymorphie keine echte Polymorphie weil zur Laufzeit nichts geänedert werden kann? Aber Java geht noch weiter: man kann die Klassen zur Laufzeit erst _erstellen_. Etwas das in C++ nicht geht. Ist jetzt die dynamische Polymorphie in C++ weniger Polymorph als in Java? Denn Java bietet eine deutlich bessere Laufzeit Polymorphie was die dynamik betrifft. Wo genau trennt man da?

Der Spaß heißt Reflection. Falsche Baustelle.
Templates können auch objektorientierte Klassen erstellen - müssen es aber nicht. Weder brauchst Du Templates oder Reflection für OOP, noch OOP für Templates oder Reflection. Du darfst sie aber gerne zusammen verwenden.

scrub

Xin schrieb:

Die freundlichen Kommentare oder dass ich das heute schon hier sagte, wird man bis dahin vergessen haben und mich weiterhin als den komischen Kerl ansehen, der sich aus unerfindlichen Gründen nicht an die Massen anpasst. Mein Verständnis hilft mir allerdings im Job, was sich in guten Zeugnissen wiederfindet, was wichtiger ist, als dass man mich im C++-Forum respektiert.

Manchmal hat die Masse Recht, manchmal haben sogar alle Recht. Wenn Du 2 + 2 = 11 behauptest und ich 2 + 2 = 4, können wir beide Recht haben.
Nur, weil Du eine anscheinend isolierte Meinung vertrittst, hast Du noch lange nicht Recht.

Xin schrieb:

Seit x Seiten warte ich auf eine Erklärung, wie die "übliche" Definition von "OOP" begründet, dass ein Algorithmus, der sich nicht am Objekt orientiert, "objektorientiert" genannt wird.

Ganz einfach, es ist völlig wurscht, ob sich irgendwas an Objekten orientiert- der Ansatzpunkt für die "übliche" Definition ist viel einfach: Es gibt Objekte und sie werden verwendet. Das reicht bereits- kein virtual, kein sontnochwas. Keine Algorithmen, die sich an irgendwas orientieren- ich als Programmierer denke in Objekten.
Für einen genialen Kopf wie Dich zu einfach?

Xin

scrub schrieb:

Xin schrieb:

Die freundlichen Kommentare oder dass ich das heute schon hier sagte, wird man bis dahin vergessen haben und mich weiterhin als den komischen Kerl ansehen, der sich aus unerfindlichen Gründen nicht an die Massen anpasst. Mein Verständnis hilft mir allerdings im Job, was sich in guten Zeugnissen wiederfindet, was wichtiger ist, als dass man mich im C++-Forum respektiert.

Manchmal hat die Masse Recht, manchmal haben sogar alle Recht. Wenn Du 2 + 2 = 11 behauptest und ich 2 + 2 = 4, können wir beide Recht haben.
Nur, weil Du eine anscheinend isolierte Meinung vertrittst, hast Du noch lange nicht Recht.

Ich gehe mal davon aus, dass Du absichtlich im Dreiersystem rechnest und nicht im Zweiersystem, um 4 auszudrücken.

Wenn nicht, solltest Du überlegen, ob Du Dich mit Deiner Meinung nicht zu schnell festgelegt hast.

scrub schrieb:

Xin schrieb:

Seit x Seiten warte ich auf eine Erklärung, wie die "übliche" Definition von "OOP" begründet, dass ein Algorithmus, der sich nicht am Objekt orientiert, "objektorientiert" genannt wird.

Ganz einfach, es ist völlig wurscht, ob sich irgendwas an Objekten orientiert- der Ansatzpunkt für die "übliche" Definition ist viel einfach: Es gibt Objekte und sie werden verwendet. Das reicht bereits- kein virtual, kein sontnochwas. Keine Algorithmen, die sich an irgendwas orientieren- ich als Programmierer denke in Objekten.
Für einen genialen Kopf wie Dich zu einfach?

Yepp. Mit Deiner Definition ist Assembler eine Sprache, die OOP unterstützt, weil dort ebenso Objekte verwendet werden.

Wenn Du OOP so definierst, brauchst Du keine Definition, Du kannst auch einfach Programmiersprache sagen, das wäre gleichwertig.

Helium

Xin schrieb:

Shade Of Mine schrieb:

In den letzten Postings klammert man sich an Nachrichten. Bemerkt denn niemand, dass "Nachrichten" ein theoretischer Ansatz zur OOP ist und überhaupt nichts mit der Realität zu tun hat, die in C++, C#, Java stattfindet?

Und genau das ist dein Fehler. C++, C# und Java bieten dir nur einen eingeschränkten Blickwinkel auf OOP.

Begründe das.

Vorher die Frage, ob du jemals mit Smalltalk gearbeitet hast.

Xin schrieb:

Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.

Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.

Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.

Multimethoden werden dynamisch dispatched, im gegensatz zu deinem operator+ in C++.

Wenn du keine Probleme mit pototyp-basierter OO hast, was hast du dann gegen JavaScript?

Warum gerade LISP? Er hätte auch Dylan nehmen können. Es geht eben darum, das jede beliebige Funktion dynamisch dispatchen kann.

Lass es mich anders ausdrücken. Virtuelle Funktionen sind besser als Multimethoden aus dem gleichen Grund warum Steine besser als Hosen sind. Beides hat nichts miteinander zu tun.

MAchen wir mal konkrete Beispiele: Es gibt Sprachen, in denen die Punkt-Notation zum Methodenaufruf nur Syntax-Zucker ist.

object.methode(argument)

und

methode(object, argument)

sind dort beides gültige Schreibweisen und beide haben natürlich das selbe Laufzeitverhalten. Es ist ja auch nur ne andere Syntax, sonst nix. Man kann aber auch sagen, dass außedem auch anhand des Typs des "zweiten" Arguments (hier 'argument') dynamisch zu dispatchen. Und schon hat man eine Multimethode.

Ich kann die Methoden innerhalb der Klasse definieren oder außerhalb. Beide erlauben die selbe Aufrufsyntax, beide dispatchen gleichermaßen dynamisch. Lediglich die zugriffsrechte auf Private Teile der Klasse sind unterschiedlich.

Das nur vielleicht als Horizont-Erweiterung.

Templates können auch objektorientierte Klassen erstellen

Klassen können also Objektorientiert sein.
Definiere dann möglichst genau, wann eine Klasse objektorientiert ist.

Helium

Xin schrieb:

Yepp. Mit Deiner Definition ist Assembler eine Sprache, die OOP unterstützt, weil dort ebenso Objekte verwendet werden.

In wie weit unterstützt mich Assembler denn dabei diese Art zu denken auch einzusetzten?
Ermöglichen != Unterstützen.