[Server-side scripting] PHP of JSP?

[DZHAW]

Welke taal is beter?

Ik heb begrepen dat JSP meer mogelijkheden biedt, maar dat PHP makkelijker/sneller is als je maar iets kleins wilt programeren.

Als je al ervaring met java hebt, is het dan een kleine stap naar JSP?

[Klaas B.]

DZHAW schreef op 23-06-2007 @ 21:46 :
Welke taal is beter?

Ik heb begrepen dat JSP meer mogelijkheden biedt, maar dat PHP makkelijker/sneller is als je maar iets kleins wilt programeren.

Als je al ervaring met java hebt, is het dan een kleine stap naar JSP?

Ik werk zelf heel veel met JSP, maar ook wel met PHP.

Je moet sowieso in het begin beseffen dat JSP een presentatietaal is. Het is niet de bedoeling dat je bussiness logic in JSP gaat schrijven. Met JSP presenteer je gegevens die je hebt verkregen via Servlets/Beans, databaseconnectie met JSP is wel mogelijk, maar niet aan te raden.

Het mooie van JAVA als technologie, is dat het veel kansen biedt tot schoon programmeren en het werken in lagen. Om hier een voorbeeld van te geven:
Je wilt een uploadsysteem maken, gebruikmakende van JAVA-technologieën. Je schrijft een uploadformulier met HTML in een JSP-pagina. (Waar je in dit geval JSP voor nodig zou kunnen hebben, is een simpele include waarmee je bepaalt of de user wel toegang tot de pagina heeft.) Met het formulier upload je naar je UploadServlet.
Het Servlet, met de gegevens uit de JSP-pagina, zorgt voor het uploaden van het formulier. Vervolgens stuurt het servlet de informatie die in de database moet door naar een JavaBean (een apart 're-usable' softwarecomponent). De JavaBean legt de databaseconnectie, gooit het in de database, en retourneert (bijvoorbeeld) een boolean (gelukt/niet gelukt). Dat gaat direct naar de JSP-pagina, of eerst via de Servlet.
In het eerste geval stuurt de Bean direct de boolean door naar de JSP-pagina, waarmee je een melding kunt weergeven. 'Het uploaden is gelukt.' Komt er echter véél meer informatie uit die Bean, zou je kunnen besluiten om je if/else-logic via je Servlet te gooien. De uit de if/else-statements overgebleven gegevens stuur je vervolgens door naar je JSP-pagina, die het op de gewenste wijze presenteert.

Het voordeel van dit model, dus de splitsing in lagen (presentation, business logic, database logic) is de effectiviteit ervan. De code waarmee je (front-end) werkt blijft zeer compact, waardoor je nooit het overzicht verliest. Mechanismen (zoals uploaden) stop je gewoon in een Servlet, en met de Bean maak je contact met de database. Omdat de funcationaliteit van de Bean niet specifiek is, kun je één Bean voor heel veel verschillende doeleinden gebruiken. Je kunt bijvoorbeeld via je Servlet een SQL-query doorgeven, afhankelijk van de input in de JSP-pagina. Die SQL-query stuurt de Bean naar de database, en vervolgens zorg je met getters en setters (in een aparte klasse, bijvoorbeeld) dat het weer teruggaat richting de client.
Wat ik hiermee wil zeggen, is dat de Bean dus voor allerhande zaken gebruikt kan worden. Als je in JSP-pagina's contact gaat maken met de database, heb je ELKE keer weer connectietoestanden nodig. Dit is niet alleen minder (of verminderd) veilig, maar ook inconsequent en zou vallen onder codeduplicatie.
Bovenstaande manier is dus veel efficiënter.

Deze manier is uitzonderlijk snel voor hele grote applicaties. Mocht er iets in de databasestructuur veranderen, pas je louter één Bean aan, en alles draait weer.

De stap van JAVA naar JSP is in principe klein, zolang je je maar aan bovenstaande principes houdt. Je loopt wel tegen veel problemen aan, zeker omdat je voor het werken met Beans ook JSTL nodighebt; JavaServerPages Standard Tag Library. Wat deze techniek precies inhoudt moet je maar even googlen, maar hiermee kun je bijvoorbeeld Custom Tags schrijven waar je volledige, externe functies met één regel kunt aanroepen.



Wat de voordeel van JSP ten opzichte van PHP is, is natuurlijk vrij lastig te zeggen. Sowieso laat PHP qua performance nog wel eens te wensen over, maar als je een simpel iets wilt maken kan PHP wel beter van pas komen. Als echter dingen als veiligheid belangrijk worden, zou ik eerder voor JAVA kiezen dan voor PHP, ook al zeggen alle PHP-freaks dat 'PHP net zo veilig is als je het programmeert'. Daarnaast heb ik de ongenuanceerde opvatting dat PHP een uit de hand gelopen hobby is, met vele gaten en onlogische, inconsequente zaken waar ik persoonlijk nooit voor had gekozen. Ik heb sowieso een hekel aan weaktyped talen, en niet alleen omdat het performance kost, maar ook omdat puur inconsequent is.

Voor als je voor het web met JAVA wilt werken, raad ik je sterk Eclipse Lomboz als IDE en JoNAS als webserver aan. Deze opensourceprogramma's werken uitstekend in combinatie met elkaar. Zorg wél voor de nieuwste versies van J2SE en J2EE.

Ik heb onlangs voor school een voorstel met betrekking tot softwareaanpassing op het gebied van JAVA gedaan. Dat post ik hieronder wel, maar het kan zijn dat er dingen tussen staan die specifiek voor de school geschreven zijn, daar moet je dan maar even overheen lezen.

Er zijn talloze voordelen te noemen als het gaat om het werken met Eclipse.


Voordelen Eclipse

- Je kunt zelf de map kiezen waarin de JAVA-bestanden worden opgeslagen. Lees: het is niet meer nodig de bestanden in de ROOT- of WEB-INF-map van de server te plaatsen.
- Er zitten zeer uitgebreide debugfuncties in. Naast het aangeven van errors, worden er ook warnings gegeven, dus aandachtspunten die de server niet zal interpreteren alszijnde error. (Voorbeeld: het gebruik van getValue om een variabele uit een sessieobject te halen. Dit is verouderd en zal in de toekomst niet meer te gebruiken zijn, dit wordt aangegeven door Eclipse.)
- Het werkt efficiënt omdat er je geen aparte browser nodighebt. InternetExplorer wordt automatisch geïmplementeerd, dus wanneer je een JSP-pagina wilt weergeven, wordt het automatisch gecompileerd en binnen Eclipse weergegeven.
- Het kan extreem veel typwerk schelen. Ik schreef laatst een klasse waarin ik talloze variabelen declareerde, die ik via een Bean zou doorgeven aan m’n JSP-pagina. Vanzelfsprekend gebruik je ‘private String’ zus, of ‘private int’ zo, maar om het daadwerkelijk te gebruiken heb je getters en setters nodig. *
- In de Project Explorer van Eclipse wordt het project waarmee je bezig bent schematisch weergegeven, zoals bij Windows Verkennen. Hierbij worden de webgebaseerde bestanden onderelkaar gezet (of in mappen, net hoe je het zelf indeelt) en hetzelfde gebeurt met de Beans of andere klasses. Verder heb je in de Project Explorer een duidelijk overzicht van alle packages die je hebt geïmporteerd in het project, zoals ‘jstl.jar’ en ‘standard.jar’ voor het gebruik van JSTL om gegevens uit Beans te halen.
- Als je binnen Eclipse een Bean of andere klasse aanmaakt, worden automatisch de packagemappen aangemaakt. Oftewel: als je als package ‘i2c2.51588.robin.opdracht1’ hebt ingevoerd, maakt hij automatisch de mappen i2c2, 51588 (etc.) aan, met de daarbijbehorende map ‘classes’ en de andere benodigde bestanden. Zonder Eclipse zou je de mappen handmatig moeten aanmaken, hetgeen al snel onoverzichtelijk wordt. Zeker als je dan ook nog zelf moet compileren en de .class-bestanden in de juiste map moet zetten.
- Eclipse kun je zien als het centrale gedeelte van je programmeerswerk. Je kunt er ordinair in programmeren, maar je importeert ook de server in de IDE zelf. Als Eclipse draait in combinatie met de geïnstalleerde server (waar ik later op terugkom) heb je nooit meer omkijken naar het functioneren van je server. De server kan gestart worden vanuit Eclipse. Het enige dat je daarvoor hoeft te doen is de server die geïnstalleerd is aan te klikken. Vervolgens voeg je de door jou gewenste projecten aan de server toe, de mappen worden in de CATALINA_HOME (synoniem voor C:/JAVA/Server etc.) aangemaakt. Als je dit handmatig moet doen, is er een extreem grote kans dat de mappenstructuur onvolledig of onjuist is, waardoor het hele project niet meer draait.
- Compileren van JSP, Servlets, Beans en andere JAVA-applicaties gaat allemaal automatisch. Een simpele JAVA-applicatie kun je zonder IDE compileren met javac.exe uit het JDK-pakket, maar alleen in bepaalde gevallen. Zodra gebruik wordt gemaakt van servlet.jar, servlet-2_4.jar of servlet-api.jar (met de klassen die nodigzijn om Beans te laten samenwerken met JSP-pagina’s e.d.) kan JDK het niet meer, omdat daar die package niet bij zit. In Eclipse echter, kun je zelf packages toevoegen (en verwijderen), waardoor Eclipse wel de benodigde packages heeft om het te compileren. Buiten dat hoef je het in dat geval ook niet meer te doen via cmd.
Het enige waar aan gedacht dient te worden, is de conflicten die kunnen ontstaan wanneer meerdere packages met dezelfde inhoud binnen Eclipse actief zijn. Onlangs had ik dit probleem met jstl.jar en standard.jar, de packages die het mogelijkmaken JSTL te gebruiken om verbinding te maken met een Bean. Deze packages mogen ALLEEN (!) in de WEB-INF/classes-map staan van het project zelf. Dit betekent, dat het alleen mag staan in, bijvoorbeeld, H:/51588/JSP32/Projecten/Opdracht1/WEB-INF/classes. Een andere locatie, zoals in een van de klassemappen op de server mag niet. Dit levert onverklaarbare errors op, het heeft vele programmeurs gedurende uren geteisterd.

Dit is enkel een greep uit de voordelen van Eclipse, daarnaast zijn er natuurlijk de details als het highlighten van variabelen, onderscheid tussen HTML en code, etc. Buiten dat is het handig dat Eclipse je informatie geeft over het stukje code waarop je met je muis staat.
Let overigens wel op, Lomboz is een soort plugin voor Eclipse, maar het volledige pakket is te downloaden. [http://forge.objectweb.org/projects/lomboz ]


JOnAS OpenSource Java EE Application Server

Ik heb me enigszins verbaasd over het feit dat we werken met Resin als applicatieserver. Ik ken geen enkele J2EE-developer die werkt met Resin – sterker nog: het gros heeft er nog nooit van gehoord. Op het forum van Sun ben ik nog nooit iemand tegengekomen die met deze server werkt. Dit hoeft geen ramp te zijn, maar gezien de leeftijd van de server en de minieme beschikbare informatie (en support) is het een slecht plan deze server nog langer te gebruiken.
Een welbekend alternatief is Tomcat (5.X). Deze server wordt door vrijwel iedereen gebruikt. JOnAS is hier een alternatief op, JOnAS is een op Tomcat 5.X-gebaseerde server, en werkt naadloos samen met het hierboven genoemde Eclipse. Sterker nog, Lomboz is van hetzelfde bedrijf (ObjectWeb) als JOnAS. Mocht er uiteindelijk besloten worden over te stappen op JOnAS ben ik wel bereid een tutorial te schrijven, het vereist wel een vrij nauwkeurige installatie.
Het is sowieso het best om vrijwel alles dat JAVA-gerelateerd is van de computers te verwijderen, je kunt namelijk niet zomaar nieuwe versies van JAVA op pc’s installeren als er nog oudere versies opstaan. Ik heb onlangs mijn computer volledig bevrijd van JAVA-versies die ik niet mee gebruikte, en ben overgebleven met de versies die je absoluut nodighebt. Dit is de nieuwste versie van J2EE en JSDK (respectievelijk Java 2 Enterprise Edition en Java Software Development Kit). Als deze geïnstalleerd zijn, staan er als het goed is 3 hoofdmappen waarin de benodigde JAVA-bestanden te vinden zijn. Dit zijn JDK1.5.0_11, JRE1.5.0_11 en SDK (Java Development Kit, Java Runtime Environment en Software Development Kit). Dat zijn de nieuwste versies op het moment van schrijven, tweedelig te downloaden vanaf de site van Sun.
Verder met de installatie van JOnAS: het enige dat ik daarover moet zeggen voor een echte tutorial te schrijven, is dat het geinstalleerd moet worden in een map waar geen spaties in voorkomen. Het kan dus niet worden geplaatst in Program Files, of Program Files/JAVA. In mijn geval staat het in C:/JavaServer.

De voordelen van het gebruiken van een nieuwe server moge duidelijk zijn. Niet alleen is het onmogelijk om Resin te importeren in Eclipse, ook is Resin niet capabel genoeg de benodigde handelingen te verrichten die nodigzijn voor de plannen van meneer Ubags met JSP32. Buiten dat staan Tomcat-gebaseerde servers beter te boek, als sneller en stabieler. De errorweergave is daarbij een stuk overzichtelijker. Dit komt het programmeren en debuggen alleen maar ten goede.

Conslusie

Bij het gebruik van Eclipse ObjectWeb Lomboz in combinatie met JOnAS als applicatieserver, is naadloze samenwerking tussen IDE en server gegarandeerd. Daarnaast is dat de enige (of een van de weinige) manieren om efficient te programmeren, zonder tussenkomst van allerlei handelingen als het aanmaken van mappen en het correct plaatsen van de bestanden. Het grootste voordeel voor ons als studenten, is dat het vanaf dan mogelijk is om serverside te programmeren zonder daarbij steeds de bestanden te hoeven kopieren en plakken van de servermap naar de netwerkmap.

[Rob]

Als je Java al kent, kun je JSP gebruiken. Maar er is wel een duidelijke splitsing tussen servlets (componenten die alle berekeningen voor je doet en antwoord terugstuurt) en de servlet pagina's waar je dingen invult en ontvangt van servlets.
De splitsing uit zich in het feit dat Servlets specifiek gemaakt zijn voor Java programmeurs en de JSP's (de pagina's voor de input en output) voor de webdevelopers. Om dat te bereiken, bestaan Servlets uit pure Java Code en de JSPs uit extra tags die op HTML lijken om het zo makkelijk mogelijk te maken voor de developers.

Het enige nadeel van Java en Tomcat, etc., vind ik het ingewikkelde opzetten ervan eer het werkt. Voor college had ik dus Tomcat draaien en ik kon de Servlet libraries niet gebruiken, ondanks dat de ClassPath variabele de verwijzing naar de JARs had. Alle webprojecten die ik wilde doen, moesten gecompiled worden met het -classpath variabele.

PHP vind ik wel prettig als het gaat om snel en simpel coden, zonder al teveel restricties en stricte controle (je bent niet verplicht het type van je variabele op te geven, bijvoorbeeld, noch hoef je te casten, geloof ik). En het is zeker makkelijker in het gebruik dan Java, als je het mij vraagt. Het nadeel ervan is dat de OO-functionaliteit niet zo goed is ontwikkelt als in Java en dat PHP zich, naar mijn mening, meer leent voor procedureel programmeren.

Ligt er, naar mijn mening, een beetje aan wat je wilt gaan doen.

[Shems]

Dit gaat ver ..... mooi ! Ik neem aan dat jullie hier een opleiding in volgen of hebben gevolgd ? .... want ik begin me oud te voelen ineens. Ik draai sinds kort server 2003 en ik heb het os al een keer corrupt gemaakt toen ik vrolijk in me services vanalles ging veranderen omdat ik eerst een dns-server moest opzetten voordat ik de web-service kon draaien. Als ik begin te lezen over hoe het werkt met protocollen, servers, html, java dan verlies ik gauw de draad; allemaal afkortingen en termen die veel meer betekenen dan ik zo snel kan vatten. Dat heb ik nog nooit meegamaakt. Hoe een pc werkt begreep ik veel sneller. Is het hele netwerk gebeuren zo complex of ligt het aan mij ... ????

[freyk]

Goh, ik wist niet dat java ook een serverside scripttaal kon zijn
Want ik kende alleen maar javascripts, applets en javaapplicaties.

Shems schreef op 24-06-2007 @ 04:24 :
Is het hele netwerk gebeuren zo complex of ligt het aan mij ... ?

ja, het is zo complex zover je het wil hebben.
ja, het ligt ook aan jou, want de meeste hier hebben dit in hun vakkenpakket en/of hebben dit zichzelf aangeleerd.
Tip: Als we met moeilijke woorden gooien, zoek ze maar eens op met wikipedia.

[Klaas B.]

freyk schreef op 24-06-2007 @ 11:51 :
Goh, ik wist niet dat java ook een serverside scripttaal kon zijn
Want ik kende alleen maar javascripts,

Dat heeft niet zoveel met Java te maken.

[Shems]

ja, het is zo complex zover je het wil hebben.

----------------------------------------------------------

Ik had al het idee dat ik me ergens in moet specialiseren wat dat betreft of zou ik best een studieboek gebruiken ? Misschien dat dat veel georganiseerder is....

Goed om te weten dat het aan mij ligt... lol

Wellicht is ASP.NET 2.0 ook wel iets om wat mee te maken.

[Dr HenDre]

Talen vergelijken is imo echt appels met peren vergelijken, en daarnaast is het zo subjectief als ik weet niet wat.
Persoonlijk vind ik weak typed talen juist heel fijn, waarom zou een variable alleen de type moeten hebben.
Verder is het onzin dat als een taal weak typed is, dat dat een significante impact heeft op de performance. Ik heb net even gegoogle naar benchmarks tussen php en jsp. php wint het over het algemeen van jsp, vooral als het op grote scripts aankomt.
En het feit dat je met jsp robustere code kan krijgen is onzin (denk ik ) waarom zou dat niet kunnen met php? Het is vanaf v5 volledig object georienteerd, ondersteunt zover ik weet alle mogelijkheden van het "normale" OOP.
Nu wil ik echter geen voorkeur uitspreken voor een van de twee talen, omdat dat helemaal persoonlijk is. En daarnaast is het afhankelijk van wat je er mee wil doen.

PHP is niet beter dan JSP, maar andersom ook niet.

[Klaas B.]

Dr HenDre schreef op 25-06-2007 @ 11:33 :
Talen vergelijken is imo echt appels met peren vergelijken, en daarnaast is het zo subjectief als ik weet niet wat.
Persoonlijk vind ik weak typed talen juist heel fijn, waarom zou een variable alleen de type moeten hebben.
Verder is het onzin dat als een taal weak typed is, dat dat een significante impact heeft op de performance. Ik heb net even gegoogle naar benchmarks tussen php en jsp. php wint het over het algemeen van jsp, vooral als het op grote scripts aankomt.
En het feit dat je met jsp robustere code kan krijgen is onzin (denk ik ) waarom zou dat niet kunnen met php? Het is vanaf v5 volledig object georienteerd, ondersteunt zover ik weet alle mogelijkheden van het "normale" OOP.
Nu wil ik echter geen voorkeur uitspreken voor een van de twee talen, omdat dat helemaal persoonlijk is. En daarnaast is het afhankelijk van wat je er mee wil doen.

PHP is niet beter dan JSP, maar andersom ook niet.

Dit bericht is echt om te huilen.

[Chimera]

Als je later professioneel nogs iets aan je kennis wil hebben zou ik zeker met Java gaan doen. Er is veel meer vraag naar Java en .Net developers, en die worden ook nog eens beter betaald (tja, marktwerking) dan PHP programmeurs.

Shems schreef op 24-06-2007 @ 14:41 :

Ik had al het idee dat ik me ergens in moet specialiseren wat dat betreft of zou ik best een studieboek gebruiken ? Misschien dat dat veel georganiseerder is....

Ik raad je sowieso aan eerst eens gewoon wat in Java te gaan programmeren (je eerste "Hello world!" programmatje e.d.) voordat je met Servlets en JSP aan de slag gaat. Dat is toch een finke stap verder, en je zult eerst een beetje de basis moeten leren ontdekken.

Dr HenDre schreef op 25-06-2007 @ 11:33 :
Talen vergelijken is imo echt appels met peren vergelijken, en daarnaast is het zo subjectief als ik weet niet wat.
Persoonlijk vind ik weak typed talen juist heel fijn, waarom zou een variable alleen de type moeten hebben.

Omdat dat veel fouten scheelt en de compiler in staat stelt je vooraf te vertellen dat wat je wil bewerkstelligen niet gaat werken. je wordt gedwongen keuzes te maken.

Dr HenDre schreef op 25-06-2007 @ 11:33 :

Verder is het onzin dat als een taal weak typed is, dat dat een significante impact heeft op de performance. Ik heb net even gegoogle naar benchmarks tussen php en jsp. php wint het over het algemeen van jsp, vooral als het op grote scripts aankomt.

Hahaha. Wat een onzin. Ja, als je de startup tijd van een VM meerekent ja. Java/.Net applicatieservers zijn schaalbaar, PHP is dat niet. PHP is nooit opgezet als een serieus webdevplatform. Dat is ook de reden dat het tegenwoordig niet voor grote sites gebruikt wordt, het is .Net/Java wat de klok slaat. De 'grote' sites die nog op PHP werken/werkten zijn aan het migreren naar Java.

Dr HenDre schreef op 25-06-2007 @ 11:33 :

En het feit dat je met jsp robustere code kan krijgen is onzin (denk ik ) waarom zou dat niet kunnen met php? Het is vanaf v5 volledig object georienteerd, ondersteunt zover ik weet alle mogelijkheden van het "normale" OOP.

Je weet niet waar je het over hebt. PHP dwingt geen OO af, en is dus geen volledige OO taal. Dat je wat OO dingetjes kunt doen maakt het niet meer OO dan C++ is. En dat is tenminste nog type-safe.

Dr HenDre schreef op 25-06-2007 @ 11:33 :

Nu wil ik echter geen voorkeur uitspreken voor een van de twee talen, omdat dat helemaal persoonlijk is. En daarnaast is het afhankelijk van wat je er mee wil doen.

PHP is niet beter dan JSP, maar andersom ook niet.

Java en .Net zijn de enige serieuze platformen, met een reden. Ze zijn schaalbaar, snel, type-safe en hebben betere ontwikkelomgevingen en libraries.

[Klaas B.]

Hear hear.

[Manuzhai]

Oh God, de enterprise-jongens nemen het forum over!

Chimera schreef op 25-06-2007 @ 17:56 :
Omdat dat veel fouten scheelt en de compiler in staat stelt je vooraf te vertellen dat wat je wil bewerkstelligen niet gaat werken. je wordt gedwongen keuzes te maken.

Static typing geeft een false sense of security dat je de meeste fouten wel uit je software hebt gehaald als de code eenmaal compileert, terwijl een groot deel van je fouten gewoon in de logica zal zitten. Om echt zeker te zijn van een lage hoeveelheid fouten in je code zul je unit tests moeten inzetten. Unit testing kan zowel in statisch als in dynamisch getypeerde talen.

Chimera schreef op 25-06-2007 @ 17:56 :
Hahaha. Wat een onzin. Ja, als je de startup tijd van een VM meerekent ja. Java/.Net applicatieservers zijn schaalbaar, PHP is dat niet. PHP is nooit opgezet als een serieus webdevplatform. Dat is ook de reden dat het tegenwoordig niet voor grote sites gebruikt wordt, het is .Net/Java wat de klok slaat. De 'grote' sites die nog op PHP werken/werkten zijn aan het migreren naar Java.

Hahaha. Wat een onzin. PHP is schaalbaar en PHP is een serieus webdevplatform (hoewel het misschien in den beginne niet als zodanig is opgezet). De shared nothing-architectuur die PHP aanhangt wordt op steeds meer plaatsen gebruikt, en nog steeds worden veel grote sites in PHP ontwikkelt. Zie alleen al Gathering of Tweakers, een van de grootste fora op internet, dat volledig in PHP is ontwikkeld en vziw geen plannen heeft om over te stappen op Java. Zie ook WikiPedia en zijn onderliggende MediaWiki-software. Yahoo! gebruikt voor het grootste gedeelte van zijn sites PHP (een van de redenen dat ze de bedenker van PHP in dienst hebben).

Chimera schreef op 25-06-2007 @ 17:56 :
Je weet niet waar je het over hebt. PHP dwingt geen OO af, en is dus geen volledige OO taal. Dat je wat OO dingetjes kunt doen maakt het niet meer OO dan C++ is. En dat is tenminste nog type-safe.

Je weet niet waar je het over hebt. Java dwingt je in een OO-model, waar ook bijvoorbeeld functional programming en zelfs procedureel programmeren hun plaats hebben. In PHP 5 kun je prima object-oriented werken, al worden de ingebakken functies voor het overgrote deel niet in een OO-model aangeboden.

Chimera schreef op 25-06-2007 @ 17:56 :
Java en .Net zijn de enige serieuze platformen, met een reden. Ze zijn schaalbaar, snel, type-safe en hebben betere ontwikkelomgevingen en libraries.

Java en .NET zijn dik gehyped door respectievelijk Sun en Microsoft, maar ondertussen wordt er hard gewerkt aan het porten van dynamische talen naar beide run-times, zodat de ontwikkelaars niet meer met ouderwetse, onnodig restrictieve talen zoals Java en C# hoeven te werken. Sun betaalt nu de ontwikkelaars van JRuby, die Ruby naar de JVM brengen, terwijl Microsoft net de Dynamic Language Runtime, de DLR, heeft uitgebracht en op die manier IronRuby, IronPython, en nog meer dynamisch getypeerde talen gaat aanbieden.

Voor het overgrote deel van de toepassingen hebben de dynamisch getypeerde talen de toekomst.

[Chimera]

Manuzhai schreef op 26-06-2007 @ 09:36 :
Voor het overgrote deel van de toepassingen hebben de dynamisch getypeerde talen de toekomst.

Complete onzin.

Verder: als je serieus genomen wil worden raad ik je aan niet op een dergelijke kinderachtige manier te reageren. Ik neem aan dat je dat in een normale discussie ook niet doet? Als je een serieuze discussie aan wil gaan hoor ik het graag.

[Manuzhai]

Chimera schreef op 26-06-2007 @ 10:36 :
Verder: als je serieus genomen wil worden raad ik je aan niet op een dergelijke kinderachtige manier te reageren. Ik neem aan dat je dat in een normale discussie ook niet doet? Als je een serieuze discussie aan wil gaan hoor ik het graag.

Sorry? Ik heb het formaat gevolgd van jouw respons, en nu ben ik kinderachtig en jij serieus?

[Chimera]

Manuzhai schreef op 26-06-2007 @ 10:41 :
Sorry? Ik heb het formaat gevolgd van jouw respons, en nu ben ik kinderachtig en jij serieus?

Mensen napraten is iets wat kinderen op de basisschool doen. Als je met tegenargumenten komt spreken deze als het goed is voor zichzelf, dan hoef je je niet zo kinderachtig te gedragen.

[Manuzhai]

Chimera schreef op 26-06-2007 @ 11:19 :
Mensen napraten is iets wat kinderen op de basisschool doen. Als je met tegenargumenten komt spreken deze als het goed is voor zichzelf, dan hoef je je niet zo kinderachtig te gedragen.

Ik ben met tegenargumenten gekomen. Het punt was dat jouw manier van reageren sowieso nogal condescending was. Vind je "Hahaha. Wat een onzin." en "Je weet niet waar je het over hebt." wel een lekker volwassen manier van reageren op mensen? Kennelijk zie je dat alleen maar als iemand het tegenover jou doet.

[Chimera]

Manuzhai schreef op 26-06-2007 @ 11:59 :
Ik ben met tegenargumenten gekomen. Het punt was dat jouw manier van reageren sowieso nogal condescending was. Vind je "Hahaha. Wat een onzin." en "Je weet niet waar je het over hebt." wel een lekker volwassen manier van reageren op mensen? Kennelijk zie je dat alleen maar als iemand het tegenover jou doet.

Als iemand die geen kennis heeft van Java een vergelijking gaat maken tussen PHP en Java en met statements aankomt dat PHP 'sneller' is en 'volledig OO' is, is dat inderdaad onzin. Ik vind dat als je geen Java / Servlets / JSP ervaring hebt, je geen vergelijking kunt maken.

[Manuzhai]

Chimera schreef op 26-06-2007 @ 12:46 :
Als iemand die geen kennis heeft van Java een vergelijking gaat maken tussen PHP en Java en met statements aankomt dat PHP 'sneller' is en 'volledig OO' is, is dat inderdaad onzin. Ik vind dat als je geen Java / Servlets / JSP ervaring hebt, je geen vergelijking kunt maken.

Hij zegt aan de hand van benchmarks die hij gegoogled heeft dat PHP eruit komt als sneller dan JSP. Jij reageert daarop met "Hahaha. Wat een onzin." Vervolgens geef je een reden waarom dat niet zo zou zijn: "Ja, als je de startup tijd van een VM meerekent ja." Had je dan niet gewoon kunnen reageren met uitleggen dat die benchmarks niet representatief zijn, in plaats van zo bot reageren.

Hahaha. Wat een onzin.
Goed argument.

Ja, als je de startup tijd van een VM meerekent ja.
Oh, het is toch geen onzin, maar zij rekenen de startup-tijd van de VM mee en om duistere redenen is dat onterecht!

Java/.Net applicatieservers zijn schaalbaar, PHP is dat niet.
De shared nothing-architectuur van PHP is juist erg schaalbaar.

PHP is nooit opgezet als een serieus webdevplatform.
En PHP is de afgelopen 10 jaar precies hetzelfde gebleven, toch?

Dat is ook de reden dat het tegenwoordig niet voor grote sites gebruikt wordt, het is .Net/Java wat de klok slaat.
Yahoo!/GoT/Tweakers.net/WikiPedia en vele anderen gebruiken nog steeds PHP.

De 'grote' sites die nog op PHP werken/werkten zijn aan het migreren naar Java.
Behalve alle bovenstaande sites, en nog een paar duizend. Joomla en Drupal worden helemaal nooit meer ingezet!

Je weet niet waar je het over hebt.
Weer zo'n vriendelijke manier om je punt te maken.

PHP dwingt geen OO af, en is dus geen volledige OO taal.
Er zijn interfaces, inheritance, data hiding, abstracte klassen, constructors en destructors en een manier om, net als in Java, klassen te laden aan de hand van de naam. Ook het gebruik van design patterns wordt ondersteund. Je kan in PHP echter ook op een procedurele manier werken; DUS is het geen OO-taal?

Dat je wat OO dingetjes kunt doen maakt het niet meer OO dan C++ is.
Sinds wanneer is C++ niet object-oriented? Volgens mij heb jij nogal een vreemde definitie van object-oriented.

En dat is tenminste nog type-safe.
Ja, want als al je types kloppen moet je code wel correct zijn!!!!!11

[Klaas B.]

Leuk ook dat de topicstarter nog reageert.

[DZHAW]

Ik volg de discussie met groot interesse, echter kan ik zelf niet echt een zinvolle bijdrage leveren.

Ik ga me nu eerst verder verdiepen in Java. Die taal moet ik sowieso leren voor een vak. En ik denk dat ik dan gebruik ga maken van JSP.

[Manuzhai]

Klaas B. schreef op 29-06-2007 @ 07:30 :
Leuk ook dat de topicstarter nog reageert.

Jammer dat jij na die eerste inhoudelijke post niet meer inhoudelijk gereageerd hebt. Maar waarschijnlijk ben je het in vrijwel alles met Chimera eens?

[Droyd]

In PHP -kan- je nog steeds een framework (CakePHP,Zend...) zodat structuur afgedwongen wordt. Je wordt bijvoorbeeld er toe aangezet om op een OO manier te werken volgens de MVC architectuur, zodat je net zoals bij JSP, .NET... de programmeerlogica kan scheiden van de rest zodat je uiteindelijke webtoepassing onderhoudbaar is. Toch denk ik dat men in JSP doorgaands gestructureerder kan werken...

Je kan eigenlijk zowel in JSP als in PHP werken met frameworks die je bv helpen bij structuur, validatie van formulieren, AJAX, beveiliging etc...

Voor minder ervaren PHP ontwikkelaars is het vast moeilijker om een relatief veilige applicatie te schrijven. Door (bijvoorbeeld) gebruik te maken van specifieke functionaliteit van een framework kan je hier wel op in spelen.

Daar staat dan weer tegenover dat je in PHP meer controle hebt over welke HTML/Javascript er precies gerenderd wordt. In JSP (eigenlijk vooral .NET) is het soms erg moeilijk een site te ontwikkelen die echt crossbrowser is.

Bijvoorbeeld: JSP en .NET maken gebruik van soms ingewikkeldere "controls" die één geheel vormen (zoals datalijsten). Vaak is het niet mogelijk om exact zoals je wil te bepalen hoe deze datalijst werkt, en hoe ze gerenderd wordt XHTML, vooral als je nog eens gebruik maakt van paginering en sortering. In PHP render je deze tabel gewoon zelf. Door gebruik te maken van een framework zoals CakePHP kan je gebruik maken van sortering en paginering mogelijkheden die niet deel uitmaakt van een bepaalde control...en dat werkt (in dit specifiek geval) gewoon een stuk beter omdat je volledige controle hebt.

Of PHP sneller is dan JSP hangt nogal af van de situatie. Voor kleinere toepassingen zal het verschil echt wel te verwaarlozen zijn.

PHP code hoef je niet te compileren. Gewoon file opnieuw oploaden en klaar.

Ik lees dat je Java leert op school. Op zich zou je op basis daarvan kunnen beslissen om JSP te leren, al mag je niet vergeten dat onafhankelijk de manier van werken (JSP of niet) je vaak heel wat meer moet leren dan de programmeertaal alleen.

[Dr HenDre]

How ik heb weer een stukje gemist zie ik, maar ik zal eventjes kort op een aantal punten reageren.

1) Volledig OO betekent naar mijn interpretatie dat de taal alle functionaliteit/mogelijkheden van het OO programmeren ondersteunt. Of dat wel of niet afgedwongen wordt heeft dat, in mijn ogen, niks met volledigheid te maken.
En uit de reactie van Chimera maak ik op dat dat dus schijnbaar niet gangbare definitie is van 'volledig oo'.
Inhoudelijk: Waarom zou een, volgens jou, 'serieuze' taal OO moet áfdwingen? De programmeur moet kiezen of hij of zij zijn programma object georienteerd of sequentieel programmeert.

2) Ik weet niet hoe jsp werkt, en of de vm wordt gestart als de server start of bij iedere request. Maar omdat het opstarten van de VM constante tijd kost wil dat niet zeggen dat je dat niet moet meerekenen.
Zoals opgemerkt zal het verschil niet denerend groot zijn bij kleine toepassingen. Misschien dat JSP sneller is op grote schaal, maar is dat iets wat je mee wil nemen in hoe "goed" een webtaal is?
Ik vind van niet, want in 9 van de 10 gevallen dat een webtaal wordt gebruikt is het voor relatief simpele gevallen, en dan maakt het geen ruk uit.
Voor die ene keer dat jsp wel significant sneller is, maak er gebruik van. Mijn punt is dat het over het algemeen qua snelheid geen ruk boeit en dat dat dus geen reden is om php danwel jsp om die reden de voorkeur te geven.

[Klaas B.]

Dr HenDre schreef op 02-07-2007 @ 18:45 :
How ik heb weer een stukje gemist zie ik, maar ik zal eventjes kort op een aantal punten reageren.

1) Volledig OO betekent naar mijn interpretatie dat de taal alle functionaliteit/mogelijkheden van het OO programmeren ondersteunt. Of dat wel of niet afgedwongen wordt heeft dat, in mijn ogen, niks met volledigheid te maken.
En uit de reactie van Chimera maak ik op dat dat dus schijnbaar niet gangbare definitie is van 'volledig oo'.
Inhoudelijk: Waarom zou een, volgens jou, 'serieuze' taal OO moet áfdwingen? De programmeur moet kiezen of hij of zij zijn programma object georienteerd of sequentieel programmeert.

2) Ik weet niet hoe jsp werkt, en of de vm wordt gestart als de server start of bij iedere request. Maar omdat het opstarten van de VM constante tijd kost wil dat niet zeggen dat je dat niet moet meerekenen.
Zoals opgemerkt zal het verschil niet denerend groot zijn bij kleine toepassingen. Misschien dat JSP sneller is op grote schaal, maar is dat iets wat je mee wil nemen in hoe "goed" een webtaal is?
Ik vind van niet, want in 9 van de 10 gevallen dat een webtaal wordt gebruikt is het voor relatief simpele gevallen, en dan maakt het geen ruk uit.
Voor die ene keer dat jsp wel significant sneller is, maak er gebruik van. Mijn punt is dat het over het algemeen qua snelheid geen ruk boeit en dat dat dus geen reden is om php danwel jsp om die reden de voorkeur te geven.

Ben ik het niet helemaal met je eens.

Er is een aantal argumenten te verzinnen waarom je JSP boven PHP zou kunnen verkiezen. Er zou geen significant snelheidsverschil bestaan bij kleinere toepassingen - daar ben ik het helemaal mee eens. Het probleem is echter dat PHP wel prestatieproblemen oplevert bij grote en complexe webgebaseerde software. Vanuit dat oogpunt doorberedeneerd: het is wellicht rendabeler om JSP te leren, dan voor PHP te gaan. Mocht je naast normale websites ook grote applicaties (CPS/PPS/PMS, etc. etc. etc.) willen schrijven, komt JAVA (niet JSP) beter van pas.

Het aanhouden van MVC is in ieder geval met JAVA makkelijker, gezien de uitgebreide documentatie die wel beschikbaar is voor JAVA, maar niet voor PHP. De application programming interfaces van JAVA lijken me toch op veel punten beter dan bij PHP.

[Klaas B.]

Manuzhai schreef op 29-06-2007 @ 12:57 :
Jammer dat jij na die eerste inhoudelijke post niet meer inhoudelijk gereageerd hebt. Maar waarschijnlijk ben je het in vrijwel alles met Chimera eens?

Ik wist zo gauw niet op welk punt ik moest reageren.

Als het op snelheid aankomt ligt de bottleneck meestal bij het type database dat gebruikt wordt, denk ik, en niet bij de scripttaal. Bij veel sites worden er volgens mij namelijk vaak geen intensieve bewerkingen op databasegegevens uitgevoerd door de scripttaal zelf.

Verder kan je in PHP ook wel objectgeoriënteerd werken, zij het iets minder strikt. PHP 5 is trouwens weer een stuk strikter dan PHP 4.

Het is uiteindelijk natuurlijk aan jezelf om te bepalen hoe overzichtelijk je de code houdt.

Bij ons op de opleiding Informatica wordt vaak ook om JavaDoc gevraagd. Dit kun je natuurlijk ook in je PHP script zetten. Hierin kun je zoveel informatie kwijt over je code/parameters als je wilt.

Een bijkomend mogelijk voordeel van het gebruik van PHP is dat veel gratis hosting providers dit ondersteunen (hoewel men nog niet zo hard bezig is om PHP 4 door PHP 5 te vervangen ).

Verder ben ik al veel websites tegengekomen, waaronder bijvoorbeeld het populaire Hyves, die PHP gebruiken (op de extensies afgaande).

Los van JSP, vind ik client-side Java meestal erg irritant. Het duurt meestal een eeuwigheid voordat Java geladen wordt als ik op een website met een Java applet stuit. Aargh. Jammer, want ik vind het wel een elegante taal.

Als 'populaire' sites (zoals als Hyves) php gebruiken, is dat vaak omdat de site als hobbyproject is begonnen (dus gebruikt het php) en er niet (goed) is nagedacht over het ontwerp (wat ook wel te merken is aan de vele wijzigingen op Hyves). Dat ze nog steeds php gebruiken komt omdat het omschrijven van bestaande functionaliteit naar .NET / JSP zeer veel risico's met zich meebrengt en heel veel werk is. Ook worden alle 'tweaks' die zijn gedaan weer ongedaan gemaakt.

Afgaan op een extensie om te bepalen in wat voor taal iets iets gemaakt is trouwens niet zo handig, want Cool URIs don't change.

Droyd schreef op 02-07-2007 @ 16:36 :
Daar staat dan weer tegenover dat je in PHP meer controle hebt over welke HTML/Javascript er precies gerenderd wordt. In JSP (eigenlijk vooral .NET) is het soms erg moeilijk een site te ontwikkelen die echt crossbrowser is.

Zoiets wordt gewoon opgelost door patches e.d. uit te brengen zodat crossbrowser steeds beter ondersteund wordt.

Droyd schreef op 02-07-2007 @ 16:36 :
Bijvoorbeeld: JSP en .NET maken gebruik van soms ingewikkeldere "controls" die één geheel vormen (zoals datalijsten). Vaak is het niet mogelijk om exact zoals je wil te bepalen hoe deze datalijst werkt, en hoe ze gerenderd wordt XHTML, vooral als je nog eens gebruik maakt van paginering en sortering. In PHP render je deze tabel gewoon zelf. Door gebruik te maken van een framework zoals CakePHP kan je gebruik maken van sortering en paginering mogelijkheden die niet deel uitmaakt van een bepaalde control...en dat werkt (in dit specifiek geval) gewoon een stuk beter omdat je volledige controle hebt.

Anders ga je het wiel even opnieuw uitvinden met PHP. Waarom moet ik zelf code gaan schijven om een tabel met inhoud weer te kunnen geven? In .NET is het gewoon een kwestie van een datasource koppelen aan een DataGrid en je kunt, geheel visueel, diverse tabeleigenschappen zetten.
ASP.NET en JSP zijn voornamelijk voor RAD handig, zeker in samenhang met een goede IDE zoals Visual Studio 2005.

De standaard controls in .NET zijn te grote mate aan te passen. En doet het nog niet wat je wilt, kun je ook zelf dergelijke controls maken.

Droyd schreef op 02-07-2007 @ 16:36 :

Of PHP sneller is dan JSP hangt nogal af van de situatie. Voor kleinere toepassingen zal het verschil echt wel te verwaarlozen zijn.

PHP code hoef je niet te compileren. Gewoon file opnieuw oploaden en klaar.

Nee, iedere keer at runtime het bestand 'compileren' is handig... Voordeel van vooraf (of Just-In-Time) compileren is dat er veel betere optimalistatie kan plaatsvinden.

eddie schreef op 02-07-2007 @ 20:51 :
Als 'populaire' sites (zoals als Hyves) php gebruiken, is dat vaak omdat de site als hobbyproject is begonnen (dus gebruikt het php) en er niet (goed) is nagedacht over het ontwerp (wat ook wel te merken is aan de vele wijzigingen op Hyves). Dat ze nog steeds php gebruiken komt omdat het omschrijven van bestaande functionaliteit naar .NET / JSP zeer veel risico's met zich meebrengt en heel veel werk is. Ook worden alle 'tweaks' die zijn gedaan weer ongedaan gemaakt.

Afgaan op een extensie om te bepalen in wat voor taal iets iets gemaakt is trouwens niet zo handig, want Cool URIs don't change.

Zelf ben ik geneigd te zeggen dat ik niet zoveel inzicht in het ontwerp heb en dus moeilijk een oordeel kan vellen over de interne technische zaken.

Wel vind ik het resultaat van het ontwerp prima.

Zef heb ik trouwens ook niet zoveel van wijzigingen gemerkt, maar juist meer van toevoegingen. Wijzigingen in het resultaat van de website zeggen ook niet altijd iets over het ontwerp.

Als de code makkelijk te veranderen is wanneer er wijzigingen moeten worden gemaakt, dan kan dat een teken zijn van een goed ontwerp.

Of er veel veranderingen in de code gemaakt moeten worden om de veranderingen in het resultaat te krijgen, daar heb ik geen kennis over. Dus kan ik geen oordeel vellen over het ontwerp. Ik kan alleen naar het resultaat kijken.

Hoe het komt dat ze PHP gebruiken heb ik ze ook niet gevraagd, en kan ik dus ook niet weten. Wel, zo heb ik gezegd, vind ik het resultaat prima.

Verder weet ik ook niet hoe Hyves opgericht is. Maar dat iets begonnen is als een hobby wil nog niet zeggen dat het uitgroeit tot iets slechts, of dat de oorspronkelijke basis slecht was.

PHP is veelgebruikt, makkelijk te leren, je kan er objectgeörienteerd in programmeren en het zo overzichtelijk/gestructureerd houden als je wilt.

Ik heb nergens gelezen dat ze toch liever kiezen voor .NET of JSP...

eddie schreef op 02-07-2007 @ 20:51 :
Afgaan op een extensie om te bepalen in wat voor taal iets iets gemaakt is trouwens niet zo handig, want Cool URIs don't change.

Schrijf je dit over mij, of over Hyves?

Als deze opmerking voor mij bedoeld is snijdt deze opmerking geen hout. Ik zag namelijk een PHP extensie in de code en concludeerde daaruit dat er waarschijnlijk PHP gebruikt wordt (hoewel dit niet per se zo hoeft te zijn).

Als deze opmerking voor Hyves bedoeld is: die links waar ik het over heb zijn sowieso al links die een zoekmachine niet indexeert. Veel links op Hyves zijn zonder extensie.

Bovendien heeft dit niks met de PHP scripttaal te maken.

[Chimera]

Manuzhai schreef op 26-06-2007 @ 13:25 :

Oh, het is toch geen onzin, maar zij rekenen de startup-tijd van de VM mee en om duistere redenen is dat onterecht!

Nou, duh. Aangezien binnen een applicatieserver echt niet voor elke request een VM gestart wordt, doet de startup tijd van een VM er gewoon niet toe. Java bytecode hoeft echt niet voor iedere request opnieuw geinterpreteerd te worden.

Manuzhai schreef op 26-06-2007 @ 13:25 :

De shared nothing-architectuur van PHP is juist erg schaalbaar.

Uhuh, daarom hebben Hyves en Fok! ook geen performance problemen.

Manuzhai schreef op 26-06-2007 @ 13:25 :

En PHP is de afgelopen 10 jaar precies hetzelfde gebleven, toch?

PHP is begonnen als hobby project. Een scripttaaltje, totaal procedureel, en daarbovenop is een OO laagje gemaakt. Voor de rest is er vrij weinig aan veranderd.

Manuzhai schreef op 26-06-2007 @ 13:25 :

Yahoo!/GoT/Tweakers.net/WikiPedia en vele anderen gebruiken nog steeds PHP.

Joh, enig idee hoeveel geld het kost om zo iets om te bouwen naar Java of .Net? De reden dat die sites nog po PHP draaien is puur historisch. Pas op het moment dat er een complete overhaul gedaan wordt, wordt een rewrite overwogen. Dat is namelijk ERG duur.

Manuzhai schreef op 26-06-2007 @ 13:25 :

Behalve alle bovenstaande sites, en nog een paar duizend. Joomla en Drupal worden helemaal nooit meer ingezet!

So? Omdat sites historisch PHP gebaseerd zijn, en de bedrijven daarachter niet het geld willen spenderen aan een migratie, is PHP dus een serieuze speler? Als je naar de markt kijkt, zie je dat alle grote spelers (Accenture, Logica, Cap, EDS) alleen in Java en .Net nieuwe projecten doen.

Manuzhai schreef op 26-06-2007 @ 13:25 :

Er zijn interfaces, inheritance, data hiding, abstracte klassen, constructors en destructors en een manier om, net als in Java, klassen te laden aan de hand van de naam. Ook het gebruik van design patterns wordt ondersteund. Je kan in PHP echter ook op een procedurele manier werken; DUS is het geen OO-taal?

PHP is net zoals C een procedurele taal. Die OO laag is leuk, maar het levert, vooral aangezien de API nog compleet procedureel is, gewoon een rotzooi op. Dankzei die rotzooi worden dergelijke applicaties snel rommelig.

Manuzhai schreef op 26-06-2007 @ 13:25 :

Sinds wanneer is C++ niet object-oriented? Volgens mij heb jij nogal een vreemde definitie van object-oriented.

Een taal is pas OO als het OO princiepes afdwingt.

Manuzhai schreef op 26-06-2007 @ 13:25 :

Ja, want als al je types kloppen moet je code wel correct zijn!!!!!11

Doe niet zo kinderachtig.

[Chimera]

Droyd schreef op 02-07-2007 @ 16:36 :
Daar staat dan weer tegenover dat je in PHP meer controle hebt over welke HTML/Javascript er precies gerenderd wordt. In JSP (eigenlijk vooral .NET) is het soms erg moeilijk een site te ontwikkelen die echt crossbrowser is.

Response.Write("<html><head><title>MyFirstSite</title></head></html>");

Je haalt de web forms API en de .net webapplicatiestructuur doormekaar. Het is volslagen onzin dat JSP of .Net invloed hebben op of je site al dan niet crossbrowser is.

Droyd schreef op 02-07-2007 @ 16:36 :

Bijvoorbeeld: JSP en .NET maken gebruik van soms ingewikkeldere "controls" die één geheel vormen (zoals datalijsten). Vaak is het niet mogelijk om exact zoals je wil te bepalen hoe deze datalijst werkt, en hoe ze gerenderd wordt XHTML, vooral als je nog eens gebruik maakt van paginering en sortering. In PHP render je deze tabel gewoon zelf. Door gebruik te maken van een framework zoals CakePHP kan je gebruik maken van sortering en paginering mogelijkheden die niet deel uitmaakt van een bepaalde control...en dat werkt (in dit specifiek geval) gewoon een stuk beter omdat je volledige controle hebt.

My god. De reden dat die controls er voor je zijn is om je tijd te besparen. Als je alles zelf wil doen kan dat in .Net net zo goed, je kunt ook daar helemaal prima zelf HTML outputten.

[Chimera]

Dr HenDre schreef op 02-07-2007 @ 18:45 :

Inhoudelijk: Waarom zou een, volgens jou, 'serieuze' taal OO moet áfdwingen? De programmeur moet kiezen of hij of zij zijn programma object georienteerd of sequentieel programmeert.

Sequentieel programmeren, da's een nieuwe! Ik neem aan dat je procedureel bedoelt.

Dr HenDre schreef op 02-07-2007 @ 18:45 :

2) Ik weet niet hoe jsp werkt, en of de vm wordt gestart als de server start of bij iedere request. Maar omdat het opstarten van de VM constante tijd kost wil dat niet zeggen dat je dat niet moet meerekenen.

Aangezien in een normale omgeving een VM blijft draaien moet je die tijd niet meerekenen nee. En er zijn altijd voorbeelden te bedenken waar een bepaalde omgeving er beter uitspringt dan anderen. Er zijn voorbeelden van Java code die sneller zijn dan C++/

Dr HenDre schreef op 02-07-2007 @ 18:45 :

Voor die ene keer dat jsp wel significant sneller is, maak er gebruik van. Mijn punt is dat het over het algemeen qua snelheid geen ruk boeit en dat dat dus geen reden is om php danwel jsp om die reden de voorkeur te geven.

Het punt was dat PHP geen grote toekomst heeft. Het wordt gewoon niet als serieus ontwikkelplatform gezien. De grote spelers gaan allemaal naar .Net en Java (en vooral .Net is enorm in opkomst, MicroSoft is goed bezig). Kleinere webdesignbedrijfjes beginnen vaak in PHP omdat je daar makkelijker goedkope programmeurs in vindt.

[Droyd]

Chimera schreef op 03-07-2007 @ 11:10 :
My god. De reden dat die controls er voor je zijn is om je tijd te besparen.

Of verliezen, als je iets niet exact kan doen werken zoals je wilt.

In sommige gevallen moet je effectief overerven van een bestaande control en dat vind ik best lastig omdat je soms niet weet wat de beste aanpak is in bepaalde situaties. Je moet best kennis hebben van de ASP.NET/JSP lifecycle om op een correcte manier eigen (ingewikkeldere, zoals varianten op datalists en datagrids) controls te schrijven...of er van over te erven, terwijl je in PHP (soms!) hetzelfde kan verkrijgen op een gemakkelijkere manier.

Zelf html outputten op de response.write manier vind ik dan min of meer in strijd met de structuur die .NET en JSP oplegt.

Maar ok, het gaat wel over specifieke gevallen dan.

Chimera schreef op 03-07-2007 @ 11:10 :

Het is volslagen onzin dat JSP of .Net invloed hebben op of je site al dan niet crossbrowser is.

Ik heb me een beetje fout uitgedrukt. Al gebeurt het tegenwoordig slechts zelden dat controls in .NET en JSP niet crossbrowser zaken outputten kan het wel dat valid XHTML/javascript niet volledig rendert/werkt zoals het moet in alle browsers. Mogelijk is de werking van een control aanpassen de enige oplossing, en dat kan lastig zijn.

Chimera schreef op 03-07-2007 @ 11:16 :
Het punt was dat PHP geen grote toekomst heeft. Het wordt gewoon niet als serieus ontwikkelplatform gezien.

Dat merk ik ook ja, al vind ik het wel bruikbaar voor kleinere projecten, vooral door de doorgaands goedkopere hosting. Het is niet dat ik een doorslaggevende voorkeur heb voor een bepaalde technologie (JSP, .NET, PHP...)

[Droyd]

eddie schreef op 02-07-2007 @ 21:09 :
Nee, iedere keer at runtime het bestand 'compileren' is handig... Voordeel van vooraf (of Just-In-Time) compileren is dat er veel betere optimalistatie kan plaatsvinden.

Ik had het ook niet op JIT compilatie. (is in het geval van PHP ook nooit van toepassing dacht ik) Ik bedoelde dat bij codewijzigingen de desbetreffende code opnieuw moet worden gecompileerd, terwijl men in PHP het gewijzigde php bestand gewoon opnieuw upload.

Min of meer afgezien daarvan: Ik dacht dat PHP code tegenwoordig wel gecompileerd -kan- worden, al is het niet echt gebruikelijk.

Uiteindelijk gaat het nog steeds om de effectieve performance, en ik denk dat niet PHP op dat vlak onderdoet ten opzichte van haar alternatieven...al is het misschien minder geschikt voor grotere sites ten opzichte van JSP/ASP.NET omwille van gebrek aan structuur wat grotendeels te wijten is aan de taal op zich.

Vette discussie, het lijkt The Daily WTF wel Volgens mij leest de TS het allang allang niet meer.

Droyd, het maken van eigen custom controls die precies datgene renderen wat je wil is een fluitje van een cent. Ingebakken controls dienen juist voor het gemak en om de ontwikkelcyclus te versnellen. Als je ze niet wil gebruiken gebruik je ze niet, maar het is geen reden om .NET af te kraken, want in PHP heb je zulke dingen uberhaubt niet.

[Manuzhai]

Chimera schreef op 03-07-2007 @ 11:16 :
Sequentieel programmeren, da's een nieuwe! Ik neem aan dat je procedureel bedoelt.

Maar je geeft geen antwoord op de vraag.

Pfff, belachelijk veel tekst hier zeg. Het antwoord is simpelweg right tool for the right job. Het feit dat je twijfelt tussen PHP en JSP (dat ongeveer hetzelfde is als twijfelen tussen een tafelpoot en een ijsschaats) doet me vermoeden dat je nog niet veel kaas hebt gegeten van dit gebeuren. En juist daarom zou ik zeggen, geen van beide. Welke dan wel? Ruby en Rails natuurlijk.

[DZHAW]

eXo schreef op 12-07-2007 @ 13:18 :
Vette discussie, het lijkt The Daily WTF wel Volgens mij leest de TS het allang allang niet meer.

Niet zo voorbarig

[Manuzhai]

Nigo schreef op 13-07-2007 @ 03:14 :
Pfff, belachelijk veel tekst hier zeg. Het antwoord is simpelweg right tool for the right job. Het feit dat je twijfelt tussen PHP en JSP (dat ongeveer hetzelfde is als twijfelen tussen een tafelpoot en een ijsschaats) doet me vermoeden dat je nog niet veel kaas hebt gegeten van dit gebeuren. En juist daarom zou ik zeggen, geen van beide. Welke dan wel? Ruby en Rails natuurlijk.

[Chimera]

Nigo schreef op 13-07-2007 @ 03:14 :
Pfff, belachelijk veel tekst hier zeg. Het antwoord is simpelweg right tool for the right job. Het feit dat je twijfelt tussen PHP en JSP (dat ongeveer hetzelfde is als twijfelen tussen een tafelpoot en een ijsschaats) doet me vermoeden dat je nog niet veel kaas hebt gegeten van dit gebeuren. En juist daarom zou ik zeggen, geen van beide. Welke dan wel? Ruby en Rails natuurlijk.

Integenstelling tot jou beargumenteren we onze posts tenminste.

Chimera schreef op 14-07-2007 @ 16:19 :
Integenstelling tot jou beargumenteren we onze posts tenminste.

Trust me, I'm a doctor volstaat niet?

Nah gut, itt jullie zal ik het eens kort houden: ruby is een dynamische taal die geheel object georienteerd is. Dat dynamisch zijn itt statisch heeft voor en nadelen, het is maar net wat je smaak is, daar kun je echt uren over blijven discussieren. Right tool for the right job is voor mij nog steeds de beslissende factor voor wanneer ik iets gebruik.

Alle voordelen genoemd in dit topic over OO (voor zover ze kloppen) gaan ook op voor Ruby. Rails zorgt ervoor dat je voor webdev een raamwerk hebt die meteen out of the box via het Model View Controller (MVC) design pattern werkt. Daarbij krijg je ook Object Relational mapping via ActiveRecords als persistance layer en zijn veel zaken als database veranderingen elegant opgelost via migrations, hierdoor kan je binnen enkele seconden van de ene naar de andere database opzet migreren.

Ook heeft men rekening gehouden met de diverse stadia waarin je je app zult ontwikkelen, namelijk development, test en production environment. De benodigde testframeworks zijn hier ook voor aangeleverd. Dit is getrouw aan de de facto standaard van dingen opbouwen.

Voorheen was ik J2EE/ASP.net 2 + C#'er, maar na dit geprobeerd te hebben krijg je me moeilijk terug op de eerstgenoemden, simpelweg omdat ik niet van configureren/boilerplate code schrijven houdt, maar wel van conventies (iets waar Rails mee werkt). Trust me, 'k studeer WO Technisch Informatica (hmmm, nee, helaas niet zo gaaf als de dokter variant)

Edit:
Even een analogie: J2EE/ASP.net 2 voor webdev is ongeveer hetzelfde als alle reacties hier lezen, je hebt er tijd voor nodig en weinig hobbies Je bereikt welliswaar hetzelfde (want je leest uiteindelijk mijn reactie, zie hieronder).

Ruby en rails zijn dan ongeveer gewoon mijn post lezen en aannemen dat ik gelijk heb. Lekker makkelijk en snel de job gedaan krijgen dus .

Wow, I never cease to amaze myself

[Chimera]

Nigo schreef op 14-07-2007 @ 18:20 :
Trust me, I'm a doctor volstaat niet?

Nah gut, itt jullie zal ik het eens kort houden: ruby is een dynamische taal die geheel object georienteerd is. Dat dynamisch zijn itt statisch heeft voor en nadelen, het is maar net wat je smaak is, daar kun je echt uren over blijven discussieren. Right tool for the right job is voor mij nog steeds de beslissende factor voor wanneer ik iets gebruik.

Dynamisch versus statisch: tja. Laten we het maar op voorkeur houden. Let wel: in de industrie wordt het dynamische karakter van PHP als onwenselijk beschouwd. Het is onzin dat het 'handig' is, je weet als het goed is van te voren wat je in een object gaat stoppen. Weet je dat niet, dan ben je aan het prutsen.

Nigo schreef op 14-07-2007 @ 18:20 :

Alle voordelen genoemd in dit topic over OO (voor zover ze kloppen) gaan ook op voor Ruby. Rails zorgt ervoor dat je voor webdev een raamwerk hebt die meteen out of the box via het Model View Controller (MVC) design pattern werkt. Daarbij krijg je ook Object Relational mapping via ActiveRecords als persistance layer en zijn veel zaken als database veranderingen elegant opgelost via migrations, hierdoor kan je binnen enkele seconden van de ene naar de andere database opzet migreren.

En die tools zijn er niet voor .Net of java? Wel eens van Hibernate gehoord?

Nigo schreef op 14-07-2007 @ 18:20 :

Ook heeft men rekening gehouden met de diverse stadia waarin je je app zult ontwikkelen, namelijk development, test en production environment. De benodigde testframeworks zijn hier ook voor aangeleverd. Dit is getrouw aan de de facto standaard van dingen opbouwen.

Je zit een beetje te zwammen. Ten eerste zijn dergelijke tools er natuurlijk ook voor .net en Java. Gezien de al lange geschiedenis van .net en Java, en de userbase, is de kans vrij groot dat er zelfs 'meer' zijn.

En leg mij eens uit WAAROM Ruby die verschillende stadia beter zou ondersteunen? Want dat 'ondersteunen' wordt over het algemeen meer door tools dan door het platform gedaan.

Nigo schreef op 14-07-2007 @ 18:20 :

Voorheen was ik J2EE/ASP.net 2 + C#'er, maar na dit geprobeerd te hebben krijg je me moeilijk terug op de eerstgenoemden, simpelweg omdat ik niet van configureren/boilerplate code schrijven houdt, maar wel van conventies (iets waar Rails mee werkt). Trust me, 'k studeer WO Technisch Informatica (hmmm, nee, helaas niet zo gaaf als de dokter variant)

Trust me: ik heb 4 jaar informatica gestudeerd en werk nu 5 jaar 'in the bussiness'. Eerst als developer, nu als technisch consultant waarbij ik klanten van ons adviseer en begeleid in implementaties en migraties. Sorry, ik vind mijn versie 'gaver'

Nigo schreef op 14-07-2007 @ 18:20 :

Edit:
Even een analogie: J2EE/ASP.net 2 voor webdev is ongeveer hetzelfde als alle reacties hier lezen, je hebt er tijd voor nodig en weinig hobbies Je bereikt welliswaar hetzelfde (want je leest uiteindelijk mijn reactie, zie hieronder).

Ruby en rails zijn dan ongeveer gewoon mijn post lezen en aannemen dat ik gelijk heb. Lekker makkelijk en snel de job gedaan krijgen dus .

Wow, I never cease to amaze myself

PHP is ook een 'quick 'n dirty' oplossing in veel gevallen. Er is geen 'quick 'n good' oplossing.

Ik heb trouwens eens naar de API gekeken, en Ruby heeft dezelfde problemen als PHP: de onderliggende API waarmee je bijvoorbeeld files benaderd is gewoon absoluut niet OO. Je krijgt dus, net zoals in PHP, een lelijke mix van OO en niet-OO code. Bah Ruby on Rails is specifiek bedoeld om snel en makkelijk een site op te zetten. Als je snel en makkelijk een weblog op wil zetten kun je net zo goed een van de honderden gratis weblog engines downloaden en die customizen. Als je voor een grote klant een applicatie moet bouwen is het platform belangrijk, en dan is het, met het oog op de toekomst, misschien een idee om een platform te kiezen dat ook daadwerkelijk een proven trackrecord heeft in grote applicaties.

[Manuzhai]

Chimera schreef op 16-07-2007 @ 10:09 :
Dynamisch versus statisch: tja. Laten we het maar op voorkeur houden. Let wel: in de industrie wordt het dynamische karakter van PHP als onwenselijk beschouwd. Het is onzin dat het 'handig' is, je weet als het goed is van te voren wat je in een object gaat stoppen. Weet je dat niet, dan ben je aan het prutsen.

"In de industrie" is ook nogal een brede claim die je niet goed onderbouwt. Ik ga binnenkort in de bank-wereld werken aan een substantieel systeem dat geschreven wordt in Python. Daar wordt het dynamische karakter van Python als wenselijk beschouwd (en het controleren van wat mensen in objecten stoppen doen we wel met unit tests).

Chimera schreef op 16-07-2007 @ 10:09 :
Dynamisch versus statisch: tja. Laten we het maar op voorkeur houden. Let wel: in de industrie wordt het dynamische karakter van PHP als onwenselijk beschouwd. Het is onzin dat het 'handig' is, je weet als het goed is van te voren wat je in een object gaat stoppen. Weet je dat niet, dan ben je aan het prutsen.

Wow, iemand neemt zichzelf te serieus hier Maar ik speel wel lekker mee met dat spelletje van baas boven baas. We kunnen er uren over discussieren over de pro's en cons van dynamisch versus statische talen, zelf heb ik wel wat beters te doen en ben ik van mening dat het een kwestie van smaak/ritme is zoals m'n oud collega wilco ook aankaart.

En die tools zijn er niet voor .Net of java? Wel eens van Hibernate gehoord?

Natuurlijk zijn die er ook voor .net en java, het tegendeel beweer ik toch ook niet met die zin? Niet dingen lezen die je wil dat er staan. Het puntje dat ik aan wil kaarten is dat rails out of the box al rekening houdt met dingen die er 9/10 keer toch van komen als gevolg van good practice in webdevelopment, o.a. dus object relational mapping, iets waar je bij java/.net eerst hibernate voor moet downloaden, dan configureren (yay, weer honderden xml regels verder) etc...,en dan zwijgen we nog maar even over het feit dat je hier zelf eerst achter moet komen dat zulke dingen bestaan, iets dat bij rails meteen al gestimuleerd wordt.

Wederom heb ik wel betere dingen te doen met mijn tijd dan configureren als ik eigenlijk wil webdevven . Misschien overdreven, maar zo voelde het wel vaak aan, wat ook mij ruby en rails heeft doen verkennen.

.net en java zou ik als platformen gebruiken om hele andere redenen, o.a. als ik van plan zou zijn mijn business logics te gebruiken over meerdere platformen en 'soort' applicaties, i.e. desktop applicaties naast webapplicaties. In plaats van een taal/platform meteen af te schrijven ga ik toch liever met de uitspraak van right tool for the right job.

Je zit een beetje te zwammen. Ten eerste zijn dergelijke tools er natuurlijk ook voor .net en Java. Gezien de al lange geschiedenis van .net en Java, en de userbase, is de kans vrij groot dat er zelfs 'meer' zijn.

Ik blijf het grappig vinden dat je m'n post teniet wil doen door dingen te suggereren die ik helemaal niet stel. Natuurlijk zijn zulke tools er ook voor .net en Java, het tegendeel beweer ik dan ook niet. Het enige wat ik zeg is dat rails een over het algemeen total solution aanbiedt voor webdevelopment die aan te vullen is met plugins en zoals ik al vele malen eerder heb gezegd, right tool for the right job, zo vind ik ook dat right advice for the right time/person geldt.

Je hebt hier immers te maken met een topicstarter die PHP vergelijkt met JSP alsof ze maar comparable zijn om mee te beginnen. Wie loopt hier dan daadwerkelijk te zwammen in de reacties? De developers die met buzzwords een beginner proberen te imponeren? Dezelfde buzzwords mag ik je eraan herinneren die de topicstarter waarschijnlijk hebben doen vermoeden dat JSP en PHP vergelijkbaar zijn.

Wel wil ik zeggen dat 'meer tools' niet per definitie beter is. De werkelijkheid is dat slechts een handjevol voor een bepaald doel er eigenlijk echt toe doet (en ook actieve onderhouding geniet), en dat is eigenlijk een goed iets, omdat je op de werkvloer makkelijk erover uit kan zijn hoe en wat zonder duizenden verschillende dialecten van API's te moeten spreken. Natuurlijk zouden we via extra abstractielagen toevoegen deze weg kunnen moffelen, maar die tijd kun je ook beter gebruiken dacht ik zo om gewoon de provider aan te passen WANNEER dat een probleem is. YAGNI so to say. Maar goed we dwalen af.

En leg mij eens uit WAAROM Ruby die verschillende stadia beter zou ondersteunen? Want dat 'ondersteunen' wordt over het algemeen meer door tools dan door het platform gedaan.

Wederom lees je weer dingen die ik helemaal niet beweer, zeker niet zo'n stomme opmerking. Ruby is een taal, en dient slechts als een manier van uitdrukken. Natuurlijk ondersteund deze de stadia dan niet, maar Rails daarentegen als framework -wel-, en de op welke manieren heb ik denk ik toch al duidelijk gemaakt in m'n vorige post, maar ik kan me voorstellen dat je ervoor hebt gekozen om deze niet te lezen

Trust me: ik heb 4 jaar informatica gestudeerd en werk nu 5 jaar 'in the bussiness'. Eerst als developer, nu als technisch consultant waarbij ik klanten van ons adviseer en begeleid in implementaties en migraties. Sorry, ik vind mijn versie 'gaver'

Trust me, ik denk dat je weer terug moet naar school. 4 jaar, HBO informatica zeker? Dan zijn we helemaal klaar met praten Ik heb niet zo de behoefte om te 'pochen' met m'n werkervaring, omdat ik van mening ben dat ik met m'n post alleen al serieus genomen wordt , maar voor wat het waard is, ook daar win ik het op. Wilco trouwens helemaal.

PHP is ook een 'quick 'n dirty' oplossing in veel gevallen. Er is geen 'quick 'n good' oplossing.

Wat een onzin, dat hangt sowiesow ten eerste van de programmeur af. Ten tweede, waarom gaat het oppeens over PHP? Als taal zuigt het gewoon met halve implementaties van mechanismen en daarmee eveneens paradoxen. Omdat mensen vast een voorbeeld willen horen: overloaden van methods kan in een class (zij het belachelijk door zelf dispatcher code te schrijven), maar overloaden in een interface is dan weer niet mogelijk...

Daarbij is quick and dirty niet per definitie een slecht iets, iets dat jij als consultant zou moeten weten, maar 'k kan me goed voorstellen dat je je zakken wil vullen . Je moet daarbij de levenscyclus van een applicatie in acht nemen, quick and dirty is in vele gevallen dan gewoon afdoende (denk aan microsites voor produktpromotie), en meer ervan proberen te maken zou in zulke gevallen gewoon roof zijn. Als je daarbij echt goed het OO paradigm goed hebt begrepen en het belang weet van goede interfaces, dan zou je zeker moeten weten dat quick and dirty helemaal zo'n probleem niet zou moeten zijn dan als de interfaces in orde zijn met het oog op de toekomst. De implementatie is immers zo vervangbaar.

Ik heb trouwens eens naar de API gekeken, en Ruby heeft dezelfde problemen als PHP: de onderliggende API waarmee je bijvoorbeeld files benaderd is gewoon absoluut niet OO. Je krijgt dus, net zoals in PHP, een lelijke mix van OO en niet-OO code. Bah Ruby on Rails is specifiek bedoeld om snel en makkelijk een site op te zetten. Als je snel en makkelijk een weblog op wil zetten kun je net zo goed een van de honderden gratis weblog engines downloaden en die customizen. Als je voor een grote klant een applicatie moet bouwen is het platform belangrijk, en dan is het, met het oog op de toekomst, misschien een idee om een platform te kiezen dat ook daadwerkelijk een proven trackrecord heeft in grote applicaties.

Edit
Hier ben ik het opzich wel met je eens m.b.t. de File API dat dat niet out of the box is zoals dat bij Java het geval is. De methoden waar jij naar refereert zijn statische methoden, net zoals je deze in Java/C# kan definieren. Dat maakt Java/C# echter niet tot een mindere OO taal, want net als daar is er NIETS, maar dan ook NIETS dat je ervan weerhoudt om daar wrappers voor te schrijven indien je ze nodig acht en kan je het zo OO naar je smaak maken als je maar wil. Hetzelfde gaat opzich ook op voor PHP (ook al is deze API bijna geheel procedureel), maar gelukkig vangt bij Ruby rails al een hoop op.

Over het algemeen zou ik je toch aan willen raden om er mee te werken ipv het op de voorhand al beoordelen op de standaard API en/of z'n dynamische karakter, want kom je erachter hoe dom sommigen van je uitspraken wel niet zijn, tenminste... dat hoop ik voor je.