Bezwaren tegen PHP als algemene programmeertaal

robert wrote:

> John Bokma <postmaster@castleamber.com>:
> > robert wrote:
> >
> >> Bedoel je de string '\t', of een tab-karakter? Want ik vind het niet
> >> echt een goed idee een tab-karakter in RE's te gebruiken, daar heb je
> >> juist metakarakters voor :)
> >
> > Ik bedoel een echt tab-teken voor dat bla bla.
>
> Ah, dat is dus ook iets wat ik in het algemeen niet doe, juist om problemen
> te voorkomen. Maar syntactisch gezien maakt het voor Perl helemaal niks uit
> of daar een tab of een paar spaties staan.

Dat klopt, maar je kan er mooi mee op je snufferd gaan. BV als je in je
__END__ tab separated data hebt staan, en de tabs raken ergens (editor,
mail, website) verloren.

--
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:
>
>> Ah, dat is dus ook iets wat ik in het algemeen niet doe, juist om
>> problemen te voorkomen. Maar syntactisch gezien maakt het voor Perl
>> helemaal niks uit of daar een tab of een paar spaties staan.
>
> Dat klopt, maar je kan er mooi mee op je snufferd gaan. BV als je in je
> __END__ tab separated data hebt staan, en de tabs raken ergens (editor,
> mail, website) verloren.

Als ik dat in een stuk C-code, of desnoods een simpele tekstfile, doe loop
ik net zo hard het risico dat het mis kan gaan, dat heeft weinig met de
gebruikte programmeertaal te maken.

--
robert

robert wrote:

> John Bokma <postmaster@castleamber.com>:
> > robert wrote:
> >
> >> Ah, dat is dus ook iets wat ik in het algemeen niet doe, juist om
> >> problemen te voorkomen. Maar syntactisch gezien maakt het voor Perl
> >> helemaal niks uit of daar een tab of een paar spaties staan.
> >
> > Dat klopt, maar je kan er mooi mee op je snufferd gaan. BV als je in je
> > __END__ tab separated data hebt staan, en de tabs raken ergens (editor,
> > mail, website) verloren.
>
> Als ik dat in een stuk C-code, of desnoods een simpele tekstfile, doe loop
> ik net zo hard het risico dat het mis kan gaan, dat heeft weinig met de
> gebruikte programmeertaal te maken.

Inderdaad, maar bij Perl, zeker door het gebruik van Here documents,
__END__ c.q __DATA_ etc heb ik een vermoeden dat sneller de fout gemaakt
wordt.

Ok, de spatie achter EOT was een beter voorbeeld :-(

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

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

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

Hoe bedoel je matig? Je kunt heel goed OO programmeren in iedere taal
die pointers naar functies ondersteund (en PHP doet dat).

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

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.

--
René Pijlman

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

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

MSN Messenger... nooit gebruikt. Welk channel? En wat is dan precies de
message om te sturen?

--
René Pijlman

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

Rene Pijlman wrote:

> John Bokma:
>
>>Rene Pijlman:
>>
>>>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.
>
> MSN Messenger... nooit gebruikt. Welk channel?

:-D Het heeft geen channels in principe (a la IRC zeg maar). Je stopt
mensen in een contactlijst, en met elk kan je praten (text, of voice).
Je zou kunnen zeggen dat je een channel kan maken, want als je met 1
iemand chat heb je een prive-channel, en je kan er mensen bij plaatsen,
en een soort groepsgesprek houden, hoewel ik dat zelden doe.

De meeste mensen op mijn lijst ken ik overigens van een andere,
webbased, chat. Je moet dus een manier vinden om mensen op je lijstje te
krijgen :-D.

Het plezier van MSN hangt nauw samen met wie er op je lijstje staat,
natuurlijk. Ik vind het prettig dat mijn lijstje voor een groot deel
bestaat uit mensen die niet programmeren (in welke taal dan ook). In een
grijs verleden (ook recent eigenlijk) wel eens naar IRC gekeken, maar
dat vond ik minder leuk.

Je kan ook met een niet-MS client "MSN" op, maar dan heb je geen geluid
(gebruik ik zelden), en geen webcam (heel veel gebruikt).

Gaim ziet er netjes uit en ondersteund meerdere IM protocollen (Yahoo,
AIM, etc) en werkt op meerdere besturingssystemen. Ik vond Trillian ook
erg lekker werken (compact). En Miranda heb ik ooit vluchtig bekeken.
Messengers die meerdere protocollen ondersteunen zijn handig als je
kennisen / vrienden, van alles gebruiken. Aan de andere kant, bijna
iedereen op mijn lijst gebruikt messenger.

> En wat is dan precies de message om te sturen?

Dat hangt een beetje van de andere kant af ;-). Een webcam kan helpen ;-)

Een ander iets, kan vast ook in Python, is om een botje te maken, en
messenger als een soort console gebruiken. Een voordeel is dat messenger
een log kan maken. En andere mensen kunnen je botje gebruiken. Voor niet
secure dingen zou je zo remote dingen op je computer kunnen checken
vanaf een andere locatie.

--
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:
>>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
cryptische logische operatoren hebben ze ook een leesbare variant
gegeven voor de mensen die bijvoorbeeld een pascal achtergrond hebben
waarin de logische operatoren voluit worden geschreven.

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

Nico Coesel:
>Je bedoelt 'and' en '&&' ? Die zijn hetzelfde, staat toch duidelijk in
>het tabelletje?

In de eerste plaats staat er nu juist dat ze niet hetzelfde zijn. 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.

--
René Pijlman

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

Rene Pijlman [on Sat, 29 May 2004 11:36:57 +0200] wrote:

> 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? Zou dat een programmeur niet een zorg mogen
zijn?

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

if (a) {
if (b) {

...
}
}



--
Erick

"The secret of success is sincerity. Once you can fake that, you've
got it made."

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
regel code schrijven die een *totaal ander* resultaat geeft voor and
vergeleken met &&. In PHP vast idem, zie
<http://www.php.net/manual/en/languag...ors.precedence>

En:

" The reason for the two different variations of "and" and "or"
operators is that they operate at different precedences. (See Operator
Precedence.) "

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

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

Erick T. Barkhuis wrote:

> Rene Pijlman [on Sat, 29 May 2004 11:36:57 +0200] wrote:
>
>
>>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?

Ja, zeer zeker:

(a++) and (a++)

> Zou dat een programmeur niet een zorg mogen
> zijn?

Het short circuiten is juist bedoelt om overhead te voorkomen. Het is
heel belangrijk om te weten of het gedaan wordt (slim) of niet.

> Wanneer ik echt zou willen voorkomen dat b wordt geevalueerd, dan zou ik
> vermoedelijk coderen:
>
> if (a) {
> if (b) {
>
> ...
> }
> }

Een and kan nooit true worden als het linker deel false is, dus waarom
toch evalueren? Dat is net zo dom als b evalueren als a false is in je
voorbeeld. Als je beiden geevalueerd wil hebben, schrijf je het maar uit
:-D.

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

Erick T. Barkhuis:
>Rene Pijlman:
>> if (kernTeHeet() and stopReactor())

>Dit lijken wel wat "ongelijkwaardige" methods te zijn, Rene.

Kanonnen, ik wilde slechts aantonen dat het al dan niet shortcut zijn van
de and-operator functioneel relevant is. Het gaat niet alleen om
performance of timing e.d., maar het heeft gevolgen voor de
functionaliteit. Neem me niet kwalijk dat mijn bewijs niet literair
geprogrammeerd is :-)

>Ik begrijp je punt. Maar aan de andere kant vraagt de programmeur wel om
>onduidelijkheid door die manier van coderen.

Integendeel, de programmeur vraagt om duidelijkheid. En dat is wat bij PHP
tekort schiet.

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

In de formele logica is dat natuurlijk zo. En het zal in bepaalde logische
en functionele programmeertalen ook wel zo werken.

Maar de programmeerconstructies zoals John en ik opvoerden komen in de
praktijk zoveel voor, dat de meeste programmeurs de voorkeur geven aan een
verkorte schrijfwijze met een shortcut-operator in plaats van geneste
if-then-else's. Maar daar mag je natuurlijk een andere opvatting over
hebben.

Dat neemt niet weg dat wat de semantiek van de operatoren ook is, het
welgedefinieerd en helder gedocumenteerd hoort te zijn.

[elders]
>....al vraag ik me af in welke situatie je zulke code nou weer zou willen
>gebruiken.

Het is toch een vrij bekend en veelgebruikt idioom.

--
René Pijlman

"Een piloot van de Mexicaanse luchtmacht heeft tijdens een routinevlucht
11 ufo's vastgelegd op film [...] De lichtobjecten omsingelden de
straaljager gedurende de routinevlucht om mogelijke drugssmokkel op te
sporen."
- nu.nl

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.

--
René Pijlman

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

Nico Coesel wrote:

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

Wie, wat waar? We hadden het over PHP, afgekeken van Perl. En in zowel
PHP als Perl zijn and en && *niet* hetzelfde.

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

Operator precendence is iets wat elke programmeur hoort te snappen. Of
schrijf jij dingen als 5 + (3 * 7) op? Een *echt* goede programmeur
schrijft leesbare code.

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

Die link boven schijnt de officiele documentatie te zijn. Als de
downloaded zonder de ruis is, is die minimaal.

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