Bezwaren tegen PHP als algemene programmeertaal

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.

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/

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/

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

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.

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.

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

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/

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

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/

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.

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

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/

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

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