🚀 go-pugleaf

Passero wrote:
> Ik ben momenteel mijn examen object geori�nteerd ontwerp en analyse
> aan het leren voor maandag en dit jaar zagen we heel veel manieren om
> te refracteren maar ik heb nu gehoord van sommige bedrijven dat ze
> dat daar niet doen, omdat het tijd kost en time is money.

Refactoren (zoals ik het noem) kost natuurlijk tijd, maar het niet doen kost 
meer tijd. Als je aan het programmeren bent, maak je op ieder moment keuzes, 
en het is lastig om iedere keer de juist keuze te maken.
Refactoren helpt je dan:
- je code leesbaarder te maken door betere namen voor je 
variabelen/classes/methods,
- je code leesbaarder te maken door een betere opdeling van je proces in 
deelstappen,
- je code leesbaarder te maken door je methoden onder te brengen in de 
juiste class)
- je code minder bug-gevoelig te maken door gelijksoortige code samen te 
voegen, waardoor je eventuele bugs erin nog maar 1 keer hoeft te ontdekken 
en op te lossen
- je code te hergebruiken, door dependency-management
- enz...

Als dit soort dingen niet belangrijk zijn voor je project (+omgeving), is 
het inderdaad tijdverlies.

> Daarom zijn
> er niet zoveel bedrijven die echt stilstaan bij het ontwerp
ouch...

Groet, Jaap 

Bedoel je soms refactoring ?


"Passero" <bla@bla.bla> wrote in message 
news:KGaGd.31705$NH4.2884676@phobos.telenet-ops.be...
> Ik ben momenteel mijn examen object geori�nteerd ontwerp en analyse aan 
> het leren voor maandag en dit jaar zagen we heel veel manieren om te 
> refracteren maar ik heb nu gehoord van sommige bedrijven dat ze dat daar 
> niet doen, omdat het tijd kost en time is money. Daarom zijn er niet 
> zoveel bedrijven die echt stilstaan bij het ontwerp, laat staan dat ze het 
> refracteren wanneer het moet bijgewerkt worden. Ik wou nu graag eens de 
> mening horen van mensen die professioneel met programmeren bezig zijn, hoe 
> refractering in het echte leven zit. Is het belangrijk of wordt het echt 
> niet gedaan? 

"Jaap Beetstra" <jaap@nospam.beetstra.com> wrote:

>Passero wrote:
>> Ik ben momenteel mijn examen object geori�nteerd ontwerp en analyse
>> aan het leren voor maandag en dit jaar zagen we heel veel manieren om
>> te refracteren maar ik heb nu gehoord van sommige bedrijven dat ze
>> dat daar niet doen, omdat het tijd kost en time is money.
>
>Refactoren (zoals ik het noem) kost natuurlijk tijd, maar het niet doen kost 
>meer tijd. Als je aan het programmeren bent, maak je op ieder moment keuzes, 
>en het is lastig om iedere keer de juist keuze te maken.
>Refactoren helpt je dan:
>- je code leesbaarder te maken door betere namen voor je 
>variabelen/classes/methods,
>- je code leesbaarder te maken door een betere opdeling van je proces in 
>deelstappen,
>- je code leesbaarder te maken door je methoden onder te brengen in de 
>juiste class)
>- je code minder bug-gevoelig te maken door gelijksoortige code samen te 
>voegen, waardoor je eventuele bugs erin nog maar 1 keer hoeft te ontdekken 
>en op te lossen
>- je code te hergebruiken, door dependency-management
>- enz...

Dus allemaal zaken rechtrekken die je eigenlijk al tijdens het ontwerp
van de software had moeten doen?

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Nico Coesel wrote:

> "Jaap Beetstra" <jaap@nospam.beetstra.com> wrote:
> 
>>Passero wrote:
>>> Ik ben momenteel mijn examen object geori�nteerd ontwerp en analyse
>>> aan het leren voor maandag en dit jaar zagen we heel veel manieren
>>> om te refracteren maar ik heb nu gehoord van sommige bedrijven dat
>>> ze dat daar niet doen, omdat het tijd kost en time is money.
>>
>>Refactoren (zoals ik het noem) kost natuurlijk tijd, maar het niet
>>doen kost meer tijd. Als je aan het programmeren bent, maak je op
>>ieder moment keuzes, en het is lastig om iedere keer de juist keuze te
>>maken. Refactoren helpt je dan:
>>- je code leesbaarder te maken door betere namen voor je 
>>variabelen/classes/methods,

Kies je namen met zorg. Sterker, wellicht als de naam niet zo slim was 
beter om die te handhaven, want die kan er na korte tijd "in" zitten, en 
dan blijf je continu fouten fixen die met een slechte naam voorkomen 
hadden kunnen worden. Mijn ervaring is: zeer zelden nodig.

>>- je code leesbaarder te maken door een betere opdeling van je proces
>>in deelstappen,

Kan soms noodzakelijk zijn, zeker als een project wat klein begon ineens 
veel meer moet doen. Ik probeer altijd te voorkomen om voor jaar 2089 te 
ontwerpen tenzij direct duidelijk is dat dit de bedoeling is.

>>- je code leesbaarder te maken door je methoden onder te brengen in de
>>juiste class)

Kan soms nodig zijn als later een class B nodig blijkt te zijn die een 
deel van de code in class A kan hergebruiken, en dus een 
gemeenschappelijke ouder, class C, handig kan zijn.

>>- je code minder bug-gevoelig te maken door gelijksoortige code samen
>>te voegen, waardoor je eventuele bugs erin nog maar 1 keer hoeft te
>>ontdekken en op te lossen

Zie boven.

>>- je code te hergebruiken, door dependency-management
>>- enz...
> 
> Dus allemaal zaken rechtrekken die je eigenlijk al tijdens het ontwerp
> van de software had moeten doen?

Nee, want vaak weet je bij versie 1 niet waar versie 3 heen gaat. Een 
kleine editor die handig is kan ineens deel uit gaan maken van een IDE 
bijvoorbeeld. Of een editor van HTML moet ineens ook XML, PHP, Perl, 
Java, C# enz. netjes kunnen kleuren e.d. 

Als je bij versie 1 al rekening gaat houden met versie 2 t/m EOL dan zal 
het project meestal niet eens uit de ontwerpfase komen. Bij elk nieuw 
idee komen er dan zoveel problemen en nieuwe ideeen naar boven dat er 
een mooie infinite loop ontstaat :-D.

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

Passero wrote:

> Ik ben momenteel mijn examen object georiënteerd ontwerp en analyse aan 
> het leren voor maandag en dit jaar zagen we heel veel manieren om te 
> refracteren maar ik heb nu gehoord van sommige bedrijven dat ze dat daar 
> niet doen, omdat het tijd kost en time is money.

Haha. Welke bedrijven zijn dat? Elke zichzelf serieus nemende 
programmeur die OOP-programmeert doet wel eens aan refactoring.

Programmeren is net als een huis inrichten en refactoren is het 
verschuiven van meubels.

Stel je vervangt je TV door een breedbeeld-TV. De huidige TV-kast is 
daar veel te klein voor. Ga je dan de kleine TV-kast vervangen door een 
grote kast (= refactoring)? Nee, je zet de grote TV-kast naast de kleine 
TV-kast (= geen refactoring).

En dan komt het nageslacht. Hmm, de rommelkamer had eigenlijk een 
babykamer moeten zijn, maar we gaan natuurlijk niet met spullen sjouwen 
(refactoring). Nou, voor het kinderbedje is nog wel plaats voor de 
kachel en naast de luidspreker.

Hopelijk is het een beetje duidelijk dat OOP-programmeren zonder 
refactoring leidt tot code waarmee je niet wilt werken.

Edwin Martin

-- 
http://www.bitstorm.org/

On 2005-01-16, Edwin Martin <e.j.martin@chello.nl> wrote:
> Passero wrote:
>
>> Ik ben momenteel mijn examen object geori�nteerd ontwerp en analyse aan 
>> het leren voor maandag en dit jaar zagen we heel veel manieren om te 
>> refracteren maar ik heb nu gehoord van sommige bedrijven dat ze dat daar 
>> niet doen, omdat het tijd kost en time is money.
>
> Haha. Welke bedrijven zijn dat? Elke zichzelf serieus nemende 
> programmeur die OOP-programmeert doet wel eens aan refactoring.
>
> Programmeren is net als een huis inrichten en refactoren is het 
> verschuiven van meubels.

Ik denk dat jullie beide gelijk hebben. Je verandert niets zomaar. Dus
als het werkt, blijf je er gewoon af.

Wanneer de systeemeisen veranderen (en die verandering was niet voorzien
in het originele ontwerp) is refactoring vaak de minst dure
oplossing om aan de nieuwe eisen te voldoen.




-- 
Met vriendelijke groeten,
Tim Van Wassenhove <http://www.timvw.info>

Nico Coesel wrote:
> Dus allemaal zaken rechtrekken die je eigenlijk al tijdens het ontwerp
> van de software had moeten doen?

Refactoren is ontwerpen 

Tim Van Wassenhove schreef:
> On 2005-01-16, Edwin Martin <e.j.martin@chello.nl> wrote:
> 

> 
> 
> Ik denk dat jullie beide gelijk hebben. Je verandert niets zomaar. Dus
> als het werkt, blijf je er gewoon af.
> 

Dat is toch niet direct het idee van refractoring. Ik heb nu mijn 
volledige cursus geleerd en heb er een beter beeld over. Als het werkt 
en je moet functionaliteit bijschrijven maar je merkt dat de code nogal 
slecht ontworpen is voor die functionaliteit toe te voegen dan refractor 
je het project en voeg je de code toe. Als je gewoon de functionaliteit 
toevoegt zonder te refractoren dan krijg je nog meer onoverzichtelijke 
code en dat leidt later tot een punt waar je zegt dat het niet meer 
doenbaar is.

Wanneer je XP (Xtreme programming) volgt dan refractor je voortdurend. 
Na elke kleine stap die je gemaakt heb en je wilt er een nieuwe 
bijvoegen (dus functionaliteit toevoegen) dan refractor je een beejte (= 
ontwerp bijschaven).

> Wanneer de systeemeisen veranderen (en die verandering was niet voorzien
> in het originele ontwerp) is refactoring vaak de minst dure
> oplossing om aan de nieuwe eisen te voldoen.
> 
> 
> 
> 

On 2005-01-16, Passero <bla@bla.bla> wrote:
> Tim Van Wassenhove schreef:
>> On 2005-01-16, Edwin Martin <e.j.martin@chello.nl> wrote:
>> 
>
>> 
>> 
>> Ik denk dat jullie beide gelijk hebben. Je verandert niets zomaar. Dus
>> als het werkt, blijf je er gewoon af.
>> 
>
> Dat is toch niet direct het idee van refractoring. Ik heb nu mijn 
> volledige cursus geleerd en heb er een beter beeld over. 

Heb je een volledige cursues "geleerd" en nog altijd niet opgemerkt dat
er in refactoring maar 2r-en voorkomen. 


> Als het werkt 
> en je moet functionaliteit bijschrijven maar je merkt dat de code nogal 
> slecht ontworpen is voor die functionaliteit toe te voegen dan refractor 
> je het project en voeg je de code toe. Als je gewoon de functionaliteit 
> toevoegt zonder te refractoren dan krijg je nog meer onoverzichtelijke 
> code en dat leidt later tot een punt waar je zegt dat het niet meer 
> doenbaar is.

Dus je herhaalt wat ik al zei: If it ain't broken, don't fix it. En als
het dan toch moet, lijkt refactoring vaak de goedkoopste oplossing.

Een goed ontwerp zal reeds functionaliteit bevatten om makkelijk aan de
nieuwe/aangepaste eisen te voldoen.

Omdat het moeilijk/onmogelijk is zo'n perfect ontwerp te maken, 
is de XP methodologie ontstaan die stelt dat je huidige code moet voldoen 
aan de huidige eisen (kan gecontroleerd worden mbv unit-tests) 
en vervolgens dmv refactoring de nieuwe/veranderde eisen in het ontwerp
kunnen opgenomen worden.

-- 
Met vriendelijke groeten,
Tim Van Wassenhove <http://www.timvw.info>

Edwin Martin wrote:

> Passero wrote:
> 
>> Ik ben momenteel mijn examen object geori�nteerd ontwerp en analyse a
> an 
>> het leren voor maandag en dit jaar zagen we heel veel manieren om te 
>> refracteren maar ik heb nu gehoord van sommige bedrijven dat ze dat daa
> r 
>> niet doen, omdat het tijd kost en time is money.
> 
> Haha. Welke bedrijven zijn dat? Elke zichzelf serieus nemende 
> programmeur die OOP-programmeert doet wel eens aan refactoring.

Werk jij freelance, en heb je ooit wel eens geprobeerd iets als refactoring 
er doorheen te krijgen bij je opdrachtgever? Of schrijven van documentatie?

Ook in loondienst komt dit te veel voor. Ik heb ooit bij een zich serieus 
neemend bedrijf gewerkt, en ik kreeg 650+ Perl modules op mijn bord. Mag 
jij raden hoeveel documentatie er was. Oh, en refactoring, ik denk dat 
alles weggooien en opnieuw beginnen een betere oplossing was voor die 
rommel.

> Programmeren is net als een huis inrichten en refactoren is het 
> verschuiven van meubels.

Voor de opdrachtgever komt het dus over als: ik heb een binnenhuisarchitect 
ingehuurd, en nu moet er weer een komen.

> Stel je vervangt je TV door een breedbeeld-TV. De huidige TV-kast is 
> daar veel te klein voor. Ga je dan de kleine TV-kast vervangen door een 
> grote kast (= refactoring)? Nee, je zet de grote TV-kast naast de kleine 
> TV-kast (= geen refactoring).

Het vervelende is dat refactoring vaak ingrijpender is dan dit. Eventjes 
een variable van naam veranderen is simpel, en kost geen tijd. Maar het 
probleem met een grotere TV-kast is dat je vaak ook de woning groter moet 
maken (want die kleine kast paste precies in een mooie nis).

> En dan komt het nageslacht. Hmm, de rommelkamer had eigenlijk een 
> babykamer moeten zijn, maar we gaan natuurlijk niet met spullen sjouwen 
> (refactoring). Nou, voor het kinderbedje is nog wel plaats voor de 
> kachel en naast de luidspreker.
> 
> Hopelijk is het een beetje duidelijk dat OOP-programmeren zonder 
> refactoring leidt tot code waarmee je niet wilt werken.

Klopt, de programmeur "wil er niet mee werken". Maar de opdrachtgever kan 
nogal eens van mening zijn dat als je gaat trouwen, en je wilt kinderen, 
dat je dan maar rekening had moeten houden met een kinderkamer :-D.

(En vergeet dus dat hij de vader is ;-) )

Dus refactoring: ja. Kwalijker vind ik het als iemand direct een heel dorp 
gaat ontwerpen als een eengezinswoning voldoende 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

Jaap Beetstra schreef op 16-1-2005
> Refactoren is ontwerpen 

Volgens http://www.array.nl/release/artikelen/2000/3_Ende_refactoring.pdf
is dat wel erg kort door de bocht.

En zoals de OP al schrijft is mijn ervaring dat daar pas tijd voor wordt 
gemaakt als er een grote verandering op stapel staat, en meestal is die 
verandering dan zo groot, dat er volledig opnieuw wordt ontworpen 
(redesign).

RP

Passero wrote:

> Tim Van Wassenhove schreef:
>> On 2005-01-16, Edwin Martin <e.j.martin@chello.nl> wrote:
>> 
> 
>> 
>> 
>> Ik denk dat jullie beide gelijk hebben. Je verandert niets zomaar.
>> Dus als het werkt, blijf je er gewoon af.
> 
> Dat is toch niet direct het idee van refractoring.

Toch wel, als het werkt ga je niet refractoren, lijk mij.

> Ik heb nu mijn 
> volledige cursus geleerd en heb er een beter beeld over.

Je bedoelt: jij hebt uit een boek geleerd hoe het heet. Sommige mensen
hier programmeren al heel wat jaartjes, en refractoren bij het leven,
maar weten niet hoe het heet :-D. 

> Als het werkt 
> en je moet functionaliteit bijschrijven

Dan werkt het dus niet (volledig).

> maar je merkt dat de code nogal 
> slecht ontworpen is voor die functionaliteit toe te voegen dan
> refractor je het project en voeg je de code toe.

Dat is gewoon praktijk. En ik kan mij geen enkel project voorstellen
waar dat niet gebeurd. Soms iets simpels als een functie naam is slecht
gekozen, en soms blijkt achteraf dat je ergens iets handiger kan doen. 

> Als je gewoon de functionaliteit 
> toevoegt zonder te refractoren dan krijg je nog meer onoverzichtelijke
> code

Dat hoeft dus totaal niet. Als je b.v. een class auto hebt, en er moet
een trekhaak aan, hoef je niet te refractoren. 

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

Tim Van Wassenhove wrote:

> Een goed ontwerp zal reeds functionaliteit bevatten om makkelijk aan
> de nieuwe/aangepaste eisen te voldoen.

Zo'n goed ontwerp is extreem zeldzaam, zeker bij dingen die niet duidelijk 
zijn. En ik zie dat we het eens zijn:

> Omdat het moeilijk/onmogelijk is zo'n perfect ontwerp te maken, 
> is de XP methodologie ontstaan die stelt dat je huidige code moet
> voldoen aan de huidige eisen (kan gecontroleerd worden mbv unit-tests)
> en vervolgens dmv refactoring de nieuwe/veranderde eisen in het
> ontwerp kunnen opgenomen worden.

En ik denk dat menig programmeur zo al heel wat jaartjes werkt. Ik weet dat 
er ook mensen zijn die de voorkeur geven om iets helemaal (wat is dat) uit 
te denken, en met alles rekening proberen te houden. Maar in de praktijk 
komt zoiets dan (naar mijn mening) nooit van de grond.

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

RP wrote:

> Jaap Beetstra schreef op 16-1-2005
>> Refactoren is ontwerpen 
> 
> Volgens http://www.array.nl/release/artikelen/2000/3_Ende_refactoring.pdf
> is dat wel erg kort door de bocht.
> 
> En zoals de OP al schrijft is mijn ervaring dat daar pas tijd voor wordt 
> gemaakt als er een grote verandering op stapel staat, en meestal is die 
> verandering dan zo groot, dat er volledig opnieuw wordt ontworpen 
> (redesign).

Yup, het is altijd de programmeur v.s. de niet-programmeur. De laatste 
meent dat bepaalde dingen "speeltjes" zijn van de programmeur, en de eerste 
meent dat de ander de PHB uithangt.

Het is ook vaak lastig uit te leggen: ja, wat ik 3 maanden geschreven heb 
werkte prima, maar als je die toeters en bellen er ook in wilt, moeten we 
eventjes terug naar de tekentafel.

Voor een opdrachtgever klinkt dat als: deze DVD speler werkt niet op de TV 
die je 3 maanden terug gekocht hebt, maar gelukkig hebben we nu dit model 
in de aanbieding...

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

John Bokma schreef:
> 
> 
>>Omdat het moeilijk/onmogelijk is zo'n perfect ontwerp te maken, 
>>is de XP methodologie ontstaan die stelt dat je huidige code moet
>>voldoen aan de huidige eisen (kan gecontroleerd worden mbv unit-tests)
>>en vervolgens dmv refactoring de nieuwe/veranderde eisen in het
>>ontwerp kunnen opgenomen worden.
> 
> 
> En ik denk dat menig programmeur zo al heel wat jaartjes werkt. Ik weet dat 
> er ook mensen zijn die de voorkeur geven om iets helemaal (wat is dat) uit 
> te denken, en met alles rekening proberen te houden. Maar in de praktijk 
> komt zoiets dan (naar mijn mening) nooit van de grond.
> 

Wel, wij hebben 2 jaar een project moeten maken met 3 mensen volgens het 
UP process. Dat hield in dat we eerst een volledig ontwerp moesten maken 
en das pas beginnen met coderen. Het sprak voor zich dat we daar dus 
heel veel tijd aan hebben verloren. HEt ontwerp hebben we te veel moeten 
aanpassen en zijn zeer laat kunnen beginnen met coderen. IN de theorie 
hebben ze gezegd dat UP gebruikt wordt voor grote projecten met veel 
mensen en XP voor kleinere projecten met een kleinere groep 
programmeurs. Volgens mij zijn 3 mensen en een projectje dat wij hebben 
moeten maken vrij kleinschalig. Waarom dan in godsnaam UP gebruiken :s

Dit jaar hadden we dan nog eens als taak zo'n project te refactoren. Was 
wel leuk eigenlijk en toen had ik de commentaar gekregen dat ik al een 
deftig ontwerp had dus we hadden er weinig werk aan. (en dit kwam om 
eerlijk te zijn niet door op de manier te werken die ons opgelegd was 
maar door elk deel appart te ontwerpen en coderen, beginnen bij het 
belangrijkst, een beetje zoals XP maar we lieten dat niet zo uitschijnen).

John Bokma schreef:
> RP wrote:
> 
> 
>>Jaap Beetstra schreef op 16-1-2005
>>
>>>Refactoren is ontwerpen 
>>
>>Volgens http://www.array.nl/release/artikelen/2000/3_Ende_refactoring.pdf
>>is dat wel erg kort door de bocht.
>>
>>En zoals de OP al schrijft is mijn ervaring dat daar pas tijd voor wordt 
>>gemaakt als er een grote verandering op stapel staat, en meestal is die 
>>verandering dan zo groot, dat er volledig opnieuw wordt ontworpen 
>>(redesign).
> 
> 
> Yup, het is altijd de programmeur v.s. de niet-programmeur. De laatste 
> meent dat bepaalde dingen "speeltjes" zijn van de programmeur, en de eerste 
> meent dat de ander de PHB uithangt.
> 
> Het is ook vaak lastig uit te leggen: ja, wat ik 3 maanden geschreven heb 
> werkte prima, maar als je die toeters en bellen er ook in wilt, moeten we 
> eventjes terug naar de tekentafel.
> 
> Voor een opdrachtgever klinkt dat als: deze DVD speler werkt niet op de TV 
> die je 3 maanden terug gekocht hebt, maar gelukkig hebben we nu dit model 
> in de aanbieding...
> 

Kun je niet tegelijk toeters en bellen aanbrengen EN refactoren? In mijn 
cursus staat er: "als programmeur verwissel je voortdurend van pet: je 
programmeert, je hebt de programmeurs-pet op. Je moet dingen 
bijschrijven na een tijdje en je zet de refactor pet op waarna je terug 
de programmeurs pet opzet. Het is een voortdurend wisselen van 
programmeren en refactoren."
Of is die methodiek niet echt rendabel?

In nl.comp.programmeren John Bokma <postmaster@castleamber.com> wrote:
> 
> Ook in loondienst komt dit te veel voor. Ik heb ooit bij een zich serieus 
> neemend bedrijf gewerkt, en ik kreeg 650+ Perl modules op mijn bord. Mag 
> jij raden hoeveel documentatie er was. Oh, en refactoring, ik denk dat 
> alles weggooien en opnieuw beginnen een betere oplossing was voor die 
> rommel.
> 
weggooien kan nooit. 
Er is misschien in het verleden al miljoenen besteed aan die
650 modules en dus zijn die modules zoveel geld waard. Later
is er misschien ook nog voor tonnen aan gesleuteld en daarmee
is de waarde van het product gestegen. Zo wordt er gedacht.
Als je alleen al praat over dingen weggooien (weggooien is
ook refactoren), dan gooi je kapitaal weg en dat kan niet!


koos.

Someone referred to as: Passero <bla@bla.bla>
 has comitted the herein quoted text :
> 
> Kun je niet tegelijk toeters en bellen aanbrengen EN refactoren? In
> mijn cursus staat er: "als programmeur verwissel je voortdurend van
> pet: je programmeert, je hebt de programmeurs-pet op. Je moet dingen
> bijschrijven na een tijdje en je zet de refactor pet op waarna je
> terug de programmeurs pet opzet. Het is een voortdurend wisselen van
> programmeren en refactoren."
> Of is die methodiek niet echt rendabel?

O jawel hoor, je kan je de voordelen nauwelijks voorstellen die het
heeft om tijdens, voor en na het programmeren regelmatig van pet
te wisselen.
Bij gebrek aan marketoidiaans en andere modernistische newspeak enzo 
behelp ik me reeds enige decennia met de uitdrukking `JKG'en'.
(je kop gebruiken)
Overigens, gewoon nadenken over waar je mee bezig bent schijnt ook te helpen.

Cor

-- 
	Mortal say: God needed 6 days to create the whole Universe
    So, Why do these mortals expect a computer to Make World in 6 seconds 
             Thou shall not worship any Operating System       

In nl.comp.programmeren Passero <bla@bla.bla> wrote:
>> 
> 
> Kun je niet tegelijk toeters en bellen aanbrengen EN refactoren? In mijn 
> cursus staat er: "als programmeur verwissel je voortdurend van pet: je 
> programmeert, je hebt de programmeurs-pet op. Je moet dingen 
> bijschrijven na een tijdje en je zet de refactor pet op waarna je terug 
> de programmeurs pet opzet. Het is een voortdurend wisselen van 
> programmeren en refactoren."
> Of is die methodiek niet echt rendabel?

Een cursus refactoring???

Hier gaat het dus mis.


koos

koos wrote:

> In nl.comp.programmeren John Bokma <postmaster@castleamber.com> wrote:
> 
>>Ook in loondienst komt dit te veel voor. Ik heb ooit bij een zich serieus 
>>neemend bedrijf gewerkt, en ik kreeg 650+ Perl modules op mijn bord. Mag 
>>jij raden hoeveel documentatie er was. Oh, en refactoring, ik denk dat 
>>alles weggooien en opnieuw beginnen een betere oplossing was voor die 
>>rommel.
>>
> 
> weggooien kan nooit. 
> Er is misschien in het verleden al miljoenen besteed aan die
> 650 modules en dus zijn die modules zoveel geld waard. Later
> is er misschien ook nog voor tonnen aan gesleuteld en daarmee
> is de waarde van het product gestegen. Zo wordt er gedacht.
> Als je alleen al praat over dingen weggooien (weggooien is
> ook refactoren), dan gooi je kapitaal weg en dat kan niet!

Joel Spolsky zegt over die ontwikkelkosten, weliswaar in relatie
tot de verkoopprijs, maar toch relevant aan deze beredenering:

"Maybe it cost you $250,000 to develop the software in the first place,
but that's a sunk cost. We don't care about that anymore, because the
$250,000 is the same whether you sell 1000 units or 0. Sunk.
Kiss it goodbye. Set any price you want, the $250,000 is gone and
therefore not relevant any more."

als de te refactoren onderdelen niet meer nodig zijn, dan verlies je er
niks mee om ze weg te gooien. de kosten zijn al gemaakt, en worden niet
hoger door de code te verwijderen. de refactoring levert toegevoegde
waarde op, dus telt ook niet als winstenderving. waarschijnlijk wordt de
refactoring immers uitgevoerd om een paar extra dozen te verkopen die
zonder de aanpassingen niet verkocht waren.

groetjes, su.
-- 
http://joelonsoftware.com/articles/CamelsandRubberDuckies.html

In nl.comp.programmeren Suzan Foster <http://members.home.nl/foz/foaf.rdf> wrote:
> 
> als de te refactoren onderdelen niet meer nodig zijn, dan verlies je er
> niks mee om ze weg te gooien. de kosten zijn al gemaakt, en worden niet
> hoger door de code te verwijderen. de refactoring levert toegevoegde
> waarde op, dus telt ook niet als winstenderving. waarschijnlijk wordt de
> refactoring immers uitgevoerd om een paar extra dozen te verkopen die
> zonder de aanpassingen niet verkocht waren.
> 
... tenzij er sprake is van ordinaire code-rot, waardoor elk aanpassing
in de code ervoor zorgt dat er ergens anders weer wat omdondert. En probeer
dan de geldbetalers er maar eens van te overtuigen dat het de moeite loont
om eens een maand met de bezem door de rotzooi te gaan.....


koos.

koos wrote:

> In nl.comp.programmeren Suzan Foster <http://members.home.nl/foz/foaf.rdf> wrote:
> 
>>als de te refactoren onderdelen niet meer nodig zijn, dan verlies je er
>>niks mee om ze weg te gooien. de kosten zijn al gemaakt, en worden niet
>>hoger door de code te verwijderen. de refactoring levert toegevoegde
>>waarde op, dus telt ook niet als winstenderving. waarschijnlijk wordt de
>>refactoring immers uitgevoerd om een paar extra dozen te verkopen die
>>zonder de aanpassingen niet verkocht waren.
>>
> 
> .... tenzij er sprake is van ordinaire code-rot, waardoor elk aanpassing
> in de code ervoor zorgt dat er ergens anders weer wat omdondert.

elk willekeurig verandering aan zo'n systeem loopt hetzelfde risico, dat 
is niet voorbehouden aan refactoring.

  groetjes, su.

"Nico Coesel" <nico@puntnl.niks> schreef in bericht 
news:41e98769.100171639@news.planet.nl...
>>- je code minder bug-gevoelig te maken door gelijksoortige code samen te
>>voegen, waardoor je eventuele bugs erin nog maar 1 keer hoeft te ontdekken
>>en op te lossen
>>- je code te hergebruiken, door dependency-management
>>- enz...
>
> Dus allemaal zaken rechtrekken die je eigenlijk al tijdens het ontwerp
> van de software had moeten doen?

hmmm, het is mijn ervaring dat je net zolang kunt ontwerpen als je wilt, 
ergens komt er altijd wel een manager die met z'n ego zijn ideeen gaat 
doordrammen of ie nou z'n handtekening heeft gezet of niet.

Dan is refactoring wel handig... 

Passero wrote:

> John Bokma schreef:
>> 
>> 
>>>Omdat het moeilijk/onmogelijk is zo'n perfect ontwerp te maken, 
>>>is de XP methodologie ontstaan die stelt dat je huidige code moet
>>>voldoen aan de huidige eisen (kan gecontroleerd worden mbv
>>>unit-tests) en vervolgens dmv refactoring de nieuwe/veranderde eisen
>>>in het ontwerp kunnen opgenomen worden.
>> 
>> 
>> En ik denk dat menig programmeur zo al heel wat jaartjes werkt. Ik
>> weet dat er ook mensen zijn die de voorkeur geven om iets helemaal
>> (wat is dat) uit te denken, en met alles rekening proberen te houden.
>> Maar in de praktijk komt zoiets dan (naar mijn mening) nooit van de
>> grond. 
>> 
> 
> Wel, wij hebben 2 jaar een project moeten maken met 3 mensen volgens
> het UP process. Dat hield in dat we eerst een volledig ontwerp moesten
> maken en das pas beginnen met coderen.

Zelf geef ik daar ook de voorkeur aan, zeker bij een ingewikkeld/groot 
project.

> Het sprak voor zich dat we daar
> dus heel veel tijd aan hebben verloren.

Dat is een foute gedachte. Ik ken inderdaad mensen die menen dat 
programmeren knopjes indrukken is, en dat het aantal toetsaanslagen per 
dag een maat is voor kwaliteit.

> HEt ontwerp hebben we te veel
> moeten aanpassen en zijn zeer laat kunnen beginnen met coderen.

En wellicht heb je zo bakken met tijd kunnen besparen in de codeerfase, 
waar je anders maar wat rond zat te kloppen, om er vervolgens achter te 
komen dat het weer eens niet goed is.

> IN de
> theorie hebben ze gezegd dat UP gebruikt wordt voor grote projecten
> met veel mensen en XP voor kleinere projecten met een kleinere groep 
> programmeurs.

Kan ik mij iets bij voorstellen.

> Volgens mij zijn 3 mensen en een projectje dat wij
> hebben moeten maken vrij kleinschalig. Waarom dan in godsnaam UP
> gebruiken :s

Om er mee te leren werken? Ik denk dat 10 studenten samen aan iets te 
laten werken erg lastig is. Mijn ervaring met samenwerken tussen 
studenten is dat je soms met 1 al het probleem hebt dat je collega niet 
op komt dagen en zo.
 
> Dit jaar hadden we dan nog eens als taak zo'n project te refactoren.
> Was wel leuk eigenlijk en toen had ik de commentaar gekregen dat ik al
> een deftig ontwerp had dus we hadden er weinig werk aan. (en dit kwam
> om eerlijk te zijn niet door op de manier te werken die ons opgelegd
> was maar door elk deel appart te ontwerpen en coderen, beginnen bij
> het belangrijkst, een beetje zoals XP maar we lieten dat niet zo
> uitschijnen). 

Ik heb een beetje het idee dat jij denkt dat programmeren dingen 
inkloppen is. Integendeel ;-)

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

Passero wrote:

> John Bokma schreef:

[ snip ]

>> Het is ook vaak lastig uit te leggen: ja, wat ik 3 maanden geschreven
>> heb werkte prima, maar als je die toeters en bellen er ook in wilt,
>> moeten we eventjes terug naar de tekentafel.
>> 
>> Voor een opdrachtgever klinkt dat als: deze DVD speler werkt niet op
>> de TV die je 3 maanden terug gekocht hebt, maar gelukkig hebben we nu
>> dit model in de aanbieding...
> 
> Kun je niet tegelijk toeters en bellen aanbrengen EN refactoren?

Mijn ervaring is dat dat vaak samen gaat. Bij het aanbrengen van een toeter 
of bel kom je er achter dat een bepaald stuk code net iets handiger had 
gekunt.

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

koos wrote:

> In nl.comp.programmeren John Bokma <postmaster@castleamber.com> wrote:
>> 
>> Ook in loondienst komt dit te veel voor. Ik heb ooit bij een zich
>> serieus neemend bedrijf gewerkt, en ik kreeg 650+ Perl modules op
>> mijn bord. Mag jij raden hoeveel documentatie er was. Oh, en
>> refactoring, ik denk dat alles weggooien en opnieuw beginnen een
>> betere oplossing was voor die rommel.
>> 
> weggooien kan nooit.

Oh zeker wel. En in dit geval was dat een prima advies. 
 
> Er is misschien in het verleden al miljoenen besteed aan die
> 650 modules

Ik denk dat de kosten van onderhoud en de tijd die een programmeur kwijt 
zou zijn aan uitbreidingen de initiele "ontwikkel"kosten wel eens 
behoorlijk in het niet doen vallen.

> en dus zijn die modules zoveel geld waard.

Maar ze kosten ook extreem veel. Ooit een hele dag bezig geweest om 3 
regels Perl code in te voegen. Aangezien er geen tijd was voor 
documentatie, als iemand anders mijn code zou moeten uitbreiden, kost 
dat ook weer een dag.

De modules stonden bol van de copy & paste code. Soms was dat een klein 
beetje geedit, soms was alleen de naam van een variabele verandert. Stel 
je voor, ik heb code soms op meer dan 5 plaatsen teruggezien.

> Later
> is er misschien ook nog voor tonnen aan gesleuteld

Oh, en niks gedocumenteerd, dus hoe meer er aan gerommeld wordt, hoe 
duurder het wordt.

> en daarmee
> is de waarde van het product gestegen. Zo wordt er gedacht.
> Als je alleen al praat over dingen weggooien (weggooien is
> ook refactoren), dan gooi je kapitaal weg en dat kan niet!

De vraag is wat kost meer: een rampproduct jaren draaiend proberen te 
houden, of opnieuw beginnen?

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

koos wrote:

> ... tenzij er sprake is van ordinaire code-rot, waardoor elk
> aanpassing in de code ervoor zorgt dat er ergens anders weer wat
> omdondert. En probeer dan de geldbetalers er maar eens van te
> overtuigen dat het de moeite loont om eens een maand met de bezem door
> de rotzooi te gaan..... 

Precies. Die brok code waar ik het over had was extreem slecht 
geschreven. Normaal is het b.v. gebruikelijk bij Perl om use strict en 
use warnings te gebruiken omdat dit bepaalde tikfouten kan detecteren. 
99% van die modules gebruikte dit dus niet. Een van de eerste dingen die 
ik deed was het dus aanzetten. Ik ben even kwijt hoeveel daadwerkelijke 
bugs ik daarmee gevonden heb.

Ander leuk verhaal: ik verving een programmeur. Die had afgesproken 
eerst nog even wat af te maken voor vertrek. Na een behoorlijke tijd 
kwamen we er achter dat hij alleen de code dichtgespijkert had, en de 
functionaliteit er voor een groot deel niet in zat. Omdat er totaal geen 
logica zat in de manier waarop dingen over modules was verdeeld. Sommige 
modules waren een vangnet voor een aantal niet gerelateerde functies, 
veel code was dubbel, en daarnaast was men ooit in het project 
overgeschakelt op een andere database. Met als gevolg dat in nogal een 
berg modules overbodige code stond (de oude code voor de database 
afhandeling hing overal nog rond).

Oh, en men "gebruikte" CVS. Een van de eerste dingen die ik deed was 
alles een commit geven. Voor sommige dingen was dat al weken niet meer 
gedaan. En tja, wat was er aangepast en waarom...

Na 1 week kreeg ik te horen dat het project stevig wat programmeurs had 
gehad, en niemand er langer dan een paar maanden op had gezeten.

Iemand die later aangenomen werd was jaloers dat ik op een Perl project 
zat, tot ik hem de code liet zien (eerst vond ie het nog meevallen..).

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

Passero wrote:
> Wel, wij hebben 2 jaar een project moeten maken met 3 mensen volgens
> het UP process. Dat hield in dat we eerst een volledig ontwerp
> moesten maken en das pas beginnen met coderen.

Welk proces bedoel je met het UP-proces? Bedoel je het Rational Unified 
Process? 

John Bokma wrote:
> Passero wrote:
>> Wel, wij hebben 2 jaar een project moeten maken met 3 mensen volgens
>> het UP process. Dat hield in dat we eerst een volledig ontwerp
>> moesten maken en das pas beginnen met coderen.
>
> Zelf geef ik daar ook de voorkeur aan, zeker bij een ingewikkeld/groot
> project.
>
>> Het sprak voor zich dat we daar
>> dus heel veel tijd aan hebben verloren.
>
> Dat is een foute gedachte. Ik ken inderdaad mensen die menen dat
> programmeren knopjes indrukken is, en dat het aantal toetsaanslagen
> per dag een maat is voor kwaliteit.


Zeker is dat een foute gedachte, maar ik associeer die juist meer met 
waterval-achtige methoden: eerst een paar maanden het ontwerp, en dan hoeft 
het alleen nog maar even uitgeprogrammeerd worden (testen wordt meestal 
overgeslagen).

Helaas blijkt dan tijdens het programmeren dat er zes maanden geleden toch 
iets onjuist gespecificeerd is, waardoor het ontwerp eigenlijk ongeschikt 
is, maar 'daar moet maar even omheen geprogrammeerd worden'.
Als dat stuk nou eerder ge-implementeerd was, had je eerder feedback, kon je 
het ontwerp bijwerken (aka refactoren), en de vervolgstappen in het project 
baseren op een juist ontwerp.

Het prettige aan een iteratief proces vind ik dus dat je er sneller achter 
komt of ontwerp-beslissingen al-dan-niet goed uitpakken. Zeker als je een 
klant hebt die actief volgt 'hoe het ermee staat'. Die kun je makkelijker 
een werkend stuk software voorleggen, dan een ontwerp.

>> IN de
>> theorie hebben ze gezegd dat UP gebruikt wordt voor grote projecten
>> met veel mensen en XP voor kleinere projecten met een kleinere groep
>> programmeurs.
>
> Kan ik mij iets bij voorstellen.

Waarbij ik mij nog wel eens afvraag wat oorzaak is en wat gevolg.

Groet, Jaap 

Jaap Beetstra wrote:

> John Bokma wrote:
>> Passero wrote:
>>> Wel, wij hebben 2 jaar een project moeten maken met 3 mensen volgens
>>> het UP process. Dat hield in dat we eerst een volledig ontwerp
>>> moesten maken en das pas beginnen met coderen.
>>
>> Zelf geef ik daar ook de voorkeur aan, zeker bij een
>> ingewikkeld/groot project.
>>
>>> Het sprak voor zich dat we daar
>>> dus heel veel tijd aan hebben verloren.
>>
>> Dat is een foute gedachte. Ik ken inderdaad mensen die menen dat
>> programmeren knopjes indrukken is, en dat het aantal toetsaanslagen
>> per dag een maat is voor kwaliteit.
> 
> Zeker is dat een foute gedachte, maar ik associeer die juist meer met 
> waterval-achtige methoden: eerst een paar maanden het ontwerp, en dan
> hoeft het alleen nog maar even uitgeprogrammeerd worden (testen wordt
> meestal overgeslagen).

maar dan wordt er een paar maanden nauwelijks een knop ingedrukt, en 
ligt het werk dus stil (hoor ik nu al).

> Helaas blijkt dan tijdens het programmeren dat er zes maanden geleden
> toch iets onjuist gespecificeerd is, waardoor het ontwerp eigenlijk
> ongeschikt is, maar 'daar moet maar even omheen geprogrammeerd
> worden'.

En dus wordt er weer even nagedacht (en geen knopjes ingedrukt) hoop ik.

> Als dat stuk nou eerder ge-implementeerd was, had je eerder
> feedback,

Maar dan moet je de rest allemaal inpassen op wat reeds geimplementeerd 
was. Daarnaast, feedback is nogal lastig als er een brokje af is (en het 
nog on the fly verzonnen is ook).

> kon je het ontwerp bijwerken (aka refactoren), en de
> vervolgstappen in het project baseren op een juist ontwerp.

Aangezien je geen idee hebt van wat het juiste ontwerp is (want dat 
wordt on the fly verzonnen)....

> Het prettige aan een iteratief proces vind ik dus dat je er sneller
> achter komt of ontwerp-beslissingen al-dan-niet goed uitpakken.

Dat kan alleen als er een ontwerp-fase aan vooraf ging.

> Zeker
> als je een klant hebt die actief volgt 'hoe het ermee staat'. Die kun
> je makkelijker een werkend stuk software voorleggen, dan een ontwerp.

In de bouw begint men ook direct met stenen metselen, want zo zien de 
kopers tenminste direct wat voor kleur de buitenmuur wordt, en kunnen ze 
alvast de kleur van hun naambordje en auto daarop afstemmen.

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

John Bokma wrote:
> Jaap Beetstra wrote:

> Maar dan moet je de rest allemaal inpassen op wat reeds
> geimplementeerd was.

Yep, geen probleem als je ontwerp goed is. Zo niet: tijd om te refactoren.

> Daarnaast, feedback is nogal lastig als er een
> brokje af is (en het nog on the fly verzonnen is ook).

Tsja, das nou eenmaal vrij essentieel aan feedback: je krijgt het alleen 
over werk dat al gedaan is (anders was het feed-forward :-). Gelukkig is 
goed ontworpen software flexibel, en kun je nog voldoende bijschaven.

>> kon je het ontwerp bijwerken (aka refactoren), en de
>> vervolgstappen in het project baseren op een juist ontwerp.
>
> Aangezien je geen idee hebt van wat het juiste ontwerp is (want dat
> wordt on the fly verzonnen)....

En je weet wel wat 'het' juiste ontwerp is als je er zonder feedback een 
paar maanden over nadenkt?

>> Het prettige aan een iteratief proces vind ik dus dat je er sneller
>> achter komt of ontwerp-beslissingen al-dan-niet goed uitpakken.
>
> Dat kan alleen als er een ontwerp-fase aan vooraf ging.

`Het` juiste ontwerp bestaat voor mij niet (slechte ontwerpen bestaan wel).
Terwijl ik bezig ben met het ontwikkelen van de software, krijg ik meer 
inzicht in de wensen/doelen/omstandigheden van de klant, en krijg ik een 
beter beeld van hoe de onderdelen van de software samen kunnen werken. Op 
basis daarvan stel ik het ontwerp steeds bij.

Een ontwerp _fase_ is mij te abstract. Ontwerpen is voor mij een continu 
proces, gestuurd door concrete wensen. Dat zijn zowel functionele wensen 
[emailtje naar klant als event zus-en-zo optreedt], als meer beheersmatige 
wensen [mail-adres klant makkelijk te configureren], als meer technische 
wensen [geen afhankelijkheid specifieke database-server]. Het best inzicht 
in al deze wensen heb ik op het moment dat ik met dat specifieke stukje 
functionaliteit bezig ben.

Dat betekent natuurlijk niet dat je als een idioot gaat zitten code-kloppen. 
Een halve dag naar het scherm turen en nadenken over een paar regels is geen 
uitzondering. Vaak is die tijd nog nuttig besteed ook. Maar een week of 
langer op papier zitten te frobelen helpt mij niet.

Maar dat kan voor jou anders liggen natuurlijk.

>> Zeker
>> als je een klant hebt die actief volgt 'hoe het ermee staat'. Die kun
>> je makkelijker een werkend stuk software voorleggen, dan een ontwerp.
>
> In de bouw begint men ook direct met stenen metselen, want zo zien de
> kopers tenminste direct wat voor kleur de buitenmuur wordt, en kunnen
> ze alvast de kleur van hun naambordje en auto daarop afstemmen.

Een huis bouwen is het uitvoeren van een herhaalbaar proces. Programmeren is 
het definieren van een herhaalbaar proces. (vrij naar 
http://c2.com/cgi/wiki?ProgrammingAintManufacturing ).

Groet, Jaap 

Jaap Beetstra wrote:

> John Bokma wrote:
>> Jaap Beetstra wrote:
> 
>> Maar dan moet je de rest allemaal inpassen op wat reeds
>> geimplementeerd was.
> 
> Yep, geen probleem als je ontwerp goed is.

Dat kan niet goed zijn, want men is al begonnen met programmeren zonder dat 
de ontwerpfase afgerond is (begreep ik uit je eerdere posting).

> Zo niet: tijd om te refactoren. 

En loop je het risico dat er te veel tijd in het refactoren gaat zitten.

Ikzelf ga voor een minimalistische maar goede ontwerpfase. Uit ervaring 
weet ik dat ff ontwerpen, dan beginnen, en tijdens het code kloppen je 
ontwerp bijwerken niet fantastisch werkt.

>> Daarnaast, feedback is nogal lastig als er een
>> brokje af is (en het nog on the fly verzonnen is ook).
> 
> Tsja, das nou eenmaal vrij essentieel aan feedback: je krijgt het
> alleen over werk dat al gedaan is (anders was het feed-forward :-).
> Gelukkig is goed ontworpen software flexibel,

Ik heb dat nog nooit gezien, flexibele software. Altijd als je iets wilt 
wat er net niet inzit kan je of de boel omgooien, of een wrapper schrijven.

> en kun je nog voldoende bijschaven. 

Te vaak: terug naar de ontwerptafel gezien. Kijk b.v. maar eens naar de 
Java classes over de loop van de tijd. (Date class, Swing, enz). Als het zo 
simpel was was er wel 1 mega library geport naar elke programmeertaal.

>>> kon je het ontwerp bijwerken (aka refactoren), en de
>>> vervolgstappen in het project baseren op een juist ontwerp.
>>
>> Aangezien je geen idee hebt van wat het juiste ontwerp is (want dat
>> wordt on the fly verzonnen)....
> 
> En je weet wel wat 'het' juiste ontwerp is als je er zonder feedback
> een paar maanden over nadenkt?

Uit ervaring (21+ jaar) werkt eerst goed nadenken beter dan: laten we maar 
beginnen, we zien wel waar we stranden. In het laatste geval wordt er te 
vaak van alles bijverzonnen omdat de programmeur het een coole feature vind 
(of de manager). 

>>> Het prettige aan een iteratief proces vind ik dus dat je er sneller
>>> achter komt of ontwerp-beslissingen al-dan-niet goed uitpakken.
>>
>> Dat kan alleen als er een ontwerp-fase aan vooraf ging.
> 
> `Het` juiste ontwerp bestaat voor mij niet (slechte ontwerpen bestaan
> wel).

Het juiste ontwerp is er een die minimaal gezeur geeft, en bestaat dus wel 
degelijk. Een ontwerp is altijd beperkt tot de mogelijkheden. Dat er 
achteraf een beter is, tja, dat is normaal.

> Terwijl ik bezig ben met het ontwikkelen van de software, krijg
> ik meer inzicht in de wensen/doelen/omstandigheden van de klant,

Die wensen probeer ik altijd van te voren op papier te krijgen. Desnoods 
met schetsen en een prototype. Ik moet er niet aan denken dat ik tijdens 
het ontwikkelen een opdrachtgever heb die mij telkens gaat zitten bijsturen 
op van alles, of "John, kan dat 7 pixels naar rechts en in het rood?". Een 
GUI kan al gemaakt worden aan het begin, en daar hoef je nauwelijks voor te 
programmeren.

> en
> krijg ik een beter beeld van hoe de onderdelen van de software samen
> kunnen werken. Op basis daarvan stel ik het ontwerp steeds bij.

Ik moet er niet aan denken zo te moeten werken.

> Een ontwerp _fase_ is mij te abstract. Ontwerpen is voor mij een
> continu proces, gestuurd door concrete wensen.

Het grootste deel van die concrete wensen zijn van te voren al te krijgen.

> Dat zijn zowel
> functionele wensen [emailtje naar klant als event zus-en-zo optreedt],
> als meer beheersmatige wensen [mail-adres klant makkelijk te
> configureren], als meer technische wensen [geen afhankelijkheid
> specifieke database-server].

Die dingen kan je al verzinnen voor je een bit programmeerd. Ik moet er 
niet aan denken dat ik achteraf nog eventjes een "voer adres klant in" 
schermpje moet maken, omdat ik daar niet aan gedacht heb.

> Het best inzicht in al deze wensen heb ik
> op het moment dat ik met dat specifieke stukje functionaliteit bezig
> ben. 

En dat is naar mijn mening dus fout. Juist bovengenoemde zaken kan je *van 
te voren* bepalen.

> Dat betekent natuurlijk niet dat je als een idioot gaat zitten
> code-kloppen.

Zo klinkt het wel.

> Een halve dag naar het scherm turen en nadenken over een
> paar regels is geen uitzondering.

Ik doe dat liever niet achter het scherm, omdat dat dan roept om 
programmeren. Ik ga expres ergens anders zitten, met pen en papier :-D.

> Vaak is die tijd nog nuttig besteed ook.

Indien van te voren en zonder computer nog beter, is mijn jarenlange 
ervaring.

> Maar een week of langer op papier zitten te frobelen helpt mij
> niet. 

Wellicht omdat je dat zo aanvoelt, maar dat wil niet zeggen dat het waar 
is. Die week of langer op papier zitten frobelen kan jou ook misschien wel 
weken turen besparen. Achter het toetsenbord (is mijn ervaring) ga je vlug 
ff proberen.

> Maar dat kan voor jou anders liggen natuurlijk.

Ik gok dat ik geen uitzondering ben. Ja, ik weet dat programmeurs een hekel 
hebben aan de papierfase, ik ook. En het lijkt zo onproduktief, want je 
maakt geen regel code. Maar nogmaals, mijn ervaring, het bespaard. En 
aangezien ik fixed price voor mijzelf werk, heb ik daar onderzoek naar 
gedaan :-D En zelfs scripts van honderd regels komen vaak tot stand na wat 
op papier te krabbelen, al is het maar een uurtje.

>> In de bouw begint men ook direct met stenen metselen, want zo zien de
>> kopers tenminste direct wat voor kleur de buitenmuur wordt, en kunnen
>> ze alvast de kleur van hun naambordje en auto daarop afstemmen.
> 
> Een huis bouwen is het uitvoeren van een herhaalbaar proces.

Onzin. Kijk maar eens naar de fouten die er in de bouw gemaakt worden. 
Daarnaast worden er regelmatig nieuwe ontwerpen gemaakt, en nieuw 
bouwmateriaal gebruikt. Daarnaast spelen er nog vreselijk veel andere 
factoren (grond, weer, enz). 

> Programmeren is het definieren van een herhaalbaar proces. (vrij naar 
> http://c2.com/cgi/wiki?ProgrammingAintManufacturing ).

Geen zin om te kijken, maar als je jouw vrije quote daar uit kan halen is 
dat dus onzin. Bij veel produktieprocessen worden regelmatig nieuwe dingen 
geintroduceerd, en dus nieuwe fouten gemaakt. Het enige verschil is dat een 
auto, huis, e.d. niet op een binaire waarde hangt. Het grote verschil 
tussen software en materie.

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

John Bokma wrote:
> Ik heb dat nog nooit gezien, flexibele software. Altijd als je iets
> wilt wat er net niet inzit kan je of de boel omgooien, of een wrapper
> schrijven.

En later zeg je dit:

> Het juiste ontwerp is er een die minimaal gezeur geeft, en bestaat
> dus wel degelijk. Een ontwerp is altijd beperkt tot de mogelijkheden.
> Dat er achteraf een beter is, tja, dat is normaal.

Voor mij liggen minimaal gezeur en flexibel dicht op elkaar. Software waar 
ik nieuwe functies aan kan toevoegen is flexibel, en geeft minimaal gezeur. 
Software waar ik niet de gewenste functies aan kan toevoegen, is niet 
flexibel, en geeft gezeur.
Die tweede categorie is makkelijk te herkennen.

Waarom zou je ontwerpen als het niet is om later wijzigingen door te kunnen 
voeren? Als dat lukt is je software toch flexibel?
Wat vind jij dan 'flexibele software'?

Groet, Jaap 

Jaap Beetstra wrote:

> John Bokma wrote:
>> Ik heb dat nog nooit gezien, flexibele software. Altijd als je iets
>> wilt wat er net niet inzit kan je of de boel omgooien, of een wrapper
>> schrijven.
> 
> En later zeg je dit:
> 
>> Het juiste ontwerp is er een die minimaal gezeur geeft, en bestaat
>> dus wel degelijk. Een ontwerp is altijd beperkt tot de mogelijkheden.
>> Dat er achteraf een beter is, tja, dat is normaal.

Klopt, ik spreek mijzelf niet tegen (denk ik).

> Voor mij liggen minimaal gezeur en flexibel dicht op elkaar.

Flexibel vind ik een editor gemaakt voor Perl, die opeens ook perfect 
werkt met elke willekeurige andere programmeertaal, taal, enz. Ok, nu 
niet allemaal Emacs roepen :-D.

Het juiste ontwerp voor een Perl editor is er een die minimaal gezeur 
geeft. (En ik betwijfel of die zomaar uit te breiden is),

> Software
> waar ik nieuwe functies aan kan toevoegen is flexibel,

Precies, en flexibiliteit bereik je niet met minimaal gezeur. Dat is 
bloed, zweet & tranen. Ontwerpen, prototype, terug naar de tekentafel, 
etc.

> en geeft minimaal gezeur.

Op het moment van toevoegen, klopt. Maar daarvoor heb je veel gezeur 
gehad. Wellicht een aantal complete rewrites en een berg hacks. Het 
toevoegen gaat altijd probleemloos als het van te voren voorzien was. En 
dan zat het of in het ontwerp, of heb je stiekem dingen aan zitten 
passen (ik sluit 100% geluk even uit).

> Software waar ik niet de gewenste functies aan kan
> toevoegen, is niet flexibel, en geeft gezeur.
> Die tweede categorie is makkelijk te herkennen.
> 
> Waarom zou je ontwerpen als het niet is om later wijzigingen door te
> kunnen voeren?

Om met minimaal gezeur een zo goed mogelijke oplossing te vinden voor 
een probleem. Ik ontwerp vaak software die daarna niet meer aangepast 
hoeft te worden. Of als het aangepast wordt is het meestal iets 
kosmetisch, of een bug fix.

Waarom zou je Emacs gaan zitten ontwerpen als je cat nodig hebt? En wat 
zou je aan cat toe willen voegen?

> Als dat lukt is je software toch flexibel?
> Wat vind jij dan 'flexibele software'?

Software die je probleemloos op elke nieuwe onverwachte situatie kan 
aanpassen met minimaal gezeur.

Als je iets weet hoor ik het graag :-D.

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

John Bokma wrote:
> Jaap Beetstra wrote:
>
>> John Bokma wrote:
>>> Ik heb dat nog nooit gezien, flexibele software. Altijd als je iets
>>> wilt wat er net niet inzit kan je of de boel omgooien, of een
>>> wrapper schrijven.
>>
>> En later zeg je dit:
>>
>>> Het juiste ontwerp is er een die minimaal gezeur geeft, en bestaat
>>> dus wel degelijk. Een ontwerp is altijd beperkt tot de
>>> mogelijkheden. Dat er achteraf een beter is, tja, dat is normaal.
>
> Klopt, ik spreek mijzelf niet tegen (denk ik).
>
>> Voor mij liggen minimaal gezeur en flexibel dicht op elkaar.
>
> Flexibel vind ik een editor gemaakt voor Perl, die opeens ook perfect
> werkt met elke willekeurige andere programmeertaal, taal, enz. Ok, nu
> niet allemaal Emacs roepen :-D.

Als je dat opeens weglaat, ben ik het met je eens. Een editor die zo aan te 
passen dat-ie ook werkt met een andere programmeertaal, in kortere tijd (zo 
kort mogelijk) dan een volledige rewrite.
Software die opeens buiten specs werkt ken ik ook niet, maar software die 
uit te breiden is zie ik gelukkig nog wel eens.

> Het juiste ontwerp voor een Perl editor is er een die minimaal gezeur
> geeft. (En ik betwijfel of die zomaar uit te breiden is),
>
>> Software
>> waar ik nieuwe functies aan kan toevoegen is flexibel,
>
> Precies, en flexibiliteit bereik je niet met minimaal gezeur. Dat is
> bloed, zweet & tranen. Ontwerpen, prototype, terug naar de tekentafel,
> etc.

Hee, prototype, code in de ontwerpfase :)

>> en geeft minimaal gezeur.
>
> Op het moment van toevoegen, klopt. Maar daarvoor heb je veel gezeur
> gehad. Wellicht een aantal complete rewrites en een berg hacks. Het
> toevoegen gaat altijd probleemloos als het van te voren voorzien was.
> En dan zat het of in het ontwerp, of heb je stiekem dingen aan zitten
> passen (ik sluit 100% geluk even uit).

Yep, het zat in het ontwerp, of ik heb zitten refactoren. Maar het ontwerp 
is bij mij niet het resultaat van een ontwerpfase, maar van continu 
ontwerpen tijdens een iteratief ontwikkelproces.

>> Software waar ik niet de gewenste functies aan kan
>> toevoegen, is niet flexibel, en geeft gezeur.
>> Die tweede categorie is makkelijk te herkennen.
>>
>> Waarom zou je ontwerpen als het niet is om later wijzigingen door te
>> kunnen voeren?
>
> Om met minimaal gezeur een zo goed mogelijke oplossing te vinden voor
> een probleem. Ik ontwerp vaak software die daarna niet meer aangepast
> hoeft te worden. Of als het aangepast wordt is het meestal iets
> kosmetisch, of een bug fix.
>
> Waarom zou je Emacs gaan zitten ontwerpen als je cat nodig hebt? En
> wat zou je aan cat toe willen voegen?

Mee eens.
Maar als een klant vraagt om UltraEdit, waarom zou ik hem dan een jaar laten 
wachten tot alles af is? Na twee weken (oid) kan hij NotePad krijgen, waar 
hij alvast zijn eerste klusjes mee kan doen. Na een maand of 2-3 heeft hij 
de 20% van de functies die hij 80% gaat gebruiken. Na een jaar het totaal. 
En zelfs al is het na 15 maanden, omdat refactoren meer tijd kost dan 
gedacht, dan heeft hij al 12 maanden lang op 80% kunnen werken, tegen anders 
3 maanden op 100%.

>> Als dat lukt is je software toch flexibel?
>> Wat vind jij dan 'flexibele software'?
>
> Software die je probleemloos op elke nieuwe onverwachte situatie kan
> aanpassen met minimaal gezeur.
>
> Als je iets weet hoor ik het graag :-D.

Hello, World :)

Elke nieuwe situatie is natuurlijk wat veel gevraagd, maar binnen de 
oorspronkelijke doelstelling van je software is dat prima mogelijk (met 
licht voorbehoud voor de definitie van minimaal en gezeur). Stukjes 
herontwerpen is weliswaar ook dan meestal nodig, maar geen probleem in mijn 
ogen.

Groet, Jaap 

Jaap Beetstra wrote:

> John Bokma wrote:

[snip ]

>> Flexibel vind ik een editor gemaakt voor Perl, die opeens ook perfect
>> werkt met elke willekeurige andere programmeertaal, taal, enz. Ok, nu
>> niet allemaal Emacs roepen :-D.
> 
> Als je dat opeens weglaat, ben ik het met je eens.

Dan zat het in het ontwerp ;-). Met opeens bedoel ik, de Perl editor is 
af, en plotseling blijkt die ook zonder de code aan te passen in te 
zetten als C, C#, XML enz editor, inclusief ondersteuning van de 
rarigheden van die talen (qua folding en kleuring b.v.).

> Een editor die zo
> aan te passen dat-ie ook werkt met een andere programmeertaal, in
> kortere tijd (zo kort mogelijk) dan een volledige rewrite.

Precies, en ik weet van geen software die dat doet. 

> Software die opeens buiten specs werkt ken ik ook niet,

Grappig, ik dacht juist dat alle software dat deed ;-)

> maar software
> die uit te breiden is zie ik gelukkig nog wel eens.

uit te breiden, ja. Probleemloos, nee. En als het uit te breiden is, is 
het vaak binnen nauwe grenzen. Zodra je iets verder wilt moet er altijd 
iets sneuvelen.

>> Precies, en flexibiliteit bereik je niet met minimaal gezeur. Dat is
>> bloed, zweet & tranen. Ontwerpen, prototype, terug naar de
>> tekentafel, etc.
> 
> Hee, prototype, code in de ontwerpfase :)

Ik heb hopelijk ook nergens beweerd dat dat niet mocht :-). Overigens 
mag dat prototype best een wegwerp iets zijn (b.v. een GUI gemaakt in 
een klik-klak programma).

>> En dan zat het of in het ontwerp, of heb je stiekem dingen aan zitten
>> passen (ik sluit 100% geluk even uit).
> 
> Yep, het zat in het ontwerp, of ik heb zitten refactoren. Maar het
> ontwerp is bij mij niet het resultaat van een ontwerpfase, maar van
> continu ontwerpen tijdens een iteratief ontwikkelproces.

Ik heb dat te vaak (ook bij mijzelf) fout zien gaan. De project-
documentatie is dan de source en zo. De documentatie is de source, alles 
is de source.

Mijn ervaring is dat bij veel projecten x tijd eerst niet achter de 
computer zitten flink tijd bespaard. En x tijd is dan niet 5 minuten :-
D.

> Maar als een klant vraagt om UltraEdit,

Dan stuur ik 'm naar www.ultraedit.com  :-D.

> waarom zou ik hem dan een jaar
> laten wachten tot alles af is? Na twee weken (oid) kan hij NotePad
> krijgen,

Nah, zie je nu wel dat eerst nadenken echt helpt? Notepad zit als source 
bij Visual C++ van MS. (Ik weet niet of het 100% de source is, maar wel 
een berg) ;-) Met een beetje snel hacken kan je vast na 1 week iets meer 
dan Notepad laten zien ;-)

> waar hij alvast zijn eerste klusjes mee kan doen. Na een
> maand of 2-3 heeft hij de 20% van de functies die hij 80% gaat
> gebruiken. Na een jaar het totaal. En zelfs al is het na 15 maanden,
> omdat refactoren meer tijd kost dan gedacht, dan heeft hij al 12
> maanden lang op 80% kunnen werken, tegen anders 3 maanden op 100%.

Maar goed, ik snap je verhaal, maar het kan volgens mij beter:

De klant vraagt om UlraEdit

Er wordt vervolgens een eisenpakket gemaakt, en uitgezocht wat de 
opdrachtgever precies wilt. (ca. 1-2 maanden).

Er wordt een prototype [1] gemaakt (dat kan zelfs getekende windows 
zijn, of iets met een GUI toolkit in elkaar gezet, of een hack op een 
bestaande (Open Source) editor [2]). Feedback wordt verder verwerkt.

Er wordt een ontwerp gemaakt wat volledig het eisenpakket afdekt van de 
opdrachtgever, ca. 1 maand.

1 maand coderen

Na 4-5 maanden heeft de opdrachtgever iets wat 100% aan de *nieuwe* 
eisen voldoet [3], maar geen UltraEdit is.

Klinkt wellicht gek, maar ik krijg regelmatig opdrachten waar men een 
vaag idee heeft van wat het moet worden, maar na een serieuze 
ontwerpfase komt er een ander, en ik hoor nogal eens beter, produkt uit.

Ik werk ook wel eens op jouw manier, maar ik merk dan dat dat altijd 
frustrerend werkt voor beide partijen. Het lijkt telkens bijna af, maar 
dan moet er net weer iets anders. En zeker met meerdere ontwikkelaars 
kan dat erg lastig worden, want wiens code moet omgehackt worden? Een 
mooi voorbeeld uit een grijs verleden:

In de GUI library was ergens een rekenfoutje gemaakt, en dingen moesten 
3 pixels opgeschoven (of zo iets, erg grijs verleden). Het voorstel was 
om dat probleem maar in de aanroepende code (ben even kwijt hoeveel 
bestandjes, maar veel) te fixen door ergens 3 af te halen (hoe ga je dat 
documenteren...) . De library ontwikkelaars hadden het namelijk te druk 
(met hun ego, of zo).


[1] Maak duidelijk dat het het topje van de ijsberg is, en niet bijna 
    klaar.

[2] Een van de dingen die ik altijd doe is uitzoeken hoeveel ik ergens 
    anders vandaan kan halen, al dan niet Open Source.

[3] Omdat alles tot in den treure is besproken is de kans dat het uit te 
    breiden is op nieuwe eisen redelijk.

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

Someone referred to as: John Bokma <postmaster@castleamber.com>
 has comitted the herein quoted text :

[giga-snip]

 
> [1] Maak duidelijk dat het het topje van de ijsberg is, en niet bijna 
>     klaar.
> [2] Een van de dingen die ik altijd doe is uitzoeken hoeveel ik ergens 
>     anders vandaan kan halen, al dan niet Open Source.
> [3] Omdat alles tot in den treure is besproken is de kans dat het uit te 
>     breiden is op nieuwe eisen redelijk.

Eigenlijk wil men Lisp, maar dat weet men alleen nog niet. ;-)


Cor

-- 
	Mortals say: God needed just 6 days to create the Universe
    So, Why do these mortals expect a computer to Make World in 6 seconds 
             Thou shall not worship any Operating System       

In nl.comp.programmeren Cor Gest <cor@clsnet.nl> wrote:
> 
> Eigenlijk wil men Lisp, maar dat weet men alleen nog niet. ;-)
> 
ja! hulde!

Lisp-code is van nature al gerefactored.


koos.

Cor Gest wrote:

> 
> Someone referred to as: John Bokma <postmaster@castleamber.com>
>  has comitted the herein quoted text :
> 
> [giga-snip]
> 
>  
>> [1] Maak duidelijk dat het het topje van de ijsberg is, en niet bijna
>>     klaar.
>> [2] Een van de dingen die ik altijd doe is uitzoeken hoeveel ik
>> ergens 
>>     anders vandaan kan halen, al dan niet Open Source.
>> [3] Omdat alles tot in den treure is besproken is de kans dat het uit
>> te 
>>     breiden is op nieuwe eisen redelijk.
> 
> Eigenlijk wil men Lisp, maar dat weet men alleen nog niet. ;-)

Ik ken Lisp te weinig, wel talen uit die richting (Miranda, Linda, Gofer, 
hoewel dat nu HUGS is iirc), ja, werkt erg prettig, nadeel is dat de markt 
er nog minder voor is dan voor Perl (is mijn gevoel).

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

John Bokma wrote:
> Jaap Beetstra wrote:
>> Software die opeens buiten specs werkt ken ik ook niet,
>
> Grappig, ik dacht juist dat alle software dat deed ;-)

Ik zag het zelf ook, maar pas toen ik het gepost had :)
Maar goed, voor een niet te ruime definitie van 'werken' dus.

>> maar software
>> die uit te breiden is zie ik gelukkig nog wel eens.
>
> uit te breiden, ja. Probleemloos, nee. En als het uit te breiden is,
> is het vaak binnen nauwe grenzen. Zodra je iets verder wilt moet er
> altijd iets sneuvelen.

Zoals ouwe bagger-code: refactoren die zooi :)

> De klant vraagt om UlraEdit
[snip zinnige dingen...]
> Na 4-5 maanden heeft de opdrachtgever iets wat 100% aan de *nieuwe*
> eisen voldoet [3], maar geen UltraEdit is.

Yep, in mijn voorbeeld ging ik er vanuit dat de wensen van de klant al 
duidelijk waren. Voor je begint met coden is het altijd zinnig om op een 
rijtje te hebben wat een klant uiteindelijk wil bereiken. Maar voor mij gaat 
dat niet erg de diepte in; dus niet ieder schermpje helemaal uitwerken, maar 
wel een overzicht van de verschillende functies.

> En zeker met meerdere
> ontwikkelaars kan dat erg lastig worden, want wiens code moet
> omgehackt worden? Een mooi voorbeeld uit een grijs verleden:
>
> In de GUI library was ergens een rekenfoutje gemaakt, en dingen
> moesten 3 pixels opgeschoven (of zo iets, erg grijs verleden). Het
> voorstel was om dat probleem maar in de aanroepende code (ben even
> kwijt hoeveel bestandjes, maar veel) te fixen door ergens 3 af te
> halen (hoe ga je dat documenteren...) . De library ontwikkelaars
> hadden het namelijk te druk (met hun ego, of zo).

Ontslag wil dan nog wel eens helpen, hebben ze opeens veel meer tijd :)
Maar goed, los daarvan, in zo'n geval zou ik gewoon de code van een ander 
aanpassen.

Groet, Jaap 

Jaap Beetstra wrote:

> John Bokma wrote:

[ UltraEdit ]

> Yep, in mijn voorbeeld ging ik er vanuit dat de wensen van de klant al
> duidelijk waren.

Ik kom dat nooit tegen :-D. In het slechtste geval is het "kan je zoiets 
maken" in het beste geval is er een idee. Hmmm.. het allerslechtste 
geval is als ik reeds "geproduceerde" code krijg.

> Voor je begint met coden is het altijd zinnig om op
> een rijtje te hebben wat een klant uiteindelijk wil bereiken.

Zeker, en dat kost veel tijd is mijn ervaring. En in die tijd kan ik 
niet programmeren. Soms heeft de opdrachtgever dan het gevoel dat het 
allemaal niet opschiet.

> Maar
> voor mij gaat dat niet erg de diepte in; dus niet ieder schermpje
> helemaal uitwerken,

Voor mij het allerliefst wel, ik vind het niks als ik halverwege 
allerlei andere wensen en dingen door moet voeren. Als het een ander 
kleurtje is, geen probleem, maar soms lijkt iets simpel voor de 
opdrachtgever maar kost het veel tijd voor de programmeur. (En die twee 
begrijpen elkaar vaak slecht qua tijd).

> maar wel een overzicht van de verschillende
> functies.

Voor mij is dat meestal de basis. Maar ik vind de (G)UI net zo 
belangrijk. En vaak draag ik ook nog wat ideeen aan :-D.
 
>> ... Het
>> voorstel was om dat probleem maar in de aanroepende code (ben even
>> kwijt hoeveel bestandjes, maar veel) te fixen door ergens 3 af te
>> halen (hoe ga je dat documenteren...) . De library ontwikkelaars
>> hadden het namelijk te druk (met hun ego, of zo).
> 
> Ontslag wil dan nog wel eens helpen, hebben ze opeens veel meer tijd
> :)

Tja, de libraries waren door een klein groepje mensen in elkaar gezet, 
en als je die buiten de deur zet ben je erg ver van huis.

> Maar goed, los daarvan, in zo'n geval zou ik gewoon de code van een
> ander aanpassen.

Dat kon nu net niet :-( Sterker het kleine groepje zorgde daar heel goed 
voor. En in zo'n geval is het vaak: de top (dat groepje zat er al een 
tijdje) v.s. de gewone programmeur.

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

Jaap Beetstra wrote:
> Waarom zou je ontwerpen als het niet is om later wijzigingen door te kunnen 
> voeren? Als dat lukt is je software toch flexibel?
> Wat vind jij dan 'flexibele software'?

Om het enigszins provocerend te stellen:
* Structuur ontstaat door het inperken van flexibiliteit
* Gebruiksgemak ontstaat door het toevoegen van structuur

Conclusie gebaseerd op bovenstaande beweringen:
* Gebruiksgemak ontstaat door het inperken van flexibiliteit.

Sjoerd

Sjoerd A. Schreuder wrote:
> Jaap Beetstra wrote:
>> Waarom zou je ontwerpen als het niet is om later wijzigingen door te
>> kunnen voeren? Als dat lukt is je software toch flexibel?
>> Wat vind jij dan 'flexibele software'?
>
> Om het enigszins provocerend te stellen:
> * Structuur ontstaat door het inperken van flexibiliteit
> * Gebruiksgemak ontstaat door het toevoegen van structuur
>
> Conclusie gebaseerd op bovenstaande beweringen:
> * Gebruiksgemak ontstaat door het inperken van flexibiliteit.

Yep. Maar het omgekeerde geldt niet: het inperken van flexibiliteit leidt 
niet automatisch tot gebruiksgemak.
Weten waar je de flexibiliteit wel moet beperken, en vooral waar niet, is 
voor mij de kunst van het ontwerpen.

Groet, Jaap 

Someone referred to as: John Bokma <postmaster@castleamber.com>
 has comitted the herein quoted text :

> >>     breiden is op nieuwe eisen redelijk.
> > 
> > Eigenlijk wil men Lisp, maar dat weet men alleen nog niet. ;-)
 
> Ik ken Lisp te weinig, wel talen uit die richting (Miranda, Linda, Gofer, 
> hoewel dat nu HUGS is iirc), ja, werkt erg prettig, nadeel is dat de markt 
> er nog minder voor is dan voor Perl (is mijn gevoel).

Inderdaad , het is zeker niet de meest gevraagd taal. 
Al zijn er vele implementaties en "smaakjes" lisp en scheme.  
Veelal voor specifieke toepassingen en xedit ;-))


Cor

-- 
	Mortals say: God needed just 6 days to create the Universe
    So, Why do these mortals expect a computer to Make World in 6 seconds 
             Thou shall not worship any Operating System       

In nl.comp.programmeren John Bokma <postmaster@castleamber.com> wrote:
>> 
>> Eigenlijk wil men Lisp, maar dat weet men alleen nog niet. ;-)
> 
> Ik ken Lisp te weinig, wel talen uit die richting (Miranda, Linda, Gofer, 
> hoewel dat nu HUGS is iirc), ja, werkt erg prettig, nadeel is dat de markt 
> er nog minder voor is dan voor Perl (is mijn gevoel).
> 
De markt voor Frans Bauer is hier ook groter dan die voor
Philip Glass.

Lisp is geweldig. Ik heb er uit eigen interesse - en omdat 
de dingen die *niet* in de markt liggen vaak veel leuker zijn
dan de dingen die *wel* in de markt liggen (zoals Frans Bauer) -
weleens mee zitten rommelen en Lisp is gewoon heel anders
dan anders.... In het begin zit je te zooien met lists
en functies, omdat je gewent bent wat functies te schrijven
en die vervolgens vanuit een main-functie een beetje
aan elkaar te klussen door er wat data naartoe te sturen.
In Lisp is dat heel anders. Alles is daar een lijst, ook
bijvoorbeeld een functie en alles is ook uitwisselbaar en 
functies kunnen dus gewoon weer functies teruggeven. En
je bouwt je programma eigenlijk op als een grote functie...
heel raar is dat.. je programmeert eigenlijk je eigen 
programmeertaal in Lisp.

Je moet maar eens common-lisp installeren en zo'n tutorial
bekijken.
http://www.cs.sfu.ca/CC/310/pwfong/Lisp/ is wel aardig.

Leuk spul; interessanter dan Visual Studio .NET Professional 
of Websphere Enterprise Edition (XML++). 


koos.

"koos" <koos@koos.nl> schreef in bericht
news:41ef5545$0$5325$e4fe514c@dreader5.news.xs4all.nl...
> Lisp is geweldig. Ik heb er uit eigen interesse - en omdat
> de dingen die *niet* in de markt liggen vaak veel leuker zijn
> dan de dingen die *wel* in de markt liggen (zoals Frans Bauer) -

Is Frans Bauer turing complete?

> weleens mee zitten rommelen en Lisp is gewoon heel anders
> dan anders.... In het begin zit je te zooien met lists
> en functies, omdat je gewent bent wat functies te schrijven
> en die vervolgens vanuit een main-functie een beetje
> aan elkaar te klussen door er wat data naartoe te sturen.
> In Lisp is dat heel anders. Alles is daar een lijst, ook
> bijvoorbeeld een functie en alles is ook uitwisselbaar en
> functies kunnen dus gewoon weer functies teruggeven. En
> je bouwt je programma eigenlijk op als een grote functie...
> heel raar is dat.. je programmeert eigenlijk je eigen
> programmeertaal in Lisp.

Lisp en scheme zijn vooral leuk voor de hobby en academisch. Het bedrijf
q-software-solutions
www.q-software-solutions.de maakt er professionele software en een editor
mee, al weet ik niet of dat een beetje loopt :)

>>Ik ken Lisp te weinig, wel talen uit die richting (Miranda, Linda, Gofer, 
>>hoewel dat nu HUGS is iirc)

Gofer is een van de voorlopers van Haskell, en Hugs is een 
Haskell-interpreter (die inderdaad voor een groot deel op de 
Gofer-interpreter is gebaseerd).

> 
> Lisp is geweldig. (...)

Ik ben inderdaad ook een fan van functionele programmeertalen zoals 
Lisp. Ik vind de syntax van bijv. ML (en afgeleiden) en Haskell echter 
veel prettiger (Lisp is toch al gauw een oerwoud aan haakjes).

groente
-- Sander

H. J. Sander Bruggink wrote:

> 
>>>Ik ken Lisp te weinig, wel talen uit die richting (Miranda, Linda,
>>>Gofer, hoewel dat nu HUGS is iirc)
> 
> Gofer is een van de voorlopers van Haskell,

Ik leerde het kennen als een Miranda cloon. Voor Miranda moest stevig 
betaald worden, dus op de UU aan de Gofer. Er was zelfs een RISC OS 
versie, dus kon ik er thuis ook mee werken :-D.

> en Hugs is een 
> Haskell-interpreter (die inderdaad voor een groot deel op de 
> Gofer-interpreter is gebaseerd).

Ik herinnerde het mij altijd als dat het iets als:

Miranda ......> Gofer \
                       ----> HUGS
Haskell ............../

Dus Gofer begon als een Miranda cloon, nam ook dingen van Haskell over 
(wellicht al eerder dan in de schets) en daar kwam HUGS uit.

Linda heb ik ooit gekregen als het parallel werkende zusje van Miranda.

> Ik ben inderdaad ook een fan van functionele programmeertalen zoals 
> Lisp. Ik vind de syntax van bijv. ML (en afgeleiden) en Haskell echter
> veel prettiger (Lisp is toch al gauw een oerwoud aan haakjes).

Ik ken Lisp een heeel klein beetje, en Miranda en co is een beetje 
weggezakt, maar ik ben het (voor zover dat kan) met je eens :-D.

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

In nl.comp.programmeren H. J. Sander Bruggink <sanderbruggink@hotmail.com> wrote:
> 
>>>Ik ken Lisp te weinig, wel talen uit die richting (Miranda, Linda, Gofer, 
>>>hoewel dat nu HUGS is iirc)
> 
> Gofer is een van de voorlopers van Haskell, en Hugs is een 
> Haskell-interpreter (die inderdaad voor een groot deel op de 
> Gofer-interpreter is gebaseerd).
> 
>> 
>> Lisp is geweldig. (...)
> 
> Ik ben inderdaad ook een fan van functionele programmeertalen zoals 
> Lisp. Ik vind de syntax van bijv. ML (en afgeleiden) en Haskell echter 
> veel prettiger (Lisp is toch al gauw een oerwoud aan haakjes).

eh...haakjes??? dat is toch een macro?

koos.

John Bokma wrote:
> Ik herinnerde het mij altijd als dat het iets als:
> 
> Miranda ......> Gofer \
>                        ----> HUGS
> Haskell ............../
> 
> Dus Gofer begon als een Miranda cloon, nam ook dingen van Haskell over 
> (wellicht al eerder dan in de schets) en daar kwam HUGS uit.


Van http://www.haskell.org/haskell-history.html:

"This variety of functional programming languages led to some confusion 
  and although each one has its specific features and advantages the 
need for a standard emerged. At the end of this process a brand-new 
programming language arose: Haskell."

Hugs is niet de enige Haskell-implementatie. GHC (een compiler) is 
volgens mij de meest bekende.


> (...) maar ik ben het (voor zover dat kan) met je eens :-D.
> 

Ik weet het, het is moeilijk te geloven, maar heel soms heb ik gewoon 
wel eens gelijk! ;-)

groente
-- Sander