Bezwaren tegen PHP als algemene programmeertaal

[Rene Pijlman]

Patrick:
[P: de makers hebben PHP bedoeld als algemene programmeertaal
RP: PHP is niet bedoeld als algemene programmeertaal]
>Ik zie alleen niet in waarom dat in het geval van PHP zo zou zijn.

Omdat PHP daar geen geschikte taal voor is. Het wordt voornamelijk
gebruikt voor het genereren van webpagina's en de hele evolutie van PHP
was daarop gericht.

Gaandeweg is het min of meer een programmeertaal geworden en dan zijn er
mensen van het type "if all you have is a hammer, everything looks like a
nail" die het voor algemeen programmeerwerk gebruiken. Maar daarvoor zijn
veel elegantere programmeertalen beschikbaar (tegenwoordig vooral: Java,
C#, Python).

Ik kan waarschijnlijk 100 voordelen van deze talen t.o.v. PHP bij elkaar
bedenken (maar dat ga ik niet doen), terwijl mij geen enkel voordeel van
PHP t.o.v. deze talen te binnen wil schieten.

De documentatie van PHP alleen al is zo weerzinwekkend slecht dat vrijwel
iedereen met een informaticadiploma fysieke symptomen van middeleeuwse
voedselziekten krijgt bij het lezen ervan.

Ik noem één piepklein voorbeeldje, dat ik in 12 seconden kon vinden. Wat
is volgens de documentatie de semantiek van de logische operatoren "and"
respectievelijk "&&"?
http://nl2.php.net/manual/en/language.operators.logical.php

En het ene A4'tje over Classes and Objects doet ook niet vermoeden dat dit
serieuze functionaliteit is.

Meer leesvoer over beperkingen van PHP:
http://www.ukuug.org/events/linux2002/papers/html/php/index.html

>Om eens enkele tegenvoorbeelden te geven:
>- http://freshmeat.net/projects/apamod/
>- http://freshmeat.net/projects/sfvchk/

Ik kan ook voorbeelden geven van mensen die een spijker in een plank slaan
met een schroevendraaier.

--
René Pijlman

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

[Branko Collin]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>, you wrote
on Fri, 28 May 2004 10:50:01 +0200:

>John Bokma:
>>Dat is toch dat blocks gemaakt worden met spaties? Dat overleef ik wel,
>
>Yep, de meeste bekwame programmeurs maken blocks met spaties (of tabs).

Nee hoor, getrainde apen maken blocks met spaties, daar zitten nogal
toevallig wat bekwame programmeurs tussen.

Whitespace heeft in de meeste programmeertalen, ook in Python, als
functie om programmeeratomen te scheiden. Daar een tweede, arbitrair
toegepaste functie aan toevoegen is waanzin. Dat is vergelijkbaar met
een link op een website zes dagen in de week naar broodjes.html te
laten verwijzen en op maandag naar kadetjes.html, en dat af te doen
met "de meeste bekwame webbezoekers snappen dit".

--
branko collin
- dr: "have you been exposed to any user interfaces designed by engineers?"
- woman: "yes"
- dr: "you have interface poisoning. you'll be dead within a week" (scott adams, dilbert)

[John Bokma]

Branko Collin wrote:

> Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>, you wrote
> on Fri, 28 May 2004 10:50:01 +0200:
>
>
>>John Bokma:
>>
>>>Dat is toch dat blocks gemaakt worden met spaties? Dat overleef ik wel,
>>
>>Yep, de meeste bekwame programmeurs maken blocks met spaties (of tabs).
>
>
> Nee hoor, getrainde apen maken blocks met spaties, daar zitten nogal
> toevallig wat bekwame programmeurs tussen.
>
> Whitespace heeft in de meeste programmeertalen, ook in Python, als
> functie om programmeeratomen te scheiden. Daar een tweede, arbitrair
> toegepaste functie aan toevoegen is waanzin.

Toch is Python hier *zeker* niet alleen in. IIRC doet Miranda, en vast
haar offsprings hier ook aan.

Ook in Perl kan whitespace soms heel significant zijn, overigens. Of of
er een tab of geen tab gebruikt wordt.

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

[John Bokma]

Patrick wrote:

> Ik gok trouwens dat het aantal hostingproviders dat PHP standaard
> ondersteunt, *net* iets groter is dan het aantal dat Python ondersteunt...

De mijne doet 't :-D

Nogal wat dingen op de gemiddelde GNU/Linux distro gebruiken Python.
Maar hier mag Rene verder over vertellen, want ik volg dat totaal niet :-D.

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

[John Bokma]

Patrick wrote:

> Windows beschikbaar (Mono verkeert nog in betafase, als ik het goed

Ik begreep dat Mono zichzelf kan compileren, en dat 1.0 ondersteund
wordt, na een vluchtige blik op de Mono site (ik wil er volgende week
tijd in gaan steken :-D)

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

[robert]

John Bokma <postmaster@castleamber.com>:
> Ook in Perl kan whitespace soms heel significant zijn, overigens.

Als scheiding van tokens wellicht, ja, net als elke andere programmeertaal.

> Of of er een tab of geen tab gebruikt wordt.

Heb je een voorbeeldje? Kan zo namelijk niks bedenken :)

--
robert

[Rene Pijlman]

Patrick:
>Je hebt de mogelijkheid de reclamefolder aan te passen als de inhoud
>volgens jou niet klopt ;-)

I know. Ben Wikipediaan.

>> Maar hier verschillen we fundamenteel van mening. De documentatie _is_ de
>> programmeertaal.
>
>Dat zou best kunnen :-)
>
>Als ik de definitie van een programmeertaal uit Wikipedia even aanhoud,
>dan is een programmeertaal een set van syntactische en semantische
>regels die gebruikt worden om computerprogramma's te definieren. Die set
>zal de ontwikkelaar van een taal, na het opstellen ervan (misschien
>rekende je dit ook al tot de documentatie?), enerzijds beschrijven in de
>documentatie en anderzijds implementeren. Wat mij betreft kan het dus
>best zo zijn dat je een slechte beschrijving hebt met een prima
>implementatie van de taal.

De taal is een abstractie. Die bestaat alleen door zijn documentatie. Als
de documentatie slecht is, dan is de taal slecht.

Stel ik bedenk een programmeertaal. Ik schrijf documentatie en een
compiler. Ik zet de compiler als download op Internet, stap met de
documentatie in het vliegtuig op weg naar mijn eerste User's Conference en
het vliegtuig crasht. Ik weg; documentatie weg. Bestaat de taal dan nog?
Ik vind van niet.

Wat is nu bijvoorbeeld de semantiek van 'and' vs '&&' in PHP? We weten het
niet. Tuurlijk, je kunt experimenteren met een implementatie en de
waarheidstabellen opstellen (en als je wakker bent: de computationele
neveneffecten). Maar dan ben je bezig met archeologie in plaats van
informatica. Bovendien kun je alleen maar hopen dat alle implementaties
hetzelfde doen.

>> Que? OO is het dominante model van deze tijd. Hoe kan een taal die dit
>> matig ondersteunt nu 'general purpose' zijn?
>
>Dan ben ik benieuwd wat voor definitie jij voor 'general purpose'
>hanteert?

OK, deze discussie loopt inderdaad spaak op gebrekkige definities.

>Je noemde de talen Java, C#, Python. Van Java gaf je zelf al aan dat het
>een flinke aanslag op de resources van je laptop was, C# is alleen voor
>Windows beschikbaar (Mono verkeert nog in betafase, als ik het goed
>heb). Python heb ik zoals gezegd geen ervaring mee. Dat zou wat mij
>betreft dan nog de enige overgebleven kandidaat zijn.

<promotie language="python">
Inderdaad. Ik programmeer er graag in.

Overigens afgezien van stijlkwesties (toegegeven, ik moest ook wennen aan
die indentering), ook vanwege het in de praktijk nogal bugvrij zijn van de
implementatie van de taal en de libraries. Met Java heb ik vreselijke
problemen gehad. C# heb ik geen ervaring mee.

En wat me aan Python bevalt is dat het voor vrijwel alle gangbare
toepassingen geschikt is. Voor ff een systeembeheerscriptje op zowel
Windows als Linux, voor GUI's, voor webapplicaties (Zope is machtig). Een
goede mix tussen het gemak van een scriptingtaal en de degelijke
constructies van een echte programmeertaal.
</promotie>

>Er is natuurlijk een verschil tussen hobby en professie

Huh?

>, voor sommigen dan ;-)

Oh :-)

--
René Pijlman

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

[Rene Pijlman]

John Bokma:
>Patrick:
>> Ik gok trouwens dat het aantal hostingproviders dat PHP standaard
>> ondersteunt, *net* iets groter is dan het aantal dat Python ondersteunt...
>
>De mijne doet 't :-D

Maar Patrick heeft gelijk dat Python relatief weinig ondersteund wordt in
standaard hosting pakketten.

>Nogal wat dingen op de gemiddelde GNU/Linux distro gebruiken Python.
>Maar hier mag Rene verder over vertellen, want ik volg dat totaal niet :-D.

Ik weet er ook niet zoveel van. De Red Hat installer geloof ik, Zope en
Mailman zijn helemaal (of grotendeels) in Python gebouwd.

Alleen kwa RAD-tools voor GUIs is het geloof ik nog matig, maar dat soort
software mijd ik als de pest.

--
René Pijlman

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

[John Bokma]

robert wrote:

> John Bokma <postmaster@castleamber.com>:
> > Ook in Perl kan whitespace soms heel significant zijn, overigens.
>
> Als scheiding van tokens wellicht, ja, net als elke andere programmeertaal.
>
> > Of of er een tab of geen tab gebruikt wordt.
>
> Heb je een voorbeeldje? Kan zo namelijk niks bedenken :)

my $voorbeeldje = <<'EOT'
bla bla
EOT

$voorbeeld =~ s/\t/x/g;

En ja, wel eens tegenaan gelopen :-D

Een andere bekende is een spatie achter de EOT, significant probleempje :-D.

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

[robert]

John Bokma <postmaster@castleamber.com>:
> robert wrote:
>
>> John Bokma <postmaster@castleamber.com>:
>>
>> > Ook in Perl kan whitespace soms heel significant zijn, overigens.
>>
>> Als scheiding van tokens wellicht, ja, net als elke andere
>> programmeertaal.
>>
>> > Of of er een tab of geen tab gebruikt wordt.
>>
>> Heb je een voorbeeldje? Kan zo namelijk niks bedenken :)
>
> my $voorbeeldje = <<'EOT'
> bla bla
> EOT
> $voorbeeld =~ s/\t/x/g;

Afgezien van dat dat op zich geen geldige constructie is (mist een ;) zie
ik het probleem niet. Tenzij je garbage-in, garbage-out bedoelt, maar dat
heeft weinig met Perl te maken.

> Een andere bekende is een spatie achter de EOT, significant probleempje
> :-D.

Ja, da's er eentje die het niet lekker doet. Gelukkig gebruik ik een editor
die dat signaleert ;)

--
robert

[Patrick]

Rene Pijlman wrote:
> I know. Ben Wikipediaan.

Wat doe je dan nog hier, aan de slag! ;-)

> Stel ik bedenk een programmeertaal. Ik schrijf documentatie en een
> compiler. Ik zet de compiler als download op Internet, stap met de
> documentatie in het vliegtuig op weg naar mijn eerste User's Conference en
> het vliegtuig crasht. Ik weg; documentatie weg. Bestaat de taal dan nog?
> Ik vind van niet.

Ik denk dat dit een zodanig filosofische discussie wordt, dat dit meer
iets voor nl.comp.programmeren is, of nl.filosofie natuurlijk :-)

[knip promotie python]

Dat klinkt op zich natuurlijk prima en ik zal er zodra ik de tijd er
voor kan vinden eens naar kijken. Ik verwacht echter niet dat ik het op
korte termijn ga gebruiken voor het ontwikkelen van webapplicaties,
inderdaad omdat bij de meeste hostingpakketten doorgaans PHP meegeleverd
wordt en geen Python.

Groeten,

Patrick

[John Bokma]

robert wrote:

> John Bokma <postmaster@castleamber.com>:
> > robert wrote:
> >
> >> John Bokma <postmaster@castleamber.com>:
> >>
> >> > Ook in Perl kan whitespace soms heel significant zijn, overigens.
> >>
> >> Als scheiding van tokens wellicht, ja, net als elke andere
> >> programmeertaal.
> >>
> >> > Of of er een tab of geen tab gebruikt wordt.
> >>
> >> Heb je een voorbeeldje? Kan zo namelijk niks bedenken :)
> >
> > my $voorbeeldje = <<'EOT'
> > bla bla
> > EOT
> > $voorbeeld =~ s/\t/x/g;
>
> Afgezien van dat dat op zich geen geldige constructie is (mist een ;) zie
> ik het probleem niet. Tenzij je garbage-in, garbage-out bedoelt, maar dat
> heeft weinig met Perl te maken.

De \t kan verloren raken met een editor die \t vervangt door spaties.
Weet niet meer of het omgekeerde ook voorkomt, ik meen mij vaag iets te
herinneren ooit een editor gebruikt te hebben die 8 spaties wel een tab
vond.

> > Een andere bekende is een spatie achter de EOT, significant probleempje
> > :-D.
>
> Ja, da's er eentje die het niet lekker doet. Gelukkig gebruik ik een editor
> die dat signaleert ;)

Die ik gebruik stript spaties weg. Kan ook mis gaan als je om een of
andere reden per se spaties achter bla bla wilt hebben.

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

[robert]

John Bokma <postmaster@castleamber.com>:
> robert wrote:
>
>> Afgezien van dat dat op zich geen geldige constructie is (mist een ;)
>> zie ik het probleem niet. Tenzij je garbage-in, garbage-out bedoelt,
>> maar dat heeft weinig met Perl te maken.
>
> De \t kan verloren raken met een editor die \t vervangt door spaties.

Bedoel je de string '\t', of een tab-karakter? Want ik vind het niet echt
een goed idee een tab-karakter in RE's te gebruiken, daar heb je juist
metakarakters voor :)

--
robert

[John Bokma]

robert wrote:

> John Bokma <postmaster@castleamber.com>:
> > robert wrote:
> >
> >> Afgezien van dat dat op zich geen geldige constructie is (mist een ;)
> >> zie ik het probleem niet. Tenzij je garbage-in, garbage-out bedoelt,
> >> maar dat heeft weinig met Perl te maken.
> >
> > De \t kan verloren raken met een editor die \t vervangt door spaties.
>
> Bedoel je de string '\t', of een tab-karakter? Want ik vind het niet echt
> een goed idee een tab-karakter in RE's te gebruiken, daar heb je juist
> metakarakters voor :)

Ik bedoel een echt tab-teken voor dat bla bla.

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

[robert]

John Bokma <postmaster@castleamber.com>:
> robert wrote:
>
>> Bedoel je de string '\t', of een tab-karakter? Want ik vind het niet
>> echt een goed idee een tab-karakter in RE's te gebruiken, daar heb je
>> juist metakarakters voor :)
>
> Ik bedoel een echt tab-teken voor dat bla bla.

Ah, dat is dus ook iets wat ik in het algemeen niet doe, juist om problemen
te voorkomen. Maar syntactisch gezien maakt het voor Perl helemaal niks uit
of daar een tab of een paar spaties staan.

--
robert

[John Bokma]

robert wrote:

> John Bokma <postmaster@castleamber.com>:
> > robert wrote:
> >
> >> Bedoel je de string '\t', of een tab-karakter? Want ik vind het niet
> >> echt een goed idee een tab-karakter in RE's te gebruiken, daar heb je
> >> juist metakarakters voor :)
> >
> > Ik bedoel een echt tab-teken voor dat bla bla.
>
> Ah, dat is dus ook iets wat ik in het algemeen niet doe, juist om problemen
> te voorkomen. Maar syntactisch gezien maakt het voor Perl helemaal niks uit
> of daar een tab of een paar spaties staan.

Dat klopt, maar je kan er mooi mee op je snufferd gaan. BV als je in je
__END__ tab separated data hebt staan, en de tabs raken ergens (editor,
mail, website) verloren.

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

[robert]

John Bokma <postmaster@castleamber.com>:
> robert wrote:
>
>> Ah, dat is dus ook iets wat ik in het algemeen niet doe, juist om
>> problemen te voorkomen. Maar syntactisch gezien maakt het voor Perl
>> helemaal niks uit of daar een tab of een paar spaties staan.
>
> Dat klopt, maar je kan er mooi mee op je snufferd gaan. BV als je in je
> __END__ tab separated data hebt staan, en de tabs raken ergens (editor,
> mail, website) verloren.

Als ik dat in een stuk C-code, of desnoods een simpele tekstfile, doe loop
ik net zo hard het risico dat het mis kan gaan, dat heeft weinig met de
gebruikte programmeertaal te maken.

--
robert

[John Bokma]

robert wrote:

> John Bokma <postmaster@castleamber.com>:
> > robert wrote:
> >
> >> Ah, dat is dus ook iets wat ik in het algemeen niet doe, juist om
> >> problemen te voorkomen. Maar syntactisch gezien maakt het voor Perl
> >> helemaal niks uit of daar een tab of een paar spaties staan.
> >
> > Dat klopt, maar je kan er mooi mee op je snufferd gaan. BV als je in je
> > __END__ tab separated data hebt staan, en de tabs raken ergens (editor,
> > mail, website) verloren.
>
> Als ik dat in een stuk C-code, of desnoods een simpele tekstfile, doe loop
> ik net zo hard het risico dat het mis kan gaan, dat heeft weinig met de
> gebruikte programmeertaal te maken.

Inderdaad, maar bij Perl, zeker door het gebruik van Here documents,
__END__ c.q __DATA_ etc heb ik een vermoeden dat sneller de fout gemaakt
wordt.

Ok, de spatie achter EOT was een beter voorbeeld :-(

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

[Nico Coesel]

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

>Patrick:
>>De documentatie, alhoewel essentieel om fatsoenlijk te kunnen
>>programmeren, zegt wat mij betreft weinig over de kwaliteiten van de
>>programmeertaal zelf.
>
>Maar hier verschillen we fundamenteel van mening. De documentatie _is_ de
>programmeertaal.

Volgens mij heb je PHP 5 minuten bekeken, werkte het niet zoals je
verwachtte en vond je het slecht. Ik vind de documentatie uitstekend.
Alles wat ik ooit heb willen weten heb ik er in terug kunnen vinden.

>>Maar een programmeertaal kan natuurlijk zonder OO prima 'general purpose'
>>zijn.
>
>Que? OO is het dominante model van deze tijd. Hoe kan een taal die dit
>matig ondersteunt nu 'general purpose' zijn?

Hoe bedoel je matig? Je kunt heel goed OO programmeren in iedere taal
die pointers naar functies ondersteund (en PHP doet dat).

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

[Rene Pijlman]

Nico Coesel:
>Volgens mij heb je PHP 5 minuten bekeken

Je hebt kennelijk een kristallen bol.

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

--
René Pijlman

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

[Rene Pijlman]

John Bokma:
>Rene Pijlman:
>> John Bokma:
>>>Python op mijn computer gezet, wat kleine dingen gedaan
>>>enz. En toen was ik ineens in Mexico :-D
>>
>> Gut, die functionaliteit heb ik nog niet ontdekt. Welke functie moet je
>> daarvoor aanroepen?
>
>Eh, ik gok dat het ook met Python had gekund, maar ik gebruikte er MSN
>Messenger voor.

MSN Messenger... nooit gebruikt. Welk channel? En wat is dan precies de
message om te sturen?

--
René Pijlman

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

[John Bokma]

Rene Pijlman wrote:

> John Bokma:
>
>>Rene Pijlman:
>>
>>>John Bokma:
>>>
>>>>Python op mijn computer gezet, wat kleine dingen gedaan
>>>>enz. En toen was ik ineens in Mexico :-D
>>>
>>>Gut, die functionaliteit heb ik nog niet ontdekt. Welke functie moet je
>>>daarvoor aanroepen?
>>
>>Eh, ik gok dat het ook met Python had gekund, maar ik gebruikte er MSN
>>Messenger voor.
>
> MSN Messenger... nooit gebruikt. Welk channel?

:-D Het heeft geen channels in principe (a la IRC zeg maar). Je stopt
mensen in een contactlijst, en met elk kan je praten (text, of voice).
Je zou kunnen zeggen dat je een channel kan maken, want als je met 1
iemand chat heb je een prive-channel, en je kan er mensen bij plaatsen,
en een soort groepsgesprek houden, hoewel ik dat zelden doe.

De meeste mensen op mijn lijst ken ik overigens van een andere,
webbased, chat. Je moet dus een manier vinden om mensen op je lijstje te
krijgen :-D.

Het plezier van MSN hangt nauw samen met wie er op je lijstje staat,
natuurlijk. Ik vind het prettig dat mijn lijstje voor een groot deel
bestaat uit mensen die niet programmeren (in welke taal dan ook). In een
grijs verleden (ook recent eigenlijk) wel eens naar IRC gekeken, maar
dat vond ik minder leuk.

Je kan ook met een niet-MS client "MSN" op, maar dan heb je geen geluid
(gebruik ik zelden), en geen webcam (heel veel gebruikt).

Gaim ziet er netjes uit en ondersteund meerdere IM protocollen (Yahoo,
AIM, etc) en werkt op meerdere besturingssystemen. Ik vond Trillian ook
erg lekker werken (compact). En Miranda heb ik ooit vluchtig bekeken.
Messengers die meerdere protocollen ondersteunen zijn handig als je
kennisen / vrienden, van alles gebruiken. Aan de andere kant, bijna
iedereen op mijn lijst gebruikt messenger.

> En wat is dan precies de message om te sturen?

Dat hangt een beetje van de andere kant af ;-). Een webcam kan helpen ;-)

Een ander iets, kan vast ook in Python, is om een botje te maken, en
messenger als een soort console gebruiken. Een voordeel is dat messenger
een log kan maken. En andere mensen kunnen je botje gebruiken. Voor niet
secure dingen zou je zo remote dingen op je computer kunnen checken
vanaf een andere locatie.

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

[Nico Coesel]

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

>Nico Coesel:
>>Volgens mij heb je PHP 5 minuten bekeken
>
>Je hebt kennelijk een kristallen bol.
>
>>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
cryptische logische operatoren hebben ze ook een leesbare variant
gegeven voor de mensen die bijvoorbeeld een pascal achtergrond hebben
waarin de logische operatoren voluit worden geschreven.

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

[Rene Pijlman]

Nico Coesel:
>Je bedoelt 'and' en '&&' ? Die zijn hetzelfde, staat toch duidelijk in
>het tabelletje?

In de eerste plaats staat er nu juist dat ze niet hetzelfde zijn. En in de
tweede plaats doelde ik natuurlijk op de semantiek m.b.t. het "shortcut"
gedrag. Je weet wel, of b in a and b wordt geëvalueerd als a false is.

--
René Pijlman

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

[Erick T. Barkhuis]

Rene Pijlman [on Sat, 29 May 2004 11:36:57 +0200] wrote:

> En in de
> tweede plaats doelde ik natuurlijk op de semantiek m.b.t. het "shortcut"
> gedrag. Je weet wel, of b in a and b wordt geëvalueerd als a false is.

Is het, behalve als "weetje", functioneel interessant om te weten of in
dat geval b wordt geevalueerd? Zou dat een programmeur niet een zorg mogen
zijn?

Wanneer ik echt zou willen voorkomen dat b wordt geevalueerd, dan zou ik
vermoedelijk coderen:

if (a) {
if (b) {

...
}
}



--
Erick

"The secret of success is sincerity. Once you can fake that, you've
got it made."

[John Bokma]

Nico Coesel wrote:

> Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>
>
>>Nico Coesel:
>>
>>>Volgens mij heb je PHP 5 minuten bekeken
>>
>>Je hebt kennelijk een kristallen bol.
>>
>>
>>>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
regel code schrijven die een *totaal ander* resultaat geeft voor and
vergeleken met &&. In PHP vast idem, zie
<http://www.php.net/manual/en/language.operators.php#language.operators.preceden ce>

En:

" The reason for the two different variations of "and" and "or"
operators is that they operate at different precedences. (See Operator
Precedence.) "

<http://www.php.net/manual/en/language.operators.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).

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

[John Bokma]

Erick T. Barkhuis wrote:

> Rene Pijlman [on Sat, 29 May 2004 11:36:57 +0200] wrote:
>
>
>>En in de
>>tweede plaats doelde ik natuurlijk op de semantiek m.b.t. het "shortcut"
>>gedrag. Je weet wel, of b in a and b wordt geëvalueerd als a false is.
>
> Is het, behalve als "weetje", functioneel interessant om te weten of in
> dat geval b wordt geevalueerd?

Ja, zeer zeker:

(a++) and (a++)

> Zou dat een programmeur niet een zorg mogen
> zijn?

Het short circuiten is juist bedoelt om overhead te voorkomen. Het is
heel belangrijk om te weten of het gedaan wordt (slim) of niet.

> Wanneer ik echt zou willen voorkomen dat b wordt geevalueerd, dan zou ik
> vermoedelijk coderen:
>
> if (a) {
> if (b) {
>
> ...
> }
> }

Een and kan nooit true worden als het linker deel false is, dus waarom
toch evalueren? Dat is net zo dom als b evalueren als a false is in je
voorbeeld. Als je beiden geevalueerd wil hebben, schrijf je het maar uit
:-D.

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

[Rene Pijlman]

Erick T. Barkhuis:
>Rene Pijlman:
>> if (kernTeHeet() and stopReactor())

>Dit lijken wel wat "ongelijkwaardige" methods te zijn, Rene.

Kanonnen, ik wilde slechts aantonen dat het al dan niet shortcut zijn van
de and-operator functioneel relevant is. Het gaat niet alleen om
performance of timing e.d., maar het heeft gevolgen voor de
functionaliteit. Neem me niet kwalijk dat mijn bewijs niet literair
geprogrammeerd is :-)

>Ik begrijp je punt. Maar aan de andere kant vraagt de programmeur wel om
>onduidelijkheid door die manier van coderen.

Integendeel, de programmeur vraagt om duidelijkheid. En dat is wat bij PHP
tekort schiet.

>Het zou mij een worst moeten zijn of, en zo ja in welke volgorde (a and b)
>wordt geevalueerd. Ik wil alleen maar TRUE terug hebben als beide waar
>zijn. Niks meer, niks minder.

In de formele logica is dat natuurlijk zo. En het zal in bepaalde logische
en functionele programmeertalen ook wel zo werken.

Maar de programmeerconstructies zoals John en ik opvoerden komen in de
praktijk zoveel voor, dat de meeste programmeurs de voorkeur geven aan een
verkorte schrijfwijze met een shortcut-operator in plaats van geneste
if-then-else's. Maar daar mag je natuurlijk een andere opvatting over
hebben.

Dat neemt niet weg dat wat de semantiek van de operatoren ook is, het
welgedefinieerd en helder gedocumenteerd hoort te zijn.

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

--
René Pijlman

"Een piloot van de Mexicaanse luchtmacht heeft tijdens een routinevlucht
11 ufo's vastgelegd op film [...] De lichtobjecten omsingelden de
straaljager gedurende de routinevlucht om mogelijke drugssmokkel op te
sporen."
- nu.nl

[Rene Pijlman]

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.

--
René Pijlman

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

[John Bokma]

Nico Coesel wrote:

> John Bokma <postmaster@castleamber.com> wrote:
>
>
>>Nico Coesel wrote:
>>
>>
>>>Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>>
>>>
>>>
>>>>Nico Coesel:
>>>>
>>>>
>>>>>Volgens mij heb je PHP 5 minuten bekeken
>>>>
>>>>Je hebt kennelijk een kristallen bol.
>>>>
>>>>
>>>>
>>>>>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.

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

>><http://www.php.net/manual/en/language.operators.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.

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

[Erick T. Barkhuis]

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

[Rene Pijlman]

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

[Nico Coesel]

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/language.operators.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

[Jaap-Andre de Hoop]

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

[Erick T. Barkhuis]

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

[Rene Pijlman]

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

[John Bokma]

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/

[John Bokma]

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/

[Erick T. Barkhuis]

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

[Erick T. Barkhuis]

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

[Nico Coesel]

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

[Nico Coesel]

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

[Rene Pijlman]

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

[John Bokma]

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/

[John Bokma]

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/

[Rene Pijlman]

John Bokma:
>Nico Coesel:
>> 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?

Dat was bij x.y.(n-1). Zelfs dat verandert elke release :-)

Maar ja, ze konden de megasuperturboglobals natuurlijk niet standaard aan
laten staan, met externe en interne variabelen in dezelfde namespace.

En ach, de gebrekkige object-oriëntatie. "All object methods and
properties are public", zegt mijn PHP-boek. Hoezo encapsulatie, de basis
van OO?

Verder ontbreekt exception handling en nog zo wat van die dingen.

Maar Nico gaat nu vast zeggen dat ik slechts 5 minuten in mijn boek heb
gekeken, dat alle bezwaren die ik noem onjuist zijn, dat ze bovendien
gelden voor elke andere programmeertaal waarvan ik geen verstand heb en
dat ik geen inhoudelijke argumenten heb.

--
René Pijlman

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

[Erick T. Barkhuis]

Rene Pijlman [on Sun, 30 May 2004 21:03:11 +0200] wrote:

> Die grote nadruk op Methoden komt vooral
> voort uit het dubieuze wereldje van zij-instromers in de ICT.

Ah...u post nu suggestieve berichten, heer Pijlman?


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

We komen nu op een punt waarop ik eigenlijk een uurtje JSP-college zou
moeten geven (of twee, of zo). Ik krijg het niet in een post van
acceptabele lengte voor elkaar dat uit te leggen.

Neem alsjeblieft van me aan dat JSP resulteert in code die bestaat uit
elementaire opdrachten (dat _kan_ het doen uitvoeren van een method zijn)
en elementaire uitvragingen (die NOOIT het uitvoeren van een method kunnen
zijn).

Wat wel een typerend fenomeen is binnen JSP, is de "Goede Fee".
Het kan voorkomen dat er een selectiecomponent in de code voorkomt (zeg
maar een "if-constructie") waarbij je op dat moment nog niet voldoende
informatie hebt om eeen uitvraging te specificeren. De JSP-methode geeft
dan aan hoe je daarmee omgaat.

Voorbeeld:
"Je gaat straks door die rode deur. Je komt dan in een gang, waar je
links- of rechtsaf kunt gaan. Neem de gang waarin je geen hond tegenkomt.
Mocht je onderweg de DVD "Pietje Puk" tegenkomen, neem die dan mee. Aan
het eind van die gang ligt een boek. Onthoud het tweede woord van
hoofdstuk 5 (mits dat aanwezig is...neem anders hoofdstuk 4) en loop dan
terug. Schrijf dat woord in het gastenboek dat naast de deur ligt waardoor
je binnenging."

Opdracht: schrijf hiervoor een programma.


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

Nou, vooruit. Misschien was het suggestief bedoeld.
Maar tegelijkertijd serieus.

JSP was ooit een niche, en is nu erfgoed geworden.
Ik vind dat jammer.


--
Erick

"If a man speaks in the forest and there are no women there to hear him, is he still wrong?"

[Nico Coesel]

John Bokma <postmaster@castleamber.com> wrote:

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

Ik ontwikkelde voorheen scripts op een testserver PHP 3.zoveel en
gebruik ze op een productieserver met PHP4.zoveel. Eigenlijk nooit
compatibiliteitsproblemen mee gehad behalve met features die in
3.zoveel niet werden ondersteund of speciaal meegecompileerde features
op de productieserver (zoals bijvoorbeeld de mogelijkheid https
verbindingen naar een andere server te openen).
Het enige serieuze compatibiliteitsprobleem dat ik tot nu toe heb
gehad was met een nieuwe versie van de GD library. Daarop werkte de
transparantie van pixels anders.

Er blijven natuurlijk altijd 'issues' met default settings zodat je
(als je de betreffende setting niet had gedefinieerd) de configuratie
moet aanpassen, maar ik ben geneigd dat niet als
compatibiliteitsprobleem te zien aangezien je uiteindelijk je scripts
niet hoeft aan te passen. Irritant is het wel.

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

[Nico Coesel]

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

>John Bokma:
>>Nico Coesel:
>>> 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?
>
>Dat was bij x.y.(n-1). Zelfs dat verandert elke release :-)

Dat valt wel mee.

>Verder ontbreekt exception handling en nog zo wat van die dingen.

Wordt, zoals het er nu naar uitziet, allemaal met versie 5 (nu nog
beta) opgelost:

http://www.zend.com/php5/articles/engine2-php5-changes.php

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

[robert]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> En ach, de gebrekkige object-oriëntatie. "All object methods and
> properties are public", zegt mijn PHP-boek. Hoezo encapsulatie, de basis
> van OO?

Ook met publieke methods en properties kan je encapsulatie bewerkstelligen,
alleen vereist dat meer discipline van de programmeur.

> Verder ontbreekt exception handling en nog zo wat van die dingen.

Dan valt C ook al af. Ach, er is nog altijd Javascript...

--
robert

[Rene Pijlman]

Nico Coesel:
>Rene Pijlman:
>>Verder ontbreekt exception handling en nog zo wat van die dingen.
>
>Wordt, zoals het er nu naar uitziet, allemaal met versie 5 (nu nog
>beta) opgelost:

Joepie, ik kan bijna niet wachten. Maar tot die tijd pak ik nog even Java
of python. En ondertussen (versie 4) had ik natuurlijk gewoon gelijk. Wees
nou zo sportief om dat even toe te geven :-)

--
René Pijlman

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

[Jaap-Andre de Hoop]

In article <40ba325c$0$197$58c7af7e@news.kabelfoon.nl>, John Bokma <postmaster@castleamber.com> wrote:

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

Ik vertrouw hier dusdanig op dat ik elke nacht een script draai die
kijkt of de phpversie veranderd is en zo ja, dan ligt er 's ochtends vroeg
een mailtje te wachten.

Jaap-Andre

[John Bokma]

Jaap-Andre de Hoop wrote:

> In article <40ba325c$0$197$58c7af7e@news.kabelfoon.nl>, John Bokma <postmaster@castleamber.com> wrote:
>
>>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?
>
> Ik vertrouw hier dusdanig op dat ik elke nacht een script draai die
> kijkt of de phpversie veranderd is en zo ja, dan ligt er 's ochtends vroeg
> een mailtje te wachten.

LOL (!). Overigens, Perl heeft ergens in een grijs verleden ook een
leuke grap gehad, while ($line = <FILE>) moest ineens een defined test
hebben. Een error log vol waarschuwingen. Gelukkig is het weer teruggedraait

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

[Nico Coesel]

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

>Nico Coesel:
>>Rene Pijlman:
>>>Verder ontbreekt exception handling en nog zo wat van die dingen.
>>
>>Wordt, zoals het er nu naar uitziet, allemaal met versie 5 (nu nog
>>beta) opgelost:
>
>Joepie, ik kan bijna niet wachten. Maar tot die tijd pak ik nog even Java
>of python. En ondertussen (versie 4) had ik natuurlijk gewoon gelijk. Wees
>nou zo sportief om dat even toe te geven :-)

Ja, maar dat maakt de taal PHP nog steeds niet onbruikbaar... C is
jarenlang gebruikt en wordt nog steeds gebruikt zonder OO.
Overigens zit er in PHP4 wel een globale exception handling feature
(zie error functions).

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

[Michiel de Roo]

Rene Pijlman wrote:
> Patrick:
> [P: de makers hebben PHP bedoeld als algemene programmeertaal
> RP: PHP is niet bedoeld als algemene programmeertaal]
>
>>Ik zie alleen niet in waarom dat in het geval van PHP zo zou zijn.
>
>
> Omdat PHP daar geen geschikte taal voor is. Het wordt voornamelijk
> gebruikt voor het genereren van webpagina's en de hele evolutie van PHP
> was daarop gericht.
>
> Gaandeweg is het min of meer een programmeertaal geworden en dan zijn er
> mensen van het type "if all you have is a hammer, everything looks like a
> nail" die het voor algemeen programmeerwerk gebruiken. Maar daarvoor zijn
> veel elegantere programmeertalen beschikbaar (tegenwoordig vooral: Java,
> C#, Python).
>
> Ik kan waarschijnlijk 100 voordelen van deze talen t.o.v. PHP bij elkaar
> bedenken (maar dat ga ik niet doen), terwijl mij geen enkel voordeel van
> PHP t.o.v. deze talen te binnen wil schieten.

Dat het overal ondersteund wordt, gratis is, makkelijk te installeren,
makkelijk te leren, er een actieve user community is, veel gratis code
beschikbaar is, .....

>
> De documentatie van PHP alleen al is zo weerzinwekkend slecht dat vrijwel
> iedereen met een informaticadiploma fysieke symptomen van middeleeuwse
> voedselziekten krijgt bij het lezen ervan.

Inderdaad. De documentatie lijkt vaak voor en door amateurs geschreven.

>
> Ik noem één piepklein voorbeeldje, dat ik in 12 seconden kon vinden. Wat
> is volgens de documentatie de semantiek van de logische operatoren "and"
> respectievelijk "&&"?
> http://nl2.php.net/manual/en/language.operators.logical.php
>
> En het ene A4'tje over Classes and Objects doet ook niet vermoeden dat dit
> serieuze functionaliteit is.

Wat mij er niet van weerhoudt serieus OO te programmeren in PHP. Je moet
jezelf dan wel strak aan het lijntje houden, iets wat natuurlijk niet
eenvoudig is in grotere groepen programmeurs, maar met één of twee mensen
goed te doen. OO programmeren is voor mij toch vooral een manier van
denken en het ontwerpen van een goede architectuur. Dat heeft niets met de
taal te maken. Een goed ontwerp kun je in meerdere talen implementeren.

Een voorbeeld wat ook vaak aangehaald wordt is het gebrek aan interfaces.
Maar wat is een interface ? Dat is toch al een abstract begrip. Dat je
geen interface kunt definieren is zwaar onhandig, maar het beperkt je op
geen enkele manier. Je kunt een interface in je ontwerp zetten, en als je
je strak aan je ontwerp houdt is er geen enkel probleem. Hetzelfde geldt
voor veel andere OO eigenschappen.

Wat ik wel een groot nadeel vind wat betreft OO eigenschappen, is dat je
je objecten zo slecht persistent kunt maken tussen verschillende pagina
aanroepen. Je kunt ze weliswaar in een sessie stoppen, maar dan ben je wel
al je composite objecten kwijt. Je zult dus zelf een methode moeten
implementeren om die ook te serialiseren.

Waar ik ook vaak tegenaan loop is dat een PHP script tergend langzaam
wordt als je veel (zeg, >40) classes gebruikt. Dit moedigt het maken van
subclasses niet aan, en bij grotere applicaties wordt het een serieus
probleem. Java is weliswaar zwaar op een server, maar de reactietijd per
pagina is vele malen beter. Er hoeft natuurlijk ook niet elke keer opnieuw
gecompileerd te worden. Een servlet hoeft zelfs niet eens opnieuw geladen
te worden.

>
> Meer leesvoer over beperkingen van PHP:
> http://www.ukuug.org/events/linux2002/papers/html/php/index.html

Tegen deze stellingen is zo ontzettend veel in te brengen. Ik vind PHP als
taal vaak onhandig, maar zeker niet onbruikbaar. Java is als taal
natuurlijk veel mooier, zeker als je toch al OO programmeert.

Michiel.

[Michiel de Roo]

Patrick wrote:
>
> Daarnaast heeft PHP weinig overhead. Bij Java bijvoorbeeld moet je eerst
> een flinke VM inladen.

Ik kan je verzekeren dan bij grotere applicaties Java vele malen
efficienter is. Bij Java moet je niet 'eerst' die VM laden, bij Java laadt
je VM en alle servlets bij het starten van de server. Daarna zijn die
gewoon onmiddelijk beschikbaar. Bij PHP moet voor ieder script bij iedere
hit het hele proces vanaf compileren weer opnieuw beginnen. Dát is pas
inefficient.

Michiel.

[Michiel de Roo]

Rene Pijlman wrote:
> Maar ik heb inderdaad ook de ervaring dat de overhead bij Java
> kwantitatief vrij hoog ligt. Een Java-programma domineert mijn redelijk
> moderne laptop, terwijl je niet eens doorhebt dat een vergelijkbaar
> Python-programma draait.

Daarvoor krijg je dan waarschijnlijk die hypermoderne en veel te 'good
looking' Swing toolkit. Als je strikt in AWT schrijft heb je dit probleem
zeker niet.

Michiel.

[Rene Pijlman]

Michiel de Roo:
>Rene Pijlman:
>> Ik kan waarschijnlijk 100 voordelen van deze talen t.o.v. PHP bij elkaar
>> bedenken (maar dat ga ik niet doen), terwijl mij geen enkel voordeel van
>> PHP t.o.v. deze talen te binnen wil schieten.
>
>Dat het overal ondersteund wordt, gratis is, makkelijk te installeren,
>makkelijk te leren, er een actieve user community is, veel gratis code
>beschikbaar is, .....

Dat het overal ondersteund wordt is wel een punt. Makkelijk te leren is
subjectief, dat mag ieder voor zich al of niet zo vinden.

Maar die andere dingen gelden voor de andere talen net zo goed. Je wilt
toch niet serieus beweren dat Java, Perl of Python moeilijk te installeren
is, dat er geen actieve user community is en dat er weinig gratis code
beschikbaar is? Kom nou.

--
René Pijlman

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

[Rene Pijlman]

Michiel de Roo:
>Bij PHP moet voor ieder script bij iedere hit het hele proces vanaf
>compileren weer opnieuw beginnen. Dát is pas inefficient.

Dat zal toch niet waar zijn? De gecompileerde code zal toch wel gecached
worden? En alleen gehercompileerd op basis van timestamps van de broncode?

Anders ga ik gelijk PHP van mijn server verwijderen.

--
René Pijlman

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

[Rene Pijlman]

Michiel de Roo:
>Rene Pijlman:
>> Maar ik heb inderdaad ook de ervaring dat de overhead bij Java
>> kwantitatief vrij hoog ligt. Een Java-programma domineert mijn redelijk
>> moderne laptop, terwijl je niet eens doorhebt dat een vergelijkbaar
>> Python-programma draait.
>
>Daarvoor krijg je dan waarschijnlijk die hypermoderne en veel te 'good
>looking' Swing toolkit. Als je strikt in AWT schrijft heb je dit probleem
>zeker niet.

Ik heb het over ui-loze command line applicaties. Een batch-scriptje dat
een database bevraagt en een website genereert. En een multi-threaded link
checker.

In ieder geval gevoelsmatig belasten die dingen mijn laptopje veel
zwaarder dan een vergelijkbaar Python-programma.

--
René Pijlman

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

[Michiel de Roo]

Rene Pijlman wrote:
> Michiel de Roo:
>
>>Rene Pijlman:
>>
>>>Ik kan waarschijnlijk 100 voordelen van deze talen t.o.v. PHP bij elkaar
>>>bedenken (maar dat ga ik niet doen), terwijl mij geen enkel voordeel van
>>>PHP t.o.v. deze talen te binnen wil schieten.
>>
>>Dat het overal ondersteund wordt, gratis is, makkelijk te installeren,
>>makkelijk te leren, er een actieve user community is, veel gratis code
>>beschikbaar is, .....
>
>
> Dat het overal ondersteund wordt is wel een punt. Makkelijk te leren is
> subjectief, dat mag ieder voor zich al of niet zo vinden.
>
> Maar die andere dingen gelden voor de andere talen net zo goed. Je wilt
> toch niet serieus beweren dat Java, Perl of Python moeilijk te installeren
> is, dat er geen actieve user community is en dat er weinig gratis code
> beschikbaar is? Kom nou.
>

Python ken ik nauwelijks. Voor Perl geldt waarschijnlijk hetzelfde.
Echter, een Java servlet engine als Tomcat opzetten i.c.m. Apache is zeker
niet zo eenvoudig als PHP installeren. Ik spreek uit ervaring ;-).
Overigens, als je het een paar keer gedaan hebt is het zo moeilijk niet meer.

En ik denk dat er inderdaad meer gratis open source code beschikbaar is
voor PHP, al ben ik niet zo heel goed meer op de hoogte van wat Jakarta op
het moment allemaal biedt. Bovendien kun je hard twijfelen aan de
kwaliteit van het grootste deel van de PHP code. Bij Java zit het met de
kwaliteit meestal wel goed. Ook zijn er veel commerciele Java producten
beschikbaar, voor PHP waarschijnlijk minder. Voor een commercieel
ontwikkelaar is dat waarschijnlijk net zo belangrijk.

Michiel.

[Jan Ehrhardt]

Rene Pijlman in nl.internet.www.server-side (Mon, 31 May 2004 15:18:13
+0200):

>Dat het overal ondersteund wordt is wel een punt. Makkelijk te leren is
>subjectief, dat mag ieder voor zich al of niet zo vinden.
>
>Maar die andere dingen gelden voor de andere talen net zo goed. Je wilt
>toch niet serieus beweren dat Java, Perl of Python moeilijk te installeren
>is, dat er geen actieve user community is en dat er weinig gratis code
>beschikbaar is? Kom nou.

Bij veel hostingcontracten krijg je PHP er 'gratis' bij. Perl en Python
zijn veel minder standaard of kosten extra euri.

Jan
--
Look, Ma. No tables - http://enbio.steenbergen-stichting.nl/

[Jan Ehrhardt]

Rene Pijlman in nl.internet.www.server-side (Mon, 31 May 2004 15:19:54
+0200):

>Michiel de Roo:
>>Bij PHP moet voor ieder script bij iedere hit het hele proces vanaf
>>compileren weer opnieuw beginnen. Dát is pas inefficient.
>
>Dat zal toch niet waar zijn? De gecompileerde code zal toch wel gecached
>worden? En alleen gehercompileerd op basis van timestamps van de broncode?

Bij mijn weten wordt er in PHP helemaal niet gecompileerd, maar
geinterpreteerd. PHP is meer een interpreter dan een compiler. Maar dat
geldt voor Perl evenzeer. En misschien voor Python ook wel.

>Anders ga ik gelijk PHP van mijn server verwijderen.

Verwijder Perl dan ook maar gelijk. Scheelt gelijk weer wat ruimte ;-)

Jan
--
Look, Ma. No tables - http://enbio.steenbergen-stichting.nl/

[Rene Pijlman]

Jan Ehrhardt:
>Bij mijn weten wordt er in PHP helemaal niet gecompileerd, maar
>geinterpreteerd. PHP is meer een interpreter dan een compiler. Maar dat
>geldt voor Perl evenzeer.

Ik verwijs je dan toch graag naar hoofdstuk 18 "Compiling" van
"Programming Perl", 3rd edition, van ene Larry Wall.

>En misschien voor Python ook wel.

Dat wordt ook gecompileerd naar tussencode voor een virtual machine, net
als vrijwel elke hedendaagse programmeertaal (Perl, Python, Java en naar
ik aanneem C#).

--
René Pijlman

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

[Michiel de Roo]

Rene Pijlman wrote:
> Michiel de Roo:
>
>>Rene Pijlman:
>>
>>>Maar ik heb inderdaad ook de ervaring dat de overhead bij Java
>>>kwantitatief vrij hoog ligt. Een Java-programma domineert mijn redelijk
>>>moderne laptop, terwijl je niet eens doorhebt dat een vergelijkbaar
>>>Python-programma draait.
>>
>>Daarvoor krijg je dan waarschijnlijk die hypermoderne en veel te 'good
>>looking' Swing toolkit. Als je strikt in AWT schrijft heb je dit probleem
>>zeker niet.
>
>
> Ik heb het over ui-loze command line applicaties. Een batch-scriptje dat
> een database bevraagt en een website genereert. En een multi-threaded link
> checker.
>
> In ieder geval gevoelsmatig belasten die dingen mijn laptopje veel
> zwaarder dan een vergelijkbaar Python-programma.
>

Ah, maar die kun je (iig onder linux) compileren met gcj, dan moet het
probleem over zijn. Je hebt dan gewoon een native applicatie, net als je
met gcc had gehad. Volgens mij IS gcj zelfs gewoon een versie van gcc.

Michiel.

[Michiel de Roo]

Rene Pijlman wrote:
> Michiel de Roo:
>
>>Bij PHP moet voor ieder script bij iedere hit het hele proces vanaf
>>compileren weer opnieuw beginnen. Dát is pas inefficient.
>
>
> Dat zal toch niet waar zijn? De gecompileerde code zal toch wel gecached
> worden? En alleen gehercompileerd op basis van timestamps van de broncode?
>
> Anders ga ik gelijk PHP van mijn server verwijderen.
>

Uit de Zend documentatie:

With standard PHP every time a PHP script is accessed, the script is
parsed and compiled by the Zend engine before it is executed. The Zend
Accelerator, from the creators of the Zend engine, tightly integrates with
the Zend engine and caches the PHP script in a post-compilation state. The
next time the script is called, Zend Accelerator serves the cached code
and the compilation process is saved.

Oftewel, je kunt PHP verwijderen of Zend Accelerator aanschaffen (starting
at $490)

http://www.zend.com/store/products/zend-accelerator.php

Michiel.

[Rene Pijlman]

Michiel de Roo:
>With standard PHP every time a PHP script is accessed, the script is
>parsed and compiled by the Zend engine before it is executed.
[...]
>Oftewel, je kunt PHP verwijderen

Dat wilde ik eigenlijk toch al, maar dit is de druppel. Staat op mijn
todolist. Dank voor de waarschuwing!

--
René Pijlman

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

[Jan Ehrhardt]

Rene Pijlman in nl.internet.www.server-side (Mon, 31 May 2004 15:52:56
+0200):

>Jan Ehrhardt:
>>Bij mijn weten wordt er in PHP helemaal niet gecompileerd, maar
>>geinterpreteerd. PHP is meer een interpreter dan een compiler. Maar dat
>>geldt voor Perl evenzeer.
>
>Ik verwijs je dan toch graag naar hoofdstuk 18 "Compiling" van
>"Programming Perl", 3rd edition, van ene Larry Wall.

Ik zie het. De URL had je er misschien wel even bij kunnen zetten ;-)
http://www.oreilly.com/catalog/pperl3/chapter/ch18.html
Ik vraag me overigens wel af hoeveel mensen de Bytecode Generator o.i.d.
zullen gebruiken. Zonder dat heeft Perl nog steeds veel van een
interpreter, die intern de zaken opdeelt in een Compile phase en een Run
Phase.

>>En misschien voor Python ook wel.
>
>Dat wordt ook gecompileerd naar tussencode voor een virtual machine, net
>als vrijwel elke hedendaagse programmeertaal (Perl, Python, Java en naar
>ik aanneem C#).

Bij Pythom kwam ik inderdaad ook de compile-optie tegen. En er werd
expliciet gesteld dat zelfs zonder py_compile byte-code cache files
worden geplaatst in de directory waar ook de source code staat. Bij Perl
zag ik iets dergelijks niet.

Jan
--
Look, Ma. No tables - http://enbio.steenbergen-stichting.nl/

[Rene Pijlman]

John Bokma:
>Ik hoor meestal verbaasde uitroepen als ik Perl demonstreer. Is ie nu al
>klaar? Wauw, het heeft echt even 1800 pagina's HTML aangemaakt?

Nou, daar kun je met Java ongeveer drie kwartier op wachten, schat ik.
Mijn 500 pagina's duren een kwartier.

Ik gebruik MS Access, de JDBC-ODBC bridge en een inefficiënt algoritme,
dat zeg ik er maar even bij :-)

--
René Pijlman

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

[John Bokma]

Rene Pijlman wrote:

> John Bokma:
>
>>Ik hoor meestal verbaasde uitroepen als ik Perl demonstreer. Is ie nu al
>>klaar? Wauw, het heeft echt even 1800 pagina's HTML aangemaakt?
>
> Nou, daar kun je met Java ongeveer drie kwartier op wachten, schat ik.
> Mijn 500 pagina's duren een kwartier.
>
> Ik gebruik MS Access, de JDBC-ODBC bridge en een inefficiënt algoritme,
> dat zeg ik er maar even bij :-)

Aha :-D. Die 1800 waren wel simpel, en de info kwam uit een plat
tekstbestandje. Was secondenwerk :-D.

200 pagina's uit XML bestanden halen gaat ook in een paar seconden :-D:

Maar ik kan mij voorstellen dat je een berg queries gebruikt :-D.

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

[Michiel de Roo]

Rene Pijlman wrote:
> John Bokma:
>
>>Ik hoor meestal verbaasde uitroepen als ik Perl demonstreer. Is ie nu al
>>klaar? Wauw, het heeft echt even 1800 pagina's HTML aangemaakt?
>
>
> Nou, daar kun je met Java ongeveer drie kwartier op wachten, schat ik.
> Mijn 500 pagina's duren een kwartier.

De ene pagina is de ander niet. Hoeveel queries zijn het en welke queries
? Hoeveel kb html ? Hoeveel dynamische content per pagina ? Dit blijft
appels met peren vergelijken.

Je kunt talen alleen vergelijken als je precies hetzelde functionele
ontwerp in verschillende talen implementeert en een standaard set met test
data gebruikt. Het zou eigenlijk best interessant zijn om dit eens te doen
voor PHP, Perl en Java. Het is alleen nogal wat werk, omdat je alles drie
keer moet schrijven.

>
> Ik gebruik MS Access, de JDBC-ODBC bridge en een inefficiënt algoritme,
> dat zeg ik er maar even bij :-)
>

Aaargh, MS Access..... Probeer het voor de gein eens met mySQL em de
com.mysql driver. In mijn ervaring is de combinatie MS Acces en JDBC-ODBC
echt vreselijk sloom. Ik heb dat ooit eens gebruikt op een laptop tijdens
een geologisch veldwerk, ik had niks anders voorhanden, maar het was niks.

Eventueel kun je MS SQL nog proberen als je echt MS wilt. Dat zal
waarschijnlijk ook nog wel een hoop schelen.

Michiel.

[Michiel de Roo]

John Bokma wrote:
> Rene Pijlman wrote:
>
>> John Bokma:
>>
>>> Ik hoor meestal verbaasde uitroepen als ik Perl demonstreer. Is ie nu
>>> al klaar? Wauw, het heeft echt even 1800 pagina's HTML aangemaakt?
>>
>>
>> Nou, daar kun je met Java ongeveer drie kwartier op wachten, schat ik.
>> Mijn 500 pagina's duren een kwartier.
>>
>> Ik gebruik MS Access, de JDBC-ODBC bridge en een inefficiënt algoritme,
>> dat zeg ik er maar even bij :-)
>
>
> Aha :-D. Die 1800 waren wel simpel, en de info kwam uit een plat
> tekstbestandje. Was secondenwerk :-D.

file:test.php
<?
$time = microtime();
echo '<html>';
for($i=0; $i<1800; $i++) {
echo include('tekst.txt');
}
echo '</html>';

echo $time;
echo microtime();
?>

php test.php > test.bin

Precies één seconde op een AMD1800 met voldoende geheugen en 720 kB output
;-) Dus PHP is sneller dan Perl ?????


>
> 200 pagina's uit XML bestanden halen gaat ook in een paar seconden :-D:
>
> Maar ik kan mij voorstellen dat je een berg queries gebruikt :-D.
>

[John Bokma]

Michiel de Roo wrote:

> Precies één seconde op een AMD1800 met voldoende geheugen en 720 kB
> output ;-) Dus PHP is sneller dan Perl ?????

Neuh, want Perl was al klaar voor jij nog maar begonnen was met je PHP
oplossing.

En ja, ik gok dat voor een CLI script Perl sneller is dan een PHP
script. We kunnen een benchmarkje maken :-P. Laten we Rene testen ;-)

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

[Ronald Klip]

Bart Vanbrabant schreef:
> Michiel de Roo wrote:
> >
> > Oftewel, je kunt PHP verwijderen of Zend Accelerator aanschaffen
> > (starting at $490)
> >
> > http://www.zend.com/store/products/zend-accelerator.php
> >
> Een open-source php accelerator:
> http://turck-mmcache.sourceforge.net/index_old.html

Ik gebruik deze al een tijdje, tot volle tevredenheid:
http://www.php-accelerator.co.uk/

De verdere ontwikkeling ervan lijkt echter gestaakt te zijn.

--
groet, Ronald

[Konstantinopel]

Nico Coesel wrote:

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

>> Patrick:
>>> De documentatie, alhoewel essentieel om fatsoenlijk te kunnen programmeren,
>>> zegt wat mij betreft weinig over de kwaliteiten van de programmeertaal zelf.
>>
>> Maar hier verschillen we fundamenteel van mening. De documentatie _is_ de
>> programmeertaal.

> Volgens mij heb je PHP 5 minuten bekeken, werkte het niet zoals je
> verwachtte en vond je het slecht. Ik vind de documentatie uitstekend.
> Alles wat ik ooit heb willen weten heb ik er in terug kunnen vinden.

In een MySQL-database heb ik bijvoorbeeld een veld dat heet varchar(20).
Hoe vang ik in een script die 20 in $veldlengte op? De veldnaam is haal
ik zo uit de array veldnaamA[]: for each($veldnaamA as $veldnaamS).

Ik heb uiteindelijk het antwoord gevonden, maar het kwam niet uit de
handleiding!

--
Newsoffice.de - Die Onlinesoftware zum Lesen und Schreiben im Usenet Die
Signatur läßt sich nach belieben Anpassen ;-)

[Nico Coesel]

Konstantinopel <Konstantinopel@expires-30-06-2004.news-group.org>
wrote:

>Nico Coesel wrote:
>
>> Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>
>>> Patrick:
>>>> De documentatie, alhoewel essentieel om fatsoenlijk te kunnen programmeren,
>>>> zegt wat mij betreft weinig over de kwaliteiten van de programmeertaal zelf.
>>>
>>> Maar hier verschillen we fundamenteel van mening. De documentatie _is_ de
>>> programmeertaal.
>
>> Volgens mij heb je PHP 5 minuten bekeken, werkte het niet zoals je
>> verwachtte en vond je het slecht. Ik vind de documentatie uitstekend.
>> Alles wat ik ooit heb willen weten heb ik er in terug kunnen vinden.
>
>In een MySQL-database heb ik bijvoorbeeld een veld dat heet varchar(20).
>Hoe vang ik in een script die 20 in $veldlengte op? De veldnaam is haal
>ik zo uit de array veldnaamA[]: for each($veldnaamA as $veldnaamS).
>
>Ik heb uiteindelijk het antwoord gevonden, maar het kwam niet uit de
>handleiding!

Logisch, want het opvragen van de velden van een tabel doe je met een
SQL statement en heeft niets met PHP als taal te maken.

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

[bram]

Michiel de Roo wrote:
> Patrick wrote:
>
>>
>> Daarnaast heeft PHP weinig overhead. Bij Java bijvoorbeeld moet je
>> eerst een flinke VM inladen.
>
>
> Ik kan je verzekeren dan bij grotere applicaties Java vele malen
> efficienter is. Bij Java moet je niet 'eerst' die VM laden, bij Java
> laadt je VM en alle servlets bij het starten van de server. Daarna zijn
> die gewoon onmiddelijk beschikbaar. Bij PHP moet voor ieder script bij
> iedere hit het hele proces vanaf compileren weer opnieuw beginnen. Dát
> is pas inefficient.
>
> Michiel.

Hoeft niet echt als je een PHP accelator gebruikt, ik gebruik
zelf Turck MMcache... Enorme snelheidswinst, tot 5x....
Scripts worden dan 1x gecompileerd en pas opnieuw als het script wordt
gewijzigd.

[Edwin Martin]

Nico Coesel wrote:

>>Meer leesvoer over beperkingen van PHP:
>>http://www.ukuug.org/events/linux2002/papers/html/php/index.html
>
>
> Ik heb het verhaal eens gelezen, maar de meeste punten hebben niets
> met de taal te maken, maar meer met de logistieke organisatie van een
> programmeursteam. Bovendien zijn een aantal punten gewoon onwaar,
> andere punten zijn eenvoudig te voorkomen (een kwestie van voldoende
> kennis van de taal).
>
> Kortom: een dergelijk verhaal kun je over iedere programmeertaal
> afsteken als je er maar niet genoeg van af weet.

Toevallig heb ik eergisteren het stukje "Why PHP sucks" geschreven.

Na ongeveer vier jaar PHP programmeren, kwam ik steeds weer beperkingen
tegen die een server-side webtaal niet hoort te hebben.

http://www.bitstorm.org/edwin/en/php-sucks/

(Het is in het Engels, wat niet mijn moeders taal is, dus er kunnen wat
spellings- en stijlfouten in zitten).

Edwin Martin

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

[John Bokma]

Edwin Martin wrote:

> http://www.bitstorm.org/edwin/en/php-sucks/
>
> (Het is in het Engels, wat niet mijn moeders taal is, dus er kunnen wat
> spellings- en stijlfouten in zitten).

Zie ook: http://tnx.nl/php

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

[Patrick]

Edwin Martin wrote:
> Toevallig heb ik eergisteren het stukje "Why PHP sucks" geschreven.
>
> Na ongeveer vier jaar PHP programmeren, kwam ik steeds weer beperkingen
> tegen die een server-side webtaal niet hoort te hebben.
>
> http://www.bitstorm.org/edwin/en/php-sucks/
>
> (Het is in het Engels, wat niet mijn moeders taal is, dus er kunnen wat
> spellings- en stijlfouten in zitten).

Ik heb maar kort even naar je stuk gekeken (daar is het nu te laat voor
:-), maar bij Confusing Licenses heb je het over PDF en ClipPDF. Toch is
er een gratis PHP class die PDF's kan genereren, zie http://www.fpdf.org.

Groeten,

Patrick

[Daniel Tryba]

Edwin Martin <e.j.martin@chello.nl> wrote:
> Na ongeveer vier jaar PHP programmeren, kwam ik steeds weer beperkingen
> tegen die een server-side webtaal niet hoort te hebben.

Ik vind persoonlijk dat de genoemde problemen niet alleen van toepassing
zijn voor "server-side webtalen"!

> http://www.bitstorm.org/edwin/en/php-sucks/

>>Bad recursion support

Er is wel wat veranderd de afgelopen 5 jaar... het gaat in mijn omgeving
pas mis bij 18051... ohnee het is afhankelijk van de stacksize... als je
dat weet (wat dus het eigenlijk probleem is) kan je die zonder probleem
aanpassen voor het pid welke PHP draaid... even verhoogt en het volgende
probleem is dat ik tegen het (voor mij) standaard limiet van 8Mb data
aanloop... En daar zou je ook tegen aan lopen als de zut wel degelijk op
de heap zou worden gegooid.

>>PHP is not thread safe

Dat is inderdaad jammer... PHP5?

>>PHP is crippled for commercial reasons

Niet belangrijk aangezien er open alternatieven zijn... Zie posting van
Renee ergens de afgelopen paar dagen.

>>No namespaces

Heeft C namespaces? Nee dan is de naming convention, en nog veel erger
de volgorde van argumenten, een veel groter probleem.

>>Non-standard date format characters

Niet belangrijk tenzij je een C programmeur bent.

>>Confusing licenses

s/come with commercial licenses/come with commercial licenses for commercial use/

voor op z'n minst de PDF functies. Als alternatief staat op de
betreffende manual pages:
http://www.php.net/manual/en/faq.using.php#faq.using.freepdf

--

Daniel Tryba

[robert]

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> Edwin Martin <e.j.martin@chello.nl> wrote:
>
>>>No namespaces
>
> Heeft C namespaces?

Dat zou alleen een relevante opmerking zijn als PHP een alternatief voor C
genoemd zou worden.

>>>Non-standard date format characters
>
> Niet belangrijk tenzij je een C programmeur bent.

Of Perl. Of Python. Of Java. Of zsh. Date-formatting op de strftime-manier
is inmiddels een conventie geworden, dus de vraag is waarom PHP daarvan af
heeft willen wijken.

--
robert

[Branko Collin]

Patrick <user@domain.invalid>, you wrote on Tue, 10 Aug 2004 01:36:09
+0200:
>Edwin Martin wrote:

>> http://www.bitstorm.org/edwin/en/php-sucks/
>
>Ik heb maar kort even naar je stuk gekeken (daar is het nu te laat voor
>:-), maar bij Confusing Licenses heb je het over PDF en ClipPDF. Toch is
>er een gratis PHP class die PDF's kan genereren, zie http://www.fpdf.org.

Ah, dus je moet voor PDF uit drie licenties kiezen? Nog verwarrender!

--
branko collin
collin@xs4all.nl

[Branko Collin]

Edwin Martin <e.j.martin@chello.nl>, you wrote on Mon, 09 Aug 2004
18:58:41 GMT:

>Toevallig heb ik eergisteren het stukje "Why PHP sucks" geschreven.
>
>Na ongeveer vier jaar PHP programmeren, kwam ik steeds weer beperkingen
>tegen die een server-side webtaal niet hoort te hebben.
>
>http://www.bitstorm.org/edwin/en/php-sucks/

Goed stukje. Ik kan me met name voorstellen dat als je met dingen als
recursieviteit bent opgegroeid, een gebrekkige implementatie daarvan
een echt struikelblok is.

Voor mij is PHP een goeie taal, omdat het voor werkt. Maar ja, smaken
verschillen. :-)

--
branko collin
collin@xs4all.nl

[Edwin Martin]

Patrick wrote:
> Edwin Martin wrote:
>
>> Toevallig heb ik eergisteren het stukje "Why PHP sucks" geschreven.
>>
>> Na ongeveer vier jaar PHP programmeren, kwam ik steeds weer
>> beperkingen tegen die een server-side webtaal niet hoort te hebben.
>>
>> http://www.bitstorm.org/edwin/en/php-sucks/
>>
>> (Het is in het Engels, wat niet mijn moeders taal is, dus er kunnen
>> wat spellings- en stijlfouten in zitten).
>
>
> Ik heb maar kort even naar je stuk gekeken (daar is het nu te laat voor
> :-), maar bij Confusing Licenses heb je het over PDF en ClipPDF. Toch is
> er een gratis PHP class die PDF's kan genereren, zie http://www.fpdf.org.

Waarom maakt die dan niet "standaard" deel uit van PHP? Waarom staat die
niet in de handleiding en de commerciele varianten wel?

Los hiervan, waar het mij om gaat is dat je voor elke module die je
gebruikt, de licensie moet controleren.

Edwin Martin.


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

[Patrick]

In-Reply-To: <sW%Rc.422$mg.242@amsnews02.chello.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@supernews.com
Lines: 40
Xref: nl-news.euro.net nl.internet.www.server-side:35989

Edwin Martin wrote:
> Waarom maakt die dan niet "standaard" deel uit van PHP?

Geen idee, ik zit niet in het ontwikkelteam van PHP. Don't shoot the
messenger :-)

> Waarom staat die niet in de handleiding en de commerciele varianten wel?

Eh... die vraag is wat lastig te beantwoorden , aangezien het namelijk
wel in de handleiding staat ;-)

"Note: If you're interested in alternative free PDF generators that do
not utilize external PDF libraries, see this related FAQ."

En dan uit 'this related FAQ':

"13. How can I generate PDF files without using the non-free and
commercial libraries ClibPDF and PDFLib? I'd like something that's free
and doesn't require external PDF libraries.

There are a few alternatives written in PHP such as
http://www.ros.co.nz/pdf/, http://www.fpdf.org/,
http://www.gnuvox.com/pdf4php/, and
http://www.potentialtech.com/ppl.php. There is also the Panda module."

Overigens is PDFLib alleen in een commerciele situatie niet gratis
(zoals bij veel meer software het geval is).

> Los hiervan, waar het mij om gaat is dat je voor elke module die je
> gebruikt, de licensie moet controleren.

Tsja, het was misschien handiger geweest als zulke modules niet
standaard meegeleverd worden. Aan de andere kant staat toch duidelijk
vermeld in de handleiding dat het om een commerciele library gaat, en je
mag naar mijn idee geacht worden die gelezen te hebben om met die
library te kunnen werken :-)

Groeten,

Patrick

[Patrick]

Branko Collin wrote:
> Ah, dus je moet voor PDF uit drie licenties kiezen? Nog verwarrender!

Sterker nog, er zijn nog diverse andere alternatieven (zie mijn reactie
op Edwin's posting)!

Pittig, niet? :-)

Groeten,

Patrick

[Daniel Tryba]

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> >>>No namespaces
> >
> > Heeft C namespaces?
>
> Dat zou alleen een relevante opmerking zijn als PHP een alternatief voor C
> genoemd zou worden.

Het hebben van een namespace is helemaal niet relevant...

> >>>Non-standard date format characters
> >
> > Niet belangrijk tenzij je een C programmeur bent.
>
> Of Perl. Of Python. Of Java. Of zsh. Date-formatting op de strftime-manier
> is inmiddels een conventie geworden, dus de vraag is waarom PHP daarvan af
> heeft willen wijken.

Ik vind juist dat wat in Java gebruikt wordt een echte ramp... en
volgens mij (als ik even man strftime bekijk) komen die niet eens
overeen
(http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html).

--

Daniel Tryba

[Rene Pijlman]

Daniel Tryba:
>Het hebben van een namespace is helemaal niet relevant...

Inderdaad, slechts het hebben van meerdere namespaces is van nut.

--
René Pijlman

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

[robert]

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>
>> >>>No namespaces
>> >
>> > Heeft C namespaces?
>>
>> Dat zou alleen een relevante opmerking zijn als PHP een alternatief
>> voor C genoemd zou worden.
>
> Het hebben van een namespace is helemaal niet relevant...

Het had een groot probleem van PHP kunnen oplossen, dus ik zie niet in
waarom niet niet relevant zou zijn voor een discussie over bezwaren tegen
PHP.

>> Of Perl. Of Python. Of Java. Of zsh. Date-formatting op de strftime-manier
>> is inmiddels een conventie geworden, dus de vraag is waarom PHP daarvan af
>> heeft willen wijken.
>
> Ik vind juist dat wat in Java gebruikt wordt een echte ramp... en
> volgens mij (als ik even man strftime bekijk) komen die niet eens
> overeen
> (http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html).

Gelukkig gaat dat gefixt worden:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Formatter.html

--
robert