Wat is er mis met PHP?

[Kajel]

Ja maar lieve jongens en meisjes, gaan we nu echt de vermeende tekortkomingen van Python gebruiken om de aandacht af te leiden van PHP? Je kunt zeggen wat je wil, maar je hoeft je over het algemeen tegenover anderen minder te schamen als je Python gebruikt, dan dat je PHP gebruikt. Je wordt al snel meer serieus genomen.
Het is niet voor niets dat Python een heel scala aan wetenschappelijke libraries en tools heeft en diep doorgedrongen is in Universiteiten en andere delen van de wetenschappelijke gemeenschap. Je hoort zelden iemand die voor zijn proefschrift aan de slag is gegaan met PHP.

Dan nog even het eeuwige "PHP draait tenminste overal en is lekker makkelijk" argument. Ik blijf erbij dat goedkope, shared, flut-hosting juist enorm bijdraagt aan het PHP-probleem. Een VPS is bijna even goedkoop, en dan weet je _wel_ waar je mee bezig bent. Als je liever gebruiksgemak hebt, kun je in veel gevallen (Python, Ruby, Java etc.) terecht bij diverse PaaS oplossingen als Heroku.

Wetenschapswereld gebruikt oa veel Python, R en Haskell, hipster startups gebruiken Ruby of Scala, Enterprise wereld gebruikt Java, Windows desktop applicatie bouwers gebruiken C# en .NET. Game-devs gebruiken C++. Web-scale bedrijven als Twitter, Google en Facebook gebruiken een combinatie van alle voorgaande talen, for each job a different tool, en daarnaast nog wat exotischere opties als Erlang.
En ja, een enkel bedrijf als Facebook gebruikt ook PHP nog, omdat het goedkoper is om allerlei tools eromheen te bouwen zoals HHVM, en zelfs de taal opnieuw uit te vinden, dan om een enorme code-base te herschrijven. Maar FB springt ook heus geen gat in de lucht van de briljantie van PHP, anders was hun hele backend daar ook wel in geschreven.

Wat blijft over? Kneuzen met Wordpress sites (80% van het internet), ja, zelfs als die sites tot de top 10 van het internet behoren. Daar doet de kneuzigheid niets aan af

[Wolfboy]

incaz schreef op zaterdag 22 maart 2014 @ 20:05:
Wolfboy, maar seriously, 8 spaties voor 1 tab? Dus de coding standard is halve tabs? En je def spam wordt zelfs door de editor hier waardeloos geformatteerd... dan kun je toch werkelijk niet met droge ogen beweren dat dat een goed idee is??

Ik kan daar echt met mijn verstand niet bij. Daarbij valt een niet-logische paramvolgorde toch ver in het niet.

De coding standaard is 4 spaties, geen tabs. Maar als je ze toch wil mixen zal je 8 spaties per tab moeten gebruiken, waarvan ik overigens meermaals gezegd heb dat het een slecht idee is.

Het was simpelweg een illustratie dat het mogelijk is in tegenstelling tot wat sommige mensen hier denken/zeggen.

[gekkie]

Wolfboy schreef op zaterdag 22 maart 2014 @ 20:23:
[...]
De coding standaard is 4 spaties, geen tabs. Maar als je ze toch wil mixen zal je 8 spaties per tab moeten gebruiken, waarvan ik overigens meermaals gezegd heb dat het een slecht idee is.

Het was simpelweg een illustratie dat het mogelijk is in tegenstelling tot wat sommige mensen hier denken/zeggen.

En deze potentiele inconsistentie met python3 er dus uit te halen, al zie je ook hier wel dat dat allemaal niet eenvoudig is en derhalve een eeuwigheid duurt voordat het gemeengoed is.

Opzich wordt er geloof ik ook wel getracht om wat inconsistenties uit php te krijgen, maarja ga er maar eens aan staan .... (en ze zijn fundamenteler en complexer van aard)

[incaz]

Kajel: het toont volgens mij vooral aan dat imago belangrijker is dan werkelijkheid. Python is cooler dan php, als je designkeuzes goed weet te verkopen worden ze geaccepteerd, en men gebruikt php dan ook vooral om te bewijzen dat je goed genoeg bent om erop neer te kijken.

En nee, ik zou php zeker niet willen kwalificeren als briljant. Alleen zijn de problemen van de taal voor mij niet van zo'n aard dat ik ze vaak tegenkom. Zoals al eerder gezegd: eigenlijk zelden zelfs.

Wolfboy: het ging er niet om dat het onmogelijk is... het ging erom dat het foutieve code kan opleveren. En geen beter voorbeeld dan je zelf hebt geillustreerd: 2 statements die zich op hetzelfde niveau bevinden worden verschillend geindenteerd en lijken dus tot verschillende scope te behoren, juist omdat je NIET het verschil kunt zien tussen een tab en een spatie tenzij je dat weer laat geven, maar het toont wel anders.

Je hebt dus whitespace die betekenis heeft, met als argument dat het misleidend is als dingen verkeerd worden weergeven... en vervolgens geef je iets waarbij de weergave nadrukkelijk misleidend is.

Dat slaat gewoon helemaal nergens op, echt niet.

[NMe]

Kajel schreef op zaterdag 22 maart 2014 @ 20:18:
Ja maar lieve jongens en meisjes, gaan we nu echt de vermeende tekortkomingen van Python gebruiken om de aandacht af te leiden van PHP? Je kunt zeggen wat je wil, maar je hoeft je over het algemeen tegenover anderen minder te schamen als je Python gebruikt, dan dat je PHP gebruikt. Je wordt al snel meer serieus genomen.

En jij wordt meer serieus genomen als je niet éérst zelf de discussie op een andere focus brengt (Kajel in "Wat is er mis met PHP?") en daarna de "lieve jongens en meisjes" aanspreken op het feit dat de discussie verlegd is. Ga dan ook in op de tegenargumenten die ik op jouw vorige post had in plaats van meningen als waarheid te verkondigen zoals je hier doet.

Ik verdien mijn brood met PHP-development. Ik word bij mijn weten doorgaans best serieus genomen en als dat niet zo is dan komt dat omdat ik onzin verkoop, niet omdat ik PHP-developer ben. Iemand afrekenen op de taal die hij gebruikt is kortzichtig en arrogant.

[RayNbow]

incaz schreef op zaterdag 22 maart 2014 @ 20:05:
maar seriously, 8 spaties voor 1 tab?

Historisch gezien werden tab-stops doorgaans op een veelvoud van 8 spaties geplaatst. Dit is ook de reden waarom o.a. CSS, Python en Haskell vrolijk tabs of tab-stops gelijkstellen aan 8 tekens.

(NB: In Haskell heeft iets als [7 spaties][tab] aan het begin van de regel de lengte van 8 spaties. Hier wordt een tab gezien als spring-naar-de-volgende-tabstop.)

Dus de coding standard is halve tabs?

De coding standaard staat los van hoe tab characters geinterpreteerd worden.

[.oisyn]

NMe schreef op zaterdag 22 maart 2014 @ 20:29:
en als dat niet zo is dan komt dat omdat ik onzin verkoop

^^^ true story

[Gomez12]

RayNbow schreef op zaterdag 22 maart 2014 @ 20:29:
[...]
De coding standaard staat los van hoe tab characters geinterpreteerd worden.

In alle talen behalve python heb je gelijk...

[gekkie]

incaz schreef op zaterdag 22 maart 2014 @ 20:28:
Je hebt dus whitespace die betekenis heeft, met als argument dat het misleidend is als dingen verkeerd worden weergeven... en vervolgens geef je iets waarbij de weergave nadrukkelijk misleidend is.

Dat slaat gewoon helemaal nergens op, echt niet.

Check .. gelukkig is dat dan bij python3 nu opgelost ...
Welke aardschokkende inconsistenties zijn er dan nog meer in vergelijking met de laatste PHP versie

(btw het kon al een warning of error laten zijn .. alleen was dit nog niet de default)

[ Voor 7% gewijzigd door gekkie op 22-03-2014 20:43 ]

[RayNbow]

Gomez12 schreef op zaterdag 22 maart 2014 @ 20:37:
[...]

In alle talen behalve python heb je gelijk...

En Haskell dan? Een taal waarin de layout ook belangrijk is?

[gekkie]

NMe schreef op zaterdag 22 maart 2014 @ 20:29:
[...]

Ik verdien mijn brood met PHP-development. Ik word bij mijn weten doorgaans best serieus genomen en als dat niet zo is dan komt dat omdat ik onzin verkoop, niet omdat ik PHP-developer ben. Iemand afrekenen op de taal die hij gebruikt is kortzichtig en arrogant.

Nogal mee eens ja .. enorm non argument ...

Echter .. stel ..
je zou opnieuw mogen beginnen met de code-base .. en je hebt ook enige ervaring met andere talen ..
zou je dan toch weer voor PHP kiezen en het goede en kwade voor lief nemen (till death do us part .. voor een vleugje romantiek .. )..

of liever een andere taal kiezen als fundament en daar verder in leren ...

[DexterDee]

PHP is verre van perfect, maar deze site is wel een must read voor alle PHP programmeurs:
http://www.phptherightway.com/

[gekkie]

Kajel schreef op zaterdag 22 maart 2014 @ 20:18:
Het is niet voor niets dat Python een heel scala aan wetenschappelijke libraries en tools heeft en diep doorgedrongen is in Universiteiten en andere delen van de wetenschappelijke gemeenschap. Je hoort zelden iemand die voor zijn proefschrift aan de slag is gegaan met PHP.

Ik denk dat andere talen zich inderdaad daar beter voor lenen en dat PHP toch voornamelijk web georienteerd is en blijft. Tevens zit er een berg legacy code in.

Maar om alles nu gelijk af te doen als "kneuzen" ... gooi je computer dan maar gelijk het raam uit ..
als je alleen al de gemiddelde legacy interfaces neemt waarmee de meeste systeem heden ten dagen nog steeds booten ... zijn dus allemaal kneuzen computers ... met allemaal kneuzen er achter ...
dus om nog maar eens te doen zoals ik vroeger deed toen ik nog klein was ...

wie dit leest is dus een kneus .. ja jij dus ook

[Gomez12]

gekkie schreef op zaterdag 22 maart 2014 @ 20:46:
[...]
Echter .. stel ..
je zou opnieuw mogen beginnen met de code-base .. en je hebt ook enige ervaring met andere talen ..
zou je dan toch weer voor PHP kiezen en het goede en kwade voor lief nemen (till death do us part .. voor een vleugje romantiek .. )..

of liever een andere taal kiezen als fundament en daar verder in leren ...

Let op dat deze vraag veel complexer is dan hij lijkt. Ik heb geen idee waar NMe werkt, maar als zijn bedrijf PHP doet dan kan hij dus gelijk al niet meer bij dat bedrijf werken en had hij hele andere collega's gehad.

Dit soort vragen zijn enkel zinvol voor ZZP'ers die in hun eentje iets uitgebreids neerzetten, voor de rest van de beroepsbevolking verandert er gelijk een hele hoop andere dingen ook.

[incaz]

gekkie schreef op zaterdag 22 maart 2014 @ 20:46:
[...]
je zou opnieuw mogen beginnen met de code-base .. en je hebt ook enige ervaring met andere talen ..
zou je dan toch weer voor PHP kiezen en het goede en kwade voor lief nemen (till death do us part .. voor een vleugje romantiek .. )..

of liever een andere taal kiezen als fundament en daar verder in leren ...

Interessante vraag en ik zou het niet weten. Ik weet zelfs niet of ik OO als paradigma zou willen houden, of meer functioneel zou gaan, of dat het misschien nog helemaal anders kan. En ik weet bv ook niet of je dan nog uitkomt bij mysql of juist documentstore nosql of nog andere storage. Het probleem is dat dergelijke beslissingen (net als de keuze van frameworks) vaak veel meer ervaring vereisen dan je hebt op het moment dat je de beslissing neemt.

[gekkie]

Gomez12 schreef op zaterdag 22 maart 2014 @ 20:58:
[...]

Let op dat deze vraag veel complexer is dan hij lijkt. Ik heb geen idee waar NMe werkt, maar als zijn bedrijf PHP doet dan kan hij dus gelijk al niet meer bij dat bedrijf werken en had hij hele andere collega's gehad.

Dit soort vragen zijn enkel zinvol voor ZZP'ers die in hun eentje iets uitgebreids neerzetten, voor de rest van de beroepsbevolking verandert er gelijk een hele hoop andere dingen ook.

Klopt .. maar stel je zou het zelf mogen beslissen ..

kortom .. wat hecht je het meeste aan PHP en zorgt er voornamelijk voor dat je er bij zou blijven

1) mooie handige geweldige fantastische taal
2) of nouja gewoon goed genoeg
2) ervaring ermee
3) veel code fragmenten beschikbaar op Inet
4) veel modules / frameworks beschikbaar
5) eigen legacy code
4) eis klant / werkgever
5) is er nog iets anders dan ?

[gekkie]

incaz schreef op zaterdag 22 maart 2014 @ 21:03:
[...]


Interessante vraag en ik zou het niet weten. Ik weet zelfs niet of ik OO als paradigma zou willen houden, of meer functioneel zou gaan, of dat het misschien nog helemaal anders kan. En ik weet bv ook niet of je dan nog uitkomt bij mysql of juist documentstore nosql of nog andere storage. Het probleem is dat dergelijke beslissingen (net als de keuze van frameworks) vaak veel meer ervaring vereisen dan je hebt op het moment dat je de beslissing neemt.

Klopt .. ben nu zelf over aan het gaan van perl naar python .. andere alternatief had PHP kunnen zijn.
Opzich kom ik een eind in PHP .. maar ben geen briljante PHP'er.

Maar ik vind python meer versatile .. en op de een of andere manier heb ik het idee dat PHP leuk is
voor stateless in een webserver. Maar om er nou meer event driven websocket dingen mee te gaan doen.

Daarnaast ook een deel van het argument van Kajel .. research projecten in Python.
Heb al eerder gebruikt gemaakt van bijvb openCV (opzich C maar met python bindings) voor beeldherkenning en dat werkte best leuk (al was dat vrij weinig python en veel openCV functies gebruiken)

Maar had ook gezien dat er wat language interpret research dingetjes waren ...

Kortom ik denk dat als ik dan toch wat nieuws moet/wil leren .. python me meer aan staat dan PHP.
(en ja de eerste keer python was met de tabs en spaces wel een ervaring )

[NMe]

gekkie schreef op zaterdag 22 maart 2014 @ 20:46:
[...]

Nogal mee eens ja .. enorm non argument ...

Echter .. stel ..
je zou opnieuw mogen beginnen met de code-base .. en je hebt ook enige ervaring met andere talen ..
zou je dan toch weer voor PHP kiezen en het goede en kwade voor lief nemen (till death do us part .. voor een vleugje romantiek .. )..

of liever een andere taal kiezen als fundament en daar verder in leren ...

Ik heb nooit gezegd dat ik begonnen ben met PHP. Toen ik leerde programmeren moest ik het doen met de Commodore64 en later met MSDOS. Los daarvan: ik weet dat ik een bekwaam programmeur ben en of ik dat nou laat zien door PHP te gebruiken of door iets met Java, Python, C# of wat dan ook te doen boeit niet. Ik heb toevallig een webdevelopmentbaan waarvoor ik met PHP werk maar je als programmeur limiteren tot één taal of omgeving is sowieso slecht, dus in mijn vrije tijd doe ik af en toe wat met andere talen.

.oisyn schreef op zaterdag 22 maart 2014 @ 20:33:
[...]

^^^ true story

I know, right?

[gekkie]

NMe schreef op zaterdag 22 maart 2014 @ 21:18:
[...]
Ik heb nooit gezegd dat ik begonnen ben met PHP.

Mooi ik ook niet

Toen ik leerde programmeren moest ik het doen met de Commodore64 en later met MSDOS. Los daarvan: ik weet dat ik een bekwaam programmeur ben en of ik dat nou laat zien door PHP te gebruiken of door iets met Java, Python, C# of wat dan ook te doen boeit niet. Ik heb toevallig een webdevelopmentbaan waarvoor ik met PHP werk maar je als programmeur limiteren tot één taal of omgeving is sowieso slecht, dus in mijn vrije tijd doe ik af en toe wat met andere talen.

Ah leuk peek'en en poke'en
En hee dat bekwaam / niet bekwaam kneuzen gedoe daar ging het mij niet om heh !

Maar meer of als jij er over ging ... en je zou van scratch moeten beginnen .. zou je die projecten dan nog in PHP uitvoeren .. of zou je wat anders voorstellen.

Kan bijvb zijn dat je zegt .. ja absoluut .. taal voldoet .. en alternatieven zijn niet veel beter ....
of .. ik zie voldoende verbeteringen in de taal worden doorgevoerd die binnen enige afzienbare tijd er voor zorgen dat dat wel het geval is .. dus gezien mijn ervaring blijf ik er dan toch liever bij ..

[NMe]

Ik zie, zeker bij het framework dat we nu gebruiken, geen enkele reden om PHP te droppen. Het performt voldoende en wanneer dat voor een groot project eens niet zo zou zijn biedt het framework ruimte om makkelijk op te schalen. We werken met een volledig OO systeem, namespaces, MVC, alle dingen die je in andere omgevingen ook kan gebruiken om goede code neer te zetten. Aan hoeveel van de eigenaardigheden van PHP je je blootstelt is wat dat betreft een kwestie van je goed indekken.

Afgezien van dat: ik zou zelfs als ik dat zou willen niet over kunnen stappen naar een andere taal, want het bedrijf waarvoor ik werk doet vrijwel alles in PHP. Het is een stuk makkelijker support leveren als alles wat je oplevert min of meer hetzelfde systeem gebruikt.

[incaz]

Overigens... ik heb niet altijd php gedaan. Ik heb in elk geval de basis in veel talen gehad (haskell tot visual basic.)

Python was voor mij echter gewoon geen taal waar ik mee uit de voeten kon, ook niet nadat ik er toch 2 jaar mee te maken heb gehad. Zoals ik ook nooit gewend ben geraakt aan de macs op de uni (waarvan iedereen zegt dat als je daar eenmaal mee werkt, je nooit meer anders wilt. Nou, ik dus wel )

Gekkie, toch is die vraag eigenlijk niet te beantwoorden. Want wat er is aan applicaties zou je niet meer op die manier bouwen omdat er nu zoveel meer beschikbaar is, maar dat hangt weer niet geheel op de taal. Zo zou de codebase op z'n minst herschreven worden met Symfony2, en een heel groot deel zou dan in keurige packages zitten. Maar dat is nu. Die dingen worden gebouwd as we speak. (Het is heel gaaf om te zien dat iets wat ik een half jaar geleden op de wishlist moest zetten nu is gefixt door het beschikbaar komen van goede packages - maar ze komen pas nu.)

Het zou ook dingen ter discussie stellen over de opslag (mogelijk geen sql), en die implicaties zijn misschien wel breder.

Maar ik zie nu, net zo min als NMe (en nee, ik werk daar niet), geen reden om het gebruik van php ter discussie te stellen. Afgezien van een incidentele 'je kunt niet alles hebben' kom ik in de praktijk betrekkelijk weinig fundamentele problemen tegen die opgelost zouden zijn met een andere taal.

[hydrargyrum]

Wow, PHP is hier een gevoelig onderwerp. Ik zie dat er duidelijke voor- en tegenstanders zijn. Ik vind zelf een van de grootste voordelen dat je niet gedwongen word om OOP te gebruiken, wat ik tegenwoordig redelijk vaak zie gebeuren(mocht iemand nog een goed artikel hebben waarom het zo superieur zou zijn, ik houd me aanbevolen). Veel van de downsides kan ik herkennen, maar ik denk dat het ook vaak het verhaal is van de spreekwoordelijke hond, en de even spreekwoordelijke stok: Je kan wel focussen op de eigenaardigheden van een taal, maar wie heeft nou niet meer dan 1 scherm, waarbij hij op dat tweede of derde scherm gewoon php.net kan, met naar mijn mening veel nuttige info. Ik kan snappen dat het een verwarrende taal is in het begin, maar dat het behandeld word alsof het Brainfuck is vind ik toch een beetje te ver gaan.

[gekkie]

NMe schreef op zaterdag 22 maart 2014 @ 21:32:
Ik zie, zeker bij het framework dat we nu gebruiken, geen enkele reden om PHP te droppen. Het performt voldoende en wanneer dat voor een groot project eens niet zo zou zijn biedt het framework ruimte om makkelijk op te schalen. We werken met een volledig OO systeem, namespaces, MVC, alle dingen die je in andere omgevingen ook kan gebruiken om goede code neer te zetten. Aan hoeveel van de eigenaardigheden van PHP je je blootstelt is wat dat betreft een kwestie van je goed indekken.

Afgezien van dat: ik zou zelfs als ik dat zou willen niet over kunnen stappen naar een andere taal, want het bedrijf waarvoor ik werk doet vrijwel alles in PHP. Het is een stuk makkelijker support leveren als alles wat je oplevert min of meer hetzelfde systeem gebruikt.

Mjah dat is wat je wel vaker leest bij PHP frameworks ... dit zou dan "PHP done right" moeten zijn.

Eigenlijk een beetje javascript en DOM ... diverse frameworks om alle inconsitenties glad te strijken .. en hopelijk kunnen die dan van lieverlee allemaal weer afgebouwd worden. (zodat je dan bijvb uiteindelijk van jQuery 1.x naar 2.x kan en een groot deel van het framework eruit kunt mikken).

En het is dus inderdaad een mix van de dingen die ik al wel dacht ... opdrachtgever/werkgever .. legacy code in projecten .. of reusable eigen framework en fragmenten .. en er valt daardoor mee te leven

Achja in het geheel is dat niet te voorkomen .. zie ook python .. opzich een filosofie erachter maar ook dan kom je bij dat soort projecten toch nog dingen in de uitvoering tegen die niet helemaal zo blijken uit te pakken als gewenst.
Enige is dat ik bij PHP niet het gevoel heb dat er heel veel schot in zit .. mede doordat sommige zaken wel heel fundamenteel van aard zijn (basis syntax of de core functies raken) .. en dan ook nog soms 2 stappen voorwaarts 1 of 1,5 terug

[Y0ur1]

Ik ben begonnen met deze thread te lezen maar ben zo veel onwetendheid en napraterij van andere mensen tegenkomen dat ik op een gegeven moment maar ben gestopt. Waarom stoppen mensen hun energie/tijd in het bashen van een taal terwijl je ook gewoon toffe dingen kunt bouwen (in welke taal dan ook?). Ja PHP is crappy op een aantal punten, maar op heel veel punten ook niet, waaronder de enorme diversiteit in systemen, mensen, frameworks en libraries. PHP is een taal die zeker de laatste jaren volop in ontwikkeling is, een goed voorbeeld hiervan is alleen al HVVM en recent http://hacklang.org.

Een van de grootste voordelen van PHP is keuze en diversiteit. of je nou een full stack framework(Zend Framework, Symfony), losse libraries (AuraPHP, Symfony components) of een micro-framework (Silex, Slim, Flight) wilt, het is er allemaal. En dan heb ik het nog niet eens over standaard systeem als Wordpress, Drupal, Magento, Joomla (vreselijk systeem btw) etc.

It gets a job done in a maintainable way zeg ik altijd maar, en dat heeft PHP zeker weten bewezen. Uiteindelijk is een taal altijd maar een tool en is software maken een echt vak, iets dat de taal PHP ver overstijgt.

[Y0ur1]

hillbillie schreef op woensdag 19 maart 2014 @ 10:23:
Zolang je het SOLID principe hanteert, je klassen goed unittest, documentatie schrijft e.d. kan je wat mij betreft elke programmeertaal gebruiken.

Tuurlijk, php heeft soms zijn eigenaardigheden, maar noem mij eens een taal waar je dit niet in hebt... juist

Alle talen spelen leentjebuur bij concurrerende talen, zo vind ik PHP steeds meer op java lijken met de SPL toevoegingen.

Wat ik wel een heel groot voordeel van PHP tov andere talen vind, is dat er zo ontiegelijk veel opensource packages zijn te vinden en de frameworks/libraries zijn echt goed `mature`. Symfony2 en Doctrine zijn gewoon degelijk.

Precies, dit komt gewoon neer op het vakmanschap van software ontwikkelen dat je kunt toepassen in iedere taal, in sommige talen gaat dit makkelijk dan in andere, dat dan weer wel.

(Verschil programming in a language vs. programming into a language.)

[ Voor 4% gewijzigd door Y0ur1 op 22-03-2014 21:57 ]

[Gomez12]

incaz schreef op zaterdag 22 maart 2014 @ 21:35:
Maar ik zie nu, net zo min als NMe (en nee, ik werk daar niet), geen reden om het gebruik van php ter discussie te stellen. Afgezien van een incidentele 'je kunt niet alles hebben' kom ik in de praktijk betrekkelijk weinig fundamentele problemen tegen die opgelost zouden zijn met een andere taal.

De "probleempjes" van php (of welke taal dan ook) zijn dan ook enkel relevant voor de incidentele gebruiker.
Als ik het na lange tijd niet gebruiken weer eens moet oppakken dan erger ik me aan veel dingen, maar zit ik er 2 weken in dan werk ik gewoon blindelings om de inconsistenties heen.

Zo ongeveer hetzelfde als met python, compleet blank vind ik het gestoord dat whitespace relevant is (en dat er een verschil is tussen tabs en spaties) maar zit je er 2 weken in dan merk je daar niets meer van omdat je gewoon of a of b hebt gekozen en het wel best is.

gekkie schreef op zaterdag 22 maart 2014 @ 21:49:
[...]
Mjah dat is wat je wel vaker leest bij PHP frameworks ... dit zou dan "PHP done right" moeten zijn.

Ik denk dat dit ook totaal niet klopt, als jij als onbekende dat framework moet leren zal je vast en zeker ook weer allerlei onhebbelijkheden zien etc. etc.
Alleen als je langere tijd met dat framework werkt dan heb je geleerd eromheen te werken of het zelf aan te vullen etc. Waardoor je de inconsistenties niet meer ziet.

[gekkie]

incaz schreef op zaterdag 22 maart 2014 @ 21:35:
Overigens... ik heb niet altijd php gedaan. Ik heb in elk geval de basis in veel talen gehad (haskell tot visual basic.)

Python was voor mij echter gewoon geen taal waar ik mee uit de voeten kon, ook niet nadat ik er toch 2 jaar mee te maken heb gehad. Zoals ik ook nooit gewend ben geraakt aan de macs op de uni (waarvan iedereen zegt dat als je daar eenmaal mee werkt, je nooit meer anders wilt. Nou, ik dus wel )

Macs .. achja oppervlakkig gezien eenvoudiger ... vaak ook minder menutjes en opties te zien. Totdat ik eens wat eenvoudigs zou met wat bestandjes ... en na wat googlen bleek dat het opzich wel kon .. met ctrl-appeltje-alt-weet-ik-het-wat-wel-niet-meer ... moest gelijk weer denken aan het al oude Wordperfect 5.1 sjabloon op de functietoetsen

Minder troep op het scherm .. maar wel meer shortcuts onthouden .. mwaah laat maar.
Is het beter .. ach tis vooral anders ..

Maar 2 jaar met een wurgslang worstelen .. zal je ook niet in de koudekleren gaan zitten

Gekkie, toch is die vraag eigenlijk niet te beantwoorden. Want wat er is aan applicaties zou je niet meer op die manier bouwen omdat er nu zoveel meer beschikbaar is, maar dat hangt weer niet geheel op de taal. Zo zou de codebase op z'n minst herschreven worden met Symfony2, en een heel groot deel zou dan in keurige packages zitten. Maar dat is nu. Die dingen worden gebouwd as we speak. (Het is heel gaaf om te zien dat iets wat ik een half jaar geleden op de wishlist moest zetten nu is gefixt door het beschikbaar komen van goede packages - maar ze komen pas nu.)

Klopt .. uiteraard zou je het dan niet implementeren in PHP 1.0 ... maar zou je met alles wat nu beschikbaar is ... en hoe de taal zich ontwikkelt .. er weer fidusie in hebben .. of op z'n minst twijfelen.

Het zou ook dingen ter discussie stellen over de opslag (mogelijk geen sql), en die implicaties zijn misschien wel breder.

Check .. zit ik nu ook mee ... op FOSDEM het nodige rond gekeken bij zowel SQL (postgresql en de ontwikkelen en performance mbt JSON) en bijvb Couchebase / Mongo.

Heb al wel wat dingetjes gedaan met Mongo .. maar liep uiteindelijk toch tegen dingen aan die ik niet optimaal vond. (toch te veel zooi in de applicatie oplossen die eigenlijk ook prima met een fatsoenlijke query bij een betere structuur opgelost hadden kunnen worden.)

Maar ik zie nu, net zo min als NMe (en nee, ik werk daar niet), geen reden om het gebruik van php ter discussie te stellen. Afgezien van een incidentele 'je kunt niet alles hebben' kom ik in de praktijk betrekkelijk weinig fundamentele problemen tegen die opgelost zouden zijn met een andere taal.

Denk dat dat opzich bij de meesten zo is hoor .. en de redenen die ik zelf al had gegeven, geven denk ik in de meeste gevallen al vrij gauw de doorslag. Denk dan ook niet dat de populariteit van PHP heel erg hard zal zakken.

[gekkie]

Gomez12 schreef op zaterdag 22 maart 2014 @ 21:57:
[...]

De "probleempjes" van php (of welke taal dan ook) zijn dan ook enkel relevant voor de incidentele gebruiker.
Als ik het na lange tijd niet gebruiken weer eens moet oppakken dan erger ik me aan veel dingen, maar zit ik er 2 weken in dan werk ik gewoon blindelings om de inconsistenties heen.

Zo ongeveer hetzelfde als met python, compleet blank vind ik het gestoord dat whitespace relevant is (en dat er een verschil is tussen tabs en spaties) maar zit je er 2 weken in dan merk je daar niets meer van omdat je gewoon of a of b hebt gekozen en het wel best is.


[...]

Ik denk dat dit ook totaal niet klopt, als jij als onbekende dat framework moet leren zal je vast en zeker ook weer allerlei onhebbelijkheden zien etc. etc.
Alleen als je langere tijd met dat framework werkt dan heb je geleerd eromheen te werken of het zelf aan te vullen etc. Waardoor je de inconsistenties niet meer ziet.

Check, check .. double check

[Mercatres]

DexterDee schreef op zaterdag 22 maart 2014 @ 20:49:
PHP is verre van perfect, maar deze site is wel een must read voor alle PHP programmeurs:
http://www.phptherightway.com/

Inderdaad, ik gebruik die constant. En dat in combinatie met het Slim Framework van Josh Lockhart en overall tips van Phil Sturgeon kom je best ver om met PHP mooie, deftige applicaties te maken.

[Zoijar]

Y0ur1 schreef op zaterdag 22 maart 2014 @ 21:49:
Ik ben begonnen met deze thread te lezen maar ben zo veel onwetendheid en napraterij van andere mensen tegenkomen dat ik op een gegeven moment maar ben gestopt.

Ik vind het dan wel weer grappig dat er altijd mensen zijn die de onderbouwde kritiek van de developers met jaren en jaren ervaring die hier rondhangen op zo'n manier wegzetten; velen daarvan die ook zelfs nog jaren ervaring hebben met PHP

[PatrickH89]

Zoijar schreef op maandag 24 maart 2014 @ 00:23:
[...]

Ik vind het dan wel weer grappig dat er altijd mensen zijn die de onderbouwde kritiek van de developers met jaren en jaren ervaring die hier rondhangen op zo'n manier wegzetten; velen daarvan die ook zelfs nog jaren ervaring hebben met PHP

En toch vind ik het typisch dat zoveel developers met ervaring die hier al jaren en jaren rondhangen toch zo biased zijn dat ze niet meer op een intellectuele manier een mening kunnen vormen over PHP (waarschijnlijk door het imago van PHP).

[Caelorum]

Wie zegt dat ze biased zijn. Ik vind de meningen over het algemeen ook vrij goed onderbouwd en van redelijk niveau. Ze spreken echter meestal allemaal uit ervaring.

[Zoijar]

PatrickH89 schreef op maandag 24 maart 2014 @ 07:42:
En toch vind ik het typisch dat zoveel developers met ervaring die hier al jaren en jaren rondhangen toch zo biased zijn dat ze niet meer op een intellectuele manier een mening kunnen vormen over PHP (waarschijnlijk door het imago van PHP).

Wie is er nou biased? Dit is precies wat ik bedoelde hehe

[PatrickH89]

Zoijar schreef op maandag 24 maart 2014 @ 08:39:
[...]

Wie is er nou biased? Dit is precies wat ik bedoelde hehe

Ik zie hier toch een aantal posts van mensen die PHP grondig haten, dat mag dan misschien prima, maar getuigt meestal niet van een rationale goed onderbouwde mening. Er zijn in dit topic een paar reacties die goed onderbouwd zijn, maar het merendeel is ofwel PHP bashen, ofwel PHP verdedigen (zonder onderbouwing). Bias zul je bij mij niet vinden overigens, beetje snel geoordeeld. Overigens doelde ik met mijn post helemaal niet direct op jou.

[Y0ur1]

Zoijar schreef op maandag 24 maart 2014 @ 00:23:
[...]

Ik vind het dan wel weer grappig dat er altijd mensen zijn die de onderbouwde kritiek van de developers met jaren en jaren ervaring die hier rondhangen op zo'n manier wegzetten; velen daarvan die ook zelfs nog jaren ervaring hebben met PHP

Jaren en jaren ervaring is voor mij geen graadmeter of iemand echt weet waar hij/zij het over heeft, evenmin een betekenisloze titel als 'senior'.

Een ervaren developer kan in een taal als PHP prima dingen bouwen. En nee dat is misschien niet altijd de keuze van de developer zelf, er zijn zo veel andere factoren die daar in meewegen.

[NMe]

Zoijar schreef op maandag 24 maart 2014 @ 00:23:
[...]

Ik vind het dan wel weer grappig dat er altijd mensen zijn die de onderbouwde kritiek van de developers met jaren en jaren ervaring die hier rondhangen op zo'n manier wegzetten; velen daarvan die ook zelfs nog jaren ervaring hebben met PHP

Ook mensen met jaren ervaring overschatten vaak de ranzigheid van PHP.

[RayNbow]

Y0ur1 schreef op maandag 24 maart 2014 @ 14:01:
Een ervaren developer kan in een taal als PHP prima dingen bouwen.

Gaat de constructie "een ervaren developer kan in een taal als <X> prima dingen bouwen" op voor alleen PHP of is het ook van toepassing voor andere talen?

Bijv.:
[list]
• Een ervaren developer kan in een taal als Haskell prima dingen bouwen.
• Een ervaren developer kan in een taal als Prolog prima dingen bouwen.
• Een ervaren developer kan in een taal als Erlang prima dingen bouwen.
• Etc...


Zo ja, waarom? Zo nee, waarom niet?

[NMe]

PHP heeft natuurlijk wel een breder repertoire aan moderne tools dan de drie talen die jij noemt. Als je met die talen echter een aan de specs voldoend project kunt maken, dan zie ik niet waarom dat statement voor die talen niet zou gelden.

[Janoz]

Dat lijkt mij precies het punt van RayNbow. Die opmerking zegt helemaal niks.

[.oisyn]

Exact. Dus het feit dat het kan zegt niets over de mogelijke designflaws van de taal.

[steffex]

Ik ben nu al een jaar of 8 PHP developer, maar ik neig steeds meer richting andere talen.

De grootste ergernis is denk ik nog wel dat ik ondanks 8jaar ervaring ik nog met enige regelmaat terug moet naar de manual om uit te zoeken welke argumenten ook alweer eerst moeten of hoe de functie ook alweer heet.

Voor mij persoonlijk somt dit artikel wel aardig op wat ik vind dat er mis mee is:
http://me.veekun.com/blog...-a-fractal-of-bad-design/

[Y0ur1]

RayNbow schreef op maandag 24 maart 2014 @ 14:16:
[...]

Gaat de constructie "een ervaren developer kan in een taal als <X> prima dingen bouwen" op voor alleen PHP of is het ook van toepassing voor andere talen?

Bijv.:
[list]
• Een ervaren developer kan in een taal als Haskell prima dingen bouwen.
• Een ervaren developer kan in een taal als Prolog prima dingen bouwen.
• Een ervaren developer kan in een taal als Erlang prima dingen bouwen.
• Etc...


Zo ja, waarom? Zo nee, waarom niet?

Misschien was ik niet helemaal duidelijk, wat ik bedoelde te zeggen is dat ervaring hebben met software maken (welke taal dan ook) veel belangrijker is dan de taal zelf. Hoe meer andere talen je kunt hoe beter.

[Y0ur1]

steffex schreef op maandag 24 maart 2014 @ 14:34:
Ik ben nu al een jaar of 8 PHP developer, maar ik neig steeds meer richting andere talen.

De grootste ergernis is denk ik nog wel dat ik ondanks 8jaar ervaring ik nog met enige regelmaat terug moet naar de manual om uit te zoeken welke argumenten ook alweer eerst moeten of hoe de functie ook alweer heet.

Voor mij persoonlijk somt dit artikel wel aardig op wat ik vind dat er mis mee is:
http://me.veekun.com/blog...-a-fractal-of-bad-design/

Als dat je grootste ergernis is vind ik dat een compliment voor PHP. Volgorde van argumenten zijn nou eenmaal dingen die soms organisch ontstaan en die je niet zomaar aan kunt passen. Bovendien is dit wat een IDE gewoon voor je oplost.

Die post is inderdaad interessant, en het is zeker goed om ook als PHP developer dit soort dingen door te nemen. Wel vind ik dat er naast een aantal echte problemen met PHP (want die zijn er) ook veel punten over smaak gaan en dat PHP bepaalde dingen niet kan/anders doet dan andere talen.

[ Voor 18% gewijzigd door Y0ur1 op 24-03-2014 14:58 ]

[Wolfboy]

incaz schreef op zaterdag 22 maart 2014 @ 20:28:
Kajel: het toont volgens mij vooral aan dat imago belangrijker is dan werkelijkheid. Python is cooler dan php, als je designkeuzes goed weet te verkopen worden ze geaccepteerd, en men gebruikt php dan ook vooral om te bewijzen dat je goed genoeg bent om erop neer te kijken.

Cooler is niet relevant, het is vrij duidelijk zichtbaar dat er beter nagedacht is over het ontwerp van Python dan het ontwerp van PHP als je simpelweg naar de naamgevingen van de functies kijkt.

Ik heb vroeger heel wat PHP geschreven en daar had ik toch zeer regelmatig de PHP handleiding nodig om functies op te zoeken omdat het niet voorspelbaar was. Bij Python kan ik 90% van de tijd gewoon puur door logisch na te denken code schrijven en heb ik maar zelden documentatie nodig. Dat is echt puur een ontwerp punt.

Wolfboy: het ging er niet om dat het onmogelijk is... het ging erom dat het foutieve code kan opleveren. En geen beter voorbeeld dan je zelf hebt geillustreerd: 2 statements die zich op hetzelfde niveau bevinden worden verschillend geindenteerd en lijken dus tot verschillende scope te behoren, juist omdat je NIET het verschil kunt zien tussen een tab en een spatie tenzij je dat weer laat geven, maar het toont wel anders.

Klopt, daarom is die onvolkomenheid er in Python 3 helemaal uitgehaald, bij Python 2 kan je dat gedrag ook krijgen door "python -tt bestand.py" uit te voeren, dan is het mixen van tabs en spaties een error.

Maar zoals gezegd, met fatsoenlijke editors en werkwijzes heb je dit probleem gewoon niet, tenzij je random code van blogs gaat copy/pasten (wat sowieso een slecht idee is, daar zijn libraries voor) loop je eigenlijk nooit tegen dat probleem aan.

Vermoedelijk zien veel PHP'ers dit als een probleem omdat het bij PHP veel normaler is code te copy/pasten van het web en/of een script te downloaden en deze aan te passen. Aangezien development in de Python community veel meer library based is en je in principe eigenlijk nooit library download om deze zelf aan te passen (afgezien van het forken van een library wat nog weleens voorkomt) werkt dit gewoon heel anders en is het in de praktijk sowieso nooit een probleem.

Nu weet ik dat je bij PHP wel PEAR hebt maar het is heel wat anders dan de standaard werkwijze bij Python.

1. Maak een virtualenv aan
2. Begin met het maken van je project
3. Heb je requirements? (Django, Flask, Numpy, etc...), installeren met "pip install <librarynaam>"
4. Tijd om te delen/deployen? "pip freeze > requirements.txt"

En dan kan je bij de productieserver en/of andere developers gewoon dit doen:

1. Maak een virtualenv aan
2. git clone repository
3. pip install -r requirements

En je hebt het geheel werkend inclusief alle libraries.

Je hebt dus whitespace die betekenis heeft, met als argument dat het misleidend is als dingen verkeerd worden weergeven... en vervolgens geef je iets waarbij de weergave nadrukkelijk misleidend is.

Dat slaat gewoon helemaal nergens op, echt niet.

Het is een voorbeeld van hoe je echt niet moet werken om te illustreren dat als je zo eigenwijs bent tabs en spaties te willen mixen, dat het kan.

Uiteraard slaat het voorbeeld nergens op, dat was het doel ook niet. Het was simpelweg een tegenbewijs van "je kan tabs en spaties niet mixen", dat iets kan wil niet zeggen dat je het moet willen

[Y0ur1]

Wolfboy schreef op maandag 24 maart 2014 @ 14:47:
[...]
Cooler is niet relevant, het is vrij duidelijk zichtbaar dat er beter nagedacht is over het ontwerp van Python dan het ontwerp van PHP als je simpelweg naar de naamgevingen van de functies kijkt.

Ik heb vroeger heel wat PHP geschreven en daar had ik toch zeer regelmatig de PHP handleiding nodig om functies op te zoeken omdat het niet voorspelbaar was. Bij Python kan ik 90% van de tijd gewoon puur door logisch na te denken code schrijven en heb ik maar zelden documentatie nodig. Dat is echt puur een ontwerp punt.


[...]
Klopt, daarom is die onvolkomenheid er in Python 3 helemaal uitgehaald, bij Python 2 kan je dat gedrag ook krijgen door "python -tt bestand.py" uit te voeren, dan is het mixen van tabs en spaties een error.

Maar zoals gezegd, met fatsoenlijke editors en werkwijzes heb je dit probleem gewoon niet, tenzij je random code van blogs gaat copy/pasten (wat sowieso een slecht idee is, daar zijn libraries voor) loop je eigenlijk nooit tegen dat probleem aan.

Vermoedelijk zien veel PHP'ers dit als een probleem omdat het bij PHP veel normaler is code te copy/pasten van het web en/of een script te downloaden en deze aan te passen. Aangezien development in de Python community veel meer library based is en je in principe eigenlijk nooit library download om deze zelf aan te passen (afgezien van het forken van een library wat nog weleens voorkomt) werkt dit gewoon heel anders en is het in de praktijk sowieso nooit een probleem.

Nu weet ik dat je bij PHP wel PEAR hebt maar het is heel wat anders dan de standaard werkwijze bij Python.

1. Maak een virtualenv aan
2. Begin met het maken van je project
3. Heb je requirements? (Django, Flask, Numpy, etc...), installeren met "pip install <librarynaam>"
4. Tijd om te delen/deployen? "pip freeze > requirements.txt"

En dan kan je bij de productieserver en/of andere developers gewoon dit doen:

1. Maak een virtualenv aan
2. git clone repository
3. pip install -r requirements

En je hebt het geheel werkend inclusief alle libraries.


[...]
Het is een voorbeeld van hoe je echt niet moet werken om te illustreren dat als je zo eigenwijs bent tabs en spaties te willen mixen, dat het kan.

Uiteraard slaat het voorbeeld nergens op, dat was het doel ook niet. Het was simpelweg een tegenbewijs van "je kan tabs en spaties niet mixen", dat iets kan wil niet zeggen dat je het moet willen

Ken je https://getcomposer.org/?

[NMe]

.oisyn schreef op maandag 24 maart 2014 @ 14:28:
Exact. Dus het feit dat het kan zegt niets over de mogelijke designflaws van de taal.

Tegelijkertijd zijn veel van die designflaws ook niet relevant voor een goeie programmeur omdat hij niet op dat niveau met de taal werkt. Natuurlijk zit je altijd met de dynamic/weak typing-issues en andere zaken die echt diep in de taal verweven zitten, maar andere dingen zoals dat het standaardframework niet consistent is in naamgeving of gebruik zul je in de praktijk vaak niet tegenkomen omdat je framework die vaak wegabstraheert.

[.oisyn]

Op die manier kun je alle fouten van alles wel bagatelliseren. Maar ook een framework gaat je niet helpen tegen een onaangekondigde en ongedocumenteerde wijziging in strcmp() waarbij een comparison tussen een string en array voortaan 0 teruggeeft* terwijl hij een versie eerder gewoon -1 teruggaf. Wooptidoo, in 1 stap meteen allemaal systemen lek die met strcmp een wachtwoord controleren (true story, kan de link alleen niet meer vinden).

Deze discussie gaat over die design flaws, niet over of en/of hoe je er omheen kan werken. Design flaws waar iedere beginnende PHP'er (met programmeerervaring of niet) vroeg of laat weer tegenaan loopt. Er zijn met vrijwel elke taalconstructie of functie zoveel caveats dat er ook geen enkele logica uit te destilleren is en je nooit bent "uitgeleerd".

*

[ Voor 36% gewijzigd door .oisyn op 24-03-2014 15:29 ]

[Y0ur1]

.oisyn schreef op maandag 24 maart 2014 @ 15:23:
Op die manier kun je alle fouten van alles wel bagatelliseren. Maar ook een framework gaat je niet helpen tegen een onaangekondigde en ongedocumenteerde wijziging in strcmp() waarbij een comparison tussen een string en array voortaan 0 terugeeft terwijl hij een versie eerder gewoon -1 teruggaf. Wooptidoo, in 1 stap meteen allemaal systemen lek die met strcmp een wachtwoord controleren (true story, kan de link alleen niet meer vinden).

Deze discussie gaat over die design flaws, niet over of en/of hoe je er omheen kan werken. Design flaws waar iedere beginnende PHP'er (met programmeerervaring of niet) vroeg of laat weer tegenaan loopt. Er zijn met vrijwel elke taalconstructie of functie zoveel caveats dat er ook geen enkele logica uit te destilleren is en je nooit bent "uitgeleerd".

Sorry hoor, maar ik denk dat je je beter kunt afvragen hoe die array in een functie als strcmp terecht is gekomen, daar zit je echte probleem. Daar krijg je netjes een waarschuwing over.

Overigens krijg ik bij

PHP:

var_dump(strcmp('test', []));

null terug en een PHP warning, die 0 kan ik dus niet reproduceren.

[ Voor 5% gewijzigd door Y0ur1 op 24-03-2014 15:47 ]

[Radiant]

code:

if (!strcmp($_POST['ww'], "hoi")) {

Gaan we testen:
index.php?ww=hoi - verwachte resultaat, namelijk dat je inlogt.
index.php?ww=blaat - verwachte resultaat, namelijk dat je een error krijgt.
(beginnende) ontwikkelaar denkt: mooi, dat werkt. Geen warnings, want het is hier gewoon een string.

Aanvaller: index.php?ww[0]=1 en hij krijgt welliswaar een warning maar is wel binnen.

[ Voor 6% gewijzigd door Radiant op 24-03-2014 15:51 ]

[NMe]

.oisyn schreef op maandag 24 maart 2014 @ 15:23:
Op die manier kun je alle fouten van alles wel bagatelliseren. Maar ook een framework gaat je niet helpen tegen een onaangekondigde en ongedocumenteerde wijziging in strcmp() waarbij een comparison tussen een string en array voortaan 0 teruggeeft* terwijl hij een versie eerder gewoon -1 teruggaf. Wooptidoo, in 1 stap meteen allemaal systemen lek die met strcmp een wachtwoord controleren (true story, kan de link alleen niet meer vinden).

Het is niet alsof dat soort fouten dingen dagelijks in de taal sluipt, en daarbij is het hetzelfde probleem dat altijd in PHP terugkomt. Het gaat er puur om dat niet 0 maar null wordt teruggegeven, wat naar false evalueert. Kwestie van === gebruiken. Dit is nog steeds diezelfde ene designflaw die al de hele tijd in dit topic terugkomt (en terecht), niet een nieuwe.

Deze discussie gaat over die design flaws, niet over of en/of hoe je er omheen kan werken.

Vind ik niet. Een design flaw heeft geen impact als hij geen effect heeft op je werkwijze. Het hele ==/=== verhaal heeft dat natuurlijk wel, maar veruit de meeste dingen die hier geopperd worden hebben niet of nauwelijks effect op je dagelijkse bezigheden.

[Y0ur1]

Radiant schreef op maandag 24 maart 2014 @ 15:47:

code:

if (!strcmp($_POST['ww'], "hoi")) {

Gaan we testen:
index.php?ww=hoi - verwachtte resultaat, namelijk dat je inlogt.
index.php?ww=blaat - verwachtte resultaat, namelijk dat je een error krijgt.
(beginnende) ontwikkelaar denkt: mooi, dat werkt. Geen warnings, want het is hier gewoon een string.

Aanvaller: index.php?ww\[0]=1 en hij krijgt welliswaar een warning maar is wel binnen.

Goed punt, echter hier zijn code reviews (zeker bij beginnende ontwikkelaars), security audits en unit tests voor. Maar ik denk dat de discussie dynamic/static typing al te vaak is gevoerd om daar nog iets aan toe te voegen, ik laat het hier bij: http://martinfowler.com/bliki/DynamicTyping.html

[RayNbow]

Y0ur1 schreef op maandag 24 maart 2014 @ 15:53:
[...]

Goed punt, echter hier zijn code reviews (zeker bij beginnende ontwikkelaars), security audits en unit tests voor. Maar ik denk dat de discussie dynamic/static typing al te vaak is gevoerd om daar nog iets aan toe te voegen, ik laat het hier bij: http://martinfowler.com/bliki/DynamicTyping.html

Het gaat niet om dynamic vs. static maar om weak vs. strong.

[Y0ur1]

RayNbow schreef op maandag 24 maart 2014 @ 15:58:
[...]

Het gaat niet om dynamic vs. static maar om weak vs. strong.

Snap ik, echter zijn de termen strong and weak beladen. Ten eerste omdat ze een impliciet oordeel geven en ten tweede is dat de definitie niet echt vaststaat.

[.oisyn]

NMe schreef op maandag 24 maart 2014 @ 15:51:
Dit is nog steeds diezelfde ene designflaw die al de hele tijd in dit topic terugkomt (en terecht), niet een nieuwe.

Fout, de flaw is dat ze het gedrag zomaar van de ene op de andere versie aanpassen zonder dat te communiceren en te documenteren. Staat er ook tot op de dag van vandaag nog steeds niet

quote: http://nl3.php.net/strcmp

Returns < 0 if str1 is less than str2; > 0 if str1 is greater than str2, and 0 if they are equal.

Daar staat niet dat het null returnt als een van de parameters geen string is. Daarnaast werkt het prima met getallen.

Vind ik niet. Een design flaw heeft geen impact als hij geen effect heeft op je werkwijze.

Dan sla je wel een hele stap over, namelijk hoe je aan die werkwijze bent gekomen. En dat was met een gigantische hoeveelheid aan vallen en opstaan. Mensen die er tot op de dag van vandaag keer op keer over vallen. En het zijn er ook niet een paar oid.

Y0ur1 schreef op maandag 24 maart 2014 @ 16:09:
[...]

Snap ik

Dat denk ik niet, anders kwam je niet met het artikel over static/dynamic, want dat is nou precies juist niet de discussie.

[ Voor 11% gewijzigd door .oisyn op 24-03-2014 16:21 ]

[Barryvdh]

.oisyn schreef op maandag 24 maart 2014 @ 16:20:
[...]

Fout, de flaw is dat ze het gedrag zomaar van de ene op de andere versie aanpassen zonder dat te communiceren en te documenteren. Staat er ook tot op de dag van vandaag nog steeds niet

[...]

Daar staat niet dat het null returnt als een van de parameters geen string is. Daarnaast werkt het prima met getallen.

Nee maar er staat wel een paar keer dat je er een string in moet stoppen en geen array

strcmp — Binary safe string comparison

Description:
int strcmp ( string $str1 , string $str2 )
Note that this comparison is case sensitive.

Parameters:
str1 - The first string.
str2 - The second string.

[Y0ur1]

.oisyn schreef op maandag 24 maart 2014 @ 16:20:
[...]

Fout, de flaw is dat ze het gedrag zomaar van de ene op de andere versie aanpassen zonder dat te communiceren en te documenteren. Staat er ook tot op de dag van vandaag nog steeds niet

[...]

Daar staat niet dat het null returnt als een van de parameters geen string is. Daarnaast werkt het prima met getallen.


[...]

Dan sla je wel een hele stap over, namelijk hoe je aan die werkwijze bent gekomen. En dat was met een gigantische hoeveelheid aan vallen en opstaan. Mensen die er tot op de dag van vandaag keer op keer over vallen. En het zijn er ook niet een paar oid.


[...]

Dat denk ik niet, anders kwam je niet met het artikel over static/dynamic, want dat is nou precies juist niet de discussie.

Als PHP statically typed was dat had je strcmp ( string $str1 , string $str2 ) niet kunnen aanroepen met een array of int. Dat gaat dus over static/dynamic typing.

Het voorbeeld Radiant gaat idd over weak/strong typing.

Jouw voorbeeld van strcmp is gewoon geen goed voorbeeld omdat je de functie verkeerd gebruikt, er hoort nooit iets anders dan een string in te gaan.

[NMe]

.oisyn schreef op maandag 24 maart 2014 @ 16:20:
[...]

Fout, de flaw is dat ze het gedrag zomaar van de ene op de andere versie aanpassen zonder dat te communiceren en te documenteren. Staat er ook tot op de dag van vandaag nog steeds niet

[...]

Daar staat niet dat het null returnt als een van de parameters geen string is. Daarnaast werkt het prima met getallen.

Dat het ronduit achterlijk is om dit a) te wijzigen, b) niet te documenteren of c) niet te fixen ben ik direct met je eens, maar dat maakt het geen design flaw. Wat ik hier wel een design flaw noem (en zelfs een die op veel verschillende plekken terugkomt) is dat PHP wél een warning gooit maar vervolgens alsnog probeert er chocola van te maken.

Dan sla je wel een hele stap over, namelijk hoe je aan die werkwijze bent gekomen.

Ik doelde voor een groot deel op goed softwaredesign, niet zozeer op een werkwijze om de flaws in PHP te neutraliseren. Bijvoorbeeld: encapsulatie is een onderdeel van goed OO en heeft als bijwerking dat het een aantal flaws oplost zonder dat je daar moeite voor hoeft te doen of zelfs over na hoeft te denken.

Je hebt gelijk dat beginners het moeilijker hebben dan ervaren PHP-programmeurs maar uiteindelijk was de vraag hier wat er mis is met PHP als geheel. Voor een bekwaam programmeur die weet wat 'ie doet is het antwoord op die vraag anders dan voor een beginner die alle gaten nog moet ontdekken.

Barryvdh schreef op maandag 24 maart 2014 @ 16:25:
[...]

Nee maar er staat wel een paar keer dat je er een string in moet stoppen en geen array

[...]

Ik ben het alsnog wel met .oisyn eens dat het niet iets is waar je op rekent wanneer je die functie schrijft. Dat een aanvaller de naam van je input alleen maar van password naar password[] hoeft te veranderen om binnen te komen is niet iets waar je op rekent. En zelfs als je isset/empty gebruikt ben je niet veilig terwijl je dat wel zou kunnen denken...

[ Voor 16% gewijzigd door NMe op 24-03-2014 16:42 ]

[.oisyn]

Barryvdh schreef op maandag 24 maart 2014 @ 16:25:
[...]

Nee maar er staat wel een paar keer dat je er een string in moet stoppen en geen array

En dan stop je er een keer een array in waarna je -1 krijgt en dan denkt dat dat automatisch goed wordt afgehandeld en dus laat je de overbodige is_string op de $_POST["someUserInput"] achterwege. En dan veranderen ze ineens het gedrag van die functie.

NMe schreef op maandag 24 maart 2014 @ 16:39:
Je hebt gelijk dat beginners het moeilijker hebben dan ervaren PHP-programmeurs maar uiteindelijk was de vraag hier wat er mis is met PHP als geheel.

Exact, dus moet je niet ineens gaan doen alsof het niet belangrijk is als je er omheen kunt werken. Nee, zus en zo is gewoon wat er mis is.

Voor een bekwaam programmeur die weet wat 'ie doet is het antwoord op die vraag anders dan voor een beginner die alle gaten nog moet ontdekken.

De sensor van de bestuurdersdeur van mijn auto is stuk. Dit heeft als probleem dat hij geen pieptoon geeft als ik het licht laat branden of dat het binnenlicht niet aan gaat als ik de deur open. Toch is er makkelijk omheen te werken door er routine van te maken dat je altijd je licht uitzet voor je uitstapt, en het binnenlicht heb je in de meeste gevallen niet nodig en anders kun je 'm handmatig aanzetten. Prima workarounds dus. Betekent dat dan ineens dat er niets mis is met mijn auto?

[ Voor 57% gewijzigd door .oisyn op 24-03-2014 16:46 ]

[NMe]

.oisyn schreef op maandag 24 maart 2014 @ 16:40:
[...]

En dan stop je er een keer een array in waarna je -1 krijgt en dan denkt dat dat automatisch goed wordt afgehandeld en dus laat je de overbodige is_string op de $_POST["someUserInput"] achterwege. En dan veranderen ze ineens het gedrag van die functie.

Het is niet alsof dat in andere talen nooit zou kunnen gebeuren. Dat het in dit geval een ronduit achterlijke keuze was staat buiten kijf, maar soms moet een functie gewoon aangepast worden om iets onvoorziens te fixen. Zeg maar het tegenovergestelde van wat ze nu gedaan hebben.

Exact, dus moet je niet ineens gaan doen alsof het niet belangrijk is als je er omheen kunt werken. Nee, zus en zo is gewoon wat er mis is.

Ik heb volgens mij nergens gezegd dat die dingen niet fout zijn. Ik wil wel wat tegengeluid bieden tegen al die mensen hier die de taal diskwalificeren op basis van issues waarvan de impact niet groot is. PHP is prima af te kraken op issues die wél zo diep in de taal geworteld zijn dat je er niet omheen kunt, daar zijn er ook genoeg van.

[.oisyn]

Door louter dat tegengeluid te horen doe je anders behoorlijk overkomen dat je vind dat er niets mee mis is.

[Radiant]

Ik denk niet dat deze issue nou zo zeer het probleem is maar wel de manier waarop het PHP-team omgaat met dit soort wijzigingen.

Overigens zou dit hele probleem niet bestaan als PHP gewoon een keiharde error zou geven als je een ongeldige type voert aan een functie waar de types expliciet zijn vermeld en niet als "mixed", waarom gebeurt dat niet?

[Wolfboy]

Y0ur1 schreef op maandag 24 maart 2014 @ 14:59:
[...]

Ken je https://getcomposer.org/?

Ken ik wel ja, helaas is het nog steeds niet heel erg ingeburgerd, dat zou de werkwijze best wel veranderen.

Ter illustratie, search traffic voor getcomposer versus pypi:


En als je ziet dat er voor PHP als geheel nog steeds 2x zoveel gezocht wordt:


Dan zie je wel duidelijk dat het helaas nog niet zo actief gebruikt wordt als je zou hopen. Al is PHP als ecosysteem ook minder geschikt voor zo'n werkwijze imho...

[Janoz]

Misschien komt dat omdat programmeren in Python wat vanzelfsprekender gaat en je niet telkens moet googlen op de parametervolgorde .

[NMe]

.oisyn schreef op maandag 24 maart 2014 @ 16:47:
Door louter dat tegengeluid te horen doe je anders behoorlijk overkomen dat je vind dat er niets mee mis is.

Je realiseert je dat dit topic al ruim 350 posts loopt en ik in eerdere posts wel ingegaan ben op een aantal issues?

Radiant schreef op maandag 24 maart 2014 @ 16:49:
Ik denk niet dat deze issue nou zo zeer het probleem is maar wel de manier waarop het PHP-team omgaat met dit soort wijzigingen.

Overigens zou dit hele probleem niet bestaan als PHP gewoon een keiharde error zou geven als je een ongeldige type voert aan een functie waar de types expliciet zijn vermeld en niet als "mixed", waarom gebeurt dat niet?

Hele goeie vraag, en dat begrijp ik ook niet. Dit had geen warning moeten zijn maar gewoon een fatal error. Misschien minder mooi maar dan komt die hacker er in elk geval niet in.

Janoz schreef op maandag 24 maart 2014 @ 16:54:
Misschien komt dat omdat programmeren in Python wat vanzelfsprekender gaat en je niet telkens moet googlen op de parametervolgorde .

Goeie IDE nemen.

[.oisyn]

NMe schreef op maandag 24 maart 2014 @ 16:58:
[...]

Je realiseert je dat dit topic al ruim 350 posts loopt en ik in eerdere posts wel ingegaan ben op een aantal issues?

Nee. Sterker nog, ik had serieus het idee dat je in ieder geval in de laatste honderd posts vooral bezig bent je best te doen PHP te verdedigen

[Barryvdh]

Wolfboy schreef op maandag 24 maart 2014 @ 16:50:
[...]
Ken ik wel ja, helaas is het nog steeds niet heel erg ingeburgerd, dat zou de werkwijze best wel veranderen.

Ter illustratie, search traffic voor getcomposer versus pypi:
[afbeelding]

En als je ziet dat er voor PHP als geheel nog steeds 2x zoveel gezocht wordt:
[afbeelding]

Dan zie je wel duidelijk dat het helaas nog niet zo actief gebruikt wordt als je zou hopen. Al is PHP als ecosysteem ook minder geschikt voor zo'n werkwijze imho...

Nou is getcomposer ook niet echt een logische zoekterm. Zoek bijvoorbeeld op 'composer php' en het ligt al heel anders:


En het is het ecosysteem van PHP daar niet voor geschikt? Niemand gebruikt nog PEAR en volgens zijn bijna alle php libraries tegenwoordig gewoon geschikt gemaakt voor Composer. Alleen de grote logge systemen doen er wat langer over (Drupal krijgt bijvoobeeld binnenkort in versie 8 pas standaard Composer support volgens mij).
Ik gebruik iig zelden nog iets wat niet op Composer/Packagist staat..

[Feanathiel]

Barryvdh schreef op maandag 24 maart 2014 @ 17:26:
[...]
Nou is getcomposer ook niet echt een logische zoekterm. Zoek bijvoorbeeld op 'composer php' en het ligt al heel anders...
[...]

Volgens mij is het maar net waar je op zoekt ('python pip' geeft mij meer resultaten dan 'composer php'). Ik vind die statistieken een beetje een vertekend beeld geven.

[NMe]

.oisyn schreef op maandag 24 maart 2014 @ 17:03:
[...]

Nee. Sterker nog, ik had serieus het idee dat je in ieder geval in de laatste honderd posts vooral bezig bent je best te doen PHP te verdedigen

Ik probeer vooral te relativeren. Maar goed, voor de duidelijkheid dan mijn volledige mening: er is van alles mis met PHP, en dat zijn fouten die variëren van onhandigheidjes tot grove designfouten. Daar zitten fouten tussen waar ik me regelmatig aan erger en ik zou vooraan staan te juichen wanneer PHP ooit aankondigt dat ze backwards compatibility gaan breken om eens wat issues aan te pakken.

Dat gezegd hebbende vind ik alsnog dat PHP vooral door programmeurs die er niets of niet veel mee doen vaak ongenadig afgerekend wordt op dingen die weliswaar stuk zijn maar die weinig effect hebben op je werk omdat je door goeie designprincipes toe te passen een deel van die problemen al neutraliseert.

[RayNbow]

Barryvdh schreef op maandag 24 maart 2014 @ 16:25:
[...]

Nee maar er staat wel een paar keer dat je er een string in moet stoppen en geen array

[...]

Dat neemt niet weg dat .oisyn's punt nog steeds valide is. Het gewijzigde gedrag is niet gedocumenteerd. Daarnaast, met PHP's weak-typing zou je verwachten dat als je er iets anders dan een string erin propt, dat PHP wat type juggling doet, nietwaar?

Y0ur1 schreef op maandag 24 maart 2014 @ 16:39:
[...]

Als PHP statically typed was dat had je strcmp ( string $str1 , string $str2 ) niet kunnen aanroepen met een array of int. Dat gaat dus over static/dynamic typing.

Fout. Een statisch getypeerde taal zou dit nog steeds kunnen accepteren als het weak-typing regels had als bijv. "converteer alle byte-arrays automatisch naar UTF8 strings". Static/dynamic is en blijft een andere as dan weak/strong.

[incaz]

Wolfboy schreef op maandag 24 maart 2014 @ 14:47:
Maar zoals gezegd, met fatsoenlijke editors en werkwijzes heb je dit probleem gewoon niet,

Zoals gezegd: een heleboel nadelen van php (en vooral de argumentvolgorde) valen met een fatsoenlijke editor ook weg.

Dus dat argument werkt gewoon niet.

tenzij je random code van blogs gaat copy/pasten (wat sowieso een slecht idee is, daar zijn libraries voor) loop je eigenlijk nooit tegen dat probleem aan.

Je schijnt dat heel hoog op te nemen, maar a, ik kopieer niet random code van blogs, b. het soort zaken dat ik kopieer zijn niet de zaken die je in libraries terugvindt, c. misschien wel het belangrijkste, het was een voorbeeld waarom ik het een bijzonder slecht idee vindt om op zoiets fragiels als whitespace te vertrouwen voor essentiele semantiek: omdat whitespace in veel contexts beschouwd wordt als iets dat niet betekenisvol is en er dus zomaar ergens een verkeerde trim of een verkeerde tabs2spaces overheen kan gaan, en dat kan valide maar incorrecte code opleveren. Met als extra nadeel dat je dergelijke zaken dus niet ziet.

Vermoedelijk zien veel PHP'ers dit als een probleem omdat het bij PHP veel normaler is code te copy/pasten van het web en/of een script te downloaden en deze aan te passen.

Nice frame opnieuw

Uiteraard slaat het voorbeeld nergens op, dat was het doel ook niet. Het was simpelweg een tegenbewijs van "je kan tabs en spaties niet mixen", dat iets kan wil niet zeggen dat je het moet willen

Ik wilde het niet. Helaas heb je dat soort dingen dus niet altijd onder controle, vooral niet als je met legacycode zit.

[Y0ur1]

RayNbow schreef op maandag 24 maart 2014 @ 17:44:
[...]

Dat neemt niet weg dat .oisyn's punt nog steeds valide is. Het gewijzigde gedrag is niet gedocumenteerd. Daarnaast, met PHP's weak-typing zou je verwachten dat als je er iets anders dan een string erin propt, dat PHP wat type juggling doet, nietwaar?


[...]

Fout. Een statisch getypeerde taal zou dit nog steeds kunnen accepteren als het weak-typing regels had als bijv. "converteer alle byte-arrays automatisch naar UTF8 strings". Static/dynamic is en blijft een andere as dan weak/strong.

Ja, maar dit komt wel erg theoretisch over, heb je een voorbeeld van een taal die dit zo doet?

[Barryvdh]

Feanathiel schreef op maandag 24 maart 2014 @ 17:33:
[...]
Volgens mij is het maar net waar je op zoekt ('python pip' geeft mij meer resultaten dan 'composer php'). Ik vind die statistieken een beetje een vertekend beeld geven.

Klopt, dat bedoelde ik ook meer, dat het niet zoveel wil zeggen. (Ook omdat het niet relatief is tov het aantal python/php gebruikers)

RayNbow schreef op maandag 24 maart 2014 @ 17:44:
[...]

Dat neemt niet weg dat .oisyn's punt nog steeds valide is. Het gewijzigde gedrag is niet gedocumenteerd. Daarnaast, met PHP's weak-typing zou je verwachten dat als je er iets anders dan een string erin propt, dat PHP wat type juggling doet, nietwaar?

Het is inderdaad niet echt een handige move, maar er is ook nergens beschreven wat er wel zou moeten gebeuren als je er een array in stopt, alleen wat er gebeurd als je er strings in stopt. Wat dat betreft kan je ze het ook minder kwalijk nemen dat het gedrag veranderd een keer, want je gebruikt het (strikt gesproken) niet zoals het bedoeld is.
Ik wil verder ook niet zeggen dat huidige gedrag niet onhandig/raar/onlogisch is hoor.

[Wolfboy]

Barryvdh schreef op maandag 24 maart 2014 @ 17:26:
[...]

Nou is getcomposer ook niet echt een logische zoekterm. Zoek bijvoorbeeld op 'composer php' en het ligt al heel anders:
[afbeelding]

En het is het ecosysteem van PHP daar niet voor geschikt? Niemand gebruikt nog PEAR en volgens zijn bijna alle php libraries tegenwoordig gewoon geschikt gemaakt voor Composer. Alleen de grote logge systemen doen er wat langer over (Drupal krijgt bijvoobeeld binnenkort in versie 8 pas standaard Composer support volgens mij).
Ik gebruik iig zelden nog iets wat niet op Composer/Packagist staat..

Het lijkt inderdaad beter zijn dan ik dacht, I stand corrected

offtopic:
Toch wat activiteit gemist de laatste tijd.

incaz schreef op maandag 24 maart 2014 @ 17:45:
[...]


Zoals gezegd: een heleboel nadelen van php (en vooral de argumentvolgorde) valen met een fatsoenlijke editor ook weg.

Dus dat argument werkt gewoon niet.

Waar heb ik dat argument opgevoerd dan?

b. het soort zaken dat ik kopieer zijn niet de zaken die je in libraries terugvindt

Klinkt alsof er ruimte is voor een library op dat gebied

misschien wel het belangrijkste, het was een voorbeeld waarom ik het een bijzonder slecht idee vindt om op zoiets fragiels als whitespace te vertrouwen voor essentiele semantiek: omdat whitespace in veel contexts beschouwd wordt als iets dat niet betekenisvol is en er dus zomaar ergens een verkeerde trim of een verkeerde tabs2spaces overheen kan gaan, en dat kan valide maar incorrecte code opleveren. Met als extra nadeel dat je dergelijke zaken dus niet ziet.

Omdat het in veel contexts beschouwd wordt als iets niet betekenisvols is het niet belangrijk?

In veel contexts is case sensitivity niet van belang, is het daarom stom om daarop te vertrouwen?

Ik wilde het niet. Helaas heb je dat soort dingen dus niet altijd onder controle, vooral niet als je met legacycode zit.

Als je met legacycode zit moet je gewoon heel goed uitkijken, gelukkig zijn er tools beschikbaar die de meeste problemen kunnen afvangen. Al is het in de meeste gevallen prima mogelijk om ook met legacy code om het probleem heen te werken.

Door de oude code via imports/subclassing aan te spreken is het prima mogelijk om te overriden zonder ooit de code te hoeven zien.

[Patriot]

Barryvdh schreef op maandag 24 maart 2014 @ 18:07:
[...]

Klopt, dat bedoelde ik ook meer, dat het niet zoveel wil zeggen. (Ook omdat het niet relatief is tov het aantal python/php gebruikers)
[...]


Het is inderdaad niet echt een handige move, maar er is ook nergens beschreven wat er wel zou moeten gebeuren als je er een array in stopt, alleen wat er gebeurd als je er strings in stopt. Wat dat betreft kan je ze het ook minder kwalijk nemen dat het gedrag veranderd een keer, want je gebruikt het (strikt gesproken) niet zoals het bedoeld is.
Ik wil verder ook niet zeggen dat huidige gedrag niet onhandig/raar/onlogisch is hoor.

Is een warning gooien en null returnen zo onhandig/raar/onlogisch dan?

Ik snap dat het om een voorbeeld gaat, maar verder vind ik het overigens ook maar een beetje een vreemd verhaal. Ik kan het niet reproduceren in ieder geval. Wat ik wel weet is dat ook in PHP 4.4.9 gewoon null teruggegeven wordt. Op php.net in de comments bij strcmp kom ik wel iemand tegen die klaagt dat (int)strcmp(array, string) 0 teruggeeft, maar daar zorgt 'ie zelf voor door te casten.

[RayNbow]

Y0ur1 schreef op maandag 24 maart 2014 @ 18:00:
[...]

Ja, maar dit komt wel erg theoretisch over, heb je een voorbeeld van een taal die dit zo doet?

Ik ken geen taal die precies dit doet, maar C wordt algemeen gezien als een zwakkere statisch getypeerde taal. Let wel, of een taal weak/strong is niet een geval van zwart/wit, maar het is eerder een continue schaal.

[NMe]

Patriot schreef op maandag 24 maart 2014 @ 18:26:
[...]

Is een warning gooien en null returnen zo onhandig/raar/onlogisch dan?

Wanneer een functie bij positief resultaat juist 0 returnt en je taal door impliciete conversies 0 en null gelijkstelt: ja.

[Patriot]

NMe schreef op maandag 24 maart 2014 @ 18:32:
[...]

Wanneer een functie bij positief resultaat juist 0 returnt en je taal door impliciete conversies 0 en null gelijkstelt: ja.

Dus door PHP z'n type juggling moet je soms controleren of iets van een bepaald type is omdat je anders in de problemen komt. Hoe lang weten we dat nu al?

Binnen die context vind ik het huidige gedrag niet zo gek hoor.

[RayNbow]

Patriot schreef op maandag 24 maart 2014 @ 18:36:
[...]


Dus door PHP z'n type juggling moet je soms controleren of iets van een bepaald type is omdat je anders in de problemen komt. Hoe lang weten we dat nu al?

Binnen die context vind ik het huidige gedrag niet zo gek hoor.

Ik neem aan dat PHP's type juggling er vooral bedoeld was om bepaalde zaken in de taal gemakkelijker te maken. Dan is het oude gedrag in het geval van strcmp een stuk makkelijker dan het huidige gedrag dat je verplicht om extra controles op de returntype te plaatsen omdat anders type juggling roet in het eten gooit.

[NMe]

Patriot schreef op maandag 24 maart 2014 @ 18:36:
[...]

Dus door PHP z'n type juggling moet je soms controleren of iets van een bepaald type is omdat je anders in de problemen komt. Hoe lang weten we dat nu al?

In andere gevallen is dat in elk geval gedocumenteerd. In dit geval is het dat niet. De documentatie noemt 0, >0 en <0 als enige potentiële returnvalues. Null wordt nergens genoemd. Dat is ronduit debiel en hoewel de oplossing inderdaad simpel is, is het nu onmogelijk om het probleem te ontdekken tot je een keer gehackt wordt. En zelfs dan is het niet echt simpel omdat je door de incomplete documentatie niet snel strcmp zal verdenken...

RayNbow schreef op maandag 24 maart 2014 @ 18:47:
[...]

Ik neem aan dat PHP's type juggling er vooral bedoeld was om bepaalde zaken in de taal gemakkelijker te maken. Dan is het oude gedrag in het geval van strcmp een stuk makkelijker dan het huidige gedrag dat je verplicht om extra controles op de returntype te plaatsen omdat anders type juggling roet in het eten gooit.

Ook dat is geen ramp, voor mij boeit het niet of ik nu if (!strcmp($string1, $string2)) schrijf of if (strcmp($string1, $string2) === 0). Maar dan moet de documentatie dus wél aangeven dat dat nodig is om vreemd gedrag tegen te gaan.

[ Voor 32% gewijzigd door NMe op 24-03-2014 18:52 ]

[Barryvdh]

Hier is een bug report trouwens: https://bugs.php.net/bug.php?id=64069

[2013-01-25 10:46 UTC] [e-mail]
-Status: Open
+Status: Not a bug
[2013-01-25 10:46 UTC] [e-mail]
It is established behavior for function that receive the wrong type of
argument(s) to return null.

Maar waarom zou je niet gewoon $string1 === $string2 gebruiken als je alleen wil weten of het wachtwoord klopt?

[Patriot]

NMe schreef op maandag 24 maart 2014 @ 18:50:
[...]

In andere gevallen is dat in elk geval gedocumenteerd. In dit geval is het dat niet. De documentatie noemt 0, >0 en <0 als enige potentiële returnvalues. Null wordt nergens genoemd. Dat is ronduit debiel en hoewel de oplossing inderdaad simpel is, is het nu onmogelijk om het probleem te ontdekken tot je een keer gehackt wordt. En zelfs dan is het niet echt simpel omdat je door de incomplete documentatie niet snel strcmp zal verdenken...

[...]

Ook dat is geen ramp, voor mij boeit het niet of ik nu if (!strcmp($string1, $string2)) schrijf of if (strcmp($string1, $string2) === 0). Maar dan moet de documentatie dus wél aangeven dat dat nodig is om vreemd gedrag tegen te gaan.

Dus zit er in dit geval een fout in de documentatie, die geeft namelijk niet aan wat hij doet als je parameters van het verkeerde type aanlevert.

Dat staat los van het feit dat het logisch is om dan null terug te geven en een warning te gooien.

[RayNbow]

Wacht...

It is established behavior for function that receive the wrong type of
argument(s) to return null.

Als het established behavior is, zijn er dan meer functies die hetzelfde gedrag vertonen? Of is deze conventie uberhaupt ergens gedocumenteerd?

[Patriot]

RayNbow schreef op maandag 24 maart 2014 @ 19:25:
Wacht...

[...]


Als het established behavior is, zijn er dan meer functies die hetzelfde gedrag vertonen? Of is deze conventie uberhaupt ergens gedocumenteerd?

http://nl3.php.net/manual/en/functions.internal.php

Note: If the parameters given to a function are not what it expects, such as passing an array where a string is expected, the return value of the function is undefined. In this case it will likely return NULL but this is just a convention, and cannot be relied upon.

[ZaZ]

.oisyn schreef op maandag 24 maart 2014 @ 16:40:
[...]
De sensor van de bestuurdersdeur van mijn auto is stuk. Dit heeft als probleem dat hij geen pieptoon geeft als ik het licht laat branden of dat het binnenlicht niet aan gaat als ik de deur open. Toch is er makkelijk omheen te werken door er routine van te maken dat je altijd je licht uitzet voor je uitstapt, en het binnenlicht heb je in de meeste gevallen niet nodig en anders kun je 'm handmatig aanzetten. Prima workarounds dus. Betekent dat dan ineens dat er niets mis is met mijn auto?

Is het een Fiat Panda?

[NMe]

Barryvdh schreef op maandag 24 maart 2014 @ 19:09:
Maar waarom zou je niet gewoon $string1 === $string2 gebruiken als je alleen wil weten of het wachtwoord klopt?

Discrepantie tussen charsets?

Patriot schreef op maandag 24 maart 2014 @ 19:41:
[...]

http://nl3.php.net/manual/en/functions.internal.php

[...]

Mja, als het zo werkt kunnen ze inderdaad beter gewoon zowel weak typing als dynamic typing uit de taal slopen want blijkbaar maken ze je vervolgens zelf verantwoordelijk voor je types zonder dat je zelf af kan dwingen dat iets het juiste type heeft...

[R4gnax]

Y0ur1 schreef op maandag 24 maart 2014 @ 18:00:
[...]

Ja, maar dit komt wel erg theoretisch over, heb je een voorbeeld van een taal die dit zo doet?

C# via implicit type conversion voor veilige conversies en explicit type conversion voor conversies die mogelijk niet veilig zijn. (En nee, dat zijn niet simpele casts...)

Radiant schreef op maandag 24 maart 2014 @ 16:49:
Ik denk niet dat deze issue nou zo zeer het probleem is maar wel de manier waarop het PHP-team omgaat met dit soort wijzigingen.

Overigens zou dit hele probleem niet bestaan als PHP gewoon een keiharde error zou geven als je een ongeldige type voert aan een functie waar de types expliciet zijn vermeld en niet als "mixed", waarom gebeurt dat niet?

Omdat de filosofie van het PHP team is dat code door iedereen, maar dan ook iedereen, geklopt moet kunnen worden en moet draaien, zelfs als het kei en kei fout is. Het is juist dat krampachtige vasthouden aan die lowest common denominator wat ervoor zorgt dat PHP op veel fronten zo'n bende is.

[ Voor 42% gewijzigd door R4gnax op 24-03-2014 20:41 ]

[gekkie]

.oisyn schreef op maandag 24 maart 2014 @ 16:40:
De sensor van de bestuurdersdeur van mijn auto is stuk. Dit heeft als probleem dat hij geen pieptoon geeft als ik het licht laat branden of dat het binnenlicht niet aan gaat als ik de deur open. Toch is er makkelijk omheen te werken door er routine van te maken dat je altijd je licht uitzet voor je uitstapt, en het binnenlicht heb je in de meeste gevallen niet nodig en anders kun je 'm handmatig aanzetten. Prima workarounds dus. Betekent dat dan ineens dat er niets mis is met mijn auto?

offtopic:
Bij mij hielp hier tegen het verwijderen van het lampje in de deur. Vervolgens vervangen door een led lampje
et voila .. dat werkt ook ... fransozen en electrotechniek

(gevonden op een forum .. het lampje is een te grote gebruiker ..waardoor de nog semi werkende sensor het signaal niet bij de ECU krijgt of iets dergelijks. Door de verbruiker te verwijderen danwel het verbruik ervan te verlagen komt het signaal "deur open" nu wel weer door.

[ Voor 14% gewijzigd door gekkie op 24-03-2014 21:15 ]

[gekkie]

R4gnax schreef op maandag 24 maart 2014 @ 20:38:
Omdat de filosofie van het PHP team is dat code door iedereen, maar dan ook iedereen, geklopt moet kunnen worden en moet draaien, zelfs als het kei en kei fout is. Het is juist dat krampachtige vasthouden aan die lowest common denominator wat ervoor zorgt dat PHP op veel fronten zo'n bende is.

Nogal een foute uitgangsgedachte ja .. aangezien die "iedereen" .. liever heeft dat de code doet wat je denkt dat het gaat doen. Als het stuk zou moeten gaan .. moet het dus gewoon stuk gaan.

[Patriot]

NMe schreef op maandag 24 maart 2014 @ 20:28:
[...]

Discrepantie tussen charsets?

[...]

Mja, als het zo werkt kunnen ze inderdaad beter gewoon zowel weak typing als dynamic typing uit de taal slopen want blijkbaar maken ze je vervolgens zelf verantwoordelijk voor je types zonder dat je zelf af kan dwingen dat iets het juiste type heeft...

Wat heeft dat in hemelsnaam te maken met een (niet gegarandeerde) conventie onder de developers van PHP?

[NMe]

Patriot schreef op maandag 24 maart 2014 @ 22:08:
[...]

Wat heeft dat in hemelsnaam te maken met een (niet gegarandeerde) conventie onder de developers van PHP?

Als het passen van variabelen aan functies anders dan de in de documentatie aangegeven types undefined gedrag veroorzaakt en in veel gevallen null zal returnen zoals in dat stukje staat, dan moet je blijkbaar al je input gaan checken op het juiste type (want anders heb je ineens zomaar een array te pakken) nog naast het feit dat je moet kijken of de variabele meegegeven is of niet. Voor een taal die je juist pretendeert het gezeik rondom types uit handen te nemen is het op zijn zachtst gezegd raar te noemen dat 't zomaar dit soort dingen doet als je het verkeerde type doorgeeft. En als 0 voor deze specifieke functie nou "false" was geweest was het niet eens een ramp, maar 0 geeft voor strcmp succes aan terwijl null (wat naar hetzelfde evalueert tenzij je de identity-operator gebruikt) juist een failure aangeeft...

[gekkie]

Radiant schreef op maandag 24 maart 2014 @ 16:49:
Ik denk niet dat deze issue nou zo zeer het probleem is maar wel de manier waarop het PHP-team omgaat met dit soort wijzigingen.

Eigenlijk wel het belangrijkste minpunt .. een gebrek aan perspectief dat het beter wordt ..

[biglia]

Ik heb altijd in .NET geprogrammeerd, maar ASP.NET WebForms vond ik persoonlijk een grote ramp. Het is sinds ASP.NET MVC dat .NET bruikbaar is voor het web.

[BtM909]

biglia schreef op dinsdag 25 maart 2014 @ 10:52:
Ik heb altijd in .NET geprogrammeerd, maar ASP.NET WebForms vond ik persoonlijk een grote ramp. Het is sinds ASP.NET MVC dat .NET bruikbaar is voor het web.

En wat heeft dat te maken met PHP?

[Barryvdh]

BtM909 schreef op dinsdag 25 maart 2014 @ 11:51:
[...]

En wat heeft dat te maken met PHP?

Aandacht afleiden van PHP, nu gaan we ASP bashen?

[NMe]

ASP bashen is lekker makkelijk, wat een bagger was dat. ASP.NET daarentegen...

[DexterDee]

NMe schreef op dinsdag 25 maart 2014 @ 13:07:
ASP bashen is lekker makkelijk, wat een bagger was dat. ASP.NET daarentegen...

__VIEWSTATE en __EVENTVALIDATION anyone? Nee, dan stoei ik liever met PHP

[kenneth]

ASP.NET Web Forms
ASP.NET MVC

[MueR]

NMe schreef op maandag 24 maart 2014 @ 22:17:
Voor een taal die je juist pretendeert het gezeik rondom types uit handen te nemen is het op zijn zachtst gezegd raar te noemen dat 't zomaar dit soort dingen doet als je het verkeerde type doorgeeft.

Ze zouden eigenlijk gewoon een InvalidArgumentException moeten gooien

[Verwijderd]

DexterDee schreef op dinsdag 25 maart 2014 @ 14:02:
[...]

__VIEWSTATE en __EVENTVALIDATION anyone? Nee, dan stoei ik liever met PHP

Als we huidige talen met oude koeien gaan vergelijken, zullen we dan good old HTML uit 1995 gaan vergelijken met PHP?

Dit is een topic wat nu loopt over PHP en dat dien je dus in de huidige tijd te vergelijken met ASP.NET MVC. Of ga jij als je nu een nieuwe auto wil kopen die ook bij wijze van spreken vergelijken met een Opel Corsa uit 1977?

Ps. Elke goede programmeur zorgde er natuurlijk in ASP.NET voor dat de viewstate zoveel mogelijk uit stond... En de viewstate is prima te vergelijken met de velen hidden fields die veel PHP programmeurs af en toe gebruiken om soortgelijken zaken op te slaan (De viewstate is zelfs opgeslagen in zo'n hidden field).

[ Voor 22% gewijzigd door Verwijderd op 26-03-2014 09:30 ]

[BikkelZ]

Ik denk dat als er een versie komt van PHP waarbij eens en voor altijd de oudste laag aan commando's aangepakt wordt en vervangen wordt door een zinvolle versie waarbij al je calls op de zelfde manier geschreven wordt én je een PEP-8 achtige formatting standaard delegeert dat je dan een verrassend bruikbare taal overhoudt. Dat je dan een tijdje een overgangssituatie hebt waarbij je via settings aan kunt geven of je de nieuwe, de oude of een gemixte set aan commando's lijkt me onoverkomelijk maar het wordt wel tijd dat de hele community naar één standaard gaat.

Het nadeel van nieuwere PHP versies is dat die oude PHP 3 achtige snelheid er bij iedere verbeterde versie weer wat meer uit gaat.

[ Voor 22% gewijzigd door BikkelZ op 28-03-2014 15:37 ]