.Net 3.5 algemeen

[Arise]

Ik vraag mij af hoe het zit met .Net 3.5 uptake. Ik bedoel, er zijn behoorlijk wat nieuwe zaken geïntroduceerd sinds .Net 2.0, maar nu vraag ik mij af of ze ook van de grond geraken en of het interessant wordt om er ook eens naartoe te beginnen kijken. Zien jullie in de praktijk (werkomgeving) WPF, WCF, Workflow, LINQ, ADO Entities framework gebruikt worden of komt het moeilijk van de grond ?

[Tags NL]

Ik zie op werk hier maar weinig mee gebeuren, had vorige maand zowaar mijn eerste 3.5 applicatie van een ontwikkelaar gekregen met functionaliteit die hij niet onder 3.0 werkend kreeg? (En het was in mijn ogen maar een simpele import/export applicatie die tegen een applicatie en SQL Server aan praat)

[gorgi_19]

-={Fred_Perry}=- schreef op zondag 15 november 2009 @ 20:32:
Ik zie op werk hier maar weinig mee gebeuren, had vorige maand zowaar mijn eerste 3.5 applicatie van een ontwikkelaar gekregen met functionaliteit die hij niet onder 3.0 werkend kreeg? (En het was in mijn ogen maar een simpele import/export applicatie die tegen een applicatie en SQL Server aan praat)

.Net 3.5 heeft ook een andere compiler, aangezien de language qua features verder uitgebreid is. Dit onafhankelijk van WPF, etc. Neem bijvoorbeeld extension methods; werken niet in .Net 2.0, wel in .Net 3.5

[ Voor 6% gewijzigd door gorgi_19 op 15-11-2009 21:38 ]

[HawVer]

Mijn persoonlijke ervaringen met WCF en Entity Framework zijn niet bijzonder goed. Voor een uitgebreide applicatie wilden we een combinatie van beide gebruiken wat dus in de praktijk haast niet mogelijk is. Daarvoor moesten we allemaal workarounds maken en vieze dingen doen. Dus nee, die technologie hebben we laten liggen. Dat is overigens geen beperking van WCF, maar van het entity framework.

WCF is een mooie paraplu geworden voor een hoop verschillende three tier oplossingen die er bestonden. Nu kun je door een config aan te passen een andere techniek gebruiken. Persoonlijk vond ik de functionaliteit behoorlijk omvattend en indrukwekkend. Het duurt even voordat je er goed mee kan werken. Verder, herkenning van een draaiende service vond ik vrij traag. Het duurt even voordat er een verbinding op is gebouwd. Als je in een enterprise omgeving connectie maakt met meerdere services kun je even koffie gaan halen.

WPF. Goed voorbeeld? MS Navision maakt gebruik van WPF voor de nieuwe interface. Erg mooi geworden vind ik zelf. Draait ook soepel.

Andere voordelen van 3.5, koude start van een applicatie is verbeterd qua performance.

[whoami]

gorgi_19 schreef op zondag 15 november 2009 @ 21:37:
[...]
Neem bijvoorbeeld extension methods; werken niet in .Net 2.0, wel in .Net 3.5

Dat gaat wel hoor, in .NET 2.0. Heb je wel de C# 3.0 compiler voor nodig, maar het kan in .NET 2.0.
(Moet je gewoon zelf even de ExtensionAttribute definieren in de juiste namespace).

Zelf maak ik wel geregeld gebruik van Linq (to objects). Het is gewoon soms handig, maar, het is natuurlijk niet noodzakelijk.
EF gebruik ik dan weer niet; ik gebruik NHibernate.

[ Voor 19% gewijzigd door whoami op 15-11-2009 22:33 ]

[bigbeng]

Ik ben net van een project afgerold waar we gebruik maakten van WPF, ASP.Net MVC, LinQ, Fluent NHibernate (waar je middels Lambda Expressies je configuratie doet) en onze code bevatte veel Lambda Expressies. Vooral lambda expressies vind ik erg handig, WPF is redelijk elegant, mits je redelijk braaf het MVVM pattern volgt.

[gorgi_19]

whoami schreef op zondag 15 november 2009 @ 22:31:
[...]

Dat gaat wel hoor, in .NET 2.0. Heb je wel de C# 3.0 compiler voor nodig, maar het kan in .NET 2.0.
(Moet je gewoon zelf even de ExtensionAttribute definieren in de juiste namespace).

Mja, maar strict genomen is .Net 3.5 een uitbouw van 2.0, vandaar dat het niet echt problemen zal opleveren qua framework

[Snake]

gorgi_19 schreef op zondag 15 november 2009 @ 21:37:
[...]

.Net 3.5 heeft ook een andere compiler, aangezien de language qua features verder uitgebreid is. Dit onafhankelijk van WPF, etc. Neem bijvoorbeeld extension methods; werken niet in .Net 2.0, wel in .Net 3.5

Nope, er zijn gewoon een aantal extra DLLs bijgevoegd en een aantal preprocessor functies, zoals het expanden van LINQ naar Method Chains en lambda's naar delegates en support voor var.

Maar uiteindelijk krijg je gewoon CLR 2.0 complient code.

De compiler is identiek. Je kan dus ook LINQ in een 2.0 Application krijgen door System.Data.Linq toe te voegen aan je project.

Kijk maar eens in een .NET 3.5 app bij je references, de runtime versie van iedere DLL is v2.**

[whoami]

Snake schreef op maandag 16 november 2009 @ 09:16:
[...]

De compiler is identiek.

Volgens mij is de compiler niet identiek.
Je kan nl. gebruik maken van de nieuwe languagefeatures in .NET 2.0, als je maar de C#3.0 compiler gebruikt.
Maw: er zijn volgens mij een aantal nieuwe features in de taal C# toegevoegd, waardoor je wel de juiste compiler moet gebruiken.

[D-Raven]

Arise schreef op zondag 15 november 2009 @ 20:30:
Ik vraag mij af hoe het zit met .Net 3.5 uptake. Ik bedoel, er zijn behoorlijk wat nieuwe zaken geïntroduceerd sinds .Net 2.0, maar nu vraag ik mij af of ze ook van de grond geraken en of het interessant wordt om er ook eens naartoe te beginnen kijken. Zien jullie in de praktijk (werkomgeving) WPF, WCF, Workflow, LINQ, ADO Entities framework gebruikt worden of komt het moeilijk van de grond ?

WCF om netwerk communicatie mee te realiseren wordt langzamerhand wel redelijk mainstream in de .net 3.5 wereld. Microsoft maakt daar zelf ook veel gebruik van in hun nieuwe software en platforms. Windows Azure maakt er ook gebruik van bijvoorbeeld.

WPF zal uiteindelijk winforms gaan vervangen als de mainstream UI toolkit voor .net. Als ik alleen al kijk naar onze eigen designers, die zijn er bij wijze van spreken lyrisch over. Het is alleen wel een heel andere wijze van UI's bouwen. Je zult in het begin dus best even wat tijd moeten investeren om het je goed eigen te maken.

Maargoed dat is met alle 3 de platforms, WWF ook namelijk. Daar hebben we kort naar gekeken maar al vrij snel links laten liggen. Het is gewoon niet volwassen genoeg, niet af genoeg. Persoonlijk vond ik het een grote hoop rotzooi. Maar ik las ergens dat MS in .Net 4.0 WWF compleet gaat veranderen. Dus wellicht dat het dan een stuk beter wordt.

Linq: Helaas is Linq-to-SQL stopgezet omwille van het Entity-Framework. Behoorlijk jammer in mijn ogen, EF kan mij niet bekoren. Hoe bepaalde dingen zijn opgelost in dat framework staan mij totaal niet aan. Ik ben dan ook van mening dat er veel betere OR Mappers zijn. Of dat EF verder veel gebruikt wordt, geen idee.
Verschillende OR-Mappers (NHibernate, LLIBGen, en misschien nog andere) zijn overigens bezig (of klaar) met een Linq adapter, d.w.z dat er een adapter is voor Linq-To-Sql voor hun framework.

Ik zie Linq-to-Sql her en der nog wel eens gebruikt worden. Voornamelijk als een licht gewicht oplossing voor kleinere applicaties. Ik zie wel dat er steeds meer voor andere oplossingen wordt gekozen, puur vanwege het feit dat het niet verder ontwikkeld wordt.

Verder gebruik ik de Linq for object extensies zelf heel veel. Lamda expressies kan ik overigens al helemaal niet meer wegdenken

[Janoz]

Even een schopje richting SEA, waar dit topic wat beter past.

[Brainstorm]

whoami schreef op maandag 16 november 2009 @ 09:30:
[...]
Volgens mij is de compiler niet identiek.
Je kan nl. gebruik maken van de nieuwe languagefeatures in .NET 2.0, als je maar de C#3.0 compiler gebruikt.
Maw: er zijn volgens mij een aantal nieuwe features in de taal C# toegevoegd, waardoor je wel de juiste compiler moet gebruiken.

Klopt, de compiler is anders, ze maken wel gebruik van dezelfde runtime (2.0).

Ik moet zeggen dat ik echt wel blij ben met .NET 3.0 en 3.5. Ik de praktijk werk ik dagelijks met Linq, is vrij snel op te pakken en te gebruiken. Zeker in mijn huidige project, waar data uit verschillende bronnen gehaald wordt en kleine resultsets in-memory gefilterd worden, is de code veel duidelijker geworden. Een linq query kan een stuk overzichtelijker zijn dan een lusje waarin je de filter zelf uitvoert.

WCF gebruik ik waar mogelijk/relevant, alhoewel er nog veel met webservices gewerkt wordt. WPF is iets wat je echt wel even moet bestuderen, maar omdat de meeste applicaties hier via het web toegankelijk zijn heb ik er weinig mee te maken.

Het Entity Framework heb ik maar even mee gespeeld, LLBLGen wordt al jaren binnen het bedrijf gebruikt dus EF is niet echt nodig. LLBGen + Linq > EF

Wat betreft Workflow heb ik maar 1 project gedaan dat WWF gebruikt, het liefste verander ik daar nooit ook maar 1 regel aan. Draait al sinds februari 2007 stabiel hoor, geen problemen. Het ontwikkelen echter was puzzelen om het fatsoenlijk aan de praat te krijgen. Komt misschien ook wel omdat het gedeeltelijk tijdens de 3.0 beta ontwikkeld is, toen er nog vrij weinig informatie over was.

[__fred__]

Beetje dezelfde ervaringen zie ik. Heb zelf ondertussen WF gebruikt, geen succes. Het designen van grote workflows is godsonmogelijk en de runtime is niet bijzonder snel. We hebben een tiental workflows draaien bij een klant in onze toepassing, maar designen bewust geen nieuwe totdat er een nieuwe designer is. Het is redelijk ruk als je tegen je klant moet zeggen dat iets waar ze tevreden over zijn, niet uit kunt breiden, omdat de flows in de designer je PC voor minuten ophangen. Meest treurige is dat ze de workflow designer niet verbeterd hebben tussen VS2005 (add-on) en VS2008.

WPF is een beetje hetzelfde verhaal. We hebben er één toepassing in gemaakt, maar een jaar geleden was er nog weinig 3rd party ondersteuning, kwam je nog een heel aantal bugs tegen en was weer de designer van matige kwaliteit. Hoe vaak ik niet "cannot display component" of iets dergelijks heb gezien. De methodiek staat me erg aan, dat wel.

Entity Framework haalt het niet bij LLBLGen, qua features, kwaliteit etc. Voordat wij van LLBLGen afgaan, moet er nog een hele hoop gebeuren aan EF.

Ik heb erg mixed feelings bij de laatste .NET versies. WPF, WCF en WF zijn geweldige technieken, maar krijg het gevoel dat er niets meer afgemaakt wordt bij microsoft. Elke week weer een nieuw trucje. Maak eens een onderdeel af. Lambda expressions en LINQ kunnen me dan wel weer erg bekoren en gebruik ik dagelijks.

Ik merk wel dat de vernieuwingen aan mijn wat minder techno-minded collega's volledig voorbij gaan. Dat kan OF betekenen dat ze de boot missen, OF dat deze technologien ondertussen ook weer in de hoek liggen te roesten.

[.oisyn]

Snake schreef op maandag 16 november 2009 @ 09:16:
[...]

Nope, er zijn gewoon een aantal extra DLLs bijgevoegd en een aantal preprocessor functies, zoals het expanden van LINQ naar Method Chains en lambda's naar delegates en support voor var.

Een compiler bestaat niet alleen uit z'n backend. Hij moet de code ook kunnen parsen (front-end), en de C#2.0 compiler snapt de C#3.0 taalfeatures niet. Dat er dezelfde IL uit komt rollen en dat de ABI niet veranderd is tussen .Net 2.0 en .Net 3.5 doet er niet zo heel veel toe, het is en blijft een nieuwe compiler.

[ Voor 15% gewijzigd door .oisyn op 16-11-2009 13:50 ]

[Alex]

Ja ik zie het veel gebruikt worden, ja ik zie veel toepassingen, maar ik zie nog veel vaker dat het half of slecht gebruikt wordt.
WCF is een duidelijke Service Layer. Was nodig. Al jaren beschikbaar voor equivalent het Java platform, maar in .NET nog missend. Stijle leercurve, lastig goed in te zeten. Goed complex, maar gelukkig komt er met .NET 4.0 ook een simplificatie vorm.
WF is een perfecte technische workflow tool. Alleen vaak bekeken als Visuele Workflow Tool. Laat daar nu een gigantisch verschil tussen zitten. Inmiddels is dat gat wel een stukje kleiner gemaakt, maar in ons .NET 3.5 CMS(wat dat ook mag zijn), zit nog geen WF simpelweg omdat het designen van de workflow te moeilijk is en de uitbreidbaarheid(extensibility & adaptability) van het systeem zich niet leent voor een dergelijke toepassing. Echter, voor een voorgedefinieerd business process een mooie library.
WPF, leuk, goed, snel, maar nog erg jong. We zijn niet gewend of zo declaratief te programmeren. Dat moet nog komen. Daarna echt een blijvertje. Alhoewel het mij niet zal verbazen als er ooit een uniforme taal wordt gestart. Moeilijk is wel om de upgrade te maken van WinForms naar WPF.

Language Features(beperk me tot C#):
2.0: Generics, Partial classes, etc: Goed gaaf, begrijpelijk. Extra productiviteit en verbeter
3.0: LINQ, Extension Methods, Lambda(functionele constructs): pijnlijk, te abstract voor developers zonder training. Ik heb het ooit zo genoemd: 'LINQ is all about being smart', je hebt immers te maken met derived execution. En een gemiddelde programmeur snapt threads nog niet eens volledig(inclusief mijzelf)...
4.0: Dynamic, Convariance, etc: Onmogelijk zonder training. Veel kans op 'slecht' gebruik en niet echt general purpose.

Al met al wordt het wel mooier, beter, gaver, maar het wordt ook lastiger om bij te blijven. Ik heb niet het idee dat een programmeur nu sneller gaat werken door de vele taal innovaties. Mogelijk wordt zijn code wel stabieler door innitiatieven zoals Pex/Code Contracts, maar zit de klant daar op te wachten?

[Snake]

.oisyn schreef op maandag 16 november 2009 @ 13:45:
[...]

Een compiler bestaat niet alleen uit z'n backend. Hij moet de code ook kunnen parsen (front-end), en de C#2.0 compiler snapt de C#3.0 taalfeatures niet. Dat er dezelfde IL uit komt rollen en dat de ABI niet veranderd is tussen .Net 2.0 en .Net 3.5 doet er niet zo heel veel toe, het is en blijft een nieuwe compiler.

True, maar m.i. is alleen de preprocessor veranderd om de nieuwe language features te verstaan.

Maar like I said, System.Data.Linq kan je perfect gebruiken in een .NET 2.0 app, en die dan compilen met een 2.0 compiler.

Maar dan moet je je methods chainen en kan je niet

C#:

var result =from t in Repo.Cars
where t.TireSize > 20
select t;

. De preprocessor snapt dit namelijk niet.

Dus ja: de compiler is identiek als je de compiler op zich neemt, reken je de preprocessor erbij, dan niet.

[whoami]

Alex schreef op maandag 16 november 2009 @ 21:14:

Language Features(beperk me tot C#):
2.0: Generics, Partial classes, etc: Goed gaaf, begrijpelijk. Extra productiviteit en verbeter
3.0: LINQ, Extension Methods, Lambda(functionele constructs): pijnlijk, te abstract voor developers zonder training. Ik heb het ooit zo genoemd: 'LINQ is all about being smart', je hebt immers te maken met derived execution. En een gemiddelde programmeur snapt threads nog niet eens volledig(inclusief mijzelf)...

Deferred execution bedoel je.
Trouwens, wat hebben threads & deferred execution met elkaar te maken ? Ik snap je vergelijking niet echt.
En, als er één ding is, waar een programmeur / developer juist goed zou moeten in zijn, dan is het het oppakken / leren van nieuwe dingen. Mits een beetje moeite zouden de dingen die je hier aangehaald hebt, echt niet te moeilijk mogen zijn.

[.oisyn]

Snake schreef op maandag 16 november 2009 @ 21:39:
[...]

True, maar m.i. is alleen de preprocessor veranderd om de nieuwe language features te verstaan.

Een preprocessor is een heel ander ding. Dat waar jij het over hebt heet een front-end.

Snake schreef op maandag 16 november 2009 @ 21:39:
Dus ja: de compiler is identiek als je de compiler op zich neemt, reken je de preprocessor erbij, dan niet.

Als je beweert dat dit er niet bij hoort dan snap je niets van compilerbouw . Het parsen van input aan de hand van een grammatica en daar vervolgens een semantische analyse op loslaten is een essentieel onderdeel van een compiler (de front-end). Optimalisatie-analyse en de transformatie van de syntax tree naar een andere vorm, zoals bijv. IL code, is slechts de back-end, maar natuurlijk niet minder belangrijk.

Wikipedia zegt:

A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language (the target language, often having a binary form known as object code)

En

A compiler is likely to perform many or all of the following operations: lexical analysis, preprocessing, parsing, semantic analysis, code generation, and code optimization.

[ Voor 73% gewijzigd door .oisyn op 16-11-2009 23:01 ]

[Alex]

whoami schreef op maandag 16 november 2009 @ 22:32:
[...]
Deferred execution bedoel je.
Trouwens, wat hebben threads & deferred execution met elkaar te maken ? Ik snap je vergelijking niet echt.
En, als er één ding is, waar een programmeur / developer juist goed zou moeten in zijn, dan is het het oppakken / leren van nieuwe dingen. Mits een beetje moeite zouden de dingen die je hier aangehaald hebt, echt niet te moeilijk mogen zijn.

Yep, correct, deferred execution.
De overeenkomst is dat het niet sequentieel as we speak gebeurd. Met dit onverwachte hebben veel mensen problemen en daarnaast is het natuurlijk lastiger debuggen(of eigenlijk te visualiseren).

Ik vind het grappig dat je dat zegt. Ik ben ook van mening dat een programmeur nieuwe dingen makkelijk moet kunnen oppakken. Helaas is het zo dat ik echt het tegenovergestelde tegen kom.
Vaak wordt er ook niet in geïnvesteerd. Ik zorg ervoor dat ik bij een nieuwe .NET versie me hercertificeer maar iig bij blijf via internet of een korte cursus. Maar bedrijven zien dit nut niet zo. Dat is enkel 'duur'.
Gevolgen zijn duidelijk. Weinig stimulans om de nieuwe zaken te gaan gebruiken. En als dat gebeurd, wordt enkel de handige toolkit gebruikt.

Je moet eens weten hoe vaak developers die ik training geef staan te knipperen als ik 15 regels code omschrijf in 4 regels LINQ en 1 additionele Lambda Expressie.
Heel jammer. Maar zelfs ook de kennis van inmiddels bekende frameworks zoals ASP.NET of methodes zoals DataBinding(en dan eventjes een eigen DataBounded control schrijven) zijn niet eens 'common knowledge'.

[Compuhair]

Linq en lambda expressions gebruiken we hier voortdurend. Een hele vooruitgang.
Entity Framework gebruiken we nog niet. Ik heb er een tijd geleden wel naar gekeken, maar toen aanbevolen (als Lead Engineer) dat we NHibernate gingen gebruiken. Dat was zo rond EF v1.0 en v2.0. Ondertussen is EF weer een stuk verder, dus ik ga er zeker nog een keer naar kijken.
Verder maken we hier voornamelijk web apps (en heel soms services) voor omgevingen die nog geen Silverlight hebben. Dus met WPF en Silverlight doen we niks.
WF nog niet gebruikt.
WCF gebruiken we wel.

Ik denk overigens dat al deze technieken best van de grond geraken, maar dat door de enorme hoeveelheid nieuwe zaken de aandacht wat versprokkeld raakt. Kijk maar eens naar de enorme lijst van zaken die je aandacht zou kunnen trekken als programmeur:
LINQ
Entity Framework
WPF / Silverlight
WCF
WF
MVC
Azure
Biztalk
Sharepoint
NServicebus (niet van MS zelf)
SQL Server 2008 (Wij zitten bijvoorbeeld nog met 2000)
VS2010
NHibernate
Test Driven Development
Domain Driven Development

Dus ja, ik kan zo tien developers die zich met MS technologie bezighouden bij elkaar zetten, waarbij ze alle tien hun eigen focus hebben. Ik heb 't gevoel dat dat een jaar of 5 à 7 wel anders was, dat er toen veel minder technologien beschikbaar waren.

Ik moet ook zeggen dat een van de sterke punten van Microsoft technologie altijd was dat er een focus was. Je hoefde niet eerst een keuze te maken uit tig UI-frameworks, databases, datalaag technieken, presentatiemethoden etc. Ondertussen moet je oppassen dat je door de bomen het bos niet meer ziet. Focus wordt voor een developer steeds belangrijker denk ik.

[whoami]

Compuhair schreef op dinsdag 17 november 2009 @ 07:46:

Dus ja, ik kan zo tien developers die zich met MS technologie bezighouden bij elkaar zetten, waarbij ze alle tien hun eigen focus hebben. Ik heb 't gevoel dat dat een jaar of 5 à 7 wel anders was, dat er toen veel minder technologien beschikbaar waren.

Laat ons zeggen dat die 'technologiën' methodologiën toen gewoon veel minder bekend waren bij het grote publiek. Ik heb mijn eerste boek over DDD gekocht in 2005 (bijna 5 jaar geleden), TDD bestaat zeker ook al zo lang ....
Het is pas sinds MS daar ook een beetje naar aan het kijken is, dat het bij het brede publiek ook aan bekendheid geniet, en dat men er zich meer gaat gaan mee bezighouden.

/off-topic

[EfBe]

In .NET 3.5 zat C# 3.0, en die heeft een nieuwe compiler gekregen, en dat is niet even een preprocessor update, want de taal is een volledige versie hoger en de compiler dus ook.

Wat MS in mijn ogen fout doet mbt .NET is het blijven releasen van allerlei 'immature' frameworks rondom .NET zodat je zolangzamerhand door de bomen het bos niet meer ziet, en wat erger is: ALS je al tijd steekt in een technologie, dat die dan een aantal jaar daarna op de intensive care ligt (zie linq to sql en workflow)

Met .NET 3.5 begint het er aardig op te lijken qua framework maar de talen zoals C# en VB.NET gaan echt de verkeerde kant op in .NET 4.0 met veel nutteloze feature toevoegingen om er maar een dynamische taal van te maken ipv dat ze kijken naar dingen die de .net ontwikkelaar werkelijk voorspoed gaan geven zoals custom class loaders (ala java, zodat je at load time je IL code kunt aanpassen /weaven) en AOP support.

De parallellisatie libraries van .NET 4.0 zijn wel weer gaaf, het enige wat werkelijk nuttig is in hun update.

Lambda's gebruik ik erg vaak, net als Linq to objects. Om aan te geven hoe compacter je code wordt: de code base van llblgen pro v3.0's designer is maar 20% groter dan die van 2.6, maar hij heeft wel inmens meer features.

Wat de MS developer nodig heeft is rust, stabiliteit rondom talen en frameworks en de features van die 2 pijlers. Dat is niet sexy en daar verkoop je geen spullen mee, (zie PDC, nu bezig) en helaas zal MS daar niet snel aan denken.

Of .NET veel gebruikt wordt in de wereld... als ik kijk naar de verdeling van de klanten van onze o/r mapper over de wereld dan is .NET in de VS erg groot, veel minder in EU, en in azië niet erg aanwezig m.u.v. india. Australie daarentegen weer wel. Het is geen solide steekproef maar geeft wel een indicatie dat in landen als bv Japan je niet hoeft te verwachten dat daar veel .NET programmeurs zitten, wat niet raar is gezien de jarenlange java traditie daar.

Of dat veel zal veranderen in de toekomst hangt af van de hoeveelheid domme zetten die MS gaat doen. Is dat aantal laag dan zal het meevallen, maar hun trackrecord laat zien dat het lastig gaat worden. Het enige voordeel is wellicht het feit dat Java nu in handen is van Oracle en IBM daar niet blij mee is natuurlijjk, en de mate waarin dyn. talen mainstream aan het worden zijn is IMHO ook wat aan het afvlakken (maar dat is ook hand-waving science, dus pin me er niet op vast ).

Aan de klanten in deze thread: bedankt voor de positieve feedback

[pedorus]

EfBe schreef op dinsdag 17 november 2009 @ 17:43:
Met .NET 3.5 begint het er aardig op te lijken qua framework maar de talen zoals C# en VB.NET gaan echt de verkeerde kant op in .NET 4.0 met veel nutteloze feature toevoegingen om er maar een dynamische taal van te maken ipv dat ze kijken naar dingen die de .net ontwikkelaar werkelijk voorspoed gaan geven zoals custom class loaders (ala java, zodat je at load time je IL code kunt aanpassen /weaven) en AOP support.

Al kijk je naar de toevoegingen, dan zijn dat dingen die de boel eenvoudiger maken en niet al te moeilijk te snappen zijn. Ik noem dingen als optional parameters in c# (eindelijk), auto-implemented properties (minder tikwerk), (co|contra)variance (gebruiken mensen zonder het door te hebben en werkt nu). COM was onhandig in C# en is daarom aangepakt, ook al gebruik je het niet ('nutteloos'), je hebt er in ieder geval weinig tot geen last van. Verder zijn dingen als linq gewoon geweldig als je het mij vraagt, maar dat zeg jij ook al.

De dingen die je voorstelt hebben potentie om enorme WTF's te maken, waarbij je (bijna) geen idee meer hebt waar de code die wordt uitgevoerd vandaan komt. Dat vinden mensen bij MS trouwens ook, het is een 5 jaar oude vraag. Daarnaast kunnen custom class loaders en AOP al grotendeels, en misschien kan het met DLR straks nog wel beter, nog niet naar gekeken.

[Sebazzz]

Een paar dingen snap ik niet...

pedorus schreef op dinsdag 17 november 2009 @ 22:04:
[...]

optional parameters in c# (eindelijk)

Wat is er mis met overloading?

auto-implemented properties (minder tikwerk)

Okey, dit gebruik ik ook maar waarom zou je geen field in plaats van een property gebruiken? Je checkt bij beiden de waardes niet die binnenkomen.

[.oisyn]

Sebazzz schreef op dinsdag 17 november 2009 @ 22:17:
Een paar dingen snap ik niet...

[...]
Wat is er mis met overloading?

Het feit dat je nogal veel moet typen?

[pedorus]

Sebazzz schreef op dinsdag 17 november 2009 @ 22:17:
Wat is er mis met overloading?

Tikwerk, en je hebt theoretisch in de orde van 2^[optionele parameters] aan methodes nodig, en dan nog kunnen ze niet altijd dezelfde naam hebben. Je kan dan zeggen, gebruik een class/struct met parameters, maar dat is ook tikwerk, voegt complexiteit toe, en kost snelheid. Daarnaast is het ook erg handig om gebruik te kunnen maken van default waardes bij externe methodes.

Okey, dit gebruik ik ook maar waarom zou je geen field in plaats van een property gebruiken? Je checkt bij beiden de waardes niet die binnenkomen.

Probeer eens {get; private set;}. Daarnaast hoeven properties geen tijd te kosten, terwijl ze wel duidelijkheid en compatibiliteit opleveren.

[Sebazzz]

.oisyn schreef op dinsdag 17 november 2009 @ 22:26:
[...]

Het feit dat je nogal veel moet typen?

Nou, veel, daar zit vast wel iets in Resharper voor Slecht excuus, als codeklopper hoor je te typen.
Okey ik ben overtuigd

[ Voor 5% gewijzigd door Sebazzz op 17-11-2009 22:32 ]

[.oisyn]

Sebazzz schreef op dinsdag 17 november 2009 @ 22:31:
Slecht excuus, als codeklopper hoor je te typen.

Complete onzin. De bedoeling is je gedachten om te zetten in een programma. Tikken is helaas een noodzakelijk kwaad, maar absoluut niet het doel van je werk.

[EfBe]

pedorus schreef op dinsdag 17 november 2009 @ 22:04:
[...]
Al kijk je naar de toevoegingen, dan zijn dat dingen die de boel eenvoudiger maken en niet al te moeilijk te snappen zijn. Ik noem dingen als optional parameters in c# (eindelijk), auto-implemented properties (minder tikwerk), (co|contra)variance (gebruiken mensen zonder het door te hebben en werkt nu). COM was onhandig in C# en is daarom aangepakt, ook al gebruik je het niet ('nutteloos'), je hebt er in ieder geval weinig tot geen last van. Verder zijn dingen als linq gewoon geweldig als je het mij vraagt, maar dat zeg jij ook al.

C# 1.0 kon al alles wat je nodig had. Hoe meer features je toevoegt aan een taal, hoe complexer de code is voor een lezer van die code en dus een grotere kans op fouten. Het probleem met C# 4.0 is dat er weer meer zaken zijn toegevoegd die de taal weer complexer maken, tot op een niveau waarbij je 2 C# programmeurs kunt hebben die elkaars code niet begrijpen omdat statements worden gebruikt die de ander niet snapt want die gebruikt die statements/constructs nooit. Dit klinkt wellicht sneu, maar het is wel de werkelijkheid, want vergis je niet, het merendeel van de .NET programmeurs begint net aan generics (en heeft daar al moeite mee).

De dingen die je voorstelt hebben potentie om enorme WTF's te maken, waarbij je (bijna) geen idee meer hebt waar de code die wordt uitgevoerd vandaan komt. Dat vinden mensen bij MS trouwens ook, het is een 5 jaar oude vraag.

Tja, good old Eric, hij is dan ook weggegaan.

Daarnaast kunnen custom class loaders en AOP al grotendeels, en misschien kan het met DLR straks nog wel beter, nog niet naar gekeken.

dat je wijst naar postsharp geeft aan dat je niet snapt waar ik op doel. Ik doel op hoe in java ieder programma at runtime geweaved kan worden dmv een custom bytecode manipulator die de classes manipuleert tijdens het laden, in .net kan dat niet, je moet OF post-compile weaving doen, OF proxies gebruiken. De class-loader hack waar jij naar verwijst is niet wat ik bedoel, ik bedoel dat je code compileert as-is en at runtime aanpast, bv door extra code erin te weaven voor profiling / monitoring, aop of bv change tracking van een entity class.

[HawVer]

EfBe schreef op woensdag 18 november 2009 @ 08:28:
[...]

C# 1.0 kon al alles wat je nodig had. Hoe meer features je toevoegt aan een taal, hoe complexer de code is voor een lezer van die code en dus een grotere kans op fouten. Het probleem met C# 4.0 is dat er weer meer zaken zijn toegevoegd die de taal weer complexer maken, tot op een niveau waarbij je 2 C# programmeurs kunt hebben die elkaars code niet begrijpen omdat statements worden gebruikt die de ander niet snapt want die gebruikt die statements/constructs nooit. Dit klinkt wellicht sneu, maar het is wel de werkelijkheid, want vergis je niet, het merendeel van de .NET programmeurs begint net aan generics (en heeft daar al moeite mee).

Mee eens. Generics in zijn basis vereist al wat abstract denken. Generics in generics en gecombineerd met interfaces is erg krachtig en je kan er mooie dingen mee doen. Dan ga je alweer een niveautje hoger zitten. Het deferred execution heb ik aan collega's geprobeerd uit te leggen maar ik kon en kan het ze nog steeds niet aan hun verstand peuteren. LINQ kun je ze nog een beetje uitleggen maar als je ze dan vertelt dat je met een dezelfde LINQ ook queries op het EF kunt doen kijken ze je wazig aan. Op een gegeven moment wordt het te abstract.

[whoami]

EfBe schreef op woensdag 18 november 2009 @ 08:28:
[...]

dat je wijst naar postsharp geeft aan dat je niet snapt waar ik op doel. Ik doel op hoe in java ieder programma at runtime geweaved kan worden dmv een custom bytecode manipulator die de classes manipuleert tijdens het laden, in .net kan dat niet, je moet OF post-compile weaving doen, OF proxies gebruiken. De class-loader hack waar jij naar verwijst is niet wat ik bedoel, ik bedoel dat je code compileert as-is en at runtime aanpast, bv door extra code erin te weaven voor profiling / monitoring, aop of bv change tracking van een entity class.

PostSharp is idd een compile-time weaver, maar, er bestaan wellicht ook runtime-weavers (spring.net), of bedoel je dat nog niet ?

[EfBe]

whoami schreef op woensdag 18 november 2009 @ 08:54:
[...]

PostSharp is idd een compile-time weaver, maar, er bestaan wellicht ook runtime-weavers (spring.net), of bedoel je dat nog niet ?

die zijn allemaal gebaseerd op dynamic proxy: je doet geen 'new ClassType()' maar gebruikt een factory die een dynamic gegenereerde subclass instance teruggeeft, dus je krijgt geen instance van ClassType maar van een subtype van ClassType.

Dit kan goed werken maar heeft nadelen.

[pedorus]

HawVer schreef op woensdag 18 november 2009 @ 08:44:
[...]

Mee eens. Generics in zijn basis vereist al wat abstract denken. Generics in generics en gecombineerd met interfaces is erg krachtig en je kan er mooie dingen mee doen. Dan ga je alweer een niveautje hoger zitten. Het deferred execution heb ik aan collega's geprobeerd uit te leggen maar ik kon en kan het ze nog steeds niet aan hun verstand peuteren. LINQ kun je ze nog een beetje uitleggen maar als je ze dan vertelt dat je met een dezelfde LINQ ook queries op het EF kunt doen kijken ze je wazig aan. Op een gegeven moment wordt het te abstract.

Nou is de grap dat de language features blijkbaar wel nog zijn uit te leggen, maar dat de libraries het probleem zijn. En we hadden het over het eerste, anders had ik ook de nuttige parallel extentions kunnen noemen. Dingen als optional parameters zijn verder nou niet echt moeilijk te begrijpen ofzo, ze zitten al vanaf het begin in VB. Dat het ingewikkelder wordt lijkt me niet een goed argument om ze niet toe te voegen. Exact welke nieuwe language features zouden ze niet toe moeten voegen dan?

EfBe schreef op woensdag 18 november 2009 @ 13:57:
Dit kan goed werken maar heeft nadelen.

Toch mis ik even de usage scenario's die goed genoeg zijn dat deze nadelen prioriteit moeten krijgen. Profiling kan al lang, change tracking toevoegen kan (normaal gesproken) ook compile time, en aop is geen doel op zich, sterker nog, het heeft als nadeel dat het onduidelijker wordt welke code wanneer wordt uitgevoerd met welk resultaat. Zolang de voordelen niet duidelijk zijn, lijkt het mij terecht dat MS nog even de kat uit de boom kijkt. Wat zouden ze precies anders moeten doen dan?

[EfBe]

Dat jij niet snapt wat voor voordelen frictionless AOP weaving heeft (dus je maakt code en je kunt zonder de compiled dll te veranderen code inweaven) betekent niet dat het niet nuttig is. Voorbeeld? Je hebt een grote webservice in java en je wilt weten of het performt als in: je wilt periodiek zien hoe lang bepaalde methods over hun werk gedaan hebben. Je kunt profilen, maar dat is intrusive en de profiler profiled alles, terwijl jij bv alleen geinteresseerd bent in een paar classes en methods. dan weave je die code in at runtime en je bent klaar.

Als je dat eenmaal in werking gezien hebt, dan ga je niet meer roepen dat aop zich eerst nog maar moet bewijzen, dan ga je je afvragen waarom het op .net nog niet zo werkt. (Het antwoord daarop is overigens Hejlsberg zelf, die falikant tegen aop is, zonder argumenten overigens, want de argumenten die hij gebruikt, dat je code niet overzichtelijk wordt, is ook te gebruiken tegen andere features die wel in c# zitten)

[pedorus]

EfBe schreef op donderdag 19 november 2009 @ 09:27:
Dat jij niet snapt wat voor voordelen frictionless AOP weaving heeft (dus je maakt code en je kunt zonder de compiled dll te veranderen code inweaven) betekent niet dat het niet nuttig is.

Dat klopt, maar ik denk dat ik daar niet de enige in ben, sterker nog, [google="frictionless AOP weaving"] geeft nog 0 resultaten. Als ik zoek op AspectJ of aop java, dan krijg ik ook niet echt een overmacht aan overtuigende filmpjes (zoek ter vergelijking even op linq), terwijl het al sinds 2001 beschikbaar is.

Als je dat eenmaal in werking gezien hebt, dan ga je niet meer roepen dat aop zich eerst nog maar moet bewijzen, dan ga je je afvragen waarom het op .net nog niet zo werkt.

Waar kan ik kijken? Bedoel je AspectJ of iets anders?

(Het antwoord daarop is overigens Hejlsberg zelf, die falikant tegen aop is, zonder argumenten overigens, want de argumenten die hij gebruikt, dat je code niet overzichtelijk wordt, is ook te gebruiken tegen andere features die wel in c# zitten)

Als je het @runtime wil doen, lijkt het me niet zozeer een c# iets. Het c# team is ook lange tijd tegen optional parameters geweest, maar VB heeft het al heel lang.

[SiErRa]

Arise schreef op zondag 15 november 2009 @ 20:30:
Ik vraag mij af hoe het zit met .Net 3.5 uptake. Ik bedoel, er zijn behoorlijk wat nieuwe zaken geïntroduceerd sinds .Net 2.0, maar nu vraag ik mij af of ze ook van de grond geraken en of het interessant wordt om er ook eens naartoe te beginnen kijken. Zien jullie in de praktijk (werkomgeving) WPF, WCF, Workflow, LINQ, ADO Entities framework gebruikt worden of komt het moeilijk van de grond ?

• WPF - Bij de klanten waar ik zit wordt eigenlijk alleen voor web ontwikkeld dus nog niet gebruikt, al weet ik wel dat er bij andere klanten projecten met Silverlight als frontend gedaan worden.
• WCF - We bouwen hoofdzakelijk binnen SOA omgevingen en gebruiken WCF op elke service, maar wel gebruiken nog niet echt alle features, custom behaviors voor identity flow overigens wel. Voorheen gebruikten we WSE ook al volop.
• WF - Veel enterprise apps gebruiken statussen en dan kan je workflow al best snel inzetten, al vind ik dat je toch nog wel vrij veel custom moet bouwen om goed inzicht in je instances te houden, de WF uit .Net 4.0 gaat wel de goede kant op
• LINQ - nog niet echt veel, lambda expressies wel (veel mensen denken dat dat pas vanaf 3.5 kan, maar dat kon met 2.0 ook al)
• EF - Is bij de meeste PoCs bij ons toch te licht bevonden, van oudsher zijn we nogal stored procedure fans, dus OR mappers worden binnen ons bedrijf nog (te) weinig gebruikt

Maar ik moet net als enkele posters boven me aangeven dat ze met .Net 4.0 wel helemaal los zijn gegaan en afvraag hoeveel developers het allemaal echt goed bij kunnen houden.