bei C/C++ bleiben oder JAVA lernen?

[gEistiO]

ich stehe zurzeit vor einer "schwierigen" frage:
soll ich bei C/C++ bleiben oder stattdessen JAVA lernen?
welche sprache hat eurer meinung (mehr) zukunft?

C/C++ kann ich mittlerweile schon ziemlich gut und ich würde es nur ziemlich gerne aufgeben. von JAVA allerdings hört man allerorts, dass dies die sprache der zukunft sei.

was meint ihr? was würdet ihr mir empfehlen? bitte nur ehrliche antworten...
danke schonmal im vorraus :D

[anda_skoa]

Es kann nicht schaden, eine weitere Sprache zu können.

Erst wenn du die Unterschiede kennst, kannst du bei einem Projekt entscheiden, welche Sprache besser geeignet ist.

Wenn du mit C++ schon gut zurecht kommst, dürfte Java kein gröberes Problem darstellen.

Ciao,
_

[Woolf]

stimmt, java ist leicht zu erlernen, wenn du c/c++ kannst

Hab ich vor nur wenigen tagen bemerken dürfen :)


Ich würd schon empfehlen eine weitere sprache zu lernen
wenn ich recht überlege, gibt es schon einige vorteile auch, zb: die java klassen/jar-files sind betriebssystemunabhängig :D

[Lin728]

Hi,

Ich muss sagen, dass man in Java sicher 20-35% produktiver arbeiten kann als mit C++.

Lg

[anda_skoa]

Original geschrieben von ceisserer
Schade, dass Sun Java im Applicationsbereich sehr behindert, da die keine Compilier zur Verfügung stelllen.


Mein letztes JDK war zwar von blackdown, aber da war in javac drinnen.
Ich bin mir ziemlich sicher, dass ach die JDKs von SUN den javac enthalten.



Auf dem Desktop ist zwar ein Compile once& Run anywhere nett, wenns aber auf kosten der Performace geht, werden viele Leute schnell ungeduldig.


Man bräuchte einen JIT, der den native Code irgendwo cached.
So wie es die VM von C# macht.

Ciao,
_

[gEistiO]

ihr meint also wirklich, dass ich JAVA lernen soll...
aber wo wird denn heutzutage wirklich in JAVA programmiert?
web-applets alleine können auch nicht das wahre sein....

[anda_skoa]

Java ist vorallem Serverseitig gefragt.
Banken und Wirtschaftsanwendungen.

Außerdem wird man durch die etwas andere Handhabung von OOP Konzepten auch in C++ besser.

Ergänzt sich wirklich gut und wie jetzt schon einige geschrieben haben, für einen C++ Programmierer kein Aufwand.

Ciao,
_

[SeeksTheMoon]

Java kann weitaus mehr als nur Applets.

Ich kann viele Programmiersprachen (u.a. C und C++) und ein paar Scriptsprachen und muss sagen, dass Java sie alle platt macht.

Gestern habe ich ne Anzeige gelesen, wo Leute gesucht wurden, die Mensch-Maschine-Interfaces in Java programmieren sollen.
Java ist z.B. in den Oracle Datenbanken ab 8i integriert und wegen der Vielseitigkeit kann man es überall benutzen.
Vor allem bei Datenbanken, Serverseitiger Internetprogrammierung und Anwendungsapplikationen stößt man immer häufiger auf Java.
Hier gibts ein gutes Zahlenbeispeil, welche Sprachen häufig verwendet werden:
http://sourceforge.net/softwaremap/trove_list.php?form_cat=160
C,C++ und Java teilen sich die Spitze (in der Reihenfolge) bei den "richtigen" Programmiersprachen. Die Scriptsprachen kommen erst dahinter.

Java bietet im Gegenteil zu C++ viele Vorteile:
Java ist sicher, Bufferoverflows, etc. gibts in Java nicht.
Zeiger und die damit verbundenen Fallstricke gibt es nicht (und man braucht sie auch nicht - ich werde bei diesem Argument immer ungläubig angesehen)
Exceptionhandling ist fest integriert, nicht so aufgesetzt wie bei C++, wo es völlig egal ist ob man es benutzt oder nicht.
Der API-Umfang, die Dokumentation, die verfügbaren Tools sind einfach genial.
Die Plattformunabhängigkeit ist natürlich auch ein wichtiger Punkt.
Java ist relativ jung und deswegen von vorn herein besser durchdacht und nicht nachträglich erweitert worden (z.B. Exceptionhandling in C++)
Java ist durch und durch Objektorientiert
Für Java gibt es viele Erweiterungsklassen, falls man mit dem Standard und Enterprise-Satz nicht auskommt. (OK, gibts in C++ auch)
Die Datenbankschnittstelle ist einfach genial
Applets, Servlets und JSP bieten alles fürs Inter- und Intranet
per JNI kann man auch mit C++ Programmen kommunizieren, wenn man wirklich muss
Javaprogrammierer produzieren halb so viele Fehler wie C++ Progger (Zitat von James Gosling aus dem c't Interview, Heft 22)
Java ist nicht so langsam wie man ihm anhängt, es existieren sogar aufwendige 3D Applikationen und Spiele in Java
Auch vom Programmierkomfort her ist es angenehmer. Was macht in C denn die Funktion strstr? Öhm, manpage nachlesen.... Javacode ist dank Schreibkonvention wesentlich besser nachvollziehbar (erst Recht für Anfänger) als eine Sprache, deren Bibliotheken von schreibfaulen Hackern entwickelt wurden *g*
Unicode ist Javas Zeichensatz. Man kann (auch wenn das nicht toll ist) alle wilden Sonderzeichen an jeder Stelle benutzen; ich weiß noch wie der gcc aus dem Trott gekommen ist, als bei mir in einem Kommentar (!) ein Umlaut stand...

Java ist nicht mehr nur ein cooles Spielzeug, Java wird immer mehr benutzt, es wird jeder Aufgabe gerecht, ist sicher, komfortabel, portabel, einfach, stabil, .......

Einem Javaprogramm, das auf Linux läuft würde ich jederzeit mein Leben anvertrauen (besonders wenn es von mir geschrieben ist *g*)!

[gEistiO]

SeeksTheMoon: du hast mich soeben überzeugt JAVA zu lernen! danke dir!
genau so eine antwort habe ich mir vorgestellt :)

achja: du sagst, dass es KEINE memory leaks oder so geben kann?
wenn ich dann in JAVA einen server programmieren würde, könnte der ja dann theoretisch ewig laufen...
in C hatte ich eigentlich immer probleme mit leaks :mad:

[Lin728]

achja: du sagst, dass es KEINE memory leaks oder so geben kann?
wenn ich dann in JAVA einen server programmieren würde, könnte der ja dann theoretisch ewig laufen...
in C hatte ich eigentlich immer probleme mit leaks

Ja, genauso ist es!
Java besitzt ein automatisches Speichermanagement, kümmert sich also selbst um das entsorgen von nicht mehr benötigten Objecten. Es ist zwar unter ganz bestimmten Umständen möglich, dieses Memory-management-system (GarbageCollector genannt) aus dem Tritt zu bringen - in der Praxis kommt das aber nicht oder nur in äußersten Extremfällen vor.

Lg

[anda_skoa]

Original geschrieben von gEistiO

achja: du sagst, dass es KEINE memory leaks oder so geben kann?


Ansich hat SeksTheMoon geschrieben, dass es keine Bufferoverflow gubt, zumindest nicht im Java Code.

Memory leak kann man schon produzieren, nur schwerer :)

Ciao,
_

[anda_skoa]

Original geschrieben von SeeksTheMoon
Vor allem bei Datenbanken, Serverseitiger Internetprogrammierung und

Man kann mit nix so fein CGI schreiben wie mit Java Servlets :)



Exceptionhandling ist fest integriert, nicht so aufgesetzt wie bei C++, wo es völlig egal ist ob man es benutzt oder nicht.


Das stimmt so nicht.
Wenn du Code benutzt, der Exceptions werfen kann, dann mußt du sie genauso behandeln.
Außerdem ist meines Wissens Exceptionhandling in C++ ebenfalls Bestandteil der Sprache.



Der API-Umfang, die Dokumentation, die verfügbaren Tools sind einfach genial.


Der Punkt ist vorallem früher sehr entscheiden gewesen.
Seit die Standardlib und die STL so gut sind, ist das nicht mehr so ei großer Unterschied,
Außerdem kann man immer noch Qt benutzen ;)
(Alle die gewußt habe, dass ich das schreiben werde, bekommen 5 Punkte :D)



Java ist relativ jung und deswegen von vorn herein besser durchdacht und nicht nachträglich erweitert worden (z.B. Exceptionhandling in C++)


Hmm, hast du Referenzen dafür?



Java ist durch und durch Objektorientiert

Naja, nicht ganz :)

Aber außer SmallTalk und Eiffel ist das auch fast keine Sprache.
Python kommt schon sehr nahe.



Schreibkonvention wesentlich besser nachvollziehbar (erst Recht für Anfänger) als eine Sprache, deren Bibliotheken von schreibfaulen Hackern entwickelt wurden *g*

Da ist auch die Qt ein gutes Beispiel für eine sehr konsistente Class Library.
Die Standardlib ist da wirklich nicht so gut.

Eigentlich kann man sagen, die Qt ist die Java API für C++ :p

Ciao,
_

[SeeksTheMoon]

"Wenn du Code benutzt, der Exceptions werfen kann, dann mußt du sie genauso behandeln.
Außerdem ist meines Wissens Exceptionhandling in C++ ebenfalls Bestandteil der Sprache."
Sicher, man kann den catch-Block leer lassen, aber immerhin wird man gezwungen, überhaupt ein try-catch zu schreiben. In C++ kann man es auch komplett bleiben lassen und muss schon von alleine drauf kommen, dass gewisse Operationen eine Exception auslösen könnten.

"Hmm, hast du Referenzen dafür?"
Nun, falls das nicht der Fall sein sollte, so bin ich bisher noch keinem Gegenteil begegnet (außerdem meine ich mit Java alles ab 1.2)

"Naja, nicht ganz :)"
Wenigstens im vergleich zu C++, das noch extrem viele Überreste von C mit sich schleift...

[anda_skoa]

Original geschrieben von SeeksTheMoon

Sicher, man kann den catch-Block leer lassen, aber immerhin wird man gezwungen, überhaupt ein try-catch zu schreiben.

Ich meinte das anders rum.
Auch in C++ ist das Exceptionhandling direkt eingebaut.
Wenn das eine Funktion eine Exception wirft und du fängst sie nicht, ist das Programm weg.



In C++ kann man es auch komplett bleiben lassen und muss schon von alleine drauf kommen, dass gewisse Operationen eine Exception auslösen könnten.

Das stimmt. Es gilt praktisch standardmäßig throw



"Hmm, hast du Referenzen dafür?"
Nun, falls das nicht der Fall sein sollte, so bin ich bisher noch keinem Gegenteil begegnet (außerdem meine ich mit Java alles ab 1.2)

Ich meinte für die Behauptung, Exceptions wäre in C++ nur aufgesetzt.
Mein Kumple Bjarne behauptet das Gegenteil und nur einer von euch beiden kann recht haben :D



"Naja, nicht ganz :)"
Wenigstens im vergleich zu C++, das noch extrem viele Überreste von C mit sich schleift...

Ansich ist C++ mehr eine Übermenge von C.
Abgesehen davon, macht die Möglichkeit prozeduralen Code zu schreiben, die Sprache nicht weniger objektorientiert.

Ich programmiere gerne in Java und hab auch kein Problem mit der erzwungenen OOP, das einzige was einem als C++ Programmierer abgeht sind Mittel zu generischen Programmierung.

Ich hab zwar auch in C++ noch keine template selber geschrieben, aber ich benutze sie laufend.

Ciao,
_

[SeeksTheMoon]

Original geschrieben von anda_skoa
Ich meinte für die Behauptung, Exceptions wäre in C++ nur aufgesetzt.
Mein Kumple Bjarne behauptet das Gegenteil und nur einer von euch beiden kann recht haben :D

Gut, mein ehemaliger C++ Lehrer (ein C++ Gott übrigens) behauptet das übrigens auch. Da sind wir schon zwei...

Nachtrag zum "besser durchdacht und noch kein Gegenteil gefunden": Das ist ein indirekter Beweis und somit mathematisch gültig :D
Is mir nur leider zu spät eingefallen... *g*




Ich hab zwar auch in C++ noch keine template selber geschrieben, aber ich benutze sie laufend.

Templates kommen in Java 1.5

[xare]

Original geschrieben von anda_skoa

Man bräuchte einen JIT, der den native Code irgendwo cached.
So wie es die VM von C# macht.


Da gibts doch schon verschiedenes, oder?


Original geschrieben von SeeksTheMoon

"besser durchdacht und noch kein Gegenteil gefunden": Das ist ein indirekter Beweis und somit mathematisch gültig

Nope, ein indirekter Beweis ist das nicht...

MfG Xare

[anda_skoa]

Original geschrieben von SeeksTheMoon
Gut, mein ehemaliger C++ Lehrer (ein C++ Gott übrigens) behauptet das übrigens auch. Da sind wir schon zwei...


Hmm, ich hab leider keine Spezifikation der ersten Stunde, jetzt sind Exceptions definitiv der Sprache.



Nachtrag zum "besser durchdacht und noch kein Gegenteil gefunden": Das ist ein indirekter Beweis und somit mathematisch gültig :D
Is mir nur leider zu spät eingefallen... *g*

Besser durchdacht und noch kein Gegenteil gefunden?
Auf was bezieht sich das?

Außerdem ist das kein indirekter Beweise :)
Du müßtest beweisen, dass es kein Gegenteil gibt.
Nur bisher keines gefunden reicht da nicht.



Templates kommen in Java 1.5
Feine Sache, dann wird mand as dauernde herumgecaste endlich los :cool:

Ciao,
_

[anda_skoa]

Original geschrieben von xare
Da gibts doch schon verschiedenes, oder?


Hmm, bin da nicht so auf dem Laufenden.
Bisher haben die Java JITs immer nur während eines Lebenszyklusses gearbeitet, also nur solange die JVM läuft.
Auf einem Server ist das auch völlig ausreichend, aber Desktopanwendungen werden öfter gestartet und beendet und da ist ein native-cache ganz fein :)

Ciao,
_

[Lin728]

Nun, ich finde Java ist extrem gut durchdacht, schade dass es im Applikationsmarkt nicht fußen kann/will. Solange Sun keine Java-Compiler veröffentlich, bleibt Java für die meisten eben nur ne aufgeblasene Scriptsprache ;-(

Mfg

[peschmae]

mein senf dazu:

Java ist relativ jung und deswegen von vorn herein besser durchdacht und nicht nachträglich erweitert worden (z.B. Exceptionhandling in C++)

quark. Java ist auch schon fünf seit der Erstveröffentlichung. und an einer Menge Stellen musste sehr stark nachgebessert werden (und auch nachträglich erweitert) (z.B. AWT (das eventmanagement), Swing dazu, das Ersetzen von Vektor durch ArrayList, ...)

Was aber insgesamt nicht gegen java spricht

MfG Peschmä

[anda_skoa]

Original geschrieben von ceisserer
Das ist ja kindisch!

Aber gerade wiels so kindisch ist, mach ich mit ;-)


Wir sind zwar knapp unter einem Flamewar, aber es ist noch eine Diskussion.
würde ich sagen ;)



Nun, ich finde Java ist extrem gut durchdacht, schade dass es im Applikationsmarkt nicht fußen kann/will.


Ich finde Java auch gut, ich hab nur was dagegen, wenn behauptet wird C++ sei schlecht.



Solange Sun keine Java-Compiler veröffentlich, bleibt Java für die meisten eben nur ne aufgeblasene Scriptsprache ;-(


Ich weiß nicht, welche Sachen du runtergeladen hast, aber bisher enthielten alle JDKs von Sun einen Compiler.
Die Pakete ohne Compiler nennt man JRE.



Natürlich kann man sagen, dass mit den JIT das nach einiger Zeit alles besser wird, aber wer bitte führt den Code immer zweimal aus, um schell zu arbeiten.


Darum finde ich die Idee gut, dass man das Ergebniss der JIT Compilierung in einem speziellen Cache speichert.
So wie es auch der JIT von .NET macht.
Wundert mich, dass es da noch keinen Java JIT gibt, der das macht.


Ciao,
_

[peschmae]

was fehlt ist ein nativer Compiler à la Jet oder so

die von javac kompilierten Dinger sind ja wohl dem Sourcecode sehr ähnlich, ist es doch mit den Decompilern sehr gut möglich das Zeugs wiederherzustellen (sogar die Variablen/Methodennamen). Also liegt die Annahme nahe, das sei gar nicht mehr als eine Skriptsprache...

MfG Peschmä

[anda_skoa]

Original geschrieben von peschmae
was fehlt ist ein nativer Compiler à la Jet oder so


Aso, daß muß man schon dazu sagen.

Es gibt von Sun eine Prozessor, der eine Java Maschine implementiert.
Da ist der normale Bytecode native :)

Es widerspricht der Phiosophie, einen Native Compiler zu machen.
Das würde Leute nur dazu verleiten, Plattformabhängige Binarys zu verteilen.

SUN wird also keinen machen, zumindest nicht als Teil des JDK.

Wie man sieht gibt es aber entsprechende Compiler von Drittherstellern (Compilerspezialisten).

Am besten finde ich aber immer noch einen Caching-JIT.
Das ist "best of both worlds".

Ciao,
_

[peschmae]

Es gibt von Sun eine Prozessor, der eine Java Maschine implementiert.

wartauflink :D

MfG Peschmä

[Lin728]

Hi,

Ein weiterer großer Hemmschuh ist sicher die "es ist nicht kompiliert, also ist es langsam" Mentalität. Ich habe ein paar Benchmarks mit dem JDK1.4, dem GCJ, Kaffe und JET gemacht. Generell kna man wirklich sagen, dass interpretiertter Code langsam ist. Natrülich, es ist eher ein einfacher Benchmark, der nicht viel über de Gesamtperformnce aussagt, aber naja, trotzdem:
Sun-Java1.4 ohne Jit: 1700msec
Kaffe: 1400 msec
GCJ-3.0.4: 600msec
Sun-Java1.4 mit JIT: 179
Jet-native kompiliert: 10msec.
Bei weiteren läufen kommt se Sun Java.14 mit Jit auf 14msec, als ziemlich naje an JET. Alle anderen Werte bleiben fast gleich. Der GCJ ist höchstwahrscheinlich schon viel schneller geworden, die getestete Version hatte schon ein paar Monate am Buckel...

Man sieht also deutlich, dass einfach nur interpretierter Code mit schlechetm JIT wie z.B. unter Kaffe langsam ist. Auch sieht man, dass sich SUN extreme Mühe gegeben hat, deine Runtime performant zu machen!

Mfg

[peschmae]

Eben, die java - probleme sind imho:

- lange startzeit
- vielzuviel speicherverbrauch
- "" hd - verbrauch
- extrem träge menüs (wenn ein button zwei sekunden zum reagieren braucht ist mir das scheissegal, aber ein menü muss einfach sofort da sein)

MfG Peschmä

[Lin728]

Jo, und da Hilft GCJ mit SWT!

Unter Windows kann man eh mit der normalen JV arbeiten, und für Linux gibts ein Executable, das einer QT-Application um nichts nachsteht!!!

Mfg

[Woolf]

WOW

Wurden hier schon die JAR files errwähnt???? :D die haben mich begeistert

Das ist wichtig, ein "Applikations Pack"-Tool
Sowas wie ein Zip-Tool

Du kannst die klassen und alles was du für dein prog benötigst mit
>jar cf [foo.jar] [file1/dir1] [file2/dir2]....
"packen"

applets werden dann ganz normal mit
code="foo.class"
angegeben, da isch foo.class im JAR befindet, einfach
archive="xyz.jar"
dazufügen

Soll es ein selbstständiges prog sein, muss einfach eine Main-Klasse rein, ich nehm an, dass das einfach nur "main.class" heißt :)

http://java.sun.com/docs/books/tutorial/jar/basics/index.html


@Seeks: Das ist auch für kleine Demos von Schattenwelten gut, enginge-demos, als applet

[SeeksTheMoon]

Original geschrieben von peschmae
Eben, die java - probleme sind imho:

- lange startzeit
- vielzuviel speicherverbrauch
- "" hd - verbrauch
- extrem träge menüs (wenn ein button zwei sekunden zum reagieren braucht ist mir das scheissegal, aber ein menü muss einfach sofort da sein)

MfG Peschmä

Eine lange Startzeit hat man bei C++ Programmen auch. Bei kleinen Programmen hat C++ aber die Nase vorn, das stimmt.
HD-Verbrauch ist ja wohl MEGAWINZIG. Wenn ein Java-Programm 1MB groß ist, dann steckt da schon einiges hinter. Dafür sind die Bibliotheken zwar groß aber ich kann mir nicht vorstellen, dass das bei C++ anders ist. QT ist ja auch fet (hat da jemand ne Größe in MB?)

@Woolf: ich kenne jar-Files und mache da auch ständig Gebrauch von. Allerdings muss da eine Datei MANIFEST/MANIFEST.MF rein, in der steht, welche Klasse die Main-Methode enthält, dann erst klappts. Ansonsten ist es nur ein Archiv.

[peschmae]

ok, qt ist genauso fett, aber bei Java kommen einfach noch über 50 dazu, aber das ist ein allgemeines Problem (noch gleich >50 für Gtk/Gnome, dann noch Mozilla, ...)


Eine lange Startzeit hat man bei C++ Programmen auch. Nicht immer! Fltk - Applikationen sind ganz schön schnell. (Fünf Punkte für die, die gewusst haben, dass ich jetzt das bringe :D)


MfG Peschmä

[anda_skoa]

Original geschrieben von ceisserer
Ich weiß, dass man das Paket von SUN ohne javac JavaRuntimeEnviroment nennt. Das was SUN da mitliefert, ist aber kein richtiger Compilier, sonder eher ein "In-ByteCode"-Umwander.


Das ist eigentlich schon ein richtiger Compiler.
Der Bytecode ist Maschinencode der Abtrakten Java Maschine.

Eine Stackarchitektur, falls es jemanden interessiert :)
Hab mal in einer Übung in Compilerbau einen Pascal Compiler geschrieben, der Java Bytecode erzeugt.



Ich glaube ein JIT-Cacher würde dem Hauptproblem der JVM auch nicht abtun. Die Hauptprobleme der JV sind die extrem große Installationsgröße (ist ja ganz normal, wenn man besenkt, was alle szur verfügung gestellt wird), die Tatsache, dass die JVM lange zum Starten braucht und der extremste Hemmschuh ist sicherlich der SWING-Gui. Bei kleinen Programmen ist das nicht so schlimm, aber der JBuilder oder Netbeans sind schon manchmal eine echte Qual. Speziell die Menüs, auf die muss man manchmal 2Sekunden warten, bis sie aufgehen, das kann schon extrem nervig sein...


Über GUIs kann ich wenig sagen, da hab ich nicht viel in Java gemacht.
Die Installationsgröße ist meiner Meinung nach nicht so wichtig.
Alle anderen Systeme haben auch Bibliotheken, mit dem zusätzlichen Nachteil, dass diese untereinander Abhängigkeiten haben.

Und das Starten kann man ja mit Tricks beschleunigen.
Bei mir startet die VM viel schneller, wenn sie gerade gelaufen ist, weil ja alles dynamischen Bibliotheken schon geladen sind.



Ich muss leider auch gestehen, dass ich kompilierte Programme leiber habe als, Java-Progies. Jetzt denkt einmal nach: Eine Firma verkauuft ein Produkt, dass in C++ geschrieben ist, eine andere eins das mit java und Swing gemacht wurde. Beide können und kosten exact das selbe. Na, und was würdet ihr nehmen? ;-)


Ich denke das hängt mehr von der Anwendung ab und vom Umfeld des Einsatzes.
Eine Java Anwendung wird man dann bevorzugen, wenn in der Firma nicht feststeht, welche Plattfomr zum Einsatz kommen wird, oder wenn man die Plattform wechseln möchte, ohne dafür die Hilfe des Herstellers zu benötigen.

Man kann zwar mit Hilfe von Crossplattform Bibliotheken wie Qt durchaus mehrere Plattformen äquivalent unterstützen, aber man braucht für jede Plattform eine extra Version.
Und der Hersteller muß für alle diese Plattformen die Möglichkeit haben zu compilieren und zu testen.


Ciao,
_

[anda_skoa]

Original geschrieben von Woolf
WOW

Wurden hier schon die JAR files errwähnt???? :D die haben mich begeistert


Stimmt, das ist wirklich was feines!



Das ist wichtig, ein "Applikations Pack"-Tool
Sowas wie ein Zip-Tool


Im Grunde genommen sit es ein ZIP Archiv.

Ciao,
_