Vanwaar het PHP bashen

[phobosdeimos]

Je kan in elke taal waardeloze software schrijven. Maar PHP maakt het veel eenvoudiger om waardeloze software te schrijven. Vooral door het feit dat de instap drempel te laag is, net zoals visual basic vroeger.
Plus het is een amateuristische taaltje, dat bij elke release met gekkere ideeën komt, en daarbij vaak backwards compatibiliteit overboord gooit.
Plus de talloze veiligheidslekken niet te vergeten (denk dat meer dan 50% van alle security bugs door PHP software veroorzaakt worden?).

Ik ken erg weinig (zeg maar geen enkele) professionele programmeur van een hoog niveau die heult met PHP.

P.S. Ik ben eerder een pythonista

[ Voor 5% gewijzigd door phobosdeimos op 28-03-2009 11:35 ]

[Tanuki]

phobosdeimos schreef op zaterdag 28 maart 2009 @ 11:35:
Plus het is een amateuristische taaltje, dat bij elke release met gekkere ideeën komt, en daarbij vaak backwards compatibiliteit overboord gooit.[/b]

Volgens mij is juist het tegengestelde waar. Volgens mij worden heel veel zaken niet of niet helemaal doorgevoerd juist vanwege de backwards compatibility.

Kijk bijvoorbeeld naar de nieuwe namespace operator. Deze is, in tegenstelling tot alle andere talen, een backslash geworden. Het PHP team had ook even alles op z'n kop kunnen gooien en er voor kunnen zorgen dat static methods gewoon met -> aangeroepen konden worden en zo :: als namespace operator kunnen gebruiken.

PHP:

<?php
$x = MyClass->DoSomething();
$y = $myClassInstance->SomeOtherMethod();
?>

Of zelfs een . kunnen gebruiken en zo de hele taal aanpassen.

[Kalentum]

phobosdeimos schreef op zaterdag 28 maart 2009 @ 11:35:
Plus de talloze veiligheidslekken niet te vergeten (denk dat meer dan 50% van alle security bugs door PHP software veroorzaakt worden?).

Dat is moeilijk te zeggen. Ik denk dat de meeste fouten voortkomen uit onvoldoende kennis en besef van de risico's die je loopt als je een applicatie bouwt die publiekelijk toegankelijk is. Als een goedwillende amateurprogrammeur in Python aan de slag gaat (en Pyton is ook niet de meest ingewikkelde taal die er is) dan zal diegene tegen de zelfde problemen en fouten oplopen.

PHP op zich zelf is niet veiliger of onveiliger dan welke taal dan ook.

Ik ken erg weinig (zeg maar geen enkele) professionele programmeur van een hoog niveau die heult met PHP.

Dat zegt op zich niet zoveel. Ik persoonlijk ken geen enkele programmeur die met Ruby 'heult' bijvoorbeeld, wat niet betekent dat Ruby een amateuristische taal is. Feit is wel dat PHP ook professioneel wordt ingezet, voornamelijk dus voor webbased toepassingen. Er zijn zat mensen die hun geld ermee verdienen. Daar zitten kleine websitebouwers tussen maar ook mensen die complexe webapplicaties bouwe.

Wat vind jij een 'hoog' niveau? Waar moet je dan aan denken?

[Verwijderd]

Ik zet rutgerw even kracht bij met google.
8 miljard resultaten tov asp, 2.3 miljard.

Verder heb ik geen reactie op het onderwerp. Ben zelf pro php, maar de hier bedachte constructies omtrent php's designproblemen zijn uitermate interessant en tegelijk lachwekkend.

Lekker door discussieren jullie

[NMe]

krvabo schreef op zaterdag 28 maart 2009 @ 05:21:
[...]

En je hebt gelijk, ik wist dat Zend 'werd meegeleverd', maar niet dat deze functies vanuit het Zend-framework komen. Of 'dat het language constructs zijn'*. Dat is imho ook niet meer dan een 'wist je dat..' en voor de gemiddelde php-scripter totaal irrelevant.

Nou heb je daar gelijk in, maar ooit zou je hier tegenaan kunnen lopen:

Note: Because this is a language construct and not a function, it cannot be called using variable functions

Je zal het niet vaak nodig hebben, maar als je er een keer tegenaan loopt is het wel heel handig om te weten dat dit helemaal geen functie is.

rutgerw schreef op zaterdag 28 maart 2009 @ 11:13:
[...]

Dat zijn geen onderdelen van het Zend Framework. Ze worden gewoon meegeleverd met PHP. Zend Framework niet. Ze horen bij de standaardfuncties.

Dan zijn het daarmee nog steeds geen onderdelen van de taal zelf.

[MBV]

Ok, jij wilt zeggen dat je de deze functies geen onderdeel van de taal vindt? Ik denk niet dat er veel mensen zijn die het daar uit praktisch oogpunt mee eens zijn. Zend Framework is iets anders, dat is toevallig door dezelfde makers gemaakt maar geen onderdeel van de taal.

On a side note: wat is volgens jouw definitie onderdeel van de taal C++? Of misschien makkelijker: van java? Is java.lang.String onderdeel van de taal? En java.util.Set? Alles uit de namespace java, alles uit java.lang, of alleen de basis-types int/char/byte? IMHO hoort java.* gewoon bij de taal Java, net zoals stdlib bij C, en STL bij C++.

spoiler:

En zodra je zegt dat java.lang er niet bij hoort: java.lang.Object

[prototype]

Ze maken imo meteen deel uit van de taal op 't moment dat er geen enkele andere wijze is om ze te omzeilen. java.lang.Object b.v. is er zo een. Dat gezegd hebbende vind ik dan ook zoiets als java.util.Set niet direct een onderdeel van de taal maar meer een datastructuur die je niet perse dient te gebruiken. java.util.iterator en java.util.iterable daarentegen worden gebruikt icm met de for-each constructie van Java en vind ik dan wel weer een onderdeel van de taal.

In C++ is dat toch net een ander verhaal daar je de STL helemaal niet hoeft te gebruiken. Als je een C++ string wil gebruiken dien je deze of een van de headers te includen die deze indirect include te includen. Dat gebeurt dus niet automagisch.

[eghie]

MBV schreef op zaterdag 28 maart 2009 @ 15:10:
Ok, jij wilt zeggen dat je de deze functies geen onderdeel van de taal vindt? Ik denk niet dat er veel mensen zijn die het daar uit praktisch oogpunt mee eens zijn. Zend Framework is iets anders, dat is toevallig door dezelfde makers gemaakt maar geen onderdeel van de taal.

On a side note: wat is volgens jouw definitie onderdeel van de taal C++? Of misschien makkelijker: van java? Is java.lang.String onderdeel van de taal? En java.util.Set? Alles uit de namespace java, alles uit java.lang, of alleen de basis-types int/char/byte? IMHO hoort java.* gewoon bij de taal Java, net zoals stdlib bij C, en STL bij C++.

spoiler:

En zodra je zegt dat java.lang er niet bij hoort: java.lang.Object

Nou ja, ik noem dat gewoon een library/framework. In dit geval de standaard library/framework wat meegeleverd wordt. Kijk dan eens naar .NET. Die heeft ook een complete functie set meegeleverd, maar die horen niet echt specifiek bij C# of VB.NET of C++.NET of whatever.

[Sebazzz]

prototype schreef op zaterdag 28 maart 2009 @ 16:29:
Dat gebeurt dus niet automagisch.

Roep maar eens een Int64 (ja, kan gewoon via long, maar toch) of een Exception aan, hoe doe je dat zonder System te gebruiken, bij C#? Het is overigens wel mogelijk om je los te koppelen van de hele System namespace, want daar is in VS een optie voor maar ik zou niet weten waarom je dat zou willen.

[alienfruit]

Ik gebruik de laatste tijd met name Oxygene voor .NET. Blijkbaar was de concurrent van Delphi.NET beter en zodoende gebruikt Borland/Codegear nu [url=hhttp://www.remobjects.com/oxygene.aspx#3]Oxygene[/url]. En ja, dat komt grotendeels van Nederlandse bodem

[ Voor 10% gewijzigd door alienfruit op 28-03-2009 22:58 ]

[vorlox]

Ik geef jullie allemaal gelijk, echter ik vind die mannen van PHP wel volhoudend..het zijn net duitsers.

De porsche 911 met de motor achter de achterwielen is echt een ontwerp fout....altijd geweest en zal het altijd blijven, toch is de nieuwe versie een van de best gebalanceerde sportauto's ter wereld.

Whehe ze hebben het zelfs geprobeerd met lood in de voorbumper...is nou ook niet de manier die je van eeen sportwagen fabrikant verwacht.
(Meneer we hebben uw auto aan de voorkant 100 Kilo zwaarde gemaakt. WHAHAHAHA)

Het is veel te makkelijk om op nieuw te beginnen als je denkt een fout te hebben gemaakt.

[ontopic]
Ik dacht dat tweakers.net ook gemaakt was in PHP, weet dit niet zeker maar ik vraag me af wat de beweegredenen daarvoor geweest zijn dan.[/ontopic]

[ Voor 32% gewijzigd door vorlox op 29-03-2009 06:32 ]

[qless]

Los van alle kritiiek op de opbouw, bij de eerste php versies had nog niemand het idee dat het zo groot zou worden...

En natuurlijk kun je in PHP ook keurig leesbare en onderhoudbare programma's schrijven, maar dan moet je daar zelf wel de hand in houden, talen als C3 en Java zijn wat dat betreft dwingender en volwassener.

Tot nu blijft PHP wel de handigste, goedkoopste, platform onafhankelijke, laag drempelige manier om een dynamische site te bouwen...

[prototype]

Sebazzz schreef op zaterdag 28 maart 2009 @ 22:36:
[...]
Roep maar eens een Int64 (ja, kan gewoon via long, maar toch) of een Exception aan, hoe doe je dat zonder System te gebruiken, bij C#? Het is overigens wel mogelijk om je los te koppelen van de hele System namespace, want daar is in VS een optie voor maar ik zou niet weten waarom je dat zou willen.

We hebben het hier niet over C#, maar ook daarbij gaat imho het argument op dat taal constructies die gekoppeld zijn aan std lib classes imo gewoon onderdeel zijn van de taal.

vorlox schreef op zondag 29 maart 2009 @ 06:17:
[ontopic]
Ik dacht dat tweakers.net ook gemaakt was in PHP, weet dit niet zeker maar ik vraag me af wat de beweegredenen daarvoor geweest zijn dan.[/ontopic]

Zoals Johan Cruijff ooit zei, "elk nadeel heb z'n voordeel". Het stateless gedrag van het afhandelen van PHP requests maakt het opzich best geschikt voor frontend scaling aangezien het een request moet afhandelen, en daarna gewoon alles weggooit: het draait niet als een applicatieserver b.v. waarbij je niet altijd zeker ervan bent of een request op een machine ervoor zorgt dat de applicatieserver doet blokkeren (natuurlijk zijn hier manieren om omheen te werken, maar bij PHP is dat lekker eenvoudig dat dat allemaal niet nodig is). Tel daar een geschikte database backend setup bij op en presto, you're set to go :-) Facebook werkt ook ongeveer met dit principe: PHP frontend, django backend. Ook het economische factor kan erbij komen kijken: niet zozeer in de zin dat PHP open source is en in feite "gratis", maar ook dat er al zoveel developers zijn die de taal beheersen (of iig beweren) met als gevolg dat je veel aanbod hebt. En wanneer het aanbod groter is dan de vraag dan zul je opzich moeten prijsvechten :-) M.a.w. veel en over 't algemeen relatief goedkope PHP ontwikkelaars levert dat op.

[ Voor 53% gewijzigd door prototype op 29-03-2009 12:23 ]

[Zoijar]

qless schreef op zondag 29 maart 2009 @ 11:31:
Tot nu blijft PHP wel de handigste, goedkoopste, platform onafhankelijke, laag drempelige manier om een dynamische site te bouwen...

Dat ligt eraan; onderhoud is meestal het duurst...

[frickY]

krvabo schreef op vrijdag 27 maart 2009 @ 21:39:
En om niet te vergeten het irritante:

PHP:

in_array();
is_array();
is_string();
isset(); // hier geen is_set()?
empty(); // en niet isempty() of is_empty()?

Hoewel ik snap dat needle en haystack omdraaien wel heel erg veel systemen zou breken, is voor het laatste toch simpel een alias al genoeg om dit langzaamaan recht te trekken (in php6 de aliassen en in php7 de inconsistente oude namen verwijderen).

isset() en empty() zijn géén functies, maar language constructs. Een onderscheid in syntax is daarom helemaal zo vreemd niet.


//Edit
Shit, was al genoemd

Probleem van PHP is gewoonweg dat het veel te veel valnetten had, waardoor het enorm laagdrempelig is. Daardoor werken veel prutsers er mee, en bestaat er veel prutscode.

[ Voor 27% gewijzigd door frickY op 29-03-2009 12:27 ]

[prototype]

Waarom is empty trouwens language construct...

Returns FALSE if var has a non-empty and non-zero value.

The following things are considered to be empty:

* "" (an empty string)
* 0 (0 as an integer)
* "0" (0 as a string)
* NULL
* FALSE
* array() (an empty array)
* var $var; (a variable declared, but without a value in a class)

PHP:

<?php
function empty($var) {
    return (is_string($var) && ((string)$var == "")
        || (string)$var == "0") 
        || (is_int($var) && (int)$var === 0) 
        || $var === null 
        || $var === false 
        || (is_array($var) && sizeof($var) == 0)
        || isset($var);
}
?>

ofzoiets?

[ Voor 2% gewijzigd door prototype op 29-03-2009 12:48 . Reden: Even wat leesbaarder gemaakt ;-) ]

[Verwijderd]

prototype schreef op zondag 29 maart 2009 @ 12:44:
Waarom is empty trouwens language construct...

Omdat het anders een E_NOTICE zou triggeren als een variabele niet bestaat.

[Patriot]

Waarschijnlijk omdat je nu stuk loopt op die laatste? In de context van die functie bestaat $var altijd. Als je jouw functie aanroept met een niet bestaande variabele krijg je bovendien een notice.

EDIT: Damn you Cheatah

[ Voor 9% gewijzigd door Patriot op 29-03-2009 12:55 ]

[prototype]

Ahja, good one :-) Voelt nu eerder aan alsof het een macro is though.

[ Voor 58% gewijzigd door prototype op 29-03-2009 13:07 ]

[.oisyn]

prototype schreef op zaterdag 28 maart 2009 @ 16:29:
In C++ is dat toch net een ander verhaal daar je de STL helemaal niet hoeft te gebruiken. Als je een C++ string wil gebruiken dien je deze of een van de headers te includen die deze indirect include te includen. Dat gebeurt dus niet automagisch.

De STL is de precursor van de container library van de standaard C++ library. Het is niet de standaard C++ library zelf

Overigens:

C++:

int main()
{
     const char * c = typeid(int).name();
}

Zou niet moeten compilen (sommige compilers hebben hier echter lak aan). De typeid operator returnt een reference naar een std::type_info structure, die in <typeinfo> gedefinieerd is. Een typisch voorbeeld van hoe taal en library met elkaar verwikkeld kunnen zijn.

[Verwijderd]

Ik wil me niet wagen aan het punt of PHP nou echt voor de zakelijke mark geschikt is,
Maar,ik vind het een heerlijke manier om allerlei leuke hobby dingen te kunnen doen!

en ik moet zeggen,dat ik van beperkingen nauwelijks tot geen last heb..
het werkt,het doet wat het moet doen...
dat is al heel wat...

en voor mij als Linux gebruiker,is .NET sowieso niet echt een oplossing
omdat het toch een Microsoft product blijft,en je dan toch nog wel eens wat comptabiliteit mist.

[roy-t]

Verwijderd schreef op maandag 30 maart 2009 @ 10:52:
Ik wil me niet wagen aan het punt of PHP nou echt voor de zakelijke mark geschikt is,
Maar,ik vind het een heerlijke manier om allerlei leuke hobby dingen te kunnen doen!

en ik moet zeggen,dat ik van beperkingen nauwelijks tot geen last heb..
het werkt,het doet wat het moet doen...
dat is al heel wat...

en voor mij als Linux gebruiker,is .NET sowieso niet echt een oplossing
omdat het toch een Microsoft product blijft,en je dan toch nog wel eens wat comptabiliteit mist.

Voor web (dus ASP.NET) is het compleet transparant, het enige dat de gebruiker zal zien, of het nu linux is of niet, is een html pagina met wat javascript, dat draait op zowel Linux, Windows en heel wat andere meuk prima. Of het request naar de server daarna op de server afgehandeld wordt in ASM, IL, JAVA, PHP, Fortran, LISP, HASKEL of wat anders maakt voor de client kant geen drol uit. Er wordt toch weer netjes "<!DOCTYPE HTML etc etc" geretourneerd.

Voor communicatie naar de client is het keizen van een taal dus een eitje, alle voldoen wel (zolang ze maar nullen en enenen naar een socket kunnen sturen). Het gaat om je eigen server park, eigen technologie, affiniteit en eisen waarop je een webtaal kiest.

[NMe]

prototype schreef op zondag 29 maart 2009 @ 12:44:

PHP:

function empty($var) {
        || $var === null

offtopic:
Geen idee of dit in PHP ook zo geïmplementeerd is (maar dat hoop ik in elk geval wel): null is nooit gelijk aan null. Checken of iets null is doe je met is_null().

[.oisyn]

NMe schreef op maandag 30 maart 2009 @ 11:48:
[...]

offtopic:
Geen idee of dit in PHP ook zo geïmplementeerd is (maar dat hoop ik in elk geval niet): null is nooit gelijk aan null. Checken of iets null is doe je met is_null().

Ik hoop niet dat jij dat hoopt. Het is geen null als in "ongedefinieerd" zoals in een database. In alle C-like talen gebeurt het gelukkig ook niet, dat null ongelijk is aan null. Het betekent dan ook letterlijk "niets", niet "niet ingevuld"

[ Voor 52% gewijzigd door .oisyn op 30-03-2009 12:24 . Reden: quote erbij omdat je je reactie hebt geedit :Y) ]

[Voutloos]

Gedrag van onder andere empty, == en === is gewoon duidelijk zichtbaar @ http://nl.php.net/manual/en/types.comparisons.php .

[NMe]

Dan heb ik niks gezegd.

[Cartman!]

NMe: na wat zoekwerk denk ik dat je Zend Engine bedoelde ipv. Zend Framework eerder want ik begreep eerst totaal niet wat je bedoelde ermee Zend Framework staat verder los van het hele devgebeuren van PHP zelf, de naam zegt t al: Framework.

[Verwijderd]

frickY schreef op zondag 29 maart 2009 @ 12:26:
Probleem van PHP is gewoonweg dat het veel te veel valnetten had, waardoor het enorm laagdrempelig is. Daardoor werken veel prutsers er mee, en bestaat er veel prutscode.

En dat maakt PHP direct een slecht systeem, waar vollop op gebashed moet worden? Denk je niet dat dit een beetje generaliserend is? Zo zijn er wel meer voorbeelden te noemen!

Iedereen kan een muurtje metselen, zo moeilijk is dat niet. Mensen die er goede kennis of een opleiding voor hebben, kunnen dat ongetwijfeld stukken beter. In andere programmeertalen kan iedereen prutscode schrijven, gewoon een kwestie van ervaring op doen en bereid zijn om te leren. Voor elke taal hetzelfde.

Ja, ik ben zelf actief bezig met PHP. Ik heb me maar neergelegd bij het eeuwig bashen tegen de taal. Het is gewoon een kwestie van smaak, waar iedereen anders over zal denken. I rest my case...

[.oisyn]

Verwijderd schreef op maandag 30 maart 2009 @ 15:23:
[...]
En dat maakt PHP direct een slecht systeem, waar vollop op gebashed moet worden?

Nee, dat maak jij er nu van. Het gaat hier voornamelijk om de gebreken van PHP zelf. Dat er veel prutsers zijn is geen gebrek van PHP. Het is wel de grootste oorzaak van PHP's imago, maar daar gaat het nou net niet over.

I rest my case...

You don't have a case

[ Voor 108% gewijzigd door .oisyn op 30-03-2009 15:38 ]

[kenneth]

Verwijderd schreef op maandag 30 maart 2009 @ 15:23:
Ja, ik ben zelf actief bezig met PHP. Ik heb me maar neergelegd bij het eeuwig bashen tegen de taal. Het is gewoon een kwestie van smaak, waar iedereen anders over zal denken. I rest my case...

Ieder zijn ding ja, maar er wordt hier toch echt inhoudelijk ingegaan op de gebreken, niet echt een gevalletje van smaak.

[Verwijderd]

Verwijderd schreef op maandag 30 maart 2009 @ 15:23:
[...]
Iedereen kan een muurtje metselen, zo moeilijk is dat niet. Mensen die er goede kennis of een opleiding voor hebben, kunnen dat ongetwijfeld stukken beter.

Scheve vergelijking.

In werkelijkheid, in geval van een muurtje metselen bijvoorbeeld, huur je iemand in waarvan je of weet dat ze de juiste ervaring hebben of iemand die de juiste certificaten heeft behaald (via een aannemer bijvoorbeeld).

In de programmeurs wereld, en dan bedoel ik in het 'websites voor kleine bedrijfjes' gedeelte is die controle er totaal niet voor zover ik weet, iedereen noemt zichzelf 'webdeveloper' en iedereen 'kan php'. Dààr gaat het mis.

[Verwijderd]

.oisyn schreef op maandag 30 maart 2009 @ 15:28:
Nee, dat maak jij er nu van. Het gaat hier voornamelijk om de gebreken van PHP zelf. Dat er veel prutsers zijn is geen gebrek van PHP. Het is wel de grootste oorzaak van PHP's imago, maar daar gaat het nou net niet over.

Dat snap ik, maar dat was de enige conclusie die ik kon trekken uit de post die ik citeerde. Vandaar dat ik het aanhaalde, niet dat ik het er mee eens ben. Beetje onduidelijk omschreven van mezelf wellicht.

Verwijderd schreef op maandag 30 maart 2009 @ 17:05:
In werkelijkheid, in geval van een muurtje metselen bijvoorbeeld, huur je iemand in waarvan je of weet dat ze de juiste ervaring hebben of iemand die de juiste certificaten heeft behaald (via een aannemer bijvoorbeeld).

In de programmeurs wereld, en dan bedoel ik in het 'websites voor kleine bedrijfjes' gedeelte is die controle er totaal niet voor zover ik weet, iedereen noemt zichzelf 'webdeveloper' en iedereen 'kan php'. Dààr gaat het mis.

Waarom zou je iemand zonder certificaten wel een website laten bouwen, maar geen muurtje laten bouwen? Ligt het dan niet helemaal aan de consument die hier de fout in gaat? Iedere gek kan zich ook 'metselaar' noemen.

Daarnaast, voor PHP'ers zijn er ook officiële (Zend?) certificaten. Dus de keuze voor een metselaar zonder certificaat is net zo eenvoudig gemaakt als een PHP'er zonder certificaat, het is voor de consument alleen wat tastbaarder. Het ligt misschien ook wel aan de kennis van zaken bij de consument. Een muurtje is makkelijker te visualiseren wellicht...

[YopY]

Verwijderd schreef op maandag 30 maart 2009 @ 17:05:
[...]

Scheve vergelijking.

In werkelijkheid, in geval van een muurtje metselen bijvoorbeeld, huur je iemand in waarvan je of weet dat ze de juiste ervaring hebben of iemand die de juiste certificaten heeft behaald (via een aannemer bijvoorbeeld).

In de programmeurs wereld, en dan bedoel ik in het 'websites voor kleine bedrijfjes' gedeelte is die controle er totaal niet voor zover ik weet, iedereen noemt zichzelf 'webdeveloper' en iedereen 'kan php'. Dààr gaat het mis.

^ Dit. Wat misschien nog wel erger is, iedereen beschouwt zichzelf als een goede metselaar, en probeert zijn kennis in het metselen ook vaak door te geven aan anderen - zelfs al zijn zijn muurtjes scheef.

Dat is op zich niet eens zo'n probleem vanuit PHP zelf, maar meer vanuit de community. Ik denk ook zo dat wanneer de PHP documentatie uitgebreid wordt met 'best practices' zoals dat bijvoorbeeld bij Java gebruikt (ook al moet die ook nodig opgeschoond worden), de gemiddelde kwaliteit van PHP devvers ook omhoog zal gaan.

Er is gewoon zoveel PHP code op internet geplaatst, zowel goeie als slechte, dat het heel moeilijk wordt om door de scheve stenen de muur te zien. Hierdoor is het, vooral voor beginnende programmeurs, moeilijk om nu goede van slechte code te kunnen onderscheiden - vooral omdat iedereen zegt 'zo moet het', ipv 'dit hoor je eigelijk nooit te doen om die-en-die-en-die redenen, zie ook *link*, *link*, *link*.

Ik zou zelf, als ik de PHP organisatie was danwel er enige invloed op had, ook op hameren om kwaliteitseisen te stellen aan bijvoorbeeld PHP lesboeken en officiele websites. En een officiele PHP coding standaard op te stellen.

Ook zouden de voorbeelden die nu lukraak in de comments van bepaalde functies nagekeken moeten worden door nozele figuren, zodat geen verkeerde informatie daarin komt.

/rant

[.oisyn]

YopY schreef op maandag 30 maart 2009 @ 17:32:
Ik zou zelf, als ik de PHP organisatie was danwel er enige invloed op had, ook op hameren om kwaliteitseisen te stellen aan bijvoorbeeld PHP lesboeken en officiele websites. En een officiele PHP coding standaard op te stellen.

Eens, maar ik kan me niet van de indruk onttrekken dat als ze dat konden, de taal zelf ook een stuk beter in elkaar gezeten had . Het ligt niet bepaald in de lijn der verwachtingen van Zend imho.

[ Voor 6% gewijzigd door .oisyn op 30-03-2009 17:36 ]

[Patriot]

YopY schreef op maandag 30 maart 2009 @ 17:32:
[...]

Er is gewoon zoveel PHP code op internet geplaatst, zowel goeie als slechte, dat het heel moeilijk wordt om door de scheve stenen de muur te zien. Hierdoor is het, vooral voor beginnende programmeurs, moeilijk om nu goede van slechte code te kunnen onderscheiden - vooral omdat iedereen zegt 'zo moet het', ipv 'dit hoor je eigelijk nooit te doen om die-en-die-en-die redenen, zie ook *link*, *link*, *link*.

Ik zie het probleem vanuit de community eigenlijk anders.. Er zijn een drietal groepen in de PHP community: de mensen die er (nog) niks van afweten; de mensen die denken dat ze er iets van afweten en de mensen die er ook daadwerkelijk iets van afweten. Wat je vervolgens vaak ziet is dat vooral de tweede groep de eerste groep probeert te helpen. De derde groep ziet de eerste groep vaak als verloren zaak, en als er al eens mensen vanuit de derde groep komen helpen is het niet zeer zelden het geval dat deze onderling in een discussie geraken over een mierenneukerig puntje. Een discussie die ontzettend verwarrend is voor de persoon die in eerste instantie de vraag stelde.

En dan komt groep twee opeens langs, en dat zijn mensen die zelf ook gewoon niet volleerd zijn. Groep één ziet alleen dat die mensen hen proberen te helpen, en neemt dat wat ze zeggen als zoete koek aan. Hier komt ook jouw "zo moet het" vs. "zo moet het niet, omdat.." ten tonele. Het eerste is geen goede zaak omdat het inderdaad zo is dat mensen er niets van leren, dat betekend echter niet dat de tweede manier beter is als de persoon van wie het komt zelf geen verstand van zaken heeft. Niets leren is namelijk minder erg dan iets fout leren.

[MBV]

@CoenJacobs: heb je die cursussen wel eens gezien?

Aan het einde van de cursus weet je alle keywords etc van PHP uit je hoofd (wat elke ervaren programmeur in een andere taal dus intikt op php.net om te zoeken) en je weet vervolgens nog niet hoe je moet programmeren.

_{Tenminste, dat was wat ik er 2 jaar geleden over vond. Misschien heeft Zend haar leven verbeterd, maar het lijkt er niet op: http://www.zend.com/en/se...tion/php-5-certification/}

@Patriot: het probleem is dat je op dat moment niet eens weet dat je in groep 2 zit

[ Voor 8% gewijzigd door MBV op 30-03-2009 18:33 ]

[Megamind]

MBV schreef op maandag 30 maart 2009 @ 18:30:
@CoenJacobs: heb je die cursussen wel eens gezien?

_{Tenminste, dat was wat ik er 2 jaar geleden over vond. Misschien heeft Zend haar leven verbeterd, maar het lijkt er niet op: http://www.zend.com/en/se...tion/php-5-certification/}

Helaas is het nogsteeds zo... Veel te veel vragen over de functies van PHP, welke parameters functie X heeft. Daar heb je toch echt geen ruk aan...

[T-MOB]

Megamind schreef op maandag 30 maart 2009 @ 19:49:
Helaas is het nogsteeds zo... Veel te veel vragen over de functies van PHP, welke parameters functie X heeft. Daar heb je toch echt geen ruk aan...

Nu ja, 't is niet dat PHP consistent is op dat vlak (in_array vs strpos bijvoorbeeld)

Verder vermaak ik me prima met PHP. Er is van alles op aan te merken vanuit theoretisch oogpunt, maar in de praktijk is PHP5 heel goed bruikbaar.

[Janoz]

Megamind schreef op maandag 30 maart 2009 @ 19:49:
[...]

Helaas is het nogsteeds zo... Veel te veel vragen over de functies van PHP, welke parameters functie X heeft. Daar heb je toch echt geen ruk aan...

Dat uit je hoofd leren is bij php anders best handig.

Dan weet je namelijk precies wanneer je nu eerst de haystack of eerst de needle moet doen.

Let trouwens ook eens op de professionele manier waarop met dergelijke feature requests omgegaan wordt door de ontwikkelaars van php : http://bugs.php.net/bug.php?id=37088 .

--edit-- Hmm, door mijn bronnen zoektoch ben ik een rijkelijke spuit 1 geworden

[ Voor 6% gewijzigd door Janoz op 30-03-2009 20:19 ]

[Megamind]

Janoz schreef op maandag 30 maart 2009 @ 20:18:
[...]

Dat uit je hoofd leren is bij php anders best handig.

Dan weet je namelijk precies wanneer je nu eerst de haystack of eerst de needle moet doen.

Pff, daar heb je code completion voor in PHPed.

Het is natuurlijk een PHP examen, geen algemeen programmeer examen. Maar toch zouden ze dieper op de materie in kunnen gaan.

Misschien dat PHP in een future versie commercieel wordt zoals MySQL en we een wat beter team kunnen verwachten.

[RobIII]

Megamind schreef op maandag 30 maart 2009 @ 20:29:
[...]

Pff, daar heb je code completion voor in PHPed.

En lees nou de pagina waar Janoz naar verwijst eens na (Of mijn sarcasmedetector is stuk )

Het is juist, o.a., deze houding die ons steeds weer voer geeft om PHP te bashen. Sure; het is op te lossen met een leuke/dikke/vette/goeie IDE. Maar dat neemt niet weg dat het gewoon onlogisch-tot-op-het-bot in elkaar steekt. Doe daar dan wat aan i.p.v. workarounds verzinnen.

[ Voor 41% gewijzigd door RobIII op 30-03-2009 20:32 ]

[mphilipp]

Cartman! schreef op donderdag 26 maart 2009 @ 18:40:
Weer lekker makkelijk op PHP bashen zo te zien zoals vaker gebeurt hier...

Wat interesseert jou het nou welke taal iemand leuk/handig/mooi vindt? Het getuigt alleen maar van ongelooflijke domheid om een programmeertaal af te kraken, dus laat de kraker zijn eigen werk maar doen. Gewoon niet aan storen en niet op in gaan. Net als die oeverloze Windows/Mac discussies. Mensen die roepen dat het ene platform beter is als het andere zijn erg dom en weten 0,0 van ICT. Vandaar dat ik hooguit nog wel eens een opmerking maak dat ze moeten nadenken of er niets van snappen.

Maar ga er nou geen punt van maken. Laat de dommen lekker raaskallen. Waar gaat het over?

[Janoz]

Zeg mphilipp, heb je het topic wel gelezen? Er wordt meermaals gefundeerd en beargumenteerd ingegaan op enkele design fouten. Dat is geen mac/windows of firefox/ie discussie.

Komop zeg, wat is er nu niet te snappen aan dat het onhandig is dat het per methode wisseld of de needle of de haystack vooraan moet? Je gaat mij toch niet vertellen dat jij dat wel handig vind? Dat is toch gewoon een slordigheid?

De grootste domheid die in dit topic naar voren komt is de incapabelheid van het team achter php, maar ook de tunnelvisie van sommige van haar verdedigers.

[prototype]

mphilipp schreef op maandag 30 maart 2009 @ 20:32:
[...]

Wat interesseert jou het nou welke taal iemand leuk/handig/mooi vindt? Het getuigt alleen maar van ongelooflijke domheid om een programmeertaal af te kraken, dus laat de kraker zijn eigen werk maar doen. Gewoon niet aan storen en niet op in gaan. Net als die oeverloze Windows/Mac discussies. Mensen die roepen dat het ene platform beter is als het andere zijn erg dom en weten 0,0 van ICT. Vandaar dat ik hooguit nog wel eens een opmerking maak dat ze moeten nadenken of er niets van snappen.

Maar ga er nou geen punt van maken. Laat de dommen lekker raaskallen. Waar gaat het over?

Ik vind het altijd weer bijzonder vermakelijk als iemand een advies plaatst die hij/zij schijnbaar zelf niet kan opvolgen.

[.oisyn]

mphilipp schreef op maandag 30 maart 2009 @ 20:32:
Het getuigt alleen maar van ongelooflijke domheid om een programmeertaal af te kraken

Grappige mening, kun je 'm ook onderbouwen, of ben je gewoon persoonlijk aan het aanvallen omdat je op je pik bent getrapt?

Blijkbaar mis je zelf de intelligentie om fanboydiscussies te onderscheiden van inhoudelijke discussies met feiten en argumenten van mensen die het onderwerp "taalontwerp" een interessant onderwerp vinden. Geeft verder niets hoor, mensen als jij moeten er ook zijn . Maar je plaats is echter niet in deze topic, dus hup, ga maar weer buiten spelen.

@hieronder: 't Is toch gezellig hier? Ik lach me iig suf

[ Voor 9% gewijzigd door .oisyn op 30-03-2009 21:05 ]

[RobIII]

Hee, hee.. kunnen we 't een beetje gezellig houden?

[Megamind]

RobIII schreef op maandag 30 maart 2009 @ 20:30:
[...]

En lees nou de pagina waar Janoz naar verwijst eens na (Of mijn sarcasmedetector is stuk )

Je hebt gelijk, die las ik pas nadat ik postte

Maar het is inderdaad zo dat er veel te veel inconsistency is, dat is jammer.

Janoz schreef op maandag 30 maart 2009 @ 20:49:
De grootste domheid die in dit topic naar voren komt is de incapabelheid van het team achter php, maar ook de tunnelvisie van sommige van haar verdedigers.

Ik denk dat veel mensen begonnen zijn met PHP, of alleen met PHP gewerkt hebben, en daarom niet beter weten.

[Janoz]

Megamind schreef op maandag 30 maart 2009 @ 21:09:
Ik denk dat veel mensen begonnen zijn met PHP, of alleen met PHP gewerkt hebben, en daarom niet beter weten.

Ik denk dat je daar niet ver van de waarheid zit. Ik ben het iig grondig met je eens.

[RayNbow]

.oisyn schreef op maandag 30 maart 2009 @ 20:54:
[...]feiten en argumenten van mensen die het onderwerp "taalontwerp" een interessant onderwerp vinden.

offtopic:
Ik krijg bijna de neiging om de shameless plugs te gaan turven

[Gomez12]

Ach, php heb ik zo ongeveer dezelfde mening over als excel. Als ik het zelf gemaakt heb dan kan ik ermee overweg, heeft iemand anders het gemaakt dan ga ik me irriteren aan de inconsistensies / slechte documentatie etc.

Deels komt dit door de gemiddelde goedkope php-programmeur en deels door gewoon de inconsistenties van de taal zelf ( want dingen als needle/ haystack moet je wmb documenteren als het inconsequent gebruikt wordt, dus bij php bijna altijd ).

Ik verwacht gewoon een syntax op te kunnen zoeken en een argument volgorde uit de voorgaande syntax op te kunnen maken in mijn hoofd, dit kan bij java redelijk, bij c redelijk, bij vb redelijk, bij python redelijk, maar bij php kan dit dus gewoon niet.
Bij zo ongeveer elke needle/haystack aanroep gooi ik er maar weer een helppage/ide bij om te kunnen zien wat nu ook alweer de goede volgorde was, lekker doorwerken zit er voor mij dan ook niet echt bij met andersmans php-code.

Megamind schreef op maandag 30 maart 2009 @ 21:09:
[...]
Ik denk dat veel mensen begonnen zijn met PHP, of alleen met PHP gewerkt hebben, en daarom niet beter weten.

Kom op, bepaalde inconsistenties moeten zelfs iemand die voor de eerste keer een php-manual over strings doorleest opvallen. Dan kun je zeggen dat je niet beter weet, maar ik heb nog steeds de illusie dat mensen eigen verstand hebben...

[Megamind]

Gomez12 schreef op maandag 30 maart 2009 @ 21:31:
Kom op, bepaalde inconsistenties moeten zelfs iemand die voor de eerste keer een php-manual over strings doorleest opvallen. Dan kun je zeggen dat je niet beter weet, maar ik heb nog steeds de illusie dat mensen eigen verstand hebben...

Toen ik 14 jaar oud was en met PHP begon las ik geen man pagina over strings Wel tutorials op PHPFreakz...

[Gomez12]

Tja imho als je in_array en strstr in 1 stuk code ziet staan en je ziet de inconsistentie niet dan ben je of geen programmeur of gewoon niet geschikt als programmeur.

Maakt mij niet echt uit of het nou in een tutorial of een man pagina staat.

offtopic:
Om maar niet te beginnen over het nivo wat sites als phpfreakz verspreiden en hoeveel dit de taal nog meer schaadt

PHP is en blijft goed bruikbaar voor een heleboel projecten, maar dat doet absoluut niets af aan het feit dat het gewoon inconsequent en onlogisch is opgebouwd.

[.oisyn]

RayNbow schreef op maandag 30 maart 2009 @ 21:26:
[...]

offtopic:
Ik krijg bijna de neiging om de shameless plugs te gaan turven

Nou ben ik zeker iemand van de shameless plugs (), maar dit keer was het slechts om aan te tonen dat het niet maar gewoon fanboy rants zijn en dat een aantal mensen hier actief bezig zijn met compilerbouw

[mphilipp]

.oisyn schreef op maandag 30 maart 2009 @ 20:54:
[...]
Grappige mening, kun je 'm ook onderbouwen, of ben je gewoon persoonlijk aan het aanvallen omdat je op je pik bent getrapt?

Waarom zou ik op mijn pik getrapt zijn?

Elke taal heeft wel iets onhandigs, moet je 'm daarvoor gaan afkraken? Wat is die drang om dingen af te kraken? Who fucking cares of jij/whoever 'mijn' taal niet goed/handig of wat dan ook vindt? Misschien ben ik te volwassen om me daar druk om te maken. Ik kan er geen oog minder dicht om doen. Als een taal (of vul hier je favoriete OS/progsel/telefoon/auto/partner) voor jou werkt, aan jouw eisen voldoet, waarom moet je je dan druk maken over wat een ander daarvan vindt?

Enneh...ik programeer niet in PHP. Ooit een poging gedaan, maar ik wil helemaal niet meer programmeren. Oracle SQL en PL/SQL vond ik genoeg. Ook daar zijn zat meningen over. So what? Ik vind de hele disussie dus nergens over gaan. Wat zou de uitkomst moeten zijn dan? Dat TS overtuigd is en niet meer in PHP gaat programmeren? Begin eens om dát uit te leggen ipv puberale reacties op mijn post.

[ Voor 60% gewijzigd door mphilipp op 30-03-2009 22:29 ]

[Verwijderd]

mphilipp schreef op maandag 30 maart 2009 @ 22:25:

Begin eens om dát uit te leggen ipv puberale reacties op mijn post.

Het doel is om mensen te laten inzien dat er méér is onder de zon. Als mensen de zwaktes kennen, zullen ze de kracht beter weten te benutten. Een intelligent iemand die weet dat ijs dun is, zal eerder plat op het ijs gaan liggen en zijn oppervlakte groot maken dan op zijn tenen gaan staan.

Het is nu eenmaal makkelijker om te vertellen wat er fout gaat dan te vertellen wat er goed gaat.

Waarom voel jij je trouwens geroepen om iets te verdedigen dat je niet interesseert?

[MBV]

mphilipp schreef op maandag 30 maart 2009 @ 22:25:
[...]

Waarom zou ik op mijn pik getrapt zijn?

Elke taal heeft wel iets onhandigs, moet je 'm daarvoor gaan afkraken? Wat is die drang om dingen af te kraken? Who fucking cares of jij/whoever 'mijn' taal niet goed/handig of wat dan ook vindt? Misschien ben ik te volwassen om me daar druk om te maken. Ik kan er geen oog minder dicht om doen. Als een taal (of vul hier je favoriete OS/progsel/telefoon/auto/partner) voor jou werkt, aan jouw eisen voldoet, waarom moet je je dan druk maken over wat een ander daarvan vindt?

Genoteerd in de categorie "Ik wil me nergens mee bemoeien hoor, maareh..."

Enneh...ik programeer niet in PHP. Ooit een poging gedaan, maar ik wil helemaal niet meer programmeren. Oracle SQL en PL/SQL vond ik genoeg. Ook daar zijn zat meningen over. So what? Ik vind de hele disussie dus nergens over gaan. Wat zou de uitkomst moeten zijn dan? Dat TS overtuigd is en niet meer in PHP gaat programmeren? Begin eens om dát uit te leggen ipv puberale reacties op mijn post.

Het is begonnen met een opmerking dat er iets heel erg fout zat in PHP. Echt op een dom niveau wat niet meer normaal is, en bij het eerste college taalontwerp al naar voren komt. Vervolgens kwam er een welles-nietes discussie op gang in het verkeerde topic, wat is afgesplitst. Dit is dus vrij letterlijk een doelloos topic, voor het geval je dat nog niet was opgevallen na het lezen van de 'topicstart'.

Waarom PHP bashen ipv [insert andere taal]? En in elke taal zitten wat onhandige dingen. Java heeft geen multiple inheritance, SQL is geen geaccepteerde standaard voor, C++ is veel werk i.v.m. geen garbagecollector by default, enzovoort. Maar die hebben allemaal bestaansrecht volgens de meeste mensen hier. In PHP zitten daarentegen zoveel fouten, dat je er elke keer weer mee wordt geconfronteerd.

[.oisyn]

mphilipp schreef op maandag 30 maart 2009 @ 22:25:
Waarom zou ik op mijn pik getrapt zijn?

Ik kan geen andere reden verzinnen om zomaar even een topic binnen te vallen met een post waarin je het gros van de posters in de topic afzeikt.

Misschien ben ik te volwassen om me daar druk om te maken.

Het feit dat jij er niet in geïnteresseerd bent wil niet zeggen dat jij te volwassen bent of wij te kinderachtig. Het zegt slechts dat onze interesses verschillen. Dat is prima, maar kom hier dan niet lopen blaten dat we allemaal dom zijn als het je blijkbaar toch geen zak interesseert. Ga ik ook niet doen op een vrachtwarenforum in een discussie over waarom de Scania motor nou eigenlijk zo kut is. Waarom? Omdat het mij niet intereseert. Dat maakt de mensen die het wél wat interessert niet ineens dom. Wat je wat pas dom is? Denken dat dat wel zo is.

Als een taal (of vul hier je favoriete OS/progsel/telefoon/auto/partner) voor jou werkt, aan jouw eisen voldoet, waarom moet je je dan druk maken over wat een ander daarvan vindt?

Blijkbaar ben jij de enige die zich er druk om maakt.

Ik vind de hele disussie dus nergens over gaan.

Prima, dat mag je best vinden. Maar wat doe je dan in hemelsnaam hier? Ik heb ook geen posts in het Apple forum. Dat heeft een reden. Kun jij raden welke dat is?
Ik ben zo vrij geweest je post history na te gaan. Je hebt vrij weinig devschuur posts. Waarom kom je je dan nu zomaar ineens bemoeien met discussies die jij nergens over vindt gaan? Blijkbaar vinden andere mensen het wel ergens over gaan, anders was de discussie er niet.

Dat TS overtuigd is en niet meer in PHP gaat programmeren? Begin eens om dát uit te leggen ipv puberale reacties op mijn post.

Gast, je hebt echt de topic niet gelezen he . Er is geen TS. Deze topic is afgesplitst en voortgekomen uit een discussie in een ander topic. Dus als je nu weer lekker gaat reageren in topics die je wél aangaan, kunnen wij ook weer verder.
En dan noem je mijn reactie puberaal? Heb je je eigen ononderbouwde en bovendien ongegronde rant die puur en alleen is gebaseerd op de eerste post uit deze draad weleens gelezen? What comes around, goes around...

[ Voor 19% gewijzigd door .oisyn op 30-03-2009 23:50 ]

[prototype]

offtopic:
@oisyn: Je krijgt de complimenten nog van mijn relatie bij Apple voor wolf 3d js

[ Voor 3% gewijzigd door prototype op 30-03-2009 23:19 ]

[NMe]

Modbreak:

Iets minder op de man en iets meer ontopic graag.

[Zoijar]

Dit is trouwens ook wel een interessant lijstje: http://wiki.python.org/moin/PythonVsPhp

[Megamind]

Zoijar schreef op maandag 30 maart 2009 @ 23:32:
Dit is trouwens ook wel een interessant lijstje: http://wiki.python.org/moin/PythonVsPhp

Leuk lijstje, maar beetje van, wij van WC eend.....

Er mist nog wel een puntje:
What does PHP have that Python doesn't?
Hosting op vrijwel alle hosting providers.
Wat het dus direct een stuk makkelijker maakt om in PHP te rommelen.

[ Voor 10% gewijzigd door Megamind op 31-03-2009 07:57 ]

[Woy]

Megamind schreef op dinsdag 31 maart 2009 @ 07:50:
[...]
Er mist nog wel een puntje:
What does PHP have that Python doesn't?
Hosting op vrijwel alle hosting providers.
Wat het dus direct een stuk makkelijker maakt om in PHP te rommelen.

En dat zorgt voor het bestaansrecht van PHP. Ik denk dat het voor veel mensen dé reden is dat er voor PHP gekozen word. Dat is natuurlijk wel in combinatie met de laagdrempeligheid, want anders zou perl-script ook wel veel populairder zijn

[Creepy]

Megamind:

an expedient (commonly installed) environment

Ze melden zelf ook al dat het commonly installed is

Edit: Woy tussendoor maar die roept wat ik ook had willen roepen: dat het nagenoeg overal geinstalleerd is is echt een enorm voordeel. Hosting met een Java/Tomcat combo bijv. is een stuk moeilijker te vinden.

[ Voor 46% gewijzigd door Creepy op 31-03-2009 09:02 ]

[mithras]

Het houdt elkaar natuurlijk wel zelf in de hand:

php is een makkelijke taal om te leren > php wordt veel gebruikt > veel mensen willen php op hun hosting > hosters bieden bijna standaard php aan > nieuwe applicaties gaan php gebruiken om snel en op veel systemen geinstalleerd te kunnen worden > ga naar begin.

En dat is ook typisch voor een verschijnsel waarbij het gebruik de ontwikkeling heeft ingehaald: afaik werkt het developers team achter de community aan. Hierdoor worden overhaaste beslissingen genomen, dat is waar. Maar door dit model blijven de mensen php gebruiken en komen er alleen maar meer php-programmeurs bij

* mithras noemt zichzelf ook php-programmeur

[ Voor 3% gewijzigd door mithras op 31-03-2009 09:16 ]

[MBV]

Zijn er geen technische voordelen aan PHP (niet taal, maar integratie met apache etc) die maken dat het nu nog steeds makkelijker is om PHP hosting aan te bieden dan Java/Tomcat?

Zelfs windows-hosters bieden standaard PHP aan Of beter gezegd: je zoekt een PHP-hoster, komt bij een voordelige uit, en dat blijkt op windows te draaien.

[ Voor 18% gewijzigd door MBV op 31-03-2009 09:47 ]

[Janoz]

MBV schreef op dinsdag 31 maart 2009 @ 09:47:
Zijn er geen technische voordelen aan PHP (niet taal, maar integratie met apache etc) die maken dat het nu nog steeds makkelijker is om PHP hosting aan te bieden dan Java/Tomcat?

Jazeker. Dat was al zo en dat is nog steeds zo. Het voordeel van php is dat elk request een apart procesje is. Het managen van een dergelijke server is redelijk simpel. Een uit de hand gelopen script kan gewoon afgeschoten worden zonder dat de webapplicatie onderuit gaat. Dat gebeurt dan ook gewoon (te veel geheugen of te lange executietijd is einde request)

Een .Net of JEE omgeving is fundamenteel anders. Daar is een webapplicatie eigenlijk een altijd draaiend proces dat de requests en reponses afhandelt. Een uit de bocht vliegende applicatie is dan ook iets dat niet zomaar afgeschoten kan worden. Dat zal de hele webapp (of soms zelfs de hele applicatie server) onderuit halen. Zeker in het geval van shared hosting kan dat een redelijke onderhoudsnachtmerrie worden. Het beheer vergt gewoon meer insight in de applicatieserver en in de daarop draaiende applicaties.

Kortom, het opzetten en beheren van PHP hosting is oneindig veel simpeler dan het opzetten van een applicatie server.

[.oisyn]

mithras schreef op dinsdag 31 maart 2009 @ 09:15:
* mithras noemt zichzelf ook php-programmeur

Gecondoleerd

Janoz schreef op dinsdag 31 maart 2009 @ 10:12:
[...]

Jazeker. Dat was al zo en dat is nog steeds zo. Het voordeel van php is dat elk request een apart procesje is.

Dat is tegenwoordig al vaak niet meer zo. Dan is het gewoon een thread in het Apache proces. Natuurlijk blijft het wel zo dat het script nog steeds een afgebakend programma is - een enkele thread kun je ook gewoon afschieten.

[Phyxion]

mithras schreef op dinsdag 31 maart 2009 @ 09:15:
Het houdt elkaar natuurlijk wel zelf in de hand:

php is een makkelijke taal om te leren > php wordt veel gebruikt > veel mensen willen php op hun hosting > hosters bieden bijna standaard php aan > nieuwe applicaties gaan php gebruiken om snel en op veel systemen geinstalleerd te kunnen worden > ga naar begin.

En dat is ook typisch voor een verschijnsel waarbij het gebruik de ontwikkeling heeft ingehaald: afaik werkt het developers team achter de community aan. Hierdoor worden overhaaste beslissingen genomen, dat is waar. Maar door dit model blijven de mensen php gebruiken en komen er alleen maar meer php-programmeurs bij

* mithras noemt zichzelf ook php-programmeur

Het valt mij op dat iedereen die ook maar een print("Hello World"); kan zichzelf al een programmeur vind (Vooral enorm goed in PHP).

[Janoz]

.oisyn schreef op dinsdag 31 maart 2009 @ 10:43:
Dan is het gewoon een thread in het Apache proces.

Thread, proces... Lood om oud ijzer binnen deze context. Kernpunt is dat het volledig afgebakend is en alleen naar buiten communiceert via het filesystem of sockets. Er is nog wel het shared memory, maar dat is kort door de bocht gezegd niks anders dan een file in het geheugen.

[zwippie]

Phyxion schreef op dinsdag 31 maart 2009 @ 10:48:
[...]

Het valt mij op dat iedereen die ook maar een print("Hello World"); kan zichzelf al een programmeur vind (Vooral enorm goed in PHP).

Impliceer je nu dat mithras niet verder komt dan Hello World?

[mithras]

Nou, ik hoop het niet

Feit is ook gewoon dat de certificering voor php niet heel bijzonder is (zoals eerder al iher gezegd geloof ik). Het onderscheidt niet de mensen die het wel kunnen en de mensen die beunhazen zijn. Volgens mij is er voor andere talen wel een beter systeem (maar dat weet ik niet, ik ken ook geen andere talen ).

Hierdoor ontstaat er een wildgroei aan mensen die zeggen dat ze het kunnen, terwijl niemand heeft gedefinieerd wat "kunnen" en "niet kunnen" is

[ Voor 90% gewijzigd door mithras op 31-03-2009 10:58 ]

[Phyxion]

zwippie schreef op dinsdag 31 maart 2009 @ 10:55:
[...]

Impliceer je nu dat mithras niet verder komt dan Hello World?

Zeker niet, meer als vervolg op zijn verhaal.

[YopY]

Janoz schreef op dinsdag 31 maart 2009 @ 10:52:
[...]


Thread, proces... Lood om oud ijzer binnen deze context. Kernpunt is dat het volledig afgebakend is en alleen naar buiten communiceert via het filesystem of sockets. Er is nog wel het shared memory, maar dat is kort door de bocht gezegd niks anders dan een file in het geheugen.

Da's op zich ook zo met Java waarbij elke Java webapp binnen een eigen proces draait (binnen Tomcat e.d.), echter Java neemt van zichzelf al een tig MB extra geheugen in - en blijft die vasthouden tussen requests door. PHP daarentegen wordt alleen actief bij een enkel request, en geeft dan alle resources weer terug. Veel makkelijker te beheren e.d.

Daardoor is Java hosting van zichzelf gewoon duurder / zeldzamer. Ik denk echter wel dat er een markt in goedkope Java hosting zou zitten, mits ze dingen als CPU usage onder een quota kunnen zetten. Maar zelfs dan - Java apps zijn van zichzelf meestal zwaarder dan PHP scripts, o.a. omdat Java gewoon uitnodigt tot goed ontwerp dat een hoeveelheid extra overhead met zich meebrengt.

Ikzelf zou liever webapps in Java ontwikkelen, maar in de praktijk blijkt toch dat PHP vaak geschikter is voor korte en goedkope projecten.

Edit: Wat een geruzie / retorts / counter-retorts / counter-counter-retorts in http://wiki.python.org/moin/PythonVsPhp

[ Voor 4% gewijzigd door YopY op 31-03-2009 11:19 ]

[MBV]

mithras schreef op dinsdag 31 maart 2009 @ 09:15:
Het houdt elkaar natuurlijk wel zelf in de hand:

php is een makkelijke taal om te leren > php wordt veel gebruikt > veel mensen willen php op hun hosting > hosters bieden bijna standaard php aan > nieuwe applicaties gaan php gebruiken om snel en op veel systemen geinstalleerd te kunnen worden > ga naar begin.

Die had ik daarnet nog gemist: NOOIT goto's gebruiken, in dit geval een while-loop o.i.d. 't zit niet eens in PHP.

.oisyn schreef op dinsdag 31 maart 2009 @ 10:43:

Dat is tegenwoordig al vaak niet meer zo. Dan is het gewoon een thread in het Apache proces. Natuurlijk blijft het wel zo dat het script nog steeds een afgebakend programma is - een enkele thread kun je ook gewoon afschieten.

Doordat PHP stateless is, kan je Apache zonder problemen herstarten. Ja, de 5 requests die dan in behandeling zijn gaan dan wel mis, maar als je server over z'n nek gaat neem je dat wel voor lief

Java en .NET zijn niet stateless, geen idee hoe die daarmee omgaan. Maar pak-em-beet Python, Ruby en dat soort talen heeft dat probleem toch niet? Ach ja, ik host het zelf wel, net zo makkelijk

YopY schreef op dinsdag 31 maart 2009 @ 11:16:

Daardoor is Java hosting van zichzelf gewoon duurder / zeldzamer. Ik denk echter wel dat er een markt in goedkope Java hosting zou zitten, mits ze dingen als CPU usage onder een quota kunnen zetten. Maar zelfs dan - Java apps zijn van zichzelf meestal zwaarder dan PHP scripts, o.a. omdat Java gewoon uitnodigt tot goed ontwerp dat een hoeveelheid extra overhead met zich meebrengt.

Java hoeft niet zwaarder te zijn:
http://shootout.alioth.de...lang=java&lang2=php&box=1
Iets meer geheugen, veel meer snelheid.
Ik denk dat daar ook een pijnpunt zit: langzamere hosting is vaak acceptabel, maar out-of-memory-exceptions niet.

Edit: Wat een geruzie / retorts / counter-retorts / counter-counter-retorts in http://wiki.python.org/moin/PythonVsPhp

Ik vind het juist wel grappig: geen wij-van-wc-eend verhaal, omdat er ook PHP-fanboys terechte verdedigingen geven.

[ Voor 28% gewijzigd door MBV op 31-03-2009 11:25 ]

[daaan]

Phyxion schreef op dinsdag 31 maart 2009 @ 10:48:
[...]

Het valt mij op dat iedereen die ook maar een print("Hello World"); kan zichzelf al een programmeur vind (Vooral enorm goed in PHP).

Dat heeft imho meer te maken met de persoon zelf, niet met de taal. Dit zie je met alles gebeuren. Iedereen die een CD kan afspelen is bijvoorbeeld ook meteen een DJ.
Het probleem dat PHP heeft is dat deze mensen mogelijkheden te over hebben om hun zelf gebakken code aan de wereld te presenteren. Dát hebben de andere talen niet. Maar dat is een hele andere discussie.

Ik ben het eens met de stelling dat PHP vele design flaws heeft, en dat er nogal onprofessioneel met de taal word omgegaan.
In het segment waar ik in werk (privé, mkb en gemeente's) is PHP echter prima. It gets the job done, snel en relatief goedkoop. Ik denk ook niet dat PHP ooit écht uit dit segment komt.

Wil je iets professioneler, dan zul je niet verder gaan met PHP, dit geld voor zowel als opdrachtgevers als programmeurs.

[Janoz]

YopY schreef op dinsdag 31 maart 2009 @ 11:16:
[...]


Da's op zich ook zo met Java waarbij elke Java webapp binnen een eigen proces draait (binnen Tomcat e.d.),

Dat is ook wat ik aangeef, alleen is het grote verschil dat de hele java web applicatie een 'eigen proces' heeft terwijl bij php elk los requestje in een apart afgebakend stukje zit.

echter Java neemt van zichzelf al een tig MB extra geheugen in - en blijft die vasthouden tussen requests door.

Het vasthouden is logisch wanneer je bedenkt dat een java applicatie niet 'stopt' wanneer een request afgelopen is. Daarnaast worden veel resources maar 1x geladen en voor alle requests gebruikt.

PHP daarentegen wordt alleen actief bij een enkel request, en geeft dan alle resources weer terug. Veel makkelijker te beheren e.d.

Dat is inderdaad precies wat ik eerder al aangeef.

Daardoor is Java hosting van zichzelf gewoon duurder / zeldzamer. Ik denk echter wel dat er een markt in goedkope Java hosting zou zitten, mits ze dingen als CPU usage onder een quota kunnen zetten. Maar zelfs dan - Java apps zijn van zichzelf meestal zwaarder dan PHP scripts, o.a. omdat Java gewoon uitnodigt tot goed ontwerp dat een hoeveelheid extra overhead met zich meebrengt.

Conclusie blijft inderdaad hetzelfde . Ik denk echter niet dat een goed ontwerp voor meer overhead zorgt. Het is eerder zo dat een slecht ontwerp, of fouten in je ontwerp, een veel grotere impact hebben op de gehele server. Een stackoverflow in php gooit 1 request weg. Een stackoverflow in een java applicatie zou je hele applicatie of zelfs de hele server plat kunnen gooien.

[netvor]

YopY schreef op dinsdag 31 maart 2009 @ 11:16:
Edit: Wat een geruzie / retorts / counter-retorts / counter-counter-retorts in http://wiki.python.org/moin/PythonVsPhp

Inderdaad. Wat ik persoonlijk uit de discussie meeneem:

1. PHP is meer een webtaal, Python is meer general-purpose.
2. Qua features zijn ze vrijwel identiek, echter elk mist her en der wel een feature die toevallig wel in Ada oid zit.
3. Datastructuren in Python zijn opgezet volgens schoolboeken theoretische informatica. In PHP zijn ze opgezet op een pragmatische manier.
4. Men vindt dat de structuur van Python's functies beter in elkaar steekt. Ben ik het mee eens, maar het blijft iets subjectiefs.
5. De overige 90% van de discussie is "wij schrijven precies hetzelfde in een andere syntax."

Met name punt 3 is een nieuwe insteek in deze discussie. En het blijft niet zozeer beperkt tot datastructuren: een groot contrast tussen Python en PHP is dat de eerste veel academischer is dan de laatste. Heel veel constructies in Python, en ook voorbeelden op de site, lijken rechtstreeks te zijn overgenomen uit een willekeurig boek uit de jaren '70 van Dijkstra/Lamport/etc. In PHP, zo krijg ik het gevoel, zijn dingen gedaan volgens het "wat werkt voor de users" dogma.

Wat vinden jullie?

[user109731]

MBV schreef op dinsdag 31 maart 2009 @ 11:20:
[...]
Ik vind het juist wel grappig: geen wij-van-wc-eend verhaal, omdat er ook PHP-fanboys terechte verdedigingen geven.

Ik ben vast biased als Python-aanhanger, maar veel van die verdedigingen zijn nogal flauw imho, zoals:

# classes are used extensively in the standard library
* Retort: PHP 5 has SPL which is fully class-based

Alsof SPL met z'n paar classes voor datastructuren en iterators te vergelijken is met Python, waar bijna alles netjes uit modules en classes opgebouwd is

netvor schreef op dinsdag 31 maart 2009 @ 11:45:
Met name punt 3 is een nieuwe insteek in deze discussie. En het blijft niet zozeer beperkt tot datastructuren: een groot contrast tussen Python en PHP is dat de eerste veel academischer is dan de laatste. Heel veel constructies in Python, en ook voorbeelden op de site, lijken rechtstreeks te zijn overgenomen uit een willekeurig boek uit de jaren '70 van Dijkstra/Lamport/etc. In PHP, zo krijg ik het gevoel, zijn dingen gedaan volgens het "wat werkt voor de users" dogma.

Wat vinden jullie?

Je lijkt hiermee te zeggen dat PHP sneller 'wegschrijft'? Daar ben ik het niet mee eens, juist de inconsistentie in functie-namen en functie-argumenten in PHP zijn niet pragmatisch. Ik heb in beide talen veel ervaring en heb niet het idee dat Python me veel meer tijd kost of "over-engineered" is ofzo

[netvor]

Je zou kunnen denken aan het argument dat op de bovengenoemde site gemaakt wordt: dat PHP slechts één datastructuur heeft, de array, terwijl je bij Python een verschil ziet tussen tuples, lists en dictionaries. In Python word je als programmeur toch iets meer gedwongen om vooraf na te denken wat je wilt opslaan en wat je ermee wilt doen, alvorens de juiste container te kiezen.

[NMe]

netvor schreef op dinsdag 31 maart 2009 @ 12:34:
Je zou kunnen denken aan het argument dat op de bovengenoemde site gemaakt wordt: dat PHP slechts één datastructuur heeft, de array, terwijl je bij Python een verschil ziet tussen tuples, lists en dictionaries. In Python word je als programmeur toch iets meer gedwongen om vooraf na te denken wat je wilt opslaan en wat je ermee wilt doen, alvorens de juiste container te kiezen.

PHP maakt dezelfde functionaliteit beschikbaar met maar één datatype. Dat is voor het overgrote deel van de mensen die PHP gebruiken juist fijn.

[Janoz]

netvor schreef op dinsdag 31 maart 2009 @ 12:34:
Je zou kunnen denken aan het argument dat op de bovengenoemde site gemaakt wordt: dat PHP slechts één datastructuur heeft, de array de map die ze array genoemd hebben.

[netvor]

NMe schreef op dinsdag 31 maart 2009 @ 12:44:
PHP maakt dezelfde functionaliteit beschikbaar met maar één datatype. Dat is voor het overgrote deel van de mensen die PHP gebruiken juist fijn.

Precies, PHP is gewoon veel pragmatischer opgebouwd. Of dat nou goed is of niet, daar geef ik nu geen oordeel over.

[SPee]

Doordat PHP stateless is, kan je Apache zonder problemen herstarten. Ja, de 5 requests die dan in behandeling zijn gaan dan wel mis, maar als je server over z'n nek gaat neem je dat wel voor lief

Java en .NET zijn niet stateless, geen idee hoe die daarmee omgaan. Maar pak-em-beet Python, Ruby en dat soort talen heeft dat probleem toch niet? Ach ja, ik host het zelf wel, net zo makkelijk

Dat lig eraan hoe je je applicatie geprogrammeerd hebt. Je kunt je applicatie gewoon stateless draaien, echter moet je dan alles aan je client zijde bijhouden. Dat wordt echter niet aangeraden, waardoor je veelal van server sessies gebruikt maken.
Van Java (tomcat) weet ik dat alle sessies geserialiseerd (opgeslagen) worden en bij de herstart weer ingelezen worden. Echter, het vereist wel dat alle objecten op die sessie weggeschreven en weer gelezen kunnen worden. Je moet dat alleen voor die objecten wel willen
Voor .NET zal het ook wel zo zijn.

Een voordeel van Java (en .NET) t.o.v. PHP is dat ze objecten in hun geheugen kunnen bewaren tussen de requests door. Hierdoor hoeven ze niet de data opnieuw op te halen en kan het systeem sneller reageren. Waarschijnlijk ook een reden dat Tweakers een Java applicatie voor caching gebruikt. Bij PHP ben je de data na het request weer kwijt (voor zover ik weet) waardoor het opnieuw opvragen van data intensiever voor het systeem is.

[MBV]

Janoz schreef op dinsdag 31 maart 2009 @ 12:55:
[...]

Fout, $array[0] is geen map-entry. In feite is een array een samenstelling van 2 dingen: 'gewone' array/vector/list, $array[$integer], en map, $array[$al-het-andere]. Ook al heet de variabele het zelfde, alleen die iterators werken hetzelfde

netvor schreef op dinsdag 31 maart 2009 @ 11:45:
[...]


Inderdaad. Wat ik persoonlijk uit de discussie meeneem:
[list=1]
• PHP is meer een webtaal, Python is meer general-purpose.

Zo is het wel ontworpen, maar je kan het prima voor shell-scripts (alles is beter leesbaar dan bash _{let the bashing begin} ) en door de uitbreidingen zelfs voor GUI's gebruiken. Lijkt me dus niet zo'n punt.

Met name punt 3 is een nieuwe insteek in deze discussie. En het blijft niet zozeer beperkt tot datastructuren: een groot contrast tussen Python en PHP is dat de eerste veel academischer is dan de laatste. Heel veel constructies in Python, en ook voorbeelden op de site, lijken rechtstreeks te zijn overgenomen uit een willekeurig boek uit de jaren '70 van Dijkstra/Lamport/etc. In PHP, zo krijg ik het gevoel, zijn dingen gedaan volgens het "wat werkt voor de users" dogma.

Wat vinden jullie?

Ik heb ooit tegen een professor theoretische informatica gezegd dat sommige dynamische talen lambda-functies ondersteunen. Een tip: doe dat nooit

[Patriot]

MBV schreef op dinsdag 31 maart 2009 @ 14:11:
[...]

Zo is het wel ontworpen, maar je kan het prima voor shell-scripts (alles is beter leesbaar dan bash _{let the bashing begin} ) en door de uitbreidingen zelfs voor GUI's gebruiken. Lijkt me dus niet zo'n punt.

Ik denk dat of het wel of niet gedaan wordt hier even belangrijker is dan of het mogelijk is. PHP is hoofdzakelijk een webtaal in de zin dat men het verder nauwelijks ergens anders voor gebruikt.

[Mental]

Phyxion schreef op dinsdag 31 maart 2009 @ 10:48:
[...]

Het valt mij op dat iedereen die ook maar een print("Hello World"); kan zichzelf al een programmeur vind (Vooral enorm goed in PHP).

En dat is dan weer een ontzettend nadeel voor de mensen die hier hun geld mee proberen te verdienen.
Hoe erg de taal ook rammelt, er is markt voor dus zijn er ook mensen die er graag mee werken.
Nu moet je alleen zowat een portfolio van 3 jaar laten zien voordat je eens een knappe klus krijgt.
Dus als alle hobby bob's eens stoppen met de reputatie van php te verneuken door professioneel ogende software met een backend van likmevestje uit te brengen, dan zou het er lang niet zo erg aan toe zijn.

[.oisyn]

MBV schreef op dinsdag 31 maart 2009 @ 14:11:
[...]

Fout, $array\[0] is geen map-entry.

Waarom niet? Het is niet alsof je array indices consecutive moeten zijn. Dat het integer keys heeft wil nog niet zeggen dat het een array is. Het is en blijft gewoon een (geordende) hash-map. Ook voor integer keys.

netvor schreef op dinsdag 31 maart 2009 @ 13:10:

Precies, PHP is gewoon veel pragmatischer opgebouwd. Of dat nou goed is of niet, daar geef ik nu geen oordeel over.

Of dat zo pragmatisch is is maar de vraag. Arrays zijn hashmaps, maar worden vaak gewoon behandeld als arrays (niet zo gek, gezien het feit dat je geen echte arrays hebt). Dit is nogal een gekunstel in de standaard functies die werken op arrays. Neem bijvoorbeeld array_merge():

Merges the elements of one or more arrays together so that the values of one are appended to the end of the previous one. It returns the resulting array.

If the input arrays have the same string keys, then the later value for that key will overwrite the previous one. If, however, the arrays contain numeric keys, the later value will not overwrite the original value, but will be appended.

De redenatie snap ik wel. Voor arrays wil je geen waarden overschrijven maar gewoon 2 arrays concantenaten. Voor hashmaps wil je ze combineren zodat duplicates verdwijnen. Echter, als ik m'n "array" gewoon wil benaderen als hash-map waar toevallig integer keys in staan ben ik de sjaak, omdat deze functie m'n hashmap dan ziet als array. En dit is slechts een voorbeeld, de hele array lib zit vol met dit soort dingen. Het was wellicht pragmatisch tijdens de implementatie van de taalfeature, maar zeker niet meer toen de library erbij gemaakt werd.

Overigens heeft ook javascript hier last van.

JavaScript:

var a = [];
a[100] = 34;
alert(a.length);

Jawel, 101. Terwijl er toch echt maar 1 element in staat. Wat javascript hier vooral mist is een goede manier om over alle elementen heen te lopen. for (var i = 0; i < a.length; i++) wordt meestal aangeraden, wat goed werkt voor echte arrays maar niet voor bovenstaand voorbeeld. De for (var i in a) enumereert over alle properties, dus ook custom functies die je toevallig aan Array.prototype hebt toegevoegd. Wel logisch, die functies zijn dan immers ook gewoon onderdeel van a. Maar niet altijd even handig.

[ Voor 84% gewijzigd door .oisyn op 31-03-2009 15:02 ]

[prototype]

Volgens mij is array ook gewoon een hashmap hoor zoals .oisyn stelt: voor HashMap's geldt in het algemeen gewoon dat de key eigenlijk van alles kan zijn, zolang er maar een Hash waarde over berekend kan worden om intern te hanteren als key voor de bucket.De hashfunctie voor de key hier accepteert in dat geval dan ook gewoon integers, i.e. kent een transformatie voor Int -> HashValue.

En dan gewoon het laatste woord:

An array in PHP is actually an ordered map. A map is a type that associates values to keys. This type is optimized for several different uses; it can be treated as an array, list (vector), hash table (an implementation of a map), dictionary, collection, stack, queue, and probably more. As array values can be other arrays, trees and multidimensional arrays are also possible.

http://php.net/manual/en/language.types.array.php

[ Voor 59% gewijzigd door prototype op 31-03-2009 15:28 ]

[MBV]

.oisyn schreef op dinsdag 31 maart 2009 @ 14:27:
[...]

Waarom niet? Het is niet alsof je array indices consecutive moeten zijn. Dat het integer keys heeft wil nog niet zeggen dat het een array is. Het is en blijft gewoon een (geordende) hash-map. Ook voor integer keys.

Ik heb het even opgezocht in de documentatie, in mijn herinnering werkt PHP anders met integers dan met andere objecten. En verrek, je mag er alleen maar integers of strings in gooien:

quote: http://nl3.php.net/manual/en/language.types.array.php

array( key => value
, ...
)
// key may only be an integer or string
// value may be any value of any type
[...]
A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08"). Floats in key are truncated to integer. The indexed and associative array types are the same type in PHP, which can both contain integer and string indices.
[...]
Arrays and objects can not be used as keys. Doing so will result in a warning: Illegal offset type.

Nu moet ik zeggen dat dat de laatste keer dat ik het probeerde geen enkel probleem was. In PHP4 geen warning gezien.

Oh en WTF nummer zoveel in PHP: "$foo[bar]" is hetzelfde als $foo["bar"]. Logisch toch?
"Hey, it compiles! Ship it!"

De redenatie snap ik wel. Voor arrays wil je geen waarden overschrijven maar gewoon 2 arrays concantenaten. Voor hashmaps wil je ze combineren zodat duplicates verdwijnen. Echter, als ik m'n "array" gewoon wil benaderen als hash-map waar toevallig integer keys in staan ben ik de sjaak, omdat deze functie m'n hashmap dan ziet als array. En dit is slechts een voorbeeld, de hele array lib zit vol met dit soort dingen. Het was wellicht pragmatisch tijdens de implementatie van de taalfeature, maar zeker niet meer toen de library erbij gemaakt werd.

En dat was precies waar ik op doelde toen ik zei dat arrays met integers en hashmaps met strings toevallig overlappende namen hebben, maar verder weinig met elkaar van doen hebben.

[.oisyn]

En dat was precies waar ik op doelde toen ik zei dat arrays met integers en hashmaps met strings toevallig overlappende namen hebben, maar verder weinig met elkaar van doen hebben.

Dat maakt nog niet dat een PHP array ook daadwerkelijk een array is - het is gewoon een hash map . Dat je er verder geen floats in mag stoppen is trouwens ook irrelevant, de situatie had niet anders geweest als dat ineens wel had gemogen.

[ Voor 19% gewijzigd door .oisyn op 31-03-2009 16:13 ]

[prototype]

MBV schreef op dinsdag 31 maart 2009 @ 16:08:
[...]

Ik heb het even opgezocht in de documentatie, in mijn herinnering werkt PHP anders met integers dan met andere objecten. En verrek, je mag er alleen maar integers of strings in gooien:


Nu moet ik zeggen dat dat de laatste keer dat ik het probeerde geen enkel probleem was. In PHP4 geen warning gezien.

Misschien dat hij de __toString() method heeft gebruikt op het object voor de hashkey?
edit
Lijkt niet meer te werken onder PHP 5 though:

PHP:

<?php
class Foo {
    public function __toString() {
        return "foo";
    }
}


$foo = new Foo();
$ary = array();
$ary[$foo] = "hoi";

echo $ary["foo"];

?>

code:

$ php test.php

Warning: Illegal offset type in /Users/ninh/test.php on line 11

Nouja, het werkt opzich wel als je expliciet hier $foo cast naar (string) in regel 11, maar ik neem aan dat je dat niet gedaan had?

[ Voor 32% gewijzigd door prototype op 31-03-2009 16:25 ]

[MBV]

Hmm, de code was nog nét niet zo fucked up dat je de warnings uit moest zetten. Notices ($array[leuke_string], $_GET vragen die niet !isset is, datzelfde geintje met andere arrays) was 3 pagina's scrollen per pagina Leuk, legacy... [/ot]

Wat gebeurt er trouwens als je op regel 13 dit neerzet:

PHP:

print_r($ary);

[XWB]

Lijkt niet meer te werken onder PHP 5 though:

__toString() wordt enkel aangeroepen wanneer je het object afprint ( met echo, print e.d. );

/edit

Zo te zien staat dit ook in de php docs vermeld:

quote: http://be.php.net/manual/...guage.oop5.magic.tostring

It is worth noting that before PHP 5.2.0 the __toString method was only called when it was directly combined with echo() or print(). Since PHP 5.2.0, it is called in any string context (e.g. in printf() with %s modifier) but not in other types contexts (e.g. with %d modifier). Since PHP 5.2.0, converting objects without __toString method to string would cause E_RECOVERABLE_ERROR.

[ Voor 63% gewijzigd door XWB op 31-03-2009 16:32 ]

[prototype]

Hacku schreef op dinsdag 31 maart 2009 @ 16:31:
[...]


__toString() wordt enkel aangeroepen wanneer je het object afprint ( met echo, print e.d. );

/edit

Zo te zien staat dit ook in de php docs vermeld:


[...]

Dan liegt de documentatie, want __toString wordt in algemene zin gewoon aangeroepen als hij gecast wordt naar String ;-)

Zie ook:

PHP:

<?php
class Foo {
    public function __toString() {
        return "foo";
    }
}


$foo = new Foo();
$ary = array();
$ary[(string)$foo] = "hoi";

echo $ary["foo"];

?>

code:

$ php test.php
hoi

__toString wordt dus __NIET ZOZEER__ angeroepen als je iets print, maar gewoon als je het naar een string cast. En dat is nodig voor echo en printf %s.

edit
@MBV:
Indien ik het expliciet cast naar string gewoon as expected:

code:

 php test.php
Array
(
    [foo] => hoi
)

Indien ik dat niet doe en dus de warning krijg krijg ik gewoon een lege array:

code:

 php test.php

Warning: Illegal offset type in /Users/ninh/test.php on line 13
Array
(
)

[ Voor 17% gewijzigd door prototype op 31-03-2009 16:41 ]

[XWB]

prototype schreef op dinsdag 31 maart 2009 @ 16:37:
[...]


Dan liegt de documentatie, want __toString wordt in algemene zin gewoon aangeroepen als hij gecast wordt naar String ;-)

Nouja, het klopt als je PHP 5.2 of hoger draait: Since PHP 5.2.0, it is called in any string context. Dus dit geldt ook voor een cast naar string.

[vorlox]

Soms heb ik rare uitgangspunten....dus don't shoot me,
echter ik heb altijd geleerd dat software, proces ondersteunend moet zijn. en van wat ik in de praktijk meemaak lijk dat idd. ook nog eens zo te zijn.

Voorbeeld. een bat bestand kopieert bestanden van machine 1 naar server 1....dat werkte jaren goed...todat er een echte programeur kwam werken die schreef een overkoepelende applicatie in C die van machine 1 en machine 2 en machine 3 en machine 4 alles kopieerde naar server 1....
erg vet denk ik echter het proces was echt niet veranderd en de uitkomst ook niet..

Nu zouden misschien mensen kunnen zeggen ja, maar eerst moest je op elke machine een bat bestandje kopieren en nu heb je 1 server die alles regelt...dus zou je het beheer-proces ondersteunen..
Echter in de praktijk was het zo dat als er 1 machine down was ook het bat bestandje van die machine dus niet werkte, maar omdat de machine niet werkte boeide dat dus niet.
Nu werd die kopieer server opeens kritiek voor alle machines dus moest hij redundant worden uitgevoerd backups van gemaakt worden, restore procedures enz enz....en dat is dan weer extra beheer.

Zoiets zie ik met PHP ook...zolang het een proces kan ondersteunen...en flexibel is dan kan de taal me geen drol schelen of het nou in ABAP, PHP, JSP, Java, Ruby, Delphi, fortran...whatever geschreven is...

Wat ik een beetje bedoel te zeggen is dat er sommige programmeurs zijn die denken dat de programeer taal enige echte betekenis heeft...en ik denk dat dat minder waar is.

[MBV]

Grotendeels mee eens, op de vele ... na dan Voor even snel een website in elkaar flansen zal ik ook naar PHP grijpen, omdat ik daar ervaring mee heb. Dat neemt niet weg dat er veel irritante gebreken in de taal zitten.

[Gomez12]

@Vorlox : Wat jij zegt klopt mits je alles goed gedocumenteerd hebt, met 100% documentatie maakt inderdaad de methode niets meer uit, het is ten allen tijde inzichtelijk voor iedereen ( totdat je het te groot maakt en daardoor de documentatie waardeloos maar dat is een andere discussie ) alleen heb ik eigenlijk in de praktijk nog nooit iets 100% goed gedocumenteerd gezien zeg maar 1 jaar na installatie

PHP kan perfect 1 proces ondersteunen, maar wil je verschillende 20 processen ondersteunen dan heb je of een beheermodule nodig die een groot gedeelte van de lacunes in je documentatie kan opvangen of je hebt perfecte documentatie nodig om geen chaos / houtje touwtje werk te krijgen.

Als iemand mij out of the blue een stuk php laat zien met stristr en in_array erin gebruikt, dan is het voor mij absoluut niet duidelijk dat needle en haystack soms omgedraaid zijn als dit niet gedocumenteerd is, code hoort redelijk selfdocumenting te zijn imho en dat is php niet vanwege de uitzonderingen.

Als eenzame programmeur op je eigen eiland met je eigen code / als bureautje wat alleen maar php doet is dit niet erg, dan ken je de uitzonderingen.
Maar als algemene stelregel voor programmeren zijn dit soort rare ( standaard niet gedocumenteerde want het is standaard functionaliteit binnen php ) uitzonderingen gewoon waardeloos. Het is gewoon niet logisch.

[vorlox]

Ik hoopte niet dat ik ergens zei dat PHP dus consequent / goed uitgedacht was.

Vooral je punt over documentatie is volledig terecht, echter begint documenteren naar mijn idee ook niet bij de software maar bij het proces, en in je proces model zul je dus ergens kwijt moeten dat je voor bepaalde onderdelen een stuk software inzet.

Vanuit eigen ervaring kan ik vertellen dat ik meermaals meegemaakt heb dat zelfs het proces niet in kaart was gebracht, dan heb je niks aan software documentatie, want je weet niet waarvoor je het gebruikt.

Ook zou je de documentatie van de software bijna evenredig naast de functionele specs moeten kunnen leggen...want daarvanuit bouw je de software. Wat ik bedoel is dat documentatie heel belangrijk is maar dat het wel van boven naar beneden moet lopen en niet andersom.

Maar goed het heeft verder niks meer met PHP te maken.
Ik miste gewoon ergens in de discussie nog dat ondersteunende verhaal...vandaar mijn post.

offtopic:
C# for president

[ Voor 6% gewijzigd door vorlox op 31-03-2009 22:58 ]

[Stijn]

Die had ik daarnet nog gemist: NOOIT goto's gebruiken, in dit geval een while-loop o.i.d. 't zit niet eens in PHP.

Jawel!