Was haltet ihr von C# 3.0?

[Manuel]

Also meiner Meinung nach sind die Ansätze im neuen Konzept toll.

Das var erspart einem ne Menge Schreibarbeit (die man sich im VS2005 zwar so auch sparen kann, aber trotzdem) und geht (soweit ich blicken kann) in keinster Weise gegen die Benutzbarkeit oder den Umfang der Sprache.

Außerdem sind die Queries IMO absolut genial ^^

Greetz :xmas1:

[Kritiker]

Glaube die anonymen Typen hast du net ganz verstanden "var" bedeutet nicht das der Datentyp variabel ist!

Mir ist schon klar, dass es nicht variabel ist, bzw. Typsicherheit trotzdem
garantiert ist. Aber trotzdem gilt doch, dass man den Datentyp kennen muss
um zu wissen auf welche Propertys und Methoden man zugreifen kann (Auch hier
gilt wieder, dass es wohl mit Visual Studio kein Problem sein wird).

Aber wenn du per Linq irgend nen Abfrage machst und net weißt was für ein Datentyp zurückkommt, dann nimmst du halt ne var Variable und nach der Abfrage hat diese Variable einen ganz bestimmten Typ den du auch nicht mehr ändern kannst!

Warum nicht hier auch Features einer IDE benutzen und den Typ einfach
vervollständigen lassen?

Trotzdem frag ich mich halt warum? Quellcode wird öfter gelesen als geschrieben
insofern ist mir doch egal ob ich jetzt ein bisschen mehr oder weniger schreiben
muss, hauptsache es wird verständlicher.

Nur zur Anmerkung: Natürlich weiß ich warum, weil man sonst keine Instanzen
von anonymen Typen anlegen kann. Allerdings gilt das "Warum?" bei anonymen Typen
eben auch.

Das nimmt meiner Ansicht nach einfach die Wendung das Sprachmittel hinzugefügt
werden, die die IDE übernehmen könnte.

Die sind in der Tat nen bissle heikel weil man viel Mist bauen kann wenn man die net vernünftig einsetzt, aber das ist dann der Unvernunft der Programmierer zuzuschreiben wenn die nen schlechten Programmentwurf machen und diese Extension Methods missbrauchen( Ist genauso wie manche heute Exception zur Programmflusskontrolle verwenden *kopfschüttel*)

Das die Sprache Unvernunft des Programmierers vorbeugen soll, waren doch anfangs
Argumente für Sprachen wie C#, Java und gegen C, C++. Ich hielt diese Ansicht
für richtig und finde es insofern einfach nicht gut, dass sich das jetzt in das
Gegenteil umkehrt (zum Glück bleibt wenigstens Java dieser Ansicht treu).

Zum Thema LINQ will ich nur ein kleines Beispiel bringen:

// Use Where to find the uppercase letters in a string
string s = "ThIs Is A sTriNg";
foreach (char ch in s.Where(c => Char.IsUpper(c)))
{
    Console.WriteLine(ch);
}

Warum nicht folgendes? Ist halt ein bisschen mehr, lässt sich aber mit
bestehenden Sprachmitteln darstellen und wirkt einfach vertrauter.

using System;
using System.Collections.Generic;

public class EnumerableUtils
{
    public delegate bool ConditionDelegate<T>(T obj);

    public static IEnumerable<T> Where<T>(IEnumerable<T> enumerable, ConditionDelegate<T> condition) {
        foreach (T obj in enumerable) {
            if (condition(obj)) {
                yield return obj;
            }
        }
    }
}

public class AppEntry
{
    public static void Main() {
        string s = "ThIs Is A sTriNg";
        foreach (char ch in EnumerableUtils.Where(s, 
                                delegate(char c) {
                                    return Char.IsUpper(c);
                                })
                           ) {
            Console.WriteLine(ch);
        }

        Console.ReadKey();
    }
}

grüße

[KeinKritiker]

Kritiker schrieb:

Warum nicht folgendes?

weils mehr und hässlicher is?

[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:

[Kritiker]

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:

[Gast]

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.

[Gast]

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

[hmmmm]

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:

[Kritiker]

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.

[Gast]

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.

[hmmmm]

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...