spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ja, jeder wie er mag. Ich find C# zwar sehr nett aber was die Flexibilität angeht sieht C# aus gewollt aber nicht gekonnt. Ich meine das jetzt nicht negativ, ich finde es sehr gut das C# sich soviel ab geguckt hat und das mittlerweile so viel möglich ist. Nur würde ich nie auf die Idee kommen C# als Skriptsprache zu benutzen, dafür ist sie mir dann doch noch zu unflexibel.

Daher noch mal: Ja, mit C# geht das auch (fast) alles aber es wirkt wie gewollt aber nicht gekonnt... (meine Meinung)

Zum Beispiel was genau sieht denn aus wie "gewollt, aber nicht gekonnt"? Denn C# integriert viele "neue Features" nativ und wirkt im Gegensatz zu C++ meiner Meinung nach ganz und gar nicht "nachgerüstet".
Konkrete Beispiele fänd ich interessant, danke.

@BlueCobold: genau das würde mich auch interessieren.
warum programmiert man dann (deiner Meinung nach) nicht in JavaScript, wenn die Sprache flexibler und einfacher ist? Ich meine es gibt so Tendenzen (http://www.commonjs.org/ und Co.) aber es gibt auch sehr gegenläufige Tendenzen wie GWT. Groovy sehe ich zum Beispiel momentan recht viel in der Java Welt. Ich als leidenschaftlicher Programmierer würde diese Strömung gerne nachvollziehen vielleicht fällt dir ja eine gute Erklärung ein.

Ja, aus der Sicht eines C++ Programmierers sieht C# sehr flexibel aus! Aber C# ist keine Skriptsprache und wird es auch nie werden (was auch gut ist).

Skriptsprachen haben (meistens) keine Typsicherheit. C# hat eine, auch mit "var"!

Und das hier ist doch wohl wie gewollt aber nicht gekonnt:

da finde ich "obj.func = function() { return true; }" 10 mal "gekonnter".

Die Diskussion ist doch eigentlich dumm, die Frage ist doch wie: "Warum ist ein Apfel nicht genauso gut wie eine Birne?". Da können wir ewig weiter reden...

Naja, ein wirklich objektiver Grund ist das zwar meiner Meinung nach nicht, sondern nur Syntax-Geplänkel, aber das musst Du letztendlich selbst entscheiden. Und wenn Du meinst, dass JavaScript mit weniger Features besser sei, weil es "gekonnter" wirkt, dann ist das Deine freie Wahl.

Ähm, es geht doch um die Syntax? IronJS läuft doch auf der DLR von .NET. Hat also (denke ich) eine ähnliche Performance wie C# (mit den selben Syntax Spielereien, die Teilweise sicherlich Performance fressen). Zumindest ist das meine Annahme, falls dem nicht so ist lass ich mich gerne belehren.

Und es geht nicht darum das JavaScript besser ist sondern darum ob es besser geeignet ist, und das würde ich sagen, ist in diesem Fall (Sprache zum Skripten in Spielen die auch von nicht Programmierern benutzt wird) so.

Ich sehe da aber nicht, wieso eine andere Syntax da jetzt mehr geeignet ist oder warum fehlende Typsicherheit da jetzt besser sein soll als existierende Typsicherheit. Und ein richtig objektives Argument außer "Ich will aber!" habe ich da jetzt auch irgendwie noch nicht gesehen. Klar, das ist letztendlich das wichtigste Argument, aber nicht unbedingt ein logisches.
Wenn Du keine Meinungen oder Argumente hören willst, dann sag es einfach.

Ok, jetzt verstehe ich was du mit "wie gewollt aber nicht gekonnt" meinst. Dann läuft es wohl darauf hinaus, dass wir unterschiedliche Ansichten über das Verhältnis von Implementierungsaufwand einer Scriptsprache und den Mehraufwand, den man durch die etwas komplexeren Ausdrücke durch C#-Scripting bekommen würde, haben.
Ich persönlich halte nicht so viel von Scriptsprachen, weil das dann wieder weitere Sprachen sind, die ich lernen muss. Ich empfinde Scriptsprachen als Relikt aus Tagen in denen man noch nicht mit flexiblen Laufzeitumgebungen gearbeitet hat. Ich mag da die "Common Language Specification/Runtime" Idee wesentlich lieber.
BTW: das sieht auch wie eine nette JS Einbindung für .NET aus: http://javascriptdotnet.codeplex.com/

Jup, Script-Sprachen wurden halt eingeführt und benötigt, weil es nicht möglich war die gleiche komplexe Sprache dynamisch zur Laufzeit zu verwenden um Verhalten zu ändern oder zu erweitern. Das ist mit Java oder C# aber beispielsweise absolut kein Problem mehr und macht jede andere interpretierte Sprache daher absolut überflüssig.

Naja oder besser: Man kann sich aussuchen in welcher Sprache man entwickelt solange die in Bytecode für die CLR/JRE kompilieren kann. Bei der JVM ist das ja zum Beispiel auch ein ganzer Haufen: JPython, Scala, Clojure, Groovy, JRuby und ein paar mehr. Hauptsache der boilerplate code fällt weg.