Warum Java vom Prinzip her schneller als C++?
-
Achja, noch ne nette Story, die nicht direkt was mit Java zu tun hat. Ich war mal auf einer Cache-Intersystems Tages-Schulung, weil mich OO-Datenbanken sehr begeistern. Im Gespräch mit einem der dt. Intersystems-Manager kam heraus, das diese mehrmals versucht haben Cache bei unserem Kunden rein zubringen. Sogar für die erste Zeit (Jahre?) kostenlos. Denn so ein Mega-Konzern kann sich langfristig auszahlen. VW hat ihnen aber keinen Hauch einer Chance gegeben. Er meinte, die Argumente die für Cache sprechen, waren praktisch nicht von interesse.
Ich kann nur sagen, das ist eine Erfahrung die ich auch gemacht habe.
Und glaubt mir, unser Kunde ist nicht die Ausnahme auf diesem Planeten. Politik (was das in der Wirtschaft heißt, hab ich schon oben gesagt) spielt eine viel größere Rolle.
-
-
-
-
tipp schrieb:
ich glaube die Java VM wird immer noch mit Visual C++ 6 compiliert!!!!!! (steht in nem Fehlerlog) das sollte sich auch mal ändern.
Wusste gar nicht, dass das Teil ELF Binaries erstellen kann...
@artchi: Du hast in vielen Punkten recht und ich stimme Dir auch zu, aber Du redest nur von win32. Für unsere Kunden spielt ein ganz anderer Gedanke eine wichtige Rolle: "Können wir vielleicht in 2-5 Jahren damit auf Linux migrieren?". Und genau diese Frage kommt immer und immer häufiger. Dann wird es auch mit C++ nicht mehr so schön möglich sein, weil dann Frameworks wie Qt ins Spiel kommen und Du damit die selben Probleme hast.
Linux ist auch ein Teil von "Politik" in diesem Zusammenhang.
-
Ich surf grad hier vorbei, weil ich ein Problem mit Eclipse habe.
Ich programmiere C++ auf Eclipse. Eclipse ist mehr etwas als ein einfacher Text-Editor, aber ich frage mich ernsthaft, ob das wirklich Produktivität bringt. Kaum ein Stündchen drangesessen, wird Eclipse so lahmarschig, dass ich rund 10 Sekunden warten muss, bis ich mal ein Wort getippt habe (Pentium 4 3,2GHz) Anschließend meldet sich Eclipse mit der Meldung, dass ich doch bitte Eclipse neustarten soll, es ist kein Speicher mehr da (1GB RAM installiert). Die - wenn's hoch kommt - 100kB Sourcecode (0.0001% des Speicherinhaltes) konnte er leider nicht mehr in aktueller Form abspeichern - wegen Speichermangel.
Java als Sprache ist nett, aber nicht mein Ding. Ich hab's ausprobiert (V1.3), sehr schnell grobe Designfehler gefunden (+ und += haben unter 1.3 unterschiedliche Funktionalität, += benutzt ein implizites Casting, + nicht, spätestens in 1.5 behoben) und daher programmiere wieder in C++.
Im Studium habe ich C++ als Tutor unterrichtet bei Leuten, die 2 Semester Java gelernt haben. Einmal kam jemand auf mich zu und sagte mir, dass er in dem paar Stunden C++-Tutorium überhaupt mal verstanden hat, was er da macht, wenn er programmiert. In Java hat das funktioniert, aber warum hätte er auch nicht erklären können. Das Tutorium war auf Informatikstudenten beschränkt.
Java und C# (was ich Java vorziehe, weil es quasi Java mit der Möglichkeit ist notfalls auch C++ zu programmieren) sehe ich in vielen Dingen als Entwicklungsbeschleunigung zu C++ an. Wenn's schnell gehen soll, gibt es einfache Standardtechniken, um schnell Ergebnisse zu _sehen_. Mit Entwicklern, die nicht verstanden haben, wie Programmierung funktioniert, entstehen da optisch hübsche Anwendungen, die funktionieren, die man verkaufen kann, aber bei 1 GB RAM nicht in der Lage sind, 20 kurze Quelltexte im Speicher zu verwalten und bei Speichermangel die Änderungen wenigstens noch abzuspeichern, bevor die Anwendung explodiert.
Ich kann in C++ - wenn die System-Umgebung nicht so will, wie ich will - immernoch alles machen, was ich will. Auch wenn ich vom System keinen Speicher mehr bekomme - was mir aber bei einem aktuellen Computer eigentlich nicht passieren kann, solange ich den Speicher nicht wie der letzte Idiot verschleudere.Vielleicht mal ein Vergleich: Mit GoldEd auf meinem alten Amiga mit 16MB RAM war ich produktiver als mit Eclipse. Die Software war zuverlässiger, resourcenschonender und schneller. Bis Ende 2003 habe ich mit 16MB bei 50MHz sehr angenehm programmiert. Auf'm Amiga gibt's kein Java.
Einer meiner Profs - wirklich gaaaanz alte Schule - drückte das so aus: Programmierer werden schneller dumm, als Computer schnell werden.
Ich hab's im Studium erlebt und ich erlebe es jetzt. Im Jahr 2000 hielt ich Java für eine Modeerscheinung - dann wurde ein Hype draus.Gute Software kommt von fähigen und gut ausgebildeten Programmieren, die wissen, wie ihr Werkzeug, egal ob C++ oder Java, funktioniert - und wo es nicht funktioniert.
Und die Chance, dass ein Programmierer weiß, wierum der Computer getaktet ist, sehe ich bei einem C++ Programmierer eher als gegeben an, als bei einem Java Programmierer. Keine Sprache schützt vor der Dummheit der Programmierer und den Versuch als eine Lösung zu präsentieren ist der falsche Ansatz: Der Programmierer darf nicht dumm sein, wenn die Software laufen soll.Und eine Sprache, die "ohne die gefährlichen Zeiger" funktioniert und dafür die Möglichkeit Strukturen ineinander zu schachteln entfernt, um stattdessen ausschließlich Zeiger zu verwenden, löst ein Marketingproblem. Die Null-Referenz als Programmierproblem bleibt aber erhalten. Und ein Fehler in der GarbageCollection (Referenz auf bereits entferntes Objekt) kann der Programmierer nicht mehr lösen. Der steht mit xMB Sourcecode für ein Programm da, das nicht zuverlässig läuft. Wie behebt diesen Fehler, wenn man die aktuelle Java-Version installiert hat?
Es gab' schonmal eine Sprache, die das Programmiereren vereinfachte: Basic. Programmiert heute jemand freiwillig in Basic? VisualBasic ist eine Krankheit und Purebasic macht sinnvollerweise gar nicht erst den Versuch eine objektorientierten Sprachen zu werden.Die "GIGANTISCHEN" Vorteile, dass Software (angeblich) portabel ist, hat P-Pascal schon nichts gebracht: Es hat nämlich keinen interessiert. Mir ist egal, ob ich eine Windows-, eine Linux- oder eine Mac-Version downloade - downloaden muss ich sie so oder so.
Im Falle von Eclipse habe ich mir dann die Linux-GTK-Version gezogen (übrigens immernoch ein Java-Programm... portabel... höhö), dann schmierte das Ding laufend ab, weil Eclipse nicht unter GNU-Java läuft, also habe ich dann - als ich endlich raus hatte, was da schief läuft - noch mal die Sun-VM installiert.Portabilität ist gut, aber für Java nur ein Marketing Gag, denn wer hat sich hier schon für in Java entwickelter Software entschieden, nur weil es portabel sein sollte? Wo genau liegt der Vorteil, dass ich mir ein mehrere Megabyte schweres Betriebsystem-Kondom (Java-Runtime) zusätzlich zu meiner Software installieren muss?
Für unterschiedliche Software brauche ich evtl. noch unterschiedliche Java-VMs. Die Firma, wo ich vorher war, lieferte die JavaVM gleich dazu, damit es nicht zu Problemen mit nicht ganz kompatiblen VMs kommt, die auf dem PC schon installiert sind. Was für ein Vorteil!In Embedded Systems wird Java dann auf C++ kaputtgebrochen (Garbagecollection aus, Speicher anfordern und brav von Hand wieder freigeben). Da könnte ich mir die Virtual Maschine auch direkt schenken, wenn ich stattdessen C/C++ genutzt hätte.
Dann höre ich von Java-Entwicklern: Auf dem normalen PCs sind Resourcen (Prozessor und RAM) billiger als Entwicklungskosten. Programme wie OpenOffice oder Eclipse werden von Tausenden und Abertausenden verwendet. Das sind abertausende Gigabyte Festplatte, RAM und eine nicht einschätzbare Menge an Prozessorlast, die da verschwendet werden. Mein privates Laptop hab' ich gleich mit 2Gig ausgestattet - wegen Eclipse, solange ich Eclipse nicht benutze, aber KDE, Opera, Mailer, ICQ, MP3-Player und und und habe ich 1,7G Dateicache...
Fazit: Java hat seine Existenzberechtigung - da wo es um schnelle und kurzzeitige Entwicklung geht oder wo eine einfache Möglichkeit gesucht wird, um einen komplexen Webservice anzubieten, wo PHP nicht mehr ausreicht. Da hat Java Stärken, da muss man in C++ mehr arbeiten, um das gleiche Ergebnis zu erziehlen (dafür belastet man dann aber evtl. auch den Server weniger). Bei großen Projekten (oder wenn man sich in C++ in die entsprechenden Libs eingearbeitet hat - obwohl man in Java ja auch nicht gleich alles wissen kann), ist C++ genauso schnell zu programmieren wie Java, aber kontrollierter und - bei einem fähigen Entwickler - resourcenschonender.
Vielleicht noch passend am Rande: Meinen aktuellen Job hat man mir angeboten, weil man einen C++ Programmierer suchte. Ich portiere vorhandene Algorithmen nach C oder C++, weil die Originale zu langsam sind. Das aktuelle Projekt ist eine Neuentwicklung, weil die vorhandene Software zuviel Speicher verbraucht und die meisten Systeme hier noch 32Bitter sind, was bedeutet, dass selbst für die Neueren mehr als 3,5G nicht drin währen. (was für alle Rechner dann auch wieder was teuer wäre). Hier stehen noch genug 0,x und 1,x GHz Rechner mit 256/512M RAM...
Manchmal ist der Entwickler doch billiger, als die Resourcen. Und wenn die Software nun auf C/C++ portiert wird, warum hat man sie dann nicht gleich in C++ geschrieben?
Ob ich Java-Kenntnissen besitze, wollte keiner von mir wissen, als ich hier anfing.Soll jeder programmieren, was er für optimal für sein Problem einschätzt. Aber Java als die Lösung für alles zu propagieren und im gleichen Atemzug C/C++ schlecht zu machen, wirkt irgendwann lächerlich.
Trotzdem propagiere ich inzwischen Java. Spätestens, wenn selbst Informatiker nicht mehr wissen, wie ein Computer arbeitet, werde ich mit guten C/C++ Kenntnissen und Erfahrungen sehr gut verdienen. Daher würde ich nie sagen, dass Java keine Vorteile mit sich bringt...
Bzgl. des Threadtitels: Alles eine Glaubensfrage - die Antwort findest Du in der Java-Bibel.
-
Xin schrieb:
Ich surf grad hier vorbei, weil ich ein Problem mit Eclipse habe.
Ich programmiere C++ auf Eclipse. Eclipse ist mehr etwas als ein einfacher Text-Editor, aber ich frage mich ernsthaft, ob das wirklich Produktivität bringt. Kaum ein Stündchen drangesessen, wird Eclipse so lahmarschig, dass ich rund 10 Sekunden warten muss, bis ich mal ein Wort getippt habe (Pentium 4 3,2GHz) Anschließend meldet sich Eclipse mit der Meldung, dass ich doch bitte Eclipse neustarten soll, es ist kein Speicher mehr da (1GB RAM installiert). Die - wenn's hoch kommt - 100kB Sourcecode (0.0001% des Speicherinhaltes) konnte er leider nicht mehr in aktueller Form abspeichern - wegen Speichermangel. [...]
Der Heap ist halt nicht groß genug gewesen. Wenn ständig nur 10K frei sind und der GC ständig deswegen stressen muss, wird natürlich auch noch alles langsam. Das ist nicht die Schuld von Java oder der VM, sondern man muss einer so großen Applikation wie Eclipse mehr Speicher zur Verfügung stellen. Außerdem kann man bei Eclipse einiges mit den VM-Parametern tunen. Meine bevorzugten Einstellungen sind (unter Windows):
javaw.exe -Xmx512M -Xms128M -Xbatch -Xoptimize -jar d:\home\programmierung\Eclipse\eclipse\startup.jarUnd immer auch die neueste Version der JRE verwenden. Versuch es einfach mal.
-
Optimizer schrieb:
Der Heap ist halt nicht groß genug gewesen. Wenn ständig nur 10K frei sind und der GC ständig deswegen stressen muss, wird natürlich auch noch alles langsam. Das ist nicht die Schuld von Java oder der VM [..] Außerdem kann man bei Eclipse einiges mit den VM-Parametern tunen.
Eclipse zieht sich auch gerne mehr als 512M rein, um dauerhaft sauber zu arbeiten.
Ansonsten: Ich finde das gar nicht so natürlich. Ich finde es eher... amüsant... dass es Leute gibt, die es als Anwender 'natürlich' finden, den Speicherverbrauch Ihrer Software zu 'tunen'. Noch ein Punkt, den ich bei Java eher 'bescheiden' finde - um sowas will ich mich als Anwender nicht kümmern müssen.
Ansonsten danke für den Tipp, da hat's Klick gemacht: die Installation ist noch recht jung [die JRE entsprechend neu] und das Problem war, dass ich vergessen hab' das Startscript vom Laptop zu übernehmen. Hatte ja vorher auch geklappt und startete ja auch jetzt - nur funktionierte eben nicht... ^^
Thx
-
Xin schrieb:
Ansonsten: Ich finde das gar nicht so natürlich. Ich finde es eher... amüsant... dass es Leute gibt, die es als Anwender 'natürlich' finden, den Speicherverbrauch Ihrer Software zu 'tunen'. Noch ein Punkt, den ich bei Java eher 'bescheiden' finde - um sowas will ich mich als Anwender nicht kümmern müssen.
Das ist auch nicht gedacht, dass Anwender das machen. Wenn dein Programm irgendwann bei nem DAU landet, gibst du eh nen Installer-Paket raus, was auch die richtige Verknüpfung anlegen kann. Als Eclipse-Benutzer bist du Programmierer, da muss man das von dir erwarten können.
Sei mal nicht so negativ, wenn du keinen GC hast, bist du meistens wesentlich stärker mit dem Speicher-Tunen beschäftigt, zum Beispiel durch das Schreiben eigener Allokatoren. Man muss halt mit seinem Werkzeug umgehen können.
-
Was für ein Post, zerpflücken wir mal ein bisschen. (Achtung, folgende Kommentare können nicht ganz ernst gemeint sein).
Xin schrieb:
Ich surf grad hier vorbei, weil ich ein Problem mit Eclipse habe.
Keine Angst, bist nicht der Erste.
Ich programmiere C++ auf Eclipse.
Eclipse ist eine IDE für Java, nicht für C++. Seine volle Stärke spielt Eclipse bei Java aus, das C++-Plugin ist nur ein müder Abklatsch.
Eclipse ist mehr etwas als ein einfacher Text-Editor, aber ich frage mich ernsthaft, ob das wirklich Produktivität bringt. Kaum ein Stündchen drangesessen, wird Eclipse so lahmarschig, dass ich rund 10 Sekunden warten muss, bis ich mal ein Wort getippt habe (Pentium 4 3,2GHz) Anschließend meldet sich Eclipse mit der Meldung, dass ich doch bitte Eclipse neustarten soll, es ist kein Speicher mehr da (1GB RAM installiert). Die - wenn's hoch kommt - 100kB Sourcecode (0.0001% des Speicherinhaltes) konnte er leider nicht mehr in aktueller Form abspeichern - wegen Speichermangel.
Die Anwendung läuft bei mir 8h am Tag, auf dem 600Mhz/512MB Laptop - keine Probleme. Vielleicht ist auch einfach das C++-Plugin Buggy programmiert.
Java als Sprache ist nett, aber nicht mein Ding. Ich hab's ausprobiert (V1.3), sehr schnell grobe Designfehler gefunden (+ und += haben unter 1.3 unterschiedliche Funktionalität, += benutzt ein implizites Casting, + nicht, spätestens in 1.5 behoben) und daher programmiere wieder in C++.
Also ich könnte nie C++ programmieren, dieses Schlüsselwort "namespace" sieht so doof aus - ein grober Designfehler.
Wenn du dich an solch einer Kleinigkeit störst, solltest du vielleicht Strassenwischer werden - die räumen den Dreck weg.Im Studium habe ich C++ als Tutor unterrichtet bei Leuten, die 2 Semester Java gelernt haben. Einmal kam jemand auf mich zu und sagte mir, dass er in dem paar Stunden C++-Tutorium überhaupt mal verstanden hat, was er da macht, wenn er programmiert. In Java hat das funktioniert, aber warum hätte er auch nicht erklären können. Das Tutorium war auf Informatikstudenten beschränkt.
Einverstanden, der c-Kurs hatte mir ebenfalls viel gebracht. Aber: dass ein Programmierer wenig von den Innereien der VM/des PC's versteht, hat nichts mit der Sprache zu tun. Eher mit den Tutoren die einem die Sprache beibringen.
Java und C# (was ich Java vorziehe, weil es quasi Java mit der Möglichkeit ist notfalls auch C++ zu programmieren) sehe ich in vielen Dingen als Entwicklungsbeschleunigung zu C++ an. Wenn's schnell gehen soll, gibt es einfache Standardtechniken, um schnell Ergebnisse zu _sehen_.
Ja und? Mit Java klatsche ich dir mindestens so schnell ein funktionierendes Programm hin. Die .NET-Library und die Java-Standardlib sind beide extrem mächtig, es geht nur noch darum, wer schneller die 5 benötigten Klassen findet...
Mit Entwicklern, die nicht verstanden haben, wie Programmierung funktioniert, entstehen da optisch hübsche Anwendungen, die funktionieren, die man verkaufen kann, aber bei 1 GB RAM nicht in der Lage sind, 20 kurze Quelltexte im Speicher zu verwalten und bei Speichermangel die Änderungen wenigstens noch abzuspeichern, bevor die Anwendung explodiert.
Und das hat mit der Sprache was zu tun? Jemand der nicht programmieren kann, wird weder mit Java, noch mit C++, noch mit Haskell was funktionierendes zum laufen bringen...
Ich kann in C++ - wenn die System-Umgebung nicht so will, wie ich will - immernoch alles machen, was ich will. Auch wenn ich vom System keinen Speicher mehr bekomme - was mir aber bei einem aktuellen Computer eigentlich nicht passieren kann, solange ich den Speicher nicht wie der letzte Idiot verschleudere.
Wenn du den Speicher nicht verschleuderst, musst du nichts rumwürgen. Wenn du den Speicher verschleuderst, hast du was falsch gemacht.
Man kann auch ein Java-Progi so schreiben, dass es Speicher freigibt, im Gegensatz zu einem wildgewordenen C++-Progi hat es aber keine systemweiten Nebeneffekte.Vielleicht mal ein Vergleich: Mit GoldEd auf meinem alten Amiga mit 16MB RAM war ich produktiver als mit Eclipse.
Wenn du das sagst, glaub ichs dir mal. Wahrscheinlich eine Übungssache...
Die Software war zuverlässiger,
Hab noch nie Quellcode verloren wegen einem Fehler in Eclipse. Auch sonst gabs nie Probleme mit dem Release-Versionen.
resourcenschonender
Also sollten auch heute noch kein Programm mehr als 1MB-Ram benutzen dürfen? Sorry, wenn man schon die Leistung hat, kann man sie auch ausnützen.
und schneller.
Objektiv oder subjektiv?
Bis Ende 2003 habe ich mit 16MB bei 50MHz sehr angenehm programmiert. Auf'm Amiga gibt's kein Java.
Ich hatte auf meinem 133MHz-Pentium Freude, da gabs Java.
Einer meiner Profs - wirklich gaaaanz alte Schule - drückte das so aus: Programmierer werden schneller dumm, als Computer schnell werden.
Früher war immer alles besser, schon bei den Griechen war das so.
Wenn die Programmierer heute so dumm sind, wie die Aussage deines Profs impliziert... wie können Zombies blos noch Nahrung aufnehmen?Ich hab's im Studium erlebt und ich erlebe es jetzt.
Eingebildet sind wir gar nicht?
Im Jahr 2000 hielt ich Java für eine Modeerscheinung - dann wurde ein Hype draus.
Im Jahr 2004 hielt ich C# (oder doch eher Java-for-MS?) für eine Modeerscheinung - heutzutage ist es ein Hype.
Gute Software kommt von fähigen und gut ausgebildeten Programmieren, die wissen, wie ihr Werkzeug, egal ob C++ oder Java, funktioniert - und wo es nicht funktioniert.
Joa, da hast du allerdings recht.
Und die Chance, dass ein Programmierer weiß, wierum der Computer getaktet ist, sehe ich bei einem C++ Programmierer eher als gegeben an, als bei einem Java Programmierer.
Ah, deine Software verhält sich auf einem 500Mhz-Prozessor anders als auf einem 1000Mhz-Prozessor?
Keine Sprache schützt vor der Dummheit der Programmierer
... leider ...
und den Versuch als eine Lösung zu präsentieren ist der falsche Ansatz: Der Programmierer darf nicht dumm sein, wenn die Software laufen soll.
Der Programmierer muss sich aber auch nicht um das hinterletzte Detail kümmern müssen wie das bei C++ oft der Fall ist.
Und eine Sprache, die "ohne die gefährlichen Zeiger" funktioniert und dafür die Möglichkeit Strukturen ineinander zu schachteln entfernt, um stattdessen ausschließlich Zeiger zu verwenden, löst ein Marketingproblem.
Und C# ist da anders? Lassen wir das Marketinggeblubber mal weg, die Lösung mit Referenzen in Java ist praktisch nichts anderes als C++-Pointer ohne Pointerarithmetik.
Ich mag mich da an einen Prof erinnern der war ein ganz toller Hecht. Er musste für einige Objekte einen bool speichern. Da er Platz sparen wollte, manipulierte er die Zeiger, er veränderte das letzte Bit.Danke, ich bin echt froh dass Java mich vor solchen "super" Programmierern schützt.
Die Null-Referenz als Programmierproblem bleibt aber erhalten.
Hättest du lieber automatische Initialisierung? Das würde noch viel mehr Probleme verursachen...
Und ein Fehler in der GarbageCollection (Referenz auf bereits entferntes Objekt) kann der Programmierer nicht mehr lösen.
Referenzen auf bereits entfernte Objekte gibt es nicht, denn dann wären sie nicht entfernt. Solltest du was wildes im Finalizer versuchen, würde ich ernsthaft über das Design nachdenken...
Der steht mit xMB Sourcecode für ein Programm da, das nicht zuverlässig läuft. Wie behebt diesen Fehler, wenn man die aktuelle Java-Version installiert hat?
Und wenn einer der unterschiedlichen Compiler mal wieder einen Fehler in das Compilat von C++ einbaut, steht der Programmierer mit xMB Sourcecode da, der nicht zuverlässig kompiliert. Was macht er da blos?
Genau dasselbe wie in Java oder jeder anderen Sprache: ein Workaround.
Es gab' schonmal eine Sprache, die das Programmiereren vereinfachte: Basic. Programmiert heute jemand freiwillig in Basic? VisualBasic ist eine Krankheit und Purebasic macht sinnvollerweise gar nicht erst den Versuch eine objektorientierten Sprachen zu werden.
Einverstanden
Die "GIGANTISCHEN" Vorteile, dass Software (angeblich) portabel ist, hat P-Pascal schon nichts gebracht: Es hat nämlich keinen interessiert. Mir ist egal, ob ich eine Windows-, eine Linux- oder eine Mac-Version downloade - downloaden muss ich sie so oder so.
Da ich für Leute mit unterschiedlichen Plattformen entwickle, bin ich extrem froh um dieses Feature.
Mein letzter Arbeitsgeber sah das übrigens auch so.Im Falle von Eclipse habe ich mir dann die Linux-GTK-Version gezogen (übrigens immernoch ein Java-Programm... portabel... höhö),
Der Java-Teil von Eclipse: ja. Die Libraries für SWT: nein. Eclipse ist nicht als reines Java-Programm anzusehen.
dann schmierte das Ding laufend ab, weil Eclipse nicht unter GNU-Java läuft, also habe ich dann - als ich endlich raus hatte, was da schief läuft - noch mal die Sun-VM installiert.
GNU-Java ist ein Gebastel von OS-Fundamentalisten. Ich kann dir auch das Beni-C-++ schicken, da starten die Programme leider nicht mal. Ist C++ deshalb schlecht?
Portabilität ist gut, aber für Java nur ein Marketing Gag, denn wer hat sich hier schon für in Java entwickelter Software entschieden, nur weil es portabel sein sollte?
Mein letzter Arbeitsgeber
Wo genau liegt der Vorteil, dass ich mir ein mehrere Megabyte schweres Betriebsystem-Kondom (Java-Runtime) zusätzlich zu meiner Software installieren muss?
Dasselbe bei .NET
Was glaubst du läuft bei C++? Genau dasselbe, nur werden die Libs halt schon mit dem Betriebssystem mitgeliefert.Für unterschiedliche Software brauche ich evtl. noch unterschiedliche Java-VMs. Die Firma, wo ich vorher war, lieferte die JavaVM gleich dazu, damit es nicht zu Problemen mit nicht ganz kompatiblen VMs kommt, die auf dem PC schon installiert sind. Was für ein Vorteil!
Das fällt dann unter die Kategorie "unfähige Programmierer". Die VM ist abwärtskompatibel, man muss ein Programm schon ziemlich versauen um da was kaputtzumachen.
Im übrigen gibt es nur eine VM, die von Sun. Alles andere ist Frickelware. Wer für Frickelware programmiert, muss sich nicht über Probleme wundern.In Embedded Systems wird Java dann auf C++ kaputtgebrochen (Garbagecollection aus, Speicher anfordern und brav von Hand wieder freigeben). Da könnte ich mir die Virtual Maschine auch direkt schenken, wenn ich stattdessen C/C++ genutzt hätte.
Entweder alles oder nichts. Von solchen Dingen halte ich auch nicht viel. Wenn man den GC nicht nutzen will, soll man auch kein Java verwenden.
Dann höre ich von Java-Entwicklern: Auf dem normalen PCs sind Resourcen (Prozessor und RAM) billiger als Entwicklungskosten. Programme wie OpenOffice oder Eclipse werden von Tausenden und Abertausenden verwendet. Das sind abertausende Gigabyte Festplatte, RAM und eine nicht einschätzbare Menge an Prozessorlast, die da verschwendet werden. Mein privates Laptop hab' ich gleich mit 2Gig ausgestattet - wegen Eclipse, solange ich Eclipse nicht benutze, aber KDE, Opera, Mailer, ICQ, MP3-Player und und und habe ich 1,7G Dateicache...
Dass ein Eclipse ein bisschen mehr Ressourcen benötigt als ICQ dürfte ja selbst dir als nicht derart unlogisch vorkommen?
Dennoch: mein kleiner Laptop zuckt nichtmal mit den Schultern, wenn ich ein Eclipse und weiter Java-Progis am Laufen habe.Fazit: Java hat seine Existenzberechtigung - da wo es um schnelle und kurzzeitige Entwicklung geht oder wo eine einfache Möglichkeit gesucht wird, um einen komplexen Webservice anzubieten, wo PHP nicht mehr ausreicht. Da hat Java Stärken, da muss man in C++ mehr arbeiten, um das gleiche Ergebnis zu erziehlen (dafür belastet man dann aber evtl. auch den Server weniger).
Ich dachte fast, du findest doch noch was gutes bei Java. Aber du scheinst ja nicht über deinen Schatten springen zu können.
Bei großen Projekten (oder wenn man sich in C++ in die entsprechenden Libs eingearbeitet hat - obwohl man in Java ja auch nicht gleich alles wissen kann), ist C++ genauso schnell zu programmieren wie Java, aber kontrollierter und
... besonders beim Debuggen, was ja mit C++ sehr angenehm ist ...
- bei einem fähigen Entwickler - resourcenschonender.
Ich empfehle Assembler, bei einem fähigen Entwickler ressourcenschonender als C++.
Vielleicht noch passend am Rande: Meinen aktuellen Job hat man mir angeboten, weil man einen C++ Programmierer suchte. Ich portiere vorhandene Algorithmen nach C oder C++, weil die Originale zu langsam sind. Das aktuelle Projekt ist eine Neuentwicklung, weil die vorhandene Software zuviel Speicher verbraucht und die meisten Systeme hier noch 32Bitter sind, was bedeutet, dass selbst für die Neueren mehr als 3,5G nicht drin währen. (was für alle Rechner dann auch wieder was teuer wäre). Hier stehen noch genug 0,x und 1,x GHz Rechner mit 256/512M RAM...
Also du schreibst eine Spezialanwendungen. Und wielange sitzt du an den Algorithmen, optimierst mühsam von Hand, wo man mit Java schon längst ein laufendes System hätte?
Manchmal ist der Entwickler doch billiger, als die Resourcen. Und wenn die Software nun auf C/C++ portiert wird, warum hat man sie dann nicht gleich in C++ geschrieben?
Frag deinen Cheffe, ich habe diese Entscheidung nicht getroffen.
Ob ich Java-Kenntnissen besitze, wollte keiner von mir wissen, als ich hier anfing.
Nach deinen Argumenten hier: nein. Und du willst auch gar keine besitzen. Es ist doch viel bequemer ein bisschen auf etwas rumprügeln als sich ernsthaft damit ausseinanderzusetzen. (Ach ja, das mit dem rumprügeln gilt auch für mich
)Soll jeder programmieren, was er für optimal für sein Problem einschätzt. Aber Java als die Lösung für alles zu propagieren und im gleichen Atemzug C/C++ schlecht zu machen, wirkt irgendwann lächerlich.
Jeden Java-Programmierer als unfähigen Trottel darzustellen und Java im gleichen Atemzug mit "langsam", "ressourcenfressend", etc nennen, wirkt ebenfalls lächerlich.
Trotzdem propagiere ich inzwischen Java. Spätestens, wenn selbst Informatiker nicht mehr wissen, wie ein Computer arbeitet, werde ich mit guten C/C++ Kenntnissen und Erfahrungen sehr gut verdienen. Daher würde ich nie sagen, dass Java keine Vorteile mit sich bringt...
Ah, ein Witz, hi hi hhhi *gähn*
Bzgl. des Threadtitels: Alles eine Glaubensfrage - die Antwort findest Du in der Java-Bibel.
Das heisst Java-API-Dokumentation
Übrigens: wenn alteingesessene C++-Leute ihre Sprache gegen Neuerungen schützen möchten, stehen sie einem religiösen Fanatiker in nichts nach.***
Natürlich weiss ich, dass es nicht *die* Lösung für alle Probleme gibt. In einigen Gebieten ist C++ klar überlegen, in einigen Gebieten kommt nichts an Java ran, nur Eiffel verliert immer.
Das andauernde Java-Gebashe geht mir auf den Kecks. Xin, du bist ja offensichtlich kein Volltrottel (?), dann guck mal über den Tellerand der C-Suppe hinaus.
Je verbreiteter PC's werden, desto mehr Programmierer wird es geben - auch unfähige. Dass sich Unfähige auf die, vermeintlich, einfache Sprache Java stürzen ist kein Wunder. Dass ein Programm in Java deshalb automatisch schlecht ist, ist hingegen ein Trugschluss.
-
mir fallt zu dem "was is schneller" auch was ein.
vor ein paar jahre, als dot net neu am makrt war, war ich bei einer MS markteting kampfveranstaltung.
uA mit so sinnvollen parabeln das die columbia mit dotnet nicht abgestuertzt waer weil ein unbermerkter integeroverflow nicht passieren kann, oder etwas aehnlich sinnfolles, verzeiung das ich den genauen bloedsinn nicht mher ganz im gedaechtniss hab, auf jeden fall wars das boese C das fuer den absturz verantwortlich war.
nunja, von manager fuer manager.auf jeden fall,
es gibt das eine java referenzapplikation, die auf eine db zugreift und eine businesslogik schicht hat.diese ref app wurde in c# nachprogrammiert und war um faktor X (ganz genau weis ich es nicht, es war absurd hoch) schneller.
c# schneller als java?
in den koepfen der anwesenden it fachleuten, bei einer developerveranstaltung mind 75% entscheidungstraeger, is es wohl so haengengeblieben.
im detail wars aber so, das die c# implementation die gesamte businesslogik direkt am SQL Server implementiert wurde.
ein detail, was von den anwesenden so gut wie niemand realisiert hatte.(T)SQL schneller als c# ?
haeaeaeae??????
was zeigt, solche schwanzlaengenvergleiche, was is schneller, sind fuer die wuerscht.
ebenfalls gabs in der ct vor einiger zeit, auch schon 1/2/3 jahre her, weiss nicht, einen vergleich, da wurde recht viel mit strings gemacht, da war java schneller als c++.
wenn man sich den c++ code angeschaut hat, und verstanden hat wo die fehler lagen, hats natuerlich niemand gewundert.fazit, so tempotests sind ungefaehr genauso serioes und sinnig wie politische meinungsumfragen.
-
JBeni schrieb:
Java als Sprache ist nett, aber nicht mein Ding. Ich hab's ausprobiert (V1.3), sehr schnell grobe Designfehler gefunden (+ und += haben unter 1.3 unterschiedliche Funktionalität, += benutzt ein implizites Casting, + nicht, spätestens in 1.5 behoben) und daher programmiere wieder in C++.
Also ich könnte nie C++ programmieren, dieses Schlüsselwort "namespace" sieht so doof aus - ein grober Designfehler.
Wenn du dich an solch einer Kleinigkeit störst, solltest du vielleicht Strassenwischer werden - die räumen den Dreck weg.Namespaces könnten etwas handlicher sein, aber für die Anwendung, wie sie in C++ geregelt benötigt wird, empfinde den Namen als korrekt.
Namespaces sind keine Packages.
Was die Kleinigkeit angeht: 1.) Java ist noch recht jung, grade mal 13 Jahre alt, man hätte mehr aus C++ lernen können. 2) C++ ist 27 Jahre alt und die erste Sprache, die OOP aus der Akademikerwelt in die reale Welt gebracht hat. Eine Sprache, die Dinge antestet und erste Schritte in ein für die Allgemeinheit unbekanntes Terrain macht, verzeihe ich einen Designfehler eher als einer Sprache, die bereits Erfahrungen hätte recherchieren können. 3.) Der von mir gefundene Fehler wurde spätestens in V1.5 behoben. Offenbar bin ich nicht der einzige, der sich Fehlern am "+"-Operator gestört hat.JBeni schrieb:
Einverstanden, der c-Kurs hatte mir ebenfalls viel gebracht. Aber: dass ein Programmierer wenig von den Innereien der VM/des PC's versteht, hat nichts mit der Sprache zu tun. Eher mit den Tutoren die einem die Sprache beibringen.
In einer Sprache, in der ich nicht verstehen muss, wie der Computer arbeitet, besteht auch keine Notwendigkeit, es den Lernenden beizubringen. Das Wort "Zeiger" löst bei vielen Angstzustände aus - bei Schülern und Lehrenden, keine Ahnung warum. Also läßt man es in Java weg. Das befreit von Angstzuständen auf beiden Seiten und wenn's keiner laut ausspricht, können wir uns einbilden, dass wie wüßten, was wir tun.
JBeni schrieb:
es geht nur noch darum, wer schneller die 5 benötigten Klassen findet...
Richtig, genau darum geht es... schön, dass mal aus der Java-Ecke bestätigt zu hören.
JBeni schrieb:
Man kann auch ein Java-Progi so schreiben, dass es Speicher freigibt, im Gegensatz zu einem wildgewordenen C++-Progi hat es aber keine systemweiten Nebeneffekte.
Welchen Vorteil hat Java, wenn nicht die Standard-Libs. Die GC! Wenn ich die dann auch noch abschaltelte habe....?
Ein Programm, dass mehr Speicher verbraucht als erforderlich, weil die GC noch nicht aufgeräumt hat, halte ich für einen systemweiten Nebeneffekt.
Eine hohe Prozessorlast, weil die GC angesprungen ist, so dass in dem Moment der Computer seine (evtl. getimten oder sogar zeitkritischen) Aufgaben nicht mehr erfüllen kann, halte ich für einen systemweiten Nebeneffekt.JBeni schrieb:
resourcenschonender
Also sollten auch heute noch kein Programm mehr als 1MB-Ram benutzen dürfen? Sorry, wenn man schon die Leistung hat, kann man sie auch ausnützen.
Warum muss ich dann die JVM von Hand erweitern oder beschränken, wenn ich die Resourcen doch habe?
JBeni schrieb:
Keine Sprache schützt vor der Dummheit der Programmierer und den Versuch als eine Lösung zu präsentieren ist der falsche Ansatz: Der Programmierer darf nicht dumm sein, wenn die Software laufen soll.
Der Programmierer muss sich aber auch nicht um das hinterletzte Detail kümmern müssen wie das bei C++ oft der Fall ist.
Um Details kümmert man sich einmal, wenn man C++ lernt. Dann kennt man die Details und benutzt angemessene Lösungen, die man bei Bedarf anpassen kann und auf das Problem optimieren kann.
JBeni schrieb:
Die Null-Referenz als Programmierproblem bleibt aber erhalten.
Hättest du lieber automatische Initialisierung? Das würde noch viel mehr Probleme verursachen...
Wie wär's mit der richtigen Informationen an den Entwickeler? Dem Programmierer wird nicht vorgeschaukelt, dass er keine Angst vor Zeigern haben muss. Er muss Zeiger verwenden, weil Java nichts anderes mehr beherrscht und er muss verstanden haben, wie Zeiger reagieren - ansonsten wird er seine Benutzer halt mit Exceptions nerven.
Zu verlangen, dass der Programmierer versteht, was er tut, verkauft sich aber nicht so gut. Java kümmert sich um alles mag vielleicht nicht der Wahrheit entsprechen, klingt in den Ohren derer, die mit Softwarefehlern kämpfen aber besser.JBeni schrieb:
Und ein Fehler in der GarbageCollection (Referenz auf bereits entferntes Objekt) kann der Programmierer nicht mehr lösen.
Referenzen auf bereits entfernte Objekte gibt es nicht, denn dann wären sie nicht entfernt. Solltest du was wildes im Finalizer versuchen, würde ich ernsthaft über das Design nachdenken...
Referenzen auf bereits entfernte Objekte gibt es nicht...? Tjo, wir haben uns die Exception auch interessiert angesehen. Die Entwickler mit Besorgnis und ich durfte grinsen. Ich habe die Entwicklung in Java von vorneherein abgelehnt, ergo nicht mein Problem.
JBeni schrieb:
Mir ist egal, ob ich eine Windows-, eine Linux- oder eine Mac-Version downloade - downloaden muss ich sie so oder so.
Da ich für Leute mit unterschiedlichen Plattformen entwickle, bin ich extrem froh um dieses Feature.
Mein letzter Arbeitsgeber sah das übrigens auch so.Der Punkt geht erstmal zweifelsohne an Dich, ich habe mich dazu hinreißen lassen, ausschließlich die Portablität aus Anwenderseite zu betrachten. Aus Entwicklerseite ist Java eine schöne Idee.
Aber auch hier sehe ich das Problem bisher nur halb. Das Problem ist in der Regel die GUI. Dafür gibt's in C++ auch Libs, ich glaube, da ist Java aber inzwischen mit SWT vorn. Aber die GUI ist auch nur ein kleines Problem - wenn man Software schreibt, die mehr tut als nur eine GUI für eine andere Software anzubieten... Die lagert man entsprechend MVC aus und wenn die vorhandenen Libs nicht gefallen, muss man den Part tatsächlich OS-Konform schreiben. Aber eine GUI stellt doch jetzt nicht ernsthaft eine Herausforderung dar, die in einem nennenswerten Verhältnis zur eigentlichen Software steht?!
JBeni schrieb:
Wo genau liegt der Vorteil, dass ich mir ein mehrere Megabyte schweres Betriebsystem-Kondom (Java-Runtime) zusätzlich zu meiner Software installieren muss?
Dasselbe bei .NET
Was glaubst du läuft bei C++? Genau dasselbe, nur werden die Libs halt schon mit dem Betriebssystem mitgeliefert.Die Libs sind das OS. (Aussage gilt nicht für .NET, das ist Java von MS.)
JBeni schrieb:
Für unterschiedliche Software brauche ich evtl. noch unterschiedliche Java-VMs. Die Firma, wo ich vorher war, lieferte die JavaVM gleich dazu, damit es nicht zu Problemen mit nicht ganz kompatiblen VMs kommt, die auf dem PC schon installiert sind. Was für ein Vorteil!
Das fällt dann unter die Kategorie "unfähige Programmierer". Die VM ist abwärtskompatibel, man muss ein Programm schon ziemlich versauen um da was kaputtzumachen.
Im übrigen gibt es nur eine VM, die von Sun. Alles andere ist Frickelware. Wer für Frickelware programmiert, muss sich nicht über Probleme wundern.Ich selber habe nur die VM für Sun benutzt - bis auf die Linux-Installation, wo Eclipse lief und wegen GNUJava abschmierte.
Wir hatten doch schon ein paar interessante Schritte in Java. 1.1 = 1.2 und alles war anders. 1.4 zu 1.5 war doch auch ein etwas eiliger Schritt.
Frag' mich nicht in Details - ich habe nur den Aufschrei gehört, als 1.5 rauskam und es plötzlich hieß, dass die Techniken von 1.4 nun böse Magie wären.
Dann wurden wohl irgendwelche Kompatiblitätsklassen nachinstalliert, die sind jetzt zwar alle veraltet und sollen in Zukunft bitte nicht mehr verwendet werden, aber wenigstens läuft ältere Software auf 1.5 dann wieder.Ich hab' da nur die Hände gehoben - ich hab' da nix zu tun, ich habe da kein Java programmiert. Nicht mein Problem und ich hab's auch nicht genauer verfolgt.
JBeni schrieb:
In Embedded Systems wird Java dann auf C++ kaputtgebrochen (Garbagecollection aus, Speicher anfordern und brav von Hand wieder freigeben).
Entweder alles oder nichts. Von solchen Dingen halte ich auch nicht viel. Wenn man den GC nicht nutzen will, soll man auch kein Java verwenden.
Ich zitiere Dich (s.o.) "Man kann auch ein Java-Progi so schreiben, dass es Speicher freigibt, ...". Wo es eben noch als Argument für Java galt, so sollte man es(Java/das Arguemnt) doch nicht nutzen, wenn's drauf ankommt!?
JBeni schrieb:
Fazit: Java hat seine Existenzberechtigung - da wo es um schnelle und kurzzeitige Entwicklung geht oder wo eine einfache Möglichkeit gesucht wird, um einen komplexen Webservice anzubieten, wo PHP nicht mehr ausreicht. Da hat Java Stärken, da muss man in C++ mehr arbeiten, um das gleiche Ergebnis zu erziehlen (dafür belastet man dann aber evtl. auch den Server weniger).
Ich dachte fast, du findest doch noch was gutes bei Java. Aber du scheinst ja nicht über deinen Schatten springen zu können.
Jow... ich versuche es nochmal: Ich finde Java grundsätzlich ja nichtmal schlecht. Java als Idee hat sich Prinzipien gesetzt und wollte die Dinge besser machen als C++. Auch ich bin der Überzeugung, dass C++ alt ist, auch mich ärgern Konzept-Fehler, die in C++ vorhanden sind. Java bringt mit den Packages sinnvolle Erweiterungen mit. Aber C++ ist trotz Konzept-Fehler eine sehr klar strukturierte Sprache, sehr schnell, sehr flexibel und ein extrem mächtigtes Tool. Java ist gut, aber es reicht in meinen Augen trotz 1.5 noch nicht an C++ heran. Der gravierenste Nachteil ist die VM, die Java immer dann disqualifiziert, sobald Resourcen oder Detail-Optimierung ins Spiel kommt. Denn Rechenzeit oder Arbeitsspeicher kann man nie genug haben.
JBeni schrieb:
Vielleicht noch passend am Rande: Meinen aktuellen Job hat man mir angeboten, weil man einen C++ Programmierer suchte. Ich portiere vorhandene Algorithmen nach C oder C++, weil die Originale zu langsam sind. Das aktuelle Projekt ist eine Neuentwicklung, weil die vorhandene Software zuviel Speicher verbraucht und die meisten Systeme hier noch 32Bitter sind, was bedeutet, dass selbst für die Neueren mehr als 3,5G nicht drin währen. (was für alle Rechner dann auch wieder was teuer wäre). Hier stehen noch genug 0,x und 1,x GHz Rechner mit 256/512M RAM...
Also du schreibst eine Spezialanwendungen. Und wielange sitzt du an den Algorithmen, optimierst mühsam von Hand, wo man mit Java schon längst ein laufendes System hätte?
Ich portiere die Algorithmen 1:1 in optimiertes C um. Eine nachträgliche Optimierung findet nicht mehr statt. Ich programmiere grundsätzlich optimiert, ich kenne die meisten Fallgruben und umgehe sie entsprechend. Bei der 1:1 Portierung verstehe ich den Algorithmus und seine Besonderheiten. Anschließend reiche ich - wenn mir passendes einfällt - eine Empfehlung ein, wie man den vorhandenen Algorithmus ersetzen könnte, gegen einen anderen, der aber identische Ergebnisse liefert. Wurde bisher noch nie umgesetzt, die 1:1 Portierungen waren bereits wesentlich schneller, als benötigt.
JBeni schrieb:
Ob ich Java-Kenntnissen besitze, wollte keiner von mir wissen, als ich hier anfing.
Nach deinen Argumenten hier: nein. Und du willst auch gar keine besitzen. Es ist doch viel bequemer ein bisschen auf etwas rumprügeln als sich ernsthaft damit ausseinanderzusetzen. (Ach ja, das mit dem rumprügeln gilt auch für mich
)Ich habe Java-Kenntnisse. Nachdem ich sie mir vor 3 oder 4 Jahren angeeignet habe, fand ich Vorzüge gegenüber C++, aber ich fand mehr, was ich C++ bevorzuge. Mir gefiel Java nicht. Trotzdem habe ich ein Projekt damit gemacht, denn wenn alle Java so toll finden und ich nicht, bin ich vermutlich der Depp und muss mal was richtiges mit Java schreiben. Mit dem Projekt wollte ich Erfahrung sammeln. Das habe ich. Seitdem habe ich kein Java mehr programmiert und meine Kenntnisse auch nicht mehr auf den aktuellen Stand gebracht.
Seit 1.5 wollte ich mich mal wieder auf den aktuellen Stand bringen, mir die generics usw mal ansehen, aber bisher fehlte die Zeit und die Notwendigkeit. Wo Java und C# in ihren aktuellen Versionen nun generics eingefügt haben, bemerke ich, dass generische Programmierung gute Chancen auf den nächsten Hype hat.
Generische Programmierung kennt C++ seit 1990, afair.JBeni schrieb:
Soll jeder programmieren, was er für optimal für sein Problem einschätzt. Aber Java als die Lösung für alles zu propagieren und im gleichen Atemzug C/C++ schlecht zu machen, wirkt irgendwann lächerlich.
Jeden Java-Programmierer als unfähigen Trottel darzustellen und Java im gleichen Atemzug mit "langsam", "ressourcenfressend", etc nennen, wirkt ebenfalls lächerlich.
Das habe ich nicht. Ich sagte, dass die Chance, dass ein hardwarenaher Programmierer weiß, wie der Computer funktioniert, in meinen Augen höher ist, als wenn man eine abstraktere Sprache verwendet. Jemand, der eine abstrakte Sprache verwendet, kann durchaus hardwarenahe Kenntnisse besitzen.
Früher war ich der Überzeugung, dass es für einen hardwarenahen Programmierer Vorteile hat, auf eine abstraktere Sprache umzusteigen. Auch ganz andere Sprachen wie Prolog haben ihren Reiz.
Inzwischen bin ich da vorsichtiger geworden. Abstraktion ist für große Projekte unverzichtbar, aber man sollte den Kontakt zum Grund nicht verlieren.Wenn's dann darum geht Lösungen zu produzieren, lande ich häufig wieder bei C++ bzw. C#. Beide Sprachen erlauben ein hohes Maß an Abstraktion, C++ steht aber mit allen Bits auf'm Grund und bei C# gibt's zumindest eine Lucke mit "unsafe", wenn man doch mal an die Basis muss.
Kann auch daran liegen, dass ich bisher selten Probleme lösen musste, die sich von einer abstrakten Basisklasse ableiten lassen.JBeni schrieb:
Bzgl. des Threadtitels: Alles eine Glaubensfrage - die Antwort findest Du in der Java-Bibel.
Das heisst Java-API-Dokumentation
Übrigens: wenn alteingesessene C++-Leute ihre Sprache gegen Neuerungen schützen möchten, stehen sie einem religiösen Fanatiker in nichts nach.Ich bin kein Fanatiker.
Ich wünsche mir eine Neuauflage von C++ mit kompletter Überarbeitung der Sprache. Den auch C++ ist nicht die endgültige Lösung.
Ich wünsche definitiv keinen Wechsel zu einer VM.
Ich wünsche auch keine GC.
Und ich arbeite seit 2003 dran. Ich schreibe mir Konzeptfehler auf und Konzepte, die ich beim Programmieren in diversen Sprachen vermisse, entwickle sie und probiere sie in meinem Compiler aus. Teste, wie sich vorhandene Konzepte abstrahieren lassen, wie sich neue Konzepte in die Sprache einfügen, wie sie sich anfühlen, ob sie intuitiv verständlich sind. Ich habe 2003 bei C++ angefangen, wollte zuerst eine kompatible Erweiterung zu C++ und habe dabei erkannt, dass sich die C++ Syntax so nicht halten läßt, wenn man Konzeptfehler korrigieren möchte.
Bjarne Stroustrup hat viele Entscheidungen, aber auch Fehler in C++ in seinem Buch 'Design und Entwicklung von C++' beschrieben. Bei Java weiß ich nicht, ob Stroustrup seine Erfahrungen da schon so offen berichtet hat. Bei C# gab es das Buch schon, was die Existenz von C# eigentlich als groben Designfehler degradiert. Aber in C# hat man wenigstens Erfahrungen aus Java berücksichtigt, das C#-Schlüsselwort "out" ist ein schönes Beispiel dafür.Wie Du siehst, ich sehe C++ nicht als Zukunft an. Aber in der Gegenwart finde ich zur Zeit nichts Besseres.
JBeni schrieb:
Xin, du bist ja offensichtlich kein Volltrottel (?), dann guck mal über den Tellerand der C-Suppe hinaus.
In beiden Fällen gebe ich mir Mühe ein positives Bild von mir zu zeigen. ^^
Meine Programmiersprachensuppe besteht aus verschiedenen Basic-Dialekten, Assembler auf verschiedenen Prozessoren, C#, (Objective) Pascal, JavaScript, Prolog, PHP, SQL.
Dazu kommt ein klein wenig Lisp, was Perl, Rebol, Python und Rexx oder ein Hauch Fortran und andere heutzutage eher exotische Sprachen. Ich habe '86 angefangen zu programmieren und schaue mich regelmäßig um. Ruby soll auch nicht verkehrt sein.
Bisher sehe ich allerdings leider(!) keine bedeutende Alternative zu C++. Java hat's versucht, Java hatte Chancen, aber in meinen Augen reicht es nicht.
-
daHa schrieb:
uA mit so sinnvollen parabeln das die columbia mit dotnet nicht abgestuertzt waer weil ein unbermerkter integeroverflow nicht passieren kann, oder etwas aehnlich sinnfolles, verzeiung das ich den genauen bloedsinn nicht mher ganz im gedaechtniss hab, auf jeden fall wars das boese C das fuer den absturz verantwortlich war.
War das nicht eigentlich die Ariane 5, die abgestürzt ist, gerade weil der Festkomma-Überlauf bemerkt wurde und der entsprechende Exception-Handler die Selbstzerstörung eingeleitet hat, wofür man Ada nun wirklich nicht die Schuld geben kann?
-
Auf jeden Fall ist irgendne Mars-Mission schiefgegangen, weil die Entwickler mit einer Mischung aus Zoll und Zentimetern gerechnet hatten. Ich weiß zwar nicht, in welcher Sprache die Software programmiert wurde, aber eine Sprache die sowas erlaubt, gehört in die Sonne geschossen.
-
Ich musste mich im Studium 2 Semester mit C++ rumplagen. Umso weiter ich in die Sprache vorgedrungen bin, desto schrecklicher fand ich sie.
Als ich dann Java kennenlernte, war ich bereits recht angetan. Richtig begeistert bin ich jedoch von C#, da es Details, die ich in Java vermisste habe, aufwies. Darunter z.B. Call-By-Reference oder Properties.
Seitdem ich VS.NET 2005 und C# benutze, macht programmieren sogar ein bißchen Spaß.
-
ARIANE 5: Die Berechnung der Flugbahn der Ariane 5 wurde in ADA programmiert. Und der Bug war folgender: Es wurde eine 64bit foating Variable in eine 16bit long Variable konvertiert. Der Boardcomputer dachte er wäre auf der falschen Flugbahn und löste eine Exception aus. Da eine falsche Flugbahn aus Sicherheitsgründen eine Exception auslöst, wurde eine Selbstzerstörung einleitet.
Wenn ich es richtig verstanden habe, war die Ariane 5 garnicht auf der falschen Flugbahn, sondern der Boardcomputer hatte halt nur falsche Werte erhalten, durch die konvertierung von 64 auf 16 bit.
Und nein, C++ war nicht im Spiel.
-
interpreter schrieb:
Ich musste mich im Studium 2 Semester mit C++ rumplagen. Umso weiter ich in die Sprache vorgedrungen bin, desto schrecklicher fand ich sie.
Als ich dann Java kennenlernte, war ich bereits recht angetan. Richtig begeistert bin ich jedoch von C#, da es Details, die ich in Java vermisste habe, aufwies. Darunter z.B. Call-By-Reference oder Properties.
Seitdem ich VS.NET 2005 und C# benutze, macht programmieren sogar ein bißchen Spaß.Seltsam, ich habe noch nie jemanden sagen hören, dass er bei C# sich gegenüber Java über den Index-Operator freut. Das ist nämlich echt ein Operator, der selbst in Java definierbar sein sollte, denn er ist unär und könnte wie jede Methode dynamisch gebunden werden. Ist der Index-Operator nur mir so wichtig?
-
Xin: wenn ich irgendwo nicht antworte, sehe ich deine Argumentation als zutreffend an.
Xin schrieb:
Was die Kleinigkeit angeht: 1.) Java ist noch recht jung, grade mal 13 Jahre alt, man hätte mehr aus C++ lernen können.
Dann wäre es von den C++-Jüngern noch mehr abgelehnt worden. Ausserdem: im Nachhinein findet sich immer etwas, das man noch ändern könnte. Schönes Beispiel sind da die neuen Generics die (endlich) sowas wie Typsicherheit bringen.
In einer Sprache, in der ich nicht verstehen muss, wie der Computer arbeitet, besteht auch keine Notwendigkeit, es den Lernenden beizubringen.
Um ein Java-Progi zu schreiben muss man die Innereien nicht kennen.
Um ein gutes Java-Progi zu schreiben, sollte man durchaus wissen wie ein PC, und noch wichtiger: wie die JVM, funktioniert.Das Wort "Zeiger" löst bei vielen Angstzustände aus - bei Schülern und Lehrenden, keine Ahnung warum. Also läßt man es in Java weg. Das befreit von Angstzuständen auf beiden Seiten und wenn's keiner laut ausspricht, können wir uns einbilden, dass wie wüßten, was wir tun.
Weil man damit sehr schnell sehr viel verbocken kann. Und herausfinden wer jetzt wieder das Objekt auf das ein Zeiger zeigte gelöscht hatte, gehört zu den eher unangenehmen Tätigkeiten.
Java hat auch "Zeiger" (von einem abstrakten Punkt aus gesehen), nur sorgt der GC dafür und die fehlende Pointerarithmetik für weniger Stolpersteine.JBeni schrieb:
Man kann auch ein Java-Progi so schreiben, dass es Speicher freigibt, im Gegensatz zu einem wildgewordenen C++-Progi hat es aber keine systemweiten Nebeneffekte.
Welchen Vorteil hat Java, wenn nicht die Standard-Libs. Die GC! Wenn ich die dann auch noch abschaltelte habe....?
Man kann auch Teile auf die Festplatte schreiben, unwichtige Objekte abräumen lassen, den GC muss man dafür nicht gleich ausschalten
Ein Programm, dass mehr Speicher verbraucht als erforderlich, weil die GC noch nicht aufgeräumt hat, halte ich für einen systemweiten Nebeneffekt.
Eine hohe Prozessorlast, weil die GC angesprungen ist, so dass in dem Moment der Computer seine (evtl. getimten oder sogar zeitkritischen) Aufgaben nicht mehr erfüllen kann, halte ich für einen systemweiten Nebeneffekt.Stattgegeben. Wobei letzteres auch ein Problem des Betriebssystemes ist.
Warum muss ich dann die JVM von Hand erweitern oder beschränken, wenn ich die Resourcen doch habe?
Es ging mir um Eclipse und GoldEd.
Über die seltsam unflexible, problemverursachende, unangepasste Pseudo-Verwaltung von Speicher bei der JVM, möchte ich mich lieber ausschweigen...Um Details kümmert man sich einmal, wenn man C++ lernt. Dann kennt man die Details und benutzt angemessene Lösungen, die man bei Bedarf anpassen kann und auf das Problem optimieren kann.
Wenn man genügend Aufwand betreibt, kann man nach einigen Jahren auch mit Assembler gut programmieren. Nur bis man es kann, schreibt man blos Quatsch.
Wenn ich Leute beim C++-coden zuschaue habe ich das Gefühl, dass sie die meiste Zeit am optimieren sind, und ansonsten fast nicht vorwärts kommen...JBeni schrieb:
Die Null-Referenz als Programmierproblem bleibt aber erhalten.
Hättest du lieber automatische Initialisierung? Das würde noch viel mehr Probleme verursachen...
Wie wär's mit der richtigen Informationen an den Entwickeler?
Jetzt bin ich aber gespannt, was soll der Entwickler denn für Informationen bekommen? Vielleicht wäre das aber auch was für einen eigenen Thread
Zu verlangen, dass der Programmierer versteht, was er tut, verkauft sich aber nicht so gut. Java kümmert sich um alles mag vielleicht nicht der Wahrheit entsprechen, klingt in den Ohren derer, die mit Softwarefehlern kämpfen aber besser.
Bitte kein Marketinggeblubber in diesem Thread, wir sind alle genug erfahren, um darauf nicht reinzufallen
Referenzen auf bereits entfernte Objekte gibt es nicht...? Tjo, wir haben uns die Exception auch interessiert angesehen. Die Entwickler mit Besorgnis und ich durfte grinsen. Ich habe die Entwicklung in Java von vorneherein abgelehnt, ergo nicht mein Problem.
Quellcode? Name der Exception? Ansonsten ist das halt doch eine recht dürftige Aussage.
JBeni schrieb:
Mir ist egal, ob ich eine Windows-, eine Linux- oder eine Mac-Version downloade - downloaden muss ich sie so oder so.
Da ich für Leute mit unterschiedlichen Plattformen entwickle, bin ich extrem froh um dieses Feature.
Mein letzter Arbeitsgeber sah das übrigens auch so.Der Punkt geht erstmal zweifelsohne an Dich, ich habe mich dazu hinreißen lassen, ausschließlich die Portablität aus Anwenderseite zu betrachten. Aus Entwicklerseite ist Java eine schöne Idee.
Danke
Von der Anwenderseite lohnt es sich, wenn man Dualboot hat (Ok, das war jetzt ein schwaches Argument, fast niemand benutzt sowas).Aber auch hier sehe ich das Problem bisher nur halb. Das Problem ist in der Regel die GUI. Dafür gibt's in C++ auch Libs, ich glaube, da ist Java aber inzwischen mit SWT vorn. Aber die GUI ist auch nur ein kleines Problem - wenn man Software schreibt, die mehr tut als nur eine GUI für eine andere Software anzubieten... Die lagert man entsprechend MVC aus und wenn die vorhandenen Libs nicht gefallen, muss man den Part tatsächlich OS-Konform schreiben. Aber eine GUI stellt doch jetzt nicht ernsthaft eine Herausforderung dar, die in einem nennenswerten Verhältnis zur eigentlichen Software steht?!
Eine gute GUI schreiben ist nicht ganz trivial. Nimm das erstbeste Programm auf deinem PC und guck mal, was dir alles an der GUI nicht gefällt...
Dann benötigt man noch jemanden der die verschiedenen Frameworks gut genug kennt. Und wenn man z.B. Eclipse anschaut: da gibt es doch einige Dialoge und Panels die nicht einfach zu bauen sind (z.B. Syntaxhighlighting).Wie portabel die verschiedenen (GUI und Nicht-GUI) Libs für C++ sind, kann ich nicht beurteilen, solange man sich auf die STL beschränkt, sehe ich da aber keine grossen Probleme?
Ich selber habe nur die VM für Sun benutzt - bis auf die Linux-Installation, wo Eclipse lief und wegen GNUJava abschmierte.
Wir hatten doch schon ein paar interessante Schritte in Java. 1.1 = 1.2 und alles war anders. 1.4 zu 1.5 war doch auch ein etwas eiliger Schritt.
Frag' mich nicht in Details - ich habe nur den Aufschrei gehört, als 1.5 rauskam und es plötzlich hieß, dass die Techniken von 1.4 nun böse Magie wären.
Dann wurden wohl irgendwelche Kompatiblitätsklassen nachinstalliert, die sind jetzt zwar alle veraltet und sollen in Zukunft bitte nicht mehr verwendet werden, aber wenigstens läuft ältere Software auf 1.5 dann wieder.1.1 auf 1.2: das war ein grosser Schritt. Das war aber noch in den "Anfangszeiten", da kann man ein paar Änderungen noch verzeihen (bei .NET ist ja 1 und 2 auch nicht 100% kompatibel).
1.4 auf 1.5: Auch da kam viel Neues hinzu (sogar syntaxmässig), und Altes wurde als "veraltet" deklariert.
Dass alte Software nicht mehr funktioniert, höre ich allerdings zu ersten mal.JBeni schrieb:
In Embedded Systems wird Java dann auf C++ kaputtgebrochen (Garbagecollection aus, Speicher anfordern und brav von Hand wieder freigeben).
Entweder alles oder nichts. Von solchen Dingen halte ich auch nicht viel. Wenn man den GC nicht nutzen will, soll man auch kein Java verwenden.
Ich zitiere Dich (s.o.) "Man kann auch ein Java-Progi so schreiben, dass es Speicher freigibt, ...". Wo es eben noch als Argument für Java galt, so sollte man es(Java/das Arguemnt) doch nicht nutzen, wenn's drauf ankommt!?
Siehe ebenfalls oben "Mit weniger drastischen Mitteln".
Wenn man sich auf Eigenheiten eines Systemes nicht einlassen will, sollte man lieber ein anderes nehmen, bevor man gefährlich tief im System Dinge abändert. Die Chancen, dass einem so ein verändertes System um die Ohren fliegt, würde ich als nicht allzu gering einschätzen.
Wie gesagt: Java ist auch kein Allheilmittel.Ich portiere die Algorithmen 1:1 in optimiertes C um. Eine nachträgliche Optimierung findet nicht mehr statt. Ich programmiere grundsätzlich optimiert, ich kenne die meisten Fallgruben und umgehe sie entsprechend. Bei der 1:1 Portierung verstehe ich den Algorithmus und seine Besonderheiten. Anschließend reiche ich - wenn mir passendes einfällt - eine Empfehlung ein, wie man den vorhandenen Algorithmus ersetzen könnte, gegen einen anderen, der aber identische Ergebnisse liefert. Wurde bisher noch nie umgesetzt, die 1:1 Portierungen waren bereits wesentlich schneller, als benötigt.
Da ich diese Algorithmen und den Quellcode nicht kenne (und auf die schnelle wohl auch nicht verstehen würde), gebe ich dazu keinen Kommentar ab.
Ich habe Java-Kenntnisse. Nachdem ich sie mir vor 3 oder 4 Jahren angeeignet habe, fand ich Vorzüge gegenüber C++, aber ich fand mehr, was ich C++ bevorzuge. Mir gefiel Java nicht. Trotzdem habe ich ein Projekt damit gemacht, denn wenn alle Java so toll finden und ich nicht, bin ich vermutlich der Depp und muss mal was richtiges mit Java schreiben. Mit dem Projekt wollte ich Erfahrung sammeln. Das habe ich.
Mir gefällt Eiffel nicht, obwohl alle Welt voll davon überzeugt zu sein scheint. Ok, ich verstehe was du meinst.
Seitdem habe ich kein Java mehr programmiert und meine Kenntnisse auch nicht mehr auf den aktuellen Stand gebracht.
Seit 1.5 wollte ich mich mal wieder auf den aktuellen Stand bringen, mir die generics usw mal ansehen, aber bisher fehlte die Zeit und die Notwendigkeit. Wo Java und C# in ihren aktuellen Versionen nun generics eingefügt haben, bemerke ich, dass generische Programmierung gute Chancen auf den nächsten Hype hat.
Generische Programmierung kennt C++ seit 1990, afair.Also die Kleinkinder-Generics von C# wollen wir mal nicht mit C++ oder Java vergleichen
Die Generics von Java sind anders als die C++-Templates. Die beiden Dinge haben zwar manchmal ähnliche Effekte, sehen syntaxmässig auch ziemlich ähnlich aus, im Detail finde ich sie aber schlecht vergleichbar. Schau es dir am besten selbst mal an...
Zum Hype: eindeutig. Die Generics hätten seit Java 1.0 in der Sprache sein sollen, aber man wollte die Sprache ja einfach halten. Manchmal wars leider zu einfach.Inzwischen bin ich da vorsichtiger geworden. Abstraktion ist für große Projekte unverzichtbar, aber man sollte den Kontakt zum Grund nicht verlieren.
Jop. Aber man muss sich ja auch nicht an ihm festketten
Wenn's dann darum geht Lösungen zu produzieren, lande ich häufig wieder bei C++ bzw. C#. Beide Sprachen erlauben ein hohes Maß an Abstraktion, C++ steht aber mit allen Bits auf'm Grund und bei C# gibt's zumindest eine Lucke mit "unsafe", wenn man doch mal an die Basis muss.
Kann auch daran liegen, dass ich bisher selten Probleme lösen musste, die sich von einer abstrakten Basisklasse ableiten lassen.Übungssache. Wenn ich ein komplexes Problem lösen will, lande ich meist bei Java. Da kann ich genügend Abstraktion einführen um das Problem in Einzelteile zu zerlegen.
Und ich arbeite seit 2003 dran. Ich schreibe mir Konzeptfehler auf und Konzepte, die ich beim Programmieren in diversen Sprachen vermisse, entwickle sie und probiere sie in meinem Compiler aus. Teste, wie sich vorhandene Konzepte abstrahieren lassen, wie sich neue Konzepte in die Sprache einfügen, wie sie sich anfühlen, ob sie intuitiv verständlich sind. Ich habe 2003 bei C++ angefangen, wollte zuerst eine kompatible Erweiterung zu C++ und habe dabei erkannt, dass sich die C++ Syntax so nicht halten läßt, wenn man Konzeptfehler korrigieren möchte.
Interessant. Gibts darüber mehr zu lesen? Ich bastle mir gerade eine Scriptsprache zusammen und gucke jede Idee gerne an.
Bjarne Stroustrup hat viele Entscheidungen, aber auch Fehler in C++ in seinem Buch 'Design und Entwicklung von C++' beschrieben. Bei Java weiß ich nicht, ob Stroustrup seine Erfahrungen da schon so offen berichtet hat.
Hab nichts gehört, hab aber auch nicht aktiv danach gesucht. Kritiken von Java gibt es aber genügend (leider in 99% aller Fälle von Möchtegernexperten
)Meine Programmiersprachensuppe besteht aus verschiedenen Basic-Dialekten, Assembler auf verschiedenen Prozessoren, C#, (Objective) Pascal, JavaScript, Prolog, PHP, SQL.
Dazu kommt ein klein wenig Lisp, was Perl, Rebol, Python und Rexx oder ein Hauch Fortran und andere heutzutage eher exotische Sprachen. Ich habe '86 angefangen zu programmieren und schaue mich regelmäßig um. Ruby soll auch nicht verkehrt sein.
Bisher sehe ich allerdings leider(!) keine bedeutende Alternative zu C++. Java hat's versucht, Java hatte Chancen, aber in meinen Augen reicht es nicht.Haskell kann ich dir noch empfehlen. Wie Prolog, nur besser. Ich vermisse da nur einige Libraries, aber wenig Benutzer -> wenig Libraries -> wenig Benutzer ...
Man benötigt irgendeine hardwarenahe Sprache (wie soll man sonst z.B. Treiber schreiben?). C++ wird nur schon deswegen nicht so schnell aussterben.
Wenn es um normale Desktopanwendungen geht, bleibt Java für mich erste Wahl. Die Libraries sind gut, die Entwicklung schnell, die Fehlermeldungen aussagekräftig und die Geschwindigkeit zur Laufzeit hoch. Bei Pt. 2 und 3 hält C++ nicht immer mit.
Für Anwendungen die in irgendwelchen Grenzbereichen arbeiten, gibt es keine allgemeingültige Aussagen.
-
Java hin, Java her...
Ich finde wer ernsthaft Programmieren will (und dazu gehören auch die Kenntnisse über die Hardware, und wie bestimmte Sachen im Rechner nunmal vorsich gehen) sollte erst C++ (C) lernen und dann umsteigen (oder bei bleiben). Auserdem ist der Weg von C auf Java leichter, als andersrum.
Meine Meinung, nix gegen die Java-Jungs.Und in Sachen Effizienz stellt C++, Java in den Schatten.
http://verify.stanford.edu/uli/java_cpp.htmlgrüße
P.S. Java ist wie automatik fahren
-
Cyriz schrieb:
Und in Sachen Effizienz stellt C++, Java in den Schatten.
http://verify.stanford.edu/uli/java_cpp.htmlMal ganz davon abgesehen, dass der Test alleine nicht unbedingt so toll ist um die Performance von Java und C++ zu vergleichen hat die JVM sich in den letzten Jahren weiterentwickelt.
Aber ich mag Java trotzdem nicht
.
