Aversion gegen Java

LordJaxom

Ethon_ schrieb:

Arbeitet hier überhaupt jemand produktiv mit Java?
Ich entwickle beide Sprachen parallel und Java ist weitaus angenehmer und macht deutlich weniger Probleme. Aus dem Grund wird C++ auch nur selektiv eingesetzt.
Wenn es Probleme gibt, dann sind die meistens im C++ Code versteckt. Und versteckt trifft es gut.

Mit geht es genau anders herum. Ich arbeite produktiv mit Java (hauptsächlich Backend) und stolpere regelmäßig über die, ich sag's mal, fehlende Ausdrucksstärke dieser Sprache (der Fairness halber muss ich aber auch eingestehen bin ich regelmäßig begeistert vom Umfang des Ökosystems).

Privat entwickle ich momentan ausschließlich C++ in den Bereichen Embedded, Tools und (seltener) GUI und freue mich immer wieder, wie vielfältig diese Sprache ist. Probleme habe ich dabei eher wenig. Hier und da mal ein kleiner Crash, weil ich eine lokale Variable per Referenz an ein Lambda gebunden habe :D, aber sonst... Und auch hier gilt zumindest für die genannten Bereiche ("Enterprise" ist sicher nicht der Hauptanwendungsfall für C++), dass es kaum etwas gibt, was nicht irgendwo jemand schonmal gemacht hat, meist sogar in Boost, welches ich sowieso immer verwende.

LordJaxom schrieb:

Privat entwickle ich momentan ausschließlich C++ in den Bereichen Embedded, Tools und (seltener) GUI und freue mich immer wieder, wie vielfältig diese Sprache ist. Probleme habe ich dabei eher wenig. Hier und da mal ein kleiner Crash, weil ich eine lokale Variable per Referenz an ein Lambda gebunden habe :D, aber sonst... Und auch hier gilt zumindest für die genannten Bereiche ("Enterprise" ist sicher nicht der Hauptanwendungsfall für C++), dass es kaum etwas gibt, was nicht irgendwo jemand schonmal gemacht hat, meist sogar in Boost, welches ich sowieso immer verwende.

Ja - betonung auf privat! Ich mag C++ ja auch und habe damit echt viel privat entwickelt, alles okay. Aber wenn 50 Leute auf einer Codebasis arbeiten dann sind Probleme weitaus häufiger als wenn das Ganze mit Java passiert. Meiner Erfahrung nach.

hustbaer schrieb:

@Ethon_
Ergibt sich irgendwie von selbst dass man bei Dingen die man deutlich seltener macht auch deutlich mehr Fehler macht

Och, habe jahrelang nur C++ programmiert, an meinem Können soll es nicht scheitern.

hustbaer

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

Artchi

Ich arbeite seit 15 Jahren beruflich mit Java.

Wie hier schon oft gefallen, ist das Ökosystem sehr gut ausgebaut. Man bekommt für alles was man braucht und nicht braucht eine Lösung. Das macht die gesamte Java-Welt sehr professionell.

Aber es gibt auch in der Sprache ein paar Dinge, wo man sich Workarounds bauen muss: täglich wird die Kapselung gebrochen! Und das von Profis, egal ob in Magazinen, Konferenzen und Real-Projekten. Weil es keine const-correctness wie in C++ gibt.
Workaround: Immutable Objects bauen oder diffensive Kopien benutzen!

Dann gibts noch so Dinge wie die OSGi-Plattform, die ja ne nette Idee ist. Aber innerhalb der Eclipse-IDE immer wieder Ärger macht (Plug-ins werden beim Product-Export nicht gefunden, weil die Patch-Versionen sich nicht finden lassen). Und das Austauschen von Bundles/Plug-ins zur Runtime ist nur im Traum möglich.

Durch die fehlenden Destruktoren bleiben immer irgendwo Listener hängen, die nie abgeräumt werden.

Aber ich kann für C++ und jede andere Sprache genauso schlechte Beispiele aufführen. Bei C++ kotzt mich heute (nach vielen Jahren Java) das Header-System an. Es macht unnötig Mehrarbeit und widerspricht dem DRY-Prinzip!

Deshalb arbeite ich mit Java heute trotzdem gerne (war nicht immer so!).

Techel

Der C++-Standard vom nächsten Jahr wird meined Wissens nach ein Modulsystem beschreiben. Clang hat es jetzt schon drin.

Artchi schrieb:

IBei C++ kotzt mich heute (nach vielen Jahren Java) das Header-System an. Es macht unnötig Mehrarbeit und widerspricht dem DRY-Prinzip!

D hat das Problem nicht. Dank Modulen.

Skym0sh0

hustbaer schrieb:

Der Knackpunkt ist dass ein GC wie er in Java, C# etc. vorhanden ist keine deterministische Finalisierung anbieten kann, sondern nur nicht-deterministische Finalisierung. D.h. die Java Runtime ruft dir schon irgendwann den Finalizer auf. Nur das passiert halt erst irgendwann. Garantiert ist bloss dass es nicht "zu früh" passiert, also nicht während das Objekt noch erreichbar ist. Es kann aber beliebig spät sein.

Lustigerweise kann man auch genau das beeinflussen, und zwar zum Negativen:

public class Foo
{
	/*public*/ static Set<Foo> objects = new HashSet<>();

	@Override
	protected void finalize()
	{
		objects.add(this);
	}
}

So kann man totgesagte Objekte weiterleben bzw. wiederauferstehen lassen. Und der Knackpunkt: Wenn solch ein Objekt dann wirklich gelöscht werden kann (d.h. hier aus dem Set herausgenommen ist), dann wird es ohne nochmaligen Aufruf der finalize-Methode gelöscht

hustbaer schrieb:

Java & Endanwender schrieb:

Mehrfachvererbung ist auch ein Übel.

Ja. So direkt widersprechen will ich da nicht unbedingt. Mehrfachvererbung schafft wohl mehr Probleme als es löst.
Es ersatzlos zu streichen ist aber auch irgendwie doof. Nein, falsch, nicht ersatzlos, immerhin gibt es in Java Interfaces.

Und seit Java 8 (und mit Java 9 und 10 etc. wahrscheinlich noch mehr) werden Interfaces immer mehr zu abstrakten Klassen.

hustbaer

Skym0sh0 schrieb:

So kann man totgesagte Objekte weiterleben bzw. wiederauferstehen lassen. Und der Knackpunkt: Wenn solch ein Objekt dann wirklich gelöscht werden kann (d.h. hier aus dem Set herausgenommen ist), dann wird es ohne nochmaligen Aufruf der finalize-Methode gelöscht

Gibt es bei Java kein Pendant zu GC.ReRegisterForFinalize (.NET)?

In Java verwendet man auch nicht den GC, wenn man deterministische Resourcenfreigabe möchte.

try(CriticalResource r = new CriticalResource()) {
  useResource(r);
}

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

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?

hustbaer

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.

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?

volkard

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.

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?