"C++ is the dumpest language in the world"
-
Der Artikel ist nur sehr oberflächlich, C++ ist aber tatsächlich eine katastrophale Sprache. Voll von halbherzig umgesetzten High-Level-Features, die dadurch verwässert und nicht wirklich brauchbar sind, dass der Low-Level-Unterbau immer noch da ist. Eine vernünftige High-Level-Sprache sollte davon abstrahieren.
Wenn es nur darum geht, irgendwas irgendwie zum Laufen zu kriegen, kommt man mit C++ sicher schneller zum Ziel als mit C. Aber elegante Programme kann man damit nicht schreiben.
-
namespace invader schrieb:
Voll von halbherzig umgesetzten High-Level-Features,
beschreibe doch mal konkret, was dir an c++ fehlt und wozu du das fehlende einsetzen würdest.
-
Der Typ lässt sich ja echt über C++ aus, was ich amüsiert hinnehme.
Aber er ist ziemlich verblendet. Z.B. schreibt er, das echte Programmiergurus nur emacs nutzen. Ehm... ja... außerdem kommt mir seine Seite so vor, als ob es nur darum geht, das man bei Amazon Bücher bestellen soll. 
Aber am schlimmsten finde ich noch seine fekale Sprache. Da hab ich immer wieder nur mit dem Kopf geschüttelt. Sowas kann nur ein Asozialer schreiben...
-
So dann will ich mich auch einmal dazu äußern: ich selbst programmiere eigentlich gerne in C++ und gehöre auch zu den Leuten die der Ansicht sind, dass man in C++ eleganten Code schreiben kann.
Aber seit längerem habe ich schon nichts mehr in C++ geschrieben, sondern in diversen höheren Sprachen (Shell-Skripte, AWK, Ruby) und seit ich vor einiger Zeit mit Lisp in Berührung gekommen bin hat sich meine Ansicht über das Programmieren auch ein wenig geändert, da es einfach 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).
Möchte man dort Flexibilität so verwendet man für gewöhnlich eine Skriptsprache wie Lua, womit man dann auch ein wenig Flexibilität errreicht indem man Config-Dateien oder Daten in Form von Lua-Code speichert und zum Laden einfach das entsprechende Lua-Skript ausführt.Der Autor hat sicher sehr provokant geschrieben, aber wer den Artikel zu Ende gelesen hat weiß, dass er nicht einfach gegen eine Sprache flamed und eine andere in den Himmel lobt, sondern sie nur unterschiedlich schlecht findent
-
Bulli schrieb:
Der Typ lässt sich ja echt über C++ aus, was ich amüsiert hinnehme.
Aber er ist ziemlich verblendet. Z.B. schreibt er, das echte Programmiergurus nur emacs nutzen. Ehm... ja... außerdem kommt mir seine Seite so vor, als ob es nur darum geht, das man bei Amazon Bücher bestellen soll. Aber am schlimmsten finde ich noch seine fekale Sprache. Da hab ich immer wieder nur mit dem Kopf geschüttelt. Sowas kann nur ein Asozialer schreiben...
Lass dich von dem Emacs-Hype in dem Artikel nicht trügen, unten in den Kommentaren stellt er richtig, dass einer von den erwähnten Gurus Vi nutzt und in anderen Artikeln lässt er sich auch über Fehler an Emacs aus.
Ich würde dir raten darüber einfach hinwegzulesen.
-
Shade Of Mine schrieb:
Es tut schon fast weh ...
Hab auch n paar andere Blog einträge gelesen - mein gott wie weh das tut...Bulli schrieb:
Sowas kann nur ein Asozialer schreiben
^^hihi, immer wieder lustig, wie aufgrund von kleinigkeiten versucht wird, jemandem jeglichen sachverstand abzusprechen, nur weil einem dessen meinung nicht passt.
-
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.
-
volkard schrieb:
namespace invader schrieb:
Voll von halbherzig umgesetzten High-Level-Features,
beschreibe doch mal konkret, was dir an c++ fehlt und wozu du das fehlende einsetzen würdest.
Oder Konstruktiv mit ANTLR v3 (http://www.antlr.org/) rumspielen/entwerfen/entwicklen und sich wundern, warum A<B<C,D>> so ein großes Problem ist/war.
-
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.