It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
Een half jaar terug ben ik begonnen als junior developer in o.a. c++ en Java.In het begin dacht ik echt "Java, waarom geen php?" Nu inmiddels een half jaar later kan zeggen "Wat zit Java goed in elkaar!"
Ik heb het idee, dat het programmeren in Java veel overzichtelijker werkt en ik weet wel waarom.
Nu kan je natuurlijk zeggen, dat ligt aan de programmeur, en dat zal ook wel voor een gedeelte waar zijn, maar toch.
Wat is hierbij je markt? MKB of Enterprise? Je stelling is op MKB zeker van toepassing, maar als je over Enterprise praat dan is deze stelling absoluut niet van toepassing. Daar is namelijk 1 ding het belangrijkst en dat is continuiteit. Dan een heel eind niets en dan misschien pegels.Erkens schreef op zondag 28 januari 2007 @ 17:24:
de markt interesseerd het helemaal niet wat er gebruikt wordt, zolang het maar werkt en onderhoudt niet veel kost
@TS: Het zal al wel gezegd zijn (heb niet alle replies volledig doorgelezen). Het antwoord op jou vraag kan alleen worden gegevens als je je eigen doelgroep duidelijk voor ogen hebt. Ga je voor MKB applicaties (en oké, binnen het MKB kun je ook weer onderscheid maken tussen verschillende klantgroepen met verschillende verwachtingen) kies dan voor een platform wat voor de klant betaalbaar is en waarmee je relatief snel iets op kunt zetten, dat kan, voor zover mij bekend, gemakkelijk met PHP. Wil je vooral Enterprise klanten aanspreken, voor wie continuiteit belangrijker is dan kosten, dan zou ik voor Java of .NET gaan.
Anderzijds gaat het ook om hetgeen wat je voor je opdrachtgever doet. Ben je bezig met een website? Dan zijn de meer script-gerelateerde talen een uitkomst. Maak je een complete webwinkel, dan kan Java / .NET weer de betere keuze zijn.
Op zoek naar een baan als Coldfusion webdeveloper? Mail me!
Verwijderd
Inderdaad. En in het geval van continuiteit heb je het dus al snel over de vraag: krijgen we ondersteuning van een betrouwbaar bedrijf? Wie garandeert ons dat de gebruikte oplossing lang genoeg meegaat en ondersteunt wordt? Enzovoorts etcetera. Je komt dan in de praktijk snel uit bij oplossingen van bekende grote bedrijven zoals Microsoft (.Net) en Sun (Java), omdat die bedrijven kunnen garanderen dat hun technologie op lange termijn nog bruikbaar zal zijn en ondersteunt zal worden. Voor PHP is dat maar twijfelachtig.faabman schreef op maandag 29 januari 2007 @ 21:34:
Interessant topic, even een paar stellingen eruit tillen.
[...]
Wat is hierbij je markt? MKB of Enterprise? Je stelling is op MKB zeker van toepassing, maar als je over Enterprise praat dan en deze stelling absoluut niet van toepassing. Daar is namelijk 1 ding het belangrijkst en dat is continuiteit. Dan een heel eind niets en dan misschien pegels.
Ik denk zelf dat Java in de nabije toekomst nog extra relevant wordt vanwege de platform-onafhankelijkheid en de open standaarden, maar dat valt nog te bezien.
Overigens is mijn persoonlijke mening dat de taal PHP een samenraapsel is van features uit andere talen, wat een ontzettende onoverzichtelijke zooi oplevert die aanzet tot het schrijven van slechte code. Maar dat wil NIET zeggen dat het niet soms "the right tool for the job" is.
Edit: kwam dit plaatje tegen - moest ik wel om lachen (niet de bedoeling om te flamen hoor) http://tnx.nl/php.jpg
[ Voor 4% gewijzigd door Verwijderd op 30-01-2007 00:47 . Reden: kleine toevoeging ]
http://tnx.nl/phpVerwijderd schreef op dinsdag 30 januari 2007 @ 00:39:
[...]
Inderdaad. En in het geval van continuiteit heb je het dus al snel over de vraag: krijgen we ondersteuning van een betrouwbaar bedrijf? Wie garandeert ons dat de gebruikte oplossing lang genoeg meegaat en ondersteunt wordt? Enzovoorts etcetera. Je komt dan in de praktijk snel uit bij oplossingen van bekende grote bedrijven zoals Microsoft (.Net) en Sun (Java), omdat die bedrijven kunnen garanderen dat hun technologie op lange termijn nog bruikbaar zal zijn en ondersteunt zal worden. Voor PHP is dat maar twijfelachtig.
Ik denk zelf dat Java in de nabije toekomst nog extra relevant wordt vanwege de platform-onafhankelijkheid en de open standaarden, maar dat valt nog te bezien.
Overigens is mijn persoonlijke mening dat de taal PHP een samenraapsel is van features uit andere talen, wat een ontzettende onoverzichtelijke zooi oplevert die aanzet tot het schrijven van slechte code. Maar dat wil NIET zeggen dat het niet soms "the right tool for the job" is.
Edit: kwam dit plaatje tegen - moest ik wel om lachen (niet de bedoeling om te flamen hoor) http://tnx.nl/php.jpg

De reden waarom ik dit vraag is omdat ik momenteel voor de keuze sta met welke technologie verder te gaan. .NET valt momenteel af vanwege de hoge investeringskosten (ontwikkelomgeving, serverinrichting en er is totaal nog geen kennis, laat staan ervaring, aanwezig), maar ik heb zelf al wel geruime ervaring met Java (waaronder ook EJB en het Struts framework). Momenteel hebben we heel veel gedaan in PHP en ik heb geprobeerd om voor mijzelf de standaard daarin hoog te houden. PHP biedt geruime mogelijkheden om verschrikkelijk slordig te programmeren, maar als je houdt van mooie architecturen en je hebt discipline, dan kun je met PHP ook best hoogwaardig gestructureerde code schrijven (zo heb ik een eigen implementatie van het Model 2 paradigma ontwikkeld voor de structurering van de software van mijn projecten).
Echter, mijn hart heeft vanaf het begin dat ik het gebruikte gelegen bij Java. Ik vind het nog steeds een prachtige taal en nu heb ik de kans om daar voor te gaan. Ik wil mij graag verder ontwikkelen en heb het gevoel dat ik bij PHP aan het maximum zit en daarbij komt ook nog eens het veel slechtere imago van PHP.
Na het lezen van jullie vele bijdragen (waarvoor mijn dank!) en mijn eigen gevoel is mijn keuze voor Java een concreet feit.
Edit (aanvulling):
Eén van de grote voordelen van Java boven PHP is, zoals hier al reeds aangehaald, de scope functionaliteit. Hoe heerlijk is het om bijvoorbeeld bij een authenticatie een object aan te maken (met daarin bijvoorbeeld de naam van de gebruiker, het aantal logins enzovoort en om deze dan ergens op een statuspaneeltje te tonen) en deze te plaatsen in een sessiescope? In PHP moet je bij iedere (page)request deze gegevens weer ophalen.
Of stel een bepaalde functie in je applicatie mag maar door één persoon tegelijk gebruikt worden. Dan kun je dit realiseren middels de applicatiescope, terwijl je in PHP zoiets moet oplossen met bijvoorbeeld een wisselbestand of ergens in de database.
Dit zijn allemaal zaken waarvan het water me alweer in de mond loopt, als ik eraan denk
[ Voor 23% gewijzigd door Verwijderd op 30-01-2007 09:38 ]
PHP heeft:flowerp schreef op maandag 29 januari 2007 @ 21:20:
[...]
Dus PHP heeft frameworks nodig om goed te worden. Java EE en .NET hebben die frameworks echter nu al. Waarom zou je dan wachten op PHP terwijl je ze vandaag al kunt gebruiken in Java en .NET?
- Zend Framework MVC framework + Component framework
- Ez Components Component framework
- Cake PHP MVC framework
- Symfony MVC framework
- PHP doctrine ORM framework (alleen documentatie is up ivm met site onderhoud)
- PEAR Application repository
- Prado Component & event based framework voor php applicatie development
PHP bied vrijheden die kunnen en vaak leiden tot slordig programmeren en het mixen van de verschillende lagen van een applicatie. Op andere platformen voor het bouwen van web applicaties kan dit echter ook het schijnt alleen bij php wat makkelijker te zijn. Het is de programmeur en de kennis van de programmeur die bepaald of een applicatie netjes in elkaar zit en hoe onderhoudbaar de applicatie in elkaar zit.
Kortom je kan met PHP prima applicaties bouwen die op een verantwoorde manier in elkaar zitten en er is een ruime keuze tussen verschillende frameworks.
PHP: De lokale visboer, automaterialenhandel of kroeg welke een simpele webapplicatie nodig heeft waar bijvoorbeeld de meest recente prijzen van af te lezen zijn in combinatie met bijvoorbeeld een simpel bestelsysteem. Feit is dat er voor dit soort klusjes een hoop prutsers aan het werk zijn.
.NET: Een bedrijf (sector doet er overigens niet toe) welke al voorzien is van een mooi Microsoft netwerk waar alles out of the box en met fabriekssupport al prima werkt. Zeer geschikt platform voor het intern afhandelen van o.a. interne administratieve handelingen en het naar buiten communiceren met dynamische pagina's.
Java: Perfecte taal voor netwerken en systemen die multi-platform zijn, goede support hoewel er ook vele derden er aan mee ontwikkelen. Maar hoe interessant is een platform als je met behulp van 1 taal en virtual machines ZOVEEL systemen kan bereiken.
Alle drie de platformen hebben factoren mee wat ze bij hen gebruikers gewoon populair maakt. Ik heb mijn voorkeuren, en gezien de verhitte discussies in dit topic zijn er meerderen die er zo over denken. Ik zeg er alleen bij dat ALS een taal in een situatie beter werkt, ik juist voor deze taal kies.
Tijd voor een mening: ik vind het woord 'simpel' denigrerend. Met PHP kan je ook wel complexe webapplicaties maken.PHP: De lokale visboer, automaterialenhandel of kroeg welke een simpele webapplicatie nodig heeft
Let op: ik zeg niet dat PHP het antwoord op alles is, dat is het niet en het heeft genoeg vervelende issues/tekortkomingen. Maar kap aub eens (algemeen bedoeld) met steeds PHP en 'simpel' of 'prutser' in adem te noemen.
{signature}
Daar wordt niet gezegd dat PHP voor prutsers is of simpel, maar dat het geschikt is voor simpelere opdrachten. En dat is ook waar. Er zijn namelijk betere tools voor de complexere jobs.Voutloos schreef op dinsdag 30 januari 2007 @ 13:19:
[...]
Tijd voor een mening: ik vind het woord 'simpel' denigrerend. Met PHP kan je ook wel complexe webapplicaties maken.
Let op: ik zeg niet dat PHP het antwoord op alles is, dat is het niet en het heeft genoeg vervelende issues/tekortkomingen. Maar kap aub eens (algemeen bedoeld) met steeds PHP en 'simpel' of 'prutser' in adem te noemen.
Niks denigrerends, maar gewoon kijkend naar de feiten en de praktijk waar de verschillende talen/platforms nu ingezet worden.
Fat Pizza's pizza, they are big and they are cheezy
Dit wordt de hele tijd gezegd maar er wordt nergens benoemd voor welke complexere jobs op het gebied van het bouwen van web applicaties PHP minder geschikt is. En dit dan puur op het gebied van functionaliteit op het gebied van de taal en libraries/frameworks die ervoor beschikbaar zijn.Daar wordt niet gezegd dat PHP voor prutsers is of simpel, maar dat het geschikt is voor simpelere opdrachten. En dat is ook waar. Er zijn namelijk betere tools voor de complexere jobs.
PHP heeft ook een bedrijf achter zich wat een drijfende kracht is, namelijk Zend. Dit bedrijf heeft er alle belang bij dat PHP doorontwikkeld en ondersteund wordt. Ook kun je via Zend Support krijgen of via een van de partners die Zend wereldwijd heeft (ook in Nederland)Verwijderd schreef op dinsdag 30 januari 2007 @ 00:39:
[...]
Inderdaad. En in het geval van continuiteit heb je het dus al snel over de vraag: krijgen we ondersteuning van een betrouwbaar bedrijf? Wie garandeert ons dat de gebruikte oplossing lang genoeg meegaat en ondersteunt wordt? Enzovoorts etcetera. Je komt dan in de praktijk snel uit bij oplossingen van bekende grote bedrijven zoals Microsoft (.Net) en Sun (Java), omdat die bedrijven kunnen garanderen dat hun technologie op lange termijn nog bruikbaar zal zijn en ondersteunt zal worden. Voor PHP is dat maar twijfelachtig.
Ok, dit is volgens al wel gezegd, zelfs meerdere keren, maar bijvoorbeeld het transactiemanagement en declaratieve security in EJB. Dat zijn dingen die de kwaliteit van je systeem beter maken, dus grotere bedrijven zoals banken houden ervan.Brakkie schreef op dinsdag 30 januari 2007 @ 15:05:
[...]
Dit wordt de hele tijd gezegd maar er wordt nergens benoemd voor welke complexere jobs op het gebied van het bouwen van web applicaties PHP minder geschikt is. En dit dan puur op het gebied van functionaliteit op het gebied van de taal en libraries/frameworks die ervoor beschikbaar zijn.
Fat Pizza's pizza, they are big and they are cheezy
Verwijderd
Best aardige vergelijking, alleen sloeg je de plank compleet mis toen je .NET en Java opsplitste. .NET en Java vissen in exact dezelfde vijver qua type applicaties, bedrijven enzovoorts. Het enige verschil is dat Java applicaties vaak aan Oracle gekoppeld worden en ook redelijk vaak op linux/unix systemen komen te draaien. Maar voor de rest maakt het geen moer uit. Ik heb al zat cross platform applicaties gebouwd met .NET, geen enkel probleem en hetzelfde geldt voor fabriekssupport bij Java. Genoeg support te vinden, ook vanuit Sun.merauder schreef op dinsdag 30 januari 2007 @ 13:07:
Tijd voor een mening: Choose the right tool for the right job!!!!
PHP: De lokale visboer, automaterialenhandel of kroeg welke een simpele webapplicatie nodig heeft waar bijvoorbeeld de meest recente prijzen van af te lezen zijn in combinatie met bijvoorbeeld een simpel bestelsysteem. Feit is dat er voor dit soort klusjes een hoop prutsers aan het werk zijn.
.NET: Een bedrijf (sector doet er overigens niet toe) welke al voorzien is van een mooi Microsoft netwerk waar alles out of the box en met fabriekssupport al prima werkt. Zeer geschikt platform voor het intern afhandelen van o.a. interne administratieve handelingen en het naar buiten communiceren met dynamische pagina's.
Java: Perfecte taal voor netwerken en systemen die multi-platform zijn, goede support hoewel er ook vele derden er aan mee ontwikkelen. Maar hoe interessant is een platform als je met behulp van 1 taal en virtual machines ZOVEEL systemen kan bereiken.
Dat laatste hoeft niet volgens mij, wat is er tegen om zo'n user-object zichzelf te laten serializen (en omgekeerd) naar de sessie-store (t.o.v. sessie-scope) ? Ok ik kan wel wat argumenten bedenken, omslachtig(er) bijvoorbeeld, maar het verschil lijkt me wat kleiner dan dit voorbeeld deed lijken.Verwijderd schreef op dinsdag 30 januari 2007 @ 08:53:
Hier weer even een reactie van de TS.
...
Edit (aanvulling):
Eén van de grote voordelen van Java boven PHP is, zoals hier al reeds aangehaald, de scope functionaliteit. Hoe heerlijk is het om bijvoorbeeld bij een authenticatie een object aan te maken (met daarin bijvoorbeeld de naam van de gebruiker, het aantal logins enzovoort en om deze dan ergens op een statuspaneeltje te tonen) en deze te plaatsen in een sessiescope? In PHP moet je bij iedere (page)request deze gegevens weer ophalen.
misschien raak ik de grote lijn een beetje kwijt
@Janoz: Ok, weer wat bijgeleerd
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Naast het feit dat zend bij lange na niet zo krachtig is als bedrijven als bijvoorbeeld Microsoft, Sun en Oracle gaat het niet enkel om de kracht van de bedrijven, maar vooral om de continuiteit. Dat is nu juist iets waarin php heeft laten zien dat ze niet goed zijn. Hoeveel applicaties zijn er bijvoorbeeld niet gemold omdat in een versie plotseling register globals uit stond?Brakkie schreef op dinsdag 30 januari 2007 @ 15:12:
[...]
PHP heeft ook een bedrijf achter zich wat een drijfende kracht is, namelijk Zend. Dit bedrijf heeft er alle belang bij dat PHP doorontwikkeld en ondersteund wordt. Ook kun je via Zend Support krijgen of via een van de partners die Zend wereldwijd heeft (ook in Nederland)
Natuurlijk is het geen slechte zet geweest om het te doen, maar als ze wat langer hadden nagedacht dan hadden ze het waarschijnlijk helemaal niet ingebouwd (het injecteren van uservars in de global scope). Je wilt als groot bedrijf niet dat je, elke keer als er een nieuwe release komt, je je hele software weer door moet omdat dingen mogelijk veranderd kunnen zijn.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
En nu noem je leuk Het zwakke punt van o.a. microsoft, bang/lui om een rigoreuze aanpassing te doen. Het is voor veel bedrijven die PHP draaide niet leuk geweest, maar dan draaide je al een onveilig systeem. De verwijzingen (o.a. $_GET[], $_POST[]) waren al langer geschikt.Natuurlijk is het geen slechte zet geweest om het te doen, maar als ze wat langer hadden nagedacht dan hadden ze het waarschijnlijk helemaal niet ingebouwd (het injecteren van uservars in de global scope). Je wilt als groot bedrijf niet dat je, elke keer als er een nieuwe release komt, je je hele software weer door moet omdat dingen mogelijk veranderd kunnen zijn.
Ik vraag me zeer zeker af of bijv. micorsoft, maar ook sun het zouden hebben aangedurfd om zo'n rigoreuze aanpassing door te voeren.
Nu kan je zeggen zorg niet voor dit soort fouten in PHP, maar alles wat door mensen is gemaakt/ontworpen zal fouten bevatten.
Just my 2 cents,
Verder een zeer hoogwaardige discussie, als PHP fan zeer leuk te lezen dat er ook redelijk over PHP kan worden gepraat.
Super Jongens
Met veel pijn en moeite zal uiteindelijk nog wel dezelfde functionaliteit te benaderen zijn, maar persoonlijk vind ik dat je dan druk bezig bent om het vierkante blokje door het ronde gaatje te duwen terwijl je ook gewoon het ronde blokje had kunnen pakken. 90% van de mensen die zeggen 'Ja, maar met php kun je ook complexe dingen doen' hebben alleen ervaring met php. Feit is dat je, wanneer je nooit wat anders hebt gezien, je ook niet weet hoe het anders kan. Een mooi tekenend voorbeeld vind ik het Ruby onRails topic. Als je kijkt welke mensen daar het meest lyrisch zijn over de mogenlijkheden dan zijn dit oud php-ers. Alleen hebben een soort 'man, wat is het ontwikkelen zo makkelijk met deze extra's in het platform'. Daarmee wel ik niet zeggen dat andere mensen er niet lyrisch over zijn, maar ik als Javaan heb veel dingen die in Ruby zitten al lang een keer eerder gezien.Brakkie schreef op dinsdag 30 januari 2007 @ 15:05:
[...]
Dit wordt de hele tijd gezegd maar er wordt nergens benoemd voor welke complexere jobs op het gebied van het bouwen van web applicaties PHP minder geschikt is. En dit dan puur op het gebied van functionaliteit op het gebied van de taal en libraries/frameworks die ervoor beschikbaar zijn.
Php mist gewoon dingen. Ik heb het scope verhaal al genoemd. Een ander iets is bijvoorbeeld object georienteerdheid. Wat er nu aan OO in php zit is imho een lachertje. Het niet impliciet aanroepen van constructors, geen fatsoenlijke overerving. Daarnaast zorgt het enkel op request gebaseerde systeem ervoor dat je voor elk proces die complete classstructuur weer moet interpreteren en eventueel moet deserializen.
Nu kun je OO wel een erg puristisch iets vinden, maar zeker bij iets grotere projecten wordt het steeds belangrijker dat het onderhoudbaar blijft en de correctheid makkelijk gegarandeerd kan worden. Correctheid bewijzen gaat veel makkelijker in een puur object georrienteerde omgeving omdat je daarin duidelijk kunt garanderen wat waarbij kan. Als je een locale variabele private maakt kun je er vanuit gaan dat niemand anders er bij kan. Dit maakt het isoleren van een stuk code veel makkelijker waardoor je bij onderhoud of controle niet je complete applicatie hoeft te controleren, maar enkel het stuk geisoleerde code hoeft te bekijken en daar keiharde garanties aan kunt hangen. Vervolgens kun je in de rest van je applicatie uitgaan van die garanties wanneer je dat stuk aanspreekt.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Ook microsoft heeft wel eens vanwege security backward compatibility moeten breken (was volgens mij tussen 1.1 en 2.0, in 2.0 waren enkele methoden niet meer beschikbaar. Preciese specs moet ik even opzoeken).Ramasha schreef op dinsdag 30 januari 2007 @ 19:57:
[...]
En nu noem je leuk Het zwakke punt van o.a. microsoft, bang/lui om een rigoreuze aanpassing te doen. Het is voor veel bedrijven die PHP draaide niet leuk geweest, maar dan draaide je al een onveilig systeem. De verwijzingen (o.a. $_GET[], $_POST[]) waren al langer geschikt.
Ik vraag me zeer zeker af of bijv. micorsoft, maar ook sun het zouden hebben aangedurfd om zo'n rigoreuze aanpassing door te voeren.
Dat het verder bij Sun en MS weinig voorkomt, komt omdat er daar een stuk langer over wordt nagedacht voordat iets wordt geimplementeerd. Dat klinkt stom, maar als je ziet hoe lang het traject is voordat bepaalde functionaliteit in de j2ee standaard wordt opgenomen. Tot die tijd zijn er vaak wel implementaties beschikbaar, maar wanneer je hiervoor kiest weet je dat het niet perse definitief hoeft te zijn. Daarnaast heeft php het probleem dat het als een simpel homepage dynamischer maak taaltje begonnen is waarbij iemand gewoon eens iets leuks in elkaar gedraait heeft om te zien hoever het komt. Dat is php lastig aan te rekenen.
Het probleem is meer dat ook bij nieuwe functionaliteiten vaak fundamentele fouten worden gemaakt en dat er niet op een normale manier met bugmeldingen omgegaan wordt. Degene verantwoordelijk voor security is niet voor niks opgestapt. Nog niet zo heel lang geleden liep er hier op GoT ook een thread over een vreemde lekkende scope van een ForEach. Dit is vervolgens als bug gemeld (dat was het ook) maar hierop werd vervolgens gereageerd met 'Its not a bug, its a feature' (Niet verzonnen!!!). Dat zijn niet de dingen die je wilt zien wanneer je een kritiek stuk software wilt ontwikkelen!
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Het voorbeeld wat je noemt wat betreft register globals vind ik juist een teken van durf en moeilijke beslissingen nemen die wel erg verstandig zijn. Maar goed dat zeg je zelf ook al min of meer.Janoz schreef op dinsdag 30 januari 2007 @ 19:29:
[...]
Naast het feit dat zend bij lange na niet zo krachtig is als bedrijven als bijvoorbeeld Microsoft, Sun en Oracle gaat het niet enkel om de kracht van de bedrijven, maar vooral om de continuiteit. Dat is nu juist iets waarin php heeft laten zien dat ze niet goed zijn. Hoeveel applicaties zijn er bijvoorbeeld niet gemold omdat in een versie plotseling register globals uit stond?
Natuurlijk is het geen slechte zet geweest om het te doen, maar als ze wat langer hadden nagedacht dan hadden ze het waarschijnlijk helemaal niet ingebouwd (het injecteren van uservars in de global scope). Je wilt als groot bedrijf niet dat je, elke keer als er een nieuwe release komt, je je hele software weer door moet omdat dingen mogelijk veranderd kunnen zijn.
Zend is dan misschien veel minder machtig en kapitaal krachtig dan de reuzen Microsoft, Sun en Oracle. Ze ondersteunen wel een scripttaal die nog steeds 1 van de snelst groeiende is. Daarnaast zijn ze goed bezig door te faciliteren in de ontwikkeling van een framework wat uiteindelijk PHP een meer volwassen speler tussen de andere web platformen zal maken. Daarnaast hoop ik wel dat PHP altijd makkelijk toegankelijk zal blijven om op een heel simpele manier dynamische websites te bouwen (en natuurlijk ook heel complexe apllicaties
Ik ga trouwens over een maand beginnen als .Net programmeur en ga dan ook voor het eerst kennis maken met .Net en C#. Ik zal over een tijdje nog eens mijn visie op dit onderwerp posten, kijken of ie erg veranderd is.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Als ik nu terugdenk aan de tijd dat ik nog in PHP bezig was, herinner ik mij dat het grootste deel van de tijd dat ik ermee bezig was te maken had met het achtergrondverhaal - databaseverbindingen, data controleren, formulieren afhandelen, dat soort van dingen. Ook was ik veel bezig met het opnieuw schrijven van stukken code, omdat ik weer iets nieuws geleerd had.
Ondertussen heb ik de MVC methode ontdekt (RoR) en weet ik nu wat OOP is en hoe ik het goed toepassen moet. Grootste project in Java tot nu toe bestaat uit iets van 30 klassen, bijna 8 weken werk (is bijna af).
Binnenkort is het goed mogelijk dat ik weer met PHP bezig ga. Wat ik nu al wel weet is dat ik RoR na ga doen, en dat alles zoveel object-georienteerd mogelijk word.
Qua overzichtelijkheid vind ik RoR het beste, je weet bijna automatisch waar wat moet. Bij PHP mag je dat bijna altijd zelf bepalen, tenzij je een streng framework gebruikt waar eerder een mooi lijstje van gemaakt werd. Ikzelf heb alleen hier en daar een stukje van PEAR gebruikt tot nu toe, simpelweg omdat ik het zelf leuker vond om met het achtergrondverhaal bezig te zijn.
Nu ik met Java bezig ben, vind ik het echter wel gemakkelijk dat veel van dat soort spul al ingebakken zit. En dat het ook werkt, en dat je ook precies weet wat het doet zonder dat je de code zelf hoeft te bekijken. Ik heb nooit het voordeel van een IDE voor PHP ingezien, afgezien van de automatische foutcontrole en onderlijning. Met Java zie je nu gelijk wat er beschikbaar is voor een klasse, wat het doet, wat erin moet, wat eruit komt, en andere informatie. Vind ik wel handig.
Ik weet dat dit ook mogelijk is in PHP, maar voordat ik Java gebruikte zag ik daar simpelweg niet veel voordeel in. Ik vertrouwde gewoon geen dingen die ik zelf niet had gemaakt, ook al was dat van anderen misschien efficienter en veilig geweest.
In ieder geval, PHP kan wel gebruikt worden voor grotere applicaties (er zijn miljoenen goeddraaiende websites en webapplicaties die mbv PHP gemaakt zijn), en is zeer geschikt voor de beginnende (web)programmeur. Maar qua veiligheid (in een programmeertechnische manier) vind ik strong-typed en OO talen zoals Java toch beter. Je word sneller gedwongen om op een bepaalde manier te programmeren, wat de overzichtelijkheid (op de korte tot middelgrote duur, zolang je een goed ontwerp hebt) ten goede komt. Je kunt dat ook in PHP, maar het word niet gedwongen door de taal zelf.
Java of PHP? Persoonlijk zeg ik nu Java. Misschien moet ik later meer met PHP doen en verander ik mijn mening, maar op het moment vind ik Java beter.
De support van Sun zelf hoor je mij ook niet over klagen, dat is minstens zo ok als Microsoft. Punt is dat ik vooral deze vergelijking pak vanuit marketings-ooghoek, en dat is waarom men vaak in 'veilige Microsoftnetwerken' wil kiezen voor een oplossing uit die hoeken.Verwijderd schreef op dinsdag 30 januari 2007 @ 15:44:
[...]
Best aardige vergelijking, alleen sloeg je de plank compleet mis toen je .NET en Java opsplitste. .NET en Java vissen in exact dezelfde vijver qua type applicaties, bedrijven enzovoorts. Het enige verschil is dat Java applicaties vaak aan Oracle gekoppeld worden en ook redelijk vaak op linux/unix systemen komen te draaien. Maar voor de rest maakt het geen moer uit. Ik heb al zat cross platform applicaties gebouwd met .NET, geen enkel probleem en hetzelfde geldt voor fabriekssupport bij Java. Genoeg support te vinden, ook vanuit Sun.
Moet eerlijk zeggen dat ik juist op dit moment mijn weg aan het kiezen ben tussen OF .NET of JAVA.
Verwijderd
Jouw vergelijking uit marketingoogpunt gaat ieg niet op voor een groot aantal van de Nederlandse IT bedrijven met zowel Java als .NET afdelingen.merauder schreef op dinsdag 30 januari 2007 @ 23:03:
[...]
De support van Sun zelf hoor je mij ook niet over klagen, dat is minstens zo ok als Microsoft. Punt is dat ik vooral deze vergelijking pak vanuit marketings-ooghoek, en dat is waarom men vaak in 'veilige Microsoftnetwerken' wil kiezen voor een oplossing uit die hoeken.
Moet eerlijk zeggen dat ik juist op dit moment mijn weg aan het kiezen ben tussen OF .NET of JAVA.
Maar wel voor kleinere bedrijven die het budget maar hebben voor 1 platformVerwijderd schreef op dinsdag 30 januari 2007 @ 23:15:
[...]
Jouw vergelijking uit marketingoogpunt gaat ieg niet op voor een groot aantal van de Nederlandse IT bedrijven met zowel Java als .NET afdelingen.
Als het je alleen om de techniek zelf gaat kun je je eigenlijk aan alle twee geen buil vallen. Zoals al eerder gezegd hier, ze zijn zeer gelijkwaardig. De voornaamste .NET taal C# en Java verschillen nu alleen op subtiele punten van elkaar (met C# 3.0 en LINQ wordt dit verschil wel wat groter) en de platformen en tooling komen ook dicht bij elkaar.merauder schreef op dinsdag 30 januari 2007 @ 23:03:
Moet eerlijk zeggen dat ik juist op dit moment mijn weg aan het kiezen ben tussen OF .NET of JAVA.
Een groot verschil zijn natuurlijk wel de kosten. Een klein bedrijf zou mischien eerder voor Java kiezen omdat ze weinig startup kapitaal hebben, en voor Java alles gratis te krijgen is. Je kunt de als stack bijvoorbeeld op Linux, Postgres en Jboss of Tomcat draaien en als tool Eclipse gebruiken. Je geeft dan geen cent aan software uit en de kwaliteit is vaak geen grammetje minder dan de commerciele mogelijkheden.
Bij Microsoft doet de kwaliteit zeker niet onder aan Java, maar er moet wel betaald worden voor alles. Natuurlijk draait asp.net alleen op een Windows server en voor tools kun toch het beste 1 van de betaalde versies van VS gebruiken. Als doekje op het bloeden zijn er wel tegenwoordig gratis express versies van VS en je kunt in principe ook gewoon een gratis DB als Postgres of MySQL gebruiken.
Nog een ander verschil is de beschikbaarheid van source voor het Java platform. Bij onduidelijk gedrag in Java zelf of in Jboss, kan ik gewoon met de debugger in een framework functie steppen en exact zien waar iets niet gaat zoals ik verwacht had. Dit is een mentaal intensief process, maar het heeft me al dikwijls gered.
Aan de andere kant; vanwege de beschikbaarheid van source is Java documentatie vaak slecht of ontbrekend. De Jboss documentatie is gewoon knudde, en dingen als Quartz lijken documentatie te hebben maar als je het even begint te lezen merk je dat het alleen een tutorial is en erg op de opervlakte blijft. Bij Microsoft is het precies omgekeerd. De MSDN documentatie is van zeer hoge kwaliteit. Ze moeten natuurlijk ook wel, maar als je liever documentatie leest dan sourcecode dan is dit zeker een voordeel.
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
Verwijderd
Nou JAVA en .NET, vier compleet verschillende karakters. Deze "stompzinnige" opmerking van mij zegt eigenlijk alles al.merauder schreef op dinsdag 30 januari 2007 @ 23:29:
[...]
Maar wel voor kleinere bedrijven die het budget maar hebben voor 1 platformEn dan kom je weer op het punt, je hebt bedrijven met zowel .NET als JAVA afdelingen, waar zou die splitsing dan wel in zitten.
[ Voor 5% gewijzigd door Verwijderd op 31-01-2007 01:27 ]
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'