[.NET] Multi-Lang: One Runtime to Bind Them All? *

[mbravenboer]

Tijdens een bezoekje aan www.javalobby.org kwam ik een artikel tegen waarin met name het multi-language gebeuren van .NET enorm op de hak wordt genomen. Zoals vaste P&W-lezertjes vast weten heb ik daar ook nogal eens kritiek op, dus ging ik snel aan het lezen .

Het stuk is vooral een kritiek op de manier waarop .NET wordt gepresenteerd en tracht meer de waarheid duidelijk te maken, dan .NET te vergelijken met Java.

Met sommige argumenten ben ik het niet helemaal eens, maar het is toch zeker de moeite van het lezen waard! Er staan veel duidelijke uitspraken in die niet zoveel te maken hebben met pure anti-Microsoft flames.

http://www.javalobby.org/clr.html

Dit stukje is mijn favoriet:

Playing with the .NET SDK, the cross-language support looks impressive, but the illusion holds true only until realizing that all languages in the mix are virtually identical. Microsoft has actually invented the concept of skinnable language: changing a languages most superficial aspects, and claiming the result to be a new language. There is only One True Language that is C#, and "skins" offered by Microsoft and third parties. Just like in GUIs, these skins will alter the systems look and feel, add a few features, but never compete with a fully new toolkit.

There are, actually, many successful "common language runtimes", with names like Pentium, SPARC and others. Mainstream CPUs are equally fitted to very different languages as they only do the most fundamental, low-level operations, so they cannot be biased towards particular languages. There arent many different ways to perform a conditional branch. However, there are radically different ways to support methods and functions, or most constructs found in high-level languages. The consequence is that every language needs different compilers and runtimes to implement their features, and different libraries to support their vision of software development.

[MisterData]

Ze hebben nu zelfs een CONVERTOR gebouwd om Java naar C# om te zetten (lees: MS marketing tool om Java developers over te halen naar C#:)

[Nielsz]

Kies dan een normale topictitle
Neej, seri, ik ben er net ff in begonnen, en het lijkt aardig leuk
Ik zal mijn .NET collegae er eens mee om de oren slaan

[mbravenboer]

MisterData: Ze hebben nu zelfs een CONVERTOR gebouwd om Java naar C# om te zetten

Das nogal een ander topic ( deze namelijk : [topic=403411/1/25] ).

Het gaat hier vooral om de generiekheid van MSIL, CTS, CLS en de CLR en de vraag of talen uberhaupt wel zo makkelijk kunnen samenwerken.

Graag feiten, meningen of ervaringen en geen bashing ... Bashing zorgt er juist voor dat feiten niet aan het licht komen .

[mbravenboer]

Even mijn eigen topic-titel klein beetje aangepast .

[Woudloper]

Interessant artikel.... Heb het net even doorgelezen...

Ik vond dit wel een grappig stukje:

Playing with the .NET SDK, the cross-language support looks impressive, but the illusion holds true only until realizing that all languages in the mix are virtually identical. Microsoft has actually invented the concept of skinnable language: changing a languages most superficial aspects, and claiming the result to be a new language.

Hebben ze toch nog iets zelfs uitgevonden....

Maar hoe zit het nou eigenlijk met dat CLR gebeuren, draait het al op andere platformen dan Windows?

[stylee]

Woudloper: Maar hoe zit het nou eigenlijk met dat CLR gebeuren, draait het al op andere platformen dan Windows?

Voor zover ik weet is er bij Microsoft intern een draaiende implementatie van de CLR op FreeBSD aanwezig, ik weet alleen niet of ze ook daadwerkelijk van plan zijn om deze te releasen.

Hopelijk wordt mono wel wat interessants...

[Verwijderd]

Op woensdag 06 februari 2002 17:05 schreef stylee het volgende:
Woudloper: Maar hoe zit het nou eigenlijk met dat CLR gebeuren, draait het al op andere platformen dan Windows?

Voor zover ik weet is er bij Microsoft intern een draaiende implementatie van de CLR op FreeBSD aanwezig, ik weet alleen niet of ze ook daadwerkelijk van plan zijn om deze te releasen.

Het is toch een open platform? Iedereen kan zijn eigen CLR bouwen..

[elnino]

Op woensdag 06 februari 2002 17:18 schreef Kerrick het volgende:
Het is toch een open platform? Iedereen kan zijn eigen CLR bouwen..

Maar daar gaat nogal veel tijd inzitten. Met het mono-project is men in ieder geval op de goede weg. .NET bestaat uit nogal veel onderdelen, bijvoorbeeld ADO .NET, .NET WinForms en die moet je ook allemaal gaan implementeren...

En Microsoft kennende zullen ze de FreeBSD-implementatie niet gaan vrijgeven...

[tomato]

elnino: .NET bestaat uit nogal veel onderdelen, bijvoorbeeld ADO .NET, .NET WinForms en die moet je ook allemaal gaan implementeren...

En Microsoft kennende zullen ze de FreeBSD-implementatie niet gaan vrijgeven...

Geloof maar niet dat ze bij Microsoft een WinForms implementatie voor FreeBSD hebben hoor

[Verwijderd]

Op woensdag 06 februari 2002 17:28 schreef tomato het volgende:

[..]

Geloof maar niet dat ze bij Microsoft een WinForms implementatie voor FreeBSD hebben hoor

Ja je hoeft .NET niet te gebruiken hoor.. maarre.. mooie uitdaging! leef je uit!

[elnino]

Maar wat ik mij eigenlijk afvraag is: Zal .NET alleen maar handig zijn voor grote enterprise-applicaties of wordt .NET juist ook voor consumenten handig? Een consument heeft niet direct belang bij al die WebControls, XML Web Services, ADO.NET etc.

De meeste gebruikers willen gewoon kunnen internetten, e-mailen, een tekstje in Word tikken en spelletjes spelen en voor hen hoeft het allemaal niet zo ingewikkeld. Het principe van .NET is misschien mooi, maar ook ingewikkeld. Probeer jij maar eens tegen iemand die niet veel van computers af weet uit te leggen wat de voordelen van XML Web Services, CLR en dat soort dingen zijn.

Microsoft probeert dat wel door haar Passport nu Passport.NET te noemen, en MSN Messenger ook een .NET-uitgang te geven, maar de meeste mensen zal dat .NET niet veel zeggen, net zoals veel MSN-gebruikers ook niet weten wat dat Passport inhoudt.

[stylee]

elnino:

Maar wat ik mij eigenlijk afvraag is: Zal .NET alleen maar handig zijn voor grote enterprise-applicaties of wordt .NET juist ook voor consumenten handig? Een consument heeft niet direct belang bij al die WebControls, XML Web Services, ADO.NET etc.

IMO is er - op dit moment - (.NET is qua webservices ed. nog niet echt van de grond, en geheel logisch ook, tis immers pas net uit) alleen maar voordeel voor ontwikkelaars.

En dan praten we niet alleen over technieken zoals WebServices, de CLR, IL, etc maar bovenal over ontwikkelen voor het windows platform zelf (HEEFT jan-modaal wel behoefte aan een cross-platform .NET omgeving?) WinForms, ADO.NET, ingebouwde language security (buffer overflows, here we come) t.o.v traditioneel Windows-programmeren (C/C++/MFC).

De meeste gebruikers willen gewoon kunnen internetten, e-mailen, een tekstje in Word tikken en spelletjes spelen en voor hen hoeft het allemaal niet zo ingewikkeld...

Ja precies, voor de consument verandert er bijna totaal niks. Het enige voordeel dat ik hier kan vinden is stabielere en meer op standaarden gebaseerde software.

[Verwijderd]

iets wat op 'javalobby' staat bekijken alsof het een nuttige kijk op de werkelijkheid geeft, lijkt me net zo zinnig als Microsoft's pages over Novell Netware gebruiken ter beoordeling van Novell Netware

[mbravenboer]

Otis: iets wat op 'javalobby' staat bekijken alsof het een nuttige kijk op de werkelijkheid geeft, lijkt me net zo zinnig als Microsoft's pages over Novell Netware gebruiken ter beoordeling van Novell Netware

Dat is goed om te beseffen terwijl je het stuk leest, maar geen reden om het niet te lezen . Bij voorbaat al vanwege de domeinnaam maar niet beginnen zou zonde zijn. Je kunt zelf beoordelen of het feiten zijn of bashing is.

Merk overigens tijdens het lezen op dat vrijwel nergens wordt beweerd dat het Java Platform beter is (dat zou ook dom zijn, want dit is absoluut niet het geval qua multi-language support). Het gaat meer over de zin en onzin van beweringen die worden gedaan over de taal-onafhankelijkheid van .NET.

Overigens is het inderdaad wat dom om het daar te hosten.

[Verwijderd]

Op woensdag 06 februari 2002 16:21 schreef mbravenboer het volgende:
There is only One True Language that is C#, and "skins" offered by Microsoft and third parties. Just like in GUIs, these skins will alter the systems look and feel, add a few features, but never compete with a fully new toolkit.

Hier ben ik het wel mee eens, maar dan: so what!
Ik bedoel, sommige mensen zullen de syntax van VB.Net heel prettig vinden, omdat die veel lijkt op VB. Da's dan heel mooi dat ze die kennis kunnen meenemen.
Anderen zullen meer van c# gescharmeerd zijn omdat dat meer op Java (als het al geen kopie is ) of op c++ lijkt.
Da's toch alleen maar mooi Ik zie het eerder als een pluspunt van .Net.

Natuurlijk maakt MS hier zorgvuldig mis ehhh gebruik van ter promotie, maar iedereen neemt de marketing kreten van MS hoop ik toch altijd met een korrel zout, hoop ik althans .

Dus wat is het probleem

[Tomatrix]

Op woensdag 06 februari 2002 19:04 schreef KoenM het volgende:
Dus wat is het probleem

Het probleem is dat MS met veel poeha en ramtamtam aankondigt dat ze een platform- en taal onafhankelijke intermediate language hebben ontwikkeld. Op beide punten valt echter nogal wat af te dingen.

[mbravenboer]

KoenM: Dus wat is het probleem

Er is niet zo'n groot probleem .

Je moet alleen bij het bespreken van voor- en nadelen van een platform wel goed weten wat 'multi-language support' betekent. Na alles wat ik gelezen heb (MSIL docs, slides, discussies, vergelijkeningen) lijkt het er voor mij op dat je multi-language support wel moet relevativeren. .NET blijft net als het Java Platform een OO-Virtual Machine. Talen die er op draaien moeten zoals je gelezen hebt aangepast worden om goed in .NET te passen. Dit geldt dus zelfs al voor talen die grofweg in hetzelfde paradigma vallen: C++, Java, VB, Eiffel.

Als je dus hoort dat al deze talen op .NET draaien moet je je wel realiseren dat dit (in extreme bewoordingen) 'skins' zijn van de kern-taal van .NET die lijken op de taal die wordt genoemd. Het is dus in vrijwel alle gevallen niet de oorspronkelijke taal en zeker niet door oorspronkelijke standaard library van deze taal. Eenmaal in .NET kom je er dus niet meer uit (das nog eens een markt voor transformatie-tools ).

Als je al ziet wat er voor toeren uit worden gehaald met de andere OO-talen, moet je denk ik het ergste vrezen voor de talen waarvoor multi-language support imho echt interessant is: declaratieve talen zoals Haskell, Lisp, Prolog etc.

Is .NET multi-language? Mwah...
In .NET werken met de taal van jouw smaak? Ja .

[Verwijderd]

Microsoft had ook weinig keus. De tussenlaag generiek maken (het COM-debacle) werkte dus niet, dan de taal maar generiek maken.

Er zal echter minder ruimte zijn voor echt andere talen. Dat is wellicht het offer dat betaald moet worden om OO naar het OS te brengen...

Nu vraag ik me af of het volgende straks gaat werken

code:

<script language="c#">...</script>

Zo, nu ga ik dat stuk 's doorlezen of ze nog punten hebben waarom ik java zou moeten gebruiken ipv dotnet.

[mbravenboer]

In een als maar doorgaande stroom info nog een paar interessante links die ik net weer vond (ja, ik lees ze zelf ook allemaal ).

Hier een stuk van Miguel de Icaza van Ximian, een belangrijk persoon in het Mono project van Ximian:
http://mail.gnome.org/archives/gnome-hackers/2002-February/msg00031.html
Uiteraard is hij zeer positief. Sommige zaken die hij noemt zijn ook duidelijk correct. Andere vind ik wat kort door de bocht.

Hij verwijst naar 2 stukken van Bertrand Meyer (vader van Eiffel):
http://eiffel.com/doc/manuals/technology/bmarticles/sd/dotnet.html
http://www.fawcette.com/dotnetmag/2001_12/online/online_eprods/bmeyer/default.asp

Helaas zijn alle stukken vrij opervlakking en gaan ze geen van alle goed in op het probleem waar dit topic uiteindelijk over ging (en ik deed zo m'n best om het geen algemene .NET discussie te maken ).

[Verwijderd]

Er zitten overigens genoeg verschillen in de talen, dus 'skinning' lijkt me wat onnozel. Zeker gezien wat VB.net kan/niet kan en wat C# bv kan/niet kan. Praat ik nog niet eens over managed C++.

[Verwijderd]

Op woensdag 06 februari 2002 20:28 schreef Otis het volgende:
Er zitten overigens genoeg verschillen in de talen, dus 'skinning' lijkt me wat onnozel. Zeker gezien wat VB.net kan/niet kan en wat C# bv kan/niet kan. Praat ik nog niet eens over managed C++.

Skinning is wellicht iets te kort door de bocht. Maar als een feature niet mapt naar CRL (bijv. templates van C++) dan is dat vanuit een andere taal niet beschikbaar.

[whoami]

Op woensdag 06 februari 2002 18:04 schreef elnino het volgende:
Maar wat ik mij eigenlijk afvraag is: Zal .NET alleen maar handig zijn voor grote enterprise-applicaties of wordt .NET juist ook voor consumenten handig? Een consument heeft niet direct belang bij al die WebControls, XML Web Services, ADO.NET etc.

Misschien hebben consumenten daar geen nood aan, maar je kan met .NET ook applicaties bouwen die geen gebruik maken van al die snufjes.
Daarbij, ik denk dat MS zich vooral richt op bedrijven met .NET, want het is daar dat er het meest geld te rapen is.

[Orphix]

Op woensdag 06 februari 2002 20:48 schreef Doekman het volgende:
Skinning is wellicht iets te kort door de bocht. Maar als een feature niet mapt naar CRL (bijv. templates van C++) dan is dat vanuit een andere taal niet beschikbaar.

waaaaaat? geen templates in C#

[mbravenboer]

Orphix: waaaaaat? geen templates in C#

Jij hebt aardig zitten slapen . C# heeft idd geen templates of generics, maar zal waarschijnlijk in de volgende 'major' release wel generics krijgen. Zie ook alle info hier:
[topic=401463]
In het bijzonder hier:
http://www.acm.org/sigplan/pldi/pldi2001/pldi01-presentations/DonSyme.pdf

Generics worden overigens ook besproken in het stuk waar dit topic mee begon.

De C in C# doet vermoeden dat het veel weg heeft van C++ , maar dat is dus zeker niet het geval.

[CyberSnooP]

Zinloos en onzin: Ach, het wordt toch allemaal assembler

Maar ik denk dat het redelijk flauw is om Micorsoft op dit punt aan te vallen. Programmeren is programmeren en ik heb de indruk dat de keuze van een taal tegenwoordig toch al voor het grootste deel een kwestie van voorkeur is.

Stel je voor dat MS had gekozen om alleen C# uittebrengen voor .NET. Dan zou iedereen nu roepen dat ze nooit overstappen omdat taal x niet wordt ondersteund bijv.

Het feit dat er een JAVA --> C# converter wordt gebouwd toont mijnsinziens wel aan dat er een redelijk algemene opvatting begint te ontstaan over hoe een moderne progammeertaal eruit moet zien. Ik heb het niet over details, die natuurlijk in de ene taal beter geïmplementeerd zijn dan de andere, maar het beeld lijkt me duidelijk.

[elnino]

Op woensdag 06 februari 2002 21:49 schreef CyberSnooP het volgende:
Zinloos en onzin: Ach, het wordt toch allemaal assembler

Met de CLR heeft Microsoft een nieuwe soort assembler 'uitgevonden', vergelijkbaar met de bytecode van Java. Aangezien je zowel C programma's, C++ programma's en bijv. Pascal programma's naar normaal assembler kunt compileren, kun je nu ook C#-programma's, managed C++-programma's en VB.NET-programma's naar die CLR compileren.

Ik ben misschien iets te optimistisch, want er zitten natuurlijk wel de nodige haken en ogen aan, want met VB.NET spreek je libraries op een andere manier aan dan met C# of met C++ bijvoorbeeld.

Met de benaming 'skins' ben ik ook niet echt helemaal mee eens, want om dezelfde reden zou je dan Pascal ook een skin van C noemen, omdat het uiteindelijk ook allemaal Assembler wordt...

[mbravenboer]

CyberSnooP: Zinloos en onzin: Ach, het wordt toch allemaal assembler

Idd . Ik pleit van een RISC gebaseerd intermediate language .

Maar ik denk dat het redelijk flauw is om Micorsoft op dit punt aan te vallen.

Er wordt volgens mij helemaal niemand aangevallen. Er wordt alleen goed gekeken in hoeverre gemaakt claims ook daadwerkelijke reeel zijn.

Het feit dat er een JAVA --> C# converter wordt gebouwd toont mijnsinziens wel aan dat er een redelijk algemene opvatting begint te ontstaan over hoe een moderne progammeertaal eruit moet zien.

Mwah, laten we het even bij een moderne OO-taal houden .

Het hele punt van deze converter is dat het onzin is. Het Java Platform is niet de taal Java. Java is slechts een irrelevant detail. Een converter is alleen zinvol als het een converter is van het ene platform naar het andere platform. Een converter van source code naar source code is niet zo spannend. Er bestaan bijvoorbeeld al tijden converter van Java source-code naar C++ (wat uiteraard triviaal is). Waarom gebruikt niemand die? Simpel: de taal Java is onlosmakelijk verbonden met het Java Platform.

Ik heb het niet over details, die natuurlijk in de ene taal beter geïmplementeerd zijn dan de andere, maar het beeld lijkt me duidelijk.

Voor libraries is abstractie van irrelevante details natuurlijk ideaal. Wat dat betreft biedt .NET ook een goede toekomst voor MS Windows ontwikkeling: de trend voor MS Windows ontwikkeling is gezet door de duidelijke libraries van .NET.

Deze hele draad was echter niet bedoeld als een discussie over .NET libraries, C#, .NET platform-onafhankelijkheid of wat dan ook. Bepaalde statements van Meyer passen precies bij mijn gedachten: C# is de human-readable variant van het object-model van .NET. In feite is MSIL in grote lijnen equivalent aan C#, net als Java Bytecode equivalent is aan Java. Omdat C# een bekende omgeving is, is het inzichtelijker of CIL nu echt een duidelijke multi-language omgeving is. Je kunt de vraag namelijk verleggen naar de vraag of C# een multi-language omgeving is. Die vraag is gemakkelijk te beantwoorden: ja, je kan alles wel compileren naar C#. Is dit echter ook wat je wilt? Compileren naar C# klinkt al een stuk minder aantrekkelijk dan compileren naar MSIL.

Ik denk zelf eigenlijk dat er eens goed onderzocht moet worden hoe basic een intermediate language moet zijn. We hebben nu een aantal uitersten gezien: Java bytecode en de instructie-set van een processor. CIL ligt daar tussenin, naar mijn smaak sterk richting de Java bytecode. Wat zou er gebeuren als je nog een stapje verder richting de instructie-set gaat?

In principe is dit een oude vraag: compilers gebruiken immers al lange tijd intermediate representations om het bouwen van compilers makkelijker te maken. In principe doen .NET en Java niets anders dan stoppen bij deze IR. Je kunt de vraag dus weer verleggen naar de vraag of er een IR is die zo generiek is dat elke paradigma er in kan worden uitgedrukt en toch specifiek genoeg om deze paradigma's ook te laten samenwerken...

[mbravenboer]

elnino: Met de benaming 'skins' ben ik ook niet echt helemaal mee eens, want om dezelfde reden zou je dan Pascal ook een skin van C noemen, omdat het uiteindelijk ook allemaal Assembler wordt...

Inderdaad, dat is zo. Maar wanneer is iets een skin?

Het is duidelijk dat we een taal geen skin noemen als het ze allebei naar het assembly model compileren. Het object-model van .NET is echter een stuk abstracter.

Er is een human-reasable variant van dit model: C#. Als je een human-readable variant van een instructie-set neemt krijg je assembly.... grote verschillen dus .

Het niveau komt dus hoger te liggen en er is een grens waarop je de verschillen tussen het object-model en een taal als irrelevant kunt gaan beschouwen. Voor Java en Java Bytecode is dat zeker het geval. Voor C# en .NET IL is het wellicht het geval.... Als andere talen nu een andere view op dit model bieden door andere syntax vormen en beperkingen van het model... Zijn ze dan een skin? Moeilijke vraag . Het is een ieder geval een alternatieve syntax voor hetzelfde model, waarbij het model van de taal altijd uitdrukbaar moet zijn in de termen van het model van .NET.

[Verwijderd]

Op woensdag 06 februari 2002 20:48 schreef Doekman het volgende:

[..]

Skinning is wellicht iets te kort door de bocht. Maar als een feature niet mapt naar CRL (bijv. templates van C++) dan is dat vanuit een andere taal niet beschikbaar.

Nee, je ziet het verkeerd: in VB.net kan bv 1 statement 100 regels MSIL code genereren, welk je in C# en in C++ in 20 regels moet uitbeitelen. _DAT_ is het verschil. C# heeft bv operator overloading dat niet in alle talen zit: je moet dan bv ook methods adden aan je classes zodat de classes gebruikt kunnen worden in andere talen die geen operator overloading hebben. Kan allemaal. De MSIL taal is wel vaststaand en de CLR werkt wel met classes en een vast stramien, maar het is te vergelijken met Delphi en BCB: de een is object pascal en de ander C++, maar beide compileren naar dezelfde intermediate language. Ik zou nu niet direct willen beweren dat Object pascal en C++ hetzelfde zijn, wirth-fetisjisten lusten je rauw

[CyberSnooP]

Op woensdag 06 februari 2002 22:05 schreef mbravenboer het volgende:
Ik denk zelf eigenlijk dat er eens goed onderzocht moet worden hoe basic een intermediate language moet zijn. We hebben nu een aantal uitersten gezien: Java bytecode en de instructie-set van een processor. CIL ligt daar tussenin, naar mijn smaak sterk richting de Java bytecode. Wat zou er gebeuren als je nog een stapje verder richting de instructie-set gaat?

Volgens mij is het doel van intermediate talen duidelijk, ze moeten platform onafhankelijkheid (net) mogelijk maken. Waar je precies op doelt met nog een stapje verder gaan weet ik niet. Misschien doel je op een processor met een bepaalde IL als instructie set. In gedachte spelen mensen daarmee, zo is er de (niet bestaande) picoJava processor die (zelfs) JAVA-Bytecode rechtstreeks uitvoert.

Je kunt de vraag dus weer verleggen naar de vraag of er een IR is die zo generiek is dat elke paradigma er in kan worden uitgedrukt en toch specifiek genoeg om deze paradigma's ook te laten samenwerken...

Tsja, hoever je met een IL (IR?) gaan? Dat ligt eraan wat de taal moet interpreteren. Ik denk dus niet dat je een algemeen antwoord kunt maken.

[mbravenboer]

CyberSnooP: Waar je precies op doelt met nog een stapje verder gaan weet ik niet. Misschien doel je op een processor met een bepaalde IL als instructie set.

Nee, zeker niet. We kennen nu Java Bytecode als IR, wat duidelijk volkomen ontoereikend is als generiek doel van compilatie. We kennen nu ook CIL als IR, wat volgens boze tongen dus ook ontoereikend is. Beiden hebben een OO-model. Wellicht ligt daar dus het grote probleem en moet er eens nagedacht worden over IR die geen OO-model hebben. Deze worden al gebruikt in compilers, waarom deze ook niet gebruiken voor een runtime?

Tsja, hoever je met een IL (IR?) gaan? Dat ligt eraan wat de taal moet interpreteren. Ik denk dus niet dat je een algemeen antwoord kunt maken.

Mwah, de instructie-set van een processor is een algemeen antwoord, maar uiteraard niet platform-onafhankelijk. Wellicht zijn er algemene antwoorden die wel platform-onafhankelijk kunnen zijn?

Overigens ken ik de CIL nog niet op m'n duimpje. Ik ben op dit moment bezig met een compiler die CIL als target heeft. Wellicht geeft dat nieuwe inzichten .

[Verwijderd]

Op woensdag 06 februari 2002 17:28 schreef tomato het volgende:
Geloof maar niet dat ze bij Microsoft een WinForms implementatie voor FreeBSD hebben hoor

Dat pretenderen ze ook niet,zie deze pagina voor meer info

The Microsoft Shared Source CLI Implementation will contain the source code to a complete implementation of the "common language infrastructure" (CLI), as well as two compilers, one for the C# language, and the other for the ECMAScript language. This CLI project shares much of its implementation with Microsoft's commercial CLI implementation, called the Microsoft .NET Framework, which is currently in beta.

Over de runtime geen woord echter (goh wat verassend )

[tomato]

Yarvieh: Dat pretenderen ze ook niet,zie deze pagina voor meer info

Precies, dat bedoelde ik ook

Over de runtime geen woord echter (goh wat verassend )

Oh wat geheimzinnig he

[Verwijderd]

Op woensdag 06 februari 2002 21:12 schreef mbravenboer het volgende:

[..]
Generics worden overigens ook besproken in het stuk waar dit topic mee begon.

De C in C# doet vermoeden dat het veel weg heeft van C++ , maar dat is dus zeker niet het geval.

Hoe belangrijk zijn die generics nu eigenlijk.

Collega's die met templates in C++ hebben gewerkt verafschuwen het. Meer last dan lust. Komt dat wellicht door de macro-achtige constructie van C++ templates?

[mbravenboer]

Doekman: Hoe belangrijk zijn die generics nu eigenlijk.

Tja, het introduceert een geheel nieuwe vorm van polymorphisme in OO... Ik werk zelf al tijden met de early access compiler (zie link in sig) en ben er werkelijk zeer tevreden mee.

Sowieso is het al zeer handig ter documentatie: een 'List' vereisen voor een methode zegt niet zoveel. Een List<String> uiteraard wel . Bij het gebruik van verzamelingen kan het enorm veel casts voorkomen en vergroot het de kans dat je at compile-time een melding krijgt over een misser.

Daarnaast is het zeer nuttig als je af en toe delen van je design iets functioneler opzet. Je kunt dan al heel snel heel goed generics gebruiken.

Zelf vind ik dat het een enorme code-reductie oplevert. Veel zaken die ik vroeger niet generiek zou implementeren tbv type-safety kan ik nu wel generiek en type-safe implementeren. Buitengewoon prettig .

Ik kan je meer dan genoeg kleine en grote voorbeelden geven van generieke implementaties. Ik heb pas een groot deel van een framework voor tabellen herschreven naar generics, waardoor je veel minder per specifieke tabel hoeft te implementeren. Een ware lust .

Ook de covariante return-typen die samen met generics zijn geintroduceerd zijn erg handig. Helaas zijn er alleen nog geen contra-variante argument-typen .

Je hebt dankzij generics en covariante return-typen in veel gevallen sneller de neiging om een interface te definieren voor een verzameling klassen. Soms is dit niet zozeer nuttig vanuit het oogpunt van polymorphisme, maar er gaat sowieso een grote documenterende werking vanuit .

Overigens kan je er ook veel te ver in gaan, waardoor je in feite volledig aan het functioneel programmeren bent in OO-vorm. Erg leuk en grappig, maar overdrijven kan tot wel vrij obscure code leiden .

Collega's die met templates in C++ hebben gewerkt verafschuwen het. Meer last dan lust. Komt dat wellicht door de macro-achtige constructie van C++ templates?

Je moet het ook niet te direct met templates vergelijken. Eigenlijk leveren generics de voordelen van templates min vrijwel alle nadelen.

[stylee]

[ot] nog wat leesvoer

[mbravenboer]

Ik kwam in de link van stylee deze tegen.... zo ontzettend grappig .

Must-read

http://haskell.org/humor/press.html

In a project that has been kept under wraps ever since the initial adoption of Java, a team of Microsoft researchers has prepared an alternative programming language for use in case of a serious dispute with Sun over the future of the Java language. After evaluating many programming languages, the team settled on Haskell as being the best alternative to Java. According to Chris Fraser, a Microsoft research scientist, "Haskell's polymorphic type system is far superior to the one developed for Java." Also, he asserts that "purely functional programs are the wave of the future: object oriented programming has reached a dead end." As other developers integrated Java into Microsoft products such as the Internet Explorer, this "shadow team" created secret versions of these same products using Haskell instead of Java. The team leader, Conal Elliott, asserts that due to the elegance and expressiveness of Haskell, his team was able to completely duplicate the work being done with Java using only a tenth of the manpower. As all tools needed to switch from Java to Haskell are already in place, Microsoft expects to completely purge its products of Java within a period of less than two months.

[stylee]

rofl

edit: argh irritant gewoon al die artikelen over .NET die om de haverklap verschijnen, heb gewoon geen tijd om ze allemaal te lezen

http://slashdot.org/developers/02/02/07/1433250.shtml

[mbravenboer]

stylee: argh irritant gewoon al die artikelen over .NET die om de haverklap verschijnen, heb gewoon geen tijd om ze allemaal te lezen

Hehe .

[Bill Joy over C#]

Zeer matig verhaal. Ik had betere stuff van Bill Joy verwacht. Dit raakt werkelijk kant nog wal. Het artikel waar dit topic mee begon is wat dat betreft een stuk beter .

[stylee]

mbravenboer: Zeer matig verhaal. Ik had betere stuff van Bill Joy verwacht...

Nee idd, het artikel was niet zo interessant als ik had gehoopt, maar die reacties op slashdot (op de standaard Microsoft-bashing replies na dan) bevatten toch wel het een en ander interessants.

[mbravenboer]

leuk:

Osvaldo heeft na zijn artikel een storm van reacties gehad. Hij heeft besloten een behoorlijk stuk aan zijn verhaal toe te voegen om dit commentaar te verwerken. Dit leidt tot een nog interessanter verhaal.

Het begin-stuk is nu ook doorspekt met commentaar van Erik Meijer (ja die kennen we ), Program Manager van de CLR bij Microsoft. Je kunt nu dus zelf bekijken wat de mening van een ongelooflijke kenner van .NET over het verhaal van Osvaldo is.

De combinatie van breed commentaar, discussie met Erik, de kijk van een Java kenner en een nieuwe conclusie zorgen voor een buitengewoon interessant verhaal.

Lezen dus!

http://www.javalobby.org/clr.html

_{en niet alleen de conclusie}

[Orphix]

pffff ... die 16 pagina's zijn wel ff doorbijten hoor op dit tijdstip wanneer je geen compilerbouwer bent

Maar eh tja, ik denk dat het wel duidelijk is dat de CLR niet perfect is. Erik Meijer nuanceert veel uitspraken maar spreekt ze niet tegen. Ik kan me wel vinden in de 2e conclusie van Osvaldo.
Ik persoonlijk geloof niet dat een goed multi-language platform ooit zal bestaan. En dan niet zozeer op byte niveau of de afhandeling van methods, maar meer het probleem dat de data-structuur en de taak-library van de talen niet overeenkomt / zal overeenkomen.

Wat ik ook wel grappig vond is dit
http://www.halcyonsoft.com/
Voor zover ik begreep kan deze .NET code naar Java compileren, inclusief support van WinForms. Heeft iemand hier al ervaring mee

[Verwijderd]

Interessant, oud topic
Zijn er nog mensen die wat kunnen zeggen over de verschillen tussen Java Byte Code en Intermediate Language en tussen de twee virtuele machines(JVM/CLR), zowel verschillen in achterliggende filosofie als de implicaties voor software-ontwikkeling?

Of eventueel interessante links weten die hier over gaan?