Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 15 von 35

Thema: Programmiersprachen

  1. #1
    Registrierter Benutzer
    Registriert seit
    29.01.03
    Beiträge
    4.909
    Ich habe auf Wunsch hin diesen Thread gestartet und in ihm Posts aus 2 anderen Threads zusammengefügt, die dort nicht zu den Threadthemen passten. Die ersten 5 Posts dieses Threads sind Kopien aus dem Thread zu FreeCol. Die darauf folgenden 11 Posts stammen ursprünglich aus dem Thread zum Patchstand, ich habe sie dort "ausgeschnitten" und hier eingefügt.
    Writing Bull



    Nun, ich persönlich bin gegen Java, weil ich bis heute noch nie ein gut funktionierendes Javaprogramm gesehen habe. Zwar hat Java im Bereich des Look und Feel gewisse Fortschritte gemacht, aber man erkennt ein Javaprogramm dennoch sehr schnell an gewissen Unzulänglichkeiten.

    Das währen zum Beispiel die bei besonders hektischen Benutzeraktionen auftretende fehlerhafte Fensteraktualisierung. In vielen Editoren, welche auf Java basieren bleiben so Fragmente von Menüs oder ehemaligen Texten im Eingabebereich erhalten, bis genau diese Zeile durch z.B. scrollen aktualisiert wurde. Dann gibt es bei Javaprogrammen auch oft Probleme mit Tastenkombinationen die ansonsten nativ von Windows unterstützt werden, aber irgendwie nicht immer vom Java-Basierten Programmen. Darüber hinaus sind viele Javaprogramme eben etwas "träge" bzw. "zähflüssig" was die Bedienung angeht. Ich bin da sehr empfindlich, was diesen Punkt angeht. Wenn ich nicht das Gefühl habe, dass eine Aktion zeitnah mit meinem "Klick" durchgeführt wird, bekomme ich irgendwie ein schlechtes Gefühl bei der Bedienung. Im Übrigen hat die Phyton-Oberfläche von Civ4/Col2 genau das gleiche Problem, allerdings bei fortgeschrittenen Spielen noch viel stärker als bei gängigen Javaprogrammen.

    Das Problem von Java ist einfach das Interpreterkonzept. Programme, die interpretiert werden können prinzipiell nicht so schnell laufen wie nativ-compilierte Programme. Der große Vorteil von Java liegt in einer kürzeren Entwicklungszeit für den Programmierer als Beispielweise bei C++, und dass plattformunabhängiges Programmieren mit Java besonders einfach wird. Den Nachteil, des mangelnden Look and Feel von Javaprogrammen muss halt der kritische User ausbaden und daher verzichte ich, soweit es mir möglich ist, auf den Gebrauch von Javaprogrammen.

    Wie gesagt, ich möchte hier auf keinen Fall die Leistung von den Programmierern von FreeCol herunterreden. Ein Programm in Java zu entwickeln ist genauso anspruchsvoll wie in C/C++. Java entwickelt sich allerdings zunehmen (besonders im Bereich der Wirtschaftsinformatik) zu DER Programmiersprache schlechthin, was ich als Benutzer aus den oben genannten Gründen sehr kritisch sehe. Leider ist MS ebenfalls mit .net auf diese Schiene aufgesprungen und der Marktanteil von Programmen die interpretiert anstatt compiliert werden, wird leider Gottes weiter steigen.
    Geändert von Writing Bull (02. Dezember 2008 um 19:33 Uhr)

  2. #2
    Registrierter Benutzer Avatar von SirRethcir
    Registriert seit
    18.11.05
    Beiträge
    460
    Zitat Zitat von Netbandit Beitrag anzeigen
    Das währen zum Beispiel die bei besonders hektischen Benutzeraktionen auftretende fehlerhafte Fensteraktualisierung. In vielen Editoren, welche auf Java basieren bleiben so Fragmente von Menüs oder ehemaligen Texten im Eingabebereich erhalten, bis genau diese Zeile durch z.B. scrollen aktualisiert wurde.
    Würde mich mal interessieren, wo du das gesehen hast.
    Allgemein gesagt ist dies ein Problem der GUI-Komponente und hat ja per se erstmal nichts mit der Programmiersprache zu tun. Möglicherweise tritt dieses Verhalten auch nur unter Microsoft-BS auf, dann wissen wir ja wer dran Schuld ist.

    Zitat Zitat von Netbandit Beitrag anzeigen
    Dann gibt es bei Javaprogrammen auch oft Probleme mit Tastenkombinationen die ansonsten nativ von Windows unterstützt werden, aber irgendwie nicht immer vom Java-Basierten Programmen.
    Ist eben kein Microsoft. Ansonsten den GUI-Komponenten Programmierer ansprechen.

    Zitat Zitat von Netbandit Beitrag anzeigen
    Das Problem von Java ist einfach das Interpreterkonzept. Programme, die interpretiert werden können prinzipiell nicht so schnell laufen wie nativ-compilierte Programme.
    Hm, mag sein, aber nur solange der Prozessor den Bytecode nicht nativ unterstützt.

    Zitat Zitat von Netbandit Beitrag anzeigen
    Der große Vorteil von Java liegt in einer kürzeren Entwicklungszeit für den Programmierer als Beispielweise bei C++, und dass plattformunabhängiges Programmieren mit Java besonders einfach wird.
    Warum die Entwicklungszeit kürzer sein soll weiß ich nicht. Der Vorteil ist die Plattformunabhängigkeit und die strikte Konzentration auf die Objektorientierte Prgrammierung.

    Zitat Zitat von Netbandit Beitrag anzeigen
    Den Nachteil, des mangelnden Look and Feel von Javaprogrammen muss halt der kritische User ausbaden und daher verzichte ich, soweit es mir möglich ist, auf den Gebrauch von Javaprogrammen.
    Hier gebrauchst du Look&Feel in einem anderen Zusammenhang als angedacht. Look&Feel beschreibt die Art und Weise wie sich eine Benutzeroberfläche verhält. Z.B. das Look&Feel von Microsoft XP, von Linux (hier gibt's ja zahlreiche GUI-Versionen) oder von MAC-Computern.

    Zitat Zitat von Netbandit Beitrag anzeigen
    Java entwickelt sich allerdings zunehmen (besonders im Bereich der Wirtschaftsinformatik) zu DER Programmiersprache schlechthin, was ich als Benutzer aus den oben genannten Gründen sehr kritisch sehe. Leider ist MS ebenfalls mit .net auf diese Schiene aufgesprungen und der Marktanteil von Programmen die interpretiert anstatt compiliert werden, wird leider Gottes weiter steigen.
    Zum Glück, sag ich da nur. So kann eine Firma viel leichter die Hardware erneuern. Es gibt ja viele Beispiele bei Firmen, wo noch Uralt-Rechner laufen, nur weil die alte Software auf anderen (neueren) Rechnern nicht läuft und eine Neuentwicklung der Software wäre sehr teuer.

  3. #3
    Kohlkönig Avatar von vadus
    Registriert seit
    24.08.01
    Ort
    Berlin
    Beiträge
    1.554
    Das Problem ist nicht die Programmiersprache sondern die Programmierung. Bei der Programmierung von Java Programmen wird in der Regel nicht viel auf Performance geachtet, weil es nicht der wichtigste Punkt in den Anforderungen ist. Trotzdem kann ich mit Java Desktopanwendungen schreiben, die C++ Programmen in Sachen Bedienbarkeit, zu der auch eine, für den User nicht unangenehm lang andauernde, Reaktionszeit zählt, in nichts nachstehen. Bestes Beispiel ist hier die Eclipse IDE. Ich finde bei der Bedienung keine Unterschiede zwischen Eclipse und Visual Studio.
    ... Earth!

    --- Civ5: Vadus World ---

  4. #4
    Registrierter Benutzer Avatar von SirRethcir
    Registriert seit
    18.11.05
    Beiträge
    460
    Zitat Zitat von vadus Beitrag anzeigen
    Trotzdem kann ich mit Java Desktopanwendungen schreiben, die C++ Programmen in Sachen Bedienbarkeit, zu der auch eine, für den User nicht unangenehm lang andauernde, Reaktionszeit zählt, in nichts nachstehen.
    Empfehlenswert unteranderem: Effective Java

  5. #5
    Registrierter Benutzer
    Registriert seit
    29.01.03
    Beiträge
    4.909
    Zitat Zitat von SirRethcir Beitrag anzeigen
    Würde mich mal interessieren, wo du das gesehen hast.
    Allgemein gesagt ist dies ein Problem der GUI-Komponente und hat ja per se erstmal nichts mit der Programmiersprache zu tun. Möglicherweise tritt dieses Verhalten auch nur unter Microsoft-BS auf, dann wissen wir ja wer dran Schuld ist.
    2006 habe ich das letzte mal bewusst und Java-Programm runtergeladen. Es war ein XML Editor, um für Civ4 was zu modifizieren. Hier waren die Probleme schon sehr krass. Leider ist es schon so lange her und ne Software die nur wenige Tage auf den Rechner war muss ich mir auch nicht merken
    Ähnliche Probleme hatte ich am Ende des selben Jahres mit Eclipse unter KDE 3. Ich suchte ne IDE für Perl und war sehr froh, dass Eclipse einen entsprechenden Port bot. Ich war ganz heiß auf diese IDE, da ich zuvor im Internet viel darüber gelesen hatte. Ich gebe zu, der Rechner war nicht besonders schnell aber die Zähflüssigkeit und Anzeigefehler von Eclipse waren ne Katastrophe. Die Software hat ca. eine Stunde auf meinem Rechner überlebt danach bin ich zum KDeveloper übergegangen, der zwar noch etwas unausgereift war, aber wenigstens konnte ich damit angenehm und flüssig arbeiten.

    Wie gesagt, wenn ein Programm träge reagiert, dann macht mich das auf dauer verrückt. Wenn es sich dabei noch um Arbeitsprogramme handeln, dann ist nicht mehr an ein vernünftiges Arbeiten zu denken.

    Zitat Zitat von SirRethcir Beitrag anzeigen
    Ist eben kein Microsoft. Ansonsten den GUI-Komponenten Programmierer ansprechen.
    Nun, ich als Anwender von Programmen interessiere mich reichlich wenig dafür, warum ein Programm nicht so funktioniert wie ich es erwarte. Wenn ein Programm meinen Erwartungen absolut nicht Gerecht werden kann fliegt es wieder von der Platte, egal wer daran Schuld ist. Überproportional sind in den letzten 10 Jahren bei mir Java-Programme von der Platte geflogen. Ich kann mir sehr gut vorstellen, dass es Anwender gibt, die da etwas toleranter sind als ich, die kein dumpfes Gefühl in der Magengegend bekommen, wenn ein Programm auf eine Benutzereingabe leicht verzögert reagiert oder hier und da der Bildschirmaufbau nicht korrekt aktualisiert wird. Vielleicht merken es diese Anwender nicht einmal... naja es gibt ja offensichtlich auch Programmierer die davon überzeugt sind, dass man mit dem vi effektiver Programmieren kann als mit einer ausgeklügelten IDE.

    Zitat Zitat von SirRethcir Beitrag anzeigen
    Hm, mag sein, aber nur solange der Prozessor den Bytecode nicht nativ unterstützt.
    Ursprüngliche Java-Programme kommen ja gar nicht auf diese Ebene. Die Javabefehle werden vorkompiliert also in eine Art Java-Maschinensprache übersetzt und dann interpretiert. Die Entscheidung ob und wie ein Java-Befehl an den Prozessor weiter gegeben werden muss, wird in jedem Fall vom Java-Interpreter getroffen und nicht vom Java-Programm selbst. Dies kostet Zeit, gegenüber einem Programm, welches direkt in Opcode für den entsprechenden Prozessor umgesetzt wird und wo nicht bei jedem Befehl oder jeder Befehlsgruppe ein anderes Programm (der Interpreter) den passenden Opcode erst bereitstellen muss.
    Dieser Umstand wurde ja auch von Sun selbst bemerkt und daher gibt es ja heute sogar Möglichkeiten Javaprogramme teilweise zu kompilieren um eben die Geschwindigkeit zu erhöhen. Doch damit geht dann auch der einzige große Vorteil von Java verloren: Die absolute Plattformunabhängigkeit.
    Aber auch mit diesem Konzept ist Java schlichtweg langsamer, weil es mehr Overhead produziert. Durch den Verzicht auf Zeiger kann man nicht direkt auf komplexe Speicherbereiche zugreifen. Der Zugriff Felder zum Beispiel findet in Java nur indirekt statt, was den Vorteil hat, dass man auch gleich eine Bereichsüberschreitung abfangen kann. Leider wird der dadurch entstehende Code nicht kürzer und benötigt mehr Zeit um ausgeführt zu werden.
    Es ist eben wie überall: Einen Tod muss mann sterben.

    Zitat Zitat von SirRethcir Beitrag anzeigen
    Warum die Entwicklungszeit kürzer sein soll weiß ich nicht. Der Vorteil ist die Plattformunabhängigkeit und die strikte Konzentration auf die Objektorientierte Prgrammierung.
    Du sagst es doch selbst: Die Konzentration auf totales OOP bewirkt durchaus eine Beschleunigung im Entwicklungsprozess. Teamarbeit und dezentrale Programmierung werden somit optimal gefördert. Bei C++ muss man sich ständig zusammen reißen alles strikt OO zu machen, da es ja auch die Möglichkeit der prozeduralen Programmierung gibt. Die entscheidenden Faktoren sind jedoch die Hardwareunabhängigkeit, die viel Entwicklungszeit einsparen kann und die Tatsache, dass völlig auf Zeiger verzichtet wurde, was die Entwicklung weniger Fehleranfällig macht.
    Ich würde mal behaupten, dass ein Großteil der Fehler bei C und C++ Programmen auf Zeiger zurückzuführen sind, welche im Wald stehen.

    Zitat Zitat von SirRethcir Beitrag anzeigen
    Hier gebrauchst du Look&Feel in einem anderen Zusammenhang als angedacht. Look&Feel beschreibt die Art und Weise wie sich eine Benutzeroberfläche verhält. Z.B. das Look&Feel von Microsoft XP, von Linux (hier gibt's ja zahlreiche GUI-Versionen) oder von MAC-Computern.
    Eben und genau das meine ich: Wenn sich ein Programm nicht ideal in das mir bekannte Look&Feel meines BS einfügt, also bestimmte Tastenkombinationen nicht funktionieren (die ansonsten betriebssystemweit unterstützt werden) oder eben die Anzeige nicht ganz zum Rest passt. Hier mal ein Beispiel:


    Diese GUI sieht nun einmal anders aus, als ich es von 99% meiner Software gewohnt bin. Das mag vielen vielleicht egal sein, ich störe mich an solchen Dingen. Es hindert mich am effektiven Arbeiten wenn sich Dinge nicht so verhalten wie erwartet oder anders aussehen als ich es gewohnt bin.

    Zitat Zitat von SirRethcir Beitrag anzeigen
    Zum Glück, sag ich da nur. So kann eine Firma viel leichter die Hardware erneuern. Es gibt ja viele Beispiele bei Firmen, wo noch Uralt-Rechner laufen, nur weil die alte Software auf anderen (neueren) Rechnern nicht läuft und eine Neuentwicklung der Software wäre sehr teuer.
    Es ist ein häufiger Fehler, dass man glaubt, dass Java die einzige Möglichkeit sei Plattformunabhängig zu programmieren. Es gibt Fällt, wo Java in der Tat große Vorteile hat und zwar dort wo der Entwickler definitiv nicht weiß auf welchen Systemen seine Software läuft. Also im Bereich von Internet-Applets oder bei Handyprogrammen. Bei PC Software ist das in der Regel anders. Hier weiß man auf welchen Systemen sein Programm zur Anwendung kommt z.B. auf Windows und Linux oder auf einem Mac. Es ist durchaus Möglich, mit C++ Programme plattformaunabhängig zu programmieren. Sie müssen nur noch für die entsprechende Plattform kompiliert werden. Was aber bei 3 möglichen Plattformen keine Hürde darstellt. Projekte wie Code::Blocks, OpenTTD, FreeCiv und viele mehr beweisen es.
    Der Unterschied ist halt: Es ist aufwendiger und verlangt mehr Disziplin ein C++ Programm zu erstellen, welches auf jeder der drei Plattformen ohne Anpassungen kompeliert werden kann. Der Gewinner ist aber in jedem Fall der User der nun eine sehr schnelle und schlanke Software besitzt. In Zeiten von Klimawandel und teurer Energie, sollte man es sich durchaus überlegen, ob man Rechenzeit und damit Energie für an sich überflüssige Programme wie einen Java-Interpreter ausgeben möchte.

    Ich gebe zu, Java ist halt eine Modesprache und wer heute in der Branche zu tun hat, kommt leider nicht mehr drum herum.

    Edit: Ich möchte hier im übrigen eigentlich keinen Krieg der Programmier/Scriptsprachen anführen. Ich denke, dass jede Sprache da ihre ganz eigenen Vorzüge hat und daher auch ihren eigenen Anwendungsbereich. Java sehe ich zum Beispiel ungeschlagen bei den Internetapplets, PHP und perl sind dafür die besten wenn es um dynamische Webseiten geht und bei großen Projekten, wo es auch auf Performance ankommt sehe ich persönlich C++ weit vorne. Es ist eben wichtig, dass man vor einem Projekt die Vor- und Nachteile richtig abwägt und dann konsequent mit der Sprache programmiert für die man sich entschieden hat. Diese Entscheidung ist meiner Meinung nach bei Col2 und Civ4 bezüglich dem Phytonscript Oberflächen eindeutig falsch ausgefallen und wir Spieler müssen nun darunter "leiden". Bei FreeCol ist diese Entscheidung ja auch irgendwann einmal getroffen worden und damals hat man sich vor Java entschieden. Was dazu geführt hat, ja keine Ahnung, aber nun ist es nun einmal so. Ob es die falsche Entscheidung war wird sich spätestens dann herausstellen, wenn in fortgeschrittenen Spielen mit viel Ki und Automatisierung auf der Karte auch viele Berechnungen gemacht werden müssen. Davon ist FreeCol ja im Moment noch ein Stück entfernt und die Zeit wird zeigen wer hier recht behält.

    Meine Sorge ist jedoch, dass in Zukunft weniger über solche Entscheidungen nachgedacht wird. Sprachen wie Java und C# haben nun einmal eine sehr geringe Einstiegsschwelle im Gegensatz zu C++ oder gar C. Viele Hobbyprogrammierer lernen halt nur noch diese Sprachen und sogar an Hochschulen gibt es Studiengänge wo nur noch solche Sprachen gelehrt werden. Dies wird in Zukunft immer mehr dazu führen, dass eine Entscheidung über die zu verwendende Programmiersprache nicht mehr danach gefällt wird, ob die Programmiersprache besonders gut zu den Anforderungen passt sondern eher ob das zur Verfügung stehende Personal damit schon Programmiererfahrungen hat.

  6. #6
    Registrierter Benutzer
    Registriert seit
    29.01.03
    Beiträge
    4.909

    Programmiersprachen

    Ab hier stammen die folgenden elf Posts aus dem Thread zum Patchstand, sie waren dort fehl am Platz und wurden von mir in diesen neuen Thread verschoben.
    Writing Bull


    Ich persönlich hoffe auch auf einen Patch, nicht wegen der Spielmechanik, die kann man sich ja notfalls zurechtmodden, sondern wegen den technischen Problemen.

    Wenn viel auf der Karte los ist (also bei fortgeschrittenen Spielen) wird das Game unglaublich zähflüssig und langsam.
    Ein Teil davon ist ganz klar konzeptioneller Art: Ich habe schon immer den Einsatz von Interpretersprachen (hier Phyton) für große Programme mit viel Berechnung und komplexer Datenstruktur abgelehnt. Civ4 und Col sind meiner Meinung nach sehr gute Beispiele, die mich dahingehend bestärken. Hier wird zwar die Programmierung und Wartung des Games einfacherer, die Kosten dafür trägt aber der Spieler in Form einer sehr zähflüssigen GUI bei fortgeschrittenen Spielen. Also darin kann sich nichts ändern, das wird hoffentlich bei Civ5 anders sein.

    Aber ein anderer Teil der Trägheit liegt wohl an einem Speicherleck. Wenn man für lange Zeit ein Spiel spielt wird immer träger. Speichert man es ab, beendet Col und startet man das Spiel neu läuft es wieder flüssiger. Das ist ein Fehler, den man sehr gut beseitigen kann und hier hoffe ich noch drauf.
    Geändert von Writing Bull (02. Dezember 2008 um 19:24 Uhr)

  7. #7
    Talking Bull Avatar von Writing Bull
    Registriert seit
    01.10.08
    Beiträge
    21.376
    Zitat Zitat von Netbandit Beitrag anzeigen
    Aber ein anderer Teil der Trägheit liegt wohl an einem Speicherleck. Wenn man für lange Zeit ein Spiel spielt wird immer träger. Speichert man es ab, beendet Col und startet man das Spiel neu läuft es wieder flüssiger. Das ist ein Fehler, den man sehr gut beseitigen kann und hier hoffe ich noch drauf.
    Genau diese Beobachtung hatte ich bereits bei Civ 4 gemacht. Col 2 hat die Engine von Civ 4 übernommen - und damit auch diese Schwäche im Programm. Obwohl das Problem den Entwicklern bekannt gewesen sein muss, haben sie es von Civ 4 nach Col 2 mitgeschleppt. Ich befürchte deshalb, dass ein Patch von Col 2 sich dieses Problems nicht annehmen wird - das hätte man ja schon früher erledigen können und hat es nicht getan.

  8. #8
    Registrierter Benutzer
    Registriert seit
    29.01.03
    Beiträge
    4.909
    Ach Mensch, ich wünschte Civ3 wäre so Modbar wie Civ4 und Col2, denn diese Engine läuft sehr stabil. Schönere Bitmaps und neue Spielelemente, für die kann Notfalls auch ein MOD sorgen.. die Engine von Col2/Civ4 kann man leider nicht umkrempeln

  9. #9
    Registrierter Benutzer
    Registriert seit
    11.04.02
    Beiträge
    34

    Programmiersprachen

    Zitat Zitat von Netbandit Beitrag anzeigen
    Ein Teil davon ist ganz klar konzeptioneller Art: Ich habe schon immer den Einsatz von Interpretersprachen (hier Phyton) für große Programme mit viel Berechnung und komplexer Datenstruktur abgelehnt.
    dass Civ4 so lahm ist liegt sicher nicht an python, sondern daran, dass es scheisse programmiert ist.

  10. #10
    Registrierter Benutzer Avatar von bisonte
    Registriert seit
    01.06.05
    Beiträge
    220
    Zitat Zitat von Dill Beitrag anzeigen
    dass Civ4 so lahm ist liegt sicher nicht an python, sondern daran, dass es scheisse programmiert ist.
    Fehler in der Struktur sind bei komplexen Sachen beinahe unvermeidbar.

    Vieles liegt aber auch am Betriebssystem (Windows z.B. ist ne echte Bremse),
    an der Hardware, und und und....

    Aber wie schon gesagt wurde... Interpretersprachen (Python,Java usw.) sind halt langsamer als die Compilersprachen (C, Asm usw.)

    Du redest in deiner Muttersprache mit Sicherheit auch schneller, als in einer Sprache, die Du später dazugelernt hast.
    Meine Projekte :
    Modmaker "Ghandi"
    ColonizationOne V1.6

    In Vorbereitung : NBMod_Extend

  11. #11
    Registrierter Benutzer
    Registriert seit
    11.04.02
    Beiträge
    34
    Aber wie schon gesagt wurde... Interpretersprachen (Python,Java usw.) sind halt langsamer als die Compilersprachen (C, Asm usw.)
    das mag ja sein. das ist aber nicht der grund dafür, dass civ4 langsam ist.
    man kann problemlos mit java oder python schnelle programme schreiben. und civ4 ist ja C++ mit ein paar python skripten. wenn die nicht extrem schlimm programmiert sind können die das system nicht ausbremsen (dann liegts aber auch nicht an der sprache sondern am coder)

    Vieles liegt aber auch am Betriebssystem (Windows z.B. ist ne echte Bremse), an der Hardware, und und und....
    das ist unsinn...

  12. #12
    Registrierter Benutzer Avatar von bisonte
    Registriert seit
    01.06.05
    Beiträge
    220
    Zitat Zitat von Dill Beitrag anzeigen
    man kann problemlos mit java oder python schnelle programme schreiben.
    Sicher... Wenn die Programme klein bleiben. An der Aussage kann ich sehen, das
    Du noch nicht viel damit zu tun hattest.

    Zitat Zitat von Dill Beitrag anzeigen
    das ist unsinn...
    Ich weiss wovon ich spreche... ist mein Job
    Geändert von bisonte (03. Dezember 2008 um 01:07 Uhr)
    Meine Projekte :
    Modmaker "Ghandi"
    ColonizationOne V1.6

    In Vorbereitung : NBMod_Extend

  13. #13
    Registrierter Benutzer
    Registriert seit
    11.04.02
    Beiträge
    34
    Ich weiss wovon ich spreche... ist mein Job
    na das heisst ja mal garnix

    was ist denn dein job, wenn ich fragen darf? scheinst ja interessante einblicke zu haben.

    achja, und:

    An der Aussage kann ich sehen, das
    Du noch nicht viel damit zu tun hattest.
    an der aussage kann man auch einiges sehen...

  14. #14
    Talking Bull Avatar von Writing Bull
    Registriert seit
    01.10.08
    Beiträge
    21.376
    @Dill und bisonte: Bitte regelt Euren Disput untereinander per PN (Persönlicher Nachricht). Oder trefft euch mit zwei Duellpistolen im Morgengrauen ...

    Aber bitte nicht hier in einem Thread, wo jeder, der hier reinklickt, hofft, Infos zu finden - und dann nur auf persönliche Sticheleien stößt.
    Geändert von Writing Bull (02. Dezember 2008 um 19:14 Uhr)

  15. #15
    Registrierter Benutzer
    Registriert seit
    29.01.03
    Beiträge
    4.909
    Zitat Zitat von Dill Beitrag anzeigen
    das mag ja sein. das ist aber nicht der grund dafür, dass civ4 langsam ist.
    man kann problemlos mit java oder python schnelle programme schreiben. und civ4 ist ja C++ mit ein paar python skripten. wenn die nicht extrem schlimm programmiert sind können die das system nicht ausbremsen (dann liegts aber auch nicht an der sprache sondern am coder)
    Also wenn ein C++ Programm langsamer ist als ein ein Scriptprogramm, dann sollte der Programmierer des C++ Programms sich mal überlegen, ob er den richtigen Job hat. Interpretersprachen sind prinzipbedingt langsamer als Sprachen, welche Maschinencode erzeugen. Jeder der anders behaupten hat das Prinzip dahinter nicht verstanden.

    Wenn ein Interpretercode erst durch ein anderes Programm ausgewertet werden muss, welches dann entscheidet, welcher Maschinencode oder welche Gruppe von Maschinencodes dem Interpretercode entsprechen, dann kann das niemals schneller sein, als wenn der Maschinencode direkt ausgeführt wird.

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

    Edit: Writing Bull: Lager doch diese Diskussion am besten in einen eigenen Thread aus

    Bin deinem Wunsch gefolgt.
    Writing Bull
    Geändert von Writing Bull (02. Dezember 2008 um 19:19 Uhr)

Seite 1 von 3 123 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •