[alg/disc] PHP is dood? *

[Verwijderd]

Het wordt me de laatste tijd steeds duidelijker dat php in veel opzichten tekort schiet. Nu heb ik zo'n 1,5 jaar ervaring met het programmeren in PHP. Ik heb kleine tot middelgrote projecten in php gedaan. Voor de kleine projecten is php redelijk bevallen, maar al heel snel loop je tegen de beperkingen van de taal op. De volgende beperkingen zijn hiervan voor mij de meest belangrijke:

OOP
"PHP is OO!" heb ik ooit eens gelezen in een artikel op internet. Nou, mooi niet dus .

In PHP zijn standaard nagenoeg geen classes beschikbaar. Zo is er bijvoorbeeld zelfs geen datum/calender class beschikbaar. Als je OO wilt programmeren in PHP, dan zul je dus zelf voor deze classes moeten zorgen. Of hier al projecten voor zijn weet ik niet.

Private variabelen ondersteunt php ook niet. Zo is het dus niet mogelijk om "encapsulation" toe te passen in PHP. Wat volgens mij elke taal die OO wilt zijn, minimaal moet ondersteunen.

Een ander nadeel is het parameter meganisme. In PHP wordt een referentie naar een variabele meegegeven als parameter. Wanneer de variabele gewijzigd wordt, wordt de variabele gekopieerd en wijst de parameter naar het kopie. Het is wel mogelijk om aan te geven dat een parameter altijd een referentie moet zijn. Dit kun je doen door een & voor de parameter te zetten. Ook is het niet mogelijk om netjes aan te geven van welk type een parameter moet zijn. Je kunt wel een paar checks bovenin de methode zetten, maar dat is niet erg netjes

Een soortegelijk verhaal heb je bij het returnen van variabelen in methode Standaard wordt de waarde van een variabele zelf teruggegeven. Door voor de methodenaam een & te zetten, kun je aangeven dat een referentie teruggegeven moet worden. Een ander probleem bij het returnen van variabelen in methode is dat je niet kunt aangeven welk type variabele terug gegeven moet worden.

Maar wat misschien nog wel het meest irritant is aan PHP, dat is dat variabelen niet gedeclareerd hoeven te worden. Als je een typefout maakt en probeert een niet bestaande instance variabele een waarde te geven, zie je geen enkele foutmelding of warning. En als je dan in een groot project bezig bent en de applicatie doet niet wat je wilt, probeer dan de fout maar eens te vinden

Bibliotheek
In PHP heeft de programmeur de beschikking over een groot aantal functies. Het idee is goed, maar de uitvoering is stukken minder. PHP kent functies met dezelfde naam (aliases). Door aliases wordt de taal er niet veel overzichtelijker op. Ook op de naamgeving van de functies is genoeg aan te merken. Zoals b.v. de functie "count()", wat telt dat ding nu? Telt die functie nu ook het aantal characters in een string (character array)?

Runnen van scripts
In php wordt bij het runnen van een script het script door de interpreter gehaald en stopt het script na de uitvoer. Wat veel logischer zou zijn, is dat er een applicatie draait (als uitbreiding op de webserver) die voor dynamische content zorgt. Nu kan informatie bewaard worden in de sessie, filesystem, cookies of database. Het nadeel van als deze manieren is dat bij geen enkele manier het openhouden van een resource mogelijk is.

Het openhouden van een connectie met een database is wel mogelijk met persistent connections. Maar als je dan per gebruiker een connectie wilt hebben is dat niet mogelijk.


Dit is mijn mening over PHP. Graag zou ik van jullie willen weten wat jullie hiervan vinden. Of jullie voor mijn problemen oplossingen weten en of jullie zelf ook problemen in de taal tegenkomen.

[Jaspertje]

Ik programmeer alleen is ASP, maar ik was van mening dat PHP net als ASP meer een scripttaal was??? of kan iets een script taal zijn en OO??

[Verwijderd]

Moet een taal voor webscripting wel persee OO zijn???
PHP is juist ook geschreven voor kleine en middelgrote projecten! Aliasses zijn er om de compatibaliteit met oudere versies te houden, dit is alleen maar handig.

Dat je variabelen niet hoeft de declareren -> nog nooit van error_reporting(E_ALL) gehoord...
Wat jij zegt komt op mij een btje over als dat je PHP helemaal afzeikt terwijl je gewoon de taal misbruikt. Als jij websites gaat schrijven waarbij OO 100% noodzakelijk is moet je php gewoon niet gebruiken.....

[_Thanatos_]

Ik bedenk zo ff nog een paar nadelen van PHP:
• PHP draait niet in-process, maar is een externe executable die voor iedere pagina die op de server geparsed wordt, wordt opgestart.
• PHP zou z'n scripts moeten compileren naar iets dat sneller te interpreteren valt, net zoals .NET, classic ASP en Java dat doen.
• Globale variabelen werken heel vreemd in PHP. Eerst kon je querystring -en formvariabelen direct aanroepen, toen opeens niet meer. Ook moet je in een functie expliciet aangeven dat je een globale variabele wilt gebruiken. Bovendien is de aanroep van server-variabelen ook verre van duidelijk voor mij.
• PHP geeft zeer cryptische foutmeldingen, waar bijv ASP.NET een hele pagina vol geeft met foutmelding, stuk van de source waar het mis ging en allerlei extra info (gelieve die op de live site natuurlijk te verbergen )
• Tot slot vind ik het jammer dat PHP geen globale events heeft voor het beëindigen van een sessie of applicatie.

Voor de rest is het best een leuke taal voor hobby -en kleine commerciële projecten.

[Sybr_E-N]

PHP is GEEEEN programeertaal, maar een web scripting taal.

PHP is ooit bedacht om snel en makkelijk web pagina's in elkaar te zetten, dynamisch HTML output generen. Je ook geen variabelen te declareren, want dat is gemakkelijker voor de maker van de site. Zo zijn er meer van de grappen die de makers van PHP er in hebben, zoals de ts al noemde de aliasses van de functions.

[Verwijderd]

Een paar opmerkingen:

• Wanneer je alle foutmeldingen wilt zien doe dan gewoon error_reporting(E_ALL). Dus dan zie je ook wanneer je een typfout hebt gemaakt in de namen van variabelen.
• De namen van functien vind ik prima zo. Vooral omdat er een super handige uitgebreide manual voor is.

En OO is best goed mogelijk hoor. Ik heb nu een forum script dat al aardig af is en door het gebruik van classes is alles zeer netjes.

[Fuzzillogic]

Op punten heb je zeker gelijk. Maar ik heb het idee dat een pure OO-taal nou eenmaal lastiger te leren is dan een imperatieve taal zoals PHP tot op heden. Wellicht dat dat 1 van de redenen van het succes is.

Maar PHP5 gaat betere OO ondersteunen, met private en public class members etc. Dat betekent niet dat meteen de hele PHP API OO zal zijn (<-geweldig, die acroniemen ) Persoonlijk vind ik niet dat dat een groot probleem hoeft te zijn. Als je met een eigen, groter project bezig bent kun je daar zelf al OO classes voor maken. Dat gaat in PHP4 al vrij aardig.

Die aliases, sja.. da's vooral legacy-zut om compatibility te behouden. Zou fraai zijn als *geen enkel PHP4 script* meer werkt in PHP5.

Nou heb ik vrijwel geen ervaring met Java en JSP, maar zou dat niet iets zijn voor jou? Dan heb je een krachtige OO taal, met strong-typing en overzichtelijk(ere) library.

[Soultaker]

Ach ja, deze discussie maar weer eens.

Verwijderd schreef op 02 februari 2003 @ 15:18:
Private variabelen ondersteunt php ook niet. Zo is het dus niet mogelijk om "encapsulation" toe te passen in PHP. Wat volgens mij elke taal die OO wilt zijn, minimaal moet ondersteunen.

Je kunt OOP ook als stramien voor de programmeur zien, waarbij de taal alleen de mogelijkheid biedt tot OO-programmeren, maar de programmeur daar niet toe dwingt. Jouw stelling impliceert dat een taal als Python, die ook geen échte private members ondersteund, ook geen OO-taal is.

Een ander nadeel is het parameter meganisme. In PHP wordt een referentie naar een variabele meegegeven als parameter. Wanneer de variabele gewijzigd wordt, wordt de variabele gekopieerd en wijst de parameter naar het kopie. Het is wel mogelijk om aan te geven dat een parameter altijd een referentie moet zijn. Dit kun je doen door een & voor de parameter te zetten.

Sorry; ik snap je punt niet. Wat is nu precies het 'nadeel' dat je noemt? De syntax voor by reference passing? Het feit dat PHP 'by default' argument by value passed? In geen van beide zie ik veel kwaads, zeker niet in de meest recente versie van PHP waar ze de syntax en semantiek van by reference passing een beetje opgeschoond hebben.

Ook is het niet mogelijk om netjes aan te geven van welk type een parameter moet zijn. Je kunt wel een paar checks bovenin de methode zetten, maar dat is niet erg netjes.

Valt dit nog steeds onder het kopje OOP? Volgens jouw redenatie, is Python weer geen OO-taal, maar de makers denken daar toch anders over. Verder is impliciete typering kenmerkend voor scriptingtalen, wat PHP in de kern toch is.

PHP kent functies met dezelfde naam (aliases). Door aliases wordt de taal er niet veel overzichtelijker op.

Ik dacht dat aliases verschillende namen voor dezelfde functie waren. Jij bedoelt, denk ik, overloading, maar die is bijna nergens beschikbaar (en meestal alleen omwille van de backwards compatibility). Je zou optionele argumenten eventueel nog als vorm van overloading kunnen zien, trouwens.

Ook op de naamgeving van de functies is genoeg aan te merken. Zoals b.v. de functie "count()", wat telt dat ding nu? Telt die functie nu ook het aantal characters in een string (character array)?

Inderdaad, dat is erg jammer. Ook het feit dat sommige functies wel geprefixed worden, zoals array_pop(), en sommige juist weer niet, zoals suffle(), getuigt van ondoordachte naamgeving.

In php wordt bij het runnen van een script het script door de interpreter gehaald en stopt het script na de uitvoer. Wat veel logischer zou zijn, is dat er een applicatie draait (als uitbreiding op de webserver) die voor dynamische content zorgt.

Met de Zend encoder kan dat prima hoor.

Nu kan informatie bewaard worden in de sessie, filesystem, cookies of database. Het nadeel van als deze manieren is dat bij geen enkele manier het openhouden van een resource mogelijk is.

File handles wil je toch al niet open houden. Waarom zou je in een op HTTP gebaseerd systeem sockets open willen houden, als je niet weet of er ooit nog een volgend request komt? Het enige wat ik me kan voorstellen, is dat je de verbinding met je database open wilt houden, omdat die verbinding binnen verschillende sessies gebruikt kan worden. En dat kan nu weer net wel!

Dit is mijn mening over PHP. Graag zou ik van jullie willen weten wat jullie hiervan vinden. Of jullie voor mijn problemen oplossingen weten en of jullie zelf ook problemen in de taal tegenkomen.

Ik ben het wel in grote lijnen met je kritiek eens, maar niet met al je stellingen. Je moet je realiseren dat PHP, net als veel andere scriptingtalen, niet ideaal is voor het uitvoeren van grote projecten, al kun je het daar wel voor gebruiken. In ieder geval is PHP een stuk beter toegerust op het gebruik in websites, dan veel andere scripting en non-scripting talen.

[vinnux]

Alle nadelen die je noemt hebben tegelijk een groot voordeel, waardoor PHP op dit moment zo groot is als het is. EENVOUDIGHEID. PHP is snel te leren en zeer eenvoudig in gebruik.
Daarmee is het een uistekende opstap naar b.v. andere scripting talen.

De kracht van PHP zit hem in de honderdeb functies en aansluitingen op andere componenten en programma's. OO en patronen en andere ontwerp en implementatie methodes kunnen uitstekens worden toegepast in PHP, als je je aan de richtlijnen er van houd. Omdat PHP je niet dwingt om die patronen te handhaven wil dat niet zeggen dat je ze niet kunt gebruiken. Het vereist wat meer disipline van de programmeur. That is all.

PHP is een mooie taal voor de oorspronkelijk doeleinden.

[Fuzzillogic]

_Thanatos_ schreef op 02 februari 2003 @ 15:29:
Ik bedenk zo ff nog een paar nadelen van PHP:
• PHP draait niet in-process, maar is een externe executable die voor iedere pagina die op de server geparsed wordt, wordt opgestart.

Ligt aan je webserver/OS. Bij Apache draait het in-process.

• PHP zou z'n scripts moeten compileren naar iets dat sneller te interpreteren valt, net zoals .NET, classic ASP en Java dat doen.

Er zijn accelerators, die de gecompileerde versie cachen.

• Globale variabelen werken heel vreemd in PHP. Eerst kon je querystring -en formvariabelen direct aanroepen, toen opeens niet meer. Ook moet je in een functie expliciet aangeven dat je een globale variabele wilt gebruiken. Bovendien is de aanroep van server-variabelen ook verre van duidelijk voor mij.

Daar zijn grotere veranderingen gekomen sinds PHP4.0 en PHP4.1. Momenteel vind ik de situatie best bruikbaar. Als je in een functie van een global var gebruik wilt maken, dan moet je dat expliciet aangeven. Niet verkeerd imo. Bovendien is er $GLOBALS[], waar prima mee te werken is.

• PHP geeft zeer cryptische foutmeldingen, waar bijv ASP.NET een hele pagina vol geeft met foutmelding, stuk van de source waar het mis ging en allerlei extra info (gelieve die op de live site natuurlijk te verbergen )

Een soort van stack/function trace mis ik wel ja..

Voor de rest is het best een leuke taal voor hobby -en kleine commerciële projecten.

Ook grote projecten schijnen er wel mee te kunnen. Over een maand of wat kan ik je daar maar over vertellen

[Soultaker]

_Thanatos_ schreef op 02 February 2003 @ 15:29:
Ik bedenk zo ff nog een paar nadelen van PHP:
• PHP draait niet in-process, maar is een externe executable die voor iedere pagina die op de server geparsed wordt, wordt opgestart.

Dan heb je de boel wel heel onhandig geconfigureerd. PHP is als webserver module beschikbaar voor een stuk of 20 populaire webservers.

• PHP zou z'n scripts moeten compileren naar iets dat sneller te interpreteren valt, net zoals .NET, classic ASP en Java dat doen.

Dat kan, met Zend encoder. Dit is alleen niet gratis, net zoals ASP en het .NET platform niet gratis zijn.

• Globale variabelen werken heel vreemd in PHP. Eerst kon je querystring -en formvariabelen direct aanroepen, toen opeens niet meer. Ook moet je in een functie expliciet aangeven dat je een globale variabele wilt gebruiken. Bovendien is de aanroep van server-variabelen ook verre van duidelijk voor mij.

Jij snapt het niet dus is het een nadeel van PHP? Ik vind het anders vrij logisch. Je kunt zelf kiezen of je externe variabelen in je global scope krijgt aangeboden, maar de reden dat dit van default aan naar default uit is gegaan, is dat zoveel prutsers er niet mee om konden gaan.

[Zoijar]

Ik ben het eigenlijk vrijwel nergens met je eens...

Verwijderd schreef op 02 februari 2003 @ 15:18:

OOP
"PHP is OO!" heb ik ooit eens gelezen in een artikel op internet. Nou, mooi niet dus .

In PHP zijn standaard nagenoeg geen classes beschikbaar. Zo is er bijvoorbeeld zelfs geen datum/calender class beschikbaar. Als je OO wilt programmeren in PHP, dan zul je dus zelf voor deze classes moeten zorgen. Of hier al projecten voor zijn weet ik niet.

OOP is een paradigme, dwz een manier van programmeren (met bijbehorende language support). Dat er geen class libraries zijn (wat overigens niet eens waar is, neem bv PEAR alleen al) wil niet zeggen dat een taal het OO paradigme niet ondersteund. Een taal is ook niet OO, een taal kan gebruikt worden (of niet) om OO te programmeren.

Private variabelen ondersteunt php ook niet. Zo is het dus niet mogelijk om "encapsulation" toe te passen in PHP. Wat volgens mij elke taal die OO wilt zijn, minimaal moet ondersteunen.

Toegegeven, dat punt kon beter. Maar in principe kan je zelf gewoon een naming scheme aanhouden. Alle vars/methods die eindigen op een underscore zijn bv private. Dan kan je die als buitenstaander nog steeds gebruiken, dat wel, maar je weet al dat je fout bezig bent dan. Je kan ook in een C++ header de regel "#define private public" opnemen; dan weet je ook dat je fout bezig bent.

Een ander nadeel is het parameter meganisme. In PHP wordt een referentie naar een variabele meegegeven als parameter. Wanneer de variabele gewijzigd wordt, wordt de variabele gekopieerd en wijst de parameter naar het kopie. Het is wel mogelijk om aan te geven dat een parameter altijd een referentie moet zijn. Dit kun je doen door een & voor de parameter te zetten.

Wat is het nou? Kan het nu wel of niet? Er wordt toch gewoon call-by-value en call-by-reference ondersteund dan? Dat van dat kopie is alleen een optimalisatie, je optimizing C++ compiler maakt ook geen kopie als jet het object niet wijzigd (als het goed is)

Ook is het niet mogelijk om netjes aan te geven van welk type een parameter moet zijn. Je kunt wel een paar checks bovenin de methode zetten, maar dat is niet erg netjes

Een soortegelijk verhaal heb je bij het returnen van variabelen in methode Standaard wordt de waarde van een variabele zelf teruggegeven. Door voor de methodenaam een & te zetten, kun je aangeven dat een referentie teruggegeven moet worden. Een ander probleem bij het returnen van variabelen in methode is dat je niet kunt aangeven welk type variabele terug gegeven moet worden.

Tsja, PHP is nou eenmaal geen strong-typed taal. Ik werk persoonlijk ook liever met strong-type checking, maar de PHP manier heeft ook wel weer zo z'n voordelen. Een "factory" is bv 2 regels in PHP.

Maar wat misschien nog wel het meest irritant is aan PHP, dat is dat variabelen niet gedeclareerd hoeven te worden. Als je een typefout maakt en probeert een niet bestaande instance variabele een waarde te geven, zie je geen enkele foutmelding of warning. En als je dan in een groot project bezig bent en de applicatie doet niet wat je wilt, probeer dan de fout maar eens te vinden

Dit is wel vervelend ja. Hoewel je toch meestal wel een warning krijgt omdat er iets fout gaat. Warnings in PHP moet je opvatten als errors, dat is al tijden bekend.

Bibliotheek
In PHP heeft de programmeur de beschikking over een groot aantal functies. Het idee is goed, maar de uitvoering is stukken minder. PHP kent functies met dezelfde naam (aliases). Door aliases wordt de taal er niet veel overzichtelijker op. Ook op de naamgeving van de functies is genoeg aan te merken. Zoals b.v. de functie "count()", wat telt dat ding nu? Telt die functie nu ook het aantal characters in een string (character array)?

Specificatie lezen?

Runnen van scripts
In php wordt bij het runnen van een script het script door de interpreter gehaald en stopt het script na de uitvoer. Wat veel logischer zou zijn, is dat er een applicatie draait (als uitbreiding op de webserver) die voor dynamische content zorgt. Nu kan informatie bewaard worden in de sessie, filesystem, cookies of database. Het nadeel van als deze manieren is dat bij geen enkele manier het openhouden van een resource mogelijk is.

Het openhouden van een connectie met een database is wel mogelijk met persistent connections. Maar als je dan per gebruiker een connectie wilt hebben is dat niet mogelijk.

HTTP is nou eenmaal een stateless protocol, dat heeft zo zijn consequenties voor de webscripting talen. Sessies zijn al een mooie oplossing imo, evenals cookies.

[chem]

Veel argumenten hier zijn een beetje kansloos. Ik heb geen zin in om allemaal berichten te quoten en vv. te weerleggen, maar vind zeer zeker niet dat PHP dood is.
Er zijn hele ladingen aan classes te vinden, van dba tot soap/xml-rpc, vrijwel allemaal compleet en werkend. En niet alleen in de PEAR, maar ook op andere verzamelsites zoals phpclasses.org en hotscripts.com.

Dat PHP vreselijk inconsistent is mag wel gezegd worden. Parameter volgordes gaan bijna random bv.
Dat variabelen niet per se van te voren geinitialiseerd hoeven te worden is mijn inziens geen flaw, maar een handigheid, en een bijkomstigheid van de type-juggling van PHP. Zet je error maar op E_ALL, en hupsa - daar heb je je 'fout' meldingen.

Grote projecten zijn zeker wel mogelijk in PHP, kijk maar naar Horde, React, en vele vele andere projecten. Het is wel raadzaam zelf een framework op te zetten.

PHP kan wel gecompiled worden, maar het hoeft niet. De PHP parser is al vreselijk snel, dus het realtime parsen en uitvoeren is in vrijwel alle gevallen afdoende - high performance doeleindes uitgesloten, maar hierbij is het compilen slechts 1 van de vele factoren die een rol spelen in het optimizen van je applicatie.

[ Voor 16% gewijzigd door chem op 02-02-2003 15:48 ]

[Soultaker]

Ik merk dat Foxboy, [C] en Zoijar allemaal onterecht opmerken dat je met error reporting E_ALL het door een typefout verkeerd toekennen van een een variabele zou kunnen detecteren. Dat is echt niet het geval, zoals de topic starter al zei!

Neem bijvoorbeeld de volgende code:

PHP:

error_reporting(E_ALL);
$goed = 123;
$geod = 456;
echo $goed;

In werkelijkheid kan tussen de drie statements veel meer code zitten en dan is het niet zo eenvoudig te vinden dat de toekenning mislukt is.

[ACM]

Sybr_E-N schreef op 02 February 2003 @ 15:29:
PHP is GEEEEN programeertaal, maar een web scripting taal.

Je programmeert toch in php? Dan is het toch een programmeertaal?

En ja, de "definitie" voor programmeertalen vs scriptingstalen is wat vaag en er zijn talloze verschillende te geven.

Laten we het er gewoon op houden dat php een programmeertaal is, simpelweg omdat je er in kan programmeren.

En bash' "scripting language" is dan een scripttaal, daar kan je niet echt uitgebreid in programmeren afaik.

PHP is ooit bedacht om snel en makkelijk web pagina's in elkaar te zetten, dynamisch HTML output generen. Je ook geen variabelen te declareren, want dat is gemakkelijker voor de maker van de site. Zo zijn er meer van de grappen die de makers van PHP er in hebben, zoals de ts al noemde de aliasses van de functions.

Dat was versie 1.0 ja. We zijn ondertussen bij 4.3 en hoewel er nog steeds een hoop aan schort is het een zeer bruikbare taal.
Dat je als ervaren php-programmeur de fouten inziet is handig, dan kan je er rekening mee houden.

Java is ook echt niet alles en voor dezelfde functionaliteit moet je vaak VEEL meer code schrijven in Java.

[Nielsz]

Verwijderd schreef op 02 februari 2003 @ 15:18:
OOP
"PHP is OO!" heb ik ooit eens gelezen in een artikel op internet. Nou, mooi niet dus .

In PHP zijn standaard nagenoeg geen classes beschikbaar. Zo is er bijvoorbeeld zelfs geen datum/calender class beschikbaar. Als je OO wilt programmeren in PHP, dan zul je dus zelf voor deze classes moeten zorgen. Of hier al projecten voor zijn weet ik niet.

PEAR
Dat blijkbaar niemand de moeite heeft genomen om een datumclass te maken ligt aan het feit dat waarschijnlijk blijkbaar 'm nodig heeft. En het feit dat niemand er classes voor gemaakt heeft maar dat je dat zelf moet doen betekend dat niet dat PHP dan maar kut is.

Trouwens in Smarty zit er een class bij, en verder zijn er 10tallen dingen te vinden op internet. Een oudcollega had trouwens ook zelf een class gemaakt in ASP.NET omdat die andere niet voldeed, dus het gaat niet alleen over PHP.
Of je er nou geen levert, of eentje die niet voldoet ;)[/quote]

[Apache]

Er is wel geprobeerd te onderbouwen, ik had zeker geen zin om heel de thread te doorlezen maar wat ik direct merkte was dat het merendeel van de problemen z'n oorzaak vonden in het niet genoeg kennen van PHP, niet weten wat er in PHP 5.x komt, en gewoon helemaal niet door heeft waarvoor sommige dingen gebruikt voor moeten worden.

Het zelf niet onderbouwen zou beetje smerig zijn dus als voorbeeld geef ik: PEAR, php 5 & ZE2 hebben nu echt aandacht gekregen voor oop zodat dingen als private, public, protected er gewoon zullen in zitten, en pconnect -> connectionpooling bvb.

[ACM]

Toekomstige features van php moet je niet als argumentatie voor het gebrek nu gebruiken.
Dat php5 wel beter om zou moeten gaan met OO maakt 4.3 niet eens geschikt ervoor.

Zelfde wanargumenten worden wel eens bij mysql gebruikt als je het over het gebrek aan subselects e.d. hebt.

pconnects != connectionpooling, bij lange na niet!
pconnects is een persistent connectie die herbruikbaar in het geheugen blijft, bij apache heb je dan _per_ child een connectie (bij een druk bezochte site met 512 clients dus max 512)

Echt connectionpooling is wel even wat anders, zodra een connectie gesloten wordt mag een ander process/thread hem gebruiken met als gevolg dat je met dat zelfde drukke voorbeeld bijvoorbeeld maar 50 connecties nodig hebt.

[mbravenboer]

Als je je niet meer thuis voelt bij de natuur van een taal ben je de taal misschien wel ontgroeid (in dat geval gefeliciteerd ! ) of werk je aan software die niet past bij de natuur van de taal (in dat geval ben je zelf dom bezig).

De enige serieuze kritiek die je kan hebben op het hele design van is wellicht dat PHP te vaak wordt gebruikt voor software die beter niet ontwikkeld kan worden met een taal met een natuur als die van PHP.

PHP is ontstaan als een pruts-maar-wat-raak project en het past ook best goed in pruts-maar-wat-raak software. Het is wellicht jammer dat de PHP ontwikkelaars het lef hebben gehad om anderen lastig te vallen met hun geprusts, maar aan de andere kant was er anders vast een andere prutser geweest die een pruts-maar-wat-raak taal had gemaakt. Er is gewoon een markt voor dergelijke talen/omgevingen.

[.oisyn]

ik kwam in deze topic eigenlijk om te typen wat mbravenboer in z'n laatste alinea heeft getypt (grrr ). Ik sluit me daar dan ook volledig bij aan. PHP is een uit de hand gelopen hobby project wat echt te ranzig in elkaar zit. De makers hebben van tevoren duidelijk amper over dingen nagedacht, wat er ook voor gezorgd heeft dat de engine al 2x opnieuw from scratch geschreven is

[ACM]

mbravenboer schreef op 02 February 2003 @ 16:13:
Als je je niet meer thuis voelt bij de natuur van een taal ben je de taal misschien wel ontgroeid (in dat geval gefeliciteerd ! ) of werk je aan software die niet past bij de natuur van de taal (in dat geval ben je zelf dom bezig).

Hoewel ik vrij aardig met Java overweg kan, zal ik toch niet gauw alles wat ik nu met php doe in Java/servlets/jsp gaan bouwen.
Dat kost domweg meer tijd een simpel test applicatietje, voor iets dat net even te veel moeite is om met de hand uit te rekenen, kost me in php wellicht 30 regels code en een half uur schrijf/test/executie tijd.
In java kost me dat gegarandeerd meer tijd en ook meer code. Zeker als het moet spelen met een database of even een file van het internet downloaden.

De enige serieuze kritiek die je kan hebben op het hele design van is wellicht dat PHP te vaak wordt gebruikt voor software die beter niet ontwikkeld kan worden met een taal met een natuur als die van PHP.

Dat ben ik wel met je eens, hoewel je soms door omstandigheden er toe gedwongen kan zijn.

PHP is ontstaan als een pruts-maar-wat-raak project en het past ook best goed in pruts-maar-wat-raak software. Het is wellicht jammer dat de PHP ontwikkelaars het lef hebben gehad om anderen lastig te vallen met hun geprusts, maar aan de andere kant was er anders vast een andere prutser geweest die een pruts-maar-wat-raak taal had gemaakt. Er is gewoon een markt voor dergelijke talen/omgevingen.

Dat je ermee _kan_ prutsen zegt nog niet dat het er ook mee _moet_ of dat het niet anders kan, dat wordt nog wel eens vergeten

.oisyn schreef op 02 February 2003 @ 16:25:
ik kwam in deze topic eigenlijk om te typen wat mbravenboer in z'n laatste alinea heeft getypt (grrr ). Ik sluit me daar dan ook volledig bij aan. PHP is een uit de hand gelopen hobby project wat echt te ranzig in elkaar zit.

Ach, hoe oud is C? En hoe begon dat? Als een wetenschappelijke taal geloof ik, dat zal wellicht gescheeld hebben, maar zat dat vanaf het begin zo netjes in elkaar?
Kijk es naar de geschiedenis van andere talen en dan dus met name de eerste versies, meerdere daarvan zijn gewoon nauwelijks gebruikt omdat ze nauwelijks werkbaar waren. En een volgende versie die bijv 10 jaar later kwam werd pas geaccepteerd.
php is gewoon een C wrapper met een hoop handige extra functies, de meeste functienamen zijn dan ook afgeleid van C en dat is ook een van de redenen dat het beter geschikt is voor non-OO werk dan voor OO-werk.

De makers hebben van tevoren duidelijk amper over dingen nagedacht, wat er ook voor gezorgd heeft dat de engine al 2x opnieuw from scratch geschreven is

En dat is een argument voor het te ranzig zijn van de taal
Vreemd, de java-engine is ook regelmatig herschreven volgens mij... En meerdere compilers zijn meerdere malen herschreven.

[Soultaker]

Die reacties van .oisyn en mbravenboer van gaan me iets te ver: ik vind zelf PHP voor het maken van simpele dynamische pagina's veel geschikter dan (bijvoorbeeld) C of Perl. Ik ben het eens met de stelling dat PHP vooral geschikt is voor een beperkt toepassingsgebied, maar binnen dat gebied werkt het naar mijn mening ook goed. Voor websites met uitzonderlijke eisen aan complexiteit en prestaties, is PHP uiteraard minder geschikt.

Dat PHP een waardeloze prutstaal is, lijkt me niet waar.

[ Voor 18% gewijzigd door Soultaker op 02-02-2003 17:00 . Reden: ff .oisyn's nick gefixed =) ]

[ACM]

* ACM ziet dat ie de mening van Soultaker vrijwel volledig deelt hierin

En dat React, ondanks zo nu en dan een foutje of bugje, over het algemeen goed werkt en goed presteert lijkt me toch ook wel het een en ander aan goeds over php te zeggen
Waarbij React dus, wmb, model staat voor een gemiddelde, relatief complexe webapplicatie (maar dan met wat hogere performance eisen) en dus niet aan een voorbeeld applicatie die vele malen complexer is of op de desktop moet.

Dat het wellicht als Servlet net zo goed had kunnen werken zal ik niet tegen spreken

[ Voor 25% gewijzigd door ACM op 02-02-2003 16:58 ]

[Nielsz]

Soultaker, je weet toch wie het zeggen, daar is nog nooit een positief geluid uit gekomen wbt PHP. Ik betwijfel trouwens of ze ooit met PHP gewerkt hebben, maar dat weet ik niet helemaal zeker

[pjonk]

Ik vind PHP voor een webscripting taal behoorlijk veel bieden.
In het begin viel er een hoop aan te merken op PHP qua script beveiliging. Het register_globals verhaal het aanspreken van GET/POST en cookie variabelen via automatische globals leidde tot onoverzichtelijke en veel lekke scripts.

PHP probeert dingen soms te veel achter je rug om te regelen en dat vind ik vervelend met als goed voorbeeld magic quotes. Ik wil zelf wel bepalen of ik mijn GPC variabelen wil quoten.

In de nieuwere PHP versies kun je gelukkig de superglobals gebruiken en hebben ze veel aandacht aan beveiliging besteedt.

PHP is in zijn gebied websites en webapplicaties gewoon erg goed en het is een beetje onzinnig om PHP met talen als C++ te gaan vergelijken.

[ Voor 7% gewijzigd door pjonk op 02-02-2003 17:15 . Reden: typo's ]

[mbravenboer]

ACM: Hoewel ik vrij aardig met Java overweg kan, zal ik toch niet gauw alles wat ik nu met php doe in Java/servlets/jsp gaan bouwen. Dat kost domweg meer tijd een simpel test applicatietje, voor iets dat net even te veel moeite is om met de hand uit te rekenen, kost me in php wellicht 30 regels code en een half uur schrijf/test/executie tijd.

Zeker, je zal mij ook niet horen zeggen dat er buiten talen als Java/C# geen behoefte is aan andere talen . Het is echter de vraag of jij voor dergelijke "snelle" projectjes PHP pakt omdat je echt vind dat PHP hier geschikter voor is dan bijvoorbeeld Python. Ik denk dat jij zelf zoveel in PHP hebt gewerkt dat je daar zo goed bekend bent dat het voor jou de eerste en de beste optie is als je "snel" iets moet implementeren.

Stel je echter eens voor dat je in het verleden voor Python had gekozen en dat je daar enorm veel mee gewerkt had. Zou Python dan ook niet een uitstekende optie zijn geweest in deze situaties? Ik denk het wel.

Ik wil me dus absoluut niet verzetten tegen de doelgroep/toepassing waar PHP zich op richt (dat lijkt er soms wel op en dan voelen mensen zich aangevallen, zie boven), maar er is voor deze doelgroep/toepassing veel meer te krijgen dan alleen PHP!

Ik had liever gezien dat een taal als Python de rol was gaan vervullen die PHP nu vervult. Ik denk dat weinig mensen het daarmee oneens kunnen zijn ...

[mbravenboer]

JonkieXL: PHP is in zijn gebied websites en webapplicaties gewoon erg goed en het is een beetje onzinnig om PHP met talen als C++ te gaan vergelijken.

Er is gelukkig ook maar 1 persoon die ik dat heb zien doen: de topic starter. Het is inderdaad onzin om een taal als PHP te gaan vergelijken met statische getypeerde talen.

Je mag je overigens wel afvragen of een dynamische en zwak getypeerde taal nu echt de oplossing is voor het rigide type systeem van statisch getypeerde talen als Java en C#. Misschien dat een degelijker en vriendelijker type systeem dan ook wel een interessante oplossing is.

[ACM]

mbravenboer schreef op 02 February 2003 @ 17:28:
Ik denk dat jij zelf zoveel in PHP hebt gewerkt dat je daar zo goed bekend bent dat het voor jou de eerste en de beste optie is als je "snel" iets moet implementeren.

Uiteraard

maar er is voor deze doelgroep/toepassing veel meer te krijgen dan alleen PHP!

D0h
Maar anderzijds, als je iets makkelijk kan leren en het is ook nog ruim voorhanden wat ondersteuning betreft... Waarom zou je dan niet voor php kiezen? Dezelfde argumentatie gaat op voor windows op de desktop, mysql als database etc...
Je kiest gauw voor de optie die het meest gebruikt wordt, het makkelijkst is in termen van ondersteuning, support en leercurve.

Ik had liever gezien dat een taal als Python de rol was gaan vervullen die PHP nu vervult. Ik denk dat weinig mensen het daarmee oneens kunnen zijn ...

Helaas ken ik python niet goed genoeg om de voors en tegens ervan tegen die van php af te wegen.
Ik ben iig wel van mening dat python eerder die taal is dan perl, die als "betere" uit de bus zou mogen komen...

[pjonk]

Perl ken ik wel aardig en daarmee kun je bijvoorbeeld wel variabelen expliciet declareren al is dit niet altijd verplicht.
Ik had liever gezien dat je in PHP een strict variabele declaration zou kunnen instellen, omdat dat leidt tot beter nadenken over het variabele gebruik.

Natuurlijk blijft het zo dat de programmeur een script zo slordig kan maken als ie maar wil. Het is echter heel goed mogelijk om nette gestructureerde scripts te maken in PHP.

[ Voor 2% gewijzigd door pjonk op 02-02-2003 17:42 . Reden: typo's ]

[tomato]

JonkieXL schreef op 02 februari 2003 @ 17:39:
Natuurlijk blijft het zo dat de programmeur een script zo slordig kan maken als ie maar wil. Het is echter heel goed mogelijk om nette gestructureerde scripts te maken in PHP.

Zie ook deze discussie. Daar komt ook het effect van taal features (zoals het type systeem) en discipline op het resultaat aan bod.

[.oisyn]

ACM schreef op 02 February 2003 @ 16:44:
php is gewoon een C wrapper met een hoop handige extra functies, de meeste functienamen zijn dan ook afgeleid van C en dat is ook een van de redenen dat het beter geschikt is voor non-OO werk dan voor OO-werk.

ik zie de relevantie met OO niet echt

En dat is een argument voor het te ranzig zijn van de taal
Vreemd, de java-engine is ook regelmatig herschreven volgens mij... En meerdere compilers zijn meerdere malen herschreven.

ik doel op de interne werking van php, niet hoe het er van buiten uitziet. Om de opmerking van Nielsz aan te halen: de meesten hier weten niet eens hoe php intern werkt, hoe goed ze php zelf ook beheersen. Toen ik mij ging verdiepen in php modules om de react syntax highlighter te bouwen kwam ik in een vage wereld van samenhangende ranzige macro's en onlogische hulpfuncties. En geloof me, het is echt vies

Nielsz schreef op 02 February 2003 @ 16:57:
Soultaker, je weet toch wie het zeggen, daar is nog nooit een positief geluid uit gekomen wbt PHP. Ik betwijfel trouwens of ze ooit met PHP gewerkt hebben, maar dat weet ik niet helemaal zeker

zie boven

[ Voor 2% gewijzigd door .oisyn op 02-02-2003 19:33 . Reden: waar C stond moest natuurlijk OO staan ]

[Verwijderd]

Woei, mijn lievelings soort topics dit

Even een paar posts die ik gebookmarked heb omdat ze me wel aanstaan (van mbravenboer):
mbravenboer in "PHP VS .NET"
[rml]mbravenboer in "[ alg] OO/polyformisme in talen (oa php)"[/rml]

Een deel is al herhaald, maar toch

[chem]

Het topic valt me verder wat tegen.
Ik mis een duidelijke beredenering waarom je bij nieuwe projecten of tools, een andere taal zou moeten gaan gebruiken?
Als ik naar Python kijk, is het wel veel strakker opgezet, maar betwijfel ik of het dezelfde performance en devtijd kan bewerktstelligen. Ik zie @ google weinig benchmarks over PHP vs Python vs C/Java.

Het enige alternatief dat mij trekt is Java, en dat is in mijn opzicht nog steeds een traag en log iets. Portabiliteit voor webapps zal me aan m'n kont roesten, C kan ook makkelijk tussen OS'en worden gebruikt (min of meer).

Andere talen die me boeien (nog niks mee gedaan, helaas) zijn bv. Objective C (met name icm Cocoa e/o andere Frameworks).

[pjonk]

chem schreef op 02 February 2003 @ 20:03:
Het enige alternatief dat mij trekt is Java, en dat is in mijn opzicht nog steeds een traag en log iets.

Zo dacht ik ook voordat ik met Java gewerkt had, maar is dit toch wat kortzichtig geredeneerd.

De performance hangt voornamelijk af hoe goed de Virtual Machine is geschreven voor het specifieke platform. Ik ontwikkel zelf onder andere Java applicaties die op printers draaien.

De virtual machines in de oude printers waren behoorlijk traag, maar de nieuwe printers met geoptimaliseerde Virtual machines bieden een ongeloofelijke performance boost met het draaien van Java applicaties.

[Verwijderd]

Om op het punt van OO te reageren:

PHP heeft OO simpel gehouden, waarom? Om toch relaties en duidelijk onderhoudbare code te maken echter niet te veel resources daarvoor te gebruiken...

Ik ken zelf geen enkele "script"-taal waarbij OO en goed is geïmplementeerd en snel werkt met een goede resource verdeling...

JSP is harstikke fijn maar doe er is een stress-test mee van 100gebruikers die tegelijk een aanvraag doen en je werkt met 3 classes dan is het om te huilen

ASP kan al niet eens in single-server verband worden ingezet als je site meer dan 500 gebruikers per minuut hebt die gebruik maken van objecten... (kijkend naar PHP en resource verdeling)...

dus...

je levert wat in en je krijgt er dat voor terug

[Verwijderd]

PHP is altijd al overgewaardeerd geweest en spoort veel te makkelijk aan om ransige code te typen. Verder gan ik liever voor een taal de wel snel is, bijvoorbeeld jsp.

JSP is namelijk 3_keer_zo_snel!

Tevens is jsp wel OO, en heeft een degelijke library.

Php is gewoon gehypte troep.

[Verwijderd]

Verwijderd schreef op 02 February 2003 @ 20:22:
JSP is harstikke fijn maar doe er is een stress-test mee van 100gebruikers die tegelijk een aanvraag doen en je werkt met 3 classes dan is het om te huilen

Ik snap dat niet hoor, maar dit is klinklare onzin. Heb je het wel is getest of zuig je alles uit je duim. Bij mij op het instituut is de test uitgevoerd tussen php en jsp. Het blijkt gewoon dat jsp 3 maal sneller is als php. En jsp wordt relatief alleen maar sneller naarmate je de server load opvoert.

Uiteraard had je dit zonder testen ook al kunnen weten wat van elke servlet container draait in jsp maar 1 instantie voor alle request. In tegenstelling tot php, daar wordt een compleet nieuwe container aangemaakt per process. Verder is jsp een gecompileerde taal en per defenitie sneller als een geparsde taal.

[Soultaker]

De gedachte om PHP als alternatief voor Python te zien vind ik interessant. Qua taal lijken Python en PHP erg veel op elkaar (de makers van PHP zullen daar wel een beetje van hebben gejat). Er zijn echter ook een aantal belangrijke verschillen aan te merken, als het gaat om het gebruik van de talen voor het ontwikkelen van webapplicaties. Die verschillen zitten 'm in de standaardbibliotheek en het executieplatform.

Wanneer de broncode van een Python programma geparsed wordt, wordt de bytecode op de schijf opgeslagen, en nooit meer opnieuw gegenereerd, totdat de broncode aangepast wordt. Dit is qua performance erg interessant; het is feitelijk hetzelfde als wat de Zend encoder doet, maar dan autoamtisch. Leuk, natuurlijk, maar als je PHP in een professionele omgeving draait en aan performance tekort komt, kun je je de kosten van de Zend encoder meestal wel veroorloven. Bij de meeste projecten is de efficientie van PHP ook geen issue.

In Python is alle functionaliteit netjes onderverdeeld in modules, die in een geneste structuur van packages gerangschikt worden. PHP modules zijn 'plat' gestructureerd (er bestaan geen submodules). Python modules worden expliciet geimporteerd (analoog aan Perl) waardoor ze alleen (en pas) geladen hoeven te worden wanneer hun functionaliteit nodig is. Dit maakt Python op de command line en als gewone CGI applicatie erg geschikt; PHP moet in principe alle modules initialiseren alvorens een script uitgevoerd kan worden, maar aangezien PHP meestal als webservermodule of desnoods fast-CGI module draait, is dit in de praktijk geen nadeel.

Overigens moet vermeld worden dat de standaard policy van Apache (al is dat in versie 2 anders te configureren) is om elke keer nieuwe processen te forken en op te ruimen, wat in principe niet ideaal is in combinatie met een monolitische engine. Ik weet niet in hoeverre PHP modules opnieuw moet initialiseren bij het forken, trouwens.

Zowel voor Python als PHP zijn veel standaardmodules beschikbaar, al zijn de PHP modules toegespitst op het maken van dynamische websites, en is er voor Python een breder maar minder 'diep' aanbod aan modules voor van alles en nogwat; een beetje te vergelijken met Perl, eigenlijk.

Al met al heb ik tot nu toe geen groot voordeel van Python over PHP kunnen noemen, als het gaat om het ontwikkelen van webapplicaties. De standaardbibliotheek van Python is minder geschikt voor dit doel, maar zit wat netter in elkaar dan de PHP module API's. Een zeer groot voordeel van PHP ten op zichte van Python, vind ik echter de mogelijkheid om PHP code te kunnen inpassen in HTML/XHTML/CSS bestanden (dus met die leuke php-tags). In Python zal je elke keer je regels constante tekst moeten printen, wat natuurlijk erg frustrerend is (en ik ook vervelend vind aan het ontwikkelen van CGI modules in Perl of C/C++), of je moet een eigen templatesysteem ontwerpen, wat meestal te veel van het goede is.

Als Python dus een voordeel heeft over PHP, dan zou dat uit de taal zelf moeten komen. Ik kan me echter geen voordeel bedenken. Misschien heeft iemand anders nog suggesties? Als het gaat om het ontwikkelen van webapplicaties, is PHP nog steeds mijn favoriet, omdat de standaardbibliotheek van PHP voor dit doel beter geschikt is dan die van Python, en de PHP code beter te combineren is met de statische content.

[Soultaker]

Verwijderd schreef op 02 February 2003 @ 20:22:
Ik ken zelf geen enkele "script"-taal waarbij OO en goed is geïmplementeerd en snel werkt met een goede resource verdeling...

Dan heb je niet opgelet; de taal Python is toch al een stuk of tien keer genoemd in dit topic. Of het strookt met jouw definitie van 'goed' en 'snel' is natuurlijk de vraag; dat is in feite in tegenspraak met het feit dat het een scriptingtaal betreft.

Verwijderd schreef op 02 February 2003 @ 20:29:
PHP is altijd al overgewaardeerd geweest en spoort veel te makkelijk aan om ransige code te typen. Verder gan ik liever voor een taal de wel snel is, bijvoorbeeld jsp.

Het feit dat er zoveel ranzige code is geschreven in PHP, komt doordat door de lage opstap er veel mensen in programmeren die dat eigenlijk niet kunnen. De programmeurs die ranzige PHP code schrijven, kunnen helemaal geen nette C code schrijven. Daarbij zie ik hier op GoT ook behoorlijk vaak ranzige Java code langskomen; dat zegt meer over de gebruikers van de taal, dan over de taal zelf. In feite kun je elke taal we 'misbruiken'.

JSP is namelijk 3_keer_zo_snel!

Toe maar. Drie keer. Leuk, zo'n gegeven, zonder toepassing of bronvermelding.

Tevens is jsp wel OO, en heeft een degelijke library.

Php is gewoon gehypte troep.

Als je op hypes tegen bent, moet je vooral de stelling dat JSP beter is dan PHP beargumenteren met het feit dat het "wel OO" is, zonder verdere uitleg.

Ik vind PHP juist geschikt omdat het NIET (per se) OO is! De redenatie daarachter is al door andere mensen genoemd: een OO programma zul je van te voren moeten ontwerpen en je zult er meer regels code aan kwijt zijn. Voor simpele toepassingen is dit overkill; zonde van de tijd en moeite.

[ Voor 6% gewijzigd door Soultaker op 02-02-2003 20:47 ]

[hobbit_be]

wat ik nooit heb gesnapt waarom er eigenlijk geen lekker open-source Javascript (ECMA) server-side spul is gemaakt met een paar goede standaard libs erbij? Kun je goed compilen- bijna alles soft valt wel bij elkaar te rapen, etc etc. En dan net zoals een JSP of 'Servlet' met een heel simpele maar oerdegelijke functies hebt (in, out, sessions and JDBC/XML:DB).

Heb lange tijd met PHP bezig en is leuk voor kleine-medium format spul - snelheid is jammer zodra je met OO begint (en PHP is echt wel OO capable) en is nog net niet 'mature' genoeg (doe maar eens iets in XML zonder dat je PHP mag configureren). Ik denk dat het wel verder zal doorbreken omdat de instap tamelijk eenvoudig is.

Nu ben ik met XSP bezig (de Java) en dat zit ook mooi in elkaar - maar niet zo eenvoudig om mee te beginnen. Java is bijna altijd sneller als de traffiek groot wordt. de Java VM is echt wel een pak sneller geworden. Maar je moet dan ook in Java weten waar het zit (bijvoorbeeld PHP is fantastisch snel met Arrays, zo is Java beestig traag met gewone Strings)

edit:

nog wel effe vergeten dat de memory footprint om te beginnen met alles wat JSP is enorm (een server zonder 256MB wordt al pijnlijk) is, maar daarna vlakt het mooi af...


En als .NET nu eens gratis was zou ik vast in C# or VB.net beginnen. Jammer dat Mono nog net niet klaar is.

Trouwens wat zou het saai zijn als er maar 1 taal was

'Variety is the spice of life'

[ Voor 9% gewijzigd door hobbit_be op 02-02-2003 20:58 ]

[Verwijderd]

Verwijderd schreef op 02 februari 2003 @ 20:36:
[...]

Ik snap dat niet hoor, maar dit is klinklare onzin. Heb je het wel is getest of zuig je alles uit je duim. Bij mij op het instituut is de test uitgevoerd tussen php en jsp. Het blijkt gewoon dat jsp 3 maal sneller is als php. En jsp wordt relatief alleen maar sneller naarmate je de server load opvoert.

Uiteraard had je dit zonder testen ook al kunnen weten wat van elke servlet container draait in jsp maar 1 instantie voor alle request. In tegenstelling tot php, daar wordt een compleet nieuwe container aangemaakt per process. Verder is jsp een gecompileerde taal en per defenitie sneller als een geparsde taal.

ik heb het zeer zeker getest... alleen zoals ik al zelf aangaf op OO gebied zit het bij jsp prima in elkaar echter gaan de hoeveelheid classes omhoog wordt het op den duur aardig traag tot zelfs time-outs terwijl dezelfde classes in php wel werden geservereerd

ik zeg totaal niet dat ik een PHP fan ben
want mijn voorkeur gaat uit naar JSP mede omdat het even snel is en stuk netter

laat we het er maar op houden het was een moment opname en die is in mijn ogen niet goed gegaan of goed op me overgekomen

[Mithrandir]

Verwijderd schreef op 02 February 2003 @ 20:29:
PHP is altijd al overgewaardeerd geweest en spoort veel te makkelijk aan om ransige code te typen. Verder gan ik liever voor een taal de wel snel is, bijvoorbeeld jsp.

JSP is namelijk 3_keer_zo_snel!

Tevens is jsp wel OO, en heeft een degelijke library.

Php is gewoon gehypte troep.

"PHP is altijd al overgewaardeerd geweest en spoort veel te makkelijk aan om ranzige code te typen."
Tsja... Aan de code zie je degene die de het typt. Je kan je code best netjes krijgen, maar dan moet je de discipline op kunnen brengen dat ook te doen. Je kunt in practisch iedere taal wel ranzig doen, dus dat is echt ee nnon-argument.

"Verder gan ik liever voor een taal die wel snel is, bijvoorbeeld jsp."
Hier suggereer je dat PHP zo sloom is als een slak. Maar wat is het verschil bij het aanroepen van een database? Een moeilijke query in veel gegevens zal al snel meer tijd kosten dan het uitvoeren van de eigenlijke code.

"JSP is namelijk 3_keer_zo_snel!"
oh? Kan waar zijn, maar waar toets ik dat? En onder welke condities is 'ie 3 keer zo snel? Je praat in raadselen.

"Tevens is jsp wel OO, en heeft een degelijke library."
Waarom zou PHP niet OO zijn? Veel OO dingen kun je wel doen met PHP. Maar hoe OO moet een taal zijn om OO te zijn? Onderbouwen alsjeblieft

"PHP is gewoon gehypte troep"
Gehypt? Ik heb nergens een hype gezien/gehoord... Het punt is alleen dat het gewoon veel gebruikt wordt, en daar zal wel een reden voor zijn denk je niet? Het heeft allemaal te maken met voor welke doelgroep een taal is. (Veel van mijn vorige argumenten ook).

[ACM]

.oisyn schreef op 02 February 2003 @ 18:47:
ik zie de relevantie met OO niet echt

Een echte OO taal moet in principe een OO-basis hebben, php heeft dat niet, net als C. C en de derivaten ervan zijn ook geen echt OO, het zou mij niet verbazen dat dat een van de redenen is waarom de boel niet echt OO is.

ik doel op de interne werking van php, niet hoe het er van buiten uitziet. Om de opmerking van Nielsz aan te halen: de meesten hier weten niet eens hoe php intern werkt, hoe goed ze php zelf ook beheersen. Toen ik mij ging verdiepen in php modules om de react syntax highlighter te bouwen kwam ik in een vage wereld van samenhangende ranzige macro's en onlogische hulpfuncties. En geloof me, het is echt vies

De meeste mensen weten ook niet hoe de JVM in elkaar steekt, of hoe hun dagelijkse OS in elkaar steekt, hun database, hun etc...
Als de taal van buiten netjes is en doet wat het moet doen, kan het me eerlijk gezegd niet veel schelen hoe de blackbox van binnen werkt. Dat het voor de php-developers vervolgens een hel is om de boel te beheren is hun eigen schuld...

Verwijderd schreef op 02 February 2003 @ 20:29:
PHP is altijd al overgewaardeerd geweest en spoort veel te makkelijk aan om ransige code te typen. Verder gan ik liever voor een taal de wel snel is, bijvoorbeeld jsp.

Lol

JSP is namelijk 3_keer_zo_snel!

Zozo, waarin?
In eerste opstarttijd van de applicatie? (not)
In compilatie tijd van de applicatie? (not)
In executie tijd? Wat voor executie tijd? Vaak zal de performance van je programmeerkunsten afhangen (caching van databaseobjecten bijv) en een bij beetje webapp zal de performance eerder van de database-performance en bijbehorende cacheing afhangen.

Tevens is jsp wel OO, en heeft een degelijke library.

Php is gewoon gehypte troep.

Pfft, nou hype je jsp

Verwijderd schreef op 02 February 2003 @ 20:36:
Ik snap dat niet hoor, maar dit is klinklare onzin. Heb je het wel is getest of zuig je alles uit je duim. Bij mij op het instituut is de test uitgevoerd tussen php en jsp. Het blijkt gewoon dat jsp 3 maal sneller is als php. En jsp wordt relatief alleen maar sneller naarmate je de server load opvoert.

Heb je ooit wel es wat met php gedaan
Als mbravenboer een java vs php benchmark zal bouwen zal java winnen, als ik dat doe is de kans groot dat php zal winnen. Benchmarks zijn altijd subjectief en je moet ze altijd met een korrel zout nemen.

Uiteraard had je dit zonder testen ook al kunnen weten wat van elke servlet container draait in jsp maar 1 instantie voor alle request. In tegenstelling tot php, daar wordt een compleet nieuwe container aangemaakt per process. Verder is jsp een gecompileerde taal en per defenitie sneller als een geparsde taal.

Haha, er wordt geen compleet nieuwe, logge container gemaakt
De container, voor zover nodig, wordt tijdens de server start al geladen, hij cached alleen standaard de gecompileerde scripts niet.
Jsp wordt gecompileerd naar bytecode wat veel weg heeft van een geinterpreteerde taal, dat argument slaat geen hout... php's zijn zelfs vele malen sneller te compileren.

[ACM]

hobbit_be schreef op 02 February 2003 @ 20:55:
wat ik nooit heb gesnapt waarom er eigenlijk geen lekker open-source Javascript (ECMA) server-side spul is gemaakt met een paar goede standaard libs erbij? Kun je goed compilen- bijna alles soft valt wel bij elkaar te rapen, etc etc. En dan net zoals een JSP of 'Servlet' met een heel simpele maar oerdegelijke functies hebt (in, out, sessions and JDBC/XML:DB).

Het nadeel van javascript is dat het een hele gekke taal is...

nog wel effe vergeten dat de memory footprint om te beginnen met alles wat JSP is enorm (een server zonder 256MB wordt al pijnlijk) is, maar daarna vlakt het mooi af...

Als jij een highperformance server voor apache+php opzet zal je ook op zijn minst 256MB erin moeten stoppen

En als .NET nu eens gratis was zou ik vast in C# or VB.net beginnen. Jammer dat Mono nog net niet klaar is.

.NET is toch gratis

[.oisyn]

[nohtml]

ACM schreef op 02 februari 2003 @ 21:51:
[...]

Een echte OO taal moet in principe een OO-basis hebben, php heeft dat niet, net als C. C en de derivaten ervan zijn ook geen echt OO, het zou mij niet verbazen dat dat een van de redenen is waarom de boel niet echt OO is.

eens, maar ik heb OO niet aangehaald, dus ik snap eigenlijk niet waarom dat een reactie op mij is

De meeste mensen weten ook niet hoe de JVM in elkaar steekt, of hoe hun dagelijkse OS in elkaar steekt, hun database, hun etc...
Als de taal van buiten netjes is en doet wat het moet doen, kan het me eerlijk gezegd niet veel schelen hoe de blackbox van binnen werkt. Dat het voor de php-developers vervolgens een hel is om de boel te beheren is hun eigen schuld...

mja, maar dat het intern zo smerig in elkaar zat was dus mijn argument dat PHP een uit de hand gelopen hobby project is. Dat het uiteindelijk wel werkt wil natuurlijk nog niet zeggen dat het ook goed werkt. Ik heb bijvoorbeeld nogal wat rants gelezen hier op GoT over het geheugenmanagement, dat php z'n resources pas vrijgeeft als het script is afgelopen e.d.. Maar goed, daar weet ik het mijne niet over, dus daar zal ik verder niet op in gaan

[ACM]

.oisyn schreef op 02 februari 2003 @ 22:13:
eens, maar ik heb OO niet aangehaald, dus ik snap eigenlijk niet waarom dat een reactie op mij is

Was ook meer algemeen

mja, maar dat het intern zo smerig in elkaar zat was dus mijn argument dat PHP een uit de hand gelopen hobby project is. Dat het uiteindelijk wel werkt wil natuurlijk nog niet zeggen dat het ook goed werkt. Ik heb bijvoorbeeld nogal wat rants gelezen hier op GoT over het geheugenmanagement, dat php z'n resources pas vrijgeeft als het script is afgelopen e.d.. Maar goed, daar weet ik het mijne niet over, dus daar zal ik verder niet op in gaan

*kuch* vraag chem er es naar?
OO-based-resources (geheugen oa) wordt gewoon niet vrij gegeven in bepaalde omstandigheden. Althans, de teller gaat niet omlaag...
En idd, je krijgt je geheugen ook tijdens de executie van een script niet meer terug.

Toch vormen beiden zelden een belemmering om goed met php te kunnen werken, het zijn uiteraard wel voorbeelden van het feit dat de php-engine nog wel iets beter kan

[Zoijar]

Tsja, beetje holy-war dit. Je moet gewoon goed bedenken voor een project wat voor eisen er gesteld worden (snelheid, onderhoudbaarheid, portabiliteit, etc.), wat voor mogelijkheden je hebt (servers, database, ontwikkel tijd, etc) en dan een taal/omgeving kiezen die daar goed bij past.
Het heeft weinig nut om bij een bedrijf dat al jaren PHP servers draait aan te komen met een verhaal hoe goed asp of jsp wel niet is.

De bekende grap..."What happens if you have a problem and ask a computer scientist to solve it? ... The scientist will come back a year later, presenting you with a brand new programming language ideally suited to solve your problem."

[whoami]

hobbit_be schreef op 02 February 2003 @ 20:55:


En als .NET nu eens gratis was zou ik vast in C# or VB.net beginnen. Jammer dat Mono nog net niet klaar is.

.NET is gratis. Je kunt de SDK gratis downloaden van de site van microsoft. Daarin zit het .NET framework, de runtime, help, en een compiler. Het enige wat je dan nog nodig hebt, is een editor.

[whoami]

[nohtml]

Verwijderd schreef op 02 februari 2003 @ 15:18:

OOP
"PHP is OO!" heb ik ooit eens gelezen in een artikel op internet. Nou, mooi niet dus .

In PHP zijn standaard nagenoeg geen classes beschikbaar. Zo is er bijvoorbeeld zelfs geen datum/calender class beschikbaar. Als je OO wilt programmeren in PHP, dan zul je dus zelf voor deze classes moeten zorgen. Of hier al projecten voor zijn weet ik niet.

Het al of niet OO zijn van een taal heeft niets te maken met het aanwezig zijn van een uitgebreide class-hierarchy.
OOP is eerder een manier van programmeren, waar volgende items van belang zijn:
- data encapsulation/data hiding
- overerving
- polymorphisme

Jaspertje schreef op 02 februari 2003 @ 15:27:
Ik programmeer alleen is ASP, maar ik was van mening dat PHP net als ASP meer een scripttaal was??? of kan iets een script taal zijn en OO??

Als er een technologie is, die op een dood spoor zit, dan is het wel ASP. Die zal volledig vervangen worden door ASP.NET


Maar verder geldt nog altijd:
Use the right tool for the job
Heb je een simpel webproject dat je moet maken, dan kan je PHP gaan gebruiken. Moet je echter een web-applicatie maken voor een bedrijf, die heel wat business-logica moet bevatten, dan kan je imho beter kiezen voor een OO taal als Java, C#, ....

[rollebol]

whoami schreef op 03 February 2003 @ 08:44:
[...]

.NET is gratis. Je kunt de SDK gratis downloaden van de site van microsoft. Daarin zit het .NET framework, de runtime, help, en een compiler. Het enige wat je dan nog nodig hebt, is een editor.

En een OS. Ook gratis?

[Crazy D]

rollebol schreef op 03 February 2003 @ 09:15:
En een OS. Ook gratis?

Dat kan voor php ook gelden (afhankelijk van welk OS je wilt draaien).

Ik vind het een intressante discussie waar ik weinig zinnigs aan toe heb te voegen. Ik denk dat, zoals al gezegt is, als je het idee hebt dat je tegen de grenzen van wat kan met een taal aanloopt, het tijd is voor een andere taal Ik denk niet dat PHP dood is, al is het maar omdat er wereldwijd miljoenen mensen "wat" met PHP doen, en velen van die mensen ook niet zo snel zullen overstappen (om welke reden dan ook). Met miljoenen gebruikers kan ik een taal niet dood noemen. (en of het technisch gezien ook dood begint te gaan, door bv gebrek aan "echte" OO ondersteuning, of omdat op de achtergrond PHP eigenlijk heel brak is, is intressant maar niet zo relevant denk ik. Dat zal de meesten die met PHP werken, een rotzorg zijn... ).

[ACM]

rollebol schreef op 03 februari 2003 @ 09:15:
En een OS. Ook gratis?

Dat is geen discussie voor in P&W en zelfs een die uit NOS geweerd wordt.

De samenvatting is dat als je een .NET omgeving nodig hebt voor je webapplicaties je waarschijnlijk je niet zo druk maakt om de kosten van een OS, aangezien de development van applicaties en het beheer ervan vele malen meer kost dan een OS, database etc kwa aanschaf.
Voor je huis, tuin en keuken projectjes ligt dat anders natuurlijk

[Banpei]

ACM schreef op 02 February 2003 @ 22:37:
OO-based-resources (geheugen oa) wordt gewoon niet vrij gegeven in bepaalde omstandigheden. Althans, de teller gaat niet omlaag...
En idd, je krijgt je geheugen ook tijdens de executie van een script niet meer terug.

Toch vormen beiden zelden een belemmering om goed met php te kunnen werken, het zijn uiteraard wel voorbeelden van het feit dat de php-engine nog wel iets beter kan

Heb zelf daar ook ervaring mee. Het probleem was alleen dat het Apache proces waarin PHP geheugen alloceerde voor een bepaalde 3rd party module in het totaal opeens 32 MB aan geheugen ging gebruiken. Als je vervolgens minimaal 15 Apache processen hebt draaien op een server met 256 MB heb je opeens een probleem dat ie geen geheugen meer heeft. Een (dirty) workaround bleek een terminate te geven aan het Apache proces nadat PHP klaar was met de executie van het script.

Verder heb ik zelf absoluut geen klachten over PHP. Is een prima taal voor de toepassingen waarvoor ik het gebruik. Natuurlijk zijn andere (script)talen in bepaalde oogpunten beter, maar dan hangt het af van waarvoor je het zou gebruiken. Per slot van rekening zou ik het ook niet aanraden om een high performance 3d game te bouwen in VB6.

[EfBe]

mbravenboer schreef op 02 February 2003 @ 17:31:
Je mag je overigens wel afvragen of een dynamische en zwak getypeerde taal nu echt de oplossing is voor het rigide type systeem van statisch getypeerde talen als Java en C#. Misschien dat een degelijker en vriendelijker type systeem dan ook wel een interessante oplossing is.

Nu is C# wel static typed, maar in een webbased omgeving heb je toch weinig aan die sterke typing, domweg omdat HTTP 1.x puur met strings werkt: alle formdata wordt in stringformat teruggegeven. Daarbij komt nog dat ASP.NET controls zoals de repeater met 'object' werken en je dus bv middels stringetjes controls moet opzoeken en binden dmv casts in de eventhandler (bv wanneer een row uit een view gebind wordt). Je bent dan volledig je types kwijt en werkt op goed geluk.:

C++:

private void rpRoles_ItemDataBound(object sender, 
            System.Web.UI.WebControls.RepeaterItemEventArgs e)
{
    switch(e.Item.ItemType)
    {
        case ListItemType.Item:
        case ListItemType.AlternatingItem:
            DataRowView drvCurrent = (DataRowView)e.Item.DataItem;

            Button btnModify = (Button)e.Item.FindControl("btnModify");
            btnModify.CommandArgument = drvCurrent["RoleID"].ToString();

            Button btnDelete = (Button)e.Item.FindControl("btnDelete");
            btnDelete.CommandArgument = drvCurrent["RoleID"].ToString();

            if((int)drvCurrent["IsAnonymousRole"] > 0)
            {
                Label lblIsAnonymousRole = 
                    (Label)e.Item.FindControl("lblIsAnonymousRole");
                lblIsAnonymousRole.Visible=true;
                btnDelete.Visible=false;
            }

            if((int)drvCurrent["IsDefaultNewUserRole"] > 0)
            {
                Label lblIsDefaultNewUserRole = 
                    (Label)e.Item.FindControl("lblIsDefaultNewUserRole");
                lblIsDefaultNewUserRole.Visible=true;
                btnDelete.Visible=false;
            }

            Label lblAmountUsersInRole = 
                (Label)e.Item.FindControl("lblAmountUsersInRole");

            lblAmountUsersInRole.Text = 
                drvCurrent["AmountUsersInRole"].ToString();

            break;
    }
}

Zolang je met HTTP werkt, is het huilen met de pet op en voldoet zelfs CGI met perl. Let wel: ik praat over de GUI tier. Zodra je BL in weak-typed talen gaat prakken ben je wel verder van huis en wordt het geheel op de lange duur onbeheersbaar. (dus direct database access in asp pages en php pages lijkt me niet goed).

ASP.NET heeft daar een sterk punt, net als overigens asp met com objects of jsp's met servlets. Php houdt dat op de lange duur niet vol, want op win32 is asp.net een beter alternatief (en ook gratis dmv de .NET sdk) en op Linux is mono met asp.net voor mono binnen afzienbare tijd een beter alternatief. Het enige wat dan rest is de immense hoeveelheid software die in php-vorm beschikbaar is. Maar dat is een kwestie van tijd.

[ Voor 33% gewijzigd door EfBe op 03-02-2003 11:49 ]

[Nielsz]

.oisyn schreef op 02 februari 2003 @ 18:47:

ik doel op de interne werking van php, niet hoe het er van buiten uitziet. Om de opmerking van Nielsz aan te halen: de meesten hier weten niet eens hoe php intern werkt, hoe goed ze php zelf ook beheersen. Toen ik mij ging verdiepen in php modules om de react syntax highlighter te bouwen kwam ik in een vage wereld van samenhangende ranzige macro's en onlogische hulpfuncties. En geloof me, het is echt vies
[...]


zie boven

Ok, dan heb ik me vergist

[mbravenboer]

EfBe: Nu is C# wel static typed, maar in een webbased omgeving heb je toch weinig aan die sterke typing, domweg omdat HTTP 1.x puur met strings werkt: alle formdata wordt in stringformat teruggegeven.

Op zich heb je hier voor een klein deel wel een punt, maar in het algemeen denk ik toch niet. Als je heel dicht bij het HTTP protocol en de formulieren blijft, werk je inderdaad voornamelijk met strings. Aan de andere kant zou je iemand denk ik altijd adviseren om zo snel mogelijk zo ver mogelijk van forumlieren en strings vandaan te gaan en op zinvolle klassen te gaan werken. Je wilt dus zo snel mogelijk de eenvoudige string georienteerde verlaten zodat je zoveel mogelijk van de faciliteiten van je taal kan profiteren.

Dit zeg je zelf al:

Zolang je met HTTP werkt, is het huilen met de pet op en voldoet zelfs CGI met perl. Let wel: ik praat over de GUI tier. Zodra je BL in weak-typed talen gaat prakken ben je wel verder van huis en wordt het geheel op de lange duur onbeheersbaar. (dus direct database access in asp pages en php pages lijkt me niet goed).

Het probleem is dat PHP deze stijl van werken wel aanmoedigd. Ik denk dat weinig mensen op de verfrissende gedachte komen om alleen het verwerken van formulieren en het produceren van pagina's in PHP te implementeren. ASP .NET is wat dat betreft een stuk beter georganiseerd omdat er bij de template omgeving al standaard een alternatief beschikbaar is waarop je zsm over kan stappen.

ASP.NET heeft daar een sterk punt

Hum, ik moet eerst alles lezen voordat ik ga reageren .

casts in de eventhandler (bv wanneer een row uit een view gebind wordt). Je bent dan volledig je types kwijt en werkt op goed geluk..

Gelukkig komen er geparameterizeerde typen . Een goed voorbeeld van een verbetering van het type systeem.

[hobbit_be]

dat .Net 'gratis' is is waar natuurlijk maar hoe ga ervoor ontwikkelen? notepad? hoeveel kost Visual Studio .Net? en natuurlijk het OS - vandaar dat ik zei dat als mono 'af' is dat het den wel 'viable' wordt. voor Java kun je JIDea gratis downloaden en dat is een IDE om 'umpff' tegen te zeggen - (als je een snelle pc hebt .

[whoami]

hobbit_be schreef op 03 February 2003 @ 13:01:
dat .Net 'gratis' is is waar natuurlijk maar hoe ga ervoor ontwikkelen? notepad? hoeveel kost Visual Studio .Net? en natuurlijk het OS - vandaar dat ik zei dat als mono 'af' is dat het den wel 'viable' wordt. voor Java kun je JIDea gratis downloaden en dat is een IDE om 'umpff' tegen te zeggen - (als je een snelle pc hebt .

SharpDevelop.
_{ff googlen}

Maargoed, dit gaat way off-topic.

[EfBe]

VC#.NET kost 120 EUR dacht ik. Je hebt ook 'Matrix', gratis editor voor ASP.NET

[Verwijderd]

EfBe schreef op 03 February 2003 @ 11:43:
[...]

Nu is C# wel static(bedoel je strong?) typed, maar in een webbased omgeving heb je toch weinig aan die sterke typing, domweg omdat HTTP 1.x puur met strings werkt: alle formdata wordt in stringformat teruggegeven. Daarbij komt nog dat ASP.NET controls zoals de repeater met 'object' werken en je dus bv middels stringetjes controls moet opzoeken en binden dmv casts in de eventhandler (bv wanneer een row uit een view gebind wordt). Je bent dan volledig je types kwijt en werkt op goed geluk.:

Misschien vergeten mensen hierzo dat het rekenen met een Integer velen malen sneller gaat als het rekenen met een String. Het is dus wel degelijk interessant om het om te zetten. Zelfs php onderkent dat en heeft de mogelijkheid om een variabele expliciet om te zetten naar een integer.

Maar ik blijf erbij dat PHP nooit geboren had mogen worden, het blijft een smerige kleuter taal die zo traag is als dikke stront door een trechter met een te klein tuitje. Even de voordelen van jsp op een rijtje omdat mensen hier vinden dat ik het moet onderbouwen:
- jsp is sneller
- jsp is relatief sneller naarmate de server load toe neemt
- compleet OO
- duidelijke eenzijdige structuur van de webapplicaties ( web.xml, classes, libs, etc.)
- uit te breiden met custom xml tags
- grotere library
- eenzijdig gedocumenteerd (Javadoc)
- goede bescherming van cruciale bestanden (WEB-INF/META-INF directory)

Iemand die niet overtuigd is is gewoon naief...

[ACM]

Verwijderd schreef op 03 February 2003 @ 19:23:
Zelfs php onderkent dat en heeft de mogelijkheid om een variabele expliciet om te zetten naar een integer.

Doet php ook automatisch impliciet al indien nodig hoor.

Maar ik blijf erbij dat PHP nooit geboren had mogen worden, het blijft een smerige kleuter taal die zo traag is als dikke stront door een trechter met een te klein tuitje.

Wat een domme opmerking...
php is behoorlijk volwassen en functioneel, hoewel af en toe nog wel duidelijk een puber.

Even de voordelen van jsp op een rijtje omdat mensen hier vinden dat ik het moet onderbouwen:

En je noemt dit onderbouwen? Een paar loze statements...

- jsp is sneller

Zonder onderbouwing is dit complete onzin.
Op een p100 met 32MB geheugen zal php zelfs altijd wel sneller zijn.

- jsp is relatief sneller naarmate de server load toe neemt

Dus jsp schaalt superlineair? Kewl!!

- compleet OO

Leuk, maar OO is een keuze, niet een verplichting om goed werk te kunnen leveren...
En in php kan je OO werken en in JSP kan je non-OO werken.

- duidelijke eenzijdige structuur van de webapplicaties ( web.xml, classes, libs, etc.)

Nou, dat is duidelijk...
php plaats je gewoon tussen je html files en het werkt.

- uit te breiden met custom xml tags

In php kan je functies definieren...

- grotere library

Groter, logger, maar is ie ook functioneler?
Een gegenereerde image moet via de een Frame , kortom de hele AWT zit in een webapplicatie-library, lekker zinvol...

- eenzijdig gedocumenteerd (Javadoc)

www.php.net

- goede bescherming van cruciale bestanden (WEB-INF/META-INF directory)

Dat soort vage bestanden heeft php gewoon niet

Iemand die niet overtuigd is is gewoon naief...

En jij bent niet naief met zo'n onderbouwingsloos eenzijdig verhaaltje?

[Verwijderd]

ACM, als je niet weet hoe het werkt moet je het er ook niet over hebben:

Groter, logger, maar is ie ook functioneler?
Een gegenereerde image moet via de een Frame , kortom de hele AWT zit in een webapplicatie-library, lekker zinvol...

het is inderdaad niet zinvol om dat via een JFrame te doen, dat getuigd simpelweg van onkunde.

Wat een domme opmerking...
php is behoorlijk volwassen en functioneel, hoewel af en toe nog wel duidelijk een puber.

En u vind dat ik niet onderbouw, nou ik wil wel is weten waarin php volwassen is, hert creeeren van een compleet nieuw process per http request?

Nou, dat is duidelijk...
php plaats je gewoon tussen je html files en het werkt.

Oftewel bagger knullige code, en dat ga ik zeker niet onderbouwen...

In php kan je functies definieren...

Dat is nog niet half de functionaliteit die je kunt bereiken met de custom xml tags, het zorgt voor degelijke overzichtelijke code, bijvoorbeeld een container tag die je pagina beveiligd.


En als laatste over snelheid ga ik het echt niet meer hebben, het is onderzocht, jsp is sneller, ook op een 32mb p100, en als je daar niet aan wilt, prima.

[Verwijderd]

ah, vergeet ik toch je opmerking over documentatie. Er is in php geen documentatie standaard, in java wel, namelijk javadoc.

[mbravenboer]

Op zich heb je best punten waar iets in kan zitten (beide overigens), maar door de manier waarop het gebracht wordt is het nogal ongeloofwaardig en doet het de taal die je promoot / verdedigt meer kwaad dan goed.

[ACM]

Verwijderd schreef op 03 February 2003 @ 20:11:
ACM, als je niet weet hoe het werkt moet je het er ook niet over hebben:

Ik zal direct toegeven dat ik geen JSP kenner ben, maar om dan direct maar aan te nemen dat ik niet weet waar ik het over heb? Zeker in geval van php zal ik mezelf, hoewel geen kenner noemen, toch wel zien als iemand die weet waar ie het over heeft.
De laatste grote applicatie die ik gemaakt heb was een 5000 regelige Servlet, dus ik heb toch wel enige (lang niet alle!) javakennis.

het is inderdaad niet zinvol om dat via een JFrame te doen, dat getuigd simpelweg van onkunde.

Het boek dat ik hier heb liggen "Core Servlets and JavaServer Pages" beschrijft een methode die ongeveer zo gaat:

Java:

Frame x = new Frame();
x.addNotify();
Image img = x.createImage(width, height);
Graphics g = img.getGraphics();
// Draw with g

Als jij me kan uitleggen hoe dat zonder de new Frame()/awt/(X) windows requirements kan lopen wil ik dat graag zien.

En u vind dat ik niet onderbouw, nou ik wil wel is weten waarin php volwassen is, hert creeeren van een compleet nieuw process per http request?

Dat heeft dus geen hout met php te maken... Dat is iets dat als een nadeel van apache gezien zou kunnen worden, multi-process applicaties zijn doorgaans behoorlijk snel daarmee in unices, maar multi-threading kan nog beter zijn.
Op linux wordt trouwens voor elke thread _ook_ een nieuw process gespawned, dus dat is niet zo'n zinvol argument. En ook wordt er niet voor _elke_ request een nieuw process gespawned in apache, maar blijven de processen een zekere tijd in leven (afhankelijk van je settings).

Oftewel bagger knullige code, en dat ga ik zeker niet onderbouwen...

Huh?
Als je geen structuur in je directory aan kan leggen ben je gewoon een prutser, je kunt ook in je java applicatie de domste structuren aanleggen door geen gebruik van packages te maken.

Dat is nog niet half de functionaliteit die je kunt bereiken met de custom xml tags, het zorgt voor degelijke overzichtelijke code, bijvoorbeeld een container tag die je pagina beveiligd.

Bij mijn weten zijn trouwens _alle_ tags voor xml custom... Tenminste, zolang je geen afspraken hebt met een of andere instantie die jouw xml moet zien te begrijpen. En dat jsp custom jsp-taglibs kan hebben ach. Met php kan je dus functies definieren en met een beetje moeite zal de functionaliteit zeker wel vergelijkbaar te maken zijn...
Doe mij maar een voorbeeld van een jsp-tag die niet in php door een functie opgelost kan worden.

En als laatste over snelheid ga ik het echt niet meer hebben, het is onderzocht, jsp is sneller, ook op een 32mb p100, en als je daar niet aan wilt, prima.

Nou, laat dat onderzoek maar zien?
Bij mijn weten draait java als stroop op een p100, zelfs met 1.4. Terwijl apache+php relatief soepel draait.

Verwijderd schreef op 03 February 2003 @ 20:12:
ah, vergeet ik toch je opmerking over documentatie. Er is in php geen documentatie standaard, in java wel, namelijk javadoc.

Er is phpdoc...
Afgeleid van javadoc en javadoc is trouwens geen onderdeel van de taal zelf, of wel?

[ Voor 6% gewijzigd door ACM op 03-02-2003 20:35 ]

[Glimi]

Verwijderd schreef op 03 February 2003 @ 20:11:
ACM, als je niet weet hoe het werkt moet je het er ook niet over hebben:

(...)
het is inderdaad niet zinvol om dat via een JFrame te doen, dat getuigd simpelweg van onkunde.

(...)

Oftewel bagger knullige code, en dat ga ik zeker niet onderbouwen...

Verwijderd schreef op 03 February 2003 @ 19:23:
Maar ik blijf erbij dat PHP nooit geboren had mogen worden, het blijft een smerige kleuter taal die zo traag is als dikke stront door een trechter met een te klein tuitje. Even de voordelen van jsp op een rijtje omdat mensen hier vinden dat ik het moet onderbouwen:
(...)
Iemand die niet overtuigd is is gewoon naief...

Al deze quotes bekijkend (en da's niet selectief quoten, omdat dit meer dan 50% is van je vorige twee berichten) vind ik dat je wel wat rustiger aan mag doen en minder mag proberen mensen iets door de strot te duwen.
We zijn hier programmeurs bij elkaar. Die zijn _per definitie_ eigenwijs, waardoor zo'n arrogante manier van stellen alleen een heleboel onwil zal opbrengen.
Daar zitten we gewoon niet op te wachten hier, daarom het vriendelijke verzoek iets minder je crusade te propaganderen, anders beland je al snel in hetzelfde hoekje waar Zemanova staat te stoffen onderwijl de menigte proberenend te bekeren.

[Verwijderd]

Even over de graphics, dat zal ik even kort uitleggen,
BufferedImage img = new BufferedImage(dimensies bla bla);
Graphics g = img.getGraphics();
klaar, tekenen met die hap en terug pompen...
--------------------------------------------------------------------------------------
Maar bravenBoer heeft gelijk, we lopen te blaten. Dat komt ook domweg omdat ik echt een hekel heb aan het feit dat php domweg overgewaardeerd wordt. Maar daarom even mijn voorstel, we gaan het domweg testen. We schrijven beide een scriptje die een nader te bepalen taak uitvoerd (even zonder db overigens, want ik heb geen zin om een test db omgeving te creeeren). We posten onze code, vergelijken of het vergeleken mag worden (oftewel daadwerkelijk dezelfde taak uitvoert) en testen het op snelheid bij verschillende loads. Ik kan hier php testen op een recente versie van apache met een recente versie van php mee gecompiled. Uiteraard draait tomcat4.1.18 hier als default. Dat is overigens op een 48MB PII 233. Dus als we beide na alle eerlijkheid de test uitvoeren hebben we een mooie vergelijking.

[ACM]

Ik vind het prima, noem maar wat

[mbravenboer]

ACM: en javadoc is trouwens geen onderdeel van de taal zelf, of wel?

Documentation comments was wel opgenomen in de eerste Java Language Specification, maar is verdwenen in de JLS 2.0. Ik neem dus aan dat Sun het niet meer ziet als onderdeel van de taal .

Dat is overigens wel een probleem, want commenaar is in de lexical structure afdeling nog steeds gedefinieerd als /* NotStar. Strikt gezien zou je dus zeggen dat documentation comments geeneens aan de Java Language Specification voldoen .

[Verwijderd]

Is dit wat:

code:

<html>
<head>
<title>
test
</title>
</head>
<body>
<%
//begin tijd
long startTime = System.currentTimeMillis();



// wat stringetjes maken
String test1 = "a test string ";
String test2 = " for testing speed";
String test3 = " while operating on strings";
//wat concatineren
String test4 = test1+test2+test3;
//Even naar uppercase/lowecase slechts 5000 keer
for( int i = 0; i <=10000; ++i ){
  if(i % 2 == 0)test4 = test4.toUpperCase();
  else test4 = test4.toLowerCase();
}
//en naar het scherm die hap
out.println(test4);

//eind tijd
long processTime = System.currentTimeMillis() - startTime;
out.println(processTime);
%>

</body>
</html>

[mbravenboer]

Ik vind het een wat merkwaardige benchmark, maar mag ik meedoen in Stratego ?

[Verwijderd]

Als je een beter stukje code hebt, kom maar op. Ik wist even niets anders, maar ja string zijn traag in Java, dus leek me wel handig om die te pakken. En uppercase/lowercase is voor java een zeer zwaar klusje...

[.oisyn]

en mag ik ook een apache module bouwen in C++?
.edit: even serieus, ik ben momenteel bezig met een loose typed niet-OO scripttaaltje (bedoeld om wiskundige berekeningetjes te doen die niet echt handig met rekenmachine of expression evaluator te doen zijn, zoals matrix berekeningen of grafiekjes plotten).

Het is nog niet af, ik moet nog een hoop operatoren implementeren, maar ik zal eens kijken of ik daarmee ook mee kan doen

De scriptcode wordt direct geinterpreteerd en dus niet eerst geconverteerd naar code, maar ik wil nou ook wel eens weten hoe snel het nou eigenlijk is

[ Voor 85% gewijzigd door .oisyn op 03-02-2003 21:23 ]

[Glimi]

mbravenboer schreef op 03 February 2003 @ 21:10:
Ik vind het een wat merkwaardige benchmark, maar mag ik meedoen in Stratego ?

Jij wel, ga ik proberen of ik nog wat begrijp van de les van vandaag

edit:
wat is er trouwens JSP aan die code? Ik vind het meer een Servlet die doet alsof ie een JSP pagina is

[ Voor 18% gewijzigd door Glimi op 03-02-2003 21:24 ]

[Verwijderd]

wat is er trouwens JSP aan die code? Ik vind het meer een Servlet die doet alsof ie een JSP pagina is

Klopt, maar het is voor velen makkelijker te schrijven en te begrijpen. Maar normaliter zul je in mijn jsp pagina geen een stukje (althans zeer nihil) java code zien. Je dient namelijk gewoon alles op te vangen met tag-libs

[elevator]

Ik vindt dat elke ontwikkelde taal wel een bepaald nut heeft.

Ik denk dan ook, dat PHP zeer geschikt is voor wat het doet - op een snelle manier (zowel qua executie als qua coden) om gaan met data die te verwachten zijn op een webpagina (strings, e.d.)

Door de reusachtige ingebouwde functie set, is het (imho) een vrij krachtige scripttaal geworden, die zeker veel mensen voorziet van hetgene wat ze zoeken in deze scripttaal.

Het kiezen van de right tool for the job (zowel qua os als qua taal/interpreter) is veelal tekenend voor de kwaliteit van de system admin danwel de programmeur, en je kan dan PHP ook niet gaan verwijten dat het niet geschikt is om er full blown applicaties in te maken - dan heb je misschien de verkeerde oplossing gekozen.

Persoonlijk geef ik overigens sterk de voorkeur aan talen die wat meer typechecking hebben, en ook een iets minder ranzige syntax - dat maakt PHP niet slecht, mij hooguit wat ouderwets

[ACM]

Verwijderd schreef op 03 February 2003 @ 21:08:
Is dit wat:

PHP:

<html>
<head>
<title>
test
</title>
</head>
<body>
<?
function microtime_diff($a, $b)
{
    list($a_dec, $a_sec) = explode(" ", $a);
    list($b_dec, $b_sec) = explode(" ", $b);
    return $b_sec - $a_sec + $b_dec - $a_dec;
}

//begin tijd
$startTime = microtime();


// wat stringetjes maken
$test1 = "a test string ";
$test2 = " for testing speed";
$test3 = " while operating on strings";
//wat concatineren
$test4 = $test1 . $test2 . $test3;
//Even naar uppercase/lowecase slechts 5000 keer
for($i = 0; $i <=10000; ++$i ){
  if($i % 2 == 0)$test4 = strtoupper($test4);
  else $test4 = strtolower($test4);
}
//en naar het scherm die hap
print($test4);
print("\n");
//eind tijd
$endTime = microtime();
print(microtime_diff($startTime, $endTime));
print("\n");
?>

</body>
</html>

Zoiets dus?

Oeps, bugje

[ Voor 3% gewijzigd door ACM op 03-02-2003 21:59 ]

[Verwijderd]

Oh het duurde wat lang dat ik dacht dat je er niet meer was, dus ik was op dit gekomen:

code:

<html>
<head>
<title>
test
</title>
</head>
<body>
<?php
$starttime = microtime();

$test1 = "a test string"; 
$test2 = "for testing speed";
$test3 = "while operating on strings"
$test4 = $test1.$test2.$test3;

for ($i = 0; $i < 10000; $i++){
    if($i % 2 == 0 ) $test4 = strtoupper($test4);
    else $test4 = strtolower($test4);
}

$processtime = microtime() - $starttime;

echo $test4;
echo $processtime;

?>


</body>
</html>

[mbravenboer]

.oisyn: Het is nog niet af, ik moet nog een hoop operatoren implementeren, maar ik zal eens kijken of ik daarmee ook mee kan doen

De scriptcode wordt direct geinterpreteerd en dus niet eerst geconverteerd naar code, maar ik wil nou ook wel eens weten hoe snel het nou eigenlijk is

Probeer maar eens trager te zijn dan Stratego . Stratego is extreem slecht in string operaties, dus deze benchmark zal vrij rampzalig zijn.

Dit is mijn code (die overigens wat wat meer doet):

code:

module benchmark
imports cgi-service xml time
 
strategies
 
  cgi-benchmark =
    cgi-service-wrap(service-just-get(benchmark-service))
 
  benchmark-service =
    cgi-xml-output(!HTML(),
      !xml |[
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" >
 
        <html xmlns="http://www.w3.org/1999/xhtml">
          <head>
            <title>test</title>
          </head>
          <body>
           <p> ~cdata:<produce-content> () </p>
 
           <p>
              This page is generated by <a href="http://www.stratego-language.org">Stratego</a>.
            </p>
          </body>
        </html>
      ]|
      ; desugar-fix
    )
 
  produce-content = 
      profile(
        <concat-strings> ["a test string ", " for testing speed", " while operating on strings :"]
      ; string-as-chars(<repeat(step); Snd> (10000, <id>))
      )
    ; (id, int-to-string)
    ; conc-strings
 
  step :
    (i, s1) -> (<dec> i, s2)
      where <gt> (i, 0)
          ; <where(<even> i) < upper-case-chars + lower-case-chars> s1 => s2
 
  desugar-fix =
    topdown(
      try(
        Attribute(id, double-quote)
      )
    )

Dit is de output:

code:

<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" >
 
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>test</title>
  </head>
  <body>
    <p>
      a test string  for testing speed while operating on strings :104
    </p>
    <p>
      This page is generated by
      <a href="http://www.stratego-language.org">Stratego</a>.
    </p>
  </body>
</html>

Glimi: Jij wel, ga ik proberen of ik nog wat begrijp van de les van vandaag

Zoek de concrete syntax .

[Glimi]

mbravenboer schreef op 03 februari 2003 @ 21:49:
Zoek de concrete syntax .

code:

|[
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" >
 
        <html xmlns="http://www.w3.org/1999/xhtml">
          <head>
            <title>test</title>
          </head>
          <body>
           <p> ~cdata:<produce-content> () </p>
 
           <p>
              This page is generated by <a href="http://www.stratego-language.org">Stratego</a>.
            </p>
          </body>
        </html>
      ]|

Volgens mij was dat alles

[elevator]

mag ik meedoen met EleXer ?

Ik hoop dat dit een goede conversie is:

code:

program pw;

var Test1, 
    Test2, 
    Test3, 
    Test4   : String;
    i       : Integer;
begin
  WriteLn('Start: ', timestr(true,true));

  test1 := 'a test string ';
  test2 := ' for testing speed';
  test3 := ' while operating on strings';

  Test4 := Test1 + Test2 + Test3;
  
  for i := 0 to 10000 do
    begin
      if i mod 2 = 0 then
        Test4 := SUpCase(Test4)
          else Test4 := SLowCase(Test4);
    end; { for }
    
  writeln(test4);
  
  writeln('End: ', TimeStr(true,true));
end.

[Verwijderd]

even wat tussen door: http://www.caucho.com/articles/benchmark.xtp

[ACM]

* ACM heeft de java code herschreven tot:

Java:

<html>
<head>
<title>
test
</title>
</head>
<body>
<%
// wat stringetjes maken
String test1 = "a test string ";
String test2 = " for testing speed";
String test3 = " while operating on strings";
//wat concatineren
String test4 = test1+test2+test3;
//Even naar uppercase/lowecase slechts 5000 keer
for( int i = 0; i <=10000; ++i ){
  if(i % 2 == 0)test4 = test4.toUpperCase();
  else test4 = test4.toLowerCase();
}
//en naar het scherm die hap
out.println(test4);
%>

</body>
</html>

En de php-code tot:

PHP:

<html>
<head>
<title>
test
</title>
</head>
<body>
<?
// wat stringetjes maken
$test1 = "a test string ";
$test2 = " for testing speed";
$test3 = " while operating on strings";
//wat concatineren
$test4 = $test1 . $test2 . $test3;
//Even naar uppercase/lowecase slechts 5000 keer
for($i = 0; $i <=10000; ++$i ){
  if($i % 2 == 0)$test4 = strtoupper($test4);
  else $test4 = strtolower($test4);
}
//en naar het scherm die hap
print($test4);
print("\n");
?>

</body>
</html>

Met apache-1.3.27+php4.3.0 vs tomcat-4.0.6+j2se 1.4.1_01 levert dat met 10 requests achter elkaar in ab op:
Requests per second: 17.01 [#/sec] (mean)
Time per request: 58.80 [ms] (mean)
Time per request: 58.80 [ms] (mean, across all concurrent requests)
Transfer rate: 5.77 [Kbytes/sec] received
en in jsp
Requests per second: 16.98 [#/sec] (mean)
Time per request: 58.90 [ms] (mean)
Time per request: 58.90 [ms] (mean, across all concurrent requests)
Transfer rate: 6.15 [Kbytes/sec] received


Voor 10 tegelijk, 100 in totaal, php:
Requests per second: 15.90 [#/sec] (mean)
Time per request: 629.10 [ms] (mean)
Time per request: 62.91 [ms] (mean, across all concurrent requests)
Transfer rate: 5.55 [Kbytes/sec] received
vs
Requests per second: 14.00 [#/sec] (mean)
Time per request: 714.20 [ms] (mean)
Time per request: 71.42 [ms] (mean, across all concurrent requests)
Transfer rate: 5.12 [Kbytes/sec] received

Kortom, je hebt mij nog niet overtuigd dat jsp veel of zelfs 3x sneller is...

[Verwijderd]

En ik mezelf ook niet, laatste test bij mij was het toch wel zo (en dan doel ik niet op nu maar via mijn instituut). Waarschijnlijk heb ik dus zo snel niet een goede test bedacht, is kijken of ik (of iemand anders) met iets anders kan komen...

[ACM]

Verwijderd schreef op 03 February 2003 @ 22:06:
even wat tussen door: http://www.caucho.com/articles/benchmark.xtp

Discussion

(...)

So is Resin or PHP or Perl faster? It really depends on your application. As a first cut, it's probably best to assume they have about the same performance unless you can benchmark your specific application. A difference of only 30% in a toy benchmark should be interpreted as having little or no difference.

These results are primarly important because previous servlet engines were much slower than PHP or Perl. With Resin, servlet performance is now about the same. Projects should use other considerations, like maintainability or ease of implementation to decide between the languages.

Conclusion

JSP can approach static page performance. A perception still exists that Java is a great programming environment but hobbled by performance. The perception is no longer valid.

The near-static performance means that many sites, who never considered JSP or servlets because of performance, can now take advantage of the Java platform's reliability and ease of programming benefits.

Met deze stukjes ben ik het iig absoluut eens
Er is geen "die is altijd sneller dan die ander".

Want voor dezelfde functionalititeit had ik ook jouw code kunnen herschrijven tot:

PHP:

<html>
<head>
<title>
test
</title>
</head>
<body>
<?
// wat stringetjes maken
$test1 = "a test string ";
$test2 = " for testing speed";
$test3 = " while operating on strings";
//wat concatineren
$test4 = $test1 . $test2 . $test3;
//Even naar uppercase/lowecase slechts 5000 keer
//en naar het scherm die hap
print(strtoupper($test4));
print("\n");
?>

</body>
</html>

Aangezien dat voor de gebruiker hetzelfde doet

Verwijderd schreef op 03 februari 2003 @ 22:16:
En ik mezelf ook niet, laatste test bij mij was het toch wel zo (en dan doel ik niet op nu maar via mijn instituut). Waarschijnlijk heb ik dus zo snel niet een goede test bedacht, is kijken of ik (of iemand anders) met iets anders kan komen...

Ga er nou maar gewoon van uit dat er wat er bij die Resin benchmarks in de discussion en conclusion staat waar is
En gooi je jsp-argumentatie op echte argumenten, niet op subjectieve argumenten als "het is 3x zo snel".

[ Voor 14% gewijzigd door ACM op 03-02-2003 22:18 ]

[ACM]

Btw, ter referentie voor de genen die graag de performance van hun lievelingstaal hiertegen af willen zetten.
Het gebruikte systeem alhier was een zeer licht belastte (ok, op dat moment even niet ) gentoo linux met op een athlon 850 + 512MB ecc ddr ram geheugen.
De gcc 2.95.3 compiler wordt daarbij telkens met march=i686 -O3 -pipe toegepast waardoor php 4.3.0 (met vrij veel modules, default gentoo-config) en apache 1.3.27 (ook met vrij veel modules) redelijk (niet extreem) optimised zijn.

Verder gebruikte het de default apache en php configuraties evenals de default tomcat 4.0.6 configuratie die verder dus met de i586 java j2se-1.4.1_01 draaide.

Waarbij ab dus in het eerste geval met -n 10 draaide en in het tweede geval met -n 100 -c 10 beide vanaf de lokale prompt.

[ Voor 17% gewijzigd door ACM op 03-02-2003 22:28 ]

[.oisyn]

OMG

M'n scripttaaltje is af (afgezien van de ingebouwde functies die er nog niet zijn), en het is gewoon sneller dan php

code:

var t = time ();

var test1 = "a test string "; 
var test2 = " for testing speed"; 
var test3 = " while operating on strings";

var test4 = test1 + test2 + test3; 

for (var i = 0; i <= 10000; ++i)
{ 
    if (i % 2 == 0)
        test4 = strToUpper (test4);
    else
        test4 = strToLower (test4); 
}

t = time () - t;

write (test4, "\n");
write (t, " seconds");

hij doet er gemiddeld 0.11 (!!!) seconden over op mijn bak (athlon xp 1400 MHz)
php doet er gemiddeld 0.35 seconden over

Mijn scripttaal (oScript Lite) interpreteert direct na het parsen en er is dus geen code generatie of optimalisatie

ik zei toch dat php bagger was, zelf ik, die met een eerste poging een scripttaal in elkaar flanst, kan het beter
Nou is deze benchmark ook niet echt representatief, maar goed

[Verwijderd]

ACM schreef op 03 February 2003 @ 22:16:
Ga er nou maar gewoon van uit dat er wat er bij die Resin benchmarks in de discussion en conclusion staat waar is
En gooi je jsp-argumentatie op echte argumenten, niet op subjectieve argumenten als "het is 3x zo snel".

Gozer, vriend, gabber, maat, kerel, hoe vaak moet ik nog zeggen dat dat de uitslag was van een objectieve test!?!?!?! Daaruit kwam dat jsp 3 keer zo snel was. Ik ga niet zomaar zitten blaten, en het traagste onderdeel van java wordt nu even getest, namelijk strings.

En nogmaals echte argumenten:

-taglib extension, iets wat php niet heeft.
-javadoc als documentatie (standaard onderdeel van Java 2.0)
-goede scheiding tussen data en interface (afgedwongen door klasses in apparte directories op te nemen)
-nette manier van globale instellingen middels web.xml
-...daardoor 1 standaard programmeer methodiek, dus makkelijk voor iedereen om te begrijpen.

[mulder]

lol.. heb jij soms ook die browser gemaakt

[elevator]

ok, dan heb ik ook maar even de eerder gepostte code gebenchmarked:
Athlon 750 - WindowsXP, niet zwaar belast.

EleXer:
0.17 seconden

PHP: (de versie van ACM met timing erin):
0.728971

oScript:
0.290999 seconds

maar zoals al eerder gezegd. Deze benchmark zegt erg weinig, al heeft het me mooi geholpen een bug op te lossen in de 'SUpCase' routine

Het probleem is natuurlijk dat je iets heel specifieks test - als je bv. van die test4[] een array maakt, zie dat PHP er geen moeite mee heeft:

PHP: 0.779385
EleXer: 0.38 seconden

zoals je ziet, stort de snelheid van EleXer (nog ) volledig in. Dus het is maar welk element je test, en dan ook nog eens specifiek hoe je het aanpakt.

[hobbit_be]

[quote]ACM schreef op 03 February 2003 @ 22:07:

Java:

// wat stringetjes maken
String test1 = "a test string ";
String test2 = " for testing speed";
String test3 = " while operating on strings";
//wat concatineren
String test4 = test1+test2+test3;
//Even naar uppercase/lowecase slechts 5000 keer
for( int i = 0; i <=10000; ++i ){
  if(i % 2 == 0)test4 = test4.toUpperCase();
  else test4 = test4.toLowerCase();
}

wil je wel effe StringBuffers gebruiken...

[Glimi]

hobbit_be schreef op 03 februari 2003 @ 23:26:
wil je wel effe StringBuffers gebruiken...

Dat doet de compiler automatisch bij een concatenatie op één enkele regel.

edit:
Ik lees een beetje over de toUpperCase() en toLowerCase() heen zie ik al

[ Voor 16% gewijzigd door Glimi op 03-02-2003 23:35 ]

[mbravenboer]

.oisyn: M'n scripttaaltje is af (afgezien van de ingebouwde functies die er nog niet zijn), en het is gewoon sneller dan php

Ik heb zo het donkere vermoeden dat je strToUpper en strToLower in native code geimplementeerd hebt (C, C++ oid). Zo kan ik het ook .

PS: de discussie over PHP versus Java is verder zo onzinnig als het maar zijn kan. Als je erover discussieert, probeer dan in ieder geval een beetje normaal en serieus te discussieren en niet op basis van vage kreten en niet onderbouwde tests. Het discussie over PHP versus Python lijkt mij meer op z'n plaats . Het is afgezaagd, maar je bent echter appels met peren aan het vergelijken.

[ Voor 42% gewijzigd door mbravenboer op 03-02-2003 23:37 ]

[.oisyn]

klopt idd, maar dat is in php ook het geval, dus het blijft een eerlijke test

[mbravenboer]

.oisyn: klopt idd, maar dat is in php ook het geval, dus het blijft een eerlijke test

Ah ok... Mee eens.

Stratego doet het zelf .

code:

  // :: String -> String
  lower-case = string-as-chars(lower-case-chars)
  upper-case = string-as-chars(upper-case-chars)
 
  // :: List(Char) -> List(Char)
  lower-case-chars = map(to-lower)
  upper-case-chars = map(to-upper)

[ACM]

.oisyn schreef op 03 februari 2003 @ 23:04:
Mijn scripttaal (oScript Lite) interpreteert direct na het parsen en er is dus geen code generatie of optimalisatie

ik zei toch dat php bagger was, zelf ik, die met een eerste poging een scripttaal in elkaar flanst, kan het beter
Nou is deze benchmark ook niet echt representatief, maar goed

Maar kan jouw scripttaal nog meer dan bovenstaand stukje code parsen? Of is dat wel zo'n beetje de volledige functionaliteit?
Ow en draait het ook op een linux doos? PHP is natuurlijk niet zo vlot op windows (valt geloof ik wel mee, magoed, je moet wat beweren )

hobbit_be schreef op 03 februari 2003 @ 23:26:
wil je wel effe StringBuffers gebruiken...

En waar gaat dat een significant verschil opleveren?
Btw, zoals je in dit topic kan zien was het niet mijn code.

mbravenboer schreef op 03 februari 2003 @ 23:34:
PS: de discussie over PHP versus Java is verder zo onzinnig als het maar zijn kan. Als je erover discussieert, probeer dan in ieder geval een beetje normaal en serieus te discussieren en niet op basis van vage kreten en niet onderbouwde tests. Het discussie over PHP versus Python lijkt mij meer op z'n plaats . Het is afgezaagd, maar je bent echter appels met peren aan het vergelijken.

Doe maar een stukje python dat hetzelfde doet dan, zal ik es `emerge mod_snake` of `emerge mod_python` doen hier

En dezelfde ab eroverheen jagen.

[ Voor 8% gewijzigd door ACM op 04-02-2003 08:12 ]

[ACM]

Verwijderd schreef op 03 February 2003 @ 23:04:
Gozer, vriend, gabber, maat, kerel, hoe vaak moet ik nog zeggen dat dat de uitslag was van een objectieve test!?!?!?! Daaruit kwam dat jsp 3 keer zo snel was.

Ja een test, niet alle tests...

Ik ga niet zomaar zitten blaten, en het traagste onderdeel van java wordt nu even getest, namelijk strings.

Nou, dan bedenk je wat anders
Gaan we dat benchmarken, hoe snel er bepaalde data uit mysql/postgresql te trekken is ofzo (alleen wel meer een benchmark voor de drivers en de database dan de engine zelf).
Dat is iets meer representatief voor de gemiddelde webapplicatie zelfs...
Ik wil best geloven dat jsp/servlets in sommige/veel/bijna alle gevallen sneller is, maar doe me dan wel serieus bewijs of bijvoorbeeld een link of testuitslag.

-taglib extension, iets wat php niet heeft.
-javadoc als documentatie (standaard onderdeel van Java 2.0)
-goede scheiding tussen data en interface (afgedwongen door klasses in apparte directories op te nemen)
-nette manier van globale instellingen middels web.xml
-...daardoor 1 standaard programmeer methodiek, dus makkelijk voor iedereen om te begrijpen.

En nogmaals, dat kan ook allemaal in php.
Een programmeer methodiek moet je alsnog leren, ook voor java.

[ Voor 11% gewijzigd door ACM op 04-02-2003 08:16 ]

[Verwijderd]

Lekker trieste "discussie" is dit geworden zeg
Een benchmark waarmee je geen zak aantoont, twee mensen waarvan ik van iig een toch wel zou verwachten OF de flamerige onbeargumenteerde opmerkingen te negeren OF ze te bestrijden met WEL beargumenteerde opmerkingen, maar nee. Maar goed, alles is ook wel gezegd denk ik...

[EfBe]

Verwijderd schreef op 03 februari 2003 @ 20:12:
ah, vergeet ik toch je opmerking over documentatie. Er is in php geen documentatie standaard, in java wel, namelijk javadoc.

Oh ja jippie. Die gegenereerde docs van Sun. No offence, maar daar heb je geen reet aan. Iedereen die ook maar 1 blik geworpen heeft op de MSDN weet dat. JSP zal wellicht betere docs hebben dan Php, maar dat neemt niet weg dat Php toch aardig in staat is om de developer dat platform te bieden waarop leuke dingen gedaan kunnen worden. Zie al die CMS-en, fora, site managers, zelfs db-tools.

Plus, no offence II, maar JSP blijft een ASP clone en je wilt echt niet meer je logica tussen HTML code prakken, plus je wilt alles als 1 app draaien, zodat je vanaf de page totaan je stored procedure kunt debuggen in 1 debugger.

[EfBe]

Verwijderd schreef op 03 februari 2003 @ 21:19:
Als je een beter stukje code hebt, kom maar op. Ik wist even niets anders, maar ja string zijn traag in Java, dus leek me wel handig om die te pakken. En uppercase/lowercase is voor java een zeer zwaar klusje...

Zegt genoeg over de structuur die erachter zit. In 1995, toen ik mn eerste rotozoomer applet maakte in Java waren arrays al traag en string operaties niet te harden zo langzaam. Als dat in 2003 nog zo is, dan heeft iedere java-programmeur boter op zn hoofd wanneer deze verklaart met state-of-the-art spullen bezig te zijn.