Onderwerp: Bezwaren tegen PHP als algemene programmeertaal

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

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.

Nico Coesel wrote:

>>Meer leesvoer over beperkingen van PHP:
>>http://www.ukuug.org/events/linux200...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/

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

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

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.usi....using.freepdf

--

Daniel Tryba

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

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

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

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/

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

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

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/...ateFormat.html).

--

Daniel Tryba

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

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/...ateFormat.html).

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

--
robert