"Zur C/C++/Java/Python-Diskussion"

[BlackJack]

@snafu: Es geht nicht darum irgendwo mehr Objekte im Speicher zu haben als nötig, sondern um Objekte die gar nicht mehr freigegeben werden oder Speicher auf den zugegriffen wird, obwohl er schon freigegeben ist. Und bei der Frage ob Kopien erstellt werden oder nicht und wovon/bis zu welcher Tiefe, geht es darum auf welchem Objekt man eigentlich gerade arbeitet. Das sind Fragen die sich in Python nicht stellen. Es wird bei Parameterübergaben und Zuweisungen nie eine Kopie eines Objekts oder Teilen davon erstellt, ich kann nicht aus versehen auf ein Objekt zugreifen dessen Speicher schon freigegeben ist, und ich muss mir grundsätzlich auch nicht um die Freigabe von Speicher Gedanken machen, auf den man im Programm keinen Zugriff mehr hat. Und ich kann Ausnahmen verwenden ohne mir über „exception safety” Gedanken machen zu müssen. Das sind alles Sachen bei denen man bei C++ unsanft auf die Nase fallen kann, wenn man sich keine Gedanken um Speicherverwaltung macht, und diszipliniert damit umgeht.

[lunar]

@EyDu: Typsicherheit ist ein armes Argument zur Rechtfertigung der Umständlichkeit von C++-Quelltext. Nicht wenige Sprache erzielen höhere Typsicherheit mit weniger deklarativem Aufwand (e.g. Haskell, C#). Zumal das C++-Typsystem unentscheidbar ist, und die Typsicherheit eines C++-Programms mithin nicht berechnet und geprüft werden kann. Templates sei Dank...

Den riesigen Vorteil der Trennung zwischen Deklaration und Definition vermag ich nicht zu erkennen. Was ist der Vorteil daran, dass man dieselbe Information an mehreren Stellen verwalten muss, und ein Typ nicht mehr durch eine einzige Datei an einer einzigen Stelle vollständig beschrieben ist? Also aus mehr Editorfenstern? Das Argument, man könnte die Signatur eines Typen so auf einen Blick sehen, lasse ich nicht gelten: Das geht mit jeder anderen Sprache auch, ist das doch nur eine Frage des richtigen Werkzeugs. In C++ schaue ich in die Header-Datei für einen Blick auf die Signatur, in C# lasse ich die IDE eben die Methodenkörper falten. Auch das Argument, dass man den Quelltext so nicht ausliefern muss, wenn man eine Bibliothek weitergibt, zählt nicht. Schließlich könnte man die Beschreibung der Schnittstelle genauso gut während des Übersetzungsvorgangs erzeugen und in die Bibliothek einbetten, oder als separate Datei ausliefern (so wie Haskell und OCaml das tun). Das würde dann auch die leidigen Include-Pfade überflüssig machen und dem Übersetzungsvorgang viel Komplexität nehmen.

Die Komplexität der Sprache C++ verringert sich auch nicht dadurch, dass man mit den Speicher mittlerweile nicht mehr selbst verwalten muss. Im Gegenteil. Man muss sich manchmal sogar erst recht Gedanken um die Lebensdauer eines Objekts machen, um die verschiedenen Objekt- und Speicherverwaltungsmodelle verschiedener Bibliotheken zu vereinen, und zu vermeiden, dass man ein einziges Objekt mit mehreren Referenzzählern versieht. In einem normalen Projekt mit Qt, ITK und boost beispielsweise gibt es drei verschiedene Modelle: den QObject-Baum von Qt, in welchem ein Vater für seine Kinder verantwortlich ist, die LightObject-Hierarchie von ITK, in der jedes Objekt seinen eigenen Referenzzähler verwaltet, und schließlich die generischen Zeiger aus Boost, mit denen man an beliebige Objekte Referenzzähler anhängen kann. In solchen Anwendungen muss man erst Recht über die für Speicher verantwortlichen Objekte und Zeiger nachdenken, um zu vermeiden, dass Objekte doppelt oder gar nicht gelöscht werden, weil man entweder zu viele oder zu wenig sichere Zeiger daran gehängt hat. Dieser Nachteil entsteht aus der Trennung von Objekt und Lebensdauer, und ist inhärent. Keine Bibliothek kann diese Komplexität wieder aus der Sprache entfernen.

Der eigentliche, praktische Unterschied zwischen Zeiger und Referenzen, nämlich das erstere freie und letztere in ihrer Lebensdauer gebundene Objekte referenzieren, ist mittlerweile auch hinfällig, da man in modernen C++ ohnehin keine rohen Zeiger mehr verwendet, und somit jedes Objekt eine gebundene Lebensdauer hat. Wozu also noch rohe Zeiger? Die sind in modernem C++ mehr oder weniger völlig überflüssig, nur wird man sie bedingt durch die Sprache nicht los.

[Leonidas]

Na, dann würde ich doch speziell das lernen, was auf der PSP bzw im Browser genutzt wird und nicht einfach C++. Ich hab den Eindruck, dass du dich da irgendwie festgefahren hast. Vielleicht musst du C++ auch einfach besser kennen lernen, um das abschätzen zu können. Ausreden kann man dir's wahrscheinlich eh nicht mehr.

PSP: C++, Assembler (Gerüchten zufolge), Lua (weniger berauschende Performance, bzw. liegengelassene Interpreter-Projekte).
Browser: auf der Client-Seite kenne ich nur Javascript, Actionscript, sowie diverse Projekte Javascript attraktiver zu machen für die Entwicklung.

Auf meiner PSP läuft auch in D geschriebener Code und C-Code mit an Sicherheit grenzenden Warscheinlichkeit. Aber ich verstehe dein Argument dann irgendwie nicht: "C++ weil das auf PSP und im Browser läuft", was es ja offensichtlich nicht tut. Wirst, wenn du gerade diese zwei Platformen abdecken willst, nicht drumrum kommen zwei Sprachen zu lernen.

Wobei die Frage ist ob es nicht sinnvoller ist, auf Android zu programmieren statt auf der PSP, mit libgdx ist man dann zumindest mehr oder minder platformunabhängig.

[webspider]

Aber ich verstehe dein Argument dann irgendwie nicht: "C++ weil das auf PSP und im Browser läuft", was es ja offensichtlich nicht tut. Wirst, wenn du gerade diese zwei Platformen abdecken willst, nicht drumrum kommen zwei Sprachen zu lernen.

Ich habe nie behauptet C++ liefe auch im Browser, weswegen ich eben für den Zweck andere Sprachen aufgelistet hab. Mir ging es lediglich um das Argument, dass ich mit Python allein nichts bauen kann, was auf dem einem oder anderem laufen würde.

Obs sinnvoller wäre für Android-unterstützende Geräte zu programmieren? Höchstwahrscheinlich. Nur besitze ich kein Smartphone und habe auch eher vor aus eigenenen Interessen etwas auf einem Gerät zu programmieren, welches an einen Controller erinnernde Tasten für die Bedienung von Spielen aufweist.
Allein schon der Gedanke Tekken auf einem iPhone zu Zocken bringt mich zum Schaudern.

[Leonidas]

Mit Python allein kann man nicht alles machen, aber mit C++ allein ebensowenig und nichtmal mit der Kombination aus beiden kommt man weiter :p Wollt nur aufzeigen, dass es halt nicht getan ist, eine Sprache zu können und damit alles erschlagen zu wollen.

Allein schon der Gedanke Tekken auf einem iPhone zu Zocken bringt mich zum Schaudern.

Fairerweise muss man aber zugeben, dass der Analogstick auf der PSP ebenfalls völlig für die Tonne ist. Ich würde heutzutage überlegen ob es nicht interessant wäre Spiele mit Canvas, WebGL und CoffeeScript für den Browser zu schreiben.

[webspider]

Ich würde heutzutage überlegen ob es nicht interessant wäre Spiele mit Canvas, WebGL und CoffeeScript für den Browser zu schreiben.

Klingt besser als der reine HTML5-Ansatz (also das Canvas-Objekt mit Javascript und den von Mozilla dokumentierten Methoden zu nutzen). Der einzige Negativ-Punkt scheint die hier erwähnte Scope-Problematik zu sein, aber ich bin mir recht sicher, dass man das umgangen kriegt. Vielen Dank auch für diesen Hinweis.

Fairerweise muss man aber zugeben, dass der Analogstick auf der PSP ebenfalls völlig für die Tonne ist.

Trotz dessen Unzulänglichkeit haben einige Modder sich tatsächlich einen zweiten symmetrisch zum erstem gelegen verbaut. Mir fehlen immer noch die Worte dafür, aber gut, scheint sinnvoller zu sein als deren andere Spielereien wie zur Tonausgabe reagierende LEDs.

[CM]

Ich habe aber irgendwie das Gefühl, dass einige C++ noch nie wirklich in einem vernünftigen Projekt eingesetzt haben und sich einfach mal über die Sprache aufregen.

Ich schon - und ich teile Deine Einschätzung. Klar ist die Lernkurve bei C++ steiler als bei den meisten Sprachen, aber vielleicht ist es so, daß bei den meisten (Hobby)programmierern ab einer gewissen zusätzlichen Sprache - insb. wenn diese semantisch stark vom Gewohnten abweicht - auch mentale Hürden auftauchen. (Bei mir ist das bei Java sicher der Fall.) Und diese machen es schwer sich in eine neue Sprache einzufühlen. Mein erstes C++-Projekt hat schon Zeit und - meine Frau kann ein Liedchen davon singen - einige Flüche gekostet. Aber wenn man meine ersten Posts hier im Forum betrachtet: Bei Python war das nicht sehr viel anders.

Soviel zum gefühlsdusseligen Teil. Bzgl. Speichermanagement kann ich nun wirklich nicht nachvollziehen, was bei C++ in Verbindung mit boost oder Qt kompliziert sein soll. Gerade bei meinem letzten Projekt ( http://yamas.meb.uni-bonn.de/ - wobei meine Kollegen wohl beim Upload des Quellcodes Mist gebaut haben ...) war die Performance ausschlaggebend und wenn ich denke das mit Java oder C oder Sprache X hätte coden zu müssen .... na ja, letztlich ist das doch wieder Geschmackssache, oder? Memoryleaks habe ich jedenfalls nicht beobachtet. Und auch bei meinem neuen Projekt (noch) nicht.

Gruß
Christian

PS Allerdings finde ich Python schon für viele Dinge viel toller .

[Hyperion]

Bzgl. Speichermanagement kann ich nun wirklich nicht nachvollziehen, was bei C++ in Verbindung mit boost oder Qt kompliziert sein soll.

Beachte dazu meinen Einwand zu Zeigern und Referenzen und vor allem lunars Auslassungen dazu. Oder hast Du eine gute Erklärung dafür, wieso eine Sprache beides braucht? Deine Äußerung lässt ja darauf schließen, dass Du eben keine Zeiger mehr verwendest - insofern könntest Du auf sie doch als semantisches Element auch verzichten, oder? Qt "fühlt" sich imho sogar stark an wie Java - eben weil es auf Sperenzien wie Zeiger verzichtet.

[deets]

@CM & @EyDu

Die Unterstellung, diejenigen, die sich ueber C++ beschweren, haetten keine Ahnung wovon sie reden ist ein bisschen gewagt, findet ihr nicht? Ich arbeite an einer 3 millionen Zeilen C++ Anwendung mit - und der Schmerz gegenueber Python ist *massiv*.

CM, deine Anwendung hat ca. 4500 Zeilen Code - ist also ein sehr kleines und ueberschaubares Projekt. Daraus jetzt abzuleiten, grosse Anwendung, die seit Jahren entwickelt werden, verschiedenste Technologien verwenden, den unterschiedlichsten Paradigmen folgen muessen (SmartPointer, Template-Meta-Programming, PIMPLs usw) waeren genauso einfach ist vermessen.

Was glaubst du was bei uns los ist, wenn eine neue BOOST-Version eingespielt werden soll? Oder welche Probleme wir gerade mit Compiler-Bugs bei der Floating-Point-Optimierung des VS-Compilers haben, der ungefragt zwischen double & single precision switcht, wie es ihm gefaellt?

Natuerlich haben auch grosse Python-Projekte ihre Herausforderungen, und es gibt schlicht Bereiche, in denen es (noch) ungeeignet ist.

Aber > 15 Jahre Software-Entwicklungs-Erfahrung mit Python & C++ sagen mir: wenn es in Python *geht*, mach es darin. C++ ist eine semantisch ueberladene & gleichzeitig erstaunlich schwache Sprache, die ein notwendiges Uebel ist - aber mehr auch nicht.

Natuerlich haben sich im Laufe der Zeit grosse Bibliotheken wie Qt ergeben, die ein vergleichsweise angenehmes Arbeiten erlauben. Doch das ist jahrelanger Arbeit & dem unbedingten Willen zur Verbesserung geschuldet, auch und nicht zu Letzt der Tatsache, dass es sich um eine *Bibliothek* handelt, deren Zielgruppe (bezahlende) Entwickler sind) - nicht um eine Software die nach aussen einfach nur monolithisch ist. Ich selbst habe diverse Paradigmen-Wechsel in Qt mitgemacht, dass noch zur Version 2 viel mehr mit Vererbung und Co gearbeitet hat, und sich erst in Version 4 mit MVC-Pattern & XML-GUI-Resourcen hervorgetan hat.

Und ich wuerde auch CMs Einschaetzung massiv widersprechen, dass eine Sprache *mehr* Huerden aufbaut. Das Gegenteil ist der Fall. Je mehr Sprachen man kennt, desto mehr Konzepte kennt man & kann vergleichen, welche Sprache wo wie Probleme hat.

Und gerade da ist Python ein Beispiel einer Sprache, die von der statischen Typisierung abgesehen eine Vielzahl von Programmierparadigmen - funktional, OO, imperativ/prozedural, deklarativ, aspekt-orientiert, meta-programmierung - unterstuetzt, und daher wesentlich mehr Probleme elegant loesen kann, als das C++ kann.

[lunar]

@CM: Was ich im letzten Beitrag kritisiert habe, entstammt nicht meiner Phantasie, sondern meiner Erfahrung aus einem Projekt mit Qt, ITK und Boost. Gerade an der Schnittstelle zwischen Qt und ITK musste man ziemlich aufpassen, um die Verantwortung für die Freigabe eines Objekts nicht zu versehentlich verteilen. Und aus Gesprächen mit anderen Entwicklern, die ebenfalls mit Qt, ITK und VTK medizinische Anwendungen schreiben, zeigen mir, dass das nicht daher kommt, dass ich mich zu blöd anstelle.

In Ermangelung eines einheitlichen, konsistenten Objekt- und Speicherverwaltungsmodell muss man in C++ an der Schnittstelle mehrerer Bibliotheken immer auf die Objekt-Verantwortlichkeiten achten, sprich wer für die Bereinigung welcher Objekte zuständig ist. Wenn man nur eine Bibliothek verwendet, ist die Sache immer einfacher. Auch bei Deinem Projekt, was - soweit ich das sehe - nur boost verwendet, und auch nicht sonderlich viele Zeilen hat. Speicherverwaltung mit "boost::shared_ptr" ist im Vergleich zur JVM oder CLR im Übrigen furchtbar primitiv, und aufgrund der atomaren Referenzzählerei gerade bei stark nebenläufigen Programmen alles andere als ideal.

[1] Also im Wesentlichen eine Liste von Objekten anlegt, die nach dem (nebenläufigen) Ablauf eines Algorithmus freizugeben sind.

@Hyperion: Qt verwendet Zeiger. Ohne gäbe es gar keine frei lebende Objekte in C++.

[needsch]

@Hyperion: Nein, es fängt ja damit an, dass ich zur Objektorientierung gezwungen werde (bisher halte ich sie noch so lange aus meinem Geschreibsel raus wie ich nichts größeres baue). Wenn man das mit der gewissen Umständlichkeit kombiniert, dem Fakt, dass man ohne IDE wahnsinnig werden kann beim Entwickeln und dass man die meiste Zeit aufgrund uneinheitlicher Benennungen und Vorgehensweisen viel eigentlich unnötigen Code schreiben muss. Wenn so Objektorientierung generell aussieht, na dann gute Nacht. Ich nutze es bisher nur wegen der Uni.

Wunderbar auf den Punkt gebracht!

Aber Java ist so schrecklich bürokratisch

Du meinst Bondage and Discipline?

Schön wär's. Aber nicht mal dafür taugt Java. Viel zu frigide und viel zu hysterisch. Wenn ich nur an die 1000+ zeiligen XML-Konfigurationsdateien und die episch langen Stacktraces denke...

Zum Thema:
C++ zu beherrschen ist eine tolle Sache, man muss sich allerdings sehr intensiv damit befassen. C++ ist deutlich komplexer als andere Programmiersprachen*. Ansonsten solltest du es meiden, wenn es nicht unbedingt auf Performance ankommt.

*Es gibt viele Leute, die behaupten, dass niemand wirklich C++ beherrscht und dass niemals 2 Programmierer die gleichen Aspekte von C++ beherrschen. Dem stimme ich ausdrücklich nicht zu. Man muss bei C++ einfach ein paar harte Nüsse knacken, aber danach kann man sich sehr schnell alles Weitere aneignen (nach Bedarf). Wenn Programmierer zu faul sind, sich in alle zentralen Konzepte einer Sprache einzuarbeiten, dann sind es eben schlechte Programmierer - Ende.

[lunar]

@needsch: Es fällt mir angesichts der Aussage, man könne sich "alles weitere sehr schnell aneignen", sehr schwer, zu glauben, dass Du Dich wirklich mit C++ beschäftigt hast. C++ wirklich in Gänze zu beherrschen, erfordert jahrelange Übung und unglaublich viel Erfahrung. Es ist illusorisch, anzunehmen, dass jeder Programmierer, der C++-Anwendungen warten muss, diese Zeit zur Verfügung hat, oder jede Firma es sich leisten könnte, ihre Entwickler zu C++-Experten auszubilden. Und es ist anmaßend, zu behaupten, alle anderen wären schlechte Programmierer. Solche Aussagen fallen früher oder später knallhart auf Dich zurück...

[deets]

@lunar

du sprichst mir aus der seele - genau dieses cowboy-coder-denken ist unter C++-Freunden halt sehr verbreitet.

Und das Problem ist ja nicht alleine die Semantik der Sprache. Die ist schon komplex genug. Nein, auch noch die vielen verschiedenen Abstraktionen, die operator-ueberladung, templating und macro-expansion in den ganzen Libs beherrscht werden wollen.

Gehen tut das alles. Nur nicht so richtig gut.

[snafu]

Zum "Klassen-Vorwurf" an Java: Naja, es müssen zwar "offiziell" immer Klassen genutzt werden, aber sobald ich ein `static` davor schreibe, fühlt es sich im Grunde auch nicht viel anders an, als ein Modulattribut in Python.

In Python mag vieles leichter von der Hand gehen, aber Java ist keinesfalls völlig unbrauchbar. Es kommt halt stark auf den Anwendungsfall an. Soweit ich das überblicken kann (und das beruht zugegebenermaßen noch nicht auf allzu viel Erfahrung), ist Java für den Einsatz in Wirtschaft und Verwaltung in Betrieben und Ämtern recht gut geeignet - gerade wenn's auf Datenbankabfragen in Netzwerken, Verwaltung von Zugriffsrechten, etc ankommt (was in dem Bereich naturgemäß viel zum Einsatz kommt). Womit ich jetzt natürlich nicht sagen will, dass man das in Python *nicht* könnte - schon klar...

[needsch]

@needsch: Es fällt mir angesichts der Aussage, man könne sich "alles weitere sehr schnell aneignen", sehr schwer, zu glauben, dass Du Dich wirklich mit C++ beschäftigt hast. C++ wirklich in Gänze zu beherrschen, erfordert jahrelange Übung und unglaublich viel Erfahrung. Es ist illusorisch, anzunehmen, dass jeder Programmierer, der C++-Anwendungen warten muss, diese Zeit zur Verfügung hat, oder jede Firma es sich leisten könnte, ihre Entwickler zu C++-Experten auszubilden. Und es ist anmaßend, zu behaupten, alle anderen wären schlechte Programmierer. Solche Aussagen fallen früher oder später knallhart auf Dich zurück...

1. Punkt: Zugegeben, mit einem Hochschulabschluss im Bereich Informatik habe ich eine etwas elitäre Sicht auf diese Dinge.
2. Punkt: Ich verlange nicht, dass man 20%, 50% oder 80% einer Programmiersprache beherrscht, geschweige denn 100%. Ich verlange die Bereitschaft, sich bei Bedarf "alles Weitere", was notwendig ist, anzueignen (bemerke: ich habe meinen vorherigen Beitrag in diesem Punkt präzisiert). Programmierer, die dazu nicht bereit oder nicht fähig sind, sind schlechte Programmierer. Die Komplexität der Programmiersprache ist keine Entschuldigung.

Viele Grüße

[Hyperion]

1. Punkt: Zugegeben, mit einem Hochschulabschluss im Bereich Informatik habe ich eine etwas elitäre Sicht auf diese Dinge.

Mit ersterem bist Du hier sicher nicht der einzige - mit letzterem eher schon; wobei mir auch etwas unklar ist, was ein "elitärer" Blick sein soll! Meinst Du das im Sinne von "abfällig"?

Die Komplexität der Programmiersprache ist keine Entschuldigung.

Die Komplexität einer Sache ist aber oftmals die Motivation, etwas zu verändern und weniger komplex zu gestalten - u.a. deswegen erfinden ja Leute neue Programmiersprachen.
Ob man einen schlechten Programmierer daran erkennt, ob er vor zu großer Komplexität kapituliert, weiß ich nicht - aber einen guten Informatiker erkennt man daran, dass er mit möglichst wenig Komplexität zum Ziel kommt

Ich kann Deine negative Einstellung zu Java diesbezüglich nicht nachvollziehen (Du hast ja weiter oben die Zusammenfassung von webspider als "wunderbar" bezeichnet). Laut Deiner eigenen Definition eines "guten" Programierers müsste Dir ja Java keine Probleme bereiten. Es ist nämlich weit weniger komplex als C++ und mittels einer guten IDE durchaus komfortabel zu programmieren. Und modernes Java kommt dank Annotationen immer mehr ohne XML-Config-Dateien aus. Also fehlt da nur die Bereitschaft, sich das anzueignen?

[BlackJack]

@needsch: Ich habe nicht die Bereitschaft mir bei Bedarf *alles* anzueignen, weil ich im Falle von C++ schon den Bedarf in Frage stelle. Ich bin der Meinung das eine Sprache nicht so komplex sein muss, und habe auch genug Sprachen angeschaut um das jetzt nicht nur auf mein eingeschüchtert sein vor der Komplexität von C++ zu schieben. Es ist eher so, dass mir die Motivation fehlt auf so viele Sachen achten zu müssen, um die sich bei anderen Sprachen der Compiler oder die Laufzeitumgebung kümmert. Macht mich das jetzt tatsächlich zu einem schlechten Programmierer?

[deets]

@needsch

"Bei Bedarf" aneignen also. Woran, wenn man's nicht weiss, erkennt man denn so den Bedarf? Schlechtes Programmieren ist nicht notwendigerweise bedingt durch ein Glasdecke an welche der eine stoesst - und ein anderer hat sie halt nicht.

Sondern oft auch durch schlichtes Unwissen. Und je weniger man wissen muss, und je orthogonaler das ist, was man wissen muss, desto besser. Darum bevorzuge ich Python. Auch gegenueber zB Ruby (wo es dann doch irgendwie immer 3 Arten gibt, dasselbe simple Ding zu machen).

[needsch]

Also nochmal für die Begriffsstutzigen:
"Es gibt viele Leute, die behaupten, dass niemand wirklich C++ beherrscht und dass niemals 2 Programmierer die gleichen Aspekte von C++ beherrschen. Dem stimme ich ausdrücklich nicht zu. Man muss bei C++ einfach ein paar harte Nüsse knacken, aber danach kann man sich sehr schnell alles Weitere aneignen (nach Bedarf). Wenn Programmierer zu faul sind, sich in alle zentralen Konzepte einer Sprache einzuarbeiten, dann sind es eben schlechte Programmierer - Ende."

Bedarf kann es dann geben, wenn man
- in fremden Code, an dem man arbeiten muss, Konstrukte sieht, die man nicht versteht.
- von Arbeitskollegen darauf hingewiesen ist, dass es schlechtes C++ ist, wenn man überwiegend C schreibt
- wenn man den Coding Styleguide liest und darin Begriffe vorfindet, die man noch gar nicht kennt, z.B. Smart pointer
- wenn man ganz konkret von Arbeitskollegen darauf hingewiesen wird, std::string statt C-Strings oder std::vector statt Arrays zu verwenden
- uvm.

Ein professioneller Programmierer wird - und da stimmen mir doch hoffentlich alle hier zu - sich in diesen Fällen zügig das fehlende Wissen aneignen.

Das heißt für mich: Die oben beschriebene Kritik an C++, die Sprache sei so komplex, dass niemals 2 Programmierer die gleichen Teile der Sprache kennen (und daher kaum zusammenarbeiten können), trifft nicht zu. Es sei denn, es handelt sich um unprofessionelle, schlechte Programmierer.

Weiteres:
- Wer kein C++ kann, der ist kein schlechter Programmierer. Wo kämen wir da hin?
- Ich mag Java nicht, das ist korrekt. Bin trotzdem mindestens durchschnittlich im Umgang mit Java und hätte mit Sicherheit keine Probleme im professionellen Einsatz in kürzester Zeit (3-6 Monate) mit den Profis aufzuschließen. Das ist mein persönlicher Anspruch, den konnte ich bisher auch immer einhalten. So war auch das "elitär" gemeint.

Viele Grüße

[BlackJack]

@needsch: Ich bin zu faul mich in alle Konzepte von C++ einzuarbeiten. Ich bin trotzdem so vermessen mich nicht für einen schlechten Programmierer zu halten. Unnötige Komplexität zu vermeiden halte ich für eine gute Eigenschaft bei einem Programmierer.