Java oder welche Sprache?

[Utopia]

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]

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]

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]

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

 

[Swoop]

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]

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]

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

 

[bronks]

... 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]

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]

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]

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]

Java oder C#

 

[bronks]

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]

... 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]

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]

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]

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]

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]

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]

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]

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]

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.

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]

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]

@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]

@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]

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]

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]

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

 

[Gregorrr]

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]

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.

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.

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.

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.

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.

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.

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]

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
- Full OOP
- wenig Boilerplatecode
- eine Scriptsprache sollte imho jeder Entwickler kennen und einigermassen beherrschen

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]

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]

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]

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]

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_]

@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]

<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]

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 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]

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

[*]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]

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]

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.

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.

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?

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]

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

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]

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]

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]

...
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_]

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]

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?

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.

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++)

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

Hier kann ich dir nicht ganz folgen..

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.

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.

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]

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);

.

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]

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]

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.