c++ vs. java... was hat zukunft
-
Konrad Rudolph schrieb:
Der Performance-Vorteil von C++ ist, dass man generisch programmieren kann und somit einen sehr hohen Grad an Abstraktion erreicht, *ohne* (im Gegensatz zu OOP) Performance-Einbuße in Kauf nehmen zu müssen.
Gibt es für "rein" generische Programmierung Musterkataloge die in ihrem Umfang den GoF Pattern vergleichbar sind?
In mehreren Bereichen würde ich's vermuten, abar bei dem "24." Muster, das die GoF implizit benutzt, nämlich "Client -> Abstrakte Schnitstelle <= Konkrete Implementierung" weiss ich nicht wie man das generisch implementieren kann.
Grüsse
*this
P.S.: @Konrad Rudolph : Hat das mit dem bitset funktioniert?
-
CStoll schrieb:
@pale dog: Ich hab' nichts gegen Java-Fans. Bei dir wundert mich nur immer wieder die Kombination "pro C", "pro Java" UND "kontra C++".
(und eventuell solltest du mal klarer herausstellen, welche deiner Aussagen jetzt für C gelten, welche für Java und welche allgemein gegen C++ ;))hauptsächlich eigene erfahrungen aber auch geschichten, die man von anderen hört (und auch die problemchen, mit denen sich manche hier auf board dem herumärgern).
z.b. kenne ich einen, der programmierkurse gibt.
wenn er C und C++ unterrichtet sagt er in etwa: 'mit C haben die leute schon probleme, die meisten schnallen's dann doch, aber mit C++ kommen die wenigsten (einsteiger) noch klar'.
über seine Java-kurse sagt er: 'wenn die grösste hürde (OOP, vererbung, etc.) erstmal genommen ist, geht alles recht flüssig.
dementsprechend weit kommen sie auch im Java-kurs, zum schluss machen sie eine swing-anwendung mit anbindung an eine SQL-datenbank und tortengrafik (so'ne wahlstimmenauszählung) drin usw. und die schüler sind hochzufrieden.
im C/C++ kurs kommen sie bis etwa 'class Auto : public Fahrzeug' und die schüler sind gefrustet.
man könnte ihm zwar vorwerfen, warum er erst mit C anfängt, und dann mit C++ weitermacht, aber er hat es schon versucht, gleich mit C++ loszulegen. das hat leider auch nicht funktioniert. offenbar muss man für C++ gewisse grundkenntnisse haben, die man etwa in einem C kurs mitbekommt.
-
damit geht java mit 17:14 in führung. jetzt muss c++ nachlegen.
-
ref schrieb:
damit geht java mit 17:14 in führung. jetzt muss c++ nachlegen.
Nein, wenn überhaut ist der Stand 16:14; "einfach in die Sprache einsteigen können" sagt nichts über die Tauglichkeit der Sprache für grosse Projekte aus!
Das ist in etwas so als habe man "Scribble"(MFC C++ Demo App) geschrieben und meine damit etwas über die Verwendung der MFC in C/S Umgebungen aussagen zu können.
Mit Einsteigern alleine kann man kein Projekt realisieren; vielmehr glaube ich dass diese fehlerhafte Interpolation der Lernkurve/Erfolgsquote für den größten Teil der Probleme mit Java verantwortlich ist.
Grüsse
*this
P.S.: Hiernach dann mindestens 15:16 wegen "Java-Lernkurvenmythos demontiert"
-
Gast++ schrieb:
Nein, wenn überhaut ist der Stand 16:14; "einfach in die Sprache einsteigen können" sagt nichts über die Tauglichkeit der Sprache für grosse Projekte aus!
nun, Java wurde für 'richtig grosse' projekte entwickelt, und wird auch dort erfolgreich eingesetzt, daran gibt's nichts zu deuteln. jemand, der programmierer für ein grosses projekt sucht, wird auch eher Java programmierer finden, denn wirklich fähige C++ programmierer sind (bedingt durch die komplexität der sprache) wirklich rar gesät.
Gast++ schrieb:
Das ist in etwas so als habe man "Scribble"(MFC C++ Demo App) geschrieben und meine damit etwas über die Verwendung der MFC in C/S Umgebungen aussagen zu können.
gutes beispiel! an der 'scribble' mfc-demo hab' ich mir damals die zähne ausgebissen, obwohl ich eigentlich dachte, ich hätte die grundlagen von C++ einigermassen verstanden. solche schwierigkeiten hatte ich beim lernen von Java nie...
Gast++ schrieb:
vielmehr glaube ich dass diese fehlerhafte Interpolation der Lernkurve/Erfolgsquote für den größten Teil der Probleme mit Java verantwortlich ist.
welche probleme siehst du (ausser vielleicht geschwindigkeit und speicherbedarf)?
immerhin ist das konzept von Java so überzeugend, dass es selbst der ewige IT-nachzügler-und-trotzdem-monopolist microsoft mit .NET nachgebaut hat.
-
pale dog schrieb:
btw, damit vm-sprachen hierbei nicht ganz alt aussehen:
so'ne vm hat die möglichkeit zur laufzeit den code zu optimieren (jit-compiler) und ihre 'virtuellen maschinenparameter' an die umgebung anzupassen. es wäre schon denkbar, dass in manchen situationen ein vm-programm scheller läuft, als eine statische 'exe'.Andererseits kann man nicht so viel Zeit für die Optimierung verwenden, da man ja alles jit machen muss. Aber der Vorteil bei der Optimierung den Java gegenüber C++ hat sind einfach: Keine Pointer. So kann man Aliasing-Probleme etc direkt ausschließen und den Code besser optimieren. Das gilt natürlich für alle Sprachen die keine Pointer haben. Daher ist Fortran zB immer noch sehr beliebt für Berechnungen.
In C99 gibt es ja das Schlüsselwort
restrictum dagegen zu wirken. Ich hoffe mal, dass das in C++0x auch kommen wird.
-
rüdiger schrieb:
So kann man Aliasing-Probleme etc direkt ausschließen und den Code besser optimieren. Das gilt natürlich für alle Sprachen die keine Pointer haben. Daher ist Fortran zB immer noch sehr beliebt für Berechnungen.
Ich denke, die Beliebtheit von Fortran für wissenschaftliche Projekte liegt eher daran, dass dafür irre viel relevanter Code existiert. ...hört man zumindest immer.
-
pale dog schrieb:
hauptsächlich eigene erfahrungen aber auch geschichten, die man von anderen hört (und auch die problemchen, mit denen sich manche hier auf board dem herumärgern).
z.b. kenne ich einen, der programmierkurse gibt.
wenn er C und C++ unterrichtet sagt er in etwa: 'mit C haben die leute schon probleme, die meisten schnallen's dann doch, aber mit C++ kommen die wenigsten (einsteiger) noch klar'.Könnte auch am Kursleiter liegen...
über seine Java-kurse sagt er: 'wenn die grösste hürde (OOP, vererbung, etc.) erstmal genommen ist, geht alles recht flüssig.
Könnte auch am Kursleiter liegen...
-
Hi Gregor,
zugegeben, es existiert unheimlich viel Fortrancode bei den Naturwissenschaftlern. Das mag u.a. daran liegen, dass diese seit den 60iger Jahren fast ausschließlich in Fortran programmieren. Wenn auch in Deutschland an den Unis vielerorts Fortran verpönt ist, so wird in den USA, England und Frankreich (die Asiaten, Japan ausgenommen, machen ja jeden Modewitz mit, z.B. Numeric Java) in Mathe, Physik und Ingenieurwissenschaften fast ausschließlich in Fortran programmiert. Die Gründe für das Überleben der alten IBM/Backus Sprache sind recht einfach:-
Fortran ist einfach überzeugend schneller als C/C++ (insbesondere bei Matrizenverarbeitung, wenn Zeiger im Spiel sind) und
-
Fortran ist doch viel viel viel einfacher als c++, trotz Objekt-Fortran (was allerdings kein Physiker anwendet).
Ich selbst beschäftige mich seit knapp einem Jaht mit der Portierung von Fortran-Algorithmen aus dem Gebiet der Astrophysik nach C++, und ich kann die Situation in diesem Bereich recht gut einschätzen. Persönlich bin ich davon überzeugt, dass c++ innovativer als Fortran ist (man bedenke nur, dass viele Physiker immer noch in Fortran 77 programmieren), aber es wird noch mehrere Generationen an Physikern erfordern, bis der Umstieg auf C++ geschafft sein wird.
Java steht hier nicht im Entferntesten zur Disskusion, da für "Massive Computing" absolut ungeeignet (nicht nur wegen der Performance, Java beherrscht ja nicht einmal IEEE-754 Zahlenformate richtig).
Viele Grüße von Tesu
-
-
@tesuji: Interessant: Für Fortran existiert also mehr Code, es ist schneller und einfacher als C++. ...warum portierst Du da was? Was ist die Motivation, die dahinter steckt? Welchen Vorteil bringt C++ da? Für Physiker stellen Programmierfähigkeiten nicht den Hauptteil Ihrer Qualifikation dar. Warum sollten die sich da gerade die komplizierteste Sprache aussuchen? Glaubst Du, dass die Interesse an möglichst elegantem Code haben? Oder benötigen sie unbedingt ein speziellen Feature von C++? Metatemplateprogrammiereung?
Abgesehen davon: Ich glaube, die wenigsten Physiker können etwas mit IEEE-754 anfangen. Die haben wichtigere Dinge zu tun, als sich über solche Dinge Gedanken zu machen.
-
Gregor schrieb:
@tesuji: Interessant: Für Fortran existiert also mehr Code, es ist schneller und einfacher als C++. ...warum portierst Du da was?
frag ich mich auch.
durch'n fortran compiler jagen und zum c++-programm dazulinken wär' wohl der gescheitere weg.
...aber vielleicht baut er auch auch nur eine weitere c++ class library (die die welt nicht braucht).
-
Gast++ schrieb:
Konrad Rudolph schrieb:
Der Performance-Vorteil von C++ ist, dass man generisch programmieren kann und somit einen sehr hohen Grad an Abstraktion erreicht, *ohne* (im Gegensatz zu OOP) Performance-Einbuße in Kauf nehmen zu müssen.
Gibt es für "rein" generische Programmierung Musterkataloge die in ihrem Umfang den GoF Pattern vergleichbar sind?
AFAIK nein. Es gibt einige Arbeiten von Alexandrescu und von einigen anderen. Aber letztendlich ist die Forschungsarbeit hier noch erstaunlich jung. Hier muss noch viel passieren. Mit ein wenig Glück wird es das aber in nächster Zeit. Allein dadurch, dass C++0x endlich anbietet, Constraints explizit auszuformulieren. Das wird generische Programmierung hoffentlich Mainstream-tauglicher machen.
Gast++ schrieb:
In mehreren Bereichen würde ich's vermuten, abar bei dem "24." Muster, das die GoF implizit benutzt, nämlich "Client -> Abstrakte Schnitstelle <= Konkrete Implementierung" weiss ich nicht wie man das generisch implementieren kann.
Generische Programmierung ist nicht allmächtig. Genau wie ein Hammer keine Schrauben eindrehen kann, muss man hier die Grenzen kennen: Generische Programmierung (zumindest in der "reinen" Form) ist statisch. Jegliche Art dynamischer Typisierung ist damit also nicht machbar.
Gast++ schrieb:
P.S.: @Konrad Rudolph : Hat das mit dem bitset funktioniert?
Klar.
Allerdings ist der Geschwindigkeitsgewinn im Anwendungsgebiet so gering, dass er praktisch kaum messbar ist. 
-
Gregor schrieb:
Abgesehen davon: Ich glaube, die wenigsten Physiker können etwas mit IEEE-754 anfangen. Die haben wichtigere Dinge zu tun, als sich über solche Dinge Gedanken zu machen.
Das ist glaube ich ein Irrtum. Wenn ich mal mit Physikern über Computing-Lösungen sprach fiel der Begriff immer.
Grüsse
*this
Btw: Zwei Menschen steigen in eine leere Fahrstuhlkabine. Beim nächsten Halt steigen drei aus.
Kommentare zum Phänomen von Experten:Experimentalphysiker: "Messfehler!"
Theoretischer Physiker: "Der Dritte hat sich reingetunnelt!"
Mathematiker: "Nun ja, wenn ein Mensch wieder einstiege wäre die Kabine erneut leer!"
-
Gast++ schrieb:
Btw: Zwei Menschen steigen in eine leere Fahrstuhlkabine. Beim nächsten Halt steigen drei aus.
Kommentare zum Phänomen von Experten:Experimentalphysiker: "Messfehler!"
Theoretischer Physiker: "Der Dritte hat sich reingetunnelt!"
Mathematiker: "Nun ja, wenn ein Mensch wieder einstiege wäre die Kabine erneut leer!"Ich (DER Experte): 9 Monate Fahrzeit, viel Essen und Langeweile.
-
MenschenKenner schrieb:
Gast++ schrieb:
Btw: Zwei Menschen steigen in eine leere Fahrstuhlkabine. Beim nächsten Halt steigen drei aus.
Kommentare zum Phänomen von Experten:Experimentalphysiker: "Messfehler!"
Theoretischer Physiker: "Der Dritte hat sich reingetunnelt!"
Mathematiker: "Nun ja, wenn ein Mensch wieder einstiege wäre die Kabine erneut leer!"Ich (DER Experte): 9 Monate Fahrzeit, viel Essen und Langeweile.
Den muss ich mir merken
-
Mal kurz eine Frage in die Runde: Wieso wird eigentlich niemals davon ausgegangen das man die VM für Java ändern kann?
Ich könnte mir schon vorstellen, das man z.B. für systemnahe programmierung eine entsprechende VM nimmt, die eben die Hardware direkter ansteuert. Genauso wird es doch für zeitkritisches Java gemacht, da wird eine spezielle VM genommen.Eigentlich bräuchte man doch nur die VM auf dem System zu ändern, den Code braucht man nicht anzufassen.
Mal ein Beispiel:
-Für alle x86-Prozessoren wird die normale JVM genommen, die eben den größten gemeinsamen Nenner bildet, damit möglichst alle Java-Programme mit dieser VM laufen.
-Für spezielle Systeme, die schneller laufen müssen, wird eben eine speziellere VM eingesetzt
-Für zeitkritsche Systeme eben eine zeitkritsche VMEin weiterer Pluspunkt für eine VM:
Stellt dir vor du schreibst Heute ein Programm in C++ für eine normale x86 32Bit Maschine. In 5 Jahren sind alle 32bit Maschinen endlich weg und es gibt nur noch 256bittige. In C++ musst du dein Programm neu kompilieren, damit es den Vorteil von den jetzigen Maschinen hat. Bei Java entwickelt sich das Programm über die JVM, das heist dein Programm bleibt immer aktuell, du hast 0 Mehraufwand.Nehmen wir doch mal das Jahr2000 Problem, alle alten Programme mussten gepatcht werden, in Java verwende ich die Klasse Calendar, die dank der Entwicklung der JVM, immer richtig rechnen wird. Anstatt 1000 Programme zu patchen, reicht es das neuste JVM auf dem System zu installieren.
Setzt natürlich eine gewährte Kompatibilität vorraus.
Das kann nur von jemand kommen der noch keine größeren Projekte mit C# gemacht hat und die Sprache + .Net nur vom Hörensagen kennt... Sorry, im Vergleich zu C# + .Net unter Windows ist Java _keine_ Alternative wenn Aspekte wie Wirtschaftlichkeit und Einhalten von engen Deadlines im Vordergrund stehen...
Was kann man den in .NET was man nicht auch in Java kann?
Äh - ja, wo ist jetzt der Unterschied zu dem normalen Umgang mit Source ? Wo ist da die spezifische Reflectionnutzung ?
Was Du da beschreibst, mache ich genauso ... eben mit C++, aber das ginge mit Fortran, COBOL, ASM, .... genauso.Geht Reflection in C++ genauso wie in Java? Also kann man (nur) kompilierten Code nehmen und daraus auf alle Eigenschaften der Klasse zugreifen?
Trotzdem verbessert sich die Performance von Java natürlich von Version zu Version. Wenn man sich die Bug-Fixes anschaut, ist man sogar sehr überrascht, welch simple und effektive Performancesteigerungen selbst in Version 7 noch eingebaut werden. ...man sollte denken, das Java schon ausgereifter wäre. Naja, aber wie schon gesagt: Das wird von Menschen geschrieben. Und die entdecken auch nach 10 Jahren nochmal, dass jemand mal nicht so sehr auf irgendetwas bestimmtes geachtet hat. Sei es nun aus Fahrlässigkeit oder deshalb, weil damals noch eine völlig andere Infrastruktur anzutreffen war.
Die C++-Compiler sind ja auch nicht über Nacht geschrieben worden und die VM Sprachen werden auch erst seit kurzem entwickelt. Ausserdem greift hier wieder mein obiges Beispiel: Ein Bug in einer VM kann durch ein Update der VM behoben werden. Wegen eines Bugs im C++-Compiler muss das Programm (bzw. alle Programme) neu kompiliert werden.
Naja, aber genauso werden die C++ Compiler natürlich auch immer besser.
Und davon profitieren die Benutzer erst, wenn der Autor sich erbarmt einen Patch für sein Programm anzuferdigen.
-
DEvent schrieb:
Ein weiterer Pluspunkt für eine VM:
Stellt dir vor du schreibst Heute ein Programm in C++ für eine normale x86 32Bit Maschine. In 5 Jahren sind alle 32bit Maschinen endlich weg und es gibt nur noch 256bittige. In C++ musst du dein Programm neu kompilieren, damit es den Vorteil von den jetzigen Maschinen hat. Bei Java entwickelt sich das Programm über die JVM, das heist dein Programm bleibt immer aktuell, du hast 0 Mehraufwand.Sooo einfach ist das alles nicht. Du willst Vorteile von 64Bit-Maschinen (oder noch mehr) mit Java ausnutzen bzw. diese Maschinen voll ausnutzen? Dann hast Du ein Problem: Java ist prinzipiell auf 32Bit ausgelegt. Willst Du mal ein Array mit 5 Mrd. Einträgen nutzen? In Java kannst Du das vergessen, auch in 10 Jahren wird das nicht möglich sein. Arrays haben in Java ein Attribut length, das ein int ist. Und die Größe eines ints ist ganz genau in der Sprache festgelegt: 32 Bit. Ebenso sieht es mit vielen Rückgabewerten usw. aus, die in der Standardbibliothek auftauchen. Du hast also prinzipiell Limitierungen, wenn es darum geht, mit der technischen Entwicklung der Rechner mitzuhalten. Und diese Limitierungen wird man nicht überwinden können, denn dadurch würde ein Großteil des bereits existierenden Javacode kaputt gehen. Wenn Du die JVM oder die Standardbibliothek änderst, dann muss alter Code weiterhin lauffähig bleiben. Wie stellst Du Dir das bei solchen Änderungen vor? Sun bringt es ja noch nichtmal fertig, deprecated-Elemente nach ein paar Jahren auch tatsächlich zu entfernen.
Wenn man einen statischen Compiler wie bei C++ hat, dann sind solche Änderungen leichter durchführbar. Da muss ein Programm nur genau einmal kompilierbar sein und nicht immer. Wenn es mit einem neueren Compiler nicht mehr kompilierbar ist, dann nimmt man halt einen alten. Die Nutzung der JVMs kannst Du als Entwickler hingegen weniger kontrollieren. (Wenn man davon absieht, dass viele Programme ihre eigene JVM mitliefern.)
Insofern denke ich, dass es momentan zwar sehr gut für Java aussieht, was Nutzung usw. betrifft, langfristig gesehen wird Java aber früher als C++ an Grenzen stoßen. ...was nicht heißt, dass C++ dann wieder die bisherigen Anwendungsgebiete von Java einnimmt: Bis dahin wird sicherlich eine andere Sprache kommen.
btw: 256Bit-Rechner wird es im Breiten Einsatz für den Privatnutzer IMHO nie geben. So weit wird die technische Entwicklung nicht gehen. Mit 64Bit ist Schluss. Man kann sich ja leicht überlegen, wieviele Miniaturisierungsschritte noch kommen müssten, bis 128Bit Sinn machen. Da würde man dann bei Strukturgrößen landen, die einfach nicht vorstellbar sind.
-
Gregor schrieb:
btw: 256Bit-Rechner wird es im Breiten Einsatz für den Privatnutzer IMHO nie geben. [...]
Zitat:
"640K sollte genug für jedermann sein."
Bill Gates, 1981
-
DEvent schrieb:
Ich könnte mir schon vorstellen, das man z.B. für systemnahe programmierung eine entsprechende VM nimmt, die eben die Hardware direkter ansteuert. Genauso wird es doch für zeitkritisches Java gemacht, da wird eine spezielle VM genommen.
Eigentlich bräuchte man doch nur die VM auf dem System zu ändern, den Code braucht man nicht anzufassen.
Wie genau stellst du dir das mit "Hardware direkter ansteuern" denn vor ohne "den Code anzufassen"? Wie könnte ich denn heute schon Java-Code für den Fluxkompensator von morgen schreiben?
-
rüdiger schrieb:
pale dog schrieb:
btw, damit vm-sprachen hierbei nicht ganz alt aussehen:
so'ne vm hat die möglichkeit zur laufzeit den code zu optimieren (jit-compiler) und ihre 'virtuellen maschinenparameter' an die umgebung anzupassen. es wäre schon denkbar, dass in manchen situationen ein vm-programm scheller läuft, als eine statische 'exe'.Andererseits kann man nicht so viel Zeit für die Optimierung verwenden, da man ja alles jit machen muss. Aber der Vorteil bei der Optimierung den Java gegenüber C++ hat sind einfach: Keine Pointer. So kann man Aliasing-Probleme etc direkt ausschließen und den Code besser optimieren. Das gilt natürlich für alle Sprachen die keine Pointer haben. Daher ist Fortran zB immer noch sehr beliebt für Berechnungen.
Klar hat Java Pointer, es versteckt sie nur recht gut
(genauer gesagt, hantierst du in Java fast nur mit Pointern, auch wenn sie dort als "Referenz" bezeichnet werden und nicht durch ein explizites * gekennzeichnet werden)Und was die Entwicklung der VM angeht: Java definiert afair exakte Größen für die verwendeten Datentypen - unabhängig von den tatsächlichen Möglichkeiten des Systems. Im C++ Standard sind legiglich Mindestgrößen definiert (und es ist durchaus erlaubt, daß irgendein zukünfitger Compiler 16-Bit-char's festlegt).