superracer hat geschrieben:ich hab's mir jetzt nicht genau angeschaut, aber ich vermute mal, daß der game-code (in python) für die gesamte grafik usw. wohl nur library calls macht, und die libraries sind dann wohl doch in C geschrieben... je größer die datenmengen sind, desto kritischer wird die performance, und aufwändige grafiken bedeuten immer _viele_ daten...
Ich muss gestehen, dass ich auch nicht genau weiß, wie viel in Python geschrieben ist. Aber Stackless Python scheint eine sehr gut Perfmance zu haben.
der knackpunkt ist und bleibt die performance. in perl oder python bspw kann man sehr schnell sehr mächtige programme schreiben, allerdings sind die anforderungen an cpu und ram um ein vielfaches höher. wenn das ganze zeug dann skalieren soll, stößt man irgendwann an die grenzen der hardware. und dann gibt's nur zwei möglichkeiten: mehr oder bessere hardware muß her, oder das ding muß in einer anderen sprache, eben etwa C neu geschrieben werden, was dann zwar kein geld, aber zeit kostet.
Wenn man sehr performancelastige Dinge programmieren will/muss, ist das natürlich ein Grund. Es ist aber sehr oft so, dass Interpretersprachen in Sachen Geschwindigkeit sehr unterschätzt werden. Wenn man Linux installiert hat ist es durchaus interessant sich mal anzusehen, welche Programme nun in C/C++ und welche in anderen Sprachen programmiert wurden. Als ich auf freshmeat.net nach Perlprojekten gesucht habe, an welchen ich meine Perlkentnisse testen und erweitern kann, habe ich teilweise sehr gestaunt, weil ich immer dachte, dass dies und jenes in C programmiert sei. Ich lade jeden dazu ein, mal das freshmeat-Archiv zu durchstöbern.
aber das ist hier ja schon ein paar mal durchgekaut worden. wenn es aber um kleine programme geht, die in der perl-version 5 mb ram brauchen und 0.2 sekunden ausführungsdauern haben, während sie in der C-version 500 kb ram brauchen und 0.05 sekunden laufen, dann ist derjenige einfach nur dumm, der das in C schreibt. (oder masochist. oder er will vielleicht einfach nur C üben.)
Es gibt einige Leute, die bestimmte Programmiersprachen einfach gern haben. Assemblerliebhaber gibt es z.B. sehr viele (siehe MenuetOS oder Assembly-Messe (hieß glaub ich so)). Aber es gibt auch sehr viele Perlanhänger (siehe die vielen Perlspielerein auf wikipedia). Aber im Grunde geb ich dir da voll und ganz recht. Es kommt einfach drauf an, was man vor hat.
auch bash (oder andere unix shells), plus die dazugehörigen utils, ist in meinen augen eine richtige programmiersprache: man kann damit programme schreiben. (wer's nicht glaubt: es gibt sogar einen httpd geschrieben in bash. die performance ist allerdings unter aller sau)
Ich habe, muss ich gestehen, noch nie "eine Shell gelernt" und das obwoh fast nie X geöffnet habe (für gewöhnlichnur zum Surfen und Spielen). Ich verwende meist Perl, habe allerdings vor mich eventuell mal genauer mit der tcsh und der zsh zu befassen.
ein computer spricht in seiner muttersprache maschinensprache, also z.b. x86 bytecode. um den bytecode für menschen lesbar zu machen, gibt es assembler.
...und um sie unlesbar zu machen gibts brainfuck *duck*
Mit C ist man allerdings um einiges näher an der Hardware dran. Wobei man, wenn man das will, meist Assembler nimmt bzw. ein bisschen mischt *g*
C sehe ich als eine art frontend zu assembler. ein C-compiler spuckt üblicherweise auch keinen maschinencode aus, sondern assembler code, der dann dem assembler zum übersetzen in die maschinensprache gegeben wird. dazu gibt es in C eine reihe von eigenarten, die zumindest ansatzweises verständnis von assembler und/oder der darunterliegenden hardware voraussetzen. (beispiele: die "register" anweisung, sizeof(), das ganze drumherum mit pointern, noch schlimmer bei funktionspointern, ganz haarig wird's bei funktionen mit ner variablen anzahl an argumenten, ditto für longjmp() et al, sehr heikel sind "atomic" operationen, bei denen man bei multi-threading, aber auch bei signal handlers sehr aufpassen muß, usw usf...)
Da kennst du dich wohl besser aus. Ich dachte allerdings immer, dass der Compiler direkt in die Maschinensprache übersetzt, da ja Assembler nur statt Nullen und Einsen ein Text ist. Ich weiss, dass der Computer klarerweise Assembler nicht direkt versteht, aber für was denn dieser Zwischenschritt?
wer also ein "richtiger" C-programmieren sein will, muß auch zumindest eine ahnung von assembler haben.
Da bin ich voll und ganz deiner Meinung. Deswegen, hab ich ja auch in meinem ersten Post geschrieben, dass man dann auch Assembler braucht.
wenn wir einen schritt weiter gehen: in perl und in python gibt es ebenfalls eine reihe eigenarten, die zumindest ansatzweises verständnis von C voraussetzen. (immerhin sind die interpreter auch in C geschrieben.) beispiele sind reference counting bei objekten, die daraus resultierenden effekte aufs speichermanagement, typecasts und type juggling, signal handling, die eigenarten bestimmter systemnaher funktionsaufrufe usw...
Da bin ich nicht ganz deiner Meinung oder im Prinzip doch wieder?
Also ich hab mich zu allererst mit C und C++ versucht und war schwer überforder (ist aber auch schon sehr lange her). Dann hab ich lange Zeit allgemeines/"theretisches" übers Programmieren gelesen, immer mit langen Pausen dazwischen und bin schlussendlichch zu Perl gekommen. Die Sprache gilt als sehr schwer lesbar, allerdings hatte ich nie Probleme damit und habe (fast) immer alles verstanden. Wenn ich mir nun C-Code ansehe kommt mir alles sehr logisch vor und ich sehe, was er bewirkt und das auch bei systemnahen Codes (dem BSD-Kernel). Zwar kann ich selbst noch kein großes Programm schreiben, aber ich kann den Code lesen und kleine Bugs ausbessern oder Modifikationen vornehen. Auch wenn sich das in Grenzen hält, aber ich habe C nie gelernt und interpretersprachen verstehe ich großteils sehr gut und kann mit ein paar Referenzen größere Veränderungen vornhemen oder Programme schreiben.
wer also ein "richtiger" perl- oder python-programmieren sein will, muß auch zumindest eine ahnung von C haben.
Also ich habe den Weg umgekehrt beschritten *g*
wer das nicht hat, kann zwar natürlich trotzdem saubere und voll funktionsfähige perl- oder python-programme schreiben, auch in größerem umfang. allerdings wird er in bestimmten gebieten an seine grenzen stoßen, weil ihm einfach die kenntnisse über die interne funktionsweise der darunterliegenden sprache fehlen.
in solchen fällen greift der programmierer dann oft zu irgendwelchen schmutzigen hacks, um ein problem zu lösen... (selbiges gilt übrigens auch für C-programmierer und fehlende assembler-kenntnisse.)
So geht es mir in der Tat oft. Wenn ich ein Programm schreibe und den Code herzeige, dann werde ich oft darauf hingewiesen und damit lerne ich dann wohl die C-Ebene kennen. Vielleicht sollte man in den Schulen mal beginnen zuerst Assembler, dann C, dann ..., dann... (wie hießen die Sprachen noch gleich, die irgendetwas mit künstlicher Intelligenz zu tun haben und, wie "echte" Sprachen zu sein versuchen) zu lernen.
dann schau dir mal den bittorrent-code genauer an. du wirst _sehr_ viele codeschnippsel finden, die ihren ursprung in der C-welt haben, und die ein programmierer ohne C-kenntnisse unmöglich hätte schreiben können.
Ich hab mir zwar nicht den von bittorent, aber viele von Perlprogrammen angeguckt. Ich geb dir da recht, aber trotzdem man C verwendet ist das Programm in Python programmiert, da man sich damit vieles einfacher macht.
Es gibt auch Server und IIRC gab es mal ne Meldung, dass Perl sogar schon den Weg in den Linuxkernel gefunden hat.
vorsicht... in der distribution der kernel-sourcen sind zwar perl-scripte vorhanden, aber _im_ kernel selbst läuft kein perl. wäre auch gar nicht möglich.[/quote]
Nein, ich meine nicht die Konfigurationsanwendung u.ä.
Ich hab mal ein bisschen gegoogelt. Das Ding heißt ORbit und scheint von Redhat zu stammen (bin mir da aber nicht sicher), allerdings ist die verlinkte Seite nicht mehr vorhanden und ich war zufaul genauer zu suchen *gähn* Jedenfalls soll man so auch Treiber in Perl realisieren können. Wie das geht weiß ich selbst allerdings nicht.
Hier ein Artikel, den ich mal schnell rausgesucht habe:
http://www.linux-magazin.de/Artikel/aus ... eadme.html
unter "Linux Kernel ORB"
Klingt sehr interessant.
