[PHP] Wat is er nou eigenlijk zo slecht aan PHP?

[telefoontoestel]

Om mijn mening hier ook nog even over te geven.

Het is in principe niet de taal die kut is, maar de ontwikkelaars die niet correct met een taal weten om te gaan die kut zijn. Ik werk op professionele basis met PHP en merk een enorm duidelijk verschil tussen de collega's die wel kunnen programmeren en de collega's die er ongeveer bij toeval in zijn gerold. Het feit dat PHP hier tolerant mee omgaat geeft deze programmeurs wel de gelegenheid om rotzooi te maken waar geen touw meer aan vast is te knopen. Dat is wat mij betreft een enorm min-punt.

Ik zelf kijk zeer uit naar PHP-7 waarbij type hints toegepast kunnen worden voor scalar types en de komst van de return types. De meer ervaren en/of onderwezen ontwikkelaar zal hier goed mee om weten te gaan, terwijl de toevallige ontwikkelaar zich hier behoorlijk aan zal kunnen ergeren. Het enige wat in dat geval nog mist is method-overloading.

Al met al heb ik wel het gevoel dat PHP steeds meer volwassen wordt en de mogelijkheden gaat bieden om meer strict te programmeren. Het is uiteindelijk aan de ontwikkelaar, en dat is gewoon in elke programmeertaal hetzelfde, om hier een goed werkend systeem van te maken.

[RayNbow]

telefoontoestel schreef op donderdag 20 augustus 2015 @ 19:22:
Het is in principe niet de taal die kut is, maar de ontwikkelaars die niet correct met een taal weten om te gaan die kut zijn.

Wat is dit voor onzin? Een taal zelf kan brak in elkaar steken ongeacht hoe goed de gebruikers van de taal zijn. Dit zijn twee aparte dingen.

Een elementair voorbeeld is iets als dit (pre PHP 5.4 weliswaar):

foo()[0]

Waarom is dit een syntaxfout? Het is toch gewoon een expr₁[expr₂]? Waarom mag expr₁ geen functieaanroep zijn? Dit voorbeeld is trouwens niet uniek aan PHP (pre 5.4). Matlab heeft ook een vergelijkbare inconsistentie in z'n syntax.

[PatrickH89]

RayNbow schreef op donderdag 20 augustus 2015 @ 19:50:
[...]

Wat is dit voor onzin? Een taal zelf kan brak in elkaar steken ongeacht hoe goed de gebruikers van de taal zijn. Dit zijn twee aparte dingen.

Een elementair voorbeeld is iets als dit (pre PHP 5.4 weliswaar):

foo()\[0]

Waarom is dit een syntaxfout? Het is toch gewoon een expr₁[expr₂]? Waarom mag expr₁ geen functieaanroep zijn? Dit voorbeeld is trouwens niet uniek aan PHP (pre 5.4). Matlab heeft ook een vergelijkbare inconsistentie in z'n syntax.

En dus geen goed voorbeeld wat er slecht aan PHP is. PHP 5.4 is al gereleased in 2012. Het topic heet nog altijd 'Wat is er nou eigenlijk zo slecht aan PHP?'.

[Barryvdh]

5.4 wordt zelfs niet meer actief ondersteund, 5.5 ook niet, dus alleen 5.6 officieel. http://php.net/supported-versions.php

[RayNbow]

PatrickH89 schreef op donderdag 20 augustus 2015 @ 20:41:
[...]


En dus geen goed voorbeeld wat er slecht aan PHP is. PHP 5.4 is al gereleased in 2012. Het topic heet nog altijd 'Wat is er nou eigenlijk zo slecht aan PHP?'.

Het was dan ook geen recent voorbeeld wat er mis is met PHP. Mijn post ging algemeen in op de stelling dat "de taal in principe niet kut is". Vandaar dat mijn voorbeeld niet specifiek inging op PHP. Immers, ik noemde Matlab als een ander voorbeeld met precies hetzelfde mankement.

Om daadwerkelijke vraag te beantwoorden wat er slecht *is* aan PHP, er werd al naar een hele lijst verwezen in de 2e reply: Avalaxy in "[PHP] Wat is er nou eigenlijk zo slecht aan PHP?"

[Barryvdh]

RayNbow schreef op vrijdag 21 augustus 2015 @ 07:15:
[...]

Het was dan ook geen recent voorbeeld wat er mis is met PHP. Mijn post ging algemeen in op de stelling dat "de taal in principe niet kut is". Vandaar dat mijn voorbeeld niet specifiek inging op PHP. Immers, ik noemde Matlab als een ander voorbeeld met precies hetzelfde mankement.

Om daadwerkelijke vraag te beantwoorden wat er slecht *is* aan PHP, er werd al naar een hele lijst verwezen in de 2e reply: Avalaxy in "[PHP] Wat is er nou eigenlijk zo slecht aan PHP?"

Tja, ook een beetje makkelijk om met een blog van 3,5 jaar oud te gooien.

Hier reactie van ircmaxell: http://blog.ircmaxell.com...-sucks-but-i-like-it.html

En hier een vergelijkbare conclusie: http://blog.codinghorror.com/php-sucks-but-it-doesnt-matter/

PHP heeft zijn rare dingen. Functies hebben verwarrende namen of onvoorspelbare parameter volgorde, foutafhandeling is niet consistent (soms errors, soms FALSE return, soms exceptions), converteren van types kan fout gaat etc etc.

En bovendien is er gigantisch veel brakke code, voornamelijk omdat het zo makkelijk is om met PHP te beginnen, dat iedereen er ook mee begint. En de tutorials/blogs van 12 jaar geleden met onveilige queries, dwalen nog steeds rond op het internet.

Gelukkig wordt er met PHP7 al een deel aangepakt qua inconsistenties, handige nieuwe features en het weghalen van mysql_* functies (zodat die onveilige blogs voor een groot deel niet meer werken). En met goede libraries/frameworks worden nog meer 'quirks' ondervangen.

Toch is het schijnbaar een van de meest populaire talen, ook al wordt er zoveel over geklaagd. (Hoge bomen vangen veel wind?)

http://www.tiobe.com/inde...paperinfo/tpci/index.html
7de meeste populaire taal in het algemeen.

http://w3techs.com/technologies/details/pl-php/all/all
81% van de websites draait PHP

https://github.com/blog/2047-language-trends-on-github
Al 7 jaar op de 4de plek qua populariteit op Github

En omdat er zo makkelijk mee begonnen kan worden, is er ook gigantisch veel software voor beschikbaar.

CMS: Drupal, Wordpress, Joomla hebben een aandeel van ca. 50% (gevolgd door Tumblr/Blogger, wat hosted oplossingen zijn)
http://trends.builtwith.com/cms

Webshops: Magento is met 20% het meest populair. Daarna Oracle ATG (niet PHP) maar dan weer WooCommerce (PHP)
http://trends.builtwith.com/shop

En persoonlijk vind ik PHP (5.4+) prima werken. Zeker met Composer en de PSR afspraken, werkt PHP gewoon prima. Er zijn veel goed werkende libraries, die gemakkelijk binnen te halen zijn met Composer en gewoon werken. Niet kloten met autoloaders, handmatig bestanden downloaden etc.
SemVer en testen wordt ook steeds meer geaccepteerd, vaak kan je niet eens een Pull Request indienen zonder ook bijbehorende tests te schrijven. Komt allemaal ten goede van de kwaliteit.

En tja, de brakke software moet je maar vandaan blijven, maar dat kan je wel redelijk beoordelen aan de hand van het Github repo..

[gekkie]

Barryvdh schreef op vrijdag 21 augustus 2015 @ 09:12:
[...]
En persoonlijk vind ik PHP (5.4+) prima werken. Zeker met Composer en de PSR afspraken, werkt PHP gewoon prima. Er zijn veel goed werkende libraries, die gemakkelijk binnen te halen zijn met Composer en gewoon werken. Niet kloten met autoloaders, handmatig bestanden downloaden etc.

Het nou ook niet dat CPAN nooit bestaan heeft zeg maar (of PIP of .. ) dus niet echt een unieke kwaliteit van PHP.

[DexterDee]

Barryvdh schreef op vrijdag 21 augustus 2015 @ 09:12:
Toch is het schijnbaar een van de meest populaire talen, ook al wordt er zoveel over geklaagd. (Hoge bomen vangen veel wind?)

Tja, zoals Bjarne Stroustrup (bedenker C++) al eens ooit zei:

Er zijn twee type programmeertalen:
• De programmeertaal waar iedereen over klaagt
• De programmeertaal die niemand gebruikt

We weten allemaal wel waar PHP onder valt

[PatrickH89]

gekkie schreef op vrijdag 21 augustus 2015 @ 09:39:
[...]

Het nou ook niet dat CPAN nooit bestaan heeft zeg maar (of PIP of .. ) dus niet echt een unieke kwaliteit van PHP.

Deze post is slechter leesbaar dan PHP

[gekkie]

PatrickH89 schreef op vrijdag 21 augustus 2015 @ 09:48:
[...]
Deze post is slechter leesbaar dan PHP

Dacht ik moet het een beetje in de stijl houden (en het is nog pre-koffie)

[Barryvdh]

gekkie schreef op vrijdag 21 augustus 2015 @ 09:39:
[...]

Het nou ook niet dat CPAN nooit bestaan heeft zeg maar (of PIP of .. ) dus niet echt een unieke kwaliteit van PHP.

Ik zeg toch ook niet dat het uniek is aan PHP? Alleen dat het erg goed werkt in PHP en het leven stuk makkelijker maakt.

[gekkie]

Nee het is niet uniek aan PHP, echter was CPAN er bij mijn weten wat eerder.
Toch zijn we allemaal van (perl)CGI scripts afgegaan (en dus ook CPAN) en PHP gaan gebruiken.

Kan er eigenlijk 2 redenen voor verzinnen:

• De ASP alike <% %> <? ?> mogelijkheid tot het makkelijk integreren van kleine PHP-snippets in je HTML pagina.
  Vroeger in de good old days was een pagina meestal meer HTML dan PHP, dus de mogelijkheid om in plaats van je hele pagina in print statements te vervatten, de PHP code
• Voor zaken waar je bij perl wellicht geacht werd dit met een minder vriendelijk ogende expressie op te lossen, kwamen er bij PHP voor van alles en nog wat nieuwe functies bij met een vriendelijk ogende naam.

Daar buiten maken ze allebei gebruik van een server-api (toen meestal apache), beide een lifetime van een request en de bijbehorende voordelen (en nadelen).

[ Voor 9% gewijzigd door gekkie op 21-08-2015 10:18 ]

[RayNbow]

Barryvdh schreef op vrijdag 21 augustus 2015 @ 09:12:
[...]

Tja, ook een beetje makkelijk om met een blog van 3,5 jaar oud te gooien.

Hier reactie van ircmaxell: http://blog.ircmaxell.com...-sucks-but-i-like-it.html

En hier een vergelijkbare conclusie: http://blog.codinghorror.com/php-sucks-but-it-doesnt-matter/

En dat zijn geen oude blog posts?

Ook de argumentatie van de eerste link is soms wat dubieus. Verder snapt de auteur soms niet de geleverde kritiek. Zie bijv.:

Static Variables Inside Instance Methods are Global - This is true, because that's exactly what a static variable is supposed to be. It's just like using a variable in Python using `obj.__class__.varname`...

De oorspronkelijke kritiek ging hier niet om static members van een class, maar static variables binnen een functie/methode.

[Barryvdh]

RayNbow schreef op vrijdag 21 augustus 2015 @ 10:48:
[...]

En dat zijn geen oude blog posts?

Jawel, en was ook makkelijk om niet op heel die post te reageren

Ik zeg ook niet dat de post in zijn geheel niet klopt he (en ircmaxell zijn post ook niet), alleen het is wel weer 3,5 jaar geleden, dus we zijn nu een stuk verder weer.

[Gomez12]

Barryvdh schreef op vrijdag 21 augustus 2015 @ 11:32:
[...]

Jawel, en was ook makkelijk om niet op heel die post te reageren

Ik zeg ook niet dat de post in zijn geheel niet klopt he (en ircmaxell zijn post ook niet), alleen het is wel weer 3,5 jaar geleden, dus we zijn nu een stuk verder weer.

Maar is er in die 3,5 jaar iets uitgehaald / weggehaald? Of zijn er betere dingen naastgezet en zitten de slechte dingen er nog steeds in (alleen is het nu nog ingewikkelder geworden want je moet nu opeens bewust gaan kiezen tussen slechte methode of goede methode)

Met php7 lijken ze het te willen veranderen, maar met de meeste dingen ervoor heb ik zoiets van : Het was slecht en er is van alles omheen gebouwd wat wel redelijk is, maar het huidige eindresultaat is dan : slecht en verwarrend. Behalve als je echt alle ins en outs weet...

[telefoontoestel]

RayNbow schreef op donderdag 20 augustus 2015 @ 19:50:
[...]

Wat is dit voor onzin? Een taal zelf kan brak in elkaar steken ongeacht hoe goed de gebruikers van de taal zijn. Dit zijn twee aparte dingen.

Een elementair voorbeeld is iets als dit (pre PHP 5.4 weliswaar):

foo()\[0]

Waarom is dit een syntaxfout? Het is toch gewoon een expr₁[expr₂]? Waarom mag expr₁ geen functieaanroep zijn? Dit voorbeeld is trouwens niet uniek aan PHP (pre 5.4). Matlab heeft ook een vergelijkbare inconsistentie in z'n syntax.

Ik zelf heb het ook over de huidige versie(s) van PHP en de aankomende waarin nog weer meer verbeteringen zitten. Hetzelfde gaat voor de argumenten waarbij parameters etc. niet consitent zijn. De structuur van de taal klopt dan nog steeds, alleen de implementatie van een of meerdere functies binnen de taal zijn door de betreffende developer(s) niet consistent uitgevoerd. Dat is dus ook weer een ontwikkelaarsfout.

[Gomez12]

telefoontoestel schreef op maandag 24 augustus 2015 @ 11:51:
[...]
Ik zelf heb het ook over de huidige versie(s) van PHP en de aankomende waarin nog weer meer verbeteringen zitten.

Zie mijn reactie hierboven, hoeveel van de oude bagger is er uit de huidige versie van PHP gehaald?
Of is het enkel een vergaarbak waar je bij toeval de juiste functie uit kan pakken, maar net zo goed de verkeerde (als beginner)

Hetzelfde gaat voor de argumenten waarbij parameters etc. niet consitent zijn. De structuur van de taal klopt dan nog steeds, alleen de implementatie van een of meerdere functies binnen de taal zijn door de betreffende developer(s) niet consistent uitgevoerd. Dat is dus ook weer een ontwikkelaarsfout.

Tja, op deze manier is de hele taal niet meer relevant, want de hele taal is dan een ontwikkelaarsfout.

[gekkie]

Gomez12 schreef op maandag 24 augustus 2015 @ 12:11:
Zie mijn reactie hierboven, hoeveel van de oude bagger is er uit de huidige versie van PHP gehaald?
Of is het enkel een vergaarbak waar je bij toeval de juiste functie uit kan pakken, maar net zo goed de verkeerde (als beginner)

Blijft toch een lastig fenomeen .. het eerst deprecaten en vervolgens verwijderen van functionaliteit.
(en nog lastiger is het verwijderen van 3rd party documentatie die niet voldoet, dat zal organisch een stille dood moeten sterven). Maar op dit tempo gaat het nog wel even duren.

Achja misschien heeft de haat/liefde verhouding met PHP een soort van bel curve ..

Als beginner is het fantatisch want je krijgt snel in iedergeval "een" resultaat.
Voor de gemiddelde PHP'er kom je steeds meer hebbelijkheden tegen en moet je er op gaan letten dat je je houdt aan alle niet afgedwongen conventies en inconsistencies.
Voor de expert is het weer fantastisch want je kan nog echt expert zijn.

Tja, op deze manier is de hele taal niet meer relevant, want de hele taal is dan een ontwikkelaarsfout.

Tijd om gelovig of een creationist te worden en alles is een ontwikkelaarsfout

[Barryvdh]

Gomez12 schreef op maandag 24 augustus 2015 @ 12:11:
[...]

Zie mijn reactie hierboven, hoeveel van de oude bagger is er uit de huidige versie van PHP gehaald?
Of is het enkel een vergaarbak waar je bij toeval de juiste functie uit kan pakken, maar net zo goed de verkeerde (als beginner)

Zie https://wiki.php.net/rfc/...ted_functionality_in_php7
In PHP7 is dus ext/mysql verwijderd (de oude mysql_* functies). Deze was al deprecated sinds PHP 5.5, dus daar kreeg je een deprecation notice op als je die gebruikt.
Daarnaast staat er al een hele tijd een grote rode waarschuwing bij al die functies: http://php.net/manual/en/function.mysql-query.php

Andere functionaliteit, zoals magic quotes zijn al eerder weggehaald.

[telefoontoestel]

Gomez12 schreef op maandag 24 augustus 2015 @ 12:11:
[...]

Zie mijn reactie hierboven, hoeveel van de oude bagger is er uit de huidige versie van PHP gehaald?
Of is het enkel een vergaarbak waar je bij toeval de juiste functie uit kan pakken, maar net zo goed de verkeerde (als beginner)


[...]

Tja, op deze manier is de hele taal niet meer relevant, want de hele taal is dan een ontwikkelaarsfout.

Uiteraard zitten er onderdelen in PHP die niet de schoonheidsprijs verdienen. Ik probeer er mee aan te geven dat een taal niet hoeft te worden afgeschoten op basis van de parameter volgorde van legacy functies van 10 jaar geleden. Een taal is veel meer dan alleen het gebruik van standaard functies.

Een groot nadeel, maar ook voordeel, is dat er binnen de PHP community sterk wordt vastgehouden aan het concept van backwords compatability. Wat mij betreft zouden ze dat best eens los mogen laten en het aan de ontwikkelaar over laten op basis van welke versie de code geschreven is. De ontwikkelingen in PHP-7 geven wat mij betreft al een goede stap in de juiste richting en zou het mooi zijn als bepaalde syntaxen (zoals scalar type-hints en return types) ook verplicht kunnen zijn.

[Gomez12]

Barryvdh schreef op maandag 24 augustus 2015 @ 12:58:
[...]
Zie https://wiki.php.net/rfc/...ted_functionality_in_php7

En in php1000 is het dan wellicht een niet zo slechte taal meer, maar de vraag ging volgens mij niet over toekomstige versies maar over huidige versies.

Barryvdh schreef op maandag 24 augustus 2015 @ 12:58:
[...]
Daarnaast staat er al een hele tijd een grote rode waarschuwing bij al die functies: http://php.net/manual/en/function.mysql-query.php

Het is alleen jammer dat wederom maar half/half gedaan is. Ik zou het verwachten bij een changelog, maar daar wordt er niet van gesproken (http://php.net/manual/en/changelog.mysql.php) ik zou het verwachten bij de examples ( http://php.net/manual/en/mysql.examples-basic.php ) en ook bij de extensie zelf staat er niets ( http://php.net/manual/en/book.mysql.php )
Het staat enkel maar bij de functie-documentatie terwijl ik die bij een "nette" taal juist zo goed als niet nodig heb (daar heb ik intellisense voor) , ik heb een functie naam nodig en dan kan ik de rest wel intypen bij een beetje nette programmeertaal (ok, agreed bij php heb je wel weer de functiebeschrijving veelal nodig, maar dat is dus een van de slechte dingen)

telefoontoestel schreef op maandag 24 augustus 2015 @ 13:32:
[...]
Ik probeer er mee aan te geven dat een taal niet hoeft te worden afgeschoten op basis van de parameter volgorde van legacy functies van 10 jaar geleden.

Ik zou het even moeten nakijken, maar ik meen dat wat jij benoemd tot legacy functies van 10 jaar geleden in veel gevallen nog steeds de enige mogelijkheid is.

Voor sommige dingen zijn er nieuwe alternatieven, maar nog voor lang niet alles.

[Barryvdh]

Gomez12 schreef op maandag 24 augustus 2015 @ 14:33:
[...]

En in php1000 is het dan wellicht een niet zo slechte taal meer, maar de vraag ging volgens mij niet over toekomstige versies maar over huidige versies.


[...]

Het is alleen jammer dat wederom maar half/half gedaan is. Ik zou het verwachten bij een changelog, maar daar wordt er niet van gesproken (http://php.net/manual/en/changelog.mysql.php) ik zou het verwachten bij de examples ( http://php.net/manual/en/mysql.examples-basic.php ) en ook bij de extensie zelf staat er niets ( http://php.net/manual/en/book.mysql.php )
Het staat enkel maar bij de functie-documentatie terwijl ik die bij een "nette" taal juist zo goed als niet nodig heb (daar heb ik intellisense voor) , ik heb een functie naam nodig en dan kan ik de rest wel intypen bij een beetje nette programmeertaal (ok, agreed bij php heb je wel weer de functiebeschrijving veelal nodig, maar dat is dus een van de slechte dingen)


[...]

Ik zou het even moeten nakijken, maar ik meen dat wat jij benoemd tot legacy functies van 10 jaar geleden in veel gevallen nog steeds de enige mogelijkheid is.

Voor sommige dingen zijn er nieuwe alternatieven, maar nog voor lang niet alles.

PHP7 is in principe de huidige versie waaraan gewerkt wordt nu, ext/mysql is weggehaald uit de master branch van php-src: https://github.com/php/ph...e120a84ee030bb87c14a199b0
Er is al een PHP7 Release candidate uitgebracht, dus het gaan vergelijken met PHP1000 is een beetje overdreven.

In de changelog staat ook duidelijk sinds PHP 5.5.0: "This extension has been deprecated".
En daarnaast, je krijgt dus gewoon een deprecation notice als je hem toch probeert te gebruiken. Een fatsoenlijk IDE zal daarnaast ook waarschuwen dat je de functies niet meer moet gebruiken.



Maargoed, ik neem aan dat je ook wel snapt dat ze niet zomaar functionaliteit van de ene op de andere dag weg kunnen gooien. Er bestaan nog steeds veel systemen die van de oude mysql extension gebruik maken. En dat hoeft helemaal niet te betekenen dat dat persé onveilig is, want die kan je ook veilig gebruiken.
Door veel breaking changes, weerhoudt je veel hosting providers juist weer van upgraden, wat dus een averechts effect heeft. En als meer hosting providers niet upgraden, kunnen frameworks/libraries/cms-en dus ook niet zomaar hun minimum versie verhogen..

[Hydra]

telefoontoestel schreef op donderdag 20 augustus 2015 @ 19:22:
Het is in principe niet de taal die kut is, maar de ontwikkelaars die niet correct met een taal weten om te gaan die kut zijn.

Nou ik vind dat je best kan stellen dat een taal waarbij 100 == "100xyz" naar true evaluate redelijk kut is.;)

Het probleem met PHP als taal is redelijk simpel: het is als taal organisch gegroeid vanuit een hobby project. Er zijn destijds een hoop keuzes gemaakt met als gedachte dat ze 'handig' zijn (zoals bovenstaande type coercion) maar uiteindelijk er toe leiden dat je jezelf gewoon in je voet schiet. Je ziet dit ook terug in de oorspronkelijke mysql_ functies; het idee was gewoon om ff snel wat HTML uit te poepen op basis van een MySQL query. Een taal die DB specifieke functies ingebakken heeft is natuurlijk vanuit een design standpoint redelijk bizar.

Daarbij komen we ook op probleem twee: PHP was de koning in cowboy-coding land en een erg ERG groot deel van het lesmateriaal beschikbaar is van dezelfde kwaliteit als de taal zelf: abominabel. SQL injections zijn aan de orde van de dag in de gemiddelde PHP tutorial bijvoorbeeld.

Tenslotte is er nog het oorspronkelijke voordeel: met PHP kan je "simpel" wat HTML outputten naar een browser. In 2002 was dat met andere talen lastiger. Toen kwam Ruby on Rails, zag men het licht wat betreft het scheiden van code en view, en was er opeens voor iedere serieuze back-end taal een plethora aan frameworks beschikbaar. Ook voor PHP: professionele PHP developers werken gewoon niet op de manier zoals tutorials aanraden.

Waarom PHP minder relevant wordt is dus simpel: de taal is slecht gedesigned. Documentatie online leert mensen verkeerde habits aan. En tenslotte: er is geen echte reden meer PHP te verkiezen boven andere talen als Ruby, Python, JavaScript, Java, Groovy, Scala of C#.

Barryvdh schreef op maandag 24 augustus 2015 @ 15:00:
[afbeelding]

Dat is geen productie code verder hoop ik? Want dat is precies het probleem wat ik beschrijf met tutorials: zo werk je in 't 'echt' niet.

[ Voor 7% gewijzigd door Hydra op 25-08-2015 11:12 ]

[telefoontoestel]

Hydra schreef op dinsdag 25 augustus 2015 @ 11:08:
Nou ik vind dat je best kan stellen dat een taal waarbij 100 == "100xyz" naar true evaluate redelijk kut is.;)

Dat is een van de weinige steekhoudende argumenten die ik in het hele topic heb terug gevonden. Die evaluatie zou inderdaad niet mogen.

Hydra schreef op dinsdag 25 augustus 2015 @ 11:08:
En tenslotte: er is geen echte reden meer PHP te verkiezen boven andere talen als Ruby, Python, JavaScript, Java, Groovy, Scala of C#.

Mijn voorkeur zou eigenlijk ook uitgaan naar Java of C#, maar er is bijzonder weinig hosting te krijgen die en betaalbaar is en een van deze platforms ondersteund.

[Hydra]

telefoontoestel schreef op dinsdag 25 augustus 2015 @ 13:05:
Mijn voorkeur zou eigenlijk ook uitgaan naar Java of C#, maar er is bijzonder weinig hosting te krijgen die en betaalbaar is en een van deze platforms ondersteund.

Ik heb zelf gewoon een VPS bij TransIP voor 10E per maand en ze zijn er al van 5 dollar per maand. En dan kan je 'em helemaal zelf inrichten. Mijn "zooi" is ook gewoon Java gebaseerd.

[Gomez12]

telefoontoestel schreef op dinsdag 25 augustus 2015 @ 13:05:
[...]

Dat is een van de weinige steekhoudende argumenten die ik in het hele topic heb terug gevonden. Die evaluatie zou inderdaad niet mogen.

Dat is een voorbeeld, geen argument op zichzelf.

[NMe]

Hydra schreef op dinsdag 25 augustus 2015 @ 11:08:
[...]

Nou ik vind dat je best kan stellen dat een taal waarbij 100 == "100xyz" naar true evaluate redelijk kut is.;)

Ik vind dat kort door de bocht. PHP heeft gewoon een verschil geïntroduceerd tussen equality (wat enigszins behoorlijk fuzzy is) en identity. Het ene check je met ==, het andere met ===. De enige verwarring zit hem erin dat andere talen die == ook gebruiken en het daar veel strikter is. Dat je dit principe niet prettig vindt is je goed recht, maar het is een van de slechtere voorbeelden waarom de taal slecht zou zijn.

Wat dat betreft zou ik eerder afgeven op dit soort geintjes:

PHP:

$a = $b = "2Z9";
++$a;
$b += 1;

var_dump($a);  // string(3) "3A0"
var_dump($b);  // int(3)

[Sgreehder]

Deze kan ook vervelend aflopen;

code:

$var = 1;
switch($var) {
  case "nope":
    var_dump($var); // geeft INT(1)
}

Valt ook niet strict uit te voeren.

Maar ach, tenzij je tegen legitieme bugs aanloopt in PHP zelf, denk ik dat de stand van zaken er tegenwoordig steeds beter voorstaan. Elegant is anders, maar al dat boilerplating hoeft allang niet meer.

[Barryvdh]

Hydra schreef op dinsdag 25 augustus 2015 @ 11:08:

[...]


Dat is geen productie code verder hoop ik? Want dat is precies het probleem wat ik beschrijf met tutorials: zo werk je in 't 'echt' niet.

Nee, iig niet mijn productie code Dat was het voorbeeld van de php.net site waar ik op reageerde: http://php.net/manual/en/mysql.examples-basic.php
Maar dat ging enkel over het aangeven van de deprecated waarschuwingen..

[gekkie]

NMe schreef op dinsdag 25 augustus 2015 @ 13:51:
[...]
Ik vind dat kort door de bocht. PHP heeft gewoon een verschil geïntroduceerd tussen equality (wat enigszins behoorlijk fuzzy is) en identity. Het ene check je met ==, het andere met ===. De enige verwarring zit hem erin dat andere talen die == ook gebruiken en het daar veel strikter is. Dat je dit principe niet prettig vindt is je goed recht, maar het is een van de slechtere voorbeelden waarom de taal slecht zou zijn.

Zit die fuzziness niet 100% in php's voodoo-typecasting ?

Ze zijn immers ook inequal .. tot dat je van de "100xyz" een int gaat proberen te maken omdat je vergelijkt met een int en dan er voor kiest om de rest van de zooi maar te truncen in je impliciete cast naar int.

En ik zou ook niet weten waarom je ever op de correctheid van die voodoo zou willen vertrouwen.

[ Voor 5% gewijzigd door gekkie op 25-08-2015 21:12 ]

[NMe]

gekkie schreef op dinsdag 25 augustus 2015 @ 21:09:
[...]

Zit die fuzziness niet 100% in php's voodoo-typecasting ?

Ze zijn immers ook inequal .. tot dat je van de "100xyz" een int gaat proberen te maken omdat je vergelijkt met een int en dan er voor kiest om de rest van de zooi maar te truncen in je impliciete cast naar int.

En ik zou ook niet weten waarom je ever op de correctheid van die voodoo zou willen vertrouwen.

Deze "voodoo" is gewoon gedocumenteerd. Dat je het er niet mee eens bent: soit. Kan gebeuren. Ik vind het ook niet geweldig dat "2 appels" == "2 sinaasappels", maar het is volledig voorspelbaar én gedocumenteerd. Dat "voodoo" noemen vind ik, zoals gezegd, kort door de bocht. Er zitten genoeg echte design flaws en bugs in PHP om op te ranten, dus dit soort dingen benoemen treft geen doel, vind ik.

[gekkie]

NMe schreef op dinsdag 25 augustus 2015 @ 21:32:
[...]
Deze "voodoo" is gewoon gedocumenteerd. Dat je het er niet mee eens bent: soit. Kan gebeuren. Ik vind het ook niet geweldig dat "2 appels" == "2 sinaasappels", maar het is volledig voorspelbaar én gedocumenteerd. Dat "voodoo" noemen vind ik, zoals gezegd, kort door de bocht. Er zitten genoeg echte design flaws en bugs in PHP om op te ranten, dus dit soort dingen benoemen treft geen doel, vind ik.

Klopt het is gedocumenteerd .. en nee ze noemen het geen voodoo, maar "type juggling" ... my bad
.. niet bedacht door een jamaicaan maar door een circusclown.

Was je andere voorbeeld dan niet gedocumenteerd, ongetwijfeld onderhand ook wel (dus dat is dan ook geen goed voorbeeld) ?

Brainfuck is ook gedocumenteerd .. hell als je wilt kun je nog steeds nulletjes en eentjes kloppen, en opzich kun je zeggen het zijn ook geen slechte talen .. voor hun doel.

Alleen was een van de eigenschappen die aan PHP toegedicht wordt dat het zo simpel is en iedereen er snel wat mee kan maken. Dan helpen alle genoemde zaken dus niet, de ultieme beginner heeft er misschien weinig last van .. de ultieme expert ook niet, maar wat er tussen zit ...

That said .. gebruik je nog wel eens een == operator zonder zelf expliciete casts te doen ?

[ Voor 3% gewijzigd door gekkie op 25-08-2015 21:49 ]

[NMe]

gekkie schreef op dinsdag 25 augustus 2015 @ 21:46:
[...]

Was je andere voorbeeld dan niet gedocumenteerd, ongetwijfeld onderhand ook wel (dus dat is dan ook geen goed voorbeeld) ?

Dat ++ en -- de string volgens Perl-logica bewerken is inderdaad gedocumenteerd:

quote: http://php.net/manual/en/language.operators.increment.php

PHP follows Perl's convention when dealing with arithmetic operations on character variables and not C's. For example, in PHP and Perl $a = 'Z'; $a++; turns $a into 'AA', while in C a = 'Z'; a++; turns a into '[' (ASCII value of 'Z' is 90, ASCII value of '[' is 91). Note that character variables can be incremented but not decremented and even so only plain ASCII alphabets and digits (a-z, A-Z and 0-9) are supported. Incrementing/decrementing other character variables has no effect, the original string is unchanged.

Het geintje van hierboven, dat ++ en += andere effecten hebben op een string wordt niet benoemd. En bovendien gaan ze helemaal niet in op deze bullshit:

PHP:

$a = "9ZZ";
$b = "A-9ZZ";
$a++;
$b++;
var_dump($a); // 10AA
var_dump($b); // A-0AA

Brainfuck is ook gedocumenteerd .. hell als je wilt kun je nog steeds nulletjes en eentjes kloppen, en opzich kun je zeggen het zijn ook geen slechte talen .. voor hun doel.

Dat is ook zo. Er is behalve persoonlijke voorkeur geen reden om die taal per definitie niet te gebruiken.

That said .. gebruik je nog wel eens een == operator zonder zelf expliciete casts te doen ?

Regelmatig eigenlijk. In veel gevallen is die fuzzy vergelijking zelfs wenselijk.

[RayNbow]

NMe schreef op dinsdag 25 augustus 2015 @ 21:32:
[...]
Ik vind het ook niet geweldig dat "2 appels" == "2 sinaasappels", maar het is volledig voorspelbaar én gedocumenteerd.

Het is gedocumenteerd.

Of het voorspelbaar is hangt van je definitie van voorspelbaar af.

[NMe]

RayNbow schreef op dinsdag 25 augustus 2015 @ 23:01:
[...]

Het is gedocumenteerd.

Of het voorspelbaar is hangt van je definitie van voorspelbaar af.

Met "voorspelbaar" bedoel ik niet dat je zonder de documentatie te kennen zelf ook zou kunnen verzinnen dat de regels zo in elkaar zitten, maar dat wanneer je de regels weet, je er in principe nooit tegenaan loopt.

[gekkie]

NMe schreef op dinsdag 25 augustus 2015 @ 21:32:
[...]
"2 appels" == "2 sinaasappels"

By de weg .. dit is False .. want beide string .. maar dat wist je natuurlijk zelf ook al .. want het is gedocumenteerd in een prachtige dikke vette tabel

gelukkig hebben we nog 2 == "2,5" maar 2 != "2.5" ... het lijkt niet ook nog locale afhankelijk te zijn .. dat valt me dan weer mee

[gekkie]

NMe schreef op dinsdag 25 augustus 2015 @ 23:16:
[...]
Met "voorspelbaar" bedoel ik niet dat je zonder de documentatie te kennen zelf ook zou kunnen verzinnen dat de regels zo in elkaar zitten, maar dat wanneer je de regels weet, je er in principe nooit tegenaan loopt.

Dus dan hebben projecten waarbij ze zeggen "de code is de beste en definitieve documentatie" ook nooit bugs ... scheelt weer een hoop ge-"it's a feature, not a bug !"

[RayNbow]

NMe schreef op dinsdag 25 augustus 2015 @ 23:16:
[...]

Met "voorspelbaar" bedoel [...] dat wanneer je de regels weet, je er in principe nooit tegenaan loopt.

Oftewel, voorspelbaarheid is een functie van de hoeveelheid regels (en de complexiteit ervan) dat een mens op 1 moment in zijn actieve werkgeheugen kan houden?

Dan scoort PHP toch behoorlijk laag qua voorspelbaarheid.

[Hydra]

NMe schreef op dinsdag 25 augustus 2015 @ 13:51:
[...]

Ik vind dat kort door de bocht. PHP heeft gewoon een verschil geïntroduceerd tussen equality (wat enigszins behoorlijk fuzzy is) en identity. Het ene check je met ==, het andere met ===. De enige verwarring zit hem erin dat andere talen die == ook gebruiken en het daar veel strikter is.

Je mist het punt. Ik weet best dat == minder strict is dan ===, dat is bijvoorbeeld in JS net zo. Mijn punt is dat zelfs JavaScript, wat een redelijke puinzooi is (net zoals PHP niet gedesigned maar een beetje in elkaar geflanst) niet zo dom is om 100 == "100xyz" naar "true" te resolven.

Het is slechts een voorbeeld van een designed van een taal die veel van dit soort rare 'shortcuts' ingebouwd heeft. Shortcuts die 1 op de 10 keer misschien een paar karakters code schelen maar de andere 9 van de 10 keer gewoon onbedoeld zijn en dus vaak bugs veroorzaken.

Python is wat dat betreft gewoon simpelweg een betere taal dan PHP is en ooit zal zijn (vanwege de legacy): het probeert altijd zo consistent mogelijk te zijn juist omdat Guido van Rossum als echte developer snapt dat je met dit soort 'geintjes' je vooral je eigen ruiten ingooit op de lange termijn.

De reden dat PHP vroeger zo populair was, is simpelweg dat het enorn simpel was om even een dynamische pagina in elkaar te zetten. PHP was beschikbaar precies op het juiste moment. De reden dat het nu nog veel gebruikt wordt is gewoon legacy: er is tonnen met oude PHP code en een heleboel PHP devs die geen zin hebben iets anders te leren. Dit terwijl er voor nieuwe projecten gewoon prima alternatieven zijn in alle maintream talen die vaak nog eens een stuk performanter zijn ook.

Nu heeft het bijzonder weinig zin hierover lang te gaan discussieren met een PHP dev is mijn ervaring dus dat ga ik ook zeker niet doen. Ik gaf slechts antwoord op de vraag waarom PHP bij niet PHPers over het algemeen geen goeie reputatie heeft.

[NMe]

gekkie schreef op dinsdag 25 augustus 2015 @ 23:18:
[...]

By de weg .. dit is False .. want beide string .. maar dat wist je natuurlijk zelf ook al .. want het is gedocumenteerd in een prachtige dikke vette tabel

My bad. Wist ik uiteraard wel, maar ik schreef het verkeerd uit in mijn post, wat mijn punt inderdaad niet ten goede komt.

Hydra schreef op woensdag 26 augustus 2015 @ 08:52:
[...]

Je mist het punt. Ik weet best dat == minder strict is dan ===, dat is bijvoorbeeld in JS net zo. Mijn punt is dat zelfs JavaScript, wat een redelijke puinzooi is (net zoals PHP niet gedesigned maar een beetje in elkaar geflanst) niet zo dom is om 100 == "100xyz" naar "true" te resolven.

Ik mis het punt niet: ik zeg dat het een designkeuze is die zelfs tot op zekere hoogte nog wel te begrijpen valt. Ik ben er ook geen groot fan van, maar ik kan me wel wat situaties bedenken waar het voor beginnende/onervaren programmeurs (en dat was toch hun doelgroep in den beginne) fijn is dat strings op semi-intelligente wijze geparset worden tot integer waar vergelijking met een integer relevant is.

Python is wat dat betreft gewoon simpelweg een betere taal dan PHP is en ooit zal zijn (vanwege de legacy): het probeert altijd zo consistent mogelijk te zijn juist omdat Guido van Rossum als echte developer snapt dat je met dit soort 'geintjes' je vooral je eigen ruiten ingooit op de lange termijn.

Het lijkt me sterk dat de PHP-devvers diezelfde realisatie niet hebben, maar die zitten met het simpele probleem dat wanneer ze backwards compatibility breken, een van de belangrijke redenen waarom mensen nog PHP kiezen wegvalt.

De reden dat PHP vroeger zo populair was, is simpelweg dat het enorn simpel was om even een dynamische pagina in elkaar te zetten. PHP was beschikbaar precies op het juiste moment. De reden dat het nu nog veel gebruikt wordt is gewoon legacy: er is tonnen met oude PHP code en een heleboel PHP devs die geen zin hebben iets anders te leren. Dit terwijl er voor nieuwe projecten gewoon prima alternatieven zijn in alle maintream talen die vaak nog eens een stuk performanter zijn ook.

Ook hier ga je ietwat kort door de bocht. PHP wordt echt niet alleen nog gebruikt door mensen die vastgeankerd zijn in hun gewoontes. Het bedrijf waar ik werk is onder andere PHP gaan gebruiken door de brede support op webservers wereldwijd die je bij ASP.NET bijvoorbeeld niet hebt. Het performanceargument is ook weinig steekhoudend omdat je met wat externe tooling (die ook heel breed overal wordt toegepast) de performance voor alles behalve de héle grote/complexe sites ook prima kan houden.

Nu heeft het bijzonder weinig zin hierover lang te gaan discussieren met een PHP dev is mijn ervaring dus dat ga ik ook zeker niet doen. Ik gaf slechts antwoord op de vraag waarom PHP bij niet PHPers over het algemeen geen goeie reputatie heeft.

Het jammere is wel dat een groot deel van die reputatie niet helemaal terecht meer is. Natuurlijk is er van alles mis met PHP, maar zo erg als veel niet-PHP-developers het soms maken terwijl ze de taal al jaren niet (of zelfs überhaupt niet) gebruikt hebben is wel een beetje jammer. Waarmee ik overigens niet zeg dat jij dat doet, gewoon een algemene opmerking naar aanleiding van jouw algemene opmerking.

[Verwijderd]

Als je begint aan web development. En je wil front & backend doen voor o.a. leuke web apps. Dan kom je toch al gauw uit op NodeJS omdat je gewoon 1 taal hoeft te leren.
Daarnaast nodigt NodeJS meer uit op een samensmelting van front + back.
En Javascript is op dit moment hevig aan het evolueren met o.a. Ecmascript 6. Er is zelfs al een OS gemaakt dat Javascript als shell heeft. https://node-os.com/

Javascript lijkt zo snel te evolueren dat het probeert in elk gaatje toe te willen slaan. Zelfs op Microcontrollers.
Javascript heeft net als PHP last van ontwerp fouten uit het verleden welke gewoon bad practises zijn. Deze moet je vermijden, maar ze zijn wel aanwezig helaas.

De V8 VM is volgens mij sneller als een Ruby VM of Python VM en zal daar ook grote stukken kunnen afpakken op dat terrein. En zal niet alleen maar gebruikt worden als backend.

Waarom ik NodeJS zie groeien tegenover PHP is, Javascript is toegankelijker dan PHP en veel front end mensen kunnen het al, als ze naar de backend groeien is dat een kleine stap.

Wat biedt PHP nou "meer" dan de V8 Javascript engine doet + een eventloop samen genaamd NodeJS. Ik zie alleen maar voordelen voor Javascript tegenover PHP.
Hoor graag van mensen die het anders zien. En ja ik snap dat heel veel oude projecten allemaal nog gebaseerd zijn op PHP en dat je dat niet zomaar kan omzetten.

Maar waarom zou iemand die nieuw is rondom Backend zonder afhankelijk te zijn van oude PHP code zich nog storten op PHP?

[NMe]

Verwijderd schreef op woensdag 26 augustus 2015 @ 21:42:
Waarom ik NodeJS zie groeien tegenover PHP is, Javascript is toegankelijker dan PHP en veel front end mensen kunnen het al, als ze naar de backend groeien is dat een kleine stap.

Wat je voor het gemak even vergeet is dat heel veel mensen moeite hebben met het objectmodel van Javascript. Die prototyping-denkwijze klikt bij lang niet iedereen even goed. Ik had er zelf een hele tijd voor nodig (en ben nog steeds geen ster in Javascript) en veel van mijn collega's met een backender-achtergrond hadden dat ook.

Het topic is overigens wat er mis is met PHP, niet wat er goed is aan Javascript/NodeJS.

[aex351]

Wat is er zo slecht aan PHP? Ik denk dat het gebruik van de taal zich geëvolueerd heeft dat niet in lijn ligt met hoe de bedenker het ziet. In PHP worden bijvoorbeeld complete frameworks geschreven met zware logica. De opzet was dat ontwikkelaars in C modules schreven voor de zware logica en dat PHP de in- en output afhandelt. Maar omdat PHP laagdrempelig is en ook de mogelijkheden heeft wordt dit wel in PHP gedaan. Door dit verschil wordt een situatie van ontevredenheid gecreëerd.

Voor mij enkele hoofdredenen: PHP mist consistentie. Het is een mengelmoes qua stijlen. En PHP mist goed leiderschap, het is teveel polderpolitiek en daardoor weinig vooruitgang. Met PHP7 zitten er echter 'eindelijk' wat mooie veranderingen aan te komen.

[Verwijderd]

NMe schreef op woensdag 26 augustus 2015 @ 21:55:
[...]

Wat je voor het gemak even vergeet is dat heel veel mensen moeite hebben met het objectmodel van Javascript. Die prototyping-denkwijze klikt bij lang niet iedereen even goed. Ik had er zelf een hele tijd voor nodig (en ben nog steeds geen ster in Javascript) en veel van mijn collega's met een backender-achtergrond hadden dat ook.

Het topic is overigens wat er mis is met PHP, niet wat er goed is aan Javascript/NodeJS.

Met Ecmascript 6 is er nu de mogelijkheid om op andere manieren te programmeren dan prototype based. Gewoon met classes. Waardoor javascript wat meer zoals de conventionele talen te gebruiken is.
Echter had ik het meer van. Als je begint, en dus geen PHP achtergrond hebt lijkt het mij persoonlijker makkelijk om Javascript te leren vanwege front/back end combinatie.

Tevens zie je gewoon dat veel nieuwe functionaliteiten of veel gebruikte frameworks die op andere talen draaien soort van "gekopieerd" worden naar PHP. Niks ernstigs hoor, ik denk dat het juist goed is.
Echter wat mij opvalt is dat het meer is van andere talen richting PHP en niet andersom. Dit komt bij mij over als dat de actieve development bij de andere talen ligt.

PHP zal nog lang blijven, en je ziet dat ze gewoon bij blijven met de nieuwste trends die bij andere talen opkomen. Bepaalde soort frameworks en ideeën komen uiteindelijk wel weer bij PHP. En straks als PHP7 uitkomt kan PHP weer goed laten bijtrekken. Voordeel van PHP en de allergrootste is dat gewoon veel oude codebase PHP is en blijft. Maar nieuwe startups / nieuwe projecten vanaf de grond af aan zie je niet meer ontworpen worden in PHP.
Denk dat er helemaal geen zorgen moet zijn dat PHP verdwijnt. Het is gewoon een grote reus die iets minder snel kan manoeuvreren zoals de kleinere talen. Maar hij blijft groot. Maar gaat met de tijd heeeeel langzaam krimpen.

[Siebsel]

Maar nieuwe startups / nieuwe projecten vanaf de grond af aan zie je niet meer ontworpen worden in PHP.

Wow, dat is wel een heel sterke (en volgens mij ook enorm onjuiste) aanname.

[PatrickH89]

Siebsel schreef op donderdag 27 augustus 2015 @ 09:30:
[...]


Wow, dat is wel een heel sterke (en volgens mij ook enorm onjuiste) aanname.

Dat weet ik wel zeker. De PHP community is nog steeds behoorlijk sterk en dat zijn zeker niet alleen mensen van een bedenkelijk niveau. Veel frameworks zijn gewoon up-to-speed vergeleken met vooraanstaande frameworks in andere talen en er is dan ook weinig mis met het kiezen van PHP als je een start-up bent.

[HansvDr]

Uiteindelijk gaat het er natuurlijk om dat je iets kunt maken waar je klant tevreden mee is.

Of dat nu in PHP, NodeJS, Java, ASP, ASP.Net of wat dan ook gemaakt wordt is voor de klant niet zo belangrijk.

Hier doen we in elk geval van alles door elkaar, PHP, Classic ASP, ASP.Net . Soms vanwege bestaande code, soms omdat het snel en simpel moet, soms omdat we op dat moment de omgeving kiezen waar de ontwikkelaar zich het fijnst in voelt.

Uiteindelijk moeten wij HTML / Js opleveren waar de klant tevreden mee is, de backend is voor de klant niet zo belangrijk.

[DexterDee]

Nog zo'n leuke gotcha in PHP, scoping van variabelen:

PHP:

<?php
$array = [1,2,3];

foreach( $array as &$item ) { } 
print_r( $array ); 

foreach( $array as $item ) { } 
print_r( $array );

De uitkomst van dit script is op z'n zachtst gezegd contra-intuïtief:

code:

Array
(
    [0] => 1
    [1] => 2
    [2] => 3
)
Array
(
    [0] => 1
    [1] => 2
    [2] => 2
)

[HuHu]

DexterDee schreef op donderdag 27 augustus 2015 @ 11:51:
Nog zo'n leuke gotcha in PHP, scoping van variabelen:

PHP:

<?php
$array = [1,2,3];

foreach( $array as &$item ) { } 
print_r( $array ); 

foreach( $array as $item ) { } 
print_r( $array );

De uitkomst van dit script is op z'n zachtst gezegd contra-intuïtief:

code:

Array
(
    \[0] => 1
    \[1] => 2
    \[2] => 3
)
Array
(
    \[0] => 1
    \[1] => 2
    \[2] => 2
)

Ja heel leuk. Maar ik zie geen enkele reden waarom iemand in de praktijk dit soort code zou willen schrijven.

Theoretisch wellicht niet zuiver of onverwacht. In de dagelijkse praktijk totaal geen probleem.

[NMe]

HuHu schreef op donderdag 27 augustus 2015 @ 12:24:
[...]

Ja heel leuk. Maar ik zie geen enkele reden waarom iemand in de praktijk dit soort code zou willen schrijven.

Heel vreemd is het niet om eerst op een bepaalde manier door je array heen te lopen en later nog eens op een andere manier. Letterlijk op deze manier ga je het niet schrijven nee, maar ik zou niet kunnen uitsluiten dat ik hier zelf tegenaan zou lopen...

[DexterDee]

HuHu schreef op donderdag 27 augustus 2015 @ 12:24:
Ja heel leuk. Maar ik zie geen enkele reden waarom iemand in de praktijk dit soort code zou willen schrijven.

Naast dat ik het in de praktijk wel eens ben tegengekomen, is deze constructie zeker niet zo raar.

Door te itereren op een pass-by-reference variabele kun je het iterated item meteen veranderen zonder deze eerst weer terug op te zoeken. Het scheelt ook een héél klein beetje in performance omdat PHP geen variabele hoeft te kopiëren. Als je vervolgens in een tweede foreach dezelfde iterator variabele naam gebruikt (ook op een andere array overigens), dan loop je al tegen deze problemen aan.

[gekkie]

DexterDee schreef op donderdag 27 augustus 2015 @ 11:51:
Nog zo'n leuke gotcha in PHP, scoping van variabelen:

PHP:

<?php
$array = [1,2,3];

foreach( $array as &$item ) { } 
print_r( $array ); 

foreach( $array as $item ) { } 
print_r( $array );

De uitkomst van dit script is op z'n zachtst gezegd contra-intuïtief:

code:

Array
(
    \[0] => 1
    \[1] => 2
    \[2] => 3
)
Array
(
    \[0] => 1
    \[1] => 2
    \[2] => 2
)

Heuh .. en why the fsck doet:

PHP:

<?php
$array = [1,2,3];

foreach( $array as &$item ) { } 
print_r( $array ); 

foreach( $array as $itempje ) { } 
print_r( $array );
?>
 

Het dan wel goed.
Ding doet dus niks met $array maar iets met $item ?!?
Kan nergens zo 123 vinden wat het nou doet en waarom het doet wat het doet.

[RayNbow]

gekkie schreef op donderdag 27 augustus 2015 @ 14:36:
[...]


Heuh .. en why the fsck doet:

PHP:

<?php
$array = [1,2,3];

foreach( $array as &$item ) { } 
print_r( $array ); 

foreach( $array as $itempje ) { } 
print_r( $array );
?>
 

Het dan wel goed.
Ding doet dus niks met $array maar iets met $item ?!?
Kan nergens zo 123 vinden wat het nou doet en waarom het doet wat het doet.

Answer to "PHP Pass by reference in foreach"

In dit geval zijn er drie dingen die voor dit gedrag zorgen: mutability, references en scope.

[gekkie]

RayNbow schreef op donderdag 27 augustus 2015 @ 14:59:
[...]

Answer to "PHP Pass by reference in foreach"

In dit geval zijn er drie dingen die voor dit gedrag zorgen: mutability, references en scope.

Thanks ..

$a[1] will become a reference variable and $a[0] will become a normal variable (Since no one else is pointing to $a[0] it is converted to normal variable. PHP is smart enough to make it a normal variable when no one else is pointing towards it)

It clearly outsmarted me there

In combinatie met:

Warning:
Reference of a $value and the last array element remain even after the foreach loop. It is recommended to destroy it by unset().

So much for scoping, en wordt natuurlijk niet gefixt want we moeten backwards compatible zijn.
Valt me dan nog mee dat er geen &real is die wel automagisch de unset doet.

[ Voor 22% gewijzigd door gekkie op 27-08-2015 15:14 ]

[GrooV]

HansvDr schreef op donderdag 27 augustus 2015 @ 11:34:
Uiteindelijk gaat het er natuurlijk om dat je iets kunt maken waar je klant tevreden mee is.

Of dat nu in PHP, NodeJS, Java, ASP, ASP.Net of wat dan ook gemaakt wordt is voor de klant niet zo belangrijk.

Hier doen we in elk geval van alles door elkaar, PHP, Classic ASP, ASP.Net . Soms vanwege bestaande code, soms omdat het snel en simpel moet, soms omdat we op dat moment de omgeving kiezen waar de ontwikkelaar zich het fijnst in voelt.

Uiteindelijk moeten wij HTML / Js opleveren waar de klant tevreden mee is, de backend is voor de klant niet zo belangrijk.

Tja als jij een developer hebt die alles in Go doet en hij is net 4 weken op vakantie en de rest van je toko snapt er niks van en er moet toch iets opgelost worden, is de klant dan nog zo tevreden?

Ik zeg niet dat je alles moet locken op 1 taal/framework maar totale willekeur lijkt mij ook niet goed

[Gomez12]

Verwijderd schreef op donderdag 27 augustus 2015 @ 08:44:
[...]
Maar nieuwe startups / nieuwe projecten vanaf de grond af aan zie je niet meer ontworpen worden in PHP.

Dit is gewoon selectieve perceptie. Als je objectief gaat kijken dan zou je vanalles opgestart zien worden overal in (ook php).

Leuk voorbeeldje is bijv dat ik laatst een self-hosted alternatief zocht voor statuspage.io.
Dan zie ik een cachethq voorbij komen, ziet er perfect uit net wat ik nodig heb, alleen heb ik geen php instantie draaien met laravel / composer etc en er ook geen behoefte aan (we hebben wel een php draaien, maar op 1 domein etc lang verhaal kort : Het daarop installeren zou veel tijd kosten)

Oftewel ik denk : Iemand zal er toch wel een alternatief voor gemaakt hebben in js of .net of voor nodejs of ... iets anders. Maar ik ben daarin momenteel nog zoekende en zit te overwegen om iemand het hier intern gewoon in 3 dagen te laten maken (zo ingewikkeld is het nou ook weer niet)

Maar het is wmb wel een mooi iets wat nog steeds enkel in php gelanceerd wordt.

Of kijk naar een FB die zelfs een eigen php-versie maakt, die gaan echt nieuwe projecten ook wel in die php-versie doen.

[EddoH]

GrooV schreef op donderdag 27 augustus 2015 @ 18:10:
[...]

Tja als jij een developer hebt die alles in Go doet en hij is net 4 weken op vakantie en de rest van je toko snapt er niks van en er moet toch iets opgelost worden, is de klant dan nog zo tevreden?

Ik zeg niet dat je alles moet locken op 1 taal/framework maar totale willekeur lijkt mij ook niet goed

Totale willekeur natuurlijk niet, maar bij ons wordt er wel bijvoorbeeld wel verwacht dat als de nood aan de man is je ook kan bijspringen in een voor jou onbekende taal. Desnoods lees je je een dag in. IMHO is een programmeur iemand die alle talen zou moeten kunnen oppakken zonder al te veel moeite. Natuurlijk zul je beter en vloeiender zijn in een taal waar je ruime ervaring mee hebt, maar ik zou de kriebels krijgen als ik 5 jaar lang met 1 taal bezig ben...

[HansvDr]

GrooV schreef op donderdag 27 augustus 2015 @ 18:10:
[...]

Tja als jij een developer hebt die alles in Go doet en hij is net 4 weken op vakantie en de rest van je toko snapt er niks van en er moet toch iets opgelost worden, is de klant dan nog zo tevreden?

Ik zeg niet dat je alles moet locken op 1 taal/framework maar totale willekeur lijkt mij ook niet goed

Totale willekeur met een taal,of drie vier valt wel mee. De meeste ontwikkelaars kunnen bij ons met meerdere uit de voeten.

En bij bestaande systemen heb je nu eenmaal niet altijd de keuze. De klant wil graag een werkend systeem, dat staat voorop bij ons, niet de taal.

[GrooV]

Ik bedoel meer dat ik het raar vind dat de keuze bij de dev ligt. Dus als Jantje iets maakt is het in PHP en als Pietje het doet is het in JavaScript/Node

[Caelorum]

GrooV schreef op donderdag 27 augustus 2015 @ 19:11:
Ik bedoel meer dat ik het raar vind dat de keuze bij de dev ligt. Dus als Jantje iets maakt is het in PHP en als Pietje het doet is het in JavaScript/Node

Ik mag hopen dat de keuze altijd bij een dev ligt. Ok, misschien eentje die ook het grote plaatje kan overzien, maar alsnog iemand met de kennis om te kunnen beoordelen wat handig is.
Zelf doe ik overigens ook van alles en nog wat. Op het werk dan maar in twee 'talen' (vb.net en c#), maar thuis doe ik er ook nog js en c++ bij en als het nodig is java. Mij persoonlijk boeit de taal niet zo heel veel, als het maar effectief is. Zelf houd ik namelijk nog steeds niet van programmeren, wel van oplossingen maken voor mensen. (en ja, dat zie je ook in de code terug. Geen zandFactoryProducer of iets dergelijks ^^)
Elke programmeur zou zonder moeite moeten kunnen overstappen op andere talen. Inderdaad zoals al gezegd hoef je niet perfect kennis te hebben van een framework of taal om de meeste dingen te kunnen doen in een bestaand project.

[ Voor 11% gewijzigd door Caelorum op 27-08-2015 21:25 ]

[GrooV]

Een dev bepaalt niet de keuze maar je pakt de juiste taal voor de job. Dus als je een ios app wil een jantje kan alleen php dan ga je dat in PHP doen?

[gekkie]

GrooV schreef op vrijdag 28 augustus 2015 @ 00:26:
Een dev bepaalt niet de keuze maar je pakt de juiste taal voor de job. Dus als je een ios app wil een jantje kan alleen php dan ga je dat in PHP doen?

En wie bepaald dan wat de juiste taal is voor de job ?
De grote almachtige door een uiting van het lot ?

[Gomez12]

EddoH schreef op donderdag 27 augustus 2015 @ 18:43:
[...]
Totale willekeur natuurlijk niet, maar bij ons wordt er wel bijvoorbeeld wel verwacht dat als de nood aan de man is je ook kan bijspringen in een voor jou onbekende taal. Desnoods lees je je een dag in.

Onbekende taal zit dan bij jullie uiteraard nog wel binnen een bepaalde bandbreedte waardoor je moeilijk kan spreken van een echt onbekende taal.

Als ik echt een tik van de molen zou krijgen en zou besluiten om een complete http-server + script taal in brainfuck te bouwen (of om het iets simpeler te houden in assembler) dan ga jij of je collega's echt niet met een dagje inlezen er zijn...

En dat geldt in meer of mindere ook nog binnen dezelfde programmeertaal, ik ken genoeg projecten waar je met 1 dagje inlezen je alleen iets mag veranderen als het bedrijf / project daadwerkelijk op vandaag omvallen staat, want de kans is zo ongeveer 100% aanwezig dat jouw code 50x zoveel werk gaat opleveren vanwege niet houden aan conventies en dus nakijken en fixen en anders testen aan de achterkant anders.

Als ik naar mezelf kijk, ik beweer (bijna) altijd dat ik een nieuwe taal binnen 2 dagen kan gebruiken en erin productief kan zijn (in meerder of mindere mate). Mits het een nieuw project betreft.
Bestaande project kan ik nooit uitspraken over doen, omdat ik niet weet of het probleem 7-laags diep genest zit waardoor ik naast de taal ook nog eens de exacte nesting / dependencies van dat project mag gaan uitvogelen.

[EddoH]

Gomez12 schreef op vrijdag 28 augustus 2015 @ 00:59:
[...]

Onbekende taal zit dan bij jullie uiteraard nog wel binnen een bepaalde bandbreedte waardoor je moeilijk kan spreken van een echt onbekende taal.

Als ik echt een tik van de molen zou krijgen en zou besluiten om een complete http-server + script taal in brainfuck te bouwen (of om het iets simpeler te houden in assembler) dan ga jij of je collega's echt niet met een dagje inlezen er zijn...

Brainfuck en Assembler natuurlijk niet, maar dat lijtk me logisch in de context van dit topic. Wel C/C++/Java/Js/HTML/Python/Bash/C#/PHP en hun verschillende frameworks.

En je kunt natuurlijk altijd een situatie bedenken die inderdaad niemand zal begrijpen, maar mijn opmerking ging erover dat hoewel er verschillende talen zullen worden gebruikt binnen een bedrijf, je werknemers moet hebben die dat ook zonder al te veel moeite kunnen oppikken. 1 a 2 talen gebruiken omdat anders de rest het niet snapt is niet de beste argumentatie voor het gebruiken van juist die 1 a 2 talen, is eigenlijk wat ik wil zeggen. Dan heb je de verkeerde mensen aangenomen.

[Lethalis]

EddoH schreef op vrijdag 28 augustus 2015 @ 09:06:
[...]
En je kunt natuurlijk altijd een situatie bedenken die inderdaad niemand zal begrijpen, maar mijn opmerking ging erover dat hoewel er verschillende talen zullen worden gebruikt binnen een bedrijf, je werknemers moet hebben die dat ook zonder al te veel moeite kunnen oppikken. 1 a 2 talen gebruiken omdat anders de rest het niet snapt is niet de beste argumentatie voor het gebruiken van juist die 1 a 2 talen, is eigenlijk wat ik wil zeggen. Dan heb je de verkeerde mensen aangenomen.

Dan ga jij ervan uit dat je mensen alleen maar aanneemt op basis van hun technische kennis en vaardigheden. Genoeg programmeurs die hun meerwaarde halen uit hun branchekennis en daardoor heel goed weten wat er gemaakt moet worden (versus hoe).

En dat is vaak waardevoller dan iemand die in 5 talen kan programmeren.

Dus is het helemaal niet gek om te standaardiseren op bepaalde talen en technieken, zodat je in 1 team kunt samenwerken met deze mensen. Ik werk zelf elke dag samen met zulke programmeurs Vaak help ik ze met technische vraagstukken, en ik vraag weer vaak wat ik nou precies moet maken (want tsja, ik ben een techneut die helaas weinig specifieke branchekennis heeft).

Zo heb ik aan een boekhoudpakket gewerkt zonder verstand van boekhouden te hebben. Dat is eigenlijk niet handig, en dan ben je heel blij dat collega X die eigenlijk alleen maar in VB kan programmeren er wel degelijk veel verstand van heeft.

Dan kun je wel ineens alles in een andere taal gaan programmeren, maar dan raak je dus de productiviteit van die collega kwijt die juist zo essentieel voor het product is.

In de praktijk zie je dan wel dat ik alles er omheen (libraries etc) al richting C# push samen met een andere collega, maar dat de core functionaliteit VB.NET blijft. Gelukkig kun je beide talen prima in 1 solution gebruiken en de VB.NET programmeur kan prima onze libraries gebruiken zonder zich druk te maken over hoe ze nou precies werken.

[ Voor 8% gewijzigd door Lethalis op 28-08-2015 10:47 ]

[GrooV]

Ik bedoel meer dat als mensen alleen maar kiezen wat in hun eigen straatje ligt dat dan juist misschien NIET de juiste taal/framework gekozen wordt.

Als je alleen nieuwe projecten maakt kan dit minder erg zijn maar als er 5 jaar later onderhoud gepleegd moet worden dan kunnen sommige keuzes erg nadelig uitpakken. Stel je doet .NET development en je collega doet VB.net en de rest C#. Nu wil je upgraden naar ASP.NET vNext ivm xplat oid. Dan kan dat niet want daar zit geen VB.NET support in want die komt eind volgend jaar pas.

Wat ik probeerde te vertellen is als je een keuze met oogkleppen maakt (dev a kan alleen vb dus hij werkt in vb) dat het natuurlijk niet de beste keuzes zijn. Dan kan je beter 1-2 weken investeren in de dev op kennis te brengen. (desnoods trek je wat langer uit en kan hij alles wat er gebruikt wordt) Verder kan het ook niet praktisch zijn als je bijvoorbeeld je continuous delivery straat op Linux hebt draaien en iemand gaat in .NET ontwikkelen omdat hij niets anders weet.

Verder heb je nog kosten dilemma. Ga je iedereen een licentie voor Visual Studio of PHP/Webstorm geven of krijgen alleen de developers die .NET doen een VS licentie en de PHP'ers een PHPStorm licentie?

Een developer moet juist zo veel mogelijk talen kennen. Er wordt niet voor niks zo vaak geroepen, "Learn at least one new language every year". Of je alles door elkaar moet gebruiken is een ander verhaal.

Maar goed, we raken off topic

[raptorix]

Ik zal niet beweren dat PHP een slechte taal is, echter juist omdat je dingen "makkelijk" kan doen maakt het een gevaarlijke taal, veel mensen roepen dat PHP een geschikte taal voor beginners is, maar dat is flauwekul, een taal als c# of java is JUIST omdat het strict is een veel geschiktere taal.