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

[-FoX-]

Java en php zijn eigenlijk niet te vergelijken met elkaar. Java heeft zoveel meer te bieden, maar php is ruimschoots voldoende voor de gemiddelde website. Maar wat nu indien er meer nodig is dan een gemiddelde website?

Beter nog... wat indien een vragende partij een webapplicatie wil laten ontwikkelen, laten we zeggen op nationaal niveau waarbij het uiterst belangrijk is dat er geen gegevens verloren gaan, privacy van de gegevens gerespecteerd dient te worden en er verschillende (tss 500 & 1000-tal) gelijktijdige gebruikers op het systeem zullen werken? Het systeem zal vooral dienen om gegevens bij te houden en statistieken te trekken.. maar ook enkele administratieve zaken.
Is een php applicatie hier dan wel op zijn plaats

Mijns inziens is een java webapplicatie hier wel op zijn plaats. Ik zeg niet dat het niet mogelijk is met een php applicatie, maar biedt een java webapplicatie niet zoveel meer (transacties, multithreading, db-onafhankelijkheid, platform onafhankelijkheid, server (tomcat, jboss, websphere, weblogic, orion, ...) onafhankelijk, uitbreidbaarheid, separation of concerns, ....) ?

Waarom zou jij een java/php webapplicatie verkiezen boven het andere?? En met welke argumenten zou je de vragende partij kunnen overhalen?
_{Er is hier geen sprake van een bestaande infrastructuur, dus op dat gebied is eigenlijk alles nog wel mogelijk}

[Creepy]

* Creepy wil even opmerken dat PHP ook db onafhankelijk, platform onafhankelijk en ook webserver onafhankelijk is. Dat is nu niet een specifiek java iets. Als je transactied op DB nivo bedoelt dan is dat in PHP ook geen probleem. En waar je op doelt met de uitbreidbaarheid is me een raadsel want dat lijkt me met correct opgezette php code ook geen probleem.
Dan blijven er ineens niet zoveel meer zaken over voor java

Note: Ik vind java / j2ee volwassener dan PHP en niet gehinderd door een bestaand platform en een partij die alleen PHP kent zou ik voor java kiezen.

[Daventry]

Zoals je zegt is het een beetje moeilijk te vergelijken ...

Ik zou natuurlijk ook voor JAVA gaan, als is het maar omdat Servlets/JSP (want daar doel je denk ik op als je PHP en JAVA gaat vergelijken) zoveel meer mogelijkheden bieden:
- Custom Tags & JSTL (erg handig eens je het doorhebt ...)
- Je kan je code grotendeels in een javabean kwijt (php files zijn, laat ons eerlijk zijn, in veel te veel gevallen gewoonweg onleesbaar [akkoord, hebben slechte JSP files ook]
- Ik vind PHP een nogal slordige taal die slecht programmeren totaal niet afstraft. Een PHP filetje kan je zo via trial-and-error in elkaar flansen, php laat vrij veel toe - en dan krijg je niet direct veilige of mooie applicaties
- En natuurlijk omdat je met JAVA echt krachtige enterprise applicaties kan maken (door EJB's bijvoorbeeld, al heb ik het niet zo met die dingen)

[Woy]

Het ligt er ook vooral aan wat voor applicatie je precies moet maken. Ik zie PHP vooral als een taal waarmee je de frontend kan maken ( In het geval van php dus de html generatie ).
Java is denk beter geschikt om een applicatie met een complexe business laag te maken. Als het dus echt een complex web applicatie is die later mischien ook nog een desktop client krijgt zou ik eerder voor Java kiezen.
Als je een simpele Front-end wil maken die enkel gegevens toont is PHP mischien wat makkelijker.

In het geval wat jij schetst zou ik als ik tussen PHP of Java moet kiezen toch voor Java gaan denk ik. Maar het is natuurlijk ook belangrijk om er rekening mee te houden waar er kennis van in huis is. Als je altijd in PHP werkt en totaal geen ervaring ing Java hebt is het denk niet handig om meteen met een groot project in Java te beginnen en andersom natuurlijk ook niet.

[blender]

Lees deze thread op Slashdot maar eens...

[Verwijderd]

- Standaard applicatie?
Voor zulke zaken zou ik dus echt GEEN PHP gebruiken. Het is heel leuk dat het platform onafhankelijk is, maar op IEDERE server is IEDERE PHP configuratie ANDERS. Het is onmogelijk om een (geavanceerde) PHP applicatie te schrijven die op FreeBSD hetzelfde draait als op Debian en als op Windows. De ene server heeft dit, de andere dat, de ene heeft die mogelijkheden uigeschakeld de andere dat, etc etc.
Vergeet daarnaast niet dat er zo goed als iedere week een PHP update is waarin soms dingen gewijzigd worden.

- Op maat?
Prima te doen met PHP.
Zou persoonlijk .NET gebruiken, kan je logingegevens van alle users direct in de webapp intergreren, hebben ze 1 pass & ww nodig. Policies wijzigen in de infrastrucuut? Ook direct aangepast in de webapp. Enfin, PHP zou prima voldoen, heeft de client ook geen Java nodig, is wel zo makkelijk.

geen gegevens verloren gaan, privacy van de gegevens gerespecteerd dient te worden

Heeft niets met de ontwikkelingstaal te maken, kan je weglaten uit je motvivering

maar biedt een java webapplicatie niet zoveel meer (db-onafhankelijkheid, platform onafhankelijkheid, server onafhankelijk

Die kan je weglaten bij een op maat oplossing.

Wat houd je dan over:

1- 1000-tal gelijktijdige gebruikers op het systeem werken
2- gegevens bij te houden
3- statistieken te trekken
4- administratieve zaken

Afhankelijk van wat er gedaan moet worden bij punt 1
- Word, Excel documenten beheren? sowieso .NET, niet eens denken aan iets anders.


Ik zou de klant overhalen op deze manier:

- Welke infrastructuur willen jullie? (windows, unix, bsd, etc (denk aan punt 1 & 4)) -> X
- Op deze infrastructuur draait Y het beste
- De applicatie zal geoptimaliseerd worden met Y voor X
- Punt

[Janoz]

Verwijderd schreef op donderdag 09 december 2004 @ 13:54:
Enfin, PHP zou prima voldoen, heeft de client ook geen Java nodig, is wel zo makkelijk.

Door deze opmerking begin ik ernstig te twijvelen of je uberhaupt wel weet wat met een java/j2ee applicatie wordt bedoeld.

[Verwijderd]

begon gelijk aan applets te denken.... foutje bedankt...

Dacht aan iets als de SIDN applicatie...

[ Voor 27% gewijzigd door Verwijderd op 09-12-2004 14:15 ]

[djc]

Ik denk dat de kwaliteit van je applicatie meer van je programmeurs dan van je platform af zal hangen. In PHP kan je zeer goede applicaties schrijven, die duidelijk gestructureerd zijn in lagen (al geef ik onmiddellijk toe dat het ook heel makkelijk is om slechte code te schrijven in PHP - daarom heb je goede programmeurs nodig!). Ook is er het voorbeeld van Friendster, dat juist van Java naar PHP migreerde om performance-redenen; zoek eens naar de share-nothing architecture die PHP gebruikt.

Het standaard-applicatie argument vind ik trouwens vrij bogus. Ik denk dat je voor een applicatie zoals beschreven wordt in de topicstart toch wel de beschikking krijgt over een enigszins geunificeerde omgeving, en zelf heb ik nooit echt problemen gehad met een gebrek aan interoperability (maar ik heb het alleen op Windows en Linux gebruikt, en bij een beperkt aantal hosts). Ook het argument "er komt elke week een nieuwe PHP uit, dus dat kan niet veel goeds betekenen" vind ik niet erg sterk... Updaten is een keuze (en het betekent ook dat bugs veel sneller worden opgelost dan bugs in Java).

Geen enkel platform is heilig, het is maar wat je ermee doet.

[ Voor 35% gewijzigd door djc op 09-12-2004 14:17 ]

[Verwijderd]

beschikking krijgt over een enigszins geunificeerde omgeving

Dus het wordt dan maatwerk.... Aangepast op juist DIE omgeving.

Standaard app = install & klaar is kees (forum, gastenboek, gallery, etc)
Maatwerk = aanpassen aan de wensen &/of omgeving

[djc]

Verwijderd schreef op donderdag 09 december 2004 @ 14:27:
Dus het wordt dan maatwerk.... Aangepast op juist DIE omgeving.

Standaard app = install & klaar is kees (forum, gastenboek, gallery, etc)
Maatwerk = aanpassen aan de wensen &/of omgeving

Het wordt zo te zien sowieso maatwerk, zie onder. En verder is maatwerk natuurlijk niet dichotoom. Het is meer een glijdende schaal, en het gebruik van een min of meer standaard PHP omgeving met wellicht enkele specifieke modulen op een bepaald OS noem ik nou niet bepaald enorm maatwerkerig.

-FoX- schreef op donderdag 09 december 2004 @ 13:20:
Beter nog... wat indien een vragende partij een webapplicatie wil laten ontwikkelen, laten we zeggen op nationaal niveau waarbij het uiterst belangrijk is dat er geen gegevens verloren gaan, privacy van de gegevens gerespecteerd dient te worden en er verschillende (tss 500 & 1000-tal) gelijktijdige gebruikers op het systeem zullen werken? Het systeem zal vooral dienen om gegevens bij te houden en statistieken te trekken.. maar ook enkele administratieve zaken.

[Verwijderd]

Zoals Manuzhai al zegt, het hangt ook een beetje van de programmeur af. Een echt goede programmeur zou in PHP ook wel wat moois kunnen maken (zie React), maar de kans dat een PHP programmeur in het algemeen sloppy is, is groter dan dat een Java programmeur dat is.

Java is volwassener en serieuzer, maar geef een kind een profesionele tool en het maakt er alsnog een janboel van. De menselijke factor blijft dus belangrijk.

Met Java heb je echter wel meteen de complete J2SE library tot je beschikking. Dit is een voordeel voor stukken code (domain logic) die eigenlijk onafhankelijk is van de gebruikte user toegang (web interface, console, desktop GUI, etc).

[-FoX-]

@Daventry: Ik doel eigenlijk meer op de applicatie in zijn geheel, in verschillende lagen (jsp/struts als front-end, actions, facade, business logic, dao (orm))
Dit is namelijk niet zo mooi verdeeld in een PHP-applicatie, al heeft de eindgebruiker hier eigenlijk schijt aan..

Bij het openen van dit topic doelde ik eigenlijk op enkele reacties wat een java-applicatie nu juist zo robuuster,.. e.d. maakt. Oftewel welke argumenten zou jij aanhalen om een java applicatie te verkopen in plaats van de applicatie die je concurrenten in php zouden maken? Of omgekeerd?

Iedereen spreekt nu namelijk graag in zijn eigen taaltje, wat maakt jou taal, voor de eindgebruiker, interessanter dan de andere?

[Alarmnummer]

-FoX- schreef op donderdag 09 december 2004 @ 14:47:
Iedereen spreekt nu namelijk graag in zijn eigen taaltje, wat maakt jou taal, voor de eindgebruiker, interessanter dan de andere?

In jouw geval: Waarom zou een opdrachtgever voor Java/.NET moeten kiezen ipv PHP (of uiteraard andersom). De opdrachtgever die wil gewoon een goeie applicatie voor weinig geld.. en de kans is groot dat de opdrachtgever niet thuis in de techniek. Dus hoe zou je een opdrachtgever kunnen adviseren?? Dat wil FOX weten.

[ Voor 24% gewijzigd door Alarmnummer op 09-12-2004 15:05 ]

[Verwijderd]

Een opdrachtgever zou het in principe niks moeten interesseren waarin een applicatie wordt opgeleverd, zolang je hem er van kunt overtuigen dat je kwaliteit en continuiteit (dus geen COBOL ) kunt leveren op het door jou gekozen platform (PHP/J2EE/.NET etc).

Met de sterk verbeterde OO ondersteuning in PHP 5 en alle optimalisatie mogelijkheden van Zend is PHP ook een volwassen platform geworden voor enterprise webapplicaties. Als er iets mis gaat met een applicatie, dan wordt dat IMO in 90% van de gevallen veroorzaakt door de applicatie zelf, zo'n 9,99% door de omgeving waar het draait (netwerkproblemen of problemen met de server/client machine) en voor 0,01% door het platform.

Geloof me, in Java en .NET kun je ook bagger applicaties schrijven, dat heb ik al veel te vaak gezien. Het ligt gewoon aan jezelf hoe elegant, robuust en maintainable je applicatie wordt. De webapplicatie waar ik momenteel aan werk schrijf ik in PHP juist vanwege de vrijheid die de taal biedt. Je moet er zelf wel op letten dat je het beheersbaar houdt, maar met een goed doordachte basisstructuur is dit geen probleem (ik zit momenteel aan 38.212 regels en 1,13 MB aan broncode en ik kom er nog prima mee uit de voeten).

Ook de mogelijkheden van PHP, Java en .NET zijn vergelijkbaar. Misschien dat in .NET alles wel wat eenboudig te gebruiken is (over Java wil ik het niet eens hebben op dit gebied ), maar m'n PHP applicatie maakt ook vrolijk gebruik van Active Directory etc. etc.


Om een lang verhaal kort te maken... jij moet er vertrouwen in hebben dat je op het platform dat je voorkeur heeft een degelijke applicatie kunt maken. Daarvan moet je je opdrachtgever overtuigen.

[Verwijderd]

Alarmnummer schreef op donderdag 09 december 2004 @ 15:03:
In jouw geval: Waarom zou een opdrachtgever voor Java/.NET moeten kiezen ipv PHP (of uiteraard andersom).

Weer de menselijk factor:

Als het een eenmalige opdracht is die voorderest weinig of geen onderhoud/uitbreidbaarheid nodig heeft, dan zou ik kiezen wat -jij- -nu- het beste beheerst. De opdracht gever maakt het dan niet uit waarin het product gemaakt is.

Als het echter om een doorlopende ontwikkeling gaat, dan zou je beter voor Java kunnen kiezen. Echte programmeurs blijken over het algemeen liever met een echte, serieuze programmeertaal te werken dan met een script taal. Op de langere termijn zou het dus je programmeurs gelukkiger houden, dat is goed voor de moraal in je team, en dat motiveert weer de verdere ontwikkeling.

Daarbij komt nog dat personeel met een informatica scholing (HBO of WO) ook in eerste instantie bekend zijn met Java of talen uit dezelfde familie (C, C++, C#). Ben je daarentegen van plan om voornamelijk ongeschoold personeel aan te trekken (hobyisten, die helemaal niet zo slecht hoeven te zijn), dan is mischien PHP weer een betere keuze.

Een php scripter zal over het algemeen weinig aan software architectuur doen, en van design patterns geen kaas gegeten hebben. Zoals gezegd, een goede (echte) programmeur zou dit ook in PHP kunnen toepassen, maar in de praktijk blijkt dit niet zo vaak voor te komen. PHP mensen denken vaak vrij direct, er moet een knop of een tabel op een website komen en die wordt direct 1:1 gescript. Dat er een achterliggende abstractie mogelijk is, wordt dikwijls niet gezien. Elke tabel wordt weer overnieuw gecode, ook al verschillen stukken code nauwelijks. Natuurlijk is de PHP programmeur zeer goed bekend met cut & paste, dus kwa productiviteit hoeft dit nog niets eens zo erg veel te schelen.

Sterker, een (goede) Java programmeur zal initieel meer tijd kwijt zijn, omdat zij eerst de abstractie opzoekt en een algemene methode schrijft. Als blijkt dat de abstractie inderdaad vaker concreet gemaakt kan worden wint de Java programmeur op de lange termijn. Blijkt het toch maar eenmalig noodzakelijk te zijn dan wint de PHP scripter.

Nogmaals, het is nogal gegeneraliseert, en natuurlijk kan een Java programmeur op de PHP wijze gaan ontwikkelen en de PHP scripter op de Java wijze.

[T-MOB]

Waarom wordt PHP als platform toch vaak zo "afgebrand" alszijnde een minder professioneel platform (of iets in die strekking). Dat er zoveel in geprutst wordt komt volgens mij alleen maar omdat de drempel om PHP te gebruiken ongeveer nul is. "apt-get install apache php4 phpmyadmin" en je kunt gelijk aan de slag. De drempel om aan een willekeurige andere (professionelere) taal te beginnen ligt net wat hoger. Als je dan de kwaliteit van de gemiddelde programmeur op een platform als maatstaf neem voor de kwaliteit van het platform dan komt PHP imo een beetje ondergewaardeerd uit de bus.

Voor een goede programmeur maakt het volgens mij geen fluit uit welke taal er wordt gebruikt. Programmeer je goed in Java dan zul je dat ook doen in PHP. Ben je een PHP-prutz0r (like me ) dan zul je er in Java niet 1-2-3 uitkomen. Het belangrijkste lijkt me dat je het platform kiest waarop je zelf het beste product kan afleveren. Als opdrachtgever zou ik dan het liefst willen zien dat de code onderhoudbaar is, dat de app zo OS-onafhankelijk mogelijk is, dat het niet te duur wordt, dat het efficiënt is (aka dat de hardwarekosten een beetje binnen de perken blijven), dat soort dingen.
PHP lijkt me daarbij een geschikte kandidaat, van de andere platformen heb ik te weinig verstand om hier een knoop over door te hakken.

[Verwijderd]

Nog snel even dit:

Als blijkt dat de abstractie inderdaad vaker concreet gemaakt kan worden wint de Java programmeur op de lange termijn

Theoretisch gezien dan, he. Hoe vaak gebeurt het niet dat abstractie te ver wordt doorgedreven? Hoe vaak wordt er niet eindeloos gepland om dat toch maar snel een ad hoc oplossing in elkaar te flansen? En dan nog, het platform staat hier helemaal los van. Je hebt gelijk dat er veel 'geschoolde' programmeurs Java leren, maar dat betekent niet dat je als 'geschoolde' programmeur geen abstractie of andere mooie constructies in PHP kunt toepassen.

Als opdrachtgever zou ik dan het liefst willen zien dat de code onderhoudbaar is, dat de app zo OS-onafhankelijk mogelijk is, dat het niet te duur wordt, dat het efficiënt is (aka dat de hardwarekosten een beetje binnen de perken blijven), dat soort dingen.
PHP lijkt me daarbij een geschikte kandidaat, van de andere platformen heb ik te weinig verstand om hier een knoop over door te hakken.

Voor webapplicaties is IMO PHP qua portabiliteit de beste keus. Java en .NET (via Mono) zullen het ook wel aardig doen, maar wat dit betreft zijn het deze twee platforms die zeker nog niet volwassen zijn. We hebben een tijd terug een onder Windows ontwikkelde Java webapp gedeployed op Linux (alletwee op dezelfde Sun VM) en toen liepen we tegen allerlei vage problemen aan (extra flushes nodig voor IO, etc etc). En volgens mij is .NET nog niet bepaald 1:1 op Mono te draaien, toch?

[Verwijderd]

Verwijderd schreef op donderdag 09 december 2004 @ 19:16:
Je hebt gelijk dat er veel 'geschoolde' programmeurs Java leren, maar dat betekent niet dat je als 'geschoolde' programmeur geen abstractie of andere mooie constructies in PHP kunt toepassen.

En dat is dus ook wat ik boven bedoel. Het lijkt een beetje op de discussie van welke vechtsport nou effectiever is. Het echte antwoord is dat het vaak aan de beoefenaar zelf ligt en niet zozeer aan de sport.

Wel is het zo dat 'moeilijkere' talen, hoe paradoxaal het ook moge klinken, de moeilijkheid initieel als voordeel hebben. Je scheidt meteen al het kaf van de koren. Zeker bij talen als C en C++ vallen de echte prutsers al snel door de mand. Het is net zoals bij HTML en IE. Doordat IE veel fouten pikt kunnen er veel mensen snel mee aan de gang. Als dat geneuzel met tags correct afsluiten is aan hun niet besteed. We weten allemaal wat voor gevolgen dat heeft.

Dat PHP niet met strong typing werkte was een voordeel voor zulk soort type mensen. Die snappen het hele nut van types toch niet, en vinden het zelfs complete onzin dat je telkens types moet opgeven. Dat je zonder types op te geven de mogelijkheid voor automatische correctheids controlle voor een gedeelte ondermijnt, tsja... zover denken de meeste PHP'ers niet eens. Als ik voor mijn bedrijf sollicitanten een opdracht geef, zijn het altijd de PHP'ers die geen goede structuur weten aan te brengen in hun opdracht. Als ik hen dan vraag waarom alles een Object is in de member signatures is het antwoord steevast dat dat zo lekker flexibel is en dat types specificeren alleen maar beperkent is. Het zelfde soort mensen wil ook altijd, bij een web app opdracht, alles op 1 (jsp) pagina hebben. Tags, (business logic) code, en SQL. Allemaal lekker doorelkaar. Als ik dan vraag waarom ze dat doen is het antwoord dat het juist goed werkt om dingen die bij elkaar horen bij elkaar te zetten en dat scheiding van dergelijke fundamenteel verschillende dingen alleen maar de boel nodeloos complex maakt.

Voor webapplicaties is IMO PHP qua portabiliteit de beste keus. Java en .NET (via Mono) zullen het ook wel aardig doen, maar wat dit betreft zijn het deze twee platforms die zeker nog niet volwassen zijn. We hebben een tijd terug een onder Windows ontwikkelde Java webapp gedeployed op Linux (alletwee op dezelfde Sun VM) en toen liepen we tegen allerlei vage problemen aan (extra flushes nodig voor IO, etc etc).

Dan heb je toch zelf iets echt fout gedaan. Welke application server of servlet container heb je dan gebruikt? Wij deployen ook op verschillende systemen (Linux, Windows en Mac OS X, met application servers Orion en Sun Application Server) maar alles draait gewoon identiek. Flushes zijn ook zeker niet nodig, maar welke bedoel je eigenlijk? Flushes voor je response of voor je file I/O?

Er zijn overigens wel application server specificieke features. Als je naar verschillende servers wilt deployen moet je die niet gebruiken. Tevens heb je natuurlijk ook bij Java gewoon revisies. Als een server een oudere J2EE of J2SE versie draait en jij roept nieuwe functies aan dan zal dat niet werken. Voorts heb je af en toe een VM release die gewoon buggy is, dat kan wel voor echte problemen zorgen. Met VM upgrades moet je dus wel altijd voorzichtig zijn.

In de velen jaren dat ik met Java werk is eigenlijk de enige platform afwijkende dingen die ik tegengekomen ben zaken in de AWT library (voor desktop werk dus). Sommige platformen die wel mouselistener events sturen bij een drag buiten de window, andere niet, etc.

[Verwijderd]

Met php kun je best leuke applicatie's maken, je moet alleen niet veel verwachten qua frameworks en support. Er is op de java platvorm zoveel te vinden als het gaat om MCV framework's, Presentation frameworks, enz. Bovendien zijn er gigantische veel testtools beschikbaar die op elke niveau je applicatie kunnen testen.

Bovendien zijn er gigantische veel kant en klare oplossingen zoals lucene! Op de php platvorm heb je ook wel dat soort dingen, maar in veel mindere mate.

Dat betekent niet dat je php moet afschrijven, voor 80% van de apps denk ik dat php genoeg bied. Je kunt Unit testen in php, je kunt MCV gebruiken, beperkt OO, enz. Ligt ook aan je eigen kennis natuurlijk.

Als je kunt niet zo eenvoudig dingen zoals applicatie's maken die zoals java webstart werken, of applet's, enz.

[Olaf van der Spek]

Zijn er al PHP IDEs beschikbaar die statisch de hele app kunnen checken zodat je tijdens het draaien geen syntax / 'compile-time' fouten meer krijgt?
Zo nee, dan zou ik zeker niet voor PHP gaan.

[Alarmnummer]

OlafvdSpek schreef op donderdag 09 december 2004 @ 20:06:
Zijn er al PHP IDEs beschikbaar die statisch de hele app kunnen checken zodat je tijdens het draaien geen syntax / 'compile-time' fouten meer krijgt?
Zo nee, dan zou ik zeker niet voor PHP gaan.

Dat vind ik dus een steengoed argument.

En ik zou dus niet zozeer voor een IDE gaan die dat kan.. maar een of andere syntax/semantic check achtige tool.

[ Voor 16% gewijzigd door Alarmnummer op 09-12-2004 20:11 ]

[Verwijderd]

OlafvdSpek schreef op donderdag 09 december 2004 @ 20:06:
Zijn er al PHP IDEs beschikbaar die statisch de hele app kunnen checken zodat je tijdens het draaien geen syntax / 'compile-time' fouten meer krijgt?
Zo nee, dan zou ik zeker niet voor PHP gaan.

Volgens mij is dat bij weak typing iha onmogelijk. Als het type pas bepaalt wordt aan de hand van wat je er aan toekent (bijvoorbeeld uit user input), dan kun je dat nooit statisch checken. Er zijn wel wat dingen mogelijk, en ik neem aan dat de betere PHP tools dat wel kunnen en dan warnings geven. De echte PHP prutser negeert die dan natuurlijk vrolijk.

Voornamelijk dat laatste aspect is zorgelijk. Met C of C++ -KUN- je geen code draaien die typerings of syntax fouten bevat. Met script talen kan dat per definitie wel.

(en natuurlijk zijn er bij zowel Java, C, C++ als C# nog genoeg andere runtime fouten die je kunt krijgen, maar een groot gedeelte vangt de compiler al af)

[-FoX-]

Blijkbaar kunnen veel mensen hier niet lezen, of posten ze gewoon aan de hand van de topictitel. De vraag was, zoals Alarmnummer goed begrepen had, op welke wijze de "niet-technische" opdrachtgever in dit geval geadviseerd kan worden om de ontwikkeling toch te laten doorgaan in Java (of PHP).

Over kennis en menselijke factor wil ik het even niet (meer) hebben. Ik WEET dat er mooie applicaties in php kunnen opgezet worden, evenals in Java. Beide partijen hebben meer dan voldoende kennis in hun vakgebied!!

Het gaat mij hier dus echt over de argumenten die gebruikt zouden kunnen worden om de opdrachtgever te overhalen om voor de Java-webapplicatie te kiezen. Want ik neem aan dat het de opdrachtgever koud laat welke design patterns er gebruikt worden.. maar dat het hem wel interesseert dat het effectief en toekomstgericht opgebouwd werd (Let op de woordspeling, er wordt hetzelfde bedoeld, maar het 2de klinkt de opdrachtgever beter in de oren)!

[Verwijderd]

-FoX- schreef op donderdag 09 december 2004 @ 20:17:
Blijkbaar kunnen veel mensen hier niet lezen, of posten ze gewoon aan de hand van de topictitel. De vraag was, zoals Alarmnummer goed begrepen had, op welke wijze de "niet-technische" opdrachtgever in dit geval geadviseerd kan worden om de ontwikkeling toch te laten doorgaan in Java (of PHP).

Wat mij als project leider een beetje over de streep trekt is dat met gecompileerde talen er bij het inleveren al 1 bewijs van correctheid is geleverd: het compileerd!

Dat -bewijs- heb ik zwart op wit. PHP kan een dergelijk bewijs niet leveren, je moet de hele applicatie doorwerken, en alle mogelijkheden proberen.

Natuurlijk weten de programmeurs onder ons dat het feit of iets wel of niet compiled zo basic is en dat het nog niet veel zegt of je app goed of niet draait. Maar zelfs deze basic garantie heb je niet met PHP.

[Verwijderd]

Ach, programmeren is niet zo moeilijk. De visie hebben om een probleem op de beste (elegantste, simpelste, snelste, best onderhoudbare, veiligste) manier aan te pakken, dat is het echt moeilijke. Helaas zijn er nog al wat programmeurs die daar geen kaas van gegeten hebben, maar wel erg thuis zijn in de laatste buzzwords...

Java en PHP hebben ieder zo hun eigen elegantie, voor- en nadelen...

Eigenlijk is het lastigste nog om te weten *welke* problemen je moet oplossen ;-)

[ Voor 10% gewijzigd door Verwijderd op 09-12-2004 20:35 ]

[Olaf van der Spek]

Verwijderd schreef op donderdag 09 december 2004 @ 20:15:
Volgens mij is dat bij weak typing iha onmogelijk.

Het is niet volledig mogelijk, maar zelfs parse errors worden vaak pas at run-time ontdekt.

Maar weak typing is inderdaad nog een goede reden om niet voor PHP te kiezen.

[Verwijderd]

-FoX- schreef op donderdag 09 december 2004 @ 20:17:

[..]

Mijn opdrachtgevers heb ik als volgt overgehaald:

- Ik kon meer zekerheid geven dat de code bugvrij was ( php moet je echt zorgen dat je met de browser elke lijn hebt gecheckt )
- Ik kon zorgen dat hij makkelijker bij anderen terecht kon ( ivm gebruik van bekende framework's)
- ik kon garanderen dat ik gebruik maakte van oplossingen die constant werden verbeterd

- verder hebben dingen als in kunnen bouwen van zeer goede zoekmachine zoals lucene, support aan java van grote partijen zoals IBM, Sun, enz, een rol gespeeld.

[Verwijderd]

Natuurlijk weten de programmeurs onder ons dat het feit of iets wel of niet compiled zo basic is en dat het nog niet veel zegt of je app goed of niet draait. Maar zelfs deze basic garantie heb je niet met PHP.

Dit is dus garantie tot aan de voordeur. Ook C en Java hebben runtime errors maar nog belangrijker,het gaat er niet om dat het iets doet maar om dat het doet wat jij wilt dat het doet.

Maar om FOX wat gelukkiger te maken. Het gaat er uiteindelijk niet om of Java beter is dan PHP maar dat jij een applicatie kan maken in Java die beter is dan wat de concurrentie in PHP kan maken. Dan kun je kijken naar zaken die voor de klant interessant zijn. Wat voor integratie met zijn huidige systemen is er nodig, kun je gebruik maken van standaard software of moet alles van de grond af opgebouwd worden, is schaalbaarheid relevant, welke kennis heb jij in huis en wat heeft hij beschikbaar. Als je een goed beeld hebt over wat de klant wilt kun je het plaatje invullen met de technieken die jij handig vindt. Dat dit allemaal Java gebaseerd is zal eigenlijk de meeste klanten worst wezen. Als de klant dan het gevoel heeft dat het aan zijn eisen voldoet en ruimte over laat voor aanpassingen als die nodig blijken (en de prijs passend is) zullen ze het project overwegen. Anders heb je je tijd verspilt.

Maar het heeft geen zin om te kijken naar de verschillen tussen PHP en Java. Meestal heeft de klant geen voorkeur en als de klant wel een voorkeur heeft is hij daar erg lastig vanaf te brengen. Want er zijn zat mensen met hele goede ervaringen met websites en PHP.

[Erkens]

OlafvdSpek schreef op donderdag 09 december 2004 @ 20:06:
Zijn er al PHP IDEs beschikbaar die statisch de hele app kunnen checken zodat je tijdens het draaien geen syntax / 'compile-time' fouten meer krijgt?
Zo nee, dan zou ik zeker niet voor PHP gaan.

http://www.zend.com/store/products/zend-studio.php

[Verwijderd]

OlafvdSpek schreef op donderdag 09 december 2004 @ 20:06:
Zijn er al PHP IDEs beschikbaar die statisch de hele app kunnen checken zodat je tijdens het draaien geen syntax / 'compile-time' fouten meer krijgt?
Zo nee, dan zou ik zeker niet voor PHP gaan.

Je zou je hele app door de Zend encoder heen kunnen halen.
Edit: 'Net' te laat

[ Voor 9% gewijzigd door Verwijderd op 09-12-2004 23:45 ]

[Verwijderd]

Verwijderd schreef op donderdag 09 december 2004 @ 23:43:
[...]

Je zou je hele app door de Zend encoder heen kunnen halen.
Edit: 'Net' te laat

Je zegt het zelf al 'je zou'...

Daaruit (en ook al uit de monden van vele andere PHP'ers) maak ik op dat dat zeker niet iets is wat gebruikelijk is. En ook zal zou dat zo zijn, dan moet je als je een script aangeleverd krijgt (als leek zijnde) maar geloven dat het gechecked is. Bij Java is dat toch wat anders.

Ik moet wel eerlijk zeggen dat ik geloof dat de Eclipse JDT (java) compiler wel classes kan genereren die compile fouten bevatten.

[djc]

Ik vind dat static typing in dit topic zwaar overschat wordt. Strong typing is misschien wel een betere keus is dan weak typing (waar ik nog wel in mee zou willen gaan), maar static typing heeft ook een heleboel nadelen. Dan heb ik liever een applicatie die volledig doorgecheckt word door unit tests dan een applicatie waarvan ik toevallig weet dat ie gecompileerd wordt.

[Grijze Vos]

Kom op zeg, dus omdat je PHP niet compileerd, is het slechter.

98% van jullie argumenten tegen PHP vloeien voort uit slecht programmeren. Een slechte programmeur programmeert even slechte Java code. Beiden gevallen zijn onwenselijk.

Als je niet de know-how hebt om zulke grote projecten te beheersen, begin er dan gewoon (nog) niet aan.

[eamelink]

Verwijderd schreef op donderdag 09 december 2004 @ 13:54:
- Standaard applicatie?
Voor zulke zaken zou ik dus echt GEEN PHP gebruiken. Het is heel leuk dat het platform onafhankelijk is, maar op IEDERE server is IEDERE PHP configuratie ANDERS. Het is onmogelijk om een (geavanceerde) PHP applicatie te schrijven die op FreeBSD hetzelfde draait als op Debian en als op Windows.

Nou, ZO ingrijpend zijn die configverschillen nou ook weer niet. Veel verder dan magic_quotes en dergelijke gaat de 'problemen' meestal niet. En dat kan je prima met een configfiletje of gewoon een configcheck systeempje afvangen. Er zijn zát standaard php applicaties die op windows, unix en linux werken...

De ene server heeft dit, de andere dat, de ene heeft die mogelijkheden uigeschakeld de andere dat, etc etc.

Maar feit is wél dat zowat álle servers bij standaard hostingproviders ten minste php draaien, terwijl je naar tomcat aardig moet zoeken laat staan een andere container

Vergeet daarnaast niet dat er zo goed als iedere week een PHP update is waarin soms dingen gewijzigd worden.

Nou, daar heb ik nooit last van eigenlijk. Hooguit bij een major versiesprong dat dingen echt niet meer werken, of als je nog met betalibs zat te prutsen dat er iets veranderd. Maar voor betalibs had je voor de zekerheid toch al een wrapper gemaakt, dus daar is geen probleem, toch, toch, toch?

Overigens zou ik voor Java kiezen, maar ik weet zeker dat het met php ook prima kan . Uiteindelijk komt het gewoon op jouw voorkeur uit

[NMe]

Grijze Vos schreef op vrijdag 10 december 2004 @ 00:52:
Kom op zeg, dus omdat je PHP niet compileerd, is het slechter.

Dat nog naast het feit dat ook PHP code te compileren valt, of gecompileerde code is zelfs te cachen, waardoor het genereren/laden van een pagina sneller gaat.

Reactie op de topicstart, zonder de gehele draad gelezen te hebben: voor webapplicaties die door een groot publiek gebruikt moeten gaan worden, zou ik voor PHP gaan. Tenminste, als jij geen controle hebt over de hardware en software die op de systemen van deze mensen draait. Java is afhankelijk van een virtuele machine, en die kan op sommige pc's nog aardig wat tijd vergen om op te starten. PHP daarentegen genereert simpelweg HTML, en wordt meteen weergegeven. Wanneer je echter een applicatie maakt die alleen door werknemers van een bepaald bedrijf gebruikt gaat worden, kun je weer wel voor de Java-oplossing gaan, omdat je daar min of meer weet wat er op die systemen kan en niet kan.

Hoe dan ook, zoals hierboven al vaker gezegd is zie ik: programmeer in die omgeving waar je het beste product kan maken. Dat kan afhankelijk zijn van je ervaring, maar dat kan ook afhankelijk zijn van de beperkingen van een omgeving met het oog op datgene wat je wil maken. En daarover kan ik niet oordelen.

[Eärendil]

-NMe- schreef op vrijdag 10 december 2004 @ 03:03:Reactie op de topicstart, zonder de gehele draad gelezen te hebben: voor webapplicaties die door een groot publiek gebruikt moeten gaan worden, zou ik voor PHP gaan. Tenminste, als jij geen controle hebt over de hardware en software die op de systemen van deze mensen draait. Java is afhankelijk van een virtuele machine, en die kan op sommige pc's nog aardig wat tijd vergen om op te starten. PHP daarentegen genereert simpelweg HTML, en wordt meteen weergegeven.

Als je de draad nou wel had gelezen wist je dat het hier om server-side Java gaat, en dat beide oplossingen HTML genereren

[Alarmnummer]

Ik kan er niets aan doen.. maar er zijn flink wat mensen die in dit topic volslagen uit hun nek lopen te lullen... Een typisch got kwaaltje...

[Erkens]

Verwijderd schreef op vrijdag 10 december 2004 @ 00:24:
[...]


Je zegt het zelf al 'je zou'...

Daaruit (en ook al uit de monden van vele andere PHP'ers) maak ik op dat dat zeker niet iets is wat gebruikelijk is. En ook zal zou dat zo zijn, dan moet je als je een script aangeleverd krijgt (als leek zijnde) maar geloven dat het gechecked is. Bij Java is dat toch wat anders.

Waarom het niet gedaan wordt komt gewoon omdat dat extra geld kost, niet dat veel uitmaakt, maar zonder die kosten werkt het toch ook? Hoewel je er wel meer snelheid voor terug krijgt
Nu dat tweede gedeelte, als je dus je PHP 'compiled' moet je maar geloven dat het gechecked is Hoe anders is gecompilde PHP code in vergelijking tot de java byte code?

[Glimi]

Niet technische redenen zoals gevraagd:
- Java wordt supported door grote bedrijven. Sun, IBM, Bea etc. Bedrijven hebben veelal een neiging om iets te nemen waar een bedrijf achter zit.
- Java heeft goed gedefinieerd wat wel en niet compatible blijft. Bovenal is het versie beleid van Java een stuk stakker, er wordt minder snel released.

Echt veel niet technisch kan ik verder niet bedenken, technisch des te meer

Manuzhai schreef op vrijdag 10 december 2004 @ 00:47:
Ik vind dat static typing in dit topic zwaar overschat wordt. Strong typing is misschien wel een betere keus is dan weak typing (waar ik nog wel in mee zou willen gaan), maar static typing heeft ook een heleboel nadelen. Dan heb ik liever een applicatie die volledig doorgecheckt word door unit tests dan een applicatie waarvan ik toevallig weet dat ie gecompileerd wordt.

Unit testing is een van de slechts mogelijke manieren van dynamic testing. Het pikt gemiddeld iets van rond de 30% van de fouten op. Dit omdat de programmeur vaak de tests ook schrijft en dus zijn beeld erop blijft projecteren (white box tests) [Weinberg's law: "A developer is unsuited to test his or her code."]. Code reviews/inspections, metrics en functional testing met live data zijn bewezen effectiever.

[Alarmnummer]

Unit testing is een van de slechts mogelijke manieren van dynamic testing. Het pikt gemiddeld iets van rond de 30% van de fouten op.

Waar haal jij dit vandaan?

Dit omdat de programmeur vaak de tests ook schrijft en dus zijn beeld erop blijft projecteren (white box tests) [Weinberg's law: "A developer is unsuited to test his or her code."].

Bullshit.

Een developer is wel degelijk geschikt om zijn eigen code te testen. En testen die je niet alleen om het testen maar ook om allerlei grijze gebieden van functionaliteit te achterhalen.

Code reviews/inspections, metrics en functional testing met live data zijn bewezen effectiever.

Aha.. ik neem aan dat jij spreekt uit jarenlange ervaring? Of heb je dit uit een boekje? Zo ja? Meld dat dan ff.. dan weten we hoe serieus we het moeten nemen.

No offence hoor.. Maar ik stoor me aan het feit dat allerlei mensen dingen lopen te roepen terwijl ze er geen fuck praktische ervaring mee hebben.

Ok.. en waarom zou ik geen php voor applicaties waar correctheid erg belangrijk is:
1) het kan niet compileren -> een hele lading syntactische en semantische fouten worden niet gevonden. Voor mensen die denken dat dit geen probleem is dan ben je of je bent een kind van God.. of je bent te achterlijk om het te begrijpen. Scripting hoort niet thuis in serieuze omgevingen.
2) een platform waar unit testen niet de standaard is neem ik niet serieus. Unit/integrationtesting is de stap na syntactische en semantische controle om fouten op te sporen.
3) voor java/.net heb je frameworks mbt security, transacties, monitoring etc. Allemaal zaken waar ik eerlijk gezegd niet zonder zou willen werken.

En verder durf ik de stelling wel aan dat het gemiddeld nivo van een php programmeur een orde van grote lager is dan het gemiddeld nivo van een Java programmeur. En als het nivo van een programmeur laag is.. tja.. dan lijkt het me wel duidelijk wat voor software daar gemiddeld gezien dan ook uit zal komen.

[ Voor 41% gewijzigd door Alarmnummer op 10-12-2004 09:34 ]

[Glimi]

Alarmnummer schreef op vrijdag 10 december 2004 @ 09:24:
Waar haal jij dit vandaan?

Applied Software Measurement Onderzocht door Jones, lijkt mij de enige manier om op percentages te komen. Trouwens die 30% klopt niet helemaal. Dat is na code review, 50% is het zonder review.

Bullshit.

Een developer is wel degelijk geschikt om zijn eigen code te testen. En testen die je niet alleen om het testen maar ook om allerlei grijze gebieden van functionaliteit te achterhalen.

Want? Waarom bewijst Weinberg dan dit wel voor zijn onderzochte niet triviale projecten?

Aha.. ik neem aan dat jij spreekt uit jarenlange ervaring? Of heb je dit uit een boekje? Zo ja? Meld dat dan ff.. dan weten we hoe serieus we het moeten nemen.

No offence hoor.. Maar ik stoor me aan het feit dat allerlei mensen dingen lopen te roepen terwijl ze er geen fuck praktische ervaring mee hebben.

Inderdaad boeken ja. Boeken waarin stellingen bewezen worden en die na 30 jaar benoemd zijn als 'law' van de software engineering.
Je kunt de boom in met je 'no offence'. Je weet ongeveer wel wat ik weet en in welke situatie ik zit, dus je zit gewoon weer in het rond te trappen; verrek maar lekker.

[Alarmnummer]

Glimi schreef op vrijdag 10 december 2004 @ 09:49:
Want? Waarom bewijst Weinberg dan dit wel voor zijn onderzochte niet triviale projecten?

Aha.. dus omdat een of andere pipo bewezen heeft dat testen niet door de programmeur gedaan moeten worden zijn de testen ineens niet praktisch meer? Waarom dacht je dat de Agile software movement testing dan zo hoog in het vaandel heeft staan? Waar dacht je dat de kreet Test Driven Development vandaan kwam? Verder is het praktisch gezien in veel bedrijven ONHAALBAAR dat aparte groepen gaan testen!

Dus de info die hij geeft is in dat opzicht totaal nutteloos. Ontoepasbare informatie.

Inderdaad boeken ja. Boeken waarin stellingen bewezen worden en die na 30 jaar benoemd zijn als 'law' van de software engineering.

Je kunt de boom in met je 'no offence'. Je weet ongeveer wel wat ik weet en in welke situatie ik zit, dus je zit gewoon weer in het rond te trappen; verrek maar lekker.

Ik weet heel goed in welke situatie je zit en dat is dus ook precies de reden dat ik er een opmerking over maak. In de praktijk is niet alles zo mooi als in de boekjes. Veel bedrijven zijn klein.. er zijn geen strakke test groepen (als er uberhaubt al iets aan gedaan wordt). Je kunt dus wel mooi redeneren vanuit een hele perfecte it wereld, maar de praktijk is gewoon anders.

[Verwijderd]

No offence hoor.. Maar ik stoor me aan het feit dat allerlei mensen dingen lopen te roepen terwijl ze er geen fuck praktische ervaring mee hebben.

Amen! Trouwens, heb je al eens een groter project in PHP geimplementeerd, Alarmnummer?

Laten we het er gewoon over eens zijn dat de keuze van het platform afhankelijk is (of zou moeten zijn) van waar de programmeur het beste mee uit de voeten kan. Als je van al die mooie opties die je beschrijft geen gebruik kunt of wilt maken, dan heb je er dus ook niks aan. Het komt dus gewoon weer neer op de ervaring en vaardigheid van de programmeur(s).

Je kunt dus wel mooi redeneren vanuit een hele perfecte it wereld, maar de praktijk is gewoon anders.

Kijk, daar ben ik het 100% mee eens. En IMHO is dat ook de reden dat de bovengenoemde nadelen aan PHP vaak in het niet vallen tegenover de rest van wat er allemaal mis kan gaan.

[ Voor 20% gewijzigd door Verwijderd op 10-12-2004 10:02 ]

[kasper_vk]

-FoX- schreef op donderdag 09 december 2004 @ 20:17:
Blijkbaar kunnen veel mensen hier niet lezen, of posten ze gewoon aan de hand van de topictitel. De vraag was, zoals Alarmnummer goed begrepen had, op welke wijze de "niet-technische" opdrachtgever in dit geval geadviseerd kan worden om de ontwikkeling toch te laten doorgaan in Java (of PHP).
[...]
Het gaat mij hier dus echt over de argumenten die gebruikt zouden kunnen worden om de opdrachtgever te overhalen om voor de Java-webapplicatie te kiezen. Want ik neem aan dat het de opdrachtgever koud laat welke design patterns er gebruikt worden.. maar dat het hem wel interesseert dat het effectief en toekomstgericht opgebouwd werd (Let op de woordspeling, er wordt hetzelfde bedoeld, maar het 2de klinkt de opdrachtgever beter in de oren)!

Bij het overhalen van de opdrachtgever zul je, denk ik, met argumenten moeten komen als

• bouwkosten / bouwtijd
• TCO (typisch management buzzword )
• en ik denk dat je opdrachtgever blij maakt als er eenvoudig een andere partij mee verder kan ontwikkelen. (m.a.w. hij zit zo min mogelijk vast aan de initiele bouwer van het spul).

Misschien dat je j2ee kan presenteren als beter overdraagbaar, omdat er (volgens mij) behoorlijk veel detacheerders zijn die (gecertificeerde / goed opgeleide) j2ee ontwikkelaars kunnen leveren, en voor php ziet dat er iets kariger uit.
Daarnaast wordt op veel hbo's & uni's Java gedoceerd (voor php weet ik dat niet); wat het ook weer iets beter overdraagbaar maakt als het om b.v. stagiaires / afstudeerders zou gaan.

[ Voor 4% gewijzigd door kasper_vk op 10-12-2004 10:08 ]

[Creepy]

Alarmnummer schreef op vrijdag 10 december 2004 @ 09:58:
[...]

Aha.. dus omdat een of andere pipo bewezen heeft dat testen niet door de programmeur gedaan moeten worden zijn de testen ineens niet praktisch meer? Waarom dacht je dat de Agile software movement testing dan zo hoog in het vaandel heeft staan? Waar dacht je dat de kreet Test Driven Development vandaan kwam? Verder is het praktisch gezien in veel bedrijven ONHAALBAAR dat aparte groepen gaan testen!

Dus de info die hij geeft is in dat opzicht totaal nutteloos. Ontoepasbare informatie.

Ik hoop niet dat je bedoelt dat testen door de programmeur genoeg is om software te ontwikkelen met zo weinig mogelijk bugs.

Software testen is een vak. Een vak apart. En dat is echt niet iets wat je alleen aan de ontwikkelaar moet overlaten. Tuurlijk moet een ontwikkelaar z'n eigen code testen en z'n eigen software gebruiken ("eat your own dog food") zo zie je als ontwikkelaar veel sneller wat wel en niet goed in elkaar zit. Tuurlijk zijn er zat kleinere bedrijven die geen apart test-team hebben maar welk bedrijf bestaat uit alleen ontwikkelaars??

[Verwijderd]

Dank je dat je ons weer even aan het topic herinnert, kasper_vk

Een opdrachtgever die een overwogen keuze maakt (deze zijn trouwens helaas dun gezaaid, naar mijn jarenlange ervaring ) zal geinteresseerd zijn in het volgende:

- Correcte werking
- Gebruiksvriendelijkheid
- Continuiteit
- Uitbreidbaarheid
- Beheerbaarheid
- Schaalbaarheid
- Prestige

De eerste 6 zijn in principe platform-onafhankelijk, dit kun je min of meer, waarschijnlijk op elk platform wel voor ellkaar krijgen. Maar ik stond er ook van te kijken van dat prestige zo'n belangrijk item is.

Dankzij de marketing van Microsoft bijvoorbeeld hebben .NET applicaties al een goede naam als innovatief, state-of-the-art etc. Voor Java geldt hetzelfde, door de commitment van grote bedrijven en door de toepassing ervan in consumer producten (GSM's!). PHP heeft inderdaad wat dit betreft een slechtere naam en wordt vaker geassocieerd met hobbyisten. Wat dat betreft is Java misschien een betere keuze om indruk op een opdrachtgever te maken.

Hopelijk heb je hier wel wat aan Fox, om onze anti/pro PHP discussie in je thread wat goed te maken

[Glimi]

Alarmnummer schreef op vrijdag 10 december 2004 @ 09:58:
Aha.. dus omdat een of andere pipo bewezen heeft dat testen niet door de programmeur gedaan moeten worden zijn de testen ineens niet praktisch meer?
Waarom dacht je dat de Agile software movement testing dan zo hoog in het vaandel heeft staan? Waar dacht je dat de kreet Test Driven Development vandaan kwam? Verder is het praktisch gezien in veel bedrijven ONHAALBAAR dat aparte groepen gaan testen!

Dus de info die hij geeft is in dat opzicht totaal nutteloos. Ontoepasbare informatie

Hij heeft bewezen dat ze niet zo effectief zijn en dat ze effectiever zijn als een ander het doet. Echter het is het goedkoopst als de programmeur dat doet, dus dat is een afweging die gemaakt moet worden. Je kunt best de programmeur de testcase blijven laten schrijven, maar dan moet je nou eenmaal genoegen nemen met een verminderd effecitiveitspercentage. Dat is geen ontoepasbare informatie en dat is waar ik op reageerde. Een applicatie weke gecovered is door testcases bevat gewoon nog bugs.
Het is beter om een combinatie van Verification and Validation methods te gebruiken voor een beter effect, zoals het toepassen van metrics op de code. Dit omdat veel methodes andere fouten vinden. Dat is ook bewezen trouwens.

Ik weet heel goed in welke situatie je zit en dat is dus ook precies de reden dat ik er een opmerking over maak.

Dat kan ook op een normale toon. Hier werd ik in ieder geval niet vrolijk van.

In de praktijk is niet alles zo mooi als in de boekjes. Veel bedrijven zijn klein.. er zijn geen strakke test groepen (als er uberhaubt al iets aan gedaan wordt). Je kunt dus wel mooi redeneren vanuit een hele perfecte it wereld, maar de praktijk is gewoon anders.

Ik werk vijf jaar bij een bedrijf dat is gegroeid van 5 medewerkers naar ~30 en daar is alles verre van perfect kan ik je zeggen. Echter dat is niet wat ik wou zeggen, de intentie heb ik hierboven wel ten treure uitgelegd.

[Alarmnummer]

Verwijderd schreef op vrijdag 10 december 2004 @ 10:00:
Amen! Trouwens, heb je al eens een groter project in PHP geimplementeerd, Alarmnummer?

Nope.. Maar zie mijn argumenten tegen php. Dat zijn dingen die ik eis bij een goeie programmeertaal. Ik werk bv ook erg veel met Prolog en het gebrek aan bv een typesysteem en controle op bestaande functies is iets dat mij onnodig bergen met tijd kost. (Daarom heb ik optioneel al extra warnings opgeworpen als je zoiets doet)

Laten we het er gewoon over eens zijn dat de keuze van het platform afhankelijk is (of zou moeten zijn) van waar de programmeur het beste mee uit de voeten kan.

Voor een gedeelte ben ik het hiermee eens. Iemand die thuis in Java moet je niet ineens in PHP laten werken en ook niet andersom.

Maar de opdrachtgever heeft keuze uit meerdere aannemers die thuis zijn in verschillende talen. Dus in principe hoeft niemand te werken met een taal waar hij niet in thuis is.

Als je van al die mooie opties die je beschrijft geen gebruik kunt of wilt maken, dan heb je er dus ook niks aan. Het komt dus gewoon weer neer op de ervaring en vaardigheid van de programmeur(s).

Voor een gedeelte ben ik het met je eens.. Maar een goed platform scheelt zo godsellendig veel werk. .NET met hun declaratieve transacties, Spring met hetzelfde.. met super eenvoudige JMX/Webservice/Remoting integratie. Security? Doe ook maar declaratief. Een goed platform met een iets minder goeie programmeur is beter dan een goeie programmeur met een iets minder platform. (imho).

Je krijgt gewoon met een goed platform een enorme performance boos.

Kijk, daar ben ik het 100% mee eens. En IMHO is dat ook de reden dat de bovengenoemde nadelen aan PHP vaak in het niet vallen tegenover de rest van wat er allemaal mis kan gaan.

Ik heb zelf het een en ander met Scripting talen gedaan.. en ook met talen met een wat minder krachtig typesysteem (bv Java zonder generics). En het valt mij op dat ik gewoon vaak fouten maak... Een goed typesysteem die compiletime al veel problemen opspoort maakt mij tot een effectiever programmeur.

Zelf JSP is vervelend als ik pas runtime achter fouten kom...

Ik wil dus zo vroeg mogelijk (liefst compiletime al) achter fouten komen. En dat is bij PHP dus niet mogelijk.

[ Voor 3% gewijzigd door Alarmnummer op 10-12-2004 10:27 ]

[Erkens]

Alarmnummer schreef op vrijdag 10 december 2004 @ 10:24:
Ik wil dus zo vroeg mogelijk (liefst compiletime al) achter fouten komen. En dat is bij PHP dus niet mogelijk.

ik kan zien dat jij geen ervaring hebt met PHP
doe dan ook geen uitspraken die niet waar zijn.

[Alarmnummer]

Creepy schreef op vrijdag 10 december 2004 @ 10:17:
[...]
Ik hoop niet dat je bedoelt dat testen door de programmeur genoeg is om software te ontwikkelen met zo weinig mogelijk bugs.

Was het maar waar Maar het feit is dat wel een hele zwik bugs op een hele goedkope manier eruit gehaald kunnen worden. Dit zijn bugs die niet later meer opgelost hoeven te worden.

Software testen is een vak. Een vak apart. En dat is echt niet iets wat je alleen aan de ontwikkelaar moet overlaten. Tuurlijk moet een ontwikkelaar z'n eigen code testen en z'n eigen software gebruiken ("eat you're own dog food") zo zie je als ontwikkelaar veel sneller wat wel en niet goed in elkaar zit. Tuurlijk zijn er zat kleinere bedrijven die geen apart test-team hebben maar welk bedrijf bestaat uit alleen ontwikkelaars??

Tuurlijk moet software getest worden... en unit/integration testen doet daar ook zeker geen afbraak aan... Maar dan kunnen de 'echte' testers zich in iedergeval concentreren op de grote lijn ipv dat er nog van die typische programmeerfouten in zitten.. En ja.. ik maak ze..

[Verwijderd]

Alarmnummer schreef op vrijdag 10 december 2004 @ 09:24:
Ok.. en waarom zou ik geen php voor applicaties waar correctheid erg belangrijk is:
1) het kan niet compileren -> een hele lading syntactische en semantische fouten worden niet gevonden. Voor mensen die denken dat dit geen probleem is dan ben je of je bent een kind van God.. of je bent te achterlijk om het te begrijpen. Scripting hoort niet thuis in serieuze omgevingen.
2) een platform waar unit testen niet de standaard is neem ik niet serieus. Unit/integrationtesting is de stap na syntactische en semantische controle om fouten op te sporen.

De vraag is of je de problemen van punt 1 niet afvangt met punt 2. Als je toch overal unit tests voor schrijft, is static type checking dan nog wel echt vitaal? Wellicht handig, maar ook echt nodig?

[Alarmnummer]

Verwijderd schreef op vrijdag 10 december 2004 @ 10:43:
[...]

De vraag is of je de problemen van punt 1 niet afvangt met punt 2. Als je toch overal unit tests voor schrijft, is static type checking dan nog wel echt vitaal? Wellicht handig, maar ook echt nodig?

Hmmm tja.. vanuit praktisch oogpunt zijn ze onmisbaar omdat ik anders allerlei syntactische en semantische fouten zou moeten opsporen en daardoor meer tests moet schrijven. Meer tests = meer tijd.. en tijd = geld... Dus vanuit praktisch oogpunt kan 1 niet vervangen worden mbv 2.

Als jij oneindig veel tijd tot je beschikking hebt.. tja.. dan zou het misschien een optie zijn..

[ Voor 8% gewijzigd door Alarmnummer op 10-12-2004 10:48 ]

[Verwijderd]

Alarmnummer schreef op vrijdag 10 december 2004 @ 10:47:
Hmmm tja.. vanuit praktisch oogpunt zijn ze onmisbaar omdat ik anders allerlei syntactische en semantische fouten zou moeten opsporen en daardoor meer tests moet schrijven. Meer tests = meer tijd.. en tijd = geld... Dus vanuit praktisch oogpunt kan 1 niet vervangen worden mbv 2.

Met unit testing test je toch alle paden sowieso al? Waarom zou je dan nog extra tests moeten schrijven in het geval van een dynamische taal?

Zie ook Bruce Eckel's Strong typing versus Strong testing

[Verwijderd]

Zie ook Bruce Eckel's Strong typing versus Strong testing

Ik heb hem net ff gelezen en het is een aanrader!

[Creepy]

Verwijderd schreef op vrijdag 10 december 2004 @ 10:58:
[...]

Met unit testing test je toch alle paden sowieso al? Waarom zou je dan nog extra tests moeten schrijven in het geval van een dynamische taal?

Zie ook Bruce Eckel's Strong typing versus Strong testing

Even heel simpel: Als je een string in een integer probeert te stoppen zal PHP standaard niet protesteren. Je zult dus hier een test voor moeten schrijven wat er gebeurt als je een string meegeeft terwijl je een integer verwacht. In een strong typed taal zal dit niet lukken omdat de compiler er meteen een error op geeft dus hoef je hier ook niet op te testen

[Verwijderd]

Verwijderd schreef op donderdag 09 december 2004 @ 23:43:
[...]

Je zou je hele app door de Zend encoder heen kunnen halen.
Edit: 'Net' te laat

Nou, nou wat een luxe, maar niet heus.

Als je NetBeans gebruikt voor het schrijven van je Java applicaties dan wordt realtime je code gecontroleerd op fouten en worden fouten aangegeven. Dat werkt alsof je code tijdens het typen constant wordt gecompileerd. Dat werkt echt super en kan je tijd schelen doordat je niet steeds hoeft te compileren.

[-FoX-]

kasper_vk schreef op vrijdag 10 december 2004 @ 10:02:
Bij het overhalen van de opdrachtgever zul je, denk ik, met argumenten moeten komen als

• bouwkosten / bouwtijd
• TCO (typisch management buzzword )
• en ik denk dat je opdrachtgever blij maakt als er eenvoudig een andere partij mee verder kan ontwikkelen. (m.a.w. hij zit zo min mogelijk vast aan de initiele bouwer van het spul).

Misschien dat je j2ee kan presenteren als beter overdraagbaar, omdat er (volgens mij) behoorlijk veel detacheerders zijn die (gecertificeerde / goed opgeleide) j2ee ontwikkelaars kunnen leveren, en voor php ziet dat er iets kariger uit.
Daarnaast wordt op veel hbo's & uni's Java gedoceerd (voor php weet ik dat niet); wat het ook weer iets beter overdraagbaar maakt als het om b.v. stagiaires / afstudeerders zou gaan.

Een interessante reply.. eindelijk
_{niet dat de rest niet interessant is hoor, maar er zit weer eens heel wat offtopic geblaat tussen van enkele, voornamelijk php'ers}
Ik denk niet dat bouwkosten/bouwtijd zo'n groot voordeel is zal zijn aangezien een j2ee applicatie meestal wel meer zal kosten dan een php applicatie. Op TCO (total cost of ownership) gebied, zal er natuurlijk wel het een en ander te vertellen zijn.. vooral op het gebied van onderhoud. Ik generaliseer hier niet door uit te sluiten dat dit met php niet mogelijk is.

Verwijderd schreef op vrijdag 10 december 2004 @ 10:18:
Dank je dat je ons weer even aan het topic herinnert, kasper_vk

Een opdrachtgever die een overwogen keuze maakt (deze zijn trouwens helaas dun gezaaid, naar mijn jarenlange ervaring ) zal geinteresseerd zijn in het volgende:

- Correcte werking
- Gebruiksvriendelijkheid
- Continuiteit
- Uitbreidbaarheid
- Beheerbaarheid
- Schaalbaarheid
- Prestige

De eerste 6 zijn in principe platform-onafhankelijk, dit kun je min of meer, waarschijnlijk op elk platform wel voor ellkaar krijgen. Maar ik stond er ook van te kijken van dat prestige zo'n belangrijk item is.

Dankzij de marketing van Microsoft bijvoorbeeld hebben .NET applicaties al een goede naam als innovatief, state-of-the-art etc. Voor Java geldt hetzelfde, door de commitment van grote bedrijven en door de toepassing ervan in consumer producten (GSM's!). PHP heeft inderdaad wat dit betreft een slechtere naam en wordt vaker geassocieerd met hobbyisten. Wat dat betreft is Java misschien een betere keuze om indruk op een opdrachtgever te maken.

Hopelijk heb je hier wel wat aan Fox, om onze anti/pro PHP discussie in je thread wat goed te maken

Prestige.. maar op welke manier zou je dit dan naar voren brengen? Aan de hand van voorbeelden of hoe zou jij dit doen?

[Olaf van der Spek]

Verwijderd schreef op vrijdag 10 december 2004 @ 10:58:
Met unit testing test je toch alle paden sowieso al? Waarom zou je dan nog extra tests moeten schrijven in het geval van een dynamische taal?

Natuurlijk, maar een unit test draaien kost meer tijd dan een file compilen en als de test faalt weet je nog steeds niet direct de oorzaak.
Als een compile faalt kun je (vaak) met een druk op de knop naar de fout gaan en die verbeteren.

[ Voor 12% gewijzigd door Olaf van der Spek op 10-12-2004 12:49 ]

[Verwijderd]

- Correcte werking
- Gebruiksvriendelijkheid
- Continuiteit
- Uitbreidbaarheid
- Beheerbaarheid
- Schaalbaarheid
- Prestige

vergeet je in dit lijstje het woord kosten beheersing niet?

En waarom een keuze maken? gebruik het beste van de twee. Ze zijn prima te combineren op het web of in een intranet. Ben zelf geen voorstander van .NET applicatie's de webservers van microsoft zijn beduidend strager en gevoelig voor fouten dan de opensource oplossing die ook nog is velen malen goedkoper zijn (ofwel gratis).

Wat dat betreft is Java misschien een betere keuze om indruk op een opdrachtgever te maken.

Met een programmeer taal maak je geen indruk met je ideeen wel.

Ik denk zelf dat een opdrachtgever zich geen ene reet kan schele hoe je het doet, als het maar werkt, goedkoop is, duidelijk en nogmaals dat het werkt.

downtime en onmogelijk intefaces zijn twee dingen waar je zeker geen punten mee scored.

Mensen(lees opdrachtgevers) hebben meestal geen verstand van zaken dus keep it simpel stupid, geen moeilijke details over servers programmeertalen etc.

Ik werk zelf veel voor de overheid en we werken hier alleen maar met php, mysql, apache, linux en java. Zeer weinig problemen gehad met beveiliging, backups of downtime.

Ik hoop dat je hier wat aan hebt.

[-RenE-]

Maak twee applicaties die hetzelfde moeten kunnen. Ik ka je nu al vertellen dat je Java programma aanzienlijk groter zal zijn dan het PHP programma.

Volgens mij betekent minder code nog altijd minder bugs, dus daar zie ik een aanzienlijke meerwaarde voor PHP.

[Alarmnummer]

-RenE- schreef op vrijdag 10 december 2004 @ 13:30:
Maak twee applicaties die hetzelfde moeten kunnen. Ik ka je nu al vertellen dat je Java programma aanzienlijk groter zal zijn dan het PHP programma.

Volgens mij betekent minder code nog altijd minder bugs, dus daar zie ik een aanzienlijke meerwaarde voor PHP.

Koel.. nou.... het is nu wachten op PHP versie van Windows... en van games..

[curry684]

Verwijderd schreef op vrijdag 10 december 2004 @ 13:05:
[...]

Ben zelf geen voorstander van .NET applicatie's de webservers van microsoft zijn beduidend strager en gevoelig voor fouten dan de opensource oplossing die ook nog is velen malen goedkoper zijn (ofwel gratis).

Kun je dit ook onderbouwen of is het gewoon een loze M$-si-teh-sux0r statement?

[RedRose]

Wat ik mis in de discussie en wel naar voren kwam in de TS: veiligheid, of in ieder geval de garandering van de privacy van de gegevens. Hierin geldt ook: de kwaliteit van de software, zij het PHP of Java, hangt ook af van de kwaliteit van de programmeur en meer nog van het programmeermodel. Wat dat betreft heb je in Java denk ik meer mogelijkheden voor het goed abstraheren van rollen, rechten en entities.

Over de aantallen concurrent users die je noemt: beide talen / platformen kunnen dat aan.

[eamelink]

Verwijderd schreef op vrijdag 10 december 2004 @ 13:05:
Ben zelf geen voorstander van .NET applicatie's de webservers van microsoft zijn beduidend strager en gevoelig voor fouten dan de opensource oplossing die ook nog is velen malen goedkoper zijn (ofwel gratis).

Dat gooi je er nogal ongefundeerd uit, maar in de meeste gevallen van grote applicaties waar het topic over gaat vallen de kosten van zo'n miezerig iis licentietje of een extra dikke serverbak in het niets bij de ontwikkelingskosten.

Als je in .net 10% sneller kan ontwikkelen dan in Java of php, dan heb je je kosten er al snel weer uit.

-RenE- schreef op vrijdag 10 december 2004 @ 13:30:
Maak twee applicaties die hetzelfde moeten kunnen. Ik ka je nu al vertellen dat je Java programma aanzienlijk groter zal zijn dan het PHP programma.

In het geval van simpele webapps waar vaak veel stringbewerkingen en dergelijke in voorkomen zal dat wel het geval zijn denk ik ja

Volgens mij betekent minder code nog altijd minder bugs, dus daar zie ik een aanzienlijke meerwaarde voor PHP.

Nou, bij mij is de hoeveelheid bugs in code voornamelijk afhankelijk van het tijdstip waarop ik programmeer Tussen 's middags rond een uurtje of drie en 's avonds een uurtje of 1 programmeer ik het beste, buiten die uren gaat het minder .

Java is een hele andere taal dan php, en om nou zo maar te zeggen dat je bij evenveel code gemiddeld evenveel bugs hebt dat zal in heele grote lijnen misschien voor één programmeur met één taal gelden, maar die lijn kan je écht niet zomaar doortrekken van php naar java ofzo.

Dus dat vind ik niet echt een "aanzienlijke meerwaarde".

[Corniel]

Het valt me op dat - zoals door sommigen aan gegeven - een aantal mensen die hier tot zover op gereageerd hebben, totaal niet lijken te weten waar ze over praten.

De topic "[Java] vs [PHP] wat is de meerwaarde?" (nog zoiets, het is Java en niet JAVA) geeft dat eigenlijk al aan. Een scriptingtaal (PHP) vergelijken met een 'reguliere' programmeertaal is nauwelijk zinnig te noemen. Natuurlijk zijn er gebieden waar ze beide goed zijn in te zetten, maar over het algemeen zijn te gebruiken voor een geheel verschillend spectrum van ICT-toepassingen.

De casus zoals geschetst door de topicstarter vraagt - als je de aanvullende info bestudeert - om een .Net-oplossing. En alle PHP-fans ten spijt, daar is PHP niet de geschikte tool voor. Hoe mooi php ook is, het is vooral geschikt om een presentatielaag te maken, voor geavanceerde logica en/of file/data/db handling niet.

En dan nog iets waar ik zo iets van had van, "wat zegt u daar?": noch PHP noch Java zijn (voledig) platformonafhankelijk; probeer maar eens een beetje grote PHP-applicatie van een Windows platform naar een Linux (Debian bijvoorbeeld) te verplaatsen. Grote kans, dat ie het *niet* doet. Voor Java geldt hellaas (gelukkig in veel mindere mate) het zelfde. Draait het op je eigen testomgeving als een Sun-netje, zie het dan ook in de productieomgeving maar eens goed te laten draaien. Dat is geen spreekwoordelijk appeltje-eitje in de meeste gevallen.

En nog even ontopic: volgens mij zou de vraag die topicstarter zou moeten bezighouden zijn: Welke OO-taal kan ik het beste gebruiken in deze .net-casus: Java, C(#/++), of een andere? Ik zou zelf voor optie twee gaan en eventueel voor 1, maar zeker niet voor PHP.

[Creepy]

Corniel schreef op vrijdag 10 december 2004 @ 14:27:
De casus zoals geschetst door de topicstarter vraagt - als je de aanvullende info bestudeert - om een .Net-oplossing. En alle PHP-fans ten spijt, daar is PHP niet de geschikte tool voor. Hoe mooi php ook is, het is vooral geschikt om een presentatielaag te maken, voor geavanceerde logica en/of file/data/db handling niet.

Waarbij ik me meteen afvraag waarom jij als conclusie trekt dat het vraagt om een .NET oplossing i.p.v. Java of PHP? Want dat laat je achterwege

[Corniel]

Euh Creepy, volgens mij kan je een .Net-oplossing ook in Java (en zelfs in PHP) realiseren. Het is nog geen antwoord op je vraag natuurlijk, maar je kan niet alles hebben. Maar waarom? Er moeten schijnbaar 500 tot 1000 gebruikers tegelijk van het systeem gebruik gaan maken. Ik ga er - misschien ten onrechte - vanuit dat dat (voornamelijk) Windows gebruikers zijn. Dit komt - bij een uitbreiding van de functionaliteit - al snel neer op integratie met Word/Excel/Outlook (Express) etc.

Met .Net gaat dat vrij eenvoudig, met PHP moet je heel veel zelf gaan ontwikkelen (en dat is, zoals gezegd uiteindelijk veel duurder). In Java is er het een en ander beschikbaar (niet allemaal even goed) en PHP is het just-a-hell-of-a-job.

[RedRose]

Corniel schreef op vrijdag 10 december 2004 @ 14:27:

... verhaaltje...

Wel grappig...

Wat is de overeenkomst tussen een appel en een peer?

Boeit niet, neem een banaan!

PHP en Java zijn, mits je goed programmeert, vrij eenvoudig platform-onafhankelijk te maken. .Net draait (behoudens Mono) toch vooral op Windows-machines, dus ik begrijp je verhaal niet helemaal. Overigens ben ik wel met je eens dat .Net ook moet worden meegenomen in de overweging, maar neem dan C#.

[djc]

Glimi schreef op vrijdag 10 december 2004 @ 09:19:
Unit testing is een van de slechts mogelijke manieren van dynamic testing. Het pikt gemiddeld iets van rond de 30% van de fouten op. Dit omdat de programmeur vaak de tests ook schrijft en dus zijn beeld erop blijft projecteren (white box tests) [Weinberg's law: "A developer is unsuited to test his or her code."]. Code reviews/inspections, metrics en functional testing met live data zijn bewezen effectiever.

Uiteraard is unit testing slechts een van de mogelijke manieren van testen. Ik noemde dit echter meer als voorbeeld, volgens mij valt bijvoorbeeld via test-driven development (eerst tests schrijven, dan code) een groot deel van Weinberg's law onschadelijk gemaakt. En heb je ook cijfers over hoeveel van de fouten worden opgepikt door een compiler?

Corniel schreef op vrijdag 10 december 2004 @ 14:27:
De topic "[Java] vs [PHP] wat is de meerwaarde?" (nog zoiets, het is Java en niet JAVA) geeft dat eigenlijk al aan. Een scriptingtaal (PHP) vergelijken met een 'reguliere' programmeertaal is nauwelijk zinnig te noemen. Natuurlijk zijn er gebieden waar ze beide goed zijn in te zetten, maar over het algemeen zijn te gebruiken voor een geheel verschillend spectrum van ICT-toepassingen.

Misschien kan je voor de lol eens dit whitepaper over dynamic languages doorlezen. Het afzetten van scriptingtalen tegen reguliere programmeertalen is wat mij betreft achterhaald, en dynamic languages hebben volgens mij in veel gevallen een aantal voordelen. Wat betreft performance problemen (wat over het algemeen als een van de grote punten tegen dynamic languages wordt gebruikt) wil ik slechts wijzen op de nutteloosheid van premature optimization.

(En wellicht is een topic-splitsing onderhand wel op z'n plaats?)

[Olaf van der Spek]

Manuzhai schreef op vrijdag 10 december 2004 @ 16:52:
Wat betreft performance problemen (wat over het algemeen als een van de grote punten tegen dynamic languages wordt gebruikt) wil ik slechts wijzen op de nutteloosheid van premature optimization.

Hoe ga je dat 'postmature' aanpakken dan?

[djc]

OlafvdSpek schreef op vrijdag 10 december 2004 @ 17:11:
Hoe ga je dat 'postmature' aanpakken dan?

In a nutshell: bottlenecks alsnog in C schrijven.

[ Voor 8% gewijzigd door djc op 10-12-2004 17:50 ]

[Verwijderd]

Alarmnummer schreef op vrijdag 10 december 2004 @ 09:24:
[...]


Ok.. en waarom zou ik geen php voor applicaties waar correctheid erg belangrijk is:
1) het kan niet compileren -> een hele lading syntactische en semantische fouten worden niet gevonden. Voor mensen die denken dat dit geen probleem is dan ben je of je bent een kind van God.. of je bent te achterlijk om het te begrijpen. Scripting hoort niet thuis in serieuze omgevingen.

Zonder de rest gelezen te hebben, wil ik wel even melden dat ik het hier helemaal mee eens ben. Een probleem is dat een PHP programmeur toch wat minder serieus overkomt, met name als ze dan gaan verdedigen dat weak-typing geen probleem is. Het levert mensen op die eigenlijk niet genoeg van programmeren af weten om iets te maken maar het toch doen. Dat het toch (een beetje) draait verbloemt hun onkunde.

Als opdrachtgever weet je dat je met PHP een groot risico neemt dat er onkundige mensen op af komen. Mischien dat de mensen die er mee beginnen van goede wil zijn, maar als je je team wilt uitbreiden zie dan maar eens aan 'profesionele' programmeurs te komen.

[Verwijderd]

kasper_vk schreef op vrijdag 10 december 2004 @ 10:02:
[...]

Daarnaast wordt op veel hbo's & uni's Java gedoceerd (voor php weet ik dat niet);

Wat denk je zelf? Overigens wordt op de uni niet Java direct gedoceerd maar na een korte inleiding gewoon gebruikt bij andere vakken.

wat het ook weer iets beter overdraagbaar maakt als het om b.v. stagiaires / afstudeerders zou gaan.

Dat is ook een voordeel. PHP is echt een hobby taal en hoort gewoon niet in serieuze bedrijven of scholen thuis.

[djc]

Verwijderd schreef op vrijdag 10 december 2004 @ 18:08:
PHP is echt een hobby taal en hoort gewoon niet in serieuze bedrijven of scholen thuis.

En dit baseer je waarop? Nogal een boude uitspraak.

[Alarmnummer]

Manuzhai schreef op vrijdag 10 december 2004 @ 18:14:
[...]
En dit baseer je waarop? Nogal een boude uitspraak.

Op het feit dat script talen (ook python) niet thuis horen in serieuze omgevingen. Ik heb eerlijk gezegd het nut van script talen nooit ingezien. Ik heb zelf een tijdje met python geprogrammeerd (Python for Java) maar ik ben hier enorm hard op terug gekomen. Ok.. je hoeft niet te compileren.. Maar je krijgt ook pas feedback over eventuele fouten die zich runtime pas voordoen. En dan krijg je pas alleen feedback als de desbetreffende functie wordt aangeroepen.

En je hoeft idd minder te typen.. en je hoeft niet te compileren.. en je hebt dus sneller je applicatie online staan. Maar ik vind die meerwaarde niet opwegen tegen zware syntactische en semantische controle`s. Zeker als je kijkt naar moderne ide`s met syntax/semantic checking, code completion, refactoring en on the fly compilers is de afstand tussen kloppen en uitvoeren ook veel kleiner geworden.


Java/c#/c++ zijn imho zelfs nog veel te vergevingsgezind zijn. Bv correctheid op concurrency control is iets dat nog niet uitgevoerd kan worden door de compiler. Er zijn programmeertalen die dat wel kunnen.

Ik wil dus zo veel mogelijk foutmeldingen waar ik zelf geen extra tests en controle`s voor hoef uit te voeren.

Scripttalen horen imho niet thuis in serieuze omgevingen. Zelfs scriptalen op het linux platform vind ik verwerpelijk omdat ik niet vroeg genoeg foutmeldingen krijg (en ja.. ik ben een tijd lang '100%' linux geweest.

Het feit dat er wel of geen code generatie wordt gedaan zal me worst zijn, en de performance in veel gevallen dito. het gaat me puur om het zo vroeg mogelijk melden van fouten. Op het moment dat een bestand wordt ingelezen moet het hele bestand controleerd worden op correctheid.. syntactisch en semantisch. En wil ik ook alle bestanden in 1 keer kunnen controleren op correctheid.. niet op het moment ze gaan draaien.. want dan is het te laat.

[ Voor 31% gewijzigd door Alarmnummer op 10-12-2004 18:45 ]

[whoami]

Corniel schreef op vrijdag 10 december 2004 @ 14:54:
Euh Creepy, volgens mij kan je een .Net-oplossing ook in Java (en zelfs in PHP) realiseren.

Wat bedoel je hier nu mee ?

[Stephan Oudmaijer]

Janoz schreef op donderdag 09 december 2004 @ 14:03:
[...]

Door deze opmerking begin ik ernstig te twijvelen of je uberhaupt wel weet wat met een java/j2ee applicatie wordt bedoeld.

sluit ik me bij aan

J2EE en PHP vergelijken slaat nergens op. PHP is een presentatie / web taal. Java / J2EE is veel meer, teveel om hier neer te gaan zetten. iig, niet te vergelijken, ze dienen een ander doel.

controle`s. Java/c#/c++ zijn imho zelfs nog veel te vergevingsgezind zijn. Bv correctheid op concurrency control is iets dat nog niet uitgevoerd kan worden door de compiler. Er zijn programmeertalen die dat wel kunnen.

hoe kan een compiler concurrency issues voorkomen dan? zou ik wel eens willen weten Concurrency issues zijn er ook vaak op twee niveau`s. Database concurrency issues en applicatie concurrency issues. De database variant wordt opgelost met locking/isolation levels en de applicatie variant zul je op een andere manier moeten oplossen, alhoewel dit ook te regelen is met leuke frameworkjes (spring + hibernate om een voorbeeld te noemen). IMHO kan een compiler over de laatste variant nooit oordelen.

[ Voor 49% gewijzigd door Stephan Oudmaijer op 10-12-2004 18:47 ]

[Verwijderd]

Inmiddels heb ik nog een mooi genuanceerd verhaal van Bruce Eckel over dynamische talen vs statische talen gevonden.

Ik denk dat je dynamische talen niet af kunt schrijven als speeltjes, of als iets dat niet thuis hoort in serieuze scenario's. Dat is wat mij betreft te makkelijk en je gewoon afsluiten voor wat er in de software engineering wereld gebeurt op dit moment. Do "groten" in de SE wereld lijken erg gecharmeerd van dynamische talen. Neem Martin Fowler, Bruce Eckel en bedrijven als Google (die Python gebruiken).

Natuurlijk, je gaat pacemaker software niet schrijven in PHP. Of firewalls in Python. Verschillende situaties, verschillende prioriteiten.

[Verwijderd]

Mijn grote bezwaar tegen deze thread is dat de hardcore programmeurs met hun correctheidsgaranties de boel dreigen over te nemen. Ik vind die hardcore programmeurs echt fantastische mensen maar ik ben bang dat zij niet zien dat ze maar een deel van de problematiek overzien.

Ik zit al lang in de automatisering en liet me vroeger nogal eens intimideren door dit soort verhalen. Zolangzamerhand begin ik me echter te realiseren dat dat volledig onterecht is. Ik weet dat er andere enthousiaste Java/PHP of god mag weten wat voor andere 'hobby' programmeurs rondlopen die in dezelfde situatie zitten als ik vroeger.

Ik programmeer hoofdzakelijk webbased applicaties (frontends meestal in PHP, backends meestal in Perl, DB meestal Mysql, ja lach maar). Mijn applicaties zijn over het algemeen zeer succesvol (zelfs in concurrentie met commerciele producten van bedrijven met een beurswaarde van honderden miljoenen), onderhoudsarm en - op een paar onvermijdelijk incidenten na - zo stabiel als de pest. Zo stabiel dat ik er met een deel van het geld wat ik ermee verdiend heb makkelijk een jaar de wereld rond kon reizen (en dat zonder dat de boel in elkaar donderde). Mijn 10-duizenden of misschien zelfs 100-duizenden gebruikers hadden nergens last van.

Mijn punt is dat de formele hardcore programmeurs weliswaar in veel situaties erg goed kunnen functioneren, maar dat de echte sterren de jongens met de ideeen zijn. Als je applicatie ooit eens in een stadium komt dat hij geen 100-duizenden gebruikers meer aan kan, huur je gewoon een paar van die Java-wizards en hoop je dat er ook nog eens iets bruikbaars uit hun handen komt. ;-)

Laat je in ieder geval niet door die jongens aanpraten dat je minder bent omdat je PHP gebruikt. Door dat soort onzin hebben de Yahoo en de Google guys zich ook niet laten weerhouden ;-)

Amateurs rule!

[mbravenboer]

Ik mis iets in de discussie over type systeem in talen als Java vs Python. Waarom hebben de ontwerpers van die talen gekozen voor die verschillende type systemen? Guido van Rossum (Python) is echt niet op z'n achterhoofd gevallen. John McCarthy (Lisp) heeft ze ook allemaal goed op een rijtje. Alan Kay (Smalltak) mag er qua hersenmassa waarschijnlijk ook wel wezen. Waarom hebben ze gekozen voor het ontwerpen van een 'dynamische taal'?

Ik denk dat de volgende quote dat perfect uitlegt: "the source of all type errors are type systems" (helaas weet ik niet van wie deze quote oorspronkelijk is). Met types is op zich niets mis: een classificatie van waarden klinkt als een nuttig idee. Maar, met veel type systemen is wel iets mis: de type checker wil gaan controleren of een programma netjes (qua types en operaties daarop) met alle waarden omgaat. Maar, van veel programma's waarvan jij zelf inziet dat ze zich netjes gedragen, kan de type checker dit niet controleren omdat jij jouw idee over het programma niet goed kan uitdrukken in het type systeem.

Infinitive vroeg me deze week waarom Stratego (mijn favouriete tijdsbesteding) eigenlijk geen type systeem heeft. Helaas hadden we toen geen tijd meer om hier uitgebreid op in te gaan, maar dit heeft dus alles te maken met de abstractie mogelijkheden die we willen bieden in Stratego. Op dit moment is het gewoon niet duidelijk hoe zulke code getypeerd zou kunnen worden. De oplossing is om het maar niet te typeren, maar dat betekent niet dat je tijdens het programmeren geen types in je hoofd hebt. Ditzelfde geldt ook voor talen als Python. Python programmeurs hebben wel degelijk een idee van types. Ze schrijven ze alleen niet op en ze kunnen dus ook niet gecontroleerd worden door de compiler.

Met het concept van een type systemen is op zich dus niets mis. Met vrijwel alle type systemen die we nu kennen is wel iets mis. Ze beperken je zo veel dat men zich af gaat vragen of die type controles uberhaupt wel nuttig zijn.

Daarnaast is het ook akelig dat je in veel talen steeds maar opnieuw moet aangeven wat het type van een variabele is. De type checker had dit vaak makkelijk zelf kunnen afleiden (type inferentie), maar helaas is dit nog niet echt doorgedrongen tot mainstream talen.

[ Voor 3% gewijzigd door mbravenboer op 10-12-2004 19:46 ]

[flowerp]

Verwijderd schreef op vrijdag 10 december 2004 @ 19:00:
Ik denk dat je dynamische talen niet af kunt schrijven als speeltjes, of als iets dat niet thuis hoort in serieuze scenario's. Dat is wat mij betreft te makkelijk

En jij denkt er helemaal te gemakkelijk over. PHP is niet een kwestie van dynamische nieuwe ontwikkelingen waar de oude rotten uit het vak zich voor afsluiten. Weakly typed en interpreted talen bestaan al zo lang als de informatica wereld bestaat. Het is een flawed concept wat in het verleden heeft bewezen niet te scalen en een grote bron te zijn van wanorde binnen het software process. Lang geleden, in de tijd dat BASIC nog nieuw was heeft men besloten dat het niet de weg is die je op zou willen gaan. Makkelijkheid in het begin weegt niet op tegen chaos later op de weg. Dijkstra zei het al : "Een BASIC programmeur is voor altijd verziekt en zal nooit meer een echte programmeur kunnen worden".

Vandaag de dag wordt een oud stoffig concept weer opgehaald, terug naar BASIC voor mensen die compiler foutmeldingen maar vervelend en moeilijk vinden. Het is leuk dat zulke mensen met PHP een aardig speeltje gevonden hebben, maar hou het daar dan ook op. Laat PHP een speeltje blijven en ga het niet perse profesioneel willen gebruiken. Een profesioneel DTP bedrijf gaat toch ook geen wordpad of notepad gebruiken voor z'n opdrachten?

Ik geloof wel dat een goed ontworpen en elegante weakly typed en interpreted script taal als domain specific taal een zeker bestaansrecht heeft. PHP is echter zeker niet een uitgekiend en doordacht ontwerp, nog is het concept van weakly typed of interpretive er vernieuwend aan.

Ik zal eens kijken of ik er wat quotes aan kan vinden, maar een jaar terug stond over de phenomeen een mooie column in C++ users journal, de embedded angle. De rant was tegen mensen die met visual basic iets in elkaar konden prutsen terwijl ze eigenlijk veels te weinig inzcht hadden in programmeren en de effecten die dat op de industrie als geheel had.

[flowerp]

Verwijderd schreef op vrijdag 10 december 2004 @ 19:39:
Mijn grote bezwaar tegen deze thread is dat de hardcore programmeurs met hun correctheidsgaranties de boel dreigen over te nemen.

Beetje overdreven, het is geen formeel correctheids bewijs ofzo hoor!? Een echt correctheids bewijs is enorm moeilijk. Ik zie zeker toekomst in een taal die (gedeeltes) automatisch op correctheid kan controlleren, of die daar tenminste een goede support voor geven. Dat gaat nog honder keer zo ver als de basic garanties die Java geeft mbt correctheid.

Mijn punt is dat de formele hardcore programmeurs weliswaar in veel situaties erg goed kunnen functioneren, maar dat de echte sterren de jongens met de ideeen zijn.

Linux, Mac OS X, TeX, gcc, the gimp, photoshop, itunes, quake, half-life... allemaal door hobby-isten met een leuk idee gemaakt he? Allemaal PHP...

Jij bent vast zo'n type die er maar wat op los prutst. Als de bloat en chaos in de code niet meer te overzien is ga je maar naar een ander bedrijf. Dan ben -ik- de gene die jouw gepruts mag onderhouden, die nieuwe dingen mag gaan toevoegen aan jouw spaghetti brij. Als je compile fouten al te 'formeel' vind, dan durf ik er niet eens over na te denken hoe jij over gestructureerd werken denkt, over architectuur, over design pattern, over modularisatie. Jij bevestigd in een paar zinnen al wat slecht is aan PHP. Mischien nog niets eens de taal opzich, maar de mentaliteit van de mensen die het aantrekt.

Het is boven al gezegd, maar om het niet al te anti te laten klinken: natuurlijk zal een goed team of een goede programmeur hele goede software kunnen schrijven in PHP. Ongetwijfeld. Maar hij/zij zal nog beter zijn geweest in Java of andere pro talen en dat er een paar mensen hele goede PHP dingen geschreven hebben is geen excuus voor de massa wannabe's die het aantrekt.

[Creepy]

Verwijderd schreef op vrijdag 10 december 2004 @ 19:39:
Mijn punt is dat de formele hardcore programmeurs weliswaar in veel situaties erg goed kunnen functioneren, maar dat de echte sterren de jongens met de ideeen zijn. Als je applicatie ooit eens in een stadium komt dat hij geen 100-duizenden gebruikers meer aan kan, huur je gewoon een paar van die Java-wizards en hoop je dat er ook nog eens iets bruikbaars uit hun handen komt. ;-)

Dus de "formele hardcore programmeurs" zijn nooit de jongerns met de ideeen

Laat je in ieder geval niet door die jongens aanpraten dat je minder bent omdat je PHP gebruikt.

Je bent niet meer of minder dan een ander om het soort taal dat je gebruikt. Maar echt handig is het niet om met PHP te beginnen omdat je daarna wat zaken van PHP zult af moeten leren als je in een andere omgeving aan de slag wilt.

Door dat soort onzin hebben de Yahoo en de Google guys zich ook niet laten weerhouden ;-)

Je wilt niet weten hoeveel "formele hardcore programmeurs" daar tussen zitten

Amateurs rule!

De professionals ook (niet allemaal helaas, maar dat geld ok voor de amateurs )

[Verwijderd]

Creepy schreef op zaterdag 11 december 2004 @ 00:54:
Dus de "formele hardcore programmeurs" zijn nooit de jongerns met de ideeen

Ik denk dat die twee instellingen elkaar inderdaad een beetje uitsluiten. Als je erg geneigd bent om je op de formaliteiten te storten verlies je meestal de big picture uit het oog. De details en formaliteiten zijn zeker belangrijk maar ik vind dat de 'big picture' belangrijker is. Ik ken niemand die die twee kwaliteiten in zich verenigt, maar dat zegt misschien niet alles.

Je bent niet meer of minder dan een ander om het soort taal dat je gebruikt. Maar echt handig is het niet om met PHP te beginnen omdat je daarna wat zaken van PHP zult af moeten leren als je in een andere omgeving aan de slag wilt.

Ach ja, dat moet je altijd, houdt je flexibel. Ik ben trouwens niet zo'n grote PHP fan, er zit veel slechts in die taal. Ik weet niet of ik de enorme reeks functies die standaard ingebouwd zit wel zo'n goed idee vind en het is vaak slecht doordacht. Aan de andere kant is het wel verdomd handig in het gebruk als je webapplicaties wilt schrijven ;-)

Je wilt niet weten hoeveel "formele hardcore programmeurs" daar tussen zitten

Dat wil ik wel ;-) Ik geloof ook dat die mensen nuttig en nodig zijn. Maar ik geloof ook dat die niet de echte drijvende kracht zijn die het bedrijf opgebouwd hebben. De minder formele types (door de formelere graag als 'prutsers'' aangeduid) zijn de drijvende en innoverende kracht.

De professionals ook (niet allemaal helaas, maar dat geld ok voor de amateurs )

Helaas voor de 'kommaneukers' is dat niet waar. Als de 'kommaneukers' de dienst uitmaken is het met je bedrijf snel afgelopen ;-)

[ Voor 6% gewijzigd door Verwijderd op 11-12-2004 10:27 ]

[Verwijderd]

flowerp schreef op zaterdag 11 december 2004 @ 00:10:
En jij denkt er helemaal te gemakkelijk over.

Eh, ja joh. Als iemand er wel makkelijk over denkt ben ik het wel .

PHP is niet een kwestie van dynamische nieuwe ontwikkelingen waar de oude rotten uit het vak zich voor afsluiten. Weakly typed en interpreted talen bestaan al zo lang als de informatica wereld bestaat. Het is een flawed concept wat in het verleden heeft bewezen niet te scalen en een grote bron te zijn van wanorde binnen het software process. Lang geleden, in de tijd dat BASIC nog nieuw was heeft men besloten dat het niet de weg is die je op zou willen gaan. Makkelijkheid in het begin weegt niet op tegen chaos later op de weg. Dijkstra zei het al : "Een BASIC programmeur is voor altijd verziekt en zal nooit meer een echte programmeur kunnen worden".

BASIC had veel belangrijkere nadelen (GOTO, considered harmful). Wat betreft de rest, zie de post van mbravenboer. De ontwikkelaars die tegenwoordig aan en met dynamische talen werken (en dan denk ik met name aan Ruby en Python, slechts in mindere mate aan PHP) zijn echt niet op hun achterhoofd gevallen. Ze dachten heus niet "Hey, dat mislukte concept ligt nu al zo lang op zolder stoffig te worden, laten we dat eens opnieuw proberen." Het zijn geen bozo's.

Een profesioneel DTP bedrijf gaat toch ook geen wordpad of notepad gebruiken voor z'n opdrachten?

Lekkere vergelijking. Dat zijn ook echt producten die elkaar functioneel kunnen vervangen.

Overigens is weakly typed iets anders dan dynamically typed:

Weak typing: Allows incorrect messages to be sent to objects. C and C++ allow you to successfully cast to the wrong type, and are thus viewed as having weak typing (although Stroustrup once said that "C++ was strongly typed with a couple of holes in the type mechanism"). I have argued in the past that "weakly typed" (a term I originally used to mean "latent typing") was distinct from "weak typing," but I think the terminology differences are far too subtle and not worth arguing over. In addition, the idea of latent typing confuses the issue; C++ (static typing, arguably weak typing), Python and Ruby (dynamically typed) all support latent typing (Ruby calls it "duck typing").

Dynamic typing: Typically still strongly typed, but the type is not checked until runtime. Type checking still happens, and it can be strong typing, but it happens at runtime rather than at compile-time. A strongly-typed dynamic language still only allows you to send valid messages to objects.

[Verwijderd]

flowerp schreef op zaterdag 11 december 2004 @ 00:25:
Jij bent vast zo'n type die er maar wat op los prutst. Als de bloat en chaos in de code niet meer te overzien is ga je maar naar een ander bedrijf.

Vooroordelen, vooroordelen... Ik zit al een slordige 15 jaar bij hetzelfde (behoorlijk grote) bedrijf. In die tijd heb ik verschillende systemen opgezet die zich over het algemeen kenmerken door een lange stabiele levenscyclus. Mijn code is misschien niet altijd overal even optimaal (je leert toch in de loop der tijd) maar gelukkig werk ik tegenwoordig samen met prima programmeurs die wel erg netjes kunnen coden. Die mensen hebben dan helaas vaak meer problemen hebben met het vinden van de juiste opzet en functionaliteit. Aldus vullen we elkaar mooi aan .

De door mij ontwikkelde concepten en gekozen opzetten zijn na vele jaren nog steeds bruikbaar en functioneel net als de code waarin ze zijn omgezet. Naar mijn mening is bij softwareprojecten het model van je probleemoplossing het allerbelangrijkste en de creativiteit die je nodig hebt om zo'n model te ontwerpen leer je op geen enkele opleiding en er is geen enkele methodiek die je daarbij zal helpen. Bloat en chaos komt juist meestal doordat de 'big picture' ontbreekt.

Of ik een prutser ben zou je moeten vragen aan mijn collega's, opdrachtgevers en mijn klanten. Ik ben persoonlijk niet zo bang voor het antwoord. Hoewel er natuurlijk ook mensen te vinden zijn die mij als een bedreiging zien, maar zelfs dan nemen ze me serieus ;-)

Flowerp, ik geloof best dat je een fantastische programmeur bent, maar er zijn meer soorten programmeurs dan ik tot dusver in deze thread aan bod zag komen en het leek me zinvol om daar eens op te wijzen. Het is niet zinvol om tegen 'PHP amateurs' en prutsers te trappen, je zou misschien zelfs nog wel het een en ander van ze kunnen leren...

[djc]

flowerp schreef op zaterdag 11 december 2004 @ 00:25:
Het is boven al gezegd, maar om het niet al te anti te laten klinken: natuurlijk zal een goed team of een goede programmeur hele goede software kunnen schrijven in PHP. Ongetwijfeld. Maar hij/zij zal nog beter zijn geweest in Java of andere pro talen en dat er een paar mensen hele goede PHP dingen geschreven hebben is geen excuus voor de massa wannabe's die het aantrekt.

Wat een vreemde laatste zin! Dus PHP is een slechte taal OMDAT hij massa's wannabe's aantrekt?

En als een programmeur goede software kan schrijven in PHP, denk je dan echt dat hij in "Java of andere pro [sic!] talen" nog betere dingen kan schrijven? Uit onderzoek is gebleken dat bugs per line of code ongeveer gelijk blijven, onafhankelijk van de taal. Dat betekent dus dat jij in hetzelfde stukje formaliteit in je "pro taal" Java veel meer fouten maakt dan als je dat stukje in PHP schrijft...

En heb je dit al gelezen? Ik denk dat dynamic languages een zeer belangrijke rol gaan spelen.

[ Voor 38% gewijzigd door djc op 11-12-2004 10:39 ]

[Alarmnummer]

Verwijderd schreef op zaterdag 11 december 2004 @ 10:26:
[...]
Het is niet zinvol om tegen 'PHP amateurs' en prutsers te trappen, je zou misschien zelfs nog wel het een en ander van ze kunnen leren...

Het is niet zo dat iedere php`er een prutser is... maar PHP is erg laagdrempelig en trekt daardoor veel beginners aan. En als jij al 15 jaar in het vak zit kunnen we je slecht een beginner noemen.

En prutsers zijn trouwens niet alleen uitbesteeds aan PHP hoor.. ik zie ook genoeg Java gepruts voorbij komen.

En zef.. mbravenboer.. hebben jullie wel eens grote lappen geprogrammeerd in dynamische talen? De programma`s die ik heb gemaakt in Jython vond ik in het begin wel 'grappig' lekker kort.. Maar na verloop van tijd zit ik zo van uhhhh.. wat the fuck zat hier nog maar in?? En moet ik weer uitpluizen hoe het in elkaar zat. Als ik zie staan List<String> dan zie ik meteen dat ik een List van Strings heb. En verder ben ik wel een beetje voor type inference.. (zelfs Java Generics heeft een beetje type inference om het iets aangenamer te laten zijn) maar ik had bv met Clean al vrij snel de behoefte om toch wat types aan te brengen... een stuk documentatie.. Ook al zou de compiler ze volledig negeren... zou ik het nog doen. Nou.. dan is het toch fijn als types door de compiler kunnen worden gecontroleerd.. als extraatje

[ Voor 4% gewijzigd door Alarmnummer op 11-12-2004 11:18 ]

[mbravenboer]

Alarmnummer:En zef.. mbravenboer.. hebben jullie wel eens grote lappen geprogrammeerd in dynamische talen?

Uh ja, ik doe niet anders. Tussen de 75 en 100% van de code die ik produceer is Stratego. Nu is Stratego niet helemaal dynamisch getypeerd (wat statisch kan wordt statisch gedaan. At run-time is er pattern-matching en reflectie), maar het is wel sterk vergelijkbaar met de ideeen van dynamisch getypeerde talen.

ik had bv met Clean al vrij snel de behoefte om toch wat types aan te brengen... een stuk documentatie.. Ook al zou de compiler ze volledig negeren... zou ik het nog doen.

Bij talen met type inferentie is dat ook vaak mogelijk. Het zorgt ervoor dat compiler kan controleren of wat hij afgeleid heeft ook overeen komt met wat jij bedoelde. Ook kan het de foutmeldingen verbeteren.

Nou.. dan is het toch fijn als types door de compiler kunnen worden gecontroleerd.. als extraatje

Je hebt me ook niet horen zeggen dat statische (type) checks en verkeerd zijn. Wel dat ze te zwak zijn en daardoor in sommige gevallen in de weg zitten. Dat argument negeer je een beetje .

[Alarmnummer]

mbravenboer schreef op zaterdag 11 december 2004 @ 11:31:
Je hebt me ook niet horen zeggen dat statische (type) checks en verkeerd zijn. Wel dat ze te zwak zijn en daardoor in sommige gevallen in de weg zitten. Dat argument negeer je een beetje .

Wat zijn de zwaktes van statische checks?? En kan het ook zijn dat jij andere behoeftes heeft dan een doorsnee programmeur? Ik heb eerlijk gezegd nog nooit het geval gehad dat een typesysteem me in de weg zat. Alleen dat ze niet genoeg konden..

[Verwijderd]

Alarmnummer schreef op zaterdag 11 december 2004 @ 11:17:
En zef.. mbravenboer.. hebben jullie wel eens grote lappen geprogrammeerd in dynamische talen?

Wel in Perl en PHP (beide projecten met meerdere duizenden regels), helaas minder in Python. De types heb ik nooit een probleem gevonden, wat ik altijd wel als vervelend ervaren heb is:

• Je merkt typefouten of verkeerde methode aanroepen pas op als je het test (met Java in Eclipse zie ik die fouten direct zodra ik opsla, of zelfs terwijl ik typ)
• Refactoring moet compleet met de hand. "Hmm, deze methode heeft niet echt een handige naam." De barière om uiteindelijk toch overal maar de naam te gaan vervangen is veel hoger dan als je Eclipse even vraagt de methode een andere naam te geven en dit overal even door te voeren (wat kan met Java)
• Je hebt geen (goede) code-completion. Hoe heet die methode ookalweer? Dit is met name een probleem als je maar af en toe aan een project werkt.

Dit zijn belangrijke nadelen. De vraag is echter of, en wanneer, gefrummel met types, casts etc. je het leven lastiger gaan maken dan de nadelen die ik noemde. Bruce Eckel stelt namelijk dat dit gebeurt.

Hoe ik in dit topic ook over mag komen, ik ben niet per sé een voorstander van dynamische talen. Ik probeer de discussie slechts wat te nuanceren. Ik geloof namelijk niet in haast extremistische beweringen als "dynamische talen zijn voor prutsers" of "statische talen zijn voor nerds die overal de correctheid bewezen van willen hebben". Ik lees al maanden artikelen van verschillende kanten over dit onderwerp, maar heb de plaats van dynamische talen in de informatica nog niet kunnen bepalen. Dat we er in deze discussie uit gaan komen lijkt me ook bijzonder sterk.

[mbravenboer]

Alarmnummer: Ik heb eerlijk gezegd nog nooit het geval gehad dat een typesysteem me in de weg zat. Alleen dat ze niet genoeg konden..

Overal waar jij een cast zet, is het type systeem niet in staat om de garanties te geven die jij zelf wel denkt te kunnen geven. Je wilt toch niet zeggen dat jij helemaal nooit meer cast? Vroeger moest je zelfs voor eenvoudige verzamelingen zelf zulke garanties geven en daarom zijn generics een flinke verbetering, maar er blijven vervelende punten waar je toch nog zult moeten casten.

Een andere indicatie dat type systemen zwak zijn, is de mate waarin je code generiek kan maken. Kan je in Java bijvoorbeeld een generieke traversal implementeren over een abstracte syntax boom zonder reflectie? Kan je serializatie implementeren zonder reflectie? We accepteren het dat je voor zulke situaties terugvalt op reflectie, maar vrijwel elk punt waar je reflectie gebruikt geeft een gebrek in het type systeem aan. Je treeft in feite buiten het type systeem.

Als de huidige type systemen perfect zouden zijn, zou er echt niet zoveel tijd ingestoken worden. Mensen zijn zelfs nog niet tevreden over type systemen van talen als Haskell, wat al vele male krachtiger is dan het type systeem van talen als Java. Daarom wordt er tijd gestoken in generiek programmeren (Generic Haskell, Scrap your boilerplate, Template Haskell, Stratego, Strafunski). Op dit moment gaat de strijd met name tussen puur generiek programmeren (getypeerd in Generic Haskell, ongetypeerd Stratego) en het bereiken van generieke code door middel van generatief programmeren (Template Haskell, Strafunski, JJTraveler, JJForester, ApiGen).

[Alarmnummer]

mbravenboer schreef op zaterdag 11 december 2004 @ 12:22:
[...]

Overal waar jij een cast zet, is het type systeem niet in staat om de garanties te geven die jij zelf wel denkt te kunnen geven. Je wilt toch niet zeggen dat jij helemaal nooit meer cast?

Sinds ik generics in Java en C# heb komt het eigelijk nog maar erg zelden voor. En voor die zeldzaamheid dat het wel voorkomt.. so be it.. vind ik eerlijk gezegd geen probleem.

Daarom wordt er tijd gestoken in generiek programmeren (Generic Haskell, Scrap your boilerplate, Template Haskell, Stratego, Strafunski). Op dit moment gaat de strijd met name tussen puur generiek programmeren (getypeerd in Generic Haskell, ongetypeerd Stratego) en het bereiken van generieke code door middel van generatief programmeren (Template Haskell, Strafunski, JJTraveler, JJForester, ApiGen).

Hmm.. Kijk het is goed dat daar onderzoek naar verricht wordt maar ik denk dat 99% van de normale programmeurs voorlopig daar niet mee in aanraking komen. Wij moeten werken binnen de mainstreamtalen en roeien met de beperkingen die daar in zitten. Niet alle bedrijven hebben tijd/geld voor onderzoek... bij veel bedrijven moet er gewoon 'normale' software geproduceerd worden om brood op de plank te brengen. Dat hoeft geen software te zijn met de coolste taalfeatures. Het moet snel goedkoop en goed te produceren zijn.. en ook de gemiddelde programmeur moet kunnen begrijpen wat er gebeurt.

[mbravenboer]

Alarmnummer: Wij moeten werken binnen de mainstreamtalen en roeien met de beperkingen die daar in zitten. Niet alle bedrijven hebben tijd/geld voor onderzoek... bij veel bedrijven moet er gewoon 'normale' software geproduceerd worden om brood op de plank te brengen. Dat hoeft geen software te zijn met de coolste taalfeatures. Het moet snel goedkoop en goed te produceren zijn.. en ook de gemiddelde programmeur moet kunnen begrijpen wat er gebeurt.

Uh, tja, dat is natuurlijk allemaal waar, maar het ging hier meer om een fundamentele discussie over statisch en dynamisch getypeerde talen. Je begon met de stelling dat er niets mis is met de type systemen van Java en C#, maar dat argument zet je nu op zij met een praktisch argument. Waarom zou jouw laatste opmerking in het bijzonder voor statische type controle pleiten? Het is een algemeen probleem in bedrijven dat je afhankelijk bent van mainstream technieken, onafhankelijk van de technieken en talen waarvoor je kiest.

[flowerp]

Alarmnummer schreef op zaterdag 11 december 2004 @ 12:42:
[...]

Sinds ik generics in Java en C# heb komt het eigelijk nog maar erg zelden voor. En voor die zeldzaamheid dat het wel voorkomt.. so be it.. vind ik eerlijk gezegd geen probleem.

In het licht van deze discussie is het mischien aardig om te realiseren dat Java generics feitelijk automatisch door de compiler ingevoerde casts zijn. C# generics zitten anders in elkaar (maar ik ben geen C# expert, dus weet het niet precies). C++ 'generics' (templates) zijn iniedergeval wel echte generic types, maar deze kunnen erg complex zijn om te bouwen. Lees, als je ze voor andere dingen wilt gebruiken als simpele geparameteriseerde collections wordt de code al snel moeilijk om te lezen.

Wat de namen van het type systeem betreft, dynamic typing vs static typing klinkt natuurlijk een stuk meer in het voordeel van dynamic typing. Dynamic wordt toch eerder gezien als iets wat beter is dan static. Als je nu strong typing vs weak typing neemt, dan klinkt strong typing weer beter. De voorstanders van een bepaalde methode geven er natuurlijk hun eigen draai aan, en kiezen dat wat het beste past bij hun aanpak. Ik weet niet of ik het helemaal met de bovengenoemde definities eens bent. Ik heb ze iniedergeval iets anders geleerd.

Maar hoe de designers over hun aanpak denken is nog een 'battle' die op niveau wordt gevoerd. Waar mijn eerdere comments eigenlijk meer betrekking op hadden, is niet zozeer het feit dat PHP zelf -echt- door en door evil is, maar dat momenteel veel mensen die eigenlijk niet zouden moeten programmeren in het openbaar, dat met PHP wel doen. Ik vergelijk het een beetje met de Australian hype uit het gabber tijdperk. Australian was opzich een normaal kleding merk, totdat de gabbers er massaal mee aan de haal gingen. Vanaf dat moment zat er, onbedoeld door de fabrikant, een bepaald smaakje aan het merk.

Ik herhaal nogmaals, hoewel ik niet gek ben van PHP en het zeker niet de 'poster boy' van het dynamic genre is (Python is wat dat betreft al een stuk beter), geloof ik echt dat een goede programmeur gewoon goede software kan maken in PHP. Of dat in Java beter had gekunt is mischien slechts mijn eigen mening en daar was ik boven iets te ongenuanceerd in. Wat wel echt zo is, is dat momenteel PHP een 'lamer magnet' is. Ik heb zelf jaren lang gezwoegd om mijn HBO informatica diploma te krijgen, waarbij ik veel kennis en inzichten heb moeten opdoen. Van PHP mensen heb ik daadwerkelijk te horen gekregen dat zo'n opleiding onzin is, want met PHP is al die kennis helemaal niet nodig. Voor de echte kenner zegt zo'n opmerking natuurlijk al genoeg.

[Verwijderd]

flowerp schreef op zaterdag 11 december 2004 @ 13:28:
Wat de namen van het type systeem betreft, dynamic typing vs static typing klinkt natuurlijk een stuk meer in het voordeel van dynamic typing. Dynamic wordt toch eerder gezien als iets wat beter is dan static. Als je nu strong typing vs weak typing neemt, dan klinkt strong typing weer beter. De voorstanders van een bepaalde methode geven er natuurlijk hun eigen draai aan, en kiezen dat wat het beste past bij hun aanpak. Ik weet niet of ik het helemaal met de bovengenoemde definities eens bent. Ik heb ze iniedergeval iets anders geleerd.

Het lijkt me een beetje treurig als je elkaar van een bepaalde aanpak gaat overtuigen door ze op een bepaalde manier te gaan benoemen. Maar wie weet heb je gelijk.

Ik vergelijk het een beetje met de Australian hype uit het gabber tijdperk. Australian was opzich een normaal kleding merk, totdat de gabbers er massaal mee aan de haal gingen. Vanaf dat moment zat er, onbedoeld door de fabrikant, een bepaald smaakje aan het merk.

Tegenwoordig heb je Lonsdale

Ik herhaal nogmaals, hoewel ik niet gek ben van PHP en het zeker niet de 'poster boy' van het dynamic genre is (Python is wat dat betreft al een stuk beter), geloof ik echt dat een goede programmeur gewoon goede software kan maken in PHP. Of dat in Java beter had gekunt is mischien slechts mijn eigen mening en daar was ik boven iets te ongenuanceerd in. Wat wel echt zo is, is dat momenteel PHP een 'lamer magnet' is. Ik heb zelf jaren lang gezwoegd om mijn HBO informatica diploma te krijgen, waarbij ik veel kennis en inzichten heb moeten opdoen. Van PHP mensen heb ik daadwerkelijk te horen gekregen dat zo'n opleiding onzin is, want met PHP is al die kennis helemaal niet nodig. Voor de echte kenner zegt zo'n opmerking natuurlijk al genoeg.

Da's natuurlijk allemaal waar, maar is niet echt de discussie (of iig: zou de discussie niet moeten zijn). PHP is makkelijk -> elke tiener gaat het gebruiken -> je krijgt een nieuwe golf van "informatici" die niet beter weten -> PHP rulezzzz!!!!11

[ Voor 4% gewijzigd door Verwijderd op 11-12-2004 13:55 ]

[Olaf van der Spek]

Manuzhai schreef op zaterdag 11 december 2004 @ 10:33:
En als een programmeur goede software kan schrijven in PHP, denk je dan echt dat hij in "Java of andere pro [sic!] talen" nog betere dingen kan schrijven? Uit onderzoek is gebleken dat bugs per line of code ongeveer gelijk blijven, onafhankelijk van de taal. Dat betekent dus dat jij in hetzelfde stukje formaliteit in je "pro taal" Java veel meer fouten maakt dan als je dat stukje in PHP schrijft...

Alleen als de code in Java langer is dan in PHP. Is dat ook (altijd/vaak) zo?

[Olaf van der Spek]

mbravenboer schreef op zaterdag 11 december 2004 @ 12:22:
Overal waar jij een cast zet, is het type systeem niet in staat om de garanties te geven die jij zelf wel denkt te kunnen geven. Je wilt toch niet zeggen dat jij helemaal nooit meer cast?

Dat klopt, maar in dat geval kan de cast toch alsnog runtime gechecked worden?

[Alarmnummer]

OlafvdSpek schreef op zaterdag 11 december 2004 @ 14:59:
[...]

Dat klopt, maar in dat geval kan de cast toch alsnog runtime gechecked worden?

Dat ligt eraan met welke/taal platform je werkt. Ik weet het niet zeker van c++ maar ik geloof dat je daar gerust een 'mis'cast kunt doen. Met java en .net is dit niet mogelijk.