"C++ is the dumpest language in the world"
-
Wann hört ihr endlich auf, C++ in Schutz zu nehmen?
-
volkard schrieb:
Diskussionsstarter schrieb:
faszinierend ist was man dort mit Leichtigkeit lösen kann, dass in Sprachen wie C++ einfach undenkbar wäre (Config-Dateien einfach als Lisp-Code speichern und laden).
die fehlt also nur ein Serializer an c++? und ich dachte schon, es wäre was besorgniserregendes.
Na, ein Serializer fehlt ihm nicht. Ihm fehlt das dynamische Nachladen von Code. Mit DLLs oder besser COM+ könnte man es platformabhängig lösen. Aber platformneutral wird es schon schwieriger mit C++. Nun, C++ ist nunmal sehr statisch, das liegt in der Natur der Sache.
Wobei ich sagen muß, das ich dann auch tatsächlich einfach Lua, Python oder AngelScript nutzen kann... auch wenn es nicht wieder ohne zusätzliche Arbeit geht. Ich kann mit C++ jedes Problem lösen, das eine einfacher, das andere aufwändiger.
-
volkard schrieb:
Diskussionsstarter schrieb:
faszinierend ist was man dort mit Leichtigkeit lösen kann, dass in Sprachen wie C++ einfach undenkbar wäre (Config-Dateien einfach als Lisp-Code speichern und laden).
die fehlt also nur ein Serializer an c++? und ich dachte schon, es wäre was besorgniserregendes.
Das hasse ich an diesem Forum. Es wird zu gerne das Gehirn abgeschaltet um trollen zu können
Aber die Antwort auf das unten stehende Zitat wird dich wohl interressierenBulli schrieb:
volkard schrieb:
Diskussionsstarter schrieb:
faszinierend ist was man dort mit Leichtigkeit lösen kann, dass in Sprachen wie C++ einfach undenkbar wäre (Config-Dateien einfach als Lisp-Code speichern und laden).
die fehlt also nur ein Serializer an c++? und ich dachte schon, es wäre was besorgniserregendes.
Na, ein Serializer fehlt ihm nicht. Ihm fehlt das dynamische Nachladen von Code. Mit DLLs oder besser COM+ könnte man es platformabhängig lösen. Aber platformneutral wird es schon schwieriger mit C++. Nun, C++ ist nunmal sehr statisch, das liegt in der Natur der Sache.
Wobei ich sagen muß, das ich dann auch tatsächlich einfach Lua, Python oder AngelScript nutzen kann... auch wenn es nicht wieder ohne zusätzliche Arbeit geht. Ich kann mit C++ jedes Problem lösen, das eine einfacher, das andere aufwändiger.Nein, das ist es nicht. Wie schon oben gesagt kann ich dieses Verhalten (Daten=Code) in C++ mit einer Skriptsprache zu einem gewissen Grade nachbauen, das geht natürlich auch über DLLs, aber das ist noch unflexibler als über eine Skriptsprache. Beim Einbinden einer Skriptsprache muss ich mir schon im Vorfeld Gedanken machen was genau dort verfügbar sein soll und das dort zur Verfügung stellen, so lange das der Fall ist, ist auch alles wunderbar und ich kann dann mit Leichtigkeit beim Speichern von "irgendwas" viel mehr tun als nur den Wert von irgendwelchen Objekten abzuspeichern und später wieder zu laden. Ich kann dort gleich den gesamten Code abspeichern, der am Ende zu dem aktuellen Zustand führt.
Und ich habe auch schon mehrfach in Programmen gesehen wie on the fly Skriptcode erzeugt wurde und mit der "do-string"-Methode der Skripting-Engine ausgeführt wurde. Das Prinzip Daten als Code zu betrachten findet sich also durchaus als nageliegende Lösung auch in Sprachen wie C++ wieder. Oder man schaue sich nur mal diese ganzen neuen XML Abkömmlinge an, welche ganze Sprachen in XML realisieren bzw. die Daten als Programm abspeichern. Die Barriere zwischen diesen intelligenten Dateien und dem Programm selbst bleibt aber bestehen und man muss sie gewollt überbrücken. Wenn dagegen das Programm und die Daten in der selben Sprache geschrieben sind fließt alles nahtlos ineinander und ich kann in den Daten alles nutzen was auch in dem Programm zur Verfügung steht. Ein schönes Beispiel ist hier Bash, dort kann ich in meinem Programm leicht mittels "source" Daten in Code-Form hinzufügen und stelle den Daten keinerlei Einschränkungen an das was sie tun (das geht natürlich nicht mit jeder Sprache, wie ihr auch gleich einwenden werdet, aber die Skript-Sprachen können das).
-
~fricky schrieb:
^^hihi, immer wieder lustig, wie aufgrund von kleinigkeiten versucht wird, jemandem jeglichen sachverstand abzusprechen, nur weil einem dessen meinung nicht passt.
Äh, emacs hype ist mir egal.
es geht um aussagen wie OOP ist ohne reflection nicht denkbar.
und in einem anderen eintrag redet er von polymorphie problemen und will eigentlich visitor haben nur weiss er es nicht und dann sind rubys offene klassen besser als polymorphie (obwohl das nix miteinander zu tun hat) und dann hab ichs bald danach aufgegeben als er programmier-style anhand der allokationen definieren wollte... da ist es dann selten dähmlich geworden und dann ich ichs sein lassen.
-
Ich hab den Artikel nicht ganz gelesen. Aber von dem was ich beim Überfliegen gesehen habe, ist er offenbar ein Fan dynamischer Sprachen. Nun gibt es bei OO-Implementierungen idr. zwei Richtungen. Einmal dynamische OOP (Smalltalk, CLOS etc) und einmal statische OOP (Simula, C++). Da er offenbar ein Fan dynamischer Sprachen ist, hält er dynamische OOP für den einzig wahren Weg.
Und da sieht man gleich das Problem: Der "Rant" basiert - wie die meisten Rants - einfach auf den persönlichen Vorlieben des Autors und nicht auf fundiertem Wissen. Wie man leicht daran sieht, wie er rumflucht. Daher kann man sich das Lesen des Artikels auch gleich sparen.
Wenn man eine vernünftige Kritik zu C++ lesen will, dann sollte man lieber die Notes von Stepanov lesen (bzw. das Buch von ihm was im Sommer rauskommen soll). So etwas wie der verlinkte Artikel ist nur Zeitverschwendung.
-
Diskussionsstarter schrieb:
Wie schon oben gesagt kann ich dieses Verhalten (Daten=Code) in C++ mit einer Skriptsprache zu einem gewissen Grade nachbauen...aber die Skript-Sprachen können das
wenn ich c++ coden müsste und unbedingt dynamisches c++ bräuchte, dann würde ich vielleicht sowas http://www.softintegration.com/ benutzen und könnte 'on the fly' c++ code erzeugen und ausführen. genau so gut geht's mit jeder anderen eingebetteten scriptsprache. ist ja wohl nix besonderes.
-
Diskussionsstarter schrieb:
Nein, das ist es nicht. Wie schon oben gesagt kann ich dieses Verhalten (Daten=Code) in C++ mit einer Skriptsprache zu einem gewissen Grade nachbauen, das geht natürlich auch über DLLs, aber das ist noch unflexibler als über eine Skriptsprache. Beim Einbinden einer Skriptsprache muss ich mir schon im Vorfeld Gedanken machen was genau dort verfügbar sein soll und das dort zur Verfügung stellen, so lange das der Fall ist, ist auch alles wunderbar und ich kann dann mit Leichtigkeit beim Speichern von "irgendwas" viel mehr tun als nur den Wert von irgendwelchen Objekten abzuspeichern und später wieder zu laden. Ich kann dort gleich den gesamten Code abspeichern, der am Ende zu dem aktuellen Zustand führt.
Tja, muss man halt statt einen compiler einen interpreter nehmen. ist ja kein problem.
das ist kein sprachfeature sondern ein implementations feature.
man muss halt bedenken womit sich die dynamik in solchen implementationen erkauft wird. je nach anwendung ist der trade-off natürlich entweder gut oder schlecht.
-
Ja, ich verstehe was du meinst. Aber wie du selbst sagst "Skriptsprachen können das". Ja, aber C++ ist keine Scriptsprache. Ich habe ein Lua-Buch vom Lua-Entwickler. Er selber sagt, das man sogar zwischen Dynamischen Sprachen und Scriptsprachen unterscheind muß. Er selber sieht Lua nicht als dyn. Sprache sondern als Scriptsprache an.
C++ ist aber keines von beiden: keine Scriptsprache, keine Dynamische Sprache. Es ist eine sehr statische Sprache, die OO-bedingt Late-Binding auf Methoden und dynamische Speicherreservierung hat. Das war es auch schon mit der Dynamik.
Ich sehe deshalb C++ nicht in der Pflicht Skriptfähigkeiten zu erlangen. Das würde doch gerade den C++-Hassern in die Finger spielen, die doch gerade anprangern, das C++ zu viel kann... ehm, zu viel will (um in deren Jargon zu bleiben).
Wenn C++ hier absolut ein Defizit aufweist, kann ich nur sagen: nutze eine andere Sprache, die dafür gedacht ist.
-
Mein vorheriger Beitrag ist an "Diskussionsstarter" gerichtet.
-
rüdiger schrieb:
Wenn man eine vernünftige Kritik zu C++ lesen will, dann sollte man lieber die Notes von Stepanov lesen (bzw. das Buch von ihm was im Sommer rauskommen soll). So etwas wie der verlinkte Artikel ist nur Zeitverschwendung.
Hast du mal ein paar Links?
Auf www.stepanovpapers.com stehen ja zig millionen Papers...
Welche davon sind denn lesenswert?
-
rüdiger schrieb:
Ich hab den Artikel nicht ganz gelesen. Aber von dem was ich beim Überfliegen gesehen habe, ist er offenbar ein Fan dynamischer Sprachen. Nun gibt es bei OO-Implementierungen idr. zwei Richtungen. Einmal dynamische OOP (Smalltalk, CLOS etc) und einmal statische OOP (Simula, C++). Da er offenbar ein Fan dynamischer Sprachen ist, hält er dynamische OOP für den einzig wahren Weg.
Und da sieht man gleich das Problem: Der "Rant" basiert - wie die meisten Rants - einfach auf den persönlichen Vorlieben des Autors und nicht auf fundiertem Wissen. Wie man leicht daran sieht, wie er rumflucht. Daher kann man sich das Lesen des Artikels auch gleich sparen.
Wenn man eine vernünftige Kritik zu C++ lesen will, dann sollte man lieber die Notes von Stepanov lesen (bzw. das Buch von ihm was im Sommer rauskommen soll). So etwas wie der verlinkte Artikel ist nur Zeitverschwendung.
-
Shade Of Mine schrieb:
rüdiger schrieb:
Wenn man eine vernünftige Kritik zu C++ lesen will, dann sollte man lieber die Notes von Stepanov lesen (bzw. das Buch von ihm was im Sommer rauskommen soll). So etwas wie der verlinkte Artikel ist nur Zeitverschwendung.
Hast du mal ein paar Links?
Auf www.stepanovpapers.com stehen ja zig millionen Papers...
Welche davon sind denn lesenswert?Das war's glaube ich:
http://www.stepanovpapers.com/notes.pdfAber die Testkapitel bzw. Folien von dem Buch was er schreibt, machen auch einen sehr guten Eindruck.
-
wenn man zwischen "dynamischen" und "Skript-"Sprachen unterscheidet, müßte man aber auch zwischen objekt-orientierter und Objekt-Programmierung unterscheiden.
Echte Objektprogrammierung, also die Programmierung von Objekten in einem in sich geschlossenen "Universum", welches vollständig aus Objekten besteht, wobei natürlich auch die Runtime, die IDE, der Code und überhaupt alles Objekte sind, gibt es nur mit ganz wenigen Sprachen wie Smalltalk oder Self.
apropos "Daten = Code" ... was auf dem Gebiet schon lange möglich ist, zeigt Tcl: "alles ist ein Kommando mit Argumenten"="alles ist ein String"="alles ist eine Liste"
-
rüdiger schrieb:
der titel passt überhaupt nicht. das ist doch bloss schnödes c++ buch. wie langweilig.
-
~fricky schrieb:
der titel passt überhaupt nicht. das ist doch bloss schnödes c++ buch. wie langweilig.
Was ich da so gelesen habe ist das durchaus generell relevant - natürlich auf einem abstrakten niveau - aber die infos in dem buch bringen einem schon weiter...
und gerade dir würde ich mal solche literatur empfehlen
-
Shade Of Mine schrieb:
Was ich da so gelesen habe ist das durchaus generell relevant - natürlich auf einem abstrakten niveau ....
in dem buch ist überhaupt nichts abstrakt, sondern alles sehr konkret auf C++ bezogen.
Shade Of Mine schrieb:
und gerade dir würde ich mal solche literatur empfehlen
die 'martial arts' der c++ programmierung sind für mich uninteressant. dazu habe ich zu wenig mit c++ zu tun.
-
~fricky schrieb:
in dem buch ist überhaupt nichts abstrakt, sondern alles sehr konkret auf C++ bezogen.
Eigentlich nicht wirklich.
Natürlich wird C++ als Implementierungssprache genommen und es lässt sich nicht 1:1 auf eine andere Sprache umlegen, aber viele Konzepte und Ideen sind Sprachneutral (auch wenn sie hier in C++ implementiert werden).
-
Shade Of Mine schrieb:
~fricky schrieb:
in dem buch ist überhaupt nichts abstrakt, sondern alles sehr konkret auf C++ bezogen.
Eigentlich nicht wirklich.
Natürlich wird C++ als Implementierungssprache genommen und es lässt sich nicht 1:1 auf eine andere Sprache umlegen, aber viele Konzepte und Ideen sind Sprachneutral (auch wenn sie hier in C++ implementiert werden)eigentlich schon. sowas wie der euklidische algorithmus, random shuffle, sortierung, usw. wird in anderen büchern besser erklärt. bei stepanov wird alles extrem mit c++ verrührt, was ok ist, für leute, die sich für c++ interessieren. für alle anderen ist das buch aber so gut wie wertlos.
-
~fricky schrieb:
eigentlich schon. sowas wie der euklidische algorithmus, random shuffle, sortierung, usw. wird in anderen büchern besser erklärt. bei stepanov wird alles extrem mit c++ verrührt, was ok ist, für leute, die sich für c++ interessieren. für alle anderen ist das buch aber so gut wie wertlos.
Ein C++ bezogenes Zitat aus den Notes:
While we could make a member function to return length, it is better to make it a global friend function. If we do that, we will be able eventually to define the same function to work on built-in arrays and achieve greater uniformity of design.Macht in allen Sprachen Sinn. Es geht hier zB um Member/Non-Member und dass Member funktionen idR eigentlich bäh sind. Das ist eine sehr wichtige Denkweise die dir in zB Python genauso hilft.
IMHO geht es in den Notes mehr um denkweisen als um C++ Probleme, denn der Code in den Notes ist trivial. Was interessant ist sind die Erklärungen und Hintergründe.
-
Shade Of Mine schrieb:
Ein C++ bezogenes Zitat aus den Notes:
While we could make a member function to return length, it is better to make it a global friend function. If we do that, we will be able eventually to define the same function to work on built-in arrays and achieve greater uniformity of design.Macht in allen Sprachen Sinn. Es geht hier zB um Member/Non-Member und dass Member funktionen idR eigentlich bäh sind.
Sein Argument zielt aber doch recht spezifisch darauf ab, daß sich damit das Behandeln der C-Altlasten in C++ vereinfachen läßt