Toepassing .NET in Longhorn beperkt
Nadat Microsoft eerder deze week de eerste beta's van de WinFX-API beschikbaar maakte, doet nu het gerucht de ronde dat daarmee meteen het leeuwendeel van de in Longhorn toe te passen .NET-code is bestreken. De bijzonder zware systeemeisen van Longhorn, die deels veroorzaakt zouden worden door een nog te traag en te instabiel managed code-model, zouden Microsoft namelijk genoopt hebben een flink deel van Longhorn nu toch maar met 'proven technology' te herbouwen. Het zou geen haalbare kaart zijn om alle functionaliteit in de .NET-omgeving te coden en toch voor eind 2006 een fatsoenlijk snelle en stabiele versie op de markt te krijgen. Nadat vorig jaar al het filesysteem WinFS werd geschrapt, lijkt dit de tweede grote tegenvaller voor het nieuwe besturingssysteem.
Versie 2.0 van het .NET-framework zal wel worden meegeleverd, en Longhorn-onderdelen als het grafische subsysteem Avalon en het communicatieplatform Indigo zullen daar wel gebruik van maken. Een anonieme developer laat weten dat hij de schijnbare stap terug geen slechte zaak vindt: 'Een groot voordeel is dat ontwikkelaars niet naar .NET hoeven over te stappen als ze de nieuwe Longhorn-features willen gebruiken'. Het bijbehorende nadeel is dat er op deze manier voorlopig nog geen einde komt aan de beruchte 'Win32 dll hell', het verschijnsel dat applicaties die van verschillende versies van dezelfde library gebruik maken elkaar in de wielen rijden. Een volledig op WinFX-technologie gebouwd OS had daar een eind aan kunnen maken. Een reactie van Microsoft blijft vooralsnog uit, maar de softwaregigant heeft nooit eerder hard toegezegd dat Longhorn wél volledig op .NET gebaseerd zou worden.
Reacties (57)
Ben ik de enige die dit niet jammer vind? Een groot gedeelte .net toepassingen die ik tot nu toe tegen ben gekomen draaien echt bagger traag, en zo slecht ben ik nu ook weer niet bedeeld hier.
Wat dat betreft heb je helemaal gelijk maar toch vind ik .net wel ok, ik gebruik het nog niet professioneel maar heb er al wel mee gespeeld. Met name voor het maken van webapplicaties vind ik de volwassen programmeertaal toch beter als het beperkte asp waarmee ik nu werk.
Groet, D.
Groet, D.
Dat is dus gewoon onkundig gebruik van de ontwikkel tooling, wat je niet moet vergeten, is dat de afgelopen paar jaar, een aantal "omschoolde mensen" een poging heeft gedaan om te programeren. Oneerbiedig gesproken, er zijn een stelletje PRUTERS nog altijd in de omloop, bij elk (al dan niet inhuur) bedrijf. Waar je tranen van in je ogen krijgt als je de code onderogen ziet.
Wie begrijpt waar hij mee bezig is, fatsoenlijk codeert, en ook nog even netjes een stress test met een paar honderd, paar duizend, of nog veel meer, clients op zijn applicatie los laat, Krijgt .Net applicaties, waarvan je beseft, hoe dankbaar je ben voor .net
Het probleem van .net is dus eigenlijk dat de drempel om er wat mee te maken, te laag is
Want wie thuis iets aan de gang krijgt met .net, is het nog niet waard om verantwoordelijk zijn voor bedrijfs critische applicaties.
Wie begrijpt waar hij mee bezig is, fatsoenlijk codeert, en ook nog even netjes een stress test met een paar honderd, paar duizend, of nog veel meer, clients op zijn applicatie los laat, Krijgt .Net applicaties, waarvan je beseft, hoe dankbaar je ben voor .net
Het probleem van .net is dus eigenlijk dat de drempel om er wat mee te maken, te laag is
Want wie thuis iets aan de gang krijgt met .net, is het nog niet waard om verantwoordelijk zijn voor bedrijfs critische applicaties.
Dat geldt toch zeker voor elke programmeer- taal/omgeving?Want wie thuis iets aan de gang krijgt met .net, is het nog niet waard om verantwoordelijk zijn voor bedrijfs critische applicaties.
Net zoals dat niet iedereen die ooit eens met Word een webpagina heeft gefabriceerd een webdesigner is?
Waarom denk je dat softwarehuizen die zichzelf serieus nemen een zogenaamde style-guide opzetten?
Daarin kunnen ze vastleggen hoe applicaties van hun hand opzetten, hoe (en ook belangrijk waarom) er bepaalde code-structuren zijn aangelegd...
Zelf heb ik een aantal jaren geleden bij een bedrijf gewerkt dat zo'n guide aan het opzetten was, en daar werden de programmeurs er gewoon allemaal bij betrokken, en wisten ze uiteindelijke een guide te creeren waarin beschreven stond hoe de programmeurs daar te werk gingen.
Dat zorgde er op zijn beurt voor dat de programmeurs makkelijker elkaars code konden overnemen omdat er min of meer gestandaardiseerd werdt geprogrammeerd...
Jammer. WinFX was eigenlijk de nieuwe programmeerinterface (API zeg maar) die volledig in managed C#-code geschreven zou worden. Dit werd blijkbaar te belastend voor de systemen die tegen de lanceringstijd van Longhorn beschikbaar zouden zijn. Gelukkig zijn de twee belangrijkste, en meteen ook de nieuwe, api's wel in managed code geschreven, zijnde Avalon en Indigo.
Het was eigenlijk misschien ook wel een beetje onrealistisch om in één klap de volledige Windows-API overboord te gooien en in .NET-code te herschrijven. Toch zet MS met Avalon en Indigo alvast een stap in de goeie richting hiervoor. Dat .NET-applicaties trager zijn klopt overigens niet helemaal volgens mij. Bij een eerste keer opstarten zijn ze trager, wat dat betreft zijn ze imho vergelijkbaar met java: een eerste keer opstarten is trager, maar alle volgende runs gaan net lekker snel.
Dat het gebruik van managed code invloed heeft op de prestaties kan ik me weer wel inbeelden.
-- EDIT --
Het was eigenlijk misschien ook wel een beetje onrealistisch om in één klap de volledige Windows-API overboord te gooien en in .NET-code te herschrijven. Toch zet MS met Avalon en Indigo alvast een stap in de goeie richting hiervoor. Dat .NET-applicaties trager zijn klopt overigens niet helemaal volgens mij. Bij een eerste keer opstarten zijn ze trager, wat dat betreft zijn ze imho vergelijkbaar met java: een eerste keer opstarten is trager, maar alle volgende runs gaan net lekker snel.
Dat het gebruik van managed code invloed heeft op de prestaties kan ik me weer wel inbeelden.
-- EDIT --
Er zijn verschillende grafische 'runlevels' die je kunt instellen afhankelijk van de mogelijkheden van je hardware. Bovendien is het volgens mij niet het weergeven van de grafische dingen die in managed code gebeurt, maar wel de volledige API om de grafische functies aan te roepen en dergelijke. Het lijkt mij niet zo te zijn dat ze zullen proberen een 3d-omgeving in C# te schrijvenIk vraag me echter af in hoeverre die nieuwe .NET-gebaseerde grafische de zaak gaat vertragen (Kun je die niet uitzetten???).
vind je dat zo erg?
Ik merk als programmeur (MFC, .NET en linux based spul) dat veel .NET progjes echt heel erg traag zijn.
Dit is ook te zien bij Java omdat beide platformen interpreted zijn, waardoor alles wat je draait een extra stap moet maken (de interpreter)....
En dat is dus niet zo snel; je merkt het niet bij zoiets als een rekenmachine-progsel maar bij een OS wel.
Ik vraag me echter af in hoeverre die nieuwe .NET-gebaseerde grafische de zaak gaat vertragen (Kun je die niet uitzetten???).
Ik merk als programmeur (MFC, .NET en linux based spul) dat veel .NET progjes echt heel erg traag zijn.
Dit is ook te zien bij Java omdat beide platformen interpreted zijn, waardoor alles wat je draait een extra stap moet maken (de interpreter)....
En dat is dus niet zo snel; je merkt het niet bij zoiets als een rekenmachine-progsel maar bij een OS wel.
Ik vraag me echter af in hoeverre die nieuwe .NET-gebaseerde grafische de zaak gaat vertragen (Kun je die niet uitzetten???).
Sun's JIT compiling komt anders mooi in de buurt van native code; kan me niet voorstellen dat die van MS zo slecht is?
ten eerste, de JVM zal altijd op moeten blijven starten..
ten 2e ik heb nog nooit een java programma gebruikt dat even snel was als een native gecode programma. met de JIT compiler is alles al wat beter geworden.. maarja daartegenover moet je wel wat(soms aanzienlijk) geheugen inleveren
ten 2e ik heb nog nooit een java programma gebruikt dat even snel was als een native gecode programma. met de JIT compiler is alles al wat beter geworden.. maarja daartegenover moet je wel wat(soms aanzienlijk) geheugen inleveren
Ja maar als je alles in het OS bakt dan is het al opgestart, daarnaast heb je theoretisch maar één garbage collector nodig en kun je al het geheugen gebruiken. Maar ja, dat is natuurlijk ook de reden waarom java op servers veel beter werkt, op een desktop word java klein gehouden.
@DLGandalf
Het opstarten van een JVM is natuurlijk totaal irrelevant voor de performance. Die vertraging heb je namelijk slechts éénmalig ook als je een programma 8 uur per dag gebruikt......
En dat je geen ervaring hebt met snelle java programma's zegt meer over jou dan over java. JIT compilers bestaan namelijk al zo ongeveer sinds java beschikbaar is. Dat java programma's meer geheugen gebruiken? Vast wel, een JVM neemt nu eenmaal ruimte in, maar je hebt stukken minder last van memory leaks. Het op hol slaan van je geheugenbeheer zul je bij java programma's dan ook veel minder tegenkomen dan bij bijvoorbeeld C++
Het opstarten van een JVM is natuurlijk totaal irrelevant voor de performance. Die vertraging heb je namelijk slechts éénmalig ook als je een programma 8 uur per dag gebruikt......
En dat je geen ervaring hebt met snelle java programma's zegt meer over jou dan over java. JIT compilers bestaan namelijk al zo ongeveer sinds java beschikbaar is. Dat java programma's meer geheugen gebruiken? Vast wel, een JVM neemt nu eenmaal ruimte in, maar je hebt stukken minder last van memory leaks. Het op hol slaan van je geheugenbeheer zul je bij java programma's dan ook veel minder tegenkomen dan bij bijvoorbeeld C++
@All here over snelheid van Java/.NET
Ik ben vrij intensief bezig geweest met Java, het optimaliseren ervan, en bytecode in het algemeen (heb eigen interpreter en bytecode compiler geschreven).
Bytecode op zich is niet "traag", en een JIT kan en zal inderdaad de performance drastisch verbeteren, MAAR - er is een grote maar. Zowel java als C# (en veel .NET talen) hun manier om met strings te werken is niet echt voordelig voor de performance, en het is niet het enige wat de performance naar beneden haalt. Er zijn een hoop trade-offs voor flexibiliteit en veiligheid gemaakt waarbij er aan performance is ingeboet. Dit zit op zeer laag niveau, wat wil zeggen dat dit zelfs als dit door een JIT gedraaid wordt er een hoop overhead is tijdens runtime. Er zijn gewoon zowel in .NET algemeen als in Java een hoop concepten die niet goed samengaan met "high performance", hoewel daar hard aan gewerkt wordt (zie de nio interfaces in java).
Theoretisch zijn de concepten van .NET en Java prachtig, ze verschillen onderling niet zo heel veel (buiten dat .NET multilanguage bytecode is, wat heel mooi is) maar praktisch zijn ze nog steeds niet altijd haalbaar. Sun was extreem veel te vroeg met Java, op het ogenblik dat dit uitkwam was de kracht van de PC's veel te laag, en wogen de voordelen niet op tegen de nadelen (traagheid). Nu begint dit echter doenbaar te worden desktop applicaties te gaan schrijven in Java of .NET (zie Netbeans/Azareus/Paint.net/...). Integratie in de core van een OS van .NET lijkt mij echter niet haalbaar. Het is - zoals het artikel ook zegt - niet volwassen genoeg. Zelfs Java zou er nog problemen mee hebben vrees ik, hoewel nu de 1.5 een hoop enorme verbeteringen under the hood, maar dit was dan vooral onder druk van .NET. Java is al een pak volwassener, en mijn stelling die vele mensen niet geloofden - dat .NET niet volwassen is, wordt hierbij eigenlijk bevestigd.
Ik ben vrij intensief bezig geweest met Java, het optimaliseren ervan, en bytecode in het algemeen (heb eigen interpreter en bytecode compiler geschreven).
Bytecode op zich is niet "traag", en een JIT kan en zal inderdaad de performance drastisch verbeteren, MAAR - er is een grote maar. Zowel java als C# (en veel .NET talen) hun manier om met strings te werken is niet echt voordelig voor de performance, en het is niet het enige wat de performance naar beneden haalt. Er zijn een hoop trade-offs voor flexibiliteit en veiligheid gemaakt waarbij er aan performance is ingeboet. Dit zit op zeer laag niveau, wat wil zeggen dat dit zelfs als dit door een JIT gedraaid wordt er een hoop overhead is tijdens runtime. Er zijn gewoon zowel in .NET algemeen als in Java een hoop concepten die niet goed samengaan met "high performance", hoewel daar hard aan gewerkt wordt (zie de nio interfaces in java).
Theoretisch zijn de concepten van .NET en Java prachtig, ze verschillen onderling niet zo heel veel (buiten dat .NET multilanguage bytecode is, wat heel mooi is) maar praktisch zijn ze nog steeds niet altijd haalbaar. Sun was extreem veel te vroeg met Java, op het ogenblik dat dit uitkwam was de kracht van de PC's veel te laag, en wogen de voordelen niet op tegen de nadelen (traagheid). Nu begint dit echter doenbaar te worden desktop applicaties te gaan schrijven in Java of .NET (zie Netbeans/Azareus/Paint.net/...). Integratie in de core van een OS van .NET lijkt mij echter niet haalbaar. Het is - zoals het artikel ook zegt - niet volwassen genoeg. Zelfs Java zou er nog problemen mee hebben vrees ik, hoewel nu de 1.5 een hoop enorme verbeteringen under the hood, maar dit was dan vooral onder druk van .NET. Java is al een pak volwassener, en mijn stelling die vele mensen niet geloofden - dat .NET niet volwassen is, wordt hierbij eigenlijk bevestigd.
Als ontwikkelaar zou je ook weten dat het niet geïnterpreteerd wordt, maar JIT gecompileerd.
Dus de eerste keer inderdaad langzamer, maar daarna zelf mogelijk sneller omdat de resulterende machinecode precies op jouw OS en hardware kan worden afgestemd!
Er zijn overigens trucs om de gecompileerde code te gebruiken i.p.v. steeds de IL te compilen...
Voor de niet ontwikkelaars:
JIT compileren= Just In Time, code wordt pas gecompileerd als het nodig is.
IL = Intermediate Language: Dotnet compileert code tot IL. Deze IL is nog platformonafhankelijk en wordt verder JIT gecompileerd.
Dus de eerste keer inderdaad langzamer, maar daarna zelf mogelijk sneller omdat de resulterende machinecode precies op jouw OS en hardware kan worden afgestemd!
Er zijn overigens trucs om de gecompileerde code te gebruiken i.p.v. steeds de IL te compilen...
Voor de niet ontwikkelaars:
JIT compileren= Just In Time, code wordt pas gecompileerd als het nodig is.
IL = Intermediate Language: Dotnet compileert code tot IL. Deze IL is nog platformonafhankelijk en wordt verder JIT gecompileerd.
Java heeft natuurlijk ook een platformonafhankelijke 'IL', alleen is die wat ongelukkig 'Java bytecode' genoemd... Dus code tot IL compileren is niet enkel iets van .NET.
Dat een .net-style API beschikbaar zou zijn betekent toch niet dat de achterliggende code ook direct .net moet zijn?Jammer. WinFX was eigenlijk de nieuwe programmeerinterface (API zeg maar) die volledig in managed C#-code geschreven zou worden.
Dat is ook wat ik in de eerste instantie dacht. Vergeet echter niet dat je iha niet razendsnel kunt switchen tussen native en vm code. Stel dat de hele .net api slechts een dunne wrapper om een native api was, dan -zou- het kunnen zijn dat door al die context switches (context in dit geval VM <-> native) de overhead toch nog behoorlijk groot is tov fully dynamic translated IL code.Dat een .net-style API beschikbaar zou zijn betekent toch niet dat de achterliggende code ook direct .net moet zijn?
Dit is slechts een aanname hoor, ik ben al een tijdje weg uit de MS wereld (wel veel gedaan met MFC en win32 altijd), maar gevoelsmatig zeg ik dat dit wel eens mee zou kunnen spelen.
De VM is toch geen interpreter? Volgens mij zijn dat soort 'context switches' helemaal niet zo duur.context switches (context in dit geval VM <-> native)
In .NET is de VM geen interpreter nee. IL Code wordt -altijd- gecompiled. Het blijft echter -wel- een VM, anders was het hele .NET concept niet meer dan een volledig automatisch make/build process.
Types kunnen bijvoorbeeld niet willekeurig zijn binnen de VM, maar moeten bepaalde high-level kenmerken hebben. Daarom konden C++ templates niet zonder meer naar IL code gecompileerd worden en van daar naar native.
Ik weet niet precies hoe het in .Net zit. Ik weet iniedergeval wel dat de Java VM ook haar code compileerd, en dat daar native calls wel altijd duur zijn.
Types kunnen bijvoorbeeld niet willekeurig zijn binnen de VM, maar moeten bepaalde high-level kenmerken hebben. Daarom konden C++ templates niet zonder meer naar IL code gecompileerd worden en van daar naar native.
Ik weet niet precies hoe het in .Net zit. Ik weet iniedergeval wel dat de Java VM ook haar code compileerd, en dat daar native calls wel altijd duur zijn.
Toch wel. Typen moeten ge-unboxed en geboxed worden, telkens als je over de CLR boundary gaat.Volgens mij zijn dat soort 'context switches' helemaal niet zo duur
Ik blijf het toch erg raar vinden dat een nieuw besturingssysteem net zoveel computerkracht nodig heeft als waar we een paar jaar geleden kernexplosies mee simuleerden.
Damm wat heerst Mac OS X dan met haar systeemwijde .Mac-integratie. 
nou, het is dat vrijwel niemand het wil kopen anders zou het nog een concurrent kunnen worden 
[OT] Vrijwel niemand? Op dit moment heeft .Mac meer dan 500.000 betalende abonnees! Zeker niet slecht voor een Mac only (muv WebMail) dienstnou, het is dat vrijwel niemand het wil kopen anders zou het nog een concurrent kunnen worden
BTW Wat heeft .Net in vredenaam met .Mac te maken?
Met .Mac wordt waarschijnlijk het object georienteerde Cocoa van apple bedoeld. Het is sterk vereenvoudigd om de vergelijking zo te maken, maar inderdaad is de grote overeenkomst dat .net en Cocoa beiden object georienteerd zijn.
ben ik de enige die het snapt, of overschat ik gewoon de intelligentie van de parent? anyway, IK denk dat het een grap was, natuurlijk zijn .mac en .net totaal niet te vergelijken...
Tegenwoordig zijn ze zo gul met de opensource community een luisterend oor te gunnen, maar als zij zaken zoals dit gaan blijven volhouden benadrukken ze alleen maar het imago van zeveraar te zijn nogmaals... MS is veel blabla, maar uiteindelijk kom je altijd met het standaard pakketje thuis van een zo goed als kale reis... In mijn ogen zal MS naar de opensource community luisteren enkel om te zien wat belangrijk is en welke nieuwe zaken ze wel even snel nog onder hun eigen naam zouden kunnen zetten. Daarbij doen ze niet al teveel moeite om hun eigen ideëen uit te werken en kwaliteit naar de klant toe te leveren ... nogmaals het zijn zeveraars ...
Wordt dan maar een magere koe dan.
Zo'n beetje alles wordt eruit gehaald omdat het niet haalbaar blijkt te zijn en microsoft heeft een nieuwe OS beloofd.
Nou ja nieuw OS. Nieuwe eyecandy en ouwe wijn in nieuwe zakken.
Hoeveel duizenden programmeurs hebben ze ook al weer?
Zo'n beetje alles wordt eruit gehaald omdat het niet haalbaar blijkt te zijn en microsoft heeft een nieuwe OS beloofd.
Nou ja nieuw OS. Nieuwe eyecandy en ouwe wijn in nieuwe zakken.
Hoeveel duizenden programmeurs hebben ze ook al weer?
JIT compilatie in een OS...
Lijkt MIJ een nekslag voor je performance.
Lijkt MIJ een nekslag voor je performance.
De Crusoe processor werkte ook zo. Daar werd het complete OS ge-jit. (OS zelf dacht dat het op een x86 draaide). De snelheid was best behoorlijk, maar idd geen racemonster.
En daarom kun je dus ook pre-jitten zodat er niet gecompileerd hoeft te worden.
Juiste DLL naast je EXE zetten -> opgelost! Het nut van DLL's is dan wel weg maar ja wie geeft er nog om een halve megabyte meer vandaag?Het bijbehorende nadeel is dat er voorlopig nog geen einde komt aan de beruchte 'Win32 dll hell', het verschijnsel dat applicaties die van verschillende versies van dezelfde library gebruik maken elkaar in de wielen rijden.
Nog beter is natuurlijk om van in het begin een DLL te gebruiken die een of ander versiesysteem gebruikt, goeie oude COM bijvoorbeeld.
'k Wil maar zeggen: 'DLL hell' is reëel maar er zijn voldoende manier om het te voorkomen, mits een beetje bewustzijn van het probleem. Hopelijk zorgt Microsoft er dan ook voor dat het probleem gereduceerd blijft in Longhorn. Alles overschakelen naar .NET zou het probleem vervangen met iets dat vaak erger is; een sloom besturingssysteem. En dat gaat niet weg met een simpele DLL patch...
Maar het is toch belachelijk dat je het hele nut van DLL's moet omzeilen om het veilig te kunnen gebruiken in die situaties? Bovendien zijn er ook systeem DLL's die verplicht uit de win directory worden gelezen en niet uit de programmamap.Juiste DLL naast je EXE zetten -> opgelost! Het nut van DLL's is dan wel weg maar ja wie geeft er nog om een halve megabyte meer vandaag?
Wel grappig dat we nu kunnen zeggen dat longhorn "unmanaged code" bevat. De belachelijke term die MS graag uit over code die zich nog niet naar hun opeens verzonnen nieuwe systeem geschikt heeft. De truuk van die term die alle niet .NET code opeens slecht laat klinken, bijt hun nu zelf terug!
Ja, ik wou enkel een paar voorbeelden geven van mogelijke oplossingen van de 'hell'. Liever een "belachelijke" oplossing dan dat.Maar het is toch belachelijk dat je het hele nut van DLL's moet omzeilen om het veilig te kunnen gebruiken in die situaties?
Bovendien zijn er ook systeem DLL's die verplicht uit de win directory worden gelezen en niet uit de programmamap.[/quote]
Voor zover ik weet is elke DLL in de system32 map beveiligd tegen veranderingen. Windows houdt een kopie bij van de vorige versie, die meteen wordt teruggeplaatst. Probeer maar eens bijvoorbeeld d3d9.dll naar je desktop te verslepen. Enkel installatieprogrammas krijgen toegang tot die bestanden, plus andere beperkingen, wat het probleem al sterk reduceert.
Bij mij had 'managed code' al een slechte bijklank.Wel grappig dat we nu kunnen zeggen dat longhorn "unmanaged code" bevat. De belachelijke term die MS graag uit over code die zich nog niet naar hun opeens verzonnen nieuwe systeem geschikt heeft. De truuk van die term die alle niet .NET code opeens slecht laat klinken, bijt hun nu zelf terug!
Ik wil niet dat mijn code 'beheert' wordt door iets anders, ik wil elke instructie rechtstreeks op de processor uitvoeren. Voor webapplicaties is .NET super, maar voor applicaties die klassiek in C/C++ worden geschreven is .NET geen optie...De conclusie: Gebruik de dingen enkel waarvoor ze hun nut bewijzen (gaat veel verder dan .NET). Gelukkig is ook Microsoft daar nu achter gekomen. Maar ja, marketing en de technische afdelingen komen zowiezo niet altijd overeen.
Ik kan me eerlijk gezegd niet herinneren ooit last te hebben gehad van 'DLL hell'.
Jij als eindgebruiker misschien niet, maar als developer is het wel degelijk een groot probleem. Op Linux en consorten kom je er als eindgebruiker misschien wat eerder mee in aanraking ("dependency hell") omdat het veel modulairder is, maar dat wil niet zeggen dat het in Windows niet bestaat. In Longhorn was het idee om met een compleet managed code model in een keer van die hele ellende af te zijn. Probleem is dat niemand ooit zo'n complex geheel als de complete Windows API als managed code framework heeft ontwikkeld, en MS komt er blijkbaar nu achter dat het misschien een veel te ambitieus plan is. Dan hebben ze 2 opties: ofwel Longhorn traag en half af op de markt brengen zodat iedereen in elk geval alvast mee kan werken, en dan in stappen optimaliseren (zoals Apple met OS X deed), of wachten tot ze het helemaal af hebben en in de tussentijd op "proven code" doorbouwen. Allebei de opties zijn niet ideaal...
Als .NET programmeur als professional, wil ik toch benadrukken dat dit niet de slechtste zaak van MS de voorbije jaren. ik zou zelfs het tegendeel durven beweren. misschien heb je voor .NET iets meer verstand en kennis nodig dan dat een doorsnee PHP programmeur heeft van zijn code.
begin nu geen flame-war van PHP is beter dan .NET of andersom, want ieder heeft daar zijn eigen visie over. ik kan alleen maar zeggen wat ik zelf dagelijks zie en te horen krijg. ik denk niet dat bedrijven als Siemens, Alcatel, Sidmar, NMBS, enz hun eigen zo hard vergissen als ze voor .NET kiezen. Er zijn natuurlijk een tal ander bedrijven die dan weer de PHP kant opgaan. As I Said, ieder het zijne.
Betreft Longhorn vind ik het weer zeer spijtig, ze hebben ons zoveel beloofd en uiteindelijk schiet er weer maar een peulschil van over. Blijft MS ons nu bedriegen
Alhoewel ze Whidbey dat dan weer net niet doen.
Het verstandigste zal zijn om gewoon niet in te gaan op al deze berichten en gewoon de tijd af te wachten totdat ie er is. En dan zullen we nog eens babbelen.
Per slot van rekening zal iedereen het toch weer een slecht OS vinden en er een jaar later vlot mee werken
begin nu geen flame-war van PHP is beter dan .NET of andersom, want ieder heeft daar zijn eigen visie over. ik kan alleen maar zeggen wat ik zelf dagelijks zie en te horen krijg. ik denk niet dat bedrijven als Siemens, Alcatel, Sidmar, NMBS, enz hun eigen zo hard vergissen als ze voor .NET kiezen. Er zijn natuurlijk een tal ander bedrijven die dan weer de PHP kant opgaan. As I Said, ieder het zijne.
Betreft Longhorn vind ik het weer zeer spijtig, ze hebben ons zoveel beloofd en uiteindelijk schiet er weer maar een peulschil van over. Blijft MS ons nu bedriegen
Alhoewel ze Whidbey dat dan weer net niet doen.Het verstandigste zal zijn om gewoon niet in te gaan op al deze berichten en gewoon de tijd af te wachten totdat ie er is. En dan zullen we nog eens babbelen.
Per slot van rekening zal iedereen het toch weer een slecht OS vinden en er een jaar later vlot mee werken
De keuze van grote bedrijven is de laatste jaren heel vaak alles behalve logisch te noemen.
Logisch in de zin dat ze slaafs Microsoft volgen, niet logisch als je naar de technische kant van de zaken kijkt.
En nee dit is niet als flame bedoelt, maar er zijn nog altijd bedrijven die Windows als OS nemen voor mission critical server systemen... Dat zegt toch allemaal genoeg ? Idem dus voor hun company keuze van programmeertaal.
Logisch in de zin dat ze slaafs Microsoft volgen, niet logisch als je naar de technische kant van de zaken kijkt.
En nee dit is niet als flame bedoelt, maar er zijn nog altijd bedrijven die Windows als OS nemen voor mission critical server systemen... Dat zegt toch allemaal genoeg ? Idem dus voor hun company keuze van programmeertaal.
Windows kun je best mission critical laten doen, mits je alles goed inregelt, opbouwt en ontwerpt. Fact of the matter is alleen, dat het je gigantische klauwen met geld kost aan hardware en licenties, wat het dan wel onrendabel maakt, dan wel een toekomstig doelwit voor bezuinigingen, wat mogelijkerwijs afbreuk doet aan de integriteit van het platform. (platform is hier specifiek design voor een specifieke applicatie dan wel organisatie).maar er zijn nog altijd bedrijven die Windows als OS nemen voor mission critical server systemen... Dat zegt toch allemaal genoeg
daarnaast heb je nog de gedachtengang bij managers e.d. dat mission critical alleen door gecertificeerde besturingsystemen gedaan kunnen worden, zoals Windows, Solaris, HP-UX, AIX. Ik als (voornamelijk opensource) unix beheerder moet nog regelmatig proberen mensen te overtuigen dat FreeBSD en Linux wel degelijk hele goede alternatieven zijn. (en daar heb ik behoorlijk wat bewijs voor inmiddels).
Ik kan de keuze voor .NET wel begrijpen. Je bespaart echt heel veel ontwikkeltijd en je kunt veel gemakkelijker overzichtelijk werken.
Blijkbaar is het vertrouwen in de ontwikkelingen van hardware van de beslissers in de ICT wereld groot.
Blijkbaar is het vertrouwen in de ontwikkelingen van hardware van de beslissers in de ICT wereld groot.
Ik snap niet dat je als zelfbenoemde ".NET professional" begint over .NET vs. PHP. Da's toch appels met peren vergelijken? .NET is een compleet framework met zeer geavanceerde mogelijkheden. PHP is alleen maar een (web)scripting-taaltje. Je zou nog enigszins de vergelijking tussen ASP.NET en PHP kunnen trekken, maar ook dat is weer een wereld van verschil.
Ik weet wel dat je met PHP ook in beperkte mate desktop software zou kunnen maken (command-line progjes enz.), maar dat doet volgens mij helemaal niemand.
Dat .NET-framework is in mijn ogen juist een van de beste dingen die Microsoft de laatste jaren geproduceerd heeft. Een heel compleet ontwikkelframework en in combinatie met bijv. Visual Studio ook nog eens een ontzettende handige omgeving voor het in zeer korte tijd ontwikkelen van geavanceerde applicaties.
Overigens ben ik niet anti-PHP (gebruik het nog regelmatig voor diverse websites). Maar ik wordt zo moe van al die mensen die .NET met PHP gaan vergelijken, want dat slaat helemaal nergens op.
Ik weet wel dat je met PHP ook in beperkte mate desktop software zou kunnen maken (command-line progjes enz.), maar dat doet volgens mij helemaal niemand.
Dat .NET-framework is in mijn ogen juist een van de beste dingen die Microsoft de laatste jaren geproduceerd heeft. Een heel compleet ontwikkelframework en in combinatie met bijv. Visual Studio ook nog eens een ontzettende handige omgeving voor het in zeer korte tijd ontwikkelen van geavanceerde applicaties.
Overigens ben ik niet anti-PHP (gebruik het nog regelmatig voor diverse websites). Maar ik wordt zo moe van al die mensen die .NET met PHP gaan vergelijken, want dat slaat helemaal nergens op.
Als professional zou je .NET helemaal niet moeten vergelijken met PHP. Dat is appels en peren vergelijken.
Of kun jij voor PHP al Windows applicaties ontwikkelen?
Of kun jij voor PHP al Windows applicaties ontwikkelen?
Dat is idd appels met peren vergelijken, maar misschien bedoelt Harde Willy (ASP).NET ten opzichte van LAMP (Linux, Apache, MySQL, PHP) en dan gaat de vergelijking wel aardig op.
nou.. ze zijn toevallig bezig met een gtkphp projectje...
http://gtk.php.net/
en je kan genoeg command line programma's maken met php analoog aan allerlei perl scripts, bash scripts etc...... php is niet puur en alleen voor webpagina's. Veelgemaakte denkfout
dus "windows programma's" mbv. php zit er aan te komen. Zie ik het ASP framework nog niet zo snel doen .... (of vergis ik me daar, door ook niet verder dan m'n HTTP neus lang is te kijken?)
http://gtk.php.net/
en je kan genoeg command line programma's maken met php analoog aan allerlei perl scripts, bash scripts etc...... php is niet puur en alleen voor webpagina's. Veelgemaakte denkfout
dus "windows programma's" mbv. php zit er aan te komen. Zie ik het ASP framework nog niet zo snel doen .... (of vergis ik me daar, door ook niet verder dan m'n HTTP neus lang is te kijken?)
@cavey:
Je hebt .NET in twee varianten, namelijk ASP.NET en 'gewoon' .NET respectievelijk voor webapplicaties en voor 'windows' applicaties.
Het is niet een andere 'taal' of wat dan ook, slechts andere toepassingen, vergelijkbaar met java en jsp. Ze maken dan ook veelal gebruik van dezelfde libs, en dat heeft samen met taalonafhankelijkheid voordelen. Zo kun je dus logics van je 'windows' applicaties ook integreren in je webapplicaties, en daarbij maakt het niet uit of de classen nou in VB.net geschreven zijn of in C# danwel J#, aangezien er sprake is van een common language interface.
Je hebt .NET in twee varianten, namelijk ASP.NET en 'gewoon' .NET respectievelijk voor webapplicaties en voor 'windows' applicaties.
Het is niet een andere 'taal' of wat dan ook, slechts andere toepassingen, vergelijkbaar met java en jsp. Ze maken dan ook veelal gebruik van dezelfde libs, en dat heeft samen met taalonafhankelijkheid voordelen. Zo kun je dus logics van je 'windows' applicaties ook integreren in je webapplicaties, en daarbij maakt het niet uit of de classen nou in VB.net geschreven zijn of in C# danwel J#, aangezien er sprake is van een common language interface.
er is 1 .NET, geen 2. ASP.NET en winforms en andere zaken gebruiken dezelfde .NET assemblies. Dus wat jij zegt klopt van geen kant.
PHP kun je gebruiken om GTK applicaties te ontwikkelen waarvoor nog een runtime environment voor nodig is, net als dat bij .NET applicaties het geval is.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
