Aversion gegen Java

hustbaer schrieb:

Ethon_ schrieb:

Sehe jetzt nicht das Problem. Passiert ja nicht so häufig, dass man Resourcen hat, die deterministisch freigegeben werden müssen.

Vielleicht programmierst du gänzlich andere Sachen als ich, aber mein C# Code strotzt vor lauter using (=try with resources).

Blöd ist nur dass using/try with resources viel zu unflexibel ist, so dass man es für manche Sachen nicht verwenden kann.

Ich halte es für guten Stil, soetwas zu abstrahieren, wird im Regelfall auch getan. Roh mit Files oä. arbeite ich doch sehr selten.

hustbaer schrieb:

Ethon_ schrieb:

hustbaer schrieb:

@Ethon_
Wenn du glaubst.
Ich programmiere halt auch C++. Ich baue dabei aber so gut wie nie "versteckte Probleme".

Du produzierst nie Bugs?

Das hab ich nicht geschrieben.
Willst du mich ärgern oder was?

Nein.
Bin nur überzeugt davon, dass C++ Bugs deutlich subtiler sein können als Java-Bugs. Gerade wenn man einen Standard unterhalb C++11 verwenden muss, was jetzt auch nicht so selten ist.

volkard schrieb:

Ethon_ schrieb:

Sehe jetzt nicht das Problem. Passiert ja nicht so häufig, dass man Resourcen hat, die deterministisch freigegeben werden müssen.

Will mich nicht darum kümmern müssen, ob…
Will mich nicht darauf verlassen müssen, daß Kollegen…
Will einfach keine Fehler, die bis zum Kunden durchschlagen.

Im allgemeinen muss ich mich ja in Java um weitaus weniger kümmern weil der Compiler und die JVM viel mehr für mich erledigen. Finde ich bei nicht-performancekritischem Code sehr allgemein.

Bei einem Großteil der Programmierfehler habe ich übrigens nach gefühlt 5 Minuten eine Mail vom Buildserver, der mir sagt, dass ich ein Depp bin.

hustbaer

Ethon_ schrieb:

hustbaer schrieb:

Ethon_ schrieb:

Sehe jetzt nicht das Problem. Passiert ja nicht so häufig, dass man Resourcen hat, die deterministisch freigegeben werden müssen.

Vielleicht programmierst du gänzlich andere Sachen als ich, aber mein C# Code strotzt vor lauter using (=try with resources).

Blöd ist nur dass using/try with resources viel zu unflexibel ist, so dass man es für manche Sachen nicht verwenden kann.

Ich halte es für guten Stil, soetwas zu abstrahieren, wird im Regelfall auch getan. Roh mit Files oä. arbeite ich doch sehr selten.

Bin mir nicht sicher was du jetzt meinst. Bring mal ein Beispiel.

Ethon_ schrieb:

hustbaer schrieb:

Ethon_ schrieb:

hustbaer schrieb:

@Ethon_
Wenn du glaubst.
Ich programmiere halt auch C++. Ich baue dabei aber so gut wie nie "versteckte Probleme".

Du produzierst nie Bugs?

Das hab ich nicht geschrieben.
Willst du mich ärgern oder was?

Nein.
Bin nur überzeugt davon, dass C++ Bugs deutlich subtiler sein können als Java-Bugs.

Und ich sage dass ich kaum solche Bugs fabriziere.
Das heisst nicht nie und es heisst nicht dass ich nicht öfter mal Fehler wo mache auf die man sofort draufkommt.

Wutz

Ethon_ schrieb:

Bei einem Großteil der Programmierfehler habe ich übrigens nach gefühlt 5 Minuten eine Mail vom Buildserver, der mir sagt, dass ich ein Depp bin.

Ach.
Das ist kein Feature oder Vorteil von Java ggü. anderen Sprachen, sondern eine Selbstverständlichkeit, was andere Sprachen natürlich ebenso bieten.

"Designer" einer neuen Programmiersprache (und deswegen natürlicherweise alle Freiheiten haben), die sich OOP auf die Fahnen schreiben und gleichzeitig Boxing/Primitive(Integer/int) Unsinn als (unumgängliches) Sprach"feature" anbieten, gehören gesteinigt und wegen Inkompetenz ignoriert.

Warum habe ich immer das Gefühl, dass solche Diskussionen immer religiös ausarten?

Nennt mich neumodisch, aber für mich sind Programmiersprachen Werkzeuge und ich nehme halt immer das Werkzeug, das gefordert wird. C++ ist ein Schraubenziehr, Java ein Schraubenschlüssel, PHP ist ein fauliger Apfel.

Kellerautomat

Die Programmiersprachen sind doch eh alle scheisse. Man waehle das geringste Uebel.

Wutz schrieb:

Ethon_ schrieb:

Bei einem Großteil der Programmierfehler habe ich übrigens nach gefühlt 5 Minuten eine Mail vom Buildserver, der mir sagt, dass ich ein Depp bin.

Ach.
Das ist kein Feature oder Vorteil von Java ggü. anderen Sprachen, sondern eine Selbstverständlichkeit, was andere Sprachen natürlich ebenso bieten.

Hatte deinen Beitrag ganz überlesen.

Also meiner Meinung nach bieten Java/.NET oä. da schon gewaltige Vorteile.
Statische Analyse ist bei C++ doch stark eingeschränkt.

Da fällt mir bei uns nur valgrind ein, das motzt, wenn im nativen Code Speicherfehler entdeckt werden.

volkard

Ethon_ schrieb:

Also meiner Meinung nach bieten Java/.NET oä. da schon gewaltige Vorteile. Statische Analyse ist bei C++ doch stark eingeschränkt.
Da fällt mir bei uns nur valgrind ein, das motzt, wenn im nativen Code Speicherfehler entdeckt werden.

Ähm. Der C++-Stil ist, stets potentielle Fehler zu Compilerfehlern zu machen. Wer valgrind und Konsorten braucht, sollte sich von mir ein Buch anpassen lassen. Ich arbeite seit 10 Jahren fast ohne Debugger (ein Stündchen pro Monat) und das ist gut so und passt zu C++. Abgesehen davon, daß ich zu faul zum Debuggen bin, tut das C++-mäßige Erzwingen, das Herauspressen von Fehlern, dem Unternehmen grundsätzlich gut, weil Fehler auf dem eigenen Schreibtisch immer viel billiger sind als Fehler beim Kunden. Ich kenne keine andere Sprache (außer Lisp natürlich), die man so pressen kann im Sinne der Fehlervermeidung beim Kunden obwohl Tonnen von Code involviert ist, der historisch gewachsen ist.

volkard schrieb:

Ethon_ schrieb:

Also meiner Meinung nach bieten Java/.NET oä. da schon gewaltige Vorteile. Statische Analyse ist bei C++ doch stark eingeschränkt.
Da fällt mir bei uns nur valgrind ein, das motzt, wenn im nativen Code Speicherfehler entdeckt werden.

Ähm. Der C++-Stil ist, stets potentielle Fehler zu Compilerfehlern zu machen. Wer valgrind und Konsorten braucht, sollte sich von mir ein Buch anpassen lassen.

Welche Buch würdest du da empfehlen? Struppi?

Ich finde, die IDE-Unterstützung bei Java bis dato am Besten.
Wenn ich bei einer Java-IDE "Find Usage (of method/class)", dann bekomme ich wirklich genaue Ergebnisse. Bei Qt Creator kriege ich da auch Quatsch raus.

Bei Java ist es außerdem auch möglich auf Servern Applikationen zur Laufzeit zu patchen.

- Header-Dateien --> Bäh!
- Ändere etwas im Header und du bekommst plötzlich einen Quatsch-Zustand in deiner Software --> Rebuild!
- Muss ich jetzt für 32 Bit, 64 Bit, Windows oder Linux kompilieren? Das sind Fragen, die stellen sich jedes mal, wenn man für einen Kunden kompiliert.
- Ich muss nicht mal Java benutzen. Scala ist deutlich mächtiger, hat auch ein besseres Build-Tool, aber ich habe die Stärken der ausgereiften JVM.

Java hat definitiv Schwächen, aber manche habe sich so sehr an die Schwächen von C++ gewohnt oder sind bereit darüber hinwegzusehen, dass es schon fast eine Beleidigung ist C++ als heiligen Gral darzustellen.

volkard schrieb:

Ethon_ schrieb:

Also meiner Meinung nach bieten Java/.NET oä. da schon gewaltige Vorteile. Statische Analyse ist bei C++ doch stark eingeschränkt.
Da fällt mir bei uns nur valgrind ein, das motzt, wenn im nativen Code Speicherfehler entdeckt werden.

Ähm. Der C++-Stil ist, stets potentielle Fehler zu Compilerfehlern zu machen. Wer valgrind und Konsorten braucht, sollte sich von mir ein Buch anpassen lassen. Ich arbeite seit 10 Jahren fast ohne Debugger (ein Stündchen pro Monat) und das ist gut so und passt zu C++. Abgesehen davon, daß ich zu faul zum Debuggen bin, tut das C++-mäßige Erzwingen, das Herauspressen von Fehlern, dem Unternehmen grundsätzlich gut, weil Fehler auf dem eigenen Schreibtisch immer viel billiger sind als Fehler beim Kunden. Ich kenne keine andere Sprache (außer Lisp natürlich), die man so pressen kann im Sinne der Fehlervermeidung beim Kunden obwohl Tonnen von Code involviert ist, der historisch gewachsen ist.

Das ist die Idee. Funktioniert sicher auch super, wenn man alleine oder in einem sehr kleinen Team arbeit. Large Scale? Eher nicht, sagt die Praxis. Vor allem wenn dutzende C-Libraries in den Mix geworfen müssen, die teilweise fragliche Modelle haben.

ShadowClone schrieb:

Ich finde, die IDE-Unterstützung bei Java bis dato am Besten.
Wenn ich bei einer Java-IDE "Find Usage (of method/class)", dann bekomme ich wirklich genaue Ergebnisse. Bei Qt Creator kriege ich da auch Quatsch raus.

Bei Java ist es außerdem auch möglich auf Servern Applikationen zur Laufzeit zu patchen.

- Header-Dateien --> Bäh!
- Ändere etwas im Header und du bekommst plötzlich einen Quatsch-Zustand in deiner Software --> Rebuild!
- Muss ich jetzt für 32 Bit, 64 Bit, Windows oder Linux kompilieren? Das sind Fragen, die stellen sich jedes mal, wenn man für einen Kunden kompiliert.
- Ich muss nicht mal Java benutzen. Scala ist deutlich mächtiger, hat auch ein besseres Build-Tool, aber ich habe die Stärken der ausgereiften JVM.

Java hat definitiv Schwächen, aber manche habe sich so sehr an die Schwächen von C++ gewohnt oder sind bereit darüber hinwegzusehen, dass es schon fast eine Beleidigung ist C++ als heiligen Gral darzustellen.

Compilezeiten sind das nächste. 50 große Java-Projekte sind so schnell gebaut, dass man es nichtmal mitbekommt und nebenher arbeiten kann.

C++ sind die Buildzeiten teilweise echt übel. 16GB RAM im Arbeitsrechner sind einfach zu wenig, damit die Buildzeiten erträglich werden, will make gerne mal mit -j8 gestartet werden, dann geht der Speicherverbrauch für ld und gcc alleine schon auf deutlich über 10GB hoch. Java würden mir 4GB reichen, ohne dass es lästig und nervig wird.

Techel

Deshalb gibt es bald ein ordentliches Modulsystem, zwar bald, aber besser später als nie.

ShadowClone schrieb:

volkard schrieb:

Ethon_ schrieb:

Also meiner Meinung nach bieten Java/.NET oä. da schon gewaltige Vorteile. Statische Analyse ist bei C++ doch stark eingeschränkt.
Da fällt mir bei uns nur valgrind ein, das motzt, wenn im nativen Code Speicherfehler entdeckt werden.

Ähm. Der C++-Stil ist, stets potentielle Fehler zu Compilerfehlern zu machen. Wer valgrind und Konsorten braucht, sollte sich von mir ein Buch anpassen lassen.

Welche Buch würdest du da empfehlen? Struppi?

Volki, welches Buch?!

hustbaer

k.A. an was volkard denkt, aber ich würde mal die ganzen Effective C++ Teile empfehlen.

volkard

ShadowClone schrieb:

ShadowClone schrieb:

volkard schrieb:

Ethon_ schrieb:

Also meiner Meinung nach bieten Java/.NET oä. da schon gewaltige Vorteile. Statische Analyse ist bei C++ doch stark eingeschränkt.
Da fällt mir bei uns nur valgrind ein, das motzt, wenn im nativen Code Speicherfehler entdeckt werden.

Ähm. Der C++-Stil ist, stets potentielle Fehler zu Compilerfehlern zu machen. Wer valgrind und Konsorten braucht, sollte sich von mir ein Buch anpassen lassen.

Welche Buch würdest du da empfehlen? Struppi?

Volki, welches Buch?!

Anpassen! Dazu bräuchte ich die komplette Programmiervorgeschichte incl aller gelesener Bücher, die Schulnoten in den Hauptfächern seit dem 7. Schuljahr und die Schuhgröße und viel Zeit.

volkard

hustbaer schrieb:

k.A. an was volkard denkt, aber ich würde mal die ganzen Effective C++ Teile empfehlen.

Eher nur den ersten.

volkard

Ethon_ schrieb:

volkard schrieb:

Ethon_ schrieb:

Also meiner Meinung nach bieten Java/.NET oä. da schon gewaltige Vorteile. Statische Analyse ist bei C++ doch stark eingeschränkt.
Da fällt mir bei uns nur valgrind ein, das motzt, wenn im nativen Code Speicherfehler entdeckt werden.

Ähm. Der C++-Stil ist, stets potentielle Fehler zu Compilerfehlern zu machen. Wer valgrind und Konsorten braucht, sollte sich von mir ein Buch anpassen lassen. Ich arbeite seit 10 Jahren fast ohne Debugger (ein Stündchen pro Monat) und das ist gut so und passt zu C++. Abgesehen davon, daß ich zu faul zum Debuggen bin, tut das C++-mäßige Erzwingen, das Herauspressen von Fehlern, dem Unternehmen grundsätzlich gut, weil Fehler auf dem eigenen Schreibtisch immer viel billiger sind als Fehler beim Kunden. Ich kenne keine andere Sprache (außer Lisp natürlich), die man so pressen kann im Sinne der Fehlervermeidung beim Kunden obwohl Tonnen von Code involviert ist, der historisch gewachsen ist.

Das ist die Idee. Funktioniert sicher auch super, wenn man alleine oder in einem sehr kleinen Team arbeit. Large Scale? Eher nicht, sagt die Praxis. Vor allem wenn dutzende C-Libraries in den Mix geworfen müssen, die teilweise fragliche Modelle haben.

Eher nicht, aber wenn überhaupt ein wenig, dann nur in C++, sagt die Praxis. Vor allem wenn dutzende Libraries in den Mix geworfen müssen, die teilweise fragliche Modelle haben.

hustbaer

volkard schrieb:

hustbaer schrieb:

k.A. an was volkard denkt, aber ich würde mal die ganzen Effective C++ Teile empfehlen.

Eher nur den ersten.

Was hältst du von "den Roten"?
Also Exceptional C++, More Exceptional C++, Exceptional C++ Style, C++ Coding Standards?

An die kann ich mich ehrlich gesagt nicht mehr ausreichend erinnern als dass ich sie uningeschränkt empfehlen würde.
Sutter ist grundästzlich gut, aber das heisst ja nicht dass die Bücher alle gut sein müssen

Bitte ein Bit

Ich darf Volkard mal übersetzen: April April

---

Ich glaube Java ist über seinen eigenen Hype gestolpert. Die Sprache soll weniger fehleranfällig sein und man muss nicht mehr auf Resourcen achten. Mit dem Ergebniss dass sehr langsame Programme entstanden, da überall Objekte kopiert wurden, und dass trotzdem Java Programme mit sehr vielen unnötigen Fehler entstanden. Und gerade die langsame Geschwindigkeit einzelner Java Programme kam nicht gut an.

volkard

Bitte ein Bit schrieb:

Ich darf Volkard mal übersetzen: April April

Nicht im Geringsten.