[alg/disc] PHP is dood? *

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

[EfBe]

.NET (C#)

page:

HTML:

<%@ Page language="c#" Codebehind="Test.aspx.cs" AutoEventWireup="false" Inherits="Bla.Test" %>

<html>
  <head> 
<title>Test</title>
</head> 
<body> 
Starttijd: <asp:label Runat="server" ID="lblStartTijd" /><br>
Eindtijd: <asp:label Runat="server" ID="lblEindTijd" />
<br><br>
Result: <asp:label Runat="server" ID="lblResult" />
</body>
</html>

codebehind:

C++:

using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Web;
using System.Web.SessionState;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;

namespace Bla
{
    /// <summary>
    /// Summary description for Test.
    /// </summary>
    public class Test : System.Web.UI.Page
    {
        protected System.Web.UI.WebControls.Label lblStartTijd;
        protected System.Web.UI.WebControls.Label lblResult;
        protected System.Web.UI.WebControls.Label lblEindTijd;
    
        private void Page_Load(object sender, System.EventArgs e)
        {
            DateTime daStartTime, daEndTime;

            daStartTime = DateTime.Now;

            // 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.ToUpper();
                }
                else
                {
                    test4 = test4.ToLower();
                }
            } 
        
            daEndTime = DateTime.Now;

            lblStartTijd.Text = daStartTime.ToString("HH-mm-ss-ffff");
            lblEindTijd.Text = daEndTime.ToString("HH-mm-ss-ffff");
            lblResult.Text = test4;
        }

        #region Web Form Designer generated code
        override protected void OnInit(EventArgs e)
        {
            //
            // CODEGEN: This call is required by the ASP.NET Web Form Designer.
            //
            InitializeComponent();
            base.OnInit(e);
        }
        
        /// <summary>
        /// Required method for Designer support - do not modify
        /// the contents of this method with the code editor.
        /// </summary>
        private void InitializeComponent()
        {    
            this.Load += new System.EventHandler(this.Page_Load);

        }
        #endregion
    }
}

Result:
Starttijd: 10-10-45-5937
Eindtijd: 10-10-45-6250

Result: A TEST STRING FOR TESTING SPEED WHILE OPERATING ON STRINGS

Gedraaid in debugmode (dus non-optimized code) meteen na compile, dus geen jit-precache voordeel, op een Dual p3-933 CUS-DLS machine met 512MB ram en win2k server.

edit:
na een aantal keren cntrl-refresh te hebben gedaan zit de jit op 2ms per request . Beat that, Sun-boy!

[ Voor 10% gewijzigd door EfBe op 04-02-2003 10:22 ]

[mbravenboer]

EfBe: Oh ja jippie. Die gegenereerde docs van Sun. No offence, maar daar heb je geen reet aan.

Ik weet niet of je dit inhoudelijk of qua opzet bedoeld? Als je doelt op de opzet van de gegenereerde docs: er is al een tijde een mechanisme waarmee je vrij gemakkelijk een eigen doc-generator kan inpluggen in Javadoc. Als je dus een ander output formaat wilt, kan je dat zelf maken. Volgens mij is er alleen nog niet echt een subliem idee uitgevoerd, dus wellicht zitten die docs nog niet zo slecht in elkaar .

EfBe: 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.

flame doos . Het lijkt mij nogal wiedes dat als je array-bounds checking en immutable strings gebruikt in een platform waarin je ook nog gebruik maakt van een jitter, je performance op dit punt nooit super zal zijn. Als je nu eens geen jitter gebruikt zou je je beperkingen wellicht nog wat kunnen opheffen met compile-time eliminatie van onnodige bounds-checks, maar ja: ga dat at runtime maar eens doen.

[EfBe]

Ik doelde op de inhoud van de docs. Of ze moeten heel recentelijk zijn verbeterd, maar wat Sun levert aan docs is ten eerste zeer onoverzichtelijk en ten tweede puur reference materiaal waarbij alleen het alle broodnodige wordt uitgelegd (m.a.w. je hebt er geen reet aan).

Dat arraybounds mee moeten worden gecompileerd snap ik wel, maar dat de JIT daar nu nog steeds zn muil over breekt vind ik toch wel wat raar, aangezien veel mensen arrays gebruiken en je die code best kunt optimizen. String concatenatie is een zeer snelle operatie zeker bij immutable strings, raar dat het dan toch 'traag' is. Naja, het blijft java, dus imho maar voor een aantal mensen echt belangrijk, en off topic (want we waren over php aan het zeuren en niet over Sun's product dat alleen maar geld kost.)

[mbravenboer]

EfBe: Dat arraybounds mee moeten worden gecompileerd snap ik wel, maar dat de JIT daar nu nog steeds zn muil over breekt vind ik toch wel wat raar, aangezien veel mensen arrays gebruiken en je die code best kunt optimizen.

Uiteraard kan je er veel weg optimaliseren, maar heb je daar at runtime genoeg tijd voor? Het hele model van bytecode die heel dicht bij de oorspronkelijke taal ligt en pas at runtime wordt gecompileerd naar native code werkt gewoon niet als je ingewikkeldere optimalisaties wilt uitvoeren. Een array-bounds check kan je niet uitschakelen in Java bytecode (maar goed ook overigens) en daarom zal het altijd een probleem blijven.

String concatenatie is een zeer snelle operatie zeker bij immutable strings, raar dat het dan toch 'traag' is.

Nou ja, concats zijn in alle talen met immutable data structuren een probleem. Een lijst concat is in functionele talen ook iets wat je wilt vermijden. Zo vreemd is het denk ik niet dat een concat een dure operate is, juist bij immutable data structuren.

Overigens werd er in dit voorbeeld met name de to-upper en to-lower getest en niet zozeer de concat op strings. Als de String ook daadwerkelijk veranderd wordt er steeds een nieuwe String opgebouwd (als hij niet veranderd overigens niet). Dat is dus altijd een trage operatie (hoe bedoel je garbage ), wat je ook doet qua optimalisaties.

[ACM]

EfBe schreef op 04 February 2003 @ 10:16:
Result:
Starttijd: 10-10-45-5937
Eindtijd: 10-10-45-6250

Das toch 31.3 ms?

edit:
na een aantal keren cntrl-refresh te hebben gedaan zit de jit op 2ms per request . Beat that, Sun-boy!

2ms om op die p3-933 die code uit te voeren ?
Das wel heel snel, ik had (niet zozeer hiervoor) .oisyn gevraagd of ie een c++ versie wilde maken van de code, op mijn amd athlon xp2100+ doet dat er 17ms over, op zijn athlon 1400 20ms. Een versie die met char-arrays werkt deed er bij hem 8ms over.

Zou jij ons uit kunnen leggen wat .NET allemaal voor optimalisaties weet te doen waardoor dat in 2ms kan op een tragere cpu?
Of was het een tikfout, dat is ook mogelijk natuurlijk (20ms ofzo)

[EfBe]

ACM schreef op 04 februari 2003 @ 23:11:
[nohtml]
[...]

Das toch 31.3 ms?

62-59 = 3 honderste van een seconde, is iid 31.3ms.

[...]

2ms om op die p3-933 die code uit te voeren ?
Das wel heel snel, ik had (niet zozeer hiervoor) .oisyn gevraagd of ie een c++ versie wilde maken van de code, op mijn amd athlon xp2100+ doet dat er 17ms over, op zijn athlon 1400 20ms. Een versie die met char-arrays werkt deed er bij hem 8ms over.

Domme fout van mij. 44-42 == 2 honderste van een seconde, is 20 ms.

[ACM]

EfBe schreef op 04 February 2003 @ 23:28:
Domme fout van mij. 44-42 == 2 honderste van een seconde, is 20 ms.

Ik vond die tijd al zo knap
Het moest ofwel output-cacheing zijn ofwel een foutje. Het eerste zou in het licht van deze "loze" (ja, dat geef ik direct toe ) benchmark niet eerlijk zijn het tweede geeft natuurlijk niet maar is wel handig om te weten

[whoami]

mbravenboer schreef op 04 February 2003 @ 12:58:

Nou ja, concats zijn in alle talen met immutable data structuren een probleem. Een lijst concat is in functionele talen ook iets wat je wilt vermijden. Zo vreemd is het denk ik niet dat een concat een dure operate is, juist bij immutable data structuren.

Overigens werd er in dit voorbeeld met name de to-upper en to-lower getest en niet zozeer de concat op strings. Als de String ook daadwerkelijk veranderd wordt er steeds een nieuwe String opgebouwd (als hij niet veranderd overigens niet). Dat is dus altijd een trage operatie (hoe bedoel je garbage ), wat je ook doet qua optimalisaties.

Voor die string-concatenatie kon EfBe natuurlijk nog gebruik gemaakt hebben van een StringBuilder in .NET, wat ook nog wat performance winst zou moeten opleveren.
Maar dit is eigenlijk off-topic.

[Verwijderd]

whoami schreef op 05 February 2003 @ 09:33:

[...]


Voor die string-concatenatie kon EfBe natuurlijk nog gebruik gemaakt hebben van een StringBuilder in .NET, wat ook nog wat performance winst zou moeten opleveren.
Maar dit is eigenlijk off-topic.

Hetzelfde geldt voor Java hoor (maar dan heet het StringBuffer )

[ACM]

whoami schreef op 05 February 2003 @ 09:33:
Voor die string-concatenatie kon EfBe natuurlijk nog gebruik gemaakt hebben van een StringBuilder in .NET, wat ook nog wat performance winst zou moeten opleveren.
Maar dit is eigenlijk off-topic.

Als het concateneren van 3 strings aan elkaar zo veel uitmaakt tov dmv een StringBuilder/StringBuffer dat het significant scheelt in bovenstaande testcode voor de executie tijd dan is het eigenlijk wel heel triest gesteld met de performance van de concatenatie

Die concat loopt niet 10000x hoor

[whoami]

ACM schreef op 05 februari 2003 @ 12:41:
[nohtml]
[...]
[/nohtml]
Als het concateneren van 3 strings aan elkaar zo veel uitmaakt tov dmv een StringBuilder/StringBuffer dat het significant scheelt in bovenstaande testcode voor de executie tijd dan is het eigenlijk wel heel triest gesteld met de performance van de concatenatie

Die concat loopt niet 10000x hoor

Neen, inderdaad, je hebt wel gelijk dat het niet zoveel uitmaakt voor de concatenatie van 3 strings.
Ik wou gewoon nog ff een ander puntje aanhalen.

[Glimi]

ACM schreef op 05 februari 2003 @ 12:41:
Als het concateneren van 3 strings aan elkaar zo veel uitmaakt tov dmv een StringBuilder/StringBuffer dat het significant scheelt in bovenstaande testcode voor de executie tijd dan is het eigenlijk wel heel triest gesteld met de performance van de concatenatie

Die concat loopt niet 10000x hoor

De concat zal niet echt sneller worden hoor. Dit omdat de overloading van de plus op een String in Java suiker is voor het gebruik van een StringBuffer. Het toUpperCase() toLowerCase() verhaal zal door een stringbuffer het creëren van 10000 objecten-overhead verhaal niet hebben.
Neemt niet weg dat de JITter het huidge geval hoptelijk/waarschijnlijk toch dooroptimaliseerd naar een println( test4.toUpperCase() )

[ Voor 8% gewijzigd door Glimi op 05-02-2003 12:48 ]

[ACM]

Glimi schreef op 05 februari 2003 @ 12:47:
De concat zal niet echt sneller worden hoor. Dit omdat de overloading van de plus op een String in Java suiker is voor het gebruik van een StringBuffer.

Met zoiets maakt het wel uit natuurlijk

Java:

String string = "blaat";
String string2 = "bladiebla";
String string3 = new String();
for(int i = 0; i < 10000; i++)
{
    string3 += string + string2;
}

Als daar stond string3 = string + string2 was het natuurlijk een ander verhaal
Omdat dan de overhead precies hetzelfde is als er zelf eerst een stringbuffer tussen zetten.

Het toUpperCase() toLowerCase() verhaal zal door een stringbuffer het creëren van 10000 objecten-overhead verhaal niet hebben.
Neemt niet weg dat de JITter het huidge geval hoptelijk/waarschijnlijk toch dooroptimaliseerd naar een println( test4.toUpperCase() )

Nou... blijkbaar niet.
Ook niet als je de code met java -O compileert ofzo. Dan kost het hier nog zo'n 50ms.

[mbravenboer]

Glimi: Het toUpperCase() toLowerCase() verhaal zal door een stringbuffer het creëren van 10000 objecten-overhead verhaal niet hebben.

Daar zit zeker wel wat in: een toUpperCase en een toLowerCase op een StringBuffer zal veel betere performance laten zien. Helaas zijn alleen bij lange na niet alle String operaties beschikbaar in een StringBuffer en zal je dit dus zelf moeten implementeren.

Probleem daarbij is dan weer dat een toUpperCase en toLowerCase eigenlijk rekening moet houden met de meest bizarre Locales. De code in java.lang.String gebruikt de Character klasse zwaar, maar maakt weer een bijzondere uitzondering van de Turkse Locale. Dit laat denk ik goed zijn dat het design zwak is: een toUpperCase moet je niet implementeren in een String datatype: hij moet kunnen functioneren op alle mogelijk String representaties.

Neemt niet weg dat de JITter het huidge geval hoptelijk/waarschijnlijk toch dooroptimaliseerd naar een println( test4.toUpperCase() )

Zo slim zijn die dingen inderdaad niet. Het is nog maar de vraag of een compile-time compiler (wat een term ) dit wel goed zou kunnen achterhalen zonder ingebouwde kennis te hebben van het gedrag van Strings (en dus gewoon op de Java sources werkt).

[LauPro]

Ik ben ook even bezig geweest, ik weet niet of ik het helemaal goed doe maar ik kom op 31,25 ms uit (http://laupro.nl/rommel/test.asp)

ASP:

<% Option Explicit

Dim sStartTimer, test1, test2, test3, test4, I

sStartTimer = Timer
    
' 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?? 10000 toch .. keer  
For I = 1 To 10000
    If I Mod 2 = 0 Then
        test4 = UCase(test4)
    Else
        test4 = LCase(test4)
    End If
Next

Response.Write Timer - sStartTimer
%>

Ik weet alleen niet wat voor een server het is (maar ik schat zo Pentium 3 1 Ghz oid), bij mij thuis op een Pentium 3 366 Mhz doet hij het 80 ms over.

edit: Ik heb de versie van ACM ook op die server gezet: http://laupro.nl/rommel/test.php

Die doet er 0.462491 seconden over, of tewel ruim 430 ms meer! Voor mij geen php voorlopig _{geintje , is btw een wel een IIS server}


Misschien leuk dat we een goede test opzetten, want om alleen te mierenneuken op strings scheit niet op. Ik stel voor:
• De bovenstaande code
• Gebruiken van Tan, Cos en Sin (om de rekenkracht met 'Floating Point' e.d. er een beetje uit te halen)
• Gebruik van een database, 10000 keer table createn, 10000 keer records toevoegen, 10000 keer updaten, 10000 keer verwijderen (niet in een keer dus ), en de 10000 tabellen verwijderen.
• Gebruikt van 'server variabelen' (voor zover die er zijn). Globaal 10000 keer een variabel vullen met een bepaade tekst/waarde.

Dan heb je een iets breder gebied, al deze getalletjes zijn wel mooi maar niet echt gelijkwaardig. Er kunnen natuurlijk meerdere databases worden gebruikt per configuratie.

[ Voor 47% gewijzigd door LauPro op 05-02-2003 21:02 ]

[.oisyn]

[nohtml]

LauPro schreef op 05 februari 2003 @ 20:43:
Gebruiken van Tan, Cos en Sin (om de rekenkracht met 'Floating Point' e.d. er een beetje uit te halen)

dit zal bij bijna alle talen op hetzelfde uitkomen. Je zou natuurlijk kunnen kijken hoe goed expressies geoptimaliseerd worden, maar het gebruik van deze functies is totaal nutteloos omdat ze gewoon direct op de CPU werken. Dat is dus meer een processor-benchmark dan een taal-benchmark

Gebruik van een database, 10000 keer table createn, 10000 keer records toevoegen, 10000 keer updaten, 10000 keer verwijderen (niet in een keer dus ), en de 10000 tabellen verwijderen.

Evenals het vorige voorbeeld is dit meer een database driver benchmark. Je kunt hooguit kijken hoe snel de variabelen worden omgezet zodra ze uit de database zijn gekomen, maar dan heb je er dus ook geen database meer voor nodig aangezien dat gedeelte nou net niet belangrijk is

Gebruikt van 'server variabelen' (voor zover die er zijn). Globaal 10000 keer een variabel vullen met een bepaade tekst/waarde.

ik snap niet helemaal wat je hiermee bedoelt

[LauPro]

.oisyn schreef op 05 February 2003 @ 22:16:
[nohtml]
[...]
dit zal bij bijna alle talen op hetzelfde uitkomen. Je zou natuurlijk kunnen kijken hoe goed expressies geoptimaliseerd worden, maar het gebruik van deze functies is totaal nutteloos omdat ze gewoon direct op de CPU werken. Dat is dus meer een processor-benchmark dan een taal-benchmark.

Hier ben ik het niet helemaal mee eens omdat de meesten bij php als eerste factor de snelheid noemen. Bovendien heb ik van iemand gehoord dat een LAMP-configuratie 70% sneller is dan ASP/IIS. Bovendien kan je kijken welke taal beter geschikt is voor het aanmaken van bijvoorbeeld plaatjes met grafieken e.d. (wat bij sommige talen dus al helemaal niet kan tenzij je plugins gebruikt, maar dan is het weer de vraag tot in hoe ver je bij de taal moet blijven).

[...]
Evenals het vorige voorbeeld is dit meer een database driver benchmark. Je kunt hooguit kijken hoe snel de variabelen worden omgezet zodra ze uit de database zijn gekomen, maar dan heb je er dus ook geen database meer voor nodig aangezien dat gedeelte nou net niet belangrijk is

Nou lijkt mij wel? Stel dat React nu voor ASP/IIS had gekozen, zou het forum dan sneller zijn? Ik vraag me nu wel af of dat php nu werkelijk zoveel scheelt (de kostprijs haal je er uit als het sneller zou zijn).

[...]
ik snap niet helemaal wat je hiermee bedoelt

ASP kent bijvoorbeeld Application() en PHP $_GLOBAL[] (meen ik, volgens mij is dit niet helemaal waar wat ik zeg). Dat soort variabelen die 'algemeen zijn', eigenlijk gewoon een dump naar het geheugen toe en weer terug om te kijken hoe de taal er mee omgaat.

[ Voor 3% gewijzigd door LauPro op 05-02-2003 22:25 ]

[.oisyn]

LauPro schreef op 05 February 2003 @ 22:24:
[...]
Hier ben ik het niet helemaal mee eens omdat de meesten bij php als eerste factor de snelheid noemen. Bovendien heb ik van iemand gehoord dat een LAMP-configuratie 70% sneller is dan ASP/IIS. Bovendien kan je kijken welke taal beter geschikt is voor het aanmaken van bijvoorbeeld plaatjes met grafieken e.d. (wat bij sommige talen dus al helemaal niet kan tenzij je plugins gebruikt, maar dan is het weer de vraag tot in hoe ver je bij de taal moet blijven).

Nu haal je er echt hele andere functionaliteit bij dan de rekenfuncties zelf. Het zijn gewoon pure functies die, gegeven een argument, een ander getal teruggeven. De taal heeft hier zelf weinig mee te maken als er gewoon gebruik wordt gemaakt van native floating point getallen en FPU functionaliteit. En dat is vrijwel altijd het geval.
Wat jij wil testen is bijvoorbeeld het aanmaken van plaatjes, en dus hoe goed een implementatie is met het accessen van buffers en arrays. Dat je daar trigonometrische functies bij gaat gebruiken is daaraan ondergeschikt

Nou lijkt mij wel? Stel dat React nu voor ASP/IIS had gekozen, zou het forum dan sneller zijn? Ik vraag me nu wel af of dat php nu werkelijk zoveel scheelt (de kostprijs haal je er uit als het sneller zou zijn).

ik had het er net met ele over in #devschuur. Wat je test is een implementatie van een database API die gebruikt wordt in de taal. Zo gebruikt PHP bijvoorbeeld de mysql API die direct op de database werkt, maar ASP zal waarschijnlijk een OLE DB of ODBC API gebruiken. Je test hier de database API, niet de taal. Als je een eerlijke test wilt zul je in alle talen dezelfde onderliggende implementatie moeten gebruiken, anders is het geen eerlijke test.
Wat je zo natuurlijk wel kan testen is welke taal out-of-the-box sneller werkt. Maar goed, wat let je om een snellere implementatie te schrijven en daarvan gebruik te maken in jouw favo taal? Maar als je dat doet kun je niet zeggen dat die taal daarom sneller is

ASP kent bijvoorbeeld Application() en PHP $_GLOBAL[] (meen ik, volgens mij is dit niet helemaal waar wat ik zeg). Dat soort variabelen die 'algemeen zijn', eigenlijk gewoon een dump naar het geheugen toe en weer terug om te kijken hoe de taal er mee omgaat.

Dit zal niet veel anders zijn dan de gewone (locale) variabele die je gebruikt in je scripts/programma's. In oScript worden alle globale variabelen van externe functies gewoon gemapped in de globale context, net als dat je een globale variabele zou declareren in het script. In PHP is het gebruik van $_GLOBAL ook gewoon het gebruik van 'een array', en in ASP waarschijnlijk gewoon het gebruik van een Object.

[ Voor 1% gewijzigd door .oisyn op 06-02-2003 03:32 . Reden: erg foute woordkeuze :) ]

[LauPro]

.oisyn schreef op 05 February 2003 @ 22:37:
[nohtml]
[...]
Nu haal je er echt hele andere functionaliteit bij dan de rekenfuncties zelf. Het zijn gewoon pure functies die, gegeven een argument, een ander getal teruggeven. De taal heeft hier zelf weinig mee te maken als er gewoon gebruik wordt gemaakt van native floating point getallen en FPU functionaliteit. En dat is vrijwel altijd het geval.
Wat jij wil testen is bijvoorbeeld het aanmaken van plaatjes, en dus hoe goed een implementatie is met het accessen van buffers en arrays. Dat je daar trigonometrische functies bij gaat gebruiken is daaraan ondergeschikt

De meeste auto's rijden op benzine, dezelfde benzine, alleen hoe daarmee wordt omgegaan in de auto is verschillend. Je kan niet zeggen dat 1 liter benzine tegenover 15 km staat, dat is per auto verschillend, zo ook met deze talen. Ze zullen welliswaar de 'pure functies' aanroepen, maar dan is het altijd nog wel interesant hoe de taal die functie gebruikt en of er bijvoorbeeld veel vertraging zit in bepaalde checks die vooraf worden uitgevoerd. Dus imo heeft een dergelijke test wel degelijk effect.

[...]
ik had het er net met ele over in #devschuur. Wat je test is een implementatie van een database API die gebruikt wordt in de taal. Zo gebruikt PHP bijvoorbeeld de mysql API die direct op de database werkt, maar ASP zal waarschijnlijk een OLE DB of ODBC API gebruiken. Je test hier de database API, niet de taal. Als je een eerlijke test wilt zul je in alle talen dezelfde onderliggende implementatie moeten gebruiken, anders is het geen eerlijke test.
Wat je zo natuurlijk wel kan testen is welke taal out-of-the-box sneller werkt. Maar goed, wat let je om een snellere implementatie te schrijven en daarvan gebruik te maken in jouw favo taal? Maar als je dat doet kun je niet zeggen dat die taal daarom sneller is

Daar heb je een punt, je meet de taal niet maar de configuratie. Maar over het algemeen is het 'LAMP' tegenover IIS+ASP+Access/MSSQL. En daar lijkt het mij op te gaan, als iemand in php programmeert ga je me niet vertellen dat 'ie nog nooit van MySQL heeft gehoord.

[..]

Dit zal niet veel anders zijn dan de gewone (locale) variabele die je gebruikt in je scripts/programma's. In oScript worden alle globale variabelen van externe functies gewoon gemapped in de globale context, net als dat je een globale variabele zou declareren in het script. In PHP is het gebruik van $_GLOBAL ook gewoon het gebruik van 'een array', en in ASP waarschijnlijk gewoon het gebruik van een Object.

Ook dit is per taal verschillend, niet elke taal zal hetzelfde met variabelen omgaan, een taal heeft een bepaalde beperking qua gebruik van variabelen. Natuurlijk is het onrealistisch om 10k aan variabelen te hebben (en dus niet in een array), maar het is wel handig om te zien wat de effecten zijn en dan vooral ook op de server. Omdat je met zulke grote aantallen werkt zullen de verschillen ook veel duidelijker zijn.

Overigens moet een dergelijke test wel op hetzelfde systeem worden gedaan. Ik ga de test zoals ik hier boven beschreef zelf uitproberen maar dan alleen 'php' tegen 'asp'.

[Verwijderd]

Zo... pff... wat een reacties
Sorry voor mijn late reactie, maar ik heb het de laatste tijd erg druk gehad en heb nu weer tijd gehad om alles te lezen en zelf wat te posten.

1e bericht
Als eerste zal ik een reactie geven op m'n post en de reacties hierop. Om te beginnen was de quote aan het begin van m'n bericht misschien niet goed. Het kan op meerdere manieren opgevat worden, maar wat bedoeld wordt is dat je in PHP gewoon fatsoenlijk OO kunt programmeren, zoals in b.v. Java.

Sommige dingen die ik noemde, zoals b.v. parameter meganisme, waren niet negatief over de taal. Het was ook niet de bedoeling om de taal zoveel mogelijk te bekritiseren. Maar meer om mijn mening over de taal op tafel te zetten en jullie over mijn ervaringen ermee te vertellen. (zodat jullie er wat aan hebben)

Met slechte functienamen bedoelde ik de functienamen die PHP aanbiedt. De naamgeving van deze functies vind ik erg slecht.

Voor de duidelijkheid. Ik heb het dus niet over dat PHP OO ondersteunt, maar eigenlijk meer over hoe goed hij deze ondersteunt. Dus of PHP genoeg features ondersteunt. En over wat genoeg is ga ik niet discussieren. Het is naar mijn mening te weinig.

Snel programmeren, Performance
Is dat belangrijk? Mijn ervaring in het bedrijfsleven is dat dit helemaal NIETS uitmaakt. Het is nu namelijk veel goedkoper om duurdere hardware te kopen dan software te optimalizeren of een snelle taal te gebruiken. De snelheid moet natuurlijk wel acceptabel blijven, maar of het nu 22 of 20 ms is... dat maakt geen kont uit.

Net als het snel kunnen programmeren van code. Het is absoluut NIET belangrijk dat code snel ingeklopt kan worden, of dat het wat langer duurt. Het moet natuurlijk niet extreem zijn, maar dan zou een taal niet bestaan. Why? Het is algemeen bekend dat bij het ontwikkelen van software 80% van de manuren besteed wordt aan testen en onderhoud van een applicatie en 20% aan het ontwikkelen van de applicatie (Analyse, Ontwerp, Implementatie, enz.). Het is veel handiger om het onderhoud en het testen te versnellen. Het lijkt me dan ook handig dat replys over performance in een nieuwe/andere post komen.

Onderhoud
Onderhoud wordt nog lastiger als je met teams werkt, wat in het bedrijfsleven erg veel voorkomt. Wel eens een bug in de software van een oudcollega mogen oplossen? Onderhoud is dus belangrijk, maar hoe kun je de tijd die hiervoor gebruikt wordt verkorten?

Debuggen, dit heb ik in m'n 1e bericht ook al genoemd en herhaal ik voor de duidelijkheid maar even.

Private variabelen. Dit heb ik in m'n 1e bericht ook gepost, maar er zijn reacties hierop gekomen. De programmeur zou zich er maar gewoon netjes aan moeten houden. Dit is makkelijker gezegd dan gedaan, vooral als je in teamverband werkt. Programmeurs hebben vaak de neiging om snel iets uit te programmeren. Het rechtstreeks aanroepen van instance variabelen komt hier erg handig van pas

Zo heb je ook nog: Interfaces, Strong typing, Systeem documentatie, enz... Maar daar hebben we er al genoeg van gehoord. Naar mijn mening is PHP geen onderhoudsvriendelijke taal en gaat in het onderhouden van software veel meer tijd zitten dan in sommige andere talen.

Waarom is PHP dan populair?
Daar heb ik een vrij simpel antwoord op. "Het is simpel" Dit heeft het voordeel dat het implementeren veel sneller gaat, maar het onderhouden dus veel langer duurt. Een aantal berichten terug las ik het advies, dat je een taal moet gebruiken, die geschikt is voor waar je mee bezig bent. PHP lijkt me dan een erg goede taal voor "throwaway prototyping" en zoals gezegd voor kleine projecten.

[djc]

Verwijderd schreef op 06 februari 2003 @ 20:26:
Met slechte functienamen bedoelde ik de functienamen die PHP aanbiedt. De naamgeving van deze functies vind ik erg slecht.

Voor de duidelijkheid. Ik heb het dus niet over dat PHP OO ondersteunt, maar eigenlijk meer over hoe goed hij deze ondersteunt. Dus of PHP genoeg features ondersteunt. En over wat genoeg is ga ik niet discussieren. Het is naar mijn mening te weinig.

Met het eerste punt ben ik het eens, maar er is weinig enthousiasme om er iets aan te doen, omdat iedereen er al gewend aan is. Jammer, maar helaas. Wat je tweede punt betreft, daar ben ik het mee eens, en voor PHP 5 (geschat stable in augustus 2003) zijn er grote uitbreidingen op dit punt. Dingen als public, protected en private komen er dan in, objecten worden standaard als reference doorgegeven, en meer van die dingen. Daar komt dus verbetering in.

Verwijderd schreef op 06 februari 2003 @ 20:26:
Net als het snel kunnen programmeren van code. Het is absoluut NIET belangrijk dat code snel ingeklopt kan worden, of dat het wat langer duurt. Het moet natuurlijk niet extreem zijn, maar dan zou een taal niet bestaan. Why? Het is algemeen bekend dat bij het ontwikkelen van software 80% van de manuren besteed wordt aan testen en onderhoud van een applicatie en 20% aan het ontwikkelen van de applicatie (Analyse, Ontwerp, Implementatie, enz.). Het is veel handiger om het onderhoud en het testen te versnellen. Het lijkt me dan ook handig dat replys over performance in een nieuwe/andere post komen.

Dat is nu juist het punt. PHP wordt (meestal) niet gebruikt voor dat soort software. Er zijn uitzonderingen (zoals React), maar daarbij wordt zorgvuldig gepland, een uitgebreid framework bedacht, enzovoort. De meeste gebruikers ontwikkelen in PHP meer een beetje zoals shell scripting voor het web. Het is gewoon een krachtig (hoewel enigszins beperkt, misschien) taaltje om van die kleine dingetjes mee te doen, wat simpele queries in een DB te gooien, wat klooien met XML, dat soort dingen. Daar is PHP voor. En daar is het *zeer* geschikt voor.

Verwijderd schreef op 06 februari 2003 @ 20:26:
Zo heb je ook nog: Interfaces, Strong typing, Systeem documentatie, enz... Maar daar hebben we er al genoeg van gehoord. Naar mijn mening is PHP geen onderhoudsvriendelijke taal en gaat in het onderhouden van software veel meer tijd zitten dan in sommige andere talen.

Ik denk dat dat een van de voornaamste minpunten van PHP is: het is inderdaad *erg* onderhoudsonvriendelijk. Het enige wat je daaraan kunt doen is een framework maken met extra functionaliteit, en duidelijke afspraken maken met collega-devvers.

Verwijderd schreef op 06 februari 2003 @ 20:26:
Daar heb ik een vrij simpel antwoord op. "Het is simpel" Dit heeft het voordeel dat het implementeren veel sneller gaat, maar het onderhouden dus veel langer duurt. Een aantal berichten terug las ik het advies, dat je een taal moet gebruiken, die geschikt is voor waar je mee bezig bent. PHP lijkt me dan een erg goede taal voor "throwaway prototyping" en zoals gezegd voor kleine projecten.

Precies. Alleen is de drempel naar (bijvoorbeeld) JSP/Java nog best groot, ook omdat het maar bij weinig hosting-providers is geinstalleerd. Dan zit je dus ineens in een heel ander segment. Daarom wordt PHP iets te veel gebruikt voor wat grotere projecten, waar iets als Java misschien wel geschikter zou zijn.