Hab mir eben durchgelesen wie die Zukunft von C# aussieht. C# 4.0 sieht sehr vielversprechend aus!
- Dynamische Objekte, die sich scheinbar im Duck Typing-Stil verhalten.
- Optionale Argumente und Argumente mit Namen aufrufen wie bei Python (macht Funktionsüberladung in vielen Fällen obsolet)
Damit will sich die CLR wohl besser mit IronPython und IronRuby verstehen. Der Schritt ist absolut richtig, finde ich! C# wird mir immer lieber als Java. Es fühlt sich auch in der Programmierung wesentlich moderner und aufgeräumter an.. außerdem finde ich die Dokumentation viel übersichtlicher.
Was meint ihr dazu?
C# wird immer dynamischer?
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
...von mir nach Offtopic verschoben.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Ich dachte nur es würde unter Links und Tutorials passen, weil ich ursprünglich nur den Link posten wollte =/ Verzeih.gerold hat geschrieben:...von mir nach Offtopic verschoben.
Ja, finde ich auch.BlackVivi hat geschrieben:C# wird mir immer lieber als Java. Es fühlt sich auch in der Programmierung wesentlich moderner und aufgeräumter an.. außerdem finde ich die Dokumentation viel übersichtlicher.
Es erscheint mir zwar auch riesig und teilweise sehr, sehr unübersichtlich, aber .NET/Mono sind mir trotzdem lieber als Java.
Vor allem, weil .NET-Apps auf dem Desktop nicht ganz so langsam wie viele, viele Java-Programme sind.
Gruß!
Microsoft hat diese Möglichkeiten nicht eingeführt, um dynamische Programmierung in C# zu ermöglichen, sondern um die wohldefinierte Übergabe von Objekten aus dynamischen Sprachen wie Python nach C# zu ermöglichen. Außerdem geht es Microsoft wohl darum, COM-Programmierung zu erleichtern. Daher auch konstante Referenzparameter und Standardparameter ...
Dynamische Typen sind in C# kein Konzept, sondern lediglich der Interoperabilität geschuldeter syntaktischer Zucker für Reflection und COM. Daher würde ich in C#-Programmen vom Gebrauch dynamischer Typen absehen, und sie nur dort verwenden, wo sie hilfreich oder gar nötig sind, nämlich bei COM-Objekten und Objekten aus dynamischen Sprachen. Alles andere hieße nur, gegen die Sprache zu programmieren, und die Möglichkeiten des Compilers bzw. der CLR nicht auszunutzen. Wenn man wirklich dynamisch programmieren will, ist und bleibt C# nicht die richtige Sprache.
Edit: Die angebliche Langsamkeit von Java-Desktop-Programmen ist schon seit geraumer Zeit mehr Vorurteil den Wirklichkeit.
Dynamische Typen sind in C# kein Konzept, sondern lediglich der Interoperabilität geschuldeter syntaktischer Zucker für Reflection und COM. Daher würde ich in C#-Programmen vom Gebrauch dynamischer Typen absehen, und sie nur dort verwenden, wo sie hilfreich oder gar nötig sind, nämlich bei COM-Objekten und Objekten aus dynamischen Sprachen. Alles andere hieße nur, gegen die Sprache zu programmieren, und die Möglichkeiten des Compilers bzw. der CLR nicht auszunutzen. Wenn man wirklich dynamisch programmieren will, ist und bleibt C# nicht die richtige Sprache.
Edit: Die angebliche Langsamkeit von Java-Desktop-Programmen ist schon seit geraumer Zeit mehr Vorurteil den Wirklichkeit.
Objekte in als "dynamic" getypen Varianten verhalten sich nicht nur scheinbar (was impliziert das es nicht der Fall ist) dynamisch sondern die statische Typprüfung ist für diese Objekte wird vom Compiler aufgehoben und stattdessen werden die bereits schon immer vorhandenen Möglichkeiten zur Reflection benutzt, ohne das man für jeden Methodenaufruf nun 5+ hässliche Zeilen Code schreiben muss. Kleine Ursache, große Wirkung.
Benannte Parameter sind ebenfalls nur ein Compilertrick. Bei Optionalen Argumenten bin ich mir nicht ganz sicher, ob der Compiler einfach alle Varianten in Form von überladenen Methoden definiert oder ihm die VM hier hilft und tatsächlich die .NET VM erweitert wurde.
Stefan
Benannte Parameter sind ebenfalls nur ein Compilertrick. Bei Optionalen Argumenten bin ich mir nicht ganz sicher, ob der Compiler einfach alle Varianten in Form von überladenen Methoden definiert oder ihm die VM hier hilft und tatsächlich die .NET VM erweitert wurde.
Stefan