mboost-dp1
Microsoft Corporation
Som nævnt på årets JAOO, så er meningen med dynamiske typer at de skal bruges som en måde at implementere funktionel programmering på i et Objekt Orienteret miljø.dsckeld (1) skrev:Jeg er ikke meget for at blive kaldt en sortseer, men velkommen til VB verdenen. Alle data er varianter og kan holde alt.
Okay, kilden angiver at så galt er det ikke, men personligt synes jeg det lugter...
Det bruges hovedsageligt til LINQ, en form for SQL til at queue collections (lists, arrays, maps, datacollections in general).
Det er en måde at kombinere flere paradigms , hvilket bliver nødvendigt når vi skal arbejde med at programmere til flere processorer på samme tid.
Det er ikke meningen at du skal bruge det til alting, langt fra.
Jeg synes ikke det var særlig svært at installere? Har udviklet i 3.5 længe.LordMike (5) skrev:Så længe 4.0 ikke er så svær at installere som 3.0/5
#6:
Ja, og det er et fint argument for at indføre dynamiske typer på CLR niveau, men det giver, for mig, ikke den store mening at tilføje funktionaliteten til c#. Det virker som om at nogen er blevet misundelige på alle de dynamiske sprog(php, python, ruby) og derfor synes at det skal c# da også have.
Men når man laver noget der kan det hele ender man somregel med noget der ikke er godt til noget som helst! :(
There is no silver bullet...
Ja, og det er et fint argument for at indføre dynamiske typer på CLR niveau, men det giver, for mig, ikke den store mening at tilføje funktionaliteten til c#. Det virker som om at nogen er blevet misundelige på alle de dynamiske sprog(php, python, ruby) og derfor synes at det skal c# da også have.
Men når man laver noget der kan det hele ender man somregel med noget der ikke er godt til noget som helst! :(
There is no silver bullet...
#7
Dynamiske typer er tæt på at være et ultimativt krav for at implementere koncepter fra funktionelle sprog i et multiparadigm sprog.
Og så samt, benyttes det på nuværende tidspunkt (det har været der siden 3.0 eller 3.5, kan ikke huske), mest til LINQ som jeg beskrev før.
Det har rigtig meget at gøre med threading også, da du kan risikere ikke at kunne bevare type infoen, og dermed være nød til at benytte en dynamisk type istedet for at skulle down og upcaste hele tiden.
In short, at det bare endnu et værktøj til programmøren. Modsat de andre sprog så er der ingen der tvinger dig til at bruge det.
Så det er fuldstændig op til udvikleren hvor elendig kode han vil skrive. Jeg mener bare at det giver anledning til meget mere elegant kode, og sikkert også bedre performance i mange tilfælde.
Det er ihvertfald min opfattelse at LINQ kan tilbyde bedre performance end en linær søgning gennem 50000 records bare for at finde en enkelt værdi.
Dynamiske typer er tæt på at være et ultimativt krav for at implementere koncepter fra funktionelle sprog i et multiparadigm sprog.
Og så samt, benyttes det på nuværende tidspunkt (det har været der siden 3.0 eller 3.5, kan ikke huske), mest til LINQ som jeg beskrev før.
Det har rigtig meget at gøre med threading også, da du kan risikere ikke at kunne bevare type infoen, og dermed være nød til at benytte en dynamisk type istedet for at skulle down og upcaste hele tiden.
In short, at det bare endnu et værktøj til programmøren. Modsat de andre sprog så er der ingen der tvinger dig til at bruge det.
Så det er fuldstændig op til udvikleren hvor elendig kode han vil skrive. Jeg mener bare at det giver anledning til meget mere elegant kode, og sikkert også bedre performance i mange tilfælde.
Det er ihvertfald min opfattelse at LINQ kan tilbyde bedre performance end en linær søgning gennem 50000 records bare for at finde en enkelt værdi.
#5,6
Alle .NET opdateringene som har bygget oven på CLR 2.0 har givet en del brugere problemer med installation af opdateringer. Der er et hav af spørgsmål på nettet om det.
Løsningen er at afinstallere alt (undtagen 1.1 hvis man har den), køre et specielt oprydnings tool (jeg kan finde et link hvis nogen er interesseret) og så installere nyeste og lade den installere de tidligere versioner.
Formentligt vil problemet ikke være der for 4.0, da jeg mener at der kommer en ny CLR og den derfor vil være helt uafhængig af 2.0/3.0/3.5.
Alle .NET opdateringene som har bygget oven på CLR 2.0 har givet en del brugere problemer med installation af opdateringer. Der er et hav af spørgsmål på nettet om det.
Løsningen er at afinstallere alt (undtagen 1.1 hvis man har den), køre et specielt oprydnings tool (jeg kan finde et link hvis nogen er interesseret) og så installere nyeste og lade den installere de tidligere versioner.
Formentligt vil problemet ikke være der for 4.0, da jeg mener at der kommer en ny CLR og den derfor vil være helt uafhængig af 2.0/3.0/3.5.
Windcape (8) skrev:
Det er ihvertfald min opfattelse at LINQ kan tilbyde bedre performance end en linær søgning gennem 50000 records bare for at finde en enkelt værdi.
Det tvivler jeg meget på. LINQ laver jo ikke noget magi. Hvis man manuelt er nødt til at løbe en lang liste igennem, så er LINQ også nødt til det.
#6,8
Du har ikke helt ret. Keyworded "var", som jeg gætter på du snakker om, har intet med dynamiske typer at gøre.
Når du skriver 'var' bliver typen stadig fastsat på compile-time. Dynamiske typer er bestemt på run-time.
Og hvorfor vil det være en stor nyhed i 4.0 hvis det allerede var i 3.0?
Og giver #11 ret. LINQ kan jo altså ikke bare tilfældigt pege ind i en liste med 50.000 elementer for at finde en bestemt record. Den skal søge som alt muligt andet.
Du har ikke helt ret. Keyworded "var", som jeg gætter på du snakker om, har intet med dynamiske typer at gøre.
Når du skriver 'var' bliver typen stadig fastsat på compile-time. Dynamiske typer er bestemt på run-time.
Og hvorfor vil det være en stor nyhed i 4.0 hvis det allerede var i 3.0?
Og giver #11 ret. LINQ kan jo altså ikke bare tilfældigt pege ind i en liste med 50.000 elementer for at finde en bestemt record. Den skal søge som alt muligt andet.
#7: C# er ikke ment som et puritansk sprog - ideen har hele tiden været at tage det bedste fra andre sprog (og paradigmer), men at indføre dem på en måde i sproget så det giver et naturligt samspil (og det er faktisk en stor udfordring at blande disse paradigmer på en måde så sproget stadig er letanvedeligt og lettilgængeligt uden en masse kluntet syntax) og det synes jeg faktisk hidtil er lykkedes meget godt.
LINQ er et godt eksempel herpå og en kærkommen mulighed.
Nogle vil måske mene at funktionel programmering ikke hører hjemme i normale OOP-sprog - måske tilmed at det forurener sproget, men C# beviser jo netop hvordan det kan blandes på en rimelig hensigtsmæssig måde hvor fordelene klart overstiger ulemperne. Det er dog ikke ensbetydende med at LINQ er hensigtsmæssigt i alle sammenhænge og jeg bryder mig personligt ikke sønderligt om LINQ to SQL, men fair nok at det eksisterer - jeg kan jo selv træffe valget om jeg vil benytte det i mit projekt eller ej.
Det er dog klart at dynamiske typer i et ellers statisk sprog er kontroversielt, men jeg har stor tillid til at Hejlsberg er manden der kan løfte den opgave. Det giver alt andet lige nogle interessante muligheder og muligheder og fleksibilitet er vigtige egenskaber når det kommer til produktivitet.
Når det er sagt så tror jeg dog ikke dynamiske typer er noget man vil gøre brug af i 99%+ af det C# kode man typisk skriver - men det åbner op for nogle nye scenarier og bedrer interoperabilitet i de få, men måske kritiske, tilfælde hvor det giver mening. Jeg ser det dog som værende mest interessant i forhold til framework-udvikling. Jeg er overbevist om at det er henvendt til special-tilfælde hvor statistike typer er en ulempe - så skrækscenarierne tror jeg er overdrevet. Det er jo heller ikke fordi folk i særlig stor grad anvender pointere i C#, blot fordi sproget understøtter muligheden - det er ligeledes beregnet til special-tilfælde og det er også sådan det bliver brugt. Almindelige frontend-udviklere behøver reelt slet ikke vide hvordan man bruger pointere i C# og jeg tror det samme bliver tilfældet med dynamiske typer.
LINQ er et godt eksempel herpå og en kærkommen mulighed.
Nogle vil måske mene at funktionel programmering ikke hører hjemme i normale OOP-sprog - måske tilmed at det forurener sproget, men C# beviser jo netop hvordan det kan blandes på en rimelig hensigtsmæssig måde hvor fordelene klart overstiger ulemperne. Det er dog ikke ensbetydende med at LINQ er hensigtsmæssigt i alle sammenhænge og jeg bryder mig personligt ikke sønderligt om LINQ to SQL, men fair nok at det eksisterer - jeg kan jo selv træffe valget om jeg vil benytte det i mit projekt eller ej.
Det er dog klart at dynamiske typer i et ellers statisk sprog er kontroversielt, men jeg har stor tillid til at Hejlsberg er manden der kan løfte den opgave. Det giver alt andet lige nogle interessante muligheder og muligheder og fleksibilitet er vigtige egenskaber når det kommer til produktivitet.
Når det er sagt så tror jeg dog ikke dynamiske typer er noget man vil gøre brug af i 99%+ af det C# kode man typisk skriver - men det åbner op for nogle nye scenarier og bedrer interoperabilitet i de få, men måske kritiske, tilfælde hvor det giver mening. Jeg ser det dog som værende mest interessant i forhold til framework-udvikling. Jeg er overbevist om at det er henvendt til special-tilfælde hvor statistike typer er en ulempe - så skrækscenarierne tror jeg er overdrevet. Det er jo heller ikke fordi folk i særlig stor grad anvender pointere i C#, blot fordi sproget understøtter muligheden - det er ligeledes beregnet til special-tilfælde og det er også sådan det bliver brugt. Almindelige frontend-udviklere behøver reelt slet ikke vide hvordan man bruger pointere i C# og jeg tror det samme bliver tilfældet med dynamiske typer.
Bare lige for at give mit indspark til den LINQ diskussion der er opstået, så er LINQ reelt bare syntaktisk sukker (som er opnået med type-interferens og lambda-expressions) der primært kalder extension metoder på typisk IEnumrable<T>
(I LINQ to Objects vel at mærke - det er iøvrigt fuldt ud muligt at definere sine egne LINQ to X implementationer hvilket er noget af det der gør LINQ til en spændende sproglig feature - LINQ er altså reelt ikke" meget andet" end en generisk query syntaks).
Og som det korrekt er pointeret tidligere så er "var" keywordet ikke en dynamisk erklæring, typen evalueres stadig compile-time.
Derfor er det heller ikke muligt i C# 3.0 at skrive:
var o = 1;
o = "Hello World";
og det tyder ikke på at det ændrer sig i C# 4.0 - istedet introduceres der et dynamic keyword, som jeg har forstået det.
Jeg bryder mig dog ikke sønderligt om var keywordet, da det gør det mindrer overskueligt hvilken type man arbejder med. Derfor har min anbefaling til mine udviklere da også været ikke at benytte det i andet end lige præcis LINQ sammenhæng (hvor jeg godt synes det kan accepteres).
(I LINQ to Objects vel at mærke - det er iøvrigt fuldt ud muligt at definere sine egne LINQ to X implementationer hvilket er noget af det der gør LINQ til en spændende sproglig feature - LINQ er altså reelt ikke" meget andet" end en generisk query syntaks).
Og som det korrekt er pointeret tidligere så er "var" keywordet ikke en dynamisk erklæring, typen evalueres stadig compile-time.
Derfor er det heller ikke muligt i C# 3.0 at skrive:
var o = 1;
o = "Hello World";
og det tyder ikke på at det ændrer sig i C# 4.0 - istedet introduceres der et dynamic keyword, som jeg har forstået det.
Jeg bryder mig dog ikke sønderligt om var keywordet, da det gør det mindrer overskueligt hvilken type man arbejder med. Derfor har min anbefaling til mine udviklere da også været ikke at benytte det i andet end lige præcis LINQ sammenhæng (hvor jeg godt synes det kan accepteres).
De nye funktioner lover rigtig godt. Ogsaa saadan noget som typevarians ved generiske typer, selvom det ikke er en fuldt tilfredsstillende implementation, er rigtig rigtig laekkert.
Dynamiske typer er ogsaa rigtig laekkert i visse sammenhaenge. Jeg forstaar ikke helt folks problem med dem; man skal aktivt skrive 'dynamic' og saa videre for at aktivere dem, saa det aendrer jo intet i ens programmer. Til gengaeld sparer man en masse reflection gejl naar man skal kalde noget dynamisk, fx plugins. Internt sparer man ikke noget, men syntaksen bliver langt langt federe.
Dynamiske typer er ogsaa naesten en noedvendighed for at interface let op imod den nye "DLR", som er en host for afvikling af dynamiske sprog som fx python og ruby, som benytter CLR nedenunder. Den har vist meget lovende performance og bruger "hotte" teknikker som polymorf inline-cache mv.
Mht. LINQ saa er dens performance faktisk som regel mange gange lavere end tilsvarende haandkodede metoder, men det er ikke pointen. LINQ er langt mere deklarativt, og giver et langt klarere program i visse tilfaelde. Det er ofte vaerd at ofre meget performance paa; samme berettigelse som sprog som python og ruby har, fx.
Mht. CLR er der ikke noget af det her som decideret kraever en ny CLR, men det kan godt vaere der kommer en alligevel. Det er vist lidt uklart p.t. DLR'en er et separat modul oven paa CLRen.
Dynamiske typer er ogsaa rigtig laekkert i visse sammenhaenge. Jeg forstaar ikke helt folks problem med dem; man skal aktivt skrive 'dynamic' og saa videre for at aktivere dem, saa det aendrer jo intet i ens programmer. Til gengaeld sparer man en masse reflection gejl naar man skal kalde noget dynamisk, fx plugins. Internt sparer man ikke noget, men syntaksen bliver langt langt federe.
Dynamiske typer er ogsaa naesten en noedvendighed for at interface let op imod den nye "DLR", som er en host for afvikling af dynamiske sprog som fx python og ruby, som benytter CLR nedenunder. Den har vist meget lovende performance og bruger "hotte" teknikker som polymorf inline-cache mv.
Mht. LINQ saa er dens performance faktisk som regel mange gange lavere end tilsvarende haandkodede metoder, men det er ikke pointen. LINQ er langt mere deklarativt, og giver et langt klarere program i visse tilfaelde. Det er ofte vaerd at ofre meget performance paa; samme berettigelse som sprog som python og ruby har, fx.
Mht. CLR er der ikke noget af det her som decideret kraever en ny CLR, men det kan godt vaere der kommer en alligevel. Det er vist lidt uklart p.t. DLR'en er et separat modul oven paa CLRen.
Korrekt, men jeg er af den forståelse at LINQ optimerer søgningen?arne_v (11) skrev:Det tvivler jeg meget på. LINQ laver jo ikke noget magi. Hvis man manuelt er nødt til at løbe en lang liste igennem, så er LINQ også nødt til det.
Jeg sammenlignede med en typisk linær søgning (for/foreach loop) for at finde den enkelte værdi.
Hvis LINQ ikke optimere, så er det om noget, mere overskueligt :)
Jeg bryder mig heller ikke om LINQ to SQL, jeg benytter det mest på collections fra andre kilder end databaser.
#16:
Svaret er vel reelt at det afhænger af den konkrete LINQ implementation (LINQ-SQL, LINQ-XML, LINQ-Objects og eventuelle custom implementationer).
Jeg ved at eksempelvis LINQ-SQL analyserer udtrykket (noget der bl.a. muliggøres ved Lambda Expression Trees) og optimerer udtrykket i forhold til den resulterende SQL kode der afvikles op imod databasen. Folk der ikke er så færm til at skrive performance-optimeret SQL kan derfor potentielt opnå en forbedring af deres Query igennem LINQ - men LINQ kan dog aldrig optimere bedrer end det er muligt manuelt, hvilket også er en af grundende til at eksperter typisk går udenom LINQ-SQL da man ofte har brug for manuelt at optimere udtrykkende - f.eks. ved helt konkret at angive hvilket index der skal anvendes i query plannen for udtrykket.
I tilfældet LINQ-Objects kalder du reelt bare extension metoder, prøv at tage et kig her - det er intet hokus pokus over det: http://msdn.microsoft.com/en-us/library/system.lin...
Bemærk at der er extension metoder som SELECT, UNION, WHERE, ORDERBY, etc. Der er iøvrigt intet galt i at kalde disse metoder udenom LINQ.
Hvis du tager Reflector.NET kan du også se hvordan disse nedenunder er implementeret og konklusionen er nok her at du ofte vil kunne skrive koden mere performance-optimalt selv, tilgengæld risikerer du at ryge ud i noget langt mere kluntet og mindrer læselig og forståelig kode og hvis du ikke har godt nok styr på hvad du laver kan du også sagtens gøre det mindrer optimalt end disse implementeringer.
Er det performance vi er ude i så performer en en std. for-løkke iøvrigt også bedrer end foreach, du kan blot tage et kig på den resulterende IL-kode. (Tilgengæld er foreach lettere læseligt og nemmere at bruge og det argument vinder i mit hoved - medmindrer der er tale om en special-situation hvor performance er kritisk)
Korrekt, men jeg er af den forståelse at LINQ optimerer søgningen?
Svaret er vel reelt at det afhænger af den konkrete LINQ implementation (LINQ-SQL, LINQ-XML, LINQ-Objects og eventuelle custom implementationer).
Jeg ved at eksempelvis LINQ-SQL analyserer udtrykket (noget der bl.a. muliggøres ved Lambda Expression Trees) og optimerer udtrykket i forhold til den resulterende SQL kode der afvikles op imod databasen. Folk der ikke er så færm til at skrive performance-optimeret SQL kan derfor potentielt opnå en forbedring af deres Query igennem LINQ - men LINQ kan dog aldrig optimere bedrer end det er muligt manuelt, hvilket også er en af grundende til at eksperter typisk går udenom LINQ-SQL da man ofte har brug for manuelt at optimere udtrykkende - f.eks. ved helt konkret at angive hvilket index der skal anvendes i query plannen for udtrykket.
I tilfældet LINQ-Objects kalder du reelt bare extension metoder, prøv at tage et kig her - det er intet hokus pokus over det: http://msdn.microsoft.com/en-us/library/system.lin...
Bemærk at der er extension metoder som SELECT, UNION, WHERE, ORDERBY, etc. Der er iøvrigt intet galt i at kalde disse metoder udenom LINQ.
Hvis du tager Reflector.NET kan du også se hvordan disse nedenunder er implementeret og konklusionen er nok her at du ofte vil kunne skrive koden mere performance-optimalt selv, tilgengæld risikerer du at ryge ud i noget langt mere kluntet og mindrer læselig og forståelig kode og hvis du ikke har godt nok styr på hvad du laver kan du også sagtens gøre det mindrer optimalt end disse implementeringer.
Er det performance vi er ude i så performer en en std. for-løkke iøvrigt også bedrer end foreach, du kan blot tage et kig på den resulterende IL-kode. (Tilgengæld er foreach lettere læseligt og nemmere at bruge og det argument vinder i mit hoved - medmindrer der er tale om en special-situation hvor performance er kritisk)
Jeg kan huske helt tilbage fra 1.0 dagene at C# havde mangler.
Efterhånden er vi ved at være ude i feature creap. Det er ikke et rent sprog længere.
I forbindelse med Linq -er det kun på compile tidspunktet der er en forskel. IL koden der oversættes er den samme.
Reelt set kan man sige at "from Q in X where Q select Q.A" er det samme som
X.Where(...).Select(...)
Jeg bruger de direkte extension metoder på en collection fremfor Linq udtryk - da de netop mere simpelt udtrykker et simpelt udtræk.
Let the religion war begin.... :)
Jeg vil give sguft fuldstændig ret i at var burde forbydes. Det er grimt og KAN... jeg skriver KAN - gøre koden nær ulæselig.
Vi er lidt tilbage i VB's dim desværre.
Efterhånden er vi ved at være ude i feature creap. Det er ikke et rent sprog længere.
I forbindelse med Linq -er det kun på compile tidspunktet der er en forskel. IL koden der oversættes er den samme.
Reelt set kan man sige at "from Q in X where Q select Q.A" er det samme som
X.Where(...).Select(...)
Jeg bruger de direkte extension metoder på en collection fremfor Linq udtryk - da de netop mere simpelt udtrykker et simpelt udtræk.
Let the religion war begin.... :)
Jeg vil give sguft fuldstændig ret i at var burde forbydes. Det er grimt og KAN... jeg skriver KAN - gøre koden nær ulæselig.
Vi er lidt tilbage i VB's dim desværre.
#18
const int count = 100000000;
var sw = new Stopwatch();
sw.Reset();
sw.Start();
for (int i = 0; i < count; i++)
{
}
sw.Stop();
var forTime = sw.ElapsedTicks;
sw.Reset();
sw.Start();
foreach (var i in Enumerable.Range(0, count))
{
}
sw.Stop();
var foreachTime = sw.ElapsedTicks;
Console.WriteLine(forTime);
Console.WriteLine(foreachTime);
Console.WriteLine((float)foreachTime / forTime);
Tiderne :
4869915
14286932
2.933713
... Så konklusionen er vel at at små hurtige iterationer altid bør foregå via for(;;)
const int count = 100000000;
var sw = new Stopwatch();
sw.Reset();
sw.Start();
for (int i = 0; i < count; i++)
{
}
sw.Stop();
var forTime = sw.ElapsedTicks;
sw.Reset();
sw.Start();
foreach (var i in Enumerable.Range(0, count))
{
}
sw.Stop();
var foreachTime = sw.ElapsedTicks;
Console.WriteLine(forTime);
Console.WriteLine(foreachTime);
Console.WriteLine((float)foreachTime / forTime);
Tiderne :
4869915
14286932
2.933713
... Så konklusionen er vel at at små hurtige iterationer altid bør foregå via for(;;)
#20
Den test og det resultat ser yderst suspekt ud.
Hvis jeg skulle gætte så har du testet i debug mode og ikke i release mode.
Derudover tester du reelt overheadet på Enumerable.Range(0, count) - ikke forskellen på for og foreach.
Ja - og i en fremtidig version af .NET kunne du risikere at løkkerne bliver helt optimeret væk.
Den test og det resultat ser yderst suspekt ud.
Hvis jeg skulle gætte så har du testet i debug mode og ikke i release mode.
Derudover tester du reelt overheadet på Enumerable.Range(0, count) - ikke forskellen på for og foreach.
Ja - og i en fremtidig version af .NET kunne du risikere at løkkerne bliver helt optimeret væk.
#20: hvis det der er hele koden så begår du en klassisk fejl, nemlig at tage højde for JIT-kompileringen.
Skil det ud i en metode og kald den metode inden hvor du bare ignorerer resultatet og kald den så igen hvor du bruger tiderne.
Beklager hvis det er det du reelt har gjort, ville blot påpege at tiderne er noget upræcise ellers :)
Skil det ud i en metode og kald den metode inden hvor du bare ignorerer resultatet og kald den så igen hvor du bruger tiderne.
Beklager hvis det er det du reelt har gjort, ville blot påpege at tiderne er noget upræcise ellers :)
For(;;)
ForEach
Bare lige for at tage den derud :-)
static void DoFor(int[] array) {
for (int i = 0; i < array.Length; i++) {
}
}
IL:
.method private hidebysig static void DoFor(int32[] array) cil managed
{
.maxstack 2
.locals init (
[0] int32 i,
[1] bool CS$4$0000)
L_0000: nop
L_0001: ldc.i4.0
L_0002: stloc.0
L_0003: br.s L_000b
L_0005: nop
L_0006: nop
L_0007: ldloc.0
L_0008: ldc.i4.1
L_0009: add
L_000a: stloc.0
L_000b: ldloc.0
L_000c: ldarg.0
L_000d: ldlen
L_000e: conv.i4
L_000f: clt
L_0011: stloc.1
L_0012: ldloc.1
L_0013: brtrue.s L_0005
L_0015: ret
}
ForEach
static void DoForEach(int[] array) {
foreach (int i in array) {
}
}
IL:
.method private hidebysig static void DoForEach(int32[] array) cil managed
{
.maxstack 2
.locals init (
[0] int32 i,
[1] int32[] CS$6$0000,
[2] int32 CS$7$0001,
[3] bool CS$4$0002)
L_0000: nop
L_0001: nop
L_0002: ldarg.0
L_0003: stloc.1
L_0004: ldc.i4.0
L_0005: stloc.2
L_0006: br.s L_0012
L_0008: ldloc.1
L_0009: ldloc.2
L_000a: ldelem.i4
L_000b: stloc.0
L_000c: nop
L_000d: nop
L_000e: ldloc.2
L_000f: ldc.i4.1
L_0010: add
L_0011: stloc.2
L_0012: ldloc.2
L_0013: ldloc.1
L_0014: ldlen
L_0015: conv.i4
L_0016: clt
L_0018: stloc.3
L_0019: ldloc.3
L_001a: brtrue.s L_0008
L_001c: ret
}
Bare lige for at tage den derud :-)
#8:
Min anke var nu ogsp mest at blande det ind i c# - og f# ser da ud til at fungere idag uden at have dynamiske typer :)
Derudover er meget af den samme funktionalitet allerede mulig med DynamicMethod og dynamisk generering af IL kode(omend syntaxen i sprog ikke er lige så "lækker")
#13:
Nu er Hejlsberg ikke ufejlbarlig - jeg tror jeg kan finde en del der synes det var jævnt tåbeligt ikke som standard at gøre alle metoder virtuelle! :) Derudover er jeg heller ikke specielt begejstret for LINQ(og i særdeleshed ikke for LINQ to SQL), men det er nok bare mig der er ved at blive gammel og mavesur :)
Min anke var nu ogsp mest at blande det ind i c# - og f# ser da ud til at fungere idag uden at have dynamiske typer :)
Derudover er meget af den samme funktionalitet allerede mulig med DynamicMethod og dynamisk generering af IL kode(omend syntaxen i sprog ikke er lige så "lækker")
#13:
Nu er Hejlsberg ikke ufejlbarlig - jeg tror jeg kan finde en del der synes det var jævnt tåbeligt ikke som standard at gøre alle metoder virtuelle! :) Derudover er jeg heller ikke specielt begejstret for LINQ(og i særdeleshed ikke for LINQ to SQL), men det er nok bare mig der er ved at blive gammel og mavesur :)
#24: Jeg var også selv meget skeptisk overfor LINQ i starten og så det mest som noget der sikkert var lavet for at please hobbyudviklere - og jeg var endda til en del TechEd foredrag om det sidste år uden at jeg af den grund var sønderlig imponeret, specielt med den megen fokus fra Microsoft på LINQ to SQL (som jeg stadig har meget svært ved at se målrettet mod andet end førnævnte målgruppe).
Men jeg har stille og roligt måtte overgive mig efterhånden som jeg har fået forståelse for hvad LINQ reelt går ud på og LINQ to Objects, samt LINQ to XML føler jeg faktisk giver et produktivitetsboost, man skal blot ikke gøre brug af det i performance-kritiske scenarier.
Desuden følte jeg at det var en sprog-feature der virkede til at være alt for tæt koblet til frameworket, men efter at have fundet ud af hvordan det reelt hænger sammen og at det står mig frit for at implementere egne query implementeringer der er lige så fleksible som dem der leveres med frameworket, begyndte jeg faktisk at synes en del bedrer om ideen med en generisk query syntax der er vendt på en måde så der kan tilbydes fuld intellisense support igennem alle steps. Men det krævede lige den her erkendelse af at det faktisk ikke er helt så bloated en feature som det ved første bekendtskab giver indtryk af :-)
Men jeg har stille og roligt måtte overgive mig efterhånden som jeg har fået forståelse for hvad LINQ reelt går ud på og LINQ to Objects, samt LINQ to XML føler jeg faktisk giver et produktivitetsboost, man skal blot ikke gøre brug af det i performance-kritiske scenarier.
Desuden følte jeg at det var en sprog-feature der virkede til at være alt for tæt koblet til frameworket, men efter at have fundet ud af hvordan det reelt hænger sammen og at det står mig frit for at implementere egne query implementeringer der er lige så fleksible som dem der leveres med frameworket, begyndte jeg faktisk at synes en del bedrer om ideen med en generisk query syntax der er vendt på en måde så der kan tilbydes fuld intellisense support igennem alle steps. Men det krævede lige den her erkendelse af at det faktisk ikke er helt så bloated en feature som det ved første bekendtskab giver indtryk af :-)
#25:
Mjaa - jeg ved det, jeg har også kigget en anelse i dybden på det, og var også ved at overveje at skrive en provider snakke med et internt udviklet object store(men har af andre grunde droppet den ide :)).
Og nej, jeg hader ikke direkte linq, men jeg synes bare at man er ved at lave c# til et sprog der kan for meget - og specielt når man giver ikke så erfarne mennesker sådan et sprog ender det med de ikke er specielt gode til at bruge det. :)
PLUS at jeg nok bare er ved at blive en gammel sur mand! ;)
Mjaa - jeg ved det, jeg har også kigget en anelse i dybden på det, og var også ved at overveje at skrive en provider snakke med et internt udviklet object store(men har af andre grunde droppet den ide :)).
Og nej, jeg hader ikke direkte linq, men jeg synes bare at man er ved at lave c# til et sprog der kan for meget - og specielt når man giver ikke så erfarne mennesker sådan et sprog ender det med de ikke er specielt gode til at bruge det. :)
PLUS at jeg nok bare er ved at blive en gammel sur mand! ;)
seahawk (27) skrev:#25:
Mjaa - jeg ved det, jeg har også kigget en anelse i dybden på det, og var også ved at overveje at skrive en provider snakke med et internt udviklet object store(men har af andre grunde droppet den ide :)).
Og nej, jeg hader ikke direkte linq, men jeg synes bare at man er ved at lave c# til et sprog der kan for meget - og specielt når man giver ikke så erfarne mennesker sådan et sprog ender det med de ikke er specielt gode til at bruge det. :)
PLUS at jeg nok bare er ved at blive en gammel sur mand! ;)
Det jeg frygter mest er at der går mere og mere VB i C#. Heldigvis kan man vælge det fra, men igen - god kodeskik er også at sortere de grimmeste ting fra.
For på den anden side kan man i C++ også lave nogle ret så grumme løsninger. F.eks. gør makroer det bestemt ikke pænere. Eller når man er stødt på VOID*. Dømt til at gå galt.
En enkelt ting jeg dog synes de skulle overveje at give lov til i C# er metoder med standard værdier.
fx. Enable(bool b=true) {}
Det er møg irriterende at skrive "genvejs metoder". Og det man gør er reelt set blot at imitere default værdier alligevel.
Ja jeg er nok også lidt sur i sulet.. MEH!
#27: Ja jeg kan godt lidt følge dig og det største problem jeg ser ved de her ting er at C# er ved at miste den her simplicitet som gjorde at det var et rigtig godt begyndersprog - nu bliver det mere og mere fyldt op med avancerede koncepter og nogle af dem skal man være en ret erfaren udvikler for at forstå til bunds.
Faktisk burde man nok lære folk C# i kronologisk rækkefølge (1.0 -> 2.0 -> 3.0)
Omvendt så åbner det op for nye muligheder og nogle af dem er jeg personligt ret vilde med (eksempelvis er jeg rimelig pjattet med extension methods og lambda expressions, som virkelig har ændret den måde jeg designer frameworks på).
Så det er jo selvfølgelig lidt en afvejning - også fra Microsofts side.
Jeg er dog enig i at nogle af disse koncepter er farlige i de forkerte hænder og kan føre til dårligere designs, samt gøre det sværere at vurdere performance-impacts (en af mine store anker ved LINQ).
Men nogle gange koder man med performance i baghovedet og der ønsker man ofte fuld kontrol over forløbet og bør således undgå de her højere abstraktioner.
Andre gange koder man noget hvor performance ikke er kritisk og hvor man istedet vægter læsbarhed og forståelse højt og her synes jeg LINQ har en berettigelse.
[Edit]
#28: Jeg mener faktisk at jeg læste at det også kommer i C# 4.0 :-)
Faktisk burde man nok lære folk C# i kronologisk rækkefølge (1.0 -> 2.0 -> 3.0)
Omvendt så åbner det op for nye muligheder og nogle af dem er jeg personligt ret vilde med (eksempelvis er jeg rimelig pjattet med extension methods og lambda expressions, som virkelig har ændret den måde jeg designer frameworks på).
Så det er jo selvfølgelig lidt en afvejning - også fra Microsofts side.
Jeg er dog enig i at nogle af disse koncepter er farlige i de forkerte hænder og kan føre til dårligere designs, samt gøre det sværere at vurdere performance-impacts (en af mine store anker ved LINQ).
Men nogle gange koder man med performance i baghovedet og der ønsker man ofte fuld kontrol over forløbet og bør således undgå de her højere abstraktioner.
Andre gange koder man noget hvor performance ikke er kritisk og hvor man istedet vægter læsbarhed og forståelse højt og her synes jeg LINQ har en berettigelse.
[Edit]
#28: Jeg mener faktisk at jeg læste at det også kommer i C# 4.0 :-)
#30: Sådan kan man jo neglitere mange ting, rigtig mange af de ting vi ser i forskellige sprog bygger på ideer som i et eller andet omfang har eksisteret i andre main-stream sprog eller koncept-sprog.
Her kunne man passende indsætte den efterhånden lidt slidte frase "We're all standing on shoulders of giants".
Kunsten består i at kunne tage disse koncepter og så tage dem et skridt videre - forfine dem og gøre dem tilgængelige og samtidig stadig bevare konsistensen i sproget. Det er en svær balancegang, men noget jeg synes er lykkedes bedrer i C# end alternativerne.
Her kunne man passende indsætte den efterhånden lidt slidte frase "We're all standing on shoulders of giants".
Kunsten består i at kunne tage disse koncepter og så tage dem et skridt videre - forfine dem og gøre dem tilgængelige og samtidig stadig bevare konsistensen i sproget. Det er en svær balancegang, men noget jeg synes er lykkedes bedrer i C# end alternativerne.
#32:
Ja det er jeg helt enig i og kernen er vel også lidt om ikke vi er mange der hellere vil have et godt generel-purpose sprog der kan bruges i rigtig mange sammenhænge end at skulle ud i at kombinere flere forskellige sprog i et projekt.
Jeg vil hellere at C# får nye features end vi skal tilbage og kode i Erlang eller Haskell til parrelel computing.
Ja det er jeg helt enig i og kernen er vel også lidt om ikke vi er mange der hellere vil have et godt generel-purpose sprog der kan bruges i rigtig mange sammenhænge end at skulle ud i at kombinere flere forskellige sprog i et projekt.
#sguft:
Faldt lige over den her.
#windscape:
Kunne det tænkes at det ikke er muligt at lave et sprog der er godt til begyndere OG kan være godt til at lave ting der skal eksekveres parallelt? :)
Præcis som man har foreskellige benzindrevne køretøjer til forskellige ting, tror jeg det samme gør sig gældende for programmeringssprog.
(og lad mig i samme åndedrag pushe det her, i tilfælde nogen af jer har unger i vil lære at kode :))
Faldt lige over den her.
#windscape:
Kunne det tænkes at det ikke er muligt at lave et sprog der er godt til begyndere OG kan være godt til at lave ting der skal eksekveres parallelt? :)
Præcis som man har foreskellige benzindrevne køretøjer til forskellige ting, tror jeg det samme gør sig gældende for programmeringssprog.
(og lad mig i samme åndedrag pushe det her, i tilfælde nogen af jer har unger i vil lære at kode :))
#34: Interessant, jeg synes så at det er morsomt at de nu mener at deres Entity Framework er deres anbefalede DA lag - det kan jeg sjovt nok heller ikke lide :p
Faktum er at Microsoft skulle holde sig til kerne-frameworket istedetfor at forsøge at markedsføre de her ting som Enterprise-produkter, når sandheden er at de oftest ikke er meget mere bevendt end hobby-brug (sådan groft sagt selvfølgelig).
Faktum er at Microsoft skulle holde sig til kerne-frameworket istedetfor at forsøge at markedsføre de her ting som Enterprise-produkter, når sandheden er at de oftest ikke er meget mere bevendt end hobby-brug (sådan groft sagt selvfølgelig).
Jeg foretrækker NHibernate som DA layer, og Castle Project som Active Record abstraktion oven på NHibernate til mere simple projects hvor super duper eksekverings hastighed ikke er hovedprorioteten.
Deres værktøjer til threading er også fantastiske, sammenlignet med Java og C++ er det så uendelig meget nemmere at skrive ordenlig kode, og man slipper nemt om dreadlocks og skal ikke lave homemade threadpools.
Jeg synes Microsoft har gjort et godt stykke arbejde indtil videre.seahawk (34) skrev:Kunne det tænkes at det ikke er muligt at lave et sprog der er godt til begyndere OG kan være godt til at lave ting der skal eksekveres parallelt? :)
Deres værktøjer til threading er også fantastiske, sammenlignet med Java og C++ er det så uendelig meget nemmere at skrive ordenlig kode, og man slipper nemt om dreadlocks og skal ikke lave homemade threadpools.
Windcape (37) skrev:
Deres værktøjer til threading er også fantastiske, sammenlignet med Java og C++ er det så uendelig meget nemmere at skrive ordenlig kode, og man slipper nemt om dreadlocks og skal ikke lave homemade threadpools.
Er der nogen som har forbudt dig at bruge den threadpool der kommer med Java ?
Og .NET og Java har stort set samme locking model, så umiddelbart vil jeg da mene at risikoen for deadlocks er præcis den samme.
#LINQ
LINQ er en genial løsning på et ikke eksisterende problem.
Set fra en sprog synsvinkel giver det mulighed for compile time check af query syntax og intellisense. Genialt.
Men det har jo aldrig været noget problem. Lige så snart folk er over begynder niveauet så er det jo ikke syntax fejl i SQL og XPath der koster tiden.
Derudover så bryder jeg mig principielt ikke om at man opfinder en et eget query language, når standarder eksisterer (SQL og XPath).
Til Microsofts undskyldning skal dog siges at der også er mange andre ORM som har opfundet deres eget QL fremfor at bruge SQL.
Mit indtryk er at:
LINQ for SQL er død og jeg synes ikke at det tegner for lovende for afløseren LINQ for EF.
LINQ for XML ikke bruges ret meget.
LINQ for objects var rødglødende hot tidligere på året, men at der er mange som har opgivet selve LINQ syntaxen, men i.s.f. bruger extension metoderne og lambda expressions tilføjet for at understøtte LINQ for objects. De giver simpelthen mere fleksibilitet og pænere syntax, når man ser bort fra de allermest simple eksempler.
LINQ er en genial løsning på et ikke eksisterende problem.
Set fra en sprog synsvinkel giver det mulighed for compile time check af query syntax og intellisense. Genialt.
Men det har jo aldrig været noget problem. Lige så snart folk er over begynder niveauet så er det jo ikke syntax fejl i SQL og XPath der koster tiden.
Derudover så bryder jeg mig principielt ikke om at man opfinder en et eget query language, når standarder eksisterer (SQL og XPath).
Til Microsofts undskyldning skal dog siges at der også er mange andre ORM som har opfundet deres eget QL fremfor at bruge SQL.
Mit indtryk er at:
LINQ for SQL er død og jeg synes ikke at det tegner for lovende for afløseren LINQ for EF.
LINQ for XML ikke bruges ret meget.
LINQ for objects var rødglødende hot tidligere på året, men at der er mange som har opgivet selve LINQ syntaxen, men i.s.f. bruger extension metoderne og lambda expressions tilføjet for at understøtte LINQ for objects. De giver simpelthen mere fleksibilitet og pænere syntax, når man ser bort fra de allermest simple eksempler.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund