Client-side php moet mobiele applicaties mogelijk gaan maken
De PHP Group en Zend zouden voornemens zijn om in oktober een serie tools aan te kondigen die het mogelijk moeten maken om client-side applicaties te bouwen voor mobiele apparaten. Momenteel is php nog zuiver een server-side scripttaal.
In een interview met Venturebeat geeft Andi Gutmans, een van de ontwikkelaars van de php3-parser, hints over nieuwe mogelijkheden voor de scripttaal. Volgens de developer zal de PHP Group en Zend eind oktober op een Zend-conferentie een serie tools aankondigen waarmee client-side applicaties gebouwd kunnen worden. Deze apps zouden met name bedoeld zijn voor mobiele apparaten. Meer details wil Gutmans echter nog niet geven.
Momenteel is php een van de meestgebruikte server-side scripttalen. Het wordt ingezet om op webservers dynamische pagina's op te bouwen en wordt onder andere gebruikt door diverse populaire contentmanagementsystemen als Drupal, Joomla, Magento en Wordpress. Als php ook mogelijkheden gaat bieden voor client-side-applicaties, is dat een forse stap die wordt gezet in de ontwikkeling van de scripttaal.
Gutmans geeft verder aan dat hij denkt dat scripttalen als javascript, dat client-side draait, en php op termijn native softwarestacks zullen gaan vervangen. Dergelijke stacks worden momenteel nog gebruikt voor het bouwen van applicaties in iOS, Android en Windows Phone, maar onder andere Mozilla poogt met Firefox OS een platform te bouwen op basis van de webstandaarden html 5, javascript en css.
Reacties (104)
Nou, ik verwacht niet snel dat scripttalen de native softwarestacks gaan vervangen. Misschien voor kleine widgets enzo, maar de performance en mogelijkheiden van native code is toch echt beter dan de script equivalenten in zijn geheel.
Je ziet het ook met phonegap en meer van dat soort tools. De apps zien er meestal niet uit.
Wat natuurlijk wel zo is, is dat mensen die goed met deze talen kunnen werken ook de mogelijkheid krijgen om apps te ontwikkelen. Wie weet dat dat positief is voor de platformen.
Je ziet het ook met phonegap en meer van dat soort tools. De apps zien er meestal niet uit.
Wat natuurlijk wel zo is, is dat mensen die goed met deze talen kunnen werken ook de mogelijkheid krijgen om apps te ontwikkelen. Wie weet dat dat positief is voor de platformen.
Maar online applicaties naar offline applicaties porten, word zo wel makkelijker.
En waarom zouden we dat willen? Caching/offline maken van delen van programma's is al prima te doen.
Ik zie liever meer online applicaties
Ik zie liever meer online applicaties
Omdat je met een mobiel apparaat soms erg lang zonder database of verbinding kunt zitten? Sommige simpele dingen zou je dan in een mobiele applicatie kunnen zetten zonder enige native programmeerkennis wat best handig kan zijn.
Dan is het nog steeds maar de vraag of een geporte web applicatie wel beter is dan een native applicatie.
Facebook is niet voor niets van een HTML5 apps terug gaat naar native apps.
Facebook is niet voor niets van een HTML5 apps terug gaat naar native apps.
Zegt meer over de HTML5 kwaliteiten van Facebook's ontwikkelaars dan iets over HTML5.
én HTML5 is gewoon nog dik in ontwikkeling... Is gewoon niet snel 
In HTML5 kan je met Local Storage data lokaal opslaan en later, wanneer de internetverbinding weer beschikbaar is, de data synchroniseren met de server. Dit is dus geen reden om een native app te moeten bouwen, tenzij je de uitgebreide querying mogelijkheden (SQL) van SQLite (beschikbaar in iOS en Android) nodig hebt.
Localstorage is echter niet onbeperkt kwa opslag, veelal maximaal 5 mb, maar zelfs dat is niet gegarandeerd. Iedere browser heeft een andere opslagruimte, waardoor je in de praktijk binnen de 3mb data zult moeten blijven.
Ondanks dat php een script taal is, lijkt php 6 wel erg veel op het schrijven zoals C. Er is veel mogelijk en dat i.c.m. al bestaan compilers krijg je erg veel mogelijkheden. Daarnaast spelen er ook andere factoren bij het kiezen van een taal. Het is niet voor niets dat Facebook een tool heeft gemaakt welke PHP omvormd naar C code. Met php is eenmaal heel snel te ontwikkelen terwijl er niet eens zo heel veel functionaliteiten worden opgegeven. Ik zie zeker baat bij deze ontwikkelingen!
Ik wist niet dat php nog verder ging en er zelfs een 6 komt. Net wat info gelezen en inderdaad ze proberen zowaar van php wat 'normaals' te maken..
Tegenwoordig heb je alleen wel enorm veel alternatieven (zoals Python, Perl en Ruby).
Als ik anno 2012 weer van php4 of het OO php5 naar php6 moest 'omscholen' zou ik toch echt eieren voor mijn geld kiezen.. en voor een SCRIPT taal kiezen die de basis al vanaf dag 1 op orde had en doorstromen naar een compile taal makkelijk maakt.
Facebook heeft overigens een eigen compiler geschreven omdat zij zoals veel bedrijven tegen het plafond liepen van php zelf.
Normaal maak je dan een professionalisering naar en 'echte' taal (dot net, java etc..) en kies je voor een platform. Maar facebook was al zo groot dat herschrijven/ omscholen/ personeel vernieuwing geen optie was.. opzich wel 'cool' dat ze dan gewoon de compiler herschrijven en het resultaat mag er zijn (groot rijk bedrijf).
Andere bedrijven zoals Hyves zijn zwaar ten onder gegaan door php te blijven gebruiken.. maar ik zou er niet graag willen werken, bij facebook.
Maar om terug te komen bij PHP als 'client' taal; PHP is een grote wrapper. Met een 'taal' om apps te maken zal Zend en PHP group vast een eindje komen. Genoeg 'script kiddies' die even snel wat cools maken en (hopelijk) doorstromen naar een behoorlijke taal Alle talen hebben zo hun plekje.
edit: Downmods allom maar ik accepteer het sentiment. Zoals ik verderop al reageerde, php is niet slecht of fobieopleverend maar gewoon een leuke taal om te beginnen alleen kan het voor (helaas veel mensen) een slechte basis afleveren voor toekomstige talen.
Tegenwoordig heb je alleen wel enorm veel alternatieven (zoals Python, Perl en Ruby).
Als ik anno 2012 weer van php4 of het OO php5 naar php6 moest 'omscholen' zou ik toch echt eieren voor mijn geld kiezen.. en voor een SCRIPT taal kiezen die de basis al vanaf dag 1 op orde had en doorstromen naar een compile taal makkelijk maakt.
Facebook heeft overigens een eigen compiler geschreven omdat zij zoals veel bedrijven tegen het plafond liepen van php zelf.
Normaal maak je dan een professionalisering naar en 'echte' taal (dot net, java etc..) en kies je voor een platform. Maar facebook was al zo groot dat herschrijven/ omscholen/ personeel vernieuwing geen optie was.. opzich wel 'cool' dat ze dan gewoon de compiler herschrijven en het resultaat mag er zijn (groot rijk bedrijf).
Andere bedrijven zoals Hyves zijn zwaar ten onder gegaan door php te blijven gebruiken.. maar ik zou er niet graag willen werken, bij facebook.
Maar om terug te komen bij PHP als 'client' taal; PHP is een grote wrapper. Met een 'taal' om apps te maken zal Zend en PHP group vast een eindje komen. Genoeg 'script kiddies' die even snel wat cools maken en (hopelijk) doorstromen naar een behoorlijke taal
Alle talen hebben zo hun plekje.edit: Downmods allom
maar ik accepteer het sentiment. Zoals ik verderop al reageerde, php is niet slecht of fobieopleverend maar gewoon een leuke taal om te beginnen alleen kan het voor (helaas veel mensen) een slechte basis afleveren voor toekomstige talen.
[Reactie gewijzigd door CT op 2 oktober 2012 21:51]
En Facebook, Tweakers, etc. gebruiken PHP niet alleen, maar ook een mix van andere talen.
Dus het beste uit de vele werelden.
Dus het beste uit de vele werelden.
Jemig. Beetje een PHP fobie opgelopen?
Zekers, het is niet de mooiste taal 'out there', maar voor een berg toepassingen is het wel de meest efficiënte keus.
Ben erg benieuwd hoe dit vorm gaat krijgen!
Zekers, het is niet de mooiste taal 'out there', maar voor een berg toepassingen is het wel de meest efficiënte keus.
Ben erg benieuwd hoe dit vorm gaat krijgen!
Ik gebruik php (5) zo nu en dan nog wel eens, al begin ik Python steeds vaker te gebruiken omdat het als scripttaal toch net wat netter en duidelijker is als je tegenwoorig 24/7 in compile talen werkt.
Groot deel van mijn 'jeugd' heb ik in php(3) doorgebracht dus ik zal niet snel gillen (zoals sommige reacties) dat het 'complete bagger is'. Het heeft echt zijn plek. Maar als je blijft hangen in php is dat gewoon niet goed voor je ontwikkeling*.
*de taal heeft zoveel verschillende regels dat niemand meer weet wat de regels zijn en dat is gewoon geen goede basis
Groot deel van mijn 'jeugd' heb ik in php(3) doorgebracht dus ik zal niet snel gillen (zoals sommige reacties) dat het 'complete bagger is'. Het heeft echt zijn plek. Maar als je blijft hangen in php is dat gewoon niet goed voor je ontwikkeling*.
*de taal heeft zoveel verschillende regels dat niemand meer weet wat de regels zijn en dat is gewoon geen goede basis
@CT
Wat heeft PHP jou ooit misdaan zeg? Natuurlijk, het heeft zijn nukken, zoals praktisch elke taal. Het is wat mij betreft echter een hele fijne taal om in te werken en heeft zeker de voorkeur voor webapps wat mij betreft. Voor native programma's gebruik ik C++ over het algemeen, en ik zie ook niet direct noodzaak om PHP clientside te brengen, maar voor server software is het zeker prima.
Waar haal jij vandaan dat Hyves ten onder gegaan is door PHP te blijven gebruiken? Volgens mij is het daar vooral bergafwaards gegaan in eerste instantie door onvoldoende te anticiperen op de populariteit waardoor de performance onvoldoende was, en daarna door te veel dingen te wijzigen om puur om de verandering, waar mensen helemaal niet op zaten te wachten. Bijvoorbeeld het mogelijk maken om een eigen achtergrond in te stellen. Nu was dat wel uit te schakelen maar het heeft mij in ieder geval aardig weggedreven bij Hyves. Bovendien mistte Hyves natuurlijk internationale acceptatie. Toen Facebook groter werd zag je dat Hyves (die overigens de performance al lang weer op peil had) dingen van Facebook ging overnemen, maar het mocht niet baten, het werd door velen al niet meer serieus genomen.
Wat heeft PHP jou ooit misdaan zeg? Natuurlijk, het heeft zijn nukken, zoals praktisch elke taal. Het is wat mij betreft echter een hele fijne taal om in te werken en heeft zeker de voorkeur voor webapps wat mij betreft. Voor native programma's gebruik ik C++ over het algemeen, en ik zie ook niet direct noodzaak om PHP clientside te brengen, maar voor server software is het zeker prima.
Waar haal jij vandaan dat Hyves ten onder gegaan is door PHP te blijven gebruiken? Volgens mij is het daar vooral bergafwaards gegaan in eerste instantie door onvoldoende te anticiperen op de populariteit waardoor de performance onvoldoende was, en daarna door te veel dingen te wijzigen om puur om de verandering, waar mensen helemaal niet op zaten te wachten. Bijvoorbeeld het mogelijk maken om een eigen achtergrond in te stellen. Nu was dat wel uit te schakelen maar het heeft mij in ieder geval aardig weggedreven bij Hyves. Bovendien mistte Hyves natuurlijk internationale acceptatie. Toen Facebook groter werd zag je dat Hyves (die overigens de performance al lang weer op peil had) dingen van Facebook ging overnemen, maar het mocht niet baten, het werd door velen al niet meer serieus genomen.
Misschien moet je even het boek "Van 3 naar 10.000.000 vrienden" van Raymon Spanjar lezen (gratis tegenwoordig):
http://van3naar10miljoenvrienden.nl/
Dan lees je hoe het exact met Hyves is gegaan.
Het klopt wel grotendeels wat je zegt. Maar voornamelijk het internationale momentum van Facebook was een mokerslag waar Hyves niet lang weerstand tegen kon bieden. Al zijn ze wel internationaal geroemd omdat ze een van de laatste 'lokale' social networks waren die zo lang populair bleven boven Facebook (in eigen land).
http://van3naar10miljoenvrienden.nl/
Dan lees je hoe het exact met Hyves is gegaan.
Het klopt wel grotendeels wat je zegt. Maar voornamelijk het internationale momentum van Facebook was een mokerslag waar Hyves niet lang weerstand tegen kon bieden. Al zijn ze wel internationaal geroemd omdat ze een van de laatste 'lokale' social networks waren die zo lang populair bleven boven Facebook (in eigen land).
[Reactie gewijzigd door Biinjo op 2 oktober 2012 21:30]
Spanjar teerde enkel in op het succes van Hyves zonder ook maar echt iets fundamenteels te druven vernieuwen.
Vanaf het begin stond ie al te brullen over iets met een verdienmodel maar in al die jaren had hij blijkbaar geen zin om er serieus werk van te maken.
Als je Hyves dan vervalt tot een soort MySpace dan is dat voornamelijk het onvermogen van Spanjar en de andere 'toppers' om mee te gaan met de tijd.
Vanaf het begin stond ie al te brullen over iets met een verdienmodel maar in al die jaren had hij blijkbaar geen zin om er serieus werk van te maken.
Als je Hyves dan vervalt tot een soort MySpace dan is dat voornamelijk het onvermogen van Spanjar en de andere 'toppers' om mee te gaan met de tijd.
Wat jij noemt het 'plafond van php' is gewoon een beperking van elke scripttaal. Interpreten is nou eenmaal trager dan gecompilede code, maar juist in het interpreten zit de kracht van een scripttaal. Het compileren zoals facebook dat doet heeft zijn beperkingen (kan niet op elk php script worden toegepast).
En natuurlijk is php nog in ontwikkeling. Net zoals er ook regelmatig nieuwe versies van java en dot net uitkomen. Da's heus geen hele omscholing en dat is nu eenmaal zo in deze sector. Gelukkig maar, anders gingen we niet meer vooruit.
En natuurlijk is php nog in ontwikkeling. Net zoals er ook regelmatig nieuwe versies van java en dot net uitkomen. Da's heus geen hele omscholing en dat is nu eenmaal zo in deze sector. Gelukkig maar, anders gingen we niet meer vooruit.
Hyves en PHP staan totaal los van elkaar het geen daar mis ging is dat men simpel weg de nieuwe machines die nodig waren om op te schalen niet aan kon slepen laat staan de kennis of de infrastructuur had om het te beheren. Dat is daar na (een jaar of anderhalf later snel beter geworden) De ondergang was simpel weg dat mensen nu eenmaal ook veel vrienden in landen hebben die niet door Hyves ondersteund werden en dat er simpel weg niet werd geaccepteerd dat een van de redenen dat MySpace faalde de bizarre aanpassingsmogelijkheden was waar door mensen de informatie die ze wilden zien simpel weg niet konden vinden.
Maar goed PHP, het is een veel al trage taal die aardig wat slechte voorbeelden heeft op het internet, van mensen die het goed bedoelde maar totaal niet wisten hoe ze een goede veilige fatsoenlijk schalende applicatie moesten bouwen. Daar door zijn er nog al wat mensen met trauma's opgelopen door het gebruik van PHP code of door het gebruik van sites geschreven door script kiddies die de code zo van het internet plukte en met een beetje kippen en plakken een eigen website bouwden die veel al vol fouten zat.
PHP is met PHP5 er niet veel beter op geworden, het is nog veel complexer en nog veel uitgebreider om aan alle eisen van een volwaardige programmeer taal te voldoen zonder ook echt te hoeven programmeren. Met 6 lijken ze eindelijk de andere kant op te gaan en meer een programmeer taal te willen worden dan een script taal. Dat is helemaal niet zo'n gek idee vind ik persoonlijk.
Om PHP nu naar de desktop te brengen is een totaal ander verhaal, het is natuurlijk geheel mogelijk en waarschijnlijk zullen er ook wel mensen zijn die hier gebruik van zullen maken maar om eerlijk te zijn zijn er meer dan voldoende alternatieven die een zelfde mogelijkheid bieden om PHP niet op een desktop nodig te hebben.
De alternatieven die je noemt zijn geen alternatieven in veel gevallen.
Perl is stukken ouder dan PHP en meer bedoeld om command line backend werk te doen en richt zich voor een groot deel op het verwerken van platte tekst om die reden. (Ik schrijf al 15 jaar in Perl dus ik weet hoeveel mensen hier boos om zullen zijn maar dat is toch echt de oorsprong tegenwoordig kan het een stuk meer maar dat is een ander verhaal)
Phyton is meer een taal die zich in de core richt op het werken met tabellen en data uit databases, de taal kan een stuk meer maar de core is toch echt tabellen en databases.
PHP is een taal die zich voornamelijk richt op het werken aan de webserver kant om pagina's te serveren en mensen van semi interactieve content te voorzien. Ook deze taal is natuurlijk gegroeid gedurende de jaren maar dat is de core.
Ruby is een taal die ontwikkeld is om interactieve web content te leveren, het kan in middels meer maar de core is rond om dat idee geschreven.
Je vergeet nog heel erg veel andere opties maar allemaal hebben ze een bepaalde niche gezien zijn er op gedoken soms simpel weg omdat ze dat de auteur dit nodig had soms omdat het gewoon leuk was om te doen etc, etc...
Allemaal kun je ze gebruiken om een zelfde eindresultaat te bereiken. In sommige talen ziet dat er mooier of minder mooi uit. Maar dat hangt voor een groot deel van de auteur van de code af. Ik heb zeer complexe perl code gezien die mooier was dan de meeste hele simpele scripts, en ik heb python code gezien die totaal onleesbaar was. Het maakt niet uit welke taal je gebruikt je kunt in allemaal dingen erg rommelig maken en allemaal hebben ze bepaalde beperkingen waar je om heen kunt werken met meer code en langzamere executie daar door.
Net als dat een taal als C bestaansrecht heeft naast C++ en zelfs een taal als Visual basic of Java een reden heeft om gebruikt te worden is dat zelfde het geval met de verschillende script talen.
Een van de belangrijkste dingen om in de gaten te houden is wat je schrijft en welke taal daar het best bij past. Als ik een tekst parser schrijf gebruik ik geen C en ook geen Visual basic. Maar als ik een driver schrijf dan is C toch erg handig.
Om je een mooi voorbeeld te geven voor een migratie traject moesten we de XML output van het oude en het nieuwe systeem (gegeven de zelfde input) vergelijken. Nu praten we hier over een systeem dat per uur een paar miljoen XML bestanden produceert waarvan er 99% exact de zelfde tags zullen bevatten en er maar een paar afwijkende bestanden tussen zullen zitten. Om die reden werd dus de eis gesteld om minimaal 1 week aan data te vergelijken. Er waren twee wat volume betreft grotendeels identieke data flows voor de eerste werd het werk in Java gedaan dat koste de twee ontwikkelaars vele weken werk om alles werkend te krijgen en vervolgens een aantal dagen om alles te vergelijken.
Voor de tweede flow werd gekozen voor Perl, geschreven in 4 uur door 1 persoon werd de vergelijking binnen 1 dag uitgevoerd....
Het grote verschil zit hem niet in het feit dat Java het werk niet zou kunnen doen of dat Perl zo veel beter is maar simpel weg in het feit dat je een boom ook niet omhakt met een brood mes maar met een bijl terwijl je voor het snijden van je brood beter geen bijl kunt gebruiken.
PHP heeft haar plaats server side, of het ook een plaats heeft op de desktop is een vraag die we alleen kunnen beantwoorden als we het resultaat zien waar het team dat aan de desktop versie werkt. Zij denken dat er een goede reden is waarom mensen dit zouden willen gebruiken op de desktop, fair enough, misschien wel. De meeste mensen die op dit bericht reageren lijken een andere mening toegedaan net als ik zelf. Wie weet zitten we er helemaal naast.
Maar goed PHP, het is een veel al trage taal die aardig wat slechte voorbeelden heeft op het internet, van mensen die het goed bedoelde maar totaal niet wisten hoe ze een goede veilige fatsoenlijk schalende applicatie moesten bouwen. Daar door zijn er nog al wat mensen met trauma's opgelopen door het gebruik van PHP code of door het gebruik van sites geschreven door script kiddies die de code zo van het internet plukte en met een beetje kippen en plakken een eigen website bouwden die veel al vol fouten zat.
PHP is met PHP5 er niet veel beter op geworden, het is nog veel complexer en nog veel uitgebreider om aan alle eisen van een volwaardige programmeer taal te voldoen zonder ook echt te hoeven programmeren. Met 6 lijken ze eindelijk de andere kant op te gaan en meer een programmeer taal te willen worden dan een script taal. Dat is helemaal niet zo'n gek idee vind ik persoonlijk.
Om PHP nu naar de desktop te brengen is een totaal ander verhaal, het is natuurlijk geheel mogelijk en waarschijnlijk zullen er ook wel mensen zijn die hier gebruik van zullen maken maar om eerlijk te zijn zijn er meer dan voldoende alternatieven die een zelfde mogelijkheid bieden om PHP niet op een desktop nodig te hebben.
De alternatieven die je noemt zijn geen alternatieven in veel gevallen.
Perl is stukken ouder dan PHP en meer bedoeld om command line backend werk te doen en richt zich voor een groot deel op het verwerken van platte tekst om die reden. (Ik schrijf al 15 jaar in Perl dus ik weet hoeveel mensen hier boos om zullen zijn maar dat is toch echt de oorsprong tegenwoordig kan het een stuk meer maar dat is een ander verhaal)
Phyton is meer een taal die zich in de core richt op het werken met tabellen en data uit databases, de taal kan een stuk meer maar de core is toch echt tabellen en databases.
PHP is een taal die zich voornamelijk richt op het werken aan de webserver kant om pagina's te serveren en mensen van semi interactieve content te voorzien. Ook deze taal is natuurlijk gegroeid gedurende de jaren maar dat is de core.
Ruby is een taal die ontwikkeld is om interactieve web content te leveren, het kan in middels meer maar de core is rond om dat idee geschreven.
Je vergeet nog heel erg veel andere opties maar allemaal hebben ze een bepaalde niche gezien zijn er op gedoken soms simpel weg omdat ze dat de auteur dit nodig had soms omdat het gewoon leuk was om te doen etc, etc...
Allemaal kun je ze gebruiken om een zelfde eindresultaat te bereiken. In sommige talen ziet dat er mooier of minder mooi uit. Maar dat hangt voor een groot deel van de auteur van de code af. Ik heb zeer complexe perl code gezien die mooier was dan de meeste hele simpele scripts, en ik heb python code gezien die totaal onleesbaar was. Het maakt niet uit welke taal je gebruikt je kunt in allemaal dingen erg rommelig maken en allemaal hebben ze bepaalde beperkingen waar je om heen kunt werken met meer code en langzamere executie daar door.
Net als dat een taal als C bestaansrecht heeft naast C++ en zelfs een taal als Visual basic of Java een reden heeft om gebruikt te worden is dat zelfde het geval met de verschillende script talen.
Een van de belangrijkste dingen om in de gaten te houden is wat je schrijft en welke taal daar het best bij past. Als ik een tekst parser schrijf gebruik ik geen C en ook geen Visual basic. Maar als ik een driver schrijf dan is C toch erg handig.
Om je een mooi voorbeeld te geven voor een migratie traject moesten we de XML output van het oude en het nieuwe systeem (gegeven de zelfde input) vergelijken. Nu praten we hier over een systeem dat per uur een paar miljoen XML bestanden produceert waarvan er 99% exact de zelfde tags zullen bevatten en er maar een paar afwijkende bestanden tussen zullen zitten. Om die reden werd dus de eis gesteld om minimaal 1 week aan data te vergelijken. Er waren twee wat volume betreft grotendeels identieke data flows voor de eerste werd het werk in Java gedaan dat koste de twee ontwikkelaars vele weken werk om alles werkend te krijgen en vervolgens een aantal dagen om alles te vergelijken.
Voor de tweede flow werd gekozen voor Perl, geschreven in 4 uur door 1 persoon werd de vergelijking binnen 1 dag uitgevoerd....
Het grote verschil zit hem niet in het feit dat Java het werk niet zou kunnen doen of dat Perl zo veel beter is maar simpel weg in het feit dat je een boom ook niet omhakt met een brood mes maar met een bijl terwijl je voor het snijden van je brood beter geen bijl kunt gebruiken.
PHP heeft haar plaats server side, of het ook een plaats heeft op de desktop is een vraag die we alleen kunnen beantwoorden als we het resultaat zien waar het team dat aan de desktop versie werkt. Zij denken dat er een goede reden is waarom mensen dit zouden willen gebruiken op de desktop, fair enough, misschien wel. De meeste mensen die op dit bericht reageren lijken een andere mening toegedaan net als ik zelf. Wie weet zitten we er helemaal naast.
[Reactie gewijzigd door Rob Coops op 2 oktober 2012 21:48]
Wat je zegt over python is niet waar. Het is een zeer breed toegepast taal: desktop applicaties, interne scripting, web development, system administration, development tools, games en zelfs high performance computing. Dat laatste omdat je makkelijk libraries in C/C++/Fortran kan maken die je vervolgens in python gebruikt.
Juist omdat het als generieke taal is ontworpen kan het meegroeien met de eisen die nieuwe ontwikkelingen, zoals bijvoorbeeld smartphones, stellen. Dat laatste in contrast tot VB, JS, en in mindere mate PHP en Perl. (Disclaimer: ik ken deze laatste 4 talen niet allemaal uit eigen ervaring)
Juist omdat het als generieke taal is ontworpen kan het meegroeien met de eisen die nieuwe ontwikkelingen, zoals bijvoorbeeld smartphones, stellen. Dat laatste in contrast tot VB, JS, en in mindere mate PHP en Perl. (Disclaimer: ik ken deze laatste 4 talen niet allemaal uit eigen ervaring)
Je kunt net zo goed libraries in C/C++/Fortan maken en in PHP en Perl gebruiken, voor allen zijn redelijk eenvoudig bindings te creeren.
Mocht je SWIG gebruiken om je Python bindings te bouwen dan kun je zelfs in een moeite door de bijbehorende PHP-bindings ook genereren.
Maar inderdaad, PHP is met name ontworpen voor webdevelopment en daar is het dan ook zeer sterk in. Het gaat met de laatste major versies wel steeds meer richting general purpose, en wat ongelukkige design-keuzes uit het verleden (magic_quotes, auto-globals, dat soort dingen) worden langzaamaan deprecated. Deze dingen maakten de taal echter nog niet totaal waardeloos, als gevorderde developer zette je deze functies alsnog uit en schrijf je gewoon nette, onderhoudbare code. Deze is ook heel goed in te zetten voor niet-web applicaties.
Dat PHP makkelijk te leren is en vergeeflijk qua syntax heeft wel gemaakt dat het vaak misbruikt is door mensen die eigenlijk niet kunnen programmeren. Maar maakt dat de taal echt minder?
Mocht je SWIG gebruiken om je Python bindings te bouwen dan kun je zelfs in een moeite door de bijbehorende PHP-bindings ook genereren.
Maar inderdaad, PHP is met name ontworpen voor webdevelopment en daar is het dan ook zeer sterk in. Het gaat met de laatste major versies wel steeds meer richting general purpose, en wat ongelukkige design-keuzes uit het verleden (magic_quotes, auto-globals, dat soort dingen) worden langzaamaan deprecated. Deze dingen maakten de taal echter nog niet totaal waardeloos, als gevorderde developer zette je deze functies alsnog uit en schrijf je gewoon nette, onderhoudbare code. Deze is ook heel goed in te zetten voor niet-web applicaties.
Dat PHP makkelijk te leren is en vergeeflijk qua syntax heeft wel gemaakt dat het vaak misbruikt is door mensen die eigenlijk niet kunnen programmeren. Maar maakt dat de taal echt minder?
Het heeft ook veel mensen geïntroduceerd in het echte programmeren 
Alles wat?
*Dyslexie. Je zinsbouw is ook slecht trouwens...
Jullie hebben allebei gelijk, misschien moet ook ik maar weer eens nl les gaan volgen... Of iig mijn post nalezen en niet op mijn tablet typen
In principe ligt dit natuurlijk niet aan phonegap. Phonegap c.s. hebben het mogelijk gemaakt dat iedere pukkelpuber apps kan produceren. Dan krijg je inderdaad veel zooi.Je ziet het ook met phonegap en meer van dat soort tools. De apps zien er meestal niet uit.
Voor veel toepassingen is de performance niet super belangrijk. Het grote voordeel is - zoals gezegd - dat je m.b.v. 1 code base verschillende platformen kunt bedienen, en dat de stap naar een web-versie van je app ook heel klein is. Kortom: je kunt vrij gemakkelijk je app anywhere anytime beschikbaar maken.de performance en mogelijkheiden van native code is toch echt beter dan de script equivalenten in zijn geheel.
Zelf ben ik wel gecharmeerd van MoSync. Zij maken het mogelijk om natieve UI elementen te creeren m.b.v. HTML/JavaScript.
Naar mijn beste weten ligt het wel aan tools als PhoneGap en Titanium, gezien deze maar beperkte mogelijkheden bieden voor de vormgeving van je App.
Zelf heb ik 0 ervaring met (Objective) C programmeren (ben een client-side nerd) maar door Titanium (Appcelerator) heb ik toch een redelijke App in elkaar kunnen zetten. Echter de vormgeving laat nog e.e.a. te wensen over door de beperkte mogelijkheden die de tool mij bied.
Zelf heb ik 0 ervaring met (Objective) C programmeren (ben een client-side nerd) maar door Titanium (Appcelerator) heb ik toch een redelijke App in elkaar kunnen zetten. Echter de vormgeving laat nog e.e.a. te wensen over door de beperkte mogelijkheden die de tool mij bied.
Er zit wel degelijk heel veel vooruitgang in deze talen neem bijvoorbeeld JavaScript dat nu met nodejs als server language word gebruikt. Kijk voor de grap ook eens onderstaande vergelijking:
http://shootout.alioth.de...languages-are-fastest.php
http://shootout.alioth.de...languages-are-fastest.php
Wat is volgens jou een script taal? Er is vaak een enorme berg onduidelijkheid en verwarring bij veel mensen hierover, en dat lijkt hier ook het geval.
Er zijn diverse programma's met een GUI die gewoon in een "scripttaal" zoals Python geschreven zijn en die gewoon een prima performance hebben. Voor die delen die meer snelheid nodig hebben is het prima om slechts die delen in iets als C of C++ te schrijven.
Hoe een App er uit ziet heeft verder niks met de taal te maken. Ik kan in C++ en in Python gewoon Qt (bijvoorbeeld) gebruiken; aan de UI zie je dan niet terug wat is gebruikt.
Er zijn diverse programma's met een GUI die gewoon in een "scripttaal" zoals Python geschreven zijn en die gewoon een prima performance hebben. Voor die delen die meer snelheid nodig hebben is het prima om slechts die delen in iets als C of C++ te schrijven.
Hoe een App er uit ziet heeft verder niks met de taal te maken. Ik kan in C++ en in Python gewoon Qt (bijvoorbeeld) gebruiken; aan de UI zie je dan niet terug wat is gebruikt.
Ik zou scripttalen niet zo makkelijk afdoen. Oracle heeft bijvoorbeeld ADF Mobile gebaseerd op PhoneGap (JavaScript) i.p.v. te kiezen voor een Java oplossing. ADF is het Oracle framework dat de backbone vormt van haar Fusion Middleware stack. PhoneGap lost een pijn op; javascript zal door elke mobile provider ondersteunt worden.
[Reactie gewijzigd door Atsjie op 2 oktober 2012 22:10]
Voor veel apps is performance niet zo relevant, dat is alleen interessant voor high-end games. Veel apps zijn gewoon 90% niets aan het doen terwijl de gebruiker leest bijv. Voor die apps is een taal als javascript prima geschikt.
De meeste (zoniet alle) scripttalen gebruiken 'just in time' compilatie. De tijd die daardoor aan het script wordt besteedt is nihil ten opzichte van de eigenlijke functie.
Dat is onzin natuurlijk, de softwarestack heeft niks met design of UX te maken, maar alles met hoe creatief iemand is. Elk softwarepakket bestaat uit fases. Concept, Design, UX, functionaliteiten/specs (technisch en inhoudelijk), informatie architectuur, technische architectuur.
Ik bouw zelf apps met phonegap/titanium. En dat doe ik puur vanwege de architectuur. Het is onzinnig om voor elk platform een heel nieuwe app te bouwen. Elke update kan je het hele riedeltje opnieuw gaan doen dan. Ik was zelfs de hoofd architect van alle buienradar apps (2009-2011), al die apps zijn native en ik merkte toen al, dit kan slimmer. Gelukkig zijn vooral die apps een soort template/lege schil, die gevuld wordt met informatie via webservices en zo bouw ik apps ook zoveel mogelijk.
Phonegap/titanium zijn ook allemaal native apps, maar worden gebouwd met een schil eromheen, heel logisch, 1 generieke taal voor alle platformen.
PHP doet dus ook een duit in het zakje en ik denk, als dit van de grond komt, dit een killer wordt. Ik werk heel veel met php, gewoon omdat je er alles mee kan, simpel en snel. PHP volgt gewoon de weg die phonegap/titanium al bewandelen, de weg die gevraagd wordt door ontwikkelaars.
Ik bouw zelf apps met phonegap/titanium. En dat doe ik puur vanwege de architectuur. Het is onzinnig om voor elk platform een heel nieuwe app te bouwen. Elke update kan je het hele riedeltje opnieuw gaan doen dan. Ik was zelfs de hoofd architect van alle buienradar apps (2009-2011), al die apps zijn native en ik merkte toen al, dit kan slimmer. Gelukkig zijn vooral die apps een soort template/lege schil, die gevuld wordt met informatie via webservices en zo bouw ik apps ook zoveel mogelijk.
Phonegap/titanium zijn ook allemaal native apps, maar worden gebouwd met een schil eromheen, heel logisch, 1 generieke taal voor alle platformen.
PHP doet dus ook een duit in het zakje en ik denk, als dit van de grond komt, dit een killer wordt. Ik werk heel veel met php, gewoon omdat je er alles mee kan, simpel en snel. PHP volgt gewoon de weg die phonegap/titanium al bewandelen, de weg die gevraagd wordt door ontwikkelaars.
Dit is wel echt een hele goede stap van PHP, de cli"ent en de server kant
Ik heb liever dat alles serverside gedaan wordt.Scheelt weer rekenkracht en dus accu van mijn telefoon...
ja maar dan moet hij het alsnog ophalen en je verbinding gebruiken en meestal is dat het geen wat veel energie gebruikt
en meestal is dat het geen wat veel energie gebruikt
en server beheerders zien dat liever andersom, dan kunnen zij namelijk meer clients bedienen voor minder kosten.Ik heb liever dat alles serverside gedaan wordt.Scheelt weer rekenkracht en dus accu van mijn telefoon...
Dat heb je dan goed fout. 3G en Wifi gebruiken heel veel stroom. Alles wat je clientside kunt berekenen en dus niet door de lucht hoeft te sturen spaart je batterij aanzienlijk.
Gegevens zullen toch van de telefoon naar de server en terug moeten. Of je nu de code stuurt die uitgevoerd moet worden of de uiteindelijke html maakt toch niet zoveel uit?
Je kunt dan de code natuurlijk cachen op de telefoon, etc, maar echt veel verschil zou het ook niet uit hoeven maken.
Je kunt dan de code natuurlijk cachen op de telefoon, etc, maar echt veel verschil zou het ook niet uit hoeven maken.
Moah, HTTP is tamelijk efficient hoor. Eerste keer ophalen, de volgende keer een HEAD request, changed/length niet verandert, niets doen.
Aangezien het slechts om de app code gaat (die je alleen als je de app start nodig hebt), kun je dus in een paar milliseconden eenmalig verifiëren.
Aangezien het slechts om de app code gaat (die je alleen als je de app start nodig hebt), kun je dus in een paar milliseconden eenmalig verifiëren.
Het eerste waar ik aan moet denken bij php zijn gehackte webservers. Ik moet die meuk echt niet op mijn telefoon hebben.
Wat een kortzichtige reactie als je het mij vraagt. Als je een webserver niet onderhoudt (niet installeren van updates/upgrades), blijven er lekken openstaan. Dan vraagt een bedrijf om gehackt te worden. Dit heeft niets met de taal of de serversoftware te maken.
Daarnaast kan een slechte ontwikkeling van software er uiteraard ook voor zorgen dat websites/webservers gehackt worden. Ook dit heeft niets met de taal te maken. Beide gevallen hebben te maken met beleid en mensen.
On topic: Dit klinkt interessant! Zo kunnen webapps snel geport worden naar een native app. Voor de softwarebedrijven kunnen de kosten zo een stuk lager worden voor de ontwikkeling van (web)apps.
Daarnaast kan een slechte ontwikkeling van software er uiteraard ook voor zorgen dat websites/webservers gehackt worden. Ook dit heeft niets met de taal te maken. Beide gevallen hebben te maken met beleid en mensen.
On topic: Dit klinkt interessant! Zo kunnen webapps snel geport worden naar een native app. Voor de softwarebedrijven kunnen de kosten zo een stuk lager worden voor de ontwikkeling van (web)apps.
PHP is wel de láátste taal die ik wil gebruiken. Wat een baggertaal . Was ik nou op zoek naar strstr of stripos? Moest dat vijfde argument nou negatief zijn of false? Echt, de meest cryptische funtienamen en geoverloadde parameters. Nee dank je, van mij mag deze taal een stille dood sterven.
Dan liever Scala. Of JavaScript. Of Ruby. Of Python. Of Java. Of een van de miljard andere talen die stukken beter zijn dan PHP en óók serverside veel gebruikt worden.
. Was ik nou op zoek naar strstr of stripos? Moest dat vijfde argument nou negatief zijn of false? Echt, de meest cryptische funtienamen en geoverloadde parameters. Nee dank je, van mij mag deze taal een stille dood sterven.Dan liever Scala. Of JavaScript. Of Ruby. Of Python. Of Java. Of een van de miljard andere talen die stukken beter zijn dan PHP en óók serverside veel gebruikt worden.
[Reactie gewijzigd door Grauw op 2 oktober 2012 20:12]
Hier een hele pagina met PHP rants: http://me.veekun.com/blog...-a-fractal-of-bad-design/
Prachtig! Dank voor de link .
.
http://www.youtube.com/watch?v=kXEgk1Hdze0
Nog een dan
Elke taal heeft z'n voor- en nadelen. PHP heeft zeker wat eigenaardigheden, maar als je vanuit een C/C++ achtergrond komt heeft elke taal dat. Python heeft net zulke vreemde constructies in sommige plaatsen, Ruby wordt af en toe een wartaal met complexe algoritmes en heeft een dependency hell probleem, Java is voor veel dingen gewoon traag, ga zo maar door. Ik neem mensen die zeggen dat taal X de "beste" is dan ook niet serieus, want ze zijn geen van allen perfect en afhankelijk van je doel ook geen van allen altijd optimaal.
Daarnaast heeft PHP toch nog steeds weldegelijk een klein voordeel op de meeste concurrenten. Het is allerminst traag en Facebook heeft laten zien dat het nog veel sneller kan (zie HipHop VM). Python/Perl zitten al een hele tijd tegen hun grenzen aan en Ruby 1.9 is pas de eerste versie van Ruby die zich kan meten met de rest qua snelheid.
Ik werk zelf regelmatig met Python, Ruby en PHP en ik heb eigenlijk geen algemene voorkeur; het hangt er maar net vanaf wat mijn doel is. Voor web applicaties heeft PHP nog steeds mijn voorkeur omdat het een stuk minder resources nodig heeft dan Ruby; zelfs als je frameworks als Symfony of Rails tegenover elkaar zet. Om dat dan even te vertalen naar hoe de klanten dat zien: goedkoper, want er zijn minder en/of minder krachtige servers nodig. Met name het feit dat je in PHP meer kunt optimaliseren omdat je toch op een iets lager niveau zit helpt weldegelijk
Aan de andere kant is Ruby/Rails wel weer uitzonderlijk om snel wat dingen in elkaar te flansen, terwijl Python nog steeds het makkelijkst is om een kleine daemon in elkaar te stampen.
Nog een dan
Elke taal heeft z'n voor- en nadelen. PHP heeft zeker wat eigenaardigheden, maar als je vanuit een C/C++ achtergrond komt heeft elke taal dat. Python heeft net zulke vreemde constructies in sommige plaatsen, Ruby wordt af en toe een wartaal met complexe algoritmes en heeft een dependency hell probleem, Java is voor veel dingen gewoon traag, ga zo maar door. Ik neem mensen die zeggen dat taal X de "beste" is dan ook niet serieus, want ze zijn geen van allen perfect en afhankelijk van je doel ook geen van allen altijd optimaal.
Daarnaast heeft PHP toch nog steeds weldegelijk een klein voordeel op de meeste concurrenten. Het is allerminst traag en Facebook heeft laten zien dat het nog veel sneller kan (zie HipHop VM). Python/Perl zitten al een hele tijd tegen hun grenzen aan en Ruby 1.9 is pas de eerste versie van Ruby die zich kan meten met de rest qua snelheid.
Ik werk zelf regelmatig met Python, Ruby en PHP en ik heb eigenlijk geen algemene voorkeur; het hangt er maar net vanaf wat mijn doel is. Voor web applicaties heeft PHP nog steeds mijn voorkeur omdat het een stuk minder resources nodig heeft dan Ruby; zelfs als je frameworks als Symfony of Rails tegenover elkaar zet. Om dat dan even te vertalen naar hoe de klanten dat zien: goedkoper, want er zijn minder en/of minder krachtige servers nodig. Met name het feit dat je in PHP meer kunt optimaliseren omdat je toch op een iets lager niveau zit helpt weldegelijk
Aan de andere kant is Ruby/Rails wel weer uitzonderlijk om snel wat dingen in elkaar te flansen, terwijl Python nog steeds het makkelijkst is om een kleine daemon in elkaar te stampen.
In elk geval een gebalanceerde post. Ik zal de eerste zijn die Italiaans of Frans mooier vindt dan Engels. Als ik echter iets gedaan wil krijgen tussen een aantal buitenlandse partijen dan is Engels het meest effectief. Elke taalkundige zal zeggen dat Engels een bij elkaar geschraapt zooitje ongeregeld is. Boeit dat? Nee.
PHP is bovenal effectief en goed in waar het oorspronkelijk voor is bedoeld. Dat je iets in elkaar flanst is ook allang niet meer zo. De 2e generatie PHP frameworks die dit jaar uitkomen zijn niet alleen krachtiger dan ooit, maar ook een stuk makkelijker om mee te werken IMO. Ik denk niet dat iemand die daar serieus naar gekeken had, nog zou spreken over hobby-isten op zolderkamers. Dat was 5 tot 10 jaar geleden ja.
Uiteindelijk moet een taal, elke taal (ook gesproken taal) iets communiceren. Als dat te moeilijk is of te omslachtig komt de boodschap niet over. PHP heeft juist een hele mooie balans tussen eenvoud en diepgang IMO.
Wat betreft het artikel: dat PHP een dalende searchterm zou zijn is onzinnig: de populariteit van een searchterm wordt gemeten en logischerwijs is Objective-C heel "populair". Javascript is bijvoorbeeld ergens 10e qua searchterms, maar nagenoeg alle websites ter wereld gebruiken wel (een beetje) Javascript.
Dat PHP een compleet pakket wil aanbieden vindt ik op zich alleen maar interessant. Het zou wel PHP's reputatie van "alleseter" benadrukken. Maar het is niet eens noodzakelijk om populair te worden en/of te blijven IMO
PHP is bovenal effectief en goed in waar het oorspronkelijk voor is bedoeld. Dat je iets in elkaar flanst is ook allang niet meer zo. De 2e generatie PHP frameworks die dit jaar uitkomen zijn niet alleen krachtiger dan ooit, maar ook een stuk makkelijker om mee te werken IMO. Ik denk niet dat iemand die daar serieus naar gekeken had, nog zou spreken over hobby-isten op zolderkamers. Dat was 5 tot 10 jaar geleden ja.
Uiteindelijk moet een taal, elke taal (ook gesproken taal) iets communiceren. Als dat te moeilijk is of te omslachtig komt de boodschap niet over. PHP heeft juist een hele mooie balans tussen eenvoud en diepgang IMO.
Wat betreft het artikel: dat PHP een dalende searchterm zou zijn is onzinnig: de populariteit van een searchterm wordt gemeten en logischerwijs is Objective-C heel "populair". Javascript is bijvoorbeeld ergens 10e qua searchterms, maar nagenoeg alle websites ter wereld gebruiken wel (een beetje) Javascript.
Dat PHP een compleet pakket wil aanbieden vindt ik op zich alleen maar interessant. Het zou wel PHP's reputatie van "alleseter" benadrukken. Maar het is niet eens noodzakelijk om populair te worden en/of te blijven IMO
[Reactie gewijzigd door ByeSell op 2 oktober 2012 23:24]
En eens je goed LISP beheerst, heb je dat gevoel ook met C/C++...PHP heeft zeker wat eigenaardigheden, maar als je vanuit een C/C++ achtergrond komt heeft elke taal dat.
Wat dus ook min of meer mijn punt is
Kleine aanvulling: Met http://speed.pypy.org/ wordt er een Python interpreter gebouwd die 5x zo snel is.Python/Perl zitten al een hele tijd tegen hun grenzen aan
Ik denk dat veel meningen over andere programmeertalen gevormd worden op basis van onwetendheid. PHP heeft zijn kracht bewezen, Python laat met Django zien dat het een enorm krachtige combinatie is. Ik gebruik beiden; PHP voor WordPress sites, en Python/Django voor custom web apps and high performance sites.
Python is een general purpose taal, wat wil zeggen dat je er zowel kleine daemons in kan maken, als web frameworks. Ik denk dat daarmee mensen de taal anders inschatten, terwijl het juist daarom zoveel kracht heeft.
PHP heeft als grootste nadeel dat het gebouwd is rondom het idee van een web-request. Je script wordt ingeladen bij het begin, en wordt afgesloten bij het einde van het request. In een desktop applicatie heb je te maken met state, threads en persistency en geheugenbeheer. Op het web hebben Java/Python/Ruby/.NET dit ook, er draait 1 proces wat eindeloos doorloopt om alle requests af te handelen. In PHP land wordt een script echter maar kortstondig uitgevoerd, en daarna is alle state weer weg. Plugins, extenties en libraries gaan hier ook van uit, omdat dit is hoe PHP werkt.
PHP inzetten voor de client/mobile betekend dat je een totaal ander executie model hebt van je applicatie. Blijft PHP zo nog de simpele programmeertaal, en heeft het zin dit model naar de client te halen? Ik denk van niet. Of gaat men deze web ervaring emuleren, en welk voordeel heb je dan nog? Ik zie het niet,.
PHP op het web? ja. Op de client? Dat weet ik nog niet zo zeer; het is een snelle taal om je eigen te maken, alleen kan men van Python nog een hoop leren. Daar zitten veel handige constructies in die me in PHP veel meer typewerk kosten. Ik zie veel liever een andere taal die plek innemen, PHP is krachtig in zijn originele plek.
[Reactie gewijzigd door YaPP op 3 oktober 2012 13:30]
Phastlight is een interessante module die in ontwikkeling is die php als Node.JS laat gedragen. Event driven met worker threads dus. Het is nog wel redelijk experimenteel maar erg interessant.
https://github.com/phastlight/phastlight
https://github.com/phastlight/phastlight
haha, brilliant. Werk in de UK momenteel (zwaar traditioneel bedrijf, mensen praten echt zo daar...) en moest vorige week wat argumenten aandragen waarom geen php. Zal dit even toevoegen.
Ontopic: Waarom geen PHP. Geen problemen met PHP an sich. Alleen, wat ik vaak zie bij bedrijven is dat ze een stelletje middelmatige programmeurs in dienst hebben (vaak offshore) die een zooitje maken van Java. Productiviteit beneden alle peil en kwaliteit nog minder. Dan komt er altijd zo'n grappenmaker van een manager aan die zegt: "als we nu eens php gaan gebruiken dan stijgt de productiviteit." Inderdaad, de eerste twee releases. Daarna gebeurd er helemaal niets meer.
Ontopic: Waarom geen PHP. Geen problemen met PHP an sich. Alleen, wat ik vaak zie bij bedrijven is dat ze een stelletje middelmatige programmeurs in dienst hebben (vaak offshore) die een zooitje maken van Java. Productiviteit beneden alle peil en kwaliteit nog minder. Dan komt er altijd zo'n grappenmaker van een manager aan die zegt: "als we nu eens php gaan gebruiken dan stijgt de productiviteit." Inderdaad, de eerste twee releases. Daarna gebeurd er helemaal niets meer.
De schrijver van dat artikel hoeft geen PHP te gebruiken..
Doordat Internet Explorer vroeger "foute" html parsde, konden miljoenen amateurs aan de slag met websites.. (in tegenstelling tot netscape die de pagina weigerde te tonen).
Zo is PHP snel groot geworden.. Simpele code, en als je een fout maakte, zoals een niet bestaande functie aanroepen, wordt de code toch verder uitgevoerd.. In tegenstelling tot Perl die dan een Internet Server Error zou geven.
Een verademing na ASP, C# en Perl, toen ik eindelijk PHP ontdekte in 2001.. Eindelijk met productiviteit bezig zijn i.p.v. met error meldingen..
Yes, dat klinkt amateuristisch, maar zonder deze amateurs hadden veel grote websites niet bestaan..
Doordat Internet Explorer vroeger "foute" html parsde, konden miljoenen amateurs aan de slag met websites.. (in tegenstelling tot netscape die de pagina weigerde te tonen).
Zo is PHP snel groot geworden.. Simpele code, en als je een fout maakte, zoals een niet bestaande functie aanroepen, wordt de code toch verder uitgevoerd.. In tegenstelling tot Perl die dan een Internet Server Error zou geven.
Een verademing na ASP, C# en Perl, toen ik eindelijk PHP ontdekte in 2001.. Eindelijk met productiviteit bezig zijn i.p.v. met error meldingen..
Yes, dat klinkt amateuristisch, maar zonder deze amateurs hadden veel grote websites niet bestaan..
Zonder amateurs hadden grote websites en bedrijven nog bestaan.
Als je niet goed je exception handling regelt dan kun je beter gaan vakkenvullen.
Als je niet goed je exception handling regelt dan kun je beter gaan vakkenvullen.
Ik heb zelf websites op mijn naam staan die zijn uitgegroeid tot 'zeer grote':) websites.. 10 jaar geleden begonnen, als ik daar nu op terug kijk was het erg amateuristisch.
Bijvoorbeeld een gastenboek service met miljoenen gebruikers die is gebouwd met register_globals aan, en mysql_real_escape_string had ik nog nooit van gehoord..
(Met terugwerkende kracht jaren geleden gefixed)
Bijvoorbeeld een gastenboek service met miljoenen gebruikers die is gebouwd met register_globals aan, en mysql_real_escape_string had ik nog nooit van gehoord..
(Met terugwerkende kracht jaren geleden gefixed)
[Reactie gewijzigd door pim op 3 oktober 2012 01:22]
Websites die serieuze transacties afhandelen kunnen niet zonder exception handling. Maar, een leerzame discussie, zal voortaan als ik Nederlandse developers inhuur vragen naar hun tweakers.net nickname.....
[Reactie gewijzigd door loetje6 op 3 oktober 2012 02:29]
Ja dat zei je al.. Ik ontkrachtte je statement dat zonder amateurs in het verleden zoals mij enkele grote websites niet hadden bestaan.
Zelfs tweakers.net is ooit gestart door amateurs.
Zelfs tweakers.net is ooit gestart door amateurs.
Amateur vs. professional. Geef mij maar de fanatieke amateurs.
Fouten of beter gezegd "gebreken" vinden in een taal is vrij makkelijk.
Uitleggen waarom alternatief A,B of C dan wel alles biedt is een stuk lastiger, indien niet onmogelijk. Aangezien de genoemde lijst "gebreken" zo lang is, dat geen enkele taal al (!) die features wel biedt.
Uitleggen waarom alternatief A,B of C dan wel alles biedt is een stuk lastiger, indien niet onmogelijk. Aangezien de genoemde lijst "gebreken" zo lang is, dat geen enkele taal al (!) die features wel biedt.
Als het zo een verschrikkelijk slechte taal is volgens jou, waarom wordt het dan zo veel gebruikt?
Precies, want er is een direct verband tussen hoeveel iets gebruikt wordt en hoe goed het is.
Zoals ze in Amerika zeggen: "Eat shit, millions of flies can't be wrong!"
Zoals ze in Amerika zeggen: "Eat shit, millions of flies can't be wrong!"
Dat zeg ik niet, maar als het zo een slechte taal is, waarom wordt het dan gebruikt?
Omdat vroeger alle goedkope webhosting een LAMP stack had, en verder niks. Waarom weet ik ook niet. Heeft wellicht iets te maken met geheugengebruik of een bepaalde sandboxingfeature die het aantrekkelijk maakte voor lowbudgethostingbedrijven. De keus daarvoor is in ieder geval gedreven door de wensen van hostingbedrijven, en op een gegeven moment was daar een critical mass van en gingen meer en meer hostingbedrijven PHP aanbieden.
Developers gebruiken vervolgen PHP omdat ze eigenlijk geen keus hebben. Beetje dezelfde reden waarom je op een website JavaScript moet gebruiken. Als je een forumpakket in PHP maakte dan werd je potentiële install base gewoon vele malen groter dan een forum in Python. Dat was ook de reden dat ik in het verleden aan meerdere PHP-projecten heb gewerkt.
Maar ik zou het nu met geen stok meer aanraken. Ik heb daar inmiddels geen noodzaak meer toe, en objectief gezien is het gewoon een ontzettend slechte taal. Lees het hierboven gelinkte artikel maar, je mond valt er van open.
Developers gebruiken vervolgen PHP omdat ze eigenlijk geen keus hebben. Beetje dezelfde reden waarom je op een website JavaScript moet gebruiken. Als je een forumpakket in PHP maakte dan werd je potentiële install base gewoon vele malen groter dan een forum in Python. Dat was ook de reden dat ik in het verleden aan meerdere PHP-projecten heb gewerkt.
Maar ik zou het nu met geen stok meer aanraken. Ik heb daar inmiddels geen noodzaak meer toe, en objectief gezien is het gewoon een ontzettend slechte taal. Lees het hierboven gelinkte artikel maar, je mond valt er van open.
[Reactie gewijzigd door Grauw op 2 oktober 2012 21:06]
Vroeger: Goedkope webhosts, makkelijk om mee te beginnen, en makkelijk om aan te prutsen. Nu: Legacy code base
Waar zou jij een "goede" website of web-gebaseerde administratiesysteem dan in schrijven?Vroeger: Goedkope webhosts, makkelijk om mee te beginnen, en makkelijk om aan te prutsen. Nu: Legacy code base
Goed heeft niet zo zeer met de taal alleen te maken natuurlijk. Maar ik zie talen als C# die gewoon veel verder geevolueerd zijn al. Java is een optie, of zelfs gewoon C++11. Ik zie het nu niet zo van een vaagopgestelde weak-typed imperatieve taal; waarom wil je dat gebruiken als er (strict) betere alternatieven bestaan?
(ik heb zelf een jaar of drie als PHP-programmeur gewerkt)
(ik heb zelf een jaar of drie als PHP-programmeur gewerkt)
[Reactie gewijzigd door Zoijar op 3 oktober 2012 00:49]
Een applicatie (of website) die geen goed service oriented model ondersteunt is maar beperkt bruikbaar. Zodra de code base te groot wordt of de omgeving (e.g. datamodel) te dynamisch dan verdwijnt plotseling de productiviteit.
Dit heeft waarschijnlijk niet zoveel met de taal te maken maar meer met het gebruikte framework of de coding strategie. Probleem met PHP is dat het niet uitnodigd tot gestructureerd programmeren. Elk project wat ik tot dusver gezien heb dat gebruik maakte van PHP had altijd wel een half dozijn developers dat alle regels mbt gestructureerd programmeren aan de laars lapte (resultaat op korte termijn) en er dus een zooitje van maakte. Projecten in andere talen hadden dat een stuk minder.
Dus, als je een gedisciplineerde, gestructureerde programmeur bent kun je denk ik bijna elke taal gebruiken. Ben je dat niet, dan zul je met elke taal falen.
Dit heeft waarschijnlijk niet zoveel met de taal te maken maar meer met het gebruikte framework of de coding strategie. Probleem met PHP is dat het niet uitnodigd tot gestructureerd programmeren. Elk project wat ik tot dusver gezien heb dat gebruik maakte van PHP had altijd wel een half dozijn developers dat alle regels mbt gestructureerd programmeren aan de laars lapte (resultaat op korte termijn) en er dus een zooitje van maakte. Projecten in andere talen hadden dat een stuk minder.
Dus, als je een gedisciplineerde, gestructureerde programmeur bent kun je denk ik bijna elke taal gebruiken. Ben je dat niet, dan zul je met elke taal falen.
Ik zou de vraag eerder omdraaien: Waarom zou je jezelf kwellen door dit in php te schrijven terwijl het ook in een echte taal kan, veel eenvoudiger en foutbestendiger.
Omdat het veeeel makkelijker was dan 'concurrerende' talen 10 jaar terug(en gratis)..
Miljoenen amateurs konden er mee aan de slag..
Zelfs tweakers.net heeft volgens mij zijn forum database verloren zien gaan omdat het Ultimate Bulletin Board forum gebruikte.. Dat was geschreven in Perl.. En zo af en toe crashde de database(tekst bestanden).
Schijnbaar was Perl te moelijk, want er waren een hoop scripts te downloaden toendestijds die een hoop problemen gaven..
Toen stapte massaal iedereen over rond 2000 naar PHP&MySQL en errors leken verleden tijd.
En volgens mij is het nu nog steeds groot omdat PHP alles kan wat je wilt.. Dat andere talen beter, logischer of consistenter zijn doet er voor mij niet toe.. Ik heb 100% de vrijheid om te maken wat ik wil in PHP, het is 100% veilig.. Dus ik zie geen noodzaak om uit te kijken naar andere talen.
Miljoenen amateurs konden er mee aan de slag..
Zelfs tweakers.net heeft volgens mij zijn forum database verloren zien gaan omdat het Ultimate Bulletin Board forum gebruikte.. Dat was geschreven in Perl.. En zo af en toe crashde de database(tekst bestanden).
Schijnbaar was Perl te moelijk, want er waren een hoop scripts te downloaden toendestijds die een hoop problemen gaven..
Toen stapte massaal iedereen over rond 2000 naar PHP&MySQL en errors leken verleden tijd.
En volgens mij is het nu nog steeds groot omdat PHP alles kan wat je wilt.. Dat andere talen beter, logischer of consistenter zijn doet er voor mij niet toe.. Ik heb 100% de vrijheid om te maken wat ik wil in PHP, het is 100% veilig.. Dus ik zie geen noodzaak om uit te kijken naar andere talen.
100% veilig? Bedoel je daarmee security?
Wederom, PHP wordt te vaak gebruikt door programmeurs die eigenlijk niet in de buurt van een toetsenbord mogen komen. Daar heeft het de slechte naam aan te danken. Het is te makkelijk.
En nogmaals, als je niet aan exception handling doet dan kun je er maar beter mee stoppen.
Wederom, PHP wordt te vaak gebruikt door programmeurs die eigenlijk niet in de buurt van een toetsenbord mogen komen. Daar heeft het de slechte naam aan te danken. Het is te makkelijk.
En nogmaals, als je niet aan exception handling doet dan kun je er maar beter mee stoppen.
Yes, daarmee bedoel ik security..
Zelfs met register_globals aan is het mogelijk een 100% veilige website te maken.
(niet dat ik ze aan heb, maar toch)
Zelfs met register_globals aan is het mogelijk een 100% veilige website te maken.
(niet dat ik ze aan heb, maar toch)
Sorry beste Pim, (ook een reactie op eerdere berichten..). Als je een website (wat voor taal dan ook, zelfs static HTML met Apache) 100% veilig durft te noemen....grapjas. Zou zelfs geen forum bericht durven achter laten uit angst dat mijn email adres wordt gestolen...
In theorie kan idd apache met statische html gehacked worden, in de praktijk zijn er al jaren geen kwetsbaarheden meer aan het licht gekomen.
100% veilig is helaas nooit mogelijk. De praktijk leert dat het meestal de beveiliging van een web-app een gevalletje security through obscurity is. Verder heb je altijd nog kans van lekken op webserver, parser of DNS niveau, en daarboven op is er altijd een functie die kan lekken. De meeste veiligheid issues treden op omdat er niet nagedacht wordt over het escapes van een string, sessie hijacking, etc. Slechts een klein deel zijn exploits op de taal zelf.
Dat er ontzettend veel slechte programmeurs zijn, dat klopt. Deze blijven niet alleen beperkt tot PHP want ook op het gebied van .NET heb ik al onwijze prutsers mogen ontmoeten, en zelfs op het gebied van C/C++ kom ik genoeg mensen die niet bekwaam zijn in het programmeren.
De oorzaak is redelijk simpel. Met vrijwel alle programmeertalen is het mogelijk om iets in elkaar te flansen zonder dat daarbij echt een ontwerp bij komt kijken. Er wordt niet gekeken naar bedrijfskundige risico's, maar nog belangrijker, deze risico's worden niet afgedekt.
Dat er ontzettend veel slechte programmeurs zijn, dat klopt. Deze blijven niet alleen beperkt tot PHP want ook op het gebied van .NET heb ik al onwijze prutsers mogen ontmoeten, en zelfs op het gebied van C/C++ kom ik genoeg mensen die niet bekwaam zijn in het programmeren.
De oorzaak is redelijk simpel. Met vrijwel alle programmeertalen is het mogelijk om iets in elkaar te flansen zonder dat daarbij echt een ontwerp bij komt kijken. Er wordt niet gekeken naar bedrijfskundige risico's, maar nog belangrijker, deze risico's worden niet afgedekt.
Om dezelfde reden dat VB6 zoveel werd gebruikt voor windows ontwikkeling
php heeft dezelfde vibe als vb6: Enorm misbruikt door hobbyisten, verguisd door echte developers.
Omdat het merendeel van de programmeurs vreselijk slechte programmeurs zijn.
Verder zegt gebruik natuurlijk niks over kwaliteit.
Verder zegt gebruik natuurlijk niks over kwaliteit.
PHP is ooit populair geworden omdat het makkelijk te gebruiken is (installatie, configuratie, snel iets 'werkends' kunnen bouwen)
Iets wat populair is blijft dat helaas ook lange tijd. Iemand die nu besluit een dynamische website te bouwen en bijvoorbeeld op google zoekt naar 'build dynamic website' krijgt 80% hits die gaan over PHP, tja, dan zit de gedachte 'dan zal het wel goed zijn' natuurlijk snel in je hoofd.
Je kunt natuurlijk de mate van gebruik als maatstaaf nemen om te bepalen of een taal goed of slecht is maar dat lijkt mij niet heel zinvol. Er is niet echt een verband tussen kwaliteit en de kwantiteit van gebruik van een taal.
-Het is natuurlijk niet alleen de schuld van de taal zelf dat er mensen zijn met een hekel aan PHP. De 'programmeurs' maken er over het algemeen een potje van-
Iets wat populair is blijft dat helaas ook lange tijd. Iemand die nu besluit een dynamische website te bouwen en bijvoorbeeld op google zoekt naar 'build dynamic website' krijgt 80% hits die gaan over PHP, tja, dan zit de gedachte 'dan zal het wel goed zijn' natuurlijk snel in je hoofd.
Je kunt natuurlijk de mate van gebruik als maatstaaf nemen om te bepalen of een taal goed of slecht is maar dat lijkt mij niet heel zinvol. Er is niet echt een verband tussen kwaliteit en de kwantiteit van gebruik van een taal.
-Het is natuurlijk niet alleen de schuld van de taal zelf dat er mensen zijn met een hekel aan PHP. De 'programmeurs' maken er over het algemeen een potje van-
[Reactie gewijzigd door fdm391 op 2 oktober 2012 20:50]
Ben momenteel bezig op school Havo 5 met php, het hele server-side idee staat mij eigenlijk niet zo aan en vind het super dat nu dus ook client side mogelijk wordt. Dit zal het script schrijven een stuk makkelijker maken voor beginners
PHP kan al heel lang gewoon op de CLI worden gebruikt (pas nog gedaan), en er kunnen zelfs UI programma's in geschreven worden (PHP-Qt en co). Het is dus zeer zeker geen "server-side" taal zoals het artikel boven lijkt te willen suggereren.
Idd, doe het ook.
Sterker nog, veel websites, draaien nog een cronjob, die geschreven is in php.
Sterker nog, veel websites, draaien nog een cronjob, die geschreven is in php.
Beste Plankhorst,
je moet dingen daar doen waar ze thuishoren. Dus sommige dingen op de server, sommige dingen op de client.
Kleine tip, wat ik zelf vaak doe (als ik met Perl werk) is een kleine server omgeving bouwen die alleen het zware werk doet (database spul, encoden, whatever). Ik genereer geen of nauwelijks HTML. Die Perl programma's produceren alleen data (ingepakt in JSON of zo). De webpaginas worden volledig opgebouwt met JavaScript en bijvoorbeeld JQuery. Dus, AJAX request naar de webserver en met het resultaat (de data) lekker JQuery freubelen.
je moet dingen daar doen waar ze thuishoren. Dus sommige dingen op de server, sommige dingen op de client.
Kleine tip, wat ik zelf vaak doe (als ik met Perl werk) is een kleine server omgeving bouwen die alleen het zware werk doet (database spul, encoden, whatever). Ik genereer geen of nauwelijks HTML. Die Perl programma's produceren alleen data (ingepakt in JSON of zo). De webpaginas worden volledig opgebouwt met JavaScript en bijvoorbeeld JQuery. Dus, AJAX request naar de webserver en met het resultaat (de data) lekker JQuery freubelen.
Client side php, dat is toch zo'n beetje wat javascript is...
Alleen javascript kan dan weer geen native functies aanroepen zonder tussenlaag, zoals PhoneGap of andere conversie tools.
De vraag die in mij optkomt is: hoe kan dit betrouwbaar overkomen 
Als je scripting mogelijk maakt, dan wil je dit veilig doen. Websites die code downloaden om client-side lokaal uit te laten voeren zitten veelal in een sandbox. En hier gebruik je veelal Javascript voor. Hier PHP voor gebruiken zou onwenselijk zijn (en waarschijnlijk ook niet hun bedoeling).
Als 'alternatieve programmeertaal' voor lokale applicaties lijkt het mij ook niet veel toe te voegen. Tenzij je de GUI in HTML programmeert. Voor grafische componenten zou er dan een nieuwe library bij moeten komen (misschien is die er al ).
Maar dan kom je tegen waar je nu tegen PHP aanloopt. De vele amateurs en hun houwtje-touwtje oplossingen. Serverside waar een beheerder nog dingen kan regelen is dat niet een groot probleem (hoewel PHP sites veel gehackt worden
). Voor gebruikers die weinig tot niets van computers afweten is het niet te doen om programmaatje X op locatie Y te zetten en als Z te configureren.
En dan hebben ze nog de concurrentie van andere scripttalen die veelal client-side gebruikt worden, waaronder python. En Gutmans heeft zeker ook niet gehoord van de verdere ontwikkeling bij Java en .Net over dynamische/functionele talen.
Als je scripting mogelijk maakt, dan wil je dit veilig doen. Websites die code downloaden om client-side lokaal uit te laten voeren zitten veelal in een sandbox. En hier gebruik je veelal Javascript voor. Hier PHP voor gebruiken zou onwenselijk zijn (en waarschijnlijk ook niet hun bedoeling).
Als 'alternatieve programmeertaal' voor lokale applicaties lijkt het mij ook niet veel toe te voegen. Tenzij je de GUI in HTML programmeert. Voor grafische componenten zou er dan een nieuwe library bij moeten komen (misschien is die er al
).Maar dan kom je tegen waar je nu tegen PHP aanloopt. De vele amateurs en hun houwtje-touwtje oplossingen. Serverside waar een beheerder nog dingen kan regelen is dat niet een groot probleem (hoewel PHP sites veel gehackt worden
). Voor gebruikers die weinig tot niets van computers afweten is het niet te doen om programmaatje X op locatie Y te zetten en als Z te configureren.En dan hebben ze nog de concurrentie van andere scripttalen die veelal client-side gebruikt worden, waaronder python. En Gutmans heeft zeker ook niet gehoord van de verdere ontwikkeling bij Java en .Net over dynamische/functionele talen.
Leuk hoor, maar aangezien PHP vrijwel altijd wordt ingezet om tekst uit een database, in een HTML sjabloontje te zetten, zie ik het grote voordeel van client side PHP niet.
Je moet dan toch evengoed alle teksten, en vooral: plaatjes! nog steeds downloaden?
Je moet dan toch evengoed alle teksten, en vooral: plaatjes! nog steeds downloaden?
PHP wordt ook op de CLI gebruikt, en er kunnen ook gewoon GUI applicaties mee gemaakt worden (PHP-Qt, e.d.). Tuurlijk moet tekst & plaatjes nog gewoon gedownloaded worden. Maar berekeningen kunnen op de client gedaan worden. Waar nu JavaScript gebruikt wordt.
Ik denk niet dat we er blij van moeten worden, echter. Ik denk dat Python een veel betere candidaat is. Maar zoals altijd is het zelden goed wat wint, maar slechts gemiddeld.
Ik denk niet dat we er blij van moeten worden, echter. Ik denk dat Python een veel betere candidaat is. Maar zoals altijd is het zelden goed wat wint, maar slechts gemiddeld.
Goed idee, ik gebruik PHP ook al jaren als scripttaal op Unix, in plaats van perl of shell scripts.
Je hebt door de vele geintegreerde libraries zo makkelijk toegang tot zo veel functies die anders heel veel gedoe zijn. Een XML file ophalen van een HTTPS server en parsen, 3 regels. Wat in een database rommelen, ook 3 regels. Statussen checken met SNMP of Soap API's, ook zo geregeld. Geen geklooi met command line tooltjes aanroepen of vage libraries moeten installeren en configureren. Ik vind het heerlijk.
En voor de meeste veel gebruikte dingen zijn er al handige functies gemaakt. Tegenwoordig zit het ook netjes in elkaar vind ik, je kan natuurlijk een hoop rommel maken als je zonder kennis gaat zitten copy/pasten maar dat heb je met elke taal. PHP is alleen wat toegankelijker.
Je hebt door de vele geintegreerde libraries zo makkelijk toegang tot zo veel functies die anders heel veel gedoe zijn. Een XML file ophalen van een HTTPS server en parsen, 3 regels. Wat in een database rommelen, ook 3 regels. Statussen checken met SNMP of Soap API's, ook zo geregeld. Geen geklooi met command line tooltjes aanroepen of vage libraries moeten installeren en configureren. Ik vind het heerlijk.
En voor de meeste veel gebruikte dingen zijn er al handige functies gemaakt. Tegenwoordig zit het ook netjes in elkaar vind ik, je kan natuurlijk een hoop rommel maken als je zonder kennis gaat zitten copy/pasten maar dat heb je met elke taal. PHP is alleen wat toegankelijker.
Dat is in Python en in Perl niet veel anders. PHP is op zich een vreemde keuze, vind ik. Perl heeft op zeker veel en veel meer modules (waarvan je uiteraard de wat exotischere zelf mag installeren), en Python is een heel stuk vriendelijker voor programmeurs. Beiden steken ze verder, wat mij betreft, een flink stuk boven PHP uit. Maar goed, ieder natuurlijk zijn/haar voorkeur.Je hebt door de vele geintegreerde libraries zo makkelijk toegang tot zo veel functies die anders heel veel gedoe zijn. Een XML file ophalen van een HTTPS server en parsen, 3 regels. Wat in een database rommelen, ook 3 regels.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets E3 2013 Mobiele telefoons Google Sony Apple Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
