[JAVA] vs [PHP] wat is de meerwaarde?

Pagina: 1 2 3 Laatste
Acties:
  • 1.373 views sinds 30-01-2008

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Erkens schreef op donderdag 16 december 2004 @ 11:03:
precies wat je zegt background processing hoort niet binnen een webapp te draaien ;)
Het hoort niet in de web request processor, maar wel in de web app.

  • Onno
  • Registratie: Juni 1999
  • Niet online
Dat al die zaken in PHP in feite niet mogelijk zijn en dat het daarin dus niet wenselijk is ze daar zo op te lossen betekent niet meteen dat dat in het algemeen ook geldt. Een connectiepool kan op weinig andere plaatsen geimplementeerd worden, caching is bedoeld om het geheel sneller te maken en daar wil je dus niet al te veel andere laagjes voor nodig hebben, background processing kan erg nuttig zijn voor bijvoorbeeld het pre-fetchen van data die je verwacht nodig te hebben in een volgende request.

Verwijderd

Voor een connectionpool is het inderdaad onmisbaar dat je code hebt draaien die ook tussen de requests blijft leven. De code die dat regelt zit natuurlijk niet in je JSP laag, maar op servlet niveau.

Wat een connectionpool bijvoorbeeld ook doet, is na een timeout (die geheel los staat van de request scope time) een connection weer vrij geven. Dat zorgt ervoor dat als je code hebt draaien die vergeet een connection (eigenlijk resource in het algemeen) vrij te geven, deze niet al je connecties opslokt.

In JSP -kun- je echter ook gewoon variablen declareren die na het omzetten in de servlet dan als class instance variablen gemaakt worden. Je gebruikt daarvoor de <%! %> syntax. Bijvoorbeeld:

Java Server Page:
1
<%! private int bar = 4; %>


Je moet er hier wel rekening mee houden dat voor elke page maar 1 servlet instance wordt gemaakt, waar dan meerdere threads (1 per request) door heen gaan. Je toegang tot bar hier -moet- dus gesynchronized zijn.

De uitzondering is als je singleThreadModel voor je page declareerd. Dan hoeft de access voor een gewone member variable niet gesynchronzied te zijn (er is altijd maar 1 thread actief in je object dan). Je kunt zelfs dan nog data delen, maar dan moet je je variable static maken:

Java Server Page:
1
<%! private static int bar = 4; %>


Deze manier van application wide data is mogelijk, maar ik vermijd haar zelf zo veel als kan en gebruik in mijn web layer alleen objecten met sessie scope. Het feit dat je met je servlets wel gewoon een continu draaiende applicatie hebt (in de diepere lagen) is echter onmisbaar. Ik wist niet dat PHP zoiets niet had en vind dat toch wel een extra gemis.

Hier is nog een quote uit core servelts and jsps over PHP vs JSP:
PHP is a free, open-source HTML-embedded scripting language that is somewhat
similar to both ASP and JSP. The advantage of JSP is that the dynamic
part is written in Java, which you probably already know, which already has an extensive API for networking, database access, distributed objects, and the like,
whereas PHP requires learning an entirely new language.
Deze quote is dus overduidelijk gericht op 'gewone' programmeurs die ook al andere applicaties schrijven behalve web apps. Het voordeel dat hier genoemd wordt is dat dezelfde API die je ook voor andere projecten gebruikt, gewoon her-gebruikt kan worden.

  • Erkens
  • Registratie: December 2001
  • Niet online

Erkens

Fotograaf

Verwijderd schreef op donderdag 16 december 2004 @ 15:02:
Hier is nog een quote uit core servelts and jsps over PHP vs JSP:


[...]


Deze quote is dus overduidelijk gericht op 'gewone' programmeurs die ook al andere applicaties schrijven behalve web apps. Het voordeel dat hier genoemd wordt is dat dezelfde API die je ook voor andere projecten gebruikt, gewoon her-gebruikt kan worden.
Die quote is van iemand die (net als heel veel hier) een negatief beeld van PHP wilt geven ;)

Verwijderd

Erkens schreef op donderdag 16 december 2004 @ 15:06:
Die quote is van iemand die (net als heel veel hier) een negatief beeld van PHP wilt geven ;)
Geen negatief beeld, een reeel beeld ;)

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Erkens schreef op donderdag 16 december 2004 @ 15:06:
Die quote is van iemand die (net als heel veel hier) een negatief beeld van PHP wilt geven ;)
Toch vind ik hem wel (deels) terecht:
The advantage of JSP is that the dynamic
part is written in Java, which you probably already know, which already has an extensive API for networking, database access, distributed objects, and the like,
whereas PHP requires learning an entirely new language.
Vooral als een deel van een applicatie als gewoon Java draait en een deel als JSP lijkt me dit een groot voordeel.

Verder zou ik met PHP uitkijken, als je iets te kritische bug reports indient wordt je gebanned van de server. :(

[ Voor 9% gewijzigd door Olaf van der Spek op 16-12-2004 15:18 ]


  • Erkens
  • Registratie: December 2001
  • Niet online

Erkens

Fotograaf

Verwijderd schreef op donderdag 16 december 2004 @ 15:14:
[...]

Geen negatief beeld, een reeel beeld ;)
lees het topic nog maar eens door ;)
de meeste weten echt niet waar ze over praten, maargoed deze discussie is ook niet nuttig, Java is meer dan alleen webapplicaties en PHP is speciaal daarvoor gemaakt, een appel en een peer vergelijken is ook niet goed mogelijk behalve dat ze allebei gegeten kunnen worden kan je er niet meer over zeggen.

Gebruik gewoon de taal waar die volgens jou het best ingezet kan worden.
OlafvdSpek schreef op donderdag 16 december 2004 @ 15:17:
Toch vind ik hem wel (deels) terecht:
PHP ljikt erg veel op andere talen dus dat je wat nieuws moet leren is onzin, daarnaast, als je altijd in taal X hebt geprogrammeerd dan is het logisch dat je wat moet leren voor taal Y, raar argument imo.
PHP heeft ook erg veel mogelijkheden voor db en networking etc, ook geen argument.
Verder zou ik met PHP uitkijken, als je iets te kritische bug reports indient wordt je gebanned van de server. :(
:?

[ Voor 34% gewijzigd door Erkens op 16-12-2004 15:22 ]


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Erkens schreef op donderdag 16 december 2004 @ 15:19:
PHP ljikt erg veel op andere talen dus dat je wat nieuws moet leren is onzin, daarnaast, als je altijd in taal X hebt geprogrammeerd dan is het logisch dat je wat moet leren voor taal Y, raar argument imo.
PHP heeft ook erg veel mogelijkheden voor db en networking etc, ook geen argument.
Het lijkt erop, maar het is niet hetzelfde. Code copy/pasten of direct hergebruiken kan dus niet.
Dat als je van taal switched je een nieuwe taal moet leren is logisch, maar dat je van taal moet switchen is niet direct logisch.

  • drm
  • Registratie: Februari 2001
  • Laatst online: 09-06 13:31

drm

f0pc0dert

Het lijkt erop, maar het is niet hetzelfde. Code copy/pasten of direct hergebruiken kan dus niet.
Dat als je van taal switched je een nieuwe taal moet leren is logisch, maar dat je van taal moet switchen is niet direct logisch.
Dat argument snijdt geen hout. Andersom geldt namelijk precies hetzelfde: als je PHP hebt geleerd is dat dus een reden om niet over te stappen op Java.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
drm schreef op donderdag 16 december 2004 @ 15:44:
Dat argument snijdt geen hout. Andersom geldt namelijk precies hetzelfde: als je PHP hebt geleerd is dat dus een reden om niet over te stappen op Java.
Als je geen van beide kent en/of geen bestaande code hebt is het niet relevant nee.
Als je wel al code hebt voor normale apps of ook normale apps moet schrijven met gedeelde code, dan is de kans groter dat dit Java is dan PHP. Dus vandaar ...

[ Voor 20% gewijzigd door Olaf van der Spek op 16-12-2004 15:47 ]


Verwijderd

OlafvdSpek schreef op donderdag 16 december 2004 @ 15:36:
Dat als je van taal switched je een nieuwe taal moet leren is logisch, maar dat je van taal moet switchen is niet direct logisch.
Goed gezegd! Je moet van taal switchen als de nieuwe taal features heeft die de oude, of andere, niet heeft. Dat geldt voor PHP niet. Het is alleen anders, zelfs 'iets' minder. Zelfs de grootste PHP fans zullen moeten toegeven dat het iniedergeval niet beter is als Java (en dan doel ik alleen op de pure, kale, taal syntax & semantics, niet over welke libs je hebt of hoe het platform werkt).

Zoals Java laat zien, is het niet nodig om voor web applicaties een nieuwe taal te introduceren. Je kunt gewoon de bestaande taal blijven gebruiken. Dat is handig, want heel veel utility classes die ik heb kan ik gewoon meenemen als ik een web app maak. Speciale algortimes, code om plaatjes te maken, de voorbeelden die in de quote genoemt werden, etc etc. Ik kan het zo meenemen.

Natuurlijk moet je niet te veel Java (scriptlets) op een JSP page gebruiken. Liever wat meer JSTL of andere taglibs, en de java code zoveel mogelijk in een lagere layer stoppen, in zowel beans of gewone classes.

  • Erkens
  • Registratie: December 2001
  • Niet online

Erkens

Fotograaf

Verwijderd schreef op donderdag 16 december 2004 @ 15:46:
Je kunt gewoon de bestaande taal blijven gebruiken. Dat is handig, want heel veel utility classes die ik heb kan ik gewoon meenemen als ik een web app maak. Speciale algortimes, code om plaatjes te maken, de voorbeelden die in de quote genoemt werden, etc etc. Ik kan het zo meenemen.
kan ik ook met PHP, onzin argument dus ;)

Verwijderd

OlafvdSpek schreef op donderdag 16 december 2004 @ 15:45:
[...]

Als je geen van beide kent en/of geen bestaande code hebt is het niet relevant nee.
Als je wel al code hebt voor normale apps, dan is de kans groter dat dit Java is dan PHP. Dus vandaar ...
Inderdaad. Zoals gezegd, Java is universeel inzetbaar: Web apps, de desktop (bv Eclipse, maar ook vele andere tools), commandline apps, en embedded.

Tevens gebruiken heel veel opleidingen, zowel HBO als Universiteit, Java. Op sommige universiteiten is het de 'hoofdtaal' (bv de VU), op andere wordt het voor sommige vakken gebruikt (UL).

Daarentegen is PHP alleen voor web applicaties bedoeld en wordt het niet op het HBO of WO onderwezen. In sommige gevallen is het beter om iets te hebben wat 1 ding goed doet dan veel dingen matig. Dit -zou- een argument -voor- PHP kunnen zijn, behalve dat PHP helemaal geen features heeft die uitzonderlijk goed in een web omgeving uitgebuit kunnen worden. Zoals uit deze thread blijkt kan het alleen maar minder dan een universele taal zoals Java of C#.

  • drm
  • Registratie: Februari 2001
  • Laatst online: 09-06 13:31

drm

f0pc0dert

OlafvdSpek:
Als je wel al code hebt voor normale apps of ook normale apps moet schrijven met gedeelde code, dan is de kans groter dat dit Java is dan PHP. Dus vandaar ...
Da's wel waar, ja.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Erkens schreef op donderdag 16 december 2004 @ 15:47:
kan ik ook met PHP, onzin argument dus ;)
Welke normale desktop/server app geschreven in PHP heb jij dan waarvan je code hergebruikt in web scripts?

Verwijderd

Dit is een discussie waar we nooit uit gaan komen omdat iedereen z'n eigen voorkeuren heeft en natuurlijk z'n eigen platform als het beste ziet... anders werk je er niet mee, toch? Ik heb in Java, PHP en C# aan verschillende middelgrote projecten (mee)gewerkt en ze zijn alledrie goed, anders waren ze niet zo populair!
Verwijderd schreef op donderdag 16 december 2004 @ 15:46:
Goed gezegd! Je moet van taal switchen als de nieuwe taal features heeft die de oude, of andere, niet heeft. Dat geldt voor PHP niet. Het is alleen anders, zelfs 'iets' minder. Zelfs de grootste PHP fans zullen moeten toegeven dat het iniedergeval niet beter is als Java (en dan doel ik alleen op de pure, kale, taal syntax & semantics, niet over welke libs je hebt of hoe het platform werkt).
Nogmaals, je bent appels met peren aan het vergelijken. De taal PHP is gewoon anders en doet vanaf versie 5 zeker niet meer onder voor Java. Zoals Zef al zei, zie ook Bruce Eckel's Strong typing versus Strong testing
Zoals Java laat zien, is het niet nodig om voor web applicaties een nieuwe taal te introduceren. Je kunt gewoon de bestaande taal blijven gebruiken. Dat is handig, want heel veel utility classes die ik heb kan ik gewoon meenemen als ik een web app maak. Speciale algortimes, code om plaatjes te maken, de voorbeelden die in de quote genoemt werden, etc etc. Ik kan het zo meenemen.
Wat wil je hiermee nou zeggen? Als ik utility spul in C++ ofzo heb, zou ik dus webapplicaties in C++ moeten gaan maken? Nee, dank je ;) Dit onderstreept alleen mijn punt van enkele pagina's terug dat de keuze voor een bepaald platform gewoon afhankelijk is van de voorkeur en de ervaring van de programmeur(s).
Natuurlijk moet je niet te veel Java (scriptlets) op een JSP page gebruiken. Liever wat meer JSTL of andere taglibs, en de java code zoveel mogelijk in een lagere layer stoppen, in zowel beans of gewone classes.
Wat dit betreft zijn JSP's en pagina's met inline PHP goed te vergelijken. In JSP's kun je ook een gigantische puinzooi bouwen als je geen fatsoenlijk ontwerp maakt. Dit is iets wat vaak als nadeel van PHP wordt aangehaald, maar het ligt wederom gewoon aan de programmeur/ontwerper om dit goed op te lossen.

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op donderdag 16 december 2004 @ 16:06:
Wat wil je hiermee nou zeggen? Als ik utility spul in C++ ofzo heb, zou ik dus webapplicaties in C++ moeten gaan maken? Nee, dank je ;)
Als je een significante hoeveelheid relevante code hebt is dat misschien niet zo'n gek idee.

Verwijderd

OlafvdSpek schreef op donderdag 16 december 2004 @ 16:23:
[...]

Als je een significante hoeveelheid relevante code hebt is dat misschien niet zo'n gek idee.
offtopic:
Meen je dat nou serieus?

Ik bedoel, dan schrijf je toch een wrapper (in Java, PHP, C# of wat dan ook) of je roept het aan via SOAP ofzo, maar je gaat toch geen webapplicatie schrijven in een taal die daar zeer zeker niet geschikt voor is... Managed C++ kan ik misschien nog wel in komen, maar zelfs dan heb ik er m'n twijfels bij.

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op donderdag 16 december 2004 @ 16:38:
offtopic:
Meen je dat nou serieus?

Ik bedoel, dan schrijf je toch een wrapper (in Java, PHP, C# of wat dan ook) of je roept het aan via SOAP ofzo, maar je gaat toch geen webapplicatie schrijven in een taal die daar zeer zeker niet geschikt voor is... Managed C++ kan ik misschien nog wel in komen, maar zelfs dan heb ik er m'n twijfels bij.
Een wrapper kan ook, maar is de taal niet geschikt of zijn de libraries niet geschikt als we het over C++ hebben?

(Het voorbeeld ging trouwens over Java, niet C++. De keuze is dan tussen een taal waarin je ook andere applicaties kan schrijven en een taal waarin je alleen web scripts kunt schrijven.)

[ Voor 16% gewijzigd door Olaf van der Spek op 16-12-2004 16:51 ]


Verwijderd

Een wrapper kan ook, maar is de taal niet geschikt of zijn de libraries niet geschikt als we het over C++ hebben?
Ik vind de taal zelf niet geschikt vanwege de vele mogelijke 'unsafe' constructies. Ik zie C++ eigenlijk alleen als handig om af en toe wat low-level dingen te bereiken via JNI, maar graag gebruik ik het zeker niet... Weer een voorbeeld van mijn stelling dat de voorkeur voor een platform meestal subjectief is.

Maar laten we C++ maar verder helemaal buiten beschouwing laten, anders hebben we dalijk nog een taal erbij waarover we kunnen discussieren :)

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op donderdag 16 december 2004 @ 16:38:
[...]

offtopic:
Meen je dat nou serieus?

Ik bedoel, dan schrijf je toch een wrapper (in Java, PHP, C# of wat dan ook) of je roept het aan via SOAP ofzo, maar je gaat toch geen webapplicatie schrijven in een taal die daar zeer zeker niet geschikt voor is... Managed C++ kan ik misschien nog wel in komen, maar zelfs dan heb ik er m'n twijfels bij.
Kom kom, zo vervelend is C++ ook weer niet om een webapp in te schrijven, het is zeer goed te doen zelfs. Wat standaard C++ mist is een goede webapp library, maar we gingen er al vanuit dat je utility spul gemaakt in C++ had.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op donderdag 16 december 2004 @ 17:14:
Ik vind de taal zelf niet geschikt vanwege de vele mogelijke 'unsafe' constructies. Ik zie C++ eigenlijk alleen als handig om af en toe wat low-level dingen te bereiken via JNI, maar graag gebruik ik het zeker niet... Weer een voorbeeld van mijn stelling dat de voorkeur voor een platform meestal subjectief is.

Maar laten we C++ maar verder helemaal buiten beschouwing laten, anders hebben we dalijk nog een taal erbij waarover we kunnen discussieren :)
Hoe meer hoe beter toch? ;)
Maar volgens mij denk je meer aan C-style constructies.
C++-style constructies (std::string, smart pointers, smart wrappers) zijn erg eenvoudig om te gebruiken en gewoon safe.
Het 'grote' probleem met C++ is eigenlijk dat je een cross compiler nodig hebt of het server platform zelf. Voor grote projecten is dat geen issue, maar voor veel hobby/prive projecten wel.

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

OlafvdSpek schreef op donderdag 16 december 2004 @ 17:48:
C++-style constructies (std::string, smart pointers, smart wrappers) zijn erg eenvoudig om te gebruiken en gewoon safe.
Precies, en met boost::any heb je een type wat in principe alles kan zijn, en een std::map<boost::any, boost::any> geeft je een mooie geassocieerde array zoals je in php ook hebt.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Verwijderd

.oisyn schreef op donderdag 16 december 2004 @ 17:18:Wat standaard C++ mist is een goede webapp library, maar we gingen er al vanuit dat je utility spul gemaakt in C++ had.
Noemen we dat gewoon niet PHP ;)

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Lees even goed, het ging er nou juist om dat je c++ ging gebruiken op het moment dat je al een hele c++ utility library hebt voor je webapp, en dat websjwans zei dat een webapp in C++ maken an sich niet verstandig is (wat nergens op slaat)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Verwijderd

.oisyn schreef op donderdag 16 december 2004 @ 18:17:
Lees even goed, het ging er nou juist om dat je c++ ging gebruiken op het moment dat je al een hele c++ utility library hebt voor je webapp, en dat websjwans zei dat een webapp in C++ maken an sich niet verstandig is (wat nergens op slaat)
Het was ook alleen maar als grapje bedoelt hoor :)
Tuurlijk kun je overigens C++ gebruiken, alleen is dat dan vaak niet wel overwogen. Want waarom zou je het wiel opnieuw uitvinden als bij de buren complete frameworks klaarliggen. Dan schrijf je een framework waar niemand verstand van heeft. Conclusie, niet handig om C++ te gebruiken.

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Te kort door de bocht, als performance en memory use een issue is zou ik zeker voor C++ gaan

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Verwijderd

.oisyn schreef op donderdag 16 december 2004 @ 18:25:
Te kort door de bocht, als performance en memory use een issue is zou ik zeker voor C++ gaan
Inderdaad, dit is te kort door de bocht.:) Als er sprake is van een realtime applicatie voldoet Java niet en C++ wel. Performance is vaak te verwaarlozen (java is in sommige gevallen sneller), en hardware is altijd goedkoop!

Verwijderd

Kwa taal heeft C++ ook zeker mijn voorkeur.

Wat wel een voordeel van Java is, is dat je garanties hebt dat als een thread een exception veroorzaakt, je niet geheugen hebt beschadigd dat door andere threads gealloceerd is. In C++ zou je dan toch eerder een process per request open moeten hebben, toch?

Ik zou zelf zeker geintresseerd zijn in C++ web apps development (mede omdat nog meer dan in Java mijn andere projecten en eigen prive libs C++ zijn), maar zie op dit moment erg weinig gebeuren op dat gebied.

In .NET daarentegen gebeurt wel heel veel (een aantal dingen ziet er zelfs mooier uit dan wat J2EE nu heeft). Als C++ meer een volwaardige .NET taal is (dus inclusief MI, templates, en alle meuk in standard C++ zodat ik ook boost kan gebruiken), dan zou C++ icm .NET wel eens de basis van mijn volgende project kunnen gaan worden.

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op donderdag 16 december 2004 @ 18:38:
Wat wel een voordeel van Java is, is dat je garanties hebt dat als een thread een exception veroorzaakt, je niet geheugen hebt beschadigd dat door andere threads gealloceerd is. In C++ zou je dan toch eerder een process per request open moeten hebben, toch?
Waarom heb je die garantie in C++ niet?
Bij beiden moet je wel opletten dat de state consistent blijft.
En nee, als een request qua CPU tijd kort is, kun je zelfs met een enkele thread toe met async/non-blocking IO.

Verwijderd

OlafvdSpek schreef op donderdag 16 december 2004 @ 18:51:
[...]

Waarom heb je die garantie in C++ niet?
Omdat threads per definitie dezelfde address space delen. In C++ kun je als er wat fout gaat perongeluk geheugen beschrijven wat niet door jou gealloceerd is. (bv een simpele toekenning aan een element buiten de grenzen van een array).
Je kunt dus niet gemakkelijk requests door verschillende threads laten afhandelen in C++. Als er wat fout gaat beinvloed dat alle users, niet alleen de user die de request deed waarin er wat fout ging.

Je zou in C++ dus eerder voor processen gaan om requests af te handelen. Een context switch voor een process is echter veel zwaarder als bij een thread.
Dit heb jij als het goed is bij het vak Operating Systems uitgebreid gehad.

(en hopelijk komt .oisyn nu met een mooie methode waarmee het toch wel kan ;) )

[ Voor 5% gewijzigd door Verwijderd op 16-12-2004 19:05 . Reden: hoop doet leven ]


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op donderdag 16 december 2004 @ 19:03:
Omdat threads per definitie dezelfde address space delen. In C++ kun je als er wat fout gaat perongeluk geheugen beschrijven wat niet door jou gealloceerd is. (bv een simpele toekenning aan een element buiten de grenzen van een array).
In Java kun je ook alle shared state kapot maken.
En ik ga er natuurlijk wel vanuit dat je geen bugs in je eigen code stopt. ;->
Of dat je ze er daarna weer netjes uit sloopt.
Als je aparte processen gebruikt ben je de voordelen van shared state kwijt.
Verder kun je in C++ ook classes gebruiken die wel bounds checks uitvoeren, etc. Dan heb je dat risico ook niet meer.

[ Voor 15% gewijzigd door Olaf van der Spek op 16-12-2004 19:54 ]


Verwijderd

dat websjwans zei dat een webapp in C++ maken an sich niet verstandig is (wat nergens op slaat)
Ik haalde C++ aan als voorbeeld, ik zal in het vervolg wel Cobol roepen, ok? Ik kon me gewoon niet voorstellen dat iemand z'n webapps in C++ gaat maken omdat ik inderdaad meer de valkuilen van C voor me zag, zoals Olaf al wat genuanceerder aan gaf.
performance en memory use een issue is zou ik zeker voor C++ gaan
Als performance en memory zo'n groot issue zijn om dat je voor C++ gaat, zou je dan nog wel voor een webapp gaan?

[ Voor 26% gewijzigd door Verwijderd op 16-12-2004 19:59 ]


  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op donderdag 16 december 2004 @ 19:57:
Als performance en memory zo'n groot issue zijn om dat je voor C++ gaat, zou je dan nog wel voor een webapp gaan?
In welke zin bedoel je dat?
In de zin van gaan naar een normale desktop app?

[ Voor 6% gewijzigd door Olaf van der Spek op 16-12-2004 20:00 ]


Verwijderd

OlafvdSpek schreef op donderdag 16 december 2004 @ 19:47:
[...]

In Java kun je ook alle shared state kapot maken.
Maar je shared niet zoveel state expliciet, en van de state die je shared weet je dat het shared is en kun je daar eventueel rekening mee houden. In C++ kunnen gewone lokale variablen, waarvan je opzich de absolute garantie denkt te hebben dat ze lokaal voor een scope zijn, toch corrupt raken door multi-threading, of door een willekeurige functie in je eigen thread.

Niet om Java nou te zeer op te hemelen, want C++ heeft veel meer andere voordelen, maar dat soort corruptie is in Java niet mogelijk. Random writes in het geheugen zijn onmogelijk.
En ik ga er natuurlijk wel vanuit dat je geen bugs in je eigen code stopt. ;->
Natuurlijk, maar helaas is dat niet realistisch. Er zitten bugs in je code. Dat komt bij de beste programmeurs voor, in PHP, Java, C++. Ga jij maar eens alle technieken die we bij Programmeren en Correctheid leerde op *elk* stukje code toepassen.
Als je aparte processen gebruikt ben je de voordelen van shared state kwijt.
Je hebt natuurlijk wel communicatie tussen processen, via pipes, messages, etc. kun je heel wat communiceren met de manager van een stuk van de state die je shared.
Verder kun je in C++ ook classes gebruiken die wel bounds checks uitvoeren, etc. Dan heb je dat risico ook niet meer.
Dat is waar, maar zodra je dan weer 1 stukje code aanroept wat niet van jou is, zeker als het een library betreft waar je de source niet van hebt, heb je dat risico weer wel.

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op donderdag 16 december 2004 @ 20:04:
Maar je shared niet zoveel state expliciet, en van de state die je shared weet je dat het shared is en kun je daar eventueel rekening mee houden.
Waarom zou je niet veel state kunnen sharen?
En ja, de robuustheid gaat wel iets naar beneden, maar daar krijg je performance voor terug.
De vraag is wat belangrijker is voor een specifieke applicatie en hoeveel bugs er inderdaad in zitten die de hele server laten crashen.

[ Voor 8% gewijzigd door Olaf van der Spek op 16-12-2004 20:17 ]


Verwijderd

OlafvdSpek schreef op donderdag 16 december 2004 @ 20:00:
[...]

In welke zin bedoel je dat?
In de zin van gaan naar een normale desktop app?
Kijk, zijn we toch nog over C++ aan het discussieren... :)

Mijn punt (dat waarschijnlijk weer nergens op slaat volgens .Oisin :P ) is dat een web omgeving nogal wat overhead met zich mee brengt, zoals het verwerken van de textuele HTTP requests, de traffic, het webserver of applicatieserver proces zelf, authenticatie, opbouw van pagina's op de client etc.

Door deze overhead zal de tijd en het geheugen dat je webapp nodig heeft om puur een request af te handelen slechts een fractie zijn van het totaal wat nodig is voor de hele omgeving. Hierdoor denk ik dat de performance en memory use wat je zou besparen met C++ geen goed argument is om voor webapps in C++ te kiezen. Tuurlijk kun je dan ook je hele omgeving in C++ gaan proggen, maar dan ben je echt het wiel 3 keer opnieuw aan het uitvinden.

Hoe je het dan wel zou moeten oplossen weet ik ook niet zo snel, maar je zou inderdaad kunnen denken aan een desktop client die rechtstreeks met een DB kan communiceren en waarvan de GUI onderdelen ook beter op de te tonen data zijn afgestemd (table component i.p.v. html table enzo).

Verwijderd

Geld is de beste reden om niet C++ te gaan!
1 dag een paar c++ programmeurs laten werken is even veel waard als een complete nieuwe server.
Hardware is goedkoop, software niet. Dus zoveel mogelijk voorkomen dat je het wiel opnieuw uit vind en gebruik maken van defacto standaard frameworks.

C is belangrijk in realtime applicaties, maar daarbuiten is het vaak een hele slechte keuze!

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op donderdag 16 december 2004 @ 20:20:
Door deze overhead zal de tijd en het geheugen dat je webapp nodig heeft om puur een request af te handelen slechts een fractie zijn van het totaal wat nodig is voor de hele omgeving. Hierdoor denk ik dat de performance en memory use wat je zou besparen met C++ geen goed argument is om voor webapps in C++ te kiezen. Tuurlijk kun je dan ook je hele omgeving in C++ gaan proggen, maar dan ben je echt het wiel 3 keer opnieuw aan het uitvinden.
De hele omgeving?
Apache? C.
MySQL? C.
PHP? C.

Dat is dus allemaal al efficient.
Verder zie je regelmatig page generation times van 10 - 100 ms, terwijl snelle webservers 100 - 10000 simpele requests per seconde kunnen afhandelen.

Een desktop client is in sommige gevallen wel een optie, maar voor bijvoorbeeld een forum niet echt. En juist in standaard forums is performance vaak nogal slecht.
C is belangrijk in realtime applicaties, maar daarbuiten is het vaak een hele slechte keuze!
Heb je het nou over C of C++?

[ Voor 20% gewijzigd door Olaf van der Spek op 16-12-2004 20:47 ]


Verwijderd

OlafvdSpek schreef op donderdag 16 december 2004 @ 20:13:
[...]
Waarom zou je niet veel state kunnen sharen?
Omdat je je clients zo onafhankelijk van elkaar wilt houden als maar kan. Er zijn wat shared resources, maar die gaan via accesor functions van de manager classes. Stel dat code door bugs slecht gaat lopen, dan kunnen er de meest rare dingen gaan gebeuren. Als je echter je shared state bewaakt door aparte managers, in plaats van rechtstreeks je code naar een instance variable laten schrijven, dan kun je garanderen dat er geen ongeldige waardes in je shared state komen (binnen redelijke limieten, er zit een grens aan wat je redelijkerwijze kunt controleren).

Echter in C++ met een shared address space en de mogelijkheid om op willekeurige plekken in het geheugen te schrijven, kun je de architectural beveiliging heel makkelijk om zeep helpen. Alleen als je met aparte processen werkt heb je dezelfde garanties, namelijk een stukje C++ code kan op de meeste moderne operating systemen niet zomaar in het geheugen van een ander process schrijven of lezen.

Als het fout gaat, dan help je in Java alleen je huidige thread (of iniedergeval de stack tot op het moment waar je een exception catched die je 100% kunt handlen) om zeep, en in C++ je huidige process. Anderen hebben er dan geen last van.

Verwijderd

Verwijderd schreef op donderdag 16 december 2004 @ 20:34:
Geld is de beste reden om niet C++ te gaan!
1 dag een paar c++ programmeurs laten werken is even veel waard als een complete nieuwe server.
Hardware is goedkoop, software niet. Dus zoveel mogelijk voorkomen dat je het wiel opnieuw uit vind en gebruik maken van defacto standaard frameworks.
Dat is niet de taal zelf maar de beschikbaarheid van frameworks voor een bepaalde toepassing. Alleen om die reden zou ik momenteel inderdaad niet voor C++ gaan.

Dat C++ programmeurs duurder zouden zijn is al helemaal onzin. Op de lange termijn zouden ze juist goedkoper zijn omdat een goede C++ wellicht productiever is in C++ (de taal is krachtiger, je kunt er meer mee dan in Java, je kunt er *echt* generiek mee programmeren, etc).

  • Erkens
  • Registratie: December 2001
  • Niet online

Erkens

Fotograaf

OlafvdSpek schreef op donderdag 16 december 2004 @ 16:04:
[...]

Welke normale desktop/server app geschreven in PHP heb jij dan waarvan je code hergebruikt in web scripts?
in mijn geval dan andersom, maar ik heb een aantal PHP shell scripts die enorm krachtig zijn en diverse zaken regelen, en dus kan ik die code ook weer hergebruiken in andere scripts ;)

Verwijderd

Lees je eigelijk wel, ik schrijf toch nergens dat C++ programmeurs duurder zouden zijn dan andere programmeurs :?
Alleen een programmeur is nou eenmaal duur en hardware goedkoop. Zodoende kies je een taal waar je zo min mogelijk hoeft te programmeren door verscheidene (defacto standaard) frameworks die beschikbaar zijn. Deze frameworks zijn dan ook bekend bij toekomstige programmeurs waardoor aanpassingen makkelijker kunnen worden doorgevoerd. Tevens kunnen ze zich dan bezig houden met de business logic in plaats van de taal.

Al met al kies je dus eigelijk heel vaak niet voor C++

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op donderdag 16 december 2004 @ 18:32:
[...]

Inderdaad, dit is te kort door de bocht.:) Als er sprake is van een realtime applicatie voldoet Java niet en C++ wel. Performance is vaak te verwaarlozen (java is in sommige gevallen sneller), en hardware is altijd goedkoop!
Realtime is heel wat anders, ik heb het gewoon over pure performance. Realtime hoeft niet snel te zijn, het zegt puur dat je garanties kan geven over hoe lang iets duurt en dat het binnen die tijd ook echt klaar is.
Verwijderd schreef op donderdag 16 december 2004 @ 19:03:

Omdat threads per definitie dezelfde address space delen. In C++ kun je als er wat fout gaat perongeluk geheugen beschrijven wat niet door jou gealloceerd is. (bv een simpele toekenning aan een element buiten de grenzen van een array).
Je kunt dus niet gemakkelijk requests door verschillende threads laten afhandelen in C++. Als er wat fout gaat beinvloed dat alle users, niet alleen de user die de request deed waarin er wat fout ging.

Je zou in C++ dus eerder voor processen gaan om requests af te handelen. Een context switch voor een process is echter veel zwaarder als bij een thread.
Dit heb jij als het goed is bij het vak Operating Systems uitgebreid gehad.

(en hopelijk komt .oisyn nu met een mooie methode waarmee het toch wel kan ;) )
Nou kan ik alleen spreken over windows omdat ik daar ervaring mee heb, maar je kunt (structured) exception handling gebruiken om fouten als page faults en access violations e.d. af te vangen. Met standaard c++ exception handling (try/catch) of met structured exception handling (__try/__except), hangt een beetje van de gebruikte compile optie af. In principe kun je dus elke thread guarden tegen exceptions en dus killt het niet het hele proces. En als safety een issue is, en performance niet (wat meestal het geval is bij simpele webapps) kun je natuurlijk altijd custom classes gebruiken zodat je nooit buiten de array bounds of naar dangling pointers kan schrijven. C++ kan zo veilig zijn als je het zelf maakt :)
Verwijderd schreef op donderdag 16 december 2004 @ 19:57:
[...]


Ik haalde C++ aan als voorbeeld, ik zal in het vervolg wel Cobol roepen, ok? Ik kon me gewoon niet voorstellen dat iemand z'n webapps in C++ gaat maken omdat ik inderdaad meer de valkuilen van C voor me zag, zoals Olaf al wat genuanceerder aan gaf.
Je kunt beter helemaal niets zomaar roepen zolang je er (nog) niet veel ervaring mee hebt ;)
Als performance en memory zo'n groot issue zijn om dat je voor C++ gaat, zou je dan nog wel voor een webapp gaan?
Dat is toch geen keuze die je hebt? Als je een webapp moet maken die goed moet performen, dan kun je toch niet kiezen om dan maar geen webapp te maken? Waarom zou een webapplicatie niet gewoon goede performance nodig kunnen hebben? Neem bijvoorbeeld een webbased game waar duizenden mensen tegelijk aan meedoen, C++ zou daarvoor echt de perfecte keus zijn.
Verwijderd schreef op donderdag 16 december 2004 @ 20:20:
Door deze overhead zal de tijd en het geheugen dat je webapp nodig heeft om puur een request af te handelen slechts een fractie zijn van het totaal wat nodig is voor de hele omgeving. Hierdoor denk ik dat de performance en memory use wat je zou besparen met C++ geen goed argument is om voor webapps in C++ te kiezen. Tuurlijk kun je dan ook je hele omgeving in C++ gaan proggen, maar dan ben je echt het wiel 3 keer opnieuw aan het uitvinden.

Hoe je het dan wel zou moeten oplossen weet ik ook niet zo snel, maar je zou inderdaad kunnen denken aan een desktop client die rechtstreeks met een DB kan communiceren en waarvan de GUI onderdelen ook beter op de te tonen data zijn afgestemd (table component i.p.v. html table enzo).
Ik denk dat jouw beeld van een webapplicatie toch meer iets van een simpel pagina-genererend iets is dat een verbinding heeft met een bepaalde database (zoals de meeste projecten die in PHP geimplementeerd worden). Maar een webapplicatie kan in principe alles zijn, van een visitor counter tot een fullblown webbased game, of misschien een game in een java applet die weer verbinding maakt met een server (ja die server is ook een webapp en ook te implementeren met talen als PHP en Java)
Verwijderd schreef op donderdag 16 december 2004 @ 20:34:
C is belangrijk in realtime applicaties, maar daarbuiten is het vaak een hele slechte keuze!
Dikke onzin. Ervan uitgegaan dat je het over C++ hebt, waar deze discussie over gaat, want C is over het algemeen idd een slechte keuze ;)
Verwijderd schreef op donderdag 16 december 2004 @ 21:13:
Lees je eigelijk wel, ik schrijf toch nergens dat C++ programmeurs duurder zouden zijn dan andere programmeurs :?
Nou hier bijvoorbeeld: Verwijderd in "[JAVA] vs [PHP] wat is de meerwaarde?"
Alleen een programmeur is nou eenmaal duur en hardware goedkoop. Zodoende kies je een taal waar je zo min mogelijk hoeft te programmeren door verscheidene (defacto standaard) frameworks die beschikbaar zijn. Deze frameworks zijn dan ook bekend bij toekomstige programmeurs waardoor aanpassingen makkelijker kunnen worden doorgevoerd. Tevens kunnen ze zich dan bezig houden met de business logic in plaats van de taal.
En wie zegt dat een dergelijke webinterface niet voor C++ bestaat? Sterker nog, je kunt in native C++ ook gewoon managed C++ gebruiken en dus heb je direct toegang tot een hele mooie webinterface.

[ Voor 8% gewijzigd door .oisyn op 17-12-2004 11:14 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

Verwijderd

.oisyn schreef op vrijdag 17 december 2004 @ 11:09:
Realtime is heel wat anders, ik heb het gewoon over pure performance. Realtime hoeft niet snel te zijn, het zegt puur dat je garanties kan geven over hoe lang iets duurt en dat het binnen die tijd ook echt klaar is.
Ik noem C++ voor realtime aangezien managed code niet voldoet. Als je de verscheiden tests bekijkt zul je zien dat er niet noemenswaardig veel verschil tussen de twee zit qua performance. Performance is dan alleen een issue als de hardware met geen mogelijkheid kan worden geupgrade. En dat is in de regel vrij weinig.
Lees eerst voordat je blaat, ik beweer nergens dat C++ programmeurs duurder zijn dan andere programmeurs. Ik zeg alleen dat een dagje programmeren/ontwikkelen klauwen met geld kost. Dus een dagje met zijn allen werken aan de performance van een applicatie is vaak onzinnig omdat je net zo goed een tweede server kunt kopen.
.oisyn schreef op vrijdag 17 december 2004 @ 11:09:
En wie zegt dat een dergelijke webinterface niet voor C++ bestaat? Sterker nog, je kunt in native C++ ook gewoon managed C++ gebruiken en dus heb je direct toegang tot een hele mooie webinterface.
Het gaat er absoluut niet om of het bestaat. Dat is compleet irrelevant. Waar het om gaat is het aanbod van programmeurs en het zo snel mogelijk vertalen van de bedrijfslogica naar correcte code. Voorwaarde zijn dus defacto standaard frameworks. Dat is waar het om gaat, niet of het wel of niet kan.

php heeft bijvoorbeeld smarty
java heeft spring, struts, hibernate, acegi, j2ee

Acties:
  • 0 Henk 'm!

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op vrijdag 17 december 2004 @ 12:07:
Ik noem C++ voor realtime aangezien managed code niet voldoet. Als je de verscheiden tests bekijkt zul je zien dat er niet noemenswaardig veel verschil tussen de twee zit qua performance. Performance is dan alleen een issue als de hardware met geen mogelijkheid kan worden geupgrade. En dat is in de regel vrij weinig.
Dat hangt ervan af wat het performance verschil tussen een C++ en PHP oplossing is. En hoeveel instances van de code er draaien.
Lees eerst voordat je blaat, ik beweer nergens dat C++ programmeurs duurder zijn dan andere programmeurs. Ik zeg alleen dat een dagje programmeren/ontwikkelen klauwen met geld kost. Dus een dagje met zijn allen werken aan de performance van een applicatie is vaak onzinnig omdat je net zo goed een tweede server kunt kopen.
Een beetje nadenken en slim design is vaak al voldoende voor veel betere performance.
Dat zo'n design in PHP misschien niet mogelijk is betekent niet dat het in C++ (veel) extra tijd kost.
Het gaat er absoluut niet om of het bestaat. Dat is compleet irrelevant. Waar het om gaat is het aanbod van programmeurs en het zo snel mogelijk vertalen van de bedrijfslogica naar correcte code. Voorwaarde zijn dus defacto standaard frameworks. Dat is waar het om gaat, niet of het wel of niet kan.

php heeft bijvoorbeeld smarty
java heeft spring, struts, hibernate, acegi, j2ee
Als zo'n framework voor C++ ook bestaat, dan is dat toch wel relevant?

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op vrijdag 17 december 2004 @ 12:07:
[...]
Ik noem C++ voor realtime aangezien managed code niet voldoet. Als je de verscheiden tests bekijkt zul je zien dat er niet noemenswaardig veel verschil tussen de twee zit qua performance. Performance is dan alleen een issue als de hardware met geen mogelijkheid kan worden geupgrade. En dat is in de regel vrij weinig.
Dat werkt misschien als je software op maat maakt, maar als je met je product een heel bereik aan klanten aanspreekt dan kun je niet van hen eisen dat ze allemaal maar een server upgrade doen, alleen om de software te kunnen draaien. Denk je dat de mensen van Parse geen tijd hebben gestoken in optimalisaties en gewoon maar tegen t.net hebben gezegd dat ze hun serverpark uit moesten breiden? Echt niet.

En voor de rest sluit ik me aan bij OlafvdSpek.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

Verwijderd

even vooraf, ik had mijn performance vergelijking vooral gebaseerd op java vs c++, niet op c++ versus php.
.oisyn schreef op vrijdag 17 december 2004 @ 12:50:Dat werkt misschien als je software op maat maakt,
En punt. Het gaat hier in dit hele topic over software op maat.

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op vrijdag 17 december 2004 @ 13:00:
even vooraf, ik had mijn performance vergelijking vooral gebaseerd op java vs c++, niet op c++ versus php.
En ik reageerde slechts op iemand die zei dat C++ niet geschikt zou zijn om een webapp mee te developen.
En punt. Het gaat hier in dit hele topic over software op maat.
Niet de hele topic dus blijkbaar.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

Verwijderd

.oisyn schreef op vrijdag 17 december 2004 @ 13:07:
En ik reageerde slechts op iemand die zei dat C++ niet geschikt zou zijn om een webapp mee te developen.
Geschikt, je kunt het met de taal realiseren
Ongeschikt, het is veel te duur

En de laatste weegt uiteraard vele malen zwaarder :)

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

En dat te duur is iets waar ik gewoon niet in geloof. Het hoeft niet langer te duren, dus waarom zou het duurder zijn?

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

Verwijderd

.oisyn schreef op vrijdag 17 december 2004 @ 13:33:
En dat te duur is iets waar ik gewoon niet in geloof. Het hoeft niet langer te duren, dus waarom zou het duurder zijn?
Kom op kerel, dan ga ik in herhaling treden. Dit heb ik nou wel duidelijk gemaakt. Geloof je het niet, dan is dat domweg een logge houding.

Acties:
  • 0 Henk 'm!

Verwijderd

.oisyn schreef op vrijdag 17 december 2004 @ 13:33:
En dat te duur is iets waar ik gewoon niet in geloof. Het hoeft niet langer te duren, dus waarom zou het duurder zijn?
waar betaal jij meer voor, php-er of iemand die c++ kan?

Acties:
  • 0 Henk 'm!

  • Erkens
  • Registratie: December 2001
  • Niet online

Erkens

Fotograaf

Verwijderd schreef op vrijdag 17 december 2004 @ 13:42:
[...]


waar betaal jij meer voor, php-er of iemand die c++ kan?
iemand met kennis

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op vrijdag 17 december 2004 @ 13:40:
[...]
Kom op kerel, dan ga ik in herhaling treden. Dit heb ik nou wel duidelijk gemaakt. Geloof je het niet, dan is dat domweg een logge houding.
Nee, jouw redenatie was gebaseerd op het feit dat je in C++ nog een heel framework moet ontwikkelen, we gingen er even vanuit dat die er al was (zie onderste regel van OlafvdSpek in "[JAVA] vs [PHP] wat is de meerwaarde?").
Verwijderd schreef op vrijdag 17 december 2004 @ 13:42:

waar betaal jij meer voor, php-er of iemand die c++ kan?
Ik zou een php-er sowieso niet betalen, daar heb ik niets aan ;)
Maar even serieus, daar hebben we het al over gehad en dat was geen issue

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

Verwijderd

Je kunt beter helemaal niets zomaar roepen zolang je er (nog) niet veel ervaring mee hebt ;)
Geloof me, dat zal ik ook niet meer doen als ik naar de antwoorden op m'n post kijk :) Maar het ging zich dus gewoon om het voorbeeld. Enfin...
Ik denk dat jouw beeld van een webapplicatie toch meer iets van een simpel pagina-genererend iets is dat een verbinding heeft met een bepaalde database (zoals de meeste projecten die in PHP geimplementeerd worden).
Dan heb ik je het verkeerde idee gegeven.
Dat is toch geen keuze die je hebt? Als je een webapp moet maken die goed moet performen, dan kun je toch niet kiezen om dan maar geen webapp te maken? Waarom zou een webapplicatie niet gewoon goede performance nodig kunnen hebben?
Mijn punt was dus dat bij WebApps op andere plaatsen een veel relevantere performance gain kan worden gehaald, dan de relatief lage gain die je zou bereiken door voor C++ te kiezen voor je WebApp.

Bijvoorbeeld bij het weergeven van database gegevens. Dit kan idd in een webapp (phpMyAdmin), maar het opbouwen van de HTML op de client alleen al duurt waarschijnlijk langer dan de hele server-side processing. In dit geval is een desktop applicatie met specifieke code en GUI voor dit soort data (MySQLFront) misschien een beter keuze.

Hetzelfde geldt voor jouw voorbeeld van een online spel. Door bijvoorbeeld een applet of Flash te gebruiken op de client ipv. (D)HTML verbeter je de performance van de gehele omgeving (dus client en server, want dat is tenslotte de 'webapp') waarschijnlijk meer dan door je backend in C++ te gaan schrijven.

En dan nog, hoe ga je vanuit je applet communiceren met je backend? Als je het netjes wilt doen via SOAP en anders via standaard HTTP requests. Ik waag te beweren dat in het licht van de overhead van deze request de performance gain die je met C++ kunt behalen in het niet valt.

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op vrijdag 17 december 2004 @ 13:49:
Bijvoorbeeld bij het weergeven van database gegevens. Dit kan idd in een webapp (phpMyAdmin), maar het opbouwen van de HTML op de client alleen al duurt waarschijnlijk langer dan de hele server-side processing. In dit geval is een desktop applicatie met specifieke code en GUI voor dit soort data (MySQLFront) misschien een beter keuze.

Hetzelfde geldt voor jouw voorbeeld van een online spel. Door bijvoorbeeld een applet of Flash te gebruiken op de client ipv. (D)HTML verbeter je de performance van de gehele omgeving (dus client en server, want dat is tenslotte de 'webapp') waarschijnlijk meer dan door je backend in C++ te gaan schrijven.
Maar je vergeet nu even compleet de mogelijke complexiteit van de logic aan de serverkant, die wel degelijk performance nodig kan hebben! En nee dan heb ik het niet over het snel afhandelen van de requests an sich, daar heb je de webserver voor. Ik heb het over de acties die ondernomen moeten worden in reactie op de request.

[ Voor 10% gewijzigd door .oisyn op 17-12-2004 13:53 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

Verwijderd

.oisyn schreef op vrijdag 17 december 2004 @ 13:51:
[...]


Maar je vergeet nu even compleet de mogelijke complexiteit van de logic aan de serverkant, die wel degelijk performance nodig kan hebben! En nee dan heb ik het niet over het snel afhandelen van de requests an sich, daar heb je de webserver voor. Ik heb het over de acties die ondernomen moeten worden in reactie op de request.
Ik denk dat we hier nooit uit gaan komen :)

In mijn ogen is de complexiteit van de logic aan de serverkant inderdaad niet zo gigantisch spannend. Als je het over echt complexe logic hebt, waar heb je het dan over?

Gegevensverwerking? Daar heb je een DBMS of ander systeem voor om dat mooi op te lossen, waar je webapp weer gebruik van kan maken. Complexe business logic? Delegeer het maar naar het ERP systeem. Bewerken van afbeeldingen? Ook daar heeft zo'n elke webapp taal wel een efficiente library voor die dit voor je kan oplossen. Etc.

Ik ben het met je eens dat het theoretisch mogelijk is dat je zo'n complexe actie moet ondernemen op een request dat je deze extra performance & efficiency van C++ zou kunnen gebruiken, maar ik weet zo snel dus echt niet waarvoor ik het zou moeten gebruiken. Als je een concreet voorbeeld weet dan hoor ik het graag en geef ik me gewonnen ;)

[ Voor 4% gewijzigd door Verwijderd op 17-12-2004 14:12 ]


Acties:
  • 0 Henk 'm!

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op vrijdag 17 december 2004 @ 13:49:
En dan nog, hoe ga je vanuit je applet communiceren met je backend? Als je het netjes wilt doen via SOAP en anders via standaard HTTP requests. Ik waag te beweren dat in het licht van de overhead van deze request de performance gain die je met C++ kunt behalen in het niet valt.
De performance gain bekeken vanuit het punt van een client op een unloaded server. Dat klopt, daar veranderd (vaak) niet zo veel aan.
Het gaat juist om de performance op een 'loaded' server. Als je per request 2x zoveel CPU tijd (of HDD/IO 'tijd') nodig hebt, kun je gewoon 2x zo weinig clients serven. Het gaat dus meer om throughput dan latency.

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op vrijdag 17 december 2004 @ 14:10:
Als je een concreet voorbeeld weet dan hoor ik het graag en geef ik me gewonnen ;)
www.tdzk.com ;)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op vrijdag 17 december 2004 @ 13:00:
even vooraf, ik had mijn performance vergelijking vooral gebaseerd op java vs c++, niet op c++ versus php.
Hmm, volgens mij heeft de rest het juist over C++ vs PHP of Java vs PHP, niet C++ vs Java.
In C++ en Java kun je ongeveer hetzelfde design gebruiken, dus daar is het performance verschil zoiezo minder.

Acties:
  • 0 Henk 'm!

Verwijderd

Afbeeldingslocatie: http://www.netforge.nl/rommel/flag.gif


... http://www.tdzk.com/external/statistics.php ... >:) ;)

[ Voor 38% gewijzigd door Verwijderd op 17-12-2004 14:44 ]


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Ja heel TDZK is in php gemaakt, het loopt dan ook niet zo heel erg soepel :)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • Grijze Vos
  • Registratie: December 2002
  • Laatst online: 28-02 22:17
Verwijderd schreef op donderdag 16 december 2004 @ 15:46:
[...]


Goed gezegd! Je moet van taal switchen als de nieuwe taal features heeft die de oude, of andere, niet heeft. Dat geldt voor PHP niet. Het is alleen anders, zelfs 'iets' minder. Zelfs de grootste PHP fans zullen moeten toegeven dat het iniedergeval niet beter is als Java (en dan doel ik alleen op de pure, kale, taal syntax & semantics, niet over welke libs je hebt of hoe het platform werkt).
Euh, wrong. Ik vind PHP een fijnere, betere taal dan Java. Gebruik Objectieven argumenten a.u.b., geen subjectieve.
Zoals Java laat zien, is het niet nodig om voor web applicaties een nieuwe taal te introduceren. Je kunt gewoon de bestaande taal blijven gebruiken. Dat is handig, want heel veel utility classes die ik heb kan ik gewoon meenemen als ik een web app maak. Speciale algortimes, code om plaatjes te maken, de voorbeelden die in de quote genoemt werden, etc etc. Ik kan het zo meenemen.
Dit is geen strict Java vs PHP argument. Maar eerder (net als je hierboven aangeeft) een switch-argument. Waarom zou je moeten switchen van Java naar PHP. Laat mij die vraag omdraaien. Neem een doorgewinterde PHP-programmeur. Eentje die geen prutser is, en al zoveel generieke classes heeft (en zelfs allemaal omgebouwd naar PHP5 ;)). Waarom zou hij dan moeten switchen naar Java voor webapps? Je argument raakt kant noch wal.
Verwijderd schreef op donderdag 16 december 2004 @ 15:52:

Inderdaad. Zoals gezegd, Java is universeel inzetbaar: Web apps, de desktop (bv Eclipse, maar ook vele andere tools), commandline apps, en embedded.
Hier kom ik later in mn post op terug.
Tevens gebruiken heel veel opleidingen, zowel HBO als Universiteit, Java. Op sommige universiteiten is het de 'hoofdtaal' (bv de VU), op andere wordt het voor sommige vakken gebruikt (UL).
Ik zal je dan even uit de droom helpen. TU/e, wat heb ik geleerd. Hmz, begonnen met Pascal, toen algoritmen leren ontwikkelen in GCL (Guarded Command Language, kennen jullie verder vast niet, is ook geen ge-implementeerde taal.), daarna hebben we C gebruikt, toen PHP voor een webwinkel. (Ja, met heuse business logic erachter.) En ook nog ergens wat assembly tussendoor. Al met al redelijk gevarieerd dus.

Vraagje? Heb je zelf een universitaire opleiding gedaan? Ik kan niet spreken namens HBO opleidingen, maar een van de eerste dingen die je leert op de universiteit is dat een taal een middel is, en geen doel. Wij 'leren' dus ook geen talen, wij 'gebruiken' talen. Een taal leren doe je maar in je vrije tijd, is het idee.

Als er werkelijk hier iemand is die zegt dat het beter is om een project met webshops op de universiteit in Java te doen dan in PHP, dan lach ik hem vierkant uit. Het leerporces zit hem niet in het uiteindelijk afgemaakte product, maar in de stappen die leiden tot dat product. En als je eerst 5 weken aan het kutten bent om Java onder de knie te krijgen, blijft er weinig tijd over om een zinnige implementatie te maken. PHP heeft een lichtere leercurve dan Java, en is in dat opzicht dus juist een geschikte taal om in het onderwijs te gebruiken.
Daarentegen is PHP alleen voor web applicaties bedoeld en wordt het niet op het HBO of WO onderwezen.
Fout dus. Zie mijn webshop voorbeeld. En ik ken zat HBO-ers die voor stages dingen in PHP hebben gemaakt. Vast voor 'gewone' schoolopdrachten ook wel, maar dat zou ik moeten navragen.
In sommige gevallen is het beter om iets te hebben wat 1 ding goed doet dan veel dingen matig. Dit -zou- een argument -voor- PHP kunnen zijn, behalve dat PHP helemaal geen features heeft die uitzonderlijk goed in een web omgeving uitgebuit kunnen worden. Zoals uit deze thread blijkt kan het alleen maar minder dan een universele taal zoals Java of C#.
Overtuig mij er eens van dat een Java-webapp implementatie sneller is in string en array manipulaties dan PHP?
Gelukkig zegt iemand hier wel nog wat zinnigs. Er zijn dus hier mensen, die, als ik ze moet geloven. Liever iemand aannemen omdat hij Java doet en geen PHP. Ik zou zeggen, kijk wat ze kunnen, ipv waarin ze het liefste werken. Maar goed, dit is weer hetzelfde argument wat ik al eerder gebruiktte. Er zijn zat prutsers die java doen. Je komt alleen eerder in aanraking met PHP-prutsers, omdat java-gepruts vaak niet web-related is; en omdat er teveel niet-programmeurs zijn die zich met PHP bezig houden.
Dit is een perfect voorbeeld van de multi-inzetbaarheid van PHP. Henk_de_man gaf aan dat java zo universeel was, etc..etc.. Nou, PHP is misschien niet geschikt voor desktop application use. Maar het is in te zetten op de commandline. (Doe ik zelf met redelijk wat dingen, te lui om bash-scripting fatsoenlijk te leren. }) )

Verder is PHP prima te combineren met andere talen. Laat een PHP script lekker de frontend doen, en doe het 'dure' werk met C++ bijvoorbeeld. Een perfect voorbeeld hiervan is .oisyn's highlighter. Dat is een in C++ geschreven module voor PHP use. Dat java 'alles kan' wil niet zeggen dat het 'alles het beste kan'.

Ik weet niet meer wie het had geschreven, maar ik las ergens hierboven iets van code copy/pasten binnen java. Als je Java's genericiteit en uitbreidbaarheid als sterk punt voor Java wilt aanprijzen, kom dan alsjeblieft niet met ranzige dingen als copy/pasten aanzetten. Bah.

sorry voor de lange post en voor het replyen op posts van 3 pages terug, ben een paar dagen niet actief geweest op GOT.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Grijze Vos schreef op vrijdag 17 december 2004 @ 14:56:
Dit is geen strict Java vs PHP argument. Maar eerder (net als je hierboven aangeeft) een switch-argument. Waarom zou je moeten switchen van Java naar PHP. Laat mij die vraag omdraaien. Neem een doorgewinterde PHP-programmeur. Eentje die geen prutser is, en al zoveel generieke classes heeft (en zelfs allemaal omgebouwd naar PHP5 ;)). Waarom zou hij dan moeten switchen naar Java voor webapps? Je argument raakt kant noch wal.
Omdat (oa) Java een andere, meer maintainable approach geeft. PHP is heel erg request based en behoorlijk stateless, alles wordt keer op keer opnieuw geparsed, gecompiled en uitgevoerd, connecties worden aangemaakt en weer verbroken, alle persistente data moet steeds opnieuw worden ingeladen. Ik kan me voorstellen dat je op een gegeven moment liever hebt dat je een persistente app hebt, en dat er een bepaalde functie in je app wordt aangeroepen op het moment dat er een request binnenkomt. De data staat dan gewoon al in het geheugen en je kunt je puur concentreren op het afhandelen van de request. Plus dat je nog dingen kunt doen op het moment dat je geen request af hoeft te vangen, wat in PHP een stuk trickier is.

Al met al kan ik me dus goed voorstellen dat je op een gegeven moment over wilt schakelen als je meer uit een systeem wilt halen dan PHP je kan bieden.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Grijze Vos schreef op vrijdag 17 december 2004 @ 14:56:
Dit is geen strict Java vs PHP argument. Maar eerder (net als je hierboven aangeeft) een switch-argument. Waarom zou je moeten switchen van Java naar PHP. Laat mij die vraag omdraaien. Neem een doorgewinterde PHP-programmeur. Eentje die geen prutser is, en al zoveel generieke classes heeft (en zelfs allemaal omgebouwd naar PHP5 ;)). Waarom zou hij dan moeten switchen naar Java voor webapps? Je argument raakt kant noch wal.
Wie zegt dat hij moet switchen?
Er is alleen gezegd dat het waarschijnlijk(er) is dat een organisatie of persoon ook gewone apps maakt en dat die niet in PHP maar in C++ of Java geschreven zijn.
Verder is PHP prima te combineren met andere talen. Laat een PHP script lekker de frontend doen, en doe het 'dure' werk met C++ bijvoorbeeld.
Dat werkt alleen als je dure pure functies hebt (die dus geen of weinig non-local state gebruiken).

[ Voor 15% gewijzigd door Olaf van der Spek op 17-12-2004 15:21 ]


Acties:
  • 0 Henk 'm!

Verwijderd

.oisyn schreef op vrijdag 17 december 2004 @ 13:49:
Nee, jouw redenatie was gebaseerd op het feit dat je in C++ nog een heel framework moet ontwikkelen,
Dat maak jij er van, maar dat heb ik niet gezegd. Zo schiet zo'n discussie niet op als mensen maar op een Andries Knevel wijze woorden in andermans mond gaan leggen.

Acties:
  • 0 Henk 'm!

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op vrijdag 17 december 2004 @ 15:30:
[...]
Dat maak jij er van, maar dat heb ik niet gezegd. Zo schiet zo'n discussie niet op als mensen maar op een Andries Knevel wijze woorden in andermans mond gaan leggen.
Hoe moet het volgende dan geinterpreteerd worden?
Voorwaarde zijn dus defacto standaard frameworks. Dat is waar het om gaat, niet of het wel of niet kan.

php heeft bijvoorbeeld smarty
java heeft spring, struts, hibernate, acegi, j2ee

Acties:
  • 0 Henk 'm!

Verwijderd

defacto standaard, veel groter bereik dus. Zo moet dat geinterpreteerd worden :)

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Dus jij wil zeggen dat het ontwikkelen op een niet defacto standaard API velen malen meer geld kost? Kom nou, je zult altijd programmeurs aannemen die niet alles van een systeem afweten, en de goede programmeurs zijn degene die zich een nieuw systeem goed kunnen aanleren. Dat nog eens naast het feit dat je als bedrijf waarschijnlijk toch al een systeem bovenop de standaard API hebt liggen waar de programmeur sowieso bekend mee moet raken, dus nu zit je imho een beetje onzin te verkondigen (en komt het meer over als je gelijk halen ipv met valide argumenten de discussie voortzetten)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

Verwijderd

Aangezien dit topic toch al helemaal stuurloos is, wil ik nog even 1 ding kwijt wat ik zo geweldig vind aan PHP.

Er is vaak het argument tegen PHP aangehaald in dit topic dat het elke keer opnieuw wordt geparsed, dat het nogal rommelig met fouten omgaat en dat types ontbreken. Dat mag dan wel zo zijn, maar daarvoor krijg je wel een ongelofelijke dynamiek en vrijheid voor terug.

Als voorbeeld heb ik iets wat ik net heb gemaakt voor m'n PHP webapp (jaja, af en toe werk ik ook nog ;) ). Ik moet bepaalde events naar het Windows event log kunnen schrijven. De gewone PHP syslog voldoet niet omdat ik m'n events graag in een log wil zetten waarin alleen events van mijn applicaties komen te staan. Dus heb ik ff een kleine utility class geschreven in C# en deze als COM lib geregistreerd. Nu kan ik in PHP het volgende doen:

PHP:
1
2
$sysLog = new COM ("LogLibrary.SysLog"); 
$sysLog->Log("App name", "Event title", "Event message", E_USER_WARNING);


Probeer dat maar eens op een ander platform :7 :)

[ Voor 8% gewijzigd door Verwijderd op 17-12-2004 15:52 . Reden: Ik kan echt niet ypen vandaag ]


Acties:
  • 0 Henk 'm!

Verwijderd

.oisyn schreef op vrijdag 17 december 2004 @ 15:45:
Dus jij wil zeggen dat het ontwikkelen op een niet defacto standaard API velen malen meer geld kost? Kom nou, je zult altijd programmeurs aannemen die niet alles van een systeem afweten, en de goede programmeurs zijn degene die zich een nieuw systeem goed kunnen aanleren. Dat nog eens naast het feit dat je als bedrijf waarschijnlijk toch al een systeem bovenop de standaard API hebt liggen waar de programmeur sowieso bekend mee moet raken, dus nu zit je imho een beetje onzin te verkondigen
Euh nee, want je begint al met een misvatting. Ze hoeven niet allemaal alles te weten, maar wel zoveel als mogelijk. Daar zit domweg een kosten post, hoe je het ook went of keert.
.oisyn schreef op vrijdag 17 december 2004 @ 15:45:
(en komt het meer over als je gelijk halen ipv met valide argumenten de discussie voortzetten)
Ik ga graag verder met argumenten zoals ik al de hele tijd doe. Dat is wat anders dan op voorhand verkondigen dat is onzin is, dus houd dit soort commentaar voor je want jij bent de laatste die het recht heeft dat als argument te gebruiken.

Acties:
  • 0 Henk 'm!

  • Olaf van der Spek
  • Registratie: September 2000
  • Niet online
Verwijderd schreef op vrijdag 17 december 2004 @ 15:55:
Euh nee, want je begint al met een misvatting. Ze hoeven niet allemaal alles te weten, maar wel zoveel als mogelijk. Daar zit domweg een kosten post, hoe je het ook went of keert.
Welk deel van de kosten van het ontwikkelen van een web app zitten in het leren van een framework?

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op vrijdag 17 december 2004 @ 15:55:
[...]

Euh nee, want je begint al met een misvatting. Ze hoeven niet allemaal alles te weten, maar wel zoveel als mogelijk. Daar zit domweg een kosten post, hoe je het ook went of keert.
en dus moet je geen C++ gebruiken om een webapp in te ontwikkelen, ongeacht de eisen van die webapp? Kom nou.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

Verwijderd

Kom op .Oisyn, hij heeft wel een punt.

Het is moeilijker om C++ goed te leren gebruiken dan Java of PHP en C++ heeft inderdaad minder uitgebreide libs specifiek voor webapps. Als je inderdaad kijkt naar de standaard frameworks die bestaan voor andere platforms is het meestal minder aantrekkelijk om C++ te gebruiken, simpelweg omdat het te veel tijd (=geld) kost voordat de gemiddelde programmeur ermee uit de voeten kan.

Je ziet het een beetje zwart-wit. Mark beweert, zoals ik, niet dat je nooit C++ moet gebruiken voor een webapp, maar we geven gewoon aan dat het meestal gewoon niet praktisch is.

[ Voor 4% gewijzigd door Verwijderd op 17-12-2004 16:53 ]


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 12:32

.oisyn

Moderator Devschuur®

Demotivational Speaker

Daar ben ik het helemaal mee eens, en dan moet ie er niet op ingaan als ik zeg dat je in sommige gevallen wel voor C++ zou kiezen :)

Ik heb nooit beweerd dat het gebruik van C++ net zo handig is als php of java, voor een web interface. Alleen dat er wel situaties denkbaar zijn waarin het gebruik van C++ voordelen heeft tov andere talen (en dan bedoel ik dus dat de voordelen wél opwegen tegen de nadelen).

.edit: ik moet wel toegeven, nu ik de posts allemaal nog eens doorlees, dat ik zelf ook wel schuldig ben aan het te zwart-wit opvatten van bepaalde opmerkingen. Mijn excuses daarvoor :)

[ Voor 136% gewijzigd door .oisyn op 17-12-2004 17:46 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • PrisonerOfPain
  • Registratie: Januari 2003
  • Laatst online: 26-05 17:08
Verwijderd schreef op vrijdag 17 december 2004 @ 15:47:
PHP:
1
2
$sysLog = new COM ("LogLibrary.SysLog"); 
$sysLog->Log("App name", "Event title", "Event message", E_USER_WARNING);


Probeer dat maar eens op een ander platform :7 :)
COM objecten aanspreken? Mocht dat zo zijn;
Visual Basic .NET:
1
2
3
Dim X
X = CreateObject("LogLibrary.SysLog")
X.Log("","","", <getal>)

Of,
Delphi:
1
X := CreateOleObject("LogLibrary.SysLog");


Of mis ik je punt?

[ Voor 13% gewijzigd door PrisonerOfPain op 17-12-2004 18:19 . Reden: Syntax... ]


Acties:
  • 0 Henk 'm!

Verwijderd

Een beetje. COM objecten aanspreken is idd niet zo bijzonder, maar PHP zorgt er zonder wrappers of wat dan ook voor dat je de methods & properties op het COM object kunt aanroepen alsof je met een PHP object te maken hebt. Dat VB dit kan mag ook wel, aangezien het hele COM gebeuren het idee van MS is, maar ik vond het gewoon mooi dat ze PHP ook zo flexibel hebben gemaakt. Hetzelfde kan in PHP trouwens ook met Java objecten en rechtstreeks met .NET classes (zonder COM interop, maar da's nog experimenteel).

Maar goed, ik stop met posten in deze thread. Elke keer als ik een voorbeeld aanhaal kan ik weer nog verder off-topic gaan uitleggen wat ik bedoel. Zo zijn we op C++ gekomen en nu zijn we weer aan het discussieren over hoe makkelijk je ook in andere talen COM objecten kunt aanroepen.

Afbeeldingslocatie: http://www.netforge.nl/rommel/flag.gif Afbeeldingslocatie: http://www.netforge.nl/rommel/flag.gif Afbeeldingslocatie: http://www.netforge.nl/rommel/flag.gif Afbeeldingslocatie: http://www.netforge.nl/rommel/flag.gif Afbeeldingslocatie: http://www.netforge.nl/rommel/flag.gif Afbeeldingslocatie: http://www.netforge.nl/rommel/flag.gif Afbeeldingslocatie: http://www.netforge.nl/rommel/flag.gif Afbeeldingslocatie: http://www.netforge.nl/rommel/flag.gif :)

Acties:
  • 0 Henk 'm!

  • -FoX-
  • Registratie: Januari 2002
  • Niet online

-FoX-

Carpe Diem!

Topicstarter
Om maar weer even ontopic te gaan, heb ik alle genoemde feiten maar eens op een rij'tje gezet. Of ze al dan niet correct zijn, laat ik even in het midden en ik wacht jullie commentaren rustig af.

Voordelen Java t.o.v. PHP
  • [small]
  • De Java programmeertaal is en blijkt uiteindelijk meer volwassen dan de PHP scripttaal.
  • In PHP is er geen aparte applicatielogica mogelijk, alle applicatielogica wordt in de scripts zelf afgehandeld.
  • PHP is een pure presentatietaal, vergelijkbaar met JSP; J2EE biedt zoveel meer zoals transactions, lifecycle management, networking, database access, threads, dynamic objects.
  • PHP werkt niet met strong typing; Er worden dus gemakkelijker fouten gemaakt. Dit resulteert in het feit dat de code niet gestructureerd is.
  • In PHP moeten de variabelen niet gedeclareerd worden. Op deze manier is het mogelijk dat er een waarde aan een niet bestaande variabele gegeven wordt (door bvb een tikfout). Er zal ook geen enkele foutmelding of warning getoond worden. Probeer zo maar eens bij grotere projecten je fouten eruit te halen en te verklaren dat je code bugvrij is!
  • PHP draait niet in-process, maar is een externe executable die voor iedere pagina die op de server geparsed wordt, opnieuw wordt uitgevoerd.
  • Java biedt zeer uitgebreide foutboodschappen, hierin is PHP zeer cryptisch en is de fout soms ver te zoeken.
  • Java biedt een nette manier om de globale web instellingen onder te brengen onder 1 web configuratiebestand.
  • PHP wordt niet gecompileerd. De code kan dus nog fouten, zowel semantische als syntaxische, bevatten. Java biedt deze vorm van correctheid reeds, het compileert! Op deze manier hebben we bij een Java applicatie meer zekerheid!!
  • Java wordt ondersteund door grote bedrijven (Sun, IBM, ..) waardoor de toekomst die Java heeft eens temeer verzekert wordt
  • In de Java taal wordt goed gedefinieerd wat wel en niet compatible is en blijft.
  • In Java wordt de code nog aan extra testen onderworpen: unit testing, regressie-testen,
    db-testing, http-testing, integration-testen, ... dit biedt zekerheid op consistente code!
  • Java ondersteund security, transacties, monitoring & logging van de code, PHP niet!
  • De TCO ligt over het algemeen lager bij een Java applicatie.
  • Een Java applicatie is beter uitbreidbaar door de opdeling in verschillende tiers (presentatie, controller, business logic, database, ..)
  • Refactoring (optimaliseren van de code), kan veel sneller en consistenter in Java.
  • Waarom wordt er nooit PHP gebruikt in kritische applicaties zoals e-banking e.d. maar wel Java?
  • Er zijn complexe en daarmee duidelijke foutafhandeling systemen in Java!
  • Java bevat: application/session/request/page scope, php mist deze request scope.
  • PHP biedt geen duidelijke en mooie onderscheiding van code --> alle code staat los door elkaar.
  • [/small]

Acties:
  • 0 Henk 'm!

  • Grijze Vos
  • Registratie: December 2002
  • Laatst online: 28-02 22:17
-FoX- schreef op vrijdag 17 december 2004 @ 20:33:
Om maar weer even ontopic te gaan, heb ik alle genoemde feiten maar eens op een rij'tje gezet. Of ze al dan niet correct zijn, laat ik even in het midden en ik wacht jullie commentaren rustig af.

Voordelen Java t.o.v. PHP
De Java programmeertaal is en blijkt uiteindelijk meer volwassen dan de PHP scripttaal.
Ontzettend flauwe kleinering van PHP. Maar je kunt java volwassener noemen.
In PHP is er geen aparte applicatielogica mogelijk, alle applicatielogica wordt in de scripts zelf afgehandeld.
Pure onzin. Je kunt aparte scripts maken met de applicatie logica. Het zit dan wel in 'PHP-scripts', maar het is nog steeds gescheiden. Dat ze bij Java toevallig wel onderscheid maken tussen frutseltjes die HTML genereren en 'gewone' code, boeit verder niet.
PHP is een pure presentatietaal, vergelijkbaar met JSP; J2EE biedt zoveel meer zoals transactions, lifecycle management, networking, database access, threads, dynamic objects.
transactions in PHP, check.
database access, check
threads, ok, die heb je niet echt in php.
dynamic objects, check.

lifecycle management is ook wel te implementeren (als ik google's definitie mag geloven.), en wat je met networking bedoeld weet ik niet, zo losstaand is het mij een te vage term.
PHP werkt niet met strong typing; Er worden dus gemakkelijker fouten gemaakt. Dit resulteert in het feit dat de code niet gestructureerd is.
Met andere woorden: jij kunt niet goed coden en hebt daarom strong typing nodig? Strong typing is afhankelijk van de stijl van de programmeur, en is naar mijn mening absoluut -niet- een feature te noemen boven PHP.
In PHP moeten de variabelen niet gedeclareerd worden. Op deze manier is het mogelijk dat er een waarde aan een niet bestaande variabele gegeven wordt (door bvb een tikfout). Er zal ook geen enkele foutmelding of warning getoond worden. Probeer zo maar eens bij grotere projecten je fouten eruit te halen en te verklaren dat je code bugvrij is!
Onzin. Kwestie van goed programmeren. Juist door gestructureerd te werken voorkom je dit soort fouten en je krijgt -WEL- een warning of notice als je dit soort fratsen doet.
PHP draait niet in-process, maar is een externe executable die voor iedere pagina die op de server geparsed wordt, opnieuw wordt uitgevoerd.
klopt. Hoeft niet altijd een nadeel te zijn.
Java biedt zeer uitgebreide foutboodschappen, hierin is PHP zeer cryptisch en is de fout soms ver te zoeken.
Valt wel mee. Kwestie van een paar keer ermee werken en je weet het. Mager argument, maar wel een van je zinnigste tot nu toe.
Java biedt een nette manier om de globale web instellingen onder te brengen onder 1 web configuratiebestand.
PHP ook.
PHP wordt niet gecompileerd. De code kan dus nog fouten, zowel semantische als syntaxische, bevatten. Java biedt deze vorm van correctheid reeds, het compileert! Op deze manier hebben we bij een Java applicatie meer zekerheid!!
http://www.zend.com/store...elerator-how-it-works.php
Daar, parsing naar bytecode. Exact zelfde als jouw Java.

En verder, test je je code niet voordat je het draait? Een php page "runnen" is ook een vorm van 'compileren'. Het geheel wordt op syntax getest.
Java wordt ondersteund door grote bedrijven (Sun, IBM, ..) waardoor de toekomst die Java heeft eens temeer verzekert wordt
PHP wordt gebruikt in meer dan 75% van de dynamische webpages. Iets wat PHP's toekomst verzekerd. (Hoe maakt dit de taal an sich beter, btw?)
In de Java taal wordt goed gedefinieerd wat wel en niet compatible is en blijft.
Ok.
In Java wordt de code nog aan extra testen onderworpen: unit testing, regressie-testen,
db-testing, http-testing, integration-testen, ... dit biedt zekerheid op consistente code!
Dus in PHP gebeurd dit niet? Deze tests hoor je in elke taal te doen.
Java ondersteund security, transacties, monitoring & logging van de code, PHP niet!
Ondersteund het wel. Waarom is dit niet te implementeren in PHP? Er is op het moment misschien geen 'framework' voor, wil niet zeggen dat het niet kan.
De TCO ligt over het algemeen lager bij een Java applicatie.
Dat mag je me dan wel eens voorrekenen.
Een Java applicatie is beter uitbreidbaar door de opdeling in verschillende tiers (presentatie, controller, business logic, database, ..)
Die tiers kun je -ook- bouwen in PHP. Kun je dat niet, ben je mijn inziens gewoon een slechte programmeur. Weerom een non-argument.
Refactoring (optimaliseren van de code), kan veel sneller en consistenter in Java.
In PHP is refactoring vaak niet nodig, dankzij de dynamiek van de taal.
Waarom wordt er nooit PHP gebruikt in kritische applicaties zoals e-banking e.d. maar wel Java?
Omdat PHP niet de allerbeste security biedt. Waarom wordt Java niet gebruikt bij meer dan 75% van de dynamisch gegenereerde webpages?
Er zijn complexe en daarmee duidelijke foutafhandeling systemen in Java!
PHP kent ook foutafhandeling systemen. En complex wil niet per se zeggen duidelijk.
Java bevat: application/session/request/page scope, php mist deze request scope.
Mja, aard van het beestje. Hoeft niet altijd erg te zijn.
PHP biedt geen duidelijke en mooie onderscheiding van code --> alle code staat los door elkaar.
Bij slechte programmeurs wel ja.


Bovendien is het bijzonder flauw om:
1.) Een lijstje pre's van Java over PHP te geven en geen lijstje van con's.
2.) Een topic te openen waarin je niet wilt discussieren maar alleen maar je eigen mening bevestigd probeert te krijgen.

[ Voor 4% gewijzigd door Grijze Vos op 17-12-2004 21:16 ]

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


Acties:
  • 0 Henk 'm!

  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 20-10 20:14
-FoX- schreef op vrijdag 17 december 2004 @ 20:33:
Voordelen Java t.o.v. PHP[list]
[small]
• In PHP is er geen aparte applicatielogica mogelijk, alle applicatielogica wordt in de scripts zelf afgehandeld.
Je kan zelf de scheiding bepalen, dat is wat anders dan dat het standaard gebeurt maar mogelijk is het.
• PHP is een pure presentatietaal, vergelijkbaar met JSP; J2EE biedt zoveel meer zoals transactions, lifecycle management, networking, database access, threads, dynamic objects.
networking en db acces zijn gewoon mogelijk lijkt mij?
• PHP werkt niet met strong typing; Er worden dus gemakkelijker fouten gemaakt. Dit resulteert in het feit dat de code niet gestructureerd is.
bewijs? Ik dacht dat het geen verschil maakte aldus een onderzoek maar ik kan me natuurlijk vergissen.
• In PHP moeten de variabelen niet gedeclareerd worden. Op deze manier is het mogelijk dat er een waarde aan een niet bestaande variabele gegeven wordt (door bvb een tikfout). Er zal ook geen enkele foutmelding of warning getoond worden.
zie vorige
• PHP draait niet in-process, maar is een externe executable die voor iedere pagina die op de server geparsed wordt, opnieuw wordt uitgevoerd.
als apache module draaien?
• Java biedt zeer uitgebreide foutboodschappen, hierin is PHP zeer cryptisch en is de fout soms ver te zoeken.
er staat zelfs een regelnummer bij volgens mij hoor.
• Java biedt een nette manier om de globale web instellingen onder te brengen onder 1 web configuratiebestand.
Wat weerhoudt je er van om hetzelfde te doen in PHP?[/quote]
• PHP wordt niet gecompileerd. De code kan dus nog fouten, zowel semantische als syntaxische, bevatten. Java biedt deze vorm van correctheid reeds, het compileert! Op deze manier hebben we bij een Java applicatie meer zekerheid!!
controleerd Java dan wel semantiek? De syntax errors worden overigens wel er uit gehaald door PHP door middel van een error. Laat maar ergens een puntkomma weg.
• Java wordt ondersteund door grote bedrijven (Sun, IBM, ..) waardoor de toekomst die Java heeft eens temeer verzekert wordt
waarom is dat zo? Als het te kostbaar wordt kunnen ze er mee stoppen als ze willen. Bij een community gebeurt dit niet zo snel aangezien ze geen winst of verlies hoeven te maken. Maar zelf buiten dat is het geen echt argument omdat het altijd kan stoppen.
• In de Java taal wordt goed gedefinieerd wat wel en niet compatible is en blijft.
Klopt sommige zaken worden bij PHP inderdaad aangepast of vervangen. In de meeste gevallen blijft de oude methode echter nog een versie gehandhaafd.
• In Java wordt de code nog aan extra testen onderworpen: unit testing, regressie-testen,
db-testing, http-testing, integration-testen, ... dit biedt zekerheid op consistente code!
Juist en dat kan zeker niet met PHP?
• Java ondersteund security, transacties, monitoring & logging van de code, PHP niet!
Wat houdt security ondersteuning in? Verder kan je gerust logging en monitoring in PHP implementeren maar het is inderdaad niet standaard. Transacties voor de code zelf bestaan inderdaad niet, de meeste databases hebben echter wel deze functionaliteit.
• De TCO ligt over het algemeen lager bij een Java applicatie.
cijfers graag
• Een Java applicatie is beter uitbreidbaar door de opdeling in verschillende tiers (presentatie, controller, business logic, database, ..)
niemand houdt je tegen in PHP om hetzelfde te doen, het komt zelfs vrij vaak voor dat dit gebeurt.
• Refactoring (optimaliseren van de code), kan veel sneller en consistenter in Java.
zou goed kunnen dat weet ik niet. Maar je punt is me sowieso niet duidelijk: met PHP kan je ook snelle applicaties kunnne maken.
• Waarom wordt er nooit PHP gebruikt in kritische applicaties zoals e-banking e.d. maar wel Java?
geen idee, zou ook te maken kunnen hebben met het imago van PHP, geen feitelijke reden voor zover ik weet.
• Er zijn complexe en daarmee duidelijke foutafhandeling systemen in Java!
Die hebben we al gehad ;)
• Java bevat: application/session/request/page scope, php mist deze request scope.
welke van de 4?
• PHP biedt geen duidelijke en mooie onderscheiding van code --> alle code staat los door elkaar.
Wat bedoel je hier precies mee? Wat zou dat volgens jou in moeten houden?

Acties:
  • 0 Henk 'm!

  • eamelink
  • Registratie: Juni 2001
  • Niet online

eamelink

Droptikkels

Jammer, dit topic was in het begin best interessant, nu is het Java kamp tegen het PHP kamp aan het knokken.

Met .oisyn als C++ hippie die er omheen danst ;)

Acties:
  • 0 Henk 'm!

  • Grijze Vos
  • Registratie: December 2002
  • Laatst online: 28-02 22:17
eamelink schreef op vrijdag 17 december 2004 @ 21:47:
Jammer, dit topic was in het begin best interessant, nu is het Java kamp tegen het PHP kamp aan het knokken.

Met .oisyn als C++ hippie die er omheen danst ;)
Nah, het stoort me gewoon dat mensen eerst je mening vragen, en vervolgens in hun samenvatting gewoon al je tergenargumenten genegeerd hebben.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


Acties:
  • 0 Henk 'm!

  • PrisonerOfPain
  • Registratie: Januari 2003
  • Laatst online: 26-05 17:08
Grijze Vos schreef op vrijdag 17 december 2004 @ 21:14:
Omdat PHP niet de allerbeste security biedt.
Ligt blijkbaar toch bij de programmeur zelf, ns.nl is ook niet echt uhm, stabiel om het zo maar te zeggen. Bij het manipuleren van een paar parameters kun je al null-pointer exceptions krijgen, en er kan html injection toegepast worden op de site zelf.

Nogmaals, heeft dus niets met de taal te maken :)

Acties:
  • 0 Henk 'm!

  • Grijze Vos
  • Registratie: December 2002
  • Laatst online: 28-02 22:17
PrisonerOfPain schreef op vrijdag 17 december 2004 @ 22:28:
[...]


Ligt blijkbaar toch bij de programmeur zelf, ns.nl is ook niet echt uhm, stabiel om het zo maar te zeggen. Bij het manipuleren van een paar parameters kun je al null-pointer exceptions krijgen, en er kan html injection toegepast worden op de site zelf.

Nogmaals, heeft dus niets met de taal te maken :)
Mja, uiteraard. Ik ben zelf niet zo thuis met Java, dus kan daar niet zo diep op ingaan. Maar, in de verdediging van Java, PHP kan i.c.m. misconfiguraties in Apache nogal gevaarlijk zijn. Nu valt dat sinds PHP4/5 al flink mee. (register_globals, o.a.), maar je blijft toch altijd wat punten hebben. Veel van die punten zullen er bij Java ook zijn, maar die ken ik verder niet.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


Acties:
  • 0 Henk 'm!

  • Erkens
  • Registratie: December 2001
  • Niet online

Erkens

Fotograaf

djluc schreef op vrijdag 17 december 2004 @ 21:23:
[...]
controleerd Java dan wel semantiek? De syntax errors worden overigens wel er uit gehaald door PHP door middel van een error. Laat maar ergens een puntkomma weg.
waarschijnlijk bedoelt hij dat het niet vooraf gechecked wordt, maar blijkbaar gebruiken ze hier nooit een debugger of encoden/"compilen" ze het niet vooraf...

o, en als je alleen een syntax check wilt:
code:
1
php -l filename.php

[ Voor 11% gewijzigd door Erkens op 17-12-2004 23:26 ]


Acties:
  • 0 Henk 'm!

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 08:14

Creepy

Tactical Espionage Splatterer

Goed.... uit dit topic blijkt maar weer dat liefhebbers van twee talen elkaar lekker in de haren kunnen vliegen ;)

Java valt aan, PHP verdedigt.. en andersom. Daarnaast mist er over de gehele thread gekeken ook te vaak een fatsoenlijke onderbouwing. Het begint hier nu echt op een holy war te lijken. Mocht je echt nog iets toe te voegen hebben met een fatsoenlijk onderbouwing (dus geen lijstje met alleen voor en nadelen, maar elk punt fatsoenlijk onderbouwt): voeg gerust nog een post toe. Op het moment dat er weer met modder en slechte/niet onderbouwde posts gesmeten wordt dan gooi ik hem dicht, want de pret heeft nu wel lang genoeg geduurt en eruit komen doen we toch toch niet ;)

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


Acties:
  • 0 Henk 'm!

  • Rex
  • Registratie: September 2003
  • Laatst online: 10-07 14:11

Rex

Wolven zijn mooie dieren

Wow...... Ik wilde een replyen met een soort anti Java reply.

Het enige wat ik wil zeggen is dat in de post van FoX veel argumenten staan die niet perse een voordeel hoeven te zijn.
Over 1 van zijn argumenten wil ik nog even kort iets op zeggen.
PHP biedt geen duidelijke en mooie onderscheiding van code --> alle code staat los door elkaar.
Als je een goede coder bent en je zet alles netjes in functies en dergelijke dan hoeft je code niet gelijk onduidelijk/lelijk te zijn!

Overigens geldt bovenstaande antwoord wel voor wat meer "voordelen" die jij noemde. Ik kan in Java en PHP coderen en toch vind ik PHP beter voor webapplicaties. Java biedt voor mij geen meerwaarde. (Tenzij ik op IRC moet via een webapplicatie. Dan is Java wel handig.)

BTW: JavaSCRIPT kan soms ook erg handig zijn. Ik gebruik vaak PHP en Javascript door elkaar. PHP creert de paginas en Javascript geeft nog een extra dimensie aan mijn formulieren en andare onderdelen van me paginas.:)

Mijn conclusie is eigenlijk dat je een combinatie van alle talen moet toepassen. Ikzelf gebruik dus PHP, Javascript, Java, CSS, HTML en XML voor mijn website. Bij elke pagina kijk ik weer welke taal ik het beste kan gebruiken voor wat ik nodig heb.

Rex


Acties:
  • 0 Henk 'm!

  • Daventry
  • Registratie: Oktober 2004
  • Laatst online: 21-04 10:00
[b][message=22380829,noline]Java biedt zeer uitgebreide foutboodschappen, hierin is PHP zeer cryptisch en is de fout soms ver te zoeken.
Ik ben pro-java, maar dit is bullshit.

Ik debug tien keer liever een PHP pagina dan bijvoorbeeld een JSP pagina waar je in Tomcat een of andere error van het gegenereerde servlet (met regelnummer in het servlet) krijgt wat moeilijker is omdat de regelnummers niet overeenkomen.

Ik PHP krijg je tenminste het "echte" (lees: php) regelnummer, dus dit is een beetje een loos
argument.

Trouwens, de foutmeldingen die PHP geeft voldoen in de meeste gevallen sowieso om het ding te debuggen (als je error reporting goed staat) ... vind dat wat dat betreft beide talen evenwaardig zijn

[ Voor 6% gewijzigd door Daventry op 17-12-2004 23:40 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Verwijderd schreef op donderdag 16 december 2004 @ 19:57:
Ik haalde C++ aan als voorbeeld, ik zal in het vervolg wel Cobol roepen, ok?
En wat is er mis met Cobol? Goed, er bstaan niet zulke mooie libraries voor als voor java, maar als je al een hoop code hebt is het vaak simpeler de webinterface in Cobol te schrijven dan alle backend code in C++. of Java of .Net of PHP of ... te repliceren. Misschien niet optimaal qua performance, maar vaak wel snel up & running.

Alle oordelen over geschiktheid qua taal zijn (IMHO) per definitie fout zolang je het project waarin de taal gebruikt wordt niet kent. Dus of het nu Cobol, Fortran, Basic of Java is, alles kan efficient zijn om een webinterface mee te programmeren. Voor nieuwe projecten zou ik natuurlijk geen Cobol of Fortran kiezen, maar voor bestaande projecten is de keuze niet zo eenvoudig.

Acties:
  • 0 Henk 'm!

Verwijderd

Websjwans, als je het volgende beweert,
Verwijderd schreef op vrijdag 17 december 2004 @ 15:47:
Nu kan ik in PHP het volgende doen:

PHP:
1
2
$sysLog = new COM ("LogLibrary.SysLog"); 
$sysLog->Log("App name", "Event title", "Event message", E_USER_WARNING);


Probeer dat maar eens op een ander platform :7 :)
Moet je niet gaan mekkeren als iemand je punt nogal simpel onderuit haalt.
Maar goed, ik stop met posten in deze thread. Elke keer als ik een voorbeeld aanhaal kan ik weer nog verder off-topic gaan uitleggen wat ik bedoel. Zo zijn we op C++ gekomen en nu zijn we weer aan het discussieren over hoe makkelijk je ook in andere talen COM objecten kunt aanroepen.
Nogal jammer. Incasseren en fouten toegeven is ook onderdeel van het leven

Acties:
  • 0 Henk 'm!

Verwijderd

Fox had wat "feiten" op een rij gezet maar daar klopt eigenlijk bar weinig van :)
-FoX- schreef op vrijdag 17 december 2004 @ 20:33:
Om maar weer even ontopic te gaan, heb ik alle genoemde feiten maar eens op een rij'tje gezet. Of ze al dan niet correct zijn, laat ik even in het midden en ik wacht jullie commentaren rustig af.

Voordelen Java t.o.v. PHP[list]
[small]• De Java programmeertaal is en blijkt uiteindelijk meer volwassen dan de PHP scripttaal.

• PHP werkt niet met strong typing; Er worden dus gemakkelijker fouten gemaakt. Dit resulteert in het feit dat de code niet gestructureerd is.
Het eerste is waar, maar heeft op zich natuurlijk weinig te maken met de mate van gestructureerdheid van de code
• In PHP moeten de variabelen niet gedeclareerd worden. Op deze manier is het mogelijk dat er een waarde aan een niet bestaande variabele gegeven wordt (door bvb een tikfout). Er zal ook geen enkele foutmelding of warning getoond worden. Probeer zo maar eens bij grotere projecten je fouten eruit te halen en te verklaren dat je code bugvrij is!
Het is bij elke programmeertaal (vrijwel) onmogelijk te verklaren dat je code bugvrij is. MS is het in ieder geval nog steeds niet gelukt en ook Linux barst van de bugs. Runtime errors zijn niet erger of minder erg dan compiler errors. Het gaat erom dat een programma doet wat het moet doen, niet of het wel of niet compileert.
• PHP draait niet in-process, maar is een externe executable die voor iedere pagina die op de server geparsed wordt, opnieuw wordt uitgevoerd.
Niet correct, op Windows draait PHP als een DLL.
• Java biedt zeer uitgebreide foutboodschappen, hierin is PHP zeer cryptisch en is de fout soms ver te zoeken.
Mening, geen feit.
• Java biedt een nette manier om de globale web instellingen onder te brengen onder 1 web configuratiebestand.
PHP is heel goed te managen met bestaande tools. 1 file, So what, en gestuctureerde managment interface is belangrijker (en heeft PHP) en voor een client is het eigenlijk helemaal oninteressant
• PHP wordt niet gecompileerd. De code kan dus nog fouten, zowel semantische als syntaxische, bevatten. Java biedt deze vorm van correctheid reeds, het compileert! Op deze manier hebben we bij een Java applicatie meer zekerheid!!
Zie hierboven. Welke zekerheid heb je? De code voldoet aan de syntax, inhoudelijk zegt het nog niets. "De Peer zegt dat de Boekenlegger goud moet comprimeren." Begrijp jij het? Toch is het correct nederlands.

• Java wordt ondersteund door grote bedrijven (Sun, IBM, ..) waardoor de toekomst die Java heeft eens temeer verzekert wordt

• In de Java taal wordt goed gedefinieerd wat wel en niet compatible is en blijft.
• In Java wordt de code nog aan extra testen onderworpen: unit testing, regressie-testen,
db-testing, http-testing, integration-testen, ... dit biedt zekerheid op consistente code!
Dat doet java niet, dat doet de programmeur! In PHP is dit ook mogelijk.
• Java ondersteund security, transacties, monitoring & logging van de code, PHP niet!
PHP ondersteund login forms, https dus een vorm van security, Php ondersteund database transacties en monitoring en logging. Zonder op java specifieke zaken in te gaan zoals EJBs is dit eigenlijk veel te ruim gedefineerd ofwel pure onzin (take your pick)
• De TCO ligt over het algemeen lager bij een Java applicatie.
Gebaseerd op wat? Weer een mening, zeker geen feit.
• Een Java applicatie is beter uitbreidbaar door de opdeling in verschillende tiers (presentatie, controller, business logic, database, ..)
Technisch is een PHP applicatie ook op te splitsen volgens het MVC patroon. Standaard java ondersteund trouwens geen MVC, daar heb je aparte libs (zoals struts) voor nodig.
• Refactoring (optimaliseren van de code), kan veel sneller en consistenter in Java.
Goede code behoeft geen refactoring. :) Daarnaast is refactoring geen optimalisatie methode. (ik heb nog nooit een programma sneller zien worden van het hernoemen van een functie :) ) Ook is de snelheid van het optimaliseren niet echt relevant, relevant is hoe snel de code na optimaliseren is. Dat is iets anders.
• Waarom wordt er nooit PHP gebruikt in kritische applicaties zoals e-banking e.d. maar wel Java?
Tegenargument. Waarom gebruikt het overgrote deel van de webdesigners PHP. Hoeveel e-banking applicaties ken jij? Hoeveel grote sites (zoals tweakers) draaien op PHP?
• Er zijn complexe en daarmee duidelijke foutafhandeling systemen in Java!
Je begint je te herhalen!
• Java biedt zeer uitgebreide foutboodschappen, hierin is PHP zeer cryptisch en is de fout soms ver te zoeken.
• Java bevat: application/session/request/page scope, php mist deze request scope.
So What? Wat is het voordeel in de applicatie en hoezo kun je het niet in de session of page scope afvangen. Verschil in concept, maar niet echt in functionaliteit
• PHP biedt geen duidelijke en mooie onderscheiding van code --> alle code staat los door elkaar.
Misschien zoals sommigen programmeren, maar het hoeft natuurlijk niet.

Als je dan feiten wilt weergeven, zouden deze 12 pagina's discussie toch op zijn minst het idee naar boven moeten brengen dat niet alles zo simpel is als het lijkt. PHP is gewoon vaak een goede taal. Als je dan een opdrachtgever wil overtuigen gebruik dan geen argumenten waarvan je bij voorbaat al weet dat ze erg makkelijk onderuit gehaald kunnen worden. Zoals ik al eerder gezegd heb, overtuig een opdrachtgeven door middel van de methode waarop jij het zou aanpakken en wijs hem op de voordelen voor hém van die methode. MVC? Wat is dat?, Foutboodschappen? Die ziet de opdrachtgever toch niet. enz.

Acties:
  • 0 Henk 'm!

Verwijderd

Verwijderd schreef op zaterdag 18 december 2004 @ 03:09:
Websjwans, als je het volgende beweert,

[...]


Moet je niet gaan mekkeren als iemand je punt nogal simpel onderuit haalt.

[...]


Nogal jammer. Incasseren en fouten toegeven is ook onderdeel van het leven
Moet dat nou?

Als je nou eens LEEST dan zie je dat ie m'n punt een beetje heeft gemist. Incasseren en fouten toegeven is inderdaad onderdeel van het leven en als je de thread ook eens LEEST zie je dat ik dat ook de hele thread heb gedaan. Tenslotte kun je in m'n laatste reply LEZEN dat ik stop met posten omdat mensen over m'n voorbeelden door gaan miereneuken, terwijl ze voor de rest weinig aan de on-topic discussie hebben bijgedragen, zoals jou reply over Cobol.

Discussieren vind ik prima, of ik nou goed of fout zit, maar deze replies dragen dus echt niks bij aan dit topic.

Acties:
  • 0 Henk 'm!

  • flowerp
  • Registratie: September 2003
  • Laatst online: 11-09 18:20
Verwijderd schreef op zaterdag 18 december 2004 @ 03:43:
Jan Klaas had wat "feiten" op een rij gezet maar daar klopt eigenlijk bar weinig van :)

Zie hierboven. Welke zekerheid heb je? De code voldoet aan de syntax, inhoudelijk zegt het nog niets. "De Peer zegt dat de Boekenlegger goud moet comprimeren." Begrijp jij het? Toch is het correct nederlands.
In Java heb je wel degelijk een aantal checks die wat over de semantiek zeggen, maar dat zijn natuurlijk wel de eenvoudigere checks zoals bijvoorbeeld "unreachable code", "variable might not be initialized at this point of usage" en "uncaught exception".
Technisch is een PHP applicatie ook op te splitsen volgens het MVC patroon. Standaard java ondersteund trouwens geen MVC, daar heb je aparte libs (zoals struts) voor nodig.
Java zelf ondersteund inderdaad niet direct een design pattern als MVC. De *standaard* libraries van Java echter wel: Swing is wel degelijk op MVC gebasseerd (hoewel wel een aanpaste vorm, waarbij M & C gedeeltelijk compressed zijn).

J2EE is voorbereid op MVC. In een model 1 applicatie maak je er geen gebruik van, en in model 2 wel. Het hele concept van servlets (en alles wat hiermee samenhangt) maakt het mogelijk om verschillende patterns toe te passen. Struts is een implementatie van model 2 door een externe partij. De standaard implementatie van Sun heet JFC. Deze wordt geleverd bij de reference implementatie van J2EE 1.4 (de huidige versie) en zal volledig opgenomen worden in de specificaties van J2EE 1.5.
JFC is volledig MVC, waarbij vooral het V gedeelte erg sterk is (de zogenaamde web widgets, zoals ASP.NET deze ook zeer sterk implementeerd). Struts is iets sterker in het C gedeelte. Je kunt Struts en JFC gewoon door elkaar gebruiken; er is een speciale intergration lib.

Maw, J2EE (wat je waarschijnlijk bedoelde met java) is door het basis design zeer geschikt voor MVC in een client-server omgeving (dit is subtiel anders als klassiek MVC zoals in smalltalk).
Goede code behoeft geen refactoring. :)
We zouden niet meer met modder gaan gooien, maar dat is toch echt B*llshjiet met een capital B. Typische PHP gedachte: design hoeft niet, patterns zijn waardeloos, scholing is overbodig, en ach refactoring dus ook maar.

Refactoring is -juist- van essentieel belang voor je ontwikkelings process. Het is een doorlopend en continu process. Code groeit, requirements veranderen, je domain evolueert, je inzichten nemen toe, etc. Als je ooit wel eens design werk hebt gedaan, dan weet je dat je in veel gevallen een design niet sluitend kan krijgen voordat je met coden begint. Overdesignen is absoluut niet goed. Met de refactoring techniek groeit je design langzaam vanuit een basis design. Dit ondersteun je met unit testen om na elke refactoring te garanderen dat je refactoring de basis garanties heel gelaten heeft.
Daarnaast is refactoring geen optimalisatie methode. (ik heb nog nooit een programma sneller zien worden van het hernoemen van een functie :) )
Refactoren is veel meer dan het alleen hernoemen van een functie. Typische kinderlijke PHP gedachte om er zo over te denken ;)
Ook is de snelheid van het optimaliseren niet echt relevant, relevant is hoe snel de code na optimaliseren is. Dat is iets anders.
De snelheid en efficientheid van refactoren is wel dedelijk een heel groot issue.

Ten eerste, tijd is geld weet je nog? Als een programmeur of software architect het overzicht verliest (omdat de taal niet strak genoeg specifeerd wat wat is) dan ben je zowieso al meer geld kwijt, en bovendien zal zij dan niet het uiterste uit de mogelijke optimalisaties kunnen halen.

Ten tweede, doordat je in Java een strakkere definitie hebt van je code, kun je veel refactorings operaties ondersteund door tools laten uitvoeren. Met name Eclipse en IntelliJ zijn hier heel sterk in. Je kunt bijvoorbeeld een inner class naar een normale class refactoren, waarbij alle parameters en referenties in je hele project automatisch upgedate worden. Dit zijn zeer krachtige tools in de handen van een volwassen programmeur.

In PHP zal je een dergelijke refactoring nooit kunnen doen, omdat de compiller niet kan weten wat wat is (de programmeur vertelt dit namelijk niet, de PHP syntax dwingt haar niet daartoe).

Ik moet dan wel toegeven dat in JSP, refactoring ook niet je van het is. JSP is met z'n fragments een heel stuk minder strakker als puur java. Daarom wil je ook zo veel mogelijk logica in je pure java code layers houden, en alleen een minimaal aan code in JSP pagina's zetten. Een niet al te snuggere J2EE programmeur zal dus gewoon hele lappen java code in haar JSP pagina gaan zetten, waardoor veel voordelen van J2EE al weer wegvallen.
Tegenargument. Waarom gebruikt het overgrote deel van de webdesigners PHP.
Omdat een webdesigner meestal geen echte programmeur is. Een website kun je best scripten, maar een webapplicatie is heel andere koek.

In het stukje hierboven over C++ was er ook iemand zo snugger om op te merken dat web applicaties geen of nauwelijks performance nodig hadden. Mischien dat dat voor websites met 1 concurrent user geldt, maar een web applicatie is feitelijk gelijk aan een willekeurige gewone applicatie maar dan met een interface in HTML over HTTP. Een web applicatie kan gewoon dingen doen als ingewikkelde berekeningen real time uitvoeren (mischien patronen in statische data zoeken), bewerkingen op bestanden uitvoeren, zoals grafische filters die zeer rekenintensief kunnen zijn, etc. In princiepe zijn zeer veel applicaties geschikt voor een web interface. Alleen die waar snelle screen updates essentieel zijn valt het af.
So What? Wat is het voordeel in de applicatie en hoezo kun je het niet in de session of page scope afvangen. Verschil in concept, maar niet echt in functionaliteit
Als je geen globale (application) scope hebt vallen een aantal mogelijkheden af voor een echte server applicatie. Maar mischien moet je gewoon eens wat posts van gisteren in deze thread lezen, dit werd namelijk al besproken.
Foutboodschappen? Die ziet de opdrachtgever toch niet. enz.
Die ziet ze wel degelijk als ze in haar web log verschijnen. Kijkt de opdracht gever niet naar die log, dan komen ze wellicht wel op haar scherm. Deze worden dan naar jou toegestuurt (als je een support/onderhoud er bij afgesproken hebt). Dan mag jij, remote aan de hand van de errors uitvogelen wat er mis ging. Des te duidelijker de foutmeldingen, des te sneller je een patch kan maken. Natuurlijk is dit niet alleen Java specificiek maar de programmeur moet zelf ook goede logging van essentiele state doen in geval van exceptions.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op zaterdag 18 december 2004 @ 03:43:
Fox had wat "feiten" op een rij gezet maar daar klopt eigenlijk bar weinig van :)
Dat gaan we nu wel eens even zien.
Het is bij elke programmeertaal (vrijwel) onmogelijk te verklaren dat je code bugvrij is. MS is het in ieder geval nog steeds niet gelukt en ook Linux barst van de bugs. Runtime errors zijn niet erger of minder erg dan compiler errors. Het gaat erom dat een programma doet wat het moet doen, niet of het wel of niet compileert.
Programmeurs maken fouten.. dat moet je met me eens zijn. Jij maakt domme type fouten en ik ook. Het compilatie proces zorgt er voor dat de meest voor de hand liggende fouten er al uit zijn gehaald. Stel dat jij en ik allebei evenveel typefouten per regel code maken, dan zal onze ongecompileerde code grofweg evenveel fouten bevatten. Maar op het moment dat ik moet compileren krijg ik ineens een hele lading foutmeldingen voor de kiezen die ik moet fixen voordat ik de app uberhaubt aan de praat kan krijgen. Het nare is natuurlijk dat ik even bezig ben om de fouten eruit te halen, maar het eind resultaat is nu ineens dat mijn code per regel code minder fouten zal bevatten dan de jouwe.

En idd.. grote semantische fouten haal je er niet uit (appels bij peren optellen), maar de kleine fouten zijn er bij gecompileerde talen meer uit dan ongecompileerde talen. En vaak zijn dit er een enorme hoeveelheid...
Zie hierboven. Welke zekerheid heb je? De code voldoet aan de syntax, inhoudelijk zegt het nog niets. "De Peer zegt dat de Boekenlegger goud moet comprimeren." Begrijp jij het? Toch is het correct nederlands.
Zie mijn verhaal hierboven.
Dat doet java niet, dat doet de programmeur! In PHP is dit ook mogelijk.
Op het gebied van testing zal PHP wel hetzelfde kunnen als Java (een testtool schrijven moet vast wel mogelijk zijn). Maar even een keyquestion: gebruik jij unit tests? Zo nee, waarom niet? Is het te veel werk? De instap te hoog? De manier van werken laat het niet toe? PHP applicaties zijn lastiger te testen omdat ze vrij monolytisch zijn opgezet? Mock objecten plaatsen is lastig omdat er geen goeie oo technieken worden toegepast?

Ik test mijn code behoorlijk zwaar (hangt trouwens wel heel erg van het type applicatie).
PHP ondersteund login forms, https dus een vorm van security, Php ondersteund database transacties en monitoring en logging. Zonder op java specifieke zaken in te gaan zoals EJBs is dit eigenlijk veel te ruim gedefineerd ofwel pure onzin (take your pick)
Wel een typerend antwoord van iemand die geen serieuze omgevingen is gewend. In java/.net is het mogelijk om security, en transacties toe te voegen op andere zaken dan alleen databases. Niet alle applicaties bestaan uit alleen maar een webinterface en een database. Dit is dus echt een heel typerend PHP antwoord..
Goede code behoeft geen refactoring. :)
Typisch het antwoord van een amateur. Het is niet erg hoor.. zo dacht ik ook eens. Code schrijf je in 1 keer goed. Maar dat is niet zo.. software schrijven is een organisch proces. Iets dat niet meteen in 1 keer goed te doen is. Als je nieuwe inzichten op doet (en ja.. die doe je nu eenmaal op), refactor je. Soms is het even methode naam aanpassen zodat hij beter beschrijft wat hij doet. Maar in sommige gevallen ga je ook op hoger nivo refactoren.
Daarnaast is refactoring geen optimalisatie methode. (ik heb nog nooit een programma sneller zien worden van het hernoemen van een functie :) ) Ook is de snelheid van het optimaliseren niet echt relevant, relevant is hoe snel de code na optimaliseren is. Dat is iets anders.
Het gaat om het gemak van refactoring. ALs ik 200 classes in een andere package moet zetten en ik heb geen beschikking over refactor opties, dan.. tjah... kan ik niets anders zeggen: kut klus. Veel eentonig werk.. imports aanpassen.. namespaces aanpassen.. kut werk en dat is ook de reden dat je het in de praktijk minder gaat doen (en ik spreek uit ervaring...). Op het moment dat je een IDE tot je beschikking hebt die dit volledig geautomatiseerd kan uitvoeren is de stap om dit soort kleine aanpassingen te doen ook vele malen kleiner geworden.

[ Voor 9% gewijzigd door Alarmnummer op 18-12-2004 15:56 ]


Acties:
  • 0 Henk 'm!

  • Erkens
  • Registratie: December 2001
  • Niet online

Erkens

Fotograaf

flowerp schreef op zaterdag 18 december 2004 @ 15:18:
We zouden niet meer met modder gaan gooien, maar dat is toch echt B*llshjiet met een capital B. Typische PHP gedachte: design hoeft niet, patterns zijn waardeloos, scholing is overbodig, en ach refactoring dus ook maar.

[..]

Refactoren is veel meer dan het alleen hernoemen van een functie. Typische kinderlijke PHP gedachte om er zo over te denken ;)
Alarmnummer schreef op zaterdag 18 december 2004 @ 15:49:
... Dit is dus echt een heel typerend PHP antwoord..
Nee zo win je je discussie :/
Mensen die PHP gebruiken zijn dus prutsers, weten niet waar ze het over hebben, hebben geen scholing gehad en PHP gebruikers zijn kinderlijk...

Nee ik heb het al door.

* Erkens verlaat het topic, ik weet wel beter ;)

Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Tja... we hebben argumenten genoeg gegeven en als je dat nog steeds niet inziet dan schort er wel iets aan je. (waarschijnlijk scholing en visie) Ik wil niet zeggen dat php een prutstaal is en dat alle php`ers prutsers zijn, maar wat ik uit dit topic (weer) naar voren heb zien komen is dat de gemiddelde php`er niet op hetzelfde nivo software schrijft als de gemiddelde java/.net man.

vraag:
hoeveel php`ers hebben bv boeken gelezen zoals:
Patterns of enterprise application architecture.
design patterns explained
design patterns, elements of reusable software.
enterprise integration patterns
refactoring.
patterns of software architecture 1/2/3

of andere boeken die zich bezighouden met software ontwikkeling op een veel hoger nivo.

de meeste .NET/Java/c++ die ik ken hebben wel een of meerdere van deze titels gelezen. Hoeveel mensen die niet in deze talen werken hebben dit soort boeken gelezen? :) ik durf de stelling nog wel aan dat dat nog geen fractie is tov de mensen die ik ken. hieruit durf ik dus wel te concluderen dat het nivo toch zeker anders is.

Als je zegt dat dit soort boeken niet belangrijk zijn trouwens, kunnen daar ook zeker bepaalde conclusies aan verbonden worden.

[ Voor 49% gewijzigd door Alarmnummer op 19-12-2004 08:37 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Waar gaat de discussie nu over? Of PHP programmeurs wel even goede programmeurs zijn als Java programmeurs? Het antwoord daarop is heel simpel. De instap bij PHP is heel laag, hierdoor kan elke tiener wel een scriptje schrijven. Het PHP publiek is hierdoor veel diverser dan het publiek van Java en gemiddeld zal een PHP programmeur daarom minder "goed" zijn dan een Java programmeur. Is dat interessant? Nee. (Overigens, zie ook The Python Paradox.)

Ik kan verschrikkelijk ranzige platte Java code schrijven. Ik kan fantastich mooie PHP code schrijven met patterns, MVC, unit tests en weet ik niet wat. De taal maakt geen kont uit. Er zijn slechts een aantal discussies echt relevant:
  • Is static typing beter dan dynamic typing?
  • Ondersteunt PHP alle benodigde OO concepten wel goed?
  • Hoe zit het met security?
  • Hoe zit het met tooling?
Bij de eerste vraag wil nu alvast melden dat we er toch niet uit komen. De meesten hier hebben slechts degelijke ervaring met een van beide en kunnen dus geen antwoord geven op deze vraag. Mensen die wel met beide ervaring hebben, hebben er weer verschillende meningen over. Aan theorie hebben we hier weinig, want de praktijk blijkt anders.

[ Voor 14% gewijzigd door Verwijderd op 19-12-2004 09:37 ]


Acties:
  • 0 Henk 'm!

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 08:14

Creepy

Tactical Espionage Splatterer

En dicht. De boel valt nu in herhaling en modder gegooi.
Mocht er iemand nog een nuttige reply hebben dan kan je mij mailen en dan wil ik deze nog wel toevoegen.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


Acties:
  • 0 Henk 'm!

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 08:14

Creepy

Tactical Espionage Splatterer

Creepy,

Ik heb nog een reply voor in dat Java/PHP/Meerwaarde topic. :P
(wel jammer dat ie dicht is trouwens, ik las hem net...)

whoami

Jan Klaassen:
Goede code behoeft geen refactoring. :) Daarnaast is refactoring geen
optimalisatie methode. (ik heb nog nooit een programma sneller zien worden
van het hernoemen van een functie :) ) Ook is de snelheid van het
optimaliseren niet echt relevant, relevant is hoe snel de code na
optimaliseren is. Dat is iets anders.


Schrijf ik dan slechte code ?
Ik heb ergens in oktober een soort 'batch' systeem ontwikkeld, dat volledig
configureerbaar was door een xml file, en verschillende soorten 'stappen'
kon uitvoeren. Enkele weken geleden heb ik dat nog eens herbekeken, en heb
ik gezien dat het hier en daar wel wat beter of anders kon opgezet worden.
Ik heb dan ook enige tijd gestoken in het refactoren van het design van dat
subsysteem.
Was mijn vorig systeem niet goed? Toch wel, het was goed. Het deed wat
het moest doen, maar nu is het nog beter. Het is uitbreidbaar en als er
plots verwacht wordt, dat mijn 'configuratie' niet alleen via een xml file
moet gebeuren, maar bv. ook in de DB moet opgeslagen zijn, dan heb ik in een
mum van tijd die functionaliteit erin gebouwd.

Refactoren is meer dan een 'method een andere naam geven'. Refactoren is
het aanpassen van je applicatie zonder daarbij nieuwe functionaliteit toe te
voegen. Refactoren is je applicatie voor een stuk redesignen, zodat die
makkelijker aanpasbaar, generieker wordt, logischer in elkaar zit.
Refactoren kan ook zo zijn dat je je applicatie herdesigned om tot een
betere performance te komen.
Echter, wat is er de dag van vandaag belangrijker ? Optimalizeren tot op de
milliseconde, of een schaalbaar en onderhoudbaar design hebben dat makkelijk
kan uitgebreid worden?

Alarmnummer:
En idd.. grote semantische fouten haal je er niet uit (appels bij peren
optellen)


Hum... Mijn compiler haalt dit specifieke voorbeeld er wel uit. :P

code:
1
2
3
float f = 5;
int i = 6;
int result = f + i;

Zal niet compilen.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

Pagina: 1 2 3 Laatste

Dit topic is gesloten.