Kennt jemand von euch D ??? neue Prog. sprache?!?
-
K.a schrieb:
Es ist vollkommen unerheblich wieviele fehler in dieser zeile sind. Ich kenne mich mit "D" nich aus und kann das nicht ersehen. Ich weis nicht warum du mich fragst ob ich darin fehler finden kann.
Die Fehler sind in der C++ Variante...
K.a schrieb:
es ist mir egal was an java langsam ist! Es IST langsam. Und sicher nicht 2 zu 5.
Kann ich mir vorstellen. Swing ist eine Bibliothek, falls dir dieser Begriff geläufig ist. Und davon ab, "2-5" liest sich 2 BIS 5, nicht 2 zu 5.
K.a schrieb:
Ich gebe ja zu dass kleine programmiersprachen wie Java, PHP, SHELL, PERL mal ganz nützlich sein können für kleinere sachen und schnell zu schreiben gehen. Aber für grosse projekte sollte man immer C nehmen. Was glaubst du warum alle grossen projekte C-projekte sind?
Frag dich lieber mal warum viele grosse Projekte eben NICHT in C geschrieben sind, obwohl es zweifellost Performancevorteile hat. (Über deren Ausmaß sich vortrefflich streiten lässt, gerade weil sie nicht für jeden Anwendungsfall gleich oder gar relevant sein müssen.)
K.a schrieb:
Viel zu allgemein. Als verktor verstehe ich eine basis coordinate und eine ziel coordinate im mathematischen sinne.
Tipp: Schlag ein Buch auf, vorzugsweise mit dem Schriftzug "Lineare Algebra" o.ä.
K.a schrieb:
cout finde ich unschön! Warum nicht einfach printf nehmen sondern alles abstaktieren und verwirrend machen für anfänger.
Entweder bist du ein waschechter C Fanatiker oder du solltest deine Posts gegenlesen lassen damit dir nicht solche Fehler unterlaufen
-
K.a schrieb:
C++ wird als erweiterung angesehen - das ist es doch auch oder etwa nicht? D ist nicht nur eine erweiterung, z.b. existiert kein preprozessor. Du kannst als C code nicht mit dem D compiler compilieren.
Auf der D Homepage steht nicht, daß D eine Erweiterung von C oder C++ ist, sondern ein "Reengineering", d.h. eine Überarbeitung.
Shade Of Mine schrieb:
Ich wiederhole mich: ungeeignet.
Wie willst du mit D cross-compilieren ohne pre-prozessor?
Wie willst du mit -D_DEBUG compilieren ohne pre-prozessor?
Pre-prozessor hat sehr viele vorteile.Schau dir D an, dann wirst du sehen, dass du einen PP braucht.
ist das ein tippfehler? Meinst du "keinen" oder "einen". Wenn du "einen" meinst, bin ich ganz deiner meinung. Wenn du "keinen" meinst, frage ich dich, wie du in D crosscompilieren willst. Oder eine debug version? Oder von ausserhalb dem compiler flags für den sourcecode mitgeben? Wie soll dass dann in D gehen?
Das zeigt nur, daß Du Dir die Sprache D nicht eine Sekunde angeschaut hast. Für Debug Versionen gibt es das Schlüsselwort Debug. Der Debug-Code wird mit dem Kommandozeilen-Parameter "-debug" einkompiliert. Was man in C/C++ mit #ifdef FLAG macht, macht man in D mit version(FLAG), Versions-Flags kannst Du, man höre und staune, mit -version=FLAG dem Compiler übergeben.
D ist sehr gut darauf vorbereitet unter unterschiedlichen Umgebungen zu kompilieren.operator void schrieb:
Da habe ich in der Tat das wichtigste vergessen: Ich meinte ein sort mit Prädikat. Von mir aus auch ein find mit Prädikat, oder alles, was so in <algorithm> rumschwirrt.
Als C++ler sehe ich for_each nur als eine Funktion von vielen, die man mit einem Prädikat ausstatten kann. Leider ist das Konstruieren dieser Prädikate in C++ sehr hässlich. (Und das ist ein Problem, sonst würde man sich nicht die Mühe machen, Boost.Lambda usw. zu schreiben.)
Da hilft D im Fall von for_each nach, indem es foreach in die Sprache einbaut. Lieber wäre es mir, D hätte so minimalistische Blöcke wie Ruby, dass man sich ein foreach, das annähernd schön wie ein eingebautes ist, selbst schreiben kann.Ok, so weit ich weiß kann man dem eingebauten sort keine Prädikate übergeben, allerdings unterstützt D Funktionsliterale (Lambda-Ausdrücke). Ich möchte meine Hand nicht ins Feuer legen, aber so etwas sollte möglich sein:
Container!(T) cont; ... for_each( cont, int function(T t1, T t2) { berechnungen; return ergebnis; } );
Ich bin ehrlich gesagt nicht so erfahren was D und C++ angeht, aber in der Sprache D ist so vieles möglich, was man erst erfährt, wenn man sich mit der Sprachspezifikation beschäftigt. In diesem Beispiel mußt Du Dir Dein for_each selbstverständlich selbst programmieren.
Viele Argumente, die ich hier gegen D lese, sind einfach ungerechtfertigt. D ist ganz gewiß nicht der Weisheit letzter Schluß, aber die Sprache kommt ziemlich nahe dessen, was ich mir unter einer nahezu perfekten Sprache vorstelle!
-
Ein Gast schrieb:
Ich bin ehrlich gesagt nicht so erfahren was D und C++ angeht [...] aber die Sprache (D) kommt ziemlich nahe dessen, was ich mir unter einer nahezu perfekten Sprache vorstelle!
o.O
-
ok aber warum macht man dann nicht einfach eine normale for? Warum fügt man ein schlüsselwort hinzu, was nur geringe abkürzungen mit sich bringt!
Das habe ich mich auch gefragt: Warum hat C ein for Schleife? Die ist sowas von unnütz und überflüssig!
Statt:for (i=0; i<5; ++i) {}
könnte man doch auch
i=0; while (i<5) { ++i; }
schreiben.
Obwohl, eigentlich finde ich sogar while totalen Käse. ein if eine Marke und ein goto und das Problem ist gelöst. Scheiß C, verschwendet gleich zwei Schlüsselwörter. Und dann auch noch ein drittes bei do...while. *ARGH*, welcher Vollidiot hat sich das blos ausgedacht.Eiffel ist da schon viel cooler mit nur einem Schleifenkonstrukt.
Auch ist der name der (template)klasse vektor unpassend.
Also weder im mathematischen, noch im informatischen sinn unpassend. Also in welchem Bezug steht das Wort "unpassend" hier?
Ich glaube dass ein anfänger nur richtig begraift wie ein kompiler und C wirklcih funktioniert, wenn er mit printf und ähnlichen anfängt. Wenn es ihm dann gefällt, kann er ja dann immernoch cout verwenden.
Hmm, Wie ein Compiler funktioniert lerne ich dabei irgendwie überhaupt nicht. Wo sehe ich denn was der Scanner oder Parser macht? Wo kann ich mir den AST ansehen, ...? Also mit Compiler-Verständnis hat das schonmal nichts zu tun.
Mit C? Hmm, printf ist eine Funktion wie jede andere, die definitiv Teile beinhaltet, die nicht in C geschrieben sind, da man sonst nicht an die Standardausgabe käme. Also bringt mich das in C auch nicht weiter.
Hmm.und das fehlen eines preprozessors(oder habe ich das flasch verstanden?) nicht akzeptabel ist für ein grosses projekt.
Weil?
Also D kennt versioning (ohne Präprozessor!!!), es gibt sogenannte Mixins, um Code einzufügen, aber deutlich sicherer, als in C. Also Was genau fehlt mir für "große Projekte". Und was ist mit den Mehrere-Millionen-Zeilen-Code-Projekten in Java ganz ohne Versioning?ich denke dass es einen anfänger sehr verwirrt, wenn er nicht begreift, dass der << operator von cout nur eine funktion ist und nichts "was der prozessor macht"
Was der Prozessor macht? Naja, alles, was da abläuft hat aus hardware-naher Sicht irgendwie mit dem Prozessor zu tun, egal, wie es in der Abstraktionsschicht mal hieß. Aber als Programmierer interessiert mich der Prozessor in der Regel einen scheiß-dreck. Es sei denn ich arbeite gerade in Assembler oder ich bin dabei eine kleine Code-Stelle auf extreme Performance zu züchten. Beides kommt bei mir im täglichen Leben als Programmierer extrem selten vor.
Ich wiederhole mich: ungeeignet.
Wie willst du mit D cross-compilieren ohne pre-prozessor?
Wie willst du mit -D_DEBUG compilieren ohne pre-prozessor?
Pre-prozessor hat sehr viele vorteile.Wie bereits erwähnt geht beides in D und das ohne die Nachteile eines Präprozessors.
Es zeigt aber IMHO das Problem hinter der D-Philosophie. foreach ersetzt jetzt std::for_each durch etwas "Schöneres". Und wo bleibt ein sort, das std::sort ersetzt? usw. - Hätte man die Mittel bereit gestellt, damit man sich ein benutzbares foreach selbst schreiben kann (so wie Enumerable#each in Ruby z.B.), hätte man mit einer allgemeineren Lösung nicht nur die Spitze des Eisbergs kaschiert.
foreach ist eine derart häufig vorkommende Aufgabe das sich ein leicht erweiterbares Sprachkonstrukt IMHO lohnt. Aber es sind für D2.0 Sather-artige Iteratoren im Gespräch. Also kein Problem mehr mit Rubys iterations-Model (das AFAIK das von Icon ist) mitzuhalten.
Oder um ein anderes Beispiel zu bringen, D stellt für Strings einen eingebauten Typ bereit (verschiebt die Arbeit also in den Compiler), der dann nicht mehr die Probleme von C++-Strings hat. Wieder wäre es mir lieber, die Sprache wüsste nichts über Strings (oder dynamische Arrays im allgemeinen, denn solche sind Strings ja in D) und würde es ermöglichen, eine schönere Stringklasse in der Sprache selbst zu schreiben.
Nein. D stellt für Strings eben keinen Typ bereit, anders, als z.B. Java oder C#.
D-Strings sind einfach nur Datenfelder von Chars (Unicode codiert).
Deine Stringklasse kannst du also Problemlos drumherumsetzten. Allerdings ist der umgang mit "Strings" deutlich bequemer als mit Char-Zeigern.Ich denke TROTZDEM dass ein anfänger verstehen sollte was eine funktion ist und was eine rechenoperation ist die vom (Co)Prozessor ausgeführt wird. Ich denke das ist nicht egal - du siehst es an den meisten leuten die sich programmierer schimpfen: sie haben das system überhaupt nicht verstanden!
Jeder Programmierer sollte wissen, was eine Funktion ist. Dazu braucht man aber kein printf.
Naja, ein Funktionsaufruf ist ein Sprung, goto auch, eine Schleife auch. Also alles das selbe auf Maschieneebene. Aber genau davon wollen wir ja weg beim Programmieren.Was glaubst du warum alle grossen projekte C-projekte sind?
Krass, was für ein Zeug rauchst du denn? Das will ich auch haben!
Und weil ja in C der operator ++ für eins erhöhen steht, ist wohl C++ vom namen her auch eine erweiterung. Und D vom namen her ein "nachfolger".
Aha, D ist also der Nachfolger von C, 2 aber nicht der Nachvolger von 1.
Also das mit dem D und C stimmt zwar im Lateinischen Alphabet, aber das mit den Zahlen musst du mir nochmal genauer erklären. (Erinnerung: ++ inkrementier(erhöht) um eins).Viel zu allgemein. Als verktor verstehe ich eine basis coordinate und eine ziel coordinate im mathematischen sinne.
Dann solltest du aber mal ganz ganz schnell deine mathematischen Kentnisse aufbessern. So wird das nichts.
-
Shade Of Mine schrieb:
K.a schrieb:
Es ist vollkommen unerheblich wieviele fehler in dieser zeile sind. Ich kenne mich mit "D" nich aus und kann das nicht ersehen. Ich weis nicht warum du mich fragst ob ich darin fehler finden kann.
es ist c++
vielleicht das ein namespace kein template sein kann? Oder dass die standardlibary klassen keine memberfunktiomnen wie begin haben? Ich weis es nicht. Und mich interessiert es auch nicht.
Shade Of Mine schrieb:
Ich denke TROTZDEM dass ein anfänger verstehen sollte was eine funktion ist und was eine rechenoperation ist die vom (Co)Prozessor ausgeführt wird. Ich denke das ist nicht egal - du siehst es an den meisten leuten die sich programmierer schimpfen: sie haben das system überhaupt nicht verstanden!
Natuerlich soll man die Grundlagen lernen. dagegen habe ich ja nichts gesagt. nur ist printf ein haessliches monster, dass man lieber nicht seinen eltern vorstellt
qie du meisnt ich finde es besser als cout und ich habe jetzt auch keine lust mehr mich darüber zu streiten
Shade Of Mine schrieb:
Werden selten gebraucht? Das kommt ganz auf den programmierer an. Dieser mechanismus ist äusserst sinnvoll.
Aber nicht fuer anfaenger und auch sonst kommt es selten vor, dass man das wirklich braucht. schau dir mal opensource C code an, wie oft siehst du da variadic functions? es ist die ausnahme...
Nicht nur das: auch schneller als manche classen aus der standard libary (str), die nur geschrieben wurden um es anfängern leichter zu machen.
ne, es sind highperformance strukturen die es _jedem_ leichter machen.
oder willst du mal auf die schnelle eine general purpose string klasse schreiben die schneller als std::string ist? geht wohl kaum.
ich schreibe mir immer meine eigene string klasse. Schneller ist sie sicher nicht aber ich verwende sie auch nur wenn unbedinge nötig.
Shade Of Mine schrieb:
Sie finden es vielleicht am anfang leicht, es ist dann für sie allerdings viel schwerer das system hinter C zu verstehen.
reden wir von C oder C++?
die stl gibt es ja nur bei C++ und da ist das system hinter C ja total unwichtig.hinter C. Hinter dem richtigen C. Und nicht hinter den versteckten überladenen operator-funktionen.
Shade Of Mine schrieb:
Schau die doch die ganzen "programmierer" an!
wen meinst du damit?
ich kenne eigentlich keinen c programmierer der c nicht kapiert. sonst wuerde er es ja nicht programmieren.
oder redest du von den anfaengern die wir hier im forum haben und die c gerade lernen?
na oh wunder, die haben es noch nicht kapiert, aber mal ehrlich: wer kapiert denn schon etwas ohne es zu lernen?achso! Also wenn man ein bisschen C kann, kann man gleich alles programmieren? Du siehst also keinen Unterschied zwischen irgendwelchen dummen Windows lib usern und leuten, die sich ihr eigenes X11 toolkit schreiben?
90% aller programmierer sind web"programmierer", VB"programmierer" oder Java"programmierer".Shade Of Mine schrieb:
Lieber ein paar wenige gute als viele die von sich sagen sie wären solch tolle programmierer aber in wirklichkeit kennen sie den unterschied zwischen einer compilersprache mit echten funktionen wie C nicht von einer interpretersprache wie PHP auseinander.
PHP hat keine echten funkionen?
keine richtigen funktionen wie in C, die wirklich in assembler code mit sprungmarken umgewandelt werden. Sondern interpretierte code stücke.
Shade Of Mine schrieb:
es ist mir egal was an java langsam ist! Es IST langsam. Und sicher nicht 2 zu 5.
ignorant
Ja es genübt für kleine projekte ist aber ZU LANGSAM für richtige!
Shade Of Mine schrieb:
Ich gebe ja zu dass kleine programmiersprachen wie Java, PHP, SHELL, PERL mal ganz nützlich sein können für kleinere sachen und schnell zu schreiben gehen. Aber für grosse projekte sollte man immer C nehmen. Was glaubst du warum alle grossen projekte C-projekte sind?
Alle grossen projekte, wie zB Windows 2000?
oder google? oder warum pusht orcale java so? oder ms setzt auf .net. oder die ganzen Java anwendungen und enterprise beans?sorry, aber du hast dich selbst disqualifiziert.
mit C projekte sind auch C++ projekte gemeint. Ich meine natürlich nicht nur AnsiC. Also sprachen != Java,VB,PHP,Perl,Shell.
Und google ist sicher kein reines php. Glaubst du wirklich dass php in der lage wäre eine riesen datenbakn zu durchsuchen? Und wenn auch php+mysql - dann ist mysql doch auch wieder in C geschrieben.
Und wenn du dich an "vorbildern" wie MS (windows) orientierst, findest du wohl auch die ganzen abstürze normal?in wie fern hab ich mich disqualifiziert?
Shade Of Mine schrieb:
C++ wird als erweiterung angesehen - das ist es doch auch oder etwa nicht? D ist nicht nur eine erweiterung, z.b. existiert kein preprozessor. Du kannst als C code nicht mit dem D compiler compilieren.
Ich kann auch nicht jeden C code mit einem c++ compiler kompilieren.
ach ja? nicht? welchen denn nicht bitte schön?
hier hast du dich wohl "disqualifiziert".Shade Of Mine schrieb:
Und weil ja in C der operator ++ für eins erhöhen steht, ist wohl C++ vom namen her auch eine erweiterung. Und D vom namen her ein "nachfolger".
dh, B ist der nachfolger von C aber 2 die erweiterung von 1?
was? B der nachfolger von C? Umgekehrt stimmts. Und ich weis nicht ws du mit 2 und 1 sagen willst.
Shade Of Mine schrieb:
cout finde ich unschön! Warum nicht einfach printf nehmen sondern alles abstaktieren und verwirrend machen für anfänger.
weil printf nicht in eine oo sprache passt. du musst immer den typen kennen, und das ist nicht akzeptabel.
nciht akzeptabel? Komm junge geh PHP programmieren, wenn du die die typen nicht merken kannst.
Ich habe ehrlich gesagt keine lust mehr darüber zu diskutieren.
Und auch kann ich nicht jede antwort von 100 leuten beantworten.
-
@newkid:
ja, ich zocke bei NBS (rtcw:et)
-
K.a schrieb:
Shade Of Mine schrieb:
C++ wird als erweiterung angesehen - das ist es doch auch oder etwa nicht? D ist nicht nur eine erweiterung, z.b. existiert kein preprozessor. Du kannst als C code nicht mit dem D compiler compilieren.
Ich kann auch nicht jeden C code mit einem c++ compiler kompilieren.
ach ja? nicht? welchen denn nicht bitte schön?
hier hast du dich wohl "disqualifiziert".alles was in C99 dazugekommen ist kannst du in c++ nicht benutzen.
typedef struct Color { int r; int g; int b; }color; funktion(10,100, (color){ .r = 255, .g = 255, .b = 255}, "hello world!");
K.a schrieb:
Shade Of Mine schrieb:
cout finde ich unschön! Warum nicht einfach printf nehmen sondern alles abstaktieren und verwirrend machen für anfänger.
weil printf nicht in eine oo sprache passt. du musst immer den typen kennen, und das ist nicht akzeptabel.
nciht akzeptabel? Komm junge geh PHP programmieren, wenn du die die typen nicht merken kannst.
ja wie jetzt? woher soll ich denn den typen kennen wenn er dynamisch während des programmablaufes festgelegt wird?
es scheint so als würdest du c/c++/d/java überhaupt nicht gut genug kennen um über sie urteilen zu können. du gibst einfach wieder was du schonmal irgendwo aufgeschnappt hast.
-
Helium schrieb:
foreach ist eine derart häufig vorkommende Aufgabe das sich ein leicht erweiterbares Sprachkonstrukt IMHO lohnt. Aber es sind für D2.0 Sather-artige Iteratoren im Gespräch. Also kein Problem mehr mit Rubys iterations-Model (das AFAIK das von Icon ist) mitzuhalten.
Ich kenne Sathers Iteratoren nicht, deshalb ist das hier jetzt vielleicht eine Fehlinterpretation - aber wenn man sich ein schöneres foreach selbst schreiben könnte, als das jetzt über Lambdas geht, hat man dann nicht zwei parallele Features? Deshalb wäre mir eine Sprache lieber, die gleich von vornherein auf einem Feature aufbaut (und so verstehe ich Ruby in dem Punkt, auch wenn ich das Sprachdesign ansonsten nicht sehr mag).
Wenn D es schafft, solche wichtigen Features im Nachhinein nahtlos zu integrieren, Respekt. Sowas würde die STL in C++ nochmal richtig aufwerten, IMHO.
-
K.a schrieb:
Shade Of Mine schrieb:
Lieber ein paar wenige gute als viele die von sich sagen sie wären solch tolle programmierer aber in wirklichkeit kennen sie den unterschied zwischen einer compilersprache mit echten funktionen wie C nicht von einer interpretersprache wie PHP auseinander.
PHP hat keine echten funkionen?
keine richtigen funktionen wie in C, die wirklich in assembler code mit sprungmarken umgewandelt werden. Sondern interpretierte code stücke.
es gibt nen php compiler der hinterher ne binary ausspuckt. hat php also nun richtige funktionen oder nicht?
-
@K.a
Ich musste echt teilweise lachen, als ich deinen Post gelesen hab :).K.a schrieb:
Shade Of Mine schrieb:
cout finde ich unschön! Warum nicht einfach printf nehmen sondern alles abstaktieren und verwirrend machen für anfänger.
weil printf nicht in eine oo sprache passt. du musst immer den typen kennen, und das ist nicht akzeptabel.
nciht akzeptabel? Komm junge geh PHP programmieren, wenn du die die typen nicht merken kannst.
Da sollte sich aber jemand schleunigst mal ein OO-Programmierungs Buch kaufen :P.
-
K.a schrieb:
nciht akzeptabel? Komm junge geh PHP programmieren, wenn du die die typen nicht merken kannst.
und du lern mal oop
Und auch kann ich nicht jede antwort von 100 leuten beantworten.
und denk mal nach, warum du so alleine dastehst
keine richtigen funktionen wie in C, die wirklich in assembler code mit sprungmarken umgewandelt werden. Sondern interpretierte code stücke.
php wird kompiliert. und zwar zu byte code.
eine funktion definiert sich aber nicht dadurch, dass sie sprungmarken beinhaltet... tatsaechlich waeren sonst viele c funktionen garkeine funktionen weil sie ja geinlinet werden...
-
darf ich mal was lustiges anmerken: ihr werft euch alles mögliche an den kopf, aber das stärkste argument gegen D ist wohl, dass die sprache nun seit mehr als 2 jahren fertig ist, aber benutzen tut sie nimand.
warum wohl?
(oder anders gesagt: wenn ich bereits einen ferrari mit 550 ps habe, werde ich mir wahrscheinlich keinen mit 560 kaufen, ausser ich habe schwierigkeiten mein geld zu verpulvern)
-
Korbinian schrieb:
darf ich mal was lustiges anmerken: ihr werft euch alles mögliche an den kopf, aber das stärkste argument gegen D ist wohl, dass die sprache nun seit mehr als 2 jahren fertig ist, aber benutzen tut sie nimand.
Darum geht es doch garnicht.
warum wohl?
weil D keine userbase hat.
D ist nett, hat aber kein killerfeature.(oder anders gesagt: wenn ich bereits einen ferrari mit 550 ps habe, werde ich mir wahrscheinlich keinen mit 560 kaufen, ausser ich habe schwierigkeiten mein geld zu verpulvern)
Klar. es geht ja auch nicht darum ob D der nachfolger von C++ ist, sondern ob D etwas taugt. und selbst darum geht es hier nicht wirklich...
-
Wieso wird hier eigentlich noch mit "K.a" diskutiert? Ist ja wohl mehr als offensichtlich, dass er keine Ahnung hat.
-
PHP hat keine echten funkionen?
keine richtigen funktionen wie in C, die wirklich in assembler code mit sprungmarken umgewandelt werden. Sondern interpretierte code stücke.
Na dann pack ich doch einfach mal einen C-Interpreter aus (sag nicht die gäbe es nicht, die gibt es!) und schwups ist es bei C genau so. Also das Ausführungsmodell ist kein Kriterium. Warum sollte man keinen PHP-compiler bauen?
Ich kann auch nicht jeden C code mit einem c++ compiler kompilieren.
ach ja? nicht? welchen denn nicht bitte schön?
hier hast du dich wohl "disqualifiziert".In C beduetet "void foo();" die deklaration einer Funktion mit einr unbekannten Anzahl von Argumenten, in C++ ist es die Deklaration einer Funktion mit einer unbekannten Anzahl von Argumenten. Das C++ Äquivalent säge so aus: "void foo(...);".
Solche kleinen Unterschiede gibt es nunmal und die haben mich schon daran gehindert C-Code unverändert in C++ zu verwenden.Aber ich kann den C-Code ja auch einfach durch einen C-Compiler schicken und dann mit meinem C++-Code linken. Moment mal, das geht ja auch mit D. Hmm.
darf ich mal was lustiges anmerken: ihr werft euch alles mögliche an den kopf, aber das stärkste argument gegen D ist wohl, dass die sprache nun seit mehr als 2 jahren fertig ist, aber benutzen tut sie nimand.
Nope. Wir sind immer noch nicht bei "Version 1.0". Wir sind zwar nah dran, aber die aktuelle Version ist 0.111.
-
Korbinian schrieb:
@newkid:
ja, ich zocke bei NBS (rtcw:et)lol ruebe sag halt gleich das du es bist
wusste gar nicht das du MOD hier bistGruss
dude
-
oweh, und du versuchst dich am programmieren...
naja, man hört sich (wenn ich mal wieder zock, bin zur zeit ziemlich inactive)