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.
Wirklich viel Entscheidungsraum lässt mir das nicht. Aber gut, ich bräuchte mehr Ressourcen und Einarbeitung um herauszufinden was mir nun wirklich liegt. Eine Sprache zurechtbearbeiten mit an Workarounds erinnernden Mustern gehört wohl eher nicht dazu, sonst hätte ich mit Javascript keinerlei Probleme.
deets hat geschrieben:Es ist auch denke ich in dem urspruenglichen Kontext von der Prozessierung von Listen gemeint. Und da bedingt richtig finde ich. Aber im allgemeinen ganz bestimmt nicht. Alleine der Zwang, vorwaerts-Deklarationen verwenden zu muessen, macht einen riesen Unterschied. Das explizite Speichermanagement ebenso. Und und und.
Nein, ich meine das schon so allgemein wie es dort steht. Mittels der Standardbibliothek, boost und, wie weiter oben schon erwähnt, mit Qt, hat man hervoragende Werkzeuge zur Hand. Natürlich ist es im Allgemeinen mehr Schreibarbeit, aber das bringen die Typsicherheit und die Aufteilung in Deklaration und Defnition (welches bei großen Projekten einen riesigen Vorteil bringt) eben mit sich.
Auch kommt einem bei C++ eigentlich kein explizites Speichermanagement mehr unter. In den meisten Fällen werden boost oder die Standardbibliothek verwendet, die stellen entsprechende Typen für eine automatische Verwaltung bereit. Ohne, dass man groß zusätzlichen Code schreiben müsste.
Hyperion hat geschrieben:Zumal es in Java weniger Konzepte zu verstehen gibt - wieso muss es in C++ Referenzen und Zeiger geben? Hier wäre es imho sinnvoller gewesen, sich auf eines von beiden festzulegen... naja,
Weil Zeiger und Referenzen für ganz Unterschiedliche Dinge da sind. Da C++ doch recht hardwarenah ist, ist über Zeiger jede Adresse explizit zu erreichen. Referenzen hingegen werden genutzt, wenn auf existierenden Objekten gearbeitet wird. Eine Referenz ist niemals uninitialisiert, bei einem Pointer ist das durchaus möglich.
Natürlich verwende ich lieber, wenn möglich, Python als C++. 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.
EyDu hat geschrieben:Natürlich verwende ich lieber, wenn möglich, Python als C++. 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.
Regt sich doch keiner drüber auf. Es wird häufig nur gesagt, dass die Sprache ziemlich komplex ist und für viele Fälle vielleicht ne Hausnummer zu hoch für einen ist. Nur weil man es auch in C++ machen *könnte*, muss man es ja nicht zwangsläufig auch wirklich *tun*, wenn's denn auch einfacher geht.
Ich will nicht sagen: "Nimm bloß kein C++", sondern eher: "Warum denn gerade C++?"
Wenn einer unbedingt mal was in C++ machen will, dann soll er's halt tun...
@EyDu: Ich habe in der Tat C++ noch nicht in einem vernünftigen Projekt eingesetzt, weil ich das mit der Sprache einfach nicht hin bekomme. Und darüber rege ich mich einfach mal auf.
Das man nicht explizit Quelltextzeilen zur Speicherverwaltung schreiben muss, heisst im übrigen nicht, dass man sich über Speicherverwaltung keine Gedanken machen muss, denn man muss ja trotzdem im Auge behalten was wo angelegt wird, wann freigegeben wird, und wann welche Teile eines Objekts unter welchen Umständen kopiert werden.
BlackJack hat geschrieben:Das man nicht explizit Quelltextzeilen zur Speicherverwaltung schreiben muss, heisst im übrigen nicht, dass man sich über Speicherverwaltung keine Gedanken machen muss, denn man muss ja trotzdem im Auge behalten was wo angelegt wird, wann freigegeben wird, und wann welche Teile eines Objekts unter welchen Umständen kopiert werden.
Muss man das nicht letzlich in jeder Sprache, also auch in Python? Gerade in "Extremsituationen", wo mit sehr großen Datenmengen hantiert wird, versuche ich doch auch, meine Objekte nicht länger zu referenzieren als unbedingt nötig, damit sie auch möglichst früh wieder vom GC abgeräumt werden können. Oder war jetzt etwas anderes gemeint?
Im Übrigen soll das oben Gesagte jetzt nicht etwa als Einwand verstanden werden, sondern eher als "Ausweitung" deiner Aussage. Nicht, dass da Missverständnisse aufkommen...
@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.
@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.
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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Leonidas hat geschrieben: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.
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.
webspider hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Leonidas hat geschrieben: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.
Leonidas hat geschrieben: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.
EyDu hat geschrieben: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 .
CM hat geschrieben:
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.
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.
@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++.
webspider hat geschrieben:@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!
Hyperion hat geschrieben:
webspider hat geschrieben: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.
Zuletzt geändert von needsch am Donnerstag 26. Januar 2012, 23:21, insgesamt 1-mal geändert.
@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...
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.
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...
lunar hat geschrieben:@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.
.
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...