🚀 go-pugleaf

"Sjoerd Schreuder" <sa_schreuder@wanadoo.nl> wrote in message
news:3C6CE0C0.CEB2127@wanadoo.nl...
> Ik heb die belofte al te vaak gezien. Eerst zien, dan geloven.

Ja, absoluut mee akoord. Als het van Microsoft afhangt is Windows het enige
OS met een .NET implementatie, dus het zal alleszins afhangen van andere
bedrijven wanneer die .NET implementaties voor andere OSen er komen.
Op de Borland site las ik overlaatst dat ze er alles aan gaan doen om .NET
van Windows te scheiden; een prachtig initiatief en laten we hopen dat hun
.NET implementatie (die blijkbaar gebruik gaat maken van hun Kylix
libraries)
er maar snel komt.

> Java was ook het ultieme portable platform, maar in de praktijk moeten
> <SNIP>
>  valt op een aantal niet-INTEL processoren)

Mja, ik heb er ook al van gehoord maar gelukkig nog niet de eer gehad om
ermee
geconfronteerd te worden.
Het feit dat de CLI/C# gestandariseerd zijn (in tegenstelling tot Java) kan
er
misschien toe bijdragen dat de vershillende implementaties meer compatibel
zijn dan de Java implementaties. Of dat in werkelijkheid nu ook zo zal zijn
valt nog
af te wachten natuurlijk...

> Wat is er eigenlijk mis met C, Ada, Pascal, FORTRAN en al die
> andere programmeertalen?

C vereist toch al meer kunt-en-vliegwerk om het cross platform te krijgen
dan
bijvoorbeeld Java. Je kan natuurlijk zoveel mogelijk gestandariseerde
libraries
gebruiken maar daar kan je ook niet alles mee doen. Een probleem dat ik
onlangs
nog tegenkwam is dat bij WinSock een socket moet gesloten worden met
'closesocket'
en bij de socket implementatie op Linux met 'close'. Dan kan je dus beginnen
met
#ifdef's in je code te gaan zetten, maar daar wordt je code niet echt
leesbaarder
door.

> Kan iemand me het verschil tussen
> sourcecode compileren en bytecode JITten uitleggen? In de praktijk
> kun je al een heel pak talen compileren naar meerdere operating systems,
> dus wat .NET op dat gebied nou eigenlijk toevoegt zie ik niet.

Het voordeel van JITten is dat de code op de client computer omgezet wordt
naar
native code en dat je bijgevolg die code kan gaan optimiseren voor de
aanwezige
instruction set.
Ikzelf werk hier op een Athlon. Dit ding heeft MMX, MMX extensions, 3DNow!,
3DNow! extensions en waarschijnlijk nog veel meer. Als ik een geJIT
programma
uitvoer op mijn computer kan die dus de bytecode omzettten naar native code
gebruiknakend van bovenstaande instruction sets.

Als ik nu code schrijf in VB6 of Delphi of C/C++ dan compiled die code naar
de 486 instruction set en maakt die dus niet gebruik van de laatste
technologieen.
Je kan natuurlijk beginnen met assembly commando's te gebruiken in die talen
maar dit heeft enkele belangrijke nadelen:
 - Je moet (x86) assembly kennen (wat voor de meeste programmeurs niet meer
   het geval is).
 - Je moet manueel testen ofdat een bepaalde instruction set aanwezig is, en
dit kan
   tot performantie verlies leiden in lussen.
 - Je code wordt minder aanpasbaar aangezien je voor een bewerking een
aantal
   verschillende implementaties moet geven (en als je die bewerking wil
veranderen
   moet je dus ook die verschillende implementaties veranderen).

In sommige gevallen wegen de nadelen niet op tegenover de voordelen (bijv.
in grafische
paketten), maar over het algemeen zijn bovenstaande nadelen toch wel erg
genoeg
om assembly code niet direct in je programma te gebruiken.

Mvg,
Pieter Philippaerts