Joachim Durchholz schrieb am 30. März 2011 22:40
> Soso. Begründung?
Ich nehme mal an das war eine rhetorische Frage.
> Eine CNC-Maschine hat nicht halb so viele
> Möglichkeiten, sich selbst in den Fuß zu
> schießen.
Du scheinst wohl noch nicht viel Ahnung davon zu haben. Obwohl ich
"nur" ein Dipl. Informatiker bin, habe ich bereits life miterlebt,
wie man mit einem 20000 EUR Werkzeug bei Fehlprogrammierung in ein
Werkstueck hineinrauschen kann.
> Übrigens widerspricht Dir da auch die Wikipedia:
Welche Wikipedia? Welcher Artikel? Das war der Artikel ueber C++0x,
nicht der ueber C++.
> "Additionally, considering the vastness
Und vastness legst du negativ aus? Vastness bedeutet "Weite" oder
eine Steigerung davon. Das bedeutet in keinster Weise, dass man Alles
nutzen muss das die Sprache oder ihre Libraries zur Verfuegung
stellt. Wenn man aber mehr benoetigt ist auch mehr da.
C++ kann man beinahe wie normales C benutzen, also ohne jede
objektorientierung. Siehe hierzu auch die Kommentare von Strustrup zu
C++0x in seiner FAQ zu diesem neuen Standard. Man kann Templates
selbst benutzen, kann es aber auch bleiben lassen.
> even the
> most experienced
> programmers can become beginners in a new
> programming paradigm.
Und das siehst du als Nachteil an? Soll ich aufgrund dieser
Einschaetzung von dir lieber auch dich oder auf C++ schliessen? Ich
kann dir verraten, dass dir die zeite Loesung besser gefallen wuerde.
> Ich bitte, insbesondere die Floskel "vastness
> of C++" zu beachten.
Jemandem der relativ lange lange Zeit in den USA gelebt und
gearbeitet hat brauchst du kein Englisch beibringen wollen. Siehe
oben.
> Zu "Einarbeiten" gehört auch, dass man mit
> altem Code umgehen kann.
Bei Bedarf. Bei neueren Sprachen verlangst du das doch auch nicht,
oder? Wenn ich jetzt SW-Entwickler bin, dann designe ich doch nicht
erst in altem C++, und steige dann um weil ich ja den ganzen Tag
sonst nichts zu tun habe.
> Die neuen Features mögen noch so toll sein
> die alten muss man immer
> noch lernen und verstehen.
Wieso? Doch nur wenn ich alten Code maintainen muss? Wie willst du
z.B. alten Code auf einem Mainframe maintainen? Da musst du dir neben
z.B. Java auch noch Cobol aneignen. Wie willst du alten Code auf
einem Embedded System maintainen? Assember lernen.
Bei C++ musst du in Gottes oder auch Stroustrups Namen einen aelteren
Dialekt von C++ aneignen. Was ist nun einfacher?
Wie portierst du alten Code einer alten Gurke auf eine neues Systrem
mit deiner aktuellen Lieblingsprogrammiersprache? Nicht anders als
oben beschrieben. Alte Sprache lernen.
Fuer aktuelle SW-Entwicklungsaufgaben trifft dein Vorwurf oder
Einwand aber nicht zu.
> Die Sache wird noch schlimmer: Da man die
> alten Mechanismen nicht
> verwendet (aus gutem Grund), vergisst man
> irgendwann die Details
Kannst du noch alle Sprachen die du jemals gelernt hast? Ich habe mit
BASIC begonnen, 6501-Assembler, Pascal und C weitergemacht. Dann
kamen der Z80-Assembler, 6809, 68K, PDP-11, IBM 36 PL1, APL, Pascal,
C, RMS68K, usw. Du kennst die Geschichte. Und was weiss ich davon
noch?
> echten Untiefen der Sprache nie ernsthaft
> befasst hat
Oje, deine Kristallkugel scheint einen Sprung zu haben. Scheinbar
fragen mich meine Kollegen seit Jahren fast egal in welcher Sprache
nur aus Langeweile nach irgendwelchen Details.
> man natürlich auch auf so Ideen wie "die
> Sprache ist so leicht zu
> lernen wie ein Hammer oder eine CNC-Maschine"
Du solltest dir noachmal deine Deutschbuecher aus der ersten bis
vierten Klasse zur Brust nehmen. Mein Aussage war: hat man ein extrem
leistungsfaehiges Werkzeug wie eine CNC-Maschine, so ist natuerlich
auch der Lernaufwand hoeher. Ist man nicht gewillt etwas zu lernen
muss es eben fuer fast alle Aufgaben ein hammer tun.
> Mehrfach, in mehreren Versionen ...
So, und an welchen Stellen hast du egal ob in der alten oder neuen
Version etwas auszusetzen? Welche Details der neuen Version von C++
sind suboptimal, schlecht oder schwer zu erlernen?
> und schon, als das Ding noch anders hieß.
Welches Ding? Der neue Standard oder die FAQ?
> Irgendwann hab ich das Interesse verloren.
D.h. du hast aufgegeben zu lernen weil es dir zu schwierig war.
> Die treibenden Designziele
> wurden immer klarer, und die hatten eben
> nichts damit zu tun, die
> Sprache endlich mal aufzuräumen und den
> ganzen alten Mist
> rauszuwerfen.
Was du als Nachteil ansiehst sehen sehr viele als Vorteil an.
Welche SPrache praeferierst du denn so? Wie alt ist diese denn und
wieviele neue versionen dieser Sprache gab es bereits wenn
ueberhaupt? Was glaubst du denn wie das weitergehen wird? Oder bist
du der Meinung diese Sprache ist bereits perfekt und benoetigt in den
naechsten 20 oder 30 Jahren keinerlei Aenderungen mehr?
> Das "zero overhead principle" haben sie immer
> noch drin.
Und das findest du negativ?
> C++ sucht also immer noch nach lokalen Maxima
Kein Wunder ist es auf den verschiedensten Systemen die verbreitetste
Sprache wenn man auch auf Ressourcen und Leistung achten muss.
> Sie verlassen sich immer noch darauf, dass der
> Programmierer
> Eigenschaften wie const immer richtig
> deklariert.
Oje. Ich glaube du hast nicht verstanden wozu const sonst noch gut
sein kann.
> Sie führen sogar
> noch ein constexpr ein.
Und, weisst du denn ueberhaupt wozu? Schon mal Embedded System
programmiert. Nur zum Hinweis: das ist der markt in der die meisten
CPUs unterwegs sind, das ist der Markt mit den groessten
Stueckzahlen. Es gibt fast nichts in dem keien Embedded Software drin
ist. Also wozu wohl ist constexpr gut?
> Das gibt lustige Fehler oder auch nicht, ...
> je nachdem, welcher Compiler diese Zusicherung
> auszunutzen versteht oder nicht
Ein C++0x mit x = B versteht das.
> Noch mehr blindes Rumprokeln à la "der Compiler
> übersetzt das
> nicht richtig? versuch's mal mit -O0".
So ein Bloedsinn. Hast du auch Aussagen mit etwas mehr gehalt als
dummes Herumgefrozzel. Ich arbeite zudem nicht mit dem MS-Compiler,
daher weiss ich nicht genau auf was du ansprichst.
> Kann man denn mittlerweile von einem Konstruktor
> Funktionen virtuell aufrufen?
Wozu sollte ich das benoetigen? Und wenn, weiss ich genau was
passiert, denn die Regel in welcher Reihenfolge was initialisiert
wird ist recht einfach.
> Oder ist es möglich, Diamantvererbung so zu
> machen, dass man die
> gemeinsamen Basismember zweimal in der doppelt
> erbenden Unterklasse
> hat?
Dann ist es doch keine reine Diamantvererbung mehr. Hast du ein
Codebeispiel, evt. auch per Link, um mir etwas genauer sagen zu
koennen welchen Fall du nun damit meinst?
> .. das alles nur mal so zum Aufwärmen.
Uber das bin ich seit ca. 15 Jahren C++-Programmierung in Embedded
Systemen und auf Hosts schon lange hinaus.
> Das Hauptproblem mit C++ ist nicht, dass man
> damit keinen guten Code
> schreiben kann
Das Hauptproblem jeder Sprache ist, dass man damit fuer den
geforderten Anwendungsfall guten Code schreiben koennen muss. Sollte
Code oder dessen Schreiberlinge in verschiedenen Anwendungsfaellen
genutzt werden koennen, ist es auch von Vorteil, dass die
Programmiersprache moeglichst universell ist.
> Das Problem ist, dass die Skala für die
> Codequalität in C++ sehr,
> sehr weit bis ins Negative reicht.
Man darf keine Laien an komplexen Code heranlassen. Das wichtigste
Statement eines sehr guten Vortrags (war IMHO jemand von Adobe) war:
an Kernlibraries laesst man Leute mit Erfahrung. Einsteiger sollen
sich an Programmen warmarbeiten die nicht zum Kunden gehen, aber
dennoch von anderen Leuten benutzt werden muss die faehig sind
brauchbare Kritiken zu liefern.
> Und jemand, der kein C++-Experte
> ist, kriegt nicht mal halbwegs anständigen Code
> hin, wenn er nicht
Ich mag keien Leute die in ihren Job keine Experten sind. Fuer jeden
Chice muss man studieren, Erfahrung sammeln, usw., nur beim
programmieren meinst jeder dahergelaufende BWLer, Elektriker oder
sonstwas es sei ja nicht sooo schwer. Die Qualitaetsunterschiede sind
schlichtweg immens, und das hoert bei der Programmiersprache nicht
auf. Denn es gibt Verfahren und Vorgehensweisen die sind beniahe
komplett von der programmiersprache unanbhaegig, und bei diesen
leuten hakelt es da kaum oder ueberhaupt nicht weniger als bei der
Programmiersprache selbst.
> vom Experten genauestens gesagt kriegt, was er
> zu tun und was er zu lassen ht.
Und das ist auch richtig so. In jedem anderen Fachgebiet ist das
nicht anders, nur bei Coputern, jeder hat ja einen und weiss wie man
damit umgeht (lach) meinen Laien sie muessten nicht auf den Rat der
Experten hoeren. Das erinnert mich staendig an Mr. Bean beim
Zahnarzt. Die Resultate sind vergleichbar.
> was C++ denn
> besser kann als, sagen wir, OCaml.
Was kann C++ denn schlechter als OCaml?
Ich weiss was C++ besser kann:
- Library Support, von STL bis 3rd-Party
- Tookit, GUI-Tookits
- auf fast jeder Architektur verfuegbar, also OS und CPU
- IMHO leichter lesbar, etwas subjektiv
- leichter parralelisierbar
- schneller bis deutlich schneller
Zu den letzten Punkten: schau mal das an:
> http://www.ffconsultancy.com/languages/ray_tracer/comparison.html
Beim original C++ sowie nach simpelsten Verbesserungen, ich habe nur
alle kleinen Funktionen inline und die anderen static gemacht, kommt
ray-c++ heraus, mit C++0X bzw. OpenMP die entsprechenden Zeiten.
Alles mit level = 1..12 und n=512.
ray-orig-c++:
10.237
20.767
31.733
42.698
53.352
63.856
74.203
84.618
95.024
105.671
116.706
128.872
ray-c++:
10.244
20.762
31.661
42.567
53.233
63.612
73.940
84.396
95.150
105.380
116.544
128.876
ray-c++0x:
10.233
20.768
31.683
42.602
53.226
63.653
73.949
84.359
95.025
105.307
116.704
128.848
ray-c++-omp:
10.118
20.240
30.480
40.706
50.878
60.991
71.061
81.197
91.399
101.554
112.146
123.858
ray-c++0x-omp:
10.112
20.236
30.470
40.689
50.848
60.956
71.032
81.149
91.343
101.496
112.073
123.822
ray-ocaml:
10.728
21.770
33.479
44.962
55.897
66.502
77.010
87.323
97.600
107.855
118.615
1211.417
> Soso. Begründung?
Ich nehme mal an das war eine rhetorische Frage.
> Eine CNC-Maschine hat nicht halb so viele
> Möglichkeiten, sich selbst in den Fuß zu
> schießen.
Du scheinst wohl noch nicht viel Ahnung davon zu haben. Obwohl ich
"nur" ein Dipl. Informatiker bin, habe ich bereits life miterlebt,
wie man mit einem 20000 EUR Werkzeug bei Fehlprogrammierung in ein
Werkstueck hineinrauschen kann.
> Übrigens widerspricht Dir da auch die Wikipedia:
Welche Wikipedia? Welcher Artikel? Das war der Artikel ueber C++0x,
nicht der ueber C++.
> "Additionally, considering the vastness
Und vastness legst du negativ aus? Vastness bedeutet "Weite" oder
eine Steigerung davon. Das bedeutet in keinster Weise, dass man Alles
nutzen muss das die Sprache oder ihre Libraries zur Verfuegung
stellt. Wenn man aber mehr benoetigt ist auch mehr da.
C++ kann man beinahe wie normales C benutzen, also ohne jede
objektorientierung. Siehe hierzu auch die Kommentare von Strustrup zu
C++0x in seiner FAQ zu diesem neuen Standard. Man kann Templates
selbst benutzen, kann es aber auch bleiben lassen.
> even the
> most experienced
> programmers can become beginners in a new
> programming paradigm.
Und das siehst du als Nachteil an? Soll ich aufgrund dieser
Einschaetzung von dir lieber auch dich oder auf C++ schliessen? Ich
kann dir verraten, dass dir die zeite Loesung besser gefallen wuerde.
> Ich bitte, insbesondere die Floskel "vastness
> of C++" zu beachten.
Jemandem der relativ lange lange Zeit in den USA gelebt und
gearbeitet hat brauchst du kein Englisch beibringen wollen. Siehe
oben.
> Zu "Einarbeiten" gehört auch, dass man mit
> altem Code umgehen kann.
Bei Bedarf. Bei neueren Sprachen verlangst du das doch auch nicht,
oder? Wenn ich jetzt SW-Entwickler bin, dann designe ich doch nicht
erst in altem C++, und steige dann um weil ich ja den ganzen Tag
sonst nichts zu tun habe.
> Die neuen Features mögen noch so toll sein
> die alten muss man immer
> noch lernen und verstehen.
Wieso? Doch nur wenn ich alten Code maintainen muss? Wie willst du
z.B. alten Code auf einem Mainframe maintainen? Da musst du dir neben
z.B. Java auch noch Cobol aneignen. Wie willst du alten Code auf
einem Embedded System maintainen? Assember lernen.
Bei C++ musst du in Gottes oder auch Stroustrups Namen einen aelteren
Dialekt von C++ aneignen. Was ist nun einfacher?
Wie portierst du alten Code einer alten Gurke auf eine neues Systrem
mit deiner aktuellen Lieblingsprogrammiersprache? Nicht anders als
oben beschrieben. Alte Sprache lernen.
Fuer aktuelle SW-Entwicklungsaufgaben trifft dein Vorwurf oder
Einwand aber nicht zu.
> Die Sache wird noch schlimmer: Da man die
> alten Mechanismen nicht
> verwendet (aus gutem Grund), vergisst man
> irgendwann die Details
Kannst du noch alle Sprachen die du jemals gelernt hast? Ich habe mit
BASIC begonnen, 6501-Assembler, Pascal und C weitergemacht. Dann
kamen der Z80-Assembler, 6809, 68K, PDP-11, IBM 36 PL1, APL, Pascal,
C, RMS68K, usw. Du kennst die Geschichte. Und was weiss ich davon
noch?
> echten Untiefen der Sprache nie ernsthaft
> befasst hat
Oje, deine Kristallkugel scheint einen Sprung zu haben. Scheinbar
fragen mich meine Kollegen seit Jahren fast egal in welcher Sprache
nur aus Langeweile nach irgendwelchen Details.
> man natürlich auch auf so Ideen wie "die
> Sprache ist so leicht zu
> lernen wie ein Hammer oder eine CNC-Maschine"
Du solltest dir noachmal deine Deutschbuecher aus der ersten bis
vierten Klasse zur Brust nehmen. Mein Aussage war: hat man ein extrem
leistungsfaehiges Werkzeug wie eine CNC-Maschine, so ist natuerlich
auch der Lernaufwand hoeher. Ist man nicht gewillt etwas zu lernen
muss es eben fuer fast alle Aufgaben ein hammer tun.
> Mehrfach, in mehreren Versionen ...
So, und an welchen Stellen hast du egal ob in der alten oder neuen
Version etwas auszusetzen? Welche Details der neuen Version von C++
sind suboptimal, schlecht oder schwer zu erlernen?
> und schon, als das Ding noch anders hieß.
Welches Ding? Der neue Standard oder die FAQ?
> Irgendwann hab ich das Interesse verloren.
D.h. du hast aufgegeben zu lernen weil es dir zu schwierig war.
> Die treibenden Designziele
> wurden immer klarer, und die hatten eben
> nichts damit zu tun, die
> Sprache endlich mal aufzuräumen und den
> ganzen alten Mist
> rauszuwerfen.
Was du als Nachteil ansiehst sehen sehr viele als Vorteil an.
Welche SPrache praeferierst du denn so? Wie alt ist diese denn und
wieviele neue versionen dieser Sprache gab es bereits wenn
ueberhaupt? Was glaubst du denn wie das weitergehen wird? Oder bist
du der Meinung diese Sprache ist bereits perfekt und benoetigt in den
naechsten 20 oder 30 Jahren keinerlei Aenderungen mehr?
> Das "zero overhead principle" haben sie immer
> noch drin.
Und das findest du negativ?
> C++ sucht also immer noch nach lokalen Maxima
Kein Wunder ist es auf den verschiedensten Systemen die verbreitetste
Sprache wenn man auch auf Ressourcen und Leistung achten muss.
> Sie verlassen sich immer noch darauf, dass der
> Programmierer
> Eigenschaften wie const immer richtig
> deklariert.
Oje. Ich glaube du hast nicht verstanden wozu const sonst noch gut
sein kann.
> Sie führen sogar
> noch ein constexpr ein.
Und, weisst du denn ueberhaupt wozu? Schon mal Embedded System
programmiert. Nur zum Hinweis: das ist der markt in der die meisten
CPUs unterwegs sind, das ist der Markt mit den groessten
Stueckzahlen. Es gibt fast nichts in dem keien Embedded Software drin
ist. Also wozu wohl ist constexpr gut?
> Das gibt lustige Fehler oder auch nicht, ...
> je nachdem, welcher Compiler diese Zusicherung
> auszunutzen versteht oder nicht
Ein C++0x mit x = B versteht das.
> Noch mehr blindes Rumprokeln à la "der Compiler
> übersetzt das
> nicht richtig? versuch's mal mit -O0".
So ein Bloedsinn. Hast du auch Aussagen mit etwas mehr gehalt als
dummes Herumgefrozzel. Ich arbeite zudem nicht mit dem MS-Compiler,
daher weiss ich nicht genau auf was du ansprichst.
> Kann man denn mittlerweile von einem Konstruktor
> Funktionen virtuell aufrufen?
Wozu sollte ich das benoetigen? Und wenn, weiss ich genau was
passiert, denn die Regel in welcher Reihenfolge was initialisiert
wird ist recht einfach.
> Oder ist es möglich, Diamantvererbung so zu
> machen, dass man die
> gemeinsamen Basismember zweimal in der doppelt
> erbenden Unterklasse
> hat?
Dann ist es doch keine reine Diamantvererbung mehr. Hast du ein
Codebeispiel, evt. auch per Link, um mir etwas genauer sagen zu
koennen welchen Fall du nun damit meinst?
> .. das alles nur mal so zum Aufwärmen.
Uber das bin ich seit ca. 15 Jahren C++-Programmierung in Embedded
Systemen und auf Hosts schon lange hinaus.
> Das Hauptproblem mit C++ ist nicht, dass man
> damit keinen guten Code
> schreiben kann
Das Hauptproblem jeder Sprache ist, dass man damit fuer den
geforderten Anwendungsfall guten Code schreiben koennen muss. Sollte
Code oder dessen Schreiberlinge in verschiedenen Anwendungsfaellen
genutzt werden koennen, ist es auch von Vorteil, dass die
Programmiersprache moeglichst universell ist.
> Das Problem ist, dass die Skala für die
> Codequalität in C++ sehr,
> sehr weit bis ins Negative reicht.
Man darf keine Laien an komplexen Code heranlassen. Das wichtigste
Statement eines sehr guten Vortrags (war IMHO jemand von Adobe) war:
an Kernlibraries laesst man Leute mit Erfahrung. Einsteiger sollen
sich an Programmen warmarbeiten die nicht zum Kunden gehen, aber
dennoch von anderen Leuten benutzt werden muss die faehig sind
brauchbare Kritiken zu liefern.
> Und jemand, der kein C++-Experte
> ist, kriegt nicht mal halbwegs anständigen Code
> hin, wenn er nicht
Ich mag keien Leute die in ihren Job keine Experten sind. Fuer jeden
Chice muss man studieren, Erfahrung sammeln, usw., nur beim
programmieren meinst jeder dahergelaufende BWLer, Elektriker oder
sonstwas es sei ja nicht sooo schwer. Die Qualitaetsunterschiede sind
schlichtweg immens, und das hoert bei der Programmiersprache nicht
auf. Denn es gibt Verfahren und Vorgehensweisen die sind beniahe
komplett von der programmiersprache unanbhaegig, und bei diesen
leuten hakelt es da kaum oder ueberhaupt nicht weniger als bei der
Programmiersprache selbst.
> vom Experten genauestens gesagt kriegt, was er
> zu tun und was er zu lassen ht.
Und das ist auch richtig so. In jedem anderen Fachgebiet ist das
nicht anders, nur bei Coputern, jeder hat ja einen und weiss wie man
damit umgeht (lach) meinen Laien sie muessten nicht auf den Rat der
Experten hoeren. Das erinnert mich staendig an Mr. Bean beim
Zahnarzt. Die Resultate sind vergleichbar.
> was C++ denn
> besser kann als, sagen wir, OCaml.
Was kann C++ denn schlechter als OCaml?
Ich weiss was C++ besser kann:
- Library Support, von STL bis 3rd-Party
- Tookit, GUI-Tookits
- auf fast jeder Architektur verfuegbar, also OS und CPU
- IMHO leichter lesbar, etwas subjektiv
- leichter parralelisierbar
- schneller bis deutlich schneller
Zu den letzten Punkten: schau mal das an:
> http://www.ffconsultancy.com/languages/ray_tracer/comparison.html
Beim original C++ sowie nach simpelsten Verbesserungen, ich habe nur
alle kleinen Funktionen inline und die anderen static gemacht, kommt
ray-c++ heraus, mit C++0X bzw. OpenMP die entsprechenden Zeiten.
Alles mit level = 1..12 und n=512.
ray-orig-c++:
10.237
20.767
31.733
42.698
53.352
63.856
74.203
84.618
95.024
105.671
116.706
128.872
ray-c++:
10.244
20.762
31.661
42.567
53.233
63.612
73.940
84.396
95.150
105.380
116.544
128.876
ray-c++0x:
10.233
20.768
31.683
42.602
53.226
63.653
73.949
84.359
95.025
105.307
116.704
128.848
ray-c++-omp:
10.118
20.240
30.480
40.706
50.878
60.991
71.061
81.197
91.399
101.554
112.146
123.858
ray-c++0x-omp:
10.112
20.236
30.470
40.689
50.848
60.956
71.032
81.149
91.343
101.496
112.073
123.822
ray-ocaml:
10.728
21.770
33.479
44.962
55.897
66.502
77.010
87.323
97.600
107.855
118.615
1211.417