Performancemythen?
-
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...
-
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?
-
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.
-
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é
-
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.
-
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?
-
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.
-
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.
-
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.
-
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?
-
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é
-
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? ;))
-
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.
-
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?
-
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.
-
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.
-
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.
-
asc schrieb:
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.
Das sind komplett unterschiedliche Problematiken. std::string ist eher vergleichbar mit StringBuffer nur dass es keine "string+int"-Overloads gibt, daher wird zum Bauen von Strings mit Zahlen etc. ein anderes Mittel nötig. stringstreams eben.
asc schrieb:
Sagen wir einfach: Wer auch immer den Artikel verfasst hat, hat keine Ahnung von der Materie gehabt, oder "seine" Sprache einfach gut darsellen wollen.
Der Rees-OO-Artikel? Äh ja, das kannst du natürlich wunderbar bewerten.
-
Xin schrieb:
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.
Code ist OOP und nicht eine Programmiersprache. Die Programmiersprache kann beim OOP höchstens helfen. Aber das gilt doch für alle Paradigmen.
( "Ein Geisterfahrer?! TAUSENDE!"
)Mr. N schrieb:
asc schrieb:
Sagen wir einfach: Wer auch immer den Artikel verfasst hat, hat keine Ahnung von der Materie gehabt, oder "seine" Sprache einfach gut darsellen wollen.
Der Rees-OO-Artikel? Äh ja, das kannst du natürlich wunderbar bewerten.
Er spricht von dem Performance-Artikel (so habe ich es zumindest verstanden).
-
Helium schrieb:
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.
Nein.
Helium schrieb:
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++.
Beschreibe den Ablauf von 'dynamisch dispatched' mal ganz detailiert.
Helium schrieb:
Wenn du keine Probleme mit pototyp-basierter OO hast, was hast du dann gegen JavaScript?
Wo steht, dass ich was gegen JavaScript habe? Und selbst wenn, was hat es mit OOP zu tun?
Helium schrieb:
Templates können auch objektorientierte Klassen erstellen
Klassen können also Objektorientiert sein.
Definiere dann möglichst genau, wann eine Klasse objektorientiert ist.Sobald virtual enthalten ist und virtuelle Methoden in abgeleiteten Klassen überschrieben werden.
Ansonsten möchte ich das gerne umformulieren, bevor jemand einwendet, dass Klassen nicht objektorientiert sein können, da sie nur eine Beschreibung darstellen: Templates können auch Klassen erstellen, die Objekte erstellen, die sich zur objektorientierten Programmierung eignen.
Müssen sie aber nicht.
