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

[Compizfox]

Hoe meer je er over leest op het internet, hoe meer je het tegenkomt: vrijwel iedereen heeft een mening over PHP, en die mening is bijna altijd dat PHP kut is.

Ik vraag me nou echter toch wel af, wat daar nou goede, concrete voorbeelden van zijn. Veel kritiek die je tegenkomt is ófwel een amusant bedoelde analogie (zoals de bekende "If PHP was a toolbox"-analogie), ófwel er is (voor mij) niet duidelijk wat er nou concreet mee bedoeld wordt.

Ik heb zelf (hobby-)ervaring in een aantal programmeertalen, waaronder C++, MATLAB, PHP (plus opmaaktalen zoals HTML en CSS). PHP is echter enige 'webdevelopmenttaal' die ik ken. Ik ben op de hoogte van Ruby on Rails en Django voor Python, maar heb er geen ervaring mee. Ik heb soms wel het gevoel dat ik die ervaring met andere webtalen mis om te begrijpen wat er nou mis is met PHP. Daarom ben ik zeker van plan om voor mijn volgende project voor de verandering eens géén PHP te pakken, maar Python of Ruby.

Er zijn uiteraard best wel dingen die ik vervelend vind aan PHP. Ik zou bijvoorbeeld graag willen dat het static typed was geweest. Als iemand die OOP heeft geleerd in C++, erger ik me er ook nog telkens aan dat PHP geen method overloading kent, wat er bijvoorbeeld voor zorgt dat je maar één constructor per class mag hebben. Daarnaast is, vergeleken met C(++), de manier hoe PHP scopes afhandelt wat raar (maar dat is een directe consequentie van het feit dat je in PHP geen variabelen kunt definiëren). Veel meer dan dat kan ik eigenlijk niet echt bedenken.

Ik vermoed ook dat veel argumenten outdated zijn, en niet meer van toepassing zijn op huidige versies van PHP. In hoe verre klopt dit?

Dan nog iets anders: ben je eigenlijk niet een beetje verplicht om PHP te gebruiken, als je een website of webapp ontwikkelt? Voor zover ik weet, bieden alle webhosters, bijna by default, een LAMP-stack aan. Als iemand die zelf dingen thuis host, is dat ook de enige serversoftware die ik nodig heb om CMS'en of webapplicaties te draaien. Er zijn af en toe wel dingen in Python geschreven (denk aan Couchpotato, SABnzbd) maar die komen altijd met hun eigen ingebouwde webserver. Met andere woorden: ik ben eigenlijk nog nooit iets tegengekomen dat onder een 'normale' webserver (zoals Apache) draait, en niet in PHP is geschreven.

Stel je schrijft een webapplicatie in Ruby of Python, en je wilt dit zelf thuis gaan hosten, onder Apache. Hoe ga je dan eigenlijk te werk? Zijn er Apache modules voor Python/Ruby net zoals er mod-php is? Of bestaat er zoals als python-fpm? En kun je überhaupt wel terecht bij de bekende hosters hiermee?

Dus, ik ben benieuwd naar jullie mening: wat is er nou eigenlijk zo slecht aan PHP?

[ Voor 3% gewijzigd door Compizfox op 18-08-2015 16:11 ]

[Merethil]

Niet echt een antwoord op je hoofdvraag, maar gewoon even terzijde: Veel webdevelopment wordt ook in C# (met of zonder .NET), Java en de momenteel hippe talen zoals Go en JS (node.js bijvoorbeeld) gemaakt.

Voordeel van bijvoorbeeld C# .NET is dat je een MVC package mee kan nemen die je een volledig webframework geeft. Dit draait prima op IIS, wat je kan krijgen op elke simpele VPS waar Windows op kan, of eventueel op een eigen server. Ook sommige (duurdere) hosters bieden deze mogelijkheid.

Java kan bijvoorbeeld draaien op Tomcat of Glassfish, waarbij die eerste gewoon een Apache-eigen webserver is. Hiervoor zijn een boel webframeworks te vinden, waaronder Play (Google), JSF (Oracle) en kleinere dingen als Jersey, Spark of zelfs het fullstack Spring Framework.

Voor JS heb je bijvoorbeeld Node.js of allerlei derivaten daarvan. Genoeg hosters voor te vinden die dat ook wel ondersteunen. Als het niet bij de één lukt kom je vanzelf eentje tegen die tegen een gelijke prijs wel die mogelijheden heeft.

GoLang (Go) van Google heeft ook genoeg mogelijkheden, zowel voor offline als online development en kan je draaien op elke simpele VPS. Daarnaast zijn er ook hosters voor te vinden, al zijn dat er lang niet zoveel als de hoeveelheid PHP hosters die je hebt idd

Bedenk je wel dat met de komst van dingen als digitalocean, je als developer ook simpel een VPS kan opzetten in allerlei vormen, waarbij je je eigen taal en framework kan inladen. Zelf heb ik een tijd een VPS gedraaid bij Strato met daarop Windows Server 2012. Draaide prima en kon daar heel makkelijk een SQL Server Express installatie op zetten, daarnaast mijn Tomcat install draaien en een prima website serveren. Uiteindelijk is het minder optimaal dan bij een hoster omdat je meer opzetwerk hebt, maar je hebt zoveel meer customizability dat je naar mijn mening beter op zoek kan naar een VPS als je het echt goede werk wil gaan doen.

Uiteraard, als je websites als een Facebook of een gemiddelde Enterprise omgeving wilt gaan draaien zul je meer nodig hebben en kan je altijd opschalen naar een dedicated server. Tot die tijd kan je voor 5 euro per maand een VPSje hebben dat veel van alles wat hierboven beschreven is kan doen. Waarom zou je jezelf dan beperken tot een hoster met weinig ruimte en alleen PHP?

[Avalaxy]

http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

[Verwijderd]

Ik vind PHP een heerlijke taal.

Voordelen:

• Enorm makkelijk te leren door eerst met HTML te beginnen en langzaam wat PHP code erin te proppen. Uiteindelijk eindig je met PHP-only en heb je de PHP code van HTML-code gescheiden.
• Goede documentatie; goede zoekfunctie die direct naar de betreffende functie gaat. Goed lettertype en kleurgebruik. Er worden voorbeelden gegeven van hoe de functie in de praktijk gebruikt kan worden. Daarnaast ook nog comments waar veel nuttige informatie te vinden is.
• Loose-type betekent dat je heel flexibel om kunt gaan - maar dit is echt een persoonlijke voorkeur.
• Goede extensies
• Brede ondersteuning onder alle webservers en frameworks.
• Jaren van bewezen stabiliteit en bruikbaarheid.

Minpunten zijn er ook:

• PHP is niet altijd even consistent. Bijvoorbeeld, de volgorde van parameters zoals 'hackstack' en 'needle' wordt nogal eens omgedraaid. Dat zorgt ervoor dat ik continu in de war ben welk parameter nu eerst moet. Andere talen doen dit beter.
• In het verleden enorm smerige constructies zoals dat alle POST en GET naar variabelen werden geconverteerd (even de naam vergeten) en slechte beveiligingen als magic_quotes_gpc die het probleem eerder verërgeren.
• Niet te compileren voor extra snelheid (al is PHP7 is alweer stukken sneller dan PHP5). Hiervoor moet je betaalde Zend framework enzovoorts voor gebruiken dacht ik.

Zomaar wat dingen die me te binnen schieten. Er zijn vast veel meer argumenten te bedenken. Bedenk echter wel dat het ene argument veel relevanter is voor een specifiek persoon dan het andere argument. Dus de afweging is ook persoonlijk. De vraag is niet of PHP een goede taal is, de vraag is of PHP een goede taal is voor jou.

[HuHu]

Het uitgebreide antwoord is reeds door Avalaxy gegeven:

Avalaxy schreef op dinsdag 18 augustus 2015 @ 16:23:
http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Mijn mening: je kunt er mee doen wat je moet doen en daarmee is het wel prima. Alles heeft positieve en negatieve kanten. Je kunt altijd wel zeiken, accepteer soms gewoon dat het is zoals het is.

Het leven wordt soms makkelijker als je standaard frameworks gebruikt (bijv. Zend Framework). Maar dat is sowieso een aanrader voor elke taal.

Maargoed, hoe meer mensen het gebruiken, hoe meer mensen je hoort zeiken. Zo zijn er ook heel veel mensen die Windows kut vinden, maar puntje-bij-paaltje draait toch 90% het.

[Douweegbertje]

Ik heb hier ook ooit al over geschreven maar ik kan het niet terug vinden. Wat mij vooral dwars zit is dat er blijkbaar een onbeschreven regel is dat PHP kut moet zijn. Iemand die nooit PHP heeft aangeraakt vindt per definitie PHP kut, net zoals JAVA.. wait for it.. traag is.
Dat zijn dus dingen die je enorm lekker kunt negeren want het gaat nergens over. Ik zie dat meer als lekker meelopen met de groep maar als je zo'n iemand zou overhoren dan hoor je waarschijnlijk alleen gestotter en geen enkel argument.

Wat verder ook nog lastig is het feit dat sommige mensen bewust dingen proberen waarbij PHP inderdaad op zijn bek gaat. Er zitten inderdaad wat flaws in, maar in mijn jaren ervaring met PHP ben ik daar nooit tegenaan gelopen. Gebruik ik juist zo weinig van PHP dat dit gebeurt? Nee, dat heeft gewoon te maken dat ik nadenk over mijn code, dingen fatsoenlijk afvang en niet de meest achterlijke voorbeelden probeer te maken zodat PHP inderdaad over de zeik gaat.

Merethil schreef op dinsdag 18 augustus 2015 @ 16:21:
Waarom zou je jezelf dan beperken tot een hoster met weinig ruimte en alleen PHP?

Omdat je met PHP iets wilt maken?
Lekker boeiend trouwens, zoveel hosters bieden gewoon een simpele VPS met Apache en je hebt daarbij zat mogelijkheden om daar van alles nog op te draaien zoals nodeJS e.d.

PHP heeft net zo goed allemaal out of the box oplossingen omtrent frameworks etc etc.

[Creepy]

Het stukje over PHP zelf sla ik even over.....

Compizfox schreef op dinsdag 18 augustus 2015 @ 16:07:
Dan nog iets anders: ben je eigenlijk niet een beetje verplicht om PHP te gebruiken, als je een website of webapp ontwikkelt? Voor zover ik weet, bieden alle webhosters, bijna by default, een LAMP-stack aan. Als iemand die zelf dingen thuis host, is dat ook de enige serversoftware die ik nodig heb om CMS'en of webapplicaties te draaien. Er zijn af en toe wel dingen in Python geschreven (denk aan Couchpotato, SABnzbd) maar die komen altijd met hun eigen ingebouwde webserver. Met andere woorden: ik ben eigenlijk nog nooit iets tegengekomen dat onder een 'normale' webserver (zoals Apache) draait, en niet in PHP is geschreven.

Nee, je bent zeker niet verpliicht om PHP te gebruiken voor een web app. Misschien bij sommige cheap-ass hosters, maar er zijn er genoeg die meer aanbieden dan een Apache met mod-php. En een eigen VPS kost ook bijna niks meer tegenwoordig zodat je dat zelf kan inrichten.

Daarnaast wil je snel van de standaard mod-php afstappen i.v.m. geheugengebruik en performance.

Stel je schrijft een webapplicatie in Ruby of Python, en je wilt dit zelf thuis gaan hosten, onder Apache. Hoe ga je dan eigenlijk te werk? Zijn er Apache modules voor Python/Ruby net zoals er mod-php is? Of bestaat er zoals als python-fpm? En kun je überhaupt wel terecht bij de bekende hosters hiermee?

Vaak starten die een eigen proces die luisteren op een eigen poort. Vervolgens kan je daar eventueel nog een webserver ala apache voorzetten zodat je die app ook (naast eventuele andere apps) via de gewone poort 80 kan draaien. Niet spannend en wordt door een beetje hoster gewoon ondersteunt. Daarnaast heb je bijv voor java een losse applicatie server waarin je Java webapps kan draaien (denk o.a. aan tomcat, Jetty, Glassfish).

Ik denk dat je een te smalle blik op de hosting wereld hebt als je denk dat er alleen maar PHP wordt gedaan en dat je zelfs daaraan je taal keuze van laat afhangen.

Overigens kan je met even 5 minuten googlen kan je o.a. voor Ruby en Python zo vinden hoe je dat via een webserver kan draaien. Zo kan je dus meerdere van die projecten laten draaien en via de webserver alsnog allemaal via poort 80 of 443 (https) benaderen.

[kwaakvaak_v2]

oh joepie... de PHP is kut discussie gebeurt een keertje niet in de coffee corner


Voor de rest is discussie ongeveer net zo nutteloos als kijken naar gras was groeit, tenzij je heel graag wilt zien hoe gras groeit natuurlijk.

PHP is kut, Java is traag, .NET is/was gesloten, Rails is een gepasseerd station, Node.JS is te nieuw.. Alles wat je kunt bedenken is er altijd wel iemand te vinden die het niets vind.. DEAL WITH IT..

Wat vooral tenenkrommend om elke keer te lezen is, dat mensen altijd eigenschappen willen hebben die niet bij het oorspronkelijke karakter van PHP als taal passen. Steeds meer enterprise design patterns, strict typing etc. PHP is vooral een getting things done taal.. Misschien niet altijd even robuust, maar wel een taal waarin je in redelijk kort tijd een hoop voor elkaar kunt krijgen. En ja, elke slechte developer kan in elke taal constructies maken waar je lul van binnenstebuiten krult.. Is dat jouw probleem? Nee... tenzij je het moet opruimen

Voorlopig is het een van de weinige stateless web georiënteerde talen, en dat kan ook zo zijn voordelen hebben. Elk request is gegarandeerd altijd 'fris' en nieuw.

[gekkie]

kwaakvaak_v2 schreef op dinsdag 18 augustus 2015 @ 16:56:
Voorlopig is het een van de weinige stateless web georiënteerde talen, en dat kan ook zo zijn voordelen hebben. Elk request is gegarandeerd altijd 'fris' en nieuw.

Mjah mijn reden om het nu eens ergens anders in te zoeken, aangezien ik vooral met websockets wil werken en daar is stateless nou niet je van het

[kwaakvaak_v2]

gekkie schreef op dinsdag 18 augustus 2015 @ 16:58:
[...]

Mjah mijn reden om het nu eens ergens anders in te zoeken, aangezien ik vooral met websockets wil werken en daar is stateless nou niet je van het

Klopt. en daar is PHP ook niet goed in. ReactPHP en consorten zijn best aardig om mee te spelen, maar halen het niet bij systemen die vanaf de grond af opgebouwd en vooral bedoeld zijn om just non-blocking event-driven zoals nodeJS.

Beetje zichzelf respecterende developer heeft ook meerdere hamers in zijn gereedschapskist liggen

[gekkie]

kwaakvaak_v2 schreef op dinsdag 18 augustus 2015 @ 17:02:
[...]
Klopt. en daar is PHP ook niet goed in. ReactPHP en consorten zijn best aardig om mee te spelen, maar halen het niet bij systemen die vanaf de grond af opgebouwd en vooral bedoeld zijn om just non-blocking event-driven zoals nodeJS.

Beetje zichzelf respecterende developer heeft ook meerdere hamers in zijn gereedschapskist liggen

Yups en je komt je zelf af en toe eens tegen. Als je iets een beetje sloppy maakt krijg je nu een afstraffing ipv dat je er mee weg komt (vooral geheugen issues kunnen heel fijn zijn, terwijl je er met stateless php nooit snel last van had).
Wat dat betreft biedt PHP impliciet een hoop gemak, echt een mooie taal waaruit een visie spreekt (of je het er mee eens bent of niet even daar gelaten) is het dan weer niet.

[ Voor 11% gewijzigd door gekkie op 18-08-2015 17:06 ]

[Merethil]

Douweegbertje schreef op dinsdag 18 augustus 2015 @ 16:43:

Omdat je met PHP iets wilt maken?
Lekker boeiend trouwens, zoveel hosters bieden gewoon een simpele VPS met Apache en je hebt daarbij zat mogelijkheden om daar van alles nog op te draaien zoals nodeJS e.d.

PHP heeft net zo goed allemaal out of the box oplossingen omtrent frameworks etc etc.

Ik zeg ook niet dat je PHP niet zou moeten gebruiken, maar dat een hoster niet meer alles hoeft te zijn. Een eigen vps kan je ook best PHP op zetten (sterker nog, het draait waarschijnlijk nog rapper ook), maar daarmee kan je ook andere kanten op.

Mijn opmerking sloeg dan ook vooral op "pin je niet teveel vast op hosters, er zijn andere oplossingen"
Excuus als ik overkwam alsof PHP kut is, ik ben er geen grote fan van maar dat is meer vanwege mijn voorliefde voor Java en C#
Ondanks dat ben ik de go-to guy voor PHP op mijn werk, gewoon omdat ik er de meeste ervaring in heb en de beste oplossingen ermee kan realiseren van ons team.

[Bosmonster]

gekkie schreef op dinsdag 18 augustus 2015 @ 16:58:
[...]

Mjah mijn reden om het nu eens ergens anders in te zoeken, aangezien ik vooral met websockets wil werken en daar is stateless nou niet je van het

Services worden nu al vaak in Node geschreven en op de client gebruiken we al JavaScript. Als je met websockets wil werken is dat ook een logische keuze.

Onze clientside buildtools (gulp, webpack, etc) zijn in Node en voor universal (isomorphic) apps krijg je JS ook als webserver/backend.

Nog even en de hele stack is gewoon JavaScript en PHP verdwijnt langzaam

* Bosmonster duikt weg

[ Voor 4% gewijzigd door Bosmonster op 18-08-2015 17:12 ]

[Compizfox]

Avalaxy schreef op dinsdag 18 augustus 2015 @ 16:23:
http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Dat artikel ben ik inderdaad al eerder tegengekomen, maar als ik eerlijk ben, schiet ik daar nog niet veel mee op.

Er worden een heleboel punten genoemd, maar de 'problemen' zijn veel te kort beschreven en worden niet uitgelegd. Ik snap dus nog niet wat de auteur er concreet mee bedoelt. Uiteraard ligt dit ook aan mijn gebrek aan formele computer science-kennis

Neem nou zoiets:

Classes are not objects. Any metaprogramming has to refer to them by string name, just like functions.

Ik begrijp niet wat dit nou concreet inhoudt, waarom het slecht is en hoe het mij in de praktijk (bij het programmeren) limiteert. Het hele artikel staat vol met dat soort gevallen.

---

Verwijderd schreef op dinsdag 18 augustus 2015 @ 16:26:
• Goede documentatie; goede zoekfunctie die direct naar de betreffende functie gaat. Goed lettertype en kleurgebruik. Er worden voorbeelden gegeven van hoe de functie in de praktijk gebruikt kan worden. Daarnaast ook nog comments waar veel nuttige informatie te vinden is.

Eens, php.net is best goed. Maar elke goede taal heeft goede documentatie, dat is niet iets wat speciaal is aan PHP.

• Loose-type betekent dat je heel flexibel om kunt gaan - maar dit is echt een persoonlijke voorkeur.

Hier ben ik het niet mee eens. Het lijkt erop dat het je flexibiliteit geeft en dat doet het ook, maar in feite zorgt het er voornamelijk voor dat de taal tolerant omgaat met 'verkeerd' programmeren.

In een taal zoals C(++) moet je elke variabele expliciet definiëren en heeft elke variabele, parameter en return value een vaste type. Bij een definiëren van een functie moet je dus bijvoorbeeld de types van de parameters én return value (of het gebrek daaraan; void) expliciet aangeven bij compile-time. Dat klinkt misschien onhandig, maar het dwingt je wel om 'netjes' te werken. Als je ergens een fout maakt, merk je dat bovendien al bij het compileren en niet tijdens het uitvoeren van het programma.

• In het verleden enorm smerige constructies zoals dat alle POST en GET naar variabelen werden geconverteerd (even de naam vergeten) en slechte beveiligingen als magic_quotes_gpc die het probleem eerder verërgeren.

Ik denk dat dit is wat ik bedoelde met "argumenten die outdated zijn". Ik heb pas PHP geleerd toen PHP4 al lang iets van het verleden was. PHP4 heb ik dus nooit meegemaakt. Ik heb dus ook geen idee wat je met het bovenstaande bedoelt

---

Creepy schreef op dinsdag 18 augustus 2015 @ 16:54:
Daarnaast wil je snel van de standaard mod-php afstappen i.v.m. geheugengebruik en performance.

Dat weet ik wel, ik gebruik dan ook geen mod-php op m'n eigen server, maar php-fpm. Maar de vraag was hoe de koppeling tussen webserver en interpreter bij andere talen dan PHP gebeurt, vandaar dat ik mod-php noemde, aangezien dat het meestgebruikte voorbeeld is.

[...]
Ik denk dat je een te smalle blik op de hosting wereld hebt als je denk dat er alleen maar PHP wordt gedaan en dat je zelfs daaraan je taal keuze van laat afhangen.

Met een VPS of een dedicated server heb je natuurlijk alle vrijheid. Ik besef ook wel dat bij grotere websites/diensten geen shared hosting gebruikt wordt.

Maar ik heb geen ongelijk als ik zeg dat bij de meeste shared hosting niets anders dan LAMP ondersteund wordt, toch? Dat limiteert zeker wel de keuze van de taal als je 'doelgroep' dat soort hosting is. Als Joomla of WordPress in Python geschreven was, was het niet zo populair geweest, omdat de websites die dat gebruiken vaak op shared hosting draaien die alleen PHP ondersteunen.

[gekkie]

Compizfox schreef op dinsdag 18 augustus 2015 @ 17:12:
[...]
Maar ik heb geen ongelijk als ik zeg dat bij de meeste shared hosting niets anders dan LAMP ondersteund wordt, toch? Dat limiteert zeker wel de keuze van de taal als je 'doelgroep' dat soort hosting is. Als Joomla of WordPress in Python geschreven was, was het niet zo populair geweest, omdat de websites die dat gebruiken vaak op shared hosting draaien die alleen PHP ondersteunen.

Of dan was de shared hosting nog steeds LAMP geweest .. maar dan met de P van Python en WSGI.

Waarom het ooit precies perl en cgi heeft verdreven weet ik niet, zit nu net weer wat in Perl te doen, en het non-verbose zijn daar van wordt je ook niet altijd vrolijk van.

[ Voor 12% gewijzigd door gekkie op 18-08-2015 17:23 ]

[xleeuwx]

Compizfox schreef op dinsdag 18 augustus 2015 @ 17:12:
[...]

Maar ik heb geen ongelijk als ik zeg dat bij de meeste shared hosting niets anders dan LAMP ondersteund wordt, toch? Dat limiteert zeker wel de keuze van de taal als je 'doelgroep' dat soort hosting is. Als Joomla of WordPress in Python geschreven was, was het niet zo populair geweest, omdat de websites die dat gebruiken vaak op shared hosting draaien die alleen PHP ondersteunen.

Plone CMS systeem is in Python geschreven (is niet zo populair maar toch). Tevens zullen deze hosters meestal ook Java of ruby accepteren maar de vraag naar PHP is gewoon groter, der zijn gewoon meer applicaties / CMS systemen / software voor geschreven.

Verder is PHP voor mij super, doordat ik het dagelijks gebruikt kan ik me huis er van betalen . even zonder dollen, voor elke taal is wat te vinden wat te zeggen en ik ben van mening dat PHP de laatste jaren echt serieus is geworden en de ergste dingen wel getackeld zijn. Dat PHP loose types gebruikt is voor de een een voordeel de andere vind het een verschrikkelijk.

[gekkie]

Voordeel van veel andere talen boven PHP is dan wel weer dat het ook bruikbaar is buiten het web domein.
Met c#, java, python kun je ook prima scripts, daemons en desktop applicaties maken.
Met php_cli kun je ook wel scripten maar ik denk dat er weinigen zijn die het doen, maar het is toch voornamelijk beperkt tot het webdomein.

[Verwijderd]

Compizfox schreef op dinsdag 18 augustus 2015 @ 17:12:
Eens, php.net is best goed. Maar elke goede taal heeft goede documentatie, dat is niet iets wat speciaal is aan PHP.

Nouja als ik zo snel even naar Python kijk... De zoekfunctie op python.org levert geen nuttige resultaten op voor functies. Daarvoor moet je op docs.python.org zijn. En om eerlijk te zijn, de documentatie lijkt mij op het eerste gezicht zeker wel inferieur aan PHP.

Inderdaad ik kan bijvoorbeeld de 'print' functie vinden als 2e zoekopdracht op docs.python.org - maar dan krijg je een pagina met allerlei functies en scrollt hij naar het stukje over 'print' - niet een eigen pagina per functie zoals ik prefereer. Daarnaast geen examples/voorbeelden van hoe de functie gebruikt wordt. Ook geen comments vanuit de community. Kortom, echt veruit minder goed dan de documentatie die PHP biedt. Voor de 'print' functie heb ik geen documentatie nodig, maar je snapt mijn punt dat bij het leren van de taal documentatie en referentie enorm belangrijk zijn.

Zo goed als PHP zie ik het eigenlijk nergens.

Hier ben ik het niet mee eens. Het lijkt erop dat het je flexibiliteit geeft en dat doet het ook, maar in feite zorgt het er voornamelijk voor dat de taal tolerant omgaat met 'verkeerd' programmeren.

In een taal zoals C(++) moet je elke variabele expliciet definiëren en heeft elke variabele, parameter en return value een vaste type. Bij een definiëren van een functie moet je dus bijvoorbeeld de types van de parameters én return value (of het gebrek daaraan; void) expliciet aangeven bij compile-time. Dat klinkt misschien onhandig, maar het dwingt je wel om 'netjes' te werken.

Inderdaad het dwingt je; het dwingt je eigenlijk tot een model waarbij je op papier het programma ontwerpt en dit vervolgens vertaalt naar een C-implementatie. Dat vereist een manier van werken zoals met UML enzovoorts. Het werkt vast heel goed in bedrijfsmatige omgevingen waarbij je één iemand of groep hebt die de applicatie ontwerpt, en een ander(e groep) die de implementatie schrijft.

Maar als je zoals ik gaandeweg je applicatie bedenkt en uitbreidt, is het helemaal niet handig dat je vooraf alles moet opgeven. Ik zie meer in type-casting; dat je weet wat er gebeurt met de data en zodoende netjes werkt omdat je alle mogelijkheden wat het programma zou kunnen doen met verschillende input, goed genoeg afdekt. Dat is meer mijn programmeerstijl en daarom dat ik denk dat het sterk persoonlijk is.

Ik geef wel toe dat het makkelijker is met PHP om slecht te programmeren dan met andere talen. Maar dat betekent nog niet dat het moeilijker is om netjes te programmeren. En met netjes bedoel ik dat je als programmeur de applicatie laat doen wat het hoort te doen; dus dat er geen mogelijke input is die tot ongewenste output leidt.

[Douweegbertje]

Bosmonster schreef op dinsdag 18 augustus 2015 @ 17:10:
[...]


Services worden nu al vaak in Node geschreven en op de client gebruiken we al JavaScript. Als je met websockets wil werken is dat ook een logische keuze.

Onze clientside buildtools (gulp, webpack, etc) zijn in Node en voor universal (isomorphic) apps krijg je JS ook als webserver/backend.

Nog even en de hele stack is gewoon JavaScript en PHP verdwijnt langzaam

* Bosmonster duikt weg

Niet iedereen gebruikt JS (als gebruiker zijnde), en uiteindelijk heeft JS hier en daar ook genoeg flaws. Als je vindt dat PHP kudt is, dan is het nogal krom om te zeggen dat JS zo'n goede "opvolger" is
Services vereisen geen sockets, en los daarvan kan PHP ook omgaan met een socket.

Je noemt weer allemaal fancy dingen/merken op, en dat is overigens helemaal prima. Punt blijft dat je voor heel veel zaken meer dan genoeg hebt aan PHP zelf. Uiteraard is PHP dan voor zat dingen niet de geschikte taal, echter zou een fatsoenlijke programmeur de juiste taal voor de job moeten kiezen. De verkeerde kiezen (of al op zijn minst vergelijken met iets anders, appels en peren dus) is de fout van de programmeur, niet de taal.

Ik doe nu genoeg in .NET en dat is een bewuste keuze omdat het krachtiger is op bepaalde vlakken. Soms ben ik daar heel blij mee, echter aan de andere kant bouw ik weer zat leuke dingen in PHP die je nooit in .NET zo snel en efficiënt had kunnen doen.

gekkie schreef op dinsdag 18 augustus 2015 @ 17:30:
Voordeel van veel andere talen boven PHP is dan wel weer dat het ook bruikbaar is buiten het web domein.
Met c#, java, python kun je ook prima scripts, daemons en desktop applicaties maken.
Met php_cli kun je ook wel scripten maar ik denk dat er weinigen zijn die het doen, maar het is toch voornamelijk beperkt tot het webdomein.

Je noemt eigenlijk net allemaal dingen op die ook mogelijk zijn met PHP Ik snap heel goed je punt, maar het is gewoon zo dat PHP niet krachtig is voor het OS van de client zelf. Het is inderdaad gebaseerd om in je browser te draaien en daar zitten alle functionaliteiten. Iets lokaal bij de gebruiker uitvoeren zal niet gaan. Logisch ook, als servertaal zijnde

[ Voor 21% gewijzigd door Douweegbertje op 18-08-2015 17:41 ]

[Feanathiel]

Verwijderd schreef op dinsdag 18 augustus 2015 @ 17:34:
[...]
Maar als je zoals ik gaandeweg je applicatie bedenkt en uitbreidt, is het helemaal niet handig dat je vooraf alles moet opgeven. Ik zie meer in type-casting; dat je weet wat er gebeurt met de data en zodoende netjes werkt omdat je alle mogelijkheden wat het programma zou kunnen doen met verschillende input, goed genoeg afdekt. Dat is meer mijn programmeerstijl en daarom dat ik denk dat het sterk persoonlijk is.
[...]

Ik denk dat dit inderdaad persoonlijk is. Ik moet er bijvoorbeeld niet aan denken dat ik iets naar (noem eens wat...) int probeer te casten en als implementerende kant maar verantwoordelijk te zijn wat er mee gebeurd.

Uiteindelijk komt dat allemaal wel weer goed, omdat het in de documentatie prima benoemd staat:
- https://secure.php.net/manual/en/types.comparisons.php
- https://secure.php.net/ma...age.types.integer.casting

Maar dan nog, een foutje zoals in de eerder genoemde link staat is zo gemaakt ( strpos(...) ==> false, $var[false] => $var[0] ), en dat zou, wat mij betreft de taal in kunnen helpen dat deze 'fouten' niet snel gemaakt kunnen worden. Ik vraag mij dan ook af of je zo snel features kunt blijven produceren zonder dat deze steeds omvallen, en/of het dan niet efficiënter is om dan een strictere taal te nemen. Volgens mij nog steeds persoonlijk, daar niet van.

[Creepy]

Verwijderd schreef op dinsdag 18 augustus 2015 @ 17:34:
[...]
Inderdaad het dwingt je; het dwingt je eigenlijk tot een model waarbij je op papier het programma ontwerpt en dit vervolgens vertaalt naar een ]C-implementatie. Dat vereist een manier van werken zoals met UML enzovoorts. Het werkt vast heel goed in bedrijfsmatige omgevingen waarbij je één iemand of groep hebt die de applicatie ontwerpt, en een ander(e groep) die de implementatie schrijft.

Maar als je zoals ik gaandeweg je applicatie bedenkt en uitbreidt, is het helemaal niet handig dat je vooraf alles moet opgeven. Ik zie meer in type-casting; dat je weet wat er gebeurt met de data en zodoende netjes werkt omdat je alle mogelijkheden wat het programma zou kunnen doen met verschillende input, goed genoeg afdekt. Dat is meer mijn programmeerstijl en daarom dat ik denk dat het sterk persoonlijk is.

Je kan wat jij wil doen in elke taal/omgeving doen. Dat je bijv. strict typing hebt dwingt je niet tot het maken van dit soort documentatie of tot het van a-z uitdenken van de code waarna een codemonkey het simpelweg nog moet gaan kloppen. Dat is echt onzin. Klein beginnen en gaandeweg uitbreiden kan in elke omgeving. Dus jouw stijl kan je ook buiten PHP prima toepassen.

Ik geef wel toe dat het makkelijker is met PHP om slecht te programmeren dan met andere talen. Maar dat betekent nog niet dat het moeilijker is om netjes te programmeren. En met netjes bedoel ik dat je als programmeur de applicatie laat doen wat het hoort te doen; dus dat er geen mogelijke input is die tot ongewenste output leidt.

Nah, daar vergis je je in. In C of C++ is het minstens net zo makkelijk om jezelf in de voet te schieten. Daarnaast denk ik dat netjes onwikkelen een stuk meer is dan dat er geen ongewenste output mogelijk is. Je hebt ook nog vaak wensen aan de onderhoudbaarheid van de code En niet onderhoudbare code is in elke omgeving te schrijven, evenals onderhoudbare code.

[ Voor 21% gewijzigd door Creepy op 18-08-2015 18:04 ]

[gekkie]

Verwijderd schreef op dinsdag 18 augustus 2015 @ 17:34:
[...]
Nouja als ik zo snel even naar Python kijk... De zoekfunctie op python.org levert geen nuttige resultaten op voor functies. Daarvoor moet je op docs.python.org zijn. En om eerlijk te zijn, de documentatie lijkt mij op het eerste gezicht zeker wel inferieur aan PHP.

Inderdaad ik kan bijvoorbeeld de 'print' functie vinden als 2e zoekopdracht op docs.python.org - maar dan krijg je een pagina met allerlei functies en scrollt hij naar het stukje over 'print' - niet een eigen pagina per functie zoals ik prefereer. Daarnaast geen examples/voorbeelden van hoe de functie gebruikt wordt. Ook geen comments vanuit de community. Kortom, echt veruit minder goed dan de documentatie die PHP biedt. Voor de 'print' functie heb ik geen documentatie nodig, maar je snapt mijn punt dat bij het leren van de taal documentatie en referentie enorm belangrijk zijn.

Zo goed als PHP zie ik het eigenlijk nergens.

Het is tegenwoordig wel beter, maar de user comments hebben niet altijd uitgeblonken in "best practices".
Er is wel een hoop verbetering, maar er zouden nog wel wat dingen definitief overboord gemikt mogen worden en dus gewoon niet meer bestaan en niet meer configureerbaar zijn in een php.ini.

[DexterDee]

Voor wie PHP wil gebruiken met static typing, type aliasing en generics moet eens kijken naar hack. Dat is PHP voor puristen waarbij een aantal veel bekritiseerde language constructs van PHP zijn herontworpen. Maar dan moet je niet gaan janken dat het op 99% van de shared hosts niet draait

[Bosmonster]

Douweegbertje schreef op dinsdag 18 augustus 2015 @ 17:36:
[...]


Niet iedereen gebruikt JS (als gebruiker zijnde), en uiteindelijk heeft JS hier en daar ook genoeg flaws. Als je vindt dat PHP kudt is, dan is het nogal krom om te zeggen dat JS zo'n goede "opvolger" is
Services vereisen geen sockets, en los daarvan kan PHP ook omgaan met een socket.

Je noemt weer allemaal fancy dingen/merken op, en dat is overigens helemaal prima. Punt blijft dat je voor heel veel zaken meer dan genoeg hebt aan PHP zelf. Uiteraard is PHP dan voor zat dingen niet de geschikte taal, echter zou een fatsoenlijke programmeur de juiste taal voor de job moeten kiezen. De verkeerde kiezen (of al op zijn minst vergelijken met iets anders, appels en peren dus) is de fout van de programmeur, niet de taal.

Ik zeg niet dat er wat mis is met PHP of dat JavaScript beter is.

Wat ik zeg is dat de toekomst waarschijnlijk ligt bij universele apps en die vereisen een platform wat reikt van de backend tot de frontend. Momenteel is er maar 1 taal/platform dat dat ondersteunt.

http://www.infoq.com/news...flix-universal-javascript
om maar een recent voorbeeld te noemen

Ik loop hier zelf ook tegen deze issues aan. Onze services zijn grotendeels deels in Node, onze frontend stack voor nieuwe applicaties is JavaScript. Ik zou dolgraag door willen groeien en deze apps universal maken en het onderhoud vele malen eenvoudiger maken (en performance een stuk beter), maar dat kan niet doordat ik afhankelijk ben van een PHP backend.

[ Voor 12% gewijzigd door Bosmonster op 18-08-2015 18:22 ]

[RayNbow]

Compizfox schreef op dinsdag 18 augustus 2015 @ 17:12:
Neem nou zoiets:

[...]

Ik begrijp niet wat dit nou concreet inhoudt, waarom het slecht is en hoe het mij in de praktijk (bij het programmeren) limiteert. Het hele artikel staat vol met dat soort gevallen.

Classes are not objects. Any metaprogramming has to refer to them by string name, just like functions.

Nu verschilt dit nog al per taal, maar wat hier simpelweg beschreven staat is dat classes in PHP "speciaal" zijn. Het volgende is bijv. niet mogelijk in PHP:

PHP:

class Foo {

   var $x;
   
   function Foo($x) 
   {
       $this->x = $x;
   }

}

$x = Foo; // dit geeft een fout...

Maar dezelfde code werkt wel in bijv. Python:

Python:

class Foo:
    def __init__(self, x):
        self.x = x

x = Foo # geen enkel probleem

Nu is dit een enorm klein voorbeeld met geen enkele toepassing, dus het is misschien nu nog lastig in te zien wat je hiermee nou kunt.

[StM]

PHP:

$x = 'Foo';
new $x();

Maar dit werkt wel, ook al gruw ik er van Ik moet de situatie nog tegenkomen waarbij het echt een beperking is Dit is meer iets voor de theoretisch CS puristen.

[RayNbow]

StM schreef op dinsdag 18 augustus 2015 @ 18:29:

PHP:

$x = 'Foo';
$x();

Maar dit werkt wel, ook al gruw ik er van Ik moet de situatie nog tegenkomen waarbij het echt een beperking is Dit is meer iets voor de theoretisch CS puristen.

Maar in dat geval is $x een string, geen class-object. Hoe benader ik Foo's members via $x?

[gekkie]

String to class cast ? *ieks*

[StM]

RayNbow schreef op dinsdag 18 augustus 2015 @ 18:33:
[...]

Maar in dat geval is $x een string, geen class-object. Hoe benader ik Foo's members via $x?

PHP:

$z = "m_foo";

$y = new $x();
$a = $y->$z;

gekkie schreef op dinsdag 18 augustus 2015 @ 18:33:
String to class cast ? *ieks*

Die reactie heb je vooral *omdat het niet zo hoort* Het werkt prima, al hou ik er ook niet van.

[ Voor 30% gewijzigd door StM op 18-08-2015 18:39 ]

[DexterDee]

Dit werkt in PHP wel:

PHP:

$example = function () {
    echo "Hello World";
};

$example();

Niet echt een class closure, maar function of method closures worden ondersteund. Je kunt een closure ook type-hinten.

[gekkie]

StM schreef op dinsdag 18 augustus 2015 @ 18:35:
Die reactie heb je vooral *omdat het niet zo hoort* Het werkt prima, al hou ik er ook niet van.

Mjah is de vraag wel weer of het nou zo zeer "by design" was, of dat het er bij gefrummeld moest worden.

[RayNbow]

StM schreef op dinsdag 18 augustus 2015 @ 18:35:
[...]

PHP:

$z = "m_foo";

$y = new $x();
$a = $y->$z;

Erm, nee? Op de laatste regel verwijs je naar een member van $y, niet van Foo.

[StM]

Static members kan je ook benaderen, maar dan krijg je wel een behoorlijk awkward syntax:

PHP:

$x::$$z

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

Mjah is de vraag wel weer of het nou zo zeer "by design" was, of dat het er bij gefrummeld moest worden.

Tja, wanneer is iets design en wanneer erin hacken. Wss is het er bij gehacked, maar dat komt vooral omdat Rasmus een ongelooflijke idioot is zonder enige kennis van language design en absoluut niks van anderen aan wil nemen.

[ Voor 66% gewijzigd door StM op 18-08-2015 19:15 ]

[gekkie]

StM schreef op dinsdag 18 augustus 2015 @ 19:12:
Tja, wanneer is iets design en wanneer erin hacken. Wss is het er bij gehacked, maar dat komt vooral omdat Rasmus een ongelooflijke idioot is zonder enige kennis van language design en absoluut niks van anderen aan wil nemen.

Zal er wel vanaf hangen wanneer het er bij gehacked is, zoveel heeft hij er tegenwoordig toch niet meer mee van doen ? In ieder geval geen BDFL zoals Larry Wall of van Rossum.

[StM]

Ik durf niet te zeggen wat hij de laatste tijd allemaal uitspookt, ik volg het niet zo intensief meer. Ik had m'n buik er aardig van vol na een paar flinke aanvaringen / discussies met hem over een aantal van die absurde keuzes en "optimalisaties" zoals hij het zelf noemt.

[Barryvdh]

Dingen als scalar type hinting en return types komen ook in PHP7 he, dat dit jaar nog verschijnt. Daarnaast ook wat verwijderen van deprecated libraries en dingen wat logischer maken.

https://blog.engineyard.com/2015/what-to-expect-php-7

[gekkie]

Barryvdh schreef op dinsdag 18 augustus 2015 @ 21:01:
Dingen als scalar type hinting en return types komen ook in PHP7 he, dat dit jaar nog verschijnt. Daarnaast ook wat verwijderen van deprecated libraries en dingen wat logischer maken.

https://blog.engineyard.com/2015/what-to-expect-php-7

Wat weer leidt naar:
https://wiki.php.net/rfc/...ted_functionality_in_php7

En ja toch nog tegenstemmers voor het ontbundelen van (my)sql-injection extension, met de onovertroffen mysql_real_yeah_really_i_meant_really_really_please?_pleasy_please?_escape()

[Douweegbertje]

Bosmonster schreef op dinsdag 18 augustus 2015 @ 18:18:
[...]


Ik zeg niet dat er wat mis is met PHP of dat JavaScript beter is.

Wat ik zeg is dat de toekomst waarschijnlijk ligt bij universele apps en die vereisen een platform wat reikt van de backend tot de frontend. Momenteel is er maar 1 taal/platform dat dat ondersteunt.

http://www.infoq.com/news...flix-universal-javascript
om maar een recent voorbeeld te noemen

Ik loop hier zelf ook tegen deze issues aan. Onze services zijn grotendeels deels in Node, onze frontend stack voor nieuwe applicaties is JavaScript. Ik zou dolgraag door willen groeien en deze apps universal maken en het onderhoud vele malen eenvoudiger maken (en performance een stuk beter), maar dat kan niet doordat ik afhankelijk ben van een PHP backend.

Ok ja zo bedoel ik het ook niet helemaal. Het ging meer om:

Nog even en de hele stack is gewoon JavaScript en PHP verdwijnt langzaam

Wat ik bedoel te zeggen is dat JS ook zijn tekortkomingen heeft en weer niet -de- oplossing is. Hoe dan ook ga je dat IMO altijd blijven houden. Iets met



Maar dan met nieuwe technieken, libs of w/e.

En uiteindelijk, goede programmeurs dat we zijn; kiezen we voor een mix van oplossing om DE oplossing te maken voor ons specifiek probleem.

[Barryvdh]

gekkie schreef op dinsdag 18 augustus 2015 @ 21:27:
[...]

Wat weer leidt naar:
https://wiki.php.net/rfc/...ted_functionality_in_php7

En ja toch nog tegenstemmers voor het ontbundelen van (my)sql-injection extension, met de onovertroffen mysql_real_yeah_really_i_meant_really_really_please?_pleasy_please?_escape()

Maar rasmus was wel voor

[Douweegbertje]

gekkie schreef op dinsdag 18 augustus 2015 @ 21:27:
[...]

Wat weer leidt naar:
https://wiki.php.net/rfc/...ted_functionality_in_php7

En ja toch nog tegenstemmers voor het ontbundelen van (my)sql-injection extension, met de onovertroffen mysql_real_yeah_really_i_meant_really_really_please?_pleasy_please?_escape()

Heb je ook daadwerkelijk gelezen waarom? Het zijn gewoon valide argumenten hoor.

Dat iemand 'nah' vote betekend niet dat hij tegen mysql is, maar wel tegen de snelheid van het deprecated maken!

[gekkie]

Barryvdh schreef op dinsdag 18 augustus 2015 @ 22:00:
[...]
Maar rasmus was wel voor

Bij mij staat tie juist bij tegen .. misschien heeft tie randomchoice() gekozen
(bij de ereg wel weer voor)

[ Voor 5% gewijzigd door gekkie op 18-08-2015 22:02 ]

[gekkie]

Douweegbertje schreef op dinsdag 18 augustus 2015 @ 22:02:
[...]
Heb je ook daadwerkelijk gelezen waarom? Het zijn gewoon valide argumenten hoor.

Dat iemand 'nah' vote betekend niet dat hij tegen mysql is, maar wel tegen de snelheid van het deprecated maken!

Het gaat hier nog alleen maar om het ontbundelen .. standaard niet meer meeleveren dus van de beroerdste deprecated extension om met mysql te babbelen.
Als je nog steeds wil mag je dus ook bij een "yes" nog steeds die al eeuwen deprecated extension gebruiken en via pecl of github (ja er bestaat al een php7 versie van de extension) gebruiken.

En nog zijn er dus lui die er kennelijk niet definitief vanaf willen, je komt die extension zelfs hier op tweakers nog steeds tegen bij lui die eens wat met php en mysql willen maken.

Waar is de boter op het hoofd smiley when you need it.

[Martindo]

Dit is volgens mij echt een discussie die niet zal eindigen. Persoonlijk vind ik .NET erg fijn omdat ik het op me werk gebruik en thuis veel in C# programmeer. En als student zijnde kun je via Dreamspark een gratis Azure subscription krijgen om een webapp te runnen. En Azure heeft weer vlekkeloze integratie met Git(Hub) om de master branch in de repository automatisch te deployen.

Maar voor kleine dingetjes gebruik ik PHP nog wel.

En aan de DB kant draai ik MySQL want dat had ik toch al draaien. Eventueel een VPS met windows + sqlserver

[ Voor 11% gewijzigd door Martindo op 18-08-2015 22:25 ]

[Barryvdh]

gekkie schreef op dinsdag 18 augustus 2015 @ 22:02:
[...]

Bij mij staat tie juist bij tegen .. misschien heeft tie randomchoice() gekozen
(bij de ereg wel weer voor)

Ow oeps, keek bij de verkeerde extensie

[Douweegbertje]

gekkie schreef op dinsdag 18 augustus 2015 @ 22:06:
[...]

Het gaat hier nog alleen maar om het ontbundelen .. standaard niet meer meeleveren dus van de beroerdste deprecated extension om met mysql te babbelen.
Als je nog steeds wil mag je dus ook bij een "yes" nog steeds die al eeuwen deprecated extension gebruiken en via pecl of github (ja er bestaat al een php7 versie van de extension) gebruiken.

En nog zijn er dus lui die er kennelijk niet definitief vanaf willen, je komt die extension zelfs hier op tweakers nog steeds tegen bij lui die eens wat met php en mysql willen maken.

Waar is de boter op het hoofd smiley when you need it.

Ik snap het wel, maar het is "pas" deprecated sinds 5.5... Dat is heel het punt. Weet je wel niet hoe weinig mensen al over zijn op 5.5. Dat één van de redenen om het deprecated te houden tot 1 extra versie

Men wilt er zeker wel definitief van af, maar er zijn meerdere factoren die mee spelen. Ook één van de redenen is dat het niet perse super slecht is, alleen de gebruiker zelf kan het slecht "houden" c.q. "maken". Een simpele wrapper en je merkt het verschil niet (even heeeel kort door de bocht).

[mbarie]

Wat ik volgens mij nog niet heb gezien in dit topic is dat PHP oorspronkelijk nooit bedoeld is als programmeertaal. In essentie is het een uit de hand gelopen hobbyproject waaraan steeds meer functionaliteiten zijn toegevoegd om later geleidelijk een grote schare users te verwerven. Alles onder het mom van 'getting things done' (wat ik eerder in dit topic al vermeld heb gezien). Dat zie je nu nog steeds terug (ook omdat compatibility een big deal is).

Tegenwoordig zijn er voldoende frameworks die helpen dat weg te abstraheren naar consistente interfaces, iets wat binnen PHP zelf wat meer tijd nodig zal hebben. Ook de performance is aardig aan het verbeteren de afgelopen jaren.

[ Voor 19% gewijzigd door mbarie op 18-08-2015 22:53 ]

[gekkie]

Douweegbertje schreef op dinsdag 18 augustus 2015 @ 22:44:
[...]
Ik snap het wel, maar het is "pas" deprecated sinds 5.5... Dat is heel het punt. Weet je wel niet hoe weinig mensen al over zijn op 5.5. Dat één van de redenen om het deprecated te houden tot 1 extra versie

Ah ik had ergens 5.3 gelezen.

Men wilt er zeker wel definitief van af, maar er zijn meerdere factoren die mee spelen. Ook één van de redenen is dat het niet perse super slecht is, alleen de gebruiker zelf kan het slecht "houden" c.q. "maken". Een simpele wrapper en je merkt het verschil niet (even heeeel kort door de bocht).

Naja opzich lijkt php7 wel de eerste release te zijn dat er eindelijk eens iets echt uit gaan mikken.
Maarja # style comments in ini files is wel klein bier.

Doe mij dan maar een harde knip waarbij er met visie gewoon een hele hoop zooi op de schop gaat.
Doet pijn, en duurt ook een tijdje .. zie python, maar als je niet te veel haast hebt en kunt wachten tot de meeste libs over zijn dan hoef je maar 1x te refactoren, ipv bij elke release weer te kijken wat er nu weer is.

[q-enf0rcer.1]

Ik raad je aan eens te kijken naar een JavaScript oplossing. Bijvoorbeeld MEAN of Meteor.JS. Voor webdevelopment is het een meerwaarde om zowel aan de front-end als back-end in dezelfde taal te kunnen werken. Overal in objecten werken is heel prettig. Daarnaast hoef je niet continue de vertaalslag te maken tussen bijvoorbeeld PHP, MYSQL en JavaScript. Qua hosting is het iets lastiger, maar je kunt eventueel een gratis EC2 server maken op Amazon en hier zelf alle software op installeren. Ik vind PHP zelf overigens gewoon een prima taal, maar ik merk de laatste tijd dat ik heel veel dingen 'realtime' wil maken. En dat gaat met PHP en MySQL toch moeilijker dan met de eerder genoemde JavaScript stacks.

[Bosmonster]

Yeah en dat is een beetje het punt. PHP begint steeds meer een volwassen oplossing te worden, alleen is het inmiddels iets te laat en gaan ze de boot naar de nieuwe wereld van realtime en universele oplossingen missen.

Ik zou heel graag meerdere mogelijkheden zien hierin, maar vooralsnog is JavaScript de enige oplossing die volledig universeel toe te passen is (tenzij PHP naar de browser komt...). Of dat nu met Express, Meteor, React, Ember en/of wat nog is, het is allemaal JavaScript wat de klok slaat.

Dus PHP zal nog vele jaren vooruit kunnen, maar het hoogtepunt hebben ze wel achter zich.

[gekkie]

Bosmonster schreef op dinsdag 18 augustus 2015 @ 23:12:
Yeah en dat is een beetje het punt. PHP begint steeds meer een volwassen oplossing te worden, alleen is het inmiddels iets te laat en gaan ze de boot naar de nieuwe wereld van realtime en universele oplossingen missen.

Ik zou heel graag meerdere mogelijkheden zien hierin, maar vooralsnog is JavaScript de enige oplossing die volledig universeel toe te passen is (tenzij PHP naar de browser komt...). Of dat nu met Express, Meteor, React, Ember en/of wat nog is, het is allemaal JavaScript wat de klok slaat.

Dus PHP zal nog vele jaren vooruit kunnen, maar het hoogtepunt hebben ze wel achter zich.

Webassembly dus wie weet ..
maar goed javascript wordt ik ook niet echt vrolijk van. Als is het merendeel van de ellende eigenlijk meer DOM gerelateerd dan echt puur javascript. Maar een echt mooie taal kan ik het ook niet vinden.

[Laurens-R]

Oh dit wespenest weer

Hoewel ik het persoonlijk helemaal niets vind, zal ik nog even met wat cliché's smijten: Kijk naar de best tool for the job, doe gewoon waar jij je lekker bij voelt, als er een arbeidsmarkt voor is: Wat houd je tegen... Etc... Etc...

Dat gezegd hebbende vind ik php zoveel gotcha's hebben dat ik me soms afvraag waarom sommige php mensen dit als fijn en flexibel beschouwen...

[StM]

Ik zie Javascript aan de serverkant wel weer verdwijnen als deze hype ook weer overgewaaid is. Er komen dan nieuwe stacks waarbij Javascript alleen nog een compilatie target is voor de frontend. Persoonlijk vind ik Javascript een verschrikking en weiger ik er serieus (als in aanzienlijke hoeveelheden) devwerk mee te doen. Dan nog altijd liever de hele dag PHP'en of nog erger, Python.

Maar dit is misschien lichtelijk offtopic

Laurens-R schreef op dinsdag 18 augustus 2015 @ 23:24:
Dat gezegd hebbende vind ik php zoveel gotcha's hebben dat ik me soms afvraag waarom sommige php mensen dit als fijn en flexibel beschouwen...

PHP is de eerste taal geweest die ik geleerd heb (In 2004 uit m'n hoofd) en dat heeft er waarschijnlijk voor gezorgd dat ik de meeste gekke dingen wel weet, maar er geen echte last van heb. Inmiddels een taaltje of 10-20 verder heb ik wel geleerd dat iedere taal wel zijn WTFs heeft, ook al is het dan misschien een design keuze geweest ipv een organisch gegroeide hack.

Ondanks vele jaren ervaring in andere talen (en dat ik het amper meer gebruik) is het nog altijd de taal die ik het beste in de vingers heb en het snelste resultaat in boek als het om web en shell dingen gaat.

[ Voor 49% gewijzigd door StM op 18-08-2015 23:34 ]

[bwerg]

Het gehaat op PHP komt denk ik ook veel uit de hoek van mensen die een beetje in taalontwerp geïnteresseerd zijn. Het initiële ontwerp leek, euh... afwezig. Zoals al gezegd, het was een hobbyproject.

Een beetje als een auto met een wiel op de bovenkant en met drie sturen want tsjah, dat was al vastgemaakt en toen bleek het toch niet nodig maar ach, de auto werkt. Dat tegenover een taal waarin alles logisch en mooi uitgedacht is - als je in een mooi ontworpen auto rijdt lach je toch over die eerste.

En natuurlijk zegt dat niet alles over de bruikbaarheid. Want men komt er ook wel achter dat dat extra stuur in de weg zit en dat wordt met de volgende versie wel gepatcht. Na zoveel jaar wordt 't natuurlijk alsnog prima. Terwijl de mooi uitgedachte taal toch wat ouderwets begint te worden en wegens backwards compatibility ook steeds meer hacky wordt (hoi, java al valt ook dat wel mee).

Bij een college over compilerbouw moesten alle studenten (o.a. ik) laten zien hoe ze dingen gebouwd hadden. Dan kwamen er soms mooie oplossingen voorbij (goed uitgedacht, werkt prima), en soms oplossingen waar niet zo goed over na was gedacht. Want ja, het moet toch af en we zijn nu zo begonnen dus maak maar af, maar jeetje, wat een lelijke hacks. En daardoor bugs overal. Als je dat eerder genoemde blog leest, dan komt het een beetje zoals dat laatste over. En bij andere talen ziet het er weer piekfijn uit (haskell bijvoorbeeld?). De semantiek van de taal wordt dan ook meer "probeer maar uit en zie wat het doet" in plaats dat alles gewoon duidelijk gedefinieerd is. Maar wat maakt dat iemand uit die er gewoon een website mee kan bouwen.

Voetnoot: ik heb nauwelijks ervaring met PHP, ik heb vooral gelezen over de eigenaardige ontwerpkeuzes.

[ Voor 4% gewijzigd door bwerg op 18-08-2015 23:42 ]

[Gomez12]

Mijn grootste probleem met PHP is eigenlijk heel simpel : De legacy...

Zou PHP nu gelanceerd worden dan zou het best nog iets kunnen zijn (alhoewel laat), maar dan moet wel alle legacy eruit.

Tot ongeveer php5 was het echt een samenraapsel taaltje van van alles en nog wat zonder enige structuur, het werkte als je de mysterieuze syntax-volgordes exact kende (en waagde het niet om naar de manual te gaan en dan de comments te lezen want die waren nog erger).

Ergens na php5 is er een professionaliserings slag op gang gekomen die wel aardig lijkt te werken, alleen momenteel is het een zaak dat de nieuwe dingen wel redelijk lijken, alleen zit er nog zo'n hoop legacy in die zo onlogisch is dat je overal bij na moet denken.

Zo heb/had je bijv 2 methodes om strings aan te spreken (maar uiteraard niet volledig gelijk) want utf-8 dat is natuurlijk een speciale case die soms wel aparte functies vereist maar soms ook weer niet en sommige functies zijn er niet in een utf-8 variant etc.

Het is net zoiets als met de mysql-extensie, in principe zou ik zeggen : Laat die lekker erin zitten, dat ding werkt perfect en is sneller dan PDO / Mysqli etc. alleen moet je weten wanneer die te gebruiken (en dat is niet op user-input). Maarja, vanuit legacy zijn er 10 miljoen tutorials te vinden hoe je die fout moet gebruiken en daarom willen mensen het weer weg hebben. Niet omdat de extensie zelf fout is, maar omdat er legacy tutorials zijn die het fout gebruiken in een fout verleden waar er geen andere keus was.

Zo te zien willen ze met php7 er weer wat legacy uitmieteren waardoor het weer beter wordt, maar het is nog een lange weg naar een echt duidelijke taal.

[Compizfox]

Verwijderd schreef op dinsdag 18 augustus 2015 @ 17:34:
[...]
Inderdaad het dwingt je; het dwingt je eigenlijk tot een model waarbij je op papier het programma ontwerpt en dit vervolgens vertaalt naar een C-implementatie. Dat vereist een manier van werken zoals met UML enzovoorts. Het werkt vast heel goed in bedrijfsmatige omgevingen waarbij je één iemand of groep hebt die de applicatie ontwerpt, en een ander(e groep) die de implementatie schrijft.

Maar als je zoals ik gaandeweg je applicatie bedenkt en uitbreidt, is het helemaal niet handig dat je vooraf alles moet opgeven. Ik zie meer in type-casting; dat je weet wat er gebeurt met de data en zodoende netjes werkt omdat je alle mogelijkheden wat het programma zou kunnen doen met verschillende input, goed genoeg afdekt. Dat is meer mijn programmeerstijl en daarom dat ik denk dat het sterk persoonlijk is.

Nee hoor, wat jij beschrijft gaat nog weer een heel stuk verder en heeft vrij weinig met static/dynamic typing te maken.

Ik heb nog nooit met UML gewerkt en in bedenk, net als jij, gaandeweg mijn applicatie. Ik wil overigens niet zeggen dat dat ook het beste is, want het resulteert dikwijls in flinke refactoring als ik weer eens een nieuw design pattern geleerd heb

Maar inderdaad, het is gewoon een voorkeur voor het één of het ander en dus persoonlijk. Ik houd zelf van static typed talen omdat dat je dwingt om gestructureerde applicaties te schrijven. Voorbeeldje:

Je hebt een functie die een integer verwacht (als parameter). In een static typed taal zoals C kun je dat vastleggen in functiedefinitie. Bij een dynamic typed taal zoals PHP kan dat niet. Als jij dan ergens in je code een string passt naar die functie, kom je daar bij PHP pas achter tijdens run-time, en alleen als die functiecall echt wordt uitgevoerd. Een C-compiler zou het zover niet laten komen, die begint al te mekkeren tijdens het compilen. Of beter nog: je IDE merkt het al op tijdens het coden. In feite ben je dus bij dynamic typing je 'foutcontrole' aan het opschuiven van compile-time naar run-time, en dat is IMHO niet iets positiefs.

---

Douweegbertje schreef op dinsdag 18 augustus 2015 @ 17:36:
Je noemt eigenlijk net allemaal dingen op die ook mogelijk zijn met PHP Ik snap heel goed je punt, maar het is gewoon zo dat PHP niet krachtig is voor het OS van de client zelf. Het is inderdaad gebaseerd om in je browser te draaien en daar zitten alle functionaliteiten. Iets lokaal bij de gebruiker uitvoeren zal niet gaan. Logisch ook, als servertaal zijnde

Wacht even, ik ben je hier even kwijt. Je zegt dat PHP bedoeld is om in je browser te draaien? Ben je nu niet in de war met Javascript? PHP draait toch echt op de server, niet in de browser van de client (zoals Javascript)

---

DexterDee schreef op dinsdag 18 augustus 2015 @ 18:17:
Voor wie PHP wil gebruiken met static typing, type aliasing en generics moet eens kijken naar hack. Dat is PHP voor puristen waarbij een aantal veel bekritiseerde language constructs van PHP zijn herontworpen. Maar dan moet je niet gaan janken dat het op 99% van de shared hosts niet draait

Dat ziet er best leuk uit Vraag me alleen af waarom ze niet gewoon de C-syntax hebben aangehouden voor bijv. specificeren van return types.

---

RayNbow schreef op dinsdag 18 augustus 2015 @ 18:24:
Nu verschilt dit nog al per taal, maar wat hier simpelweg beschreven staat is dat classes in PHP "speciaal" zijn. Het volgende is bijv. niet mogelijk in PHP:

PHP:

class Foo {

   var $x;
   
   function Foo($x) 
   {
       $this->x = $x;
   }

}

$x = Foo; // dit geeft een fout...

Maar dezelfde code werkt wel in bijv. Python:

Python:

class Foo:
    def __init__(self, x):
        self.x = x

x = Foo # geen enkel probleem

Nu is dit een enorm klein voorbeeld met geen enkele toepassing, dus het is misschien nu nog lastig in te zien wat je hiermee nou kunt.

Maar waarom zou je dat willen inderdaad? Als ik het goed begrijp, probeer je nu een class in een variabele te proppen? Zoiets kan bv. in C++ toch net zo goed niet?

---

DexterDee schreef op dinsdag 18 augustus 2015 @ 18:38:
Dit werkt in PHP wel:

PHP:

$example = function () {
    echo "Hello World";
};

$example();

Niet echt een class closure, maar function of method closures worden ondersteund. Je kunt een closure ook type-hinten.

Dat ken ik wel, dat is gewoon een closure, aka lambda function, aka anonymous function. Snap even niet direct wat dat met het bovenstaande verhaal van classes in variabelen proppen te maken heeft.

---

Douweegbertje schreef op dinsdag 18 augustus 2015 @ 22:44:
[...]
Ik snap het wel, maar het is "pas" deprecated sinds 5.5... Dat is heel het punt. Weet je wel niet hoe weinig mensen al over zijn op 5.5. Dat één van de redenen om het deprecated te houden tot 1 extra versie

Dat is een non-argument. Als je zegt dat php5.5 blijkbaar nog zo nieuw is dat het nog weinig wordt gebruikt, dan is php7 dat wel helemaal. Met andere woorden: mensen die achterlopen qua PHP-versie, zullen ook pas later iets merken van het verwijderen van de extensie.

[Gomez12]

Compizfox schreef op woensdag 19 augustus 2015 @ 01:51:
[...]
Dat is een non-argument. Als je zegt dat php5.5 blijkbaar nog zo nieuw is dat het nog weinig wordt gebruikt, dan is php7 dat wel helemaal. Met andere woorden: mensen die achterlopen qua PHP-versie, zullen ook pas later iets merken van het verwijderen van de extensie.

Mensen zijn lui en slaan dus regelmatig een versie over, dat leidt er dan weer vaak toe dat er meerdere versies overgeslagen worden, oftewel php7 kan er sneller opstaan bij een host dan php5.5

[Douweegbertje]

Compizfox schreef op woensdag 19 augustus 2015 @ 01:51:
[...]


Wacht even, ik ben je hier even kwijt. Je zegt dat PHP bedoeld is om in je browser te draaien? Ben je nu niet in de war met Javascript? PHP draait toch echt op de server, niet in de browser van de client (zoals Javascript)

---

Nee ik zeg precies wat jij nu zegt.

[...]

Dat is een non-argument. Als je zegt dat php5.5 blijkbaar nog zo nieuw is dat het nog weinig wordt gebruikt, dan is php7 dat wel helemaal. Met andere woorden: mensen die achterlopen qua PHP-versie, zullen ook pas later iets merken van het verwijderen van de extensie.

Voor jou misschien, maar mensen kunnen nu over zonder zo'n grote verandering. Dus kunnen meer mensen migreren. Dat is prettig.
Nu heb je misschien dat mensen lang op PHP 5.5 bijvoorbeeld blijven.. puur omdat ze nog niet over kunnen.

Ik zeg overigens niet dat ik het er allemaal mee eens ben, echter snap ik heel goed waarom er zo gevote is. En daarbij, als het zo'n 'non-argument' was, waarom is het dan daadwerkelijk als argument opgevoerd en hebben meerdere mensen 'no' gevote? Hun leveren alleen kul argumenten op of..? Niet dat je perse "pro" moet zijn om in die groep te zitten maar een beetje kennis hebben ze wel, en dan niet alleen over programmeren zelf.

[RayNbow]

Compizfox schreef op woensdag 19 augustus 2015 @ 01:51:
[...]

Maar waarom zou je dat willen inderdaad? Als ik het goed begrijp, probeer je nu een class in een variabele te proppen? Zoiets kan bv. in C++ toch net zo goed niet?

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?

Maar goed, hier volgt een uitgebreider voorbeeld. Laten we beginnen met deze class:

Python:

class MemoFib(object):
    def __init__(self):
        self._memo = {}
    
    def __call__(self, n):
        return self.apply(n)
    
    def __repr__(self):
        return '<%s@%s>' % (self.__class__.__name__, id(self))
    
    def apply(self, n):
        if n not in self._memo:
            res = None
            if n == 0:
                res = 0
            elif n == 1:
                res = 1
            else:
                res = self.apply(n-1) + self.apply(n-2)
            
            self._memo[n] = res
        
        return self._memo[n]

Dit is een simpele class om Fibonacci-getallen te berekenen (en eentje die memoization toepast om de boel te versnellen). Tot zo ver niets bijzonders. We kunnen een instantie aanmaken en gebruiken:

>>> fib = MemoFib()
>>> fib(5)
5

Maar wat nu als ik voor deze class een versie nodig heb die elke method call logt? Moet ik deze class kopiëren en log statements toevoegen? Moet ik een subclass aanmaken en elke methode overerven? Moet ik de class aanpassen en een extra parameter aan de constructor meegeven die aangeeft of ik wel of niet wil loggen? Wat als ik dit ook wil doen voor andere classes?

Wanneer een class een object is net als elke andere waarde in een taal, dan kan ik op een programmeerbare wijze een nieuwe class aanmaken. In Python is iets als het volgende dus mogelijk:

Python:

LoggedFib = Logged(MemoFib, name='LoggedFib')

Dit definieert een class LoggedFib die we dan op eenzelfde manier als MemoFib kunnen gebruiken:

>>> fib = LoggedFib()
>>> fib(5)
*** Calling LoggedFib.apply(*(<LoggedFib@32016528>, 5), **{})
  *** Calling LoggedFib.apply(*(<LoggedFib@32016528>, 4), **{})
    *** Calling LoggedFib.apply(*(<LoggedFib@32016528>, 3), **{})
      *** Calling LoggedFib.apply(*(<LoggedFib@32016528>, 2), **{})
        *** Calling LoggedFib.apply(*(<LoggedFib@32016528>, 1), **{})
        *** Returning 1
        *** Calling LoggedFib.apply(*(<LoggedFib@32016528>, 0), **{})
        *** Returning 0
      *** Returning 1
      *** Calling LoggedFib.apply(*(<LoggedFib@32016528>, 1), **{})
      *** Returning 1
    *** Returning 2
    *** Calling LoggedFib.apply(*(<LoggedFib@32016528>, 2), **{})
    *** Returning 1
  *** Returning 3
  *** Calling LoggedFib.apply(*(<LoggedFib@32016528>, 3), **{})
  *** Returning 2
*** Returning 5
5

Implementatie van Logged voor de liefhebbers:

Python:

from functools import wraps

# (Note: This example only makes sense in a single threaded environment...)
def Logged(cls, name=None):
     name = 'Logged' + cls.__name__ if not name else name
     bases = (cls,)
     
     state = {'depth': 0}
     
     def logged_function(member_name, member):
         @wraps(member)
         def func(*args, **kwargs):
             indent =  ' ' * (state['depth']*2)
             print '%s*** Calling %s.%s(*%r, **%r)' % (indent, name, member_name, args, kwargs)
             
             state['depth'] += 1
             res = cls.__dict__[member_name](*args, **kwargs)
             state['depth'] -= 1
             
             print '%s*** Returning %r' % (indent, res)
             return res
         
         return func
     
     namespace = dict(
         (member_name, logged_function(member_name, member))
         for member_name, member in cls.__dict__.iteritems()
         if callable(member) and not member_name.startswith('_')
     )
     
     return type(name, bases, namespace)

[Firefly III]

-

[ Voor 100% gewijzigd door Firefly III op 23-10-2016 15:39 . Reden: Leeg vanwege privacy. ]

[gekkie]

Mjah dat vind ik toch wel een duidelijk verschil tussen PHP en Python, de mate waarin concepten zijn uitgedacht en vervolgens eigenlijk overal systematisch doorgevoerd.

[mbarie]

Wat weer terug komt op de reden dat PHP oorspronkelijk nooit bedoeld was als programmeertaal maar dat door samenloop van omstandigheden wel geworden is . Misschien moet je het zien als een enterprise-applicatie met een hoop technical debt waar (eindelijk) een flinke refactorbeurt aanstaande is/lijkt waarin eindelijk die nieuwe inzichten, kennis en functionaliteit verwerkt kan worden. Onderweg naar wat je graag zou willen dat het is, maar voorlopig nog niet daar.

[ Voor 15% gewijzigd door mbarie op 19-08-2015 10:22 ]

[bwerg]

Slarioux schreef op woensdag 19 augustus 2015 @ 10:01:
Volgens mij past hier de dooddoener "er zijn geen slechte programmeertalen, alleen slechte programmeurs" wel een beetje bij.

Wat natuurlijk flauwekul is. Een taal kan best goed of slecht uitgewerkte onderdelen hebben. Als iets sneller, robuuster, gemakkelijker, veiliger, etc. te doen is in een andere taal dan is die eerste taal daar kennelijk dus relatief slecht in. En als een taal relatief veel goede of slechte onderdelen heeft, is het een relatief goede of slechte taal.

[gekkie]

Een van de lastige punten is wel wat je onder "taal" wil rekenen.

Alleen de syntax ? ook de systemlibs ? meegeleverde extensies? veel gebruikte extensies ?

Documentatie ? Alleen meegeleverde/officiele documentatie? user comments als die bij de officiele documentatie zitten ? documentatie / examples op het gehele internet ?

Frameworks ?

[analogue]

In een ideale wereld zouden de 'quirks' van PHP het daglicht niet zien, maar de praktijk is dat een keuze voor een programmeertaal (of techniek in het algemeen) niet alleen afhankelijk is van de programmeur. PHP biedt blijkbaar een fijne balans tussen features, een lage basiskennis om er mee aan de slag te gaan, kosten etc, en die nadelen.

Ik werk zelf zeer regelmatig nog in PHP en moet ook eerlijk zeggen dat ik niet echt gehinderd wordt door inconsistencies of backward functienamen en parameters. Een goede IDE (phpStorm) en een beetje kennis van zaken maken het prima werkbaar en dat is uiteindelijk wat telt; of je een degelijke, veilige en functionele app kan maken met een begrijpelijke codebasis die onderhoudbaar is.

[ Voor 0% gewijzigd door analogue op 19-08-2015 13:37 . Reden: typo ]

[Guillome]

Ik vind PHP een fijne taal, maar inderdaad zijn mankementen.

Want naast dat Typecasting en returntypes handig en veiliger is, is het ook gewoon *geil* voor programmeurs. Zo simpel is het ook.

Zo jammer van Hack. Dan willen ze PHP concequenter en beter maken, dan doen ze nog steeds:

PHP:

public int $test;
public function blaat() : int

Aaarhg dan baal ik wel. Waarom niet concequent:

PHP:

public int blaat()

Gemiste kans..

[ValHallASW]

Guillome schreef op woensdag 19 augustus 2015 @ 13:38:
Zo jammer van Hack. Dan willen ze PHP concequenter en beter maken, dan doen ze nog steeds:

PHP:

public int $test;
public function blaat() : int

Aaarhg dan baal ik wel. Waarom niet concequent:

PHP:

public int blaat()

Gemiste kans..

Omdat blaat een functie is, en niet een int In je bovenste voorbeeld is het access modifier, type, naam. In je onderste syntax kan je tweede parameter zowel een type als een return type zijn.

[Guillome]

In C# weet ik dat het ook zo gebeurt als ik voorstelde. Volgens mij wel in meer talen.

Het is in het onderste voorbeeld een return type, zoals ook bij properties.
Is in weze precies hetzelfde. Een property geeft een type terug zoals gedeclareerd.
Een functie idem. Alleen die heeft geschreven logica om de waarde van dat type te bepalen.

[ Voor 59% gewijzigd door Guillome op 19-08-2015 13:48 ]

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