Programmiersprachen

[SirRethcir]

Interpretersprachen sind prinzipbedingt langsamer als Sprachen, welche Maschinencode erzeugen. Jeder der anders behaupten hat das Prinzip dahinter nicht verstanden.

Und hier kommen 'Just-in-time-Kompilier' zum Zuge.
Wikipedia
Interessanter Satz: "Hochentwickelte JIT-Compiler können speziell für dynamische Sprachen schnelleren Code als herkömmliche Compiler generieren, da sie Closed-World-Annahmen treffen können und Dynamische Optimierungen durchführen."

Was willst du eigentlich erreichen?
Kannst ja auch gleich Assembler programmieren, um ganz sicher zu gehen, daß alles optimal abläuft. Will man das wirklich?
Und wer würde dann wirklich 'optimal' programmieren? Soll doch der Compiler den Unsinn machen. Den haben Leute entwicklet, die sich besser damit auskennen und alle profitieren davon.
Wenn es wirklich um jedes Bit und um jede Millisekunde geht, kann man ja sowas machen, aber man entwickelt auf dieser Ebene keine Anwendungsprogramme. Interessant dabei ist aber das Java auch für den Einsatz in Küchengeräten (Wasch-, Geschirspülmaschienen usw.) entwickelt wurde.

Der Grund warum in der Lehre Java eingesetzt wird, ist ja, daß man lernt ordentlich OO zu programmieren, da man weniger Unsinn machen kann, weil man weniger (unnötige?) Freiheiten hat als in C++. Und das automatische Speichermanagment ist sicher auch ein Grund dafür.
Meines Wissens nach, kann man ein Java-Programm auch für eine Plattform compilieren, insofern würde dein Hauptargument wegfallen.
Bleibt also kein Grund warum ich einen Programmier-Einsteiger raten sollte mit C++ anzufangen. Wer ordentlich mit Java programmieren kann, kann das Wissen dann leicht auf C++ übertragen und hoffentlich dort der Versuchung widerstehen 'dirty hacks' zu benutzen, weil es mal schnell gehen soll.

[Netbandit]

Und hier kommen 'Just-in-time-Kompilier' zum Zuge.
Wikipedia
Interessanter Satz: "Hochentwickelte JIT-Compiler können speziell für dynamische Sprachen schnelleren Code als herkömmliche Compiler generieren, da sie Closed-World-Annahmen treffen können und Dynamische Optimierungen durchführen."

Solche Sprüche stammen mit Sicherheit aus der Marketingabteilung von SUN und ich halte so etwas für ein Gerücht. Man muss sich doch mal überlegen, welcher Overhead durch das JIT Kompelieren zur Laufzeit entsteht. Wenn man ein komplexes Programm mit einem guten C/C++ Compiler übersetzt, kann dies durchaus mehrere Minuten/Stunden in Anspruch nehmen. Der JIT-Compiler soll es nun also schaffen einen Interpretercode zur Laufzeit zu übersetzten, zu optimieren, an den Prozessor zu schicken und dann auch noch schneller laufen zu lassen? Anschließend wird der erzeugte Maschinencode auch noch gespeichert (für den nächsten Durchlauf dieses Codeteiles) und wenn es mal wieder so weit ist, muss auch noch ein Vergleich stattfinden, ob die Optimierungsvoraussetzungen (dynamische Optimierung) überhaupt noch zutreffen.

Sicher wird es Extremfälle geben, in denen durch dynamische Optimierung ein Geschwindigkeits-Netto gegenüber nativ übersetzten Code entsteht. Aber das sind dann Sonderfälle, wo zum Beispiel der JIT-C erkennt, dass anstatt 1000 Schleifendurchläufen nur 10 nötig sind.

Selbst in gängiger Java-Literatur wird daher eher gesagt, dass man mit JIT-Compilern annähernd die Geschwindigkeit von nativ übersetzten Programmen erreichen kann. Dafür hat man aber in jedem Fall ein Overhead an Speicher und mindestens einen weiteren Prozess der zur Laufzeit das System belastet.

Was willst du eigentlich erreichen?

Ich habe hier nur auf die Äußerung reagiert, dass Script- und Interpretersprachen nicht langsamer sind als native Sprachen. Es gibt auf jeden Fall Anwendungszwecke für solche Sprachen, auch ich verwende auf Linuxsystem sehr gerne Perl und Scripte meine Webseiten in PHP. Doch der Trend, immer mehr normale Anwendungsprogramme durch solche Sprachen zu erschaffen geht mir als Anwender gehörig gegen den Strich! Was nutzen mir immer schnellere Rechner und immer mehr Speicher, wenn die Programme durch solche Programmiertechniken immer ineffizienter werden?
Civ4 und Col2 sind nicht die einzigen Programme wo solche Programmiertechniken zu deutlichen Performanceeinbußen, auch bei sehr schnellen Rechnern, führen. Immer mehr Programme, die ich täglich in der lehre und später im Berufsleben anwende leiden an dieser Seuche. Ich bin kürzlich von Matlab 5 auf Matlab 7 umgestiegen und kann nun jedes mal hautnah Performanceeinbußen erleben.. Wofür? Dafür dass ich Matlab, ohne andere Bineries zu benutzen, auch auf Linux starten kann? Na vielen Dank, dafür darf ich nun bei jeder Scriptausführung und bei jedem Start von Matlab länger warten.

Kannst ja auch gleich Assembler programmieren, um ganz sicher zu gehen, daß alles optimal abläuft. Will man das wirklich?

Ich bin davon überzeugt, dass gute Compiler im Schnitt besseren Maschinencode erzeugen können als ein durchschnittlicher Assembler-Programmierer. Zu DOS-Zeiten lag der Vorteil in Assembler darin, dass man sehr schnell un direkt auf die Hardware zugreifen konnte. Dafür musste der Code für jede neue Grafikkarte/Soundkarte angepasst werden. Heute geschehen Hardwarezugriffe zu 95% nur noch über Betriebssystemaufrufe, was unter Umständen sogar für das Multi-Tasking notwendig ist (alle nicht NT Windowssysteme). So gesehen ist heutzutage ja nicht einmal dieser Vorteil der Assemblerprogrammierung geblieben (den man sich ja sowieso mit einem Haufen Nachteilen eingekauft hat).

Und wer würde dann wirklich 'optimal' programmieren? Soll doch der Compiler den Unsinn machen. Den haben Leute entwicklet, die sich besser damit auskennen und alle profitieren davon.
Wenn es wirklich um jedes Bit und um jede Millisekunde geht, kann man ja sowas machen, aber man entwickelt auf dieser Ebene keine Anwendungsprogramme. Interessant dabei ist aber das Java auch für den Einsatz in Küchengeräten (Wasch-, Geschirspülmaschienen usw.) entwickelt wurde.

Mir geht es hier nicht um jede Millisekunde, sondern um merkbare Performanceunterschiede. Wie gesagt: Das wozu in Col2 ein Phytonscript Minuten (!!) benötigt, macht die nativ übersetzte Engine von Col2 jede Runde innerhalb von (Milli-)Sekunden.
Auch hier geht es darum, zu entscheiden, wo Performance gebraucht wird. Habe ich ein Programm, was 80% der Zeit auf Anwendereingaben warten, dann muss das Berechnen von Werten zwischen zwei Eingaben nicht unbedingt in Windeseile geschehen. Dafür erwarte ich dann ein flottes Reagieren auf die entsprechende Eingabe das Anwenders. Im Übrigen ein Gebiet wo Java ebenfalls schon immer ein paar Problemchen hatte (die zugegebener Maßen inzwischen relativ in den Griff bekommen wurden).

Der Grund warum in der Lehre Java eingesetzt wird, ist ja, daß man lernt ordentlich OO zu programmieren, da man weniger Unsinn machen kann, weil man weniger (unnötige?) Freiheiten hat als in C++. Und das automatische Speichermanagment ist sicher auch ein Grund dafür.

Ich persönlich halte es für didaktisch sinnvoller sauberes Programmieren zu lernen, auch wenn man alle Freiheiten der Welt hat. Ich bin davon überzeugt, dass es zur "Grundausbildung" eines jeden Programmierers gehören sollte einmal ein größeres Projekt in Assembler realisiert zu haben. Erst dann weiß man, wie wichtig es ist strukturiert zu programmieren, Unterprogramme zu nutzen und eine saubere Dokumentation anzufertigen.

Ich habe auch erst durch das Programmieren mit C gelernt, wie wertvoll OOP sein kann, wie schön es ist, wenn man Operatoren überladen kann und wie bequem es ist, wenn man Probleme von einer Klassenmethode einfach zur nächsten weiter reicht. Dies ist eine wichtige Erkenntnis, die ich erst machen musste, denn ich gehöre definitiv nicht zu den Leuten, die alles sofort bereitwillig glauben und aufnehmen, nur weil es neu ist oder ein Professor erzählt. Ich muss meine eigenen Erfahrungen machen und lerne durch den Vergleich.

Java auf µC Ebene ist wohl der größte Frevel den ich mir vorstellen kann. Nicht nur, dass diese 12 MHz, 8Bit-Systeme von vorneherein schon nicht mit Performance protzen, nein die hier notwendigen Programme sind im höchsten Maße von von der Außenbeschaltung der Hardware abhängig. Daher kann Java hier nicht einmal seinen größten Trumpf ausspielen: Hardwareunabhängigkeit. Denn bei der nächsten Produktionsserie des Kaffeeautomaten ist die rote LED nicht mehr auf Port X, Pin1 sondern auf Port Y, Pin 3. Das nächste verwendete LCD-Modul hat keinen Treiberchip vom Typ A sondern einen von Typ B. Man müsste also für jede noch so kleine Veränderung an der Hardware einen neuen Javainterpreter einsetzen. Da die Außenbeschaltung von µCs und die verwendete Hardware nicht solch strengen Standards unterliegt wie die Hardware von PCs, ist hier eine ungeahnte Variabilität vorhanden, so dass ich hier keine Möglichkeit sehe mit Java hardwareunabhängig zu bleiben. Mal ehrlich, das Programm für einen Kaffeeautomaten möchte ich auch gar nicht auf meiner Waschmaschine abspielen, selbst wenn (oder vielleicht gerade wenn) dort ein Java arbeitet

Darüber hinaus muss man sich auch überlegen, ob es sinn macht die steigende Performanche solcher Chips sofort wieder durch neuen Programmoverhead wieder aufzufressen. Gerade 8Bit-µCs können sehr energiesparend programmiert werden, wenn man sie bewusst mit geringerer Taktfrequenz laufen lässt. Nebenbei kann man sich durch einen niedrigen Takt auch ne Menge Ärger mit der EMV ersparen. Wer hier sauber programmiert, kann in C nahezu hardwareunabhängig bleiben. Im Notfall muss dann nur noch eine Datei auf die neue Hardware angepasst werden, in der ein paar Defines drin stehen.

Hier sehe ich für C++ eine große Zukunft. Durch die bessere Modularisierung mit Hilfe von Klassen wird es hier sehr gut möglich sein, Programme für µCs zu entwickeln, welche absolut keinen Bezug zur Hardware mehr haben. Die komplette Hardware kann in Klassen abgebildet werden, welche jederzeit austauschbar sind. Zudem erlaubt C++ auch einen besser lesbaren Code, was gerade im Vergleich zu manch kryptischen µC-C Code sehr vorteilhaft sein dürfte. Wenn man gewisse Regeln einhält, kann ein moderner C++ Compiler das ganze in ein Maschinenprogramm übersetzen, welches sich bezüglich der Performance kaum vor einem C Programm verstecken muss, aber durch saubere Programmiermethoden ist die Wiederverwendbarkeit des Codes mit Sicherheit höher.

Meines Wissens nach, kann man ein Java-Programm auch für eine Plattform compilieren, insofern würde dein Hauptargument wegfallen.

Leider fällt damit auch der Hauptvorteil von Java weg
Langsamer als C++ Programme wird es dennoch sein, da Java-Programme viele zusätzliche "Überprüfungen" zur Laufzeit durchführt, welche ja auch bei einem statisch kompilierten Programm eingearbeitet werden müssen. So wird, bei einem Array-Zugriff auf Bereichsüberschreitung geprüft. Was bei C/C++ Programmen nicht der Fall ist, es sei denn man implementiert dies explizit). Allerdings gebe ich zu, dass solche Überprüfungen in der Regel sehr sinnvoll sind und sich der dadurch leicht geringe Verlust an Performance sehr schnell durch eine höhere Laufsicherheit des Programmes auszahlt. Hier sehe ich also in der Summe ein eher Gewinn als ein Verlust.

Bleibt also kein Grund warum ich einen Programmier-Einsteiger raten sollte mit C++ anzufangen. Wer ordentlich mit Java programmieren kann, kann das Wissen dann leicht auf C++ übertragen und hoffentlich dort der Versuchung widerstehen 'dirty hacks' zu benutzen, weil es mal schnell gehen soll.

Es kommt eben drauf an, was man als 'dirty hacks' bezeichnet. Java verzichtet ganz auf Pointer, was viele Probleme von hause aus schon einmal ausschließt. Jemand der mit C/C++ groß geworden ist, weiß jedoch dass Pointer ein wesentliches Programmiermittel dieser Sprachen sind und ein mächtiges Werkzeug darstellen. Allerdings weiß man dann auch, was für ein Mist damit passieren kann und man bekommt schon ein gewissen Gefühl für die damit verbundenen Gefahren. Ich erachte so etwas als Vorteil gegenüber Programmierern, die Pointer nur aus den Schauermärchen ihrer Professoren kennen
In C++ ist es dank Kapselung sehr gut möglich, viele dieser Probleme im Zusammenhang mit Pointern zu vermeiden. Zum Beispiel kann man Array-Klassen erzeugen, welche die Bereichsüberprüfung (so wie bei Java) schon implementiert haben (Normalerweise stehen dafür auch Standardklassen zur Verfügung). Dies alles erkauft man sich jedoch immer mit Performanceverlust. Solange man diesen in Kauf nehmen kann (32bit und 64bit Rechensysteme) ist das kein Problem. In Einzelfällen kann der Verzicht auf so etwas und das Vertrauen in eine korrekte Programmierung ein wertvolles Mittel zum Erreichen des Zieles sein.

Am Ende stehe ich wieder bei meiner Kernaussage: Es kommt darauf an was man machen will. Manchmal kann man mit einer Programmiersprache auch Probleme lösen die man mit einer anderen Programmiersprache besser lösen könnte. Hier muss man halt sehen ob der Gewinn größer ist als der Verlust.

Assembler auf low-cost µC Ebene:
Assembler auf PC Ebene:
Java für Internet-Templates und kleine Handyprogramme:
Java für komplexe PC-Anwendungen:
C für komplexe µC programme:
C für komplexe Anwendungsprogramme:
C++ für komplexe Anwendungsprogramme:
C++ als Ersatz für Kommandozeilen-Scripte:
Scripte für die Kommandozeilenadministration:
Scripte für die Bedienoberflächte von Colonization:

[Dill]

Wenn man hier bei Col2 auf einen Beraterbildschirm klickt, dann wird in Phyton innerhalb einer Schleife die Abfrage für die Werte einer Stadt an die C++ Engine geschickt. Die Engine guckt dann in der eigenen Datenstruktur nach und holt die Werte um sie anschließend an den Phytoninterpreter weiterzuleiten. Dieser stellt diese Werte dann innerhalb von Variablen im Script zur Verfügung. Danach bearbeitet das Phytonscript die Daten und zeigt sie entsprechend formatiert an. Bevor die Schliefe zu Ende ist und somit die vollständige Anzeige erscheint können auf meinem Rechner im fortgeschrittenen Spiel Minuten (!!!) vergehen.

aber woran liegts?
1. an python, das genrell arschlahm ist
2. an einem speicherleck oä in der engine
3. an unfähigen programmierern. das wäre mein tipp. ich habe mal ne zeitlang reviews von code der von outgesourceden codern aus indien zu uns kam gemacht. man glaubt nicht was es für code gibt.

ich fände es sehr interessant, wenn du den code von besagter schleife hier mal reinstellen könntest. python hat afaik ein nettes profiling modul, kannst ja evtl mal drauf ansetzen.

Die gleiche Menge an Daten muss die C++ Engine zu jeden Rundenbeginn abfragen und verändern um die Produktion zu berechnen. Dies schafft die Engine alleine innerhalb von (Milli-)Sekunden.
Das hier die Beraterbildschirme so träge sind liegt also nicht daran, dass sie schlecht programmiert wurden. Sondern einfach am Interpreter der für die gleiche Abfrage, für die die Engine Millisekunden braucht, mehrere Minuten benötigt.

damit implizierst du, dass python generell ca 10000mal langsamer ist als C.
das stimmt einfach nicht. im extremfall, bei algorithmen die viel schieben oder direkt befehle nutzen an die python nicht drankommt liegst du evtl bei faktor 1000. aber doch nicht bei ner desktopanwendung. da bist du maximal bei faktor 50, eher 2-10. und das darf einfach bei der problemstellung Civi4 nicht zu solchen problemen führen.

[Netbandit]

aber woran liegts?
1. an python, das genrell arschlahm ist
2. an einem speicherleck oä in der engine
3. an unfähigen programmierern. das wäre mein tipp. ich habe mal ne zeitlang reviews von code der von outgesourceden codern aus indien zu uns kam gemacht. man glaubt nicht was es für code gibt.

ich fände es sehr interessant, wenn du den code von besagter schleife hier mal reinstellen könntest. python hat afaik ein nettes profiling modul, kannst ja evtl mal drauf ansetzen.

Es ist halt der nationale Beraterbildschirm, dort gibt es unzählige Schleifen, welche sich von der Engine die Informationen holen. Leider fehlt mir im Moment die Zeit der Sache nachzugehen und zu schauen, wo die unmöglich lange Abfrage entsteht. Das wäre etwas, was man sich eventuell für die nächsten Semesterferien vornehmen könnte... Vielleicht kann man das sogar irgendwie verbessern...

damit implizierst du, dass python generell ca 10000mal langsamer ist als C.
das stimmt einfach nicht. im extremfall, bei algorithmen die viel schieben oder direkt befehle nutzen an die python nicht drankommt liegst du evtl bei faktor 1000. aber doch nicht bei ner desktopanwendung. da bist du maximal bei faktor 50, eher 2-10. und das darf einfach bei der problemstellung Civi4 nicht zu solchen problemen führen.

Sicher ist die Sache mit dem Beraterbildschirm schon ein Extremfall. Ich benutze sie daher bei voran geschrittenen Spielen gar nicht mehr... Aber auch im Hauptbildschirm und Stadtbildschirm stellt sich eine gewisse Trägheit ein... die liegt nur Millisekundenbereich, das reicht aber oft schon, dass man davon genervt wird, wenn zum Beispiel bei einem sehr flüchtigen Klick ein Befehl nicht ausgeführt wird oder man zwischen zwei Befehlen immer eine kleine Wartezeit hat. Es fühlt sich an wie bei Javaprogrammen von vor 10 Jahren

Das es ein Problem mit einem Speicherleck gibt ist mir klar, aber die oben genannten Probleme treten auch direkt nach dem Neustart des Programmes auf... hinzu kommt eben noch die Trägheit der Engine an sich (ruckelnde Grafik etc.) nach einigen Runden Spielzeit. Dies scheint wohl direkt an der Engine zu liegen...

Das Problem ist, dass die Sache mit der Bedienträgheit anscheinend vielen Leuten gar nicht auffällt, bzw. diese es als normal hinnehmen. Diese leichte Trägheit der GUI gab es ja auch schon bei Civ4 Vanilla und trotzdem störte sich kaum jemand daran. Es gibt ja auch Leute die seit Jahren mit Javaprogrammen arbeiten bei denen ich deswegen verrückt werden würde. Vielleicht reagiert der eine empfindlicher darauf und dem anderen ist es egal...

Naja ich brauche das Gefühl direkte Kontrolle über die Bedienoberfläche eines Programmes zu haben. Solche Latenzzeiten geben mir aber immer das Gefühl, als ob der Computer erst nachdenken muss, ob er meinen Befehl überhaupt ausführen möchte. Ich werden dann innerlich unruhig und reagiere gereizt... für Programme, die man täglich zum arbeiten benötigt einfach ein KO-Kriterium. Mag sein, dass du da anders reagierst...

[Writing Bull]

Aber auch im Hauptbildschirm und Stadtbildschirm stellt sich eine gewisse Trägheit ein... die liegt nur Millisekundenbereich, das reicht aber oft schon, dass man davon genervt wird, wenn zum Beispiel bei einem sehr flüchtigen Klick ein Befehl nicht ausgeführt wird oder man zwischen zwei Befehlen immer eine kleine Wartezeit hat. ... hinzu kommt eben noch die Trägheit der Engine an sich (ruckelnde Grafik etc.) nach einigen Runden Spielzeit. Dies scheint wohl direkt an der Engine zu liegen... Diese leichte Trägheit der GUI gab es ja auch schon bei Civ4 Vanilla und trotzdem störte sich kaum jemand daran.

Ja, all das ist wirklich bei Col 2 zu beobachten - und schon zuvor bei Civ 4. Je länger das Spiel läuft und/oder je komplexer das Städte- und Einheitennetz ist, desto langsamer läuft vieles ab. Der Stadtbildschirm und die Berater-Übersichten öffnen sich z.B. mit Verzögerung. Nach meiner Erinnerung war das in der ungepatchten Civ-4-Vanilla-Version am schlimmsten. Irgendwann - durch Patches und AddOns - wurde das Problem nicht mehr ganz so arg. Bei Col 2 sind die Probleme am mildesten. Die Verzögerungen gibt's zwar immer noch, aber alles flutscht im Vergleich zu Civ 4 doch wesentlich besser.

Was ich sehr seltsam finde: Wenn ich das Spiel mit einem alten Spiel vom Desktop aus starte, geht das schneller, als wenn ich später aus einer laufenden Partie heraus dieses Save ein zweites Mal öffne. Dieser Effekt trat ebenfalls schon bei Civ 4 auf. Wenn ich dort während einer fortgeschrittenen Partie einen Spielstand laden möchte, schließe ich manchmal das Programm und lade das Save dann lieber bei einem erneuten Programmstart, weil ich weiß, dass das rascher geht.

Vielleicht kann mir jemand erklären, woran das liegt? Bitte bei freundlicher Berücksichtigung der Tatsache, dass ich Programmierlaie bin und Java immer noch für eine Insel halte ...

[SirRethcir]

@Netbandit
Wir betrachten die Problematik von verschieden Seiten.
Du siehst was möglich wäre, wenn man alle Möglichkeiten optimal nutzen würde. Nur muß auch jemand da sein der dies realisieren kann. Und hier liegt der springende Punkt. Es gibt diese Leute nicht in Massen und selbst diese machen genügend Fehler, weil sie Menschen sind. (Außerdem ist eine optimale Ausreizung der zur Verfügung stehenden Mittel mit Sicherheit teurer als eine 'normale' Lösung. - Kosten/Nutzen?)
Alle modernen Überlegungen zu Programmiersprachen und Softwarearchitektur resultieren ja aus der Erkenntnis, daß in der Vergangenheit zu viele Fehler gemacht wurden und zu viele Projekte scheiterten.
Und dies ist nun mein Blickwinkel. Lieber sicheres und sauberes Programmieren und ein bißchen Performance verlieren.
Und dies ist bei großen Projekten um so wichtiger. Warum du gerade in diesem Gebiet Java die Existenzberechtigung absprechen willst, kann ich nun gar nicht verstehen, da ja gerade bei großen Projekten die Java-Technologie(n) ihre Stärken ausspielt. Stichwort sei hierbei auch 'Verteilte Systeme'.

Was nun Civ4 betrifft:
Warum wurde eine Scriptsprache eingesetzt? Schon mal darüber nachgedacht?
-> Einfaches Ändern von vielen Teilen des ganzen Spieles.
Die Modder freut es und Firaxis konnte bei der Entwicklung von Civ4 schon früh Civ4 spielen und Änderungen ohne großes Aufheben vornehmen und schnell Sachen ausprobieren und auch wieder verwerfen.

PS: Und eigentlich bin ich der Meinung das der Performance-Einbruch im Endspiel eher vom Speicherleck herrührt.
EDIT: Writing Bulls Beobachtungen unterstützen diese These. Bei Col2 konnte ich dies sehr gut beobachten. Das Spiel wurde immer langsamer und ich schob es auch auf die Skripte, da Verschiebungen in Stadtbildschirmen 'unendlich' lange dauerten. Als dann das Bewegen der Einheiten auch immer länger dauerten dachte ich auch, daß eventuell zu viele Einheiten auf der Karte unterwegs sind. Aber alle diese Thesen wurden letztendlich dadurch widerlegt, daß nach einem Speichern des Spiels, Beenden und Neustarten von Col2 und dem Laden des zuvor gespeicherten Spielstandes, die genannten Probleme nicht mehr auftraten. Alles flutschte wie zu Beginn der Partie.

Gruß!

[Netbandit]

@Netbandit
Wir betrachten die Problematik von verschieden Seiten.
Du siehst was möglich wäre, wenn man alle Möglichkeiten optimal nutzen würde. Nur muß auch jemand da sein der dies realisieren kann. Und hier liegt der springende Punkt. Es gibt diese Leute nicht in Massen und selbst diese machen genügend Fehler, weil sie Menschen sind. (Außerdem ist eine optimale Ausreizung der zur Verfügung stehenden Mittel mit Sicherheit teurer als eine 'normale' Lösung. - Kosten/Nutzen?)
Alle modernen Überlegungen zu Programmiersprachen und Softwarearchitektur resultieren ja aus der Erkenntnis, daß in der Vergangenheit zu viele Fehler gemacht wurden und zu viele Projekte scheiterten.
Und dies ist nun mein Blickwinkel. Lieber sicheres und sauberes Programmieren und ein bißchen Performance verlieren.
Und dies ist bei großen Projekten um so wichtiger. Warum du gerade in diesem Gebiet Java die Existenzberechtigung absprechen willst, kann ich nun gar nicht verstehen, da ja gerade bei großen Projekten die Java-Technologie(n) ihre Stärken ausspielt. Stichwort sei hierbei auch 'Verteilte Systeme'.

Nun der einzige Vorteil von Javacode bezüglich der Sicherheit liegt darin, dass generell auf Programmierelemente verzichtet wurde, welche zwar sehr mächtig, dafür aber auch gefährlich sind. Logisch, da wo keine Pointer sind, da gibt es auch keine Probleme mit Pointern. Hier vertrete ich jedoch die Philosophie, dass man damit auch viele Möglichkeiten verschenkt.

Ich bin davon überzeugt, dass man auch in C++ sehr sicheren Code erzeugen kann. Zum Beispiel gibt es auch hier Klassen in denen Listen und Arrays gekapselt sind und über eine Prüfung auf Bereichsüberschreitung verfügen. Dies erzeugt etwas langsameren Code, aber das nicht nicht besonders tragisch, man gewinnt ja ne ganze Menge dabei. Aber in den 5% der Anwendungsfälle wo man doch lieber darauf verzichten möchte kann man das immer noch machen. Es wird also dem Programmierer überlassen ob er sauberen Code abliefert, er wird dabei unterstützt, aber nicht gezwungen.

das ist es was für mich eine Programmiersprache richtig mächtig macht: Alles ist erlaubt, alles ist möglich, nichts wird erzwungen. man kann in C++ vollständiges OOP betreiben, man kann aber auch vollständig darauf verzichten. Man kann in C++ ausschließlich mit virtuellen Methoden arbeiten (was gerade auf Kleinrechnern und µCs zu massiven Performanceeinbußen führen kann) man kann aber auch vollständig darauf verzichten und noch viel besser: Man kann von Methode zu Methode abwägen ob man das so machen möchte.

Mit genügend Sorgfalt und einer guten Struktur kann man in C++ auch sehr sicheren Code erzeugen. Nur weil eine Programmiersprache viele dieser Entscheidungen von vorne herein festlegt, wird sie nicht besser.
Aber das ist eine Philosophiefrage und auf modernen Rechnersystemen ist es völlig egal ob durch mehr Sicherheit 10% an Codeoverhead entsteht. Diese 10% sind in 99% der Falle gerechtfertigt und am Ende auch ein Gewinn für den Kunden 8den Anwender).

Das Problem an Java ist also nicht, dass es solche Einschränkungen besitzt, nein das ist mir als Nicht-Java-Programmierer auch völlig egal. Damit können sich die rumärgern (oder auch nicht) die jeden Tag damit programmieren. das Problem an Java ist, dass es keinen Maschinencode erzeugt. Denn das ist mir als Anwender nicht egal. Hier wird sinnlos Rechenpower verpulvert, das bringt für den Anwender 0 Vorteile. Wenn dafür das Programm dann über deutliche Bedienlatenzen verfügt ist es mir ich inakzeptabel.

Wie schon oben geschrieben, kommt es mir so vor, als ob ich diesbezüglich vielleicht sehr empfindlich bin. Vielleicht ist es wirklich so, dass viele Anwender dort keinen Unterschied bemerken. Ich behaupte von mir jedoch schon, dass ich Latenzen von 250ms deutlich merke. Und es stört mich massiv. Im Übrigen kann ich aus dem gleichen Grund auch nicht mit Touchscreens arbeiten, weil ich hier keine sinnliche Rückmeldung erhalte... es fehlt der Tastenanschlag...

Was nun Civ4 betrifft:
Warum wurde eine Scriptsprache eingesetzt? Schon mal darüber nachgedacht?
-> Einfaches Ändern von vielen Teilen des ganzen Spieles.
Die Modder freut es und Firaxis konnte bei der Entwicklung von Civ4 schon früh Civ4 spielen und Änderungen ohne großes Aufheben vornehmen und schnell Sachen ausprobieren und auch wieder verwerfen.

Ja eben, für die Moder und Programmierer ist das Phyton hier ein Segen. Aber zu welchen Preis? Ich als Spieler leide jede Sekunde des Spiels unter der höheren Reaktionszeit der GUI. Es kann doch nicht sein, dass nur weil es für die Programmierer bequemer ist es dem Kunden unbequemer gemacht wird.
"Äh ja die neuen ICEs haben kein gepolsterten Sitze mehr, weil diese schwieriger zu reinigen waren als Hartschalensitze...", na wo kommen wir denn da hin?

PS: Und eigentlich bin ich der Meinung das der Performance-Einbruch im Endspiel eher vom Speicherleck herrührt.
EDIT: Writing Bulls Beobachtungen unterstützen diese These. Bei Col2 konnte ich dies sehr gut beobachten. Das Spiel wurde immer langsamer und ich schob es auch auf die Skripte, da Verschiebungen in Stadtbildschirmen 'unendlich' lange dauerten. Als dann das Bewegen der Einheiten auch immer länger dauerten dachte ich auch, daß eventuell zu viele Einheiten auf der Karte unterwegs sind. Aber alle diese Thesen wurden letztendlich dadurch widerlegt, daß nach einem Speichern des Spiels, Beenden und Neustarten von Col2 und dem Laden des zuvor gespeicherten Spielstandes, die genannten Probleme nicht mehr auftraten. Alles flutschte wie zu Beginn der Partie.
Gruß!

Wir reden hier aneinander vorbei... das Speicherleck, was du beschreibst das kenne ich auch. nach wenigen Spielrunden fängt die Grafik an zu Ruckeln (die Wagenzüge fahren nicht mehr Gleichmäßig, die Engine läuft deutlich langsamer) und nach einem neustart des Programmes ist alles wieder ok. Das ist in der Tat ein Fehler der Engine.

Ich rede hier jedoch nicht von diesem Fehler sondern von der schlechten Reaktion der GUI. Die existiert auch, wenn ich das Spiel frisch gestartet habe... sie wird nur schlimmer wenn es viele Bedienobjekte gibt... also in großen Städten mit vielen Bürgern ist es schlimmer als in kleinen Städten mit wenig Bürgern. Dies kann kein Speicherleck sein, da es sonst in kleinen Städten genauso schlimm wäre, wenn man die kleine Stadt nach der großen Stadt besucht.

[SirRethcir]

Eigentlich liegen wir ja nicht so weit auseinander. Ich bin auch ein Fan von guter und gewissenhafter Programmierung. Allerdings reagiere ich auch allergisch, wenn man ein gutes Konzept bei der Programmierung verwässert, weil es anders schneller/einfacher geht.
Und ja natürlich kann man in C++ sauber und sicher programmieren und ja man kann in Java auch ein heilloses Durcheinander veranstalten, das ist ja auch gar nicht das Thema - für mich. Für dich?
Mir gefällt aber dein 'Fanatismus' nicht. Denn es liegt per se ja nicht an einer Programmiersprache, ob die mit ihr erstellten Programme gut sind. Desweiteren sind die zur Verfügung stehenden Bibliotheken zu einer Programmiersprache von immenser Bedeutung über Produktivität und Ergebnis der Programmierung. Und hier hat sicher C++ Vorteile gegenüber Java. (Muß aber nicht so bleiben.)

Also nochmal:

• Dein Problem mit Verzögerungen in der GUI hat primär nichts mit der Java-Programmiersprache oder der Java-Technologie zu tun.
• Eine VM ist sicher nicht so schnell, hat aber andere Vorteile und die Technologie wird sicher nicht aus einer Modererscheinung heraus eingesetzt, wie du es uns weiß machen willst. Desweiteren haben sich die JVMs sehr verbessert und der Abstand zu C++ Programmen hat sich deutlich verringert.
• Sollten Spiele mit Java programmiert werden? Nun sicher nicht solche, die den Anspruch haben die aktuelle Hardware bis aufs Letzte auszureißen. Ansonsten, warum nicht und für Hobbyprojekte sicher nicht die schlechteste Wahl. Das heißt natürlich nicht, daß C++ Könner auf Java umsteigen sollten.

Davon völlig unabhängig ist die Verwendung und Einbindung von Skriptsprachen in ein Programm. Darüber kann man natürlich streiten, dies hat aber gar nichts mit der Programmiersprache Java zu tun. Im übrigen gibt es auch explizit für die Einbindung in Java eine eigene Scriptsprache.

Über das Thema Scriptsprachen in Spielen können wir uns gerne unterhalten. Vor- und Nachteile. Moddabilität als Verkaufsargument usw.
Allerdings ist dies ein anderes Thema (siehe Threadtitel).
Die Vermischung beider Themen ist äußerst unglücklich.
Die Thematik C++ vs Java finde ich eher, ..., nun ja, ..., eigentlich interessiert es mich nicht wirklich und ich finde es etwas kindisch, weil - wie hier andeutungsweise zu sehen ist - die Fronten abgesteckt scheinen und sich keiner Bewegen will. Es gibt Vor- und Nachteile, bestimmte Rahmenbedingungen können eine Sprache bevorzugen.

Wenn ich in meinem Hobby-Projekt Java verwenden möchte und sei es nur, weil ich zu faul bin mich tiefer mit C++ zu beschäftigen, dann ist es eben so. Wenn ich meine Vorstellung mit Java realisieren kann, dann benutze ich Java. Wenn nicht, bin ich gern bereit mich tiefergehend mit C++ zu beschäftigen. Starrköpfigkeit finde ich hier fehl am Platze.

Und das soll es auch von meiner Seite zu diesem Thema (Java vs C++) gewesen sein. Einen Austausch über interessante Dinge (Bibliotheken, Frameworks, Engines usw.) beider Sprachen, würde ich allerdings durchaus positiv gegenüber stehen.

Gruß!

[Shakka]

Ich empfinde das Programmieren mit Java wesentlich angenehmer als mit C++. Und ich denke, man kann schon sagen, dass man mit Java schneller und zeiteffizienter als mit C++ programmieren kann.

Besonders unter Windows fühlen sich Java-Programme, besonders mit GUIs aus der Standardbibliothek schlechter an als durchschnittliche "native" Windowsprogramme.

Ob Java oder C++ schneller ist, liegt mittlerweile sehr an der Anwendung. Bei Spielen wie FreeCol dürfte es auf das letzte Bisschen Performance aber sicher nicht ankommen.

Und daher würde ich heute ein nichtkommerzielles Spiel nicht mit Java bauen. Entweder würde ich C++ nehmen oder wenn es auf Performance nicht ankommt Flash oder Python oder andere Mittel mit denen man schnell vorankommt.
Java sehe ich hier als weder Fisch noch Fleisch.

[bisonte]

Ich empfinde das Programmieren mit Java wesentlich
angenehmer als mit C++. Und ich denke, man kann schon sagen, dass man mit
Java schneller und zeiteffizienter als mit C++ programmieren kann.

Ist richtig. Die Umgebung nimmt einem auch ne Menge Arbeit ab. Wenn man sich nicht
um jeden Krams selbst kümmern muss (wie bei C z.B.), kommt man schneller zu einem Ergebnis.

Und vor allem sind OOP Sprachen im Kommen, da sie nicht ganz so fehleranfällig sind.
Da Kann der Programmierer auch mal einen etwas merkwürdigeren Weg nehmen,
ohne das einem gleich alles wegschmiert.

Das ist in meinen Augen auch der Grund für die wachsende Beliebtheit....

Und ich bin auch ein Fan von sauberem, Strukturiertem SourceCode...
das mit dem SpaghettiCode war zu Basiczeiten schon ein Greuel....,
obwohl das mit den Interpretersprachen auch wieder überhand nimmt.

[Shakka]

Und ich bin auch ein Fan von sauberem, Strukturiertem SourceCode...
das mit dem SpaghettiCode war zu Basiczeiten schon ein Greuel....,
obwohl das mit den Interpretersprachen auch wieder überhand nimmt.

Je schneller man mit einer Sprache zum Ziel kommen kann, desto häufiger wird der Code einfach nur unstrukturiert heruntergeschrieben.

[Polly]

Ich empfinde das Programmieren mit Java wesentlich angenehmer als mit C++. Und ich denke, man kann schon sagen, dass man mit Java schneller und zeiteffizienter als mit C++ programmieren kann.

Das kommt aber auch sehr auf die Art des Projekts an. Das Problem, mit dem Java am meisten zu kämpfen hat, ist meines Erachtens die im Vergleich zu C/C++ eher bescheidene 3rd Party Unterstützung. Während es für C++ Bibliotheken wie Sand am Meer gibt, muss man bei Java schon genauer hinschauen. Aber das kann man natürlich auch als Java-Vorteil sehen.

Grundsätzlich finde ich es aber müßig Java mit C++ vergleichen zu wollen. Beide Programmiersprachen sind für unterschiedliche Softwareprojekte entwickelt worden und innerhalb ihres Gebiets ohne Frage führend. Wer laufzeitkritische und speicherplatzkritische native Software braucht, greift sehr wahrscheinlich zu C++. Wer plattformunabhängige Software braucht, die möglichst schnell entwickelt werden soll und den Rechner nicht in die Knie zwingt, der greift eher zu Java.

Wenn man schon eine Ideologie-Debatte beginnen möchte, sollte man Java zumindest mit der MS-Sprache vergleichen, mit der es tatsächlich konkurriert: nämlich mit C#.

Als Software-Entwickler sollte man sowieso sowohl C++ wie auch Java/C# zumindest im Grundgerüst beherrschen und je nach Lage entscheiden.

[Netbandit]

Leider geht mir die zeit aus, hier weiter lange Texte zu schreiben daher gehe ich nicht mehr auf alle Argumente ein.

Ich bin nicht fanatisch... wie schon oft erwähnt stehe ich jeder Sprache und jedem Sprachkonzept offen gegenüber und denke, dass alle ihre Berechtigung haben. Es gibt gute Gründe Assembler einzusetzen und gute Gründe Java einzusetzen. Das ist doch genau das was ich die ganze Zeit hier predige.

Worüber wir hier ja diskutieren ist die Frage ob Java bei PC-Anwendungen Sinn macht. Hier gebe ich Shakka recht: Aus sich des Programmierers macht es Sinn, denn Java Programme lassen sich schon komfortabler und schneller entwickeln als C++ Programme.

Ich als Anwender habe eben sehr schlechte Erfahrung gemacht oder mache diese immer noch, dass viele diese Erfahrung nicht teilen deutet darauf hin, dass entweder meine PCs an denen ich gearbeitet habe irgendwie nicht in Ordnung waren oder ich diesbezüglich überempfindlich bin.

Das das Problem mit der Latenz nicht an der Java GUI liegt widerspricht halt diesen Erfahrungen... Heute erst wieder getestet: Matlab... Die Version 7 ist echt langsam. Starte ich das Programm mit der Option "-nojvm" hab ich zwar keine schöne GUI mehr, bin aber viel schneller mit Unterwegs.

Du sagst es ja selbst: Wenn man spiele programmiert die einen Computer eh schon stark auslasten muss man das nicht noch durch langsamere Technologie (zum Beispiel Scripte) verschlechtern. Colonization hat aber ein Performance Problem und zwar nicht erst nach X Runden. Selbst direkt nach dem Start ist die Col2 Engine einfach langsamer als beispielsweise die Civ3 Engine. Ich habe einen Rechner im oberen Leistungsmittel, also daran kann es nicht liegen...
Jetzt greif ich dein Argument auf und sage: Wenn die Col 2 Engine schon von Hause aus langsam ist, dann muss man das ja nicht auch noch durch den Einsatz von Scripten verschlechtern...

Da die Scripte eh nur die GUI berühren frage ich mich, ob wirklich so viele Modder dicke Tränen weinen würden, wenn es eine GUI.dll gäbe in der die Benutzeroberfläche per C++ programmiert wäre. Immerhin gibt es auch genügen Modder die die GameCoreDLL.dll ändern, daher würde hier das gleiche Konzept für die GUI dem Moddern keine Steine in den Weg werfen.
Aber klar: Die Entscheidung ist damals bei Firaxis so gefallen und wir als Anwender müssen damit leben. Firaxis hat es einfacher gehabt die GUI zu programmieren und wir müssen die Kosten dafür tragen. Dir ist es vielleicht egal, da du die Latenz beim Bedienen vielleicht gar nicht bemerkst oder überhaupt nicht als kritisch empfindest. Mir persönlich geht es da leider etwas anders.

Am Ende möchte ich noch einmal auf den Abschlussatz von Polly hinweisen, den ich absolut so unterstreichen kann. leider sieht die Realität heute anders aus: In ganzen Bereichen der Informatik bekommen die Studenten ihr ganzes Studium nichts mehr anderes als Java zu Gesicht. Das ist schade und wahrscheinlich auch einer der Gründe warum Java immer stärker eingesetzt wird.

[SirRethcir]

Ich als Anwender habe eben sehr schlechte Erfahrung gemacht oder mache diese immer noch, dass viele diese Erfahrung nicht teilen deutet darauf hin, dass entweder meine PCs an denen ich gearbeitet habe irgendwie nicht in Ordnung waren oder ich diesbezüglich überempfindlich bin.

Keine Ahnung. Entweder du überempfindlich, oder schlecht programmiert, oder eine ganz frühe Java-Version, oder alte JVM, hm, wer weiß.

Das das Problem mit der Latenz nicht an der Java GUI liegt widerspricht halt diesen Erfahrungen... Heute erst wieder getestet: Matlab... Die Version 7 ist echt langsam. Starte ich das Programm mit der Option "-nojvm" hab ich zwar keine schöne GUI mehr, bin aber viel schneller mit Unterwegs.

Und ich kann deine Erfahrungen nicht teilen.
Aber du machst mich neugierig. Was soll bei "-nojvm" passieren?

PS: Schon mal mit Eclipse rumhantiert? Treten diese Latenzen für dich dort auch auf?

[Netbandit]

Und ich kann deine Erfahrungen nicht teilen.
Aber du machst mich neugierig. Was soll bei "-nojvm" passieren?

Matlab startet ohne GUI, also nur als Kommandozeile. Die GUI brauch ich eh nicht, da ich nur Scripte ausführe oder schnell mal ein paar Matrizen in die Kommandozeile eingebe.

PS: Schon mal mit Eclipse rumhantiert? Treten diese Latenzen für dich dort auch auf?

Ja, allerdings 2006 (also schon etwas her) und unter KDE 3. Hat ca. 30 min auf meinem Rechner überlebt, das hatte Probleme mit dem Aktualisieren des Fensterinhaltes. Wie gesagt, ich war nicht schon immer so gegenüber Java eingestellt, hab halt viele schlechte Javaprogramme erlebt.

Hmm, was ich eigentlich noch sagen wollte: Ich habe tiefen Respekt vor Leuten die ihre Freizeit opfern um Open Source Projekte voran zu bringen. Selbst wenn die auf Java basieren Daher finde ich es auf jeden Fall gut, dass du an Freecol mitarbeitest und natürlich wünsche ich dir da auch viel Erfolg. Vielleicht schaffst du mit Freecol ein Programm, welches mich davon überzeugen kann, dass Java doch nicht so schlecht ist. Nämlich dann wenn die von mir genannten Kritikpunkte darauf nicht zutreffen.