Was haltet ihr von C# 3.0?

Manuel

KeinKritiker schrieb:

Kritiker schrieb:

Warum nicht folgendes?

weils mehr und hässlicher is?

Wo ich ihm als schreibfauler Mensch zustimmen würde. Und überleg mal selbst, was du im Nachhinein schneller nachvollziehen kannst

Greetz :xmas1:

Wo ich ihm als schreibfauler Mensch zustimmen würde. Und überleg mal selbst, was du im Nachhinein schneller nachvollziehen kannst

Für mich geht nich ganz klar heraus, wen du hier meinst, also wem du zustimmst,
ich nehm aber einfach mal an, dass du damit KeinKritiker zustimmst.

Ich würde wie bereits gesagt meine Version eher verstehen, da anonyme Methoden und
Iteratoren für mich nach einiger Zeit bereits vertraut sind, anderen wird es sicher
ähnlich gehen.

Natürlich ist es etwas mehr und es sieht auch nicht ganz so "schön" aus, aber
meiner Meinung rechtfertigt dass keine zusätzlichen Sprachfeatures. Da ist es
wesentlich vernünftiger eben die Klasse EnumerableUtils zu vervollständigen,
bzw. weitere Klassen einzuführen um den Funktionsumfang nachzubilden.

Was können Lambda Expressions, was anonyme Methoden nicht auch können? Je mehr
ich dafür nachdenke, desto sicherer erscheint mir, dass ich C# 3.0 "boykottieren" werde.

Würde jetzt gerne mal ein paar wirkliche Vorteile hören, nicht dass ich
mir jetzt noch Visual Studio wieder runtergeb bei den Aussichten ..

grüße

Manuel

Gut. Du hast ja an sich auch recht - neue Sprachfeatures rechtfertigt das nicht - und keine zwingt dich auf 3.0 umzusteigen (was du dann bestimmt eh machst - aber egal). Trotzdem find ich den Ansatz mit den Querys toll, da das IMO trotzdem im Code besser aussieht als dein Ansatz. Zugegeben - ich hätt das Problem noch anders (evtl. nicht so stylisch) gelöst ...

Btw: Meine Seite is, wie schon von dir vermutet, die vom NichtKritiker

Greetz :xmas1:

Kritiker schrieb:

Am allerschlimmsten find ich ja die Verwendung von 'var' zur Deklaration von
Variablen. Schlimm genug dass VB.NET entwickelt wurde, aber dass es Einfluss
auf C# hat .. einfach schrecklich.

var finde ich cool. Ich stand dem mal eine Zeit lang eher kritisch gegenüber, aber eigentlich ist daran nicht viel auszusetzen. Das Beispiel var i = 5 ist natürlich nonsense, weil man int hier genausogut schreiben kann und ich finde es zu unstatisch, alles extrem flexibel mit var zu schreiben. var ist auch eher für komplexe Rückgabewerte gedacht, z.B. System.Collections.Generic.IEnumerator<FooBar>. Da erstmal using hinzu und dann mit Typparametern.... und dabei will ich die Variable vielleicht nur gleich wieder weitergeben.... da sehe ich die großen Vorteile. Am meisten würde man dieses Feature wohl in C++ brauchen können, aber auch in C# sehe ich ein paar sinnvolle Anwendungen davon.

Mindestens genau so schlimm ist meiner Meinung nach die Möglichkeit statische
Methoden so zu definieren, dass man sie wie Instanzmethoden anderer
Klassen aufrufen kann um zum Beispiel den Datentyp String zu erweitern.

Darüber muss ich mir noch Gedanken machen. Bei Instanzmethoden ist mein erstes Gefühl, dass es zu viel Gepfusche sein könnte. Ich sehe aber kein Problem bei einem statischen String.CompareItMyWay(String, String). Zumindest die Kapselung wird aber dadurch nicht verletzt, da diese hinzugefügten Methoden nur öffentliche Member benutzen dürfen. Das ist mal das allerwichtigste.

Ich fand partielle Typen in der 2.0er Version schon schlimm

Die sind godlike. Ich arbeite viel mit nested classes und es ist ein Albtraum, alles in die Datei der äußeren Klasse schreiben zu müssen... amsonsten benutze ich das Feature auch nicht großartig, weil ich denke, dass Klassen in erster Linie klein sein sollen. Aber zusammen mit nested classes macht dieses Feature wirklich Sinn.

Das LINQ Zeug sieht auch sehr interessant aus, auch wenn ich mir nicht vorstellen kann, das oft zu brauchen. Es macht aber den Code außerordentlich lesbar, bzw. um es anderweitig lesbar zu haben, müsste man Selektion und Projektion in mindestens eine Methode mit sprechendem Namen auslagen.

Artchi

Optimizer schrieb:

Am meisten würde man dieses Feature wohl in C++ brauchen können

Wird sich auto im nächsten Standard nennen.

Ich dachte, das wird nicht kommen, zum Leidwesen volkard's? Naja, wenn es jetzt doch kommt, viel Spaß damit. Sinnvoll ist es ja.

Der C# 3.0 Standard ist einfach genial.
Ich kann dich nicht wirklich verstehen. Vorallem, weil deine Kritik auf Pseudoargumenten beruht. Die Einführung von echten Lambdamethoden in C# ist ne coole Sache. Sie vereinfachen die Softwareentwicklung enorm und lassen sich zudem auch noch in ASTs zerlegen (geht mit delegates nicht!). Das konnten bisher nur Leute, die mit funktionalen Programmiersprachen gearbeitet haben (LISP macht beispielsweise auch keinen Unterschied mehr zwischen Daten und Code). Funktionale Programmierung hat nun nach vielen Jahren endlich den Mainstream erreicht.
Ich glaube, du bist dir noch nicht der Möglichkeiten bewusst geworden. Schon mal funktional programmiert? Scheinbar nicht, denn dann hättest du dir diesen Thread sparen können.

Das neue Var-Schlüsselwort ist bei Trivialdeklarationen, wie var i = 10, witzlos. Es ist erst in Zusammenhang mit anonymen Typen sinnvoll. (Spec nochmal genau lesen, nachdenken und dann hoffentlich ein Aha-Erlebnis haben)

Und mit deinem Beispielcode hast du dir selbst ein Bein gestellt: Die C# 3.0 Variante ist 1. deutlich kürzer, 2. viel verständlicher und 3. wartbarer.
Bei der "alten" C# 2.0 Version muss ich erst 3 mal hinschauen, bevor ich weiß, was sie eigentlich macht

Rutsch gut :xmas1:

Schon mal funktional programmiert? Scheinbar nicht, denn dann hättest du dir diesen Thread sparen können.

Nein, ich hab tatsächlich noch nicht funktional programmiert und kann insofern nicht korrekt beurteilen, in welchen Fällen man Nutzen daraus ziehen kann.

Ich hab allerdings auch nichts gegen funktionale Programmierung gesagt. Was mir daran nicht gefällt ist, dass:

Anonyme Methoden einen Ansatz zur funktionalen Programmierung bieten sollten, und dass nun doch ganz übernommen wird, 2 Sprachmittel für das selbe Ergebniss (bitte jetzt keine Beispiele ala: Es gibt ja auch for und while Schleifen, sowas spielt meiner Meinung nach in einer anderen Liga ..)
Man doch genau so gut gleich für diese wenigen Klassen eine funktionale Sprache verwenden könnte, wozu gibt es denn F# und Co? Warum eine Universal-Sprache entwickeln, die letztendlich überquillt an Features?

Und mit deinem Beispielcode hast du dir selbst ein Bein gestellt: Die C# 3.0 Variante ist 1. deutlich kürzer, 2. viel verständlicher und 3. wartbarer.
Bei der "alten" C# 2.0 Version muss ich erst 3 mal hinschauen, bevor ich weiß, was sie eigentlich macht

Nochmal der effektive Vergleich:

// 7 Zeilen
foreach (char ch in EnumerableUtils.Where(s,
                        delegate(char c) {
                            return Char.IsUpper(c);
                        })
                   ) {
    Console.WriteLine(ch);
}

// 4 Zeilen
foreach (char ch in s.Where(c => Char.IsUpper(c))) 
{
    Console.WriteLine(ch);
}

3 Zeilen Differenz würde ich nicht als deutlich kürzer oder länger bezeichnen. Bzw. ich würd gern wissen, inwiefern die LINQ Version wartbarer ist?

Optimizer schrieb:

Die sind godlike. Ich arbeite viel mit nested classes und es ist ein Albtraum, alles in die Datei der äußeren Klasse schreiben zu müssen... amsonsten benutze ich das Feature auch nicht großartig, weil ich denke, dass Klassen in erster Linie klein sein sollen.

Nur weil du Nested Classes gern in eigene Dateien aufteilst ist das Feature "godlike"? Würde es nicht auch eine IDE tun, die die aufgesplitteten Dateien vorm Kompilieren in eine temporäre schreibt?

grüße
Kritiker

P.S: Ich muss allerdings zugeben, langsam finde z.B: 'var' auch nicht mehr so
schlimm, bin also nicht so dickköpfig und sturr, wie ich vielleicht rüberkomm.

Kritiker schrieb:

3 Zeilen Differenz würde ich nicht als deutlich kürzer oder länger bezeichnen. Bzw. ich würd gern wissen, inwiefern die LINQ Version wartbarer ist?

Wartbarer ist die LINQ-Version ganz bestimmt, weil SQL-ähnliche Syntax für das extrahieren von Daten aus einer Datenstruktur sehr intuitiv ist. Selbst ein ungeübter Programmierer kann sofort erkennen, worum es geht. Um den von Hand geschriebenen Code zu erkennen, muss man schon sehr viel genauer hinschaun. Wie gesagt, ich denke nicht, dass ich sehr oft Nutzen aus diesem Feature ziehen kann. Ich fand das Video auf der verlinkten Seite schon recht beindruckend. Natürlich muss man jetzt doch langsam mal anfangen, damit aufzuhören, ständig neue Features hinzuzufügen. Ich will kein C++ light, sondern eine Sprache, die von der Komplexität her ungefähr zu 3/4 auf der Skala an C++ und zu 1/4 an Java liegt und dabei einige affige Sachen nicht hat. Das gelingt IMHO bis jetzt ganz gut, aber nach 3.0 würde ich auch sagen, dass Vorsicht angebracht ist.

Optimizer schrieb:

Die sind godlike. Ich arbeite viel mit nested classes und es ist ein Albtraum, alles in die Datei der äußeren Klasse schreiben zu müssen... amsonsten benutze ich das Feature auch nicht großartig, weil ich denke, dass Klassen in erster Linie klein sein sollen.

Nur weil du Nested Classes gern in eigene Dateien aufteilst ist das Feature "godlike"? Würde es nicht auch eine IDE tun, die die aufgesplitteten Dateien vorm Kompilieren in eine temporäre schreibt?

Vielleicht, vielleicht aber auch nicht. Man bräuchte gewisse Einstellmöglichkeiten bei der IDE und die IDE bräuchte eine Menge Logik, um zu verifizieren, ob das Mergen so sein darf. So prüft der Compiler, dass eine Klasse nicht in der einen Datei abstract und in der anderen sealed ist und ich mache mich nicht abhängig von der u.U. komplexen Logik, die eine solche IDE zur Verfügung stellt und die ich bei anderen vielleicht nicht habe. Oder man kann natürlich nur textuell includen. Aber zu was für Problemen das führt, haben die Sprachdesigner und Programmierer inzwischen alle gesehen und es ist von Anfang an oberstes Designziel gewesen, darauf nicht angewiesen zu sein.

Und für mich sind die nested classes wirklich allein schon ein Grund genug. Mich stört das in Java krassest, fette Source-Dateien zu haben, weil ich die inneren Klassen nicht auslagern kann.

Kritiker schrieb:

Anonyme Methoden einen Ansatz zur funktionalen Programmierung bieten sollten, und dass nun doch ganz übernommen wird, 2 Sprachmittel für das selbe Ergebniss (bitte jetzt keine Beispiele ala: Es gibt ja auch for und while Schleifen, sowas spielt meiner Meinung nach in einer anderen Liga ..)

Beide sind miteinander kompatibel, was aber noch lange nicht bedeutet, dass sie gleichwertig sind. Die Lambdas aus C# 3.0 sind mächtiger als die anonymen Delegaten. Sie lassen sich nämlich in ASTs zerlegen. Auch die Rückübersetzung von AST zu Lambda wird wohl möglich sein. (Ist aber leider im Spec nicht genau beschrieben). Daraus resultiert auch die ganze "Magie", die hinter LINQ steckt, um deinen Code z.B. in gleichwertige SQL, XPath Kommandos umzuwandeln. Auch für genetische Programmierung und polymorphe Algorithmen könnte man das nutzen (auch wenn das jetzt zwei eher abgehobene Beispiele sind ).

Kritiker schrieb:

Man doch genau so gut gleich für diese wenigen Klassen eine funktionale Sprache verwenden könnte, wozu gibt es denn F# und Co? Warum eine Universal-Sprache entwickeln, die letztendlich überquillt an Features?

Ich selbst habe überwiegend gute Erfahrungen mit Misch-Sprachen gemacht. Also die imperativ und funktional sind. Nimm Phyton mal einfach als Beispiel, dort funktioniert das wunderbar...