Performancemythen?
-
Undertaker schrieb:
Shade Of Mine schrieb:
Danke ich kann besser C als du
den gleichen satz hast du schon mal gebracht, nur mit JavaScript.
Ich hasse es mir Leute statt über das Thema zu reden die Grundlagen von einer Sprache erklären wollen...
Was mich da aber interessiert, @minhen:
Wie gut kennst du dich mit Self, Nice, Lisp, Haskell, JavaScript,... aus?
-
Shade Of Mine schrieb:
Ich hasse es mir Leute statt über das Thema zu reden die Grundlagen von einer Sprache erklären wollen...
immer schön cool bleiben.
aussagen wie 'ich kann dieses und jenes besser als du' wirken nur kindisch.
-
Xin schrieb:
...
minhin schrieb:
Xin schrieb:
Mich hätte hier lediglich Marc++us Definition noch interessiert. Ich gehe nicht davon aus, dass er mir zustimmt, weil meine Definition braucht man nicht zu binden, da tun es auch ein, zwei Blätter. Ich gehe aber davon aus, dass wenn er schon ein Buch schreibt, er sich ebenfalls intensiver mit dem Thema beschäftigt hat und entsprechend schärfere Definitionen benutzt.
Marcus bezeichnet (Laufzeit-)Polymorphie in seinem Buch als "wesentliches Merkmal der objektorientierten Programmierung". Laufzeit-Polymorphie macht also das Wesen von OOP aus.
Was in C++ durch virtuelle Funktionen erreicht wird...
Aber das ist doch nur ein Mechanismus, mit welchem OOP in C++ ermoeglicht wird.
Das heisst nicht, dass das generell so sein muss.Ich habe den Eindruck, du faehrst dich hier auf einem Sprachfeature fest, bitte
korrigiere mich, wenn ich falsch liege.gruss
v R
-
Wenn ich jetzt ein einfaches Programm schreibe, bei dem es garkein switch/OOP Laufzeitpolymorphie benötigt wird, dann kann ich da garkeine OOP anwenden?
-
Vom sachlichen Endergebnis sin solche "Diskussionen" (im Grunde ist es ja eher ein "dädä, ich weiß es besser als du!11") total fürn Arsch. Aber für Psychologen wäre es bestimmt interessant.
-
minhen schrieb:
Shade Of Mine schrieb:
Aber ich kann nicht oft genug wiederholen: Es gibt massig Sprachen ohne virtuelle Funktionen. zB JavaScript.
"Ja", aber mit Laufzeit-Polymorphie. [...]
Warum muss es denn ausschließlich "Laufzeit-Polymorphie" sein? (was zB der Stroustrup gar nicht sagt, falls du mal wieder irgend was zitieren und entsprechend deiner Meinung auslegen willst)
-
otze schrieb:
Diese beziehung hab ich garnicht im UML diagramm dargestellt und bei der version mit abstraktet basisklasse gibts das auch nicht.
Was wolltest du nochmal trollen?
Jetzt bezeichnet ihr mich als Troll?
-----------------| |---------| | Klasse1 | | Klasse2 | |----------------| |---------| | Member |<----|.... | |----------------| |---------| |Klasse1(Member1)| | | |function() | |foo() | |________________| |---------| / \ / \ / \ |-----------| |-----------| |Konkret1 | |Konkret2 | |... | |... | |-----------| |-----------| |foo() | |foo() | |-----------| |-----------|In diesem UML Dialgramm steht eindeutig das Klasse2 eine Klasse1 ist. Diese Beziehung haben wir weder bei Templates noch bei JS.
Da schenke ich dem Thread paar Tage keine Beachtung, und schon werde ich als Troll denunziert.
Shade Of Mine schrieb:
Ich sehe da das Problem nicht. Warum ist es falsch zu sagen "alles was sich wie eine Energiequelle verhält, ist eine Energiequelle". Warum soll das falsch sein?
Kann sein das es manchmal nicht wichtig ist. Ein Vogel kann fliegen, ist er damit ein Flugzeug?
rüdiger schrieb:
Seit wann sind die von dir genannten Punkte Bestandteil einer Definition?
Wenn man diese einfachen Fragen nicht beatworten kann, ist eine Definition nutzlos.
Overtaker schrieb:
@DEvent: schau dir mal eine dynamisch typisierte sprache wie eben javascript oder so an dann sollte sich dein missverstehen zu shades posts wohl klären
Kein Missverstaendniss. Ich habe gesagt das diese BEziehung in JS nicht gegeben ist, Shader hat gesagt das es nicht wichtig seih.
-
DEvent schrieb:
In diesem UML Dialgramm steht eindeutig das Klasse2 eine Klasse1 ist. Diese Beziehung haben wir weder bei Templates noch bei JS.
Und nu?
-
rüdiger schrieb:
DEvent schrieb:
In diesem UML Dialgramm steht eindeutig das Klasse2 eine Klasse1 ist. Diese Beziehung haben wir weder bei Templates noch bei JS.
Und nu?
Otze und Shader haben gesagt das der JS und Template Code das gleiche ist, wie der C++ und der Java Code, ich stimmt mit ihnen nicht ueberein, weil man diese Beziehung in JS/Tpm gar nicht abbilden kann. Das wars.
-
DEvent schrieb:
In diesem UML Dialgramm steht eindeutig das Klasse2 eine Klasse1 ist. Diese Beziehung haben wir weder bei Templates noch bei JS.
ich hatte weiter oben ein tool erwähnt (rhapsody in C), das solche diagramme in C (eine sprache, die mit OOP nichts am hut hat), überführen kann.
warum sollt es dann nicht mit JS gehen?
-
Undertaker schrieb:
... C (eine sprache, die mit OOP nichts am hut hat), ...
Darüber wird z.Zt. noch diskutiert, ob das wirklich so ist.
-
merker schrieb:
Undertaker schrieb:
... C (eine sprache, die mit OOP nichts am hut hat), ...
Darüber wird z.Zt. noch diskutiert, ob das wirklich so ist.
was gibt es da zu diskutieren? C ist von haus aus nicht objektorientiert, im gegensatz zu etwa C#, Java, Smalltalk, Objective-C und was-weiss-ich. natürlich kann man mit C objektorientierung nachbilden, genau so wie man's z.b. mit assembler (und ich denke auch JS) machen kann.
-
Undertaker schrieb:
merker schrieb:
Undertaker schrieb:
... C (eine sprache, die mit OOP nichts am hut hat), ...
Darüber wird z.Zt. noch diskutiert, ob das wirklich so ist.
was gibt es da zu diskutieren? C ist von haus aus nicht objektorientiert, im gegensatz zu etwa C#, Java, Smalltalk, Objective-C und was-weiss-ich. natürlich kann man mit C objektorientierung nachbilden, genau so wie man's z.b. mit assembler (und ich denke auch JS) machen kann.
JS hat OOP-Tools schon von Haus aus :p
Aber ja: Standardmäßig hat C keine Möglichkeiten um mit OOP umzugehen. Scheme auch nicht und das Basis-System von Lisp auch nicht. Aber dennoch gilt Common Lisp als OO-Sprache, weil in der Library ein komplettes OOP System enthalten ist (und vermutlich deswegen eines der flexibelsten, was ich so kenne.).
OOP ist vor allem eine Denkweise (und weniger eine Compiler Technik
), wenn man dazu die passenden Tools hat oder entwickelt, dann kann man OOP in fast jeder Sprache betreiben. Ich verstehe überhaupt nicht, warum die Diskussion sich fast ausschließlich um Tools dreht. Es geht ums Denken! (Und ich denke sicher nicht über so was konkretes wie Laufzeit oder Statischen Polymorphismus nach, wenn ich mir Objekte und die Nachrichten zwischen ihnen im Kopf zusammen lege).
-
rüdiger schrieb:
Scheme auch nicht und das Basis-System von Lisp auch nicht. Aber dennoch gilt Common Lisp als OO-Sprache, weil in der Library ein komplettes OOP System enthalten ist (und vermutlich deswegen eines der flexibelsten, was ich so kenne.).
Mit Closures kann man sehr gut OO-Verhalten nachbilden. So kann man auch leicht mit Closures und Makros ein komplettes OO-System bilden (so ist ja im Prinzip auch CLOS aufgebaut).
-
rüdiger schrieb:
Es geht ums Denken! (Und ich denke sicher nicht über so was konkretes wie Laufzeit oder Statischen Polymorphismus nach, wenn ich mir Objekte und die Nachrichten zwischen ihnen im Kopf zusammen lege).
stimmt schon was du sagt, aber letztendlich muss aus einer objektorientierten denkweise kein objektorientiertes programm entstehen. denn wenn man mal den abstraktionslevel runterschaltet, kann man Xin auch verstehen, der statischen polymorphismus als nichtig erklärt. aus 'low-level' sichtweise ist statischer polymorphismus nur eine optimierung, die polymorphismus beseitigt, wo eigentlich keiner sein muss. d.h. eine übertrieben objektorientierte denkweise für die maschine vereinfacht und nur noch 'echten' polymorphismus übrig lässt.
-
Doktor Prokt schrieb:
Mit Closures kann man sehr gut OO-Verhalten nachbilden. So kann man auch leicht mit Closures und Makros ein komplettes OO-System bilden (so ist ja im Prinzip auch CLOS aufgebaut).
Erinnert mich irgendwie hieran:
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html
-
Doktor Prokt schrieb:
rüdiger schrieb:
Scheme auch nicht und das Basis-System von Lisp auch nicht. Aber dennoch gilt Common Lisp als OO-Sprache, weil in der Library ein komplettes OOP System enthalten ist (und vermutlich deswegen eines der flexibelsten, was ich so kenne.).
Mit Closures kann man sehr gut OO-Verhalten nachbilden. So kann man auch leicht mit Closures und Makros ein komplettes OO-System bilden (so ist ja im Prinzip auch CLOS aufgebaut).
Ja, natürlich. Lisp arbeitet ja eh bei dem Tool Prinzip komplett andersrum, als Sprachen wie C++ oder Java. Eben aus der Richtung des Denkens, was ich ja gesagt habe. (Deswegen rate ich ja auch Xin sich mal mit anderen Sprachen zu befassen)
-
DEvent schrieb:
Otze und Shader haben gesagt das der JS und Template Code das gleiche ist, wie der C++ und der Java Code, ich stimmt mit ihnen nicht ueberein, weil man diese Beziehung in JS/Tpm gar nicht abbilden kann. Das wars.
Klar kann man es abbilden und es wird abgebildet - aber eben nicht so wie du es erwartest.
Die Abbildung findet über die Schnittstellendefinition statt.
Wir sagen: Dynamo ist eine Energiequelle.
In Java implementiert man das: alles was das Interface Energiequelle implementiert, ist eine Energiequelle.
In JavaScript implementiert man das: alles was sich wie eine Energiequelle verhält, ist eine Energiequelle.Der Ansatz ist etwas unterschiedlich. Aber dennoch stehen Dynamo und Atomreaktor in einer Beziehung - diese wird nicht direkt im Source Code durch Inheritance oder ähnliche Mechanismen implementiert, sondern es wird als "abstraktes Konzept" betrachtet.
Es gibt keine Energiequelle - es gibt nur Sachen die sich wie Energiequellen verhalten. Selbes Prinzip wie in Java: es gibt keine konkrete Energiequelle - es gibt nur unterschiedliche Ausprägungen.
Eine Beziehung muss nicht direkt im Soucrcode vorhanden sein. Denn SourceCode ist nur eine Ebene - daraus macht der Compiler dann zB C Code und dann wird daraus Assembler Code gemacht und dann erstmal Opcode und den emuliert die CPU dann auf eine eigene Opcode Sprache. Weiters ist der Source Code ja auch nicht die oberste Ebene: es gibt diverse Planungstools, UML oder Gedankengänge die Ebenen höher als der Source Code liegen.
Wo genau muss nun die Beziehung direkt im Code stehen - wo setzt man die gültige Ebene an?
Unsere Behauptung ist nun: diese Beziehung muss im Geiste da sein und das Programm muss nach dieser Beziehung modelliert werden. Ob diese Beziehung nun als Interface im Code vorkommt oder nicht, ist nach unserer Definition implementationsabhängig - ändert aber nichts an dem Gedanken hinter dem Code.
-
In diesem UML Dialgramm steht eindeutig das Klasse2 eine Klasse1 ist. Diese Beziehung haben wir weder bei Templates noch bei JS.
das Beist sich aber mit der Überschrift "pseudouml" und der erklärung des diagramms darunter.
-
Shade Of Mine schrieb:
Danke ich kann besser C als du
Müsste ich schätzen, würde ich Gegenteiliges vermuten. Und ich kann eine solche Vermutung auf Indizien stützen. Da ich in diesem Forum aber noch nie etwas zu C gesagt habe, hat deine lächerliche Aussage im Gegenzug jedoch schlicht keinerlei Grundlage. Doch das ist nicht das Thema hier.
Es geht darum, dass dein Beitrag sehr leicht nachweisbar mit von dir frei erfundenen Dingen argumentiert (ich sag nur Marcus' Buch). Dass du darauf mit deinem Ego als Argument reagierst, mag für dich vielleicht überzeugend sein. Bei objektiver Betrachtung ist es aber einfach nur kindlich und lächerlich. Das Verhalten ist hier zwar nicht einmalig (man denke nur an Jester), wohl aber zum ersten Mal an mich gerichtet.
Eine Selbstüberschätzung wie deine ist nebenbei auch für Menschen typisch, die zwar schon einiges wissen, aber noch über kein umfassendes, tiefergehendes Wissen verfügen. Das ist auch ein Indiz. Nur so als RandbemerkungLaut Xin ist das nicht OOP. Ist es für dich OOP?
Um die Frage zu beantworten gibst du mir zu wenig Informationen. Denn im Gegensatz zu dir ist für mich weder das ominöse Gedachte noch die hingeschriebene Syntax, sondern das tatsächlich ausgeführte Verhalten der bestimmende Faktor.
Und dabei halte ich es mit Stroustrups Defintion. Du hast also alle Informationen um dir selbst zu überlegen, ob ich den Code für objektorientiert halten würde oder nicht.
Ich selbst habe allerdings wenig Lust einen Ersatz für Xin hier zu spielen und den Thread um weitere 40 Seiten zu erweitern. Xin hat seine Definition von OOP, Stroustrup eine ähnliche und ich die selbe wie Stroustrup. Der große Rest hier wiederum hat sein eigenes teils dubioses Verständnis von OOP (von Definition kann ja oft keine Rede sein). Wenn in diesem Riesen-Thread eine Sache klar geworden ist, dann die, dass das OOP-Verständnis wohl teilweise Religion ist, auf jeden Fall keine der Seiten von ihrem Standpunkt abweicht und jede darüberhinaus der Gegenseite die Existenzberechtigung abspricht.
Also entschuldige bitte wenn ich u.U. einen Klärungsbedarf mit Sicherheit aber keinen Diskussionsbedarf sehe ...rüdiger schrieb:
minhen schrieb:
Shade Of Mine schrieb:
Aber ich kann nicht oft genug wiederholen: Es gibt massig Sprachen ohne virtuelle Funktionen. zB JavaScript.
"Ja", aber mit Laufzeit-Polymorphie. [...]
Warum muss es denn ausschließlich "Laufzeit-Polymorphie" sein? (was zB der Stroustrup gar nicht sagt, falls du mal wieder irgend was zitieren und entsprechend deiner Meinung auslegen willst)
Bereits mehrfach zitiert und vor vielen Seiten auch indirekt verlinkt. Diesmal zitiere ich es jedoch auch mal mit Kontext. Denn offensichtlich hat sich niemand hier - inklusive dir - die "Mühe" gemacht, es sich mal näher anzusehen:
Bjarne Stroustrup schrieb:
(...)
Given these general criteria for a definition of
’’object-oriented’’ you can find several plausible
candidates, and several communities have their own
definitions. However, I suggest we stick to the tradi-
tional definition of object-oriented used within broad
communities of programmers. A language or tech-
nique is object-oriented if and only if it directly sup-
ports:
[1] Abstraction – providing some form of classes
and objects.
[2] Inheritance – providing the ability to build
new abstractions out of existing ones.
[3] Run-time polymorphism – providing some
form of run-time binding.
This definition includes all major languages com-
monly referred to as object-oriented: Ada95, Beta,
C++, CLOS, Eiffel, Simula, Smalltalk, and many
other languages fit this definition. Classical pro-
gramming languages without classes, such as C, For-
tran4, and Pascal, are excluded. Languages that lack
direct support for inheritance or run-time binding,
such as Ada88 and ML are also excluded.
ML is a good example of something that is good
but not object-oriented.
(...)aus Bjarne Stroustrups Paper "Why C++ is not just an Object-Oriented Programming Language". Der dritte Punkt der Definition ist auch mit noch so viel Voreingenommenheit noch immer ziemlich eindeutig. Ohne Voreingenommenheit ist's selbst bei dem an selber Stelle verlinkten FAQ-Eintrag relativ klar.