Vanwaar het PHP bashen

[harrald]

Je moet met php leren werken net zo als dat je met andere talen moet leren werken.
Ikzelf vind php best fijn om mee te proggen.

Het is jammer dat de taal zo'n slecht imago heeft.
Javascript had dit ook en dat begint nu pas een beetje af te zakken met de komst van de 'ajax' libraries.

[.oisyn]

Heeft javascript een slecht imago dan?
For what it's worth, ik vind javascript een mooie en goed uitgedachte taal. Dat PHP een slecht imago heeft vind ik terecht, maar dat imago heeft ie dan wel weer om de verkeerde redenen denk ik (namelijk het vele aantal prutsers, maar dat is niet de "schuld" van PHP zelf)

[ Voor 46% gewijzigd door .oisyn op 27-03-2009 18:07 ]

[roy-t]

.oisyn schreef op vrijdag 27 maart 2009 @ 18:06:
Heeft javascript een slecht imago dan?
For what it's worth, ik vind javascript een mooie en goed uitgedachte taal. Dat PHP een slecht imago heeft vind ik terecht, maar dat imago heeft ie dan wel weer om de verkeerde redenen denk ik (namelijk het vele aantal prutsers, maar dat is niet de "schuld" van PHP zelf)

Klopt, net als dat Visual Basic (.Net) een slechte naam had doordat er veel mensen waren waarvoor dat hun eerste taal was. (Vooral met VB.net is er weinig meer op aan te merken, en VB heeft een paar leuke functies waar ik als C# programmeur jalours op ben, en tbh vond ik all die "{ }" overal en ";" aan het eerst maar shit!) ( Wikipedia: Comparison of C Sharp and Visual Basic .NET maar niet compleet / veel is sinds C#2008 ook in C# aanwezig).

Verder heb ik om zelf wat feeling voor webtalen te krijgen geprobeerd om een mini-cmsje te maken in zowel C#/asp.net3.5 en php5. (Heel simpel, meeste hardcoded maar gewoon login/register, beetje rechten en articles/publish/comments)

In beide talen is dit goed te doen, maar toch had ik veel meer problemen met PHP, waar ASP allemaal hele nette controls heeft die het doen zowel als er wel of geen js actief is, en ook altijd een serverside check doen op verificatie van input, moest je dit in php allemaal zelf doen (goed maar dat maakt php natuurlijk nog niet brak).

Ik had echter veel problemen om sessie netjes op te zetten, daar heeft ASP veel meer support door door verschillende lagen sessies. (Viewstate, Cookies, Session, Membership) en ook voor performance optimalisatie helpt ASP je erg goed (denk aan de verschillende caching mechanisme).

In php kan je dit waarschijnlijk allemaal ook wel zelf maken, maar toch ben je zo met ASP sneller aan de gang, en heb je robuste geteste code ipv je eigen progsels (security issues zijn niet altijd direct zichtbaar als je het zelf maakt).

Ok maar nogsteeds is er dan niets mis met PHP zelf. Echter vind ik PHP ook erg onlogisch, (sowieso vind ik het hele weak typed gebeuren een beetje lastig, maargoed dat kan ik nog zien als een feature).

Waar ik wel van baalde was het al aangehaalde gedrag van de == operator icm met strings. Ook leek het telkens zodra je probeerde OO te programmeren of PHP je express dwars probeert te zitten. Je kunt niet-static methoden aanroepen uit je nette classen zonder je class te initialiseren. WTF!? Encapsulatie lijkt iets waarvan de ontwikkelaars nog nooit van gehoord hebben. Het doet me zelfs vermoeden dat itern alles eigenlijk nog harstikke imperatief is opgezet en dat OO in php eigenlijk maar een beetje syntactic sugar is.

Ook zijn er vage backwardcompatiblity besluiten gemaakt, kijk maar naar de constructors, waar dit eerst Classname() was is dit nu __construct(), maar waarom? Bij talen als Java, C++, C# e.d. ging het altijd goed met Classname() ook na update, ook qua backwardscompatibility, wat zat er fout waardoor php nu __construct() nodig heeft?

Ook kwam ik op de volgende vaagheid (niet zeker of dat nu nog zo is).

quote: http://discuss.fogcreek.c...&ixPost=17599&ixReplies=8

fter working with PHP for a while, I noticed a serious design flaw in the language: when you perform an object assignment, the object is copied as a whole, while you would expect only a reference to the object to be copied.

$myObj = new MyObject();
$myObj.prop = 1;
$yourObj = $myObj;
$yourObj.prop = 2;

There are now two objects instead of one, with two different property values. To avoid this, you apparently have to use =& instead of =. This leads to really hard-to-find bugs because it's so easy to forget the & everywhere.

On a related note, PHP's parser displays hints of a one-dimensional implementation that is so common among mediocre programmers. For example, it will accept:

$child =& $myObj->getChild();
$child->doSomething();

but not:

$myObj->getChild()->doSomething();

Aaarg!

[Michali]

roy-t schreef op vrijdag 27 maart 2009 @ 18:47:
Ook zijn er vage backwardcompatiblity besluiten gemaakt, kijk maar naar de constructors, waar dit eerst Classname() was is dit nu __construct(), maar waarom? Bij talen als Java, C++, C# e.d. ging het altijd goed met Classname() ook na update, ook qua backwardscompatibility, wat zat er fout waardoor php nu __construct() nodig heeft?

Dit is gedaan omdat dit de conventie van PHP is. Er zijn verschillende 'magic' methods, die je (in principe) niet direct mag aanroepen. Die beginnen met 2 underscores. De constructor is aangepast zodat hij ook binnen deze conventie valt.

Ook kwam ik op de volgende vaagheid (niet zeker of dat nu nog zo is).
Aaarg!

Tja, dit is natuurlijk het probleem van OO in PHP4. Sinds PHP5 is dit niet meer het geval.

[sky-]

Onderstaande werkt gewoon hoor.

[Cartman!]

.oisyn schreef op vrijdag 27 maart 2009 @ 18:06:
Dat PHP een slecht imago heeft vind ik terecht, maar dat imago heeft ie dan wel weer om de verkeerde redenen denk ik (namelijk het vele aantal prutsers, maar dat is niet de "schuld" van PHP zelf)

Dat was dan ook een beetje het punt wat ik wilde maken in den beginne

[NMe]

Cartman! schreef op vrijdag 27 maart 2009 @ 19:20:
[...]

Dat was dan ook een beetje het punt wat ik wilde maken in den beginne

Mja, ik ben het er ook niet echt mee eens hoe dat gebeurt. Vandaag kreeg ik nog een reactie op mijn blog waaruit het bleek dat de schrijver lijkt te denken dat slecht coden alleen voorbehouden is aan PHP-programmeurs omdat ik toevallig een voorbeeld in PHP postte.

PHP is op bepaalde punten crap, en de meesten van ons kennen al die punten. Als je ze kent, dan kun je toch gewoon met de taal werken? Je weet dan toch waar de valkuilen zitten? PHP kan nog steeds the best tool for the job zijn, afhankelijk van wat die job is.

[krvabo]

Naast de eerder genoemde grote defecten aan PHP zijn er ook nog wat kleinere ergernissen.
Ikzelf dev toch ook al zo'n bijna 6 jaar in php, en pas ~3.5 in java/c#.
Nadat ik ongeveer een jaar niets aan php had gedaan had ik weer een project waar ik aan wilde beginnen.
De keuze bestond uit php en jsp. JSP was een goede kanshebber, maar er zijn zo bar weinig goedkope hosts (met veel dataverkeer) die het aanbieden dat ik maar koos voor php.

Nadat ik na die rustperiode weer was gestart viel ik meteen over het volgende (al genoemd):

PHP:

$tmp = getObjByName('bla')[0]; //kan dus niet

Daarna ook meerdere keren het irritante gewissel tussen:

PHP:

in_array($needle, $haystack);
strstr($haystack, $needle);

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

[Zoijar]

Ik ben het er niet mee eens dat PHP alleen een slecht imago heeft omdat er veel "prutsers" de taal gebruiken; ik vind de taal zelfs ook echt gewoon slecht: vaak onlogisch en niet orthogonaal. En dat komt dan nog niet eens door de implementatie van de taal, maar ook door de ontwerp beslissingen. De weak typing in PHP en alle bijkomstige problemen vind ik bagger. Dat is nergens voor nodig imho. Je kan alsnog een volledige typed AST bijhouden en de gebruiker de vrijheid geven om tussen types te converteren, desnoods impliciet.

(ASP.NET is strict gezien geen taal maar een library. Eigenlijk kan je PHP alleen met C# of VB vergelijken in dat opzicht.)

[Megamind]

krvabo schreef op vrijdag 27 maart 2009 @ 21:39:

PHP:

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

Typisch geval van functies erin blijven stoppen en al vanaf het begin geen goede richtlijnen opzetten.

Zo zijn er wel meer functies die rare naamgevingen hebben...

[user109731]

JS heeft een slecht imago bij 'programmeurs' die hippe mouse-over scriptjes copy-pasten van de daarvoor bestemde Web 1.0 websites, inclusief globals, document.all en "new Array()" Is meer een kwestie van niet kunnen programmeren of de taal niet kennen.

.oisyn schreef op vrijdag 27 maart 2009 @ 11:59:
[...]
Proton language proposal

offtopic:
Zit er copyright op ? Ik heb wel interesse in het maken van een interpreter/compiler voor een scripttaal met zowel dynamic als static typing, handig voor berekeningen..

[harrald]

.oisyn schreef op vrijdag 27 maart 2009 @ 18:06:
Heeft javascript een slecht imago dan?
For what it's worth, ik vind javascript een mooie en goed uitgedachte taal. Dat PHP een slecht imago heeft vind ik terecht, maar dat imago heeft ie dan wel weer om de verkeerde redenen denk ik (namelijk het vele aantal prutsers, maar dat is niet de "schuld" van PHP zelf)

Javascript had een slecht imago ja. Maar dat kwam dan ook weer omdat iedereen er wel iets mee kon.
Douglas crockford weet het heel mooi uit te leggen .

[prototype]

Hacku schreef op donderdag 26 maart 2009 @ 20:57:
[...]


Hier kan php ook leuke dingen met doen.

PHP:

$t = '6_test';

echo (int) $t; // 6

Dit gedrag opzich kan best wenselijk worden geacht denk ik voor beginnerlingen die nog niet helemaal het datatypen gebeuren doorhebben. Het moet in ieder geval niet gedacht worden dat dit een quirk is dat alleen in PHP kan, je kan namelijk zoiets ook lekker in C++ flikken.

Het verschil zit hem echter dan erin dat ik hierbij dan mijn eigen specifieke string implementatie erbij zou moeten pakken en de int type conversion operator zou moeten overloaden om dit gedrag na te kunnen doen. Natuurlijk alleen doen als daar echt goede reden toe is, anders niet.

Een taal als C++ is dan ook niet imo voor een beginnerling weggelegd, en dat dit soort gedrag er dan niet standaard in zit lijkt me in dit geval even wenselijk als dat het voor PHP wel zo is. Oh, en als ik niet duidelijk genoeg was, **ik vind** PHP erg geschikt voor beginnerlingen. Mensen die eenmaal ervaren dat de taal hun meer tegenwerkt dan meewerkt moeten overstappen vind ik of genoeg tijd en geduld hebben om dit soort dingen aan te vechten bij de PHP core team. HEEL VEEL TIJD EN GEDULD ;-)

Hacku schreef op donderdag 26 maart 2009 @ 21:11:
[...]
Dan nog is het niet logisch String casten naar integer.

Waarom is dat niet logisch? Een Type naar Type cast is gewoon meer dan logisch lijkt me zolang er een gepaste transformatie voor te bedenken is. (int) "12345" is er zo een imo, evenals --alhoewel veel meer twijfelachtig-- (int)"12345asdasdas". Het logische aspect komt hem pas erbij kijken hoe de programmeur dit weet te gebruiken imo.

P.S. JanDM ik ben al een paar dagen geleden begonnen met implementeren :-) Eerste paar AST classes en constantfolder classes zitten er al in. LLVM heb ik voorlopig even opgegeven aangezien de documentatie ervan ZWAAR outdated is en er gewoon regelrechte leugens vaak ook in zitten. Beweringen van implementaties die gedaan zijn die in werkelijkheid __NIET__ gedaan zijn.

[ Voor 24% gewijzigd door prototype op 28-03-2009 00:20 ]

[NMe]

krvabo schreef op vrijdag 27 maart 2009 @ 21:39:

PHP:

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

Zoals je aan de highlighting al kunt zien zijn isset() en empty() language constructs en zijn de diverse is_* en in_* functies gewoon dat: functies, onderdeel van het Zend framework. Aangezien dat framework en PHP als taal los ontwikkeld zijn is die tegenstrijdigheid redelijk simpel verklaard.

[ Voor 9% gewijzigd door NMe op 28-03-2009 01:10 ]

[Verwijderd]

prototype schreef op vrijdag 27 maart 2009 @ 23:59:
[...]


Waarom is dat niet logisch? Een Type naar Type cast is gewoon meer dan logisch lijkt me zolang er een gepaste transformatie voor te bedenken is. (int) "12345" is er zo een imo, evenals --alhoewel veel meer twijfelachtig-- (int)"12345asdasdas". Het logische aspect komt hem pas erbij kijken hoe de programmeur dit weet te gebruiken imo.

Casten van Type1 naar Type2 zou alleen moeten mogen wanneer je een object verwacht wat aan Type2 voldoet.

Zodra het om twee compleet verschillende types gaat; String en Integer bijvoorbeeld zou het casten niet zomaar mogen. Je weet immers niet wat de inhoud van de string is, dit kan een heel verhaal zijn of de tekens "123".
Daarom zijn er ook convertie methoden bedacht, zie in C# bijvoorbeeld de Convert klasse (of int.TryParse) en in Java is er Integer.parseInt.
In deze methoden kan je dus precies specificeren wat er in elk geval kan en mag gebeuren.

[ Voor 15% gewijzigd door Verwijderd op 28-03-2009 01:23 ]

[krvabo]

NMe schreef op zaterdag 28 maart 2009 @ 01:10:
[...]

Zoals je aan de highlighting al kunt zien zijn isset() en empty() language constructs en zijn de diverse is_* en in_* functies gewoon dat: functies, onderdeel van het Zend framework. Aangezien dat framework en PHP als taal los ontwikkeld zijn is die tegenstrijdigheid redelijk simpel verklaard.

Oh er zit vast wel een redenatie achter, maar het maakt het niet minder irritant, lomp en ronduit verwarrend. Zoals ik al zei kan dit makkelijk aangepakt worden.
Inconsistentie hoort niet in een taal, of het nou komt door groei / samenvoeging of niet..

[prototype]

Verwijderd schreef op zaterdag 28 maart 2009 @ 01:18:
[...]

Casten van Type1 naar Type2 zou alleen moeten mogen wanneer je een object verwacht wat aan Type2 voldoet.

Waarop baseer je deze uitspraak? Kijk, in dit geval hebben we het bij PHP over een weaktyped taal dat uitgaat van het principe als het kwaakt als een eend en waggelt als een eend dan is het eend. Dit staat nog in het verlengde van je uitspraak, maar dat gezegd hebbende is het vaak genoeg voorgekomen dat ik een integer representatie nodig heb van een object in C++, denk bijvoorbeeld aan een filedescriptorhandler class die voor bepaalde system calls naar een integer representatie gecast moet kunnen worden. Een int representatie getter zou natuurlijk ook volstaan maar dat is weer zoveel tikwerk

Zodra het om twee compleet verschillende types gaat;

Wat zijn in jouw ogen twee compleet verschillende types? Dus wat zijn de criteria ervoor voor jou? Deze vraag is meteen eigenlijk de essentie van mijn punt. Als er een logische beredenering voor te vinden is dan zou het gewoon toegestaan moeten zijn imo.

String en Integer bijvoorbeeld zou het casten niet zomaar mogen. Je weet immers niet wat de inhoud van de string is, dit kan een heel verhaal zijn of de tekens "123".

Daarom zijn er ook convertie methoden bedacht, zie in C# bijvoorbeeld de Convert klasse (of Integer.TryParse) en in Java is er Integer.parseInt.
In deze methoden kan je dus precies specificeren wat er in elk geval mag gebeuren.

Dit is een implementatie detail en voegt niet zo bar veel toe aan de discussie (het is een ander verhaal zelfs, eentje die meer neigt naar strongtyped talen vs weaktyped talen). PHP is gewoon een weaktyped taal,en zal vanuit deze filosofie dit gewoon proberen te coercen/casten indien hij denkt dat het mogelijk is. Hier kun je het mee eens zijn of niet en het biedt ook mogelijkheden om expliciet(er) te zijn in je intenties. Als dit je alsnog niet bevalt, overstappen naar een strongtyped taal want dan zit je hier niet goed.

Voor strongtyped talen is mijn in C++ type operator overload in essentie hetzelfde als die Integer.TryParse en Integer.parseInt en net als die methoden kun je in geval van "een heel verhaal als input" gewoon een exception gooien indien je dat wenst.

Verder, naar mijn herinnering zijn classes in C# en Java niet heropenbaar. Daarbij zijn de Integer classes in C# en Java naar mijn herinnering ook nog eens "final" dus wat je nou precies bedoelt met wat je precies kan specificeren in dat soort gevallen ontgaat mij.

[ Voor 11% gewijzigd door prototype op 28-03-2009 01:49 ]

[NMe]

krvabo schreef op zaterdag 28 maart 2009 @ 01:29:
[...]

Oh er zit vast wel een redenatie achter, maar het maakt het niet minder irritant, lomp en ronduit verwarrend. Zoals ik al zei kan dit makkelijk aangepakt worden.
Inconsistentie hoort niet in een taal, of het nou komt door groei / samenvoeging of niet..

Taal != framework.

[.oisyn]

Kan wel zijn, hij heeft weldegelijk een punt. PHP komt met een standard library die impliciet gekoppeld is aan de taal. Je kunt op z'n minst voor consistentie zorgen. Sowieso is het bij het ontwerp van een library handig om consistent te zijn met de naamgeving van de taal.

[NMe]

Da's waar, maar ik heb een beetje moeite met mensen die een taal afzeiken terwijl ze zelf language contructs niet van functies kunnen onderscheiden en het framework niet van de taal.

[prototype]

MBV schreef op vrijdag 27 maart 2009 @ 16:07:
[...]

Java ook niet.


[...]

*kadoenk* *klimt op stoel* WTF?!
Dus je moet zoiets doen:

PHP:

__construct() {
  switch (func_num_args()) {
  ...
  }
}

Dit soort problemen is vaak omheen te werken met default argument waarden (wat zo'n beetje een idoom voor dit soort problemen lijkt te zijn in meer scripttalen die overloading niet ondersteunen). Je krijgt dan zoiets als:

PHP:

class Foo {
    public function __construct($arg = "hoi", $arg2 = true, $arg3 = 1821, $x = null) { }
}

Je kan dan in feite die argumenten waar een default waarde voor is weglaten in de invocation.

Dit is dan ook nog niet zozeer imo de WTF. Volgens mij --maar dat kan ik niet met zekerheid stellen, te lang geleden immers-- kan PHP in dit geval niet overweg met "complexere" default args. Zoiets als:

PHP:

class Foo {
    public function __construct($arg = new SomethingElse()) {
        //...
    }
}

Zal de parser bij op z'n bek gaan iirc. En een soortgelijk iets (en enigzins gerelateerd mbt constructie van objecten) voor:

PHP:

class Foo {
    private $arg = new SomethingElse();
    //...
}

Zal de parser op z'n bek doen laten gaan iirc. Andere talen (zoals Ruby) ondersteunen ook geen method overloading, maar kunnen daarentegen dit soort expressies voor default argumenten wel aan. Dit is imo dan ook meer de WTF (indien PHP dit nog steeds niet kan).

Een ander idoom dat vaak gebruikt wordt voor het ondervangen van het ontbreken van method overloading is de welbekende factory method. Je krijgt dan bij PHP zoiets als:

PHP:

class Foo {
    public static function createWithBla($bla) { }
    public static function createWithFoo($foo) { }
    public static function createWithSjaakAndTrekhaak($sjaak, $trekhaak) { }
}

Roeien met de riemen die je hebt heren , mooi is anders.

[NMe]

prototype schreef op zaterdag 28 maart 2009 @ 03:25:
[...]

Roeien met de riemen die je hebt heren , mooi is anders.

Hoe wou je überhaupt function overloading ondersteunen in een loosely typed taal? Als ze dat netjes willen gaan doen dan moeten ze eerst eens PHP strong typed maken of op zijn minst type hinting beter implementeren én gaan forceren. Zie ik zo snel niet gebeuren.

[prototype]

NMe schreef op zaterdag 28 maart 2009 @ 03:36:
[...]

Hoe wou je überhaupt function overloading ondersteunen in een loosely typed taal? Als ze dat netjes willen gaan doen dan moeten ze eerst eens PHP strong typed maken of op zijn minst type hinting beter implementeren én gaan forceren. Zie ik zo snel niet gebeuren.

Normaal zou ik het met je eens zijn hierop, maar --zoals je zelf al zegt-- PHP heeft ook zoiets als typehinting. :-) Aan de hand daarvan zou je al een heel eind kunnen komen met method dispatching, en de reden waarom dit nog niet gedaan is is volgens mij dat a) de overhead voor het resolven van de juiste method invocation te groot is, b) te complex is om te implementeren voor de PHP implementeermensen ;-) Hoe dan ook, ik ben het met je eens dat dit er niet zo snel van zal komen, maar dat heb ik wel met meer dingen bij PHP. Zolang het aantal PHP'ers nog steeds zo huge blijft ga ik er maar van uit dat ze de "juiste" overwegingen nemen met hun achterban in het achterhoofd.

Ik ben niet zozeer van mening dat het liberale ervan af zou moeten gaan bij typehinting: indien het immers niet geresolved kan worden zou er een methodinvocationerror/ambiguousinvocationerror ofzo gegooid moeten worden :-)

Edit:

roy-t schreef op vrijdag 27 maart 2009 @ 18:47:
Ook kwam ik op de volgende vaagheid (niet zeker of dat nu nog zo is).


[...]


Aaarg!

Michali schreef op vrijdag 27 maart 2009 @ 18:55:
[...]

Tja, dit is natuurlijk het probleem van OO in PHP4. Sinds PHP5 is dit niet meer het geval.

Hehe, dit was imho meer een "oh, wij gaan C/C++ zoveel mogelijk nadoen maar eigenlijk niet goed/slecht genoeg" probleem (zoals vergeten dan ook de gebruiker een copy constructor en assignment operator respectievelijk te laten definieren en overloaden). Zo is in C++ b.v. het gedrag van een default copy ctor dat hij alle velden kopieert en in feite dus een shallow kopie maakt van het object: dit default gedrag zal toegepast worden als je niet je eigen copy constructor levert die eventueel toegepast zou kunnen worden. Je zou dan je eigen gedrag kunnen definieren, iets wat in PHP4 niet kon.

Het waren nou net deze dingen die in PHP4 niet voorhanden waren waardoor dit nogal een WTF implementatie was. In PHP5 gebeurt nu schijnbaar alles via references en zul je wanneer je een object wil kopieren dit expliciet moeten aanduiden met clone. Dit zal een shallow copy uitvoeren op het object net als de default copy ctor in C++, en indien je een deep copy wil maken, zul je nog dit gedrag moeten specificeren in je eigen "copy constructor" __clone().

[ Voor 61% gewijzigd door prototype op 28-03-2009 04:49 ]

[krvabo]

NMe schreef op zaterdag 28 maart 2009 @ 03:15:
Da's waar, maar ik heb een beetje moeite met mensen die een taal afzeiken terwijl ze zelf language contructs niet van functies kunnen onderscheiden en het framework niet van de taal.

Ik zeik de taal niet af, ik zeg dat het vervelend en verwarrend is dat er geen consistente naamgeving is in functies 'die eenzelfde doel hebben'. Ik vind php een prima taal zolang je er niet teveel van verwacht.

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.
Toen ik na een jaar weer begon typte ik steevast is_empty en ik vroeg me af waarom het niet werkte. Dáárom is het vervelend. Uiteraard, zodra je eenmaal weer er achter bent dat het gewoon 'empty' is, dan is er niets aan de hand.

* Ik heb net nog opgezocht wat hiermee precies wordt bedoeld, maar in essentie betekent het dus dat het een onderdeel is van de taal zelf is en geen function overhead heeft, maar zich (soms) wel gedraagt als een functie. Afgezien of het nou een language construct is of niet gebruik ik een functie als ik hem nodig heb. Op dat moment boeit het me zeer weinig of het een language construct is of een functie is in een standaard meegeleverd framework.

[ Voor 19% gewijzigd door krvabo op 28-03-2009 05:33 ]

[Verwijderd]

prototype schreef op zaterdag 28 maart 2009 @ 01:44:

Wat zijn in jouw ogen twee compleet verschillende types? Dus wat zijn de criteria ervoor voor jou? Deze vraag is meteen eigenlijk de essentie van mijn punt. Als er een logische beredenering voor te vinden is dan zou het gewoon toegestaan moeten zijn imo.

[...]

Voor strongtyped talen is mijn in C++ type operator overload in essentie hetzelfde als die Integer.TryParse en Integer.parseInt en net als die methoden kun je in geval van "een heel verhaal als input" gewoon een exception gooien indien je dat wenst.

Verder, naar mijn herinnering zijn classes in C# en Java niet heropenbaar. Daarbij zijn de Integer classes in C# en Java naar mijn herinnering ook nog eens "final" dus wat je nou precies bedoelt met wat je precies kan specificeren in dat soort gevallen ontgaat mij.

Ik had in mijn verhaal inderdaad vergeten mee te nemen dat PHP (helaas ) een weakly typed taal is. Zelf werk ik alleen maar met strongly typed talen, PHP ben ik al lang geleden vanaf gestapt.

En over die 'logische beredenering'...iedereen heeft daar een ander idee over (of kan er een ander idee over hebben).
Het lijkt mij dan het beste dat de taal/het framework zelf de 'standaard' convertie regels voorschrijft, en dat je indien gewest je eigen methoden kan schrijven (of operators kan overloaden) wanneer het standaard gedrag niet afdoende is.

[Kalentum]

NMe schreef op zaterdag 28 maart 2009 @ 01:10:
[...]

Zoals je aan de highlighting al kunt zien zijn isset() en empty() language constructs en zijn de diverse is_* en in_* functies gewoon dat: functies, onderdeel van het Zend framework. Aangezien dat framework en PHP als taal los ontwikkeld zijn is die tegenstrijdigheid redelijk simpel verklaard.

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

[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 ]