Schon die 3.5 "Erweiterungen" von C# waren ziemlich vermurkst:
Erweiterungsmethoden sind ja eine nette Idee die ich prinzipiell auch
gut fände, wenn, ja wenn das nicht so grauenhaft umgesetzt wäre. Denn
nun sind ausschließlich statisch gebundene Exemplarmethoden möglich,
keine Eigenschften, keine statischen Methoden/Eigenschaften, keine
Klassen, keine sonstigen Deklarationen. Mit einem einfachen "extend
class ..." wäre das alles kein Problem (das würde auch eine bessere
Steuerung der Sichtbarkeit von Erweiterungen erlauben). So bleibt es
einem einfach verwehrt, die Klasse System.Math mit einer
Implementation für komplexe Zahlen samt zugehörigen
Funktionsüberladungen für Sqrt, Log, Exp, Sin etc. zu beglücken.
Constraints für generische Parameter sind auch eine gute Idee (stammt
sogar noch aus C# 2.0). Aber auch hier wurde die Sache vergeigt.
Statt die Bedingungen als "Aussagen über Typen" zu interpretieren
sind nur ganz wenige Bedingungen möglich, nämlich
Standardkonstruktor, Ableitung, Schnittstellenimplementation sowie
Referencetype bzw. Valuetype Constraints. Nicht möglich sind
insbesondere Constraints für nicht-Standardkonstruktoren, auf
Basistypen sowie Einschränkungen auf geschachtelte Klassen. Die
Ausdrucksfähigkeit ist damit gegenüber C++ erheblich eingeschränkt.
Das mekt man, sobald man versucht etwa die C++ STL nach C# zu
portieren.
Lambda-Ausrücke sind auch so eine nette Idee, die wohl nur wegen LINQ
eingeführt wurde. Dabei bietet C# 1.0 bereits die Möglichkeit,
Ausdrucksbäume per Operatorüberladung zu erzeugen. Das Feature wäre
also garnicht notwendig gewesen. Ein echter Fortschritt wäre dagegen,
wenn anstelle von Ausdrücken gleich komplette Ableitungsbäume von
beliebigem gültigem C#-Code verwendet werden könnten. Dann wäre es
nämlich möglich, etwa Stored Procedures (aber auch Javascript) in C#
zu schreiben. Der C# Compiler hätte die komplette Analyse
durchgeführt. Lediglich der Codegenerator hätte für die verschiedenen
Anwendungen noch implementiert werden müssen. So hat man lediglich
die Möglichkeit, z.B. einen LINQ Expression Tree in SQL zu
übersetzen.
LINQ selbst ist lediglich "syntactic sugar" wie ich es mal in einem
Blog gelesen habe. Die Mittel der Sprache lassen die Implementation
derartiger Funktionalität auch so zu. Das zeigt allein schon die
Tatsache, dass der C# Compiler LINQ Konstrukte in normale
Methodenaufrufe von Objekten umstrukturiert.
Auch anonyme Typen werden lediglich für LINQ verwendet und sind auch
nur wegen der missglückten LINQ Definition erforderlich. Welchen
Nutzen sie darüber hinaus für den Entwickler haben sollen erschließt
sich mir nun wirklich nicht.
Wenn die angekündigten Features genauso "überlegt" umgesetzt werden
wie in der Vergangenheit wird C# echt zu einer verkorksten
Programmiersprache.
MS Blick scheint stark durch Scheuklappen beeinträchtigt zu sein. C++
war - und ist - so erfolgreich, weil sie sich auf keine
Anwendergruppe beschränkt und keinen überflüssigen Ballast in Form
von Features die bereits von anderen Sprachelementen abgedeckt werden
mit sich herumschleppt. Es gibt eben nicht nur Entwickler für Office-
und Webanwendungen. Die total verkorksten APIs der Vergangenheit,
insbesondere von MS Office werden nicht dadurch verbessert, dass die
neu entwickelte Technik nun genauso verkorkst wird. Aber vieleicht
will MS die Anwender ja auch nicht enttäuschen, die sind sowas ja
gewohnt *resignier*.
Mir scheint "C sharp" entwickelt sich langsam zu "C flat".
MfG
RZ
Erweiterungsmethoden sind ja eine nette Idee die ich prinzipiell auch
gut fände, wenn, ja wenn das nicht so grauenhaft umgesetzt wäre. Denn
nun sind ausschließlich statisch gebundene Exemplarmethoden möglich,
keine Eigenschften, keine statischen Methoden/Eigenschaften, keine
Klassen, keine sonstigen Deklarationen. Mit einem einfachen "extend
class ..." wäre das alles kein Problem (das würde auch eine bessere
Steuerung der Sichtbarkeit von Erweiterungen erlauben). So bleibt es
einem einfach verwehrt, die Klasse System.Math mit einer
Implementation für komplexe Zahlen samt zugehörigen
Funktionsüberladungen für Sqrt, Log, Exp, Sin etc. zu beglücken.
Constraints für generische Parameter sind auch eine gute Idee (stammt
sogar noch aus C# 2.0). Aber auch hier wurde die Sache vergeigt.
Statt die Bedingungen als "Aussagen über Typen" zu interpretieren
sind nur ganz wenige Bedingungen möglich, nämlich
Standardkonstruktor, Ableitung, Schnittstellenimplementation sowie
Referencetype bzw. Valuetype Constraints. Nicht möglich sind
insbesondere Constraints für nicht-Standardkonstruktoren, auf
Basistypen sowie Einschränkungen auf geschachtelte Klassen. Die
Ausdrucksfähigkeit ist damit gegenüber C++ erheblich eingeschränkt.
Das mekt man, sobald man versucht etwa die C++ STL nach C# zu
portieren.
Lambda-Ausrücke sind auch so eine nette Idee, die wohl nur wegen LINQ
eingeführt wurde. Dabei bietet C# 1.0 bereits die Möglichkeit,
Ausdrucksbäume per Operatorüberladung zu erzeugen. Das Feature wäre
also garnicht notwendig gewesen. Ein echter Fortschritt wäre dagegen,
wenn anstelle von Ausdrücken gleich komplette Ableitungsbäume von
beliebigem gültigem C#-Code verwendet werden könnten. Dann wäre es
nämlich möglich, etwa Stored Procedures (aber auch Javascript) in C#
zu schreiben. Der C# Compiler hätte die komplette Analyse
durchgeführt. Lediglich der Codegenerator hätte für die verschiedenen
Anwendungen noch implementiert werden müssen. So hat man lediglich
die Möglichkeit, z.B. einen LINQ Expression Tree in SQL zu
übersetzen.
LINQ selbst ist lediglich "syntactic sugar" wie ich es mal in einem
Blog gelesen habe. Die Mittel der Sprache lassen die Implementation
derartiger Funktionalität auch so zu. Das zeigt allein schon die
Tatsache, dass der C# Compiler LINQ Konstrukte in normale
Methodenaufrufe von Objekten umstrukturiert.
Auch anonyme Typen werden lediglich für LINQ verwendet und sind auch
nur wegen der missglückten LINQ Definition erforderlich. Welchen
Nutzen sie darüber hinaus für den Entwickler haben sollen erschließt
sich mir nun wirklich nicht.
Wenn die angekündigten Features genauso "überlegt" umgesetzt werden
wie in der Vergangenheit wird C# echt zu einer verkorksten
Programmiersprache.
MS Blick scheint stark durch Scheuklappen beeinträchtigt zu sein. C++
war - und ist - so erfolgreich, weil sie sich auf keine
Anwendergruppe beschränkt und keinen überflüssigen Ballast in Form
von Features die bereits von anderen Sprachelementen abgedeckt werden
mit sich herumschleppt. Es gibt eben nicht nur Entwickler für Office-
und Webanwendungen. Die total verkorksten APIs der Vergangenheit,
insbesondere von MS Office werden nicht dadurch verbessert, dass die
neu entwickelte Technik nun genauso verkorkst wird. Aber vieleicht
will MS die Anwender ja auch nicht enttäuschen, die sind sowas ja
gewohnt *resignier*.
Mir scheint "C sharp" entwickelt sich langsam zu "C flat".
MfG
RZ