Java-uitvinder: "Microsoft's C# slaat de plank mis"

Om eens te kijken hoe een kenner tegen Microsoft's C#-programmeertaal aankijkt, heeft ZDNet een interview gehouden met James Gosling. Deze uitvinder van Java is uiteraard wel behoorlijk partijdig, maar aangezien C# een directe concurrent voor Java zal worden, heeft hij veel verstand van de situatie en de voor hem interessante nadelen van Microsoft's nieuwe taal. Als we de beste man mogen geloven, zijn dat er nogal een aantal.

De bij Sun werkende Gosling vertelt niet echt wakker te liggen van C#. Imitatie is de eerlijkste vorm van vleierij, en daar wil Sun Microsoft voor bedanken. Daarnaast weet de zeer directe en voor Microsoft onvriendelijke persoonlijkheid te concluderen dat C# een soort Java is, waaruit betrouwbaarheid, productiviteit en veiligheid geschrapt zijn. Men heeft namelijk de basis van Java overgenomen, maar door de toevoeging van compatibiliteit voor C en C++ is het geheel verschrikkelijk onbetrouwbaar geworden. Men heeft dus onnodig dingen toegevoegd die juist alleen maar een slechter product opleveren, aldus de lacherige concurrent.

Lees het hele interview hier.

Reacties (94)

[stylee]

Ik heb het artikel nog niet doorgelezen, maar ikzelf ben al sinds ongeveer 1995 bekend met java. Ik moet zeggen dat het mij destijds erg zwaar tegenviel (applets) maar hedendaags is Java dermate ver dat het een zeer gevanceerde taal is geworden op zo ongeveer elke gebied (servers/embedded/enterprise).

Ik ben op dit moment bezig met het leren van C# (microsoft's C# manual roeleert toch wel zo een beetje ) en ik moet eerlijk toegeven dat het me een stuk beter bevalt dan Java. Juist door de toevoegingen die C# als C/C++ doet lijken maakt de taal juist zo interessant en bruikbaar. Deze zullen ook ervoor zorgen dat een flink aantal C++ programmeurs toch de overstap zullen maken naar C# (references en pointers versus ref en out parameters bijvoorbeeld).

Daarnaast staat het gehele .net (lees: CLR/IL) principe me erg aan. Javahova's zullen zeggen maar dat had Java allang al in de vorm van een VM. Maar helaas is dat niet compleet waar. Pak er bijvoorbeeld maar eens "Oreilly - .net framework essentials" bij en zie wat voor dingen er zoal mogelijk zijn. Als je zin hebt kan je zelfs direct Assembler gaan programmeren in de CLR

Ook de 'evolutie' van technologien zoals ADO.NET vindt ik bijzonder interssant. Jammer genoeg is er denk ik zeer weinig kans dat deze ook daadwerkelijk op een goede dag platformonafhankelijk zullen zijn.

Niet echt het mooie van C# maar meer het mooie van .net is taalonafhankelijkheid. Tijdens verscheidene projecten heb ik hier weleens van gedroomd > , nu alleen nog kijken voor hoever het bruikbaar is in de praktijk (maar ik verwacht er veel van). Hoe vaak heb je niet je database-code in C++ willen schrijven en je GUI in VB? Nu is dat mogelijk.

Erg jammer is dat de .net runtime behoorlijk groot (naja voor niet-kabelaars dan), rond de 21 MB geloof ik. En daardoor dus niet echt interesant voor de gemiddelde freeware-programmeur die zijn brouwsels via internet aanbiedt.

Ook Microsofts Visual Studio.net is echt een aanrader.

edit: daarnaast is IMO het argument waar veel mensen mee komen ".net is gebonden aan windows en daardoor gewoon niet bruikbaar", waar, doch niet echt een argument waar rekening mee gehouden zal worden aangezien zo ongeveer 95% van .net's 'target audience' zoiezo al windows draait.

[mbravenboer]

ik moet eerlijk toegeven dat het me een stuk beter bevalt dan Java. Juist door detoevoegingen die C# als C/C++ doet lijken maakt de taal juist zo interessant en bruikbaar. Deze zullen ook ervoor zorgen dat een flink aantal C++ programmeurs toch de overstap zullen maken naar C# (references en pointers versus ref en out parameters bijvoorbeeld).

Dat zijn inderdaad keuzes die je kunt maken. Het doel van Java is het ontwikkelen van een netwerk-taal geweest. Bij Java staat hierom voorop: security, security en security. Ref parameters zorgen ervoor dat je eventueel lokale variabelen kunt aanpassen. Dat is een gevaarlijke business. Voor out-parameters geldt hetzelfde. In Java-Bytecode gaan alle parameters by-value en zijn er geen instructies om niet lokale variabelen te benaderen. Dat zijn wellicht tekortkomingen voor bepaalde applicatie, maar geen tekortkomingen van de taal Java of Java-Bytecode: het zijn bewuste keuzes die gemaakt zijn.

Ook de 'evolutie' van technologien zoals ADO.NET vindt ik bijzonder interssant. Jammer genoeg is er denk ik zeer weinig kans dat deze ook daadwerkelijk op een goede dag platformonafhankelijk zullen zijn.

Mee eens.

Niet echt het mooie van C# maar meer het mooie van .net is taalonafhankelijkheid.

De instructie-set van MSIL is inderdaad een stuk uitgebreider dan Java-Bytecode. Dit zijn voor beide platformen echter ook keuzes die gemaakt zijn. Je kunt trouwens ook uitstekend andere talen naar Java-Bytecode compileren (neem Python bijvoorbeeld), maar omdat de instructie-set ook volledig gericht is op veiligheid, vallen hier ook veel talen af. Voorlopig is het helaas ook weer een feit dat vrijwel alle talen die op .NET draaien ".NET-ified" moeten worden om ook prettig binnen het frame-work te passen. Dit geldt voor de eenvoudige imperatieve-talen als C++, VB .NET en J#, maar ook voor experimentele talen zoals functionele talen (Haskell).

Erg jammer is dat de .net runtime behoorlijk groot (naja voor niet-kabelaars dan), rond de 21 MB geloof ik. En daardoor dus niet echt interesant voor de gemiddelde freeware-programmeur die zijn brouwsels via internet aanbiedt.

Ach, Microsoft beschikt over het meest krachtige distributie-kanaal: Microsoft Windows. Het is simpelweg een feit dat .NET het ontwikkelplatform voor MS Windows gaat worden.

daarnaast is IMO het argument waar veel mensen mee komen ".net is gebonden aan windows en daardoor gewoon niet bruikbaar", waar, doch niet echt een argument waar rekening mee gehouden zal worden aangezien zo ongeveer 95% van .net's 'target audience' zoiezo al windows draait.

Daar kom ik inderdaad ook altijd mee en dus moet ik het ook nu weer even vertellen . C# en MSIL zijn uiteraard keurig gestandaardiseerd en platform-onafhankelijk. Veel libraries zijn echter niet gestandaardiseerd. Helaas draait het bij een platform toch echt om de libraries. Je geeft dit zelf al aan omdat je Java in de begintijd niet interessant vond en nu wel. De taal Java is in die tijd niet echt veranderd. De bibliotheken en de JVM echter wel. Veel bibliotheken van .NET zijn zeer gericht op/afgeleid uit het MS Windows Platform. Ze zijn zeer lastig, zo niet onmogelijk te implementeren op andere platformen. Microsoft wil echter ook graag .NET plaatsen als server-side platform (de enige markt die ze nog niet in hun macht hebben). Daarvoor hebben ze naar mijn mening toch echt implementaties op andere platformen nodig.

[Verwijderd]

Huh, die redenatie van security en ref en out parameters snap ik niet helemaal. Dat je door die constructies lokale parameters mogelijk zou kunnen aanpassen is toch niet per definitie slecht. Misschien wil je dat nou juist wel. Het zou pas gevaarlijk zijn als dit buiten jou weten zou kunnen gebeuren, maar in een taal als C++ en C# moet je gelukkig altijd van de voren in de methode header keurig aangeven of een parameters als ref,out of by value moet worden gebruikt.
Als je op jouw manier redeneert zou je het trouwens ook moeten verbieden om (pointers naar) objecten als parameter te gebruiken, immers, de methode zou het object wel eens kunnen veranderen!
In java moet je nu dus gaan prutsen met nieuwe objecten als return value als je toevallig meer dan 1 resultaat op wilt leveren. Wat mij betreft geen echt handige keuze van de java designers...

[mbravenboer]

Huh, die redenatie van security en ref en out parameters snap ik niet helemaal. Dat je door die constructies lokale parameters mogelijk zou kunnen aanpassen is toch niet per definitie slecht.

Dat denk ik wel: via ref en out parameters krijg je de geheugen-locaties door van lokale variabelen van de aanroepende methoden. Hiervoor is het sowieso al noodzakelijk dat een methode toegang heeft tot het gegeugen van de aanroepende methode. Dat kan gevolgen hebben voor de veiligheid: methoden kunnen onverwachte bijeffecten hebben of gegevens vergaren die ze niet zouden mogen hebben. In de instructie-set van Java bytecode is het onmogelijk om bij niet lokale variabelen te komen.

Misschien wil je dat nou juist wel. Het zou pas gevaarlijk zijn als dit buiten jou weten zou kunnen gebeuren.

Je weet toch niet wat een implementatie gaat doen met een waarde die je by-reference moet doorgeven? Je geeft een geheugen-locatie die verwijst naar een plek in het stack-frame van de aanroepende methode. Als de aangeroepen methode ook daadwerkelijk iets met die locatie kan doen (en dat is uiteraard nodig) kunnen er problemen onstaan. In C# zijn deze er default uiteraard niet, maar in unsafe code zou je een heleboel kunnen bereiken.

Als je op jouw manier redeneert zou je het trouwens ook moeten verbieden om (pointers naar) objecten als parameter te gebruiken, immers, de methode zou het object wel eens kunnen veranderen!

Inderdaad, dat is mogelijk, maar dat is ook de realiteit van object-orientatie. Wat echter niet mogelijk is: een lokale variabelen in een aanroepende methode naar een ander object laten verwijzen. Je kunt via de interface van een object controleren wat wel en niet mogelijk mag zijn.

[Verwijderd]

In de instructie-set van Java bytecode is het onmogelijk om bij niet lokale variabelen te komen.

Statics daargelaten dan

Je weet toch niet wat een implementatie gaat doen met een waarde die je by-reference moet doorgeven? Je geeft een geheugen-locatie die verwijst naar een plek in het stack-frame van de aanroepende methode. Als de aangeroepen methode ook daadwerkelijk iets met die locatie kan doen (en dat is uiteraard nodig) kunnen er problemen onstaan.

Aangezien de CLR type-safe is zie ik er niet al te veel problemen mee, dat alleen een waarde veranderd word. Je vertrouwd methoden ook objecten toe, dus waarom niet een verwijzing naar geheugen. Door type-safety zal hij nooit andere waardes dan geldig zijn kunnen aanpassen.

In C# zijn deze er default uiteraard niet, maar in unsafe code zou je een heleboel kunnen bereiken.

Volledig mee eens, maar dat kun je netjes uitzetten via een policy. Dit kan op user, machine of enterprise niveau doen. Zo kan code die van internet af komt standaard nooit unmanaged code aanroepen.
Maar dit geeft ook de kracht dat je bestaande applicaties kan migreren en niet al je code hoeft om te gooien als je op .NET wilt overstappen, Denk aan gewoon `oude' DLL's importeren, COM interop etc.

[mbravenboer]

De pointer naar een object wordt in Java by-value meegegeven. Als je het echt technisch bekijkt worden hierdoor alle parameters in Java by-value doorgegeven.

Het zal inderdaad ook zeker wel een design-keuze geweest zijn, maar het heeft dus met een logische implementatie ook gevolgen voor de veiligheid van een taal. Nu is het in Java niet mogelijk om uberhaupt het gegeugen direct te gebruiken, dus is dat inderdaad niet echt een punt bij Java.

Bij C# is dat echter wel een punt als je unsafe code gebruikt.

[mbravenboer]

Statics daargelaten dan

Ik bedoelde inderdaad lokale variabelen van een andere methode .

Aangezien de CLR type-safe is zie ik er niet al te veel problemen mee, dat alleen een waarde veranderd word.

Stel bijvoorbeeld dat jij lokaal in een aantal bytes een password opslaat en een methode tussendoor aanroept: de aanroepende methode kan deze uitlezen met behulp v an unsafe code... In Java is dat absoluut onmogelijk, maar uiteraard wel lastiger te realiseren via JNI.

Je vertrouwd methoden ook objecten toe, dus waarom niet een verwijzing naar geheugen.

Bij objecten maak je daarbij een bewuste keuze: je geeft aan via welke interface een object gebruikt kan worden. Als je een variabele meegeeft by-reference kan de aanroepende methode andere lokale variabelen gebruiken als hij kennis heeft van de implementatie en frame architectuur. Dat is dus absoluut geen bewuste keuze bij het meegeven van een reference en daarom zie ik dat ook als een nadeel...

[Verwijderd]

Stel bijvoorbeeld dat jij lokaal in een aantal bytes een password opslaat en een methode tussendoor aanroept: de aanroepende methode kan deze uitlezen met behulp van unsafe code...

Daarom moet je nadrukkelijk aangeven dat je een assembly vertrouwd unsafe code aan te roepen.

In Java is dat absoluut onmogelijk, maar uiteraard wel lastiger te realiseren via JNI.

Je zegt het al, via JNI kan je gewoon C aanroepen die je hele stack uitleest of vernaggeld. Het is dus ook mogelijk. Ik heb nog niet met JNI gewerkt, maar kan je in java ook aangeven dat een package/jar (incl alle packages/jar die door dat package geinclude worden) geen rechten hebben om JNI aan te roepen? in de CLR kan dit namelijk weer wel. Als dat zo is, vind ik de CLR toch veiliger.

[mbravenboer]

Daarom moet je nadrukkelijk aangeven dat je een assembly vertrouwd unsafe code aan te roepen.

Dat is ook uitstekend, maar ik ben bang dat er veel unsafe code gebruikt zal gaan worden omdat het zo laag-drempelig is. Ik vraag me dus af of dit toestemmings-systeem echt goed gaat werken...

maar kan je in java ook aangeven dat een package/jar (incl alle packages/jar die door dat package geinclude worden) geen rechten hebben om JNI aan te roepen?

Uiteraard kan dat. Hoe kan je anders ooit Java Applets of Java Web Start applicaties vertrouwen? De SecurityManager van Java bepaalt of native libraries gebruikt mogen worden door niet standaard Java libraries.

Note that the ability to load dynamic libraries is subject to approval by the current security manager. When working with native methods, you must load dynamic libraries. Some applets may not be able to use native methods because the browser or viewer they are running in restricts the ability to load dynamic libraries.

Zie ook de security en JNI onderdelen van Java Tutorial.

Het is dus duidelijk dat beide omgevingen dezelfde faciliteiten bieden qua veilighied. Ik heb alleen zo mijn twijfels bij laag-drempeligheid van unsafe code .

[Verwijderd]

Ik heb eventjes vlugtig naar de security gekeken en "JDK 1.2 Security Model:" lijkt redelijk op wat .NET bied. Alleen kon ik niet zo snel vinden hoe fijn die security policies te definieren zijn en hoe fijn de security te regelen valt. Bij .NET heb je eigenlijk alleen nog maar custom codegroups (equivalent met domains volgens mij). Full Access en sandbox zijn neem ik aan gewoon speciale domains. Bij .Net zijn er ook een aantal standaard codegroups als internet, localemachine, intranet en everything waar alle codegroups van `extenden' om het zo maar te noemen.
Daar zijn we het dan over eens

Over laagdrempeligheid vant idd te twisten. Het heet ook niet voor niets unsafe ipv JNI

[Verwijderd]

Hmm ik snap ook niks van dat argument dat by reference of out parameters iets met security van doen hebben.

reference is gewoon dat je de parameter aan kunt passen, out ook, alleen dan krijg je alleen een placeholder mee als beginwaarde, ipv een echte waarde.

reference werkt ook zo in java (alle objecten worden by reference meegegeven). out/reference constructies moet je gewoon met een object oplossen.

Volgens mij is dit gewoon een design keuze in de taal geweest (net zoals impliciet virtual maken van alles), meer om de taal simpel en licht te houden, dan om mega security te hebben.

Het verhaal over het stack frame, nu ja dat is dus maar net hoe je het implementeert, en dat is dus het verhaal van de vrije geheugentoegang, inderdaad ook voor security (maar vooral voor stabiliteit) erg belangrijk. Dat heeft echter in principe niks met by reference of out parameters te maken.

[Verwijderd]

daarnaast is IMO het argument waar veel mensen mee komen ".net is gebonden aan windows en daardoor gewoon niet bruikbaar", waar, doch niet echt een argument waar rekening mee gehouden zal worden aangezien zo ongeveer 95% van .net's 'target audience' zoiezo al windows draait.

Mono: an Open Source Common Language Infrastructure implementation.
Ximian has begun work on Mono, a project that aims to bring the Common Language Infrastructure platform to free systems.

When the GNU project was launched, they picked the best operating system that was available out there, and they began to clone it: Unix.

The .NET development platform is a very rich, powerful, and well designed platform that would help improve the free software development platform. Just like the GNU project began to clone Unix sixteen years ago, we will be cloning the .NET development platform because it is a great platform to build on.

http://www.go-mono.com/

[mbravenboer]

Mono is heel aardig, maar zoals ik in mijn andere post uitleg wordt het een hels karwei om de libraries compatible te maken met het .NET Framework voor MS Windows. Ze zullen zelfs veel bibliotheken voorlopig helemaal niet implementeren.

[mbravenboer]

Als je zin hebt kan je zelfs direct Assembler gaan programmeren in de CLR

Dat is inderdaad een leuke bezigheid . Er is trouwens ook een 'assembly' voor Java Bytecode: Jasmin.

[Verwijderd]

En we hebben we 1000 en 1 mogelijkheden gemaakt om virussen te implementeren waar absoluut geen beveiliging op toe te passen is. Er is maar 1 volk dommer dan de NOBRAINER computer consument en dat is de MS-programmeur. In Java is het gemakkelijk een shield te maken tegen "vijandige" of "wazige" java appletjes en dergelijke. Stel je voor dat je nu de combinatie hebt van C (waar geloof ik al 90% van alle virussen in geschreven is) en de combinatie van Assembly en alle "hidden features" van Microsoft in 1. De dag dat .NET in gebruik is is de dag dat Internet en E-commerce in 1 dag plat kan.


(this is done without sending ANY information to Microsoft. Honest, REALY !!)

[Verwijderd]

Ik denk dat je eens eventjes dit moet lezen:
msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/htm l/netframesecover.asp?frame=true
Je kan in de CLR code groepen aanmaken. Dit kan je doen op criteria als waar de code vandaan komt: Netwerk, pad, url. Waar de code vandaan komt: wie heeft hem gesigned. Hier kun je een logische structuur van maken met `of' en `en' constructies. Aan elke groep kan je rechten hangen als: Deze mag remoting gebruiken, deze mag unsafe code gebruiken. Deze mag files in deze directory wel lezen maar niet schrijven. Deze mag sockets openen. Deze mag alleen sockets openen naar waar hij vandaan komt of naar een harde URL. Etc. etc. etc.

[Verwijderd]

Beveiliging is nooit een argument geweest om voor Java te kiezen. Zelfs Sun is daar duidelijk in.

[Verwijderd]

Het feit dat 90% van alle virussen in C++ geschreven is bewijst volgens mij alleen maar dat C++ een super krachtige taal is!
Volgens mij vergeet je hier VB te noemen waar ook echt heel erg veel virussen vandaan komen.

Buiten dat is het natuurlijk onzin dat je de kwaliteit van een programmeertaal gaat linken aan het feit of je er virussen in kan schrijven of niet (als het niet kan lijkt het me juist een gelimiteerde taal!)

Just a thought......

[Verwijderd]

(voordat ik even begin laat ik even weten dat ik met Java zelf werk)

MS heeft al de .net architectuur in haar laatste OS zitten en dat is een macht/kracht die Java dus niet heeft. En zonder goede VM omgeving heb al gauw last van eigenaardigheden van het OS zelf.

C# mag technisch wel minder zijn dan Java maar we weten allemaal vast wel een voorbeeld te noemen van mindere software van MS die dankzij de marketing en andere strategieen het toch gemaakt heeft.

Wat wel nieuw is tov Sun is de .net structuur die erachter zit. Want een tussencompiler maken voor elke taal die er zou bestaan en daarmee een heleboel dingen meer standaard maken heeft Sun niet gedaan. (En MS zelf is geen computer voor Java voor .net aan het ontwikkelen maar een 3rd party)

En wat ik bij Java gewoon mis is een super uitgebreid aantal API's die C++ wel heeft en die van C# waarschijnlijk ook wel snel groter zal worden dan die van Java.

En waarschijnlijk heeft de beste man wel min of meer gelijk als hij zegt dat MS de plank mis slaat maar volgens mij mikt MS gewoon op een andere plank.

[CmdrKeen]

Niet dat ik MS blindelings vertrouw, maar de waarschuwing voor partijdigheid van de geïnterviewde lijkt mij zeer terecht...

Hoe moeten we C# trouwens uitspreken?

[Dr. Cheeks]

C# spreek je uit als C-sharp (see-sjarp dus )

[Maxonic]

Mijn Java Docent spreek het altijd uit als C- <"C-Blerk">.. Hij maakt er ook altijd een leuke kotsneiging bij

Ik denk trouwens niet dat C# het gaat maken. Er zijn duizenden Elvis imitators maar geen eentje kan aan de King tippen. Zo is het met Java precies hetzelfde..
Ik wou dat Microsoft dat eens inziet en Sun ging helpen ipv de grond in boren.
Ik zou veel blijer zijn als MS help de compatibiliteit van Java te verhogen door zelf een paar leuke Java-classes te maken met speciale Win snufjes maar nee hoor.. MS gedraagd zich weer als het jaloerse kindje dat er niet tegen kan dat een ander bedrijf iets revolutionairs ontwikkeld. Want zo zou ik Java toch willen noemen. En die platformonafhankelijkheid is al helemaal een doorn in het oog voor onze Bill en zijn vrienden...

Ik hoop van harte zat C# een one-day-fly wordt en dat Java uiteindelijk victory mag roepen...

[Verwijderd]

Ik zou veel blijer zijn als MS help de compatibiliteit van Java te verhogen door zelf een paar leuke Java-classes te maken

Precies dat heeft Microsoft een paar jaar geleden gedaan en daar hebben ze erg veel heibel over gehad, slepend proces met Sun. Dat gaat dus niet meer gebeuren zolang Sun de controle over Java heeft.

Microsoft was in die zaak niet ter goeder trouw en heeft terecht verloren, maar je moet niet vergeten dat Sun ook een commercieel bedrijf is dat zijn commercieel eigenbelang moet verdedigen.

Ik zou Java trouwens niet 'the King' noemen. Mischien werkt het aan de serverkant goed maar moet je eens deze statistiek over applet-gebruik zien:
www.securityspace.com/s_survey/data/man.200112/techpen.html

Java bestaat al sinds 1995 en Flash sinds 1997 maar wordt (iets) vaker gebruikt in webpagina's.

[mbravenboer]

Merk op dat het helemaal geen punt was geweest als Microsoft libraries had geimplementeerd die alleen op MS Windows draaiden. Het punt was de taal Java is aangepast en essentiele onderdelen niet werden ondersteund, maar goed, dat is een heeeeeeele oude discussie .

Voorlopig sta ik afwachtend, doch enthousiast tegenover de samenwerking tussen verschillende talen. Veel talen die onder .NET draaien (zoals bijvoorbeeld als exotische talen Haskell in de toekomst en nu al Mondriaan Script) verliezen toch een groot deel van hun karakter omdat het gebruiken van een gemeenschappelijke library of verschillende paradigma's nu eenmaal niet op rolletjes loopt. De technische basis van .NET: .NET CLR, MSIL etc is uitermate degelijk en zonder twijfel platform-onafhankelijk en taal-onafhankelijk. Je ziet echter dat de libraries voortdurend in de weg zitten.

Over je commentaar op de Java libraries: uiteraard zijn er problemen. Dat is logisch als je een uniform platform wilt aanbieden en dus alle specifieke platformen moet gaan vertalen in dat uniforme platform. Op dit punt is Java daar echter aardig in geslaagd na enkele flaters (zoals AWT).

Ik ben benieuwd hoe .NET dit aan gaat pakken. Voorlopig zie ik nog geen volwaardige .NET applicaties met GUI en database toegang op een ander OS dan MS Windows draaien. Als ze dat voor elkaar krijgen met de WinForms vind ik dat zeer respectabel. Voorlopig zit het er echter niet in dat dat gaat gebeuren: de WinForms en ADO .NET zullen voorlopig geeneens geimplementeerd worden door het Mono project.

Als je ziet hoeveel er in het Mono project opnieuw geschreven wordt, vraag ik me sowieso af of dit niet grote moeilijkheden op gaat leveren: dat kan eenvoudigweg vrijwel onmogelijk volledig compatible zijn (helaas).

[Verwijderd]

Argh. Telkens iemand "Java" zegt denken mensen maar aan 2 dingen:

- JavaScript (onverwante, slecht gëïmplementeerde script-taal)
- Java Applets voor browsers (irritante, achterlijke water effectjes om oninteressante websites toch 5 seconden in het oog te laten springen).

Als je door het tweede Java met Flash vergelijkt, zijn dat appelen en peren. Flash is gemaakt om vector-gebaseerde animaties te maken met een beperke programmeer/interactiviteitsmogelijkheid. Meer niet.

Java is een OO programmeertaal, maar ook véél meer: Java compilet naar platform-onafhankelijke code die op een 'Java Virtual Machine' moet gedraaid worden. Zolang er voor een bepaalde CPU-architectuur een Java VM bestaat, kan je Java draaien.

In ieder geval, het gaat hier *niet* om de populariteit van Java Applets of zelfs Java, maar om het feit dat C# gewoon een Java-cloon is met C++ derin waardoor het een slechte mix wordt.

Voor platform-specifieke applicaties geschreven in een robuuste programmeertaal is er C++.
Voor platform-onafhankelijk applicaties is er Java.
Tegenwoordig is er ook een grote opkomst van script talen zoals Perl (ook krachtig) of PHP (note: hoewel PHP bedoeld was als HTML pre-processor, kan je er nu volwaardig mee programmeren).

Ik zie eigelijk nergens plaats voor C#. Microsoft heeft ermee het gat in de markt willen vullen dat niet bestaat. Wie wilt er nu een taal die lijkt op Java, stukken C++ bevat en aanvoelt als Visual Basic? (*)

(*) Microsoft heeft in C# enkele VB'isms gestoken (zoals ongewoon gedrag bij een switch-statement enzo). Zogezegd omdat C++/Java in die gevallen toch niet zo intuïtief en logisch was.

[JeroenB]

Het is precies deze instelling die helaas een groot deel van de IT-wereld heeft. Bedrijfspolitiek, marketing en concurrentie zijn allemaal de drijfveer voor de gebruikte en te gebruiken technologie.

Dat is natuurlijk onzin. Als Microsoft een beter stuk gereedschap (want dat is software tenslotte) maakt dan Sun dan krijgen ze mijn volledige steun en zal ik het gebruiken om mijn werk te doen. Om geen enkele andere reden.

[Verwijderd]

Ik denk dat als Sun van java een open standaard hadden gemaakt dit helemaal geen probleem zou zijn geweest.
Nu MOEST Sun zonodig MS aanklagen wegens het uitbreiden.

Ik vind het feit dat je meerdere talen ondersteund, zelfs exotische die niet direct op een imperatieve taal mappen als Haskell en Prolog ondersteund redelijk revolutionair hoor. (Niet dat de een hoop compilers dit intern niet deden, maar door het nu netjes te scheiden in de distributie). .NET is ook platform onafhankelijk, het draait op 32bits machines, 64 bit, StrongARM. Straks waarschijnlijk ook op unices (zie Mono) etc. En dat gezeur over api's. Ik heb al een aantal mensen horen klagen over java compatibiliteit. Exceptions in de netwerk librarie die in de Sun VM wel op soliris worden gegeven maar niet in de Sum VM van windows, daar gaat je platform onfahankelijkheid.

C# heeft naar mijn mening wel een toekomst, maar daar hang .NET niet vanaf. De meeste programma's voor .NET zullen waarschijnlijk, zeker in het begin, nog in VB.NET worden geschreven gezien de grootste codebase van bedrijven die snel zullen overstappen naar .NET nu al in VB is.

[Aaargh!]

Ik denk dat als Sun van java een open standaard hadden gemaakt dit helemaal geen probleem zou zijn geweest.
Nu MOEST Sun zonodig MS aanklagen wegens het uitbreiden.

Het probleem was niet het uitbreiden maar de manier waarop, microsoft deed dit door windows-specifieke aanpassingen in de taal mee te proggen. hier was Sun het uiteraard niet mee eens, er is namelijk een correct mechanisme om dit soort dingen te doen zonder de hele taal te verkrachten: JNI (Java Native Interface)

[Atmosphere]

Precies dat heeft Microsoft een paar jaar geleden gedaan en daar hebben ze erg veel heibel over gehad, slepend proces met Sun. Dat gaat dus niet meer gebeuren zolang Sun de controle over Java heeft.

not really, MS had namelijk een eigen VM gemaakt die helemaal niet meer compatbile was met die van SUN.. dwz dat als jij de SUN java-VM had geinstalleerd je geen specifieke java-code voor de MS-VM kon draaien, en anders om.. Dit maakt JAVA eigenlijk platform afhankelijk. En SUN zal gek zijn als ze daar niets tegen doen.

[Edit sorry post hierboven the same thing.. hehe]

[Verwijderd]

# = 'hash'

C# = dus 'cash'

[Verwijderd]

Het is alleen "dash" voor #. ik zei eerst ook de hele tijd c dash, maar het is dus c sharp, als in de muziek.

Ik blijf het wel een domme naam vinden, c was al een domme naam voor een taal, c++ was een dom grapje om aan te geven dat het 1 versie hoger was, en dit eigenlijk een nog dommer grapje om aan te geven dat het 2 versies hoger is.

[deadinspace]

Het is alleen "dash" voor #.

'#' heet wel degelijk 'hash'.
'dash' is '-'.

[Bananeman]

Het hekje in C# is afgeleid van C++. Als je de twee plusjes van C++ pakt en dit aantal verdubbelt, heb je er dus 4. Zet je er dan twee naast elkaar, twee onder elkaar, dan krijg je:

++
++

en da's een hekje. C# is dus C++ ++.

[Verwijderd]

Eigelijk dus C-kwadraat

[Verwijderd]

Niet helemaal.

Misschien handig als je iets van programmeren in C weet. Als je ++ achter een variabele zet, wordt de inhoud van de variabele met 1 verhoogd.
Stel dat $test gelijk is aan 4. Als ik '$test++;' in mijn programma zet, krijgt $test de waarde 5.

Eigenlijk is het dus C +2, niet in het kwadraat.
[/mierenneuk-mode]

[Verwijderd]

zo, als we gaan mierenneuken kan ik er ook nog wel een:

Misschien handig als je iets van programmeren in C weet.
..
Stel dat $test gelijk is aan 4
...
Eigenlijk is het dus C +2

$test ? dacht dat je 't over C++ had ?

C +2 ? eerder C += 2 dan eh.. aangezien test++ ook direct toewijst

als jij kan zieken, kan ik 't ook

[wacko]

c-hekje

[heraut]

Je spreekt C# uit als <"See-Sharp">, heb ik tijdens een presentatie van MS eens gehoord...

[Aetje]

See Sharp, dat wazige taaltje... Vreemde (maar wel leuke) naam

[OverSoft]

ik had gehoord dat je het uitsprak als C - tone. (als in see tone)

[DeuTeRiuM]

niet als sie-sharp?
dus niet de engelse C zeg maar? of wel
Euh.. als je begrijpt wat ik bedoel.

[SG]

nee 'n US C uit redmond

[PalmPal]

C# kan je uitspreken als C sharp, dit is dus een hoge C. In de muziek heb je ook nog een Cb (C mol).

[Raafz0r]

oftewel, Cis en Ces dus (wat jij "hoge C" en "C mol" noemt.

[Verwijderd]

C# spreek je uit zoals het er staat in het engels

# =sharp (uhm juist zoals in de muziek... ok dubbelpost)

dus c sharp

[sonix666]

Imitatie is de eerlijkste vorm van vleierij, en daar wil Sun Microsoft voor bedanken.

Oh, en Java is zeker geen slap aftreksel van C++. Nogal slap argument van die man.

Daarnaast weet de zeer directe en voor Microsoft onvriendelijke persoonlijkheid te concluderen dat C# een soort Java is, waaruit betrouwbaarheid, productiviteit en veiligheid geschrapt zijn. Men heeft namelijk de basis van Java overgenomen, maar door de toevoeging van compatibiliteit voor C en C++ is het geheel verschrikkelijk onbetrouwbaar geworden.

Dit is je reinste berg van flauwekul die hier uitgesproken wordt. Een van de belangrijkste tekortkomingen van Java is simpelweg dat pointers missen. Sommige algoritmes kunnen nou eenmaal wel een 10x speedup krijgen door het direct kunnen gebruiken van pointers. Java zal nooit interessant worden voor applicaties die die snelheid nodig hebben.

C# ondersteund default geen pointers en is dus net zo veilig als Java. Echter als men voor een bepaalde functie pointers wil gebruiken om een enorme snelheidswinst te behalen, dan kan men deze functie als unsafe betitelen. Dan zijn pointers beschikbaar. Da's even een heel wat ander verhaal dan deze persoon staat op te hangen.

[Verwijderd]

Oh, en Java is zeker geen slap aftreksel van C++. Nogal slap argument van die man.

Inderdaad, java is GEEN slap aftreksel van C++. Java heeft veel technieken en syntax-elementen 'geleend' van allerlei talen, waaronder C++, maar is daardoor geen 'slap aftreksel' maar juist een betere taal geworden. Een soort 'best-of'.

Nu hebben alle talen wel hun voor- en nadelen en dus ook Java, en er is altijd wel iets te vinden waar de ene taal beter geschikt voor is dan de andere. Java heeft zich echter zeer sterk gefocused op veiligheid en platform-onafhankelijkheid. Dus als Microsoft dan een taal 'bedenkt' die wel heel veel op Java lijkt maar waarvan de veiligheid 'optioneel' wordt en de praktische platform-onafhankelijkheid op zijn minst twijfelachtig te noemen is, zijn de opmerkingen van James Gosling niet zo vreemd en m.i. dan ook volledig correct, ongeacht het feit dat hij gezien zijn achtergrond niet geheel objectief zal zijn.

Een van de belangrijkste tekortkomingen van Java is simpelweg dat pointers missen. Sommige algoritmes kunnen nou eenmaal wel een 10x speedup krijgen door het direct kunnen gebruiken van pointers. Java zal nooit interessant worden voor applicaties die die snelheid nodig hebben.

De relatie tussen pointers en snelheid zie ik niet helemaal, maar goed... de manier waarop een ontwikkelaar een bepaald algoritme codeert is m.i. bijna altijd van doorslaggevende factor voor de performance.
Java heeft in principe inderdaad geen pointers maar alleen object-referenties. Die intern natuurlijk gewoon als pointers geimplementeerd zijn, maar het verschil is dat ze niet door de code gemanipuleerd kunnen worden, en dat zowel de initieele class-compiler als de runtime hardware abstraction layer (de java VM dus) controleert of de operaties die m.b.v. de object-referentie worden uitgevoerd, wel geldig zijn. Veiligheid dus, en koste van slechts een klein beetje run-time performance.

Want vergis je niet, met de nieuwste JIT-compilers doet de performance van Java niet meer onder voor die van C++ of andere talen. Niet alleen wordt er door de JIT on-the-fly assembly code gegenereerd die razendsnel is en logischerwijs niet onderdoet voor code die bv C++-compilers hadden kunnen maken (met enkel de eenmalige runtime overhead van de java JIT-compiler), doordat de JIT-compiler run-time kan optimaliseren wordt er tegenwoordig zelfs code gegenereerd die vaak optimaler is dan compile-time machinecode ooit had kunnen zijn! Java kan dus sneller zijn dan C++ code, en ik heb dat zelf ook al diverse malen in de praktijk meegemaakt (zowel in real-world apps als in 'wedstrijdjes').
Plus daarbij nog eens de enorme verbeteringen die de JIT-compilers de laatste jaren hebben doorgemaakt, waarbij diverse algoritmes bepalen wanneer en zelfs of het nut heeft een stuk java byte-code daadwerkelijk runtime naar machine-code te compilen, waardoor naast de optimale gegenereerde machinecode ook nog eens het JIT-compile proces zelf enorm is verbeterd en veel minder vertraging oplevert dan in de begindagen van Java.

C# ondersteund default geen pointers en is dus net zo veilig als Java. Echter als men voor een bepaalde functie pointers wil gebruiken om een enorme snelheidswinst te behalen, dan kan men deze functie als unsafe betitelen. Dan zijn pointers beschikbaar. Da's even een heel wat ander verhaal dan deze persoon staat op te hangen.

Een keten is zo zwak als de zwakste schakel, en de introduktie van een zeer zwakke schakel maakt de taal/technologie er dus niet betrouwbaarder op. Ja, gebruik van unsafe modules is in principe een keus die de ontwikkelaar niet hoeft te maken, maar het grote probleem is dat er in zeer veel gevallen vanwege al bestaande unsafe modules, talen of OS toch unsafe code gebruikt zal gaan worden. En aangezien Microsoft er nu eenmaal voor gekozen heeft dat compatibiliteit met bestaande talen en modules nu eenmaal belangrijker is dan veiligheid, komt dat er in de praktijk dus neer dat de ontwikkelde .NET applicaties niet veilig zullen zijn.

Net zoals veel java-apps, zolang ze niet continu worden getest op meerdere platformen of browsers, na verloop van tijd toch platform- of browser-afhankelijk zijn geworden, zo zal ook .NET code als vanzelf onveilig zijn.

En ook al zijn alle .NET ontwikkelaars in een team goed op de hoogte van veiligheids-issues (wat in de meeste gevallen m.i. niet het geval zal zijn; er zijn nu eenmaal veel onervaren ontwikkelaars), gebruik van verschillende modules en talen door elkaar bevordert de security nu eenmaal niet echt, en bovendien, een foutje is snel gemaakt. .NET applicaties zullen dus van nature al veel onveiliger zijn, en ondanks de maatregelen die een ontwikkelteam mogelijkerwijs neemt altijd verdacht blijven vanwege de mogelijkheid van unsafety, zowel in de door het team ontwikkelde als in de bestaande/externe modules.

[mbravenboer]

Oh, en Java is zeker geen slap aftreksel van C++. Nogal slap argument van die man.

Java is net zoals Delphi, C, C++, VB, Pascal enz een imperatieve taal dus het is nogal logisch dat er grote overeenkomsten zijn. Al deze talen vallen in hetzelfde paradigma en in dit geval zelfs nog in specifiekere groeperingen. Een aantal features in C# doen echter wel verdacht veel denken aan features in Java. Sommige zijn net iets beter uitgevoerd, andere net iets anders, andere naar mijn smaak een stuk minder.

Dit is je reinste berg van flauwekul die hier uitgesproken wordt. Een van de belangrijkste tekortkomingen van Java is simpelweg dat pointers missen.

Je verwart tekortkomingen met keuzes: Java kent geen expliciete pointers omdat dat het doel van Java zou beschadigen.

Java zal nooit interessant worden voor applicaties die die snelheid nodig hebben.

Dat is weer ietwat overdreven er zijn zeker applicaties die je beter niet in Java kunt ontwikkelen, maar dat zijn over het algemeen systemen met extreme eisen die zeer dicht bij de hardware liggen.

C# ondersteund default geen pointers en is dus net zo veilig als Java.

Het gebruik van expliciete pointers is in C# alleen een stuk gemakkelijker dan in Java. Voor Java moet je hiervoor naar JNI grijpen. Voor C# neem je gewoon even een stukje unsafe code.

Da's even een heel wat ander verhaal dan deze persoon staat op te hangen.

Nee: dat is een verschil in interesses, doelstellingen en prioriteiten .

[sonix666]

Nee: dat is een verschil in interesses, doelstellingen en prioriteiten

Nee, dat noemen ze een gedeelte van de werkelijkheid weglaten en daarmee de werkelijkheid uit zijn verband te trekken. C# biedt gewoon de mogelijkheid wat C++ voor heeft op andere talen, namelijk het gebruik van pointer waar dat voor performance voordelig is. Hierdoor is C# voor meer gebieden interessant.

[mbravenboer]

Abstractie van irrelevante details is voor andere gebieden ook interessant. Voor veel normale applicaties zijn pointers irrelevante details.

Waarom zijn er anders zelfs declaratieve talen? Deze gaan nog veel verder en zijn toch interessant voor veel toepassingen.

Low-level werk is heel leuk en je hebt natuurlijk uitmuntende controle op de performance, maar dat wil niet zeggen dat low-level werk interessant is voor alle applicaties.

[curry684]

Het gebruik van expliciete pointers is in C# alleen een stuk gemakkelijker dan in Java. Voor Java moet je hiervoor naar JNI grijpen. Voor C# neem je gewoon even een stukje unsafe code.

'Unsafe' is echt belachelijk spul in C#... omdat het nutteloos is. Unsafe betekent dat je dat betreffende stuk code gewoon C++ style mag kloppen met pointers en pointer arithmetic, en dus even voorbijgaan aan alle taalveiligheid van C#. Tot nog toe dus een voordeel: je declareert je onveilige operaties expliciet op die manier en dus makkelijk debuggen mocht er daar iets fout gaan.

Nu het nadeel van unsafe: de runtimes bieden de gebruiker de mogelijkheid om unsafe te weigeren. Deze optie gaat in de .NET Windows edities default AAN staan. Oftewel het gebruik van unsafe zorgt er dan voor dat niemand je applicatie gebruikt, omdat niemand constant 'OK' gaat klikken bij de opmerking 'The program you are trying to run might fuck up your computer beyond repair and introduce 20 viruses and trojans. Do you want to continue?'

Tot zover het nut van unsafe...

* 786562 curry

[Verwijderd]

'Unsafe' is echt belachelijk spul in C#... omdat het nutteloos is. Unsafe betekent dat je dat betreffende stuk code gewoon C++ style mag kloppen met pointers en pointer arithmetic, en dus even voorbijgaan aan alle taalveiligheid van C#.

Ik vermoed dat je unsafe verkeerd leest. In C# kun je helemaal niet C++ style kloppen. Het houd alleen in dat als een assembly (dll/exe/groepjes daarvan) unsafe code mag gebruiken, hij/zij hij andere assemblies die usafe zijn, doordat ze bijv. in unmanage c++ zijn geschreven, mag importeren en gebruiken.
Het aanroepen van unsafe code is een recht dat een assembly gegeven kan worden (Zie eerdere post voor uitgebreidere uitleg).

De java dudes noemen java de jvm + bytecode + syntax een ding. Bij .NET zijn deze bewust strict gescheiden. jvm +-= CLR bytecode +-= MSIL syntax +-= C# / J# / VB.NET / managed C++.

edit: [ quote ] verkeerd geschreven

[Verwijderd]

Klopt niet helemaal. Java kent juist alleen maar pointers (ookal staat er geen * bij), wat je echter niet kan doen is pointer arithmic (rekenen met pointers).

[sonix666]

Ja, ik weet ook wel dat iedere object referentie een pointer in werkelijkheid is. Maar wat ik in Java niet kan is om een pointer naar een pointer naar een pointer naar een integer structuur kan maken bijvoorbeeld daarom.

[Verwijderd]

Over de vraag waarom Microsoft C# heeft ontwikkeld:
a) Java is geen standaard die je zomaar mag gebruiken (eigendom Sun) en daarom kreeg MS ruzie met Sun
b) Java heeft voor elk systeem een Virtual Machine nodig, waardoor de apps relatief traag draaien, met .NET is er eenmalig een "vertaler", waardoor de apps na 1 keer runnen gewoon veel sneller draaien, terwijl ze toch systeemonafhankelijk blijven.

.NET is WEL een standaard (bij een van de standaardiseringsorganisaties) en daardoor niet meer eigendom van MS, iedereen mag een implementatie voor .NET maken, vanuit verschillende talen. En de standaardiseringsorganisatie (ben even de naam kwijt) beslist over evt. veranderingen/uitbreidingen, niet MS.
Er is o.a. ook al een opensource implementatie gestart voor .NET (www.go-mono.com/)
Ditalles lijkt positief, maar de veiligheid is nog even afwachten.

Inderdaad zit de Java VM niet meer standaard bij windows (XP), de .NET runtime zal er denk ik wel standaard inkomen.

[Janoz]

a) Java is geen standaard die je zomaar mag gebruiken (eigendom Sun) en daarom kreeg MS ruzie met Sun

Kleine korrektie.. Het is niet gebruiken, maar aanpassen. MS had in hun vm namelijk wat win specifieke functies toegevoegd. Hierdoor kon een op win gecompileerd programma dat van die functies gebruik maakte niet op een andere dan de ms vm gedraaid worden. Hier werd Sun boos over.

.NET is WEL een standaard (bij een van de standaardiseringsorganisaties) en daardoor niet meer eigendom van MS, iedereen mag een implementatie voor .NET maken, vanuit verschillende talen. En de standaardiseringsorganisatie (ben even de naam kwijt) beslist over evt. veranderingen/uitbreidingen, niet MS.

Dat lijkt allemaal wel heel erg leuk, maar in de praktijk heb je er erg weinig aan. .net is namelijk compleet ontwikkeld op de win32 API. Om deze volledig op een ander platform te implemeteren is bijna onmogelijk. Mischien kunnen sommige simpele console apps wel ergens anders op draaien, maar echt heel veel verder zul je IMHO niet komen.

[Tijger]

Ik heb op XP nu de Sun Java VM draaien en ik kan me niet aan de indruk ontrekken dat de MS VM een stuk sneller was onder 2000.

[marsattacks]

Wat volgens mij nog een groot voordeel van C# / CLR voor Microsoft en anderen is, is dat men voortaan applicaties kan ontwikkelen die zowel op 32 bits windows en 64 bits windows draaien, zonder aanpassingen/hercompileren. Denk maar aan de Itanium/McKinley's en de Hammers die er aan zitten te komen.

Janoz: dus wat men bij www.go-mono.com doet bestaat niet?. Het is inderdaad een hoop werk om de CLR te porten maar zeker niet onmogelijk.

[cablepokerface]

Iemand die wat thuis is in de ontwikkelwereld weet eigenlijk best wat er gaat gebeuren ... MS zou MS niet zijn als het niet alles zou doen om C# erdoor te drukken. (En de standaard verklaring van de ISAM is daar maar een klein onderdeeltje van).

Ik programmeer al behoorlijk wat jaar in VB en C++ en ik moet zeggen dat C# een goed bekeken offensief is. C# is niet meer dan een taal met een erg platgeslagen model waardoor 'low-level' geprogrammeerd kan worden. (note: ALLE base-classes in de CLR zijn in C# geschreven). Hierdoor wordt C# ook wel een 'simpele' taal genoemd. (Hiermee wordt bedoelt: simpel in opbouw en structuur, NIET simpel om te leren).

Een groot voordeel van C# is dat het ontwerpen van de Applicatie GUI hetzelfde is als VB. De onderliggende syntax structuur komt echter voor een groot deel van C++ af. Ze hebben ook de mogelijkheid om 'unmanaged' code te schrijven nog deels in C# gelaten. (een kruising tussen VB (ALLEEN managed Code) en C++ (grotendeels unmanaged code))

Ik denk dat MS met C# een goede slag gaat slaan. Tuurlijk, we moeten vooral kritisch zijn. Echter, iedereen die dit leest is een tweaker en weet hoe MS omgaat met nieuw te lanceren producten. Dat bestormt de markt.

Voorspelling: Java verliest het van C# binnen nu en 3 jaar. Nee, dit verdient Java niet, maar realistisch nadenked; dit gaat wel gebeuren ...

[Verwijderd]

Dat

C# is dat het ontwerpen van de Applicatie GUI hetzelfde is als VB

.
Dit komt door het ontwerp. Elke taal in .NET of het nu VB, C#, J#, Cobol of Haskell is. Ze kunnen bij de base classes komen. Wat jij bedoeld met de designer is een feature van de IDE. Voor een taal kan je nl een codedom schrijven, dit is een abstracte representatie van je programmeer taal. Hierdoor kan de designer code generen voor de taal waarin jij je project gemaakt hebt.

een kruising tussen VB (ALLEEN managed Code).

Dit is niet waar. In C# en VB kun je unmanage code aanroepen, niet schrijven.
Wel kun je ervoor zorgen dat je C# of VB code unsafe word door van het DllImport attribuut gebruik te maken. Dit kan in VB, VB.NET en C#.

[bredend]

Ik heb een voorgevoel dat er veel mensen zijn die doorkrijgen dat er alternatieven zijn. Dus niet alleen maar wat ze altijd hadden. Volgens mij word het heel normaal om eens NIET een programma voor alles te gebruiken.
maja, t'is maar een voorgevoel.....

[heraut]

Het succes zal voor een groot deel afhangen van de bereidheid van softwarehuizen om deze taal te adopteren, en gezien de ijzersterke marketing en de huidige marktpositie van MS is hier een grote kans op.

Dat de uitvinder van Java, en dus een gedoodverfde concurrent, C# maar niks vindt zegt eigelijk helemaal niets. De uitvinder van Novell en onze vriend Linus Thorvalds vinden W2k ook niets, gek he?!

[Verwijderd]

Het ligt voor de hand dat de CLR wat meer mogelijkheden biedt dan een Java Virtual Machine, simpel weg omdat het idee dat aan het ontwerp ten grondslag ligt anders is. Voor Java is gekozen voor platform onafhankelijk en gegarandeerd veilige byte-code, voor het .Net platform ligt de nadruk op performance en aansluiten bij bestaande talen.

Dat laatste houdt in dat het mogelijk is om unsafe code te gebruiken, en uiteraard kan de performance (zeker van GUI componenten) een stuk omhoog als je niet per se platform onafhankelijkheid nodig hebt. Door de beschermde opzet van de JVM (verificatie van bytecode) kun je aan de ene kant er zeker van dat je geen 'slechte' code download, aan de andere kant betekend het dat veel constructies uit andere talen niet te implementeren zijn (zoals pointers).

Kortom: ander uitgangspunt, andere keuzes.

[Verwijderd]

maar door de toevoeging van compatibiliteit voor C en C++ is het geheel verschrikkelijk onbetrouwbaar geworden.

Het is allemaal wel iets subtieler dan dat.
Zogauw je gebruik gaat maken van die C++ compatibiliteit is je code niet meer "safe". In .Net gaat je OS je dan melden dat je unsafe code gaat starten en of je dat wel echt wilt.
Hou je je bij C# code, dan wordt je applicatie wel "safe".