dotNET platform onafhankelijk?

[Verwijderd]

Ik probeer me wat meer te verdiepen in het .NET verhaal van Microsoft. Eén van de dingen die ik interessant vind is de (on)mogelijkheid van platform onafhankelijkheid.
Omdat alles op het .NET Framework draait zou het natuurlijk gewoon mogelijk moeten zijn om dat Framework naar een ander platform te porten om daar de .NET applicaties ook te kunnen draaien (zie Java).
Ik heb 2 soorten kritiek gehoord:
1. Het Framework heeft te weinig klassen waardoor je al snel systeem klassen moet gaan gebruiken. En dn is je applicatie niet meer platformonafhankelijk.
2. Het Framework is wel makkelijk te porten, maar de klassen bibliotheken niet omdat die te veel op Windows zijn gericht.

Volgens Microsoft is dat natuurlijk niet waar. Die zeggen een werkende versie voor FreeBSD te leveren inclusief diverse klassen. zie hier

Verder is er het Mono project dat volgens mij al ver op weg is om ook die klassen beschikbaar te maken voor Unix.

Zou het dan toch zo zijn dat Microsoft iets heeft gemaakt waardoor platform onafhankelijkheid dicht in de buurt komt? Of is het alleen een slimme zet van Microsoft om wat tegenstanders de mond te snoeren?

Graag jullie mening en bronnen van informatie.

[Dennis]

elefino:
Zou het dan toch zo zijn dat Microsoft iets heeft gemaakt waardoor platform onafhankelijkheid dicht in de buurt komt? Of is het alleen een slimme zet van Microsoft om wat tegenstanders de mond te snoeren?

Microsoft zal heus wel oppassen dat het niet wéér rechtszaken aan haar broek krijgt, maar ik kan me niet voorstellen dat ze toe staan te juichen dat het op andere platforms wordt gebruikt, laat staan dat ze daar _zelf_ support voor leveren (middels het bijleveren van klassen voor andere OS).

[mbravenboer]

Pfff, hier hebben we het al zoooo vak over gehad .

Kijk bijvoorbeeld eens hier:
[topic=326240/1/25]

Ik heb niet zoveel zin om alles te gaan herhalen wat in het verleden is gezegd, maar kan misschien nog wel op reacties ingaan.

In ieder geval moet je beseffen dat Rotor (de FreeBSD port) maar een zeer beperkt aantal applicaties kan draaien die op het de het .NET Framework voor Microsoft Windows draaien. Het bevat slechts een fractie van alle bibliotheken.

Verder is het zo dat .NET inderdaad in theorie platform-onafhankelijk is ivm de IL waarmee wordt gewerkt. Pijnlijk probleem bij .NET is alleen dat veel bibiotheken in .NET slechts een view vormen op native functionaliteit die dan platform onafhankelijk is verklaard. Omdat deze libraries echter zelf niet platform onafhankelijk geimplementeerd zijn, zorgt dit voor grote problemen bij het porten van de libraries naar andere platformen. Bij Java is dit anders: hier is het min of meer de gewoonte om alleen voor echt 'atomaire' operaties native code te gebruiken. Alle andere libraries zijn in 100% Java geimplementeerd en zijn dus ook direct platform-onafhankelijk.

Mono volgt deze aanpak in feite: hier wordt zoveel mogelijk van de libraries geimplementeerd in C# en is daardoor in feite platform onafhankelijk. Dit zorgt ervoor dat deze libraries ook ingezet kunnen worden op andere platformen. Ze timmeren op zich best aardig aan de weg en het is al leuk bruikbaar, maar het is zeker nog geen alternatief voor het .NET Framework op Microsoft Windows en Mono staat qua libraries nog in de kou vergeleken met het Java Platform.

Hum, toch nog teveel gezegd .

[mbravenboer]

Het grote probleem van andere implementaties als Mono is dat ze een andere codebase hebben en niet tegelijk met het 'echte' framework worden bijgehouden. Het zal erg lastig blijken te zijn om echt goed compatible te zijn met de implementatie van Microsoft en om aanpassingen en uitbreidingen in de implementatie van .NET bij te houden. Microsoft zal bijvoorbeeld in de volgende grote release van .NET de taal C# al weer op de schop nemen en geparameterizeerde typen toevoegen (zoals die ook in Java komen). De libraries zullen hierop ook aangepast moet worden (in het bijzonder de collections) en de andere implementaties moeten deze aanpassingen maar zien door te voeren in hun compilers en libraries.

Daarnaast is de specificatie in feite ook niet compleet genoeg. Een klein voorbeeldje: veel klassen gebruiken eigen serializatie code via het implementeren van ISerializable interface. Voor veel gevallen is deze serializatie niet gedocumenteerd en is de code ook niet beschikbaar. De enige manier om hierachter te komen is dus in feite via reverse engineering, waarmee je vaak nooit de hele waarheid kunt achterhalen of je op de grenzen van het toelaatbare begeeft.

Zo heeft het Mono project eigenlijk ontzettend veel punten waarin de specificatie of de API documentatie niet voldoende informatie geeft om duidelijk te kunnen achterhalen wat het gedrag van een stukje code moet zijn. Het werken met verschillende codebases is echt een groot probleem.

Serieuze implementaties voor andere platformen kunnen naar mijn gevoel (ik hoop dat ik het verkeerd heb) eigenlijk alleen geleverd worden door Microsoft zelf of door een andere enorme organisatie met goede ondersteuning van Microsoft.

Het Mono project is erg ondernemend, maar naar mijn mening naief. .NET bevat een schat aan bibliotheken op ontzettend veel gebieden (neem eens XML: XML Schema, XSLT, SOAP, XPath). Ze willen al deze bibliotheken in feite in het project opnieuw gaan ontwikkelen en dat is toch wel vrij onrealistisch. IBM/Apache en Microsoft hebben er bijvoorbeeld al erg veel moeite mee gehad om een fatsoenlijke XML Schema implementatie af te leveren. Dit zijn enorme organisaties! Zou het Mono project dan zo even al deze technologie in 1 klap implementeren? Hier is veel bredere ondersteuning en ontzettend veel tijd voor nodig...

Je merkt het: * mbravenboer kan z'n mond niet houden .

[Verwijderd]

Ik heb er geen problemen mee dat je je mond niet kn houden hoor :-)

Maar waar het volgens jou dus op neer komt is dat MONO heel hard achter de feiten aanloopt. En hoe hard ze ook lopen. Ze lopen er altijd achter. En als Microsoft vindt dat ze te dicht bij komen veranderen ze gewoon wat eigenschappen van C#.

En daarnaast zijn de klassen van .NET niet geschreven om platformonafhankelijkheid te bieden.

Toch moet ik zeggen dat als ik naar het overzicht kijk van welke klassen al (bijna)werkend zijn, ik best onder de indruk ben.

En natuurlijk bevat .NET veel bibliotheken, maar je moet Microsoft ook niet te veel eer toekennen. SOAP is niet van Microsoft en volgens mij zijn daar ook helemaal geen bibliotheken voor. Het is nl, voor zover weet, alleen maar een standaard over de opmaak van XML bestanden zodat communiceren via XML makkelijker wordt. En de ontwikkeling valt volledig onder het w3c.

[Alarmnummer]

kan het zijn dat Microsoft express heeft gezegd dat het theoretisch kan zodat het .NET project nog beter zou aanslaan? (Staat mooi als een feature). Maar dit expres niet gaat doen omdat dit Windows gaat ondermijnen?

Ik heb hier ook totaal geen problemen mee dat je uitleg geeft over c# en .NET want ik steek behoorlijk veel hiervan op

[whoami]

Op maandag 24 juni 2002 16:31 schreef elefino het volgende:

Maar waar het volgens jou dus op neer komt is dat MONO heel hard achter de feiten aanloopt. En hoe hard ze ook lopen. Ze lopen er altijd achter. En als Microsoft vindt dat ze te dicht bij komen veranderen ze gewoon wat eigenschappen van C#.

Dat denk ik niet. Ze lopen wel achter, maar dat komt door de complexiteit van de .NET classes, en niet omdat Microsoft vind dat ze te dicht komen en daarom wat veranderen aan C# of het .NET framework.
Ik denk dat Microsoft het heel graag zou hebben dat hun .NET framework ook op andere platformen kan draaien, zodat ze een waardig alternatief hebben voor het Java platform. Hun enige probleem is, dat hun framework redelijk complex is.

En daarnaast zijn de klassen van .NET niet geschreven om platformonafhankelijkheid te bieden.

Ik dacht het wel ?

[Verwijderd]

En als Microsoft de bibliotheken slechts heeft gemaakt als "view" op platform afhankelijke functionaliteit. Dan kunnen we concluderen dat Microsoft idd geen platformonafhankelijkheid wil en dit alles alleen doet om tegenstanders de mond te snoeren.

Of ben ik nu te kort door de bocht?

Het lijkt mij eerlijk gezegd wat raar. Microsoft heeft er toch veel tijd/geld in gestoken. Dat zullen ze toch niet alleen gedaan hebben om "te kunnen zeggen" dat het platformonafhankelijkheid biedt?

[Verwijderd]

Op maandag 24 juni 2002 16:37 schreef whoami het volgende:
Ik dacht het wel ?

Volgens mbravenboer juist niet. Maar alleen een nieuwe benaming die intern (dus in de runtime) gewoon platformafhankelijke functies aanroept.

[whoami]

Misschien wel ja...

Ik denk wel dat MS niet alleen die IL ontwikkeld heeft om platform-onafhankelijkheid te bekomen, maar eerder om taal-onafhankelijkheid te bekomen. (Wat volgens mij toch zo geen groot voordeel is als platform-onafhankelijkheid).

[Verwijderd]

Op maandag 24 juni 2002 16:31 schreef elefino het volgende:
maar je moet Microsoft ook niet te veel eer toekennen. SOAP is niet van Microsoft [..] Het is nl, voor zover weet, alleen maar een standaard over de opmaak van XML bestanden zodat communiceren via XML makkelijker wordt. En de ontwikkeling valt volledig onder het w3c.

Opzich heb je gelijk, maak kijk voor de grap es naar de schrijvers van de W3 Soap Specificaties

Authors (alphabetically):
Don Box, DevelopMentor
David Ehnebuske, IBM
Gopal Kakivaya, Microsoft
Andrew Layman, Microsoft
Noah Mendelsohn, Lotus Development Corp.
Henrik Frystyk Nielsen, Microsoft
Satish Thatte, Microsoft
Dave Winer, UserLand Software, Inc.

Tel het aantal niet microsofters (Don box is inmiddels ook Microsoft).

[Verwijderd]

Op maandag 24 juni 2002 16:46 schreef whoami het volgende:
Misschien wel ja...

Ik denk wel dat MS niet alleen die IL ontwikkeld heeft om platform-onafhankelijkheid te bekomen, maar eerder om taal-onafhankelijkheid te bekomen. (Wat volgens mij toch zo geen groot voordeel is als platform-onafhankelijkheid).

Ik ben het niet helemaal met je eens dat taal onafhankelijkheid / meertaligheid van minder belang is. Het biedt hele grote voordelen als bij een applicatie voor verschillende functie's gebruik gemaakt kan worden van talen die daarvoor het best geschikt zijn.
Daarnaast wordt het veel makkelijker om code te hergebruiiken omdat het niet meer afhankelijk van de taal is of het wel of niet kan.

Maar waar ik nu vooral in geïnteresseerd ben is de platform onafhankelijkheid.

mbravenboer, waar haal jij die informatie vandaan dat het framework toch gewoon gebruik maakt van platformafhankelijke functies?

[whoami]

Op maandag 24 juni 2002 16:54 schreef elefino het volgende:


Ik ben het niet helemaal met je eens dat taal onafhankelijkheid / meertaligheid van minder belang is. Het biedt hele grote voordelen als bij een applicatie voor verschillende functie's gebruik gemaakt kan worden van talen die daarvoor het best geschikt zijn.

Zie jij een wezenlijk verschil tussen de .NET talen die nu beschikbaar zijn? C#, VB.NET, ...

[Verwijderd]

Op maandag 24 juni 2002 16:56 schreef whoami het volgende:
Zie jij een wezenlijk verschil tussen de .NET talen die nu beschikbaar zijn? C#, VB.NET, ...

C# laat unsafe code (POINTERS!! YEAH BABY! YEAH!) toe, VB.net niet

[whoami]

Op maandag 24 juni 2002 16:59 schreef Yarvieh het volgende:

C# laat unsafe code (POINTERS!! YEAH BABY! YEAH!) toe, VB.net niet

Idd, maar dat vind ik argument om te zeggen dat C# dan voor een bepaald onderdeel beter geschikt is dan VB.NET.

Trouwens, als je unsafe code schrijft, heb je unmanaged code.

[mbravenboer]

elefino: Maar waar het volgens jou dus op neer komt is dat MONO heel hard achter de feiten aanloopt. En hoe hard ze ook lopen. Ze lopen er altijd achter.

Daar ben ik inderdaad bang voor en als je reeel bent is dit gewoon een feit: zelfs IBM loopt op Java gebied altijd achter op Sun. .NET is qua omvang toch groter dan het Java Platform en Ximian is met alle respect toch niet echt een gigantisch bedrijf. Bovendien gebruikt IBM ook nog de standaard libraries .

En als Microsoft vindt dat ze te dicht bij komen veranderen ze gewoon wat eigenschappen van C#.

Mwah, dat zijn jouw woorden... . Generics zijn een waardevolle toevoeging, alleen jammer dat ze er niet vanaf het begin al in zaten: het grote probleem waar het Java Platform op dit punt nu zit, gaat in feite nu ook al spelen voor .NET.

Toch moet ik zeggen dat als ik naar het overzicht kijk van welke klassen al (bijna)werkend zijn, ik best onder de indruk ben.

Klopt, het valt mij ook zeker mee: toch moet je wel even goed naar die klassen kijken. Veel klassen zijn niet klaar en in veel packages zijn alleen de makkelijk interfaces gegeven: implementaties ontbreken nog vaak. De status is op dit moment naar mijn mening ongeveer gelijk aan Java 1.0 en dat is toch meer dan ik had gedacht een jaar geleden.

SOAP is niet van Microsoft en volgens mij zijn daar ook helemaal geen bibliotheken voor. Het is nl, voor zover weet, alleen maar een standaard over de opmaak van XML bestanden zodat communiceren via XML makkelijker wordt. En de ontwikkeling valt volledig onder het w3c.

Mwah, W3C levert alleen maar standaarden hoor: implementaties zijn voor de rekening van bedrijven als Sun, Microsoft, IBM emn Apache. SOAP vraagt wel degelijk een behoorlijke kwak code, zeker in de vorm van .NET Remoting. Kijk bijvoorbeeld maar eens naar de Java bibliotheken voor SOAP: Apache SOAP, Axis, JAXM en JAX-RPC zijn toch echt bibliotheken waar aardig wat werken in zit.

kan het zijn dat Microsoft express heeft gezegd dat het theoretisch kan zodat het .NET project nog beter zou aanslaan? (Staat mooi als een feature). Maar dit expres niet gaat doen omdat dit Windows gaat ondermijnen?

Mwah, ik geloof niet zo in al die complot-theorien...

Wel is het denk ik zo dat de platform-onafhankelijkheid van .NET vaak toch wel wat erg positief belicht wordt en de haken en ogen die eraan kleven in ieder geval niet besproken worden door Microsoft.

In feite is het zo dat een Microsoft een platform-standaard heeft neergezet die sterk lijkt op een Microsoft Windows platform. De implementatie van deze standaard voor andere platformen is in de visie van Microsoft niet hun probleem. Ze geven de .NET implementatie voor Microsoft Windows op deze manier een enorme voorsprong op implementaties op andere platformen.

En als Microsoft de bibliotheken slechts heeft gemaakt als "view" op platform afhankelijke functionaliteit. Dan kunnen we concluderen dat Microsoft idd geen platformonafhankelijkheid wil en dit alles alleen doet om tegenstanders de mond te snoeren.

Of ben ik nu te kort door de bocht?

Mwah, het is een logische aanpak voor een opzet van een platform wat het ontwikkel platform voor Microsoft Windows moet gaan worden. Ik heb er een beetje moeite mee om dan gelijk een voorstelling te geven van mannetjes binnen Microsoft als duiveltjes complotten zitten te smeden.

Volgens mbravenboer juist niet. Maar alleen een nieuwe benaming die intern (dus in de runtime) gewoon platformafhankelijke functies aanroept.

Uiteraard, op zich is daar geen probleem mee: Java doet dit ook. Elke platformonafhankelijk runtime zal dit moeten doen. Het grote verschil is alleen dat de hoeveelheid native code in Java zover mogelijk geminimaliseerd wordt en dat in .NET niet is gebeurd (of misschien zelfs niet kan gebeuren). Overigens was het nog de vraag geweest of de code die wel platform-onafhankelijk geimplemenenteerd was, gebruikt mocht gaan worden op andere platformen, maar dat is koffie-dik kijken.

Het lijkt mij eerlijk gezegd wat raar. Microsoft heeft er toch veel tijd/geld in gestoken. Dat zullen ze toch niet alleen gedaan hebben om "te kunnen zeggen" dat het platformonafhankelijkheid biedt?

Vergeet niet dat de opzet van .NET (IL, platform-onafhankelijk, just in time compilatie) ook voor systemen met het Microsoft Windows besturingssysteem erg gunstig kan zijn.

Denk maar eens aan kleine devices, maar bijvoorbeeld ook aan 64 bits processoren die toch door gaan dringen. Deze tweedeling had weleens een zootje kunnen creeeren op het Microsoft Windows platform, maar met een runtime als .NET wordt dat voorkomen (als deze tegen die tijd ook daadwerkelijk intenstief gebruikt wordt).

Ook hebben ze met deze renovatie behoorlijk orde op zaken kunnen stellen in de vaak bekritiseerde libraries en de documentatie daarvan. Ontwikkeling voor Microsoft Windows heeft met .NET toch een aanmerkelijk hoger 'fun' gehalte dan voorheen....

Verder speelt taal onafhankelijkheid zoals whoami al zegt ook wel een rol. Dit had ook wel native gerealiseerd kunnen worden, maar in een runtime komt het toch allemaal wat prettiger over. Microsoft voorziet misschien een grote stijging in de diversiteit onder de talen (laten we het hopen ) en wellicht zelfs een doorbraak in de praktijk van declaratieve talen. .NET helpt hier zeker bij, alhoewel het nog steeds vele problemen heeft (dat is nog vaker besproken hier ).

[Verwijderd]

Op maandag 24 juni 2002 15:37 schreef elefino het volgende:
Ik probeer me wat meer te verdiepen in het .NET verhaal van Microsoft. Eén van de dingen die ik interessant vind is de (on)mogelijkheid van platform onafhankelijkheid.

Platformonafhankelijkheid is iets voor marketing-pipo's. In de praktijk bestaat er niet zoiets als platformonafhankelijkheid, maar wordt dat ook niet gemist: je praat over functionaliteit die je implementeert op een zeker platform P en waar je gebruik van maakt op eenzelfde of ander platform P'. Dat is met erg veel technieken mogelijk en geeft aan dat het streven naar platformonafhankelijkheid (en daar dus consessies voor doen, erg belangrijk) niet nodig is.

Omdat alles op het .NET Framework draait zou het natuurlijk gewoon mogelijk moeten zijn om dat Framework naar een ander platform te porten om daar de .NET applicaties ook te kunnen draaien (zie Java).
Ik heb 2 soorten kritiek gehoord:
1. Het Framework heeft te weinig klassen waardoor je al snel systeem klassen moet gaan gebruiken. En dn is je applicatie niet meer platformonafhankelijk.

Wie dit roept heeft zn kop in zn aars en leest louter boekjes over C.

2. Het Framework is wel makkelijk te porten, maar de klassen bibliotheken niet omdat die te veel op Windows zijn gericht.

Ook kul. Erg veel classes zijn geschreven in C#. Maw: selfhosting.

Zou het dan toch zo zijn dat Microsoft iets heeft gemaakt waardoor platform onafhankelijkheid dicht in de buurt komt? Of is het alleen een slimme zet van Microsoft om wat tegenstanders de mond te snoeren?

Who gives a flying f*ck! Ja sorry hoor, maar ik word altijd zo moe van dat ge-emmer over platformonafhankelijkheid! Kijk naar de functionaliteit die je moet bouwen, kies het platform uit dat je wilt gebruiken en bouw je functionaliteit. Heb je functionaliteit nodig van andere services, dan communiceer je daarmee en gebruik je de output van die services. Dat kon 10 jaar geleden al, dat kan nog steeds en met webservices / SOAP / XML wordt dat alleen maar beter en makkelijker.

Mensen die emmmeren over 'platformonafhankelijkheid' begrijpen niet wat er werkelijk belangrijk is.

[mbravenboer]

elefino: mbravenboer, waar haal jij die informatie vandaan dat het framework toch gewoon gebruik maakt van platformafhankelijke functies?

Tja, dat ligt voor eenvoudige zaken nogal voor de hand omdat je wel zult moeten (net als in Java). Als de library helemaal platform onafhankelijk zou zijn, zou hij op welke platform kunnen draaien als je een jitter hebt .

In Java (en ook in .NET) gaat het hierbij per definitie om zaken als IO: files, sockets en dergelijke. Dat is echter niet het punt omdat je op dit punt niet ontkomt aan platform specifieke, native code.

Bij concrete voorbeelden moet ik even goed uitkijken omdat 1 vergissing m'n argumenten zal ontkrachten en ik uiteraard ook geen insider ben . Ik kan echter wel verdenkingen uiten die ondersteunt worden door uitlatingen in interviews met bijvoorbeeld de mannen van de open-source .NET projecten: System.Windows.Forms (wat dus wel in de System namespace zit en niet in de Microsoft.Win32 namespace), System.Drawing, ADO .NET, OLE.

Verder zijn er nog erg veel bibliotheken die wellicht prima op andere platformen te realiseren zijn, maar toch duidelijk een verspreiding van Microsoft Windows ideeen tot gevolg zullen hebben. Denk daarbij bijvoorbeeld eens aan System.DirectoryServices wat volledig op Active Directory is gericht (passen alternatieven daarin zoals die in JNDI passen?) en uiteraard weer de WinForms.

Ik heb helemaal geen problemen met intensief gebruik van native functionaliteit, maar je moet uitkijken met native functionaliteit in de System namespace. Alles wat onder Microsoft.Win32 zit, vind ik fantastisch.

[Verwijderd]

Op maandag 24 juni 2002 16:54 schreef elefino het volgende:
[..]
Ik ben het niet helemaal met je eens dat taal onafhankelijkheid / meertaligheid van minder belang is. Het biedt hele grote voordelen als bij een applicatie voor verschillende functie's gebruik gemaakt kan worden van talen die daarvoor het best geschikt zijn.

Dat kan al jaren, dat fenomeen heette vroeger 'library' en tegenwoordig 'com object/corba object'.

Daarnaast wordt het veel makkelijker om code te hergebruiiken omdat het niet meer afhankelijk van de taal is of het wel of niet kan.

Hergebruik van CODE is iets dat onzinnig is. Hergebruik van geimplementeerde functionaliteit, DAAR heb je wat aan. Het focussen van het hergebruik van programmateksten is volledig NIET begrijpen wat je aan het doen bent wanneer je programma's bouwt. Daarom is het ook niet interessant als je een library of COM object gebruikt, je de sourcecode er per se van moet hebben. Het gaat om de functionaliteit die geboden wordt, DIE moet je hergebruiken. De CLR heeft alle features die het mogelijk maken IEDERE library te hergebruiken of ieder .NET object, zelfs ieder COM object. Interesseert het IEMAND in welke bout-taal die dingen geschreven zijn? Nee natuurlijk niet. Creeer object, roep functie aan, van resultaat op, destroy object, klaar. Oh, was dit in VB geschreven? Lekker belangrijk.

Maar waar ik nu vooral in geïnteresseerd ben is de platform onafhankelijkheid.

Nee, waar je in geinteresseerd bent is op hoeveel platforms (lees: OS-en) de functionaliteit van het .NET platform wordt uitgebracht. Dat is het enige dat interessant is. De rest is zeur-voer voor puristen uit java.advocacy groepen of nog erger: Sun-marketeers.

mbravenboer, waar haal jij die informatie vandaan dat het framework toch gewoon gebruik maakt van platformafhankelijke functies?

Ieder kind van 3 dat programmeert snapt dat .NET gebruik maakt van win32/win64, waar nuttig en dat ze ook veel opnieuw hebben gedaan waar ze kans lopen door wijzigingen in win32 of fixes op dat level het .NET platform onderuit te halen. Veel, heel veel, van de .NET classes zijn gewoon C# code, zie bv de rotor sourcecode.

[mbravenboer]

Otis: Platformonafhankelijkheid is iets voor marketing-pipo's.

Java heeft anders verbazingwekkend genoeg met platformonafhankelijkheid wel de server-side verovert. Kennelijk is het daar dus een relevant issue. Op de desktop is het geen issue omdat er daar in feite maar 1 speler is. Exact om die reden is Java op de desktop ook nooit echt aangeslagen (meegewerkt door grote integratie problemen).

Ook kul. Erg classes zijn geschreven in C#. Maw: Selfhosting.

Het .NET Framework is alles behalve selfhosting, maar goed... Verder lijkt het mij vooral kul als je beweert dat een framework met als hoofdonderdelen onder andere WinForms, ADO .NET en Active Directory niet sterk gebaseerd is op het Microsoft Windows Platform. Niet dat ik zeg dat ze het anders hadden moeten doen: ze kunnen moeilijk anders.

Who gives a flying f*ck! Ja sorry hoor, maar ik word altijd zo moe van dat ge-emmer over platformonafhankelijkheid!

Tja, dat jij altijd aangeeft dat bijvoorbeeld Linux jouw geen ruk interesseert en dat het je zeker niet boeit of .NET daarop draait of niet, wil nog niet zeggen dat iedereen die mening deelt. Zoals ik al eerder noemde: Java is juist op de server-side een groot succes (zeg maar gerust alleen op de server-side) en platform onafhankelijkheid van Java is daarvan toch echt 1 van de oorzaken.

Mensen die emmmeren over 'platformonafhankelijkheid' begrijpen niet wat er werkelijk belangrijk is.

Bedankt, het went om afgezeken te worden door Otis .

Ik zou graag willen dat het complete .NET Framework beschikbaar is voor bijvoorbeeld Linux en dat ik bijvoorbeeld m'n web-services en .NET Remoting applicaties op een Linux gebaseerd systeem kan hosten. Ik zou graag willen dat ik WinForms gebaseerd applicaties kon draaien op zowel Linux als Microsoft Windows. Ik zou graag XML tools willen schrijven in .NET voor bijvoorbeeld Relax NG en die laten gebruiken door zowel Unix, Mac OS X, Linux als Microsoft Windows gebruikers. Nu moet ik hiervoor nog Java pakken (wat ik overigens met liefde doe ).

[Verwijderd]

Nog even over dat platformonafhankelijkheidsgezever: als je per-se een OS A wilt gebruiken omdat je plasser daar strak van gaat staan en DUS wilt dat een zeker applicatie-framework geport wordt naar dat OS, maw: platform onafhankelijk wordt, en je diep droevig wordt wanneer dat platform louter voor OS B te krijgen is, het OS waarvan je de gebruikers altijd uitlacht omdat ze zo dom zijn, luistert:

dan snap er niks van en zou het je verboden moeten worden software te bouwen.

Zo.

[mbravenboer]

Otis: Nog even over dat platformonafhankelijkheidsgezever: als je per-se een OS A wilt gebruiken omdat je plasser daar strak van gaat staan en DUS wilt dat een zeker applicatie-framework geport wordt naar dat OS

Agosj, wat ben ik toch dol op je manier van discussieren . Die subtiliteit! Die argumenten! .

dan snap er niks van en zou het je verboden moeten worden software te bouwen.

Ik werk met Stratego. Stratego is een bere krachtige transformatie-taal waarin ik onder andere compilers schrijf en diverse andere transformatie-tools. Ik wil graag extra tools rond Stratego implementeren waarbij ik af en toe een imperatieve taal moet pakken. Is het gek als ik dan een fatsoenlijke taal en platform wil hebben? Ik kies nu voor Java, maar zou het even graag in .NET willen doen.

Platform-onafhankelijkheid is in mijn geval wel degelijk een issue en dat is ook voor veel andere mensen zo. Dat je web-services kunt hosten op alle platformen en dat kunt communiceren is irrelevant in dit geval: ik wil gewoon tools op mijn platform.

[mbravenboer]

Otis: Nee, waar je in geinteresseerd bent is op hoeveel platforms (lees: OS-en) de functionaliteit van het .NET platform wordt uitgebracht. Dat is het enige dat interessant is.

Dat is ook het onderwerp van discussie. Dat je daarover praat als platform-onafhankelheid kan misschien strikt genomen niet helemaal juist zijn, maar het verandert niets aan de kern van de wens. De platform onafhankelijkheid van een platform is een indicatie van de mogelijkheden om je wens vervult te zien in de toekomst.

De rest is zeur-voer voor puristen uit java.advocacy groepen of nog erger: Sun-marketeers.

Agosj.... gooi de frustraties er maar uit hoor .

[Verwijderd]

Op maandag 24 juni 2002 17:52 schreef mbravenboer het volgende:
[..]
Java heeft anders verbazingwekkend genoeg met platformonafhankelijkheid wel de server-side verovert. Kennelijk is het daar dus een relevant issue. Op de desktop is het geen issue omdat er daar in feite maar 1 speler is. Exact om die reden is Java op de desktop ook nooit echt aangeslagen (meegewerkt door grote integratie problemen).

Java op de serverside was de enige manier om op Unix op een gemakkelijke, OO manier n-tier apps te bouwen. Je alternatief was perl of C. Geen wonder dat veel mensen kozen voor Java op de server. Maar zeg eens, hoeveel platforms ondersteunen EXACT dezelfde java-api, met dezelfde performance?

Juist.

Is dat belangrijk? Nee. Want: wil je per se java programmeren? Dan neem je het platform waar java het beste op draait. Dan kies je dus geen Windows2000. Wil je VB programmeren? Ga je dan zeuren dat Linux geen VB programma's draait? nee, je kiest voor windows2000 en gaat fijn VB programmeren.

[..]
Het .NET Framework is alles behalve selfhosting, maar goed... Verder lijkt het mij vooral kul als je beweert dat een framework met als hoofdonderdelen onder andere WinForms, ADO .NET en Active Directory niet sterk gebaseerd is op het Microsoft Windows Platform. Niet dat ik zeg dat ze het anders hadden moeten doen: ze kunnen moeilijk anders.

Sinds wanneer is AD een hoofdonderdeel van .NET? De api die bij Rotor is geleverd is erg groot al, nee, geen ASP.NET, geen ADO.net en geen winforms, klopt. Maar wel veel plumbing code, erg veel zelfs. Lijkt me dat die plumbing code wel belangrijker is dan 'ADO.NET', ookal is dat een belangrijke serie namespaces.

Tuurlijk grijpen veel zaken terug naar OS-specifieke zaken, waarom niet? Erg veel code is echter wel degelijk .NET code.

[..]
Tja, dat jij altijd aangeeft dat bijvoorbeeld Linux jouw geen ruk interesseert en dat het je zeker niet boeit of .NET daarop draait of niet, wil nog niet zeggen dat iedereen die mening deelt. Zoals ik al eerder noemde: Java is juist op de server-side een groot succes (zeg maar gerust alleen op de server-side) en platform onafhankelijkheid van Java is daarvan toch echt 1 van de oorzaken.

Nee. Ik progde java in '95 en toen was het nog een issue. Nu allang niet meer. Linux interesseert me inderdaad echt geen reet. Dat komt omdat het applicatie-framework waar ik mee wil werken op windows2000 draait, dus waarom moet ik naar Linux kijken? Dat is EXACT het debiele van platformonafhankelijkheid en daar consessies voor doen. want dat moet je, bij platformonafhankelijkheid. Ik wil als windows2000 gebruiker helemaal geen 'grootst gemene deler'-troep draaien omdat het ook op een apple iMac moet draaien. Wilde ik dat, dan kocht ik wel een iMac.

Functionaliteitsdistributie, DAT is belangrijk: ervoor zorgen dat je oracle database op je 2miljoen euro kostende Sunbak kan communiceren met je goedkope win2k webserverfarm. Moet dat allemaal op 1 platform gebouwd worden? Nee natuurlijk niet. Dat interesseert niemand iets. Het gaat om de functionaliteit en of je daarmee kunt werken. Vroeger kon dat nog niet overal, dus wilde men overal 1 platform. Nu ziet men in dat dat onhaalbaar is en ook onnodige consessies oplevert. Er is veel energie gestoken in het mogelijk maken van ongelimiteerde communicatie tussen services op allerlei platforms. dat is niet voor niks. Zodoende maak je gebruik van elk platform's beste kanten en minimaliseer je de grootst-gemene-deler ellende.

[..]
Bedankt, het went om afgezeken te worden door Otis .

Je gaat me toch niet vertellen dat platformonafhankelijkheid, dat ALTIJD een prijs heeft, belangrijk is. Les 1 uit de praktijk: dat is het nl. niet.

Ik zou graag willen dat het complete .NET Framework beschikbaar is voor bijvoorbeeld Linux en dat ik bijvoorbeeld m'n web-services en .NET Remoting applicaties op een Linux gebaseerd systeem kan hosten.

Waarom? Waarom is linux in dit kader belangrijk? Het interesseert toch geen ene moer waar je framework op draait, je applicaties draaien toch op / binnen het framework? Nu ga je dus de keuze van het OS onder het framework belangrijk maken en als motivatie voor platformonafhankelijkheid. Erg nuttig... not.

Ik zou graag willen dat ik WinForms gebaseerd applicaties kon draaien op zowel Linux als Microsoft Windows. Ik zou graag XML tools willen schrijven in .NET voor bijvoorbeeld Relax NG en die laten gebruiken door zowel Unix, Mac OS X, Linux als Microsoft Windows gebruikers. Nu moet ik hiervoor nog Java pakken (wat ik overigens met liefde doe ).

Mja, op windows gebruikt iedereen MSXML. Een java tool werkt daar niet mee. Tot zover je platformonafhankelijkheid. Ik zit er overigens niet mee hoor: use the right tool for the job. En daar hoort een OS ook bij, dat is tenslotte ook gewoon een tool, net als een taal en welke ranzige api men ook moge gebruiken.

[Verwijderd]

Op maandag 24 juni 2002 17:58 schreef mbravenboer het volgende:
[..]
Agosj, wat ben ik toch dol op je manier van discussieren . Die subtiliteit! Die argumenten! .

heb de spot er maar mee, elk jaar worden er erg veel bakken met geld verkwist doordat men niet begrijpt dat platformonafhankelijkheid onnozel is en men eigenlijk ergens anders over zou moeten zemelen.

[..]
Ik werk met Stratego. Stratego is een bere krachtige transformatie-taal waarin ik onder andere compilers schrijf en diverse andere transformatie-tools. Ik wil graag extra tools rond Stratego implementeren waarbij ik af en toe een imperatieve taal moet pakken. Is het gek als ik dan een fatsoenlijke taal en platform wil hebben? Ik kies nu voor Java, maar zou het even graag in .NET willen doen.

Dan installeer je windows2000, je stratego interpreter en .net. klaar ben je. Dat jij perse alle tools voor bv linux wilt is jouw probleem. Ik wil ook alle leuke gratis tools voor linux voor mijn win2k bak. Dat lukt ook niet altijd. Jammer dan, dan moet ik maar linux gebruiken.

Platform-onafhankelijkheid is in mijn geval wel degelijk een issue en dat is ook voor veel andere mensen zo. Dat je web-services kunt hosten op alle platformen en dat kunt communiceren is irrelevant in dit geval: ik wil gewoon tools op mijn platform.

Ah, die laatste zin is precies de issue: jij wilt niet van je platform af (OS) en dus moeten alle frameworks maar naar dat platform toe. Platformonafhankelijkheid is DUS belangrijk want anders lukt dat niet! Nou, je had iets over argumenten, dit is, sorry, echt geen argument voor platformonafhankelijkheid. Dat op windows veel software veel prettiger werkt en op MacOS X alles er nog gelikter uitziet is leuk en je wilt dat wellicht op solaris 7.x, maar je kunt ook van platform wisselen, dan ben je sneller klaar. Een van de redenen dat ik op windows zit nu en niet op Unix: visual studio en visio werken alleen op windows.

Webservices hoeven ook niet naar 'alle platforms'. Je kunt altijd een sucket openen en daar xml over duwen of binaire data voor mijn part. Hoeveel systemen communiceren er niet altijd nog (got forbid) via ascii files en polling? Heden ten dage is dat dus GEEN (vroeger, zeg 1995-1998, wel) reden meer om dan maar platformonafhankelijkheid te betrachten opdat alles op 1 platform draait en dus communicatie tussen processen / services makkelijker bereikt kan worden: dat is nu transparant (ga maar eens een webservice integreren in je applicatie in visual studio.net, daar merk je dus niets van). En zo hoort het ook.

[Verwijderd]

Op maandag 24 juni 2002 18:02 schreef mbravenboer het volgende:
[..]
Dat is ook het onderwerp van discussie. Dat je daarover praat als platform-onafhankelheid kan misschien strikt genomen niet helemaal juist zijn, maar het verandert niets aan de kern van de wens. De platform onafhankelijkheid van een platform is een indicatie van de mogelijkheden om je wens vervult te zien in de toekomst.

Huh? Dringt het echt niet tot je door dat platformONafhankelijkheid alleen maar consessies kost? En dus nadelen? (want: wanneer je op platform A bepaalde functionaliteit niet levert (waar kennen we dat van? ) dan is 'platformonafhankelijkheid' daarmee automatisch dead). Wat essentieel is in frameworks van vandaag is dat ze 1) gemak leveren voor functionele communicatie tussen services op ieder ander platform en 2) de mogelijkheid hebben dat de API uitbreidbaar is met toekomstige functionaliteit zonder de API structuur aan te tasten. that's IT. wat voor stoffig OS er onder draait is helemaal niet interessant: je ziet het nl. nooit.

[mbravenboer]

Otis: Java op de serverside was de enige manier om op Unix op een gemakkelijke, OO manier n-tier apps te bouwen. Je alternatief was perl of C. Geen wonder dat veel mensen kozen voor Java op de server. Maar zeg eens, hoeveel platforms ondersteunen EXACT dezelfde java-api, met dezelfde performance?

Als je het nieuwste van het nieuwste wilt hebben, ben je afhankelijk van Sun. Het komt dan neer op Microsoft Windows, Solaris en Linux. Apple loopt iets achter met Mac OS X maar is behoorlijk goed bezig. IBM loopt ook altijd achter op Sun en de versies die ondersteunt worden varieren nogal al.

Het mooi is echter: stel je wilt Xerces of Xalan gebruiken. Op elke Java Platform waar Java enigszins bij de tijd is (1.2 of hoger) draaien Xerces en Xalan. Dat is het voordeel van Java: een complexe XML Schema validator werkt in 1 klap op alle platformen. Een XSLT processor werkt ook in 1 klap op alle platformen.

Is dat belangrijk? Nee. Want: wil je per se java programmeren? Dan neem je het platform waar java het beste op draait. Dan kies je dus geen Windows2000.

Mwah, andere figuren beweren juist weer dat andere platformen achterblijft op Microsoft Windows ports van de J2RE.

Linux interesseert me inderdaad echt geen reet. Dat komt omdat het applicatie-framework waar ik mee wil werken op windows2000 draait, dus waarom moet ik naar Linux kijken? Dat is EXACT het debiele van platformonafhankelijkheid en daar consessies voor doen. want dat moet je, bij platformonafhankelijkheid.

En als iemand nu een toolset gebaseerd op Unix of Linux heeft en eigenlijk ook gebruik wil maken van leuke XML stuff uit .NET of Java? Ga je dan je toolset maar weggooien? Nee: je wilt immers geen consessies doen. Maar ja: je wilt juist ook tools gebruiken die op andere platformen draaien. Is er een reden waarom een XSLT engine of XML Schema validator alleen op Microsoft Windows zou moeten werken? IMHO niet. Xerces of Xalan draaien op elke Java Platform. Waarom is de MSXML code niet beschikbaar voor alle platformen waarop de basisverzameling van .NET libraries draait?

Functionaliteitsdistributie

Waarom functionaliteit dirstribueren en spreken in termen van services als daar helemaal geen concrete reden voor is? Veel materiaal zoals bijvoorbeeld mijn running-example: XML Schema validators en XSLT engines hebben geen enkele band met een specifiek platform en kunnen dus gewoon platform onafahnkelijk geimplementeerd worden. Daar komt platform onafhankelijkheid tot z'n recht en dat zie je bijvoorbeeld terug in de vele fantastische XML gerelateerde producten die beschikbaar zijn voor het Java Platform.

Moet dat allemaal op 1 platform gebouwd worden? Nee natuurlijk niet. Dat interesseert niemand iets.

Nee, in het geval van een Oracle server interesseert inderdasd niemand dat iets en je zou ook wel een rund zijn als je dat allemaal percee op je eigen platform wilt draaien (alhoewel het voor ontwikkeling misschien makkelijk kan zijn). Voor karrevrachten andere producten is het echter wel mooi als je het gewoon op je eigen platform kan gebruiken. Extreme voorbeelden als een database server vormen wat mij betreft niet echt een bewijs van de onzin van platform onafhankelijkheid.

Mja, op windows gebruikt iedereen MSXML. Een java tool werkt daar niet mee. Tot zover je platformonafhankelijkheid.

Ja, waarom? Omdat MSXML onnodig platform specifiek is geimplementeerd en alleen op de voor dat platform gebruikte methoden benaderd kan worden. Is dat een bewijs dat de platform onafhankelijkheid irrelevant en onhandig is? Xerces en Xalan vind ik het bewijs dat platform onafhankelijhkheid wel interessant is.

Ik zit er overigens niet mee hoor: use the right tool for the job.

Exact: waarom je zou in vredesnaam je OS (ja: je OS) moeten bepalen welke XML library jij kunt gebruiken? Dat is echt een absoluut onzinnige beperking.

[mbravenboer]

Otis: heb de spot er maar mee, elk jaar worden er erg veel bakken met geld verkwist doordat men niet begrijpt dat platformonafhankelijkheid onnozel is en men eigenlijk ergens anders over zou moeten zemelen.

Ach, ik ben blij dat uwe grootheid me toch nog probeert te redden .

Dan installeer je windows2000, je stratego interpreter en .net. klaar ben je. Dat jij perse alle tools voor bv linux wilt is jouw probleem. Ik wil ook alle leuke gratis tools voor linux voor mijn win2k bak. Dat lukt ook niet altijd. Jammer dan, dan moet ik maar linux gebruiken.

Stratego kan juist niet beschaaft draaien onder Microsoft Windows omdat dit helaas ook platform specifiek is. Als Stratego ook onder Microsoft Windows zou draaien, zou mijn argument inderdaad onzinnig zijn: het is echter niet slechts voorliefde voor Linux oid, maar pure noodzaak. Stratego wordt overigens niet geinterpreteerd maar gecompileerd .

Ah, die laatste zin is precies de issue: jij wilt niet van je platform af (OS) en dus moeten alle frameworks maar naar dat platform toe. Platformonafhankelijkheid is DUS belangrijk want anders lukt dat niet! Nou, je had iets over argumenten, dit is, sorry, echt geen argument voor platformonafhankelijkheid.

Juist wel: ik heb tools die alleen op Linux/Mac OS X/Cygwin en Unix draaien (dat zijn trouwens heel veel operating systems ). Ik zie helaas dat er ontzettend veel tools onzinnig platform specifiek geimplementeerd worden terwijl dat prima op een platform onafhankelijk manier zou kunnen. MSXML is hiervan een uitstekende voorbeeld. Ik wil dat tools die met weinig moeite ook platform onafhankelijk geimplementeerd kunnen worden gewoon beschikbaar zijn op elke platform.

maar je kunt ook van platform wisselen, dan ben je sneller klaar.

Dat is waar en daar heb je ook zeker een punt. Daarom zit ik ook achter twee computers .

Webservices hoeven ook niet naar 'alle platforms'. Je kunt altijd een sucket openen en daar xml over duwen of binaire data voor mijn part.

Uiteraard, maar waarom zou je ze vastbinden op een bepaald platform als dat totaal geen enkele concrete reden heeft? Als idereen er in ieder geval voor zorgt dat tools die platform onafhankelijk kunnen zijn zonder consessies te hoeven doen, gewoon platform onafhankelijk geimplemeneteerd worden is er in deze wereld weer een probleem minder.

[mbravenboer]

Otis: Huh? Dringt het echt niet tot je door dat platformONafhankelijkheid alleen maar consessies kost?

Leg mij dan maar eens uit wat voor consessies gedaan zouden moeten worden als je een XML parser, XML Schema validator, een XSLT processor, een SOAP library, een XPath engine, een C# compiler, een database access API, een Corba implementatie, een XSL Formatter, een SVG viewer enz enz platform onafhankelijk zou moeten implementeren in plaats van platform specifiek? Ik zie geen zinvolle beperkingen. Dat is het mooie van Java: al deze producten zijn platform onafhankelijk geimplementeerd.

Deze tools vormen dus in ieder geval geen probleem bij beperkingen die een platform zou kunnen hebben

[Verwijderd]

Ik heb het genoegen gehad om tijdens GUADEC in Sevilla, Spanje dit jaar te luisteren naar Miguel d'Icanza van Ximian, hij is helemaal gek van C#/.NET. Hij hield een reclame-achtig maar informatievol praatje over hoe de implementatie van .NET classes in Ximian geschiedde en hoe de programma's gebaseerd op Mono/.Net eruit zouden zien.

Basically hebben ze een aantal standaard classes die je na kunt maken. Dit zijn standaard I/O classes etc. Deze zullen dus verschillend qua interne implementatie zijn op verschillende platforms, maar de interface is hetzelfde en dus de programma's ook. Denk hierbij aan de Java VM - java binaries runnen overal (zelfde interface), maar de VM is anders.

Okee, dat zijn alleen de standaard classes. Vanaf daar kom je in GUI classes terecht. Hier begon d'Icanza over de win32 GUI classes voor win32 en de gtk+ GUI classes voor (bv.) linux/Gtk+, Het gevolg is dus dat als iemand een GUI-applicatie cross-platform wil maken, hij twee mogelijkheden heeft: of het moet bestaan uit if (platform == win32) teken_win32_button(); else if (platform == mono) teken_gtk_button(); else ...
Een tweede mogelijkheid is dat een van de twee (goh, welke zou dat nou worden... ) de overhand krijgt en dat er voor Mono dus een soort 'win32/Gtk+ GUI class wrapper' komt. In dat geval krijgt een programma geschreven voor win32 dus onder mono gewoon een Gtk+ layout. Hetzelfde zou je voor Qt of andere TKs kunnen doen.
Uiteindelijk zullen de classes dus platform specifiek worden, maar omdat interfaces niet platformgebonden zijn kun je dus via wrappers hetzelfde breieken als wat je via java kan doen. De vraag is echter of alle classes zich hier even makkelijk voor lenen...

[Verwijderd]

Even de boel relativeren.

Otis, nog ff door en je krijgt een nominatie voor de ACA

Een groot argument voor platform-onafhankelijkheid: geld; en dat geldt zowel voor de gebruikers als de ontwikkelaars. De gebruiker bindt zich niet aan een leverancier (en dat is een flink argument als het over serverparks gaat) en kan toch zijn software blijven gebruiken. De ontwikkelaar zet ook niet alles op een paard, heeft een grotere potentiele markt, en als er eenmaal portable libraries zijn geschreven (QT is een mooi voorbeeld) kost het ontwikkelen van een applicatie niet langer dan voor een native API.

mbravenboer: Apache is geen bedrijf, maar een open-source collectief. Het feit dat die toch XML voor elkaar krijgen pleit dus voor Mono Apache (de webserver) is trouwens portable software, hetgeen zeker aan haar marktleiderspositie heeft bijgedragen.

[Alarmnummer]

Op maandag 24 juni 2002 18:47 schreef beelzebubu het volgende:
Okee, dat zijn alleen de standaard classes. Vanaf daar kom je in GUI classes terecht. Hier begon d'Icanza over de win32 GUI classes voor win32 en de gtk+ GUI classes voor (bv.) linux/Gtk+, Het gevolg is dus dat als iemand een GUI-applicatie cross-platform wil maken, hij twee mogelijkheden heeft: of het moet bestaan uit if (platform == win32) teken_win32_button(); else if (platform == mono) teken_gtk_button(); else ...
Een tweede mogelijkheid is dat een van de twee (goh, welke zou dat nou worden... ) de overhand krijgt en dat er voor Mono dus een soort 'win32/Gtk+ GUI class wrapper' komt. In dat geval krijgt een programma geschreven voor win32 dus onder mono gewoon een Gtk+ layout. Hetzelfde zou je voor Qt of andere TKs kunnen doen.
Uiteindelijk zullen de classes dus platform specifiek worden, maar omdat interfaces niet platformgebonden zijn kun je dus via wrappers hetzelfde breieken als wat je via java kan doen. De vraag is echter of alle classes zich hier even makkelijk voor lenen...

Dit doe je ook met SWT (en AWT). Dit zijn ook java wrappers om native componenten, zodat je als programmeur niet hoeft te weten voor welk platform je programmeerd, terwijl je wel gebruik kan maken van de snelle componenten en van het OS + je krijgt geen applicaties die erg opvallen omdat ze er anders uitzien, zoals Swing. Maar ik moet eerlijk zijn, Swing programmeer wel erg fijn.

[mbravenboer]

mietje: mbravenboer: Apache is geen bedrijf, maar een open-source collectief.

Uiteraard, ik had geen zin om ze een aparte status in het rijtje van 'groten' te geven .

Het feit dat die toch XML voor elkaar krijgen pleit dus voor Mono

Eigelijk niet denk ik: aan de Apache projecten (in ieder geval die van XML en Jakarta) werken toch voornamelijk werknemers van grote bedrijven die belang hebben bij een bepaald product. De XML producten zijn bijvoorbeeld stuk voor stuk afkomstig van grote bedrijven (IBM in het geval van Xerces, Lotus in het geval van Xalan, Apache SOAP komt ook van IBM) en de projecten zijn daar eigenlijk slechts gestalt om de continuiteit te waarborgen (dat is ook voornamelijk het doel van Apache: tools niet afhankelijk laten zijn van de inzet van 1 bedrijf).

Mono zie ik helaas toch meer als een centraal georganiseerd project wat niet erg breed ondersteunt wordt door andere bedrijven en die ook daadwerkelijk mensen inzetten om dit project grof te ondersteunen (ik kan me vergissen uiteraard). Alleen als dit gebeurt kan Mono een groot succes worden, voor nu is het gewoon 'leuk'.

[Verwijderd]

Op maandag 24 juni 2002 18:31 schreef mbravenboer het volgende:
[..]
Als je het nieuwste van het nieuwste wilt hebben, ben je afhankelijk van Sun. Het komt dan neer op Microsoft Windows, Solaris en Linux. Apple loopt iets achter met Mac OS X maar is behoorlijk goed bezig. IBM loopt ook altijd achter op Sun en de versies die ondersteunt worden varieren nogal al.

... en Sun's versies draaien het beste op Sun's Solaris middels bv native threads in de JVM.

Het mooi is echter: stel je wilt Xerces of Xalan gebruiken. Op elke Java Platform waar Java enigszins bij de tijd is (1.2 of hoger) draaien Xerces en Xalan. Dat is het voordeel van Java: een complexe XML Schema validator werkt in 1 klap op alle platformen. Een XSLT processor werkt ook in 1 klap op alle platformen.

Je denkt verkeerd om. Je moet niet denken 'ik wil Xerces gebruiken', je moet denken 'ik wil XSLT en XML gebruiken'. En dat die tools die jij noemt daar dan voor in aanmerking komen is leuk voor ze, maar wellicht zijn andere tools beter: als ik in VB een COM object bouw dat XML moet verwerken, heb ik dan IETS aan java-tools? Nee. Ik heb WEL iets aan een COM object dat dat voor mij doet. Ziedaar MSXML.

De objects in java zijn alleen leuk in java, ik heb er buiten java niet zoveel aan, ik heb dan altijd java nodig. Daarom zeg ik: functionaliteit is belangrijker.

Platformonafhankelijkheid is alleen nuttig, indien:
1) je om beheertechnische redenen kiest voor 1 platform
2) je een standalone tool wilt maken die moet draaien op zoveel mogelijk platforms en dat niet afkan met functionaliteit die je deelt.

Maar, dingen die java nodig hebben zijn dus niet nuttig buiten java, dus je argument snijdt niet echt hout en is alleen nuttig wanneer je in de TAAL java op veel platforms wilt programmeren, je kunt dan altijd dezelfde tools / 3rd party libraries gebruiken.

[..]
En als iemand nu een toolset gebaseerd op Unix of Linux heeft en eigenlijk ook gebruik wil maken van leuke XML stuff uit .NET of Java? Ga je dan je toolset maar weggooien? Nee: je wilt immers geen consessies doen. Maar ja: je wilt juist ook tools gebruiken die op andere platformen draaien. Is er een reden waarom een XSLT engine of XML Schema validator alleen op Microsoft Windows zou moeten werken? IMHO niet. Xerces of Xalan draaien op elke Java Platform. Waarom is de MSXML code niet beschikbaar voor alle platformen waarop de basisverzameling van .NET libraries draait?

Omdat het COM objects zijn. COM is alleen beschikbaar op een select aantal platforms. En in een COM oriented world heb je geen moer aan java-tools/libs/objects maar wel aan COM objects, OF je moet java gebruiken, maar misschien wil je dat wel niet. (ik iig niet)

[..]
Waarom functionaliteit dirstribueren en spreken in termen van services als daar helemaal geen concrete reden voor is?

Steeds meer applicaties worden ipv 2 lagen, meerdere lagen en die lagen worden op verschillende machines gehost. De reden daarvoor is veelal dat de verschillende lagen beter gemanaged kunnen worden op aparte machines en hergebruik makkelijker wordt.

Veel materiaal zoals bijvoorbeeld mijn running-example: XML Schema validators en XSLT engines hebben geen enkele band met een specifiek platform en kunnen dus gewoon platform onafahnkelijk geimplementeerd worden. Daar komt platform onafhankelijkheid tot z'n recht en dat zie je bijvoorbeeld terug in de vele fantastische XML gerelateerde producten die beschikbaar zijn voor het Java Platform.

huh? Sinds wanneer is een aan het java platform geklonken library platform onafhankelijk? Kan ik die zonder java in VB gebruiken? Nee. IEDERE implementatie van een zekere set functionaliteit legt grenzen op aan de toepassing van die implementatie. Of dat nu is de interface in de library zelf, de keuze welk binary object model of de keuze welk framework, er zijn altijd keuzes. Ook jouw voorbeeld is alleen binnen java 'platformonafhankelijk', maar dan wel zolang je java gebruikt.

[..]
Nee, in het geval van een Oracle server interesseert inderdasd niemand dat iets en je zou ook wel een rund zijn als je dat allemaal percee op je eigen platform wilt draaien (alhoewel het voor ontwikkeling misschien makkelijk kan zijn). Voor karrevrachten andere producten is het echter wel mooi als je het gewoon op je eigen platform kan gebruiken. Extreme voorbeelden als een database server vormen wat mij betreft niet echt een bewijs van de onzin van platform onafhankelijkheid.

juist in client-server applicaties is platformonafhankelijkheid altijd gepredikt en toont de huidige stand van de techniek aan dat het niet nodig is. Voor standalone tools (dus 1 executable met een paar schermpjes of commandline interface) is dat minder belangrijk, maar ook daar zul je zien dat functionaliteit nu makkelijker wordt gedeeld, want DAT is belangrijk: niet 20 tools met dezelfde lap code er in maar 1 keer een service met die code en 20 clients op die service.

[..]
Ja, waarom? Omdat MSXML onnodig platform specifiek is geimplementeerd en alleen op de voor dat platform gebruikte methoden benaderd kan worden. Is dat een bewijs dat de platform onafhankelijkheid irrelevant en onhandig is?

Nee, maar het toont aan dat 'platformonafhankelijk' bezig zijn met java op een ander platform waar java wel draait maar men BUITEN java ook nog dingen doet, niet belangrijk is. In de windowswereld gebruik je COM objects. Geen java object/class/jarfile, tenzij ik mn programmatuur in Java ga bouwen. Maar, op windows iets in java bouwen is onnodig, er zijn equivalenten die je op windows betere performance en functionaliteit bieden.

Daarom is jouw voorbeeld niet nuttig: je zit aan java vast. Dus geen platformonafhankelijkheid, tenzij je java gebruikt.

Xerces en Xalan vind ik het bewijs dat platform onafhankelijhkheid wel interessant is.

Alleen wanneer je java gebruikt. Ik gebruik geen java, maar C++, C# en VB6. Het is dan veel belangrijker dat MSXML er is en goed via com een hoge performance haalt dan dat ik met java een lib kan gebruiken die hetzelfde doet. Je platformonafhankelijkheid houdt dan dus op.

[..]
Exact: waarom je zou in vredesnaam je OS (ja: je OS) moeten bepalen welke XML library jij kunt gebruiken? Dat is echt een absoluut onzinnige beperking.

Dat doe jij ook: door java te kiezen zit je aan java vast voor al je code. Of kun je tegenwoordig in java alweer com objects bouwen?

Als ik op windows voor een java oplossing zou kiezen, ga ik dus voorbij aan MSXML met een betere performance op windows. Waarom zou ik dat doen, als mn programmatuur toch op windows draait en via een webservice communiceert met andere services?

[Verwijderd]

Op maandag 24 juni 2002 18:24 schreef Otis het volgende:
Huh? Dringt het echt niet tot je door dat platformONafhankelijkheid alleen maar consessies kost? En dus nadelen? (want: wanneer je op platform A bepaalde functionaliteit niet levert (waar kennen we dat van? ) dan is 'platformonafhankelijkheid' daarmee automatisch dead).

Als je op die manier redeneert dan is elke vorm van general API maken uberahupt bij voorbaar kansloos. Laten we even naar de videokaarten kijken die XFree86 support. De ene kan wel 3D, de andere niet. Betekent dat dat we geen generic API voor 3D kunnen maken? Tuurlijk wel! Maar je moet du zorgen dat er de mogelijkheid tot software-rendering is als de kaart die functie niet biedt of dat de functie niet wordt vrijgegeven.

Pseudocode:

code:

interface.h:

struct x_card_interface
{
  void * draw_normal_button (struct position pos);
  void * draw_3d_button     (struct position pos);
};

simple_card_driver.c:
--

static void
draw_button (struct position pos)
{
  ..
}

void
init (struct x_card_interface *if)
{
  if->draw_normal_button = draw_button;
}

advanced_card_driver.c:
--

static void
draw_3d_button (struct position pos)
{
  ..
}

static void
draw_button (struct position pos)
{
  ..
}

void
init (struct x_card_interface *if)
{
  if->draw_normal_button = draw_button;
  if->draw_3d_button = draw_3d_button;
}

interface.c:
--
static struct x_card_interface if;
static void *dl;

void
init_card_driver (const char *drivername)
{
  DL_info info;
  char buff[256];
  sprintf(buff, "/usr/X11R6/lib/drivers/lib%s.so", drivername);
  dl = dlopen(buff, RTLD_LAZY);
  dladdr(dlsym(dl, "init"), &info);
  memset(&if, 0, sizeof(struct x_card_interface));
  info.dli_saddr(&if);
}

void
exit_card_driver (void)
{
  dlcose(dl);
}

static void
draw_generic_button (struct position pos)
{
  ..
}

void
draw_button (struct position pos)
{
  if (if.draw_standard_button)
    if.draw_standard_button(pos);
  else
    draw_generic_button(pos);
}

static void
draw_generic_3d_button (struct position pos)
{
  ..
}

void
draw_3d_button (struct position pos)
{
  if (if.draw_3d_button)
    if.draw_3d_button(pos);
  else
    draw_generic_3d_button(pos);
}

Simpel toch? Platformonafhankelijkheid werkt exact hetzelfde.

[Verwijderd]

Op maandag 24 juni 2002 18:58 schreef mbravenboer het volgende:
Mono zie ik helaas toch meer als een centraal georganiseerd project wat niet erg breed ondersteunt wordt door andere bedrijven en die ook daadwerkelijk mensen inzetten om dit project grof te ondersteunen (ik kan me vergissen uiteraard). Alleen als dit gebeurt kan Mono een groot succes worden, voor nu is het gewoon 'leuk'.

Dat ligt er helemaal aan of er veel programmer-power achter Mono komt of niet, idd. Hierover voorspellingen doen is koffiedik kijken; aan de ene kant wordt er in (bepaalde) linux-kringen nu voor het eerst serieus gesproken over het "veroveren van de desktop" in de komende jaren, en dat zou een enorme boost geven aan Gnome/Mono. Anderzijds kan MS het de Mono-ontwikkelaars ontzettend moeilijk maken met de IP-wetgeving en het patentrecht zoals die nu in de VS heersen.

[Verwijderd]

Op maandag 24 juni 2002 18:45 schreef mbravenboer het volgende:
[..]
Leg mij dan maar eens uit wat voor consessies gedaan zouden moeten worden als je een XML parser, XML Schema validator, een XSLT processor, een SOAP library, een XPath engine, een C# compiler, een database access API, een Corba implementatie, een XSL Formatter, een SVG viewer enz enz platform onafhankelijk zou moeten implementeren in plaats van platform specifiek? Ik zie geen zinvolle beperkingen. Dat is het mooie van Java: al deze producten zijn platform onafhankelijk geimplementeerd.

Nee, ze zitten aan java vast. Ik werk buiten java om, ik heb er dus geen reet aan. Ik mis het ook niet hoor: op windows heb je veelal equivalenten genoeg, mocht het uberhaupt nodig zijn. JAVA is wel platformonafhankelijk (OS-onafhankelijk), maar door java te kiezen als platform, zit je daar wel weer aan vast. Gebruik je de taal java niet, zit je met de gebakken peren. Ergo: lost niets op.

Op windows zijn veel libraries tegenwoordig COM objects en steeds meer krijgen ze nu een .NET equivalent (al is dat niet nodig, COM is goed te gebruiken in .NET). Is het dan DOM dat een library kiest voor COM? Nee natuurlijk niet. Immers, dat is de library-structuur keuze van windows en zo kunnen erg veel talen/compilers op windows dezelfde library gebruiken.

Dat op unix men op het java-framework daar totaal niets mee kan, tja, lekker belangrijk. Ik kan in een COM framework ook geenmoer met java-objects. Lekker belangrijk. (jaja, via bridges/andere overhead wel).

Maar goed, men snapt het niet, het zij zo. Men vergeet wel dat platformonafhankelijkheid steeds minder en minder wordt gepredikt en dat is niet voor niks. Geld is allang niet meer een issue, want de organisatie waar 1 team zit dat maar 1 taal kan en 1 api en de beheerder maar 1 OS, is allang vervangen door een organisatie waar 1 of meerdere teams zitten met kennis van meerdere api's / platformen en er beheerders zijn die meerdere platforms onderhouden.

[Verwijderd]

Op maandag 24 juni 2002 19:10 schreef beelzebubu het volgende:
[..]
Als je op die manier redeneert dan is elke vorm van general API maken uberahupt bij voorbaar kansloos. Laten we even naar de videokaarten kijken die XFree86 support. De ene kan wel 3D, de andere niet. Betekent dat dat we geen generic API voor 3D kunnen maken? Tuurlijk wel! Maar je moet du zorgen dat er de mogelijkheid tot software-rendering is als de kaart die functie niet biedt of dat de functie niet wordt vrijgegeven.

Ja, zoiets kennen we al jaren in OpenGL en D3D/Dx. Dat is het punt ook helemaal niet. Het punt is dat software rendering niet acceptabel is wanneer je pixel shaders 1.2 wilt gebruiken en je een Geforce2 hebt. Dan heb je geen moer aan je software rendering, want Doom 3 zal lopen als dikke stront in een trechter

/me , die wel eens iets deed in OpenGL en weet dat ook dat niet platformonafhankelijk is. (in tegendeel)

[Verwijderd]

Op maandag 24 juni 2002 19:19 schreef Otis het volgende:
Ja, zoiets kennen we al jaren in OpenGL en D3D/Dx. Dat is het punt ook helemaal niet. Het punt is dat software rendering niet acceptabel is wanneer je pixel shaders 1.2 wilt gebruiken en je een Geforce2 hebt.

Dan zit je alweer drie stappen verder - performance. Je bent het toch met me eens dat je op zo'n manier om limitaties van bepaalde platformen/OS'en kan werken? Dat was mijn punt.

[mbravenboer]

Otis: Nee, ze zitten aan java vast. Ik werk buiten java om, ik heb er dus geen reet aan.

Inderdaad, dat is ook een zeker een gebrek in de huidige virtual machines. Ik denk dat het beter mogelijk moet zijn om vanuit je platform specifieke omgeving code in de virtual machien te gebruiken en dat is absoluut niet goed voor elkaar bij Java (wel mogelijk, maar ja: alles is mogelijk).

Geld is allang niet meer een issue

In het geval van complexe libraries is een platform onafhankelijk codebase denk ik toch wel een financieel aantrekkelijk iets. Xerces2 kan op elk platform ingezet worden en er zijn geen meerdere codebases nodig voor een organisatie die vast zit aan meerdere platformen. Als Xerces2 uit verschillende codebases zou bestaan voor de verschillende platformen zou het dit veel lastiger te onderhouden, debuggen, en upgraden zijn.

Platform-onafhankelijkheid is pas financieel minder aantrekkelijk als er extra financiele belemmeringen uit voortkomen, wat helaas nog wel het geval is: Xerces zit bijvoorbeeld min of meer opgesloten in de JVM.

[Verwijderd]

Op maandag 24 juni 2002 19:21 schreef beelzebubu het volgende:

[..]

Dan zit je alweer drie stappen verder - performance. Je bent het toch met me eens dat je op zo'n manier om limitaties van bepaalde platformen/OS'en kan werken? Dat was mijn punt.

Ja dat zei ik toch: consessies doen, in jouw voorbeeld door een software renderer te plaatsen. Echter, is dat acceptabel? in veel gevallen niet. Je zou dan eerder kiezen voor (om in jouw voorbeeld te blijven) het gebruik van bv de network rendering capaciteit van OpenGL om rendercalls die hw nodig hebben die je niet aantreft op je host, uit te besteden aan hardware die het wel aankan. Zodoende gebruik je services die je ter beschikking hebt beter, zonder concessies te doen.

[mbravenboer]

Otis: ... en Sun's versies draaien het beste op Sun's Solaris middels bv native threads in de JVM.

Mwah, dat valt allemaal best mee. De JVM voor Solaris buit specifieke Solaris functionaliteit uit, maar de Linux JVM gebruikt tegenwoordig ook native thread via de pthread library die standaard weer direct kernel threads gebruikt.

Je moet denken 'ik wil XSLT en XML gebruiken'.

Ja duh, ik ben echt wel weer zo briljant dat ik weet dat m'n XSL transformatie wel in meerdere XSLT engines gebruikt kan worden. Dat ik hiervoor de termen Xerces en Xalan gebruikt komt meer omdat deze twee min of meer een monopolie positie in de Java wereld hebben. Dat er maar 1 goede XML Schema implementatie is, is niet zo verwonderlijk overigens . Het fraaie van deze libraries is in ieder geval dat ik in mijn keuze voor een library niet beperkt wordt door het OS waarop ik deze wil gebruiken: imho is dat irrelevant voor een XSLT engine of XML Schema validator.

als ik in VB een COM object bouw dat XML moet verwerken, heb ik dan IETS aan java-tools? Nee. Ik heb WEL iets aan een COM object dat dat voor mij doet. Ziedaar MSXML.

Juist en zouden we nu niet eigenlijk gewoon willen dat je alle libraries overal prettig in kunt gebruiken? Helaas biedt niets daar nog een goede oplossing voor: COM niet, Java niet, .NET niet. Het mooie van de Java en .NET oplossing is in ieder geval wel dat de library op elk platform kan draaien.

Steeds meer applicaties worden ipv 2 lagen, meerdere lagen en die lagen worden op verschillende machines gehost. De reden daarvoor is veelal dat de verschillende lagen beter gemanaged kunnen worden op aparte machines en hergebruik makkelijker wordt.

Ik heb het niet over informatie-systemen, enterprise oplossingen, 2-tier, client-server applicaties of hoe je ze ook wilt noemen.

Ik heb het over libraries die je op een bepaald platform wilt gebruiken vanuit een applicatie: XML parser, XML Schema validator, XSLT engine. Ik ga geen XSLT engine op een andere machine draaien en die via een service aanroepen .

Dat doe jij ook: door java te kiezen zit je aan java vast voor al je code. Of kun je tegenwoordig in java alweer com objects bouwen?

Dat kan inderdaad, wat maar weet aantoont dat daar geen aanpassingen van de taal Java voor nodig waren....

http://developer.java.sun.com/developer/earlyAccess/j2eecas/download-com-bridge.html
http://developer.java.sun.com/developer/earlyAccess/j2eecas/doc/index.html
http://java.sun.com/products/javabeans/software/bridge/

Als ik op windows voor een java oplossing zou kiezen, ga ik dus voorbij aan MSXML met een betere performance op windows.

Waarom zou MSXML een betere performance opleveren dan Xerces? Stel dat Xerces in C# was geimplementeerd en in .NET te gebruiken was. Was Xerces dan een serieus alternatief geweest voor MSXML als je bijvoorbeeld XML Schema validatie nodig hebt?

[Verwijderd]

Op maandag 24 juni 2002 19:57 schreef mbravenboer het volgende:
[..]
Ja duh, ik ben echt wel weer zo briljant dat ik weet dat m'n XSL transformatie wel in meerdere XSLT engines gebruikt kan worden. Dat ik hiervoor de termen Xerces en Xalan gebruikt komt meer omdat deze twee min of meer een monopolie positie in de Java wereld hebben. Dat er maar 1 goede XML Schema implementatie is, is niet zo verwonderlijk overigens . Het fraaie van deze libraries is in ieder geval dat ik in mijn keuze voor een library niet beperkt wordt door het OS waarop ik deze wil gebruiken: imho is dat irrelevant voor een XSLT engine of XML Schema validator.

Maar, je moet dan wel java gebruiken of ermee werken. Een XSLT engine staat niet op zichzelf, die gebruik je ergens in. Op windows wil je dan een COM object of als je een .net app bouwt, een .net lib. Jij zegt: je kiest voor een lib en dan is het mooi dat het op een os draait waar je toevallig mee moet werken. Mja, ik kies dan voor een andere lib als dat os toevallig mijn lib in kwestie niet draait. Zo specifiek zijn de meeste libs niet, in tegendeel. Ja sommige software wel, maar het gros gebruikt die niet.

[..]
Juist en zouden we nu niet eigenlijk gewoon willen dat je alle libraries overal prettig in kunt gebruiken? Helaas biedt niets daar nog een goede oplossing voor: COM niet, Java niet, .NET niet. Het mooie van de Java en .NET oplossing is in ieder geval wel dat de library op elk platform kan draaien.

Je kunt toch ook je library, mocht je dat perse willen, in een service encapsulaten, op de doos draaien waar het op wil draaien en remote er gebruik van maken, mocht dat per se de enige oplossing zijn? Natuurlijk zou het prettig zijn als iedere library overal gebruikt zou kunnen worden. Echter dat is niet zo, en dat zal ook niet zo worden. Maar nogmaals: hoeveel libraries worden door veel developers gebruikt en zijn erg platform specifiek zodanig dat het erg nadelig is? m.i. erg weinig, iig weinig waarbij het nadelig is. Voorbeeld: op win32 is het bv een voordeel dat MSXML een com library is.

[..]
Ik heb het niet over informatie-systemen, enterprise oplossingen, 2-tier, client-server applicaties of hoe je ze ook wilt noemen.

Ik heb het over libraries die je op een bepaald platform wilt gebruiken vanuit een applicatie: XML parser, XML Schema validator, XSLT engine. Ik ga geen XSLT engine op een andere machine draaien en die via een service aanroepen .

Nee, je hebt het over functionaliteit, niet over 'libraries' want, dan zit je naast het platform ook nog vast aan binaire formats zoals COFF.

[..]
Dat kan inderdaad, wat maar weet aantoont dat daar geen aanpassingen van de taal Java voor nodig waren....

Alleen de 3e url kan ik bekijken zonder registratie, en dat is een bridge. Dit valt imho in de categorie: consessies die je niet wilt doen. Nog een consessie die je niet wilt uit dezelfde categorie: COM+ services in .NET

[..]
Waarom zou MSXML een betere performance opleveren dan Xerces? Stel dat Xerces in C# was geimplementeerd en in .NET te gebruiken was. Was Xerces dan een serieus alternatief geweest voor MSXML als je bijvoorbeeld XML Schema validatie nodig hebt?

Zit XML schema validatie niet in MSXML? MSXML is handig voor COM oriented omgevingen, dus veel talen op windows. Als xerces een .net equivalent krijgt is het wellicht een alternatief voor System.Xml. Niet voor MSXML, tenzij Xerces een COM alternatief krijgt. Immers: vanuit VC++ of Delphi of VB6 een .NET component of een java component aanroepen is niet echt efficient, wanneer je een alternatief hebt dat dat wel is.

Leef je BINNEN java, dan is er geen vuiltje aan de lucht, immers, alles is java. Leef je binnen .NET, dan is er ook geen vuiltje aan de lucht, alles is .NET: waar het framework op draait, daar draait je programmatuur. Wil je communiceren met functionaliteit buiten dat framework, dan zit je al snel vast aan de gangbare inter-process communicatie, en daarbij maakt het niet zoveel verschil of dat nu op dezelfde machine plaatsvindt of tussen machines. Dit laatste ondergraaft het nut van platformonafhankelijkheid.

[mbravenboer]

Otis: Alleen de 3e url kan ik bekijken zonder registratie

Klopt: Sun support het niet echt fanatiek en hierdoor is het nog steeds early-access. Persoonlijk boeit het me niet en ik heb het nog nooit gebruikt, maar ik kan me voorstellen dat veel mensen eigenlijk eens beschaafd met COM willen werken vanuit Java.

Leef je BINNEN java, dan is er geen vuiltje aan de lucht, immers, alles is java. Leef je binnen .NET, dan is er ook geen vuiltje aan de lucht, alles is .NET: waar het framework op draait, daar draait je programmatuur. Wil je communiceren met functionaliteit buiten dat framework, dan zit je al snel vast aan de gangbare inter-process communicatie, en daarbij maakt het niet zoveel verschil of dat nu op dezelfde machine plaatsvindt of tussen machines. Dit laatste ondergraaft het nut van platformonafhankelijkheid.

Tja, dat is helaas nog steeds een waarheid als een koe. Ik kan je hierin dus absoluut geen ongelijk geven. Zoals ik al eerder zei zo het mogelijk moeten zijn om beter met een Java Runtime te kunnen samenwerken. Je ziet wel enkele native interface gerelateerde intiatieven naast JNI, maar prettig is toch duidelijk anders.

Ik zag trouwens dat Rotor ook System.Xml bevat met C# source code voor XSLT, XML Schema, XPath en dergelijke. Dat wist ik eerlijk gezegd niet (en had ik verwacht) en daar was ik toch wel blij verrast door (ondanks dat je er weinig mee mag ).

Ik vind het jammer dat deze codebase (die tot mijn vreugde dus in elke .NET omgeving zou moeten kunnen draaien omdat er geen native functionaliteit wordt gebruikt, behalve via .NET zelf) niet gebruikt mag worden in projecten als Mono...

[mbravenboer]

Nog even voor de topic-starter:

Na aan het denken te zijn gezet door Otis kwam ik tot de gedachte dat er een subtiele fout in je vraagstelling zit die eigenlijk voor de hele discussie heeft gezorgd.

Het is niet de vraag of .NET platform onafhankelijk is, maar je moet je afvragen in hoeverre .NET goed geport kan worden naar andere platformen. Dit is een klein, maar toch wel belangrijke aanpassing van de vraag, waar je eigenlijk veel beter over kunt praten. Zoals je uit de posts van Otis kunt afleiden is platform onafhankelijkheid een vage term.

Als je dus de nieuwe vraag wilt gaan behandelen kan je verschillende punten onderscheiden:

1) Is .NET IL te compileren naar andere processor architecturen?
2) Is interpretatie van IL mogelijk als compilatie niet haalbaar is voor een platform?

Dat is eigenlijk het enige technische issues. Daarnaast zijn er een heleboel praktische issues:

3) In hoeverre zijn .NET libraries zo erg op Microsoft Windows libraries gebaseerd dat het onacceptabel veel werk zou zijn om deze te implementeren voor andere platformen?

4) In hoeverre kan je gebruik maken van platform onafhankelijke naar IL compileerbare codebases om de hoeveelheid werk te beperken en waarschijnlijke grotere compatibliteit te beiden?

Er zijn vast nog meer punten, maar dit is toch wel de kern van de zaak.

[mbravenboer]

Merk trouwens wel op dat dat in feite alleen een andere naam voor hetzelfde beestje is: met de platform-onafhankelijkheids discussie werd uiteraard dit bedoeld.

Omdat de term echter vaag is, is het beter andere termen te gebruiken. M'n mening is dus ook zeker niet bijgesteld, maar ik heb nu denk ik wel wat meer inzicht in hoe je de term 'platform-onafhankelijkheid' eigenlijk moet gebruiken .

[Jrz]

Valt me op dat veel mensen er geen koe van gegeten hebben, allemaal mensen die slechts herhalen wat anderen zeggen. Net als wat er met linux is gebeurd. Maargoed.

In java kan je makkelijk COM componenten gebruiken, heel makkelijk. ALS je dat zou willen iig.

SWT is een mooie API voor guis, lekker snel, goed te programmeren.

Dat Java de enige taal voor Java VM is, is gewoon onzin. Maarja.. Sun legt daar de nadruk niet op, want als je even nadenkt is 1 taal veel beter te begrijpen, en taal onafhankelijkheid is inherent aan VM.

[Alarmnummer]

Ik ben het niet met je eens dat een taal goed is. Het is misschien handig om 1 soort imperatieve taal aan te houden, maar er zijn ook andere, bv functione talen. Sommige problemen kan je daarin netter uitdrukken dan in Java, maar aangezien een volledige applicatie maken in een functionele taal niet echt handig is, wordt er op dit moment gekozen voor een volledig imperatieve aanpak. Het is jammer dat er nog geen bruikbare functionele taal is voor de vm van java (er is een project gaande bij haskell waarmee ze wel naar bytecode willen compileren, maar dit is nog niet klaar).

[mbravenboer]

Jrz: In java kan je makkelijk COM componenten gebruiken, heel makkelijk. ALS je dat zou willen iig.

Nou nou, 'heel makkelijk' vind ik toch wel wat sterk uitgedrukt...

SWT is een mooie API voor guis, lekker snel, goed te programmeren.

* mbravenboer zoekt de relatie tussen SWT en dit topic

Dat Java de enige taal voor Java VM is, is gewoon onzin.

Java is wel de enige taal voor de Java Virtual Machine (ja, ik ken die pagina met alle andere talen). Wat ik bedoel ik hiermee? Java Bytecode (weleens bekeken?) is equivalent aan gewone Java code. In Java Bytecode kan je niets meer en niets minder. Ik zie Java Bytecode daarom ook min of meer als getype-checkte Java.

Als je een andere taal op de Java Virtual Machine wilt targetten (waar ik mee bezig ben) komt dit neer op het transformeren van je taal naar Java code. Je kunt ook best direct naar Java Bytecode compileren, maar dat voegt niets toe: Je moet alleen maar meer werk doen zoals bijvoorbeeld het aangeven van het aantal lokale variabelen in een stack-frame.

Het is flauw om te zeggen dat de JVM meer dan alleen Java aankan (en zeker om te zeggen dat het onzin is als iemand beweerd dat dit zo is). De JVM kan absoluut niet meer talen aan dan Java, maar je kunt talen wel vertalen in Java. Dat is wat alle compilers voor taal X op de bekende pagina doen.

Overigens is het dan nog wel boeiend om even de link met .NET te leggen (alhoewel we dan weer op een gevaarlijk topic komen ).

.NET kan niet meer aan dan IL. IL is de enige taal die op .NET uitgevoerd kan worden. C# is een taal die erg dicht bij IL ligt, maar wel wat suiker bevat, die de C# compiler eruit haalt bij compilatie naar IL. C# en IL hebben zoveel van elkaar weg dat het niet helemaal idioot is om te stellen dat compilatie naar .NET IL in feite gezien kan worden als compilatie naar C#.... Dit geldt voor meer afwijkende talen als SML .NET en Eiffel .NET, maar ook voor VB .NET.

want als je even nadenkt is 1 taal veel beter te begrijpen

Je kunt er erg lang over discussieren of managed C++ en VB .NET zinvol zijn naast C#, maar verdere abstracties zijn in ieder geval zinvol: funtionele talen bijvoorbeeld.

en taal onafhankelijkheid is inherent aan VM.

Sorry, maar dat is echt onzin: een VM accepteert code geschreven met een bepaalde instructie-set. Voor de JVM is dit Java Bytecode en voor .NET CLR is dit .NET IL. Voor een Inter processor is dit IA32 en voor een MIPS processor is dit MIPS assemlby.

Dat je talen kunt vertalen naar deze instructie-set betekent niet dat deze VM ook gelijk deze taal accepteert of taal-onafhankelijk is. Een Intel Pentium processor kan natuurlijk geen C, C++ of Pascal uitvoeren. De compiler compileert een taal naar de instructie-set van een processor en ditzelfde kan je ook doen bij een virtual machine.

Het punt bij .NET en het Java Platform is juist dat deze instructie-set een beetje vreemd is: het is gebaseerd op een OO systeem met garbage-collection.

[mbravenboer]

Jrz: ik begrijp overigens prima wat je bedoelde met je opmerkingen, maar je verklaarde zoveel uitspraken van mensen als 'onzin' dat ik het niet kon laten jou ook ff op de vorm te pakken .

[Alarmnummer]

Maar jij bent/gaat ook aan de source code generatie? Misschien kunnen we samen dan een paar utilitie classes maken?

[Verwijderd]

Op maandag 24 juni 2002 21:29 schreef mbravenboer het volgende:
Nog even voor de topic-starter:

...nuttig verhaal...

Dank je wel
Maar ook de hele discussie heb ik met plezier gelezen hoor.
Ik heb weer het een en ander opgestoken vandaag.

Wel nog even een vraagje over je 2e post. Waar kan ik bij Microsoft vinden wat de veranderingen zullen zijn bij de volgende versie .NET/C#? Ik heb gekeken, maar kan het zo snel niet vinden.

[mbravenboer]

Alarmnummer: Maar jij bent/gaat ook aan de source code generatie? Misschien kunnen we samen dan een paar utilitie classes maken?

Ik ben bang dat je mijn tools te OS-beperkend vindt . Mijn afstudeerpoject is weer eens van onderwerp veranderd en ik ga me nu vooral bezighouden met het code generatie en het embedden van talen. Voorbeelden zijn: SQL embedding in Java, XML embedding in Java, generatie van Java code met concrete syntax (Stratego compiler is daar een onderdeel van), refactoring met concrete syntax en herschrijf strategien enzovoorts.

Eigenlijk dus al mijn favoriete onderwerpen op 1 hoop . Op dit moment ben ik bezig met een degelijke SDF gramamtica voor Java in diverse varianten (normale Java, Java + Javadoc, Java Generics) waardoor ik ook echt met concrete syntax kan gaan werken in bijvoorbeeld Stratego applicaties.

Als je wilt samenwerken of code wilt gebruiken vind ik dat een prima plan, maar je begrijpt vast wel dat ik geen transformaties in Java ga zitten programmeren .

_{Zullen we het hier maar op Javahova over hebben?}

[Alarmnummer]

dat lijkt me een heel wijs plan

[mbravenboer]

elefino: Waar kan ik bij Microsoft vinden wat de veranderingen zullen zijn bij de volgende versie .NET/C#?

Zie deze website:

http://research.microsoft.com/projects/clrgen/

Generics staan beschreven in dit artikel:

http://research.microsoft.com/projects/clrgen/generics.pdf

en deze presentatie:

http://www.acm.org/sigs/sigplan/pldi/pldi2001/pldi01-presentations/DonSyme.pdf

Dit vind je misschien ook nog wel leuk:
[topic=462298/1/25]

Je kan eventueel ook nu al de Java Generics compiler gebruiken als je dat wilt.

[Verwijderd]

Op maandag 24 juni 2002 21:57 schreef Jrz het volgende:
Valt me op dat veel mensen er geen koe van gegeten hebben, allemaal mensen die slechts herhalen wat anderen zeggen. Net als wat er met linux is gebeurd. Maargoed.

Says who? Ik weet donders goed waar het over gaat, al jaren.

In java kan je makkelijk COM componenten gebruiken, heel makkelijk. ALS je dat zou willen iig.

Lijkt me onzin. Tuurlijk kun je via tussenlayers com objects gebruiken, net zoals je via tussenlayers java beans kunt gebruiken in COM omgevingen. Lijkt me niet de juiste weg.

SWT is een mooie API voor guis, lekker snel, goed te programmeren.

Ziet een SWT app er uit als een native app? Is het dan een goede gui layer?

Dat Java de enige taal voor Java VM is, is gewoon onzin.

Gaap. No offence, maar iedereen met 1 les vertalerbouw weet dat voor de java VM je veel compilers kunt bouwen voor veel talen. Dat was ook niet het punt. (Er zijn overigens nauwelijks andere compilers voor de java vm)

Maarja.. Sun legt daar de nadruk niet op, want als je even nadenkt is 1 taal veel beter te begrijpen, en taal onafhankelijkheid is inherent aan VM.

1 taal maar? Sinds wanneer is 1 taal genoeg voor alles? Lijkt me toch niet. Taalonafhankelijkheid zie ik niet als een feature van een VM alleen, maar is het kenmerk van iedere verwerkingsunit, virtual of physical.

Kunnen we nu weer over tot de discussie ipv het werpen van holle frazen? bedankt.

[Verwijderd]

Op maandag 24 juni 2002 21:29 schreef mbravenboer het volgende:
Nog even voor de topic-starter:

Het is niet de vraag of .NET platform onafhankelijk is, maar je moet je afvragen in hoeverre .NET goed geport kan worden naar andere platformen. Dit is een klein, maar toch wel belangrijke aanpassing van de vraag, waar je eigenlijk veel beter over kunt praten. Zoals je uit de posts van Otis kunt afleiden is platform onafhankelijkheid een vage term.
Als je dus de nieuwe vraag wilt gaan behandelen kan je verschillende punten onderscheiden:

1) Is .NET IL te compileren naar andere processor architecturen?

Dit lijkt me een no-brainer: ja. Omdat IL nu al voor x86 wordt gecompileerd, immers bij de 1e run compileert de CLR naar native code.

2) Is interpretatie van IL mogelijk als compilatie niet haalbaar is voor een platform?

Dat doet de CLR nu al voor je, dus ook ja. (maar wellicht niet acceptabel, en daardoor niet nuttig)

Dat is eigenlijk het enige technische issues. Daarnaast zijn er een heleboel praktische issues:
3) In hoeverre zijn .NET libraries zo erg op Microsoft Windows libraries gebaseerd dat het onacceptabel veel werk zou zijn om deze te implementeren voor andere platformen?

Rotor laat zien dat je een platform mee moet porten voor .net. Dit is gedaan voor Rotor maar daarnaast heb je dan natuurlijk de win32 afhankelijkheid, daar ontkom je niet aan, zeker bij zaken als ASP.NET, ADO.NET en winforms.

4) In hoeverre kan je gebruik maken van platform onafhankelijke naar IL compileerbare codebases om de hoeveelheid werk te beperken en waarschijnlijke grotere compatibliteit te beiden?

Ik denk heel veel. Rotor laat nu al zien dat een groot deel van de API gewoon .NET code is. Het is natuurlijk wel erg naief om te denken dat key-namespaces waar erg veel gebruik van gemaakt gaat worden, zoals System.Data.*, totaal in C# zijn geschreven, gezien het feit dat deze library erg snel moet performen. Het zou wel interessant zijn om de GaC libs zoals System.Data.dll eens door ildasm te halen en te kijken in hoeverre ze .NET code zijn en waar de calls afbuigen naar interne calls. (of beter: of System.Data.Dll werkt icm de rotor C# compiler ).

[mbravenboer]

Het is off-topic maar dit is toch wel boeiend:

Otis: Ziet een SWT app er uit als een native app? Is het dan een goede gui layer?

SWT ziet er inderdaad uit als een native app. Sterker nog: het is native. SWT is de nieuwe GUI library van IBM die onstaan is omdat ze vonden dat ze geen beschaafde library hadden om Eclipse een goede GUI te geven.

SWT is een soort middenweg tussen AWT en Swing: in principe worden native componenten gebruikt (rijke verzameling, niet zoals in AWT), maar als dit echt niet mogelijk is kan het getekend worden. Nadeel hiervan is wel dat het per OS aardig wat native werk vereist. Voordeel is dat het echt responsief is en er gewoon uitziet zoals de rest van de applicaties.

Verder is SWT ook opgebouwd uit twee lagen: een normale niet model gebaseerde library en JFace, die wel met modellen werkt. Swing dit doet in 1 keer: het is niet mogelijk om zonder modellen te werken. JFace zit qua design erg yummie in elkaar (heb er niet erg veel van gezien nog), maar dat is niet gek als Erich Gamma eraan mee werkt .

[mbravenboer]

Otis: Dit lijkt me een no-brainer

Hum ja, het was ook niet echt bedoeld als vraag om te beantwoorden .

Ik denk heel veel. Rotor laat nu al zien dat een groot deel van de API gewoon .NET code is.

Yepz (Ik was echt blij met System.Xml in Rotor ), probleem is alleen dat die niet gebruikt mogen worden in een serieuze port .

Het is dus wel mogelijk en het is te hopen dat de pogingen om een serieuze port te maken een beetje gecoordineerd worden en er uitwisseling van succesvolle implementaties kan plaatsvinden. Als er veel van de libraries in C# wordt geimpelementeerd en dit onder een soepele licentie beschikbaar komt, is het eigenlijk een koud kunstje om ports naar andere platformen te maken (laten we WinForms maar even laten voor wat het is).

[Alarmnummer]

Ik heb eerlijk gezegd de indruk dat IBM wil dat SWT alleen maar gebruikt wordt voor Eclipse want je kan bv niet een losse SWT jar downen en ze zijn ook niet echt vriendelijk met het verstrekken van informatie. Maar als zo`n grote naam als Erich Gemma er aan mee werkt dan willen ze het wel voor een groter publiek beschikbaar stellen ?(lees gui proggers die totaal niet geintereseerd zijn in Eclipse (zoals ik dus)).

[mbravenboer]

Alarmnummer: Ik heb eerlijk gezegd de indruk dat IBM wil dat SWT alleen maar gebruikt wordt voor Eclipse want je kan bv niet een losse SWT jar downen en ze zijn ook niet echt vriendelijk met het verstrekken van informatie.

Ja, daar baal ik van .

Maar als zo`n grote naam als Erich Gamma er aan mee werkt dan willen ze het wel voor een groter publiek beschikbaar stellen ?

Misschien dat ze eerst meer ports willen maken of bang zijn voor de toorn van Sun . SWT zorgt er natuurlijk niet voor dat Sun IBM lief gaat vinden en die relatie is toch ook wel belangrijk.

Ik zou zeggen vervang de A in AWT door een S .

[Verwijderd]

Op maandag 24 juni 2002 21:57 schreef Jrz het volgende:
Valt me op dat veel mensen er geen koe van gegeten hebben, allemaal mensen die slechts herhalen wat anderen zeggen.

Vind ik jammer dat je dat zegt. . Hiermee geef je dus aan dat dat volgen jou hier ook gebeurt?

Tsja, ieder z'n mening. .

Net als wat er met linux is gebeurd. Maargoed.

_{En dat is al helemaal een belediging. .}

[Verwijderd]

Op maandag 24 juni 2002 23:47 schreef mbravenboer het volgende:
SWT verhaal...

Hmmm, was ik toch in de war (wat je al vermoedde denk ik ) met Swing, ik dacht dat SWT voor Swing Windowing Toolkit stond... En swing... tja...

En wie is Erich Gamma? ff googlen dan maar...

[edit]
Ah gevonden: http://c2.com/cgi/wiki?ErichGamma

Erich is a former Swiss Ski School instructor and a great barbecuer.

[Alarmnummer]

Op dinsdag 25 juni 2002 09:25 schreef Otis het volgende:

[..]

Hmmm, was ik toch in de war (wat je al vermoedde denk ik ) met Swing, ik dacht dat SWT voor Swing Windowing Toolkit stond... En swing... tja...

SWT is heel leuk, super snelle gui natuurlijk. Maar progt minder fijn omdat je niet alles mag extenden en je moet voor de verandering de resources zelf vrij geven ipv het via de garbage collector te laten doen. Plus ik erger me aan het feit dat IBM niet echt de indruk wekt dat het ook voor andere dingen gebruikt moet worden behalve Eclipse. Ik wil best met een andere Widget set aan de slag, maar dan wil ik wel zeker weten dat ik hier in de toekomst ook mee uit de voeten kan.

En wie is Erich Gamma? ff googlen dan maar...

[edit]
Ah gevonden: http://c2.com/cgi/wiki?ErichGamma
[..]

Hij is een van de schrijvers van 'Design patterns & Elements of Reusable Object-Oriented Software'

eigelijk 'het' boek over low level design patterns.

De meeste andere boeken behandelen dezelfde patterns als in doet boek, maar dan toegespitst op een andere taal. Dit boek heeft voorbeeld C++ code.

Erich is a former Swiss Ski School instructor and a great barbecuer.

[mbravenboer]

Otis: En swing... tja...

Er moet iemand eens op het idee komen om een native look and feel te implementeren op Microsoft Windows zoals Apple dat ook heeft gedaan op Mac OS X, wat werkelijk een fantastische iets is geworden.

[Alarmnummer]

Op dinsdag 25 juni 2002 12:31 schreef mbravenboer het volgende:

[..]

Er moet iemand eens op het idee komen om een native look and feel te implementeren op Microsoft Windows zoals Apple dat ook heeft gedaan op Mac OS X, wat werkelijk een fantastische iets is geworden.

Op de mac hebben ze toch onder Swing stiekum de native componenten aangesloten?

[mbravenboer]

Alarmnummer: Op de mac hebben ze toch onder Swing stiekum de native componenten aangesloten?

Yepz en ik zie geen reden waarom dat ook niet op Microsoft Windows zou kunnen...

[Alarmnummer]

Op dinsdag 25 juni 2002 13:39 schreef mbravenboer het volgende:

[..]

Yepz en ik zie geen reden waarom dat ook niet op Microsoft Windows zou kunnen...

Misschien een leuke afstudeeropdracht

[Verwijderd]

In het kader: ON topic, kwam ik deze url tegen in microsoft.public.dotnet.framework.adonet:

http://www.inetsoftware.de/English/Produkte/GATE.NET/default.htm

Het zijn databasedrivers voor Sybase en SQLServer, totaal geschreven in .NET languages, dus ze draaien op mono en rotor, zeggen ze. Ik heb ze nog niet geprobeerd, maar indien dit waar is, dan heb je de functionaliteit van .net portable dmv rotor en mono, maar .net zelf blijft op 1 platform draaien, en toch heb je er geen last van.

[Verwijderd]

Ben trouwens nu met Anakrino, dat is een C# decompiler, de .NET assemblies aan het doorkijken, maar pas heel diep in de SqlConnection.Open() call gaat de code naar MDAC's COM libraries, de rest is allemaal .NET code. Had ik niet verwacht. Wel is er veel obfuscated, dus local varnamen e.d. zijn niet meer te achterhalen, maar voor de rest is alles goed te lezen. Anakrino haal je op: http://www.saurik.com/net/exemplar/

edit:

Hmm, hij called in dbnetlib.dll functies. Die dll is gewoon een C-style dll, dus export gewoon functies, niks COM.

[mbravenboer]

Dat ziet er op zich wel positief uit .

Ik wil eigenlijk een dezer dagen eens kijken of ik die Linux port van Rotor aan de praat krijg. Ik was erg verrast dat daar ook de XML toestanden inzitten en wil weleens kijken in hoeverre dat goed bruikbaar is in Rotor...