Onderwerp: Bezwaren tegen PHP als algemene programmeertaal

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

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/

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

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/

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)

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

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

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)

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

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

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

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

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

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

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