Site thuis hosten

Nico Coesel wrote:

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

> Als je niet kunt programmeren / software ontwerpen, dan wordt het
> nooit wat. Ongeacht de taal. Helaas zijn er nog vele webdesigners die
> het programmeren er nog wel even bij doen.

Omgekeerd ook :-D. Maar je mist mijn punt. Iemand die goed kan
programmeren en ff hop hop PHP leert in 3 dagen, die zal in het begin
zeer zeker niet goed PHP programmeren (of welke taal dan ook). Sterker,
ik beweer nu probleemloos dat die aankloot code gewoon na 3 maanden ook
door de uitvoerder als gekloot wordt aangemerkt (excuses voor het
Frans).

>>> In geval van een nieuwe
>>> taal zoek ik een voorbeeldje op voor de syntax en ik begin met
>>> programmeren van _mijn_ applicatie.
>>
>>Tja, en naar mijn niet zo heel erg bescheiden mening is dat de meest
>>foute manier om het te leren.
>
> Het is een vorm van extreme programming.

Extreem gekloot. Werkt prima voor u roept, wij draaien. Maar niet als
het over 3 maanden eens onderhouden moet worden. Ok, uitzondering zijn
kleine dingen, ook omdat je bij kleine dingen vaak min of meer op het
zelfde uitkomt.

Maar zodra het een groot project is, wordt het diepe tranen als er
mensen op werken die ff on-the-fly denken een taal te kunnen leren.

> Knip en plak je eerste
> programma in elkaar van bestaande code en focusseer alleen op de
> probleemgebieden.

Jaaa, heerlijk, ik heb zo een ding gezien met 650 perl modules. Na een
paar jaar was het probleemgebied de gehele applicatie. En wellicht ook
dat niemand er langer dan 3 maanden onderhoud op kon doen (ik verving de
vervanger of zoiets, en werd ook weer vervangen).

>>En dus "ontdek" jij een vreemd dialect. Leuk hoor, en ja, je krijgt
>>uiteindelijk wel iets werkend. Het vervelende is dat je code extreem
>>onleesbaar is voor iemand die wat langer in de taal zit.
>
> Juist niet, zie onder.

Vreemd, ik zie dat al zo'n 20 jaar in de praktijk gebeuren, ook bij
eigen werk als ik het op de door jouw omschreven manier doe.

>>Ik zie regelmatig dingen in Perl code (ik vertel zo de bron), a la:
>>
>>for ( $i = 0; $i < 100; $i++ ) {
>>
>> print("<td>\n");
>> printf("%d\n", @items[ $i ]);
>> print("</td>");
>>}
>
> Niets mis mee toch? Perfect juist;

Omdat je wellicht geen Perl kent. Voor iemand die dagelijks Perl
programmeert is dit dus extreem lastig te lezen. Daarnaast mankeren er
wat dingen aan.

> leesbaar voor iemand die ook C kent

Juist, en die zal dus de helft van mijn Perl, en Perl van elke
programmeur die het langer doet dan 2 jaar niet kunnen lezen. En
omgekeerd, zijn halve C pogingen maken de Perl code onleesbaar, en
ononderhoudbaar.

Door te zeggen dat ik ongelijk heb, bevestig je alleen maar mijn gelijk
:-D

> (en wellicht nog wat andere talen). Lekker standaard (C kun je toch
> min of meer als standaard beschouwen). Programma's moet je vooral
> standaard houden dan kan iedereen ze onderhouden.

Mis, bovenstaande code is extreem onhandig in Perl (ook omdat er een
foute aanname in zit, maar een die *juist* gemaakt wordt als een C
programmeur aan de Perl gaat).

> Mensen die langer met een programmeertaal bezig zijn gebruiken vaak
> allerlei truukjes en shortcuts. De ervaring leert dat juist het
> gebruik van deze truukjes en shortcuts het onderhoud aan software voor
> anderen lastig maakt.

Wiens ervaring? Ah, de ervaring van de onervaren programmeur. Oh, vast,
ik denk dat een C programmeur die Perl op de aankloot manier geleerd
heeft niet 1,2,3 dit snapt:

print "<td>\n$_\n</td>" for @items;

En toch is dit gelijk aan bovenstaande "C" gepruts (ff uitgegaan dat
@items 100 dingen bevat).

En sterker, het is nog leesbaarder ook: druk af voor alle dingen. Geen
zorgen om ondergrens, bovengrens, enz.

Ik ben het niet zo ver eens met Dijkstra, die ooit iets riep dat als
iemand ooit Basic had geprogrammeerd had die verloren was, maar iemand
die denkt dat Perl een soort C on acid is, is verkeerd bezig.

> De kans dat iemand naar je code kijkt die meer
> ervaring heeft dan jezelf is kleiner

In mijn geval met Perl of Java of straks Python, ja, zal vaak opgaan.
Maar die bovenstaande Perl = C prutser? Ik hoop van harte van niet.

> dan de kans dat iemand naar je
> code die minder ervaring heeft dan jezelf.

En zo filter je dus mensen die nog meer aankloten dus mooi uit als je
het op mijn manier doet. Ik bedoel, wie neemt er een zeer onervaren
programmeur aan die zo dom programmeert dat iemand met nog minder
ervaring het ook kan snappen? Hemeltje.

Ga jij in Java ook in C zitten programmeren, dus geen OO maar (want dat
is complex)? Iets van C is de ondergrens?

En merk op: ik promoot niet om de smart ass uit te hangen, dat zie ik
ook wel eens in code, iemand die denkt dat als het allemaal op 1 regel
past dat het dan helemaal mooi is.

Maar wel: gebruik idiomen die gangbaar zijn in de taal. De bovengenoemde
.... for .. is er zo een.

>>Ik kan in ca. 2 uur 2 Python boeken doorlezen, en na die 2 uur
>>"programmeren" in Python. Ik weet dan dat ik echter maanden nodig heb
>>om echt Python te produceren, en als ik de libraries wil gebruiken,
>>nog meer maanden.
>
> In het vakgebied waarin ik momenteel nog werkzaam ben, ben je dan
> compleet onbruikbaar :-)

Een klassieke vergissing. Vaak gedaan door mensen die menen dat
programmeren 12 uur lang knopjes indrukken is.

Op "jouw" manier leren programmeren betekent dat je alle nieuwe kennis
op te breken in brokken die dom genoeg zijn, en je leert dus in feite
niks nieuws. En als er vervolgens iemand naar kijkt die een paar jaar er
in zit, dan heeft die geen idee waar het gekloot over gaat.

> Deze week iets met DCOM objecten, volgende
> week iets met een seriele poort en de week daarna weer een of ander
> protocol dat via UDP berichten loopt en op Linux moet draaien. Als ik
> eerst alles zou lezen, dan zou ik alleen maar aan het lezen zijn en
> het werk komt niet af. Uit de documentatie pikken wat nodig is (en dat
> tot op het bot uitpluizen)

Ben je stiekem toch aan het lezen geslagen. Je kan iets pas overslaan
als je weet wat er staat natuurlijk.

Tenzij het totaal buiten hetgeen wat je nodig hebt valt, ik ga voorlopig
ook niet leren hoe ik C code met Python kan interfacen. Maar ik heb wel
gelezen dat het kan (en dus kan ik het opzoeken).

Jouw manier van leren klinkt mij te veel in de oren als:

nieuwe taal: ok, ik heb een variabele nodig, index.... variabele...
pagina 20. Ok, nu wil ik printen naar het scherm, print... print... ah,
ok, print... Nu wil ik een for loop... for... for...

> en de rest laten liggen is het devies.

En dus krijg je halfbrakke implementaties die vaak terugkomen als je
niet voldoende gelezen hebt. Je verschuift dan de ellende naar een later
tijdstip. Als je wel voldoende gelezen hebt, ben je het met mij eens
:-D.

> Een resultaat dat werkt, onder alle omstandigheden blijft werken en
> onderhoudbaar is, is veel belangrijker dan een efficient taalgebruik.

Ik hoop dat soort code niet vaak onder ogen te krijgen. De laatste keer
was erg genoeg.

Tenslotte, ik kom het ook wel eens tegen hoor, dat ik in erg korte tijd
iets onder de knie moet krijgen. Maar tot nu toe gemerkt dat het beter
werkt om er ff een dag voor te zitten (niet achter de computer vaak) en
het dan te programmeren (soms eerst op papier) dan:

met boek op de schoot trial en erreur until it workz ferry prima.

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

>Nico Coesel wrote:
>
>> John Bokma <postmaster@castleamber.com> wrote:
>
>> Als je niet kunt programmeren / software ontwerpen, dan wordt het
>> nooit wat. Ongeacht de taal. Helaas zijn er nog vele webdesigners die
>> het programmeren er nog wel even bij doen.
>
>Omgekeerd ook :-D. Maar je mist mijn punt. Iemand die goed kan
>programmeren en ff hop hop PHP leert in 3 dagen, die zal in het begin
>zeer zeker niet goed PHP programmeren (of welke taal dan ook). Sterker,
>ik beweer nu probleemloos dat die aankloot code gewoon na 3 maanden ook
>door de uitvoerder als gekloot wordt aangemerkt (excuses voor het
>Frans).
>
>>>> In geval van een nieuwe
>>>> taal zoek ik een voorbeeldje op voor de syntax en ik begin met
>>>> programmeren van _mijn_ applicatie.
>>>
>>>Tja, en naar mijn niet zo heel erg bescheiden mening is dat de meest
>>>foute manier om het te leren.
>>
>> Het is een vorm van extreme programming.
>
>Extreem gekloot. Werkt prima voor u roept, wij draaien. Maar niet als
>het over 3 maanden eens onderhouden moet worden. Ok, uitzondering zijn
>kleine dingen, ook omdat je bij kleine dingen vaak min of meer op het
>zelfde uitkomt.
>
>Maar zodra het een groot project is, wordt het diepe tranen als er
>mensen op werken die ff on-the-fly denken een taal te kunnen leren.

Ik heb ook nooit beweerd dat je meteen grote complexe projecten moet
aanpakken :-)

>> Knip en plak je eerste
>> programma in elkaar van bestaande code en focusseer alleen op de
>> probleemgebieden.
>
>Jaaa, heerlijk, ik heb zo een ding gezien met 650 perl modules. Na een
>paar jaar was het probleemgebied de gehele applicatie. En wellicht ook
>dat niemand er langer dan 3 maanden onderhoud op kon doen (ik verving de
>vervanger of zoiets, en werd ook weer vervangen).

Probleem is dan vaak niet de code, maar de documentatie. Hoe dom of
ingenieus een stuk software ook in elkaar zit, zonder documentatie kun
je geen onderhoud plegen.

>>>En dus "ontdek" jij een vreemd dialect. Leuk hoor, en ja, je krijgt
>>>uiteindelijk wel iets werkend. Het vervelende is dat je code extreem
>>>onleesbaar is voor iemand die wat langer in de taal zit.
>>
>> Juist niet, zie onder.
>
>Vreemd, ik zie dat al zo'n 20 jaar in de praktijk gebeuren, ook bij
>eigen werk als ik het op de door jouw omschreven manier doe.
>
>>>Ik zie regelmatig dingen in Perl code (ik vertel zo de bron), a la:
>>>
>>>for ( $i = 0; $i < 100; $i++ ) {
>>>
>>> print("<td>\n");
>>> printf("%d\n", @items[ $i ]);
>>> print("</td>");
>>>}
>>
>> Niets mis mee toch? Perfect juist;
>
>Omdat je wellicht geen Perl kent. Voor iemand die dagelijks Perl
>programmeert is dit dus extreem lastig te lezen. Daarnaast mankeren er
>wat dingen aan.

Ik heb weleens wat met Perl gedaan (kort programmaatje om wat gegevens
uit een database in een grafiek te zetten), maar dat is lang geleden.

>> leesbaar voor iemand die ook C kent
>
>Juist, en die zal dus de helft van mijn Perl, en Perl van elke
>programmeur die het langer doet dan 2 jaar niet kunnen lezen. En
>omgekeerd, zijn halve C pogingen maken de Perl code onleesbaar, en
>ononderhoudbaar.

Dat is meer een manier van opmaken en taalgebruik. Zoals het verschil
tussen het Nederlands dat de Nederlanders gebruiken en de Belgen. Wie
spreekt er nu fout Nederlands?

>> De kans dat iemand naar je code kijkt die meer
>> ervaring heeft dan jezelf is kleiner
>
>In mijn geval met Perl of Java of straks Python, ja, zal vaak opgaan.
>Maar die bovenstaande Perl = C prutser? Ik hoop van harte van niet.
>
>> dan de kans dat iemand naar je
>> code die minder ervaring heeft dan jezelf.
>
>En zo filter je dus mensen die nog meer aankloten dus mooi uit als je
>het op mijn manier doet. Ik bedoel, wie neemt er een zeer onervaren
>programmeur aan die zo dom programmeert dat iemand met nog minder
>ervaring het ook kan snappen? Hemeltje.

Je mist mijn punt. Het werkt juist andersom. Door 'dom' programmeren
houd je een stuk software over dat door meer en bovendien goedkopere
mensen onderhouden kan worden. Bovendien worden simpele stukken code
eerder hergebruikt dan ingewikkelde. Je hebt 3 manieren om een functie
te schrijven: de kortste, de langste en de eenvoudigste. De
eenvoudigste versie is het makkelijkste in onderhoud en ook het meest
robuust.

>Ga jij in Java ook in C zitten programmeren, dus geen OO maar (want dat
>is complex)? Iets van C is de ondergrens?

Ik ga geen uitspraak over Java doen omdat ik er echt nog nooit naar
gekeken heb.
Ik gebruik weleens OO in C(++), maar alleen als het de oplossing echt
makkelijker maakt. OO blijkt voor velen nog een lastig te visualiseren
concept en dus lastig onderhoudbaar (vergt ook meer documentatie).
Ik heb genoeg programma's van anderen gezien waarbij je een object
maar 1 keer kan instantieren omdat anders de globale variabelen dubbel
worden gebruikt of dat de instanties niet meer netjes op te ruimen
zijn.
Bovendien is het gebruik van OO geen Haarlemmer olie waarmee je alle
problemen oplost. Zoiets van 'met een grote hamer krijg je ook
schroeven in de muur'. OO heeft z'n nut maar ook z'n nukken.

>Jouw manier van leren klinkt mij te veel in de oren als:
>
>nieuwe taal: ok, ik heb een variabele nodig, index.... variabele...
>pagina 20. Ok, nu wil ik printen naar het scherm, print... print... ah,
>ok, print... Nu wil ik een for loop... for... for...

Nee, heb ik nooit gezegd. Mijn manier: voorbeelden (op internet)
opzoeken die lijken op hetgeen je wilt doen (voor een deelprobleem) en
dat gebruiken. Zie/leer je ook meteen de gebruikelijke idioom voor de
betreffende taal en welke elementen de taal biedt om bepaalde dingen
efficient op te lossen.

>Tenslotte, ik kom het ook wel eens tegen hoor, dat ik in erg korte tijd
>iets onder de knie moet krijgen. Maar tot nu toe gemerkt dat het beter
>werkt om er ff een dag voor te zitten (niet achter de computer vaak) en
>het dan te programmeren (soms eerst op papier) dan:

Dat is meer de manier van werken. Ik specificeer / documenteer altijd
vooraf wat m'n software moet doen. Zomaar ergens beginnen met
programmeren leidt nergens toe. Meestal heb ik Word openstaan om de
documentatie in lijn te houden met het programma en vice versa.

De discussie ging echter over PHP en ik ben nog steeds van mening dat
iemand die een redelijke kennis van C of Perl heeft makkelijk met PHP
overweg zou moeten kunnen.

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

Nico Coesel wrote:

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

[ snip ]

>>Maar zodra het een groot project is, wordt het diepe tranen als er
>>mensen op werken die ff on-the-fly denken een taal te kunnen leren.
>
> 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.)

[ snip ]
> Probleem is dan vaak niet de code, maar de documentatie. Hoe dom of
> ingenieus een stuk software ook in elkaar zit, zonder documentatie kun
> je geen onderhoud plegen.

Als er al geen tijd is om de taal door studie te leren, is er zeer zeker
geen tijd om documentatie te maken. Die dingen gaan een beetje hand in
hand. Als je de idiomen van een taal beheerst is het vaak heel eenvoudig
om zelf documenterende code te maken, e.g.

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

v.s.

for ( my $i = 0; $i < scalar @numbers; $i++) {

printf("%d\n", $numbers[ $i ] * 2);
}

[ snip slecht stukje Perl ]
> Ik heb weleens wat met Perl gedaan (kort programmaatje om wat gegevens
> uit een database in een grafiek te zetten), maar dat is lang geleden.

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.

>>Juist, en die zal dus de helft van mijn Perl, en Perl van elke
>>programmeur die het langer doet dan 2 jaar niet kunnen lezen. En
>>omgekeerd, zijn halve C pogingen maken de Perl code onleesbaar, en
>>ononderhoudbaar.
>
> Dat is meer een manier van opmaken en taalgebruik.

Nee, het is een keuze van gangbare uitdrukkingen in de taal. Het
volgende stukje illustreerd prima mijn verhaal:

"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
the whole day, but you and your twelve children have not to eat. - I see
the future dark in, his woman agreed. -We must try to fit a sleeve on
it, the woodchopper resumed. I have a plan: tomorrow we shall go on step
with the children, and then, in the middle of the wood, we'll leave them
to their fate over. His woman almost went of her little stick when she
heard this. -What is there with you on the hand, she cried, aren't you
good wise?" <http://www.ttoschool.nl/docs/pdf/esc...m_language.pdf>

> Je mist mijn punt. Het werkt juist andersom. Door 'dom' programmeren
> houd je een stuk software over dat door meer en bovendien goedkopere
> mensen onderhouden kan worden.

Yup, mensen die niet thuis zijn in de taal dus, in geen enkele taal maar
gewoon was basiskennis bij elkaar geplukt hebben van het net. (Geen MS
grappen, graag :-D ).

> Bovendien worden simpele stukken code
> eerder hergebruikt dan ingewikkelde.

Waarom?

Code stop je achter een method, functie, subroutine. Hergebruik is dat
ding aanroepen. ( Of bedoel je knip en plak? )

Of nog beter, je gebruikt een library. Een ander *enorm* bijkomend
probleem van mensen die, b.v. wel C kennen maar nauwelijks Perl, is dat
ze geen idee hebben van welke libraries er allemaal zijn. Dus of gaan ze
opzoek naar een C equivalent, of, wellicht vaker, maken ze een wiel dat
extra onderhoud oplevert, en niet eens lekker draait.

Ik ben zelf Python aan het leren: inmiddels 2 boeken doorgelezen. Het
volgende wordt de library reference.

> Je hebt 3 manieren om een functie
> te schrijven: de kortste, de langste en de eenvoudigste. De
> eenvoudigste versie is het makkelijkste in onderhoud en ook het meest
> robuust.

Wat een beginner de eenvoudigste vind is voor een ervaren programmeur
weer niet de eenvoudigste. Mijn Perl voorbeeld illustreerd dit erg mooi,
de "eenvoudigste" versie lijkt de C versie, maar is het niet: meer
regels, meer kans op fouten (naast die er al in zitten). Daarnaast loop
je het risico dat een ervaren programmeur dat soort dingen gaat zitten
fixen (en mogelijk fouten introduceert).

>>Ga jij in Java ook in C zitten programmeren, dus geen OO maar (want
>>dat is complex)? Iets van C is de ondergrens?
>
> Ik ga geen uitspraak over Java doen omdat ik er echt nog nooit naar
> gekeken heb.

Ok, ga jij in C++ C zitten programmeren omdat de "basis" is?

> Ik gebruik weleens OO in C(++), maar alleen als het de oplossing echt
> makkelijker maakt.

Maar hoe moet dat dan met die andere programmeurs die niks van C++, OO
en zo snappen (maar wel heel "goedkoop" zijn, dat wel)

> OO blijkt voor velen nog een lastig te visualiseren
> concept

Nee, de visualisatie is kinderlijk eenvoudig. Het probleem is dat de
meeste beginners half een boek lezen, en dan maar aan de slag gaan, en
dus dingen missen als: niet alles hoeft een is-a relatie te zijn, soms
is has-a veel beter etc. Ze missen het "wanneer wel en niet", en dan zie
je dus dat ze op een project beginnen met een basis class, en daar een
class opzetten, en nog een, en nog een en nog een, en nog een en nog
een.

> en dus lastig onderhoudbaar (vergt ook meer documentatie).

Omdat?

> Ik heb genoeg programma's van anderen gezien waarbij je een object
> maar 1 keer kan instantieren omdat anders de globale variabelen dubbel
> worden gebruikt of dat de instanties niet meer netjes op te ruimen
> zijn.

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.

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

> Nee, heb ik nooit gezegd. Mijn manier: voorbeelden (op internet)
> opzoeken die lijken op hetgeen je wilt doen (voor een deelprobleem) en
> dat gebruiken. Zie/leer je ook meteen de gebruikelijke idioom voor de
> betreffende taal en welke elementen de taal biedt om bepaalde dingen
> efficient op te lossen.

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.

Het is net als: ik ga Engels leren door ff wat webpagina's te bekijken.
Of ik ga HTML leren door ff de broncode van wat pagina's te bestuderen.

> De discussie ging echter over PHP en ik ben nog steeds van mening dat
> iemand die een redelijke kennis van C of Perl heeft makkelijk met PHP
> overweg zou moeten kunnen.

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

En verder, ik heb wat PHP gedaan, en nee, ik kan er niet makkelijk mee
overweg.

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

>Nico Coesel wrote:
>
>> John Bokma <postmaster@castleamber.com> wrote:
>
>[ snip ]
>
>>>Maar zodra het een groot project is, wordt het diepe tranen als er
>>>mensen op werken die ff on-the-fly denken een taal te kunnen leren.
>>
>> 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.

>[ snip ]
>> Probleem is dan vaak niet de code, maar de documentatie. Hoe dom of
>> ingenieus een stuk software ook in elkaar zit, zonder documentatie kun
>> je geen onderhoud plegen.
>
>Als er al geen tijd is om de taal door studie te leren, is er zeer zeker
>geen tijd om documentatie te maken. Die dingen gaan een beetje hand in
>hand. Als je de idiomen van een taal beheerst is het vaak heel eenvoudig
>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.

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

Het onderste voorbeeld snap ik enigzins, maar het bovenste voorbeeld
zegt mij helemaal niets.

>v.s.
>
>for ( my $i = 0; $i < scalar @numbers; $i++) {
>
> printf("%d\n", $numbers[ $i ] * 2);
>}
>
>[ snip slecht stukje Perl ]
>> Ik heb weleens wat met Perl gedaan (kort programmaatje om wat gegevens
>> uit een database in een grafiek te zetten), maar dat is lang geleden.
>
>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, 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. :-)

>>>Juist, en die zal dus de helft van mijn Perl, en Perl van elke
>>>programmeur die het langer doet dan 2 jaar niet kunnen lezen. En
>>>omgekeerd, zijn halve C pogingen maken de Perl code onleesbaar, en
>>>ononderhoudbaar.
>>
>> Dat is meer een manier van opmaken en taalgebruik.
>
>Nee, het is een keuze van gangbare uitdrukkingen in de taal. Het
>volgende stukje illustreerd prima mijn verhaal:
>
>"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. Als je
compiler/interpreter het snapt en het doet wat het functioneel moet
doen, dan is het correcte code.

>> Je mist mijn punt. Het werkt juist andersom. Door 'dom' programmeren
>> houd je een stuk software over dat door meer en bovendien goedkopere
>> mensen onderhouden kan worden.
>
>Yup, mensen die niet thuis zijn in de taal dus, in geen enkele taal maar
>gewoon was basiskennis bij elkaar geplukt hebben van het net. (Geen MS
>grappen, graag :-D ).
>
>> 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?

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

>>>Ga jij in Java ook in C zitten programmeren, dus geen OO maar (want
>>>dat is complex)? Iets van C is de ondergrens?
>>
>> Ik ga geen uitspraak over Java doen omdat ik er echt nog nooit naar
>> gekeken heb.
>
>Ok, ga jij in C++ C zitten programmeren omdat de "basis" is?

Zo puristisch ben ik niet. C++ of C maakt me eigenlijk geen moer uit.
C++ heeft wat leukere libraries erbij zitten en classes maken is wat
eenvoudiger.

>> Ik gebruik weleens OO in C(++), maar alleen als het de oplossing echt
>> makkelijker maakt.
>
>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.

>> 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.
Goed leren programmeren kost je ongeveer 8 tot 12 jaar. Met een
opleiding alleen red je het 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.

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

>> Ik heb genoeg programma's van anderen gezien waarbij je een object
>> maar 1 keer kan instantieren omdat anders de globale variabelen dubbel
>> worden gebruikt of dat de instanties niet meer netjes op te ruimen
>> zijn.
>
>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.

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

>> Nee, heb ik nooit gezegd. Mijn manier: voorbeelden (op internet)
>> opzoeken die lijken op hetgeen je wilt doen (voor een deelprobleem) en
>> dat gebruiken. Zie/leer je ook meteen de gebruikelijke idioom voor de
>> betreffende taal en welke elementen de taal biedt om bepaalde dingen
>> efficient op te lossen.
>
>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.
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. Maar als je een aantal
voorbeelden naast elkaar legt, dan ontstaat daar meestal wel idee uit
van wat het zou moeten zijn.

>> De discussie ging echter over PHP en ik ben nog steeds van mening dat
>> iemand die een redelijke kennis van C of Perl heeft makkelijk met PHP
>> overweg zou moeten kunnen.
>
>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...

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

Nico Coesel wrote:

> Pertinente onzin. Je kunt een Access database prima met meerdere
> gebruikers delen. Alleen krijg je boven een bepaald aantal gebruikers
> (10 of zo) en een bepaald aantal records (100000 dacht ik) performance
> problemen.

De opdrachtgever heeft gezegd dat het daar wel onder blijft. Maar goed,
dat verhaal heb ik vaker gehoord...

Maar ik kan het altijd nog zonder veel werk porten naar Interbase, dat
is een stuk steviger.

--
ir. J.C.A. Wevers // Physics and science fiction site:
johanw@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html