Bezwaren tegen PHP als algemene programmeertaal

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

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

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

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/en...p5-changes.php

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

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

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

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

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/

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

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/languag...rs.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/linux200...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.

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.

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.

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

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

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