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

[RayNbow]

Guillome schreef op woensdag 19 augustus 2015 @ 13:47:
In C# weet ik dat het ook zo gebeurt als ik voorstelde. Volgens mij wel in meer talen.

In de wiskunde en de betere talen (o.a. Haskell) zetten we het type gewoon achter de variabele, functie, expressie, etc.

[Guillome]

Ok, maar hoe dan ook: het is nu inconsequent en daar baalde ik van.

[Compizfox]

ValHallASW schreef op woensdag 19 augustus 2015 @ 13:45:
[...]

Omdat blaat een functie is, en niet een int In je bovenste voorbeeld is het access modifier, type, naam.

In talen met C-achtige syntax (zo uit m'n hoofd C, C++, C#, Java) ziet een functiedefinitie er zo uit. Dat het een functie is en geen variabele, wordt aangegeven door de haken ().

Aangezien ook PHP C-achtige syntax gebruikt, was het consequent geweest als ze die syntax hadden gevolgd voor de return types.

In je onderste syntax kan je tweede parameter zowel een type als een return type zijn.

Nee, parameters (en dus ook de types daarvan) staan altijd binnen de haken. De int in dat voorbeeld kan dus alleen een return type zijn en niets anders.

[ Voor 43% gewijzigd door Compizfox op 19-08-2015 15:34 ]

[StM]

RayNbow schreef op woensdag 19 augustus 2015 @ 09:50:
[...]

Ik heb het niet uitgeprobeerd, maar ik weet vrijwel zeker dat dit ook gewoon allemaal in PHP kan. Enige beperking die ik zo zie is dat LoggedFib = Logged(MemoFib, name='LoggedFib') iets als LoggedFib = Logged("MemoFib", name='LoggedFib') zal zijn. De rest is allemaal prima na te bouwen met closures en magic methods. Ik gok dat je wel *iets* meer glue code nodig hebt, maar heel veel zal het niet zijn...

Als ik vanavond tijd heb zal ik het eens nabouwen.

[ Voor 4% gewijzigd door StM op 19-08-2015 15:09 ]

[johnkeates]

StM schreef op woensdag 19 augustus 2015 @ 15:04:
[...]


Ik heb het niet uitgeprobeerd, maar ik weet vrijwel zeker dat dit ook gewoon allemaal in PHP kan. Enige beperking die ik zo zie is dat LoggedFib = Logged(MemoFib, name='LoggedFib') iets als LoggedFib = Logged("MemoFib", name='LoggedFib') zal zijn. De rest is allemaal prima na te bouwen met closures en magic methods. Ik gok dat je wel *iets* meer glue code nodig hebt, maar heel veel zal het niet zijn...

Als ik vanavond tijd heb zal ik het eens nabouwen.

Ja, op die manier kan het ook in Brainfuck of Whitespace, dat zegt niet dat het er geschikte talen voor zijn om je applicatie in te bouwen...

[StM]

Dus omdat de syntax iets anders is, is het opeens geen geschikte taal meer? Dat noem ik eerder blinde haat tegen een bepaalde taal

[Compizfox]

RayNbow schreef op woensdag 19 augustus 2015 @ 09:50:
[...]

C++ behoort dan ook niet in mijn rijtje van favoriete talen.

Maar waarom zou het niet kunnen? Wat maakt een class anders dan een int, string, boolean, array, object, etc.? Waarom kunnen we wel een lijst integers definiëren maar geen lijst die classes bevat? Waarom kunnen we een functie toepassen op een string om een nieuwe string te verkrijgen maar is dat niet mogelijk voor een class?

Omdat een object een instantie van een class is. Dat je dat in een variabele stopt, lijkt me vanzelfsprekend.

Een class zelf in een variabele, tja, ik vind het gewoon een vreemd concept

[DennusB]

StM schreef op woensdag 19 augustus 2015 @ 15:18:
Dus omdat de syntax iets anders is, is het opeens geen geschikte taal meer? Dat noem ik eerder blinde haat tegen een bepaalde taal

QFT.
Ik snap ook niet wat iedereen altijd loopt te bitchen op PHP, als ik bijvoorbeeld .NET site's wel eens zie, man man man wat een draken kunnen dat worden, geheugenlekken, CPU opslokken, "opwarmen" van je site bij de eerste hit enz enz, dat heeft PHP allemaal niet.

[ Voor 34% gewijzigd door DennusB op 19-08-2015 15:34 ]

[FireDrunk]

Een Class zelf in een variabele stoppen is handig als je bijvoorbeeld met Asynchrone communicatie gaat werken...

In multithreaded omgevingen doe je dan:

$a->DoeJeWerkLuieHond($metdezedata, $enroepditaanalsjeklaarbent);

Als de functie klaar is doet hij iets als $enroepditaanalsjeklaarbent($resultaat,$extrainfo);

Maar dat is maar 1 van de voorbeelden... Dat soort constructies doet C# via Delegates, en Java kent ze weer niet, wil dat je transparante superclasses maakt ofzo, en Python staat gewoon keiharde functie pointers toe...

Het probleem is vooral: Je moet begrijpen wat je doet. Als je precies snapt hoe de logica in de machine aan de slag gaat, is het schrijven van de code in een bepaalde taal maar bijzaak.

Net zoals dat je niet design patterns moet doen omdat ze er zijn, maar omdat je ze in jouw situatie nodig hebt...

[gekkie]

Compizfox schreef op woensdag 19 augustus 2015 @ 15:32:
[...]
Omdat een object een instantie van een class is. Dat je dat in een variabele stopt, lijkt me vanzelfsprekend.

Een class zelf in een variabele, tja, ik vind het gewoon een vreemd concept

In python doe je dat ook niet echt. Sterker nog je stopt eigenlijk nooit iets in een variabele.
Je assignt een referentie naar een object .. en alles is een object .. een string, een int, een functie.
En als je dat hebt is een referentie naar een class ook logisch, voor het maken van een instance moet je toch aan een class refereren.
Wat dat betreft zou een term als "label" wellicht beter zijn dan "variabele".

[FireDrunk]

Goed punt! Kijk met Python naar de dir() functie

[mbarie]

DennusB schreef op woensdag 19 augustus 2015 @ 15:33:

Ik snap ook niet wat iedereen altijd loopt te bitchen op PHP, als ik bijvoorbeeld .NET site's wel eens zie, man man man wat een draken kunnen dat worden, geheugenlekken, CPU opslokken, "opwarmen" van je site bij de eerste hit enz enz, dat heeft PHP allemaal niet.

Geheugenlekken zal iets moeilijker worden omdat alles na iedere request weer netjes opgeschoond wordt. CPU opslokken en opwarmen kan PHP net zo goed hoor. Zeker als je OPcache oid toepast kunnen eerste requests beduidend langzamer zijn dan de rest omdat alle bytecode nog niet gecached is.

Verder hebben we hier ook diverse dure requests die om en nabij een minuut duren om de volledige dataset op te bouwen, maar dat kan je designtechnisch ook op de achtergrond uitvoeren.

Verder kunnen PHP sites ook prima draken worden. Ik heb er in een ver verleden zelf ook een gebouwd...

[ Voor 6% gewijzigd door mbarie op 19-08-2015 16:22 ]

[gekkie]

mbarie schreef op woensdag 19 augustus 2015 @ 16:21:
[...]


Geheugenlekken zal iets moeilijker worden omdat alles na iedere request weer netjes opgeschoond wordt. CPU opslokken en opwarmen kan PHP net zo goed hoor. Zeker als je OPcache oid toepast kunnen eerste requests beduidend langzamer zijn dan de rest omdat alle bytecode nog niet gecached is.

Verder hebben we hier ook diverse dure requests die om en nabij een minuut duren om de volledige dataset op te bouwen, maar dat kan je designtechnisch ook op de achtergrond uitvoeren.

Verder kunnen PHP sites ook prima draken worden. Ik heb er in een ver verleden zelf ook een gebouwd...

Niet voor niks dat er genoeg opensource projecten zijn die je vragen de max looptijd en geheugen gebruik per script aan te passen in je config (php.ini, apache config of het staat in een .htaccess).
Maar het hele stateless gebeuren maakt het wel makkelijk (en tegelijkertijd ook weer kostbaar, want je mag je state iedere keer opnieuw laden bij elk request).

[Lethalis]

DennusB schreef op woensdag 19 augustus 2015 @ 15:33:
[...]

QFT.
Ik snap ook niet wat iedereen altijd loopt te bitchen op PHP, als ik bijvoorbeeld .NET site's wel eens zie, man man man wat een draken kunnen dat worden, geheugenlekken, CPU opslokken, "opwarmen" van je site bij de eerste hit enz enz, dat heeft PHP allemaal niet.

Al is de hamer nog zo mooi, als je niet kunt timmeren dan wordt het niks.

Maar voor iemand die wel goed kan timmeren, is de mooie hamer wel fijner.

[DJMaze]

PHP werkt prima, de ontwikkelaars zijn brak.
En in elke taal zitten brakke ontwikkelaars.

Kijk nou naar jQuery, iedereen zweert er bij als je op stackoverflow kijkt.
Persoonlijk heb ik er een gruwelijke hekel aan (met name op mobiel).
Open eens een WordPress (ja php) website met een YOO theme op mobiel, en nee dat ligt niet aan PHP.

Waarom PHP projecten de memory_limit moeten ophogen ligt aan de ontwikkelaars.
Al mijn projecten volstaan prima met een memory_limit van 8MB.

En ja elke taal heeft zijn WTF's en is slecht, maar niet zo slecht als de persoon die het gebruikt.

Zelfde geld trouwens ook voor OS'en, de één zegt OSX, de ander Windows, en weer een ander GNU/Linux
Zoals hier duidelijk is: http://www.computerworld....led-windows-platform.html

[ Voor 16% gewijzigd door DJMaze op 19-08-2015 16:57 ]

[Douweegbertje]

DJMaze schreef op woensdag 19 augustus 2015 @ 16:55:
PHP werkt prima, de ontwikkelaars zijn brak.
En in elke taal zitten brakke ontwikkelaars.

Kijk nou naar jQuery, iedereen zweert er bij als je op stackoverflow kijkt.
Persoonlijk heb ik er een gruwelijke hekel aan (met name op mobiel).
Open eens een WordPress (ja php) website met een YOO theme op mobiel, en nee dat ligt niet aan PHP.

Waarom PHP projecten de memory_limit moeten ophogen ligt aan de ontwikkelaars.
Al mijn projecten volstaan prima met een memory_limit van 8MB.

En ja elke taal heeft zijn WTF's en is slecht, maar niet zo slecht als de persoon die het gebruikt.

Zelfde geld trouwens ook voor OS'en, de één zegt OSX, de ander Windows, en weer een ander GNU/Linux
Zoals hier duidelijk is: http://www.computerworld....led-windows-platform.html

Not sure if sarcasme of..
PHP werkt wel prima, maar zit niet prima in elkaar. Twee dingen eigenlijk.

Ben ik nu trouwens ook slecht als ik het niet haal met 8mb memory, of ben je gewoon onervaren in het daadwerkelijk weten hoe snel iets opvult vanwege de de manier hoe PHP werkt?
Lees gewoon even: https://nikic.github.io/2...rays-really-Hint-BIG.html

Prima als je altijd je standaard portfolio websites maakt, maar op het moment dat je even wat meer doet met data loop je zo tegen de 8MB aan. Pak dan nog even het parsen van bijvoorbeeld XML objecten erbij en voila.. vol.

Hell, die van mij staat zelfs op een halve gig. En nee dat is niet slecht, ik gebruik PHP soms voor dingen waarbij ik dat geheugen voor nodig heb. Een .exe mag wel 1 gig geheugen gebruiken maar mijn script die soms het zelfde doet/kan mag maar 8MB gebruiken?

[Caelorum]

DennusB schreef op woensdag 19 augustus 2015 @ 15:33:
[...] Ik snap ook niet wat iedereen altijd loopt te bitchen op PHP, als ik bijvoorbeeld .NET site's wel eens zie, man man man wat een draken kunnen dat worden, geheugenlekken, CPU opslokken, "opwarmen" van je site bij de eerste hit enz enz, dat heeft PHP allemaal niet.

Dat heeft dan weer niets te maken met .NET of de taal, maar met de architectuur van de website. Het zijn (bewuste) designkeuzes die leiden tot dingen als caches opwarmen.

[NMe]

Heel veel dingen die PHP worden aangerekend zijn trouwens niet zo zeer problemen met de taal maar problemen met het framework. Daarmee zijn het nog steeds problemen die opgelost moeten worden, maar zeggen dat PHP als taal zuigt omdat de functienamen niet altijd consistent zijn is net zoiets als zeggen dat C# zuigt omdat er iets mis is met .NET. Dat zijn over het algemeen dingen die je al snel weg-abstraheert in een goed framework en dus is de impact van die problemen te verwaarlozen.

Aan de andere kant heb je natuurlijk problemen die echt uit de taal voortkomen, en die zullen wat lastiger op te lossen zijn (en waarschijnlijk ook nooit opgelost worden). Bijvoorbeeld het punt dat "foo" == TRUE en "foo" == 0 maar tegelijkertijd TRUE != 0 is een behoorlijke designflaw, maar de kans dat daar ooit iets aan gedaan wordt lijkt me nihil zolang de ontwikkelaars van PHP vast blijven houden aan het supporten van legacy...

Douweegbertje schreef op woensdag 19 augustus 2015 @ 18:50:
Hell, die van mij staat zelfs op een halve gig. En nee dat is niet slecht, ik gebruik PHP soms voor dingen waarbij ik dat geheugen voor nodig heb. Een .exe mag wel 1 gig geheugen gebruiken maar mijn script die soms het zelfde doet/kan mag maar 8MB gebruiken?

Je kan die geheugenlimiet toch gewoon ophogen? Gezien de originele doelgroep is 8MB helemaal geen vreemde default.

[ Voor 21% gewijzigd door NMe op 19-08-2015 20:33 ]

[Douweegbertje]

NMe schreef op woensdag 19 augustus 2015 @ 20:31:


Je kan die geheugenlimiet toch gewoon ophogen? Gezien de originele doelgroep is 8MB helemaal geen vreemde default.

Ging over:

Waarom PHP projecten de memory_limit moeten ophogen ligt aan de ontwikkelaars.
Al mijn projecten volstaan prima met een memory_limit van 8MB.

In de trend van dat de ontwikkelaar slecht is.

PHP werkt prima, de ontwikkelaars zijn brak.

[Antrax]

Ik heb altijd een regel voor programmeurs die een afkeer hebben tegen PHP-programmeurs zoals ik: If you've never written a line of code in your life, or if you've already learned something that can both do the job, and work the way you expect - then by all means, stay as far away from PHP as you can

[NMe]

Douweegbertje schreef op woensdag 19 augustus 2015 @ 21:00:
[...]

Ging over:

[...]

In de trend van dat de ontwikkelaar slecht is.

Oh, ja, dat is een beetje onzin inderdaad. Ik durf zomaar te beweren dat ik een goede programmeur ben (of in elk geval een goede PHP-programmeur) maar ik heb toch echt forse projecten die nevernooit genoeg hebben aan 8MB. Voor mijn grootste project is er al 16MB aan geheugen in gebruik voordat ik überhaupt aan mijn eigen controllercode toe kom.

[gekkie]

NMe schreef op woensdag 19 augustus 2015 @ 21:44:
[...]
Oh, ja, dat is een beetje onzin inderdaad. Ik durf zomaar te beweren dat ik een goede programmeur ben (of in elk geval een goede PHP-programmeur) maar ik heb toch echt forse projecten die nevernooit genoeg hebben aan 8MB. Voor mijn grootste project is er al 16MB aan geheugen in gebruik voordat ik überhaupt aan mijn eigen controllercode toe kom.

Tssss php-keizer af hoor .. 640K ought to be enough for anybody

[Gomez12]

Caelorum schreef op woensdag 19 augustus 2015 @ 20:29:
[...]

Dat heeft dan weer niets te maken met .NET of de taal, maar met de architectuur van de website. Het zijn (bewuste) designkeuzes die leiden tot dingen als caches opwarmen.

Het nadeel is dat het een beetje half-half is.

In php heb je die designkeuzes helemaal niet. Als ik een web-app maak die maar 1 current user hoeft te hebben maar die snel requests moet kunnen doen dan kan ik in php die user helemaal niet netjes cachen.
Of ik moet naar externe apps grijpen (memcached etc) of naar suboptimale caching op bijv disk oid of ik kan kijken naar het laden van de user om dat te versnellen, maar binnen php kan ik er niet echt iets mee. Alles is een nieuwe request.

Maar aan de andere kant zie ik in andere talen vaak genoeg dingen in caches staan waarvan ik me echt afvraag : Wat moet dat in een cache op dat niveau...
Resultaten van een query moet je niet in een webserver cache gaan stoppen, maar ik zie het geregeld gebeuren.

[Webgnome]

DJMaze schreef op woensdag 19 augustus 2015 @ 16:55:....
Waarom PHP projecten de memory_limit moeten ophogen ligt aan de ontwikkelaars.
Al mijn projecten volstaan prima met een memory_limit van 8MB.
...

Zonder dat je weet waar andere ontwikkelaars aan werken zeg je dat deze brak zijn omdat jou projecten het makkelijk af kunnen met 8mb.. nou top redenatie hier.. Ik heb jaren met de mening gelopen dat PHP brak/kak was en als ik het vergelijk met mijn lievelingstaaltje Java is het ook wel een beetje vervelend om mee te werken door dat het niet static/strong typed is. Maar voor de rest kun je er heel leuke dingen mee doen.

The right tool for the right job is mijn advies. Als jij een website in elkaar moet zetten dan is PHP nog steeds een keuze tenzij je natuurlijk de node.js kant op wil gaan. Wil je statefull websites maken gebruik dan Tomcat of iets dergelijks.

even offtopic: De huidige ontwikkeling van Nodejs en alles in javascript gaan /willen doen daar gruwel ik pas van. Waarom zou je in een , voor mijn gevoel, onvolwassen taal hele sites in elkaar gaan lopen hacken? Maar dat heeft natuurlijk ook weer te maken met mijn onervarenheid met die systemen.

[NMe]

Gomez12 schreef op woensdag 19 augustus 2015 @ 22:57:
[...]

In php heb je die designkeuzes helemaal niet. Als ik een web-app maak die maar 1 current user hoeft te hebben maar die snel requests moet kunnen doen dan kan ik in php die user helemaal niet netjes cachen.
Of ik moet naar externe apps grijpen (memcached etc) of naar suboptimale caching op bijv disk oid of ik kan kijken naar het laden van de user om dat te versnellen, maar binnen php kan ik er niet echt iets mee. Alles is een nieuwe request.

Gezien de aard van de HTTP-standaard vind ik dat niet per se gek. Goed, dat het ook anders kan heeft bijvoorbeeld ASP.NET wel bewezen, maar dat maakt de PHP-manier niet per se slecht. Het maakt eigenlijk vooral je application stack wat ingewikkelder.

[Gomez12]

Webgnome schreef op woensdag 19 augustus 2015 @ 23:03:
[...]
even offtopic: De huidige ontwikkeling van Nodejs en alles in javascript gaan /willen doen daar gruwel ik pas van. Waarom zou je in een , voor mijn gevoel, onvolwassen taal hele sites in elkaar gaan lopen hacken? Maar dat heeft natuurlijk ook weer te maken met mijn onervarenheid met die systemen.

offtopic:
Wedervraag (zonder waardeoordeel over NodeJS te willen uitten) : Welke taal is er al volwassen dan? Behalve Cobol / Assembly (en dan enkel de basis-specs niet met uitbreidingen) zie ik zo ongeveer alles nog overal in beweging zijn en alle richtingen op bewegen.

Het is inherent aan de tijd dat er bijna geen tijd meer is om volwassen te worden.
En het is ook van de laatste xx jaren dat er gestreefd wordt naar 1 taal voor frontend en backend (bijv GWT van Google was ook zo'n poging)

Het is zoals je zelf al zegt the right tool for the right job, en html5 etc bewegen "momenteel" voornamelijk te snel voor de reguliere talen (.Net / Java) om bij te benen en dan krijg je nieuwe talen die bepaalde jobs weer heel goed uitvoeren en daarvoor the right tools zijn

NMe schreef op woensdag 19 augustus 2015 @ 23:52:
[...]
Gezien de aard van de HTTP-standaard vind ik dat niet per se gek. Goed, dat het ook anders kan heeft bijvoorbeeld ASP.NET wel bewezen, maar dat maakt de PHP-manier niet per se slecht. Het maakt eigenlijk vooral je application stack wat ingewikkelder.

Ik las het alsof het een design-keuze voor de programmeur van de site was, niet als design-keuze voor de programmeur van de taal. En voor een site-programmeur is er in php geen keuze in bepaalde dingen, dat is al voor je gekozen.

[StM]

Je kan het in PHP ook in een shared memory segment duwen. Daar zijn extensies voor (rechtstreeks via de shm API of bv via APC waarbij je gewoon store en fetch functies hebt waar je ook gewoon objecten in kan stoppen (en die op de achtergrond worden serialized, dat wel). Je begint wel nog altijd ieder request vanaf 0 ja

[InZane]

DJMaze schreef op woensdag 19 augustus 2015 @ 16:55:
Waarom PHP projecten de memory_limit moeten ophogen ligt aan de ontwikkelaars.
Al mijn projecten volstaan prima met een memory_limit van 8MB.

Ja dat is leuk voor de website van de bakkerij op de hoek, maar bij serieuze projecten zul je toch al snel te weinig hebben aan die 8MB.

[DJMaze]

Douweegbertje schreef op woensdag 19 augustus 2015 @ 18:50:
Ben ik nu trouwens ook slecht als ik het niet haal met 8mb memory, of ben je gewoon onervaren in het daadwerkelijk weten hoe snel iets opvult vanwege de de manier hoe PHP werkt?
Lees gewoon even: https://nikic.github.io/2...rays-really-Hint-BIG.html

Prima als je altijd je standaard portfolio websites maakt, maar op het moment dat je even wat meer doet met data loop je zo tegen de 8MB aan. Pak dan nog even het parsen van bijvoorbeeld XML objecten erbij en voila.. vol.

Hell, die van mij staat zelfs op een halve gig. En nee dat is niet slecht, ik gebruik PHP soms voor dingen waarbij ik dat geheugen voor nodig heb. Een .exe mag wel 1 gig geheugen gebruiken maar mijn script die soms het zelfde doet/kan mag maar 8MB gebruiken?

Ik zeg niet dat je maar 8MB mag gebruiken, ik zeg eigenlijk dat scripts verkeerd in elkaar zitten.
Zelfs bij het inlezen van 2G xml bestanden kom ik niet boven de 8MB uit.

Alleen bij het verwerken van DSLR camera foto's heb ik 128MB geheugen nodig.

Het probleem is dat men vergeet dat PHP post processing is.
Oftewel bij elk HTTP request moet elk PHP bestand gecompileerd worden EN de rechten van elk bestand worden gecontroleerd of het mag.
Ja je lost dat op met byte code cache om een website sneller te maken, maar eigenlijk moet je jezelf afvragen: moet ik al die bestanden überhaupt wel inladen?

Zo ja, dan zou ik toch echt voor een andere taal kiezen dan PHP.

[NMe]

DJMaze schreef op donderdag 20 augustus 2015 @ 14:14:
[...]

Ik zeg niet dat je maar 8MB mag gebruiken, ik zeg eigenlijk dat scripts verkeerd in elkaar zitten.

Sorry, maar dat is onzin. Als ik een uitgebreid framework gebruik met ORM en dergelijken erin dan loopt het geheugengebruik al snel enorm op. Dat maakt zo'n framework niet een slecht idee, dat maakt die limiet gewoon ongeschikt voor jouw toepassing. Het is fijn als je zonder framework to speak of onder de 8MB kan blijven en als je daar blij mee bent moet je dat vooral blijven doen, maar zeg niet dat scripts die niet onder de 8MB blijven verkeerd in elkaar zitten, want dat is gewoon onzin.

[Gomez12]

DJMaze schreef op donderdag 20 augustus 2015 @ 14:14:
[...]

Ik zeg niet dat je maar 8MB mag gebruiken, ik zeg eigenlijk dat scripts verkeerd in elkaar zitten.
Zelfs bij het inlezen van 2G xml bestanden kom ik niet boven de 8MB uit.

Als ik alleen even dit voorbeeldje pak, dit valt niet serieus te nemen.

Of het is niets/retesimpel wat je met dat xml bestand doet, of het is traag als dikke stront wat je met dat xml bestand doet.

Geheugen is nu eenmaal nog steeds duizenden malen sneller dan disk (of het nou ssd is of niet) en met 2GB aan data is het logisch dat je een bepaald geheugengebruik hebt (hoeveel exact verschilt van bestand tot bestand etc, maar 8MB is simpelweg niet serieus te nemen) als je een beetje snelheid wilt.

Jouw DSLR camera foto's die hebben ook geen 128MB nodig "als je het maar iets beter zou schrijven", ik bedoel je kan ook gewoon foto's pixel voor pixel inlezen en daarop veranderingen doorvoeren en acties terug kan je ook gewoon de vorige bits gaan lezen. Het zal retetraag zijn en je gaat zelf wat trucjes moeten uithalen om on the fly de stream te gaan decoden en je kan er niet dingen mee doen in een acceptabele tijd, maar heck je kan wel binnen de 8MB blijven...

Programmeren / ontwikkelen is altijd een afweging van :
- Nut voor de klant vs
- Tijd/benodigd geld voor de ontwikkelaar vs
- Geld voor de hardware.

En waarschijnlijk als jij op het programmeren al 1 minuut per dag kan winnen dan heb je je hardwareinvestering om die 8MB uit te breiden er voor de komende 10 jaar er alweer uit.
Hardware is cheap tegenwoordig, er zit een bovengrens aan. Maar 8MB is in deze tijd echt onzinnig en tijd/geld verspilling voor je programmeurs die zich hierbinnen proberen te houden.

[DJMaze]

Gomez12 schreef op donderdag 20 augustus 2015 @ 16:16:
Programmeren / ontwikkelen is altijd een afweging van :
- Nut voor de klant vs
- Tijd/benodigd geld voor de ontwikkelaar vs
- Geld voor de hardware.

Helemaal mee eens hoor.
Maar even nadenken over waarvoor en hoe je PHP gebruikt is geen slecht idee.
Of je stuit op andere zaken zoals http://2bits.com/articles...c-and-php5-memcached.html

[StM]

Tja en op dezelfde pagina staat ook de oplossing. Daarnaast wordt een flink deel van dat geheugen door meerdere requests gedeeld omdat dezelfde pages steeds in de address space gemapped worden. Ik heb op een project zonder al te veel moeite (het reguliere spul + wat optimalisaties in de libs die voor een deel ook terug aangeboden zijn zover ik weet) met 8 gb ram 600-700 requests per seconde (op een reguliere pagina, niet de frontpage, die was flink zwaarder) per applicatie server gehaald waarbij de core een paar miljoen regels aan libs was waarvan een leuk aantal (ik heb geen flauw idee hoeveel) ook uitgevoerd moest worden.

Kan het sneller? Vast. Maar het was iig niet 1 van onze bottlenecks.

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