Große Spiele in welcher Sprache

[hannes68]

In welcher Sprache werden eigentlich die "großen" Spiele programmiert??
Oder entwickeln die Firmen wie EA ihre eigene Sprache ???:L

Dan noch was anderes was hier nicht reingehört aber mir gerade so einfällt:
Wie wurde eigentlich das erste Programm gemacht?? (schreib jetzt bloss keiner "Mit einem Editor" )

 

[Icewind]

alle spiele werden eigentlich so weit ich weis in c++ geschrieben...

und die ersten programme kann ich nur vermuten, hm eine der ersten arten programme zu machen war glaub ich mit lochkarten

 

[Roar]

(fast) alle spiele (für PC) werden in c, c++ und assembler geschrieben.
"das erste programm" gibts nich. da hat sich niemand hingesetzt und gesagt: so nu schrieb ich mal ein programm.
die erste mikroprozessoren waren natürlich mit maschinencode und ur-assembler implementiert. frag jetzt bitte nicht wie :?
dann kam M$ und Basic und x86 assembler und die apple I und II und Lisa etc.

 

[Manfred]

Ich hab mal im Netz so über die Geschichte von Computern gelesen. Dabei bin ich auch auf ein "Excel" Progarmm gestossen, dass unter DOS lief.

Ich glaube der Mitbegründer von Apple hat das damals programmiert. Echt toll war das! Er hat das lt. Angaben in einer Nacht programmiert, ich glaube in Assembler, oder wars gar Maschinencode (!?) und es lief auf Anhieb OHNE Probleme!

VisiCalc wars, kann hier gedownloadet werden, das war aber nicht das "eine Nacht Projekt.."
http://www.bricklin.com/history/vcexecutable.htm

 

[Reality]

Hi,
die ersten Programme hat man in Maschinensprache geschrieben (001101011). Erst später wurde Assembler erfunden, wo dann Akronyme für die langen Maschinenbefehle erfunden wurden (0101100111 wurde zu MOV).
Dann wurden irgendwann Hochsprachen erfunden. Sie erledigten mehrere Schritte mit nur einem Befehl (z.B. printf()).

Zur Spieleprogrammierung:
Ich kenne sogar ein kommerzielles deutsches und erfolgreiches Spiel das in PureBasic geschrieben wurde. "Restricted Area" heisst das Spiel. Es ist schneller als C++ da es direkt in Assembler-Code kompiliert wird. Daher hat das Spiel auch so niedrige Anforderungen (800 MHz) ohne dass man an Grafik gespart hat.
Es ist auch einfacher als C++. Das Spiel hat nur ein Programmierer programmiert (aber es waren natürlich mehrere Grafiker etc.) und das Spiel misst 50 000 Zeilen Code wofür man in C++ ca. 500 000 gebraucht hätte (laut einem Mitarbeiter).

Ich habe mir mal die Sprache angeschaut und mag sie trotz ihrer Einfacheit nicht da sie

1. kein OOP kann
2. keine richtige Logik hat.

Liebe Grüße
Reality

 

[0xdeadbeef]

Naja, daß PureBasic schneller sei als C++, halte ich global betrachtet für zweifelhaft. Ich würde mal behaupten, auf Anweisungsebene ist C/C++ mit einem guten Compiler kaum von Basicdialekten zu überbieten, einfach weil in den C/C++-Compilern viel mehr Manpower und Erfahrung steckt. Zumal ja viele Basicdialekte zunächst mal interpretiert sind.
Sicher sind einige Basicdialekte (u.a. auch BlitzBasic) dort schnell, wo sie eingebaute Funktionen benutzen, die nativ implementiert sind. Will heißen: zeichnet man eine Linie mit "Line", geht das recht flott, zeichnet man jeden Punkt einzeln, ist es sterbenslangsam.
In C++ kann man aber ja nach wie vor sehr maschinennahen C-Code schreiben, der u.U. nicht wesentlich schlechter ist als handoptimierter Assembler. Zudem steht einem ja in C/C++ frei, externe Assemblerroutinen einzubinden.
In vielen Basicdialekten ist es allerdings nicht möglich, selber externe Module/Routinen einzubinden: der Sprachumfang muß also groß sein, weil man keine Möglichkeit hat, den Funktionsumfang (perfomant) zu erweitern.
Die Anzahl der Zeilen zu vergleichen, ist erstens spekulativ und zweitens ein bißchen unfair: die Standardlib reicht in C/C++ halt nicht aus, um Spiele zu programmieren, aber für viele Bereiche gibt es freie oder kommerzielle Bilbliotheken (Grafik/Sound), die das wieder ausgleichen.

Mal davon abgesehen ist Spiel nicht gleich Spiel. Das genannt Restricted Area scheint eine - vom Performancestandpunkt - verhältnismäßig einfache isometrische Ansicht aus vorgerenderten Elementen zu benutzen. Das ist natürlich nicht ganz das gleiche wie eine 3D-Engine mit den neuesten Pixelshader etc.

Ob OOP ein Muß in einer Sprache ist, sei mal dahingestellt. Nur wenige Leute benutzen Objektorientierung wirklich sinnvoll und man hat auch ganz gut mit "einfachen" modularen Sprachen wie C, Pascal oder Modula2 leben können.
Was mich an Basic wirklich stört, ist, daß man seine Programme üblicherweise nur mit genau diesem einem Dialekt ausführen (bzw. kompilieren) kann. Dagegen kann man bei Verzicht auf MFC und andere herstellerspezifische Spezialfeatures C/C++-Programme durchaus so schreiben, daß sie auf mehreren Compilern übersetzbar sind. Konsolenprogramme kann man sogar - mit einiger Mühe - plattformübergreifend kompilierbar machen.

 

[Reality]

Hi,
du kannst PureBasic nicht mit anderen Basic-Dialekten vergleichen, da wie gesagt PureBasic nicht interpretiert, sondern in Assembler-Code kompiliert wird.

Liebe Grüße
Reality

 

[0xdeadbeef]

Das ist nicht neu - bereits vor 10 Jahren gab es BasicDialekte, die kompiliert werden konnten. Ich gehe deshalb in meinem obigen Posting gar nicht speziell auf die Unterlegenheit eines Interpreters ein, sondern auf die des Compilers.

 

[Dr. Morv]

Es gab nicht immer als unterstes den Maschinencode. Um Java einen Sinn zu geben, gab es mal einen Prozessor, der JavaByteCode verstanden hat. Maschinencode wird genau genommen auch nur interpretiert.... aber mit Hardwareuntestützung. Meiner Meinung nach iszt gerade OOP für Spieleprogrammierung sehr hilfreich, da man dort mehr mit ganzen Objekttypen zu tun hat, für die man Klassen schreiben kann. Es ist schon besser, wenn die Gegner Klassen sind, die man verbessern und separat schreiben kann.

 

[0xdeadbeef]

Es gab nicht immer als unterstes den Maschinencode. Um Java einen Sinn zu geben, gab es mal einen Prozessor, der JavaByteCode verstanden hat.

Die picoJava-Architektur hat halt quasi Bytecode als Maschinencode. So what? Welchen Sinn ergibt diese Aussage?

Maschinencode wird genau genommen auch nur interpretiert.... aber mit Hardwareuntestützung.

In gewisser Hinsicht sind auch Ribosomen Interpreter, trotzdem ist die Definition eines Interpreters im Kontext "Software" recht klar:
http://de.wikipedia.org/wiki/Interpreter
Bevor ich einen Skriptsprachen- oder Basicinterpreter mit einen Prozessor vergleichen würde, käme mir zuerst mal die JVM in den Sinn. Jetzt mal davon abgesehen, daß ich die Unterlegenheit von Basicdialekten explizit nicht an der Diskussion Interpreter vs. Compiler festgemacth habe.

Meiner Meinung nach iszt gerade OOP für Spieleprogrammierung sehr hilfreich, da man dort mehr mit ganzen Objekttypen zu tun hat, für die man Klassen schreiben kann. Es ist schon besser, wenn die Gegner Klassen sind, die man verbessern und separat schreiben kann.

Objektorientierte Programmierung lohnt sich in allererster Linie dort, wo man durch Vererbung Zeit und Code spart. Wenn man nicht exzessiv Gebrauch von Vererbung macht, lohnt sich OOP IMHO nicht wirklich ... jetzt mal ganz pragmatisch betrachtet ohne Rücksicht auf "Schönheit" oder "Sauberkeit" (beides liegt ohnehin im Auge des Betrachters).

Warum sollte man das Verhalten usw. von "Gegnern" nicht ebenso in einem sauberen Modul mit klaren Schnittstellen definieren können? Ein Schuh wird draus, wenn man sagt, man hat 20 Sorten von Gegener mit leicht unterschiedlichem Verhalten/Aussehen, die aber viele gemeinsame Kernfunktionen haben, also alle von einer gemeinsamen Klasse abgeleitet werden können. Aber selbst das läßt sich mit einer saubern Architektur in einer modularen Sprache recht gut nachbilden.
Nichts gegen OOP: aber Objektorientierung ist nicht der Weisheit letzter Schluß und nicht die perfekte Lösung für alle Probleme.

 

[Dr. Morv]

Was für ein reichhaltiges Feedback!
OK, kann man nicht mal ausgelassen übers Proggen philosophieren? Irgendwie finde ich OOP hilfreich. Natürlich wird man nie vom Prozeduralen wegkommen und Objektorientierte Programme sind auch in andere Sprachen "übersetzbar", aber irgendwie kommt es dem menschlichen Denken näher. Aber OOP ist nicht nur Vererbung. Mehr Abstraktion, Generizität, das sind auch Merkmale der OOP. Die übrigens ihre ganz eigenen Vorteile haben. Irgendwer in diesem Forum wollte Klassen, die "on-the-fly" erstellt werden. Das wäre sicher auch hilfreich. Man braucht vielleicht nicht alle OOP-Aspekte in ganz normalen Programmen, aber es ist doch schön, wenn man die Möglichkeit hat, sie zu nutzen. Oh, jetzt ist ein Aufsatz draus geworden.
Gut, zurück zu den großen Spielen: Die sind glaube ich in C++ geschrieben, damit man ein kompiliertes Programm hat, man nicht Unterklassen des Spiels schreiben kann oder über Reflection die Methoden auslesen kann wie in Java. Wenn irgendwann Computer Spiele aus dem Internet herunterladen wie vom Handy(oder das Handy zum Computer wird), dann wird es vermutlich mehr Javagames zum Herunterladen geben.

 

[Oxygenic]

Maschinencode wird genau genommen auch nur interpretiert.... aber mit Hardwareuntestützung

Das ist schlichtweg vollkommener Quatsch. Das was im Prozessor passiert, ist die Abarbeitung von Befehlen (also die echte Ausführung dessen, was getan werden soll) und nicht nur eine Umwandlung einer Handlungsanweisung in eine andere.

 

[Oxygenic]

Er hat das lt. Angaben in einer Nacht programmiert, ich glaube in Assembler, oder wars gar Maschinencode (!?) und es lief auf Anhieb OHNE Probleme!

Urbane Legenden...aber das "ich glaube" belegt das ja auch eindrucksvoll ;-)

 

[CelikBlek]

erste programmier schritte hat conrad zuse so etwa 1035-1940 mit mechanisch arbeitenden programmgesteuerten rechenmaschinen gemacht. dazu entwickelte er nach einigen jahren die erste programmiersprache(hiess Plankalkül, ENIAC). Umsetzung durch umstecken und löten von drähten. in den 60'er kam erst der Einsatz von IC's.
Dies waren soweit ich weiss die ersten Schritte. Es sei denn mein Prof hat uns alle angelogen

 

[Thorsten]

Naja, daß PureBasic schneller sei als C++, halte ich global betrachtet für zweifelhaft. Ich würde mal behaupten, auf Anweisungsebene ist C/C++ mit einem guten Compiler kaum von Basicdialekten zu überbieten, einfach weil in den C/C++-Compilern viel mehr Manpower und Erfahrung steckt. Zumal ja viele Basicdialekte zunächst mal interpretiert sind.

PureBasic wird per NASM bzw. FASM in reinen Machinencode KOMPILIERT.

In C++ kann man aber ja nach wie vor sehr maschinennahen C-Code schreiben, der u.U. nicht wesentlich schlechter ist als handoptimierter Assembler. Zudem steht einem ja in C/C++ frei, externe Assemblerroutinen einzubinden.

ASM kannst du auch in PureBasic inline schreiben...

In vielen Basicdialekten ist es allerdings nicht möglich, selber externe Module/Routinen einzubinden: der Sprachumfang muß also groß sein, weil man keine Möglichkeit hat, den Funktionsumfang (perfomant) zu erweitern.

In PureBasic kann man DLLs einbinden und auch selber kompilieren.

Mir ist aber Java viel lieber Und wo steht, dass man mit Java keine umfangreichen Spielen schreiben kann?
Ja, ein Doom3 wird nicht gehen, klar. Aber wenn man an andere Spiele denkt... ohne 3D... :wink:

Wenn man sich die Mühe macht, mit Java ein Spiel zu schreiben, dann hat man zumindest mal den Vorteil, dass
es auch aufm Mac und Linux läuft.....

 

[Reality]

Du kannst mit Java auch 3D Spiele programmieren. OpenGL steht dir auch zur Verfügung.

Liebe Grüße
Reality

 

[AlArenal]

Maschinencode wird genau genommen auch nur interpretiert.... aber mit Hardwareuntestützung

Das ist schlichtweg vollkommener Quatsch. Das was im Prozessor passiert, ist die Abarbeitung von Befehlen (also die echte Ausführung dessen, was getan werden soll) und nicht nur eine Umwandlung einer Handlungsanweisung in eine andere.

Das ist weiderum in dieser Form auch vollkommener Quatsch.

Es gibt bereits eine ganze Reihe von modernen Prozessoren, die Assemblerbefehle bzw. deren Maschinencodes intern in mittels Programmen, die in Microcode geschrieben sind in Mikroanweisungen umsetzen, die dann von den Ausführungseinheiten der CPU abgearbeitet werden. Auf diese Weise versucht man im Nachhinein beispielsweise CISC-Prozessoren mit den Vorteilen von RISCs auszustatten.

Schau dir mal die Architektur von M68060, Athlon, P4, Transmeta, ....

 

[amlug]

Warum werden eigentlich alle Spiele in C,C++ oder Assembler geschrieben, denn Java kann bis auf die Schnelligkeit fast mithalten Es gibt gute "Tools", mit denen man aus Java auch exe erstellen kann. (nehmt es nicht so wörtlich, denn die Javadatei bleibt erhalten)
Und 3D-Unterstützung gibt es auch. Z.B jPCT (kann ich nur empfehlen). http://www.jpct.net

 

[DesertFox]

Es gibt schon Spiele die zumindest Teilweisse in Java geschrieben sind wie Iljuschin 2 Sturmovik, welches auch gleich die VM mitliefert, aber die geschwindigkeit ist vor allem im 3D bereich doch sehr viel langsamer wie bei C++.

 

[0xdeadbeef]

PureBasic wird per NASM bzw. FASM in reinen Machinencode KOMPILIERT.

Denkanstoß: Ein Programm in Machinencode ist nicht per se schnell. Deshalb muß im Compiler sehr viel Know-How über allgemeine und prozessorspezifische Optimierungstrategien stecken.

ASM kannst du auch in PureBasic inline schreiben...

Aha. Habe ich dem widersprochen? Schränkt das die Wahrheit meiner Aussage irgendwie ein? Nö!

In PureBasic kann man DLLs einbinden und auch selber kompilieren.

Ein Eingeständnis in den begrenzten Funktionsumfang und die mangelnde Performance. Warum sollte man das sonst tun wollen?

 

[Illuvatar]

Aber Il 2 Sturmovik nutzt (wie auch Vampire 2) Java nur als Scriptsprache, oder?
Soweit ich weiß ist Law and Order übrigens auch auf Java basierend.

PS: @Thorsten, 0xDEADBEEF: Bitte hier keinen Streit über PureBasic anfangen

 

[Roar]

Warum werden eigentlich alle Spiele in C,C++ oder Assembler geschrieben, denn Java kann bis auf die Schnelligkeit fast mithalten Es gibt gute "Tools", mit denen man aus Java auch exe erstellen kann. (nehmt es nicht so wörtlich, denn die Javadatei bleibt erhalten)
Und 3D-Unterstützung gibt es auch. Z.B jPCT (kann ich nur empfehlen). http://www.jpct.net

tjaja die geschwindigkeit...
wenn die exe4j "Tools" wirklich ein argument für spieleprogrammierung mit java sei nsollen lach ich mich schlapp...
und wie vorhin schon jemand gesagt hat: wenn, dann mit opengl...

 

[hannes68]

Ein gutes Java Spiel ist ja Trail Bike

 

[Thorsten]

Ich fange sicher keinen Streit wegen PureBasic an :wink: Ich liebe Java

Java und Spiele... das Problem ist doch, dass es noch keiner (?) versucht
hat, ein Spiel direkt in Java zu schreiben. Also eine Engine in Java zu
schreiben.

Wobei ich jetzt Monopoly, Pong usw. nicht zähle :wink: Die Leute, die
versuchen ein Spiel in Java zu schreiben (wie auch hier im Forum),
begehen immer große Fehler -- und damit sind diese Projekte im
Prinzip von vorn herein zum scheitern verurteilt.

Schaut euch das "Das JAVA-FORUM.ORG/DE-Spiel Projekt" an...

Hey -- wir reden hier über extrem umfangreichen Code, der länger
als ein paar tausend Zeilen sein wird! Wir reden über extrem viele
Klassen -- so ab hundert und mehr... eigene Klassen!!

WENN man wirklich Interesse an so einem Projekt hat, und es wirklich
bis zum Ende durchhalten will, muss man ganz anders anfangen.

Denn zunächst muss alles komplett geplant werden. Der größte Fehler
ist es, sofort mit dem programmieren anzufangen. Dann ist es sicher,
dass das Projekt scheitern wird!

Nein... man muss vorher jede Klasse "trocken" planen, man muss
für jede erdenkliche Funktion im Spiel eine Lösung nieder geschrieben
haben.

Wenn man dann, nach einem Jahr oder so, 200 Seiten Dokumentation
hat, und Klassendiagramme angefertigt hat, DANN kommt die erste
Zeile Code.


Glaubt mir... ich spreche aus Erfahrung. Leider leider leider kann und
werde ich über mein Projekt nichts sagen :wink:

 

[Guest]

Glaubt mir... ich spreche aus Erfahrung. Leider leider leider kann und
werde ich über mein Projekt nichts sagen :wink:

Ist das ein Spiel-Projekt?

 

[DesertFox]

@Illu, ja hast recht, aber immerhin ist ein Teil davon in Java geschrieben.

Mit fällt grad ein, dass derzeit doch Quake 2 in Java programmiert wird (ich weiss derzeit nicht neues davon, aber vor ein paar monaten war ich auf der Projektseite davon), also ein Clon, ich weiss gerade nicht mehr genau, wies heisst, aber das kennen sicher viele von euch. Das zeigt, dass mit Java 3d ziemlich viel möglich ist. Abers wird halt nicht so schnell laufen wie das orginal Wuake 2 auf heutigen rechnern.

 

[0xdeadbeef]

Man muß sich bloß die FPS-Demo auf JPCT.net ansehen, und man weiß, daß man durchaus Egoshooter in Java programmieren kann, zwar vielleicht nicht mehr ganz "state of the art" (a la FarCry und Doom3), aber dafür auch mit komplett in Java implementiertem Software-Renderer!

 

[amlug]

Warum werden eigentlich alle Spiele in C,C++ oder Assembler geschrieben, denn Java kann bis auf die Schnelligkeit fast mithalten Es gibt gute "Tools", mit denen man aus Java auch exe erstellen kann. (nehmt es nicht so wörtlich, denn die Javadatei bleibt erhalten)
Und 3D-Unterstützung gibt es auch. Z.B jPCT (kann ich nur empfehlen). http://www.jpct.net

tjaja die geschwindigkeit...
wenn die exe4j "Tools" wirklich ein argument für spieleprogrammierung mit java sei nsollen lach ich mich schlapp...
und wie vorhin schon jemand gesagt hat: wenn, dann mit opengl...

Das soll noch nicht mal ein Argument sein, sondern nur ein Hinweis, für die, die denken, dass es eigentlich gar keinen Zweck hat, spiele zu programmieren, weil es ja eh nicht auf jedem PC läuft.

 

[Roar]

Warum werden eigentlich alle Spiele in C,C++ oder Assembler geschrieben, denn Java kann bis auf die Schnelligkeit fast mithalten Es gibt gute "Tools", mit denen man aus Java auch exe erstellen kann. (nehmt es nicht so wörtlich, denn die Javadatei bleibt erhalten)
Und 3D-Unterstützung gibt es auch. Z.B jPCT (kann ich nur empfehlen). http://www.jpct.net

tjaja die geschwindigkeit...
wenn die exe4j "Tools" wirklich ein argument für spieleprogrammierung mit java sei nsollen lach ich mich schlapp...
und wie vorhin schon jemand gesagt hat: wenn, dann mit opengl...

Das soll noch nicht mal ein Argument sein, sondern nur ein Hinweis, für die, die denken, dass es eigentlich gar keinen Zweck hat, spiele zu programmieren, weil es ja eh nicht auf jedem PC läuft.

hmm dir ist schon klar dass executables nur auf windumm laufen und normale java anwendungen ohne wrapper auf allen plattformen sofern keine plattformabhängigen bibliotheken oder so verwendet werden (obwohl opengl gibts ja auch für windows und linux (mac auch?))?
oder meintest du das jpct rendering?

 

[amlug]

oder meintest du das jpct rendering?

Eigentlich ist es egal, da beides fast gleich gut ist. (es kommt nur auf den prozessor an)

hmm dir ist schon klar dass executables nur auf windumm laufen und normale java anwendungen ohne wrapper auf allen plattformen sofern keine plattformabhängigen bibliotheken oder so verwendet werden (obwohl opengl gibts ja auch für windows und linux (mac auch?))?

Man kann java auf in Linux anwendungen und Mac anwendungen umwandeln.

 

[Jockel]

Alle Interessierten sollten sich vielleicht mal die Postmortems auf Gamasutra anschauen:
http://www.gamasutra.com/php-bin/article_display.php?category=5 (benötigt, glaube ich, eine Registrierung).
Dort werden kommerzielle Projekte vorgestellt, was gut verlief, was weniger gut war und meist auch die verwendeten Tools, LOC, etc.

John Carmack meinte in einem Interview wohl mal, dass er für Quake III (glaube ich), lieber C++ verwendet hätte, als reines C, allerdings hätte er schon so viel C-Code, den er wiederverwenden könnte, dass ein Umstieg nicht lohnen würde. Und das ist wahrscheinlich auch der Grund, warum die meisten Spiele in C/C++ entwickelt werden. Es gibt genügend (erprobte) Tools/Libraries/etc. die sich für den Einsatz unter C/C++ bewährt haben. Außerdem gibt es tonnenweise Ressourcen in Bezug auf C/C++ und Spieleprogrammierung. Wer also damit anfangen möchte, wird in der Regel ja nicht zu irgend einem Exoten greifen. Außerdem setzt sich ja nicht immer die beste Technologie durch. (Auch wenn ich immer wieder gerne sage: "Für jede Aufgabe das richtige Tool").

Und zu Assembler: Ich hatte mal Kevin Pickell (den Programmierer von Stunts (4D Sports Driving) (http://www.scale18.com/kpickell.html)) gefragt, wie das heutzutage aussehen würde und er meinte, dass höchstens noch 5 % des Codes Assembler-optimiert sind... wahrscheinlich sogar weniger als ein halbes Prozent. Soviel dazu...

Es ist auch einfacher als C++. Das Spiel hat nur ein Programmierer programmiert (aber es waren natürlich mehrere Grafiker etc.) und das Spiel misst 50 000 Zeilen Code wofür man in C++ ca. 500 000 gebraucht hätte (laut einem Mitarbeiter).

Naja, aber in der Regel sind eh nur eine handvoll Programmierer am Werke. Schaut man sich das Team von id-Software mal an, so tragen nur 3 Leute, den Titel 'programmer' und insgesamt sind es wohl nur 5, die überhaupt was mit dem Code zu tun haben...

 

[adsci]

Früher wurde viel mit watcom C++ geschrieben (DOS4GW Zeiten) - inzwischen wird fast alles mit MS Visual C++ geschrieben.

 

[adsci]

und wegen der schnelligkeit der programmiersprachen:

umso hardwarenäher die programmiersprache ist, umso schneller KANN man damit programmieren.
umso abstrakter umso langsamer. heisst: je weniger du selbst machen musst als programmierer, umso schneller ist das endprodukt. bei assembler musst du viel machen, dafür kannst dus genau steuern. unter c/c++ weitaus weniger, aber doch noch ne ganze menge = guter kompromiss. alles höhere wie basic, java, etc. ist für rechenintensive anwendungen nicht geeignet.

nunja, meine meinung.

 

[Manfred]

umso hardwarenäher die programmiersprache ist, umso schneller KANN man damit programmieren.
umso abstrakter umso langsamer. heisst: je weniger du selbst machen musst als programmierer, umso schneller ist das endprodukt.

Ich denke das ist ein Widerspruch......