Mit welcher Sprache anfangen?

tntnet

@Gregor: und ich soll Deine Kommentare unkommentiert lassen? Das kannst Du nicht erwarten. Wir sind hier schliesslich in einem Diskussionsforum.

Ich versuche, meine Aussagen stets sachlich und ohne Seitenhiebe, wie z. B. "...umgekehrt stimmt das übrigens auch." zu formulieren (oh - das könnte ein Seitenhieb gewesen sein ).

Daß Java-Programmierer ihre liebe Not damit haben, sich das new abzugewöhnen, ist meine persönliche Erfahrung. Das wollte ich hier einfach mal einwerfen. Ich glaube nicht, daß das unbedingt einen Flame-war auslösen muß.

Wobei ich diesen Thread gar nicht so auffassen möchte. Hier kommt doch wieder einmal eine sachliche Diskussion rüber, die den originalen Frager, der sich über verschiedene Programmiersprachen informieren möchte, helfen sollte.

Und nun wieder zum Flame-war. Oh sorry - ich meinte natürlich zum Thema.

Was ich an C++ sehr schätze sind Destruktoren. Die gab es auch schon von anfang an. Daher ist die Verwendung von "new" ausserhalb von engen Grenzen (eine Klasse nämlich) in der Regel nicht notwendig. Das hat nichts damit zu tun, wann man C++ "sich beigebracht hat", bzw. gelernt hat (eigentlich komisch, daß man andere Dinge lernt und Programmieren bringt man sich bei ),

Bevor Templates in C++ einzug gehalten haben, habe ich mir 2 Makros geschrieben: DEFINE_ARRAY und DECLARE_ARRAY, welches typsichere dynamische Vektoren definiert haben. Das war so ca. 1992. Auch eine String-Klasse habe ich geschrieben. Von daher sehe ich es noch nicht mal so, daß sich die Programmierung in C++ so massiv verändert hat. Natürlich verwende ich heute std::vector und std::string. Aber das Grundprinzip ist gleich geblieben. Und auch das schätze ich an C++.

Diese Konstanz der Sprachdefinition ist doch einfach Klasse. Programme, die vor 15 Jahren geschrieben wurden, kann man mit modernen C++-Compilern noch compilieren und ausführen. Und ich denke, daß wir die Programme, die wir heute schreiben auch in 15 Jahren noch verwenden können. Diese Konstanz müssen andere Programme erst mal beweisen. Da habe ich so meine Bedenken.

Tntnet

ten

Gregor schrieb:

In welcher Reihenfolge sich der Autor mit den beiden Sprachen beschäftigt hat, ist mir nicht auf Anhieb klar. Ich vermute eher, dass er C++ früher gemacht hat als Java.

ich kann mir auch gut vorstellen, das für oop-fans, die sich einst mit c++ herumgequält haben, java oder C# wie eine offenbarung sein muss

nep

Also ich denke schon, dass es prinzipiell immer noch wichtig ist zumindest zu wissen wie Ressourcenverwaltung (also new/delete usw...) funktioniert. Vielleicht ändert sich das mal, aber im Moment finde ich nicht. Man kann übrigens auch in Java mit GC Memory Leaks erzeugen. Wenn man aber etwas darüber bescheid weiß kann man sowas evtl. vermeiden.
Deshalb find ich es prinzipiell auch nie verkehrt wenn jemand z.B. mit C++ anfängt zu programmieren. Selbst wenn man dann später mal eine andere Sprache benutzen wird, wird das Wissen dass man sich mit C++ angeeignet hat, sicherlich nicht unnütz sein

tntnet

ten schrieb:

Gregor schrieb:

In welcher Reihenfolge sich der Autor mit den beiden Sprachen beschäftigt hat, ist mir nicht auf Anhieb klar. Ich vermute eher, dass er C++ früher gemacht hat als Java.

ich kann mir auch gut vorstellen, das für oop-fans, die sich einst mit c++ herumgequält haben, java oder C# wie eine offenbarung sein muss

Also ich quäle mich mit C++ nicht herum. Ich quäle mich eher mit Java rum, da mir in Java so vieles fehlt, was ich in C++ zu schätzen gelernt habe. Java ist für mich persönlich keine Offenbarung sondern ein Rückschritt.

Was immer wieder vergessen wird ist, daß es noch andere Resourcen ausser Speicher, die frei gegeben werden müssen, wie z. B. Locks, Transaktionen, Filehandles, temporäre Dateien usw. . All das kann ich automatisch im Destruktor der Klasse implementieren, welche dafür zuständig ist. Fehlt mir der Destruktor, wie in modernen Sprache, die GC verwenden, muß ich die Resourcen explizit frei geben.

Tntnet

Simon2

nep schrieb:

...
Deshalb find ich es prinzipiell auch nie verkehrt wenn jemand z.B. mit C++ anfängt zu programmieren....

Ich auch nicht.
Aber es ist IMO auch kein Drama, mit Java anzufangen - bzw. inzwischen unterscheide ich zwischen Leuten, die schnell was auf die Beine stellen wollen/müssen und solchen, die sich lieber gründlich mit einem Thema beschäftigen wollen. Ersteren rate ich eher zu Java, letzteren zu C++. (allerdings sage ich Ersteren auch, dass sie das, was sie an Anfang sparen hinterher doppelt "nachzahlen" müssen).

nep schrieb:

...
...wird das Wissen dass man sich mit C++ angeeignet hat, sicherlich nicht unnütz sein

"Unnütz" sowieso nicht. Es ist auch nicht unnütz, was mein Kollege in Host-ASM und PL1 weiß ... aber es wird zunehmend zu Spartenwissen, das immer weniger Leute beherrschen müssen. Das wird bei uns nur noch in der Systemprogrammierung gebraucht - und das machen in unserer Firma vielleicht 10-20 von 600 Leuten. Von den Anderen programmieren der Großteil nur Java, ein kleinerer Mal Java, mal Cobol und vielleicht 80 Leute C oder C++.
D.h. nur ein 6tel unserer Programmierer haben jemals Erfahrung mit manueller Ressourcenverwaltung gemacht (die "alten" Programmiersprachen wie Cobol haben das ja alles auch nicht) - und da sind beileibe nicht nur Programmiergurken dabei.

EDIT: Hier war tntnet mit dem Argument schon schneller:
Ach ja: GC wird IMO in beiden Richtungen überschätzt -

tntnet schrieb:

...
Was immer wieder vergessen wird ist, daß es noch andere Resourcen ausser Speicher, die frei gegeben werden müssen, wie z. B. Locks, Transaktionen, Filehandles, temporäre Dateien usw. ...

D.h.
- das müssen sie genauso machen (also nix mit "Mit GC kann nichts mehr passieren") aber auch:
- Dadurch haben auch Java-und Cobol-Programmierer Erfahrung mit Ressourcenverwaltung (wenn auch nicht mit so schönen Sprachmitteln wie bei C++ ).

Ich denke einfach, dass dieses Thema an Gewicht verlieren wird, weil einem immer mehr von OS, Runtime, ... abgenommen und es deswegen irgendwann nur noch von Leuten gebraucht wird, die sowas programmieren.

Gruß,

Simon2.

P.S.: Mein "Host-ASM-Kollege" ist übrigens sehr gefragt mit seinem Spezialwissen und hat sehr lukrative Jobs - auch ein Argument, was man bei der Frage, ob man sich mit "alten Techniken" beschäftigt, mal durch den Kopf gehen lassen sollte.

ten

tntnet schrieb:

Was immer wieder vergessen wird ist, daß es noch andere Resourcen ausser Speicher, die frei gegeben werden müssen, wie z. B. Locks, Transaktionen, Filehandles, temporäre Dateien usw. . All das kann ich automatisch im Destruktor der Klasse implementieren, welche dafür zuständig ist. Fehlt mir der Destruktor, wie in modernen Sprache, die GC verwenden, muß ich die Resourcen explizit frei geben.

das stimmt natürlich.
ich hatte mal eine java-klasse gebastelt, die automatisch eine netzwerkverbindung aufmacht und sich anmeldet. kurz vor ende der objektlebenszeit musste noch was über's netz geschickt werden. eigentlich eine aufgabe für einen destruktor. ich hab' dann einfach 'finalize()' überschrieben (in einen try/catch block mit super.finalize(), wie sich das gehört) und das klappte problemlos. der einzige nachteil ist, dass man es nicht ganz exakt zeitlich steuern kann (genau jetzt musst du dich abmelden).

DEvent

Ihr mit eueren Destructoren...

Was immer wieder vergessen wird ist, daß es noch andere Resourcen ausser Speicher, die frei gegeben werden müssen, wie z. B. Locks, Transaktionen, Filehandles, temporäre Dateien usw. . All das kann ich automatisch im Destruktor der Klasse implementieren, welche dafür zuständig ist. Fehlt mir der Destruktor, wie in modernen Sprache, die GC verwenden, muß ich die Resourcen explizit frei geben.

In C++ musst du externe Ressourcen auch explizit freigeben, seit wann macht das der Destructor automatisch? Du musst auch in C++ einen Destruktor definieren, in dem steht: Gibt mir die Ressource frei. Das ist in Java nur an einer anderen Stelle.

Du hast die Möglichkeiten: a) finallize() und b) eine Methode dispose() oder so zu definieren. Ein Destruktor ist auch nichts weiter als eine Methode, die aber halt implizit aufgerufen wird, wenn du das Objekt zerstörst.

Ein GC soll einem nur dir Speicherverwaltung von spracheigenen Ressourcen abnehmen, nicht mehr und nicht weniger.

das stimmt natürlich.
ich hatte mal eine java-klasse gebastelt, die automatisch eine netzwerkverbindung aufmacht und sich anmeldet. kurz vor ende der objektlebenszeit musste noch was über's netz geschickt werden. eigentlich eine aufgabe für einen destruktor. ich hab' dann einfach 'finalize()' überschrieben (in einen try/catch block mit super.finalize(), wie sich das gehört) und das klappte problemlos. der einzige nachteil ist, dass man es nicht ganz exakt zeitlich steuern kann (genau jetzt musst du dich abmelden).

Auf die Idee eine Methode disconnect() zu definieren bist du nicht gekommen?

Daß Java-Programmierer ihre liebe Not damit haben, sich das new abzugewöhnen, ist meine persönliche Erfahrung. Das wollte ich hier einfach mal einwerfen. Ich glaube nicht, daß das unbedingt einen Flame-war auslösen muß.

Das ist ja auch nachvollziehbar, alle Objekte in Java werden mit new erstellt, und ist auch für die Sprache Java o.k.

inzwischen unterscheide ich zwischen Leuten, die schnell was auf die Beine stellen wollen/müssen und solchen, die sich lieber gründlich mit einem Thema beschäftigen wollen. Ersteren rate ich eher zu Java, letzteren zu C++. (allerdings sage ich Ersteren auch, dass sie das, was sie an Anfang sparen hinterher doppelt "nachzahlen" müssen).

Also das ist ja Blödsinn hoch 3. Auch in C++ kann man "mal schnell was auf die Beine stellen" und dann hinterher Designfehler ausbügeln. Hast du vor 10 Jahren auch Leuten geraten in Assembler zu programmieren, weil man in Asm ja so viel effezientere Programme schreiben kann?

ten

DEvent schrieb:

das stimmt natürlich.
ich hatte mal eine java-klasse gebastelt, die automatisch eine netzwerkverbindung aufmacht und sich anmeldet. kurz vor ende der objektlebenszeit musste noch was über's netz geschickt werden. eigentlich eine aufgabe für einen destruktor. ich hab' dann einfach 'finalize()' überschrieben (in einen try/catch block mit super.finalize(), wie sich das gehört) und das klappte problemlos. der einzige nachteil ist, dass man es nicht ganz exakt zeitlich steuern kann (genau jetzt musst du dich abmelden).

Auf die Idee eine Methode disconnect() zu definieren bist du nicht gekommen?

nö, das wollte ich nicht.
das objekt sollte alles selbständig machen (es hat dafür auch einen eigenen thread), verbindung aufbauen, daten in eine queue schieben...und wenn es fertig ist, sich abmelden und tschüss.

Artchi

DEvent! tntnet meinte sowas:

void foo()
{
    fstream f("test.txt");
} // f wird autom. close() aufrufen

void foo()
{
   try{
    FileInputStream f = new FileInputStream("test.txt");
    f.close();   // muß ich selber dran denken...
   }catch(FileNotFoundException e)
   {}
}

Wenn ich in Java nicht close() aufrufe, wird f dann geschlossen, wenn der GC Lust und Laune hat. Das im fstream-Dtor einmal auch close() stehen muß, ist klar. Aber es steht nur einmal vom fstream-Entwickler, aber nicht vom Anwender. Das ist der springende Punkt.

Simon2

DEvent schrieb:

Ihr mit eueren Destructoren...

Naja, sie geben einem eben eine synchronisierbare automatische Möglichkeit des Aufräumens. In Java gibt's das halt nicht (automatisch schon, synchronisierbar nicht). Wie wichtig dieses Mittel für eine Sprache ist, muß jeder selbst entscheiden (für mich ist es kein KO-Kriterium) ....

DEvent schrieb:

Daß Java-Programmierer ihre liebe Not damit haben, sich das new abzugewöhnen, ist meine persönliche Erfahrung. Das wollte ich hier einfach mal einwerfen. Ich glaube nicht, daß das unbedingt einen Flame-war auslösen muß.

Das ist ja auch nachvollziehbar, alle Objekte in Java werden mit new erstellt, und ist auch für die Sprache Java o.k.

Hat auch niemand etwas Anderes behauptet. Es geht mehr um die "Kommunikationskultur" hier im Forum ... wenn man weiß, dass jemand von Java herkommt, kann man gezielter Tipps geben ... und bisweilen legt eine in C++ unübliche Verwendung von new es nahe, dass das auf den Fragesteller zutrifft.
(alles noch vollkommen OK)
Wenn man (ich) dann das aber anspricht (z.B. um zielgerechter antworten zu können), gibt es Leute hier, die das gleich zum Anlass für einen Flame-war nehmen.
(Nicht OK)

Nach meiner letzten (vollkommen neutralen) Bemerkung in so einer Situation hatte ich auch über eine Woche lang hier einen Stalker an den Hacken wie ein LKW einen kläffenden Hund.....

Das darf man IMO gerne mal beklagen.

DEvent schrieb:

inzwischen unterscheide ich zwischen Leuten, die schnell was auf die Beine stellen wollen/müssen und solchen, die sich lieber gründlich mit einem Thema beschäftigen wollen. Ersteren rate ich eher zu Java, letzteren zu C++. (allerdings sage ich Ersteren auch, dass sie das, was sie an Anfang sparen hinterher doppelt "nachzahlen" müssen).

Also das ist ja Blödsinn hoch 3. Auch in C++ kann man "mal schnell was auf die Beine stellen" und dann hinterher Designfehler ausbügeln. Hast du vor 10 Jahren auch Leuten geraten in Assembler zu programmieren, weil man in Asm ja so viel effezientere Programme schreiben kann?

Was hat denn ASM jetzt damit zu tun ? ASM und C++ unterscheiden sich durch grundsätzlich andere Abstraktionsstufen ... C++ und Java nicht.
Und von "effizienten Programmen" habe ich IIRC auch nichts geschrieben... ich verstehe den Vergleich und deswegen Deine Aussage hier nicht.

Nach meiner Erfahrung kommt man als Anfänger mit Java "schneller zum Schuß" als in C++ - nicht mehr und nicht weniger. Kann sein, dass Andere abweichende Erfahrungen gemacht haben, das ändert aber genausowenig an meinen wie der Umstand, dass der Grund dafür nur zum geringeren Teil an der Sprache selbst liegt.
(Es wäre übrigens guter Stil, auf Pauschalaussagen wie "Blödsinn hoch 3" zu verzichten. Die bringen nichts ein und sollen nur ein Thema mit einem "Dicke-Eier-Faktor" versehen, der der Diskussion nie weiterhilft).

Gruß,

Simon2.

tntnet

@Artchi: Genau das meinte ich. Und das Java-Beispiel ist ein gutes Beispiel dafür, was man da falsch machen kann. Korrekterweise gehört der Aufruf von close grundsätzlich in einen finally-Block, da man mit der Datei in der Regel was machen möchte, was wiederum eine Exception werfen könnte (wobei das aufgrund der Methodensignatur in der Java-Variante nicht erlaubt wäre, d.h. bei der Verarbeitung darf kein Fehler auftreten - könnte man ja auch mal diskutieren ). Etwa so:

void foo()
{
   try{
    FileInputStream f = new FileInputStream("test.txt");
    try {
      // mach was mit der Datei, sonst macht das öffnen keinen Sinn
    }
    finally {
      f.close();   // muß ich selber dran denken...
    }
   }catch(FileNotFoundException e)
   {}
}

Da wird noch deutlicher, daß die Verantwortung, die Resource aufzuräumen beim Anwender der Klasse statt bei der Klasse selbst liegt, wie das bei C++ der Fall ist. Ich finde, die C++-Lösung eleganter:

void foo()
{
    fstream f("test.txt");
    // mach was mit der Datei, sonst macht das öffnen keinen Sinn
} // f wird autom. close() aufrufen

Und danke Simon2 für den Hinweis auf die Kommunikationskultur. Da kann ich Dir nur zustimmen.

Tntnet

Artchi

Die Kommunikationskultur hier im Forum beruht darauf, das C++ grundsätzlich bullshit ist. Wenn ein Newbie C++ lernen will, um ein konkretes Problem zu lösen, wird ihm auch schon mal von C++ abgeraten. Ohne nennenswerte Begründung... einfach nur "C++ ist eh doof, aber XY ist besser dafür geeignet.". Jüngstes Beispiel von heute:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-171250.html
Theoretisch kann man jeden Tag sowas hier als Beispiel aufführen.

Du kannst hier im Forum praktisch nicht einmal pro C++ sein, ohne das jemand aus einem _anderen_ Lager kommt, und C++ für bullshit erklärt.

Selbst wenn man in Sprache XY etwas nicht für ganz optimal hält, ist C++ sowieso bullshit. Das ist so, als ob ich an einem Mercedes den Kühlergrill nicht so toll finden würde, und mir ein Benzfahrer darauf hin sagt "Dein BMW ist der letzte Dreck!". Was ist das für eine Diskussion?

Und in Sprache XY ist es ja by-design so gewollt, und deshalb gut und richtig. Aber was bei C++ by-design ist, ist eh bullshit, weil im C++ Komitee eh nur Assis sitzen, die 1998 eh alles falsch entschieden haben.

Und Dtors sind auch bullshit. Auch Stackobjekte die sich alleine aufräumen können sind auch bullshit.

ten

Artchi schrieb:

Wenn ein Newbie C++ lernen will, um ein konkretes Problem zu lösen, wird ihm auch schon mal von C++ abgeraten.

was auch gerechtfertigt ist.
für newbies ist c++ ein ziemlicher hammer.
wer noch nie programmiert hat, der hat mit c++ mehr frust als spass.
und selbst erfahrene programmierer kann c++ an den rand der verzweiflung bringen.
(ich erinnere dich nur mal an dein problem mit den wchar_t/unicode-streams)

Artchi

ten schrieb:

Artchi schrieb:

Wenn ein Newbie C++ lernen will, um ein konkretes Problem zu lösen, wird ihm auch schon mal von C++ abgeraten.

was auch gerechtfertigt ist.
für newbies ist c++ ein ziemlicher hammer.
wer noch nie programmiert hat, der hat mit c++ mehr frust als spass.

Das Thema hatten wir schon mal diskutiert. Meinung einiger C++ler (Simon2, tntnet u.a.) ist, das dieser Frust vermeidbar wäre, würde man die Einsteiger zu Anfang (!) nicht mit char*-Strings, dynamische Plain-Arrais und sonstigen Pointer-Geschichten belästigen. Denn wie wir wissen, gibt es für eine einfache Nutzung und vorallem Erlernung der Sprache eine String-Klasse, Vectoren, Referencen, Stackobjekte und ab C++2009 auch definitiv Sharedpointer.
Gut, werden wieder einige sagen, das sind keine Build-In-Core-Features. Aber gut... jedes mal die selber Leier.

Ich halte es aber auch für ein elitäres "Gehabe", wenn man sagt, das C++ nur für erfahrene Programmierer ist. Genau das gleiche wie bei Windows vs. Linux. Ich habe schon so manchem jungen Kollegen/in, die nur Java oder VB programmiert haben, die string-Klasse u.ä. von C++ gezeigt. Meiste Reaktion: "Das ist ja praktisch wie in Java?!" Klar, um so weiter man vordringt, um so mehr gibts, was nicht wie Java ist. Aber für die tägliche Arbeit (Strings, Datencontainer, eigene Klassen usw.) kann man es einfach "haben".

Hier gilt der Spruch: "Warum einfach, wenn es auch kompiliziert geht?" Die meiste C++ Einsteiger-Literatur geht danach. Kenne nur ein gutes deutschen C++-Buch, welches den einfachen C++-Weg geht.

ten schrieb:

und selbst erfahrene programmierer kann c++ an den rand der verzweiflung bringen.

Kann ich von mir nicht behaupten.

(ich erinnere dich nur mal an dein problem mit den wchar_t/unicode-streams)

Ehm... du meinst als ich einen wstring in einen filestream rausschreiben wollte? Du kannst den Thread ruhig hier nochmal verlinken... ich war da jedenfalls nicht verzweifelt. Ich war lediglich verwundert. Sowas fällt aber unter "Unwissenheit", die einem in jeder Sprache passieren kann.
Die Lösung des "Problems" ist einfach nur eine fehlende Implementierung, die man durch eine einfache gewünschte austauschen kann. Dabei liegt die Betonung auf "kann", was sagt, das C++ einem hier bewusst by-design eine Option per Facet (codecvt) überlässt:

http://www.kharchi.de/codecvt.png

Jetzt wo ich mich damit beschätigt habe, weiß ich für die Zukunft bescheid. Dieses Thema wird aber leider stiefmütterlich in der C++ Literatur behandelt. DAS ist etwas was man den Buchautoren ankreiden muß, aber nicht C++.

Simon2

ten schrieb:

Artchi schrieb:

Wenn ein Newbie C++ lernen will, um ein konkretes Problem zu lösen, wird ihm auch schon mal von C++ abgeraten.

was auch gerechtfertigt ist.
für newbies ist c++ ein ziemlicher hammer.
wer noch nie programmiert hat, der hat mit c++ mehr frust als spass.

Hi,

das finde ich auch übertrieben.
Es ist nach meiner Erfahrung eben nur so, dass "Mal-eben-nebenbei-Einsteiger" oftmals auf "Clickibunti-Programme" stehen. Das ist doch der typische Newbie-Thread: "Habe noch nie was programmiert, will aber mal eben ein MMORPG mit eingebautem Chat schreiben".
Den Leuten rate ich zu java, weil Java für diesen Ansatz viel mehr bietet (nicht die Sprache, sondern das "Produkt" !).
Ich will jetzt gar nicht den "Chat-Programmierer" schlechtreden - immerhin sind Internet und Spiele üblicherweise die ersten (und lange auch einzigen) Kontaktflächen zum PC.

Aber: Es gibt Leute, die bleiben bei "eben-mal-nebenbei" .... und es gibt andere, die sich zunehmend für das Grundsätzliche interessieren und die mehr Energie und Mühe reinstecken wollen. Die sind immer noch Einsteiger, aber mit denen kann man auch über Programmstruktur, Ressourcen, Multithreading, .... reden und bleibt nicht auf dem Level von "Wie bekomme ich diese WinAPI-Funktion so hin, dass sie tut, was ich will ?". Denen würde ich C++ empfehlen, weil es (als Sprache) viele Konzepte anbietet, um sich damit auseinanderzusetzen.

Für Erstere sind ein anderes Beispiel "Sprachumsteiger" in unserer Firma, die jahr(zehnt)elang COBOL programmiert haben und nun binnen kürzester Frist in einem OO-Projekt lauffähigen Code abliefern müssen. Die werden von Java (wieder: das "Produkt" !) stärker an die Hand genommen. (Wichtig dabei: Die "Tester" sind in einer anderen Abteilung :p )

Lange Rede, kurzer Sinn: Einsteigern würde ich Java oder C++ empfehlen .... je nach Ausrichtung.

Gruß,

Simon2.

P.S.: Bitte beachten, dass ich nirgendwo geschrieben habe, Java-Programmierer seien alles "Clickibunti"-Programmierer oder Einsteiger oder sonstwie schlechter als andere Menschen.

Artchi

Simon2! Der Disclaimer ist genial!

Simon2

Artchi schrieb:

Simon2! Der Disclaimer ist genial!

Ja, man muß langsam aber sicher catch-Blöcke einführen

Gruß,

Simon2.

DEvent

Was hat denn ASM jetzt damit zu tun ? ASM und C++ unterscheiden sich durch grundsätzlich andere Abstraktionsstufen ... C++ und Java nicht.
Und von "effizienten Programmen" habe ich IIRC auch nichts geschrieben... ich verstehe den Vergleich und deswegen Deine Aussage hier nicht.

Nach meiner Erfahrung kommt man als Anfänger mit Java "schneller zum Schuß" als in C++ - nicht mehr und nicht weniger. Kann sein, dass Andere abweichende Erfahrungen gemacht haben, das ändert aber genausowenig an meinen wie der Umstand, dass der Grund dafür nur zum geringeren Teil an der Sprache selbst liegt.
(Es wäre übrigens guter Stil, auf Pauschalaussagen wie "Blödsinn hoch 3" zu verzichten. Die bringen nichts ein und sollen nur ein Thema mit einem "Dicke-Eier-Faktor" versehen, der der Diskussion nie weiterhilft).

Das bezog sich auf dein:

(allerdings sage ich Ersteren auch, dass sie das, was sie an Anfang sparen hinterher doppelt "nachzahlen" müssen).

Deswegen der Vergleich Asm zu C++, weil dein "Hinweis" in den Klammern ist wie ein Asm-Programmierer zu C++ sagen würde, "C++ ist kannst du schneller programmieren als in Asm, aber was du bei C++ einsparst musst du hinterher doppelt "nachzahlen"

Simon2

DEvent schrieb:

...
Deswegen der Vergleich Asm zu C++, weil dein "Hinweis" in den Klammern ist wie ein Asm-Programmierer zu C++ sagen würde, "C++ ist kannst du schneller programmieren als in Asm, aber was du bei C++ einsparst musst du hinterher doppelt "nachzahlen"

Aha !!

Jetzt verstehe ich Dein Argument. Danke.

Allerdings sehe ich das inhaltlich immer noch anders: C++ hat einen deutlich höhere "Design- und Compile-Hürde" als Java (und erst Recht als ASM). Diese Hürde ist allerdings nicht Schikane, sondern hat oft zur Folge, dass einige Inkonsistenzen schon zur Entwicklungszeit auffallen, die ohne diese Hürde erst in der Testphase auffallen. Wenn dort andere Leute als die Entwickler sitzen (wie es bei größeren Unternehmen häufig der Fall ist), vergrößert sich höchstwahrscheinlich dadurch der Gesamtaufwand gegenüber der "Compilezeit-auffall-Variante".
Das ist an sich nichts Schlechtes, sondern kann sich im Schnitt immer noch rechnen ... man darf diesen Aufwand nur nicht unter den Tisch fallen lassen, wenn man sich ein realistisches Bild von den verschiedenen Sprachen machen will (Die Werbeaussage "Mit Java kommen Sie schneller zu lauffähigem Code" verschweigt das nämlich gerne).

Das ist jetzt nicht nur meine Privatmeinung, sondern wurde von unserem Java-Dozenten unbd Berater (extern) so geäußert.

Um damit Deine ursprüngliche Frage zu beantworten:

... Hast du vor 10 Jahren auch Leuten geraten in Assembler zu programmieren, weil man in Asm ja so viel effezientere Programme schreiben kann? ...

Nein.
Und heute tue ich das auch nicht.
Und in diesem Thread und Anderen kannst Du nachlesen, dass ich durchaus der Meinung bin, dass "mit der Technik mithalten" auch bedeutet, seine Programmierparadigmen mitzuwechseln.

Gruß,

Simon2.

Simon2.0 wurde in VBScript geschrieben.