On 2004-04-25, Erik Hensema <usenet> wrote:
>
> Windows is een OS dat een abstractielaag om de hardware vormt.
> Net als elk OS tegenwoordig trouwens.

Tuurlijk, en vroeger op dos had ik een abstractielaag mbt monochrome en
kleuren monitoren.

> Door die abstractielaag gaat code al snel beter portible worden
> (wat overigens niet zegt dat je zomaar alles overal kunt draaien
> natuurlijk).

En dat elke abstractielaag niet hetzelfde is.

> Vroeger had je dingen als DOS. Toen kon je nog echt op de
> hardware schrijven. Sterker nog: dat was toen regel, geen
> uitzondering.

Tuurlijk. Toch komt van de HAL maar een miniem, zo niet totaal te
verwaarlozen deel van de huidige traagheid af. Zeker omdat de hoofddader
(scherm) inmiddels accelerated is.

>> - Portabiliteit vereist geen fat binaries. Tuurlijk, je kan net zo goed
>> lagen software stapelen vanwege portabiliteit als vanwege
>> elke andere reden, maar het hoeft niet.
>>
>>> - interoperatie met andere applicaties, zeker als ze van een
>>> andere fabrikant zijn, zal moeilijk zijn.
>>
>> Die logica zie ik ook niet.

> Het kost moeite om te maken, het kost schijfruimte en het kost
> ramgeheugen.

Amper. Net als het hardware verhaal zit je er hier orde groottes naast. Een
export naar een bepaald formaat ksot enkele tientallen kbs. Je kan er
tientallen van in een MB stoppen.

> Nu pak je er gewoon een of andere library bij en maak je je geen
> zorgen om die halve MB meer ruimte op schijf of in het geheugen.

Nu zit je er dichter bij. Dubbel zelfs

Niet de portabiliteit of die functionaliteit is
het probleem, maar
- opstapelen van frameworks en libraries.
- het onzalige idee dat als je niet zo gauw tegen performance problemen
oploopt, ze helemaal niet bestaan.

>>> - gebruikersvriendelijkheid zal snel ondergeschikt worden aan de
>>> snelheid.
>>
>> Lamme applicaties zijn niet gebruikersvriendelijk.
>
> Dat is van alle tijden.

Probleem is dat het tegenwoordig niet meer hoeft. Een stomme TWAIN app
om foto's op te halen van een camera (niet de goedkoopste overigens) heeft
geen 2GHz nodig om een JPGtje op te halen.

Toegegeven, het is niet realistisch om te vragen de software ook voor i386's
geschikt te maken, maar sub 1GHz zou geen probleem zijn.

Aan de UI is het overigens ook niet gespendeerd. Ziet er uit al de
gem app.

>>> Zoals je al zegt: de fonts. Leuk voorbeeldje. Kijk nu eens naar
>>> een applicatie uit 1992. Het ziet er werkelijk vreselijk uit.
>>
>> Vind ik best meevallen. Ik vind eerlijk gezegd geskinnde bonte apps
>> oerlelijk. Maar goed, het stadium van fluor gele stereotorens met
>> meer lichtjes dan Philips in Eindhoven heeft heb ik ook overgeslagen.
>
> Je kunt best een mooi ingetogen design gebruiken dat gigantisch
> veel mooier is dan de gemiddelde windows 1.0 applicatie.

Geen idee. Ik heb Windows grotendeels weten te vermijden tot 98, al heb ik
nog wat 95 ervaring.

Toch raakt die opmerking van jou weer een facet van het probleem. Elke
developer denkt dat ie de UI beter kan doen, met als gevolg een wildgroei
van stijlen, en het onbruikbaar zijn van vrijwel alle "creative UIs".

Niet omdat ze zo slecht zijn, maar omdat ze niet standaard zijn.

Ik neem het risico als ouwe zeur te klinken, maar vroeger was dat beter.
Microsoft hield toen met het recht om het Windows logo te voeren de devels
nog enigzins aan de styleguides.

Met XP lijkt dat losgelaten te zijn, waarschijnlijk in een deels desperate
poging van Microsoft om de UI toch maar vooral _anders_ te laten zijn dan
voorganger win98/ME. (voorganger in de ogen van de meeste gebruikers)

De softwareboeren zagen hun kans om hun eigen apps nog eens opnieuw
te verkopen, en voila.

>>> was domweg nog niet nodig, maar wegens de onscherpte van die monitor zag
>>> alles er toch wel al wat afgerond uit ;-)
>>
>> Van anti aliasing in een system lib wordt je binary niet groter.
>
> Klopt. Maar dat is *zo* vreselijk oninteressant. Grootte van je
> binary heeft vrijwel geen relatie met het uiteindelijke
> geheugengebruik, uitvoersnelheid, enz.

Dat hoeft inderdaad niet, maar toch gaat die relatie redelijk gelijk op.

>>> een stuk hoger. De ergonomie is gewoon enorm toegenomen. En ja,
>>> dat gaat ten koste van wat snelheid, maar dat wordt meer dan
>>> gecompenseerd met brute rekenkracht.
>>
>> Dit wordt allemaal grotendeels door de (geaccellereerde) driver
>> afgehandeld, heeft op wat grafische software na geen impact op de app
>> denk ik.
>
> Precies. En dat kon een aantal jaren geleden domweg nog niet.

Klopt, maar dat is dus geen verklaring voor trage, grote apps.

>> die let niet op of de laag te dik wordt.
>>
>>> En dat is denk ik waar het allemaal om draait: programmeren wordt
>>> minder low-level, het wordt minder werken met computers en meer
>>> met de dingen waar het *echt* om gaat.
>>
>> TMF, maar dan geskinned op je applicatie. Tsja, mooi of productief is het
>> niet, maar de klant vraagt er inderdaad om.
>
> De klant heeft interactie met je applicatie. Het gaat niet om de
> functionaliteit van een applicatie, het gaat veel meer om hoe je
> die functionaliteit aanspreekt. Er moet ook nog mee gewerkt
> worden immers.

Dat zie ik nu net er niet aan af. Wel nog enigzins aan de software van
Microsoft en Adobe e.d., maar aan veel van de kleinere en meegeleverde kraam
niet. (Davilex, voor mij hebben ze er voor moeten studeren om dat
addressending zo traag te maken)

> Als de klant dat graag wil doen in een interface die schattige
> animaties vertoont, knipperende lichtjes heeft en volledig
> skinbaar is: so be it.

Er is geen "de klant". Het is denk ik een kwestie van tijd tot de
fabrikanten zich dat realiseren. De gemiddelde klant is upgrade moe.

> Niet zo leuk voor de techneut die het moet
> schrijven, tot het moment dat die techneut betaald gaat worden
> ;-)

Kweet. Ik ben ook een webapp aan het schrijven terwijl een gewone
clientserver app beter zou zijn :)

On 2004-04-25, Edwin Martin <e.j.martin> wrote:

> Software ontwikkelen kost tijd. Deze software optimaliseren op snelheid
> en geheugegebruik kost daar een veelvoud van.
>
> Stel, bedrijf A maakt snel een applicatie die het snel in de markt zet
> voor een redelijk bedrag en misschien met nog wat foutjes.
>
> Bedrijf B wil een kwalitatief goede applicatie maken en is daar langer
> mee bezig. Het komt ook later op de markt en is een stuk duurder.


Scenario 1:
> Bedrijf A is ondertussen marktleider en kan de inmiddels opgestreken
> winst gebruiken om de bugs eruit te halen en versie 2 te verkopen.
> Bedrijf B blijft een niche-speler.
>
> Welk bedrijf wil je zijn?

Scenario 2:

A breekt de markt over, maar wordt later ingehaald door B die een wat
degelijker app net wat goedkoper neerzet.

Toen ik John Bokma kietelde, kwam er dit uit:

> De meeste assembly-programmeurs die ik kon, waren er juist gek op. Ik
> vond het ook erg leuk, maar extreem omslachtig, dat wel.

Met een goede macro- en routines-bibliotheek echt niet omslachtiger
dan C-programmeren.

E.N. wrote:

> Oracle/Sybase en SQL server, begonnen allen als binair opslag, SQL 2003/2004
> (precies nummer weet ik niet) zal zelfs 'native' XML opslag gaan toepassen.

niet helemaal (SQL 2003) krijgt uitbreidingen om resultsets als native
xml structures te retourneren, de onderliggende datamodel blijft
relationeel. krijg je bijvoorbeeld zoiets als:

select c.CustId, c.name
xmlelement(name customer,
xmlattributes(c.CustId as id),
xmlelement(name name, c.name),
...


groetjes, su.

Erik Hensema wrote:

>>Dit wordt allemaal grotendeels door de (geaccellereerde) driver afgehandeld,
>>heeft op wat grafische software na geen impact op de app denk ik.
>
> Precies. En dat kon een aantal jaren geleden domweg nog niet.

Dat kan al heel veel jaren, SGI hardware b.v. Alleen duur.

E.N. wrote:

> "Hans" <nospam> wrote in message
> news:2eh1

> Waarom? Ze hadden het herschreven met C++ en 32 bits instructies, zijn
> natuurlijk 2x zo groot.

Eh, 32 bits instructies wil niet zeggen dat je programma's ineens 2x zo
groot worden. Die 16 bits extra doen ook nog leuke extra dingen :-D.

> 1) Kijk eens naar de historie van ontwikkelen.
> De eerste programmeurs programmeerden HEX ops.

Welnee. Bitjes :-D.

> De volgenden gebruikten een mnemonic (zoals assembly).

Een mnemonic, is gewoon een assemblyinstructie opschrijven in een
leesbaar iets, verschilt echt niet van invoeren van hexcodes, je doet nl
hetzelfde, alleen tik je nu iets in als mov r1, r2 ipv 3f 2d, of zet je
twee keer 8 schakelaars anders.

> Daarna kwam C, BASIC jadda jadda, tot nu Java en .NET
>
> Wat opvallend is, dat hoe verder de tijd, hoe minder efficient (overhead) de
> instructies zijn die de taal produceert. Maar dit wordt **gecompenseerd**

Dat is niet zo, sterker, de meeste compilers van nu zijn vele malen
efficienter. Neem maar van mij aan dat de een programma gecompileerd met
een huidige C compiler vele malen efficienter is dan een compiler van 20
jaar terug, voor dezelfde processor. Ook de complexiteit van een taal
zegt niets over de efficientie van de compiler, of de geleverde code.
Een goede compiler kan betere en snellere code leveren dan een
gemiddelde assemblyprogrammeur.

> door betere hardware. De programmeur daarintegen, kan in steeds *minder*
> tijd *meer* functionaliteit schrijven.

Dat hangt er heel erg van af wat die aan het doen is. Sommige
toepassingen gaan echt niet sneller. Een simpel tooltje in Perl kost
soms net zo veel tijd als een vergelijkbaar tooltje in BASIC. En een
goede Grafische GUI, met alle toeters en bellen kost heel veel meer tijd
dan een doodsimpele textgeorienteerde menuinterface.

> (ps: Ik heb nog een oud BASIC PDS 7.x programmaatje, een label printer
> software, dit was in de tijd van DOS een paar opstart seconden, en ik
> optimaliseerde dat door te linken met stubs ;=), nu is hetzelfde
> programaatje nog steeds ergens in mijn archieven. Toen ik het opstartte, was
> het oneindigsnel opgestart :)

Ja, mijn Archimedes was ook snel klaar met opstarten. Aanzetten, piep,
even wachten, en je zat in de desktop. Overigens XP start ook stukken
sneller op.

> 2) Een andere interessante ontwikkeling ligt op data opslag.
>
> Vroeger werden data bestandjes binair opgeslagen, en was 'random' access met
> een index op een sleutel erop, -hot-. Daarna kregen we op de PC dbase
> toepassingen die eenvoudig relationele theorie een beetje toepasbaar maakte.
> Omdat uitwisselen van gegevens steeds belangrijker wordt, en de hoeveelheid
> RAM en de snelheid van harddisks sneller wordt, is het 'efficient' opslaan
> van binaire data niet zo belangrijkmeer.

Dat dacht je maar. MP3, MPEG?

> Oracle/Sybase en SQL server, begonnen allen als binair opslag, SQL 2003/2004
> (precies nummer weet ik niet) zal zelfs 'native' XML opslag gaan toepassen.
> Feitelijk is XML opslag best inefficient en vereist veel meer rekenwerk dan

Dat hangt voor een deel af hoe e.e.a. gedaan wordt, uiteraard.

Edwin Martin wrote:

> Hans wrote:
>>
> Software ontwikkelen kost tijd. Deze software optimaliseren op snelheid
> en geheugegebruik kost daar een veelvoud van.
>
> Stel, bedrijf A maakt snel een applicatie die het snel in de markt zet
> voor een redelijk bedrag en misschien met nog wat foutjes.
>
> Bedrijf B wil een kwalitatief goede applicatie maken en is daar langer
> mee bezig. Het komt ook later op de markt en is een stuk duurder.
>
> Bedrijf A is ondertussen marktleider en kan de inmiddels opgestreken
> winst gebruiken om de bugs eruit te halen en versie 2 te verkopen.
> Bedrijf B blijft een niche-speler.
>
> Welk bedrijf wil je zijn?

Die met de meeste netto winst :-D. Soms is dat stiekem toch bedrijf B.

Dr.Ruud wrote:

> Toen ik John Bokma kietelde, kwam er dit uit:
>>>De meeste assembly-programmeurs die ik kon, waren er juist gek op. Ik
>>vond het ook erg leuk, maar extreem omslachtig, dat wel.
>
> Met een goede macro- en routines-bibliotheek echt niet omslachtiger
> dan C-programmeren.

Zeer zeker wel. Helemaal als je iets nieuws moet maken waarbij je niet
terug kan vallen op je libraries. En ik bedoel dan niet een assembler
die een soort programmeertaaltje aan boord heeft, wat ik ken uit mijn ZX
Spectrum tijd :-D.

Ik heb veel in assembly op RISC OS machines geprogrammeerd, en in C. De
meeste routines zaten keurig in relocatable modules als software
interrupts (SWIs), en voor C waren daar wrappers voor die niets anders
deden dan de juiste SWI aanroepen + wat parameters omzetten. Toch werkte
C vele malen lekkerder.

"Suzan Foster" <su> wrote in message
news:514c
> E.N. wrote:
>
> > Oracle/Sybase en SQL server, begonnen allen als binair opslag, SQL
2003/2004
> > (precies nummer weet ik niet) zal zelfs 'native' XML opslag gaan
toepassen.
>
> niet helemaal (SQL 2003) krijgt uitbreidingen om resultsets als native
> xml structures te retourneren, de onderliggende datamodel blijft
> relationeel. krijg je bijvoorbeeld zoiets als:

Ik had begrepen dat SQL 2003 ook de opslag anders regelt. Zodoende worden
indexen en zoek-opdrachten efficienter.
[..]

"John Bokma" <postmaster> wrote in message
news:af7e
> E.N. wrote:
>
> > "Hans" <nospam> wrote in message
> > news:2eh1
>
> > Waarom? Ze hadden het herschreven met C++ en 32 bits instructies, zijn
> > natuurlijk 2x zo groot.
>
> Eh, 32 bits instructies wil niet zeggen dat je programma's ineens 2x zo
> groot worden. Die 16 bits extra doen ook nog leuke extra dingen :-D.

Over het algemeen is een 16-bits instructie 2x zo klein.
Dus MOV ax,10h is net zo 'klein' op beide systemen.
Maar MOV EAX,10x gebruikt een instructie die 32 bits groot is.
Maar je hoefde geen 64K segments blokken meer bij te houden.

> > 1) Kijk eens naar de historie van ontwikkelen.
> > De eerste programmeurs programmeerden HEX ops.
>
> Welnee. Bitjes :-D.

Whatever. Ik hoorde van mensen die hexjes programeerden.

> > De volgenden gebruikten een mnemonic (zoals assembly).
>
> Een mnemonic, is gewoon een assemblyinstructie opschrijven in een
> leesbaar iets, verschilt echt niet van invoeren van hexcodes, je doet nl
> hetzelfde, alleen tik je nu iets in als mov r1, r2 ipv 3f 2d, of zet je
> twee keer 8 schakelaars anders.

dat klopt.

> > Daarna kwam C, BASIC jadda jadda, tot nu Java en .NET
> >
> > Wat opvallend is, dat hoe verder de tijd, hoe minder efficient
(overhead) de
> > instructies zijn die de taal produceert. Maar dit wordt
**gecompenseerd**
>
> Dat is niet zo, sterker, de meeste compilers van nu zijn vele malen
> efficienter. Neem maar van mij aan dat de een programma gecompileerd met
> een huidige C compiler vele malen efficienter is dan een compiler van 20

Dat klopt, maar ik had het niet over de taal op zich. Je ziet een duidelijke
movement van mnemonics, C (3e generatie) naar 4e generatie. En feit: Java en
..NET is in principe trager dan C. Dus als je de beste programmeurs,
verkrijgbaar in de wereld bij elkaar zoekt voor genoemde talen, om dezelfde
functie te schrijven, is uiteraard assembly de snelste.
Maar met C# en/of java heb je in kortere tijd, meer functionaliteit. Je moet
toch een mierenvreter zijn om dit te ontkennen.

> jaar terug, voor dezelfde processor. Ook de complexiteit van een taal
> zegt niets over de efficientie van de compiler, of de geleverde code.
> Een goede compiler kan betere en snellere code leveren dan een
> gemiddelde assemblyprogrammeur.

niet filosoferen he? Ik heb het dus over de taal, niet over de programmeur.

> > door betere hardware. De programmeur daarintegen, kan in steeds *minder*
> > tijd *meer* functionaliteit schrijven.
>
> Dat hangt er heel erg van af wat die aan het doen is. Sommige
> toepassingen gaan echt niet sneller. Een simpel tooltje in Perl kost
> soms net zo veel tijd als een vergelijkbaar tooltje in BASIC. En een
> goede Grafische GUI, met alle toeters en bellen kost heel veel meer tijd
> dan een doodsimpele textgeorienteerde menuinterface.

Suites, waarbij alles kan, SOAP,XML,HTTP,classes, executables,batches etc,
zijn typisch geschreven voor java/.NET talen. Overigens tel ik basic (vb6)
daar niet bij. Dat is ook al weer van de 'oudere tijd'.

> > (ps: Ik heb nog een oud BASIC PDS 7.x programmaatje, een label printer
> > software, dit was in de tijd van DOS een paar opstart seconden, en ik
> > optimaliseerde dat door te linken met stubs ;=), nu is hetzelfde
> > programaatje nog steeds ergens in mijn archieven. Toen ik het opstartte,
was
> > het oneindigsnel opgestart :)
>
> Ja, mijn Archimedes was ook snel klaar met opstarten. Aanzetten, piep,
> even wachten, en je zat in de desktop. Overigens XP start ook stukken
> sneller op.
>
> > 2) Een andere interessante ontwikkeling ligt op data opslag.
> >
> > Vroeger werden data bestandjes binair opgeslagen, en was 'random' access
met
> > een index op een sleutel erop, -hot-. Daarna kregen we op de PC dbase
> > toepassingen die eenvoudig relationele theorie een beetje toepasbaar
maakte.
> > Omdat uitwisselen van gegevens steeds belangrijker wordt, en de
hoeveelheid
> > RAM en de snelheid van harddisks sneller wordt, is het 'efficient'
opslaan
> > van binaire data niet zo belangrijkmeer.
>
> Dat dacht je maar. MP3, MPEG?

Uitzondering bevestigt de regel :)
We hebben het over de programma's die wij maken op ons werk. Ik neem aan dat
jij op je werk geen MP3's moet produceren.

> > Oracle/Sybase en SQL server, begonnen allen als binair opslag, SQL
2003/2004
> > (precies nummer weet ik niet) zal zelfs 'native' XML opslag gaan
toepassen.
> > Feitelijk is XML opslag best inefficient en vereist veel meer rekenwerk
dan
>
> Dat hangt voor een deel af hoe e.e.a. gedaan wordt, uiteraard.

Cliche in delfde trant als een goede C++ maakt snellere code dan een slechte
assemblytyper. Ik filosofeerde niet, ik gaf aan dat de opslag van XML gewoon
inefficienter is dan binaire opslag bijvoorbeeld.

E.N. wrote:

> Cliche in delfde trant als een goede C++ maakt snellere code dan een slechte
> assemblytyper. Ik filosofeerde niet, ik gaf aan dat de opslag van XML gewoon
> inefficienter is dan binaire opslag bijvoorbeeld.

permathread alert..

groetjes, su.

Toen ik E.N. kietelde, kwam er dit uit:

> Ik filosofeerde niet, ik gaf aan dat de opslag
> van XML gewoon inefficienter is dan binaire opslag bijvoorbeeld.

Dat ligt er maar helemaal aan wat je wilt opslaan. In XML kun je,
met de data, ook gegevens over de data opslaan. Dus als je dat
wilt, valt het met die inefficientie al weer mee. Serialiseren
is 'gewoon' iets anders dan de memory-map van een reeks integers
in een file opslaan.

Verder is veel XML goed te comprimeren (soms wel tot 5% van
de oorspronkelijke grootte maar dan is de netto data ook al
goed comprimeerbaar). Een compressor kan zelfs gebruik maken
van de XML-structuur om een betere compressie van de data te
bereiken. Zie o.a.
http://xml.coverpages.org/xmlAndCompression.html

E.N. wrote:

> "John Bokma" <postmaster> wrote in message
> news:af7e
>> Over het algemeen is een 16-bits instructie 2x zo klein.
> Dus MOV ax,10h is net zo 'klein' op beide systemen.

Dat hangt erg af van het type processor. Een ARM heeft alleen 32 bits
instructies bv. Maar doordat er 32 bits gebruikt werden, was het
mogelijk heel veel slimme dingen te doen, en zelfs instructies te besparen.

> Maar MOV EAX,10x gebruikt een instructie die 32 bits groot is.
> Maar je hoefde geen 64K segments blokken meer bij te houden.
>
>>>1) Kijk eens naar de historie van ontwikkelen.
>>>De eerste programmeurs programmeerden HEX ops.
>>
>>Welnee. Bitjes :-D.
>
> Whatever. Ik hoorde van mensen die hexjes programeerden.

Oh, kan ook. Op een toetsenbordje 0-9 A-F en wat extra knopjes. Maar ook
schakelaars om bitjes te zetten, en een "enter" knopje.

>>Dat is niet zo, sterker, de meeste compilers van nu zijn vele malen
>>efficienter. Neem maar van mij aan dat de een programma gecompileerd met
>>een huidige C compiler vele malen efficienter is dan een compiler van 20
>
> Dat klopt, maar ik had het niet over de taal op zich. Je ziet een duidelijke
> movement van mnemonics, C (3e generatie) naar 4e generatie. En feit: Java en
> .NET is in principe trager dan C. Dus als je de beste programmeurs,

Waarom is Java 4e generatie? En de traagheid van Java komt meer door het
interpreteren dan wat dan ook.

> verkrijgbaar in de wereld bij elkaar zoekt voor genoemde talen, om dezelfde
> functie te schrijven, is uiteraard assembly de snelste.

Als die programmeurs exact op de hoogte zijn van een processor-
architectuur, ja, dan wel.

> Maar met C# en/of java heb je in kortere tijd, meer functionaliteit. Je moet
> toch een mierenvreter zijn om dit te ontkennen.

Wat is er mis met mieren eten? :-P. Het hangt er af van wat je
functionaliteit is. Met Java een device driver schrijven, wordt lastig :-D.

>>jaar terug, voor dezelfde processor. Ook de complexiteit van een taal
>>zegt niets over de efficientie van de compiler, of de geleverde code.
>>Een goede compiler kan betere en snellere code leveren dan een
>>gemiddelde assemblyprogrammeur.
>
> niet filosoferen he? Ik heb het dus over de taal, niet over de programmeur.

Ben kwijt was je over de taal wilde zeggen. Een complexe taal hoeft in
ieder geval geen inefficiente code op te leveren, en vice versa.

>>Dat hangt er heel erg van af wat die aan het doen is. Sommige
>>toepassingen gaan echt niet sneller. Een simpel tooltje in Perl kost
>>soms net zo veel tijd als een vergelijkbaar tooltje in BASIC. En een
>>goede Grafische GUI, met alle toeters en bellen kost heel veel meer tijd
>>dan een doodsimpele textgeorienteerde menuinterface.
>
> Suites, waarbij alles kan, SOAP,XML,HTTP,classes, executables,batches etc,
> zijn typisch geschreven voor java/.NET talen.

Gek, ik doe SOAP, HTML, HTTP, classes, batches etc in Perl. Executables
nog niet :-D.

> Overigens tel ik basic (vb6) daar niet bij. Dat is ook al weer van
> de 'oudere tijd'.

Hoe oud is Java denk je? En wat maakt Java nu zo speciaal voor SOAP,
XML, HTTP, classes. Executables maak je overigens niet echt in Java. Wat
kan in Java wat niet in C++ kon? Of zelfs met meer moeite in C?

>>>van binaire data niet zo belangrijkmeer.
>>
>>Dat dacht je maar. MP3, MPEG?
>
> Uitzondering bevestigt de regel :)

De meeste multimediabestanden zijn binaire data. En dat zijn juist geen
uitzonderingen.

> We hebben het over de programma's die wij maken op ons werk. Ik neem aan dat
> jij op je werk geen MP3's moet produceren.

Nog niet voorgekomen, zou niet gek opkijken als het wel eens zou
gebeuren. Wel plaatjes natuurlijk. En ooit gecomprimeerde videobestanden
moeten bewerken. Binaire data.

>>>Feitelijk is XML opslag best inefficient en vereist veel meer rekenwerk
>
> dan
>
>>Dat hangt voor een deel af hoe e.e.a. gedaan wordt, uiteraard.
>
> Cliche in delfde trant als een goede C++ maakt snellere code dan een slechte
> assemblytyper.

Maar is wel zo :-D.

> Ik filosofeerde niet, ik gaf aan dat de opslag van XML gewoon
> inefficienter is dan binaire opslag bijvoorbeeld.

XML kan ook on-the-fly aangemaakt worden, het hoeft niet als XML
opgeslagen te worden. En inefficient, dat hangt er weer van af. Sommige
binaire bestanden maken gebruik van padding om mooie vaste records te
krijgen. Inefficient in ruimte en tijd, vast vaak. Maar wel eenvoudiger
om te zetten naar iets anders. Met een goede tag keuze zelfdocumenterend.

On 2004-04-26, John Bokma <postmaster> wrote:
> Erik Hensema wrote:
>
>>>Dit wordt allemaal grotendeels door de (geaccellereerde) driver afgehandeld,
>>>heeft op wat grafische software na geen impact op de app denk ik.
>>
>> Precies. En dat kon een aantal jaren geleden domweg nog niet.
>
> Dat kan al heel veel jaren, SGI hardware b.v. Alleen duur.

Gewone 2D accelerated kaarten zijn ook al bijna weer een decennium
gemeengoed.

On Mon, 26 Apr 2004 04:14:58 -0500, John Bokma wrote:

>> Dat klopt, maar ik had het niet over de taal op zich. Je ziet een duidelijke
>> movement van mnemonics, C (3e generatie) naar 4e generatie. En feit: Java en
>> .NET is in principe trager dan C. Dus als je de beste programmeurs,
>
> Waarom is Java 4e generatie? En de traagheid van Java komt meer door het
> interpreteren dan wat dan ook.

Waar heb je die kennis vandaan? De overhead van een JIT compiler loopt
naarmate een applicatie langer draait terug tot (bijna) 0; traagheid wordt
vooral veroorzaakt door het gebrek aan degelijke ondersteuning van een
native user interface (swing applicaties tekenen hun eigen gui en
herbruiken geen native code die daarvoor beter geschikt kan zijn) en een
groter geheugen gebruik omdat ongebruikte objecten pas vrijgegeven worden
wanneer een garbage collector loopt en omdat alle objecten dynamisch zijn.
Beide problemen heb je net zo hard in een statisch gecompileerde taal met
dezelfde eigenschappen.

>> Overigens tel ik basic (vb6) daar niet bij. Dat is ook al weer van
>> de 'oudere tijd'.
>
> Hoe oud is Java denk je? En wat maakt Java nu zo speciaal voor SOAP,
> XML, HTTP, classes.

SOAP: introspectie waardoor stubs om bestaande objecten via soap te callen
dynamisch aangemaakt worden ipv. via code generators vooraf.
XML/HTTP: standaard ondersteuning ingebouwd in het platform
classes: alle Java applicaties zijn OO; geen geklooi met headers,
ondersteuning voor dynamisch linken at runtime...

> Executables maak je overigens niet echt in Java.

Java kan anders prima naar native code gecompileerd worden.

> Wat kan in Java wat niet in C++ kon? Of zelfs met meer moeite in C?

Code schrijven tegen een standaard API die op alle implementaties
ondersteund wordt; bescherming tegen de meest voorkomende
veiligheidslekken in software zoals buffer overflows?

Klaasjan