Waarop baseer je eigenlijk de keuze voor 'n bepaalde taal?

[De_Bastaard]

Ola,

Ik ben me aan het verdiepen in het maken van een website gebaseerd op Google Maps en het hosten van subsites door users van die site.

Nu vraag ik me echter af, waarop baseer ik (of anderen in het algemeen) nu wat voor taal ik ga gebruiken om zoiets te maken?

Gebruikt iedereen PHP omdat het (volgens velen) vrij toegankelijk is voor nieuwelingen en omdat je er veel van kan leren, of kies je juist voor iets anders zoals RubyOnRails omdat dat "misschien" beter om kan gaan met scaling of iets anders? Of misschien wel ASP ? Waarop baseer je zoiets?

Of is het zoals ik eigenlijk verwacht, je kiest de taal waar je zelf verstand van hebt ... en gaat daarvoor ....

[NMe]

Het is eigenlijk altijd een combinatie van factoren. Dat laatste wat je noemt zal sowieso een zwaarwegende factor zijn; een internetbureau dat geen verstand heeft van ASP.NET maar wel van PHP zou het liefst bij PHP blijven omdat dat minder risico en ontwikkeltijd kost, maar als een klant maar voldoende betaalt gaat zo'n bureau vast overstag. Los van dat heeft elke taal (eigenlijk: elk platform) zijn eigen voordelen en nadelen en je moet wel enigszins iets van de taal weten om hem aan te kunnen prijzen/af te schrijven.

Ik denk trouwens dat deze discussie beter past in Software Engineering & Architecture, dus ik zal je topic even een tikje geven.

[YopY]

In het geval van dit soort toepassingen ligt het er vaak maar net aan waar je aan gewend bent. Als het voor je werk moet en/of op korte termijn kiezen mensen vaak hetgeen waar ze bekend mee zijn. Als het meer een persoonlijk project is en niet kritisch kies je wel eens voor hetgeen je het meest interresant vindt.

Als je het abstract wilt zien is de keuze een functie van ontwikkelsnelheid, betrouwbaarheid, performance en nog wat factoren, waarbij die ook weer afhankelijk zijn van de aanwezige kennis.

En soms heb je gewoon een use case waar een specifieke taal of omgeving zich ideaal voor leent. Een site of webservice met veel gelijktijdige gebruikers en relatief kleine berichten die heen en weer gestuurd zijn is een ideale case voor NodeJS en een in-memory datastore als Redis of MongoDB. Een alternatief die goed met bestaande systemen (zoals Java zooi / libraries) kan samenwerken is dan Scala icm Akka.

Als je vrije keuze hebt en iets nieuws leren geen bezwaar is en je er natuurlijk de tijd voor hebt kun je alle kanten op, ligt er maar net aan wat je casus precies is. Uiteindelijk baseer je de keuze op je eigen ervaringen - alhoewel je die natuurlijk wel eerst opgebouwd moet hebben.

[djc]

YopY schreef op vrijdag 03 februari 2012 @ 22:18:
En soms heb je gewoon een use case waar een specifieke taal of omgeving zich ideaal voor leent. Een site of webservice met veel gelijktijdige gebruikers en relatief kleine berichten die heen en weer gestuurd zijn is een ideale case voor NodeJS en een in-memory datastore als Redis of MongoDB. Een alternatief die goed met bestaande systemen (zoals Java zooi / libraries) kan samenwerken is dan Scala icm Akka.

Dit soort "ideale matches" zijn alleen helemaal niet objectief vast te stellen. De dingen die jij hier noemt zijn connecties die jij in je hoofd hebt zitten, maar ik zou weer andere keuzes maken. Als je het goed wil doen moet je het een stuk algemener stellen, en zelfs dan wordt het moeilijk. Ik vind NodeJS bijvoorbeeld niet zo interessant, en denk dat ik met Twisted Python heel goed hetzelfde (of iets beters) kan bereiken.

Het beste dat je dus kan doen is kijken naar de applicatie die je wil ontwikkelen, wat voor performance-karakteristieken je daar verwacht (bijvoorbeeld het aantal users tegelijkertijd, de verwachte read/write ratio's) en wie die applicatie gaat ontwikkelen (welke ervaring die mensen hebben). Daarna kan je dan proberen veel te lezen over de technologie-opties die er zijn, en te kijken hoe die mappen naar jouw applicatie en jouw mensen.

[kwaakvaak_v2]

Volgens moet je de vraag omdraaien, waarom zou de keuze van je een andere taal (of beter gezegd dialect) bepalend zijn voor het succes van je applicatie?

Dus ja je geeft zelf het antwoord al in je laatste zin

[Hydra]

kwaakvaak_v2 schreef op zondag 05 februari 2012 @ 12:58:
Dus ja je geeft zelf het antwoord al in je laatste zin

Dat is een beetje simpel. Een developer hier heeft ook wat perl scripts gebouwd voor een bepaalde taak. Op zich een prima keuze, ware het niet dat het verder in het bedrijf niet gebruikt wordt en het dus lastig is iemand te vinden die het kan onderhouden.

Omdat wij windows en linux ondersteunen is cross-platform een eis. Performance intensieve applicaties gaan in C++ en de rest in Java.

[Avalaxy]

Kijkend naar bijvoorbeeld PHP, C# (ASP.NET) en C++ (om maar eens een reeks uiteenlopende talen te pakken) dan zou ik PHP verkiezen voor hele kleine scripts die makkelijk te updaten moeten zijn (je hoeft immers niks te compileren, je gooit het op de webserver en het draait), ASP.NET (MVC) voor grote applicaties vanwege de veel betere debugmogelijkheden, betere editor, zeer goed in elkaar stekende libraries, de hogere performance, etc. C++ leent zich hier weer niet voor omdat het gigantisch veel tijd kost om een groot ERPpakket om maar iets te noemen te ontwikkelen met een dusdanig low-level taal.

Zo kun je voor een hoop talen wel argumenten bedenken

[ Voor 14% gewijzigd door Avalaxy op 06-02-2012 14:55 ]

[RobIII]

Waarom kiest een timmerman voor een hamer om een spijker in een balk te slaan en niet voor een schroevendraaier? Met een schroevendraaier lukt 't vast, op de duur, ook wel maar of je dan slim bezig bent is een tweede. Right tool for the right job.

Als je dan twee (of meer) tools "for the job" hebt (zoals, zeg, ASP.Net, PHP, Ruby, ...) dan kies je gewoon die die je 't best beheerst. Je kunt eventueel nog rekening moeten houden met licentievormen en ander "bureaucratisch" gedoe dat niet echt specifiek met de techniek te maken heeft; in zo'n geval neem je dat natuurlijk wel mee in je beslissing. Als je kunt kiezen tussen X en Y waarbij Y een restrictieve licentievorm heeft maar waarbij je Y wel beter beheerst kan 't toch gunstig zijn voor X te kiezen. Ook kies je soms voor product Z, ondanks een investering van 20k, simpelweg omdat je dat ontwikkelkosten bespaart (je zou er zelf 40k voor moeten spenderen om 'tzelfde te bereiken bijvoorbeeld) of omdat je zelf nooit de kwaliteit/robuustheid van Z zou kunnen evenaren (wie schrijft er nou zelf een RDBMS bijvoorbeeld?).

Het is niet zo zwart-wit als TS misschien denkt. Het is niet "if A then B else C". Er spelen een boel factoren mee en je kunt er geen "algemene stelregel" van afleiden anders dan "right tool for the right job"; hoe "right" die "tool" dan is ligt aan jezelf en andere externe factoren (budget, wens van de klant, beschikbaarheid van alternatieven, platformkeuze, etc. etc.)

[ Voor 14% gewijzigd door RobIII op 06-02-2012 16:04 ]

[kwaakvaak_v2]

Hydra schreef op maandag 06 februari 2012 @ 14:49:
[...]


Dat is een beetje simpel. Een developer hier heeft ook wat perl scripts gebouwd voor een bepaalde taak. Op zich een prima keuze, ware het niet dat het verder in het bedrijf niet gebruikt wordt en het dus lastig is iemand te vinden die het kan onderhouden.

Omdat wij windows en linux ondersteunen is cross-platform een eis. Performance intensieve applicaties gaan in C++ en de rest in Java.

Ja maar jullie zijn een bedrijf waar afspraken gelden, en de TS is alleen.. De enige afspraak die dan telt is dat de TS zelf de taal moet begrijpen en het dus niet zoveel uit maakt waar de app in gemaakt wordt. Er wordt te vaak. heel erg gewichtig gedaan over ontwikkelomgevingen, rekening gehouden met de meest succesvolle start-up/app ooit. Terwijl 9/10 nooit gaat pieken en dus alle problemen die geschetst worden nooit gaan halen.

Tuurlijk moet je beetje nadenken over een taal en schaalbaarheid, maar een applicatie wordt niet succesvoller als deze in PHP/ASP.NET, Perl of wat dan ook gemaakt wordt.

[Hydra]

kwaakvaak_v2 schreef op dinsdag 07 februari 2012 @ 08:19:
Ja maar jullie zijn een bedrijf waar afspraken gelden, en de TS is alleen..

De_Bastaard schreef op vrijdag 03 februari 2012 @ 21:46:
Nu vraag ik me echter af, waarop baseer ik (of anderen in het algemeen) nu wat voor taal ik ga gebruiken om zoiets te maken?

Daar geef ik antwoord op. Daarnaast is het voor hem net zo goed handig om bezig te gaan in een taal waar hij later wat aan heeft als de keuze toch niet echt uitmaakt. Mijn punt is dus dat in het bedrijfsleven, waar de TS later misschien in terecht komt, wel iets complexer is dan simpelweg "wat jij wil" maar dat veel developers dat zelf ook als ze in het bedrijfleven werken nog niet helemaal doorhebben.

[ Voor 26% gewijzigd door Hydra op 07-02-2012 08:41 ]

[De_Bastaard]

Het is niet zo dat ik er zwart/wit over denk, ik vroeg me gewoon af op basis waarvan men kiest voor een bepaalde taal. Ik wil mezelf gaan verdiepen in 'ontwikkeling' (en dan het liefst vooral webapplicaties met geocoding etc.), maar dat kan natuurlijk op 10 verschillende manieren.

Als ik dan weer hier op mijn werk dezelfde vraag stel, zegt bijv. iedereen je moet je site(s) maken in ASP en niet in PHP, want dat is een rommelige kindertaal. Vanzelfsprekend slaat dat argument natuurlijk nergens op, maar wordt dat argument aangehaald omdat men hier alles in .NET doet en de stap naar ASP.NET dan weer makkelijker is.

Zo hoor ik bijvoorbeeld ook iedereen zeggen dat je in PHP moeilijker object georienteerd kunt werken als in ASP.NET of Ruby. Aan de andere kant draait bijv. Facebook en andere grote sites wel op PHP dus dan vraag ik me af tot in hoeverre dat wel klopt

Wanneer wordt schaalbaarheid echt een probleem? Is dat wanneer je het niveau bereikt van Twitter of ga je dat toch al merken als je bijvoorbeeld een website maakt in combinatie met een android app waar enkele duizenden gebruikers mee werken?

Is er misschien een soort van guideline die je kunt aanhouden als je je idee op papier gaat uitwerken? Wil je meer van dit gebruiken dan moet je kijken naar taal-x, maar als je dan toch weer functionaliteit-b erbij wilt dan komt taal-b ook weer in zicht.

[Caelorum]

De_Bastaard schreef op dinsdag 07 februari 2012 @ 09:18:
[...] Aan de andere kant draait bijv. Facebook en andere grote sites wel op PHP dus dan vraag ik me af tot in hoeverre dat wel klopt [...]

Alleen een deel he.. Bij Facebook snappen ze het idee van de right tool for the right job wel. "Facebook’s backend services are written in a variety of different programming languages including C++, Java, Python, and Erlang." bron: http://www.makeuseof.com/...lts-technology-explained/
Je moet je in ider geval realiseren dat als je nu kiest voor een bepaald framework of taal je daar niet aan vast hoeft te blijven zitten.

[Avalaxy]

De_Bastaard schreef op dinsdag 07 februari 2012 @ 09:18:

Als ik dan weer hier op mijn werk dezelfde vraag stel, zegt bijv. iedereen je moet je site(s) maken in ASP en niet in PHP, want dat is een rommelige kindertaal. Vanzelfsprekend slaat dat argument natuurlijk nergens op,

Muah, PHP is wel degelijk rommeliger dan ASP.NET MVC of iets dergelijks hoor! Zelfs met frameworks die proberen om PHP's beperkingen heen te werken.

Zo hoor ik bijvoorbeeld ook iedereen zeggen dat je in PHP moeilijker object georienteerd kunt werken als in ASP.NET of Ruby. Aan de andere kant draait bijv. Facebook en andere grote sites wel op PHP dus dan vraag ik me af tot in hoeverre dat wel klopt

Het klopt wel, ze zijn met PHP begonnen, maar daar hebben ze gewoon een fout gemaakt. Wat ze nu doen: ze hebben HipHop ontwikkeld waarmee ze hun PHP omzetten naar C++ omdat PHP gewoon te traag is.

[flowerp]

De_Bastaard schreef op vrijdag 03 februari 2012 @ 21:46:
Gebruikt iedereen PHP omdat het (volgens velen) vrij toegankelijk is voor nieuwelingen en omdat je er veel van kan leren, of kies je juist voor iets anders zoals RubyOnRails omdat dat "misschien" beter om kan gaan met scaling of iets anders?

Niet om het een of ander, maar RoR staat er juist bekend om om niet zo goed te schalen. Rails is absoluut een mooi platform en dat blijkt ook uit dat meerdere andere platforms (zoals b.v. Java EE/JSF) dingen eruit heeft overgenomen.

Probleem is dat Ruby traag, traag, traag is. Staat PHP al niet bekend om een snelheidsmonster te zijn vergeleken met C/C++/Java/C#, dan is Ruby meestal nog eens even net een tikkeltje trager.

De volgende benchmark is indicatief hiervoor: http://shootout.alioth.de...languages-are-fastest.php (let op, dit zijn slechts benchmarks en real-world usage kan anders uitpakken). Meer op real-world gebruik gebaseerd zijn de verhalen van Twitter die ondanks een massive engineering effort het gewoon niet snel en goed schaalbaar hebben kunnen krijgen. Uiteindelijk zijn ze op Java overgestapt.

Natuurlijk zit je niet zomaar op het niveau Twitter, maar Ruby is dus zeker NIET per definitie schaalbaar. Ook is Ruby helemaal niet zo populair in vergelijking met hoe vaak het genoemd wordt in blogs en fora zoals deze. Ter indicatie: http://www.tiobe.com/inde...paperinfo/tpci/index.html (andere bronnen, zoals aangeboden banen laten ongeveer een zelfde beeld zien).

Maar goed wat dan wel?

PHP is zoals reeds vermeldt ook vrij langzaam en is zowel als taal als platform vrij rommelig opgezet, en is ook al een poosje flink aan het dalen in populariteit. Wel is dit nog steeds -het- platform waarop je eenvoudige
homepage achtige sitjes kunt laten bouwen door tal van goedkope webbedrijfjes. Open source en cheap (shared) hosting zijn de kern woorden hier.

Denk alleen niet dat je zo'n goedkoop webbedrijfje even een complex platform kan laten bouwen (ala Tweakers, Facebook, Marktplaats, etc).

ASP.NET/C# is een platform dat zich duidelijk meer richt op de professionele markt. Veel grote bekende merken hebben hun site op dit platform draaien. ASP.NET/MVC zit vrij goed in elkaar en de IDE support is zeer goed omdat deze door Microsoft hand in hand met het platform ontwikkeld wordt. In de C-style familie wordt C# als 1 van de beste talen gezien. De bekende C syntax, met veel moderne features (voor imperatieve talen) als clossures, linq, reified (echte) generics, etc.

Het grote nadeel van ASP.NET/C# is dat het alleen op Microsoft platformen draait. Goedkope hosting kun je vergeten en zelfs bij zelf hosten moet je nog de license voor het OS betalen. Ook is het niet open source, wat inovatie door derden tegenwerkt en debuggen bemoeilijkt. Ik heb tenminste vaak gescholden als er een wazige error melding terug komt en je niet even in de source kunt kijken onder welke condities die nu precies gegenereerd wordt. Om deze reden is er misschien ook wat minder een "blogosphere' om ASP.NET heen.

Dan is er nog Java/Java EE. De taal Java is al een ruim decennia de absolute nummer 1 (wel continu dalend, dus de vraag is voor hoe lang nog). Het Java platform is er 1 van grote tegenstrijdigheden. Zo staat Java in de volksmond bekend als traag, terwijl het in de regel juist 1 van de snelste moderne talen is. Voor puur number crunching winnen C en C++ het nog wel, maar het verschil is opvallend klein. Deze opvatting komt van de oude applets en trage desktop apps die het 'volk' kent, maar dit speelt op de server absoluut niet.

De standaard library voor web en server toepassingen (Java EE, voorheen J2EE), stond bekend als prijzig, heavyweight en closed source. Dit omdat het rond 2004 partijen als IBM waren die gedrochten aanboden van 1GB install size waar duizenden voor betaald moest worden en die er tientallen minuten(!) over deden om op te starten. Tegenwoordig download je echter GlassFish, TomEE, Resin, of JBoss AS. Download size tussen de 25 en 100MB. Volledig open source en start in enkele seconden op. De oude vooroordelen zijn dus absoluut niet meer waar.

De API van Java EE is tegenwoordig erg elegant. Het web framework (JSF) lijkt wat op ASP.NET, maar waar ASP.NET iets gebruikt dat meer op het oude JSP/ASP lijkt, gebruikt JSF de moderne templating engine Facelets. Wel heeft ASP.NET dan weer ASP.NET MVC, waar Java EE met JSF en JAX-RS slechts gedeeltelijk een antwoord op heeft.

C# is ooit begonnen als een nauwelijks van Java te onderscheiden Java-clone, maar heeft ondertussen veel meer interessante features in zich opgenomen, waar Java als taal (niet als platform!) toch wel lang heeft stilgestaan.

Voor Java is ondertussen ook veel gratis/goedkope hosting te krijgen (in de regel cloud gebasseerd), zoals GAE en OpenShift.

Het grote nadeel van Java is en blijft de grote interne fragmentatie. Bij ASP.NET huur ik een ASP.NET developer en die gaat dan ASP.NET dingen bouwen. Er is hooguit de discussie VB.net vs C#, maar die is toch wel grotendeels beslecht nu in het voordeel van C#. Als je echter 'gewoon' een Java developer huurt, weet je nooit wat je krijgt. Het kan een fanatieke Spring aanhanger zijn die volledig over de rooie gaat bij het horen van de term "EJB", maar het kan ook een Wicket zealot zijn die juist weer helemaal gek wordt als hij Spring MVC moet doen. Etc.

Waarop baseer je zoiets?

Of is het zoals ik eigenlijk verwacht, je kiest de taal waar je zelf verstand van hebt ... en gaat daarvoor ....

Dat gebeurd inderdaad vaak ja. Samengevat van bovenstaande (lange) verhaal zijn de keuzen: volwassenheid taal, platform en IDE, performance, beschikbaarheid developers, hosting opties, open source / gratis beschikbaar en nog niet genoemd; wat is gebruikelijk in het segment waar je iets voor gaat ontwikkelen?

B.v. NoSQL en Search wordt momenteel grotendeels gedomineerd door Java. Als je iets wilt bouwen wat hier direct op aansluit ben je gek als je PHP gaat gebruiken. Aan de andere kant, CMS, fora en blog systemen worden volledig gedomineerd door PHP. In de UK draaien banken enorm vaak Java/Spring. Wil je iets in die sector doen, dan is dat waarschijnlijk geen slechte keuze, etc etc.

[Caelorum]

Een mooie post maar wil toch nog even op het volgende reageren:

De_Bastaard schreef op vrijdag 03 februari 2012 @ 21:46:
[...] Het grote nadeel van ASP.NET/C# is dat het alleen op Microsoft platformen draait. Goedkope hosting kun je vergeten en zelfs bij zelf hosten moet je nog de license voor het OS betalen. Ook is het niet open source, wat inovatie door derden tegenwerkt en debuggen bemoeilijkt. Ik heb tenminste vaak gescholden als er een wazige error melding terug komt en je niet even in de source kunt kijken onder welke condities die nu precies gegenereerd wordt. Om deze reden is er misschien ook wat minder een "blogosphere' om ASP.NET heen.[...]

Waar WebForms wellicht niet opensource is is ASP.net MVC dat wel. Daarnaast is de C# language specification gewoon vrij verkrijgbaar en kan je ASP.net WebForms (en MVC) websites/apps gewoon hosten met mono, apache en mod_mono onder linux.
Je kan dus gewoon C# + asp.net dus gebruiken in een volledig opensource omgeving.
Enige nadeel hieraan is dat je geen support krijgt vanuit MS.

[flowerp]

Caelorum schreef op dinsdag 07 februari 2012 @ 13:51:
Een mooie post maar wil toch nog even op het volgende reageren:

[...]

Waar WebForms wellicht niet opensource is is ASP.net MVC dat wel.

Klopt, ASP.NET MVC is dat inderdaad wel. Vroeger op de desktop was van MFC overigens ook al de source meegeleverd (was niet officieel open source), dus MS kan het wel.

Daarnaast heb je nu de diverse express edities van VS, die het geheel toch een stuk aantrekkelijk maken voor de beginner. Toch kom je vaak uit op een lager gedeelte van ASP.NET waar je dan niet meer verder kan debuggen. Ik ben zelf toch meer voorstander van dat je *overal* in kunt steppen als dat nodig is.

Daarnaast is de C# language specification gewoon vrij verkrijgbaar en kan je ASP.net WebForms (en MVC) websites/apps gewoon hosten met mono, apache en mod_mono onder linux.

Mwoahh... mono werkt super voor gewoon applicaties direct voor Linux ontwikkelen, maar ik zou het niet gebruiken voor ASP.NET applicaties. Ik moet toegeven dat ik het al een poosje niet meer geprobeerd hebt, maar het liep destijds altijd behoorlijk achter en een hele snelle blik lijkt erop te wijzen dat dit nu nog steeds zo is. Als prototype zo even snel tussendoor, okay. Maar ik zou er geen productie op durven te draaien.

Enige nadeel hieraan is dat je geen support krijgt vanuit MS.

Support is niet iets wat ik nodig heb, maar het moet wel gewoon allemaal draaien zonder extra instabiliteit en bugs. Vooralsnog heb ik niet de indruk dat Mono + ASP.NET (laatste versies) een goede combinatie is. Heb jij hier wel ervaring mee?

[Caelorum]

flowerp schreef op dinsdag 07 februari 2012 @ 14:06:
[...]Support is niet iets wat ik nodig heb, maar het moet wel gewoon allemaal draaien zonder extra instabiliteit en bugs. Vooralsnog heb ik niet de indruk dat Mono + ASP.NET (laatste versies) een goede combinatie is. Heb jij hier wel ervaring mee?

Persoonlijk niet, maar als ik kijk wat voor sites (bijv. developer.mozilla.org) er wel gebruik van maken zou ik mij niet zo heel veel zorgen maken over onoverkoombare instabiliteit. Daarentegen is het wel zo dat zij natuurlijk meer ontwikkelkracht hebben om eventuele bugs zelf op te lossen.

[flowerp]

Caelorum schreef op dinsdag 07 februari 2012 @ 14:43:
[...]

Persoonlijk niet, maar als ik kijk wat voor sites (bijv. developer.mozilla.org) er wel gebruik van maken zou ik mij niet zo heel veel zorgen maken over onoverkoombare instabiliteit. Daarentegen is het wel zo dat zij natuurlijk meer ontwikkelkracht hebben om eventuele bugs zelf op te lossen.

Het is wel een interessante keuze toch. Wikipedia zegt er momenteel dit over:

"The Mono Project supports "everything in .NET 4.0 except WPF, EntityFramework and WF, limited WCF"
Zie: Wikipedia: ASP.NET

Misschien moet ik het toch weer eens proberen

[Hydra]

flowerp schreef op dinsdag 07 februari 2012 @ 13:21:
Het grote nadeel van Java is en blijft de grote interne fragmentatie. Bij ASP.NET huur ik een ASP.NET developer en die gaat dan ASP.NET dingen bouwen. Er is hooguit de discussie VB.net vs C#, maar die is toch wel grotendeels beslecht nu in het voordeel van C#. Als je echter 'gewoon' een Java developer huurt, weet je nooit wat je krijgt. Het kan een fanatieke Spring aanhanger zijn die volledig over de rooie gaat bij het horen van de term "EJB", maar het kan ook een Wicket zealot zijn die juist weer helemaal gek wordt als hij Spring MVC moet doen. Etc.

Komt nog eens bij dat recruiters er al helemaal geen hout van snappen. Ik heb "Java" ervaring op m'n CV staan. Ondertussen ben ik niet echt een developer meer maar heb meer een commerciele rol, maar het is me wel duidelijk geworden dat je Java ervaring dan kennelijk gewoon van je CV moet halen want ik krijg nu vooral Java en .Net baantjes aangeboden. Ze snappen dus al niks van je huidige functie, laat staan de verschillende nuances binnen een platform.

[flowerp]

Hydra schreef op dinsdag 07 februari 2012 @ 15:51:
[...]


Komt nog eens bij dat recruiters er al helemaal geen hout van snappen.[...] Ze snappen dus al niks van je huidige functie, laat staan de verschillende nuances binnen een platform.

En om recruiters helemaal gek te maken, het leuke verschil in Java tussen specificatie en implementatie van een techniek. Hoe vaak ik al niet met een recruiter aan tafel heb gezeten om het verschil uit te leggen tussen b.v. JSF, MyFaces, Mojarra, of Java EE en JBoss AS.

En dan uiteindelijk zegt ie het te snappen, en dan zie je de uiteindelijke vacature en dan staat het er NOG fout in Dan is MyFaces ervaring opeens vereist en is JSF ervaring een pre geworden

[De_Bastaard]

Zo dan bedankt voor de verhelderende reacties vandaag, vooral flowerp !

Mijn intentie was niet om hier een topic te starten over 'wat moet ik leren', maar het is me nu wel duidelijker geworden wat ik waarvoor kan gebruiken en ook wat waar de nadelen van zijn. Nu nog maar eens goed in kaart brengen wat ik exact wil maken en wat dit voor eisen zou stellen aan reactietijd, en dan kan ik daar wellicht op gaan baseren hoe ik m'n product ga ontwikkelen. Dat maakt het dan ook een stuk makkelijker om ergens mee te beginnen in plaats van het dilemma dat ik nu heb dat ik ongeveer wel weet wat ik wil, maar dat ik totaal geen idee heb waar ik zoiets nu in wil maken (het zou volgens mij namelijk wel in elke taal kunnen).

Uiteraard denk ik dat het vanuit carriere-technisch oogpunt het makkelijkst zou zijn om me bezig te houden met Java en/of .NET, omdat daar in de zakenwereld meer mee gewerkt wordt. Maken van kleine sites is niet mijn ding, en ik zie dan ook niet zo heel veel heil in het leren van PHP.

Had overigens geen benul ervan dat PHP en Ruby zo traag waren, bedankt daarvoor :-)

[YopY]

mbt de snelheid van een taal: Ten eerste zijn er genoeg quick wins te behalen door het toevoegen van opcode en memory caches of door het naar C++ te compilen. Ten tweede, het ligt er maar net aan wat je nodig hebt. Een belangrijke factor in het taal vs performance verhaal is hoe snel kun je een product neerzetten.

Je kunt een belachelijk goed performende webservice / applicatie in Scala of C++ schrijven die 100 miljoen miljard requests per seconde kan afhandelen, maar als je maar 100 requests / uur krijgt heb je dus die vijf jaar van je leven voor niks en een imposante blogpost opgeofferd.

Een factor is dus ook ontwikkeltijd versus gewenste performance. RoR wordt wel gebruikt voor rapid prototyping; binnen een dag kun je een werkende webapplicatie in elkaar schroeven die desnoods productierijp is. Als je website vervolgens populair wordt kun je er alsnog voor kiezen om delen van je systeem te herschrijven in een meer performante taal / omgeving.

[ZpAz]

Denk alleen niet dat je zo'n goedkoop webbedrijfje even een complex platform kan laten bouwen (ala Tweakers, Facebook, Marktplaats, etc).

Dat ligt hem meer aan het bedrijf dan de taal. Van Facebook weet ik dat ze PHP gebruiken, van Marktplaats verwacht ik het, maar Tweakers.net niet. Dus of je voorbeeld het beste voorbeeld is.

En true, Facebook heeft allemaal truukjes om hun site sneller te laten lopen, maar al hadden ze het in Python gemaakt (wat ze ook gebruiken) of Java (wat ze ook gebruiken) dan hadden ze alsnog allerlei dingen toegepast om te schalen op zo'n hoog niveau.

[creator1988]

ZpAz schreef op woensdag 08 februari 2012 @ 11:29:
[...]


Dat ligt hem meer aan het bedrijf dan de taal. Van Facebook weet ik dat ze PHP gebruiken, van Marktplaats verwacht ik het, maar Tweakers.net niet. Dus of je voorbeeld het beste voorbeeld is.

En true, Facebook heeft allemaal truukjes om hun site sneller te laten lopen, maar al hadden ze het in Python gemaakt (wat ze ook gebruiken) of Java (wat ze ook gebruiken) dan hadden ze alsnog allerlei dingen toegepast om te schalen op zo'n hoog niveau.

Marktplaats is van PHP naar Java overgegaan (of zijn nog bezig met de transitie).

[flowerp]

ZpAz schreef op woensdag 08 februari 2012 @ 11:29:
[...]
Dat ligt hem meer aan het bedrijf dan de taal. Van Facebook weet ik dat ze PHP gebruiken, van Marktplaats verwacht ik het, maar Tweakers.net niet. Dus of je voorbeeld het beste voorbeeld is.

Wat ik primair bedoelde is dat je die goedkope PHP webbedrijfjes "van om de hoek" meestal niet kan inzetten om zo'n platform te ontwikkelen (ook niet als je ze voor langere tijd inhuurt). Deze zijn alleen gespecialiseerd en in het opleveren van eenvoudige homepage dingen voor clubs enzo.

Daarnaast, Facebook gebruikt PHP ja, maar is allang al niet meer gebouwd op PHP. Waar denk je b.v. dat Cassandra vandaan komt? Naast een keur van technieken wordt vrij veel Java gebruikt voor performance kritische dingen.

creator1988 schreef op woensdag 08 februari 2012 @ 17:29:
[...]
Marktplaats is van PHP naar Java overgegaan (of zijn nog bezig met de transitie).

Ze zijn waarschijnlijk nog bezig, we werden niet zo gek lang geleden nog opgebeld door een recruiter

Wel is dit mooi een voorbeeld van de fragmentatie van Java, want welke Java technieken marktplaats ging inzetten verschillende nog al eens. Spring, JSF, Wicket, Play! het kwam allemaal wel eens voorbij.

Iemand die weet wat het nu concreet geworden is?

[creator1988]

flowerp schreef op woensdag 08 februari 2012 @ 23:48:
Ze zijn waarschijnlijk nog bezig, we werden niet zo gek lang geleden nog opgebeld door een recruiter

Wel is dit mooi een voorbeeld van de fragmentatie van Java, want welke Java technieken marktplaats ging inzetten verschillende nog al eens. Spring, JSF, Wicket, Play! het kwam allemaal wel eens voorbij.

Iemand die weet wat het nu concreet geworden is?

Ik zal het eens vragen als ik weer eens langs loop daar.

[BikkelZ]

Hydra schreef op dinsdag 07 februari 2012 @ 15:51:
[...]


Komt nog eens bij dat recruiters er al helemaal geen hout van snappen. Ik heb "Java" ervaring op m'n CV staan. Ondertussen ben ik niet echt een developer meer maar heb meer een commerciele rol, maar het is me wel duidelijk geworden dat je Java ervaring dan kennelijk gewoon van je CV moet halen want ik krijg nu vooral Java en .Net baantjes aangeboden. Ze snappen dus al niks van je huidige functie, laat staan de verschillende nuances binnen een platform.

Zo staan classic ASP en ColdFusion gewoon niet meer op mijn CV. Een goed CV is na de eerste tien jaar van je carrière vooral een kwestie van de juiste dingen er niét op te zetten

[Kajel]

Avalaxy schreef op dinsdag 07 februari 2012 @ 12:19:
[...]


Muah, PHP is wel degelijk rommeliger dan ASP.NET MVC of iets dergelijks hoor! Zelfs met frameworks die proberen om PHP's beperkingen heen te werken.

"Proberen om PHP's beperkingen heen te werken" -> Totaal subjectieve nonsense. PHP 5.3 is heel netjes object georienteerd. Uiteraard kun je er nog steeds lelijke puur procedurele code in schrijven, maar dat kan in C++ en Python bv ook. Punt is dat PHP zich in de huidige vorm prima leent om goede OO principes mee te verwezenlijken.
PHP heeft ook een hoop nadelen, en .NET MVC "forceert" je out-of-the-box veel meer om OO te programmeren, maar dat brengt weer een heel zwik nieuwe mogelijke anti-patterns met zich mee Frameworks als Zend en zeker Symfony2 proberen niet om PHP's beperkingen heen te werken, ze zijn ontzettend krachtige tools in their own right, om goede webapplicaties mee neer te zetten.

[...]


Het klopt wel, ze zijn met PHP begonnen, maar daar hebben ze gewoon een fout gemaakt. Wat ze nu doen: ze hebben HipHop ontwikkeld waarmee ze hun PHP omzetten naar C++ omdat PHP gewoon te traag is.

Als ze zelf het gevoel hadden gehad een fout gemaakt te hebben met PHP, dan hadden ze het wel helemaal uit hun systeem gesloopt. Feit is, dat Facebook in den beginne 100% PHP was, maar dat ze inderdaad tegen de restricties van PHP zijn aangelopen, en steeds meer backend services in andere talen zijn gaan implementeren. Toch is PHP gebleven om precies dat te doen waar het oorspronkelijk voor gemaakt is, en ook nog prima voor voldoet: als templating engine.

Overigens doet Twitter precies hetzelfde met Ruby. Dat gebruiken ze ook nog steeds voor de "frontend" omdat het flexibel is.

Ik denk dat veel mensen vergeten dat de keuze van taal ook echt van de schaal afhangt. In PHP i.c.m. een framework of in RoR ontwikkel je gewoon razendsnel. Als je vervolgens geen miljoenen gebruikers bij launch verwacht, kun je door gebruik van deze platformen ontzettend snel tot je eindproduct komen, zonder je zorgen te hoeven maken over performance.
Word je applicatie alsnog razend populair, dan ga je langzaam aan delen vervangen door in andere talen geschreven oplossingen. Als je PHP/RoR app goed modulair is opgezet, kan dat prima.

[Hydra]

Kajel schreef op maandag 20 februari 2012 @ 11:08:
Word je applicatie alsnog razend populair, dan ga je langzaam aan delen vervangen door in andere talen geschreven oplossingen. Als je PHP/RoR app goed modulair is opgezet, kan dat prima.

Komt nog eens bij dat de bottlenecks vaak in de backend zitten. Je kunt vrij simpel de frontend code intact laten (helemaal als de meeste meuk uit webservices opgehaald wordt) en de backend schaalbaarder maken.

[Kajel]

Hydra schreef op maandag 20 februari 2012 @ 11:45:
[...]


Komt nog eens bij dat de bottlenecks vaak in de backend zitten. Je kunt vrij simpel de frontend code intact laten (helemaal als de meeste meuk uit webservices opgehaald wordt) en de backend schaalbaarder maken.

Exact! Zolang je je backend (die wellicht in eerste instantie in PHP geschreven is) bv RESTful opzet, dan kun je later prima datzelfde backend in Java bouwen, en je frontend PHP code intact laten

edit: het is overigens zo, dat de meeste applicaties geen baat hebben bij HipHop for PHP, omdat de verwerkingssnelheid & CPU-load van PHP niet de bottleneck is. Dus wat Facebook gedaan heeft, is meestal niet eens nodig.

[ Voor 17% gewijzigd door Kajel op 20-02-2012 12:00 ]

[Hydra]

Kajel schreef op maandag 20 februari 2012 @ 11:59:
Exact! Zolang je je backend (die wellicht in eerste instantie in PHP geschreven is) bv RESTful opzet, dan kun je later prima datzelfde backend in Java bouwen, en je frontend PHP code intact laten

Yup. Het is natuurlijk wel belangrijk om hierover van te voren een beetje na te denken. Frontend en backend netjes gescheiden houden kost ook veel minder tijd dan veel mensen denken.

edit: het is overigens zo, dat de meeste applicaties geen baat hebben bij HipHop for PHP, omdat de verwerkingssnelheid & CPU-load van PHP niet de bottleneck is. Dus wat Facebook gedaan heeft, is meestal niet eens nodig.

Ik denk dat ze het daar ook vooral doen omdat het zo groot is dat het aantal servers een significant onderdeel van je uitgaven is. Als je 10% CPU bespaart op je frontend servers kan je met 10% minder servers toe. Als je een website hebt met 3 bezoekers per dag op 1 server is dat een stuk minder een issue, daar zijn de kosten aan development een veel grotere post relatief gezien.