# Java oder welche Sprache?



## Utopia (2. Dez 2011)

Hallo, 
ich möchte gerne Programmieren lernen. Ich habe 4 große Sprachen gefunden, die wohl infrage kommen würden: C, C++, C#, Java. Was denkt ihr, womit ich anfangen sollte? (Und ich frage hier natürlich mit gewisser Absicht in einem Java Forum, also haut ruhig die Vorteile eurer wahrscheinlichen Lieblingssprache raus, von einem Bekannten wurde mir nämlich C++ empfohlen und ich möchte ja etwas zum Gegenhalten haben.)


----------



## Sym (2. Dez 2011)

Ich würde Java empfehlen.

Gerade durch die vielen verschiedenen Möglichkeiten in C++ kann man dort vieles lesen und lernen, was eigentlich nicht korrekt ist oder sogar Fehler verursacht. Du musst Dich da stark mit Speichernutzung beschäftigen, was für den Einstieg vielleicht nicht geeignet ist. Du brauchst relativ viel Vorwissen über Hardware, Betriebssystem, Compiler, etc gemessen an High-Level-Sprachen wie C# oder Java.

C ist zu alt und wird nur für sehr spezielle Bereiche eingesetzt. Würde ich nicht empfehlen.

C# und Java unterscheiden sich in ihrer Komplexität eher marginal. Allerdings empfinde ich die freien Tools wie Eclipse und Maven als Vorteilhaft. Bei C# wäre es wohl sinnvoll Visual Studio zu verwenden, was entweder Geld kostet oder in der Express Version enorm eingeschränkt ist (ob das in der aktuellen VS-Version noch so ist, kann ich nicht beurteilen).


----------



## Fab1 (2. Dez 2011)

Ich denke auch mit Java oder C++ bist du gut bedient. Wirkliche Gründe dafür kann ich nicht nennen, beide Sprachen haben  Vor- sowie auch Nachteile.

Sofern deine Freunde auch programmieren, würde ich mich für die gleiche Sprache wie die von deinen Freunden entscheiden, dann kann man sich wenigstens über die gleichen Sachen unterhalten zusammen Probleme lösen, oder mal gemeinsam ein Projekt starten.

Das wäre zumindest ein Punkt über den ich mich freuen würde, wenn man sich mal mit Freunden über sowas unterhalten könnte, aber das wird in meinem Dorf nie der Fall sein :-(


----------



## tfa (2. Dez 2011)

Ich denke, von allen genannten Sprachen ist C++ mit Abstand am ungeeignetsten für einen Programmieranfänger.


----------



## Swoop (2. Dez 2011)

tfa hat gesagt.:


> Ich denke, von allen genannten Sprachen ist C++ mit Abstand am ungeeignetsten für einen Programmieranfänger.



Hm ich finde C ist die ungeeignetste Sprache... Entweder Java oder C#... Wobei ich Java besser finde... Es liegt aber wohl daran dass ich erst Java und dann C# lernte ...


----------



## maki (2. Dez 2011)

Auch IMHO ist C++ die am wenigsten geeignete Sprache für Anfänger, C würde da jederzeit den Vorzug bekommen wenn es nur diese beiden Möglichkeiten gäbe.

Ansonsten natürlich Java!


----------



## fastjack (2. Dez 2011)

+ Java
- C/C++
-- C#


----------



## bronks (2. Dez 2011)

Utopia hat gesagt.:


> ... C++, C#, Java. Was denkt ihr, womit ich anfangen sollte? ...


Meine Meinung:*
C++:* Sehr tolle und kompromisslose Sache, wenn die Programme für Unix gebaut werden. Ist umständlich, aber man gewöhnt sich daran.
*Java:* Sehr tolle Sache, wenn die Programme auch auf Windows laufen sollen. Es gibt zwar Einschränkungen, welche die Sache etwas komplizierter machen, aber das bekommt man in den Griff.
*C#:* Wenn die Programme nur auf Windows laufen sollen, dann erreicht man damit eigentlich alles. Es gibt viele Macken für welche es noch mehr Workarounds gibt, an welche man sich  stillschweigend gewöhnt. Auf GuiSeite läuft alles streng ereignissorientiert ab, was oft zu interesseanten Lösungen führt, die dem Javaprogrammierer auf den ersten Blick sehr fricklerhaft erscheinen.

Nimm C# oder Java (alphabetische reihenfolge).


----------



## ARadauer (2. Dez 2011)

Was willst du machen?
Business Software oder Apps für Android schreiben: Java
Alte Business Software warten und viel fluchen: C++
Hardware Treiber oder sonstige krankte Dinge schreiben: C
Sich auf die Gunst eines großen Konzerns verlassen müssen: C#


----------



## eso (2. Dez 2011)

bronks hat gesagt.:


> *C#:*  Es gibt viele Macken für welche es noch mehr Workarounds gibt, an welche man sich  stillschweigend gewöhnt.


Würde ich eher von Java behaupten, als von C#. Gerade das ist die Stärke von .NET - wenn's drin ist, dann kann man sich auch darauf verlassen. Und es ist viel drin. Worauf man sich nicht verlassen kann, ist das, was man heute lernt, morgen noch aktuell ist (siehe Silverlight).


----------



## Dow Jones (3. Dez 2011)

Wenn du zum ersten mal programmierst, dann finde ich C/C++ gar nicht verkehrt. Gerade der Einstieg dürfte etwas einfacher sein als bei Java, und mit "Vorwissen über Hardware, Betriebssystem etc" wirst du dich zu Beginn auch nicht belasten müssen. Java ist zwar eine sehr bequeme Sprache, da sehr viele Dinge bereits fertig implementiert vorliegen, aber um diese zu nutzen muss man erstmal Programmieren können (recht gut sogar). Außerdem ist es nie verkehrt C/C++ Kenntnisse zu haben. 
Um das Programmieren _von der Pike auf_ zu lernen würde ich ersteinmal mit C anfangen. Nach 2-3 Monaten kannst du dann auf Java wechseln Die grundsätzliche Syntax ist bei beiden Sprachen extrem ähnlich, so dass der Umstieg leicht fällt und man die bereits gesammelten Kenntnisse größtenteils weiterverwenden kann.

Eigentlich macht es für den absoluten Anfang so ziemlich gar keinen Unterschied ob man mit C oder Java beginnt. Unterschiede zwischen den Sprachen treten erst in einem späteren Stadium auf.


----------



## Final_Striker (3. Dez 2011)

Java oder C#


----------



## bronks (5. Dez 2011)

eso hat gesagt.:


> Würde ich eher von Java behaupten, als von C#. Gerade das ist die Stärke von .NET - wenn's drin ist, dann kann man sich auch darauf verlassen. Und es ist viel drin. Worauf man sich nicht verlassen kann, ist das, was man heute lernt, morgen noch aktuell ist (siehe Silverlight).


Also, die letzten ca. 2 Jahre war ich sehr pro C# und .NET und war davon wirklich begeistert. Bis in den letzten Wochen ein paar Sachen passiert sind, welche sehr fragwürdig waren.

So z.B. ein FTP-Client in .NET 4. Dieser Client funktionierte wohl auf allen Computern im Netzwerk, aber nicht auf dem einen Computer, für welchen dieser Client gebaut wurde. Auf diesem einen Computer funktionierten alle möglichen FTP-Clients, aber nur nicht meiner. Lange wurde herumexperimentiert und herumgerätselt, warum es nicht funktionieren möchte. Letztendlich habe ich das Programm auf Java portiert und danach ist es gelaufen. 

Auf der anderen Seite durfte ich die letzten Tage mit Java arbeiten. Anfangs war ich gut gelaunt, aber die letzten Tage doch ziemlich ange****t.

Egal ob C# oder Java. Die Macken und Fehlfunktionen hat man massenhaft in Beidem. Man muß sich immer nur fürs nächste Projekt überlegen, welche Macken unter den gegebenen Rahmenbedingungen angehemer zu ertragen sind.


----------



## bronks (5. Dez 2011)

ARadauer hat gesagt.:


> ... Sich auf die Gunst eines großen Konzerns verlassen müssen: C#


Da muß ich jetzt mal wirklich provokativ nachfragen, wo hier der genaue Unterschied zu Java liegt?


----------



## darekkay (5. Dez 2011)

bronks hat gesagt.:


> Da muß ich jetzt mal wirklich provokativ nachfragen, wo hier der genaue Unterschied zu Java liegt?



OpenJDK ist frei (für den Fall der Fälle), Eclipse und Netbeans (sowie die meisten Plugins dafür) sind ebenfalls frei. Man hängt bei weitem nicht so sehr von Oracle ab, wie man bei C# von Windows abhängt. (falls es sowas wie OpenC# gibt, nehm ich's zurück. bis jetzt nur von Lobo gehört, was auf Linux laufen soll, aber an das Original nicht rankommt)

Mich hat bei Visual Studio Express ebenfalls gestört, dass es eben gleich viel zu viele Einschränkungen gibt. "Kostenlos" und "gut" verträgt sich irgendwie nicht wirklich, wenn es um M$ geht (Ausnahmen bestätigen die Regeln..)


----------



## maki (5. Dez 2011)

bronks hat gesagt.:


> Da muß ich jetzt mal wirklich provokativ nachfragen, wo hier der genaue Unterschied zu Java liegt?


Auf die Gefahr hin das dies zu einem MS vs. Oracle vs OSS Thread wird...

MS spuckt schneller neue APIs Libs aus als man hinsehen kann, diese verschwinden dann aber genauso schnell wieder, fast von heute auf morgen... 

ATL, sagt das noch jemandem etwas?
Das war 2001 der letzte Schrei von MS, ich war sogar auf Fortbildung, ein paar Monate später war das Ding begraben.

Schon mal gesehen welchen Platz .Net bei Windows 8 einnehmen wird?
Ja, richtig, eine Randerscheinung, weil MS jetzt wieder auf COM und C++ setzt und ansosnten auf JavaScript und HTML...

Klar gibt es auch bei Sun/Oracle fragwürdige Entscheidungen (JavaFX, aber das war abzusehen), aber zumindest kann man da immer noch auf APIs und das eigene Wissen darüber aufbauen, die mal vor über 10 Jahren rausgekommen sind (zB. JDBC, Servlet Spec., etc. pp.)


----------



## fastjack (5. Dez 2011)

maki hat gesagt.:
			
		

> Schon mal gesehen welchen Platz .Net bei Windows 8 einnehmen wird?
> Ja, richtig, eine Randerscheinung, weil MS jetzt wieder auf COM und C++ setzt und ansosnten auf JavaScript und HTML...



ich pack mich weg. doppel :lol: an M$


----------



## Sym (5. Dez 2011)

maki hat gesagt.:


> Schon mal gesehen welchen Platz .Net bei Windows 8 einnehmen wird?
> Ja, richtig, eine Randerscheinung, weil MS jetzt wieder auf COM und C++ setzt und ansosnten auf JavaScript und HTML...


Hast Du dazu eine Quelle?


----------



## fastjack (5. Dez 2011)

das hier ist ganz nett:

Silverlight und .Net: Windows 8 verunsichert Entwickler - Golem.de-Forum

Microsoft's high-risk Windows 8 .NET switch ? The Register

Rockford Lhotka - Windows 8 Development Platform Clarified


----------



## inv_zim (5. Dez 2011)

Der Artikel ist doch alt. Die meisten Bedenken sind seit BUILD zum großen Teil hinfällig:

Premature cries of Silverlight / WPF skill loss. Windows 8 supports all programming models  Burela's house-o-blog


----------



## schalentier (5. Dez 2011)

Mh, keine Ahnung, ob der Threadersteller nochmal herkommt, aber ich wunder mich grad, wieso bisher nur Java, C, C++ und C# genannt wurden.

Ich hab z.B. mit BASIC angefangen (GW/BASIC) und letztlich ist das immer noch eine super Sprache fuer Anfaenger, gerade weil sie so extrem beschraenkt und eben einfach ist. Heutzutage wuerde ich natuerlich niemandem ernsthaft Basic empfehlen, aber was waere z.B. mit Python (mag ich persoenlich nicht) oder Ruby?

Diese Scriptsprachen haben einige Vorteile fuer Anfaenger:
- kein Compilieren notwendig
- interaktive Shell (fuer die allerersten Schritte)
- einfache Konstrukte moeglich
- Full OOP
- wenig Boilerplatecode
- eine Scriptsprache sollte imho jeder Entwickler kennen und einigermassen beherrschen

Nur mal so als Anregung...


----------



## MasterK (6. Dez 2011)

ARadauer hat gesagt.:


> Alte Business Software warten und viel fluchen: C++


Also ich, als jemand der sowohl sehr gut java als auch sehr gut c++ kann und anwendet, finde das immer sehr lustig:
Die java entwickler jammern über c++ ("buhu, destruktoren"), die c++ entwickler über java ("buhu, keine destruktoren").

Momentan arbeite ich an einem stück software in c++, wo ich mir mit java die kugel geben würde. Denn da brauche ich _echte_ templates, nicht so diesen kikifax generic quark von java. Und ich brauche operator-überladung. Nicht 08/15 + und -, sondern cast-operatoren, stream operatoren. Und nein, das schränkt die lesbarkeit ganz und gar nicht ein.

Daneben (gleiche firma, anderes projekt) arbeite ich auch an einem java-projekt. Und da wiederrum würd ich mir mit c++ die kugel geben. Denn da brauche ich ein umfangreiches framework für webapplikationen.

Als jemand, der in beiden welten heimisch ist, sag ich mal: java ist schon wirklich toll. Aber das gute an java ist vor allem das ökosystem drumherum. Die _sprache_ ist, wenn mans objektiv betrachtet, doch eher so naja. Vor allem mit krücken durchsetzt. Wie zB die generics oder try-with-resources. Beides so ein fall, wo sich jeder ernsthafte c++ entwickler vor lachen biegt.
Bei c++ ist das ökosystem drumherum eher "naja". Ehrlich gesagt, ohne Qt entwickle ich in c++ auch gar nicht mehr, wär mir auf dauer zu nervenaufreibend, für jede kleinigkeit entsprechende bibliotheken zu suchen (und nein, boost ist auch nicht das allheilmittel).

Lange rede kurzer sinn:
Wenn die vom threadersteller genannten sprachen eine rolle spielen sollen, dann bin ich der meinung:
c++ UND (java ODER c#). Ein softwareentwickler, der nicht mit den vorteilen von c++ (RAII, operator-überladung, echte template programmierung, const-correctness, usw) vertraut ist, den nehm ich erst gar nicht ernst. Genauso wenig wie c++ entwickler, die webanwendungen in c++ schreiben wollen.

Ich persönlich würde für das programmieren lernen aber eine sprache nehmen, welche mit wenig code einfache ein- und ausgaben auf der konsole möglich macht und problemlos zu nutzen ist. Ich find ja python ganz nett.



maki hat gesagt.:


> Das war 2001 der letzte Schrei von MS, ich war sogar auf Fortbildung, ein paar Monate später war das Ding begraben.


Nun, das letzte update kam zwar schon 2009 raus, aber "ein paar monate" würd ich das nicht nennen. Ausserdem kam die erste version afaik irgendwann mitte der 90er raus. Und da es ja wohl eh keiner vermisst, tut es manchmal gut alte zöpfe einfach abzuschneiden.


----------



## maki (6. Dez 2011)

> Bei c++ ist das ökosystem drumherum eher "naja".


IMHO ist bei C++ die Sprache und das drumherum "naja".
C++ bietet weder Unterstützung für Threads noch für sonst. interessante Sachen (DB Treiber), das kommt alles aus 3rd Party Libs, nicht selten vom OS gestellt.
Die Sprache selber... naja, hat ja als "Hybrid" angefangen (oft auch "Müllhaufen" genannt), deswegen sind die Konzepte nicht durchgängig, viele Alternativen um ein und dasselbe zu erreichen, was zu einer hohen Komplexität führte, wieviele der möglichen Sprachelemente werden denn wirklich in C++ eingesetzt?
Man denke nur an die Zeiger Notation, die Zeiger auf Zeiger Notation, die Referenznotation etc. pp.
Da ist imho viel Müll dabei den man sich sparen könnte.



> Wenn die vom threadersteller genannten sprachen eine rolle spielen sollen, dann bin ich der meinung:
> c++ UND (java ODER c#). Ein softwareentwickler, der nicht mit den vorteilen von c++ (RAII, operator-überladung, echte template programmierung, const-correctness, usw) vertraut ist, den nehm ich erst gar nicht ernst. Genauso wenig wie c++ entwickler, die webanwendungen in c++ schreiben wollen.


RAII braucht man doch nur wenn man keinen GC hat 
const-correctness ist imho nur nützlich wenn man keine Immutables kennt? 
Operatorüberladung? Witzig, hab ich in Java noch nie vermisst, schreibe aber auch keine Math. Anwendungen.

Sicherlich sind die Java Generics und andere lückenhaft umgesetzt, oberstes Ziel war die Abwärtskompatibelität, bin auch der Meinung dass man alte Zöpfe mal abschneiden sollte, sieht aber nicht so aus als ob es kommen würde.

IMHO ist das komplexeste an C++ das man lernt was man nicht einsetzen sollte und wie man das einsetzt was man einsetzen sollte, da bleibt nicht viel Zeit für Anfänger um OO Konzepte zu begreifen und anzuwenden.

Das gesagte gilt für "Anfängersprachen", dass C++ in der richtigen Welt doch mal die bessere Wahl ist, ist offensichtlich.
Google hatte erst vor ein paar Monaten einen Studie über Performanceunteschiede zwischen Java und C++ vorgestellt, das endergebnis war ungefähr: "C++ lässt sich viel besser optimieren, aber nur von Experten".

Finde es halt immer wieder witzig wenn Umsteiger von C++ hier im fiorum fragen stellen ala "Warum wird der Copy Konstructor nicht vom Compiler erstellt" bzw. "Ich hab mir da einen Copy Konstruktor geschrieben" weil sie der Meinung sind das würde zur OO gehören, Copy Konstruktoren und überladene Zuweisungsoperatoren sind halt etwas was man nur in C++ "braucht".

Da wirst du wohl aber mehr Erfahrungswerte haben wenn du regelmässig in beiden Welten unterwegs bist.



> Nun, das letzte update kam zwar schon 2009 raus, aber "ein paar monate" würd ich das nicht nennen. Ausserdem kam die erste version afaik irgendwann mitte der 90er raus. Und da es ja wohl eh keiner vermisst, tut es manchmal gut alte zöpfe einfach abzuschneiden.


Sicher, und wie relevant war es?
Nicht vergessen, es wurde als das "neue Schwarz" für Webseitenentwickelung(!!) angekündigt.


----------



## schlingel (6. Dez 2011)

@Topic: Je nachdem. Ich bin mittlerweile der Meinung dass ein guter Programmierer seine Maschine kennt. Wenn Computerarchitektur, Betriebssystemkunde und Programmieren unterrichtet werden ist C wohl die beste Wahl. Ansonsten würde ich zu Java oder C# greifen.



> C# und Java unterscheiden sich in ihrer Komplexität eher marginal.


Das hat bis C# 2 wohl noch gestimmt aber seit C# Version 3 ist das anders. In der aktuellen Version ist C# wohl Scala ähnlicher als Java. Bis man beliebige - vor allem auch neue - C#-Programme lesen kann vergehen da schon ein paar Monate.



> Schon mal gesehen welchen Platz .Net bei Windows 8 einnehmen wird?
> Ja, richtig, eine Randerscheinung, weil MS jetzt wieder auf COM und C++ setzt und ansosnten auf JavaScript und HTML...


Zum einen blendet das vollkommen die Tatsache aus, dass die Metro-Oberfläche kaum den normalen Desktop vertreiben wird. Außerdem gibt's genauso .Net-Bindings damit mit WPF/C# Metro-Apps entwickelt werden können. Was im Vergleich zur Overblowen HTML5/JS-API nichts so unattraktiv ist.

Zudem ist .Net auch im Enterprise-Bereich dick da. Dort ist es auf jeden Fall gekommen um zu bleiben.


----------



## maki (6. Dez 2011)

@schlingel
Wollte ja auch nicht behaupten dass .Net verschwindet, aber bis jetzt (einschliesslich Windows 7) war .Net eben das "Flagschiff" was SW Entwicklung unter Windows betrifft und ab Windows 8 soll es dann eine von vielen möglichen alternativen sein und plötzlich ist C++/COM und JS/HTML "die Nr. 1".
Selbst wenn es für C++/COM und JS/HTML nicht zutrifft ist ganz klar dass .Net eben nicht mehr der Platzhirsch sein wird, VBA zB. gitb es ja heute auch noch


----------



## schlingel (6. Dez 2011)

Ich seh das so: C# bzw. .Net (MS investiert ja zur Zeit auch sehr in F#) wird weiterhin ein Big Player im MS-Universum bleiben. Ganz einfach weil es ja neben dem Desktop noch die Server und die Smartphones gibt. Beides Bereiche die so schnell nicht weg kommen. 

In geringem Ausmaß ist ja auch die XBox durch XNA als .Net-Plattform interessant. Aber irgendwie geht das alles am Topic vorbei. Wir können ja in einem anderen Thread die Glaskugel befragen =D


----------



## Gregorrr (6. Dez 2011)

Also, ich würde (falls Zeit besteht), wirklich erst mal mir bisschen Assembler angucken und versuchen die Computer-Architektur zu verstehen. Einfach mal erstmal ausprobieren, wie das so ist, dann lernt man die höheren Programmiersprachen nämlich erst wirklich zu schätzen und da am Ende sowieso alles in Maschinencode übersetzt wird, hat man ein grundlegendes Verständnis, wie alles hinter den Kulissen abläuft. Natürlich sollte man sich bewusst sein, dass man in Assembler nicht wirklich etwas gescheites auf die Schnelles hinkriegt - muss man auch nicht, wäre nur für den Lerneffekt.

Danach würde ich mir ein Fundament aus C aufbauen. C spielt immer noch eine wichtige Rolle. Ich finde, wenn man sich mit einer höheren Programmiersprache beschäftigt, dann abstrahiert die für den Anfang zu viel, ausserdem lernt man mal mit Speichern umzugehen.
Danach weiß man aber auch, warum man mit Java/Python/Ruby produktiver ist.

Danach vielleicht mal ein anderes Programmierparadigma anschauen, d.h. sowas wie Haskell, Scheme, oder ähnlich.

Auf jedenfall ist eine "Skriptsprache", wie Python/Ruby immer sinnvoll (sind ausgewachsene OO-Sprachen mit funktionalen Bestandteilen) da man damit schnell man was zusammenschnipseln, sozusagen ein Schweizer Messer.


Naja, eine Programmiersprache ist immer nur ein Tool, das sollte man nicht vergessen und wenn mal eine Sprache "aussterben" sollte, die man benutzt hat, so hat man doch wichtige Aspekte gelernt, die einem bei der nächsten Sprache auf jedenfall helfen sollten.


----------



## tfa (6. Dez 2011)

Ich finde, ein Anfänger sollte einen Eimer Transistoren hingestellt bekommen und sich seinen Rechner selbst zusammen löten müssen.


----------



## Gregorrr (6. Dez 2011)

tfa hat gesagt.:


> Ich finde, ein Anfänger sollte einen Eimer Transistoren hingestellt bekommen und sich seinen Rechner selbst zusammen löten müssen.



Kommt drauf an wohin man will. Für bestimmte hochperformante und optimierte Applikationen ist es interessant FPGAs zu programmieren! Also ungefähr so, wie du es oben angedeutet hast


----------



## MasterK (6. Dez 2011)

maki hat gesagt.:


> C++ bietet weder Unterstützung für Threads noch für sonst.


Auch c++ entwickelt sich weiter. Die in C++11 hinzugekommenen threads sind aber in der standard bibliothek hinzugekommen, nicht in der sprache an sich. Letztlich wie überall.



maki hat gesagt.:


> interessante Sachen (DB Treiber), das kommt alles aus 3rd Party Libs, nicht selten vom OS gestellt.


Das sagte ich ja: das ökosystem bei java ist ungleich umfangreicher.



maki hat gesagt.:


> Man denke nur an die Zeiger Notation, die Zeiger auf Zeiger Notation, die Referenznotation etc. pp.


Na, man sollte die unterschiede schon kennen, um die vorteile schätzen zu können. Leider haperts da bei den java-onlys häufig.



maki hat gesagt.:


> RAII braucht man doch nur wenn man keinen GC hat


Das ist quatsch und hat nichts mit einander zu tun. Eben weil man in java KEIN RAII hat braucht man solche krücken wie try-with-ressources. GCs gibts in c++ btw auch wenn du willst. Aber eben als library.



maki hat gesagt.:


> const-correctness ist imho nur nützlich wenn man keine Immutables kennt?


Auch quatsch. Wenn ich in c++ eine const referenz auf eine map zurückgebe, dann ist das ding auch const. In java gebe ich eine Collections.unmodifiableMap(Map m) zurück, was einfach irre besch...... ist. Ich WEISS ja nichtmal, dass es eine "unmodifiableMap" ist. Wenn ich also das ding versehentlich in eine neue Map packe, dann wars das mit "unmodifiable". In c++ ist const wirklich const, und ich muss das const explizit entfernen. Versehentlich passiert das nicht. Ausserdem: ich nutze in oben erwähnten java projekt eine MultiHashMap. Wenn ich die unmodifiable haben will, muss ich eine eigene UnmodifiableHashMap schreiben. In c++ reicht ein "const".
Hat also mit Immutables erstmal gar nix zu tun.



maki hat gesagt.:


> Operatorüberladung? Witzig, hab ich in Java noch nie vermisst, schreibe aber auch keine Math. Anwendungen.


Siehste, wieder genau das gleiche: man kennt die vorzüge nicht, schon meint man es nicht zu brauchen. Operatoren in c++ bestehen aus mehr als nur +, - und ==. Sicher, operatorüberladung macht in reinen anwendungen eher selten sinn. In bibliotheken, frameworks etc aber um so mehr.



maki hat gesagt.:


> IMHO ist das komplexeste an C++ das man lernt was man nicht einsetzen sollte und wie man das einsetzt was man einsetzen sollte, da bleibt nicht viel Zeit für Anfänger um OO Konzepte zu begreifen und anzuwenden.


Ich denke auch nicht, dass c++ als anfängersprache zu gebrauchen ist. Gerade dass die leute dann teilweise wirklich schlechtes c++ lernen, macht die sache nur noch schlimmer. Aber von einem professionellen entwickler sollte man es erwarten dürfen.
Aber java finde ich ebenfalls schlecht als anfängersprache geeignet. Man wird einfach zu schnell von den bibliotheken "erschlagen". War zumindest meine beobachtung bei leuten, die mit java angefangen haben. Was natürlich nicht heisst, dass das nicht ginge. Aber man macht es sich wohl doch schwerer als man müsste.


----------



## escalate (10. Dez 2011)

schalentier hat gesagt.:


> Mh, keine Ahnung, ob der Threadersteller nochmal herkommt, aber ich wunder mich grad, wieso bisher nur Java, C, C++ und C# genannt wurden.


Ist leider oft so, dass man in solchem Empfehlungsrunden nicht über die üblichen Verdächtigen hinauskommt. 



> einfach ist. Heutzutage wuerde ich natuerlich niemandem ernsthaft Basic empfehlen, aber was waere z.B. mit Python (mag ich persoenlich nicht) oder Ruby?


Wenn es sonst keine "Sonderwünsche" gibt schlage ich immer "Python oder Ruby" vor.
Ruby kenne ich zwar viel weniger (letztes Jahr habe ich mal ein Tutorial gemacht und hin und wieder Code gesehen), aber auf mich wirkt das nicht viel anders als Python. 

Python war ja auch ein Vorbild von Ruby. Daher wundert es mich ein wenig, warum man das eine nicht mögen kann, das andere aber schon.




> Diese Scriptsprachen haben einige Vorteile fuer Anfaenger:
> - kein Compilieren notwendig
> - interaktive Shell (fuer die allerersten Schritte)
> - einfache Konstrukte moeglich
> ...


Genau richtig 

Die interaktive Shell gibts zwar auch bei statischen Sprachen wie Scala, aber wenn man sowas wie IPython kennt will man davon nicht mehr weg... 
Einen besseren "Taschenrechner" kann ich mir kaum vorstellen und fürs Schreiben von einfachen Programmen oder Testen von einzelnen Funktionen auch nichts.


----------



## Landei (10. Dez 2011)

Ich würde auch keine der vier genannten Sprachen empfehlen. Es sind "große" Sprachen, weil sie alle einen sehr pragmatischen Ansatz verfolgen, und dabei nicht viel Rücksicht auf Anfänger nehmen.

C ist hornalt, hat das krankste Typsystem (samt Poiner-Arithmetik), das man sich vorstellen kann und ist nicht objektorientiert. C++ hat den ganzen Mist von C übernommen und wild tausende Features dazugepackt (leider zählt ein Garbage Collector nicht dazu). Java hat alle "gefährlichen" Sachen aus C++ verbannt, allerdings auch wichtige Abstraktionsmöglichkeiten, und hinkt in der Entwicklung anderen modernen Sprachen hinterher. C# ist ähnlich wie Java, hat auch ähnliche Krankheiten, ist aber etwas moderner. Es wäre noch die beste Wahl, wenn dich die M$-Abhängigkeit nicht stört.

Die genannten Alternativen Ruby und Python sind nicht schlecht, aber für Einsteiger halte ich Fantom oder Gosu besser geeignet, auch wenn sie relativ unbekannt sind. Außerdem würde ich mir an deiner Stelle auch mal die funktionale Seite ansehen, insbesondere Erlang oder die ML-Sprachen (z.B. OCaml, F#).

Ausdrücklich _nicht_ empfehlen möchte ich die Sprachen, die mir am meisten Spaß machen, nämlich Scala und Haskell: Man lernt auch nicht in einer Boeing oder einem Düsenjet fliegen...


----------



## Java-Basher (30. Dez 2011)

MasterK hat gesagt.:


> die c++ entwickler über java ("buhu, keine destruktoren").


 Das beschreibt meine Reaktion auf Java so gut, dass ich mal was dazu schreibe. Ich bin ganz klar C++ Programmierer. Nun wollte ich mir Java doch mal antun. Das Erste was einem C++ler auffällt ist natürlich, dass es keine freien Funktionen gibt und Klassen als Namespaces missbraucht werden. Na gut, kann man sich noch dran gewöhnen. Dazu keine Mehrfachvererbung. Ok, Interfaces sind auch nett. Was dann aber anfängt zu nerven ist das fehlende auto, ist das ernst gemeint?

```
FileInputStream is = new FileInputStream(filename);
vs.
auto is = new FileInputStream(filename);
[/Java] Da ist die Code-Redundanz ja schon in die Sprache eingebaut, yay.
Ok, kann man ja noch drüber hinwegsehen. Java ist schließlich toll und man kann super schnell und vor allem viel sicherer als in C++ arbeiten. Schließlich hat die Sprache ja keine Pointer und Pointer sind ja extrem böse, sie können uninitialisiert sein. Aber was ist das? NullPointerException? Oh stimmt, es gibt ja gar keine Garantie darauf, dass so eine "Java-Referenz" auch initialisiert ist. Hm.. ok.. was machte Java noch gleich sicherer? Ah, sicher wird alles in Java immer schön ordentlich geschlossen. Aber.. es gibt ja gar keine Destruktoren? Ich muss _manuell_ close() aufrufen? OO Stimmt, geht ja auch gar nicht, der Müllsammler im Hintergrund darf ja machen was er will. Operatorüberladungen gibt es auch nicht? Also statt [code] auto newvec = vec1 + vec2;
```
 schreibt man 
	
	
	
	





```
GeometricVector3 newvec = vec1.add(vec2); // Oder so
```
 ? Das hat mir irgendwie den Rest gegeben.

So, genug gebasht, aber das ist doch sehr erleichternd nach dem ich meinen Kopf stundenlang gegen den Tisch hauen musste. Daher meine ehrliche Frage: Wo seht ihr den Vorteil von Java bzw. dem GC-Konzept gegenüber C++? C++ hat shared_ptr, weak_ptr. Gebraucht habe ich die übrigens noch nie, denn solange der Scope eines Objekts bekannt ist (was eigentlich immer der Fall sein sollte), reicht unique_ptr völlig. Und den muss man nicht closen, geht alles automatisch. (Von const, Templates und Performance fange ich gar nicht erst an.)

Den Vorteil, den ich noch bei Java sehe, ist die wesentlich größere Bibliothek. Aber rechtfertigt die eine Sprache am Limit des Erträglichen, zumal C++ an dieser Stelle immer weiter nachbessert?

@TE & Topic
Ich würde ganz klar C empfehlen. Man kann mit C schneller interessantere Dinge bauen als in Assembler, aber lernt trotzdem viel von dem was innerhalb des PCs so vor sich geht. Variablen, Bedingungen, Schleifen, Funktionen, Arrays, etc. kann man auch in C problemlos lernen. Zudem ist die Sprache ziemlich spartanisch, dafür aber auch sauber. Die Grundzüge kann man sich daher recht schnell aneignen.

PS: Ich freue mich schon über zahlreiche Antworten auf diesen Bash. Mir ist bewusst, dass das wie ein Troll wirken könnte, aber nein, das ist ernst gemeint. Ich bin sogar an einer ernsthaften Diskussion interessiert, aber Java nervt mich momentan so sehr, dass dieser Beitrag einfach ein Bash sein musste. Tut mir auch ganz furchtbar leid.


----------



## Noctarius (30. Dez 2011)

Zu deinem Codebeispiel:
Normal würde man in Java auch gegen das Interface entwickeln und nur irgendwo mal eine bestimmte Implementierung nutzen, ergo wäre der Code

```
InputStream stream = new FileInputStream(...);
```

Damit hast du dann keinen Effekt mehr der dem "auto" gleich kommt.

NullPointerExceptions allerdings sind tatsächlich eine sehr seltsame Sache. Vor allem sind sie s******e benannt. Theoretisch wäre eine UninitializedReferenceException an dieser Stelle klarer. Der Vorteil bleibt aber, dass du keinen echten Speicherzugriff bekommst. BufferOverflow und BufferUnderflow gibt es in Java auch nur als Exception, aber nicht als echten Fehler. Du bleibst in deiner VM und kannst so kein anderes Programm gefährden.

Das manuelle [c]close()[/c] musst du natürlich machen, wieso sollte das in Java nicht gehen? [c]InputStream.close()[/c]
Das wurde in Java 7 jetzt aber automatisiert:


```
try (InputStream stream = new FileInputStream(...)) {
  // do somthing
} // InputStream will be closed automatically
```

Falls du eine Art [c]Referece.close()[/c] meinst: Nee gibt es nicht, wofür auch? Sobald eine Variable in ihrem Scope nicht mehr referenziert wird darf der GC sie abräumen. Hat erstmal nicht mit Magie oder "machen was er will" zu tun, sondern ist eine klare Regel. Was in Java schon mal ein wenig nerven kann, dass der GC erst abräumt wenn er mag.
Es gab / gibt in Java ein Konzept für "Destruktoren" was aber als unsauber, unsicher und nicht nutzbar abgehakt wurde, die [c]finalize()[/c] Methode. Diese sollte man als Java Programmierer aber besser nur vom Namen her kennen. Braucht man einen echten Objekt-Lifecycle muss dieser vom Framework verwaltet werden und nicht von der JVM.

Ob man Operator-Overloading benötigt ist Geschmackssache. Offiziell wird es nicht eingeführt, weil es unleserlichen Code erzeugen kann.

```
Haus haus1 = new Haus("Meins");
Haus haus2 = new Haus("Deins");
Haus result = haus1 + haus2;
```

Was macht der +-Operator an dieser Stelle? Addiert er die Raumanzahl oder die Quadratmeter oder ...?
Ich glaube die Hoffnung ist einfach, dass Menschen an dieser Stelle dann wenigstens aussagekräftige Methodennamen nutzen:

```
Haus result = haus1.addRoomCount(haus2);
```

Aber auch hier kann der Coder natürlich genauso einfach [c]add(...)[/c] machen und der "Vorteil" ist weg. Ich persönlich würde mich über Operator-Overloading in Java freuen, gerade dann wenn man Typen von mathematischen Ausdrücken erzeugt.

PS: Ich fand den spontan mal außergewöhnlich gut formuliert und vor allem sachlich für die typischen C++ler die hier sonst so rum laufen und habe ihn daher gar nicht als Troll Post aufgenommen


----------



## Landei (30. Dez 2011)

Java-Basher hat gesagt.:


> PS: Ich freue mich schon über zahlreiche Antworten auf diesen Bash. Mir ist bewusst, dass das wie ein Troll wirken könnte, aber nein, das ist ernst gemeint. Ich bin sogar an einer ernsthaften Diskussion interessiert, aber Java nervt mich momentan so sehr, dass dieser Beitrag einfach ein Bash sein musste. Tut mir auch ganz furchtbar leid.



Aus C++-Sicht fehlt Java ein weiteres wichtiges Feature, nämlich Closures. C++ hat zwar "nur" Funktionspointer, aber auch die sind besser als nichts.

Die Kritikpunkte sind alle berechtigt (bis auf das automatische Schließen von Resourcen, was aber erst seit Java 7 unterstützt wird), was man schon daran sehen kann, dass die meisten davon in den neuen JVM-Sprachen (Scala, Gosu, Fantom, Ceylon, Kotlin...) berücksichtigt wurden. Vielleicht solltest du dich mal mit selbigen beschäftigen (die Java-Interoperabilität ist ja - mal mehr, mal weniger bequem - gegeben). Eventuell wäre aber auch D das richtige für dich: Wenn ich systemnah programmieren müsste, wäre das meine Wahl. Insbesondere die funktionalen Features sind sehr interessant.


----------



## Dit_ (30. Dez 2011)

@Java-Basher
oh eh ich glaube es gibt schon unzählige Java vs C++ Diskussionen in diesem Forum und im Netz...

Meine Meingung dazu, kurz und bündig:


C++ namepace ~ Java package
Du würdest gern 
	
	
	
	





```
auto is = new FileInputStream(filename);
```
 schreiben können, was ist noch der Vorteil davon? Anders ausgedrückt, warum? Wenn du "auto" niergendwo definiert hast, dann geht es auch in C nicht oder doch?
Also für mich gilt folgende Regel: Sobal du das Mehrfach-Vererbung-Bedürfnis verspürst, überdenke dein SoftwareDesign... Einfachvererbung ist schon böse genug 
Ja du hast Recht, es gibt keine Garantie, dass eine Referenz initialisiert ist. Das Initialisieren von Variablen, Referenzen übernimmt in Java, per default, ein Objekt das sich unmittelbar vor dem Bildschirm befindet.
_Müllsammler im Hintergrund darf ja machen was er will_, stimmt auch. Und er macht das sehr gut. GC mag nicht perfekt funktionieren, aber ich hatte noch nie Probleme damit... vielleicht kommt noch 
Der Vorteil von GC-Konzept gegenüber C++? Na ja, der Entwickler konzentriert sich auf das Entwickeln und muss nicht ständig überlegen, habe ich das freigegeben? Wann soll ichs am besten freigeben? Habe ich wirklich alle (5, 10, 20?) Objekte, Felder im Destruktor freigegeben? Oh das stimmt was nicht, irgendwo habe ich oder ein Kollege doch was vergessen! Na dann prüfe ich doch mal alle Destruktoren, es ist ja bloß 20 mb Kode... Außerdem habe ich keine Sternchen und Pfeile, die den Kode unleserlich machen, ich weiß, man kann sich dran gewöhnen, aber trotzdem.
Performance und Vorurteile... Ich glaube das Thema Java's-Low-Performance war vor 12 Jahren das Thema. Wenn es nicht um Bild-, Grafik, Videobearbeitung geht, dann ist Java meistent sogar schneller als C++.  java-vs-c-performance/
Beste Sprache für Anfänger? Also aus meiner Erfahrung kann ich sagen, dass diese Reihenfolge die beste ist: *Java -> C/C++*. Für viele Anfänger ist Zeigerarithmetik einfach zu viel. Es fehlt auch das Grundwissen. Frage eines Ersties (wirklich passiert): _Warum muss ich Speicher freigeben, habe doch 1 TB Festplatte, reicht das nicht?!?_ Besonders am Anfang sind die Erfolgserlebnise sehr wichtig, sonst ist man schnell frustriert. Außerdem ist Java hervorragend dokumentiert, so dass jeder Anfänger schnell Informationen oder Tutorials (sogar auf Deutsch) findet. Es ist ja auch kein Geheimnis, dass Java-Kommunity viel netter und tolleranter ist als die C/C++-Community. *<offtopic>* _wobei man muss zugeben sie ist immer noch besser als irgendeine Linuxcommunity die einen Anfänger immer wie Dreck behandelt... Hat aber was mit der sozialen Kompetenz der "Kellerkinder" zu tun ("google kaputt?", "RTFM"...)...(wer sich angesprochen fühlt... ehmm... sorry  )_*</offtopic>*


----------



## TheDarkRose (30. Dez 2011)

Dit_ hat gesagt.:


> *<offtopic>* _wobei man muss zugeben sie ist immer noch besser als irgendeine Linuxcommunity die einen Anfänger immer wie Dreck behandelt... Hat aber was mit der sozialen Kompetenz der "Kellerkinder" zu tun ("google kaputt?", "RTFM"...)...(wer sich angesprochen fühlt... ehmm... sorry  )_*</offtopic>*
> [/LIST]



Hey, solche Aktionen kommen auch nur vor, wenn ein "Noob" meint einen Server im Internet administrieren zu "können", was genau so fahrlässig ist wie ein Auto ohne Führerschein zu lenken *hmpf*


----------



## escalate (30. Dez 2011)

Java-Basher hat gesagt.:


> Was dann aber anfängt zu nerven ist das fehlende auto, ist das ernst gemeint?


Finde ich auch sehr schade, dass man das nicht gleich zu Beginn eingeführt hat, aber C++ hat das auch erst seit 2011 im Standard. 

In funktionalen Programmiersprachen gibts das schon ein wenig länger 

Immerhin sind die schlimmsten Fälle von "Typ-Salat" schon ein wenig schöner geworden seit Java 7:


```
Map<String, Integer> map = new HashMap<String, Integer>();
```

zu


```
Map<String, Integer> map = new HashMap<>();
```

Ich gebe dir völlig Recht, dass in Java schon so einige interessante Features fehlen, was sich im Nachhinein oft schwer korrigieren lässt. Gibt ja nette Geschichten zu der Entwicklung von Java, die das ein wenig erklären, z.B. das hier:

Seeking the Joy in Java

Den Aspekt "Zeitdruck" fand ich ganz interessant:



			
				The Long Strange Trip to Java hat gesagt.:
			
		

> The interesting thing is that we were right about needing to finish the language even though it had missing features. It was a timing issue, there was only about a three-month window in which the whole Java phenomenon could have happened. We barely made it.





> Schließlich hat die Sprache ja keine Pointer und Pointer sind ja extrem böse, sie können uninitialisiert sein. Aber was ist das? NullPointerException? Oh stimmt, es gibt ja gar keine Garantie darauf, dass so eine "Java-Referenz" auch initialisiert ist. Hm..


Ich fand das schon immer ein wenig seltsam, dass man sowas (wahrscheinlich eher kontraproduktives) wie checked exceptions einführt, aber gleichzeitig NullPointerExceptions völlig unkontrolliert sind. Sogar von Standard-Methoden (wie z.B. map.get(key)) bekommt man null zurück, auf das explizit testen muss um keinen NPE zu bekommen.
Wie man das besser macht kann man bei Scala und anderen modernen JVM-Sprache sehen.



> Operatorüberladungen gibt es auch nicht?


Nein, hast du schon Beispiele für BigInteger oder Vektorrechnung gesehen? Das macht wirklich Spass in Java 



> Daher meine ehrliche Frage: Wo seht ihr den Vorteil von Java bzw. dem GC-Konzept gegenüber C++? C++ hat shared_ptr, weak_ptr.


Zum GC-Thema: GCs sind einfach gut für die allermeisten Programme, das sage ich einfach mal so. Sogar Systemprogrammiersprachen wie Go oder D benutzen GCs.

Shared_ptr und Ähnliches benutzt reference counting, was ein paar Probleme mit sich bringt, auch in Sachen Geschwindigkeit. 

Man kann den Müll auch einfach erstmal überhaupt nicht wegräumen, das beschleunigt das Programm lokal sogar. GCs können sich dann verzögert oder auch mit mehreren Threads um das Aufräumen kümmern.

Die Website von D hat auch viele interessante Informationen zu den Vorteilen von GC.



> Den Vorteil, den ich noch bei Java sehe, ist die wesentlich größere Bibliothek.
> Aber rechtfertigt die eine Sprache am Limit des Erträglichen, zumal C++ an dieser Stelle immer weiter nachbessert?


Die Bibliothek allein rechtfertigt die Benutzung der Sprache nicht, da man die auch von anderen Sprachen aus benutzen kann. Gegen die Standard-Libs von Python oder Ruby wirkt die von Java auch eher klein und eingeschränkt.


----------



## Java-Basher (30. Dez 2011)

Ok überraschenderweise scheinen wir uns ja in vielen Punkten einig zu sein. Nur das hier finde ich noch komisch:


Dit_ hat gesagt.:


> [*]Der Vorteil von GC-Konzept gegenüber C++? Na ja, der Entwickler konzentriert sich auf das Entwickeln und muss nicht ständig überlegen, habe ich das freigegeben? Wann soll ichs am besten freigeben? Habe ich wirklich alle (5, 10, 20?) Objekte, Felder im Destruktor freigegeben?


 Mein Punkt ist ja gerade, dass man in C++ eigentlich kein delete (und im besten Fall auch kein new) braucht. Also man braucht es natürlich, aber solange man keine dreckigen Performance-Hacks basteln möchte, muss man es manuell nicht verwenden. Nie. Nada. Und da gibt es auch nichts zu vergessen. Arrays, vector, list, ... da wird alles sicher freigegeben. Falls man mal so einen Pointer braucht nutzt man halt unique_ptr. (Leider gibt's im Standard kein make_unique, dann könnte man auf ein manuelles new auch gleich verzichten.)

So weit so gut, das kann Java ja auch problemlos. Die Klassen selbst (vector, ..) sind sogar noch etwas leichter. Was aber problematisch wird ohne Destruktor sind halt Dateien oder irgendwie anders reservierte Dinge. DirectX-Objekte müssen z.B. mit ->release() freigegeben werden. Wenn man sich die Verwendung mal in C++ anschaut:

```
class Obj
{
    DXObj *obj_; // unique_ptr kann ja nur mit new reservierten Speicher freigeben, hat also das gleiche Problem wie der GC
public:
  ... // Konstruktor macht neues Objekt etc.
  ~Obj()
  {
    obj_->release(); // <-----
  }
  ...
};

void foo()
{
  std::vector<Obj> objects(500); // 500 Objekte gebaut
} // Destruktor von vector ruft Destruktor von Obj auf, alles wird sicher freigegeben.
```
Das schöne ist hier einfach, dass Klassen hier wirklich zu einer vollständig selbstständigen Einheit werden. Die Beschaffung und die Freigabe von Speicher und sonstigen Ressourcen kann jede Klasse abgeschlossen in sich selbst verwalten, das geht ohne Destruktoren leider nicht. Und das macht Fehlersuche auch unglaublich einfach. Es gibt keine Ressourcenbeschaffung/Freigabe außerhalb von Konst/Destruktoren mehr, weshalb 99% des Codes bei der Lecksuche einfach wegfallen. Das GC-Konzept ist ja nett, aber wenn es nur für Speicher funktioniert doch irgendwie nicht sehr universell.

@"auto muss definiert sein": Da das Schlüsselwort "auto" früher das quasi Gegenstück zu "static" und zudem implizit war, wurde es seit C++11 umfunktioniert. auto generiert den Typ der Variablen jetzt automatisch aus der Initialisierung.

@"Durch VM kein Einfluss auf andere Programme.": Das ist bei nativen Programmen nicht anders, Speicherzugriffe werden durch das System kontrolliert. Na gut, ob man dem jetzt mehr vertraut als einer VM.. 
Interessanter sind da schon Variablen und Rücksprungadressen die direkt hintereinander liegen. Aber da entfernt man sich dann auch schon langsam von der Sprache, denn theoretisch könnte man das in C++ auch anders regeln.


----------



## escalate (30. Dez 2011)

Java-Basher hat gesagt.:


> Das schöne ist hier einfach, dass Klassen hier wirklich zu einer vollständig selbstständigen Einheit werden. Die Beschaffung und die Freigabe von Speicher und sonstigen Ressourcen kann jede Klasse abgeschlossen in sich selbst verwalten, das geht ohne Destruktoren leider nicht.


Mit der automatischen Speicherverwaltung fallen schonmal die allermeisten Resourcen-Probleme weg; für die anderen kann man auch selbst eine Methode schreiben, die irgendwo aufgerufen wird wenn das Objekt nicht mehr gebraucht wird. Das ist von der Funktionsweise her auch nicht viel anders als ein Destruktor, der ja auch irgendwie ausgelöst werden muss.

Falls man etwas braucht, das von der VM automatisch aufgerufen wird wenn das Objekt entfernt wird kann man finalize() benutzen. Das ist auch mit Vorsicht zu genießen, da eben die GC verzögert sein kann aber Destruktoren in sind ja auch nicht ganz ohne Probleme 

Für Resourcen, die von mehreren benutzt werden kann man sich ja auch etwas in Richtung Referenzzählung bauen wie auto_ptr bei C++. Das ist ja auch nur eine Klasse in einer Standardbibliothek und nicht direkt eine Spracheigenschaft.



> Es gibt keine Ressourcenbeschaffung/Freigabe außerhalb von Konst/Destruktoren mehr, weshalb 99% des Codes bei der Lecksuche einfach wegfallen.


Außer bei nicht geschlossenen Transaktionen (dafür gibt es auch automatische Lösungen) kann ich mich nicht erinnern bei einen VM-Programm jemals nach Problemen wegen nicht freigegebenen Resourcen gesucht zu haben.



> Das GC-Konzept ist ja nett, aber wenn es nur für Speicher funktioniert doch irgendwie nicht sehr universell.


Das ist der Unterschied zu C++: es löst zumindest einen großen Teil der Probleme auf eine recht elegante und performante Weise


----------



## Java-Basher (30. Dez 2011)

escalate hat gesagt.:


> Mit der automatischen Speicherverwaltung fallen schonmal die allermeisten Resourcen-Probleme weg;


 Bei mir macht Speicherbeschaffung vielleicht 1/3 der Ressourcen aus. Dateien und andere Objekte (z.B. Shader, Sockets) sind da nicht zu vernachlässigen.



escalate hat gesagt.:


> Das ist von der Funktionsweise her auch nicht viel anders als ein Destruktor, der ja auch irgendwie ausgelöst werden muss.


 Nein, ein Destruktor wird automatisch, immer und exception-sicher aufgerufen. Das ist mit einer Methode nicht zu vergleichen.



escalate hat gesagt.:


> Das ist auch mit Vorsicht zu genießen, da eben die GC verzögert sein kann aber Destruktoren in sind ja auch nicht ganz ohne Probleme


 Eigentlich.. schon. Welche Probleme siehst du bei Destruktoren?



escalate hat gesagt.:


> Das ist der Unterschied zu C++: es löst zumindest einen großen Teil der Probleme auf eine recht elegante und performante Weise


 Ob das performant ist will ich hier mal nicht diskutieren, aber der Teil der für den Speicher zuständig ist, ist elegant, ohne Frage. Man muss sich da einfach nicht mehr drum kümmern. Was das für Nebeneffekte bei der Speicherorganisation hat ignoriere ich auch mal. Aber ein Konzept das als Ressourcen nur Speicherbeschaffung in Blick nimmt und bei dem man ansonsten alles manuell aufrufen muss, halte ich für ziemlich halbgar.

Ich finde es nur lustig wie ich mich immer vor Java gesträubt habe. Als ich C gelernt habe, wollte ich primär wissen wie so ein Computer eigentlich funktioniert, da war Java natürlich die falsche Wahl. Als ich dann C++ konnte hätte ich auch öfter mal zu Java schauen können, aber irgendwie haben dann Templates gefehlt und dank meiner Nähe zu C hatte ich da auch keine große Motivation. Jetzt bin ich quasi gezwungen mit Java zu arbeiten (Android) und bin sogar guter Dinge an diese ominöse Sprache gegangen, die einem alles so leicht macht, bei der man sich um nichts mehr kümmern muss und sich ganz auf sein Programm konzentrieren kann. Offen gesagt bin ich ziemlich enttäuscht, und ich kann überhaupt nicht mehr nachvollziehen warum jemand behaupten sollte Java sei sicherer als C++. Gut, bei Java liegen Rücksprungadresse und Daten nicht hintereinander, also Bufferoverflows sind weniger problematisch. Aber sonst? Ressourcen müssen mit der Ausnahme von Speicher manuell freigegeben werden, Referenzen müssen nicht initialisiert sein, keine Operatorüberladungen. Irgendwie hatte ich mehr erwartet. So fühlt sich das Programmieren fast wieder an wie in C, außer dass man überall komische try/catch Blöcke bauen muss.


----------



## MasterK (30. Dez 2011)

Noctarius hat gesagt.:


> Das manuelle [c]close()[/c] musst du natürlich machen, wieso sollte das in Java nicht gehen? [c]InputStream.close()[/c]
> Das wurde in Java 7 jetzt aber automatisiert:
> 
> 
> ...



Gerade dieses beispiel zeigt hervorragend, wie sich die sprache java langsam in eine sackgasse manöveriert. Dieses recht eklige "try-with-resources" funktioniert nur mit AutoCloseable, das ganze wirkt eher wie ein übler hack, besonders wenn man sich die beschreibung zu diesem interface anschaut. Dank destruktoren funktioniert das in c++ elegant für alle klassen. Und vor allem nicht nur in einem try-catch, sondern in jedem beliebigen block. Es gibt ja durchaus auch java bibliotheken die keine exceptions werfen, sondern fehlercodes zurückliefern (zB wenn es schmale wrapper um C bibliotheken sind).


----------



## escalate (30. Dez 2011)

Java-Basher hat gesagt.:


> Nein, ein Destruktor wird automatisch, immer und exception-sicher aufgerufen. Das ist mit einer Methode nicht zu vergleichen.


Das lässt sich mit einer selbstgebauten Methode auch erreichen. Wie man das genau macht hängt von den genauen Umständen ab. 



> Eigentlich.. schon. Welche Probleme siehst du bei Destruktoren?


Was mache ich, wenn da irgendwas schiefgeht? Exceptions werfen im Destruktor soll ja keine so gute Idee sein...



> Was das für Nebeneffekte bei der Speicherorganisation hat ignoriere ich auch mal.


GCs können auch den Speicher defragmentieren und habe sonst noch eine Menge Optimierungen auf Lager. Gibt eine Menge Material zu dem Thema, das kann ich nur  empfehlen. Immerhin gibt es das schon seit über 50 Jahren und es steckt schon eine Menge Arbeit drin. 

Das zu ignorieren und den Speicher per Hand zu verwalten halte ich in den meisten Fällen schon für ein wenig veraltet 

Man muss auch die GC nicht zwingend vorschreiben, bei D kann man sich auch nach Bedarf selbst um den Speicher kümmern oder irgendwelche Container mit Referenzzählung benutzen. Leider funktioniert das umgekehrt bei C++ nicht so wirklich.



> Aber ein Konzept das als Ressourcen nur Speicherbeschaffung in Blick nimmt und bei dem man ansonsten alles manuell aufrufen muss, halte ich für ziemlich halbgar.


Ist ja auch nicht so, dass es keine guten und funktionierenden Alternativen gibt.

Wie gesagt: einfach einen Container mit Referenzzählung bauen und das hat sich das Thema auch erledigt.



> Offen gesagt bin ich ziemlich enttäuscht, und ich kann überhaupt nicht mehr nachvollziehen warum jemand behaupten sollte Java sei sicherer als C++.


In Sachen Produktivität fand ich Java auch sehr enttäuschend wenn ich mir mal überlege dass die Sprache eigentlich recht jung ist und weil ich sowas wie Python kenne 



> Gut, bei Java liegen Rücksprungadresse und Daten nicht hintereinander, also Bufferoverflows sind weniger problematisch.


Es gibt aber auch keine Möglichkeit, über das Ende eines Arrays hinaus oder per Zeiger einfach irgendwohin zuschreiben. Das bringt schon eine ganze Menge. Eine "managed" Umgebung in der VM ist schon wesentlich besser isoliert als native C++-Programme. 

Da gibt es zwar mittlerweile auch einiges an Speicher- und Ausführungsschutz vom System aber ganz so umfassend ist das nicht.

Wenn ich in Java irgendetwas uninitialisiert verwende passiert ja auch nicht viel und bei lokalen Variablen meckert sowieso vorher der Compiler.


----------



## Noctarius (30. Dez 2011)

MasterK hat gesagt.:


> Gerade dieses beispiel zeigt hervorragend, wie sich die sprache java langsam in eine sackgasse manöveriert. Dieses recht eklige "try-with-resources" funktioniert nur mit AutoCloseable, das ganze wirkt eher wie ein übler hack, besonders wenn man sich die beschreibung zu diesem interface anschaut. Dank destruktoren funktioniert das in c++ elegant für alle klassen. Und vor allem nicht nur in einem try-catch, sondern in jedem beliebigen block. Es gibt ja durchaus auch java bibliotheken die keine exceptions werfen, sondern fehlercodes zurückliefern (zB wenn es schmale wrapper um C bibliotheken sind).



Und wo ist die Unlogik ein Interface zu haben welches sich "AutoCloseable" nennt? Ich finde der Interfacename trifft es schon ziemlich gut.
Klar könnte man auch einfach in Object eine Methode [c]destroy()[/c] definieren welche dann überschrieben werden muss um im try-Block aufgerufen zu werden, aber ob das schöner ist?

Abgesehen davon, was hindert dich daran AutoCloseable immer und überall zu implementieren? Ist auch nur eine Methode mehr, genau wie ein Destruktor.


----------



## Landei (30. Dez 2011)

MasterK hat gesagt.:


> ...
> Dank destruktoren funktioniert das in c++ elegant für alle klassen.
> ...



Eine Sprache, die nicht hinter ihren Objekten saubermacht, ist schlicht und ergreifend inkontinent. Aber wenn du ständiges Windelwechseln für "elegant" hältst...


----------



## Dit_ (30. Dez 2011)

TheDarkRose hat gesagt.:


> Hey, solche Aktionen kommen auch nur vor, wenn ein "Noob" meint einen Server im Internet administrieren zu "können", was genau so fahrlässig ist wie ein Auto ohne Führerschein zu lenken *hmpf*


das sagt schon viel über die Benutzerfreundlichkeit von OS der Zukunft.


----------



## Java-Basher (30. Dez 2011)

escalate hat gesagt.:


> Das lässt sich mit einer selbstgebauten Methode auch erreichen. Wie man das genau macht hängt von den genauen Umständen ab.


 Dass man das Verhalten *irgendwie* erreichen kann, ist mir bewusst. Allerdings eben lange nicht so schön. Und darum geht es doch, sonst kann man ja auch Assembler programmieren. Während man in Java ein try/catch/finally Konstrukt bauen muss(?), macht man in C++ einfach gar nichts, weil der Destruktor eh sicher ausgeführt wird.
Vor allem sollte ein Destruktor der bei Refcount 0 ausgeführt wird doch kein Problem sein, der GC muss deshalb ja den Speicher nicht freigeben?



escalate hat gesagt.:


> Was mache ich, wenn da irgendwas schiefgeht? Exceptions werfen im Destruktor soll ja keine so gute Idee sein...


 Das stimmt, aus einem Destruktor sollte keine Exception entkommen. Andererseits.. was willst du auch machen, wenn eine Datei nicht geschlossen werden kann? Was machst du denn, wenn der GC keinen Speicher mehr freigeben kann? Das sind irgendwie Fälle, bei denen die Welt eh untergegangen ist.



escalate hat gesagt.:


> Das zu ignorieren und den Speicher per Hand zu verwalten halte ich in den meisten Fällen schon für ein wenig veraltet


 Wenn man die Performance braucht nutzt man halt Allokatoren. Und die dürften auch ohne 50 Jahre Forschung in den allermeisten Fällen wesentlich schneller als ein GC sein, weil der Programmierer hier bereits Dinge weiß, die der GC nicht wissen kann. Aber das Performance-Thema sollten wir vielleicht erst mal außen vor lassen. Allerdings bin ich immer offen für eine Performance-Challenge. (Stellt ne Aufgabe, ich implementiere es in C++) 



escalate hat gesagt.:


> Wie gesagt: einfach einen Container mit Referenzzählung bauen und das hat sich das Thema auch erledigt.


 Hier kann ich dir nicht ganz folgen..




escalate hat gesagt.:


> Es gibt aber auch keine Möglichkeit, über das Ende eines Arrays hinaus oder per Zeiger einfach irgendwohin zuschreiben.


 Wie gesagt, du kannst in einem modernen System nicht einfach irgendwo hinschreiben. Der Speicher muss dir gehören. Auch native Programme müssen schließlich am System vorbei.



escalate hat gesagt.:


> Da gibt es zwar mittlerweile auch einiges an Speicher- und Ausführungsschutz vom System aber ganz so umfassend ist das nicht.


 Doch. Also dein eigenes Programm schützt es leider nicht, aber auf fremden Speicher kannst du so nicht zugreifen.



escalate hat gesagt.:


> Wenn ich in Java irgendetwas uninitialisiert verwende passiert ja auch nicht viel und bei lokalen Variablen meckert sowieso vorher der Compiler.


 Das ist in vermutlich allen anderen Sprachen nicht anders.


----------



## Anderer Basher (30. Dez 2011)

Noctarius hat gesagt.:


> Ob man Operator-Overloading benötigt ist Geschmackssache. Offiziell wird es nicht eingeführt, weil es unleserlichen Code erzeugen kann.
> 
> ```
> Haus haus1 = new Haus("Meins");
> ...



Dass du als Mod ein solches Anti-Argument bringst, finde ich unter aller Sau. Zumal du ja offenbar selbst für Operator-Überladung bist. Ich könnte genauso eine Methode schreiben, die .add() heißt und in Wirklichkeit eine Email an den Chef mit dem Inhalt "**** dich" sendet, oder beim nächsten Lieferdienst Pizza bestellt. Wie wäre es mit einer Variable namens socket, die eigentlich ein Thread ist?

C++ stellt einem hier ein wichtiges Mittel zur Verfügung, seinen Code ausdrucksstärker zu machen. Jedes Sprachmittel kann missbraucht werden, aber darum geht es nicht. Kein guter Programmierer würde so einen operator + schreiben, deshalb ist das Argument unbrauchbar.


----------



## escalate (30. Dez 2011)

Java-Basher hat gesagt.:


> Dass man das Verhalten *irgendwie* erreichen kann, ist mir bewusst. Allerdings eben lange nicht so schön.


Dass der Code für die Speicherverwaltung komplett wegfällt, das ganze recht schnell ist und ich da absolut keinen Fehler mehr machen kann halte ich für wesentlich wichtiger für die "Schönheit". 

Der Rest wird fast immer von irgendwelchen Libraries übernommen, da muss ich auch kaum etwas per Hand schreiben.
Klar, wenn man in C oder C++ mehr Code selber schreibt und kaum Libs benutzt muss man sich öfter selbst um irgendwelche Resourcen kümmern.

Eine Datenbankverbindung habe ich auch schon lange nicht mehr per Hand zugemacht und wenn ich eine Datei benutze mache ich die nach dem Schreib- oder Lesevorgang meistens gleich wieder zu 

Wie gesagt, wenn sogar eher "Low-Level"-Sprachen wie D oder Go auf GC setzen kann das wohl nicht die falsche Richtung sein für Sprachen, mit denen man auf einer etwas höheren Ebene entwickelt. 

Garbage Collection - D Programming Language

Über Schönheit kann man sich natürlich streiten, aber für mich ist C++ die hässlichste Sprache, die ich bisher benutzt habe. Fortran (immerhin in einer modernen Form) war auch dabei  Man kann damit leben, aber ich bin doch ganz froh, wenn ich was anderes benutzen kann...



> Und darum geht es doch, sonst kann man ja auch Assembler programmieren.


C++ ist aber schon etwas näher an Assembler als Java, oder? 



> Vor allem sollte ein Destruktor der bei Refcount 0 ausgeführt wird doch kein Problem sein, der GC muss deshalb ja den Speicher nicht freigeben?


Doch, das ist ein Problem, wenn man keine Refcounts hat  Die JVM verzichtet ja auch Refcounting und das hat ja auch gute Gründe.



> Das stimmt, aus einem Destruktor sollte keine Exception entkommen.


Dann muss man aber auch wissen, dass der komplette Code, der irgendwie vom Destruktor aufgerufen wird sich an die Regeln hält. Oder ich packe es auch wieder in try-catch ein, aber schön ist das dann auch nicht mehr...


----------



## fastjack (30. Dez 2011)

Noctarius hat gesagt.:
			
		

> Ob man Operator-Overloading benötigt ist Geschmackssache. Offiziell wird es nicht eingeführt, weil es unleserlichen Code erzeugen kann.



Genau aus den Gründen die Du aufgeführt hast, ist das auch gut so!

-- für Operator-Overloading

Normalerweise lag der eigentliche Reiz an Java in einer gewissen wohl-Definiertheit, der leider immer mehr und mehr aufgeweicht wird.


----------



## Anderer Basher (31. Dez 2011)

escalate hat gesagt.:


> Dass der Code für die Speicherverwaltung komplett wegfällt, das ganze recht schnell ist und ich da absolut keinen Fehler mehr machen kann halte ich für wesentlich wichtiger für die "Schönheit".


Richtig. Genau darum gehts. Und genau das ist in Java nicht der Fall. Ich muss manuell irgendwas closen.



escalate hat gesagt.:


> Der Rest wird fast immer von irgendwelchen Libraries übernommen, da muss ich auch kaum etwas per Hand schreiben.


kaum != gar nichts
Wo du etwas per Hand schreiben musst, können Fehler passieren. Immer.



escalate hat gesagt.:


> C oder C++


Boah ey, Junge. Du hast echt nichts verstanden. Du bist der Realität gegenüber so ignorant, dass du dir einredest, C++ sei immer noch eine Erweiterung von C. Es ist mehr als das. Die Sprachen haben sich auseinanderentwickelt. In C musst du alles manuell aufräumen, also immer schön die Finger still halten, was das betrifft.



escalate hat gesagt.:


> mehr Code selber schreibt und kaum Libs benutzt muss man sich öfter selbst um irgendwelche Resourcen kümmern.


So 'n Blödsinn. Wenn du eine OS-API wrappst, schreibst du dir eine kleine Klasse, die im Destruktor ein close(handle) oder etwas vergleichbares macht, das wars dann auch schon. Dieses Konzept lässt sich auf jede beliebige Resource übertragen. Der Aufwand ist minimal.



escalate hat gesagt.:


> Eine Datenbankverbindung habe ich auch schon lange nicht mehr per Hand zugemacht und wenn ich eine Datei benutze mache ich die nach dem Schreib- oder Lesevorgang meistens gleich wieder zu


Das macht alles RAII für mich.



escalate hat gesagt.:


> Wie gesagt, wenn sogar eher "Low-Level"-Sprachen wie D oder Go auf GC setzen kann das wohl nicht die falsche Richtung sein für Sprachen, mit denen man auf einer etwas höheren Ebene entwickelt.


Tausende Fliegen können nicht irren, schon klar. Warum verweigerst du dich eigentlich der Realität und behauptest, man müsse so extrem viel mit Resourcen hantieren? In C++ ist der vom Java-Basher erwähnte unique_ptr die Lösung für die meisten Fälle. Meist sind Besitzverhältnisse so klar, dass man nicht lange darüber nachdenken muss, wo und wann irgendwas freigegeben werden muss.

Was der Java-Basher nicht weiß: Man kann mit unique_ptr auch jede beliebige Art von Resource verwalten, indem man einen sog. "Deleter" angibt, also eine Funktion, die bei Freigabe aufgerufen werden soll.



escalate hat gesagt.:


> Über Schönheit kann man sich natürlich streiten, aber für mich ist C++ die hässlichste Sprache, die ich bisher benutzt habe. Fortran (immerhin in einer modernen Form) war auch dabei  Man kann damit leben, aber ich bin doch ganz froh, wenn ich was anderes benutzen kann...


Weil du kein modernes C++ kennst. Modernes C++ besteht nicht aus irgendwelchen Zeigerfrickeleien, Resource-Frickeleien oder ähnliches, wie ich sie immer wieder von naiven Programmierern hören muss. Es gibt da so ein schönes Sprichwort, es fängt an mit: Wenn man keine Ahnung hat, ...



escalate hat gesagt.:


> Doch, das ist ein Problem, wenn man keine Refcounts hat  Die JVM verzichtet ja auch Refcounting und das hat ja auch gute Gründe.


Richtig, Refcounts haben ihre Probleme. Aber 1) sind Besitzverhältnisse in 99,9% der Fälle so klar, dass ein GC die langsame, inperformante und unnötige Wahl ist und 2) Wird selbst der GC irgendwann feststellen, dass ein Objekt nicht mehr gebraucht wird und kann dann eine entsprechende Freigabemethode aufrufen.



escalate hat gesagt.:


> Dann muss man aber auch wissen, dass der komplette Code, der irgendwie vom Destruktor aufgerufen wird sich an die Regeln hält.


Nicht unbedingt. Es hat sich in C++ die Konvention durchgesetzt, in Destruktoren nichts zu werfen. Wenn man über einen solchen Fehler informiert werden möchte, ruft man explizit eine .close() Methode auf, die etwas wirft oder ein Fehlerflag setzt.



escalate hat gesagt.:


> Oder ich packe es auch wieder in try-catch ein, aber schön ist das dann auch nicht mehr...


Das ist dann aber immer noch nur ein einziges mal, nämlich genau dann, wenn ich den Destruktor implementiere. Besser, als bei jeder Verwendung der Klasse einen try-catch Block um das close zu brauchen. Absolut lächerlich.


----------



## escalate (31. Dez 2011)

fastjack hat gesagt.:


> Genau aus den Gründen die Du aufgeführt hast, ist das auch gut so!
> 
> -- für Operator-Overloading



Fehlende Möglichkeiten, Infix-Operatoren zu definieren führt dazu, dass man hin und wieder unleserlichen Code schreiben muss (nicht nur kann).


```
BigInteger y = a2.multiply(x.pow(2)).add(a1.multiply(x)).add(a0);
```
Ist schon sehr hübsch, aber ich schreibe lieber:


```
y = a2 * x ** 2 + a1 * x + a0
```



> Normalerweise lag der eigentliche Reiz an Java in einer gewissen wohl-Definiertheit, der leider immer mehr und mehr aufgeweicht wird.


Vielleicht wäre es wirklich besser, einen Schlussstrich zu ziehen und nur noch Kleinigkeiten zu verbessern. Wer das nicht will kann sich ja bei anderen Sprachen umsehen. Gibt doch genügend Auswahl...


----------



## Java-Basher (31. Dez 2011)

escalate hat gesagt.:


> Dass der Code für die Speicherverwaltung komplett wegfällt, das ganze recht schnell ist und ich da absolut keinen Fehler mehr machen kann halte ich für wesentlich wichtiger für die "Schönheit".


 Die Speicherverwaltung fällt mit Destruktoren genau so weg. Aber sie sind halt darüber hinaus wesentlich mächtiger als der GC. (Siehe manuelles close())



escalate hat gesagt.:


> Über Schönheit kann man sich natürlich streiten, aber für mich ist C++ die hässlichste Sprache, die ich bisher benutzt habe.


 Aber auch wenn man über Schönheit streiten kann, sollte man schon Gründe dafür nennen. Manuelle Speicherverwaltung lasse ich jedenfalls nicht gelten, denn dazu wirst du schlicht und ergreifend nicht gezwungen.



escalate hat gesagt.:


> Dann muss man aber auch wissen, dass der komplette Code, der irgendwie vom Destruktor aufgerufen wird sich an die Regeln hält.


 Stimmt, aber der Destruktor besteht meinstens aus einem delete oder einer Funktion einer C-API, da hält sich der Aufwand in Grenzen.


----------



## escalate (31. Dez 2011)

> Boah ey, Junge. Du hast echt nichts verstanden. Du bist der Realität gegenüber so ignorant, dass du dir einredest, C++ sei immer noch eine Erweiterung von C.


Interessant, dass du meinst meine Gedanken lesen zu können aber da ist wohl etwas schiefgelaufen...



> Weil du kein modernes C++ kennst.


Da hat dein Gedankenlese-Modul schon wieder übelst versagt...



> Tausende Fliegen können nicht irren, schon klar.


Wenn die Fliegen schon einen C++-Compiler geschrieben haben würde ich sie zumindest ernstnehmen 

Lies dir mal durch, was ein Erfinder einer modernen Programmiersprache zu dem Thema GC zu sagen hat und dann sagst du mir mal, was du davon nicht glaubst.



> Nicht unbedingt. Es hat sich in C++ die Konvention durchgesetzt, in Destruktoren nichts zu werfen.


Wenn man sich auf Konventionen verlässt können Fehler passieren.


----------



## Anderer Basher (31. Dez 2011)

escalate hat gesagt.:


> Interessant, dass du meinst meine Gedanken lesen zu können aber da ist wohl etwas schiefgelaufen...


Ich nur langsam angepisst von den Programmierern anderer Sprache, die mich mit C'lern in eine Schublade stecken. Entschuldige den Ton.



escalate hat gesagt.:


> Lies dir mal durch, was ein Erfinder einer modernen Programmiersprache zu dem Thema GC zu sagen hat und dann sagst du mir mal, was du davon nicht glaubst.


Werde bitte etwas konkreter.



escalate hat gesagt.:


> Wenn man sich auf Konventionen verlässt können Fehler passieren.


Richtig, aber 1) Verwende ich schlechten Code nicht und 2) habe ich meinen letzten Destruktor vor geschätzt 'nem Monat geschrieben.

P.S.: Ich finde ist interessant, dass du lediglich zu dem irrelevanten Mist, der lediglich meine persönliche Meinung widerspiegelst, Stellung beziehst, aber meine sachlichen Argumente vollkommen ignorierst.


----------



## fastjack (31. Dez 2011)

Ihr könnt übrigens auch buchstabenweise zitieren 

Naja, auf jeden Fall können Fliegen und deren Maden an einem Tag 140 Kilogramm totes Elefantenfleisch in Brei umwandeln (hab ich gerade in N24 gesehen). Aber ne Fliege die nen c++ Compiler schreibt, neeee.

@Java-Basher Du merkst ab das Du hier in einem Java-Forum bist oder nicht gelle?


----------



## Java-Basher (31. Dez 2011)

fastjack hat gesagt.:


> @Java-Basher Du merkst ab das Du hier in einem Java-Forum bist oder nicht gelle?


 Äh.. was?


----------



## escalate (31. Dez 2011)

Mich würde einfach mal deine Meinung  (oder die vom anderen Basher) zu diesem Link hier interessieren:

Garbage Collection - D Programming Language

Würdest du dem Erfinder von D (oder auch denen von Go) empfehlen, den GC standardmäßig wegzulassen?



Anderer Basher hat gesagt.:


> Richtig. Genau darum gehts. Und genau das ist in Java nicht der Fall. Ich muss manuell irgendwas closen.


Der zitierte Teil von mir bezieht sich auf die Speicherverwaltung. Und da muss ich nichts manuell closen, also was soll ich mit der Antwort anfangen?



> So 'n Blödsinn. Wenn du eine OS-API wrappst, schreibst du dir eine kleine Klasse, die im Destruktor ein close(handle) oder etwas vergleichbares macht, das wars dann auch schon. Dieses Konzept lässt sich auf jede beliebige Resource übertragen. Der Aufwand ist minimal.


Da kann ich nur auf das nächste Zitat verweisen:



> kaum != gar nichts
> Wo du etwas per Hand schreiben musst, können Fehler passieren. Immer.


Es ist wie bei Konventionen: es können Fehler passieren, im Normalfall aber eher nicht. Wie gesagt, ich habe schon länger nichts mehr manuell aufräumen müssen und im Normalfall macht das eine Lib im Hintergrund. Der vertraue ich auch, dass sie das richtig macht.
Im "schlimmsten" Fall muss ich an sinnvoller Stelle ein obj.dispose() aufrufen und das ist jetzt auch nicht besonders fehleranfällig. 



> Warum verweigerst du dich eigentlich der Realität und behauptest, man müsse so extrem viel mit Resourcen hantieren?


Extrem viel? Wer sagt denn das? Ich muss quasi überhaupt nicht mit Resourcen hantieren und bei C++ darf man sich (je nach Anwendung) zusätzlich noch ein bisschen mit Speicherverwaltung beschäftigen...



> Besser, als bei jeder Verwendung der Klasse einen try-catch Block um das close zu brauchen. Absolut lächerlich.


Dazu zwingt einen keiner, man kann den Code anders organisieren.


----------



## MasterK (31. Dez 2011)

Noctarius hat gesagt.:


> Und wo ist die Unlogik ein Interface zu haben welches sich "AutoCloseable" nennt? Ich finde der Interfacename trifft es schon ziemlich gut.


Es geht überhaupt nicht um den namen, sondern um die art und weise an sich. Was mach ich denn, wenn ich eine bibliothek benutze, welche mir eine final klasse ohne AutoCloseable zur verfügung stellt?
Es ist eben ein nachträglich rangepapptes feature welches nicht mal allgemeingültig funktioniert.



escalate hat gesagt.:


> Was mache ich, wenn da irgendwas schiefgeht? Exceptions werfen im Destruktor soll ja keine so gute Idee sein...


Die gegenfrage wurde ja schon gestellt: was machst du in seinem solchen fall? Ein try-catch-finally block um den try-catch block?



Landei hat gesagt.:


> Eine Sprache, die nicht hinter ihren Objekten saubermacht, ist schlicht und ergreifend inkontinent. Aber wenn du ständiges Windelwechseln für "elegant" hältst...


Holen wir jetzt den fäkalhumor raus? Man kanns auch anders ausdrücken: in C++ darf ich selbst entscheiden, wann ich sch****.

Letztendlich ist die ganze diskussion bzgl GC in c++ und java eh schwachsinn. Wenn man c++ nutzt, dann ja gerade auch wegen der möglichkeit, das löschen von objekten absolut eindeutig definieren zu können. So wie der GC eben ein feature von java ist, ist eben RAII ein feature von c++. Sie haben beide ihre berechtigung und sind beide mächtige werkzeuge. Letztendlich gibt es bzgl GC nur eines zu sagen: wenn ich in C++ garbage collection haben will, dann KANN ich das auch. Ja, es gibt auch GC bibliotheken für c++. Aber garantiert aufgerufene desktruktoren in java kann ich nicht haben.

Und um das ganze noch abzurunden: In welcher sprache ist eigentlich die HotSpot VM geschrieben?


----------



## Noctarius (31. Dez 2011)

Anderer Basher hat gesagt.:


> Dass du als Mod ein solches Anti-Argument bringst, finde ich unter aller Sau. Zumal du ja offenbar selbst für Operator-Überladung bist. Ich könnte genauso eine Methode schreiben, die .add() heißt und in Wirklichkeit eine Email an den Chef mit dem Inhalt "**** dich" sendet, oder beim nächsten Lieferdienst Pizza bestellt. Wie wäre es mit einer Variable namens socket, die eigentlich ein Thread ist?
> 
> C++ stellt einem hier ein wichtiges Mittel zur Verfügung, seinen Code ausdrucksstärker zu machen. Jedes Sprachmittel kann missbraucht werden, aber darum geht es nicht. Kein guter Programmierer würde so einen operator + schreiben, deshalb ist das Argument unbrauchbar.



Äh? Ich habe lediglich gesagt, dass es aus diesem Grund nicht integriert wird. Das war die offizielle SUN Aussage - habe ich an irgendeiner Stelle gesagt, dass ich diese Ansicht teile?

Vielleicht erst lesen, dann denken, dann abreagieren, dann von C++ auf Java schalten und erst danach antworten...

Leute wie du sind es die unserem tatsächlich mal sachlichem C++-Freund Sätze erzwingen wie "ich will nicht flamen oder trollen" ... Junge Junge... Und schon sind wir wieder im Kindergarten.


----------



## Landei (31. Dez 2011)

MasterK hat gesagt.:


> Holen wir jetzt den fäkalhumor raus? Man kanns auch anders ausdrücken: in C++ darf ich selbst entscheiden, wann ich sch****.



Da kommen wir zum Punkt: Wieso glaubst du, dass du die beste Methode und den besten Zeitpunkt besser bestimmen kannst als ein moderner, ausgereifter GC? Die Praxis zeigt, dass der GC seinen Job extrem gut (und natürlich 100% fehlerfrei) macht, auf jeden Fall besser als der durchschnittliche C++-Programmierer. Die Anwendungen, wo extremes Finetuning und absolute Kontrolle notwendig sind, sind eine Nische, für die Java sowieso nicht gedacht ist. Die breite Masse der Anwendungsprogramme braucht so etwas schlicht und ergreifend nicht.

Ich habe das Gefühl, manche Programmierer denken, sie "verlieren die Kontrolle", wenn ihnen der Compiler, GC, die IDE oder sonstwer Arbeit abnimmt, aber* genau das Gegenteil ist der Fall*, sie _gewinnen zusätzliche _Kontrolle. Meditiere ein wenig darüber, dann wirst du vielleicht auch erleuchtet.


----------



## Java-Basher (31. Dez 2011)

escalate hat gesagt.:


> Mich würde einfach mal deine Meinung  (oder die vom anderen Basher) zu diesem Link hier interessieren:





			
				D Seite hat gesagt.:
			
		

> Reference counting is a common solution to solve explicit memory allocation problems. [...]


 Ich habe shared_ptr noch nie gebraucht. (Denn üblicherweise hat ein Objekt auch einen klaren Scope.)


			
				D Seite hat gesagt.:
			
		

> Destructors are used to deallocate resources acquired by an object. For most classes, this resource is allocated memory. With garbage collection, most destructors then become empty and can be discarded entirely.


 Destruktoren werden wegoptimiert. Das sind keine Funktionsaufrufe. Folgende Programmausschnitte erzeugen identischen Code:

```
int main()
{
  std::unique_ptr<int>(new int);
}
// ----
int main()
{
  int *i = new int;
  if (i)
    delete i;
}
```



			
				D Seite hat gesagt.:
			
		

> All those destructors freeing memory can become significant when objects are allocated on the stack. For each one, some mechanism must be established so that if an exception happens, the destructors all get called in each frame to release any memory they hold. If the destructors become irrelevant, then there's no need to set up special stack frames to handle exceptions, and the code runs faster.


 Kann ich leider wenig zu sagen. Müsste man mal testen.


			
				D Seite hat gesagt.:
			
		

> All the code necessary to manage memory can add up to quite a bit. The larger a program is, the less in the cache it is, the more paging it does, and the slower it runs.


 Na ja. Destruktoren machen vielleicht 2% Code aus. Ich denke der Nachteil hält sich hier stark in Grenzen.


			
				D Seite hat gesagt.:
			
		

> Garbage collection kicks in only when memory gets tight. When memory is not tight, the program runs at full speed and does not spend any time freeing memory.


 Na gut. Das kann man in C++ natürlich auch erreichen, aber man muss es selbst machen.

Was mich aber an der gesamten Argumention stört ist, dass so getan wird als würde ein GC gar keine Zeit verbrauchen. Alles was die Destruktoren machen, muss der GC schließlich auch machen. Und zwar in doppelter Hinsicht: Er muss die Objekte verfolgen *und* freigeben.

Weiterhin habe ich ja auch nicht viel gegen einen GC an sich (zumindest außerhalb von C++), was mich wirklich stört ist, dass es keine Destruktoren gibt.

Interessant ist auch wie D das regelt. In D gibt es Destruktoren, trotz Müllsammler:


			
				D Seite hat gesagt.:
			
		

> The destructor is expected to release any resources held by the object.
> 
> The program can explicitly inform the garbage collector that an object is no longer referred to (with the delete expression), and then the garbage collector calls the destructor immediately, and adds the object's memory to the free storage. The destructor is guaranteed to never be called twice.


Und weiter:


			
				Digital Mars Seite hat gesagt.:
			
		

> However, if they:
> 
> are allocated as local symbols in a function
> are allocated using new
> ...


 Was ja zumindest brauchbar klingt. Schade, dass Java so etwas nicht hat. (Auch wenn ich Müllsammlung eher als Bibliotheksfeature anbieten würde.)


----------



## Noctarius (31. Dez 2011)

D Seite hat gesagt.:
			
		

> The destructor is expected to release any resources held by the object.
> 
> The program can explicitly inform the garbage collector that an object is no longer referred to (with the delete expression), and then the garbage collector calls the destructor immediately, and adds the object's memory to the free storage. The destructor is guaranteed to never be called twice.



Das wäre meiner Ansicht nach auch (wie schon oben irgendwo von mir erwähnt) ein interessantes Feature für einen GC. Es gibt Fälle wo es einfach Sinn machen würde, z.B. nach der Initialisierung einer Anwendung wo Tonnen an Daten geladen wurden nur um sie weiter zuverarbeiten (z.B. XML).


----------



## MasterK (31. Dez 2011)

Landei hat gesagt.:


> Wieso glaubst du, dass du die beste Methode und den besten Zeitpunkt besser bestimmen kannst als ein moderner, ausgereifter GC? Die Praxis zeigt, dass der GC seinen Job extrem gut (und natürlich 100% fehlerfrei) macht, auf jeden Fall besser als der durchschnittliche C++-Programmierer.


Hm, du willst es einfach nicht verstehen. Also 1) bin ich nicht nur ein durchschnittlicher C++ Programmierer 
2) Es geht nicht zwingend darum, den "besten" zeitpunkt zu bestimmen. Denn dieser wird entweder durch die sprache definiert (wenn das objekt den scope verlässt) oder ist relativ egal. Ich weiss nicht, ob du jemals _richtig_ mit C++ entwickelt hast oder nicht. Aber wenn, dann weiss man, dass man ohne GC, aber mit RAII eben etwas anders entwickelt. Was durchaus seine vorteile haben kann, wenn man einen destruktor hat, welcher garantiert dann aufgerufen wird wenn ein objekt zB aus einem container entfernt wird. Meiner meinung nach sollten leute, die von modernen C++ nicht wirklich ahnung haben bei solch einer diskussion am besten auch einfach die klappe halten. Wenn der java weg das einzig wahre wäre, dann bräuchte man nicht so eine krücke "try-with-resources".

Nur weil es keinen GC gibt heisst das nicht, dass man auch nur ein einziges mal den speicher selbst freigeben muss. Man sieht es zugegebenermaßen aber sehr häufig, sogar code in dem leute mit malloc rumhantieren obwohl idR absolut unnötig. Aber fehlendes know-how ist kein fehler der sprache.


----------



## Landei (1. Jan 2012)

MasterK hat gesagt.:


> Hm, du willst es einfach nicht verstehen. Also 1) bin ich nicht nur ein durchschnittlicher C++ Programmierer


Bleibt ja nur noch unterdurchschnittlicher. Ein überdurchschnittlicher Entwickler würde wissen, wie nützlich Abstraktionen sein können.



> 2) Es geht nicht zwingend darum, den "besten" zeitpunkt zu bestimmen. Denn dieser wird entweder durch die sprache definiert (wenn das objekt den scope verlässt) oder ist relativ egal.


Es gibt aber günstigere und weniger günstigere Zeitpunkte, den Speicher freizugeben. Und du hast wenig Chancen, einen günstigen (etwa wenn der Prozessor auf trödelnde IO wartet) zu erwischen. Aber das kann den Unterschied zwischen einer ruckeligen und flüssigen Applikation ausmachen.



> Ich weiss nicht, ob du jemals _richtig_ mit C++ entwickelt hast oder nicht. Aber wenn, dann weiss man, dass man ohne GC, aber mit RAII eben etwas anders entwickelt. Was durchaus seine vorteile haben kann, wenn man einen destruktor hat, welcher garantiert dann aufgerufen wird wenn ein objekt zB aus einem container entfernt wird.


Ersetze "anders" durch "low level", dann stimme ich dir zu.



> Meiner meinung nach sollten leute, die von modernen C++ nicht wirklich ahnung haben bei solch einer diskussion am besten auch einfach die klappe halten.



Man muss nicht in C++ programmieren können (nebenbei bemerkt _kann _ich es, neben Delphi, Prolog, Scala, Haskell und einigen anderen) um solche konzeptionellen Schwächen erkennen zu können. Ein Garbage Collector ist geradezu eine Voraussetzung dafür, dass eine Sprache ein gewisses Abstraktionsniveau erreichen kann: 





> Generally speaking, higher-level programming languages are more likely to have garbage collection as a standard feature. In languages that do not have built in garbage collection, it can often be added through a library, as with the Boehm garbage collector for C and C++. This approach is not without drawbacks, such as changing object creation and destruction mechanisms.
> 
> Most functional programming languages, such as ML, Haskell, and APL, have garbage collection built in. Lisp, which introduced functional programming, is especially notable for introducing this mechanism.
> 
> Other dynamic languages, such as Ruby (but not Perl 5, or PHP, which use reference counting), also tend to use GC. Object-oriented programming languages such as Smalltalk, Java and ECMAScript usually provide integrated garbage collection. Notable exceptions are C++ and Delphi which have destructors. Objective-C has not traditionally had it, but ObjC 2.0 as implemented by Apple for Mac OS X uses a runtime collector developed in-house, while the GNUstep project uses a Boehm collector.


(Garbage collection (computer science) - Wikipedia, the free encyclopedia)

Was schließen wir daraus? Sind denn die Entwickler aller anderen modernen Sprachen blöd, weil sie den Vorteil von Destruktoren nicht erkennen können? 

Ich finde es ehrlich gesagt ziemlich traurig, wenn Entwickler nicht über den Tellerrand "ihrer" Sprache schauen können.



> Wenn der java weg das einzig wahre wäre, dann bräuchte man nicht so eine krücke "try-with-resources".


Java ist für Anwendungsprogrammierung gemacht, und das geht um Längen besser als in C++. Wenn wir jetzt anfangen, "Krücken" zu zählen, käme C++ nämlich ziemlich schlecht weg.



> Nur weil es keinen GC gibt heisst das nicht, dass man auch nur ein einziges mal den speicher selbst freigeben muss. Man sieht es zugegebenermaßen aber sehr häufig, sogar code in dem leute mit malloc rumhantieren obwohl idR absolut unnötig. Aber fehlendes know-how ist kein fehler der sprache.



Richtig, fehlendes Know-How ist ein Problem von Entwicklern, die auf einem zu tiefen Level herumkrebsen und denken, ihre Pointer-Hacks und ihr Bit-Geschiebe wären große Kunst.


----------



## MasterK (1. Jan 2012)

Landei hat gesagt.:


> Richtig, fehlendes Know-How ist ein Problem von Entwicklern, die auf einem zu tiefen Level herumkrebsen und denken, ihre Pointer-Hacks und ihr Bit-Geschiebe wären große Kunst.


Weisst du eigentlich, was du da für einen unsinn schreibst? Pointer-hacks und Bit-geschiebe? Nur weil ich das machen KANN wenn ich es wirklich brauche, zwingt mich die sprache doch nicht dazu. Ich habe lediglich die wahl.



Landei hat gesagt.:


> Was schließen wir daraus? Sind denn die Entwickler aller anderen modernen Sprachen blöd, weil sie den Vorteil von Destruktoren nicht erkennen können?
> 
> Ich finde es ehrlich gesagt ziemlich traurig, wenn Entwickler nicht über den Tellerrand "ihrer" Sprache schauen können.


Ein vorschlag: du liest dir meine vorherigen posts durch und kommst dann zum schluss, dass du mir hier grad etwas vorwirfst das ich nie behauptet habe. Ok?

Apropos "tellerrand":
_Gefühlt_ habe ich die einschätzung, dass sich da java entwickler wesentlich schwerer mit tun. C++ entwickler meckern zwar mehr, schauen aber auch mehr. Zumindest mein ganz persönliches gefühl, dass ich so im laufe der jahre gewonnen habe.

Edit:
Ein punkt bzgl "destruktoren" hätte ich da aber doch noch. Warum gibt es dann konstruktoren? Ich mein, die argumente hier waren, man könne sich doch selbst eine "close" methode oder "finish" oder wie auch immer schreiben. Wozu brauchen wir dann konstruktoren? Schreiben wir doch einfach "init" oder "initialize" oder "prepare", jeder so wie er will? Keine ahnung was landei dagegen hat, aber ich habe ganz gern die möglichkeit, den lebenszyklus eines objekts von erstellen bis löschen klar definiert zu haben. Zumindest die _möglichkeit_ dazu, genau das zu haben. Wurde ja in diesem thread schon erwähnt, dass sich destruktoren und GC nicht ausschliessen müssen.


----------



## Java-Basher (1. Jan 2012)

Landei hat gesagt.:


> Wenn wir jetzt anfangen, "Krücken" zu zählen, käme C++ nämlich ziemlich schlecht weg.


 Dann mal los. Aber um gleich zwei Punkte vorwegzunehmen:
 - Fehlender Garbage-Collector: Argument im Zusammenhang des Threads nicht mehr sinnvoll. (C++ kann das halt auch, nur wird es einem nicht aufgezwungen, da nicht in die Sprache integriert. Eine Lösung im Standard wäre vielleicht sogar ganz nett, aber das gehört dann halt auch wieder nicht zur Sprache selbst.)
 - Kleine Standardbibliothek. Da hast du meine Zustimmung, aber das gehört halt auch nicht direkt zur Sprache.

Ich bin auf deine Krückensammlung gespannt.


----------



## Landei (1. Jan 2012)

MasterK hat gesagt.:


> Ein punkt bzgl "destruktoren" hätte ich da aber doch noch. Warum gibt es dann konstruktoren? Ich mein, die argumente hier waren, man könne sich doch selbst eine "close" methode oder "finish" oder wie auch immer schreiben. Wozu brauchen wir dann konstruktoren? Schreiben wir doch einfach "init" oder "initialize" oder "prepare", jeder so wie er will? Keine ahnung was landei dagegen hat, aber ich habe ganz gern die möglichkeit, den lebenszyklus eines objekts von erstellen bis löschen klar definiert zu haben. Zumindest die _möglichkeit_ dazu, genau das zu haben. Wurde ja in diesem thread schon erwähnt, dass sich destruktoren und GC nicht ausschliessen müssen.



Es gibt mehrere Unterschiede zwischen Konstruktoren und normalen Methoden, etwa der (explizite oder implizite) Aufruf von Super-Konstruktoren oder initialisierungsspezifische Details (wie das Setzen von final-Variablen). Aber das solltest du eigentlich wissen.


----------



## MasterK (1. Jan 2012)

Landei hat gesagt.:


> Es gibt mehrere Unterschiede zwischen Konstruktoren und normalen Methoden, etwa der (explizite oder implizite) Aufruf von Super-Konstruktoren oder initialisierungsspezifische Details (wie das Setzen von final-Variablen). Aber das solltest du eigentlich wissen.


Ja eben. Und es gibt mehrere unterschiede zwischen destruktoren und normalen methoden. Warum also destruktoren verteufeln und konstruktoren nicht?


----------



## Landei (2. Jan 2012)

Weil niemand wissen kann, welche Daten du in ein Objekt packen willst, aber völlig klar ist, wie diese Daten (und welche) am Ende wieder aufgeräumt werden müssen. 

Ein Konstruktor ist eben kein Spiegelbild eines Destruktors, man kann nicht individuelle Speicher für seine Daten anfordern, sondern bekommt diesen für _alle_ Daten geliefert, ob man will oder nicht (natürlich hat man die Wahl, den Speicher sofort zu belegen oder nicht).


----------



## MasterK (2. Jan 2012)

Landei hat gesagt.:


> Weil niemand wissen kann, welche Daten du in ein Objekt packen willst, aber völlig klar ist, wie diese Daten (und welche) am Ende wieder aufgeräumt werden müssen.


Dafür brauchst du keinen konstruktor. Da kannst du wie fürs "close()" auch einfach ein "init()" nehmen. Dass ein destruktor kein "spiegelbild" eines konstruktors ist ist mir klar. Dir ist aber durchaus klar, dass sich ein destruktor von normalen methoden in solch sinnvoller art und weise unterscheidet, dass destruktoren an sich sinnvoll sind?


----------



## Landei (3. Jan 2012)

MasterK hat gesagt.:


> Dafür brauchst du keinen konstruktor. Da kannst du wie fürs "close()" auch einfach ein "init()" nehmen.


In Java ginge das nicht, weil man keine Möglichkeit hat, Speicher manuell anzufordern. In solch einer Sprache ist es dann aber auch sinnlos, einen Destruktor zu haben, weil jedes Bit Speicher bereits unter Kontrolle der VM ist.

Natürlich ist in C++ ein Destruktor komfortabler als eine close()-Methode, keine Frage, aber ein GC ist eben trotzdem komfortabler als ein Destruktor, und ist alles, was man in der *Anwendungs*entwicklung braucht. Natürlich gibt es in der Low-Level-*System*entwicklung Fälle, wo man keinen GC haben darf, z.B. um selbst einen GC zu implementieren - aber das brauchen wir hier nicht zu diskutieren, dafür ist Java sowieso nicht gemacht.


----------



## MasterK (3. Jan 2012)

Und c++ entwickler sind eben der meinung (der meinung bin ich auch), dass ein destruktor und RAII auch oft vorteile hat. Ein paradebeispiel ist ja das try-with-resources in java...


----------



## fastjack (3. Jan 2012)

Utopia hat gesagt.:
			
		

> Hallo,
> ich möchte gerne Programmieren lernen. Ich habe 4 große Sprachen gefunden, die wohl infrage kommen würden: C, C++, C#, Java. Was denkt ihr, womit ich anfangen sollte? (Und ich frage hier natürlich mit gewisser Absicht in einem Java Forum, also haut ruhig die Vorteile eurer wahrscheinlichen Lieblingssprache raus, von einem Bekannten wurde mir nämlich C++ empfohlen und ich möchte ja etwas zum Gegenhalten haben.)



*C, C++, C#, Java?* Das ist war hier die Frage.

Allein aus der bisherigen Diskussion kann man eigentlich die Komplexität von c / c++ erkennen, was jetzt um Gottes willen nicht heißen soll daß diese Sprachen schlechter sind. Ich denke ein Anfänger will sich heutzutage nicht mit char* oder Destruktoren, oder... herumschlagen, er will einfach das seine Gehversuche funktionieren. C# wäre mir ehrlich gesagt zu fett / viel / groß. Kurzum nimm *Java*.


----------



## bronks (3. Jan 2012)

Eines vorab: Ich bin kein Fan von Microsoft, C# und .NET, aber von den Entwicklungen in Java bin ich zunehmend immer mehr angepi**t. Aber da bin ich zum Glück nicht alleine.

Der TIOBE-Index wird immer hervorgekramt, um zu zeigen, wie beliebt doch Java ist. An dem Index ist auch eindeutig zu erkennen, daß Java seit Jahren unbeliebter wird. Richtig eingebrochen ist die Linie kurz bevor EE5 in Aussicht gestellt wurde, denn da waren die EE-Entwickler schon richtig gelangweilt.



fastjack hat gesagt.:


> ... Gehversuche funktionieren ... C# wäre mir ehrlich gesagt zu fett / viel / groß. Kurzum nimm *Java*.


Sorry, aber was ist an C# so fett, viel und groß? 

Ja, es stimmt, denn man hat Windows, Visual Studio, IIS und SQL Server inclusive. Alles durchdacht, selbserklärend, getestet und funktionierend.

Und nochmal:
Ja, es stimmt, denn noch hat Sun/Oracle/JCP es nicht geschafft alle guten Ideen aus C#/.NET zu kopieren. Der Grund liegt wohl darin, daß man sich in einer üblen technischen Sackgasse verfahren hat. Dafür versucht man jetzt mit z.B. TryWithRessources eigene wege zu gehen.



EDIT: Reihenfolge der Absätze in Ordnung gebracht.


----------



## Firephoenix (3. Jan 2012)

Die Diskussion hier ist mittlerweile auf einem Niveau als würde man in den Baumarkt schreien:
"Welches Werkzeug ist am wichtigsten"
und als Antworten kommen:
Heimwerker: Hammer
Maler: Pinsel
Heimwerker2: Bohrer
Schreiner: Säge
Elektriker: Isolierwerkzeug
Heimerwerker3: Schraubenzieher

und dannach beginnt die Debatte ob man besser in die Wand schraubt oder Nageln soll, natürlich kann man mit der Säge auch keine Löcher in die Wand sägen, außer man modifiziert die Säge entsprechend, damit wird aber der Hammer wieder hinfällig.
Nich zu vergessen, dass man mit dem Hammer auch Nageln kann falls nötig - oder war es schrauben?
Natürlich macht es auch einen riesen Unterschied ob der Pinsel einen Handschutz für die Farbe hat - alle anderen sind ja mittlerweile veraltet und kosten zuviel Zeit weil man sich noch die Finger waschen muss - was man aber auch mit Handschuhen und Malerkittel vermeiden könnte 

Und jetzt hauen mit gleich hunderte Leute auf den Kopf die noch nicht damit fertig waren ihre Lieblingsprogrammiersprachen zu verteidigen


----------



## fastjack (3. Jan 2012)

> Ja, es stimmt, denn man hat Windows, Visual Studio, IIS und SQL Server inclusive.



Wenn Du mal scharf nachdenkst, sind das alles Sachen, die man zum Einstieg eben nicht unbedingt brauchen sollte. Okay ein OS braucht man, aber ich brauche als Anfänger kein VisualStudio (auch kein Eclipse oder IDEA), kein IIS und auch keinen SQL-Server. Was Du brauchst, um die Grundlagen einer Sprache richtig zu lernen ist ein Editor und halt die Sprache, fertig.

edit:



> Alles durchdacht, selbserklärend, getestet und funktionierend.



Das habe ich bis jetzt bei keiner Sprache erlebt  auch bei keiner IDE, schon gar nicht bei MSSQL-Servern.


----------



## nocturne (3. Jan 2012)

@Operator-überladen:
meinHaus += deinHaus ist ein zu einfaches Beispiel(!): ein Haus mehr ist als die Summe seiner Räume (raumliste1 += raumliste2 finde ich 100%ig).

Ob man Operatorüberladen verwendet oder nicht halte ich für Sitouationsabhängig, hoffe ihr stimmt mir zu.

@GC und Smartpointer / Autopointer.
Ich denke hier muss nicht nur die Sitouation unterschieden werden sondern auch die Spezialisierung der Fachkraft.

@auto
Bei groovy gibt es das typenunsichere deklarierren von variablen mit def.
Das finde ich nur gut, wenn
- die IDE anhand der vorherigen codezeilen erkennen kann, welche typen drin sein könnten und probleme markiert. 
z.B. um von einem String auf ein DetachedQuery zu kommen benötigt man nur eine variable mit namen sql. Das finde ich praktisch.


----------



## bronks (3. Jan 2012)

fastjack hat gesagt.:


> ... Anfänger kein VisualStudio (auch kein Eclipse oder IDEA), kein IIS und auch keinen SQL-Server. Was Du brauchst, um die Grundlagen einer Sprache richtig zu lernen ist ein Editor und halt die Sprache, fertig ...


Editor und Sprache waren irgenwann in den 80er das Mittel. Damals war noch alles einfach und übersichtlich, aber trotzdem hat man damit nicht weniger erreicht, als heute.

Heute will der Benutzer ein Klickibunti, welches sich aus vielen komplizierten Objekten zusammensetzt. Schon dafür braucht man eine vernünftige IDE mit CodeCompletion bzw. IntelliSense, denn Auswendiglernen oder in Büchern herumblättern muß sich heute niemand mehr antun.

Mittlerweile sind wir soweit, daß es für Java sogar brauchbare GuiEditoren gibt. Und plötzlich sind diese sogar beliebt. Mache Leute kritisieren zwar, daß man den generierten Code nicht bzw. mit Einschränkungen editieren kann. Ich meine, daß es eine Frechheit von technischer Krücke ist, daß ein GuiEditor überhaupt JavaCode erzeugt.

Vernünftige GuiEditoren für Java gab es natürlich auch schon vor 10 Jahren, aber da diese etwas gekostet haben passten diese einfach nicht in die Javawelt.


----------



## fastjack (3. Jan 2012)

> Heute will der Benutzer ein Klickibunti, welches sich aus vielen komplizierten Objekten zusammensetzt. Schon dafür braucht man eine vernünftige IDE mit CodeCompletion bzw. IntelliSense, denn Auswendiglernen oder in Büchern herumblättern muß sich heute niemand mehr antun.



Leider. Durch Klickibunti lernt man aber leider nicht... CodeCompletion + IntelliSense sind natürlich sinnvoll, zum reinen Erlernen würde ich es nicht empfehlen, kurzum, es verblödet. Ich kenne Leute, die keinen deutschen Satz mehr ohne IntelliSense zustande bringen. Andere schreiben nichtmal mehr Klassen- oder Methodennamen richtig, wieso denn auch, die CodeCompletion sucht schon das Passende heraus. Und "denn Auswendiglernen oder in Büchern herumblättern muß sich heute niemand mehr antun", antun? tja, wir haben ja auch schon aufgehört zu denken stattdessen googeln wir 

Ich sage immer noch: Um Java zu lernen, reicht ein normaler Editor und das JDK (wie groß nochmal 50-60MB?), fertig.

P.S.: Um GUI geht es in dem Thread gar nicht.


----------



## bronks (3. Jan 2012)

Firephoenix hat gesagt.:


> Die Diskussion hier ist mittlerweile auf einem Niveau als würde man in den Baumarkt schreien: "Welches Werkzeug ist am wichtigsten" ...


Nene, falsch verstanden. Hier geht es darum, welches Universalwerkzeug unter den üblichen Bedingungen am einfachsten Verwendet werden kann.

So z.B. ein Hammer mit drangeschraubtem Flaschenöffner und Gabel.

Mit einer Zange kann man einen Nagel auch ins Holz schlagen, Flaschen öffenen kann man damit sowieso und eine Gabel macht Diese auch überflüssig. Ist zwar fricklerhaft, aber es funktioniert.


----------



## fastjack (3. Jan 2012)

Auch falsch. Hier gehts es darum das jemand programmieren lernen möchte und wissen wollte, mit welcher der Sprachen (c, c++, c#, Java) er am besten anfangen sollte, mehr nicht...


----------



## Tomate_Salat (3. Jan 2012)

Ich würde eine von diesen hier empfehlen. z.b.  Whitespace.

Naja, auch wenn das hier der x-tausende Thread zu dem Thema ist. Überlege dir, was du später mal machen willst und lerne dafür eine Sprache (vorab: Spieleentwicklung geht mit allen!). 

Wenn du z.B. daheim einen Androiden hast, empfielt sich Java, dann kannst du späte mal darauf entwickeln. 
Wenn du Plattformunabhängig arbeiten willst, Java oder C++ (afaik soll das mit QT funktionieren. Arbeite nur im Betrieb mit C++ und haben da unser eigenes FW).
...


----------



## bronks (3. Jan 2012)

fastjack hat gesagt.:


> Auch falsch. Hier gehts es darum das jemand programmieren lernen möchte und wissen wollte, mit welcher der Sprachen (c, c++, c#, Java) er am besten anfangen sollte, mehr nicht...


Was? Hast Du die letzten 3 Seiten nicht gelesen? Es geht um Programmiersprachenbashing! Vor allem um C++ vs. Java. Ist doch sowieso alles Kindergarten, wenn man C# als vergleich nimmt.


----------



## Evil-Devil (6. Jan 2012)

Wenn Java Generics mit nativen Typen wie C# unterstützen würde, wären sicherlich viele schon glücklich.


----------



## s4ke (6. Jan 2012)

Ohne jetzt den ganzen Thread gelesen zu haben:

Meine Entscheidung sich erst mal voll auf Java zu konzentrieren war die richtige. Ich hatte aber für den Einstieg in Java minimale Kenntnisse in C++ mitgebracht (was mir das Konzept der "Referenzen" in Java gleich nähergebracht hat, "Referenzen" weil es ja keine Referenzen im näheren Sinn sind ) was mir unheimlich geholfen hat. Aber für Programmiereinsteiger ist Java das Nonplus-Ultra, weil man sich nicht mit Sprachbestandteilen auseinanderzusetzen hat, die einen am Anfang nur verwirren (später schaut man dafür aber öfters mal neidisch zu anderen Sprachen (C# mit Properties, C++ mit Operatorenüberladung, etc.). Und man lernt das Programmieren besser als mit Sprachen wie Python, die einem die Abläufe hinter hinter der Kulisse ein bischen verschweigen.

Und noch etwas: Android Programmierung macht einfach höllisch Spaß und man muss keine neue Sprache lernen, wenn man bereits Java kann. Es gibt dafür einiges an neuen Konzepten zu lernen .

An was man sich aber bei Java öfters mal gewöhnen muss ist etwas à la:

[Sarkasmus]

```
Double d = DoubleFactoryFactory.getInstance().createDoubleFactory().createDouble(1.0);
```
[/Sarkasmus]

sake


----------



## schlingel (6. Jan 2012)

Ein Punkt den fastjack gebracht hat kann ich allerdings nur unterstützen: IDEs mit samt ihrer Macht, helfen dem Neuling nicht beim Erlernen des Werkzeugs. Im Gegenteil, das ganze bleibt für ihn - sofern er wirklich ein absoluter Anfänger ist - das Klicken von Knöpfen um bestimmte Dinge zu erreichen ohne zu wissen wie es funktioniert.

Das beste Beispiel dafür sind Daten getriebene Anwendungen die in VS wild zusammengeklicked werden können und per Databinding an eine vom Wizard erstellte Datenbank gebunden werden können. Doch was ist passiert? Wie wird das deployed? etc. sind dann Fragen die derjenige der das Tutorial schritt für schritt befolgt hat, dann nicht beantworten können. (Ich konnte es jedenfalls damals nicht ...)

Sogar Petzold, jeder der halbwegs etwas von Windows versteht sollte der Name ein Begriff sein, hat das Thema beschäftigt weshalb er diesem Thema einen Artikel gewidmet hat.

Ein anderes Buch das diese Thematik anschneidet ist Design For How People Learn. In dem Buch wird auch kurz auf oben angesprochene Problematik eingegangen.

So sehr IDEs auch die Entwicklung beschleunigen, es hilft einem Anfänger viel mehr mit Editor und Kommandozeilencompiler anzufangen!


----------



## bronks (6. Jan 2012)

schlingel hat gesagt.:


> ...  etc. sind dann Fragen die derjenige der das Tutorial schritt für schritt befolgt hat, dann nicht beantworten können. (Ich konnte es jedenfalls damals nicht ...) ...


So z.B. und auf Java bezogen: JSF + EJB + JPA. Das kann man sich im Texteditor in wenigen Dateien zusammentippen, aber was ist das Ergebnis: 

In die GUI wird etwas reingetippt daraufhin wird
- das Datenmodell automatisch aktualisiert
- die Transaktion automatisch begonnen
- die Daten automatisch persistiert
- die Transaktion automatisch commited

Das ist alles so abstrakt. Es funktioniert einfach. Was will man da für Fragen haben und was erwartet man als Antworten. Macht es überhaupt einen Sinn sich mit den darunterliegenden Techniken, wie z.B. JTA, JDBC, Servlet ... ... zu beschäftigen?


----------



## schlingel (6. Jan 2012)

Spätestens wenn es nicht mehr "einfach" funktioniert, macht es sehr viel Sinn ;-)

PS: Ich beginne lieber auf Servlet Ebene :-D


----------



## bronks (6. Jan 2012)

schlingel hat gesagt.:


> Spätestens wenn es nicht mehr "einfach" funktioniert ...


Dann ist es verbugter Müll, welcher nirgendwo akzeptiert wird.


----------



## schlingel (6. Jan 2012)

bronks hat gesagt.:
			
		

> Dann ist es verbugter Müll, welcher nirgendwo akzeptiert wird.



Mit der Aussage kann ich absolut nichts anfangen. Du dürftest deutlich mehr Glück mit Frameworks haben als ich. Mir begegnet fast täglich "verbugter Müll", der allerdings überall akzeptiert wird. (Android-Framework, Jackson-JSON-Parser, etc.)

Die perfekte Welt gibt es IMHO nicht. Mir hat technisches Verständnis und tieferes Wissen mehr Zeit gerettet als es mich gekostet hat sie zu erlernen.

Wer das anders sieht, schön, allerdings ist die Annahme das jedes Framework fehlerfrei funktioniert und es nutzlos ist, zu wissen welche Sub-Frameworks im verwendeten Framework verwendet werden und wie diese funktionieren, gefährlich wenn mal Anforderungen geändert werden und man spezielle Anpassungen machen muss.


----------



## bronks (6. Jan 2012)

schlingel hat gesagt.:


> ... Du dürftest deutlich mehr Glück mit Frameworks haben als ich ...


Wird wohl so sein oder ich bin in dieser Hinsicht etwas toleranter. Letztes Jahr hatte ich nur 2 Probleme, welche eindeutig auf Bugs zurückzuführen waren. Eines davon habe mit einem einfach Workaround in den Griff bekommen und das andere Problem erforderte härtere Massnahmen. In Summe bis jetzt 1 Arbeitstag Schaden.

Außer o.g. gab es schon ein paar mehr Situationen, wo etwas nicht so funktioniert hat, wie es eigentlich hätte funktionieren sollen, aber dann habe ich es minimal anders umgesetzt ohne mich damit besonders aufzuhalten.


----------



## Landei (6. Jan 2012)

schlingel hat gesagt.:


> Ein Punkt den fastjack gebracht hat kann ich allerdings nur unterstützen: IDEs mit samt ihrer Macht, helfen dem Neuling nicht beim Erlernen des Werkzeugs. Im Gegenteil, das ganze bleibt für ihn - sofern er wirklich ein absoluter Anfänger ist - das Klicken von Knöpfen um bestimmte Dinge zu erreichen ohne zu wissen wie es funktioniert.



Man muss aber schon unterscheiden, ob die IDE etwas wirklich "magisches" tut, oder nur etwas ausführt (Refactorings, Einfügen von Konstruktoren und Standardmethoden), was man sich hinterher problemlos ansehen kann.


----------



## schlingel (6. Jan 2012)

Vollkommen richtig. Ich meinte jetzt natürlich so etwas wie Formeditoren, DB-Erzeuger, WS-Erzeuger, etc.


----------



## bronks (8. Jan 2012)

schlingel hat gesagt.:


> Vollkommen richtig. Ich meinte jetzt natürlich so etwas wie Formeditoren, DB-Erzeuger, WS-Erzeuger, etc.


Du meinst also, die Sachen welche man sich hinterher problemlos ansehen kann.


----------



## schlingel (8. Jan 2012)

Zum Beispiel, ja.

Was die Logik von DB-Erzeugung angeht, sind wir ja in einem Bereich den man sich nicht "problemlos" ansehen kann, aber das nur so nebenbei ;-)

Im allgemeinen ist es nun einmal so: Wer glaubt eine IDE ist ein simples Werkzeug das so nebenbei gelernt wird, ist schon wieder zu weit weg von der Sicht des Anfängers, der von der immensen Informationsflut - gerade in einem komplexen Gebiet wie dem Programmieren - erschlagen wird. "Problemlos" ist eben auch Definitionssache, ähnliche dem "es ist leicht zu sehen" oder "trivial" in mathematischen Texten.

Ich empfehle - noch einmal - die oben verlinkte Literatur zu lesen um die Argumentationsketten im ganzen zu verstehen. 

PS: Ich mag so suggestive Einzeiler nicht. Man weiß nie was da jetzt wirklich gemeint war. Könnte eine interessierte Frage, eine höhnische Anmerkung oder was anderes sein. Das ist eine schlechte Grundlage für eine Debatte.


----------



## bronks (8. Jan 2012)

schlingel hat gesagt.:


> ... PS: Ich mag so suggestive Einzeiler nicht. Man weiß nie was da jetzt wirklich gemeint war. Könnte eine interessierte Frage, eine höhnische Anmerkung oder was anderes sein. Das ist eine schlechte Grundlage für eine Debatte ...


Sorry, aber genau der Deine, von mir zitierte, Satz hat irgenwie keine Aussage für mich gehabt. Denn genau die von Dir erwähnten Formeditoren, DB-Erzeuger und WS-Erzeuger erzeugen einen verständlichen Programmcode, den man glücklicherweise nicht manuell Tippen muß.




schlingel hat gesagt.:


> ... Was die Logik von DB-Erzeugung angeht, sind wir ja in einem Bereich den man sich nicht "problemlos" ansehen kann, aber das nur so nebenbei ;-) ...


Beim Speichern von Änderungen im DB-Designer frägt mich meine IDE immer, ob ich den das Script dazu gerne sehen würde. Es gibt keine Geheimnisse und ich habe die volle Kontrolle.

Kann es sein, daß Du einfach nur die falschen Werkzeuge verwendest?




schlingel hat gesagt.:


> ... Im allgemeinen ist es nun einmal so: Wer glaubt eine IDE ist ein simples Werkzeug das so nebenbei gelernt wird, ist schon wieder zu weit weg von der Sicht des Anfängers, der von der immensen Informationsflut - gerade in einem komplexen Gebiet wie dem Programmieren - erschlagen wird. "Problemlos" ist eben auch Definitionssache, ähnliche dem "es ist leicht zu sehen" oder "trivial" in mathematischen Texten ...


Genau das Gegenteil, denn in der IDE klicke ich mir etwas zusammen, sehe mir den erzeugten Code an und denke mir: "Ja logisch, klar, steht doch alles da". Ich verstehe den erzeugten Code, obwohl ich diesem im vi nicht stolperfrei und auf anhieb kompilierbar eingetippt hätte. 




schlingel hat gesagt.:


> ... Ich empfehle - noch einmal - die oben verlinkte Literatur zu lesen um die Argumentationsketten im ganzen zu verstehen ...


Das sind Argumente zu einer von vielen Meinungen. Es hat m.E. absolut keinen Sinn zu lernen, wie man Farben herstellt, wenn man Bild malen möchte. Irgendwann kommt der Punkt, wo es interessant wird sich mit dem Mischen von Farben zu beschäftigen, aber am Anfang möchte man einfach nur die Farbe aufs Papier bringen und schöne Formen malen.


----------



## schlingel (8. Jan 2012)

> Beim Speichern von Änderungen im DB-Designer frägt mich meine IDE immer, ob ich den das Script dazu gerne sehen würde. Es gibt keine Geheimnisse und ich habe die volle Kontrolle.


Das heißt noch lange nicht, das der Anfänger deshalb weiß was eine Datenbank ist, wie diese zu deployen ist, was die verschiedenen Zeilen des SQL-Skripts tun und weshalb das da so steht. WS ist es das gleiche und Forms auch. Wobei bei Forms noch am ehesten Verständnis hergestellt werden kann weil es keinen Technologiesprung gibt (Von WSDL auf Java, von SQL zu Java, etc).



> Genau das Gegenteil, denn in der IDE klicke ich mir etwas zusammen, sehe mir den erzeugten Code an und denke mir: "Ja logisch, klar, steht doch alles da".


Meiner Erfahrung nach gibt es nur sehr wenige Ausnahmefälle in der Menge der Anfänger die sich das so überlegen. Für die meisten Normalsterblichen ist die Informationsfülle einfach erschlagend. Klar, ich benutze auch eine IDE und bin sehr zufrieden damit, das heißt aber noch lange nicht, das es deshalb auch für einen Anfänger das beste Werkzeug ist.



> Das sind Argumente zu einer von vielen Meinungen.


Wobei genau das die Streitfrage ist. Hier habe ich meine Meinung *argumentiert* und vor allem mit Erfahrungen eines der bekanntesten Praktiker (jedenfalls in der MS Windows-Welt) und einem leichten Buch zum Thema Lerntheorie untermauert. 
Du bist anderer Meinung, weil du gut zurecht kommst mit einer IDE oder weil du andere Erfahrungen gemacht hast. Das ist dein gutes Recht, aber einer der am meisten gemachten Fehler in der Lehre. Deshalb würde ich in solchen Fragen immer auch Erfahrungen von Lehrenden und Fachliteratur zum Thema abrufen. 



> [...]aber am Anfang möchte man einfach nur die Farbe aufs Papier bringen und schöne Formen malen.


Das ist ein guter Punkt. Aber dann wären andere Tools noch besser geeignet, wie z.B. Lightswitch oder App Inventor, allerdings helfen diese einem Anfänger nicht damit die Materie besser zu verstehen. Und der Lernerfolg wird ja durch die Fähigkeit bestimmt Programme entwickeln und auch warten zu können. Dadurch ist Verständnis ein absolutes Muss-Kriterium.
Es ist hierbei mehr gefragt wie die Tutorials vorgehen anstatt alles auf die Tools zu schieben. Aber siehe auch dazu das verlinkte Buch ;-)


----------



## bronks (9. Jan 2012)

schlingel hat gesagt.:


> Das heißt noch lange nicht, das der Anfänger deshalb weiß was eine Datenbank ist, wie diese zu deployen ist, was die verschiedenen Zeilen des SQL-Skripts tun und weshalb das da so steht ... ... Meiner Erfahrung nach gibt es nur sehr wenige Ausnahmefälle in der Menge der Anfänger die sich das so überlegen. Für die meisten Normalsterblichen ist die Informationsfülle einfach erschlagend ...


Ja. Jetzt verstehe ich, was Du meinst, aber kann es nicht wirklich glauben, daß jemand so anfängt, wenn er damit wirklich etwas erreichen möchte. 

Ich habe absolut in die falsche Richtung gedacht, da ich Bildungstechnisch wohl die besten Voraussetzungen für den Start als Programmierer hatte: 2 Jahre Hauptschulinformatik in den Jahren 1988/89 mit gwbasic und dBase.


----------

