Leren programmeren [was Re: Site thuis hosten]

[John Bokma]

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

[Nico Coesel]

John Bokma <postmaster@castleamber.com> wrote:

>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.

Natuurlijk niet. Hoe kan code -iets om een 'machine' aan te sturen-
zelf documenterend zijn? Hoe kun je aan een complexe beschrijving van
een probleem (want dat is een programma) die vaak vele pagina's lang
is eenvoudig de structuur aflezen? Dat gaat domweg niet.
Zelfdocumenterende code is een regelrechte mythe die in het leven is
geroepen door of programmeurs die te lui zijn om spullen te
documenteren of programmeurs die zichzelf graag onmisbaar maken -punt-

>>>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.

Ik _wil_ helemaal geen cryptisch Perl leren. <rant modus> Leg dat stuk
code eens voor aan mensen die wel programmeren maar geen Perl kennen;
niemand die je kan vertellen wat het doet. Als je 2 jaar niets met
Perl heb gedaan, dan moet je opzoeken hoe het ook al weer zat. Sorry,
maar programma's waarbij ik later weer moet opzoeken hoe het ook
alweer zat wil ik niet maken.</rant modus>

>>>"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?

Ken jij wel Engels?
"This wood chopping, he said one
day to his woman, there sits no dry bread in it"

Bepalingen van plaats en tijd staan in het Engels altijd vooraan of
achteraan de zin, niet in het midden.

>> 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.

Wat heeft de compiler met de programmeur te maken? Wie specificeerd
hoe code eruit moet zien? Zie onderaan.

>>>> 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.

Ben ik met je eens. Maar waarom neem je aan dat _ik_ code zou knippen
en plakken? Ik heb het over hergebruik, hoe je daar knippen en plakken
van maakt is me een raadsel.

>>>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.

Helaas staan niet alle platformen toe een library van een grote reeks
parameters te voorzien vanwege geheugengebrek. Sterker nog, in sommige
toepassingen wil je de initialisatie het liefst als constantes in ROM
hebben zitten. Dan is het dus een kwestie van constantes aanpassen en
mee compileren. Nog steeds geen knippen en plakken.

>>>Ok, ga jij in C++ C zitten programmeren omdat de "basis" is?
>>
>> Zo puristisch ben ik niet.
>
>Maar waarom wel C in Perl?

Omdat het werkt. Lees bovendien eens:
<http://search.cpan.org/~nwclark/perl...yntax_overview>

>>>> 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.

Ging die leek ook meteen een programma maken?

>> 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.

Wie zegt dat ik het over mensen zonder opleiding heb? Weer een
onjuiste aanname.

>> 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.

Weer een aanname. Ik heb gezegd dat ik on-the-fly een taal toepas
omdat de syntax van de meeste talen sterk op elkaar lijken. Niet dat
anderen dat ook per definitie doen.

>>>> 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.

Nee, bij procedureel programmeren heb je een set data die wordt
bewerkt door een set functies. Bij OO heeft ieder element van de set
data (virtueel) zijn eigen set met functies. Procedureel programmeren
ligt dichter bij de natuur van de mens. In het dagelijks leven heb je
1 lichaam waarmee je je dagelijkse patroon afwerkt. Als je 10 brieven
moet schrijven, dan schrijf je 10 brieven achter elkaar met dat ene
lichaam. Zou je dat in een OO vorm gieten, dan zou je 10 lichamen
nodig hebben om 10 brieven te schrijven. (de volgorde van verwerken
even buiten beschouwing gelaten).
Iets dat verder van je natuur af staat, heeft meer beschrijving nodig
zoals 1+1 sneller is uit te leggen dan een differentiaal vergelijking.

>>>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.

Je gaat nu de technische kant van de zaak bekijken. Ik heb
geconstateerd dat een veel gemaakte fout is dat men niet alle
variabelen die bij een object horen in een object stopt met als
resultaat dat het object maar 1 keer te gebruiken is. Als iemand dat
doet, dan heeft die persoon OO nog niet onder de knie.

>>>> 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.

Dat is jouw aanname.

>>>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.

Ik zie daar vanuit technisch oogpunt absoluut het nut niet van in.
Code is correct als de compiler/interpreter het snapt en er correct
mee om gaat.
Vanuit onderhoudsoogpunt heb je wel gelijk, maar dan hangt het toe te
passen idioom af van je werkomgeving. Ieder bedrijf heeft zo z'n eigen
codeer conventies. Als die er niet zijn, dan doe je gewoon wat jezelf
het beste uitkomt.

>>>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.

Je trekt e.e.a. nu wel tot in het onwaarschijnlijke uit zijn verband.

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

[John Bokma]

Nico Coesel wrote:

> John Bokma <postmaster@castleamber.com> wrote:

[ snip zelfdocumenterende code ]

>>Onzin natuurlijk.
>
> Natuurlijk niet. Hoe kan code -iets om een 'machine' aan te sturen-
> zelf documenterend zijn? Hoe kun je aan een complexe beschrijving van
> een probleem (want dat is een programma) die vaak vele pagina's lang
> is eenvoudig de structuur aflezen? Dat gaat domweg niet.
> Zelfdocumenterende code is een regelrechte mythe die in het leven is
> geroepen door of programmeurs die te lui zijn om spullen te
> documenteren of programmeurs die zichzelf graag onmisbaar maken -punt-

Dat is hetzelfde als beweren: het recept op een pak bakmix is geen
documentatie hoe het te maken, want het beschrijft niet tot in detail
alle handelingen, en waar het aan te schaffen.

Onzin natuurlijk.

>>>>print $_ * 2, "\n" for @numbers;

[ snip ]

>>Als je Perl wilt leren en je snapt die bovenste niet loop je erg snel
>>tegen problemen op :-D.
>
> Ik _wil_ helemaal geen cryptisch Perl leren.

Dat is nu juist het probleem, het *is* geen cryptisch Perl. Je gezeur is
van hetzelfde nivo als iemand die malloc cryptisch vind, of casting, of
een reguliere expressie.

> <rant modus> Leg dat stuk
> code eens voor aan mensen die wel programmeren maar geen Perl kennen;

$_ krijgt een voor een elk element in het array @numbers. Dit print dus
elk element maal 2, gevolgt door een nieuwe regel teken.

>>> 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.
>
> Wat heeft de compiler met de programmeur te maken?

Dat zeg ik.

> Ben ik met je eens. Maar waarom neem je aan dat _ik_ code zou knippen
> en plakken? Ik heb het over hergebruik, hoe je daar knippen en plakken
> van maakt is me een raadsel.

Voor code hergebruik maakt het geen worst uit hoe de *interne* code er
uitziet, die zit nl. achter een API.

> Helaas staan niet alle platformen toe een library van een grote reeks
> parameters te voorzien vanwege geheugengebrek.

Kan ik mij niks bij voorstellen, tenzij er sowieso al geheugengebrek is.
Parameters kan je ook in een structure (by reference) meegeven.

> Sterker nog, in sommige
> toepassingen wil je de initialisatie het liefst als constantes in ROM
> hebben zitten. Dan is het dus een kwestie van constantes aanpassen en
> mee compileren. Nog steeds geen knippen en plakken.

En wat is het probleem?

c1 = 10;
c2 = 13;
c3 = 14;

object = new Thingy( c1, c2, c3);

>>>>Ok, ga jij in C++ C zitten programmeren omdat de "basis" is?
>>>
>>> Zo puristisch ben ik niet.
>>
>>Maar waarom wel C in Perl?
>
> Omdat het werkt.

Dat is geen reden.

[http://search.cpan.org/~nwclark/perl-
5.8.6/pod/perlintro.pod#Basic_syntax_overview]

En je punt is?

>>Ik heb OO een paar maal aan een leek uitgelegd, en die snapte het
>>direct.
>
> Ging die leek ook meteen een programma maken?

Je punt was: lastig te visualiseren. Je punt is?

>>> Met een opleiding alleen red je het niet.
>>
>>Maar *zonder* een opleiding en het on-the-fly leren zeer zeker niet.
>
> Wie zegt dat ik het over mensen zonder opleiding heb? Weer een
> onjuiste aanname.

Als die mensen een opleiding gehad hebben, hebben ze een studie gevolgt.
En ik gok dat dat niet was: neem je ongelezen boek mee op tentame, en
doe je best.

Bij tentames werd in mijn geval altijd de kennis getoetst, en niet of je
in taal A aan kon kloten.

>>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.
>
> Weer een aanname. Ik heb gezegd dat ik on-the-fly een taal toepas
> omdat de syntax van de meeste talen sterk op elkaar lijken.

Yup, en dat je het prima vond om C tot het hoogste nivo te verheffen,
was makkelijker voor beginners.

>>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.
>
> Nee, bij procedureel programmeren heb je een set data die wordt
> bewerkt door een set functies.

Goh, bij OO ook, alleen stop je het samen in 1 ding :-D

> Bij OO heeft ieder element van de set
> data (virtueel) zijn eigen set met functies.

Waarom?

Je kan prima 1 class maken die alleen hash-a doet, je set data. En een
set functies die daar op werken. Geen verschil met alles in 1 file
proppen bij C, of OO.

> Procedureel programmeren ligt dichter bij de natuur van de mens.

Hemeltje?

> In het dagelijks leven heb je
> 1 lichaam waarmee je je dagelijkse patroon afwerkt. Als je 10 brieven
> moet schrijven, dan schrijf je 10 brieven achter elkaar met dat ene
> lichaam. Zou je dat in een OO vorm gieten, dan zou je 10 lichamen
> nodig hebben om 10 brieven te schrijven. (de volgorde van verwerken
> even buiten beschouwing gelaten).

Kletskoek:

my $nb = new BrievenSchrijver();

$nb->schrijf_brief( $text1 );
$nb->schrijf_brief( $text2 );
:
:
$nb->schrijf_brief( $text10 );

Volgens mij snap jij bitter weinig van programmeren, of OO, of ik snap
er niks van.

>>Het heeft *niks* met OO te maken. Exclusieve toegang zal je op een
>>manier exclusief moeten maken.
>
> Je gaat nu de technische kant van de zaak bekijken. Ik heb
> geconstateerd dat een veel gemaakte fout is dat men niet alle
> variabelen die bij een object horen in een object stopt

Ja, dat kan ik snappen als men alleen maar C syntax mag gebruiken :-D.
(Of eigenlijk: ik snap het niet).

> met als
> resultaat dat het object maar 1 keer te gebruiken is. Als iemand dat
> doet, dan heeft die persoon OO nog niet onder de knie.

Tja, zo iemand zal vast ook een shared resource niet locken, en niet elk
gealloceerd object en resource vrijgeven.

>>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.
>
> Dat is jouw aanname.

Als je eist dat iedereen alleen C syntax in Perl gebruikt klopt dat
perfect.

>>Nee. Nogmaals: je moet het idioom van de taal leren, en *dat*
>>gebruiken.
>
> Ik zie daar vanuit technisch oogpunt absoluut het nut niet van in.

Da's inmiddels duidelijk.

> Vanuit onderhoudsoogpunt heb je wel gelijk,

Gelukkig.

> maar dan hangt het toe te passen idioom af van je werkomgeving.

Yup, programmeertaal en style guide.

> Ieder bedrijf heeft zo z'n eigen codeer conventies.

Yup, styleguide. Sommige zijn openbaar. Diverse talen hebben ook
styleguides opgesteld door soms de makers, soms enthousiastelingen.

> Als die er niet zijn, dan doe je gewoon wat jezelf het beste uitkomt.

Ik zou het opzoeken, en evt. aanpassen.

>>De beginners komen zo nooit verder, en de mensen die wel verder
>>willen, kunnen dat niet, omdat die vrachtwagen maar niet opschiet.
>
> Je trekt e.e.a. nu wel tot in het onwaarschijnlijke uit zijn verband.

Ik las ergens: programmeren in Perl beperken tot de C syntax. En dat was
schrikken.

--
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

[Nico Coesel]

John Bokma <postmaster@castleamber.com> wrote:

>Volgens mij snap jij bitter weinig van programmeren, of OO, of ik snap
>er niks van.

Ik heb zo'n 12 jaar ervaring en schrijf o.a. software die indien het
niet correct zou werken mensenlevens zou kunnen kosten of in een
minder erg scenario slechts een vette claim zou kunnen opleveren. Ik
zie programmeren slechts als een middel om een doordacht systeem te
implementeren in een 'informatie verwerkend apparaat'.
Ik denk dat jij programmeren ziet als een doel op zich.

Zullen we afspreken nooit samen aan een project te werken? :-)

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

[Erick T. Barkhuis]

Nico Coesel [on Tue, 29 Mar 2005 18:05:23 GMT] wrote:
> John Bokma <postmaster@castleamber.com> wrote:
>
> >Volgens mij snap jij bitter weinig van programmeren,

> Zullen we afspreken nooit samen aan een project te werken? :-)

Klinkt prima! Mag ik dan daarvan de projectleider zijn?

--
Erick

[John Bokma]

Nico Coesel wrote:

> John Bokma <postmaster@castleamber.com> wrote:
>
>>Volgens mij snap jij bitter weinig van programmeren, of OO, of ik snap
>>er niks van.
>
> Ik heb zo'n 12 jaar ervaring

Tja, ik 22, en nu?

> Ik denk dat jij programmeren ziet als een doel op zich.

Ik zie programmeren als iets dat maar weinig mensen goed kunnen leren,
en al helemaal niet met een boek op hun schoot, voorbeeldjes van het
Internet knippen en plakken.

En om altijd maar te programmeren in een soort minimale
gemeenschappelijke basis is net zo krom als x^7 als x * x * x * x * x *
x * x moeten schrijven omdat een paar mensen in een team geen
machtsverheffen hebben gehad.

> Zullen we afspreken nooit samen aan een project te werken? :-)

Klinkt goed, want ik programmeer graag Perl in Perl, en niet een soort C
wat enorme brokken onleesbare code opleverd.

Het mooie van Perl (en Python) vind ik dat ik bepaalde ideeen direct in
de taal om kan zetten. Het is zonde om dat naar een soort pseudo C om te
moeten zetten. Ik heb behoorlijk wat studietijd in functioneel
programmeren gestoken, en dan kan je dat soort dingen waarderen :-D.

--
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

[Daniel Tryba]

John Bokma <postmaster@castleamber.com> wrote:
> En om altijd maar te programmeren in een soort minimale
> gemeenschappelijke basis is net zo krom als x^7 als x * x * x * x * x
> * x * x moeten schrijven omdat een paar mensen in een team geen
> machtsverheffen hebben gehad.

Ehhh, van x*x*x... is het over het algemeen duidelijk wat het doet, als
ik x^7 zie in een programmeertaal lees ik een bitwise xor. Net zoals ik
bij << een shift lees. Echter betekenen die dingen buiten een
programmeertaal heel iets anders (en soms vergeet ik dat wel eens zodat
ik inderdaad x tot de macht 7 als x^7 schrijf met onverwachte gevolgen).

Je voorbeeld is dus een uitermate goed voorbeeld om rekening te houden
met een gemeenschappelijke basis.

[John Bokma]

Daniel Tryba wrote:

> John Bokma <postmaster@castleamber.com> wrote:
>> En om altijd maar te programmeren in een soort minimale
>> gemeenschappelijke basis is net zo krom als x^7 als x * x * x * x * x
>> * x * x moeten schrijven omdat een paar mensen in een team geen
>> machtsverheffen hebben gehad.
>
> Ehhh, van x*x*x... is het over het algemeen duidelijk wat het doet,
als
> ik x^7 zie in een programmeertaal lees ik een bitwise xor.

In wiskunde :-D Ik kon ff zo snel niet een superscript 7 vinden :-D

> Je voorbeeld is dus een uitermate goed voorbeeld om rekening te houden
> met een gemeenschappelijke basis.

Nee, omdat je het voorbeeld verkeerd las ;-)

Ik bedoel dus:

7
x schrijven als x . x . x . x . x . x . x

Overigens is wiskunde een prima voorbeeld waar "men" gek is op korte
notaties. Wellicht slikt men dat ook beter omdat nogal wat mensen
wiskunde leren door een boek door te nemen, en zo.

--
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

[Daniel Tryba]

John Bokma <postmaster@castleamber.com> wrote:
>> Ehhh, van x*x*x... is het over het algemeen duidelijk wat het doet,
> als
>> ik x^7 zie in een programmeertaal lees ik een bitwise xor.

Aiiii, je newsagent is broken, ga eens op zoek naar het oequotefix
equivalent voor je misbaksel.

> Ik bedoel dus:
>
> 7
> x schrijven als x . x . x . x . x . x . x

Dat is gewoon een decimale punt. het puntje van de vermenigvuldiging
staat veel hoger op de regel.

> Overigens is wiskunde een prima voorbeeld waar "men" gek is op korte
> notaties. Wellicht slikt men dat ook beter omdat nogal wat mensen
> wiskunde leren door een boek door te nemen, en zo.

Dan weet je vast ook dat x een betekenis heeft bij bv vectoren. Maar
voor wiskunde zijn de afspraken vrijwel universeel, voor
programmeertalen geldt dat niet echt.

> --

Aiii, nog een fout in je newsding.

[John Bokma]

Daniel Tryba wrote:

> John Bokma <postmaster@castleamber.com> wrote:

> Dat is gewoon een decimale punt. het puntje van de vermenigvuldiging
> staat veel hoger op de regel.

Als het nog steeds niet doorgedrongen is, wil ik je wel ff een pdfje
emailen.

> Dan weet je vast ook dat x een betekenis heeft bij bv vectoren.

Ja, ja, mooi hoor.

> Maar voor wiskunde zijn de afspraken vrijwel universeel,

vrijwel? Oh? Goh, hoera.

> voor programmeertalen geldt dat niet echt.

niet echt? Jeetje.

--
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

[Daniel Tryba]

John Bokma <postmaster@castleamber.com> wrote:
>> Dat is gewoon een decimale punt. het puntje van de vermenigvuldiging
>> staat veel hoger op de regel.
>
> Als het nog steeds niet doorgedrongen is, wil ik je wel ff een pdfje
> emailen.

Kom dan eens met voorbeelden die niet op allerlei manier kunnen worden
opgevat. Mailen hoeft niet, verwijzen naar characters in unicode is hier
veel makkelijker:

http://www.unicode.org/charts/PDF/U0080.pdf
00B7 ? MIDDLE DOT
= midpoint (in typography)
= Georgian comma
= Greek middle dot (ano teleia)
->0387 ? greek ano teleia
->2022 ? bullet
->2024 ? one dot leader
->2027 ? hyphenation point
->2219 ? bullet operator
->22C5 ? dot operator
->30FB ? katakana middle dot

>> Dan weet je vast ook dat x een betekenis heeft bij bv vectoren.
>
> Ja, ja, mooi hoor.

Goed he!

>> Maar voor wiskunde zijn de afspraken vrijwel universeel,
>
> vrijwel? Oh? Goh, hoera.

Mooie stof voor SF: wiskunde als universele taal.

>> voor programmeertalen geldt dat niet echt.
>
> niet echt? Jeetje.

En dan zijn we weer terug bij de gemeenschappelijke basis.

[John Bokma]

Daniel Tryba wrote:

> Mooie stof voor SF: wiskunde als universele taal.

http://en.wikipedia.org/wiki/Lojban

> En dan zijn we weer terug bij de gemeenschappelijke basis.

Dus: optellen, aftreken, vermenigvuldigen en delen.

--
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

[Nico Coesel]

John Bokma <postmaster@castleamber.com> wrote:

>Nico Coesel wrote:
>
>> John Bokma <postmaster@castleamber.com> wrote:
>>
>>>Volgens mij snap jij bitter weinig van programmeren, of OO, of ik snap
>>>er niks van.
>>
>> Ik heb zo'n 12 jaar ervaring
>
>Tja, ik 22, en nu?

Weten we dat we allebei professionals zijn.

>> Ik denk dat jij programmeren ziet als een doel op zich.
>
>Ik zie programmeren als iets dat maar weinig mensen goed kunnen leren,
>en al helemaal niet met een boek op hun schoot, voorbeeldjes van het
>Internet knippen en plakken.

Nu haal je een taal leren en leren programmeren door elkaar.
Programmeren is een vak, een programma maken een doel en een
programmeertaal is een dom stuk gereedschap.
Mijn stelling is en blijft dat wanneer je eenmaal kunt programmeren,
de taal er niet meer toe doet.

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

[John Bokma]

Nico Coesel wrote:

> John Bokma <postmaster@castleamber.com> wrote:

...

>>Ik zie programmeren als iets dat maar weinig mensen goed kunnen leren,
>>en al helemaal niet met een boek op hun schoot, voorbeeldjes van het
>>Internet knippen en plakken.
>
> Nu haal je een taal leren en leren programmeren door elkaar.

Om te leren programmeren zal je toch een (pseudo)taal moeten leren.

> Programmeren is een vak, een programma maken een doel en een
> programmeertaal is een dom stuk gereedschap.

Wat je niet kan leren door knip en plak, en een beetje aankloten.

> Mijn stelling is en blijft dat wanneer je eenmaal kunt programmeren,
> de taal er niet meer toe doet.

Maar dan zal je altijd klungelig programmeren, als je je beperkt tot een
basis C achtig dialect. En ik vraag mij af hoe je je dan red in talen als
Prolog, of Miranda.

--
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

[Hein van Dale]

Op 4 april 2005 22:33:14 GMT, blundert John Bokma <postmaster@castleamber.com>
en staat weer eens compleet voor lul:


>Maar dan zal je altijd klungelig programmeren, als je je beperkt tot een
>basis C achtig dialect. En ik vraag mij af hoe je je dan red in talen als
Hé sukkel, snap je het nog steeds niet, je bedoelt----------^dt!
> Prolog, of Miranda.

Elke boerenlul begrijpt het volgende ezelsbruggetje direct, nu
speciaal voor jou :-)))

De Nederlandse taal heeft een paar regeltjes die ZEER eenvoudig zijn. Als
je 1 keer de volgende krankzinnige regel leest dan vergeet je het de rest
van je leven niet meer!

Hij neukD, zij naaiD, er zwemD, hij rukD, zij doeD, het trekD, er waaiD
winT, hij copuleerD, masturbeerD, corrigeerD, onaneerD, verzorgD, pijpD,
befD, regelD, configureerD, er gebeurD, dit duiDD enz.

Sterkte sukkel!