Je kunt dat woordje "documentatie" in je laatste zin ook wel weghalen
[ Voor 79% gewijzigd door een moderator op 26-08-2008 04:33 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Echter maakt succesvol het niet meteen goed. En dat het niet goed is leidt ook tot het volgende punt:
Over heel veel dingen in PHP wordt niet nagedacht. Veel neven-effecten van veel functies laten zich leiden door hoe de code geschreven is, ipv dat die neven-effecten van tevoren goed worden uitgedacht / gedocumenteerd en dat men de code daar dus ook op ontwerpt. Het gevolg hiervan is dat een wijziging in de implementatie van een functie ineens gevolgen gaat hebben voor de inmiddels gedocumenteerde bijwerkingen.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Daar heb je inderdaad een aantal hele sterke punten. Ik geef toe dat het inderdaad meer een naslagwerk is. Het hangt ook wel af van je ervaring met de documentatie (ik blijf het voor het gemak toch zo noemen
), want ik kan er uitstekend mee uit de voeten.Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Nouja, ik gebruik nooit impliciete casts in PHP 
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Nee, het is een gevolg van het feit dat de mensen bij Zend een stel eikels zijn
Onzin. Het gedrag van PHP is niet inherent aan het feit dat het loosely typed is. Dat is bijv. Javascript ook, toch geeft die false als je een int met een string vergelijkt en de string is niet castbaar naar int, terwijl het true geeft als het wel castbaar is én de int-vergelijking geeft true. Natuurlijk moet je casten om de vergelijking te doen. Maar als de cast niet kan impliceert dat dat de twee objecten ongelijk zijn aan elkaar. Wat PHP doet is simpelweg een arbitraire waarde (0) nemen als een string niet castbaar is naar int. De situatie was imho niet anders geweest als ze bijv. 1337 als die arbitraire waarde hadden gekozen. Maar dan is iedereen het er ineens over eens dat het een complete absurditeit is.
Waarom is '0' == 0 niet zinvol maar '1' == 1 wel?
Zucht. Anders lees je mijn eerste reactie hierover nog eens door. De definitie staat mij idd niet aan, maar het was slechts een voorbeeld. Waar het om gaat is hoe die definitie tot stand is gekomen, waarom het zo is gedefinieerd. Omdat dat toevallig de bijwerking was van hoe de code is opgeschreven, of omdat ze er goed over hebben nagedacht? Gezien de overall design van PHP zet ik mijn geld in op dat eerste. En dat was nou juist de aanleiding van deze discussie.
Allereerst klopt je opmerking over "hogere programmeertalen" niet. PHP is gewoon 3GL, net als C++ en Java e.d. dat zijn. Maar even los daarvan, als wat jij zegt waar zou zijn, waarom wordt er dan zo weinig gebashed op andere talen die anders zijn? Zoals bijv. javascript?
. Face it, PHP is gewoon voortgekomen uit een knullig hobbyprojectje. Het mist een degelijke definitie, en dat zie je terug in de eigenaardigheden in de taal. En natuurlijk, it gets the job done, maar dat is niet wat ik aan de kaak stel .Niet dus, zie boven.
[ Voor 33% gewijzigd door .oisyn op 25-08-2008 13:12 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
PHP is geen lagere GL dan een andere taal (waar jij op doelt); PHP is net zo 3GL als (bijv.) C#. If anything, dan is PHP zelfs een hogere GL
[ Voor 6% gewijzigd door RobIII op 25-08-2008 13:01 ]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Het is zeker een gevolg van. Als de taal niet loose-typed was, dan hadden we deze discussie niet.:
[...]
Nee, het is een gevolg van het feit dat de mensen bij Zend een stel eikels zijn
Dat is ook niet inherent aan het feit dat het loose typed is, maar het speelt wel mee. Jij zou er voor kiezen om de vergelijking tot false te evalueren (valt zeker wat voor te zeggen), maar daarmee is het mijns inziens zeker niet fout een string die niet begint met cijfers naar 0 te "casten" (want echt casten is het niet, het is meer omzetten).
Ik denk dat hij letterlijk de vergelijking "'0' = 0" bedoelt, welke inderdaad niet hardcoded in je script hoeft voor te komen. En dat gaat in feite op voor elke hardcoded vergelijking.
Het is inderdaad goed mogelijk dat deze uitkomst het gevolg is van eerder gemaakte beslissingen. Maar dat neemt niet weg dat het niet mogelijk is dat het een bewuste beslissing is geweest om dit later niet af te vangen. Ook weet je simpelweg niet of het überhaupt op die manier tot stand is gekomen. Kun je wel over speculeren maar ik heb toch echt het idee dat dat niet de discussie is die we hier voeren.
Als je kijkt naar de strictere regels, naar de mensen die het gebruiken en de manieren waarop dan kun je m.i. PHP en C++, Java, etc. niet in hetzelfde rijtje zetten.
Ik ben net als jou van mening dat kritiek op bepaalde punten, mits ondersteund met goede argumenten, helemaal geen probleem is. Maar ik vind het vreemd hoe sommige mensen PHP direct afdoen om soms redelijk triviale punten. Vaak speelt gevoel daarin een grotere rol dan objectiviteit.Natuurlijk zijn er veel napraters, maar dat neemt niet weg dat er weldegelijk wat te bashen valt met valide argumenten. Het feit dat dat populair zou zijn doet daar verder niets aan af. "Oh, shit, nu is het populair, nu kan het niet meer"
Wederom, het heeft er wel mee te maken want als PHP niet loose typed was dan zou het met de == operator gewoon naar false evalueren.
Slechte verwoording van mij, ik bedoel gewoon de strictere (en daarmee eigenlijk gewoon alle niet-loose typed) talen.PHP is geen lagere GL dan een andere taal (waar jij op doelt); PHP is net zo 3GL als (bijv.) C#. If anything, dan is PHP zelfs een hogere GL
Euh ja, dat is wat casting betekent. De term casting komt uit de metaalbewerking - je giet een type als het ware in een andere vorm. Type conversion en typecasting zijn equivalent
. Je zou het lexical casting kunnen noemen.Inmiddels niet meer nee, maar dat krijg je als mensen selectief reageren
. .oisyn in "[Alg] Slechtste programmeervoorbeelden d..." Overigens was de daadwerkelijke bugreport idd degene die Janoz daarna postte, en vergiste ik me dus in het specifieke voorbeeld. Het was verder niet mijn bedoeling om een discussie over == te ontketenen.Dan heeft de big bang er ook mee te maken, want als die er niet was dan was PHP er ook niet geweest
. Dat PHP besluit om true te returnen is geen direct gevolg van het feit dat het loose typed is - ze hadden immers ook kunnen besluiten om false te returnen. Dat ze die keuze niet meer konden maken als de situatie anders was geweest doet er in feite weinig toe.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
?? het lijkt mij zelf toch makkelijker als je van te voren al precies weet wat voor type iets is en er dan mee te rekenen dan met loose types te werken en converteer algoritmes te moeten werken en types proberen te herkennen on the fly.:
Het ontbreken van type checking in PHP is ook geen "feature", maar is gewoon gedaan omdat het de implementatie makkelijker maakt(e). En dan zit je ineens al snel vast aan backward compatibility... Het wordt in ieder geval mooi vekocht onder de illusie dat het is om het programmeren makkelijker te maken en de learning curve lager
1
2
3
4
5
6
| int i = 10;
string s = "10";
if(s.CompareTo(i.toString()) == 0)
{
//doe iets
} |
1
2
3
4
| if(10 == "10")
{
//doe iets.
} |
| Last.fm | "Mr Bent liked counting. You could trust numbers, except perhaps for pi, but he was working on that in his spare time and it was bound to give in sooner or later." -Terry Pratchett
'0' == 0 is prima. Het punt was nou juist 'aap' == 0
. Plus dat === alleen == kan vervangen. Je zit ook nog met <, <=, > en >=Ja, dat argument hoor je wel vaker. Ik vind 't kul. Gebruik dan een strong typed taal
.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Is al eerder langsgekomen, en dat is niet het geval.
Daar sluit ik me bij aan, maar wil er nog even aan toevoegen dat ook mensen die best als ervaren omschreven worden vreemde constructies kunnen bouwen als in een vroeg stadium een denkfout gemaakt word.:
Ik heb weinig toe te voegen aan wat er hier allemaal al gezegd is, maar ik wil wel even kwijt dat elke tekortkoming in PHP in principe geen ramp is voor een ervaren ontwikkelaar. Als je de eigenaardigheden van een taal kent kun je ze in je voordeel gebruiken of in elk geval zo te werk gaan dat je er niet mee te maken krijgt. Het probleem zit hem dus niet in ervaren programmeurs die met PHP werken, maar juist in zolderkamerprogrammeurtjes die dénken te kunnen programmeren en daardoor fout na fout begaan.
[ Voor 51% gewijzigd door Patriot op 26-08-2008 08:50 ]
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Verwijderd
Vanuit het oogpunt van de klant/eindgebruiker misschien, maar als developer/programmeur wil ik code zien die goed (te) onderhouden is en waarbij er geen rare/vieze constructies nodig zijn om iets toe te voegen op een later tijdstip.
Lijkt me dat dat niet enkel voor PHP geldt?
QTF. Het is tevens een van mijn grootste persoonlijke ergernissen aan PHP.
Maar de documentatie voor de == operator zegt wat anders voor int en string vergelijkingen:
Dit laatste is dan ook precies wat er gebeurd. PHP mag dan een loose typed taal zijn, er wordt niet altijd even goed gedocumenteerd wat nu waarom gebeurd met de verschillende types en dat verklaart ook waarom er door verschillende mensen anders over wordt gedacht.....
[ Voor 3% gewijzigd door Creepy op 26-08-2008 11:32 ]
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Dan moet je wel een beetje oppassen wélke eigenaardigheden je gebruikt; een beetje programmeur voelt dat wel op z'n klompen aan, maar je wil niet dat net die ene eigenaardigheid die je -tig keer gebruikt in je PHP projectje in de eerstvolgende minor release wordt 'gefixed'
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
Als je weet waar een variabele voor staat, hoef je nooit appels met peren te vergelijken. Wáárom is het nou geen wtf van de programmeur om een var waarvan de waarde een dierennaam is met een getal te vergelijken.:
Ja, dat argument hoor je wel vaker. Ik vind 't kul. Gebruik dan een strong typed taal
Die eigenaardigheden worden dan ook niet agressief opgeruimd. En dan nog zegt Nme 'of in elk geval zo te werk gaan dat je er niet mee te maken krijgt', want je kan problemen ook opzoeken natuurlijk.:
[...]
Dan moet je wel een beetje oppassen wélke eigenaardigheden je gebruikt; een beetje programmeur voelt dat wel op z'n klompen aan, maar je wil niet dat net die ene eigenaardigheid die je -tig keer gebruikt in je PHP projectje in de eerstvolgende minor release wordt 'gefixed'
[ Voor 12% gewijzigd door Voutloos op 26-08-2008 11:53 ]
{signature}
Je zal er inderdaad sowieso spaarzaam mee moeten zijn en het goed moeten documenteren. En je zal de overweging moeten maken of de kans op een fix groot is; als het al een "bug" genoemd mag worden van het PHP team.:
[...]
Dan moet je wel een beetje oppassen wélke eigenaardigheden je gebruikt; een beetje programmeur voelt dat wel op z'n klompen aan, maar je wil niet dat net die ene eigenaardigheid die je -tig keer gebruikt in je PHP projectje in de eerstvolgende minor release wordt 'gefixed'
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Dat is idd een WTF. Echter is input doorgaans gewoon een string. Bovendien zeg ik niet dat voor je redenatie best wat te zeggen is. Maar dan zou een string-int compare gewoon altijd false op moeten leveren. De discussie was de (imho) rare design-keuze in PHP. Dan moet je dat niet afdoen met "maakt geen zak uit, je moet toch geen verschillende types vergelijken". De issue was namelijk niet hoe je PHP gebruikt, maar hoe PHP ontworpen was.
)Ik gok een lage leercurve, een uitgebreide set van libraries en een overvloed aan hosting-mogelijkheden.
[ Voor 21% gewijzigd door .oisyn op 26-08-2008 12:08 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dat is niet voor iedereen, gedurende de gehele discussie duidelijk. Hoe PHP ontworpen was moge wel duidelijk zijn, getuige de originele betekenis van de afkorting.
Ik heb zelf doorgaans ook de meer wetenschappelijke insteek, met het geïnteresseerd zijn in het hoe & waarom ipv het leren van trucjes om een doel te bereiken. Maar dan nog kan je aan de huidige situatie, met de toch wel aardige b/c policy (soms te aardig
) er verder niets aan doen, behalve inderdaad constateren dat niet elke keuze ideaal was (of op de juiste basisn genomen is) en er hopelijk voor de toekomst van leren. Ik weet het wel zeker.
En het performance argument vervalt bovendien ook voor een groot deel, als je maar een opcode cache (APC, eAccelerator etc) draait.
{signature}
Zeker. Hoewel ik er niet van overtuigd ben dat de mensen bij Zend het ermee eens zijn dat dit specifieke voorbeeld een foute keuze was, en dus weer exact dezelfde keuze maken bij een nieuwe PHP die b/c zal breken:
Maar dan nog kan je aan de huidige situatie, met de toch wel aardige b/c policy (soms te aardig
Dat zal voor het overgrote deel van de scripts idd wel de belangrijkste factor zijn. Maar het is natuurlijk ook wel inherent aan de taal dat het nooit de performance kan halen van menig statically typed taal. Maar daar is het dan ook weer helemaal niet voor bedoeld.Ik weet het wel zeker.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Wat mij betreft breken ze de backwards compatibility, zolang ze er maar voor zorgen dat je de verschillende PHP versies maar eenvoudig naast elkaar kan gebruiken... Want anders gaat het weer jaren duren voordat "alle" hosting partijen door hebben dat er een nieuwe versie is.:
Zeker. Hoewel ik er niet van overtuigd ben dat de mensen bij Zend het ermee eens zijn dat dit specifieke voorbeeld een foute keuze was, en dus weer exact dezelfde keuze maken bij een nieuwe PHP die b/c zal breken
[ Voor 12% gewijzigd door Erkens op 26-08-2008 12:53 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Nou moetje niet gaan overdrijven
Dat is gedeeltelijk waar, maar er worden nu veel grote projecten in PHP geschreven die veel verder gaan dan waar het ooit voor bedoeld was. In reactie evolueert de taal ook verder, maar wordt altijd gehinderd door backward compatibility. Als je dan toch een nieuwe project begint, dan zie ik niet zo heel erg het nut van PHP in. Het is een soort C, maar dan hinderlijk loose-typed (imho), en het is een soort C++ maar dan met een hinderlijk object model. Perl vind ik overigens ook verschrikkelijk. (Ik moet ineens denken aan een 3D engine schrijven in turtle
)[ Voor 11% gewijzigd door Zoijar op 26-08-2008 16:32 ]
Ik had hem gezien maar was er van overtuigd dat dat wél zo was. Eigenwijs even getest, maar Creepy, en jij, hebben inderdaad gelijk
Het staat alleen niet vermeld waarom een string altijd naar een float/int wordt gecast, en waarom middels bovenstaande methode.
CamelCased functies komen in php voor zover ik weet niet voor. Ik doelde op het underscore gebruik bij bijvoorbeeld str_replace en strpos.
Ik meen dat het enkele jaren terug mogelijk was je aan te melden om mee te developen, en jeje eigen functies kon submitten
Ik werk een ruime 7 jaar professioneel met oa. PHP en moet die associatie helaas met je delen. Probleem van PHP is dat het zo verschrikkelijk laagdrempelig is. Iedereen met een internetverbinding en Google kan in een dag eenvoudige dynamische pagina's maken met PHP.
[ Voor 6% gewijzigd door frickY op 26-08-2008 23:07 ]
Goedendag lichtgewicht (om maar even neerbuigend te zijn). Jouw code? Als de klant ervoor heeft betaald ben ik toch eerder geneigd om te zeggen dat het de code van de klant is
( min of meer dan ). Daarbij werkt zo'n mentaliteit van code-ownership niet zo bijster goed in de praktijk naar mijn ervaring, zeker niet in team verband. Daar wil je juist stimuleren dat mensen iteratief zowel hun eigen als de code van anderen verbeteren. Kwestie van goede source version control hebben om te zien wat er precies is veranderd en waarom. Leuke bijkomstigheid is dat je het evengoed dus kan terugdraaien als je het er niet mee eens bent en daar ook een comment over kan plaatsen in de commit history. Joel Spolski van Joel on Software heeft hier ook een tijdje geleden over geschreven meen ik, en raad het je van harte aan om dat even door te nemen. (maar dat is denk ik door zijn toedoen of een regressie in LLVM zelf misschien). Link: http://llvm.org/devmtg/20..._PHP-JIT-InTwoDays_Hi.m4vDat scheelt je hooguit de lex en parse tijd m.u.v. de initiele performance penalty en alhoewel 't een beetje helpt denk ik niet dat niet zozeer de bottleneck is in de meeste gevallen
.Ik neem aan dat je hier doelt op Zend Encoder? Heb me er niet in verdiept, maar het lijkt me heel erg onwaarschijnlijk dat de commentaar mee geobfusceerd wordt daar het gewoon geen toegevoegde waarde heeft voor het eindresultaat. Het beoogde eindresultaat is immers om een geobfusceerde doch uitvoerbare versie te hebben van het script. Identifiers worden hier dan enkel gebruikt ter referentie van geheugenaddressen en comments worden gewoon niet meegenomen omdat ze parse overhead zijn. Het is immers de bedoeling ook dat de geobfusceerde versie niet meer terug te vertalen is naar het origineel lijkt me
Ben het niet helemaal eens met het performance verhaal. Wel ben ik van mening dat PHP vast geschikt is om view werk gedaan te krijgen op een cost-effective manier. Facebook is hier een goed voorbeeld van. De backend is Django + Erlang l33tness, de frontend lekker PHP omdat het zo makkelijk en goedkoop is om aan dat soort developers te komen. Een leuke bijkomstigheid is dat PHP met z'n setup/teardown aard gewoon ideaal is voor dit soort werk en het daarmee in zekere zin eigenlijk ook cost-effective schaalt: gewoon naar hartelust frontend webservers kan neerzetten om enigzins evenredig dat soort requests af te laten handelen door PHP.
. Het maakt niet zozeer uit welke taal, als het maar een ander taal is dan PHP, het liefst met een ander paradigm zoals een functionele programmeertaal b.v. Mensen als .oisyn enzo hebben imho correct kritiek hier op enkele "design keuzes" van PHP en ik denk dat dat pas echt tot je doordringt als je meerdere talen achter de kiezen hebt. Je hebt dan wat meer referentie materiaal en bent imho dan ook meer een software engineer dan alleen een PHP'er...). Om eerlijk te zijn interesseert de grammatica van de taal me niet bijster veel, 't gaat mij meer om de VM maken, maar als ik 't voor het zeggen zou hebben zou ik de grammatica niet op PHP laten lijken. Na x jaar blijkt echter nog steeds dat PHP het meest gebruikt wordt voor webdev en om nou iets te maken dat niemand gebruikt... Daar wil je vast ook een geweldige module voor gebruiken dan dat door enorm knappe en slimme mensen is gemaakt </schaamteloze promotie>
[ Voor 32% gewijzigd door prototype op 27-08-2008 03:24 ]
Verwijderd
Tjah, die dingen zijn razend populair en ik weet ook uit eigen ervaring dat het echt een flink performance verschil geeft. Zeker bij veel requests.:
[...]
Dat scheelt je hooguit de lex en parse tijd m.u.v. de initiele performance penalty en alhoewel 't een beetje helpt denk ik niet dat niet zozeer de bottleneck is in de meeste gevallen
Er zijn nog een paar anderen, maar Zend Encoder is er een van.[...]
Ik neem aan dat je hier doelt op Zend Encoder? Heb me er niet in verdiept, maar het lijkt me heel erg onwaarschijnlijk dat de commentaar mee geobfusceerd wordt daar het gewoon geen toegevoegde waarde heeft voor het eindresultaat. Het beoogde eindresultaat is immers om een geobfusceerde doch uitvoerbare versie te hebben van het script. Identifiers worden hier dan enkel gebruikt ter referentie van geheugenaddressen en comments worden gewoon niet meegenomen omdat ze parse overhead zijn. Het is immers de bedoeling ook dat de geobfusceerde versie niet meer terug te vertalen is naar het origineel lijkt me
PHP zelf is inefficient gemaakt, en dan hebben we het echt over extreem inefficient. Dat heeft dus absoluut niets te maken met OOP oid, hoewel menig PHP script zelf ook niet bijster efficient gemaakt is inderdaad. Zelfs al maak je super efficiente PHP code dan blijft het nog altijd PHP en dus maakt het niet optimaal gebruik van de hardware.
[ Voor 5% gewijzigd door Verwijderd op 27-08-2008 03:25 ]
Oh ongetwijfeld, maar 'k doelde meer op 't feit dat de bottleneck van dergelijke apps naar alle waarschijnlijkheid meer bij I/O handelingen zitten. Vergeleken daarmee is de winst die je haalt uit bytecode cachen denk ik niet zo bijzonder groot. Denk aan zware of inefficiente database queries. Dat soort dingen optimaliseren zal eerder merkbaar zijn me dunkt
. Of om de mensen van Zend zelf te quoten (uit php-5.3.0alpha1/Zend/README.ZEND_VM):Ik vind 'm creatief gevonden
Hmmm, da's waar ook, PHP ondersteund geen open classes etc itt Ruby b.v.
Daar zou je dit probleem dan ook gewoon niet hebben...Ah ja, je hebt gelijk met het feit dat in zo'n geval niet alles geobfusceerd kan worden: ik bedenk me net dat alles wat waarneembaar is (b.v. identifiers in de global scope) niet 'verwaarloosd' kan worden. Echter hetgeen wat niet waarneembaar zou zijn na een include b.v. (zoals de lokale variabelen in een class) prima 'verwaarloosd' kunnen worden tbv de parsetijd verminderen (om maar iets te noemen).
Wow, strong claims. Nu heb je m'n aandacht
Heb je concrete voorbeelden? In de praktijk ben ik wel wat mensen tegengekomen die met RoR werken maar niet goed weten wat ze doen. RoR is voortgekomen uit veel good practices van andere programmeer paradigms, AOP om er maar een te noemen voor filterchains. Mensen die net om 't hoekje komen kijken zonder kennis van dit soort mechanismen zullen idd slechte code schrijven omdat ze niet goed weten wat ze ermee aan moeten. In de handen echter van iemand die deze dingen wel begrijpt, zul je bloedmooie code krijgen en performance was daar geen issue (iets dat ik toevallig weet als zijnde een van de personen achter mod_rails). Voorbeeld: The Yellow Pages, BBC, NYTimes etc... Zeker niet de kleinsten zeg maar.
Zeg dan gelijk dat je me niet gelooft:
[...]
Ik had hem gezien maar was er van overtuigd dat dat wél zo was. Eigenwijs even getest, maar Creepy, en jij, hebben inderdaad gelijk
Uit verontwaardiging de manual maar ingedoken, en zo te zien is de manier waarop de string naar een integer wordt gecast volstrekt normaal, en ook gebruik in Unix en C++.
Uiteraard test ik dit soort dingen ook voordat ik het als waarheid post Creepy in "PHP als loose typed taal"
Mooi voorbeeld dit. Alweer iemand met ruime PHP ervaring die een aantal eigenaardigheden van de taal niet weet/kent of zich er niet van bewust is. Ok, de betere (PHP) ontwikkelaars voorkomen dat ze een string met een int gaan vergelijken maar dat blijkbaar een hoop mensen met ruime PHP ervaring niet goed weten hoe dat nu echt in z'n werk gaat wil ik toch afschuiven op de documentatie van PHP waar dat gewoon niet duidelijk in staat. Combineer dat met de mogelijkheid om aan de "officiele" documentatie commentaar toe te staan van alles en iedereen en dan moet ik toch zeggen dat PHP(of Zend..) zichzelf toch niet zo heel serieus neemt....Ik werk een ruime 7 jaar professioneel met oa. PHP en moet die associatie helaas met je delen. Probleem van PHP is dat het zo verschrikkelijk laagdrempelig is. Iedereen met een internetverbinding en Google kan in een dag eenvoudige dynamische pagina's maken met PHP.
Het bedrijfsleven haalt die mensen vervolgens binnen waar ze zichzelf proberen te ontplooien met slechte voorbeelden van hun voorgaande generatie en ze leren de syntax uit hun hoofd, maar echt programmeren leren ze noiot. Door dat soort mensen heeft PHP zo een slechte reputatie, en is veel PHP code ronduit slecht. Het instapniveau is gewoon te laag
Dat zegt echters niets over PHP zelf, welke wat mij betreft ook uitermate geschikt is voor de grotere webprojecten, mits er maar door goede programmeurs aan gewerkt wordt. Dat in oudere versies hulpmiddelen als register_globals en magiq_quotes standaard aanstonden heeft hier ook niet aan bijgedragen maar hier is met PHP5 gelukkig verandering in gekomen, en het ziet er uit dat er met PHP6 nog meer verbetering komt.
[ Voor 3% gewijzigd door Creepy op 27-08-2008 09:03 ]
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Open classes zijn namelijk zo'n lekker goed idee, dat zorgt in Rails ook helemaal niet voor problemen.:
Hmmm, da's waar ook, PHP ondersteund geen open classes etc itt Ruby b.v.
Rustacean
* PHP is snel genoeg. Ja leuk dat je met FastCGI en geoptimaliseerde C++ code snellere code kan maken. Dat boeit echter helemaal niet als je vervolgens naar een DB server of andere backend server gaat om gegevens op te halen. In mijn ervaring zijn PHP (mod_php) + Opcode cache (APC ofzo) zeker vergelijkbaar
Met het verschil dat je de libraries bij PHP er standaard bij krijgt en iedereen ze kent. Jouw C++ oplossing is weer compleet anders dan de C++ oplossing van je buurman. Zie voorgaande argumenten om PHP te gebruiken. PHP is gewoon een prima template taal. C++ is daar niet direct geschikt voor.
Maakt mij ook niet zoveel uit, zowel voor als nadelen tijdens ontwikkelen.
Snelheid scheelt niet significant. PHP draait ook overal.
Ik snap niet dat er nog mensen zijn die C++ gebruiken voor de frontend. Gebruik het gewoon in de backend, waar het thuishoort.
Jij wel ja. Hoeveel ervaring heb je met C++? Ik denk te weinig. Het blijft natuurlijk wel dat ervaring bij C++ belangrijker is dan bij PHP. Dwz, php kennis is sneller gesatureerd.
Er zijn zat frameworks voor C++. Ze zijn alleen niet onderdeel van de taal, omdat C++ ruim inzetbaar is, itt PHP dat voornamelijk voor 1 doel ontworpen is. Dat maakt PHP uiteraard geschikter om een webapp mee te maken. En minder geschikt om een game mee te maken. Maar ik geloof dat geschiktheid niet ter discussie stond hier in deze draad* Het gemis van frameworks voor C++ blijf ik ook onbegrijpelijk vinden. Nouja, misschien niet geheel onbegrijpelijk als je ziet dat er zo'n makkelijke taal is als PHP
[ Voor 10% gewijzigd door .oisyn op 05-09-2008 18:14 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik geef gelijk toe dat ik te weinig ervaring met C++ heb. Ik doelde echter op het argument dat jij ook geeft: PHP is makkelijker
Dat is precies mijn punt. PHP is gespecialiseerd (voor 1 doel ontworpen) : frontend. C++ is een prima taal voor de backend, of waar je low-level code moet produceren. Natuurlijk kun je met C++ alles doen wat je met PHP ook kan. Het gaat er alleen om wat makkelijker is. Productiviteit voor frontend is gewoon veel hoger in PHP dan in C++. Maakt niet uit hoeveel ervaring je hebt in C++. En voor dat ene doel is PHP een prima taal (die allicht verbetert kan worden). Het is echter veel geschikter voor deze taak dan C++, zelfs met alle onvolkomenheden van PHP.
[ Voor 8% gewijzigd door T.T. op 05-09-2008 18:20 ]
Je vergeet "te leren". Ik vind C++ niet moeilijker dan PHP. Sterker nog, ik vind PHP moeilijker omdat het op sommige punten onintuitief en clumsy is. Maar een doorgewinterde PHP'er kent die eigenaardigheden dan weer uit z'n hoofd.:
[...]
Ik geef gelijk toe dat ik te weinig ervaring met C++ heb. Ik doelde echter op het argument dat jij ook geeft: PHP is makkelijker
En ik zeg dus dat dat onzin is, wat Zoijar ook al aangaf. Als we even aannemen dat je dezelfde API kunt gebruiken in C++ als in PHP heeft een doorgewinterde C++'er heeft met een frontend in C++ niet meer tijd nodig dan een doorgewinterde PHP'er. Het punt is alleen dat een doorgewinterde C++'er meer investering nodig heeft om dat punt te bereiken dan een doorgewinterde PHP'er.
. Dat PHP the right tool for the right job is wil nog niet zeggen dat het niet z'n tekortkomingen heeft.
[ Voor 8% gewijzigd door .oisyn op 05-09-2008 18:25 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
En ik zeg dat dat onzin is
Als het meer investering kost, dan is het minder productief (of wellicht moet ik dan efficient gebruiken 
)Tsja, wat precies het centrale thema in dit topic is, was vanaf het begin al niet duidelijk. Het begint met jouw opmerking dat PHP slecht is
Dan lok je reacties zoals de mijne uit, alhoewel ik wel steeds heb aangegeven dat PHP niet zonder tekortkomingen is. Ik denk dat het productiviteits argument opweegt tegen de tekortkomingen. Wanneer PHP niet zo handig was voor de frontend, dan waren de tekortkomingen daadwerkelijk interessant geweest. Het blijkt echter dat het toch goed genoeg is. Je kunt daarom PHP niet afbranden op wat de onvolkomenheden.Daar sluit ik me (nogmaals) bij aan.
Ja, dat krijg je met afgesplitste topics.:
Tsja, wat precies het centrale thema in dit topic is, was vanaf het begin al niet duidelijk. Het begint met jouw opmerking dat PHP slecht is
Ik brand de taal PHP af, waar ik alle recht toe heb en zelfs de argumenten om dat de staven. Ik brand niet het doel van de taal af. Je schijnt de twee maar moeilijk uit elkaar te kunnen houden, maar het verschil is er toch echt
Denk je niet dat met een vergelijkbare maar beter ontworpen taal die al die genoemde punten in zich heeft je blijer zou zijn dan met PHP? Ik bedoel, het is niet inherent aan die punten dat PHP, zoals hier gesteld, "kut" is
[ Voor 20% gewijzigd door .oisyn op 05-09-2008 18:42 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik begrijp wat je bedoelt, maar de vraag is of het praktisch is om het verschil te maken. Ik ben het grotendeels met je eens qua argumenten dat PHP niet zo goed in elkaar is gezet.:
Ik brand de taal PHP af, waar ik alle recht toe heb en zelfs de argumenten om dat de staven. Ik brand niet het doel van de taal af. Je schijnt de twee maar moeilijk uit elkaar te kunnen houden, maar het verschil is er toch echt
Haha per definitie is dat natuurlijk waar.Denk je niet dat met een vergelijkbare maar beter ontworpen taal die al die genoemde punten in zich heeft je blijer zou zijn dan met PHP? Ik bedoel, het is niet inherent aan die punten dat PHP, zoals hier gesteld, "kut" is
[ Voor 9% gewijzigd door T.T. op 05-09-2008 18:56 ]
Eh, is_int? Of mis ik je punt?:Overigens is .oisyn in de eerdere discussie nog een punt vergeten bij zijn 0 == 'blaat' bij php hetze
Want dit is toch wel een belangrijke reden waarom deze keuze raar is:
PHP:
Het ergste hierbij is niet eens dat $a naar true evalueert in het tweede statement, maar dat je van $b eigenlijk niet zo eenvoudig kan controleren of het een integer is waarbij 0 ook een geldige waarde is. Kwa aangeboden mogelijkheden komt is_numeric in de buurt, maar een float is geen integer. En domweg casten naar int en kijken of er een integer is, is ook raar want een string is geen int.
Gelukkig is dit met name relevant bij het controleren van user-input en dat doe je doorgaans maar een maal in je script-executie, waardoor je er een regexp of iets in die geest op los kan laten, zonder dat het te duur wordt.
[ Voor 12% gewijzigd door Patriot op 06-09-2008 14:47 ]
{signature}
Aha, en daar loopt de discussie dus mank, want ik verwerp het gebruik van PHP helemaal niet
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Wat zou dan de reactie zijn?
[ Voor 5% gewijzigd door drm op 06-09-2008 20:52 ]
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Als antwoord op de gestelde vraag in je "anders geformuleerde discussievraag": Ja, dat is inderdaad vreemd.:
In reactie op de PHP discussie:
Volgens mij is een groot probleem met php'ers dat als ze horen dat de taal php niet deugt (in sommige opzichten) ze denken dat php als geheel aangevallen wordt. Dat is helemaal niet de discussie, en ik onderstreep daarom het volgende (niet écht want dan lijkt het een link....): PHP is een taal. PHP is een framework. Dat zijn twee verschillende dingen, die in de meeste talen goed gescheiden zijn, ook in de hoofden van de gebruikers ervan. Bij PHP blijkt dat lastig te zijn. Bij Java, C#, C++, Perl, enzovoorts heeft niemand er moeite mee.
Laat ik daarom voor iedere PHP'er de discussievraag iets anders formuleren:
[...]
Wat zou dan de reactie zijn?
edit:
Voor de volledigheid: ik doe echt al 8 jaar php, en heb aardig wat quirks ontdekt in PHP, genoeg getuigen hier, denk ik zo
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dat is kletspraat (nofi). PHP is in de laatste 10 jaar meer geëvolueerd dan welke taal dan ook, dus zeggen dat php niet beinvloedbaar zou zijn is per definitie al niet waar omdat er toch iets of iemand is geweest die die veranderingen heeft bewerkstelligd. Dat het veel gebruikt wordt kan dus zeker niet de reden zijn dat het niet te veranderen is (het werd 5 jaar geleden ook veel gebruikt).
Dat is ook veel leuker dan websites bouwen in PHP, maar desondanks is PHP toch voor heel veel mensen de dagelijkse praktijk. En die dagelijkse praktijk verandert volgens mij niet met een nieuw taaltje (met een suffe naam
), maar met (een aanmoediging van) bijdragen aan dat wat er al is. Dat wil niet zeggen dat je nu moet stoppen met je nieuwe taal, integendeel, hou vol en post hier vooral wat (je) er interessant aan (is/vindt), maar geloof er maar niet dat het de wereld gaat veranderen Maar waarom zou je niet zeggen dat PHP brak is? Het zegt toch niks over jouw keuze of jouw situatie om PHP toch te gebruiken? Ik vind PHP ook brak, ik verdien er wel mijn boterham mee. Wil ik dan ineens websites in C++ gaan bouwen? Nee, want het gaat in PHP prima. Maar dat neemt niet weg dat ik erg kritisch ben op PHP. Geldt voor MySQL overigens net zo goed.
Toughen up
PHP is nou eenmaal geen taal die goed doordacht is. Maar vraag iedere doorgewinterde programmeur of hij nog terug zou willen naar de eerste versies van C, de eerste versies van C++, de eerste versies van Java.... niemand die je zegt dat het niet vooruit is gegaan. Zo gaat het gewoon, en des te beter, want ik zou dus echt niet meer terugwillen naar php3, jij?
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Een applicatie als Twitter is ook zwaar IO bound he... geen enkele webframework zal je daarvoor behoeden als je je database niet goed geschaald hebt aangezien daar het grotendeel plaatsvindt van een request (en 9 van de 10 requests zijn restful controller API requests). Bovendien, zoiets dat zwaar van message passing, distribution en fault tolerance afhankelijk is, is Erlang geschikter voor. Dat was niet echt rocket science om dat te achterhalen he aangezien dat ook z'n oorsprong voor dit soort doelen vindt binnen de telecommunicatie. Het resultaat is dat de backend vervangen is grotendeels door ejabber (erlang powered), waar de frontend nog gewoon mooi via Rails werkt. De database hebben ze ook flink getuned
Je moet erlang dan ook niet voor alles gebruiken. Again, voor concurrent distributed problemen oplossen is het awesome, maar probeer eens reguliere expressies toe te passen in Erlang mbv de bestaande libs. a) performed super slecht omdat hij niet compiled naar een NFA, b) is bijna onleesbaar. Zoek voor de lol maar eens naar Tim Bray's (van sun microsystems) wide finder project over beautiful code. De kunst, zoals ze bij twitter ook achter zijn gekomen, is de balans zien te vinden van right tool for the right job gebruiken. Python zou je perfect met erlang kunnen gebruiken middels ports als je het aan een frontend zou willen koppelen middels django b.v. Again, right tool for the right job. PHP is enkel onder economische omstandigheden nog de right tool for the job imho, aangezien het zo widespread in use en verkrijgbaarheid is. Alhoewel, dat is misschien iets te kort door de bocht. Door het 'share nothing' principe van PHP, krijg je eigenlijk hetzelfde idee als in Erlang m.b.t. deze policy. Daardoor zou het mogelijk eenvoudiger kunnen schalen dan gebruik van meerdere applicationservers.
[ Voor 7% gewijzigd door prototype op 07-09-2008 13:29 ]
[ Voor 15% gewijzigd door Creepy op 07-09-2008 17:48 ]
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
| Last.fm | "Mr Bent liked counting. You could trust numbers, except perhaps for pi, but he was working on that in his spare time and it was bound to give in sooner or later." -Terry Pratchett
{signature}
Met ^, de keuze tussen == of === zou afhankelijk moeten zijn van je logica (wil je gewoon twee variabelen vergelijken of wil je ook checken op type), niet van performance.:
Tenzij het in een loopje staat met extreem veel iteraties, is een dergelijke vraag zonde van je tijd, want micro optimalisatie. En als je een gruwelijk loopje begint, loont het ook wel de moeite om je datastructuur en data types voor dat punt al op orde te hebben.
Een kleine opmerking: user input is bij PHP (webbased) altijd van het type string (of array met strings)
Je zal het dus altijd moeten casten naar een ander type als je dat nodig. En eventueel kan je controleren of de string ook een getal kan vormen (is_number oid).
), kun je beter het zekere voor het onzekere nemen en checken of je daadwerkelijk met bijv. false te maken hebt en niet iets dat evalueert naar false.
Dat is toch ook zijn punt? Op het moment dat je een string met een integer gaat veregelijken doe je iets fout, je had voor die tijd die string al moeten casten (of bwvs een waarschuwing geven als hij niet gecast kan worden).:
[...]
Een kleine opmerking: user input is bij PHP (webbased) altijd van het type string (of array met strings)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
:strip_icc():strip_exif()/u/132250/d1ca484677dbb1382705e67689809639.jpeg?f=community)
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
:strip_icc():strip_exif()/u/35767/images.jpg?f=community)
:strip_icc():strip_exif()/u/26612/droptikkels_icon.jpg?f=community){kind=icon}
:strip_exif()/u/26373/anim4.gif?f=community)
:strip_exif()/u/47168/loop.gif?f=community)
:strip_icc():strip_exif()/u/43400/avatar.jpeg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/126096/crop580e4f8566fec_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/22092/crop5fa8360e95568_cropped.jpeg?f=community)
/u/84769/crop5f8b3cbb73ded_cropped.png?f=community)
:strip_exif()/u/73955/foxavatar-60.gif?f=community){kind=avatar}
/u/214894/crop5baaa31f9c4ff_cropped.png?f=community)
/u/107051/jeroenmadtrix60.png?f=community)
:strip_icc():strip_exif()/u/43473/crop5e12eeae6a054_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/116726/crop5e3ee297a8a03_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/77332/crop5e54ec42433bc_cropped.jpeg?f=community)
:strip_exif()/u/28900/sharingan.gif?f=community)
:strip_icc():strip_exif()/u/43250/crop68baa3c257258_cropped.jpg?f=community)
:strip_exif()/u/5299/msnsmall.gif?f=community)
:strip_exif()/u/22119/ch.gif?f=community)