John Bokma
24/03/05, 22:15
Nico Coesel wrote:
> John Bokma <postmaster@castleamber.com> wrote:
>>> Ik heb ook nooit beweerd dat je meteen grote complexe projecten moet
>>> aanpakken :-)
>>
>>Het probleem is dat het zo wel gaat in de praktijk. Een programmeur
>>krijgt zelden een project van 50 regels voor zijn kiezen (zie ook je
>>opmerking over DCOM etc.)
>
> 50 regels is wel erg weinig, maar je heb nou eenmaal ingewikkelde en
> eenvoudige problemen.
Als programmeur kom ik zelden niet complexe projecten tegen :-D. En
zelfs in 50 regels kan je een erg complex iets schrijven, en in 10,000
iets eenvoudigs :-D. Maar voor beiden geld: leer voor je begint.
>>om zelf documenterende code te maken, e.g.
>
> "zelf documenterende code" is net zoiets als zeggen dat God bestaat.
> Sommigen gloven er in en anderen niet, maar niemand heeft Hem ooit
> gezien.
Onzin natuurlijk.
>>print $_ * 2, "\n" for @numbers;
>
> Het onderste voorbeeld snap ik enigzins, maar het bovenste voorbeeld
> zegt mij helemaal niets.
Als je Perl wilt leren en je snapt die bovenste niet loop je erg snel
tegen problemen op :-D.
>>Yup, en dus omdat het op C lijkt begrijp jij het. Maar... iemand die
>>jaren Perl ervaring heeft moet dat stukje 2x lezen, en fixen :-D.
>
> Maar eigenlijk is het probleem van Perl dus dat het op C lijkt,
Tja, dat kan je van Java, Python, PHP enz ook wel zeggen :-D. Heel veel
programmeertalen lijken enorm op elkaar.
> maar
> dat Unix mensen die ervaring met (Ba)sh hebben er van oudsher op een
> shell script achtige manier mee programmeren en dat dat tot standaard
> is verheven. Te flexibel dus. :-)
Onzin. Niemand die serieus Perl programmeerd doet dat alsof het een
shellscript is. Vervang sh even door C, en Perl door een van de vele
talen met een C achtige syntax en je hebt 'm door.
>>"There once was a poor woodchopper. This wood chopping, he said one
>> day to his woman, there sits no dry bread in it. I work myself an
>> accident
>
> Slecht voorbeeld, want het is grammaticaal onjuist.
Waar zitten de grammaticale onjuistheden?
> Als je
> compiler/interpreter het snapt en het doet wat het functioneel moet
> doen, dan is het correcte code.
Voor de compiler, maar zeer zeker niet voor de programmeur.
>>> Bovendien worden simpele stukken code
>>> eerder hergebruikt dan ingewikkelde.
>>
>>Waarom?
>
> Omdat het eerder wordt begrepen. Ik heb de indruk dat je weinig in
> teamverband programmeert. Klopt dat?
Ik heb op diverse projecten met meerdere personen gezeten. Maar denk je
dat ik daar code ging zitten hergebruiken? Daar zijn libraries voor.
Ik ben ooit op een project gezet, en daar was inderdaad jouw manier van
code hergebruik: letterlijk dezelfde code op 20 plaatsen (echt waar),
*zelfs* in library onderdelen.
>>Code stop je achter een method, functie, subroutine. Hergebruik is dat
>>ding aanroepen. ( Of bedoel je knip en plak? )
>
> Helaas moeten de meeste stukken nog geinitialiseerd worden. Dus dan is
> enige kennis van de inwendige werking soms wel noodzakelijk.
Bij een goede library zit het inwendige verstopt. Initialisatie stappen
stop je in een functie, en je geeft parameters mee. Dat wordt uiteraard
gedocumenteerd.
>>Ok, ga jij in C++ C zitten programmeren omdat de "basis" is?
>
> Zo puristisch ben ik niet.
Maar waarom wel C in Perl?
>>Maar hoe moet dat dan met die andere programmeurs die niks van C++, OO
>>en zo snappen (maar wel heel "goedkoop" zijn, dat wel)
>
> Die hebben dan wat meer werk te doen om dat uit te zoeken.
Yup, en als ze op de on-the-fly manier gaan leren, en programmeren, wat
een bende gaat dat worden.
>>> OO blijkt voor velen nog een lastig te visualiseren
>>> concept
>>
>>Nee, de visualisatie is kinderlijk eenvoudig. Het probleem is dat de
>
> Voor jou en voor mij wel, maar je moet daar niet zomaar vanuit gaan.
Ik heb OO een paar maal aan een leek uitgelegd, en die snapte het
direct.
> Goed leren programmeren kost je ongeveer 8 tot 12 jaar.
Yup
> Met een opleiding alleen red je het niet.
Maar *zonder* een opleiding en het on-the-fly leren zeer zeker niet.
> Als je in teamverband werkt heb je
> dus te maken met junior en senior programmeurs en het is de bedoeling
> om het nivo van met name de junior programmeurs steeds een stapje
> hoger te tillen.
Precies!! En hoe krijg je dat voor elkaar? Door de lat hoger te liggen
dan een gemeenschappelijke we kloten maar aan in C als het op C lijkt.
>>> en dus lastig onderhoudbaar (vergt ook meer documentatie).
>>
>>Omdat?
>
> Als je procedureel programmeert, dan ontstaat er automatisch een
> bepaalde 'flow' in je programma. Bij een klasse is dat minder en heb
> je bovendien te maken met een hierarchie. Je zult dus minimaal op
> schrift moeten stellen hoe e.e.a. in elkaar steekt en hoe de gegevens
> door het programma vloeien.
Snap er niks van, of laat ik het zo zeggen, ik zie het verschil niet.
Tenzij je bedoelt: procedureel is alles in 1 bestandje knikkeren, en met
OO moet je 20 bestandjes aanmaken.
>>Je bedoelt wellicht dat een object 1 resource beheert, een singleton.
>>Niks mis mee, ook zonder OO zal je dat op een soortgelijke manier op
>>moeten lossen, en heeft dus niks met OO op zich van doen.
>
> Nee, maar het illustreert wel dat OO een lastiger concept is.
Het heeft *niks* met OO te maken. Exclusieve toegang zal je op een
manier exclusief moeten maken.
>>> Bovendien is het gebruik van OO geen Haarlemmer olie waarmee je alle
>>> problemen oplost.
>>
>>Oh, dat beweer ik ook niet, maar het is een beetje krom om het *nooit*
>>te gebruiken omdat je programmeurs allemaal op hetzelfde nivo moeten
>>werken, dat van de programmeur met de minste kennis.
>
> Misschien is het krom, maar het is wel praktisch. Als je achter een
> vrachtwagen rijdt, dan kun je ook niet harder dan 90.
Maar wat jij doet is die vrachtwagen 50 laten rijden omdat dat binnen de
bebouwde kom moet (IIRC, geen rijbewijs etc) ook als je buiten de
bebouwde kom zit.
>>Als je de taal niet beheerst heb je totaal geen idee of iets een
>>idioom is of niet. En ook heb je totaal geen idee of het dingen
>>efficient oplost. De stukken Perl en PHP die je hier en daar kan
>>bekijken bevestigen mijn verhaal. Kijk eens naar de PHP documentatie
>>*met* bezoekersbijdragen zou ik zeggen.
>
> Daarmee bevestig je mijn standpunt dat je code vooral eenvoudig moet
> houden omdat het voor velen toch lastig is.
Nee. Nogmaals: je moet het idioom van de taal leren, en *dat* gebruiken.
> De PHP documentatie met bezoekersbijdragen bekijk ik ook liever niet
> :-). Ik ben met je eens dat er veel rotzooi te vinden is. Ook bij
> API's waar dik voor betaald moet worden vind je voorbeelden die niet
> kloppen of nodeloos ingewikkeld zijn.
Yup, ik weet het. Maar dat wil niet zeggen dat je daar aan moet gaan
bijdragen.
>>En ik bezit meer dan redelijke kennis van Perl en C, en ik beweer nu
>>dat PHP leren door stukjes code van het net te plukken en een beetje
>>ombuigen de meest foute manier is om het te leren :-D
>
> Misschien werkt mijn methode voor mij heel goed en voor jou juist
> niet...
Ik betwijfel of: "leer" een taal door voorbeelden hier en daar bij
elkaar te plukken en verhef het laagste kennisnivo in je team tot
standaard ook maar voor iemand werkt.
De beginners komen zo nooit verder, en de mensen die wel verder willen,
kunnen dat niet, omdat die vrachtwagen maar niet opschiet.
--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html
> John Bokma <postmaster@castleamber.com> wrote:
>>> Ik heb ook nooit beweerd dat je meteen grote complexe projecten moet
>>> aanpakken :-)
>>
>>Het probleem is dat het zo wel gaat in de praktijk. Een programmeur
>>krijgt zelden een project van 50 regels voor zijn kiezen (zie ook je
>>opmerking over DCOM etc.)
>
> 50 regels is wel erg weinig, maar je heb nou eenmaal ingewikkelde en
> eenvoudige problemen.
Als programmeur kom ik zelden niet complexe projecten tegen :-D. En
zelfs in 50 regels kan je een erg complex iets schrijven, en in 10,000
iets eenvoudigs :-D. Maar voor beiden geld: leer voor je begint.
>>om zelf documenterende code te maken, e.g.
>
> "zelf documenterende code" is net zoiets als zeggen dat God bestaat.
> Sommigen gloven er in en anderen niet, maar niemand heeft Hem ooit
> gezien.
Onzin natuurlijk.
>>print $_ * 2, "\n" for @numbers;
>
> Het onderste voorbeeld snap ik enigzins, maar het bovenste voorbeeld
> zegt mij helemaal niets.
Als je Perl wilt leren en je snapt die bovenste niet loop je erg snel
tegen problemen op :-D.
>>Yup, en dus omdat het op C lijkt begrijp jij het. Maar... iemand die
>>jaren Perl ervaring heeft moet dat stukje 2x lezen, en fixen :-D.
>
> Maar eigenlijk is het probleem van Perl dus dat het op C lijkt,
Tja, dat kan je van Java, Python, PHP enz ook wel zeggen :-D. Heel veel
programmeertalen lijken enorm op elkaar.
> maar
> dat Unix mensen die ervaring met (Ba)sh hebben er van oudsher op een
> shell script achtige manier mee programmeren en dat dat tot standaard
> is verheven. Te flexibel dus. :-)
Onzin. Niemand die serieus Perl programmeerd doet dat alsof het een
shellscript is. Vervang sh even door C, en Perl door een van de vele
talen met een C achtige syntax en je hebt 'm door.
>>"There once was a poor woodchopper. This wood chopping, he said one
>> day to his woman, there sits no dry bread in it. I work myself an
>> accident
>
> Slecht voorbeeld, want het is grammaticaal onjuist.
Waar zitten de grammaticale onjuistheden?
> Als je
> compiler/interpreter het snapt en het doet wat het functioneel moet
> doen, dan is het correcte code.
Voor de compiler, maar zeer zeker niet voor de programmeur.
>>> Bovendien worden simpele stukken code
>>> eerder hergebruikt dan ingewikkelde.
>>
>>Waarom?
>
> Omdat het eerder wordt begrepen. Ik heb de indruk dat je weinig in
> teamverband programmeert. Klopt dat?
Ik heb op diverse projecten met meerdere personen gezeten. Maar denk je
dat ik daar code ging zitten hergebruiken? Daar zijn libraries voor.
Ik ben ooit op een project gezet, en daar was inderdaad jouw manier van
code hergebruik: letterlijk dezelfde code op 20 plaatsen (echt waar),
*zelfs* in library onderdelen.
>>Code stop je achter een method, functie, subroutine. Hergebruik is dat
>>ding aanroepen. ( Of bedoel je knip en plak? )
>
> Helaas moeten de meeste stukken nog geinitialiseerd worden. Dus dan is
> enige kennis van de inwendige werking soms wel noodzakelijk.
Bij een goede library zit het inwendige verstopt. Initialisatie stappen
stop je in een functie, en je geeft parameters mee. Dat wordt uiteraard
gedocumenteerd.
>>Ok, ga jij in C++ C zitten programmeren omdat de "basis" is?
>
> Zo puristisch ben ik niet.
Maar waarom wel C in Perl?
>>Maar hoe moet dat dan met die andere programmeurs die niks van C++, OO
>>en zo snappen (maar wel heel "goedkoop" zijn, dat wel)
>
> Die hebben dan wat meer werk te doen om dat uit te zoeken.
Yup, en als ze op de on-the-fly manier gaan leren, en programmeren, wat
een bende gaat dat worden.
>>> OO blijkt voor velen nog een lastig te visualiseren
>>> concept
>>
>>Nee, de visualisatie is kinderlijk eenvoudig. Het probleem is dat de
>
> Voor jou en voor mij wel, maar je moet daar niet zomaar vanuit gaan.
Ik heb OO een paar maal aan een leek uitgelegd, en die snapte het
direct.
> Goed leren programmeren kost je ongeveer 8 tot 12 jaar.
Yup
> Met een opleiding alleen red je het niet.
Maar *zonder* een opleiding en het on-the-fly leren zeer zeker niet.
> Als je in teamverband werkt heb je
> dus te maken met junior en senior programmeurs en het is de bedoeling
> om het nivo van met name de junior programmeurs steeds een stapje
> hoger te tillen.
Precies!! En hoe krijg je dat voor elkaar? Door de lat hoger te liggen
dan een gemeenschappelijke we kloten maar aan in C als het op C lijkt.
>>> en dus lastig onderhoudbaar (vergt ook meer documentatie).
>>
>>Omdat?
>
> Als je procedureel programmeert, dan ontstaat er automatisch een
> bepaalde 'flow' in je programma. Bij een klasse is dat minder en heb
> je bovendien te maken met een hierarchie. Je zult dus minimaal op
> schrift moeten stellen hoe e.e.a. in elkaar steekt en hoe de gegevens
> door het programma vloeien.
Snap er niks van, of laat ik het zo zeggen, ik zie het verschil niet.
Tenzij je bedoelt: procedureel is alles in 1 bestandje knikkeren, en met
OO moet je 20 bestandjes aanmaken.
>>Je bedoelt wellicht dat een object 1 resource beheert, een singleton.
>>Niks mis mee, ook zonder OO zal je dat op een soortgelijke manier op
>>moeten lossen, en heeft dus niks met OO op zich van doen.
>
> Nee, maar het illustreert wel dat OO een lastiger concept is.
Het heeft *niks* met OO te maken. Exclusieve toegang zal je op een
manier exclusief moeten maken.
>>> Bovendien is het gebruik van OO geen Haarlemmer olie waarmee je alle
>>> problemen oplost.
>>
>>Oh, dat beweer ik ook niet, maar het is een beetje krom om het *nooit*
>>te gebruiken omdat je programmeurs allemaal op hetzelfde nivo moeten
>>werken, dat van de programmeur met de minste kennis.
>
> Misschien is het krom, maar het is wel praktisch. Als je achter een
> vrachtwagen rijdt, dan kun je ook niet harder dan 90.
Maar wat jij doet is die vrachtwagen 50 laten rijden omdat dat binnen de
bebouwde kom moet (IIRC, geen rijbewijs etc) ook als je buiten de
bebouwde kom zit.
>>Als je de taal niet beheerst heb je totaal geen idee of iets een
>>idioom is of niet. En ook heb je totaal geen idee of het dingen
>>efficient oplost. De stukken Perl en PHP die je hier en daar kan
>>bekijken bevestigen mijn verhaal. Kijk eens naar de PHP documentatie
>>*met* bezoekersbijdragen zou ik zeggen.
>
> Daarmee bevestig je mijn standpunt dat je code vooral eenvoudig moet
> houden omdat het voor velen toch lastig is.
Nee. Nogmaals: je moet het idioom van de taal leren, en *dat* gebruiken.
> De PHP documentatie met bezoekersbijdragen bekijk ik ook liever niet
> :-). Ik ben met je eens dat er veel rotzooi te vinden is. Ook bij
> API's waar dik voor betaald moet worden vind je voorbeelden die niet
> kloppen of nodeloos ingewikkeld zijn.
Yup, ik weet het. Maar dat wil niet zeggen dat je daar aan moet gaan
bijdragen.
>>En ik bezit meer dan redelijke kennis van Perl en C, en ik beweer nu
>>dat PHP leren door stukjes code van het net te plukken en een beetje
>>ombuigen de meest foute manier is om het te leren :-D
>
> Misschien werkt mijn methode voor mij heel goed en voor jou juist
> niet...
Ik betwijfel of: "leer" een taal door voorbeelden hier en daar bij
elkaar te plukken en verhef het laagste kennisnivo in je team tot
standaard ook maar voor iemand werkt.
De beginners komen zo nooit verder, en de mensen die wel verder willen,
kunnen dat niet, omdat die vrachtwagen maar niet opschiet.
--
John Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Website design: http://johnbokma.com/websitedesign/
Ervaren Perl / Java programmeur beschikbaar: http://castleamber.com/
Tevreden opdrachtgevers: http://castleamber.com/testimonials.html