🚀 go-pugleaf

H,Schampheleer wrote:

>>> CONCLUSIE: Picassso oefende meer ...
>> Een foute conclusie. De conclusie is: Picasso heeft iets wat je niet
>> door oefenen kan leren.

> Sorry voor de andersdenkenden, maar daar ga ik niet helemaal mede
> akkoord. Waarom? Ik weet zeker dat Pablo zeer goed de kunst van het
> vereenvoudigen begrepen had; daarenboven ontwikkelde hij een geheel
> eigen stijl. Of je het mooi vind of niet, is daarbij volledig
> onbelangrijk. In ieder geval: het werkte in zijn specialiteit!

Wat ik bedoel is dat je door net zo veel te oefenen als Picasso niet 
eventjes een Picasso wordt.

>> Hetzelfde geld overigens voor programmeren.
>> Neem 2 programmeurs, elk met 5 jaar ervaring. Ik durf probleemloos te
>> beweren dat als ze zelfs beiden evenveel geoefend hebben, ze toch
>> stevig verschillen.

> Hij die het beste vraagstukjes kon oplossen in het derde leerjaar
> zal wel de beste zijn.

Dat hoeft dus ook weer niet. Iemand die perfect voorgekauwde 
vraagstukjes kan oplossen kan wel eens vastlopen op iets wat net ff 
anders is.

>> Ander voorbeeld: ik deed zelden tot nooit huiswerk. Toch waren veel
>> vakken voor mijn eenvoudig te doen. Ik oefende dus niet tot
>> nauwelijks. Ik was nu en dan zelfs in staat hogere cijfers te halen
>> dan iemand die elke som 2x geoefend had.

> Ja; dat is h��l goed mogelijk.
> bijvoorbeeld: je gedachten gaan veel verder dan wat op het schoolbord 
> geschreven
> staat; je vraagt je tijdens de lessen steeds af "wat kan ik daarmede
> doen.." Besluit: je snapte wat er geschreven staat...

Ik ging meestal een week voor het tentamen het boek eens doorkijken :-D. 
Overigens niet aan te raden. Ik was meestal druk met totaal andere 
dingen bezig, wat soms later weer handig uitkwam (b.v. electronica deed 
ik op de HAVO, wat erg handig was, later op de HTS).

> ( huiswerk maken = meestal toepassen, weergeven van de opgedane
> kennis) ( in lagere afdelingen althans)
> In hogere afdelingen moet je z�lf toevoegen aan de "schoolse" kennis;
> dat kan je niet als je het voorgaande niet snapt...
> (Daarom veel aandacht gegeven aan bv de samenvatting
> van een voorgelezen tekst... in belgie toegang tot graad 1- vele
> kanditaten "sneuvelen" daar; en niet op de theoretische examens)

Ah, ok. Ja, ik was altijd goed in samenvattingen maken :-D. 
Noodzakelijk, ook :-D.

>> Vergissing. Een formule die eenvoudiger is hoeft per se niet sneller
>> te zijn. Een mooi voorbeeld, er zijn algoritmen bekend met een pracht
>> van een O waarde, maar in de praktijk zit er te veel overhead in de
>> constante factor.

> Ik ken niet zoveel toepassingen waar de kortste vorm niet de beste
> is... 

En ik weer genoeg :-D. Soms kan extra complexiteit toevoegen aan een 
functie deze *juist* versnellen. Voorbeeld:

dure_functie( input) {

}

v.s.

functie ( input ) {

    	if (input in hash table )

    	    	value = waarde in table
    	
    	else 

    	    	value = dure_functie( input )
    	    	stop value in hash table met input = key

    	return value
}

Extra complexiteit, langer, maar kan sneller zijn als je vaak dezelfde 
soort input verwacht.

Je browser werkt zo b.v. met een cache.

>>> Uit een vereenvoudiging kan een betere ontstaan...
>>> Programmeren = wiskunde? Ja!
>>> Grootste kunst: moeilijke dingen eenvoudiger maken.
>>> etc etc
>>> allermooiste spreekwoord: KISS (keep it....)
>> Wat vaak niet opgaat als het snel moet.
> Ja maar: neem als voorbeeld een sorteeralgoritme.
> Je kan het doen in 4 lijntjes; wat trouwens in sommige gevallen
> prima kan werken. Als je echter met 5 mio records zit; en je gebruikt
> 4 lijntjes, heb je een groot probleem.
> Als je in dit geval 4 lijntjes gebruikt; heb je niet de kortste,
> snelste vorm gezien. (yes; ik schreef kortste; in dat geval heb je
> volkomen gelijk!)
> Je ziet: begrip "kortste" kan verschillende betekenissen hebben.
> In voorgaande geval is bedoeling natuurlijk kortste = snelste...
> niet aantal lijnen...

Ah, ok: de snelst werkende oplossing is de beste. Hmmm... ook niet 
altijd het geval. Soms is het onderhoudtechnisch beter om een trage 
versie te gebruiken, omdat die duidelijker te lezen is door andere 
programmeurs.

Optimalisatie van code (= kortste versie) is vaak extreem duur, zeker 
als je gewoon snellere hardware kan kopen.

Je kan niet algemeen stellen dat de kortste versie (snelste versie) de 
beste is.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html