🚀 go-pugleaf

In be.comp.programming Theo <theoa_nl@hotmail.com> wrote:
> "Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote in message
> news:402e1eb0$1@news.nb.nu...

>> Ik dacht dat platformonafhankelijkheid juist de essentie van .net was. Een
>> soort veredelde java.

> Nee, .Net doet het juist net andersom van Java:
> - .Net is taal-onafhankelijk, maar platform-afhankelijk

sorry, niet correct. Je kan een "gecompileerde" .net dll (gecompileerd
met visual c# op windows) perfect runnen op de Mono runtime op linux bv.
(Voor zover je natuurlijk functies/klasses gebruikt die al geport zijn
naar Mono).

> - Java is platform-onafhankelijk maar taal-afhankelijk.

Ook dit is niet waar: er bestaan compilers die Java byte code maken van
C code, van Rexx, ... 


Vriendelijke groeten,
Frank Louwers

-- 
Openminds bvba                www.openminds.be
Tweebruggenstraat 16  -  9000 Gent  -  Belgium

In be.comp.programming Dr. O <dr.o@xxxxx> wrote:
> Mensen die met Dot.NET spelen zijn verkeerd bezig en naar mijn idee
> leeghoofden. Als je platform onafhankelijk wil hebben gebruik dan gewoon
> Java. Dot.NET is van M$ en die zal het te pas en te onpas misbruiken om
> Linux een hak te zetten. Nu nog niet misschien, maar later zeer zeker (de
> geschiedenis verteld het hele verhaal). En Mono is per definitie off-limits
> voor mij vanwege deze reden. de Icaza is painting himself into a corner.

Wel, strikt gezien zijn er argumenten om te zeggen dat .Net meer
onafhankelijk is dan Java. Zo heeft Sun expliciet beslist om GEEN
stadaard te maken van Java, terwijl Microsoft de fundamenten van .Net al
vrij snel bij de ECMA heeft gesubmit om er een ECMA standaard van te
maken.

Het is natuurlijk wel zo dat ik me meer vragen stel bij de ethische
werkwijzes van Microsoft dan bij die van Sun, maar strikt gezien is
.Net dus momenteel meer standaard dan Java...


Vriendelijke groeten,
Frank Louwers

-- 
Openminds bvba                www.openminds.be
Tweebruggenstraat 16  -  9000 Gent  -  Belgium

"Theo" <theoa_nl@hotmail.com> writes:

> "Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote in message
> news:402e1eb0$1@news.nb.nu...
> 
> > Ik dacht dat platformonafhankelijkheid juist de essentie van .net was. Een
> > soort veredelde java.
> 
> Nee, .Net doet het juist net andersom van Java:
> - .Net is taal-onafhankelijk, maar platform-afhankelijk
> - Java is platform-onafhankelijk maar taal-afhankelijk.

Dus wat er wel gedaan moet worden, als ik het begrijp,
is een .not-java.not-net maken dat zowel platform als taal onafhankelijk is. 


cor
-- 
(defvar wannabe "s0 u w4Nn4b3 4 h4x0r")  http://www.clsnet.nl/tuxoharata.html
(setq reply-to (concatenate 'string "Cor Gest " "<cor" '(#\@)  "clsnet.nl>"))
No, I will NOT fix your Computer                      http://www.geekgrrrl.nl
          Artificial intelligence has no cure for human stupidity

<frank@openminds.be> wrote in message
news:c0lefm$18mitm$1@ID-103399.news.uni-berlin.de...
> In be.comp.programming Theo <theoa_nl@hotmail.com> wrote:
> > "Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote in message
> > news:402e1eb0$1@news.nb.nu...
>
> >> Ik dacht dat platformonafhankelijkheid juist de essentie van .net was.
Een
> >> soort veredelde java.
>
> > Nee, .Net doet het juist net andersom van Java:
> > - .Net is taal-onafhankelijk, maar platform-afhankelijk
>
> sorry, niet correct. Je kan een "gecompileerde" .net dll (gecompileerd
> met visual c# op windows) perfect runnen op de Mono runtime op linux bv.
> (Voor zover je natuurlijk functies/klasses gebruikt die al geport zijn
> naar Mono).

.Net is by design platform afhankelijk. Dat er nu toevallig een paar andere
implementaties zijn zegt niets.
De klassen libraries zullen niet helemaal up to date zijn en als er een
nieuwe versie van de runtime uitkomt moet je weer wachten op mono.
Sommige zaken kunnen alleen op windows draaien.
Microsoft gaat echt niet (publiekelijk) zitten testen of de nieuwe .Net ook
op linux draait, Sun doet dat wel natuurlijk.

> > - Java is platform-onafhankelijk maar taal-afhankelijk.
>
> Ook dit is niet waar: er bestaan compilers die Java byte code maken van
> C code, van Rexx, ...

En dan kan ik zoiets doen?
class JavaClass extends RexxClass { public void foo() { super.foo(); } }

Cor Gest wrote:

> Dus wat er wel gedaan moet worden, als ik het begrijp,
> is een .not-java.not-net maken dat zowel platform als taal onafhankelijk is. 

parrot..

groetjes, su.

Cor Gest wrote:

> Dus wat er wel gedaan moet worden, als ik het begrijp,
> is een .not-java.not-net maken dat zowel platform als taal onafhankelijk is. 

Ik meen gelezen te hebben dat de Java VM taalonafhankkelijk is....

-- 
Andreas

"Serv� Lau" <serve@detongiser.com> writes:

...

> > Ook dit is niet waar: er bestaan compilers die Java byte code maken van
> > C code, van Rexx, ...
> 
> En dan kan ik zoiets doen?
> class JavaClass extends RexxClass { public void foo() { super.foo(); } }

Uiteraard kan dat.

 S.

Suzan Foster <su@islief.nl> writes:

> Cor Gest wrote:
> 
> > Dus wat er wel gedaan moet worden, als ik het begrijp,
> > is een .not-java.not-net maken dat zowel platform als taal
> > onafhankelijk is.
> 
> parrot..

ergens in de volgende eeuw misschien ...

 S.

"Serv� Lau" <serve@detongiser.com> writes:

...

> .Net is by design platform afhankelijk. Dat er nu toevallig een paar andere
> implementaties zijn zegt niets.

Dit is theoretische blah. Vrijwel elk stuk C code is platform afhankelijk maar
daar gaat het hier niet om. Waar het om gaat is dat je een .net assembly kan
pakken van een platform en draaien op een ander platform waar de runtime ook
beschikbaar is.

In de praktijk zijn er vaak maar een paar platformen relevant. Net zoals bij
Java. Als je op die reeks je applicatie kan deployen dan kan je spreken van
onafhankelijk vind ik zelf.

Java: Linux, FreeBSD, Windows, OS X, Solaris, HP/UX, Neutrino, AIX, IRIX, etc.
Mono: Linux, FreeBSD, Windows, OS X, Solaris.

Dat het niet op je Commodore 64 werkt maakt het niet platform onafhankelijk.

 S.

Deze kerel is fake.  Moet wel !
Don't feed the troll !

eltwo

"Stefan Arentz" <stefan@tiSateh.local> wrote in message
news:m2isi8pj2j.fsf@tiSateh.local...
> "Dr. O" <dr.o@xxxxx> writes:
>
> ...
>
> Mooie emotionele rant. Hoe kan je zo pissed of zijn over een stuk software
> vraag ik me af als ik zoiets lees. Helaas is er ook weinig van waar.
>
> > Ja, idd en mensen die Microsoft kiezen zijn allemaal domme schapen wat
mij
> > betreft die allemaal geslacht gaan worden.
>
> De meeste mensen zijn gewoon praktisch. Klant zegt, ik wil applicatie zus
en
> zo en dan blijkt .Net een prima manier te zijn om dat te implementeren.
Wat
> is daar mis mee vraag ik je dan?
>
> > Er is niets unieks aan .NET want
> > het is gewoon een Java kloon.
>
> Dit is een argument dat ik elke keer weer hoor en ik begrijp nog steeds
niet
> waarom dat zou boeien. Naast .Net en Java zijn er nog talloze andere
manieren
> om applicaties te bouwen en door die keuze blijft de kwaliteit hoog. Zie
wat
> Sun en Microsoft nu doen in nieuwe versies van .Net en Java; er worden nu
> echt dingen beter.
>
> > Ik zie .NET trouwens meer als een side-show
> > omdat binnen Microsoft zelf niemand .NET gebruikt om de 'echte'
applicaties
> > te bouwen (Office, Exchange, MSN Messenger, Outlook etc.).
>
> Alle applicaties in Longhorn zijn .Net applicaties. Nu zijn er ook al
diverse
> dingen op XP die dat zijn. Zoals de Windows Messenger bijvoorbeeld.

En wat moet .NET dan precies concreet voorstellen volgens jou? Als ik met
Dependency Walker naar Windows Messenger kijk dan zie ik geen speciale
(zoals de runtime) waar de .exe van afhankelijk is. Je kan ook C++
executables maken met Visual Studio.NET  maar dat is naar mijn mening geen
'echte' .NET executable. Alleen applicaties die onder de .NET runtime (VM)
draaien zijn 'echte' .NET applicaties.

>
> > Daarvoor
> > gebruiken ze nog steeds alleen maar C/C++.
>
> Een aantal van mijn vrienden werken bij Microsoft en de boodschap is; alle
> nieuwe projecten maak je met .Net. Dat je dat nu nog niet zien komt
natuurlijk
> omdat het vrij lang duurt om nieuwe software in de markt te zetten.

Dat geloof ik als ik het zie. Ik zie Microsoft echt niet Office onder de
.NET runtime draaien. Er zijn verschillende Java Office kloons geweest en
die zijn allemaal gefaald omdat ze te traag en te stroperig waren. Ik zie
trouwens ook duidelijk dat VB.NET executables trager werken dan native code
VB executables.

Toen ik Dr. O kietelde, kwam er dit uit:

> Ik zie Microsoft echt niet Office onder de
> .NET runtime draaien.

Maar Office kan natuurlijk wel de .NET-ondersteuning mee-installeren
en daar onderdelen van gebruiken.

-- 
Affijn, Ruud

"Dr.Ruud" <'t.leven.is.fijn@life.i$.great> wrote in message
news:c1f9ob.1fo.1@news.isolution.nl...
> Toen ik Dr. O kietelde, kwam er dit uit:
>
> > Ik zie Microsoft echt niet Office onder de
> > .NET runtime draaien.
>
> Maar Office kan natuurlijk wel de .NET-ondersteuning mee-installeren
> en daar onderdelen van gebruiken.

Dat is onbelangrijk. Dat zullen ze trouwens wel moeten want er is nu
natuurlijk ook zoiets als VB.NET for Applications, de opvolger van VBA.

Voor mij telt het alleen maar als Microsoft hun 'mainstream' (Office,
Outlook, SQL Server etc.) applicaties in VB.NET maakt. Ik zie dat niet
gebeuren; ze gebruiken nog steeds C++ en volgens mij zal dat nooit
veranderen.

"Dr. O" <dr.o@xxxxx> writes:

...

> Voor mij telt het alleen maar als Microsoft hun 'mainstream' (Office,
> Outlook, SQL Server etc.) applicaties in VB.NET maakt. Ik zie dat niet
> gebeuren; ze gebruiken nog steeds C++ en volgens mij zal dat nooit
> veranderen.

De Win32 API bestaat niet meer in Longhorn. Slechts alleen nog voor
compatibiliteit met oudere applicaties. Dat zoiets zou gebeuren dacht
ook niemand.

Ik nodig je uit om eens wat te lezen over Longhorn; dan zal je zien dat
jouw visie nogal beperkt is.

 http://msdn.microsoft.com/Longhorn/understanding/default.aspx

Het gaat nog wel even duren, maar dan weet je iig wat je te wachten staat.

 S.

Stefan Arentz wrote:

> De Win32 API bestaat niet meer in Longhorn. Slechts alleen nog voor
> compatibiliteit met oudere applicaties. Dat zoiets zou gebeuren dacht
> ook niemand.
> 
> Ik nodig je uit om eens wat te lezen over Longhorn; dan zal je zien dat
> jouw visie nogal beperkt is.
> 
>  http://msdn.microsoft.com/Longhorn/understanding/default.aspx
> 
> Het gaat nog wel even duren, maar dan weet je iig wat je te wachten staat.

wat een hoop bla zeg.. ik vraag mij af hoe lang het gaat duren voordat 
bedrijven overstappen. als er geen backwards compatibility in zit gaat 
het hun handenvol geld kosten om te migreren. goed nieuws voor windows 
developers, dat wel.

groetjes, su.

Suzan Foster <su@islief.nl> writes:

> Stefan Arentz wrote:
> 
> > De Win32 API bestaat niet meer in Longhorn. Slechts alleen nog voor
> > compatibiliteit met oudere applicaties. Dat zoiets zou gebeuren dacht
> > ook niemand.
> > Ik nodig je uit om eens wat te lezen over Longhorn; dan zal je zien
> > dat
> > jouw visie nogal beperkt is.
> >  http://msdn.microsoft.com/Longhorn/understanding/default.aspx
> > Het gaat nog wel even duren, maar dan weet je iig wat je te wachten
> > staat.
> 
> wat een hoop bla zeg.. ik vraag mij af hoe lang het gaat duren voordat
> bedrijven overstappen. als er geen backwards compatibility in zit gaat
> het hun handenvol geld kosten om te migreren. goed nieuws voor windows
> developers, dat wel.

Die compatibiliteit zit er dus wel in. Maar zeg nou zelf, die nieuwe APIs
zijn toch een hele verbetering tov Win32?

 S.

"Suzan Foster" <su@islief.nl> wrote in message
news:403b538a$0$564$e4fe514c@news.xs4all.nl...
> Stefan Arentz wrote:
>
> > De Win32 API bestaat niet meer in Longhorn. Slechts alleen nog voor
> > compatibiliteit met oudere applicaties. Dat zoiets zou gebeuren dacht
> > ook niemand.
> >
> > Ik nodig je uit om eens wat te lezen over Longhorn; dan zal je zien dat
> > jouw visie nogal beperkt is.
> >
> >  http://msdn.microsoft.com/Longhorn/understanding/default.aspx
> >
> > Het gaat nog wel even duren, maar dan weet je iig wat je te wachten
staat.
>
> wat een hoop bla zeg.. ik vraag mij af hoe lang het gaat duren voordat
> bedrijven overstappen. als er geen backwards compatibility in zit gaat
> het hun handenvol geld kosten om te migreren. goed nieuws voor windows
> developers, dat wel.

Ik snap nu ook meteen waarom het tot 2006 gaat duren. Dan zijn hopelijk pc's
snel genoeg om applicaties op een XML based managed OS te draaien. Kijk naar
java dat eigenlijk ook twee of drie jaar te vroeg is uitgegeven, men zit nog
steeds te zeuren dat java zo traag is.

Stefan Arentz wrote:

> Die compatibiliteit zit er dus wel in. Maar zeg nou zelf, die nieuwe APIs
> zijn toch een hele verbetering tov Win32?

niet als je focus ligt bij cross-platform development. en dan nog dat 
bagger wat xaml heet: "mixed markup and source code".

groetjes, su.(*blegh*)

"Serve Laurijssen" <cs@nospam.comp.com> writes:

...

> men zit nog
> steeds te zeuren dat java zo traag is.

Alleen jij Serve. Maar op Usenet mag dat hoor :-)

 S.

"Serve Laurijssen" <cs@nospam.comp.com> writes:

> "Stefan Arentz" <stefan@tiSateh.local> wrote in message
> news:m2znb8woht.fsf@tiSateh.local...
> > > men zit nog
> > > steeds te zeuren dat java zo traag is.
> >
> > Alleen jij Serve. Maar op Usenet mag dat hoor :-)
> 
> Hier, een week geleden nog in deze groep en je hebt zelf meegedaan aan die
> thread (waar was je?).
> 
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=c0d1pn%241nq1%241%40nl-news.euro.net&rnum=1&prev=/groups%3Fas_epq%3D200%2520MMX%26safe%3Dimages%26ie%3DUTF-8%26oe%3DUTF-8%26as_ugroup%3Dnl.comp.programmeren%26as_scoring%3Dd%26lr%3D%26hl%3Den
> 
> Je hoeft echt niet hard te zoeken om iemand te vinden die het roept en dat
> zal nog wel een tijdje blijven.

Ah daar is de Pentium 200 MMX weer die opa nog op zolder had staan!

 S.

"Stefan Arentz" <stefan@tiSateh.local> wrote in message
news:m2znb8woht.fsf@tiSateh.local...
> > men zit nog
> > steeds te zeuren dat java zo traag is.
>
> Alleen jij Serve. Maar op Usenet mag dat hoor :-)

Hier, een week geleden nog in deze groep en je hebt zelf meegedaan aan die
thread (waar was je?).

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=c0d1pn%241nq1%241%40nl-news.euro.net&rnum=1&prev=/groups%3Fas_epq%3D200%2520MMX%26safe%3Dimages%26ie%3DUTF-8%26oe%3DUTF-8%26as_ugroup%3Dnl.comp.programmeren%26as_scoring%3Dd%26lr%3D%26hl%3Den

Je hoeft echt niet hard te zoeken om iemand te vinden die het roept en dat
zal nog wel een tijdje blijven.

Serve Laurijssen wrote:

> Ik snap nu ook meteen waarom het tot 2006 gaat duren. Dan zijn hopelijk pc's
> snel genoeg om applicaties op een XML based managed OS te draaien.

aja, maar de xaml wordt weer gecompileerd tot baml, wat weer een binary 
format xml is.. zo ongeveer nu moeten dus teringveel 
waarschuwingslampjes en sirenes afgaan.

groetjes, su.

"Stefan Arentz" <stefan@tiSateh.local> wrote in message
news:m2vflwwnp2.fsf@tiSateh.local...
> > > > men zit nog
> > > > steeds te zeuren dat java zo traag is.
> > >
> > > Alleen jij Serve. Maar op Usenet mag dat hoor :-)
> >
> > Hier, een week geleden nog in deze groep en je hebt zelf meegedaan aan
die
> > thread (waar was je?).
> >
> >
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=c0d1pn%241nq1%241%40nl-news.euro.net&rnum=1&prev=/groups%3Fas_epq%3D200%2520MMX%26safe%3Dimages%26ie%3DUTF-8%26oe%3DUTF-8%26as_ugroup%3Dnl.comp.programmeren%26as_scoring%3Dd%26lr%3D%26hl%3Den
> >
> > Je hoeft echt niet hard te zoeken om iemand te vinden die het roept en
dat
> > zal nog wel een tijdje blijven.
>
> Ah daar is de Pentium 200 MMX weer die opa nog op zolder had staan!

Vergeet je niet te lezen waar het ook alweer over ging?

Er wordt bijna 10 jaar later nog steeds door talloze mensen beweerd dat java
traag is en dat door de indruk die het ooit achterliet. Stel dat MS nu
longhorn zou releasen met z'n managed xml toeters en bellen en een
gemiddelde gebruiker 2.4 ghz met 512 mb zou het draaien (gemeten aan die
dell reclames), die zou dezelfde indruk krijgen als java toen kreeg. Ik ben
er van overtuigd dat ze die release datum bewust in 2006 hebben gezet. Er
moeten tenslotte ook nog applicaties ontwikkeld worden met xaml, C# en java
bovenop windows.

"Robert" <sl@detongiser.com> wrote in message
news:103n7h2rtuld81@corp.supernews.com...
> Er wordt bijna 10 jaar later nog steeds door talloze mensen beweerd dat
java
> traag is en dat door de indruk die het ooit achterliet.

Zouden die talloze mensen dan misschien gelijk hebben?
Ik heb een webeditor, Arachnophilia genaamd. Gewoon een win32 applicatie. Op
een gegeven moment was een een update.... in Java. Niet vooruit te branden.

Meindert

"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote in message
news:403bce93@news.nb.nu...
> "Robert" <sl@detongiser.com> wrote in message
> news:103n7h2rtuld81@corp.supernews.com...
> > Er wordt bijna 10 jaar later nog steeds door talloze mensen beweerd dat
> java
> > traag is en dat door de indruk die het ooit achterliet.
>
> Zouden die talloze mensen dan misschien gelijk hebben?

Dus ik ben niet de enige die het zegt dan?

> Ik heb een webeditor, Arachnophilia genaamd. Gewoon een win32 applicatie.
Op
> een gegeven moment was een een update.... in Java. Niet vooruit te
branden.

Stel dat je die app nu op longhorn zou draaien met dezelfde pc, zou de
performance dan niet nog een stuk lager komen te liggen?

"Stefan Arentz" <stefan@tiSateh.local> wrote in message
news:m2fzd01uxa.fsf@tiSateh.local...
> "Dr. O" <dr.o@xxxxx> writes:
>
> ...
>
> > Voor mij telt het alleen maar als Microsoft hun 'mainstream' (Office,
> > Outlook, SQL Server etc.) applicaties in VB.NET maakt. Ik zie dat niet
> > gebeuren; ze gebruiken nog steeds C++ en volgens mij zal dat nooit
> > veranderen.
>
> De Win32 API bestaat niet meer in Longhorn. Slechts alleen nog voor
> compatibiliteit met oudere applicaties. Dat zoiets zou gebeuren dacht
> ook niemand.
>
> Ik nodig je uit om eens wat te lezen over Longhorn; dan zal je zien dat
> jouw visie nogal beperkt is.
>
>  http://msdn.microsoft.com/Longhorn/understanding/default.aspx
>
> Het gaat nog wel even duren, maar dan weet je iig wat je te wachten staat.

LOL!! Deze troep betekend het einde van Microsoft. Ik blij!!! :))))))

En dat XAML is trouwens een ripoff van Netscape's XUL met wat Java
(Windows.NET) shit erbij. Ik vind het te belachelijk voor woorden. Maar wel
mooi want mensen zullen dit zo belachelijk vinden dat ze Windows massaal
zullen laten vallen.

Serve Laurijssen wrote:
> "Suzan Foster" <su@islief.nl> wrote in message
> news:403b538a$0$564$e4fe514c@news.xs4all.nl...
> 
>>Stefan Arentz wrote:
>>
>>
>>>De Win32 API bestaat niet meer in Longhorn. Slechts alleen nog voor
>>>compatibiliteit met oudere applicaties. Dat zoiets zou gebeuren dacht
>>>ook niemand.
>>>
>>>Ik nodig je uit om eens wat te lezen over Longhorn; dan zal je zien dat
>>>jouw visie nogal beperkt is.
>>>
>>> http://msdn.microsoft.com/Longhorn/understanding/default.aspx
>>>
>>>Het gaat nog wel even duren, maar dan weet je iig wat je te wachten
> 
> staat.
> 
>>wat een hoop bla zeg.. ik vraag mij af hoe lang het gaat duren voordat
>>bedrijven overstappen. als er geen backwards compatibility in zit gaat
>>het hun handenvol geld kosten om te migreren. goed nieuws voor windows
>>developers, dat wel.
> 
> 
> Ik snap nu ook meteen waarom het tot 2006 gaat duren. Dan zijn hopelijk pc's
> snel genoeg om applicaties op een XML based managed OS te draaien. Kijk naar
> java dat eigenlijk ook twee of drie jaar te vroeg is uitgegeven, men zit nog
> steeds te zeuren dat java zo traag is.
> 
> 
en waarom. Ik heb steeds geleerd dat XML een prachttechniek was om op 
platformonafhankelijke wijze data van de ene naar de andere kant te 
krijgen. Om data op te slaan is het echter complete overhead. (wat niet 
wegneemt dat XML Configuratiebestandjes makkelijker lezen dan 
.properties files in java :))
Ergens gaat MS iets te ver met XML...het is mooi om systemen met 
verschillende API's met elkaar te doen spreken (xslt ertussen), 
platformonafhankelijk data versluizen, ...

achja...waarschijnlijk mis ik wel iets

"Dr. O" <dr.o@xxxxx> writes:

...

> En dat XAML is trouwens een ripoff van Netscape's XUL met wat Java
> (Windows.NET) shit erbij. Ik vind het te belachelijk voor woorden. Maar wel
> mooi want mensen zullen dit zo belachelijk vinden dat ze Windows massaal
> zullen laten vallen.

Haha. Jij leeft echt in een hele aparte wereld :-)

 S.

VoodooChile wrote:

> en waarom. Ik heb steeds geleerd dat XML een prachttechniek was om op 
> platformonafhankelijke wijze data van de ene naar de andere kant te 

de grap is dat microsoft xaml heeft gepatenterd, lijnrecht tegen de 
platform onafhankelijkheid in. gooi er dan nog een binair formaat over 
de xml heen..

> Ergens gaat MS iets te ver met XML...

mja, ik zal wel en xml zealot wezen, maar beg to differ..

groetjes, su.

"Stefan Arentz" <stefan@tiSateh.local> wrote in message
news:m2y8qqx58x.fsf@tiSateh.local...
> "Dr. O" <dr.o@xxxxx> writes:
>
> ...
>
> > En dat XAML is trouwens een ripoff van Netscape's XUL met wat Java
> > (Windows.NET) shit erbij. Ik vind het te belachelijk voor woorden. Maar
wel
> > mooi want mensen zullen dit zo belachelijk vinden dat ze Windows massaal
> > zullen laten vallen.
>
> Haha. Jij leeft echt in een hele aparte wereld :-)

Ik dacht hetzelfde over jou trouwens. De uptake van bepaalde Microsoft
Windows versies (zoals ME en Server 2003) is vrijwel nihil en ik denk dat M$
met Longhorn een heleboel bullshit verspreid om mensen te overtuigen dat dit
een 'must have' gaat worden. Nou, ik vind het grotendeels totaal overbodig
en als ontwikkelaar zit ik er al helemaal niet op te wachten om XML te
moeten schrijven voor een UI.

Zoals Su als zei is M$ totaal over de rooie gegaan wat XML betreft. De reden
(mijns inziens) dat men XML gebruikt is dat men een zowel de UI in een
browser als op de client wil kunnen weergeven met dezelfde 'broncode'.
Eigenlijk bizar als je je realiseert dat Sun dit met Java al 10 jaar geleden
heeft opgelost, nl. door gewoon de code (bytecode) te downloaden naar de
browser. M$ had dit met .NET natuurlijk ook kunnen doen (het is immers een
Java kloon die ook met bytecodes werkt) maar men heeft dit voor ��n of
andere bizarre reden (patenten van Sun?) niet gedaan.

Dr. O <dr.o@xxxxx>:
 > "Stefan Arentz" <stefan@tiSateh.local> wrote in message
 > news:m2y8qqx58x.fsf@tiSateh.local...
 >>
 >> Haha. Jij leeft echt in een hele aparte wereld :-)
 >
 > Ik dacht hetzelfde over jou trouwens. De uptake van bepaalde Microsoft
 > Windows versies (zoals ME en Server 2003) is vrijwel nihil en ik
 > denk dat M$ met Longhorn een heleboel bullshit verspreid om mensen
 > te overtuigen dat dit een 'must have' gaat worden. Nou, ik vind het
 > grotendeels totaal overbodig en als ontwikkelaar zit ik er al helemaal
 > niet op te wachten om XML te moeten schrijven voor een UI.

En je denkt niet dat MS een mooie interfacebuilder aanbiedt? Wist je
overigens dat Glade (de interfacebuilder van GNOME) ook XML bestanden
uitspuugt?

 > Zoals Su als zei is M$ totaal over de rooie gegaan wat XML betreft. De
 > reden (mijns inziens) dat men XML gebruikt is dat men een zowel de
 > UI in een browser als op de client wil kunnen weergeven met dezelfde
 > 'broncode'.  Eigenlijk bizar als je je realiseert dat Sun dit met Java
 > al 10 jaar geleden heeft opgelost, nl. door gewoon de code (bytecode) te
 > downloaden naar de browser.

.NET is niet bedoeld voor het maken van applets, maar voor het maken van
applicaties.

 > M$ had dit met .NET natuurlijk ook kunnen doen (het is immers een Java
 > kloon die ook met bytecodes werkt)...

Als het gebruiken van bytecode impliceert dat iets een Java kloon is dan
vrees ik dat je �cht in een hele aparte wereld leeft.

-- 
                                                                     robert

"robert" <{n.c.p}@allyourbass.org.invalid> wrote in message
news:slrnc3rh64.56v.robert@home.allyourbass.org...
> Dr. O <dr.o@xxxxx>:
>  > "Stefan Arentz" <stefan@tiSateh.local> wrote in message
>  > news:m2y8qqx58x.fsf@tiSateh.local...
>  >>
>  >> Haha. Jij leeft echt in een hele aparte wereld :-)
>  >
>  > Ik dacht hetzelfde over jou trouwens. De uptake van bepaalde Microsoft
>  > Windows versies (zoals ME en Server 2003) is vrijwel nihil en ik
>  > denk dat M$ met Longhorn een heleboel bullshit verspreid om mensen
>  > te overtuigen dat dit een 'must have' gaat worden. Nou, ik vind het
>  > grotendeels totaal overbodig en als ontwikkelaar zit ik er al helemaal
>  > niet op te wachten om XML te moeten schrijven voor een UI.
>
> En je denkt niet dat MS een mooie interfacebuilder aanbiedt? Wist je
> overigens dat Glade (de interfacebuilder van GNOME) ook XML bestanden
> uitspuugt?

Dat wist ik, maar dat wordt door geen enkel OS native gebruikt.

>
>  > Zoals Su als zei is M$ totaal over de rooie gegaan wat XML betreft. De
>  > reden (mijns inziens) dat men XML gebruikt is dat men een zowel de
>  > UI in een browser als op de client wil kunnen weergeven met dezelfde
>  > 'broncode'.  Eigenlijk bizar als je je realiseert dat Sun dit met Java
>  > al 10 jaar geleden heeft opgelost, nl. door gewoon de code (bytecode)
te
>  > downloaden naar de browser.
>
> .NET is niet bedoeld voor het maken van applets, maar voor het maken van
> applicaties.

Java kan ook gebruikt worden voor applicaties en of het nou in een browser
wordt gehost of niet, dat maakt weinig uit.

>
>  > M$ had dit met .NET natuurlijk ook kunnen doen (het is immers een Java
>  > kloon die ook met bytecodes werkt)...
>
> Als het gebruiken van bytecode impliceert dat iets een Java kloon is dan
> vrees ik dat je �cht in een hele aparte wereld leeft.

Neen, de taal is ook een kloon van Java.

Dr. O <dr.o@xxxxx>:
 > "robert" <{n.c.p}@allyourbass.org.invalid> wrote in message
 > news:slrnc3rh64.56v.robert@home.allyourbass.org...
 >>
 >> En je denkt niet dat MS een mooie interfacebuilder aanbiedt? Wist je
 >> overigens dat Glade (de interfacebuilder van GNOME) ook XML bestanden
 >> uitspuugt?
 >
 > Dat wist ik, maar dat wordt door geen enkel OS native gebruikt.

Wat is in godsnaam het probleem van het native gebruiken van XML files?

 >> .NET is niet bedoeld voor het maken van applets, maar voor het maken
 >> van applicaties.
 >
 > Java kan ook gebruikt worden voor applicaties en of het nou in een
 > browser wordt gehost of niet, dat maakt weinig uit.

Uh-huh.

 >> Als het gebruiken van bytecode impliceert dat iets een Java kloon is
 >> dan vrees ik dat je �cht in een hele aparte wereld leeft.
 >
 > Neen, de taal is ook een kloon van Java.

.NET is geen taal.

-- 
                                                                   robert

{n.c.p}@allyourbass.org.invalid (robert) writes:

...

> Wat is in godsnaam het probleem van het native gebruiken van XML files?

Ik heb ook wel interesse in een antwoord met inhoud maar ik ben bang dat
Dr O alleen emotionele en onvolledige argumenten heeft :-)

 S.

Dr. O wrote:

> Ik dacht hetzelfde over jou trouwens. De uptake van bepaalde Microsoft
> Windows versies (zoals ME en Server 2003) is vrijwel nihil en ik denk dat M$
> met Longhorn een heleboel bullshit verspreid om mensen te overtuigen dat dit
> een 'must have' gaat worden. Nou, ik vind het grotendeels totaal overbodig
> en als ontwikkelaar zit ik er al helemaal niet op te wachten om XML te
> moeten schrijven voor een UI.

waarom niet? juist de geneste widget achitectuur van een ui is goed te 
bevatten in xml.

> Zoals Su als zei is M$ totaal over de rooie gegaan wat XML betreft.

nee, dat zeg ik niet. mijn grootste gripe tegen de XAML implementatie is 
dat Microsoft er een proprietary, potentieel closed standard, systeem 
van maakt. voor de rest ben ik juist een groot voorstander van het 
gebruik van xml.

> De reden (mijns inziens) dat men XML gebruikt is dat men een zowel de UI in een
> browser als op de client wil kunnen weergeven met dezelfde 'broncode'.
> Eigenlijk bizar als je je realiseert dat Sun dit met Java al 10 jaar geleden
> heeft opgelost, nl. door gewoon de code (bytecode) te downloaden naar de
> browser. M$ had dit met .NET natuurlijk ook kunnen doen (het is immers een
> Java kloon die ook met bytecodes werkt) maar men heeft dit voor ��n of
> andere bizarre reden (patenten van Sun?) niet gedaan.

dit is onzin.

groetjes, su.

"Suzan Foster" <su@islief.nl> wrote in message
news:403dff74$0$563$e4fe514c@news.xs4all.nl...
> Dr. O wrote:
>
> > Ik dacht hetzelfde over jou trouwens. De uptake van bepaalde Microsoft
> > Windows versies (zoals ME en Server 2003) is vrijwel nihil en ik denk
dat M$
> > met Longhorn een heleboel bullshit verspreid om mensen te overtuigen dat
dit
> > een 'must have' gaat worden. Nou, ik vind het grotendeels totaal
overbodig
> > en als ontwikkelaar zit ik er al helemaal niet op te wachten om XML te
> > moeten schrijven voor een UI.
>
> waarom niet? juist de geneste widget achitectuur van een ui is goed te
> bevatten in xml.
>
> > Zoals Su als zei is M$ totaal over de rooie gegaan wat XML betreft.
>
> nee, dat zeg ik niet. mijn grootste gripe tegen de XAML implementatie is
> dat Microsoft er een proprietary, potentieel closed standard, systeem
> van maakt. voor de rest ben ik juist een groot voorstander van het
> gebruik van xml.

Dat betekent dat third-party's geen GUI editors kunnen bouwen met het
systeem. Dat lijkt me zoiets als jezelf in de voet schieten. Ik denk dus dat
het maar beperkt gesloten zal zijn.

>
> > De reden (mijns inziens) dat men XML gebruikt is dat men een zowel de UI
in een
> > browser als op de client wil kunnen weergeven met dezelfde 'broncode'.
> > Eigenlijk bizar als je je realiseert dat Sun dit met Java al 10 jaar
geleden
> > heeft opgelost, nl. door gewoon de code (bytecode) te downloaden naar de
> > browser. M$ had dit met .NET natuurlijk ook kunnen doen (het is immers
een
> > Java kloon die ook met bytecodes werkt) maar men heeft dit voor ��n of
> > andere bizarre reden (patenten van Sun?) niet gedaan.
>

Totaal niet, want het onderliggende idee is hetzelfde, nl. dat je code wil
schrijven die zowel in een browser draait als stand-alone applicatie. En dat
is Java natuurlijk allang. Een applet is vrijwel hetzelfde als een
applicatie en Microsoft zal dezelfde problemen moeten oplossen zoals Sun dat
al 10 jaar geleden deed.

Dr. O <dr.o@xxxxx>:
 > Totaal niet, want het onderliggende idee is hetzelfde, nl. dat je
 > code wil schrijven die zowel in een browser draait als stand-alone
 > applicatie.
 >
 > En dat is Java natuurlijk allang. Een applet is vrijwel hetzelfde als
 > een applicatie en Microsoft zal dezelfde problemen moeten oplossen zoals
 > Sun dat al 10 jaar geleden deed.

Je haalt maar weer eens 'applets' en 'webservices' door elkaar.

-- 
                                                                     robert

"robert" <{n.c.p}@allyourbass.org.invalid> wrote in message
news:slrnc3u5er.6l8.robert@home.allyourbass.org...
> Dr. O <dr.o@xxxxx>:
>  > Totaal niet, want het onderliggende idee is hetzelfde, nl. dat je
>  > code wil schrijven die zowel in een browser draait als stand-alone
>  > applicatie.
>  >
>  > En dat is Java natuurlijk allang. Een applet is vrijwel hetzelfde als
>  > een applicatie en Microsoft zal dezelfde problemen moeten oplossen
zoals
>  > Sun dat al 10 jaar geleden deed.
>
> Je haalt maar weer eens 'applets' en 'webservices' door elkaar.

Webservices zijn niet de reden dat Microsoft z'n UI in XML gaat uitvoeren.

Dr. O <dr.o@xxxxx>:
 > "robert" <{n.c.p}@allyourbass.org.invalid> wrote in message
 > news:slrnc3u5er.6l8.robert@home.allyourbass.org...
 >> Je haalt maar weer eens 'applets' en 'webservices' door elkaar.
 >
 > Webservices zijn niet de reden dat Microsoft z'n UI in XML gaat
 > uitvoeren.

Dan ben ik benieuwd naar documentatie over de plannen die Microsoft heeft
om .NET apps in browsers te gaan draaien. Aangezien je een kenner bent kan
je vast een aantal urls posten. Ik ben benieuwd!

-- 
                                                                    robert

"robert" <{n.c.p}@allyourbass.org.invalid> wrote in message
news:slrnc3usj3.76s.robert@home.allyourbass.org...
> Dr. O <dr.o@xxxxx>:
>  > "robert" <{n.c.p}@allyourbass.org.invalid> wrote in message
>  > news:slrnc3u5er.6l8.robert@home.allyourbass.org...
>  >> Je haalt maar weer eens 'applets' en 'webservices' door elkaar.
>  >
>  > Webservices zijn niet de reden dat Microsoft z'n UI in XML gaat
>  > uitvoeren.
>
> Dan ben ik benieuwd naar documentatie over de plannen die Microsoft heeft
> om .NET apps in browsers te gaan draaien. Aangezien je een kenner bent kan
> je vast een aantal urls posten. Ik ben benieuwd!
>

http://msdn.microsoft.com/Longhorn/understanding/preparing/default.aspx?pull=/msdnmag/issues/04/01/DevelopingAppsforLonghorn/default.aspx

" Finally, it is worth noting that Windows executables can be hosted in a
window (by default) as well as in the browser. In both cases, the code
remains the same and only needs to be compiled again with a different
project property. "

Suzan Foster wrote:

> waarom niet? juist de geneste widget achitectuur van een ui is goed te
> bevatten in xml.

Als je het gaat nesten en beschrijven in XML moet je /veel/ wijzigen als je
iets veranderd door de strucuur van XML. Stel dat je b.v. 2 knoppen op een
panel hebt: als je dat panel wil verwijderen maar de knoppen wil houden, of
als je ��n van de knoppen naar een ander panel wil verplaatsen ga je ferm
moeten beginnen klooien. Dat kan uiteraard opgevangen worden met designer
tools, maar wat is dan het nut van XML nog?

IMO is de objectgeori�nteerde manier van werken voor GUI's toch te verkiezen
boven XML. Veel natuurlijker denken, veel properdere syntax, veel minder
geklooi.

Ik denk ook dat XML nogal veel wordt gebruikt waar het eigenlijk niet nodig
is (en niet enkel door MS). XML is een fijn formaat maar het wordt gezien
als een "antwoord op alles" terwijl dat IMO geen goed idee is...

-- 
Mvg, JeroenV
<URL:http://www.briachons.org/>

Dr. O <dr.o@xxxxx>:
 > "robert" <{n.c.p}@allyourbass.org.invalid> wrote in message
 > news:slrnc3usj3.76s.robert@home.allyourbass.org...
 >> Dan ben ik benieuwd naar documentatie over de plannen die Microsoft
 >> heeft om .NET apps in browsers te gaan draaien. Aangezien je een kenner
 >> bent kan je vast een aantal urls posten. Ik ben benieuwd!
 >
 > http://msdn.microsoft.com/Longhorn/understanding/preparing/default.aspx?pull=/msdnmag/issues/04/01/DevelopingAppsforLonghorn/default.aspx
 >
 > "Finally, it is worth noting that Windows executables can be hosted in a
 > window (by default) as well as in the browser. In both cases, the code
 > remains the same and only needs to be compiled again with a different
 > project property. "

Heb je de rest van dat artikel ook gelezen? Ik quote even een stukje:

  If configured to run within a browser, an instance of Internet Explorer
  starts up and hosts the application.

Ik ken geen enkele Java applicatie die op mijn machine een browser opstart
om zichzelf te draaien. Daar is .NET/Longhorn dus al anders dan Java.

Nog een stukje:

  As an alternative, you can also deploy an application from a remote
  server...When users point their browser to the specified deployment
  location, Longhorn automatically downloads and installs the application.

Dat gaat over applicationdeployment, niet over applets. Vooral het stukje
'installs the application' is daar duidelijk genoeg over.

Kortom, met applets heeft het vooralsnog weinig te maken, tenzij jij
meent dat elke vorm van het draaien van een stuk code binnen een browser
"hetzelfde is als Java"; in dat geval ben ik bang dat dat al eerder is
gedaan door Netscape (JavaScript) en Macromedia (Flash, Shockwave).

En voor wat betreft XAML: het ziet er uit als een zinnig systeem. Het lijkt
inderdaad op XUL, maar XUL speelt weer leentjebuur bij CSS, DOM en SVG.

Daarnaast krijg ik de indruk dat XUL nou niet echt een standaard en/of
uitontwikkeld te noemen is.

-- 
                                                                     robert

robert wrote:

> En voor wat betreft XAML: het ziet er uit als een zinnig systeem. Het lijkt
> inderdaad op XUL, maar XUL speelt weer leentjebuur bij CSS, DOM en SVG.

kun je ook intepreteren als: xul gebruikt standaarden waar deze al 
bestaan (css, dom, svg), terwijl xaml het wiel opnieuw uitvindt en 
incompatibiliteit nastreeft.

> Daarnaast krijg ik de indruk dat XUL nou niet echt een standaard en/of
> uitontwikkeld te noemen is.

kun je dat toelichten?

groetjes, su.

Suzan Foster <su@islief.nl>:
 > robert wrote:
 >
 >> En voor wat betreft XAML: het ziet er uit als een zinnig systeem. Het
 >> lijkt inderdaad op XUL, maar XUL speelt weer leentjebuur bij CSS, DOM
 >> en SVG.
 >
 > kun je ook intepreteren als: xul gebruikt standaarden waar deze al
 > bestaan (css, dom, svg), terwijl xaml het wiel opnieuw uitvindt en
 > incompatibiliteit nastreeft.

Zo kan je het inderdaad ook interpreteren :) Maar XAML is natuurlijk wel
gebaseerd op standaards als XML en C#.

Maar ik heb geen zin er een oorlogje over te starten, hoor. Alleen de
bewering dat 'XAML een ripoff is van XUL' wil ik graag iets nuanceren.

 >> Daarnaast krijg ik de indruk dat XUL nou niet echt een standaard en/of
 >> uitontwikkeld te noemen is.
 >
 > kun je dat toelichten?

Ik wil het geen standaard noemen omdat alleen Gecko-based browsers er iets
mee kunnen, en ik krijg het gevoel dat het niet uitontwikkeld is omdat de,
neem ik aan, officie�le specificatie [*] 'still under construction' is.

*: http://www.mozilla.org/projects/xul/xul.html

Wat mij er overigens niet van weerhoudt om er af en toe mee te spelen :)

-- 
                                                                    robert

JeroenV wrote:

> Suzan Foster wrote:
> 
>>waarom niet? juist de geneste widget achitectuur van een ui is goed te
>>bevatten in xml.
> 
> Als je het gaat nesten en beschrijven in XML moet je /veel/ wijzigen als je
> iets veranderd door de strucuur van XML. Stel dat je b.v. 2 knoppen op een
> panel hebt: als je dat panel wil verwijderen maar de knoppen wil houden, of
> als je ��n van de knoppen naar een ander panel wil verplaatsen ga je ferm
> moeten beginnen klooien. Dat kan uiteraard opgevangen worden met designer
> tools, maar wat is dan het nut van XML nog?

duidelijkheid van implementatie voor zowel mens als machine, 
off-the-shelf parsers en dynamisch genereerbaar ui's door krachtige 
transformer tools om maar een paar te noemen.

> IMO is de objectgeori�nteerde manier van werken voor GUI's toch te verkiezen
> boven XML. Veel natuurlijker denken, veel properdere syntax, veel minder
> geklooi.

wat is er niet objectgeorienteerd aan een gui beschreven in xml?

> Ik denk ook dat XML nogal veel wordt gebruikt waar het eigenlijk niet nodig
> is (en niet enkel door MS). XML is een fijn formaat maar het wordt gezien
> als een "antwoord op alles" terwijl dat IMO geen goed idee is...

ofschoon het door vele niet-wetenden zo wordt bejegend denk ik dat de 
afgelopen jaren hebben bewezen dat xml een volwassen standaard is 
geworden. ik ben het danook niet mee eens tat het zogenaamd voor alles 
wordt ingezet. kun je een concrete toepassing aangeven waar xml 
onterecht wordt toegepast?

groetjes, su.

robert wrote:

> Zo kan je het inderdaad ook interpreteren :) Maar XAML is natuurlijk wel
> gebaseerd op standaards als XML en C#.

mja, maar vooral jammer vind ik dat zij hun eigen interpretatie van svg 
hebben gebruikt in plaats van een standaard.

> Maar ik heb geen zin er een oorlogje over te starten, hoor. Alleen de
> bewering dat 'XAML een ripoff is van XUL' wil ik graag iets nuanceren.

mee eens.

>  >> Daarnaast krijg ik de indruk dat XUL nou niet echt een standaard en/of
>  >> uitontwikkeld te noemen is.
>  >
>  > kun je dat toelichten?
> 
> Ik wil het geen standaard noemen omdat alleen Gecko-based browsers er iets
> mee kunnen, en ik krijg het gevoel dat het niet uitontwikkeld is omdat de,
> neem ik aan, officie�le specificatie [*] 'still under construction' is.
> 
> *: http://www.mozilla.org/projects/xul/xul.html

ooit op http://xul.sourceforge.net/ gekeken?

groetjes, su.

Suzan Foster <su@islief.nl>:
 > ooit op http://xul.sourceforge.net/ gekeken?

Nope, bedankt voor de tip :)

-- 
                                                           robert

JeroenV <jeroenv@pebbels.invalid> writes:

> Suzan Foster wrote:
> 
> > waarom niet? juist de geneste widget achitectuur van een ui is goed te
> > bevatten in xml.
> 
> Als je het gaat nesten en beschrijven in XML moet je /veel/ wijzigen als je
> iets veranderd door de strucuur van XML. Stel dat je b.v. 2 knoppen op een
> panel hebt: als je dat panel wil verwijderen maar de knoppen wil houden, of
> als je ��n van de knoppen naar een ander panel wil verplaatsen ga je ferm
> moeten beginnen klooien. Dat kan uiteraard opgevangen worden met designer
> tools, maar wat is dan het nut van XML nog?

Het nut is dat je geen gegenereerde code meer hebt om je GUI op te bouwen. Die
is namelijk nog veel lastiger te onderhouden.

Het probleem dat jij beschrijft komt door een gebrek aan tools; maar dat gebrek
is er helemaal niet bij longhorn, die komt natuurlijk met een hippe gui
designer.

 S.

Stefan Arentz wrote:

> JeroenV <jeroenv@pebbels.invalid> writes:
> 
>> Suzan Foster wrote:
>> 
>> > waarom niet? juist de geneste widget achitectuur van een ui is goed te
>> > bevatten in xml.
>> 
>> Als je het gaat nesten en beschrijven in XML moet je /veel/ wijzigen als
>> je iets veranderd door de strucuur van XML. Stel dat je b.v. 2 knoppen op
>> een panel hebt: als je dat panel wil verwijderen maar de knoppen wil
>> houden, of als je ��n van de knoppen naar een ander panel wil verplaatsen
>> ga je ferm moeten beginnen klooien. Dat kan uiteraard opgevangen worden
>> met designer tools, maar wat is dan het nut van XML nog?
> 
> Het nut is dat je geen gegenereerde code meer hebt om je GUI op te bouwen.
> Die is namelijk nog veel lastiger te onderhouden.

I.p.v. gegenereerde code heb je gegenereerde XML. Die kan net zo
onduidelijk/onduidelijker zijn.

> Het probleem dat jij beschrijft komt door een gebrek aan tools; maar dat
> gebrek is er helemaal niet bij longhorn, die komt natuurlijk met een hippe
> gui designer.

Die zijn er nu ook. Met XML verandert enkel hetgeen onder die
designer...waar de meesten zich toch niets van aantrekken.

-- 
Mvg, JeroenV
<URL:http://www.briachons.org/>

JeroenV <jeroenv@pebbels.invalid>:
 > Stefan Arentz wrote:
 >> Het nut is dat je geen gegenereerde code meer hebt om je GUI op te
 >> bouwen.  Die is namelijk nog veel lastiger te onderhouden.
 >
 > I.p.v. gegenereerde code heb je gegenereerde XML. Die kan net zo
 > onduidelijk/onduidelijker zijn.

De XAML voorbeelden die ik tegenkom zijn 100x duidelijker dat de NIB files
die Interface Builder op OSX genereert; NIB files zijn ook nog eens binary,
dus niet eventjes makkelijk te editten.

-- 
                                                                     robert