Bezwaren tegen PHP als algemene programmeertaal

Rene Pijlman [on Sat, 29 May 2004 22:09:39 +0200] wrote:
> Erick T. Barkhuis:

> [elders]
> >....al vraag ik me af in welke situatie je zulke code nou weer zou willen
> >gebruiken.
>
> Het is toch een vrij bekend en veelgebruikt idioom.

Ongetwijfeld. Maar ik verzet me ertegen.

[Even een vraag alvorens verder te debatteren: zijn er threadvolgers in de
zaal die een beetje thuis zijn in Jackson Structured Programming (JSP)?]

--
Erick

"A father is someone who carries pictures where his money used to be."

Erick T. Barkhuis:
>[Even een vraag alvorens verder te debatteren: zijn er threadvolgers in de
>zaal die een beetje thuis zijn in Jackson Structured Programming (JSP)?]

Nee; vertel, vertel!

--
René Pijlman

"Wíj zullen onze verantwoordelijkheid nemen. Wij zullen díe stappen zetten
die gezet moeten worden."
- JP

John Bokma <postmaster@castleamber.com> wrote:

>Nico Coesel wrote:
>
>> John Bokma <postmaster@castleamber.com> wrote:
>>
>>>>>
>>>>>>Ik vind de documentatie uitstekend.
>>>>>>Alles wat ik ooit heb willen weten heb ik er in terug kunnen vinden.
>>>>>
>>>>>Nou, misschien kun je dan even op mijn inhoudelijk voorbeeld reageren.
>>>>
>>>>
>>>>Je bedoelt 'and' en '&&' ? Die zijn hetzelfde, staat toch duidelijk in
>>>>het tabelletje? De basis syntax van PHP is afgekeken C, maar de nogal
>>>
>>>s/C/Perl/;
>>>
>>>en in Perl zijn and en && *niet* hetzelfde. Je kan probleemloos een
>>
>> We hebben het over C, Pascal en PHP.
>
>Wie, wat waar? We hadden het over PHP, afgekeken van Perl. En in zowel
>PHP als Perl zijn and en && *niet* hetzelfde.

PHP is van alles afgekeken :-)

>>>" The reason for the two different variations of "and" and "or"
>>>operators is that they operate at different precedences. (See Operator
>>>Precedence.) "
>>
>> En als je nooit op operator precedence vertrouwd maar altijd -zoals
>> een goed programeur betaamt- haakjes gebruikt om de volgorde van
>> berekenen aan te geven doen ze dus altijd hetzelfde.
>
>Operator precendence is iets wat elke programmeur hoort te snappen. Of
>schrijf jij dingen als 5 + (3 * 7) op? Een *echt* goede programmeur
>schrijft leesbare code.

Ik gebruik altijd haakjes. a + (b*c) is veel duidelijker, meestal
draai ik dat soort expressies om: (b*c) + a. Ik ben overigens al
diverse compilers / talen tegengekomen waarbij 'meneer van dalen wacht
op anwoord' niet goed was geimplementeerd. Met haakjes werkt het
domweg altijd.
Ik ga er niet vanuit dat diegene die na mij naar de code zit te kijken
alle in's en out's van de taal weet. Ik ga er wel vanuit dat hoe
sneller diegene na mij mijn code kan hergebruiken of aanpassen hoe
beter, want het kost minder tijd = minder geld.

>>><http://www.php.net/manual/en/languag...rs.logical.php>
>>>
>>>Ben het overigens met Rene eens dat die "user comments" niet doorheen te
>>>komen is. En ik kon in de documentatie niet even vinden of and en && een
>>>short circuit doen (die user ruis er onder zie ik niet als een onderdeel
>>>van documentatie).
>>
>> Rene heeft een of ander forum te pakken. Je kunt beter bij
>> http://www.php.net/ de officiele documentatie downloaden.
>
>Die link boven schijnt de officiele documentatie te zijn. Als de
>downloaded zonder de ruis is, is die minimaal.

Maar wel afdoende (alles staat er echt in). En zelfs in deze minimale
vorm bestaat de documentatie uit bijna 4100 pagina's (nee, geen nul
teveel getikt) in PDF formaat.

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

In article <40b91336.455820535@news.planet.nl>, nico@puntnl.niks (Nico Coesel) wrote:
>
>Maar wel afdoende (alles staat er echt in). En zelfs in deze minimale
>vorm bestaat de documentatie uit bijna 4100 pagina's (nee, geen nul
>teveel getikt) in PDF formaat.

Aantal zegt natuurlijk niet alles over de kwaliteit en of het afdoende is,
daar ben ik het ook niet helemaal mee eens, maar ik moet zeggen dat ik de
documentatie erg uitgebreid vind. Vergeleken met bijv PEAR gedoe vind ik de
doc erg goed (en dan zie je gelijk dat de documentatie erg belangrijk is voor
een programmeertaal). De gebruikersbijdrage kan je evt nog net een stapje
verder helpen, maar soms ook niet, maar goed dat is met alle informatie die je
krijgt. Maar op details kan ie inderdaad beter (regexps bijvoorbeeld,
voor iemand zonder perlachtige kennis is dat vrij lastig.

Het lastigste vind ik dat je met een nieuwe versie er niet op kan vertrouwen
dat de scripts die je schrijft nog precies hetzelfde werken omdat het
programma in ontwikkleing is. Ook lastig is dat je bij zoeken in strings de
ene keer de naald in de hooiberg moet zoeken en de andere keer de hooiberg in
de naald uh eerst aan moet geven in welke hooiberg je wilt zoeken.

Jaap-Andre

Rene Pijlman [on Sat, 29 May 2004 23:00:46 +0200] wrote:
> Erick T. Barkhuis:
> >[Even een vraag alvorens verder te debatteren: zijn er threadvolgers in de
> >zaal die een beetje thuis zijn in Jackson Structured Programming (JSP)?]
>
> Nee; vertel, vertel!

Een programma-ontwerp-methode, redelijk populair in de jaren 80, alhoewel
al in 1970 bedacht. Erg rigide opgezet: alleen sequenties, selecties en
iteraties zijn toegestaan, en alles enkelvoudig.
Elementaire programma-opdrachten (statements) en stuurvoorwaarden (dat wat
tussen haakjes staat in de if/while/for-constructies) is secundair, en
wordt achteraf wel ingevuld. De _structuur_ die je data-stromen oplegt en
het verhaal dat de overeenkomsten vertellen bepalen de programmastructuur.

Met JSP zul je onmogelijk iets kunnen krijgen als
if (object.method() and o2.m2()) {...}
maar krijg je een verhaal dat je ook je tante kunt vertellen. Naar mijn
smaak veeeeeeel prettiger, zowel voor de programmeur als degene die straks
gaat onderhouden.
Maar het mooiste: (a and b) is net zo commutatief als a+b. Het maakte niet
uit in welke volgorde je het beschouwt.

JSP kent in Nederland, gok ik, nog slechts 1 enthousiaste aanhanger.
*snif*

--
Erick

"Every man who is high up likes to think he has done it all himself, and the
wife smiles and lets it go at that." - J.M. Barrie

Erick T. Barkhuis:
>Rene Pijlman:
>> W8ff, dat lijkt verdacht veel op de Nassi-Schneiderman diagrammen uit het
>> 1e-jaarscollege Inleiding Informatica.
>
>Nee, nee, nee.
>Die diagrammen zijn niet veel anders dan de basis "stroomdiagrammen" in
>een ander jasje.

Ho ho, nee nee. De crux van die Nassi-Schneiderman diagrammen is nu juist
dat alleen bepaalde gestructureerde constructies mogelijk zijn. Je kunt er
geen goto-spaghetti mee maken, wat met stroomdiagrammen wel kan.

>Maar goed....ik geloof niet dat dit een erg on-topic verhaal wordt. Laat
>gerust verzanden.

Waarin?

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Erick T. Barkhuis wrote:

> Met JSP zul je onmogelijk iets kunnen krijgen als
> if (object.method() and o2.m2()) {...}
> maar krijg je een verhaal dat je ook je tante kunt vertellen. Naar mijn

Mijn tante begrijpt prima als ik vraag: als het gas en de tv uit zijn, dan.

> smaak veeeeeeel prettiger, zowel voor de programmeur als degene die straks
> gaat onderhouden.
> Maar het mooiste: (a and b) is net zo commutatief als a+b. Het maakte niet
> uit in welke volgorde je het beschouwt.

func1() + func2() is niet commutatief als er side effects zijn.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/

Rene Pijlman wrote:

>>Maar goed....ik geloof niet dat dit een erg on-topic verhaal wordt. Laat
>>gerust verzanden.
>
> Waarin?

Momenteel denk ik aan strandzand :-D. 27.5 C, in huis.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/

Rene Pijlman [on Sun, 30 May 2004 19:27:49 +0200] wrote:
> Erick T. Barkhuis:
> >Rene Pijlman:
> >> W8ff, dat lijkt verdacht veel op de Nassi-Schneiderman diagrammen
> >
> >Die diagrammen zijn niet veel anders dan de basis "stroomdiagrammen" in
> >een ander jasje.
>
> Ho ho, nee nee. De crux van die Nassi-Schneiderman diagrammen is nu juist
> dat alleen bepaalde gestructureerde constructies mogelijk zijn. Je kunt er
> geen goto-spaghetti mee maken, wat met stroomdiagrammen wel kan.

Da's waar. Daarom zijn die NS-dingen iets beter. Maar ze komen niet
middels een _methode_ tot stand. Bovendien maak je zo'n N-S-ding omdat je
een programmastructuur wilt bedenken. Dat doe je niet in JSP.

JSP is echt een stappenplan, een methode, waarbij volgende stappen volgen
uit de vorige. Een beetje beta smult ervan, terwijl alfa's liever N-S-
grammetjes zullen maken.

> >Maar goed....ik geloof niet dat dit een erg on-topic verhaal wordt. Laat
> >gerust verzanden.
>
> Waarin?

In vergetelheid?

--
Erick
[die door JSP volstrekt anders naar programmeren is gaan
kijken....wellicht vanuit de verkeerde hoek, wie zal het zeggen?]

John Bokma [on Sun, 30 May 2004 12:44:51 -0500] wrote:

> Mijn tante begrijpt prima als ik vraag: als het gas en de tv uit zijn, dan.

Tuurlijk. Zou het die tante wat uitmaken in welke volgorde je die twee
voorwaarden noemt?

> > Maar het mooiste: (a and b) is net zo commutatief als a+b. Het maakte niet
> > uit in welke volgorde je het beschouwt.
>
> func1() + func2() is niet commutatief als er side effects zijn.

Exact.
Heb je de berichten in deze subthread een beetje gevolgd?

--
Erick

"Never argue with an idiot. They drag you down to their level,
then beat you with experience."

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:

>Nico Coesel:
>>Kortom: een dergelijk verhaal kun je over iedere programmeertaal
>>afsteken als je er maar niet genoeg van af weet.
>
>Tuurlijk Nico, zij wij hullie en de rest hebben er geen verstand van.
>Alleen jij hebt het licht gezien. Duidelijk.

Weer geen inhoudelijke argumenten... Noem nou eens een echt goed
argument waarom PHP niet geschikt zou zijn om er een applikatie mee te
ontwikkelen en C#, Perl en Java wel.

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

Erick T. Barkhuis <spamblok@webwax.nl> wrote:

>Rene Pijlman [on Sun, 30 May 2004 19:27:49 +0200] wrote:
>> Erick T. Barkhuis:
>> >Rene Pijlman:
>> >> W8ff, dat lijkt verdacht veel op de Nassi-Schneiderman diagrammen
>> >
>> >Die diagrammen zijn niet veel anders dan de basis "stroomdiagrammen" in
>> >een ander jasje.
>>
>> Ho ho, nee nee. De crux van die Nassi-Schneiderman diagrammen is nu juist
>> dat alleen bepaalde gestructureerde constructies mogelijk zijn. Je kunt er
>> geen goto-spaghetti mee maken, wat met stroomdiagrammen wel kan.
>
>Da's waar. Daarom zijn die NS-dingen iets beter. Maar ze komen niet
>middels een _methode_ tot stand. Bovendien maak je zo'n N-S-ding omdat je
>een programmastructuur wilt bedenken. Dat doe je niet in JSP.
>
>JSP is echt een stappenplan, een methode, waarbij volgende stappen volgen
>uit de vorige. Een beetje beta smult ervan, terwijl alfa's liever N-S-
>grammetjes zullen maken.

Ik heb hier een boek dat heet 'Strategies voor Real Time system
specification'. Het is geschreven door 2 mensen die systemen voor
vliegtuigen (ik dacht Boeing) ontwerpen en een methode zochten om het
ontwerpen op een gestructureerde wijze te doen. Zij kwamen erachter
dat 1 methode nooit voldoet. Een applikatie heeft namelijk toestanden
en verwerkt data. Daarom moeten zowel informatiestroom als de
toestanden worden beschrijven en er moet voor gezorgd worden dat beide
beschrijvingen met elkaar in overeenstemming zijn.

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

Erick T. Barkhuis:
>Rene Pijlman:
>> De crux van die Nassi-Schneiderman diagrammen is nu juist
>> dat alleen bepaalde gestructureerde constructies mogelijk zijn. Je kunt er
>> geen goto-spaghetti mee maken, wat met stroomdiagrammen wel kan.
>
>Da's waar. Daarom zijn die NS-dingen iets beter. Maar ze komen niet
>middels een _methode_ tot stand.

Dat is geen wet van meden en perzen. Het staat je vrij om met welke
methode dan ook Nassi-Schneiderman diagrammen te construeren. In de
informatica-opleidingen aan de Nederlandse universiteiten wordt dit vziw
niet aan een methode gekoppeld. Die grote nadruk op Methoden komt vooral
voort uit het dubieuze wereldje van zij-instromers in de ICT.

>JSP is echt een stappenplan, een methode, waarbij volgende stappen volgen
>uit de vorige.

Euh, je beweerde:

>>>>>>>>Met JSP zul je onmogelijk iets kunnen krijgen als
>>>>>>>> if (object.method() and o2.m2()) {...}"

.... en dat kan ik dan niet plaatsen. Hoe kan zo'n stappenplanmethode
verhinderen dat je op een bepaalde codeerconstructie komt?

>Een beetje beta smult ervan, terwijl alfa's liever N-S-grammetjes zullen
>maken.

Que? Het tegendeel is natuurlijk het geval, maar iets zegt me dat ik nu
getrolld wordt :-)

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Erick T. Barkhuis wrote:

> John Bokma [on Sun, 30 May 2004 12:44:51 -0500] wrote:
>
>>Mijn tante begrijpt prima als ik vraag: als het gas en de tv uit zijn, dan.
>
> Tuurlijk. Zou het die tante wat uitmaken in welke volgorde je die twee
> voorwaarden noemt?
>
>
>>>Maar het mooiste: (a and b) is net zo commutatief als a+b. Het maakte niet
>>>uit in welke volgorde je het beschouwt.
>>
>>func1() + func2() is niet commutatief als er side effects zijn.
>
> Exact.
> Heb je de berichten in deze subthread een beetje gevolgd?

Dat is duidelijk, toch? Dus zelfs met haakjes kom je er niet altijd, en
moet je *heel goed* weten wat je aan het doen bent :-D.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/

Nico Coesel wrote:

> Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>
>>Nico Coesel:
>>
>>>Kortom: een dergelijk verhaal kun je over iedere programmeertaal
>>>afsteken als je er maar niet genoeg van af weet.
>>
>>Tuurlijk Nico, zij wij hullie en de rest hebben er geen verstand van.
>>Alleen jij hebt het licht gezien. Duidelijk.
>
> Weer geen inhoudelijke argumenten... Noem nou eens een echt goed
> argument waarom PHP niet geschikt zou zijn om er een applikatie mee te
> ontwikkelen en C#, Perl en Java wel.

Dat je script gisteren nog perfect werkte, en nu ineens (overstap van
versie x.y.n naar x.y.(n + 1) niet meer? Of is dat inmiddels niet meer zo?

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/