'Ruby on Rails serieuze bedreiging voor Java'

Gisteren verzamelden ontwikkelaars en fans van het ontwikkeplatforum Ruby on Rails zich in een onderzoekscentrum van IBM voor het Ruby on Rails Camp. De bezoekers van deze conferentie waren het over een ding eens: Java heeft een serieuze concurrent in de vorm van Ruby on Rails. De 150 bezoekers van de conferentie vergeleken tijdens de bijeenkomst RoR op diverse onderdelen met Java, waarbij volgens hen de nieuwe telg op het gebied van webapplicatie-ontwikkeling duidelijke voordelen biedt ten opzichte van Java.

Of het daadwerkelijk zo'n vaart loopt valt nog te bezien. Ruby on Rails is pas sinds eind vorig jaar beschikbaar in een stabiele 1.0-versie en heeft nog een duidelijke achterstand in marktaandeel. Ook op technische punten lijkt Java nog niet volledig te zijn verslagen door het op Ruby-gebaseerde ontwikkelplatform. Wel zijn veel ontwikkelaars het er over eens dat Ruby on Rails een lagere instapdrempel heeft en sneller tot bruikbaar resultaat leidt. Het idee achter Ruby on Rails is dat met zo min mogelijk programmeercode zo veel mogelijk wordt bewerkstelligd. Om dit te realiseren wordt zoveel mogelijk voorkomen dat men programmacode dupliceert. Automatische OR-mapping zorgt ervoor dat er weinig programmacode hoeft te worden gebruikt om databases te benutten. Ook hoeft de ontwikkelaar zich nauwelijks zorgen te maken over de verwerking van HTTP-request, omdat ook dit vrijwel automatisch gebeurt.

Nadelen heeft de aanpak van Ruby on Rails ook, zo blijkt wanneer Infoworld doorvraagt aan de bezoekers van Ruby on Rails Camp. Zo vergen applicaties die in Ruby on Rails zijn ontwikkeld duidelijk meer resources dan een vergelijkbare applicatie in Java. Dit probleem is volgens Ruby-programmeurs echter onbelangrijk omdat de ontwikkeltijd van een RoR-applicatie duidelijk lager is en de extra kosten voor rekencapaciteit minder zijn dan de kosten voor de extra ontwikkeltijd die een Java-applicatie vergt. Een probleem waarvoor nog geen pasklare oplossing is, betreft het ontbreken van een standaard veiligheidsmodel in Ruby on Rails, zo melden de conferentiebezoekers. Alle beveiligingfeatures in Ruby on Rails moeten handmatig worden geprogrammeerd, wat potentiële veiligheidsfouten in de hand werkt. Toch lijkt er een mooie toekomst voor het framework te zijn weggelegd. Bedrijven zoals IBM investeren al flink in Ruby on Rails-projecten. 'Big Blue' gebruik RoR onder andere voor Koala, een Wikipedia-achtig systeem voor bedrijfsprocessen.

Reacties (79)

[Petok]

Zo vergen applicaties die in Ruby on Rails zijn ontwikkeld duidelijk meer resources dan een vergelijkbare applicatie in Java. Dit probleem is volgens Ruby-programmeurs echter onbelangrijk omdat de ontwikkeltijd van een RoR-applicatie duidelijk lager is en de extra kosten voor rekencapaciteit minder zijn dan de kosten voor de extra ontwikkeltijd die een Java-applicatie vergt.
Hoe kan je de resources die het programma verbruikt vergelijken met de tijd die het kost om het te maken? (Ik vind dit niet echt een argument, kan liggen aan mijn beginnende-programmeur-ervaringen)

[intoxicated]

Dat is wel degelijk een argument

Talloze manuren extra aan programmeerwerk kosten een opdrachtgever vaak aanzienlijk meer dan wat extra servers. Al met al kan het dan zeker wel voordelig zijn om te kiezen voor een framework dat programmeerwerk bespaart maar wat meer resources kost.

[Titusvh]

Daar staat tegenover dat het grootste deel van de extra ontwikkelkosten eenmalig is, en de extra kosten voor resources gedurende de hele levensduur van de applicatie.

Vaak gaat een applicatie langer mee dan hardware.

[Wilke]

Daar staat tegenover dat het grootste deel van de extra ontwikkelkosten eenmalig is, en de extra kosten voor resources gedurende de hele levensduur van de applicatie.

Het tegenovergestelde is ook goed te verdedigen:

Een goed werkende applicatie wordt vrijwel altijd uitgebreid qua functionaliteit, bugs moeten gefixed, zooi moet onderhouden worden (kleine wijzigingen), etc. Ontwikkelingskosten zijn dus vrijwel nooit echt "eenmalig".

De aanschaf van een paar extra servers is daarentegen juist wel eenmalig (ok, de stroomkosten en rackspace inderdaad niet).

De vraag is dus net hoe die balans uitvalt, en zonder echte metingen/cijfers over al dat soort dingen (hoeveel meer servers, hoeveel minder tijd in de ontwikkeling, onderhoud, blahblahblah) kunnen we daarover lang of kort praten, maar het blijft borrelpraat (niks mis mee op vrijdagavond overigens ).

Bovendien kun je net als bij Java verwachten dat als het platform doorbreekt, er vroeg of laat wel wat geld tegen het verbeteren van de bytecode interpreter aangesmeten wordt (ja, ook Ruby wordt eerst gecompileerd naar een of andere bytecode). Dus dan heb je gratis betere performance, net als Java 1.5 t.o.v. eerdere versies.

Een andere vraag is of het onderhouden van Ruby (on Rails) applicaties ook daadwerkelijk minder tijdrovend is dan bij Java. Minder code-duplicatie is geweldig, maar met al die frameworks gebaseerd op metaprogramming kan aardig ondoorzichtig worden wat er nou uiteindelijk precies gebeurt.
Maar goed, dat zeiden mensen vroeger ook over OO ("hoe weet je dan welke methode uiteindelijk aangeroepen wordt als een subclass die kan overriden!?"), wie weet is het een kwestie van wennen aan hoe het werkt.

[YopY]

Een andere vraag is of het onderhouden van Ruby (on Rails) applicaties ook daadwerkelijk minder tijdrovend is dan bij Java.

Volgens mij ligt dat helemaal aan de programmeur zelf. Ik bedoel, RoR is gemaakt volgens het DRY-principe, waar het de bedoeling is dat niets herhaald word, en je dus als je iets wilt veranderen het maar op één plek in de hele applicatie hoeft te doen.

Volgens mij kun je met Java ook wel goed zo'n soort applicatie(framework) maken, ze zijn er zelfs mee bezig (heb ik gehoord), weet echter niet of die ook goed te vergelijken valt met RoR.

[Barend]

Al met al kan het dan zeker wel voordelig zijn om te kiezen voor een framework dat programmeerwerk bespaart maar wat meer resources kost.

Daar ben ik het volstrekt mee eens. We moeten ook vooral niet vergeten dat Java zelf zo'n framework is.

Helaas schalen servers ook niet onbeperkt. Op het moment dat je meer dan één doos nodig hebt neemt de complexiteit zo'n enorme sprong dat het allemaal al een stuk ingewikkelder wordt. De problemen zijn zeker overkomelijk, maar de Ruby community stapt daar wel erg gemakkelijk overheen.

Ontwikkelen zonder compiler-checked types is in mijn ogen net zoiets als ontwikkelen zonder ontwikkelproces, ontwikkelen zonder SCM, ontwikkelen zonder acceptatieprocedure; zelf je huis verbouwen, een artikel schrijven zonder eindredacteur...

...tot een bepaalde systeemomvang gaat het goed, en daarna valt het in duigen. (en don't get me wrong: met weak typing hou je het aanmerkelijk langer vol dan zonder SCM).

Ik denk daarom dat Ruby, zoals ook door anderen genoemd, voor een bedreiging is voor PHP en eventueel de onderkant van de markt in .NET en Java. Voor grootschaliger applicaties zal het nauwelijks worden toegepast.

Het is absoluut zo dat Java en .NET het een en ander van Ruby kunnen, ja, moeten leren. Dat proces is in volle gang.

[arjankoole]

Helaas schalen servers ook niet onbeperkt. Op het moment dat je meer dan één doos nodig hebt neemt de complexiteit zo'n enorme sprong dat het allemaal al een stuk ingewikkelder wordt. De problemen zijn zeker overkomelijk, maar de Ruby community stapt daar wel erg gemakkelijk overheen.

Dat valt best mee. wij gebruiken RoR met mongrel en dat maakt het schalen over meerdere servers heen heel makelijk, omdat je op 1 server al direct meerdere mini servertjes gebruikt. Die boel knoop je met mod_balancer weer aan elkaar. (Mongrel is niet goed in multithreaded / veel concurrent sessies werk zoals apache, dus voor een beetje webapp heb je direct al 3 mongrel instanties nodig)

Ik denk dat RoR juist heel schaalbaar is in combinatie met mongrel en apache.

[Anoniem: 168910]

Maar dan is het natuurlijk wel belangrijk dat de winst die er per pageview gemaakt is, of tenminste het budget in verhouding staan.

Er is een reden dat de front-page van Google met een in C geschreven module in apache is ingebakken door hun. En dan zal weinig te maken hebben met maintainability of 'programmer-friendly-ness'

Hun gemiddelde winstmarge per page view is laag, dus de kosten (stroom en bandbreedte) moeten zo laag mogelijk zijn. Of dat nou 3 of 100 programmeurs kost maakt in hun geval niet zoveel uit.

RoR is dan vooral leuk voor de emancipatie van community sites, webshops en niche-dienst-verleners. En misschien dat het juist daarom een concurrent voor Java is. Java is ook niet echt de meest performance friendly en wordt vooral gebruikt voor interne websites en low-traffic websites waar de site gekoppeld moet zijn aan een al bestaande achterliggende infrastructuur.

[Anoniem: 141802]

Mijn ervaring is dat de ervaring en deskundigheid van de programmeur van grotere invloed is op de snelheid van het uiteindelijke 'programma' dan de taal waarin hij de code schrijft.

Zelf programmeer ik ook in Ruby (http://code.google.com/p/rubyripper/) en ik moet zeggen dat het super werkt. Omdat ik de code eenvoudiger leesbaar vind dan talen als Python, Perl of Java is het optimaliseren van de code ook eenvoudiger en dus sneller.

Het is waar dat je soms tegen factoren oploopt waaruit blijkt dat de taal nog jong is, maar aan de andere kant is de ruby community zeer behulpzaam ingesteld. Een workaround (of zelfs een fix in de Ruby code zelf) is meestal zo gevonden.

[Anoniem: 168910]

Het gaat om maximaal rendement voor minimale kosten.
Een front-site van google is geschreven in C, omdat in hun geval resources de bottleneck zijn.

Voor een internetshop met maximaal 10.000 pageviews per dag zijn de ontwikkel en beheer kosten van de site de bottleneck: niet de bandbreedte, noch de CPU/stroom belasting.

Google verdient aan elke pageview gemiddeld misschien maar een cent. Het is dus belangrijk dat ze aan stroom en bandbreedte kosten minder dan die cent kwijt zijn om die pagina aan je te tonen.

Een webshop verdient aan elke pageview gemiddeld een euro (1 op de 100 bezoekers koopt er een laptop van 1400 euro, waar 200 euro winst op zit). Stroom en bandbreedte zijn in dit geval de kosten niet. De site ontwikkel en beheer kosten zijn dat wel, want in totaal verkopen ze misschien maar 1 laptop per dag.

[jip_86]

Ze bedoelen dat de kosten voor een betere machine met meer rekencapaciteit lager zijn dan de extra tijd die het kost om een java applicatie te maken.

[Remus]

Dat geldt misschien voor een one-off project, maar niet voor een product dat bij veel klanten ingezet gaat worden. Dan lopen de kosten voor hardware (voor de klant, niet voor de ontwikkelaar) toch al snel op.

[i-chat]

sterker nog dat geld niet eens bij een enkel project,
misschien als je een project je maakt voor 50users,

maar de meeste java webaplicaties worden gemaakt voor grotere aantallen,

is het voor een bedrijfs aplicatie dan zal het voor de server niet zo erg zijn dat je 4 in plaats van 2 cpu's nodig hebt,

maar ga je dan weer praten over hosted servers, dan word't verhaal wel weer heel anders aangezien je dan waarschijnlijk ook weet hogere servers nodig hebt... en dus een stukje meer kwijt bent... -

dan is enkele tientallen euro's per server per maand zo terug verdiend door de paar extra programmeer uurtjes..

[Brent]

Omdat je alles uiteindelijk uitdrukt in geld (als bedrijf) en een iets dikker cpu en een latje extra in je systeem, maar vervolgens wel 50% ontwikkelkosten besparen is netto goedkoper.

[SkizikS]

Vergeten we niet dat de applicaties/webpaginas ook op onze pc's kunnen gaan draaien; wat dus betekent dat het in dit geval een non argument is dat de bespaarde ontwikkelkosten per definitie aan sneller hardware uit kan gegeven worden.
PS, ik haat bloatware/lagware

[mOrPhie]

Ruby on Rails is een Ruby-framework en Java is een programmeertaal. Ruby applicaties zijn interpreted en java zijn byte-code gecompiled. Java is voor meer dan webdevelopment alleen en Ruby On Rails wordt vrijwel alleen voor web-interfaces gebruikt. Bedreiging voor Java? Misschien voor PHP, maar ik denk dat het bij veel selectieprocedures al snel afvalt als serieuze overweging voor bedrijfskritische enterprise-software.

[Anoniem: 168910]

Je hebt Java en het Java Framework.

Was het niet voor de gingantische framework en schaalmogelijkheden van Java, dan werd Java niet gebruikt.

Ruby + Rails + Mongrel moet je natuurlijk vergelijken met de setup van TomCat + JSP + JavaFramework.

De programmeertaal zelf is daar maar een klein gedeelte van het totaal plaatje. Alhoewel zaken als first-order-functions, etc. wel beinvloeden hoe programmeur-vriendelijk de liberaries kunnen zijn.

Maar dan hoor ik dit uit je mond komen:

als serieuze overweging voor bedrijfskritische enterprise-software

En als iets voor een framework zou pleiten lijkt het me toch wel dat de enterprises het links laten liggen. Te goedkoop, te voor de hand liggend, te weinig marketing, niet genoeg genoemd in combinatie met hippie afkortingen. Niet dat alle enterprise oplossingen inefficent, dom en duur zijn, er is vast wel een uitzondering die de regel bevestigd. Toch is het zo dat de statistische kans dat een hobbyist een betere site maakt dan een enterprise bedrijf vrij groot. (als je zaken als MySpace niet tot het maken van je eigen site rekent)

Enterprise oplossingen komen als volgt tot stand:

- met neme een it-manager die heel veel afkortingen kent. En dan betalen we hem heel veel, want we verwachten hoge ROI
- de it-manager weet natuurlijk nergens wat van, behalve hoe je zakelijk moet overleven, dus hij neemt een consultant in dienst: gaat het dan mis, dan kan hij aantonen dat hij duur advies ingekocht heeft om succes te garanderen. (shift the blame in advance)
- de consultant heeft al 20 jaar niet geprogrammeerd en de enige programmeerervaring die hij heeft is in Visual Basic op Windows 95 en beetje access.
- de consultant leest domme blaadjes als 'computable' (in plaats van zo slim te zijn Tweakers.net te lezen) om bij te blijven
- daarin heeft hij een keer zien staan dat in de enterprise webserver market Java heel errug hot is. Als iedereen het gebruikt en adviseert, dan kan dat advies geen slecht advies zijn. (spring in die sloot, want al je concurrenten springen ook in die sloot!)
- consultant heeft advies gegeven, zak geld ontvangen, en gaat weer door naar de volgende job
- een zooi programmeurtjes van de hbo/uni wordt erop gegooid die geen werkervaring hebben
- het kan natuurlijk niet mis gaan, java is the bomb en het management heeft duur kwalitatief advies ingewonnen.
- het gaat mis. ze waren niet in staat om de juiste OO design te ontwikkelen, de hebben alle SQL code concreet zonder enige abstractie erin gezet
- een jaar na de geplande datum dat het af zou moeten zijn, en een half miljoen verder, is er eindelijk een werkend prototype
- inmiddels zijn alleen een aantal kleine dingen veranderd aan de bedrijfsvoering. Dit vereist voornamelijk kleine wijzigingen in de data-structuur.
- drie maanden later zijn ze eindelijk klaar overal de sql aan te passen
- de site gaat live
- de site wordt gehackt. De sql code wordt niet overal netjes ge-escaped. Een bijdehande RoR gebruikers opent een link: http://www.enterprisey.com/search/term%33;DROP TABLE Orders;%33
- de directie begint te panieken en vindt het project een mislukking
- maar de manager laat zien dat hij heel duur advies ingekocht heeft, dus aan hem ligt het niet
- ze besluiten het project te cancellen en gaan een extern bedrijf inhuren voor de site
- patroon herhaalt zich in dat bedrijf, maar project mislukt net wat minder, aangezien ze al wat jaren programmeurs hebben zitten selecteren.

Het probleem is dat het een technisch intelligent persoon vereist om technisch intelligente mensen aan te nemen. Bedrijven waar technisch intelligente mensen werken zijn te herkennen aan het feit dat hun platform/framework/etc. keuzes niet conform de standaard zijn.

Denk bijvoorbeeld aan Google:
- draaien alles op linux servers
- gebruiken Python (notabene!) voor alle data-aggregatie, verwerking en de googlebot enzo. Ookal is Python zo snel is, het is wel zonder compile-stap te bewerken en is redelijk fault-tolerant.
- gebruiken compiled C code, die ze als apache module integreren voor de backend van de search-sites. Omdat meer CPU meer stroom kost is dit kosten-technisch goedkoper met een website die zo vaak geopend wordt.
- gebruiken een zelfontwikkelde java -> javascript compiler (want Javascript is niet te debuggen en java programmeurs zijn er te over) voor hun Ajax sites.

Een typisch enterprise die niet weet wat doet: De overheid die een miljoen neer legt om een flash site ( http://www.watvooreikelbenjij.nl ) te maken.

De enterprise die zo slim is om voor RoR te kiezen, zal dan ook een succesvol project tegemoet gaan. Gedeelte vanwege de guarilla-programming-style en gedeeltelijk omdat het niet een taal is die je op de HBO/Uni krijgt. Mensen die dit soort baantjes opzoeken zijn gewoon veel beter dan de figureren die nooit verder dan Java gekeken hebben. Deze figuren missen de passie, motivatie en daarmee dus ook het inzicht. (alhoewel ze absoluut niet dommer hoeven te zijn, minder motivatie kan er ook voor zorgen dat je ergens slechter in bent dan anderen)

En die factor moet je ook niet onderschatten: het is veel moeilijker om goede Java programmeurs te krijgen, omdat goede programmeurs liever niet met Java werken.

De marketing/mangement buzz is gewoon bezigheidstherapy voor mensen met een goedbetaalde melkert-baan die niet willen toegeven dat eigenlijk niks nuttigs kunnen.

[Grub]

Ongelooflijk, wat een ongerelativeerde reactie. Je begint met te zeggen dat Java een programmeertaal is en geen framework, en na een enorm onzin verhaal maak je toch dezelfde fout en doe je er nog een schepje bovenop.

Was het niet voor de gingantische framework en schaalmogelijkheden van Java, dan werd Java niet gebruikt.

Java komt juist pas goed tot zn recht in de grotere enterprise applicaties, en in bijv EAI. En geloof me, er is hier geen enkele concurrentie te bespeuren voor java.

De enterprise die zo slim is om voor RoR te kiezen, zal dan ook een succesvol project tegemoet gaan. Gedeelte vanwege de guarilla-programming-style en gedeeltelijk omdat het niet een taal is die je op de HBO/Uni krijgt. Mensen die dit soort baantjes opzoeken zijn gewoon veel beter dan de figureren die nooit verder dan Java gekeken hebben. Deze figuren missen de passie, motivatie en daarmee dus ook het inzicht. (alhoewel ze absoluut niet dommer hoeven te zijn, minder motivatie kan er ook voor zorgen dat je ergens slechter in bent dan anderen)

De figuren die dus RoR beheersen, zijn gemotiveerd en hebben passie omdat ze niet van een HBO/Uni komen waar ze Java krijgen en vervolgens niet verder kijken..... right... Ik ruik hier ergens dat je zelf nooit zo'n opleiding hebt voltooid.
Een getalenteerde IT-er zal geen moeite hebben met zo'n opleiding en het als een goede start zien, om vervolgens vol "passie, motivatie en inzicht" verder te gaan met zich te ontwikkelen in het bedrijfsleven.

...java programmeurs zijn er te over...
...het is veel moeilijker om goede Java programmeurs te krijgen, omdat goede programmeurs liever niet met Java werken...

Nog zo'n belachelijke bewering waarin je jezelf tegenspreekt. Goede Java programmeurs zijn lastig te krijgen, omdat de leercurve erg lang is. Dit komt mede doordat er van goede Java programmeurs verwacht wordt dat ze niet alleen goed kunnen programmeren maar ook nog eens ervaring hebben met zoveel mogelijk api's op de vele terreinen waar Java gebruikt wordt. Wat een onzin trouwens dat een goede programmeur liever niet met Java werkt, hier ga ik niet eens op in.

De marketing/mangement buzz is gewoon bezigheidstherapy voor mensen met een goedbetaalde melkert-baan die niet willen toegeven dat eigenlijk niks nuttigs kunnen.

Als je ooit zelf een product of dienst wilt gaan leveren, kom je er vanzelf wel achter waar marketing nou eigenlijk goed voor is.

[Anoniem: 168910]

Je hebt op een aantal punten aangegeven dat je het niet met me eens bent. Op geen enkele plek beargumenteer je dat. Daarom dus, met dikke vette knipoog, de meneerR popquiz!

POPQUIZ:
Beantwoord de volgende vragen en win 2 legitieme meneerR WC-Rollen. Stuur je antwoorden naar [e-mail] voor 15 november. Over de uitslag kan gecorrespondeerd worden, alleen niet met mij.

Vraag 1: Het ruikvermogen van afgestudeerden
".. Ik ruik hier ergens dat je zelf nooit zo'n opleiding hebt voltooid."

Deze quote betreft:
a - een standpunt
b - een belediging
c - een argument
d - "geloof me, ik ben helderziend"
e - "geloof me, ik weet het beter"
f - op deze vraag ga ik niet eens in

Om je helderziendheid tegen te spreken:

Guess again. Het is juist op de universitaire opleiding waar Java me strot zo uitkomt.
Terwijl ze (de leraren) er zelf ook allemaal een hekel aan hebben. Maar ze zeggen dan: "daar hebben je straks in de markt het meest aan, want daar is veel vraag naar. "
Ken je dat verhaal van die kip en dat ei? Weet jij nog hoe het begon? Ik ben het geloof ik vergeten...
Sowieso, de markt? Wetenschappelijke studie? Hmm.


Vraag 2: Hier ga ik niet op in
"Wat een onzin trouwens dat een goede programmeur liever niet met Java werkt, hier ga ik niet eens op in."

Deze quote betreft:
a - een standpunt
b - een belediging
c - een argument
d - "geloof me, ik ben helderziend"
e - "geloof me, ik weet het beter"
f - op deze vraag ga ik niet eens in

Reactie:
Misschien ben jij misschien een Java fanboy? Misschien heb je misschien geen enkele serieuze ervaring met andere programmeertalen en frameworks. Misschien trek je het dus persoonlijk aan.
Ben je nooit nieuwsgierig geweest naar die andere talen? Hoe die andere frameworks werken?
En waarom dan niet? Wat de boer niet kent vreet ie niet. Omdat de boer niet van lekker houdt. De boer heeft geen passie voor eten.
Maar jij bent toch geen boer? En programmeren is toch niet eten?


Vraag 3: Spraakverwarring
"Java komt juist pas goed tot zn recht in de grotere enterprise applicaties, en in bijv EAI. En geloof me, er is hier geen enkele concurrentie te bespeuren voor java."

Deze quote betreft:
a - een standpunt
b - een belediging
c - een argument
d - "geloof me, ik ben helderziend"
e - "geloof me, ik weet het beter"
f - op deze vraag ga ik niet eens in

Ik had gezegd:

Was het niet voor de gingantische framework en schaalmogelijkheden van Java, dan werd Java niet gebruikt.

Mij lijkt dat je me hier helemaal niet tegenspreekt. Het zal wel aan mij liggen, ik ben helaas niet helderziend.

Vraag 4: Marketing
"Als je ooit zelf een product of dienst wilt gaan leveren, kom je er vanzelf wel achter waar marketing nou eigenlijk goed voor is."

Deze quote betreft:
a - een standpunt
b - een belediging
c - een argument
d - "geloof me, ik ben helderziend"
e - "geloof me, ik weet het beter"
f - op deze vraag ga ik niet eens in

Reactie:

Ik snap het economische principe van marketing wel. Al die marketing rondom Java zorgt ervoor dat Java en gerelateerde producten goed verkopen.

De reden dat anti-rimpel-zalf X goed verkoopt is dat mensen geloven dat er echt een formule Y bestaat die dmv super-bestandsdeel Z ervoor zorgt dat je spontaan 10 jaar jongen wordt. Maar de klanten van een anti-rimpel-creme hebben geen opleidingen en kennis van scheikunde genoten.

De mensen die bepalen welk framework en technologien gebruikt gaan worden zouden toch genoeg technische kennis moeten hebben om totaal ongevoelig voor marketing te zijn. Juist het feit dat er zoveel marketing is suggereert dat het werkt. Wat weer suggereert dat de betreffende managers dus keuzes baseren op reclame informatie dat totaal gebakken lucht is. En dat zegt weer heel veel over hun kennis en inzicht.

[Anoniem: 145126]

Sarcasme is de uitting van een zwakke geest.

Ik programmeer sinds het hbo inderdaad in java en heb meerdere sun certificaten. Ik heb veel andere talen geprogrammeerd en ik vind java een erg goede taal waarin de grens tussen strakke regels en creative mogelijkheden precies goed ligt. Java heeft de juiste connectiviteit mogelijkheden en een uitgebreid framework.

Ik vind programmeren leuk en doe het ook nog eens voor mijn werk. En dat je zegt dat ik een slechte programmeur vind, dat mag, maar ik wordt nogsteeds goed betaald en mijn opdrachtgevers zijn tevreden. Ook heb ik nog nooit een project meegemaakt wat serieus over de voorgestelde ontwikkeltijd heen ging. Bovendien heb ik meerdere serieuze bedrijven gezien die java op een zeer goede manier hebben geimplementeerd wat je niet ff met een andere taal zou kunnen overnemen. (Ja C++ wellicht, na enkele tientallen jaren programmeren).

Ik weet dus eigenlijk totaal niet wat je loopt te zeuren hier, maar waarschijnlijk is Java gewoon te moeilijk voor jou en probeer je daarom iedereen scripttaaltjes aan te praten.

Zelf ben ik het meer eens met de eerste reactie van mOrPhie. Java is idd meer een ontwikkeltaal en platform voor enterprices en Ruby lijkt mij (ik heb er nog niets in gebouwd) meer een webgerichte scrtipttaal, wellicht met een grote library zoals php.

Dit moest ik even kwijt.

[Anoniem: 168910]

Sarcasme is de uitting van een zwakke geest.

Sorry daarvoor. Ik kon gewoon geen andere manier vinden om duidelijk te maken dat je reactie inhoudelijk zo diep gaat als Georgina Verbaan. Het was een mengelmoes van standpunten, drogredenen en beledigingen. Het enige punt dat je wist te maken is dat je waarschijnlijk geen prettig persoon bent om in je omgeving te hebben. Je gaat ervan uit dat je het beter weet, beargumenteerd dat dan niet, en als iemand het daar niet mee eens is, ga je lopen beledigen. Maar goed, dat bewaar je maar voor je sessie met Dr. Phil.

Maar ik kom je tegemoet: Dit keer minder sarcasme en meer jouw lullige toon:

Ik programmeer sinds het hbo inderdaad in java en heb meerdere sun certificaten. Ik heb veel andere talen geprogrammeerd ..

Lees: ik heb verstand van zaken want ik ben zo debiel die een sun certificaat GEKOCHT heeft. Je betaald voor een nepcursus en dan krijg je, bijna gegarandeerd, een papiertje, om dan vervolgens op je CV reclame te maken voor een PRODUCT. Wie is hier nou de idioot?

Link naar meer informatie waarom dit geen argument is:
http://nl.wikipedia.org/wiki/Beroep_op_autoriteit

.. en ik vind java een erg goede taal waarin de grens tussen strakke regels en creative mogelijkheden precies goed ligt. Java heeft de juiste connectiviteit mogelijkheden en een uitgebreid framework.

Is dit een reclame folder? Wat zijn de juiste connectiviteits-mogelijkheden dan volgens jou? En wat maakt ze dan juist? Hoe vindt de scheiding tussen creative en strakke regels dan plaats? En in hoeverre is deze mix dan perfect voor web-ontwikkeling? En op welke manier dan? Zeggen dat het zo is, is niet argumentatie. Het daarna herhalen en herhalen dat het zo is, is niet debateren.

Daarnaast: Ik wil en heb je hier niet over tegengesproken. Java heeft een goed framework. De voornaamste reden om java te gebruiken zei ik al in mijn eerste post, ookal is de taal gehandicapt en ouderwets.

Ik vind programmeren leuk en doe het ook nog eens voor mijn werk. En dat je zegt dat ik een slechte programmeur vind, dat mag, maar ik wordt nogsteeds goed betaald en mijn opdrachtgevers zijn tevreden.

Ik ken je niet. Ik heb ook nooit beweerd dat JIJ een slechte programmeur bent. Ik heb alleen de logische stelling neergelegd dat iemand die denkt dat Java de bomb is, waarschijnlijk nooit serieus met een taal als bijvoorbeeld Haskell gespeeld heeft.

Ook heb ik nog nooit een project meegemaakt wat serieus over de voorgestelde ontwikkeltijd heen ging. Bovendien heb ik meerdere serieuze bedrijven gezien die java op een zeer goede manier hebben geimplementeerd wat je niet ff met een andere taal zou kunnen overnemen. (Ja C++ wellicht, na enkele tientallen jaren programmeren).

Ik zal je maar verbeteren: "wat je niet ff met een ander framework zou kunnen overnemen." Dat is toch wat je wou zeggen? Of zijn er bepaalde constructies in Java die in andere talen, behalve ASM, moeilijker zijn?

Ter vergelijking van deze redenatie:
- windows is een beter OS want er zijn meer applicaties voor
- een normale DVD speler is beter dan een blueray-DVD-speler want er zijn meer normale DVD's
- een bezine-auto is beter dan een waterstof-auto want er zijn meer bezine-tank-stations.

Trouwens, er zijn wel degelijk alternatieve frameworks. Ik mag er toch vanuit gaan dat je van .NET hebt gehoord. Opvallend bij .NET is misschien ook dat de taal en het framework losgekoppeld zijn.

En zelfs voor het Java framework zijn alternatieve, superieure, talen te vinden. JRuby en Groovy bijvoorbeeld. Volgens mij kan je zelfs Scheme draaien op de JVM.

Ik weet dus eigenlijk totaal niet wat je loopt te zeuren hier, maar waarschijnlijk is Java gewoon te moeilijk voor jou en probeer je daarom iedereen scripttaaltjes aan te praten.

De helft van talen die ik daar noemde zijn meer statisch-getype-checked en gemodulariseerd dan Java. Dat jij al die talen classificeert als script-talen toont je gebrek aan kennis.

En als sarcasme een uiting van zwakte is, wat is jouw belediging hierboven dan?

Zelf ben ik het meer eens met de eerste reactie van mOrPhie. Java is idd meer een ontwikkeltaal en platform voor enterprices en Ruby lijkt mij (ik heb er nog niets in gebouwd) meer een webgerichte scrtipttaal, wellicht met een grote library zoals php.

Ruby is inderdaad een webgerichte scripttaal met dynamische typechecking.

En voor het maken van een website is dat de perfecte soort technologie. De voornaamste struikelblokken zijn niet super ingewikkelde algoritmes of modularisatie waarmee je met 100 man aan een project kan werken.

Bij het maken van een site is juist het probleem dat je minstenst 3 talen en methodologien door elkaar zit te mengen. En daar helpt Java je totaal niet.

- Al Java's typechecking beschermt je niet tegen SQL injection. Ruby ActiveRecord bijvoorbeeld wel. HaskellDB integreert SQL in de taal en type-checked ook je database queries die meteen op native datatypes gemapped worden. Dat je zo'n library niet voor Java kan maken heeft alles met de tekort-komingen van de semantiek en type-checking te maken. Waar zijn de type-classes? Waar zijn de first-order-functies? Waar zijn de algebraishe datatypes? Lijken mij toch triviale zaken wil je statische typechecking overwegen.

- Al Java's strakke regels helpen je niet om gegarandeerd geldige XHTML af te leveren. Het kan wel, door voor elk tag een klasse te maken. Voor elk attribuut een methode. Maar dan is het toch doorslaggevend dat je zoiets in Ruby doet met ongeveer 3% van de hoeveelheid code die je in Java nodig hebt. Juist omdat je dynamisch klasses kunt maken waarvan tijdens 'compile-time' nog niet vast staat hoe de methodes gaan heten en wat hun type precies zal zijn. En dan hebben we het nog niet over bijvoorbeeld de web-extensie van Haskell, waar XML tags first-class datatypes zijn. Om maar even aan te geven dat dit of kan door statische type-checking af te schaffen of door statische-type-checking op het Hindley-Milner theorie te baseren.

- En hoe helpt Java je bij het integreren van Javascript en Ajax? Alhoewel hier wederom geldt dat je met veel meer moeite een vergelijkbare support klasses zou kunnen maken in Java. Die zijn er in ieder geval nog niet.

Dit moest ik even kwijt.

En, lucht het op?

[qless]

Leuk stukje tekst meneer r, maar het volgende stukje:

En die factor moet je ook niet onderschatten: het is veel moeilijker om goede Java programmeurs te krijgen, omdat goede programmeurs liever niet met Java werken.

Vindt ik toch niet zo heel erg goed. Behoorlijk suggestief zelfs. Ik neem aan dat je wat negatieve ervaringen met java hebt?

[flowerp]

Java kent geen abstracte datatypes bijvoorbeeld.

Voordat Java generics had, was de aanwezigheid van statische type-checking zinloos

Wow, je allereerste 'bijna' zinvolle opmerking in tijden. Gefeliciteerd man!

Helaas slechts bijna, omdat jij natuurlijk niet kunt begrijpen dat niet alle code van enige vorm van collections gebruikt maakt. Native arrays zijn bijvoorbeeld als sinds dag 1 impliciet generic en fully type checked.

Bijna zinvol, maar helaas leven we al bijna in 2007. Generics bestaan al zo lang. Ga je ook zeuren dat computers vroeger 8 bit waren en je je niet kon voorstellen dat iemand ze gebruikte omdat je voor elke getal boven de 255 handmatig dingen moest doen"

Dat zijn allemaal dingen van lang geleden man. Get over it!

Het kost je 5 regels om hello world te maken. Het tijdperk van LOC betaling is toch al voorbij?

Tjezus... 5 hele regels. Das inderdaad wel wat veel voor iemand zoals jij die dagelijks hello world implementaties maakt he?

Hier moet ik je wel gelijk geven. Voor een profesionele "hello-worlder" zoals jij is Java niet geschikt. Het is meer een taal voor mensen die iets grotere applicaties schrijven, en waar onderhoud, uitbreidbaarheid en leesbaarheid toch niet helemaal onbelangrijk zijn.

Oh, en vergeet ik daar toch nog helemaal JSP (wat ook een onderdeel van Java is en waarin een hello world er zo uitziet:

[code]
hello world
[/code]

Als ik jou was zou ik dus maar naar JSP gaan kijken, dan kun je mischien wel je hello world productie opvoegen tot 1000 stuks per dag.

suc6 ermee!

[Anoniem: 168910]

Ik heb in mijn leven met een flink aantal programmeertalen zowel gewerkt als gespeeld. Het werken betrefde zowel de studie als betaald-werk.

Java is als imperatieve oude generatie object georienteerde taal zo slecht niet.

Maar dat is precies wat het is. Pas sinds generics kan ik me uberhaupt voorstellen dat iemand het zou WILLEN gebruiken.

Maar dan blijft nog de ongeloofelijke verbose syntax. Je blijft je afvragen of ze aandelen in fabrieken die keyboards produceren hebben ;-)

Wat ik gewoon probeer te zeggen, en waar ik toch vanuit ga dat de meeste programmeurs goed van op de hoogte zijn, is dat de ene programmeertaal de andere niet is. Er is geen perfecte programmeertaal voor elke purpose, maar er zijn wel slechte.

Typische Java quirks:

- Java kent geen abstracte datatypes bijvoorbeeld.
- Voordat Java generics had, was de aanwezigheid van statische type-checking zinloos, aangezien je of code moest dupliceren, of je moest casten (waardoor je terugvalt op dynamische typechecking)
- Het kost je 5 regels om hello world te maken. Het tijdperk van LOC betaling is toch al voorbij?

Je hebt gemotiveerde programmeurs in alle soorten en maten, maar Java als taal zou van al die categorien toch geen van hun moeten bekoren.

De quick'n'dirty mensen pakken wel perl.
De hackers pakken wel o'caml.
De web2.0 citizens pakken wel ruby.
De OSS boys prefereren Python/C#/C++
En de compiler/parser hackers gebruiken natuurlijk Haskell
De AI jongens werken met Prolog, Curry of Mercury

Als Java je lievelingstaal is, dan ben ik er vrij zeker dat Programmeren NIET JE PASSIE is.

Net zo goed als een britney spears fan waarschijnlijk geen muziekliefhebber is. Maar een Rammstein (metal), Yann Tiersen(modern klassiek) of Reel Big Fish (skapunk) fan waarschijnlijk wel.

Waar het om gaat is dat een liefhebber zich in het vakgebied verdiept. En dan zouden ze toch moeten ontdekken dat er een bepaalde taal is die bij hun beter past.

En of dat perse leidt tot slechtere programmeurs. Ik denk het wel, maar dat is moeilijker te beargumenteren. Zou je een goeie auto-monteur kunnen zijn als je helemaal niks met auto's hebt? Als je je schouders voor een ferrari ophaalt? Misschien.

[Anoniem: 168910]

@flowerp

Wow, je allereerste 'bijna' zinvolle opmerking in tijden. Gefeliciteerd man!

Dank je wel. Het is fijn gevoel om te horen een grote expert zoals jij een opmerking van mij als bijna zinvol weet te benoemen. Sterk punt. Zinvol ook. Kan ik nog veel van leren ;-)

Helaas slechts bijna, omdat jij natuurlijk niet kunt begrijpen dat niet alle code van enige vorm van collections gebruikt maakt. Native arrays zijn bijvoorbeeld als sinds dag 1 impliciet generic en fully type checked.

Helaas begrijp jij het niet als je denkt dat over collections perse gaat. Zelfs zonder collections, kun je zonder generics geen binary-search-tree maken dat met een wikkekeurig datatype werkte, zonder tot casting over te gaan.

Natuurlijk komen zaken als binary search trees alleen in 'complexe' projecten voor. Maar zijn dat niet net de projecten waar je statische-typechecking voor nodig hebt?

De korte proggies kunnen ook wel in een scripttaal.
Oftewel: zonder generics was Java, als statisch getypecheckde taal een lachertje tov C++ met templates of Haskell/ML/O'Caml/etc. Je moest toch altijd terug vallen op dynamische typechecking in Java (en daar betaalde je ook de bekende performance penalty voor)

Bijna zinvol, maar helaas leven we al bijna in 2007. Generics bestaan al zo lang.

En alle support libraries en het omliggende framework is al totaal aan generics aangepast? Dacht het niet. Ik leef inderdaad in 2006, maar jij lijkt in 2010 te leven.

Zowieso tegen die tijd implementeren ze vermoedelijk weer die andere missing-features die serieuze programmeertalen wel hebben. Zoals algebraishe datatypes, type classes, type-constraints, first-class-functions, etc.

Of dacht je dat Java nu opeens up-to-date was? Lol.
Niet overigens, dat .NET zoveel beter is, maar het is nu, vandaag de dag, toch meer up to date. Het LINQ project vereist namelijk precies deze aanpassingen aan het type-systeem. Natuurlijk noemt de marketing het anders want de wetenschappelijke termen zijn natuurlijk door de managers niet uit te spreken, of af te korten, om intressant te lijken.

... 5 hele regels. Das inderdaad wel wat veel voor iemand zoals jij die dagelijks hello world implementaties maakt he?

Hello, world doet er ook niet toe, maar het toont wel de omslachtigheid van de syntax aan. Objecten zijn het enige niveau van abstractie in Java. Als je een functie hebt die als argument mee wilt krijgen, hoe je bijvoorbeeld een lijst wilt sorteren, dan is het toch harstikke overkill dat je niet gewoon even een lambda-functie als comparision operator mee kan geven. Je wordt verplicht of om een klasse te subklassen, of om apart een klasse voor de comparision operator te maken.

Neem nou de haskell functie 'map'. Hoe wou je dat implementeren in Java? Voor als je het niet weet, map krijgt als argument een functie die hij toepast op elk element uit een lijst.

map (*2) [1..5] (is de lijst van 2,4..8,10)

Wil je dit implementeren op een manier dat het ook nog generiek is, dan zal de functie (*2 in dit geval) in een klasse gestopt moeten worden. Een aparte klasse om dingen met 2 te vermenigvuldigen lijkt mij toch overkill.

En de oorzaak dat je daar zoveel code voor nodig hebt in Java is dezelfde oorzaak dat hello-world 5 regels kost.

Oh, en vergeet ik daar toch nog helemaal JSP (wat ook een onderdeel van Java is en waarin een hello world er zo uitziet:

Wat neemt dat af van het feit dat de abstractie van het zeggen 'hello, world' teveel werk is. Zonder abstractie ergens in knallen kan natuurlijk altijd. Je zou ook een heel programma in de main functie kunnen knallen en nooit je code netjes in klasses, etc. opdelen. Volgens mij was dat de bedoeling achter Java niet.

[Anoniem: 168910]

@ flowerp:

Je smiley omtrend abstracte datatypes gaf aan dat je me niet begreep. Dit zal ook wel komen door mijn misbruik van de term abstracte datatype. De correcte term is algebraish datatype:

http://en.wikipedia.org/wiki/Algebraic_data_type

[flowerp]

Dank je wel. Het is fijn gevoel om te horen een grote expert zoals jij een opmerking van mij als bijna zinvol weet te benoemen.

Met liefde hoor. Ik mag dan af en toe een brompot zijn, maar ik ben zeker niet te beroerd om zinvolle (of bijna zinvolle ) opmerkingen als dusdanig te typeren!

Zelfs zonder collections, kun je zonder generics geen binary-search-tree maken dat met een wikkekeurig datatype werkte, zonder tot casting over te gaan.

Voordat we verder deze discussie in gaan wil ik wel eerst even duidelijk maken dat ik het gemis aan generics in oudere Java versies ook een enorme misser vond. Ik heb jaren lang op diverse forums en mailing listen lopen te 'zeuren' dat dit echt iets was wat java miste. Geen generics was gewoon een loophole in het type-systeem. Bij een goed opgezet design en correct geimplementeerde code is bijna geen plaats voor casting.

Zelfs zonder collections, kun je zonder generics geen binary-search-tree maken dat met een wikkekeurig datatype werkte, zonder tot casting over te gaan.

Is dat zo? Ik zie wel degelijk mogelijkheden. Wat dacht je van een abstract super type waarbij je de typed value in een sub class defineerd? (binaire tree waarbij de vertakkingen op een algemeen type gaan, zeg integer of boolean en elke node een value bevat).
Of als je de vertakkings beslissing ook door je type wilt laten doen, dan defineer je daar een interface voor. De binaire-search code hoeft op elke node alleen een 'links/rechts' beslissing te maken, en heeft het concrete type dus helemaal niet nodig.

Als je deze twee aanpakken combineert kun je een binaire tree maken met alle gangbare operaties, zonder generics of templates en zonder casting. Voor elk type in de tree defineer je dan wel een apart sub-type van de tree, maar als je C++ een beetje kent dan weet je dat de C++ compiler dat ook doet (en bij oudere compilers mogelijk zelfs dubbel).

En alle support libraries en het omliggende framework is al totaal aan generics aangepast? Dacht het niet. Ik leef inderdaad in 2006, maar jij lijkt in 2010 te leven.

Inderdaad is niet alles aangepast, wel gelukkig steeds meer. Notoire uitzonderingen zijn Jakarta commons collections en (je zult het bijna niet geloven) JSF 1.2 dat notabene onderdeel is van Java EE 5. Voorderest is JPA en SEAM wel degelijk volledig voorzien van generic support, alsmede alle classes in de Java SE API. Tenzij je dus je eigen custom JSF componenten gaat schrijven, hoef je zeker voor nieuwe projecten niet al te veel met non-generic support te maken te hebben.

Legacy blijft natuurlijk wel een issue, maar dat is/was in C++ ook zo. Templates zijn ook relatief laat aan C++ toegevoegd, de eerste (non spec) versies hadden ze zeker niet. Jaren na de spec kwam ik toch echt nog dagelijks code tegen waar ik void pointers mocht gaan casten.

Niet overigens, dat .NET zoveel beter is, maar het is nu, vandaag de dag, toch meer up to date.

Volgens mij is het meer C# waar je hier op doelt. Deze heeft een aantal features zoals operator overloading, delegates of de aardige properties syntax die Java mist.

Ik geloof echter niet dat iemand in deze thread eerder heeft beweerd dat Java als taal sterker is dan C#.

Objecten zijn het enige niveau van abstractie in Java.

Objects should be the only modules? *lol* Maar je hebt natuurlijk ook nog packages naast classes. En via zowel reflectie als EL (Expression Language) heb je ook het concept van een functie pointer, een method binding en een value binding. Niet direct in the language zelf, maar wel via de std Java library.

Als je een functie hebt die als argument mee wilt krijgen, hoe je bijvoorbeeld een lijst wilt sorteren, dan is het toch harstikke overkill dat je niet gewoon even een lambda-functie als comparision operator mee kan geven.

Hoeveel imperatieve talen hebben uberhaupt nu al lambda functies? In C++ worden ze ook via een library toegevoegd (boost::lambda) en werken ze -NIET- handig.

Dit heeft eigenlijk bijna niets meer met een Java rant te maken, maar is meer een vergelijking tussen het puur functionele en imperatieve paradigma.

Mischien heb je wel een beetje het verkeerde element gekozen om op te ranten, want juist 1 van de voorstellen over syntax toevoegingen aan een nieuwe Java versie betreft lambda functies.

Neem nou de haskell functie 'map'. Hoe wou je dat implementeren in Java

Standaard in Java is nu het geheel in een implementatie van een interface wrappen. Klinkt veel werk, is het niet. Staat suf, maar werkt identiek.

Alternatief kun je het nu ook al met EL implementeren:

map ( "#{val * 2}", list );

[mxcreep]

JSP, was dat niet 'The most sorry excuse for a scripting language' ? Tenminste die opmerking hoorde ik eens iemand maken en eerlijk gezegd ben ik die blijven aanhouden

[flowerp]

JSP zelf is geen scripting language maar een template. De language is Java

Een ouderwetse JSP pagina is identiek aan een PHP pagina:

Ziet er basically zo uit:

<html>
<% String param = request.getParameter( "naam" ); %>
<body> Hallo, mijn naam is <%=param%> <br> </body>
</html>

Als je wilt kun je in JSP 100% zoals in PHP werken.

Java in zijn geheel (dus SE en EE) is echter ongelooflijk veel groter dan dat. Kwa kale syntax is Java niet eens zo veel beter als de kale PHP syntax, het gaat voornamelijk om het krachtige en uitgebreide framework. In de web layer heb je bijvoorbeeld een concept als een web component. Dat is zeg maar de OO versie van templating. Heel grof gezegt kun je dan van wat in PHP een stukje losse HTML met script is echte 'instanties' van aanmaken. Net zoals bij een clientside GUI kun je met web componenten echte compositions maken en heb je een echt event systeem.

Net zoals OO voor code is het eigenlijk niet in een paar woorden uit te leggen. Je moet het echt eens beleefd hebben om het voordeel er van in te zien

[Left]

@meneer r:
Op een aantal punten heb je gelijk maar hier ga je wel heel kort door de bocht:

Bedrijven waar technisch intelligente mensen werken zijn te herkennen aan het feit dat hun platform/framework/etc. keuzes niet conform de standaard zijn.

Dat is niet waar. Het feit dat een bedrijf voor een oplossing heeft gekozen die niet conform de standaard is kan inderdaad betekenen dat de technische afdeling genoeg inzicht heeft gehad om in te zien dat hun applicatie beter af was met een andere oplossing. Maar een non-standaard framework heeft ook duidelijke nadelen:
- je weet niet hoe lang het nog ondersteund gaat worden door de community. Dit kan betekenen dat na een tijdje jij zelf voor alle uitbreidingen etc. moet gaan zorgen, hetgeen een boel tijd en werk kan gaan kosten
- nieuwe collega's moeten hoogstwaarschijnlijk eerst een tijd lang ingewerkt worden voordat ze met jouw ongebruikelijke framework aan de slag kunnen. Voor een standaard framework is dat veel minder het geval, omdat de meeste sollicitanten er wel ervaring mee zullen hebben
- een standaard framework heeft zich in de praktijk ruimschoots kunnen bewijzen. Voor een non-standaard framework geldt dat veel minder. Hetgeen kan betekenen dat voor jouw specifieke probleem er plotseling bugs in het framework blijken te zitten die niemand nog was tegengekomen.
- voor een standaard framework is ruimschoots ondersteuning en technische info te vinden op het internet. Voor een non-standaard framework ook wel, maar uiteraard veel minder.

[Anoniem: 168910]

@Left

Er zijn wel degelijk nadelen op het gebruik van een niet standaard framework. Daarin heb je helemaal gelijk.

Belangrijkste vraag is dan: wil je dat technologie je concurrentie-positie versterkt?

Al deze nadelen die je noemt kunnen er wel voor zorgen dat jij straks dingen kunt doen die al je concurrenten niet even gemakkelijk en tegen dezelfde kosten kunnen doen.

Aan de andere kant: als technologie een noodzakelijke bijzaak is, maar niet doorslaggevend voor je concurrentie-positie, dan zou een behoudendere keuze misschien verstandig zijn.

Voor jezelf denken is altijd meer risico vol dan de concurrenten kopiëren. Je kan een gigantische enterprise worden door nooit zelf iets zinnig uit te vinden (qua technologie, bedrijfsvoering, whatever). But what's the fun in that?

[tjerkw]

Sorry meneer r maar even wat misverstanden weghalen

Ruby + Rails + Mongrel moet je natuurlijk vergelijken met de setup van TomCat + JSP + JavaFramework.

Je vergeet hier dat Tomcat slechts 1 van de velen serlvet containers is. Ook vergeet je dat java tegenwoordig ook scripting talen als EcmaScript Python (Jython) en ja zelfs ruby ondersteund ( toegegeven de scripting api is nieuw).

Toch is het zo dat de statistische kans dat een hobbyist een betere site maakt dan een enterprise bedrijf vrij groot

Serieus de hobbiest heeft geen verstand van software evolution, requirements analysis, uml modelling, distributed systems, software patterns, artificial intelligence etc etc etc etc.
Er zijn echt serieuze studies gedaan naar het grote "Software Mangement Probleem" software werd altijd duurder dan geplanned, duurder altijd langer, was niet onderhoudbaar. Precies hierna is dus onderzoek gedaan en zijn er uitkomsten uitgekomen die ik bijvoorbeeld leer.

Het probleem is dat het een technisch intelligent persoon vereist om technisch intelligente mensen aan te nemen. Bedrijven waar technisch intelligente mensen werken zijn te herkennen aan het feit dat hun platform/framework/etc. keuzes niet conform de standaard zijn.

Inderdaad, men kiest het jusite platform voor het probleem. Laat nou net java veel voordelenen hebben als platform onafhankelijkheid, static typing, zeer grote api base. etc etc etc etc.

Trouwens ook ff wat: google kiest ook voor java. Maar niet alleen voor java.

Kort gezegd: je weet niet waar je over praat.

[polthemol]

meneer r, geen flauw idee waar jij ooit projectbeheer hebt gehad, maar mijn gok is dat het een LOI-cursus was, want wat een gigantische bullshit pleur je me daar in man -_-

[theskysurfer]

het schijnt dat het 'populaire' hyves.
ook gebruik maakt van RoR.
En als je de hyves site bekijkt, best leuk, maar traaaaaaaag. natuurlijk zijn er redelijk wat meer redenen voor.

Heb ooit een demo gezien, maar kon er zo 123 geen wijs uit.

(niet dat ik zo'n talent heb hoor... )

[ludo]

Hyves is gewoon PHP hoor

[Ajunne]

"een solide Java enterprise basis"? Je lijkt wel een marketeer...

Als iemand die betaald wordt om Java applicaties dag (en nacht) te ondersteunen weet ik wel hoe enterprise Java in elkaar zit. En op zich is het een goed platform, maar alleen als je echt zware dingen moet doen, die dan nog eens gelinkt zijn aan een hoop backend-systemen. Iets wat ik me bij Hyves moeilijk kan voorstellen. Voor zo'n setup blijft een PHP-site, eventueel gecombineerd met een goede database (en ik heb het dan niet over MySQL) toch de beste keus. Misschien moeten ze eens hun hardware upgraden, of een servertje erbij zetten. Of misschien moeten ze gewoon hun code optimaliseren...

[OMX2000]

The Painful & Horrible Performance versie

[flowerp]

Misschien moeten ze eens hun hardware upgraden, of een servertje erbij zetten.

Ik las eens ergens op Hyves of in een blog van die Koen dat ze 100'en(!) servers hadden staan, inderdaad wel allemaal MySQL natuurlijk.

Wat ik in PHP zie is dat men altijd de DB als 1 grote "state fetcher" gebruikt. PHP schaalt dus uitstekend zolang de DB het aankan. Elke request wordt de hele state uit de DB opgehaald en eventueel aan het einde daarvan weer terug gezet in de DB.

In Java (maar ook ASP.NET), zijn er veel meer mogelijkheden voor memory caches en het beheer daarvan. JPA (Java Persistance Architecture, uit het nieuwe Java 5) kan zeer intelligent bepalen wanneer er wel en niet een DB actie nodig is, en ook clustered caches als Coherence kunnen potentieel enorm veel latency wegnemen.

Nu is Coherence een zeer profesionele (lees ook dure) tool en als cache bijna een platform opzich zelf, maar zoiets heeft wel een bepaalde basis nodig om op te funtioneren. Zowel de technische als sociale eigenschappen van PHP maken dat zoiets als Coherence voor zover ik weet niet echt geschikt is daarvoor.

[flowerp]

Zou zo'n mega site als Hyves niet veel beter af zijn geweest als het op een solide Java enterprise basis was gebouwd?

PHP is natuurlijk heel goed voor tal van andere dingen, maar is Hyves nu niet net een voorbeeld waar Java beter geschikt is?

[mxcreep]

100'en servers ???
Dan mag degene die dat beheert zich wel heel erg schamen met die performance !

Voor PHP zijn overigens ook specifieke session servers beschikbaar om sessies over een heel park servers centraal te regelen en er zijn ook nog diverse Persistent Data Objecten beschikbaar die net als jij aangeeft intelligent omgaan met data van en naar database brengen. In Java zit het misschien allemaal net iets mooier samen in een doos, maar ook PHP kan gebruik maken van die opties.

[Anoniem: 42145]

100'en servers ???
Dan mag degene die dat beheert zich wel heel erg schamen met die performance

Valt misschien wel mee. Google heeft nog wel meer servers staan. Je moet het ook een beetje in verhoudingen zien. Hyves is zo'n beetje de grootste site van Nederland. Het kan in z'n eentje bijna het hele Nederlandse 'tiener' internet vervangen.

Dat van die 100'en servers heb ik ook gelezen. Stond inderdaad op Hyves vorig jaar. Toen klaagde iemand over performance en werd gezegd dat ze al 100 hadden staan en er net 100 bij gezet hadden. Dat is al weer lang geleden, dus het moet nu wel richting de 1000 gaan schat ik.

Bekijk je echter users/server dan valt het waarschijnlijk best mee.

[YopY]

Heb ooit een demo gezien, maar kon er zo 123 geen wijs uit.

Tsja, een ander nadeel van RoR is dat de beginnersdrempel een stukkie hoger ligt dan bij PHP (in mijn ervaring). Dit komt waarschijnlijk omdat het helemaal object-georiënteerd is, waar PHP vaak nog meer op de oude manier gebruikt wordt.

PHP is langzaamaan op weg om meer OO te worden, maar dat gaat waarschijnlijk nog wel even duren, denk ik.

Ik had er toen ik er (RoR) eerst mee begon ook best wel moeite mee, ik schreef de stukjes code uit het boek netjes over, maar uiteindelijk snapte ik er weinig van.

Een paar maanden later toen ik er opnieuw mee begon en een paar maanden OO-ervaring had (HBO informatica) snapte ik het al veel beter.

[Anoniem: 168910]

Je hebt je auto rij-lessen toch ook niet een Ferrari?

[Sagi]

"Misschien voor PHP, maar ik denk dat het bij veel selectieprocedures al snel afvalt als serieuze overweging voor bedrijfskritische enterprise-software."

Wat voegt het buzzword enterprise hier toe aan je comment? Enterprise in combinatie met kwaliteit van software is zo nietszeggend

Verder ben ik het helemaal eens met je comment, Java is voor meer bedoeld dan webapplicaties. Het is tamelijk logisch dat een framework totaal gericht op gebruik op het web voordelen biedt tov. een general purpose taal, goed punt!

[YopY]

Ruby is ook een all-purpose scripttaal, Rails is alleen een framework speciaal gericht op webapplicaties geschreven in Ruby.

(en om eerlijk te zijn, ik vind Ruby een tikkie mooier dan Java . Niets zeggend over de mogelijkheden of snelheid, gewoon de syntax)

[- peter -]

Ruby is de programmeertaal. Ruby on Rails het framework.

[Norjee]

Hmmm... wat is er dan wel niet met java aan de hand.

Een jaar geleden leek RoR idd je van het, inmiddels heb ik de indruk dat het (zowel het "platform" RoR als de "hype") allemaal behoorlijk stagneert.

RoR had een redelijk vooruitstrevende visie over hoe je MVC ook kon implementeren. Deze visie is inmiddels terug te vinden in alle alternatieve/andere talen (en eigenlijk was het al eerder in die talen, alleen de marketing was stukken minder handig).
RoR had een leuke ajax/js library, inmiddels zijn er meerdere js libraries, welke minstens zo goed zijn als prototype.

Maar RoR heeft ook serieuze problemen. Waar developers vroeger wegliepen van perl omdat het resulteerde in code-soep is heel RoR ook een machtige soep aan het worden. Het is altijd weer een verassing waar je de sourcecode voor een bepaalde functie terugvind, soms mag je meerdere bestanden doorspitten.
Ook is RoR, en ruby, nog lang niet volwassen. Het is leuk dat bijvoorbeeld voor de mysql adapter een simpele patch 30% performance winst kan geven, maar het had natuurlijk nooit gemogen dat die adapter extreem veel onnodige data bewaart.
En ook RoR zelf heeft zulke rare problemen, Active-Record is gewoon langzaam. Het opbouwen van queries wordt op geen enkele manier gecached, waardoor dit telkens opnieuw moet gebeuren. Zelf de query schrijven geeft weer betere performance, maar zou eigenlijk niet moeten. Idem voor die leuke url-mapper.
Een ander probleem is gerelateerd aan de spaghetti code en het ruby concept dat je alle classes / functies / whatever kan openbreken, en dat dit ook gestimuleerd wordt vanuit de RoR community. Hierdoor kun je heel makkelijk plugins maken. Echter, die plugins houden op te werken zodra iets uit de core van rails herschreven wordt. In de praktijk betekend het dat een groot gedeelte van de beschikbare extenties/plugins aangepast moeten worden om te werken met een nieuwe RoR versies. (zelfs al is die versie "slechts" een beveiliging update). Nodeloos te zeggen dat hierdoor veel plugins slechts werken voor 1 versie, waarna ze niet meer geüpdate worden.
Ook lijkt het mij enigszins naïef om te stellen dat performance geheel ondergeschikt is aan, laten we het de programeer beleving van de developer noemen. Tuurlijk, een nieuwe server erbij zetten lijkt makkelijk, maar als je concurrent door een ander platform te gebruiken domweg een snellere, responsievere, webapp aflevert kun je nog zoveel servers bijplaatsen, het blijft dweilen met de kraan (RoR) open.

Ik denk dat RoR zijn meest belangrijke wapenfeit al bereikt heeft, het is duidelijk dat er alternatieven boven struts/zope en meer oude garde frameworks zijn. Echter is in mijn ogen RoR niet de beste implementatie.

[smooc]

Mee eens. Ben nu aan het experimenteren mete JBOSS Seam + Ajax4jsf.

Wat een godsgeschenk, maar ik denk dat RoR best wel leuk is maar het nog wel even gaat duren voorat het stabiliteit en performance van Java heeft.

[addictive]

zie ook het RoR topic op GoT: http://gathering.tweakers.net/forum/list_messages/1035239

[m-m]

Het feit dat er een centraal RoR is zegt misschien genoeg over de populariteit.... Moet je eens alle Java topics gaan mergen tot een groot topic

[addictive]

en dan graag even vergelijken hoelang beide bestaan

[Fuzzillogic]

Ik ken Ruby verder niet echt. Sommige demootjes zagen er wel leuk uit. Weblog-ding in no-time in elkaar gooien. Maar vaak wil de klant net even wat anders en zul je toch buiten de standaardopties om moeten gaan.

PHP ken ik wel goed. En hoe meer ik het ken, hoe meer het mij tegenstaat; het is op veel plaatsen te beperkt, te sloom. Echt netjes programmeren, zoals je bij grote projecten wel haast moet, is lastig. Weaktyping helpt daar IMHO zeker NIET bij.

Java is full-fledged. Een volwaardig OO-systeem, met alles wat daarbij hoort, met een zeer uitgebreide standaardbibliotheek.

Misschien kun je met Ruby en PHP dan wel sneller tot resultaat komen, op een gegeven moment interesseert je die lage instapdrempel je ook niet meer en wil je gewoon relaxt kunnen programmeren, met profiling, testing en debugging zonder gedoe. Bij PHP is juist dat omslachtig. En gezien de leeftijf van Ruby gok ik dat dat ook nog niet al te uitgewerkt is.

[ludo]

Ik ken Ruby verder niet echt. Sommige demootjes zagen er wel leuk uit. Weblog-ding in no-time in elkaar gooien. Maar vaak wil de klant net even wat anders en zul je toch buiten de standaardopties om moeten gaan.

Dit is zóóóó'n übergrote misvatting over Ruby. Ruby is net zo OO als Java en een volwaardige programmeertaal. Álles dat jij in PHP, Java, of welke programmeertaal dan ook kan, kun je in Ruby net zo goed. Ik zou zeggen: werp er nog eens een blik op, en dan iets diepgaander dan die showcases waar jij het over hebt.

Ik heb in ieder geval het gevoel dat ik nu op de juiste trein zit En dit zeg ik na ruim 6 jaar ervaring met PHP (waar ik overigens ook nog steeds mee werk, maar werken met Ruby en Ruby on Rails geeft mij toch veel meer plezier).

En gezien de leeftijf van Ruby gok ik dat dat ook nog niet al te uitgewerkt is.

PHP is geboren in 1995, Ruby in 1993 En testing is een belangrijk (geïntegreerd) onderdeel van Ruby.

[Pruttelpot]

Php stamt uit 94 en is weer gebaseerd op perl, wat weer stamt uit 87.

[ludo]

Volgens de website van php zelf is het toch echt 1995 http://nl2.php.net/manual/en/history.php

En 'gebaseerd op' Perl is het ook niet echt hoor, zie ook bovenstaande link.

[Anoniem: 168910]

Met een dikke vette knipoog naar functionele programmeertalen zoals Haskell en en ML.

Denk aan zaken als First Class Functions en lambda's.

Het is ook niet verwonderlijk dat de Ruby interpreter zelf in ML geschreven is.

Het is dus een programmeertaal met the least-suprise-principle qua syntax, en de state-of-the-art- priniciple qua semantiek.

Een taal als ML is echt ongeloofelijke krachtig. Je kan met heel weinig code heel veel bereiken op een declaratieve en maintainable manier. De syntax zuigt alleen big time. En ja, juist als de semantiek expressiever is, is het belangrijk dat je kortere code net zo leesbaar is al de lange variant. Je zult in de praktijk in ML toch vergelijkbare code gaan schrijven als in Java of C, omdat leesbare code gewoon betere maintainability heeft.

Ruby is gericht op leesbare code. Er zijn ook van die van die zieke voorbeelden waar zelf niet programmeurs precies begrijpen wat er staat:

10.minutes.ago

10.times { say "hello" }

people.foreach { person | person.canRead ('Ruby') }

Toch blijft het heel lastig om werk te vinden, waar domme managers het risico aandurven. Ze wedden toch liever allemaal op het paard, waar ze allemaal op wedden. Het alternatief voor die managers zou dan ook alleen zijn om maar gewoon toe te geven dat ze het niet weten, en naar de mensen die het moeten implementeren luisteren.

Nog wat Rails candy:

Stel je maakt een model genaamd Person. Dan verwacht rails een tabel in je database genaamd People. (ja zo bijdehand is het: het kent de meervouds-vormen van het engels)

Stel die tabel People, heeft twee velden, name en gender.


girls = People.find_by_gender ('female');
girls.each { g | print g.name }

Of je doet meteen:

Person.find_by_gender ('female').each { g | print g.name
}

Merk op dat je hem niet verteld hebt dat een gender veld heeft. Hij kijkt gewoon in de database en maakt dan allerlei functies aan in de Person classe. Zoals find_by_gender en find_by_gender_and_name.

Stel je wilt een nieuw persoon aanmaken:

x = new Person
x.name = "Piet"
x.gender = "male"
x.save!

Besef dan dat je van SQL-backend kan wisselen zonder aanpassingen van je programma.

Stel dat je ook een Tabel genaamd Addresses hebt en dat je People tabel ook een veld address_id heeft.

Dan vertel je in je Person model de volgende zin:

:has_a address

Dan kun je opeens:

x.find_first_by_name ("Piet")
x.addres.street = "Kalverstraat 239"
x.save!

Dit soort meta-programming shit, waar de methodes van klassen tijdens het creeren van de klasse bepaald worden is een geniale vrijheid.

Zodra je je database structuur veranderd (je voegt een veld toe bijvoorbeeld), hebben je klasses meteen specifieke methodes om met dat veld te werken.

Hoe lui kan je zijn.

[al-ahlex]

Die ORM features die je aanhaalt zijn inderdaad allemaal heel leuk. ActiveRecord is echter op andere punten te beperkt om de volwassen ORM frameworks van Java te kunnen vervangen. Zo heb je geen invloed op hoe de data worden opgehaald uit de database ("fetch strategies" in hibernate), en is er niet zoiets als lazy initialisation.
Gevolg: heb je een Bestelling met meerdere BestellingLijn objecten eraan, dan worden die lijnen zowiezo mee opgehaald indien gedefinieerd als has_many. Pech als het toevallig over 100.000 bestellingen gaat, en er door de programmeur niets te tweaken valt!

Dit lijkt mij min of meer de algemene lijn met dit soort "too simple to be true!" frameworks. Je kan triviale dingen op een heel eenvoudige manier en 10 keer sneller verwezenlijken, maar het systeem schaalt niet of maar met veel moeite - zowel in volume van data als complexiteit van code.

[Terracotta]

Ruby is gebaseerd op Perl en Python.

[Pruttelpot]

Volgens die link van je:

" PHP succeeds an older product, named PHP/FI. PHP/FI was created by Rasmus Lerdorf in 1995, initially as a simple set of Perl scripts for tracking accesses to his online resume. "

Ennem:

"PHP werd in 1994 ontwikkeld door Rasmus Lerdorf. De eerste publieke versie werd uitgegeven in 1995"

[Anoniem: 168910]

In dat geval kun je puur voor dat attribute, has-many simuleren. Haal de has-many weg, en voeg een methode toe met als naam de naam van het field (in jouw geval denk ik bestelLijnen). In die methode haal de de jouw data op, met een BestelLijnen.find_by ( .. ) en return je het. Je kan ook nog een cache om de fetch-code heenzetten, zodat je het maximaal 1 keer per sessie/minuut/whatever ophaalt.

Maar ik geef toe dat om Rails te tweaken je voorbij de simpelheid moet gaan, en ook enigzins moet snappen hoe Ruby werkt en hoe Rails geimplementeerd is. (als je weet hoe Ruby werkt, dan snap je hoe Rails doet wat het doet)

Een vergelijkbaar moment waar ik deze truuk ook toepas, is met boolean fields. Ik stop ze meestal in de database als enum('true', 'false') waardes als die database engine geen natives booleans ondersteund. Dan heb ik een methode ala:

def activeUser? ()
.. controleer hier of activeUser == "true" return dan true, anders "false"...
end

Dan kan ik activeUser? direct gebruiken als een soort on-demand boolean field in if/when staments enzo.

[sys64738]

Ik hou me zowel met java als met ruby bezig. Ruby is in mijn ogen leuker en veel krachtiger (kwa taal). Helaas geld hier toch wel beetje "my strength is my weakness".

Doordat je alles op zoveel manier kunt doen (en er zoveel programmeer shortcuts zijn) is het lastig om iemand anders z'n code te lezen. Als je een stuk java in je handen geduwd krijgt, kun je vrij snel zien wat het doet. Bij ruby is dat een stuk lastiger, wat onderhoud niet vereenvoudigd.

Tuurlijk kun je met duidelijk documenteren (ruby heeft ook soort javadoc tool) dit voorkomen. Maar ja, je weet hoe dat gaat... zelf documenteren we tuurlijk altijd alles, maar die andere developers hè,,,

[Anoniem: 168910]

Leesbaarheid is overrated.
Modularisatie niet.

Het is belangrijker dat je collega programmeur kan vinden waar een bepaald stukje code staat, dan of hij 2 ipv 10 seconden naar die code moet staren als hij het eenmaal gevonden heeft.

[flowerp]

Met de steeds verder gevorderde ontwikkeling van het .net framework en van Mono is C# steeds al meer de grote concurrent van java.

Aan de ene kant is .NET inderdaad de grote concurent van Java. Ze richten zich allebij meer op de bovenkant van de markt en proberen een meer profesioneel/hoger opgeleide developer aan te spreken.

Vanuit de developer gezien zou ik .NET/C# en Java/Java meer als collega's zien. Juist omdat ze in veel aspecten zo gelijk zijn, kan ik zo overstappen tussen de 2 zonder dat ik een radicaal andere aanpak moet kiezen. Kijk je bijvoorbeeld naar alleen de talen Java en C# dan lijken die al als 2 druppels water op elkaar. Neem je dat ook het (web) platform erbij, dan zie je dat ASP.NET en JSF ook al weer sprekend op elkaar lijken.

[Olaf van der Spek]

Dit probleem is volgens Ruby-programmeurs echter onbelangrijk omdat de ontwikkeltijd van een RoR-applicatie duidelijk lager is en de extra kosten voor rekencapaciteit minder zijn dan de kosten voor de extra ontwikkeltijd die een Java-applicatie vergt.

Eh, dat ligt er natuurlijk maar net aan hoe vaak je die applicatie draait en hoeveel requests er verwerkt moeten worden.
Als je 10x zoveel servers nodig hebt gedurende enkele jaren, dan zou ik het wel weten.

[Cameleon73]

Ach, dan hebben we altijd nog JRuby. Peace on earth!

[Mr_Light]

meer onder dit punt;
Ik zie ze eerder elkaar versterken dan aan elkaar afdoen.

liefde alom hoor, ik deel de mening over het alg de mening van mensen die aan het onderzoek meededen dus niet.

[Anoniem: 146114]

Interessante stelling, maar het lijkt me een beetje optimistisch ingeschat door de Rails-fans. RoR heeft een nieuwe standaard neergezet voor webontwikkeling, maar de standaard Rails-applicatie begeeft zich toch op een heel ander vlak dan de J2EE-applicatie.

Het is hier al vaker gezegd, Rails is toch vooral een concurrent van PHP aan het worden. Maar ook daar is de strijd nog niet gestreden. Een PHP-site kan je overal hosten, voor Rails moet je nog naar specialisten. Het zal nog wel enige jaren duren eer Rails in de buurt komt van PHP.