Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 108 reacties
Bron: eWeek

.NET logoTijdens de Financial Analyst Meeting van Microsoft heeft Bob Muglia, senior vice-president van de Server&Tools-divisie, laten weten dat het .NET-platform de afgelopen vijf jaar zo gegroeid is dat het inmiddels meer gebruikt wordt dan Java Enterprise Edition. Inmiddels heeft het .NET-platform een marktaandeel bereikt van 60 procent, terwijl het vijf jaar geleden nog slechts 25 procent was. Volgens Muglia was er dan ook maar één conclusie mogelijk: 'J2EE has run its course'. Om deze voorsprong te behouden, heeft het Redmondse softwarebedrijf enkele plannen gepresenteerd. Zo is Visual Studio Team System op de markt gebracht, software die door middel van technologie het eenvoudiger kan maken om binnen een ontwikkelteam op een goede wijze samen te werken. Gedurende het fiscale jaar 2006, dat eindigde op 30 juni, heeft de Server&Tools-divisie een omzet geboekt van 9,7 miljard dollar. In boekjaar 2007 dat van 1 juli 2006 tot 30 juni 2007 loopt, verwacht Muglia een omzet tussen de 11 en de 11,7 miljard dollar te behalen.

Moderatie-faq Wijzig weergave

Reacties (108)

Toch grappig om te weten dat C# enzo compleet gejat is van Java.

Maargoed persoonlijk moet ik zeggen dat ik C# .NET best aardig vind proggen. Niet moeilijke dingen verzinnen maar gewoon grabbelen uit de brede libary die beschikbaar is.
Erg grappig ook dat je libaries van andere talen kan gebruiken (niet dat ik dat doe maar toch)

Wel jammer dat de snelheid om over te huilen is (net zoals Java trouwens)
Als MS slim is brengen ze het .net framework ook uit voor linux enzo.. maar ik denk dat dat nog een lange weg heeft om te gaan en tot die tijd zal Java nog steeds de enige taal zijn die platform onafhankelijk zal zijn.

@joho

Het voordeel van een "hoge" taal is dat het netjes fouten af kan vangen voor je, mooi kan tracen waar het allemaal is mis gelopen en netjes variabelen niet niet meer gebruikt worden voor je opruimt.
Zoals alles in deze wereld is niks gratis, de kosten van al dit moois is tijd. doordat je in C/C++ direct met het geheugen kan spelen, iets wat in java/C# niet mogelijk is omdat die vituel machine/framework er tussen zit

Maar vooruit ik zal een "open mind" proberen te houden, op welk vlak is java sneller qua uitvoering van "perfecte" code?
Ik ben het met je eens dat het maken van fouten in C sneller kan en daardoor de ontwikkel tijd langer is en het debuggen stukken moeilijker. Maar als de code er eenmaal is dan durf ik best te zeggen dat de zelfde functionalteit sneller in C is dan in java.
Zelfs een "programma" als "hello world" is denk ik sneller in C als in java op de terminal

Java is toch nog steeds niet in machine taal en zal daardoor nog door ene JIT compiler gehaald moeten worden (lees: kost tijd'). Ookal is het vaak 'just in time' voor complexe zaken zal het nog steeds 'just to late' zijn.

en ach het internet staat vol met allemaal idee-en hoe de wereld in elkaar zit, hier een persoon die het tegenover gestelde beweerd van jou link:
http://www.jelovic.com/articles/why_java_is_slow.htm
Toch grappig om te weten dan C# enzo compleet gejat is van Java.
Maar C# is alleen een taal...de taal alleen maakt nog geen .NET.

Persoonlijk ben ik niet echt gek op .NET...nu doe ik alleen webdevelopment de laatste jaren, maar het ASP.NET deel is nou net een van de onderdelen van het .NET platform waar ik een beetje jeuk van krijg doordat MS daarin developers weer stront lui maakt en dat zie je toch terug in de sites...vaak beroerde html uit de standaard componenten. Het postback mechanisme is ook niet iets om trots op te zijn...oftewel wil je in .NET goede sites bakken dan moet je je eigen componenten gaan maken. Dan ben je eigenlijk alle voordelen die MS aangeeft voor ASP.NET kwijt. Componenten zelf bouwen kan ik namelijk voor elke omgeving. Java en LAMP geven je daarin vind ik persoonlijk toch heel wat meer vrijheid om dingen op te lossen zoals jij dat wilt.
welke mogelijkheden heeft Java die een .NET taal niet heeft?
welke mogelijkheden heeft Java die een .NET taal niet heeft?
het feit dat het multiplatform is en .NET niet?

Tuurlijk, MS heeft .NET gedeeltelijk beschikbaar gemaakt voor FreeBSD, een erg charmante schijnbeweging, maar meer ook echt niet.

De huidige zakenmarkt heeft 1 ding waar het zo'n beetje unaniem allergisch voor is: vendor lock-in. De zakenwereld heeft geen intresse in 1 platform en 1 framework, als dat inhoudt dat ze voor 100% afhankelijk zijn van Microsoft.

Java is onmogelijk om vendor lock-in mee te creeeren, je hebt verschillende (al dan niet opensource) VM's, en meerdere applicatie servers. Het feit dat je het ook nog eens op ieder denkbaar OS kunt draaien helpt mee in de populariteit.

Bij ons op de zaak bouwen we iedere maand weer een onnoemelijk aantal applicaties en als 1% .NET is is het veel. Dat is gedeeltelijk onze keuze als de applicatie bouwer, maar voor een zeer aanzienlijk deel de keuze van de klant. Zoveel vertrouwen is er nu ook weer niet in microsoft. (behalve als het om bijvoorbeeld MSSQL gaat).
"De huidige zakenmarkt heeft 1 ding waar het zo'n beetje unaniem allergisch voor is: vendor lock-in. De zakenwereld heeft geen intresse in 1 platform en 1 framework, als dat inhoudt dat ze voor 100% afhankelijk zijn van Microsoft."

Ik denk dat dat gewoon heel erg afhangt in welk deel van de zakenwereld je zit.
Ik kan je verzekeren dat bijna alle Fortune 500 bedrijven (behalve IBM natuurlijk) bijna volledig op Microsoft software draaien.
Deze bedrijven kunnen bijna niet meer overstappen, het enige wat ze kunnen doen is proberen Microsoft te veranderen. (Ze kunnen redelijk veel druk zetten) Deze bedrijven zullen echt wel .Net gaan gebruiken boven bijvoorbeeld Java, omdat ze de cross platform dingen niet echt nodig denken te hebben en vanwege allerlei andere voordelen die .Net biedt.

Je kan wel vertellen dat ze geen interesse in 1 platform en 1 framework, maar ik denk dat ze daar juist wel interesse in hebben omdat de de interoperabiliteit binnen het bedrijf verveelvoudigd.
Bovendien zijn .Net developers goedkoop, is het snel te programmeren en wordt er van Microsoft verwacht dat ze problemen komen oplossen als er wat mis mocht zijn.

Voor het middelgrote bedrijfsleven kan je best gelijk hebben, maar toch denk ik niet dat de interoperabiliteit van Java zo'n grote impact heeft op de beslissing om .Net of Java te nemen. Degenen die dat beslissen worden verteld dat je als je op Linux overstapt nog steeds je .Net applicaties kan draaien via Mono, dus die denken dat het ongeveer de platform onafhankelijkheid redelijk tegen elkaar opweegt.
Waar denk je dat Java van gejat is? ;) De grootvader van beide talen blijft C++, dat op zijn beurt niets meer is dan C met klassen.

Anyway, ik heb geprogrammeerd op beide platformen en geef toch de voorkeur aan .NET. Maar of het J2EE verslagen heeft, ik heb zo m'n twijfels. Zeker omdat dit een uitspraak is van Microsoft zelf.
C++ de grootvader? Vergeet Smalltalk niet. De syntax van Java is op C/C++ gebaseerd, de semantiek lijkt veeleer op Smalltalk dan op C++. Die laatste is, zoals je zelf al zegt, niets meer dan C met klassen. Smalltalk daarentegen is iets totaal anders.

(Jammer trouwens dat de closure niet is overgenomen uit Smalltalk. Een innerclass werkt ook wel, maar het wordt er allemaal niet leesbaarder op.)

Aangaande het hoofdonderwerp:

Het dood zijn van Java: zo'n vaart loopt dat ook weer niet. Sure, Microsoft is een grote speler, maar laten we alsjeblieft Oracle, IBM en SAP niet vergeten. Die zijn heus nog niet verslagen. Een leuke recente ontwikkeling: de Google Web Toolkit.

Verder is er in de enterprise automatisering een dermate grote hoeveelheid aan Java-systemen dat het hooguit "dood als COBOL" zal raken... met andere woorden: in onbruik maar wel onsterflijk. Vergis je ook niet in de hoeveelheid nieuwbouw die nog in COBOL plaatsvindt. De hele financiële sector draait op CICS, Java (en .NET) doen hooguit de messaging en de front-ends.

That said, het is duidelijk dat het J2EE platform aan een grondige herziening toe is. Dat besef is zelfs tot het Java Community Process doorgedrongen. Als je naar javax.persistence kijkt dan zie iets dat verdraaid veel lijkt op Hibernate, met annotations in plaats van XML, en nog maar zo weinig met EJB2.x te maken heeft dat de naam EJB3 welhaast misleidend is (vandaar dat ik liever van javax.persistence spreek).

Overigens geen kwaad woord over .NET. Het is vijf jaar later opgezet dan Java, en je merkt dat ze bij Microsoft verdomd goed hebben gezien welke punten goed zijn (o.a. bytecode/MSIL, ingewikkeld genoeg maar niet ingewikkelder dan dat) en welke punten echt beter moesten (declarative security, strong versioning, JIT vs interpretatie), en dat ze met die kennis ook daadwerkelijk iets moois hebben gemaakt.

Microsoft kan .NET sneller innoveren dan het JCP Java, dat is een individuele leverancier eigen (het JCP is altijd een compromis). Wat je echter in Java veel meer ziet dan in .NET is de kweekvijver van goede ideeën in het Open Source gebeuren, waardoor Java niet de innovatieachterstand heeft die je zou verwachten als je ziet hoe het JCP functioneert (Hibernate is een mooi voorbeeld). Het feit dat .NET van één enkele leverancier komt is een sterk punt, maar tevens een zwakte.

Op het hele gebied van embedded tot aan enterprise zie je dat haast alles geheel op Microsoft technologie is, of geheel niet. In die tweede soort is Java erg sterk vertegenwoordigd. Het is een soort "neutrale grond", voldoende gestandaardiseerd dat het de voordelen daarvan oogst, maar genoeg gefragmenteerd dat alle partijen het kunnen aanvaarden. Ik denk dat Java mede daarom in een prima positie zit om .NET het hoofd te bieden. Een marktverdeling van ongeveer 50/50 (+/-10%) vind ik heel geloofwaardig. Ik zie Java dan ook niet verdwijnen, en wanneer het verdwijnt zal dat niet enkelhandig door toedoen van .NET zijn.

De desktop is wel een ander beeld. Het ontbreken van een standaard, full-featured "applicatieskelet" zoals bijvoorbeeld Delphi dat aanbiedt is een van de hoofdredenen waarom Sun het browser applet -na het te hebben uitgevonden- onmiddellijk is verloren aan Macromedia. Voor de desktop geldt dat niet minder. Voeg daar MS Office als applicatieplatform aan toe en het is overduidelijk dat Java op de desktop voorlopig in de verste verte het marktaandeel van .NET niet kan evenaren.

Als je echter ziet wat er met desktop Java mogelijk is (kijk eens naar de Aerith demo op swinglabs.org), dan zie je dat de technische achterstand intussen behoorlijk is ingelopen. Java Web Start is een veel mooier deployment platform dan waar het erkenning voor krijgt, dus de infrastructuur is er echt wel. Nu de praktijk nog. Er stond laatst een leuk betoog op Artima waarin wordt gesteld dat Sun de java desktop zou moeten / had moeten outsourcen aan Apple.


(edit: paar typo's gecorrigeerd)
Voor de liefhebber zijn er ook
smalltalk.NET
en COBOL.NET
en nog een 30-tal andere programmeer talen/scripttalen die worden ondersteund door .NET
[qoute]That said, het is duidelijk dat het J2EE platform aan een grondige herziening toe is. Dat besef is zelfs tot het Java Community Process doorgedrongen. Als je naar javax.persistence kijkt dan zie iets dat verdraaid veel lijkt op Hibernate, met annotations in plaats van XML, en nog maar zo weinig met EJB2.x te maken heeft dat de naam EJB3 welhaast misleidend is (vandaar dat ik liever van javax.persistence spreek).[/qoute]

en toch is het nog backwards compatible. btw, javax.persistence heeft meer te maken met JPA (java persistence api) dan ejb3, welke er gebruik van maakt. ejb3 is maar de specificatie van de container JPA kan ook los (zo als bij de nieuwe hibernate versies het geval is) geimplementeerd worden.

ik weet niet wat ik toch van de hele .net discussie moet vinden: performance heb ik nog geen echte problemen mee gehad dus dat staat nu niet echt boven aan mijn lijst, innovatie tja de industrie kan ook maar zo snel de veranderingen door voeren; ik bedoel volgens mij halen veel bedrijven nog niet eens de helft uit 1.5 terwijl 1.6 er al bijna weer is. het programmer pooltje van bijde word prima gevult: jonge mensen duiken op .net omdat het microsoft bekend is, en scholen leren hun studenten in de basis java aan en niet .net vanwege entische redenen.
Bij die eerste link kloppen de "facts" m.b.t. Perl al niet (en waar is Perl 5 en 6?).
Ik had het niet over de grootvader van alle talen... Want dan kunnen we wel terug naar 1837 waar het allemaal mee begon. Namelijk Ada Lovelace.
Want als we gaan kijken naar de eerste taal die EN klassen ondersteund EN een syntax heeft waar C# en Java op is gebaseerd, dan komen we toch wel terecht bij C++.
"Toch grappig om te weten dan C# enzo compleet gejat is van Java."

Net als Java compleet gejat is van C++? Nee toch. Overigens begreep ik dat er C# dingen overgenomen zijn in Java... En wat maakt het uit wie wat jat? Ik kan even geen originele dingen verzinnen die in Java zitten. Misschien jij wel?

Wat belangrijk is, wat gebruiken we morgen en overmorgen? Ik gok dat .NET een aardige kans maakt om daar bij te zitten.
Door dit soort opmerkingen, blijft iedereen zeggen wat iedereen zegt. Een soort semi-intelligent doen, van kijk mij eens.
Java/.Net zijn niet langzamer dan dan C/C++. Mischien als je een enkele a=b+c weet te timen.
Google eens op 'java' en 'slow', of verzin je eigen kreet, doe onderzoek voordat je iets napraat. Zo vond ik net http://kano.net/javabench/. Interessant, niet.
Als je me nou gaat vertellen dat mijn C# compiler programma's produceert die net zo snel draaien als de equivalente C programma's gecompileerd door mijn C compiler, dan ga ik je toch eens smakelijk uitlachen.

Talen vergelijken op "performance" is altijd misleidend geweest. Je kunt maar heel globaal conclusies trekken op dat niveau. Java/.NET kan heel snel zijn, als je (JIT) compiler maar goed z'n best doet. C programma's kunnen heel traag zijn, als de programmeur maar dom genoeg te werk gaat. Vergeet ook niet dat de compilers voor de "oude" talen jaren voorsprong hebben op het gebied van optimalisatie.

Daarentegen zullen de meeste mensen het Java/.NET programma veel sneller geschreven hebben dan het C programma, en dat telt voor de meeste toepassingen nog meer mee dan de runtime performance.
@MneoreJ : op zich klopt het wel wat je zegt. Maar vergeet niet dat het .NET Framework daar helemaal niet voor bedoeld is. Voor stukken software waarbij de prestaties erg belangrijk zijn kan je beter unmanaged code schrijven. (wordt op dit moment ook door Microsoft aanbevolen) Op langere termijn zal dat wel wijzigen, maar op korte termijn naar mijn mening niet

Overigens, de meeste mensen die ik met .NET bezig zie snappen vrij weinig van optimalisatie. De beste optimalisatie die je kunt bedenken is het aanpassen van je algorithme. (staat trouwens volledig los van het platform dat je gebruikt) Het lijkt soms wel of mensen de meest moeilijke oplossing kiezen omdat het nou eenmaal zo mooi staat. Hoe minder een ander ervan begrijpt, hoe beter het lijkt. Ik vind het juist een kunst om iets zo eenvoudig mogelijk te maken, hoe minder en simpeler hoe beter.

En voor optimalisatie zijn er binnen het .NET Framework behoorlijk wat dingen te doen. Zoek maar eens op boxen en unboxen, dat kan echt een gruwelijke uitwerking hebben op de prestaties.
Je kan ook zorgen dat de JIT compiler niet gebruikt wordt door de software al in gecompileerde vorm mee te leveren.
Echter je verliest dan wel de voordelen (optimale compilatie voor de doelomgeving).
Je kan wel leuk zeggen dat het niet zo is, maar zelfs ik al doorgewinterde Java programmeur weet dat uiteindelijk in benchmarks een C(++) applicatie een Java applicatie er uit raced. Weliswaar klopt de opmerking van Madcat ook niet (Java is niet zo overdreven slow / de reden waarom hij slow is , klopt ook niet helemaal) maar het is een waarheid dat Java, zelfs met de nieuwste compilers e.d niet sneller is dan een C(++) applicatie die gecompiled is met een beetje zinnige compiler.
C++ => unmanged code
C# => managed code
De unmanged code is snel maar gevoelig voor buffer overflows
De managed code ook, maar dan kun je dat als applicatie-programmeur niet fixen.
Het open source Mono platform draait op Linux en andere *X-en en is grotendeel compatibel met .Net.
Wat is het punt om een framework te maken als je oorspronkelijk toch niet van plan was om andere platformen te gaan ondersteunen ?

Java is werkelijk platformonafhankelijk mits je alles binnen de VM houdt en geen platformspecifieke systemcalls doet etc.

Dat er mono als os alternatief wordt ontwikkeld is mooi, maar natuurlijk niet hetzelfde als een proffesionele jre waar een bedrijf als Sun achter staat en die voor vele platformen aanwezig is !
Een framework is, in termen van software ontwikkeling, een ondersteunende structuur waarop of waarmee software kan worden ontwikkeld. Een framework heeft, of hoeft, niet noodzakelijkwijs direct iets met een platform (OS) te maken.

Dat een bedrijf als Sun achter JRE, of Java in het algemeen, staat kan evengoed ook als last ervaren worden.
Professioneel zegt iets over de manier waarop je iets doet.
'Professie' is gewoon een ander woord voor beroep.
'Professioneel' kun je dus opvatten als iets dat iemand voor z'n beroep doet (een prof-voetballer bv). Dan zegt het niet direct iets over de kwaliteit.

Maar je kunt het ook opvatten als 'vakkundig'... vergelijkbaar met hoe een vakman het zou doen.

Zie ook: http://www.vandale.nl/opz.../?zoekwoord=professioneel

Ik denk dat hier voornamelijk de eerste betekenis bedoeld werd, namelijk dat het bedrijf erachter staat, en dat daarom de JRE voor zoveel platformen beschikbaar is, en onderhouden wordt.
Bij .NET hetzelfde verhaal... Een bedrijf staat erachter met een leger programmeurs die er fulltime aan werken, en een bepaald doel voor ogen hebben. Niet het 'scratch my itch'-principe.
1. Het framework is niet alleen bedoeld voor platform-onafhankelijkheid. Maar ook om een framework te bieden voor 'managed code'. http://en.wikipedia.org/wiki/Managed_code

2. platform onafhankelijkheid betekent niet alleen dat het op verschillende besturingssystemen moet kunnen draaien. SQL server is ook een platform. ASP.NET is ook een platform. WinFX (WinForms) is ook een platform. In die zin is .NET een framework voor meedere platformen (ookal zijn het alleen platformen van Microsoft).
Sinds wanneer is iets wat onder bedrijfstijd gemaakt is 'professioneel' en iets in de eigen tijd niet. Mischien zijn het wel dezelfde mensen. Mischien worden er vanwege bedrijfsbelang wel keuzes gemaakt die iets technisch minder mooi maken, of dat er fouten ongefixed blijven omdat het niet loont.
Professioneel zegt iets over de manier waarop je iets doet.
"Toch grappig om te weten dat C# enzo compleet gejat is van Java."
Maar eigenlijk vind ik het wel een goede zaak, zo zorg je ervoor dat mensen met een Java/C++ achtergrond bijna meteen aan de slag kunnen met C#.

Als je bij de serieus gejatte talen wil kijken, moet je misscien J# eens bekijken. Deze taal is helemaal gemaakt om java applicaties te kunnen porten naar .Net.
En hoe is dat anders dan C++/CLI, Cobol.Net, Fortran.Net, Delphi 8, etc.?

Het idee van .Net was nou juist dat je elke taal naar de CLR kon compilen. En ja, daar moeten soms aanpassingen voor gedaan worden. Javisten kunnen nu zonder problemen een .Net applicatie maken, de syntax is hetzelfde en zowat de hele J2SE class library is beschikbaar.

Het heet J# omdat Java een merknaam van Sun is en MS dat dus niet zomaar mag gebruiken.
> Toch grappig om te weten dan C# enzo compleet gejat is van Java.

Er is veel afgekeken van Delphi en Java, ze hebben geprobeerd het beste van verschillende talen over te nemen en zonodig te verbeteren.

Waarom Delphi? Omdat Anders Hejlsberg (de vader van Turbo Pascal) de lead architect was.
"Als MS slim is brengen ze het .net framework ook uit voor linux enzo.."

Je bedoelt een aap klonen? http://www.mono-project.com/ (mono = aap, en niet mono <-> stereo)

Als jij MS een mooi businessplan kan voorschotelen hoe ze bakken met geld daar uit kunnen halen, wie weet.
doordat je in C/C++ direct met het geheugen kan spelen, iets wat in java/C# niet mogelijk is omdat die vituel machine/framework er tussen zit
Saillant detail: in C# (en dus .Net in het algemeen, maar de taal moet er uiteraard wel ondersteuning voor hebben en dus kan het in VB.Net bijvoorbeeld weer niet) kun je wél met pointers werken zoals je dat in C/C++ kan - het ondersteunt gewoon de C/C++ pointer syntax en de bijbehorende arithmetic. Alleen moet je de code wel markeren als unsafe.

Dit geeft .Net wel die edge die het Java platform niet heeft om wat uiteenlopendere applicaties te maken waar performance (denk bijv. aan games) of het interfacen met hardware van belang is. Zeker C++/CLI is hiervoor uitstekend geschikt.
eerst even kwijt dat in dit topic weer heel veel cliches verteld zijn. Dank aan Barend en madnificent om hun kwaliteitsvolle posts.

Persoonlijk programmeer ik liever in .NET dan in Java. Toen ik aan het solliciteren was, viel me dan ook dik tegen dat er blijkbaar meer vraag was naar Javanen (zoals ze hier blijkbaar genoemd worden) dan naar .NETters. De vacatures waren er wel maar meestal in mindere mate. De bedrijven die ik aansprak gaven ook meestal aan dat ze minder .NET dan Java deden.

De reden dat er weinig overgeschakeld wordt tussen beide is de aanwezige expertise. Je kan heus wel nieuwe mensen aannemen en die op .NET laten werken voor andere projecten, maar je gaat je dure experts niet zomaar omscholen. Als .NET het dan echt moet winnen van Java, dan hebben ze nog minstens een generatie programmeurs te gaan.
Iets wat in het artikel niet staat is waar de cijfers op gebaseerd zijn. 60% van wat? NIeuwe projecten, regels code, aantal ontwikkelaars? Typisch een gevalletje van PR waarbij er iets geroepen wordt zonder dat journalisten even vragen of opschrijven waar dat op is gebaseerd.

Vwb het groter zijn van de vraag naar Java dan .Net ontwikkelaars, dat is simpel uit te leggen. Ook al zouden er meer nieuwe projecten in .Net zijn dan in Java, dan nog heeft Java zo'n enorme installed base dat alleen al voor het onderhouden daarvan veel mensen nodig zullen zijn.

Zelf doe ik ook alleen in Java en ik merk dat het tempo van ontwikkeling nog steeds hoog ligt, zeker als je kijkt naar wat bijvoorbeeld JBoss en Apache Jakarta uitbrengen. Het is voor mij te veel moeite om ook te proberen .Net bij te houden, maar ik zie als ik bijvoorbeeld .Net magazine lees dat er heel erg veel ideeën worden overgenomen. HTTP modules? In J2EE noemen we dat Filters en zo zijn er nog veel meer dingen te noemen.

.Net zit goed in elkaar, maar het is dan ook een jaar of 10 jonger dan Java en heeft daarmee veel meer materiaal gehad om naar te kijken.

Voor .Net is het grootste gevaar een eventueel afkalven van het marktaandeel van Windows, gezien de strakke koppeling tussen .Net en Windows. Dat zal niet zo'n vaart lopen, maar een OS wordt steeds minder relevant.
Wat mij opvalt is dat er uberhaupt onderscheid gemaakt wordt.
Als je java kunt, heb je .NET binnen een paar dagen onder de knie, en vice versa. De concepten zijn vrijwel hetzelfde, en als je C# of J# gebruikt met .NET, dan is zelfs de syntax vrijwel identiek. Een andere API vind ik niet echt een probleem, je zoekt een paar dagen naar de functies, en dan weet je wel ongeveer waar je het kunt vinden, en voor je het weet, ben je er net zo in thuis als de rest.

Ik vond zelf tenminste dat de overstap van Java naar .NET weinig voorstelde.
Ik zie mezelf dan ook niet als een Java-programmeur, of een .NET-programmeur, of wat dan ook.
Ik ben programmeur, en de taal maakt me weinig uit, het is allemaal ongeveer hetzelfde.
Ik heb ondertussen al vaak genoeg projecten gehad met talen die ik tot dan toe nog nooit gezien had. Intussen is m'n lijstje van talen waar ik ervaring mee heb, dan ook behoorlijk compleet. Het lijkt mij dat als je moeite hebt om van Java naar .NET over te stappen, of wat dan ook, dat je dan in die andere taal ook niet echt goed bezig was, en de achterliggende concepten niet helemaal goed begreep. Eigenlijk des te meer reden om eens wat anders te proberen, want als je het vanuit een ander perspectief ziet, dan zie je misschien ineens die verbanden wel.
Het gaat helemaal niet om het leren van een taal, dat is een kwestie van even met je neus in de documentatie. Het gaat, zeker bij enterprise applicaties, juist om de kennis van de API's. En dan bedoel ik nog niet eens zozeer welke functie wat doet, maar hoe je globale problemen oplost. Dat is iets waar je gewoon ervaring voor nodig hebt, als je een dure engineer omschoolt dan duurt het even voordat hij zich die ervaring eigen heeft gemaakt.

Het kunnen programmeren in het algemeen staat hier dus compleet los van.
Het gaat helemaal niet om het leren van een taal, dat is een kwestie van even met je neus in de documentatie. Het gaat, zeker bij enterprise applicaties, juist om de kennis van de API's. En dan bedoel ik nog niet eens zozeer welke functie wat doet, maar hoe je globale problemen oplost. Dat is iets waar je gewoon ervaring voor nodig hebt, als je een dure engineer omschoolt dan duurt het even voordat hij zich die ervaring eigen heeft gemaakt.

Het kunnen programmeren in het algemeen staat hier dus compleet los van.
Dat bedoelde ik ook niet zozeer (ik noemde ook specifiek APIs, maar blijkbaar was het niet duidelijk wat ik bedoelde).
Als je kennis van de ene API hebt, zul je ook makkelijk je weg vinden in een andere API die vergelijkbare functionaliteit heeft. Ik denk dat ervaring vaak overschat wordt.
Als je maar weet wat je wilt doen, dan vind je met de meeste talen en API's gauw genoeg hoe je het moet doen, dat is mijn ervaring tenminste. APIs hebben toch altijd een bepaalde logische structuur, en een bepaalde filosofie. En APIs met vergelijkbare functionaliteit hebben ook vaak vergelijkbare structuren en filosofieen. Natuurlijk zijn er uitzonderingen, maar meestal zitten de verschillen slechts in de details, niet globaal.
In mijn werk kom ik bij de meest uiteenlopende bedrijven met de meest uiteenlopende projecten. Het kost me misschien een dag of 2 a 3 om m'n weg te vinden, maar op een project van een paar maanden is dat verwaarloosbaar, vind ik.
Maar misschien pik ik dingen gewoon veel makkelijker op dan andere programmeurs, dat zou kunnen.
maar meestal zitten de verschillen slechts in de details, niet globaal.
Maar dat is nou juist mijn punt: met de enterprise APIs hoeft dat helemaal niet zo te zijn. Ze hebben een bepaalde visie van hoe dingen benaderd worden, en die visie wordt helemaal niet gedeeld tussen de verschillende platforms. Juist omdat ze zo uitgebreid zijn kunnen ze compleet verschillend van elkaar opgezet zijn. En dan zitten de verschillen juist niet in de details, maar op globaal niveau.

En natuurlijk zal elke degelijke programmeur zichzelf wel een weg kunnen banen, maar dat kost tijd en zeker in het begin zal hij/zij zich nog niet kunnen meten met iemand die ervaring heeft met het platform.
Maar dat is nou juist mijn punt: met de enterprise APIs hoeft dat helemaal niet zo te zijn. Ze hebben een bepaalde visie van hoe dingen benaderd worden, en die visie wordt helemaal niet gedeeld tussen de verschillende platforms. Juist omdat ze zo uitgebreid zijn kunnen ze compleet verschillend van elkaar opgezet zijn. En dan zitten de verschillen juist niet in de details, maar op globaal niveau.
Kun je een voorbeeld noemen dan? Ik ben nog nooit iets tegengekomen dat bij de ene fabrikant zo enorm anders was dan bij de andere fabrikant, dat ik daar weken van wakker moest liggen. Jij blijkbaar wel, dan vraag ik me dus af waar dat is, want het zal wel toevallig een of andere technologische uithoek zijn waar ik me nog niet mee beziggehouden heb.
De geijkte technologieen (zoals bv email, sql, http, xml, filesharing, GUI/graphics etc) vond ik altijd zeer vanzelfsprekend werken.
En natuurlijk zal elke degelijke programmeur zichzelf wel een weg kunnen banen, maar dat kost tijd en zeker in het begin zal hij/zij zich nog niet kunnen meten met iemand die ervaring heeft met het platform.
Ik denk dat je dat soms ook kunt omkeren. Er zijn ook genoeg programmeurs die wel ervaring met iets hebben, maar niet zo 'degelijk' zijn (qua begrip/kennisniveau). Soms kun je beter iemand hebben die wat minder ervaring heeft, maar een degelijkere basiskennis. Als die een paar dagen met een nieuwe technologie stoeit, kan ie daarna meer en betere code afleveren dan een mindere programmeur die het misschien al jaren doet. De verschillen tussen programmeurs zijn soms gigantisch, in werktempo en kwaliteit. Een goede programmeur kan soms wel 10 keer zo snel zijn met iets dan een slechte programmeur, of meer... En z'n code kan ook wel makkelijk 10 keer zo snel zijn, of 10 keer zo klein etc (of meer). Dat soort extreme verschillen kom je volgens mij in geen enkele andere industrie tegen.
Nou, nou. Dat is wel een beetje overdreven. Zelfs als .net fan vind ik dat het iets genuanceerder is. Alhoewel .net vele malen meer in nieuwe omgevingen gebruikt wordt is J2EE nog in heel erg veel systemen aanwezig. Java is daardoor niet zomaar uitgefaseerd. Wel meot Sun opletten dat ze niet de boot missen door 'system upgrades' aan .net te verliezen, maar de verstokte UX-ers zullen nog lang geen .net in gaan zetten.
Tja, ik denk dat Java bij de kleinere ontwikkelaars er langzaam maar zeker uitgaat en dat .NET steeds meer marktaandeel zal krijgen vooral ten koste van Java.

Op zichzelf niets mis mee, .NET is per slot van rekening een ontwikkelplatform dat erg goed in elkaar zit. Het moge dan niet multiplatform zijn ('hacks' als Mono niet meegerekend), maar wellicht is dat ook maar beter. Verschillende OS'en hebben verschillende paradigma's en ideologiën en Java GUI applicaties waren vaak een vreemde eend (trage GUI, knopjes net niet helemaal correct uitgelijnd, etc...). De oplossingen die langzamerhand ontstaan zijn een beetje 'too little, too late'.

Desondanks zullen de grote multinationals nog heel wat jaren Java blijven gebruiken. Veel code is geschreven in die taal en niet meer eenvoudig te vervangen, ook beschikt men vaak over een berg ervaring. En voor applicaties zonder GUI kan Java (wat mij betreft) nog steeds erg geschikt zijn.
"('hacks' als Mono niet meegerekend)"

Als je vergelijkt hoe MS normaal met zijn eigen technologieen omgaat met hoe MS met .Net is omgesprongen mag het toch wel duidelijk wezen dat Microsoft bij .Net eerder geholpen heeft om het ook op andere platformen te laten werken, dan dat het heeft geprobeerd het tegen te werken.
Er is duidelijk gedocumenteerd wat je moet doen om .Net code op je platform te kunnen laten draaien, er is alleen geen implementatie geleverd.
Bij Java wordt wel de implementatie geleverd, maar niet de documentatie.

Maar iig, mijn punt was dat je Mono niet als een hack mag bestempelen :)
wat heeft de architectuur van een systeem dan te maken met het al dan niet multiplatform zijn?

java is uiteindelijk ook niet multiplatform, het ondersteund maar 1 platform: JavaVM, welke bestaat voor meerdere OS'en
maar ik denk (met mono in gedachte) dat, indien MS dit zou willen, .net evengoed op andere OS'en kan werken
Doe eens moeite om je erin te verdiepen, dan lukt het misschien wel om een zinvolle opmerking te maken.

Het feit dat er geen runtime voor andere platformen van het .NET Framework is komt echt niet omdat het niet mogelijk is, dat is gewoon een politieke beslissing van Microsoft.

De basis van het .NET Framework is SSCLI. Ga maar eens kijken wat dat precies is op: http://msdn.microsoft.com.../html/mssharsourcecli.asp

Om alvast een klein stukje te verklappen, SSCLI is ontwikkeld op zowel Windows XP als FreeBSD.
Dat mag misschien waar zijn, maar veel belangrijker is nog de concurrentie met Apache/PHP/MySql. Daar heeft MS nog een lange weg te gaan.

En BRAINLESS01, hoezo klote? Bovendien .Net is vergelijkbaar met J2EE plus Java plus Apache plus een DB, en Java is te vergelijken met C#, dus je vergelijking klopt niet.
PHP kun je absoluut niet vergelijken met .NET. PHP is om websites mee te bouwen en met .NET kun je de hele IT software wereld bouwen (in theorie, praktijk is soms wat lastiger). Daarnaast staat IIS compleet los van .NET en ook MSSQL Server heeft niets met .NET te maken, behalve dat deze tegenwoordig wat makkelijker te integreren zijn met .NET. Je slaat hier de plank dus compleet mis.

Bedrijven die PHP gebruiken bouwen websites en ja dat kan ook met .NET, maar de soort websites die zij bouwen zijn veels te licht voor .NET en voor J2EE. Jouw vergelijking gaat dus niet op. Ik vind dit een erg vreemde vergelijking.

.NET is een ontwikkelplatform met daarbinnen tal van talen als VB.NET, C#, ASP.NET, Cobol.NET, Delphi.NET, Python.NET, Mono (Al dan niet ondersteund door MS). Dit is niet te vergelijken met een taal als PHP. Daarnaast probeer jij een vergelijking te trekken tussen LAMP en een omgeving waarin de database en webserver niet in betrokken worden (godzijdank). Erg vreemde vergelijking dus....

@mxcreep: Ook jouw vergelijking gaat niet op. .NET ondersteunt wel degelijk transacties buiten de database, buiten COM+ om en de snelheid en performance (MSSQL outperformed bijv. MySQL dik. MySQL staat immers niet bekend om de snelheid) van een applicatie ligt aan jouw code, niet aan de platformen.... Beide statements gaan dus niet op.

Dit is natuurlijk wel weer een standaard verkooppraatje wat je kunt verwachten van bedrijven. Er zit wel een kern van waarheid in. Veel (grote) bedrijven stappen over van J2EE naar .NET, maar de snelheid waar dit meegebeurd vind ik nou niet echt wereldschokkend voor om er een persbericht voor uit te sturen. Daarnaast durf ik J2EE ook zeker absoluut niet af te gaan schrijven. Deze omgeving zal nog lang blijven bestaan. Dat Microsoft hun kans grijpt met .NET is al tijden duidelijk.

Typisch weer een statement van een MS bobo waarin hij wel min of meer gelijk heeft, maar natuurlijk de wereld op zijn commercieels best afschildert: Zwart-Wit.
IIS staat niet echt los van .NET maar is zelfs vrij belangrijk voor het draaien van ASP.NET. Ik weet niet of jij al eens geprobeerd hebt om onder bv Apache een ASP.NET applicatie of een WEB Service te laten draaien, maar dat is op dit moment nog niet echt lekker te noemen.

Verder is Mono geen taal zoals VB.Net of C#, maar een open source implementatie van de CLI. En dat is toch heel iets anders ;) En het wordt niet ondersteund door Microsoft, wel is het gebaseerd op de Shared Source Common Language Infrastructure van Microsoft (oftewel Rotor).

Overigens is een ASP.NET applicatie met Mono onder Apache te draaien, maar op dit moment draait het onder IIS toch echt een stuk beter.
Dat is niet helemaal waar, ik heb met de OpenSource webserver Cassini als basis een heel simpele webserver geschreven (in C#) die ASP.NET kan draaien. Cassini is overigens onderdeel van Microsoft WebMatrix, wat een aardig productje is.
Met WSE 3.0 (Web Service Enhancements 3.0) is dat ook mogelijk. In de example sources die daarbij zitten worden webservices ook buiten IIS gehost. Er zijn ook artikelen op MSDN te vinden, waarin wordt beschreven dat ASP.NET zo is ontworpen, dat het niet afhankelijk is van IIS. IIS kan alleen handig zijn om webservices op een georganiseerde manier te hosten (met gecentraliseerde account-control etc).
Je kunt onder PHP ook CLI en GUI (http://gtk.php.net) applicaties maken. PHP is niet bedoelt om websites mee te maken, het is een general purpose taal. Daarnaast staat MySql wel bekend om z'n snelheid maar alleen als het simpele queries betreft.
Doe normaal man, php is voor websites, dat is de oorsprong en dat is waar php voor ontwikkeld wordt.
Dat je er toevallig ook andere dingen mee kunt, veranderd daar helemaal niets aan.
Bovendien moet je eens kijken waar JEE en PHP in de praktijk ingezet worden. Ik heb nog niet zo veel complexe bedrijfskritische systemen gezien in PHP en dat is juist waar JEE gebruikt wordt. JEE wordt gebruikt in de financiele wereld en de overheid en PHP niet. (of althans minder)

Dit is ook exact de reden dat je online niets van JEE ziet; de toepassingen van JEE zijn voornamelijk backends die niet algemeen toegankelijk zijn.
PHP wordt niet gebruikt voor applicaties en daar is het ook niet voor bedoeld. Ik moet wel bekennen dat ik een php script gebruik voor de website die als een soort batch functie wordt gebruikt. Voordeel daarvan is dat de hele website op één technologie draait.
Je weet jezelf in 2 zinnen enorm tegen te spreken, Atlantis95. Knap hoor.
3x1st4nz3, (tjonge, l33t hoor)
Ik ontwikkel onderandere telefonie applicaties in PHP. Dat draait binnen de CLI omgeving en performed uitstekend...

Niet blaten dat PHP alleen voor websitejes is.
Dat is ASP5. PHP is veel breder.
Als je direct ook even de PEAR libs meeneemt is de vergelijking een stuk eerlijker, want .net zou ook niet veel zijn zonder al die default libs.
Grappig dat PHP van oorsprong "Personal Home Page Tools" was ;)

Nu kan je er veel meer mee maar VROEGA was het wel degelijk specifiek voor websites.
Vind het zowieso een foute vergelijking.... .NET is maar ten dele vergelijkbaar met J2EE, transactie ondersteuning buiten het database deel is in .NET nog steeds niet echt ondersteund, daarvoor heb je nog steeds COM+ nodig.
Verder is lang niet alles wat met Java ontwikkeld wordt een J2EE applicatie, Microsoft telt hierin zijn simpele 'non enterprise' bouwers wel mee, terwijl voor de Java hoek alleen J2EE geteld wordt. Java is zoveel meer als alleen J2EE...

Maar goed, ze hebben weer een leuk marketing dingetje om van de daken te schreeuwen. Leuk weer voor de IT managers die door dit soort geschreeuw altijd de foute keuzes maken.

Ennehhh je hebt gelijk...kom eerst maar es in de buurt van LAMP, zowel qua aantal implementaties als qua performance....voorlopig blijft dat van de 3 hierboven genoemde platformen wel mijn favoriet...
Oh, dat gaat prima in .NET .... zolang je maar met single-threaded werkt. Datasources worden ook niet ondersteund bij .NET.
.net meer gebruikt dan J2EE?.. Ik hoop dat ze het niet meten in hoeveel computers de frameworks geinstalleerd hebben... De .NET 1.1SP1 is inmiddels immers een required update. Nogal wiedes dat dan veel windows bakken die geinstalleerd hebben...
Ik geloof niet dat jij hebt begrepen waar het stukje over gaat. Voor de duidelijkheid, alleen het installeren van een runtime is niet waar het hier om draait.
Ik weet niet waar jij deze 'duidelijkheid' vandaan haalt want de bron zegt op geen enkele manier hoe zij dit marktaandeel meten. Het is dus helemaal niet uit te sluiten dat ze idd de runtime installments hiervoor gebruikt hebben!
nicetas zei:
Dat mag misschien waar zijn, maar veel belangrijker is nog de concurrentie met Apache/PHP/MySql. Daar heeft MS nog een lange weg te gaan.
Apache/PHP/MySQL kan je niet vergelijken met .Net en J2EE. PHP is een scripttaal met voldoende beperkingen voor grote transacties.

Ik zeg dit uit eigen ervaring omdat toen ik een XML/SQL applicatie aan het ontwikkelen was en 8 MB aan XML probeerde in te laden PHP op z'n gat ging. Onder .Net was dat dus echt een eitje en ASP.Net deed het met de handen op z'n rug. PHP liet nix van zich horen 30 seconden lang en ging vervolgens op z'n gat. Na slim onze XML in stukjes gehakt te hebben en deze selectief te laden ging het pas 'acceptabel' maar zeker niet snel. Om over grote DB queries maar niet te spreken. PHP toonde veel moeite te hebben met grote MSSQL en Oracle transacties waarbij duizenden records in 1x verwerkt moesten worden.

PHP is leuk voor CMSjes e.d. maar voor de echte grote complexe databases met echt GROTE transacties heeft het mij te veel in de steek gelaten :S
Ik vraag me af hoe je dat gedaan hebt, want zoiets doe ik ook wel es en nooit grote problemen mee gehad.
Dat mag misschien waar zijn, maar veel belangrijker is nog de concurrentie met Apache/PHP/MySql. Daar heeft MS nog een lange weg te gaan.
Die vergelijking gaat nu eens helemaal niet op. Java en .NET worden gebruikt voor Enterprise-applicaties, grote dingen die de backend van bedrijfslogica vormen. Een normale applicatie van xAMP blijft kleine, dynamische websites. Die kunnen ook binnen een groot bedrijf te vinden zijn, begrijp me niet verkeerd, maar die is dan gekoppeld aan een groter stuk middleware, dat is één van de bovengenoemde talen geschreven is. Trouwens, een database als MySQL loopt al snel tegen zijn grenzen aan als je er bijvoorbeeld gegevens van enkele miljoenen klanten in moet stoppen.

Over de cijfers van Microsoft gesproken: volgens mij kan dat gerust wel kloppen. Volgens mij ligt de verdeling echter iets anders: grote bedrijven (multinationals, ...) gebruiken doorgaan J2EE voor hun systemen, waar kleinere bedrijven (KMO's) sneller voor Microsoft kiezen. Op kleine schaal komt dat iets goedkoper uit, Windows-systeembeheerders (of toch mensen die Microsoft certificaat zwaaien en denken dat ze het zijn) en .NET-developers zijn iets goedkoper. Samen met de interessante licentiekosten springen kleine bedrijven iets sneller op de .NET bandwagon.
Grote bedrijven maar ook veel gebruik van .NET hoor.
Het blijkt over het algemeen net iets goedkoper uit te vallen. Bovendien kun je bijvoorbeeld intranet spul lekker ontwikkelen in ASP.NET, bedrijfscritische client server applicaties in bijvoorbeeld C# en high performance applicaties in C++.
Daarmee biedt .NET juist voor heel grote bedrijven die dergelijke verschillende systemen hebben veel flexabiliteit.
Java is te vergelijken met C#
C# is eigenlijk te vergelijken met Java :) Java was eerder op de markt he ;)
inderdaad, c# is een kopie van Java
In de bedrijfswereld speelt het hoe langer hoe minder een rol, maar het overgrote deel van webapplicaties wordt ontwikkeld voor particulieren en kleine verenigingen en dergelijke. Als je daar de keuze moet maken tussen een hosting pakket van 50 euro per jaar, of een van 250 euro per jaar voor uw MS licenties, dan is de keuze rap gemaakt...
Er zijn dan ook fundamentele dingen mis gegaan. Sun kon zich met Java jaren lang niets aantrekken van de buitenwereld omdat er in hun segment geen echte concurenten zaten. .NET is de enige echte stevige concurent.

Maar wat ging er dan mis?
-Vooreerst had java in het begin last van een slecht geheugenmanagement, dit probleem is nu van de baan, maar het blijft een teer punt waar onder devs mee gelachen wordt.
-Sun kreeg het halen van licenties voor bij voorbeeld mp3 niet in handen waardoor de media APIs en dergelijke geen goed punt was.
-Sun kreeg het ook niet voor elkaar een goede eenduidige manier van nieuwe APIs leren ter beschikking te stellen. JavaDoc is een naslagwerk, geen manier van leren.
-Sun ging in de clinch met Microsoft omdat deze laatste zelf een implementatie van Java wilde maken, dit is zowat de grootste vrees van Sun ivm Java. Het resultaat: Een verouderde versie van Java in windows (en XP had initieel geen ondersteuning << niet heel zeker van).
-Sun maakt weer problemen ivm licenties van Java (niet GPL compatible) en sluit de deur naar de FOSS comunity. Dit heeft tot gevolg dat een grote hoeveelheid software, die op Java goed had kunnen draaien, in andere talen geïmplementeerd werd (en dus enkel voor *NiX). Hierdoor is er geen 'boost' van beschikbare programmas gekomen. <<< Sun is wel zwaar aan de licentie aan het sleutelen.

Wanneer Microsoft met een nieuw product op de markt komt, hebben ze de luxe om diet goed te kunnen promoten, de tentakels van msn en andere liggen ver verspreid. Geef hier nog bij dat Microsoft voor het Windows-platform een geweldige oplossing verzonnen heeft, en het wordt een mathematische zekerheid.

Toch mogen we niet vergeten dat er ook mensen zijn die *niet* achter microsoft staan, deze zullen .NET dan ook ten alle kosten vermijden (bv door MONO te gebruiken).
Ik weet niet hoe ze tellen. Bij ons op de werkvloer zijn even veel mircosoft mensen als javanen. Echter zijn er maar 'een paar' opdrachten voor microsoft, en bergen opdrachten voor java.

Ik denk dat het nog lang duurt voordat we java dood kunnen verklaren.
Ik weet niet hoe ze tellen. Bij ons op de werkvloer....
Ze tellen vast meer dam één bedrijf
Onzin, .NET is wel degelijk booming.
Op vacatures, in bedrijven zelfs op het web kom ik steeds meer ASPX pagina's tegen.
Dit bericht is wel degelijk waarheid, maar natuurlijk een beetje aangedikt.

.NET is juist zeer geschikt voor hele grote projecten.
En .NET code (en Java) zijn theoretisch weer sneller dan script-talen. Die gaan namelijk "on the fly". en met al die blokken code tussen de HTML is het ping-pong effect van de interpreter ook niet ideaal.

Toch heeft PHP wel degelijk meerwaarde.
Het is een stevige "allrounder" en heeft nog steeds een gigantische userbase. Ik kan je wel vertellen dat als ik "even snel iets moet maken" voor iemand (webpagina) ik nagenoeg altijd voor PHP zal kiezen.
Bovendien wordt het door gigantisch veel (betaalbare) providers ondersteund.

Ik werk met J2EE en dat werkt prima, maar voor een website of eenvoudige webapplicatie ga ik ook voor PHP.
dat ping-pong effect is makkelijk te voorkomen door templates te gebruiken. Daarbij blijf je in php tot het einde waar alles naar de pagina wordt geschreven.

En daardoor is ook mooi je code en design gescheiden.
Grappig blijft toch een aantal rare dingen horen.

LAMP kan je NIET vergelijken met .NET.
.NET is een framework, LAMP is een raar acronym voor veelgebruikte opensource oplossingen voor webservers.
Daarbij is PHP niet met .NET te vergelijken.
PHP is een script-taal, .NET een framework.
PHP is meer met het klassieke ASP te vergelijken (waarbij PHP glansrijk zal winnen m.b.t. zo'n beetje alles)

.NET en Java zijn wel degelijk per definitie langzamer dan unmanaged code C / C++ .NET heeft de MIL-code als "tussencode" en Java de "bytecode" die draaid op de bekende JVM.
Die performance zal in sommige gevallen veel minder merkbaar zijn dan in andere. Je kan dus niet zeggen "het is altijd x% langzamer. soms is het verschil te verwaarlozen, echter in sommige voorbeelden zeer duidelijk aanwezig. Ik zou mensen die beweren dat Java / .NET niet langzamer is dan unmanaged C graag eens vragen waarom alles games (en dan bedoel ik niet op je mobieltje) NIET in Java of .NET framework zijn ontwikkeld.
Ik heb nog geen moderne 3D game gezien die vroeg om JVM client, of om .NET client vroeg. Games zijn voorbeelden waarin een "virtuele tussen machine" duidelijk NIET gewenst is m.b.t. performance.
Ik zou mensen die beweren dat Java / .NET niet langzamer is dan unmanaged C graag eens vragen waarom alles games (en dan bedoel ik niet op je mobieltje) NIET in Java of .NET framework zijn ontwikkeld.
Ik heb nog geen moderne 3D game gezien die vroeg om JVM client, of om .NET client vroeg. Games zijn voorbeelden waarin een "virtuele tussen machine" duidelijk NIET gewenst is m.b.t. performance.
Volgens mij ligt dat niet alleen aan de performance van de taal zelf.
Ik heb laatst een demo gezien in C#, met marchingcubes en HDR etc, en die liep gewoon perfect soepel: http://www.pouet.net/prod.php?which=10855

Ik denk dat het voor een groot deel te maken heeft met het feit dat de .NET-interface van DirectX pas sinds kort bestaat, en eigenlijk nog niet officieel ondersteund wordt, er ontbreekt ook nog wat functionaliteit.
Voor Java is er nog helemaal geen standaard-API voor 3d-acceleratie, geluid, input devices etc, die je nodig zou hebben voor spelletjes.
En natuurlijk worden spelletjes vanouds in C++ met DirectX gemaakt, dus is er daarover veel kennis, ervaring en herbruikbare code in huis. Met .NET of Java zouden ze opnieuw moeten beginnen, en dat kost extra geld. Dat zouden ze alleen doen als er ook echt voordelen aan zitten, en die zijn er op het moment nog niet echt.

Ik denk dat je op zich een prima spel kunt maken met .NET... misschien dat je een aantal bottlenecks in C++ of asm moet optimaliseren, maar ik denk dat voor het grootste gedeelte de performance van .NET geen probleem zal vormen.
Toch is PHP de lachende derde.
Dat PHP zo'n beetje voor alles webbased in gezet kan worden blijkt uit de praktijk. Het ontwikkeld sneller cq zonder meer rompslomp dan in .NET en Java. Tegenwoordig willen ontwikkelaars wel eens dingen overarchitecteren en verliezen het doel uit het oog... Waardoor het ook nog eens slecht doorzichtbaar en onderhoudbaar is. Wat juist het doel zou moeten zijn van de architectuur.
Minder code en minder lagen wil niet zeggen dat het beter onderhoudbaar is. Ook zaken als transactiemanagement en volwaardige logging horen daarbij en dat heb ik in PHP nog niet gezien.

Doorzichtig is doorgaans niet het hoofddoel van architectuur, maar onderhoudbaarheid. Natuurlijk moet je (na wat moeite) begrijpen wat er gebeurt, maar het is veel belangrijker dat je wijzigingen gemakkelijk kunt doorvoeren, mits je weet hoe de applicatie in elkaar steekt. Het kunnen inschatten van de gevolgen van die wijzigingen vind ik persoonlijk in Java veel gemakkelijker dan in PHP.
Waarom? Omdat Java je de goede richting in stuurt met betrekking tot netjes werken en PHP slordig werken gemakkelijk maakt.
5 jaar terug 25% marktaandeel? Hmm... .NET 1.0 kwam in 2002 op de markt. Het lijkt me ERG sterk dat .NET 1.0 BETA zonder enige vorm van go-live license al door 25% van de developers gebruikt werd.

m.a.w.: marketing prietpraat om de aandeelhouders tevreden te stellen...
Op 16 januari 2002 verscheen versie 1.0 van .NET, dus ja, 5jr is wat moeilijk aan te tonen ;)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True