Drucken

Bitte logg dich ein oder registriere dich.
1 Stunde 1 Tag 1 Woche 1 Monat Immer
Einloggen mit Benutzername, Passwort und Sitzungslänge

[Simia]

Hey, Du bist ein Mädchen! 

[K-Ninchen]

Hey, Du bist ein Mädchen! 

Okay, ich hab ja nix gesagt... *küche putzen geht*


...aber ich will echt wissen, was das mit dem R ist!

[Eisbär]

Mal ganz doof: Kann ein einzelnes Programm (ein Office Writer, ein Spiel oder so) eigentlich aus verschiedenen Sprachen geschrieben sein? So ein installiertes Programm besteht ja am Ende immer aus x Dateien. Verstehen die sich, wenn eine in Basic, eine in C++, eine in Java, eine in .NET etc.pp. geschrieben wurde?


Und ja, ich habe keine Ahnung von der Materie, finde es aber witzig der Diskussion zu folgen...

[PlumBum]

Mal ganz doof: Kann ein einzelnes Programm (ein Office Writer, ein Spiel oder so) eigentlich aus verschiedenen Sprachen geschrieben sein? So ein installiertes Programm besteht ja am Ende immer aus x Dateien. Verstehen die sich, wenn eine in Basic, eine in C++, eine in Java, eine in .NET etc.pp. geschrieben wurde?


Und ja, ich habe keine Ahnung von der Materie, finde es aber witzig der Diskussion zu folgen...

Um es kurz zu machen: Ja.

[Simia]

Egal. Jede Sprache hat halt ein geeignetes Einsatzgebiet. Da wo Javascript steht, wäre C eher unangebracht. Und gut, dass Windows-Anwendungen idr. nicht mit PHP programmiert werden. So hat eben alles seinen Platz.

Und es gibt Leute, die bedienen sich bei blöden Web-Landingpages (Logo, Überschrift, Text zum Anheizen und Kontaktformular) glatt richtiger Java-Applets. Auch FleXML für einfachste Websites, die nix können müssen, ist ... hmja. Nicht alles was geht, ist auch sinnvoll.

[TimuЯ]

Bei den größeren Spielen (und ich meine keine Flash- oder Browser-Spielchen) ist es sogar sehr sinnvoll, verschiedene Sprachen wegen ihren besonderen Stärken und Eigenschaften zu nutzen. Alles was Performance-kritisch ist, wird in der Sprache geschrieben, die am "schnellsten" bzw. performantesten läuft. Üblicherweise ist das dann C bzw. C++. Nachteil ist hier allerdings, dass die beiden schwer zu debuggen sind und am ehesten für Speicherlecks sorgen. In die Engine muss dabei auch die meiste Zeit investiert werden, damit alles nahezu perfekt läuft.

In dem Grafik-Part der Game-Engine braucht man wieder eine Sprache, die auf die Grafik-Hardware ausgelegt ist. Üblicherweise wird hier bei DirectX HLSL und bei OpenGL eine entsprechend ähnliche Sprache verwendet. Diese Programme, die dann nicht mehr von dem (Haupt-)Prozessor, sondern von dem Grafikprozessor ausgeführt werden können ("Shader") kümmern sich um die Berechnung von Licht, Schatten, Geometrie-Darstellung, Farben, Reflektionen usw. Sehr viel Vektorrechnung, auf die die Grafikprozessoren spezialisiert sind.

Wenn es dann um den Spielablauf geht, ist eine "mächtigere" Sprache eher von Vorteil, die einfach zu debuggen und die Programmierer sehr schnell alles Nötige beschreiben lässt, ohne dass sie sich groß um Performance und RAM Sorgen machen müssen. Hier werden Skriptsprachen eingesetzt, entweder Eigenentwicklungen, C# oder andere Sprachen. Wichtig ist halt, dass man den Überblick bei der gesamten Spielbeschreibung behält und der Code nicht in den ganzen "Features" der Charaktere einfach nicht mehr überschaubar wird. Klar, dafür kann man auch C / C++ nehmen, aber Skriptsprachen erleichern da schon das Coden um Einiges. Und man muss dann kein "Hardcore-Coder" sein, um eine kleine Änderung an einer bestimmten Stelle zu machen.

Dann hat so ein schönes Game auch noch einen Launcher, der kann in sehr verschiedenen Sprachen geschrieben sein, auch in Flash, er muss ja nur eine exe-Datei mit ein paar Parametern starten.

Dann kann so ein Game auch noch einen Level-Editor haben, der kann dann auch wieder in fast jeder beliebigen Sprache geschrieben sein. Hauptsache er liefert am Ende Daten, mit denen die Game-Engine etwas anfangen kann.


Das Prinzip von mehreren Sprachen kann man natürlich auch auf Web-Anwendungen übertragen, wie Simia und der Bleimann schon sagten. Eine serverseitige Web-Anwendung generiert sogar gegebenenfalls den Code einer anderen Sprache, die dann auf dem Client (Browser) zur Darstellung benutzt wird (PHP -> HTML/CSS ist da das einfachste Beispiel). Außerdem kann eine Server-Anwendung auch mit PHP und C# oder C++ geschrieben sein, je nachdem wo und wie Performance gebraucht wird (PHP ist u.U. eher etwas langam, um Serverdienste zu übernehmen, das wird dann an ein C++ / C#-Programm weiter gereicht.

Natürlich gibt es auch reihenweise eher sinnlose Fälle, wo mehrere Sprachen eingesetzt werden. Dann behindern sich die Programmteile gegenseitig und nichts läuft mehr wie es soll =)

[K-Ninchen]

Das ist sehr schön auf den Punkt gebracht

Mal ein Beispiel von geht-überhaupt-gar-nicht:

Wir haben damals (2000) Die www.diddl.de Seite programmiert mit WebOjects UND Objective C. Das hat Monate gedauert und wir mussten sogar externe Anheuern, die das schlecht bis gar nicht dokumentierte Framework kannten.
Und was konnte die Seite letztendlich? NIX! Unterseiten darstellen und irgendwo konnte man sich für irgendwas eintragen. Ha-ha.
Ein Fall von "Thermonukleare Atomwaffen auf Bakterien werfen", was zwar der Dimension nicht ganz gerecht wird (es ist eigentlich noch schlimmer), aber so hat man eine Idee.

Edit:
Und nein, mit der aktuellen Seite haben wir/ich nix mehr zu tun. Hm, lineare zickzack-Animationen... wer's mag...

[kb]

...aber ich will echt wissen, was das mit dem R ist!

Die Antwort ist: Reflection. Also dass z.B. eine Klasse selber "weiß", welche Member sie hat, und dass man sie abfragen oder ggf. durchiterieren kann. Moderne dynamische Sprachen haben das natürlich, aber es gibt an sich überhaupt keinen Grund, warum es nicht auch bei einer statisch typisierten Sprache wie C++ gehen soll. Einzige Limitation wäre dabei halt, dass man wirklich nur die Members von dem Typ bekommt, den man gerade zu handlen glaubt (und nicht automatisch alle Members von z.B. Unterklassen, von denen man nichts weiß), aber für vollautomatische Serialisierung oder message passing oder Bindings zu anderen Sprachen (z.B: Skriptinterpretern in einer Gameengine wäre es trotzdem unglaublich praktisch.

So muss man sich die Metadaten halt irgendwie selber besorgen. Entweder komplett selbstgeschrieben, durch manuelles Parsen der Debug- oder RTTI-Informationen (sofern vorhanden, ausserdem höchstgradig plattformabhängig), oder wie im Fall von Qt als Präprozessor, der die Metadaten aus der Klassendefinition erzeugt.

Ansonsten, yep, TimuЯ, gut zusammengefasst, kann ich als Mensch mit knapp 10 Jahren "richtiger" Gameindustrieerfahrung so perfekt stehen lassen

"The right tool for the right job" ist eh der beste Ansatz. Deswegen find' ich Leute, die Argumente wie "Legacy-Scheiß" oder andersrum "pottenlangsam" dafür ins Feld führen, dass ihre Sprache der Wahl ja so viiiiiiiiel besser ist, alle ein wenig albern.

[Eisbär]

Hab ich das jetzt richtig verstanden? Um die in verschiedenen Sprachen programmierten Programmteile gemeinsam laufen zu lassen, nutzt man z.B. eigene Scriptsprachen?

[K-Ninchen]

Hab ich das jetzt richtig verstanden? Um die in verschiedenen Sprachen programmierten Programmteile gemeinsam laufen zu lassen, nutzt man z.B. eigene Scriptsprachen?

Letztendlich läuft das auf irgendeiner Ebene darauf hinaus.

Es gibt da so viele Möglichkeiten, da steig ich dann auch nicht mehr ganz durch.

z.B. gibt es Programmbibliotheken, in denen jeweils ein ganzer Sack von Funktionen drin steckt, hast du sicher auch schon auf deiner Festplatte gefunden: DLL-Dateien (Dynamic Link Libraries). Die sind meist in C++ oder einer anderen Hochsprache geschrieben. Gilt nur für Windows-Plattformen. Was es da auf Mac OS gibt, weiß ich nicht, oder wie das in Linux läuft.

Dann hast du eine kleine EXE-Datei, die sich dann sämtlicher DLL-Dateien bedient, um z.B. ein Datei-Öffnen Fenster auf zu machen (das machen dann die System-DLLs die von Anfang an bei Windows dabei sind) oder du spielst ein spezielles Musikformat ab, da hat der Player dann z.b. eine eigene DLL mitgebracht, die nur die Aufgabe hat, dieses Musikformat abzuspielen.
Das schöne daran: Alles ist nett verpackt, wie "Black Boxen". In so einer DLL sind manchmal hunderte von Funktionen, Variablen, Klassen usw. aber es reicht aus, wenn man die Funktion kennt, die man braucht.

Bis dahin ist aber noch nicht unbedingt eine Scriptsprache aufgetaucht. Die tauchen eher ganz am vorderen Ende auf (Stichwort "Launcher"), als Start-Programm, die ein nettes Auswahl-Menu anzeigen und vielleicht bestimmte Einstellungen, die man in diesem Menu macht an das Programm übergeben.
...diese Scriptsprachen tauchen dann aber auch am anderen Ende, bzw. ganz tief, mitten im Programm wieder auf. z.B. wenn bei Quake die Gegner durch die Gegend laufen und einen angreifen:
Hier haben die Entwickler eine eigene Scriptsprache entwickelt (Quake C), mit der sich einfach solche Dinge machen lassen.
Das schöne daran: Man muss gar nicht mal so viel Erfahrung in Programmierung haben, um das Spiel mit neuen Waffen, Gegnern und Regeln zu erweitern. Die "Hardcore-Programmierer" haben auch besseres zu tun, als zu programmieren, dass ein Gegner nicht dauernd gegen die Wand läuft oder so.
Blender ist auch so ein Beispiel.
Es ist ein 3D-Programm (übrigens frei), mit dem 3D-Animationen und vieles mehr gebastelt werden können. Wenn andere Nutzer diese Programm erweitern wollen, z.B. eine Funktion, die automatisch ganze Bäume konstruiert, können sie das mit der Scriptsprache Python machen. Python ist dabei keine Eigenentwicklung, sondern schon etwas verbreiteter. Das ist von Vorteil, da einigen Nutzern diese Sprache schon bekannt ist.

Ansonsten ist ein ganz klassisches Beispiel, bei dem sehr viele Scriptsprachen zusammenarbeiten, tadaaaa... das Internet.
Sobald du http:... eingibst, landet deine Anfrage auf irgendeinem Server.
Dort wird meist schon das erste Skript gestartet (über einen kleinen Umweg, aber das ist mir dann doch zu wild erst mal). Meist PHP, ASP, etc.
Dieses PHP-Script wird vom Server interpretiert. Der server selber besteht aus vielen Programmen, teilweise in Hochsprache, teilweise auch als Skript programmiert, passend für den jeweiligen Server-Typ.
Dann wird aus diesem Skript die Seite im Browser aufgebaut. Auf dieser Seite befindet sich wiederum JavaScript oder Flash, wodurch wieder Skripte gestartet werden.
Der Browser selber ist meist in einer Hochsprache programmiert, enthält aber eben wieder Skript-Interpreter, die z.B. Javascript ausführen.
Wenn nun ein Flash auf der Seite ist, wird ein Plugin geladen (übrigens eine .DLL-Datei, in Hochsprache programmiert), die wiederum das Flash ausführt.
...jetzt käme eigentlich noch Metacode/Bytecode ins spiel, denn es gibt Fälle, da wird ein Script nicht direkt interpretiert, sondern das Script erst mal "vorgekaut", damit es schneller ausgeführt werden kann. Dieses "vorgekaute" Skript ist dann der Metacode/Bytecode... ja ich hör ja schon auf... *bad putzen geht*

[TimuЯ]

Cooler Beitrag, K-Nin, dem konnte ich sogar folgen, bei kb und Lucas verstehe ich trotz 9 Semester Medieninformatik nach dem 2. Satz immer nur "Macintosh"

Und Daaaaanke an kb für den Lob, ich wusste mal was Gescheites und hab was Sinnvolles beigetragen *woohooo* \o/
Da hat sich das halbe jahr Praktikum bei Replay Studios endlich bezahlt gemacht ^^

[CubistVowel]

CubistVowel:
Och komm, trau dich. Wir wollen nur spielen, lass dich von uns nicht stören.

Na schön, jetzt nach ein paar Postings, die fast normal wirkten, trau ich mich :

Hallo Timur und viel Spaß hier!

[TimuЯ]

Huuuu danke, ich fühl mich auch schon ganz wohl hier =)

[Lucas de Vil]

z.B. gibt es Programmbibliotheken, in denen jeweils ein ganzer Sack von Funktionen drin steckt, hast du sicher auch schon auf deiner Festplatte gefunden: DLL-Dateien (Dynamic Link Libraries). Die sind meist in C++ oder einer anderen Hochsprache geschrieben. Gilt nur für Windows-Plattformen. Was es da auf Mac OS gibt, weiß ich nicht, oder wie das in Linux läuft.

Bei UNIX und Derivaten enden die dynamischen Bibliotheken auf .so und sind ebenfalls in C oder C++ geschrieben.

Bei Linux werden die dynamischen Bibliotheken ähnlich wie bei Windows an bestimmten Orten vorgehalten.
Die meisten liegen in /usr/lib und /usr/local/lib, bei XP meines Wissens <WindowsVerzeichnis>\System und <WindowsVerzeichnis>\System32.

Der Unterschied bei Linux ist, dass in diesen Ordnern ALLE Bibliotheken landen. Du kannst also im schlimmsten Fall 17 verschiedene Versionen einer Programmbibliothek haben, die eigentlich immer dasselbe machen. Doch Programm A braucht zwingend Version 1.2, Programm B Version 1.4 und Programm C Version 0.9, und irgendwie bekommst du es mit durchschnittlichen Kenntnissen nicht hin, alle auf einen Nenner zu bringen.

Bei Apple hingegen ist es ähnlich wie bei Windows. Programme können ihre eigenen Bibliotheken mitbringen und in ihren Programmordner packen. Das Schöne am Dateimanager auf dem Mac ist, dass er Programmordner als einzelnes Programmicon anzeigt und ein Doppelklick das Programm startet.
Dass man eigentlich auf einen Ordner geklickt hat, der aus mindestens drei Unterordnern und mehreren Dutzend Dateien besteht, bekommt man als normaler User gar nicht mit.

Zum Beispiel liegen auf meinem Mac (Unix-Derivat) 899 dynamische Bibliotheken rum.
Das Programm 'blender.app', welches wie gesagt via Doppelklick sofort gestartet wird, enthält geschlagene 56 Programmbibliotheken, die es bei Bedarf einfach dazu lädt.

Beispielhaft sei hier die zlib.so bzw. zlib.dll unter Windows erwähnt, die dafür sorgt, dass Blender auch via ZIP gepackte Dateien öffnen und schreiben kann, wenn auf dem Rechner kein Winzip, Winrar, 7-Zip, gzip oder Sonstiges installiert ist.

Neben den von Ninchen angeführten Scriptsprachen nutzen einige Spiele wie beispielsweise World of Warcraft oder Warhammer Online weitere Scriptsprachen, um zusätzlich dem User zu ermöglichen auf das Look&Feel des Spiels Einfluss zu nehmen.
Die genannten Spiele nutzen die Scriptsprache LUA, mit der sich von einfachen kleinen Makros (quasi eine Sammlung von wiederkehrenden Befehlen) über kleine Zufallsscripte bis hin zu komplett neu gestalteten Spieloberflächen fast alles machen lässt.

Mal ein Beispiel von geht-überhaupt-gar-nicht:
Wir haben damals (2000) Die www.diddl.de Seite programmiert mit WebOjects UND Objective C. Das hat Monate gedauert und wir mussten sogar externe Anheuern, die das schlecht bis gar nicht dokumentierte Framework kannten.
Und was konnte die Seite letztendlich? NIX! Unterseiten darstellen und irgendwo konnte man sich für irgendwas eintragen. Ha-ha.
Ein Fall von "Thermonukleare Atomwaffen auf Bakterien werfen", was zwar der Dimension nicht ganz gerecht wird (es ist eigentlich noch schlimmer), aber so hat man eine Idee.

Erinnert mich an den Spruch eines Ingenieurs in Bezug auf einige Softwareentwickler, die alles machen einfach weil es geht.
"Würden sie den von innen verstellbaren Außenspiegel erfinden wären sie total happy und würden sich sofort danach an die Entwicklung des von außen verstellbaren Innenspiegels machen."
WebObjects ist doch Java, dat hat doch nur ganz entfernt mit Objective-C zu tun... +kopf kratz+

Das von dir geschriebene Beispiel lässt sich prima auf Alltägliches ummünzen:
ich möchte einen Nagel in die Wand bekommen, arbeite aber lieber mit nem Seitenschneider. Das geht doch bestimmt auch irgendwie.

"The right tool for the right job" ist eh der beste Ansatz.

Stimmt. Es ist halt immer blöd, wenn einem die Tools vorgegeben werden.
Insofern kann ich ja die Stimmung gegen diesen verdammten Rotz namens 'Objective-C', zu dem man bei der Entwicklung für das iPhone gezwungen wird, vollkommen nachvollziehen.

Allerdings kenne ich halt seit 2004 nur das großartige 'Objective-C', mit dem man auf dem Mac am einfachsten und effizientesten Programme entwickeln kann. Ohne Garbage Collection, Dot-Notation und den ganzen Schmiss.
Im Vergleich zu C++ mit Carbon, welches bis OS9 den Ton angab, eine wahre Wohltat.

Aus welchem Grund also sollte ich zurück?

[K-Ninchen]

Aus welchem Grund also sollte ich zurück?

Weil ich das so will. Basta.

Nein ehrlich, sei mal FROH, dass du kein Problem damit hast und das beherrschst. Es gibt bestimmt eine ganze Menge Leute, die schon im Vorfeld abgeschreckt sind und dem eher aus den Weg gehen und somit sind Objective-C Entwickler seltener zu finden, was für dich dann wieder ein Vorteil ist