keuze ruby on rails en php

[chuxiej]

Hoi Allemaal,

De afgelopen maanden ben ik bezig geweest met het leren van ruby on rails.
Ik begin het best redelijk onder de knie te krijgen en heb al een paar (eigen) projectjes afgerond.
Nu is mij gevraagd om een centraal winkeladministratie en verkoop systeem te maken voor een keten met meerdere filialen.
Ik zou dit project erg graag met RoR willen maken alleen kamp ik met een aantal vragen:
- hoe stabiel is mongrel_cluster (ik heb namelijk een paar keer gehad dat ik de server opnieuw moest starten omdat deze gecrashed was)
- hoe snel is mongrel_cluster / RoR i.s.m. apache2 mod_proxy en statische files gewoon door apache te laden
- is RoR wel een goede keuze voor een een applicatie als deze.
Het zou een grote ramp zijn als bv de server crashed.

Vast bedankt voor de hulp.

[SchizoDuckie]

Ik heb totaal geen kennis van RoR, maar ik kwam dit relevante artikeltje zojuist tegen van SitePoint:

http://www.sitepoint.com/...sh-resolution-more-flame/

imho is RoR gewoon nog té beta

[ Voor 9% gewijzigd door SchizoDuckie op 02-01-2008 17:49 ]

[MisterBlue]

SchizoDuckie schreef op woensdag 02 januari 2008 @ 17:49:
Ik heb totaal geen kennis van RoR, maar ik kwam dit relevante artikeltje zojuist tegen van SitePoint:

http://www.sitepoint.com/...sh-resolution-more-flame/

imho is RoR gewoon nog té beta

Interessante 'rant' van de maker van mongrel welke ondanks zijn zeer aggressieve stijl misschien wel serieus genomen moet worden.
Je geeft echter aan dat je totaal geen kennis van RoR hebt en het desondanks toch nog te beta vind. Is dat gebaseerd op deze link alleen?

[Kanarie]

Die rant is inderdaad van de originele ontwikkelaar van mongrel, echter Mongrel wordt tegenwoordig door anderen ontwikkeld.

Als je Mongrel snel wilt serveren i.c.m. statische files moet je eens kijken naar nginx.
De stabiliteit van Mongrel is naar mijn ervaring perfect, maar of Rails voor jouw project geschikt is zou ik aan de hand van je omschrijving niet durven zeggen.

[SchizoDuckie]

MisterBlue schreef op woensdag 02 januari 2008 @ 18:32:
[...]

Interessante 'rant' van de maker van mongrel welke ondanks zijn zeer aggressieve stijl misschien wel serieus genomen moet worden.
Je geeft echter aan dat je totaal geen kennis van RoR hebt en het desondanks toch nog te beta vind. Is dat gebaseerd op deze link alleen?

Nee, deze link geeft vat zo ongeveer mijn gedachtes over RoR samen. Het is iets wat mensen bedacht hebben, wat op zich leuk in elkaar zit maar wat ook een berg quirks heeft. Verder zegt iedereen en zn broertje dat ze 'iets met RoR' gaan doen, en zijn er een hoop consultants die ineens 'experts' hebben maar ik ken weinig tot geen sites die ook *echt* van voor tot achter op RoR gebaseerd zijn omdat je als je ook maar iets wilt doen wat niet binnen het framework past, je een hele wereld van shit over je heen krijgt. Ken je het verhaal over CdBaby?

Begrijp me niet verkeerd. Een hele hoop ideën die in RoR zitten zijn echt gewoon goed. Ik heb niet voor nix mijn eigen php framework ook 'PHP On Rails (Kinda) / P.O.R.K' genoemd omdat ik wat ideeën zoals de scaffolding en de ORM geleend heb en zeer losjes geimplementeerd heb naar wat ik zag in de demo vids van RoR. Uiteindelijk is de core van al mijn PHP programmeerwerk nu een 500 regels tellende PHP class, en dat is dan de ORM én Active Record in één. De rest van de *gigantische* lib van rails heb ik me dus niet in verdiept omdat het té uitgebreid is naar mijn zin, je met een standaard directory structuur zit die iemand verzonnen heeft waar ik me niet in kan vinden en te beta qua het zich bewezen hebben

[ Voor 26% gewijzigd door SchizoDuckie op 02-01-2008 19:05 ]

[Nielsvr]

Als je de mogelijkheid hebt zelf de project omgeving op te zetten, zeker voor Ruby on Rails gaan. In combinatie met lighthttp is hiermee een zeer stabiele omgeving mee te creëren (voor mijn projecten waar honderden actieve gebruikers tegelijk online kunnen zien, en redelijke intensieve acties uitvoeren blijft lighthttp prima overeind, waar apache2 keihard crashde met de app in PHP). Ruby on Rails is een echte applicatie programmeer taal. En daar hebben we het nu over. PHP zelf vind ik goed voor kleine websites e.d., maar voor het grote werk zou ik grijpen aan ruby.

Ben er nu een groot intranet applicatie mee aan het ontwikkelen, en dit bevalt mij beter dan de versie die ik momenteel in PHP heb draaien. Niet alleen qua performance, maar ook qua opzet voor iemand die eventueel het project moet overnemen of beheren.

@hieronder die weinig websites in RoR ziet, de taal wordt momenteel veel gebruikt voor indoor applicaties, zoals intranet's / extranet's, winkel applicaties maar ook grote internet applicaties zoals:

http://www.alistapart.com/
http://www.jobster.com/
http://www.basecamphq.com/
http://www.gonutshell.com/
http://www.43things.com/
http://www.typosphere.org/

[ Voor 31% gewijzigd door Nielsvr op 02-01-2008 18:52 ]

[FragFrog]

Ikzelf ken natuurlijk alleen de andere kant van het verhaal, maar dat zegt op zich al aardig wat: PHP bestaat nu grofweg 13 jaar. RoR ongeveer 3. PHP wordt door miljoenen sites gebruikt, van RoR weet ik het slechts van een handvol. Waar zou jij op vertrouwen voor een bedrijfskritisch platform?

Persoonlijke ervaring (gevaarlijk om daar conclussies uit te trekken maar vooruit) is dat ik nog -nooit- heb meegemaakt dat een PHP script wat werkt er plotseling voor zorgt dat een server crashed, hoe brak het ook was- ergste wat ik ooit voor elkaar gekregen heb is een gecrashde Apache toen ik een mooie recursieve functie had geschreven die in een infinite loop belande, maar zelfs daar herstelde Apache zelf prima van. Als jij nu met RoR in -naar ik gok- relatief simpelere projecten al crashes tegenkomt zou ik toch gaan twijfelen

[Kanarie]

SchizoDuckie schreef op woensdag 02 januari 2008 @ 18:40:
Ken je het verhaal over CdBaby?

Begrijp me niet verkeerd. Een hele hoop ideën die in RoR zitten zijn echt gewoon goed. Ik heb niet voor nix mijn eigen php framework ook 'PHP On Rails (Kinda) / P.O.R.K' genoemd omdat ik wat ideeën zoals de scaffolding geleend heb.

Het CDBaby verhaal is nogal scheef. Het gaat hier om iemand die een succesvolle PHP website heeft, deze zelf geprogrammeerd heeft. Tijdens het herschrijven in RoR komt hij erachter dat hij beter de ideeen uit Rails kan overnemen en de site opnieuw te maken in PHP.
Dat je 'scaffolding' noemt als idee dat je over hebt genomen uit Rails spreekt imo boekdelen. Dat lijkt aan te geven (nofi, misschien heb je een ongelukkig voorbeeld gekozen) dat je niet weet wat er 'goed' is aan Rails (of Django, CakePHP, vul je favo MVC framework in).

[ Voor 0% gewijzigd door Kanarie op 02-01-2008 19:00 . Reden: Gequote post werd aangepast ]

[Stephan11117]

Nielsvr schreef op woensdag 02 januari 2008 @ 18:44:
http://www.alistapart.com/
http://www.jobster.com/
http://www.basecamphq.com/
http://www.gonutshell.com/
http://www.43things.com/
http://www.typosphere.org/

Voeg ik daar even aan toe:
http://waarnaartoe.nl
http://nakko.com
http://skiq.nl
http://www.afvalbakken.nl
http://www.sterrenzoekensterren.nl

Deze sites draaien allen onderr een mongel-cluster op een CentOS machine. Apache staat ingesteld op enkel proxyen naar het cluster dmv mod-proxy-balancer. Draait bijzonder stabiel!

[ Voor 17% gewijzigd door een moderator op 02-01-2008 23:03 ]

[Creepy]

Eeh, opsommen van sites die ergens op draaien voegen nu niet zo heel veel toe aan het PHP vs RoR gebeuren. Als je al sites noemt onderbouw dan in elk geval waarom er voor die sites is gekozen voor PHP of RoR en niet voor de andere taal

[ Voor 7% gewijzigd door Creepy op 02-01-2008 23:03 ]

[Kanarie]

Misschien ook handig om niet een framework tegenover een taal te zetten, maar Ruby on Rails te vergelijken met PHP frameworks (bijv. Symfony en CakePHP)

[Verwijderd]

IMHO:

Ik zou gaan voor PHP, waarom:

PHP is in de hoofdlijnen gebaseerd op de syntax van de bekende C taal, de meest gebruikte programmeertaal ooit. C is zo populair met een goede reden natuurlijk, de syntax is natuurlijk, eenvoudig te begrijpen en heeft een duidelijke structuur.

PHP is natuurlijk geen C, sterker nog, vaak denk je dat de bedenkers van PHP de grote hoofdlijnen van C helemaal nooit begrepen hebben en daarom hele rare dingen doen. Toch lijkt het er veel op.
Dit heeft tot effect dat als je ervaren bent in een van de vele C dialecten je erg eenvoudig PHP zult oppikken, even snel de manual skimmen voor de belangrijkste basisfuncties en je kunt aan de gang.
Ook later wanneer je bijvoorbeeld wilt beginnen aan C# helpt de ervaring met de C achtige PHP.

Ruby echter is een obscuur taaltje, een erg mooie taal, maar weinig gebruikt. Het leent eea van bijvoorbeeld Perl en Python, beide zeer complexe talen die niet iedereen zomaar oppikt.

Hoewel het voor je eigen ontwikkeling erg goed is als je eens wat kijkt bij andere talen en frameworks help je jezelf niet zo gek veel mee en mocht Ruby of RoR ooit stopgezet worden dan houdt het een beetje op.

IMHO is dezelfde functionaliteit als in RoR ook te vinden in menig PHP framework wat het MVC model volgt. Als je dan bekijkt dat PHP een veel grotere community heeft en veel actiever ontwikkeld wordt, perfecte integratie met bijvoorbeeld Apache en mega veel uitbreidingen dan lijkt me de keuze makkelijk.

Ruby is dus een zeer mooie taal waar je zeker heel veel mee kunt doen, echter zegt dat (zoals vaak) helemaal niets over of het de beste keuze is in een praktische situatie.

[MisterBlue]

Los van of een gebruikte technologie geschikt is voor een applicatie, zou ik geen bedrijfskritische applicatie maken in een technologie waar je nog niet voldoende vertrouwd in ben. Als je meer vertrouwd ben in PHP zou ik dat gewoon gebruiken. Als het om het even is, zou ik zelf voor Ruby/RoR gaan. Daar ligt op dit moment toch het momentum. Het groeit het snelst in populariteit en veel nieuwe ontwikkelingen zoals behaviour driven development en het ontwikkelen van domain specific languages vinden nu daar plaats.

[RayNbow]

Verwijderd schreef op woensdag 02 januari 2008 @ 23:49:
PHP is in de hoofdlijnen gebaseerd op de syntax van de bekende C Perl taal,

PHP is eerder een voortvloeisel van Perl, wat veel gebruikt werd (wordt?) op het web. Vandaar ook veel overeenkomende eigenschappen als weaktyping en die rare $-tekens voor variabelen.

(C...), de meest gebruikte programmeertaal ooit.

Ik trek in twijfel of C de meest gebruikte taal is... Er is veel legacy code op deze aardkloot te vinden. Tevens is het lastig om het gebruik van een taal te bepalen. Ik bedoel, welke taal in dit diagram is het meest gebruikt?

C is zo populair met een goede reden natuurlijk, de syntax is natuurlijk, eenvoudig te begrijpen en heeft een duidelijke structuur.

C is niet populair vanwege de syntax. De populariteit zou je eerder kunnen toeschrijven aan dat het toentertijd wat higher level dan assembly was, maar dat je nog steeds system level software erin kon schrijven. Dit is ook de filosofie van C:

"C is an imperative (procedural) systems implementation language. Its design goals were for it to be compiled using a relatively straightforward compiler, provide low-level access to memory, provide language constructs that map efficiently to machine instructions, and require minimal run-time support. C was therefore useful for many applications that had formerly been coded in assembly language."
(bron)

De syntax is tevens alles behalve "natuurlijk" en "eenvoudig". Veel beginners gruwelen eigenlijk van de syntax in het begin. Toen ik 10 jaar geleden of zo voor 't eerst C code zag stond ik iig niet te springen. De C syntax wordt op een gegeven moment "natuurlijk" en "eenvoudig".

PHP is natuurlijk geen C, sterker nog, vaak denk je dat de bedenkers van PHP de grote hoofdlijnen van C helemaal nooit begrepen hebben en daarom hele rare dingen doen. Toch lijkt het er veel op.
Dit heeft tot effect dat als je ervaren bent in een van de vele C dialecten je erg eenvoudig PHP zult oppikken, even snel de manual skimmen voor de belangrijkste basisfuncties en je kunt aan de gang.

Dat je snel PHP kunt oppikken als je al een C-style taal kent komt denk ik eerder door het feit dat je dan al imperatief kunt programmeren en de C-style syntax kunt lezen.

Ook later wanneer je bijvoorbeeld wilt beginnen aan C# helpt de ervaring met de C achtige PHP.

C# is eigenlijk voornamelijk gefocust op object georienteerd programmeren, waarbij PHP die nadruk niet ligt. Natuurlijk kan elke programmeringervaring wat bijdragen, maar je dan wel inzien dat bepaalde dingen die je in PHP leert misschien niet zo netjes zijn of weinig waarde hebben in een andere taal. Denk aan verschillen tussen strong/weak typing, static/dynamic typing, etc.

Ruby echter is een obscuur taaltje,

Ik ben zelf geen fan van de syntax, maar ik heb momenteel ook niet de interesses om een taal zoals Ruby te leren.

een erg mooie taal, maar weinig gebruikt. Het leent eea van bijvoorbeeld Perl en Python, beide zeer complexe talen die niet iedereen zomaar oppikt.

Wat vind jij complex aan Perl en Python? (Ok, van Perl kan ik me de syntax voorstellen en de verschrikkelijke obfuscated one-liners )

Hoewel het voor je eigen ontwikkeling erg goed is als je eens wat kijkt bij andere talen en frameworks help je jezelf niet zo gek veel mee en mocht Ruby of RoR ooit stopgezet worden dan houdt het een beetje op.

Hetzelfde geldt voor PHP. Als dat niet meer onderhouden wordt, dan heb je ook een probleem.

IMHO is dezelfde functionaliteit als in RoR ook te vinden in menig PHP framework wat het MVC model volgt.

Een aantal PHP MVC frameworks hebben heel veel van het Rails framework afgekeken.

Als je dan bekijkt dat PHP een veel grotere community heeft en veel actiever ontwikkeld wordt,

PHP heeft misschien meer gebruikers dan Ruby, maar dit komt voornamelijk omdat tegenwoordig elke webhost PHP ondersteuning heeft. De toegangsdrempel is dus ook lager. De vraag is, wat heb je aan een grotere community als er ook veel beginners in die community zitten? Ik heb niets tegen beginners, maar PHP heeft het imago dat er veel prutsers zijn die slechte code produceren en dat andere beginners dit weer overnemen, etc. (Natuurlijk zijn er ook goede proggers in de PHP community)

perfecte integratie met bijvoorbeeld Apache en mega veel uitbreidingen dan lijkt me de keuze makkelijk.

Sommige PHP versies hebben ruzie met sommige Apache versies, dus van een perfecte integratie zou ik niet spreken.

Ruby is dus een zeer mooie taal waar je zeker heel veel mee kunt doen, echter zegt dat (zoals vaak) helemaal niets over of het de beste keuze is in een praktische situatie.

Dat kan je van elke taal zeggen. In het geval van de TS is het belangrijkste wat de beschikbare kennis is van de te kiezen taal binnen het filiaal (zeer belangrijk voor de toekomst) en wat de beperkingen zijn van bijv. de depoyment. Als het niet mogelijk is om Ruby te draaien omdat de servers niet onder eigen beheer zijn, dan houdt 't op.

[chuxiej]

Iedereen heel erg bedankt voor de reacties.

Wij hebben beschikking tot een eigen server dus RoR hosten is geen probleem.
Wat mijn grootste obstakel is, is de snelheid waarmee mijn rails applicaties laden.
Ik merk wel een duidelijke snelheidswinst als de app in de production env. draaid ipv. development.
Toch is de responsetijd bij mij erg langzaam, zie bv. www.conquer.nl.
Ik draai deze op een mongrel_cluster met 3 mongrel processes verdeeld via mod_proxy van apache2.

Ik geef MisterBlue erg gelijk om een bedrijfskritische applicatie te maken in de taal waar je de meeste ervaring en kennis van hebt.
Toch vind ik het echt verschrikkelijk om grotere applicaties te maken in PHP al heb ik mijn eigen geschreven framework gebaseerd op MVC, dit is ook de grootste reden waarom ik voor RoR wil kiezen.

[Kanarie]

chuxiej schreef op donderdag 03 januari 2008 @ 11:33:
Iedereen heel erg bedankt voor de reacties.

Wij hebben beschikking tot een eigen server dus RoR hosten is geen probleem.
Wat mijn grootste obstakel is, is de snelheid waarmee mijn rails applicaties laden.
Ik merk wel een duidelijke snelheidswinst als de app in de production env. draaid ipv. development.

Development environment doet niet aan caching. Als je meer snelheid in je production wil moet je wat grondiger naar caching kijken.

Toch is de responsetijd bij mij erg langzaam, zie bv. www.conquer.nl.
Ik draai deze op een mongrel_cluster met 3 mongrel processes verdeeld via mod_proxy van apache2.

Laat je statische zaken (plaatjes, javascripts) ook serveren door Apache2? Apache2 is namelijk sneller hierin.
Draai ook eens YSlow van Yahoo over je site, daar kun je goed in zien welke optimalisaties je nog kunt doorvoeren (minder HTTP requests, Javascript minifyen, Gzippen, etc).
Tevens is de site bij een schone cache een flinke 611KB groot. Vergelijk dat eens met de 129KB van Tweakers.net

Het valt me ook op dat alle 'kopjes' en buttons op de site aparte plaatjes zijn (zelfs hover/unhover plaatjes). Alle knoppen van je navbar hebben dezelfde achtergrond met een andere tekst. 7 knoppen met elk 2 images.Kun je ook met 2 images (hover/unhover) en 'plain-text' doen.
Ook de kopjes aan de rechterkant "User panel", "Head sponsor", zijn verschillende plaatjes, terwijl het telkens hetzelfde plaatje is met een andere tekst.

Met een download van 611KB zou ik dus eerst kijken naar de client-wacht tijden voordat je je server configuratie gaat tweaken.

Nog even terugkomend op de vraag uit je topicstart betr. mod_proxy en statische files: Kijk eens naar nginx icm met Mongrel ipv Apache2.

[ Voor 28% gewijzigd door Kanarie op 03-01-2008 12:01 ]

[M-ThijZ]

De keuze tussen Ruby en PHP is heel persoonlijk. Kies voor de omgeving waar jij je het fijnst bij voelt. Persoonlijk zou ik voor Rails kiezen (of merb), dat is omdat ik al een tijd in Ruby programmeer en weet waar ik mee bezig ben. Ik kom niet zomaar voor verassingen te staan en weet waar ik op moet letten.
Mede door de leuke Ruby/Rails gemeenschap vind ik het leuk om in Ruby te programmeren, maar de keuze is echt persoonlijk.
Ik denk dat er in elke taal iets te bouwen valt wat een oplossing biedt voor je probleem, zo lang je maar gepassioneerd en dus gemotiveerd blijft.
Dat gaat met de ene omgeving makkelijker dan met de ander.

[FragFrog]

RayNbow schreef op donderdag 03 januari 2008 @ 01:34:
PHP is eerder een voortvloeisel van Perl, wat veel gebruikt werd (wordt?) op het web. Vandaar ook veel overeenkomende eigenschappen als weaktyping en die rare $-tekens voor variabelen.

PHP was written as a set of Common Gateway Interface (CGI) binaries in the C programming language by the Danish/Greenlandic programmer Rasmus Lerdorf in 1994, to replace a small set of Perl scripts he had been using to maintain his personal homepage.[3]

Als je naar de PHP syntax kijkt zie je heel duidelijk de C invloeden daarin, er zijn tientallen standaard functies uit C die met nagenoeg dezelfde syntax ook in PHP bestaan. Ook qua taalstructuur is PHP bijna hetzelfde.

Ik heb vrij weinig ervaring met C++, maar wat ik aan ervaring hebt geeft me de indruk dat PHP 5 daar nog het allermeest op lijkt qua taal. Grote verschillen zijn het gebrek aan namespaces (wat naar ik meen in PHP6 goed gaat komen), de $ variabele prefix en natuurlijk weak vs strongtyped, maar afgezien daarvan kun je echt netjes geschreven PHP code bijna letterlijk compilen in C++. Zoals gezegd, ik pruts af en toe wat aan in die hoek en hoe meer ik OO code in PHP des te beter ik ook C++ begin te begrijpen. Maargoed, dit is allemaal meer een argument voor het kiezen van een taal om te leren, niet voor de keuze welke taal die je al kent je moet gebruiken

[ Voor 8% gewijzigd door FragFrog op 03-01-2008 12:35 ]

[RayNbow]

FragFrog schreef op donderdag 03 januari 2008 @ 12:32:
[...]


[...]


Als je naar de PHP syntax kijkt zie je heel duidelijk de C invloeden daarin, er zijn tientallen standaard functies uit C die met nagenoeg dezelfde syntax ook in PHP bestaan. Ook qua taalstructuur is PHP bijna hetzelfde.

Er staat ook dat PHP geschreven werd om wat Perl scripts te vervangen? Verder zie je in 't eerder gelinkte diagram dat C invloed heeft gehad op Perl en dat Perl invloed heeft gehad op PHP. Je kunt dus beter zeggen dat PHP beinvloed is door Perl aangezien deze wat dichter bij PHP staat.

[Verwijderd]

Ik was niet van plan een discussie over PHP te starten, enkel mijn advies te geven aan de TS, maar aangezien er een reactie op is gegeven zal ik toch even reageren, dit is geen topic kaap poging ofzo.

RayNbow schreef op donderdag 03 januari 2008 @ 01:34:
[...]

PHP is eerder een voortvloeisel van Perl, wat veel gebruikt werd (wordt?) op het web. Vandaar ook veel overeenkomende eigenschappen als weaktyping en die rare $-tekens voor variabelen.

Hoewel PHP zeker wat dingen uit Perl heeft geleend is het toch primair gebaseerd op de C syntax. Dit is ook nogal logisch aangezien ook Perl gebaseerd is op de C syntax.

[...]

Ik trek in twijfel of C de meest gebruikte taal is... Er is veel legacy code op deze aardkloot te vinden. Tevens is het lastig om het gebruik van een taal te bepalen. Ik bedoel, welke taal in dit diagram is het meest gebruikt?

Natuurlijk is het bijna onmogelijk om te bepalen wat precies de meestgebruikte taal is, toch zie je dat er extreem veel in C gemaakt is. Welke taal (incl aftreksels van de taal) zou jij dan aan willen geven als meest gebruikte?

Zeker in het gebied van consumenten software (wat toch de grootste markt is qua hoeveelheid software en dus de grootste kans dat een programmeur werkzaam in is) dan zie je dat ongeveer alles vanuit Microsoft en het gros van de Linux software gebaseerd is op C.

[...]

C is niet populair vanwege de syntax. De populariteit zou je eerder kunnen toeschrijven aan dat het toentertijd wat higher level dan assembly was, maar dat je nog steeds system level software erin kon schrijven. Dit is ook de filosofie van C:

De syntax is tevens alles behalve "natuurlijk" en "eenvoudig". Veel beginners gruwelen eigenlijk van de syntax in het begin. Toen ik 10 jaar geleden of zo voor 't eerst C code zag stond ik iig niet te springen. De C syntax wordt op een gegeven moment "natuurlijk" en "eenvoudig".

C is natuurlijk wel zo populair vanwege de syntax, er waren meer dan genoeg hogere talen beschikbaar in de begintijden, ook met een vergelijkbare filosofie, denk aan Pascal en Basic, maar ook FOTRAN, COBOL en Prolog.

C is de enige die door de tijden heen nog steeds zeer intensief gebruikt wordt.

Dat de syntax natuurlijk en eenvoudig is is natuurlijk relatief en subjectief, ook moet je bepaalde rare uitzonderingen niet verwarren met de basis syntax. Zo is het hele concept van pointers iets waar veel beginnende C programmeurs moeite mee hebben, maar dat heeft natuurlijk niets met de daadwerkelijke syntax te maken.

C# is eigenlijk voornamelijk gefocust op object georienteerd programmeren, waarbij PHP die nadruk niet ligt. Natuurlijk kan elke programmeringervaring wat bijdragen, maar je dan wel inzien dat bepaalde dingen die je in PHP leert misschien niet zo netjes zijn of weinig waarde hebben in een andere taal. Denk aan verschillen tussen strong/weak typing, static/dynamic typing, etc.

Natuurlijk, PHP heeft een zeer slecht object model, sterker nog, het is amper OOP te noemen.

Toch ben je al wel gewend met de concepten, heb je gezien waar de limitaties liggen en is het natuurlijk alleen maar goed dat bepaalde limitaties wegvallen.

Dat er verschillen zitten tussen de verschillende talen is bij alle talen natuurlijk het geval, dus het lijkt me niet relavant voor de discussie verder

Wat vind jij complex aan Perl en Python? (Ok, van Perl kan ik me de syntax voorstellen en de verschrikkelijke obfuscated one-liners )

Perl heeft inderdaad een erg lastig te begrijpen syntax, daarnaast steunt het vaak hevig op reguliere expressies, een concept niet eenvoudig te begrijpen.

Python is erg minimalistisch van opzet, dit maakt de taal erg lastig om te leren en lezen als beginner.

Ook zie ik hier wederom niet in hoe dit relevant is voor de discussie van de TS?

[...]
Hetzelfde geldt voor PHP. Als dat niet meer onderhouden wordt, dan heb je ook een probleem.

Hoe groter de community hoe kleiner de kans dat het niet meer onderhouden wordt, daarnaast is de kans dan veel groter dat er een nieuw dialect komt of een dialect al bestaat waarmee je eenvoudig verder kunt.

[...]
Een aantal PHP MVC frameworks hebben heel veel van het Rails framework afgekeken.

Daag
Want Rails is het eerste framework wat op deze manier werkt wil je zeggen? De concepten erachter zijn al zou oud als de kont van Sinterklaas en worden gebruikt in talloze frameworks.

[...]
PHP heeft misschien meer gebruikers dan Ruby, maar dit komt voornamelijk omdat tegenwoordig elke webhost PHP ondersteuning heeft. De toegangsdrempel is dus ook lager. De vraag is, wat heb je aan een grotere community als er ook veel beginners in die community zitten? Ik heb niets tegen beginners, maar PHP heeft het imago dat er veel prutsers zijn die slechte code produceren en dat andere beginners dit weer overnemen, etc. (Natuurlijk zijn er ook goede proggers in de PHP community)

De toegankelijkheid van een taal lijkt me juist een zeer sterk punt voor de TS om juist voor PHP te kiezen. Wat probeer je hiermee nu te zeggen? Dat als je PHP programmeert je een prutser bent en als je Ruby programmeert je dat per definitie niet zal zijn?

Sommige PHP versies hebben ruzie met sommige Apache versies, dus van een perfecte integratie zou ik niet spreken.

Dus? Perfecte integratie bestaat niet, thanks Captain Obvious...

[Wolfboy]

Verwijderd schreef op donderdag 03 januari 2008 @ 14:38:
Hoewel PHP zeker wat dingen uit Perl heeft geleend is het toch primair gebaseerd op de C syntax. Dit is ook nogal logisch aangezien ook Perl gebaseerd is op de C syntax.

Als je naar je eigen logica kijkt dan kan ik afleiden dat Perl primair gebaseerd is op C, en PHP primair gebaseerd is op Perl. Hieruit volgt uiteraard dat PHP indirect gebaseerd is op C (al zit er m.i. een flink verschil tussen C en PHP, teveel om het "gebaseerd op" te noemen).

Ja, er zijn een aantal modules direct gebaseerd op de C syntax, maar dat is meer omdat de PHP developers PHP ook in C geschreven hebben en die functies dus direct aan te roepen zijn. Op die manier kan je van ladingen talen zeggen dat ze gebaseerd zijn op C.

Natuurlijk is het bijna onmogelijk om te bepalen wat precies de meestgebruikte taal is, toch zie je dat er extreem veel in C gemaakt is. Welke taal (incl aftreksels van de taal) zou jij dan aan willen geven als meest gebruikte?

Mijn vermoeden is dat (op dit moment) Java ergens bovenaan het lijstje staat, de vraag is uiteraard wat jij "aftreksels van de taal" noemt, als dat elke taal met de C syntax (brackets, puntcomma, etc.) is, dan zal het wel de nummer 1 taal zijn ja.

Zeker in het gebied van consumenten software (wat toch de grootste markt is qua hoeveelheid software en dus de grootste kans dat een programmeur werkzaam in is) dan zie je dat ongeveer alles vanuit Microsoft en het gros van de Linux software gebaseerd is op C.

Dan hangt het er weer vanaf wat je onder meest populaire taal verstaat. Een taal waar veel mensen nu in schrijven, of een taal waar veel mensen in geschreven hebben. Er is ladingen C code te vinden in zowel Windows als Linux, maar hoeveel veranderd daar nog in? Er is ook heel veel code geschreven in C++, Fortran en andere talen. Om nog maar niet te spreken van de beweging naar scripttalen die duidelijk te zien is onder Linux.

C is natuurlijk wel zo populair vanwege de syntax, er waren meer dan genoeg hogere talen beschikbaar in de begintijden, ook met een vergelijkbare filosofie, denk aan Pascal en Basic, maar ook FOTRAN, COBOL en Prolog.

C is de enige die door de tijden heen nog steeds zeer intensief gebruikt wordt.

Vertel dat maar eens tegen de ladingen COBOL, Delphi en Fortran programmeurs. Of het er meer of minder zijn dan de C programmeurs durf ik niet te zeggen, maar om te zeggen dat C de enige taal is die door de tijden heen veel gebruikt is en nog steeds veel gebruikt wordt gaat me te ver. Dat is _echt_ niet correct.

Dat de syntax natuurlijk en eenvoudig is is natuurlijk relatief en subjectief, ook moet je bepaalde rare uitzonderingen niet verwarren met de basis syntax. Zo is het hele concept van pointers iets waar veel beginnende C programmeurs moeite mee hebben, maar dat heeft natuurlijk niets met de daadwerkelijke syntax te maken.

Uiteraard wel, zonder pointers kan je niet eens een array doorsturen naar een functie en moet je het dus bij globals houden. Je kan jezelf onmogelijk C programmeur noemen als je niet begrijpt hoe pointers werken. De C syntax is toch niet echt eenvoudig te noemen, misschien als je het vergelijkt met Fortran en COBOL, maar de Basic varianten zijn toch echt eenvoudiger voor de beginner.

Python is erg minimalistisch van opzet, dit maakt de taal erg lastig om te leren en lezen als beginner.

Ook zie ik hier wederom niet in hoe dit relevant is voor de discussie van de TS?

Python moeilijk leesbaar?...

Python is een van de weinige talen die ik aan non-programmeurs kan laten zien waarbij ze de essentie van een functie kunnen begrijpen. Om dit minimalisitisch te noemen vind ik wel erg overdreven... Python is juist erg eenvoudig leesbaar doordat er geen obscure dingen als || en && gebruikt worden maar gewoon "and" en "or".

Hoe groter de community hoe kleiner de kans dat het niet meer onderhouden wordt, daarnaast is de kans dan veel groter dat er een nieuw dialect komt of een dialect al bestaat waarmee je eenvoudig verder kunt.

Uiteraard is de kans kleiner, maar noem jij eens een taal met zoveel gebruikers als ruby die doodgebloed is _binnen_ de levensduur van een gemiddelde website?

De toegankelijkheid van een taal lijkt me juist een zeer sterk punt voor de TS om juist voor PHP te kiezen. Wat probeer je hiermee nu te zeggen? Dat als je PHP programmeert je een prutser bent en als je Ruby programmeert je dat per definitie niet zal zijn?

Wat dacht je van, als je een "ervaren" Ruby programmeur binnen haalt dan heb je meer kans op een fatsoenlijke programmeur dan als je een "ervaren" PHP programmeur binnen haalt?
Als je het er niet mee eens bent dat het algeheel niveau van programmeurs binnen de PHP community laag is dan moet je maar eens naar jezelf gaan kijken, zelfs de developers van PHP zelf hebben (aan de structuur en wazige dingen in de taal te zien) blijkbaar niet zoveel programmeer kennis.

Zoja, dan mag je mij eens uit gaan leggen waarom de vergelijkings operatoren van PHP zo achterlijk in elkaar gezet zijn, bijvoorbeeld

PHP:

$a = 0;
$b = "eggs";
$c = "spam";

print ($a == $b) ? "a == b\n" : "a != b\n";
print ($b == $c) ? "b == c\n" : "b != c\n";
print ($a == $c) ? "a == c\n" : "a != c\n";
print ($a == $d) ? "a == d\n" : "a != d\n";
print ($b == $d) ? "b == d\n" : "b != d\n";
print ($c == $d) ? "c == d\n" : "c != d\n";

Met als uitvoer

a == b
b != c
a == c
a == d
b != d
c != d

Leg eens uit waarom a == b en a == c maar niet b == c?
Het is toch belachelijk dat een taal niet eens standaard vergelijkingen correct kan maken?

[FragFrog]

RayNbow schreef op donderdag 03 januari 2008 @ 13:13:
Er staat ook dat PHP geschreven werd om wat Perl scripts te vervangen? Verder zie je in 't eerder gelinkte diagram dat C invloed heeft gehad op Perl en dat Perl invloed heeft gehad op PHP. Je kunt dus beter zeggen dat PHP beinvloed is door Perl aangezien deze wat dichter bij PHP staat.

Ik had me er eigenlijk nooit verder in verdiept, maar even wiki'en leert dat ik je hierin gelijk moet geven - PHP lijkt op het eerste gezicht qua syntax nog een stuk meer op Perl dan op C

Wolfboy schreef op donderdag 03 januari 2008 @ 18:18:
Leg eens uit waarom a == b en a == c maar niet b == c?
Het is toch belachelijk dat een taal niet eens standaard vergelijkingen correct kan maken?

Het is toch belachelijk dat er mensen zijn die PHP's typecasting misbruiken en dan verbaasd zijn over de resultaten

PHP:

$a = '0';
$b = 'eggs';
echo $a == $b ? 'true' : 'false'; // False.

$a = 0;
echo $a === $b ? 'true' : 'false'; // False

echo (int) $b; // 0

Als jij een string met een integer vergelijkt wordt de string naar een int gecast ja. En ja, de intwaarde van een string zonder numerieke waarde is 0, als je dan niet op type controleert zal dit true opleveren. Wat verwacht je dan?

In plaats van a == b en a == c maar niet b == c zou je moeten zeggen a == (int) b en a == (int) c maar niet b == c en dan werkt die vergelijkingsoperator prima.

[ Voor 10% gewijzigd door FragFrog op 03-01-2008 18:37 ]

[Wolfboy]

Het is belachelijk dat een taal dat soort dingen zo afhandeld, automatische type casting is prima maar de php oplossing slaat gewoon nergens op. PHP zou een stuk beter af zijn als ze de === operator als standaard hadden ingesteld en de == als eventuele extra operator.

Wie heeft ooit bedacht dat als je een int vergelijkt met een string dat die string dan direct automatisch gecast moet worden naar een int? En als dat wel automatisch moet, doe het dan _alleen_ als de string ook een getal bevat. Als ik een stukje tekst zonder enige getallen er in vergelijk met een getal dan is het gewoon onlogisch als het opeens als getal vergeleken wordt.

[prototype]

Ok, na duizenden msn/irc berichten van RayNbow en een discussie op irc met Wolfboy mbt topic heb ik me toch maar laten verleiden om deel te nemen aan dit topic Gewoon om ervan af te zijn

In eerste instantie wil ik zeggen dat ik iemand ben die nog altijd geloofd dat je de right tool for the right job moet kiezen. Daar spelen diverse factoren een rol bij, e.g. levenscyclus van het project, inhouse ervaring, deadlines etc... Als er bijvoorbeeld al veel kennis binnen een bedrijf is met een bepaalde taal en je moet projecten afkrijgen voor een bepaalde deadline, dan is het wellicht voor de hand liggend om niet zomaar even iets nieuws erbij te pakken waar nog geen werknemer (genoeg) kennis van heeft.

Ten tweede ben ik ook iemand die nog altijd gelooft dat paradigma's beheersen belangrijker is dan een taal beheersen. Vergeet niet dat een taal 'slechts' een mechanisme is om eenvoudiger volgens een paradigma te kunnen programmeren. Zo is C al genoemd als een 'beter' alternatief voor assembler, maar aan het einde van de dag vallen beiden nog steeds onder de noemer imperatief programmeren. Daarbij is het aan de smaak van de programmeur om te bepalen welke hij fijner acht voor een bepaalde klus.

TS zegt dat hij al maanden bezig is met RoR, en ik vraag me dan af hoeveel daarvan effectief zijn, want maanden moet in dit geval genoeg zijn voor een developer om zelf in te kunnen schatten of een tool geschikt is voor de job. Ik zet dus vraagtekens bij de diversiteit aan ervaring mbt programmeren die TS heeft gehad en uit ze dan ook openlijk. Niet alleen TS trouwens, ook bij sommige reacties heb ik deze bedenkingen... vooral wanneer het neerkomt op argumentloze opsommingen van websites, en schuine argumentatie, quotes/blogposts die oost indisch blind gelezen worden etc... Gelukkig zijn de meesten dan ook weerlegd.

Ik heb dan ook het gevoel dat weinig mensen hier in dit topic ook echt ervaring hebben met RoR om zinnige uitspraken hierover te doen, aangezien argumentatie in de meeste posts gewoon ontbreekt. En hoe noemen ze dat ook alweer in de nederlandse taal?

De meesten hier hebben ervaring met PHP, dat zie ik, maar volgens mij is dat ook de enige taal waar men echt ervaring mee heeft. Hiermee blijft je horizon nogal beperkt, zoals Bjarne Stroustrup ook zegt (vader van C++ als ik toch C++ even moet aanhalen), een goede programmeur dient meerdere talen/paradigma te beheersen.

De blogpost mbt cdbaby laat dit ook blijken, waarbij iemand die voorheen enkel PHP kende een uitstapje maakte naar Ruby (en rails) en zich liet inspireren door de good practices van de framework. Dat hij deze nu dan toepast op PHP is dan ook in overeenstemming met het feit dat hij wel meer gegroeid is door zijn ervaring met RoR: zijn persoonlijke voorkeur lijkt gewoon meer bij PHP te liggen, net als dat de mijne meer bij Ruby ligt.

Wat betreft het 'argument' dat Ruby te beta is, daar zou ik toch graag argumentatie op willen zien. Want dan moet je even tegen reuzen als Amazon en BBC even vertellen dat ze verkeerd bezig zijn. Wat betreft de BBC trouwens, interessante link: http://www.bbc.co.uk/blog...07/11/perl_on_rails.shtml . Net als cdbaby hebben ze zich laten inspireren door rails, maar doordat men al veel kennis in huis heeft met perl heeft men besloten om een rails te bouwen voor perl (hetgeen in overeenstemming met right tool for the right job).

Wat betreft het crashen enzo, ik zou dat liever willen verwijten aan een slechte server config. Zo heb ik evenzo genoeg verhalen gehoord met RoR configs die honderdduizenden mensen moeten serveren en dit zonder crashen kunnen (e.g. www.ilike.com). Mijn voorkeur gaat trouwens uit naar een lighty config.

Wat betreft verschillende loads, dat is nogal voor de hand liggend he? Rails doet een stuk meer werk dan jouw op maat gemaakte PHP scripts. Nee, dat zeg ik verkeerd, Rails neemt veel meer werk uit handen, wat je o.a. bij PHP met je eigen custom template engine die je in je overschot aan tijd in elkaar hebt gefietst. Want tijd teveel dat heeft iedereen toch? Bovendien is die code ook bewezen vergeleken met een framework dat onderhouden wordt door een grote community. Oh nee, toch niet. Je moet wel meten met gelijke maten he? Vergelijk eens een PHP rails clone* qua performance met RoR, dan zul je zien dat deze al een stuk minder van elkaar verschillen. Maar wanneer je bezwaren/performance bottleneck bij de overhead ligt van een framework als deze dan ga ik toch vraagtekens zetten. Pragmatiek, wat was dat ook alweer?

Als men het diagram trouwens bekijkt van RayNBow, dan zien jullie dat Ruby als taal ongeveer uit dezelfde tijd komt als PHP. Het verschil is echter dat Ruby op dat moment al geheel object georienteerd was, en PHP gekozen heeft het pad te bewandelen van eerst procedural, met later OO erop geplakt... en dat is goed te merken imho, maar daar heb ik me in het verleden vaak genoeg over geuit, dus als je daar m'n argumentatie op wil hebben moet je maar even zoeken op m'n nick op GoT...

Maar goed, wat ik wil zeggen is elke taal wel een voordeel heeft voor bepaalde programmeurs en dat RoR het resultaat is van good practices als design patterns en AOP in de webdevelopment wereld. MVC is welliswaar een oud concept, maar je moet eens weten hoeveel varierende implementaties er op deze design pattern bestaan. Zo hebben we codebehind/MVC2 dat bekend is geworden in de asp.net/j2ee wereld en nu dus ook MVC ala RoR. Dat laatste bevalt veel mensen dusdanig dat .net sinds kort .net MVC heeft geintroduceerd dat zich nogal heeft laten inspireren door RoR. Daar is helemaal niks mis mee, integendeel, mensen krijgen meer opties om te bepalen wat voor hun de beste oplossing is voor een bepaalde situatie.

Zelf heb ik wat betreft webdevelopment o.a. ervaring met C# + asp.net, J2EE, PHP en RoR. Doordat ik ervoor kies om meerdere dingen goed te proberen stelt dat mij ook in staat om zoiets als asp.net MVC binnen een paar uren op te pikken, goede concepten evt elders toe te passen etc... Persoonlijk schrijf ik websites het liefst met RoR, vooral vanwege de filosofie van DRY, pragmatische dingen als migrations, gratis ORM in de vorm van ActiveRecord etc... Sterker nog, op m'n uni (utwente) wordt RoR steeds meer boven PHP verkozen, hetgeen ik o.a. terugzie in de oproepen van o.a. http://www.studentunion.utwente.nl/os/home/vacatures.html, webcommissies voor o.a. Daedelus, Scintilla etc...

Maar dat kan misschien ook door het werk komen dat mijn bacheloropdracht groepje momenteel verricht voor de utwente. We zijn nu met RoR een kennisoverdracht systeem aan het implementeren welke gepresenteerd wordt tijdens de student it conference op 25 januari op de utwente. Mensen die interesse hebben (voor o.a. mijn ongezouten mening mbt PHP** ) zijn bij deze van harte uitgenodigd.

* = Ik geloof trouwens dat PHP nooit een volwaardige rails clone zal krijgen, gewoon omdat er iets fundamenteel ontbreekt dat rails zo geweldig maakt: ruby. Hetgeen in RoR is over 't algemeen ook te doen in PHP, maar of je het wil is iets totaal anders. Zo heeft Ruby mechanismen in de taal zelf voor open classes en closures, waar Rails heel zwaar op leunt. Probeer datzelfde eens met PHP en gruwel van de code.

**= Ruby on Rails >>>>>>>> PHP

[BCC]

Pracht verhaal prototype. Ik ben het hier 100% mee eens. Ben een jaar geleden een groot project gestart onder Ruby On Rails (wat ook voor heel wat wikken en wegen gezorgd heeft) en ben erg blij dat we die keuze gemaakt hebben. Dit is voor ons echt the right tool voor the job.

Nog wat aanvullingen:
- Op Railsconf berlijn ben ik ook nog reuzen als IBM en Sun tegengekomen.
- Websites als basecamp.com verwerken zonder problemen meer dan 1500 reqs/seconde op rails. Ruby On Rails is trouwens nu perfect schaalbaar, dus performance is sowieso geen issue meer.

[ Voor 38% gewijzigd door BCC op 04-01-2008 00:34 ]

[Kanarie]

BCC schreef op vrijdag 04 januari 2008 @ 00:12:

...

- Websites als basecamp.com verwerken zonder problemen meer dan 1500 reqs/seconde op rails. Ruby On Rails is trouwens nu perfect schaalbaar, dus performance is sowieso geen issue meer.

Dat is een beetje kort door de bocht. Er wordt op verschillende manieren gewerkt om de performance van Ruby te verbeteren. Ruby 1.9 heeft YARV, er is JRuby, Rubinius, etc...
Een deel van Basecamp (eigenlijk een deel van Campfire) moest herschreven worden in C omdat er met Ruby niet genoeg performance was.
Ja, Rails is qua performance stukken beter dan een paar maanden terug ("Twitter doesn't scale" geldt niet meer), maar er is nog wel een verbeterslag te maken.

[whoami]

prototype schreef op donderdag 03 januari 2008 @ 21:25:


Zo hebben we codebehind/MVC2 dat bekend is geworden in de asp.net/j2ee wereld en nu dus ook MVC ala RoR. Dat laatste bevalt veel mensen dusdanig dat .net sinds kort .net MVC heeft geintroduceerd dat zich nogal heeft laten inspireren door RoR.

MS is idd bezig met een MVC framework voor ASP.NET (nog niet beschikbaar vziw). Echter, er is al een tijdje een dergelijk MVC project beschikbaar voor .NET : Castle Monorail (dat idd nogal geinspireerd is door RoR.
(Waar idd niets mis mee is; als een bepaald iets goed is, waarom dan geen versie / implementatie maken voor een andere taal / omgeving ? )

[Niek.NET]

whoami schreef op vrijdag 04 januari 2008 @ 10:44:
[...]

MS is idd bezig met een MVC framework voor ASP.NET (nog niet beschikbaar vziw). Echter, er is al een tijdje een dergelijk MVC project beschikbaar voor .NET : Castle Monorail (dat idd nogal geinspireerd is door RoR.
(Waar idd niets mis mee is; als een bepaald iets goed is, waarom dan geen versie / implementatie maken voor een andere taal / omgeving ? )

Wat prototype impliceert is dat, omdat de MVC implementatie van Rails als inspiratie wordt gebruikt voor frameworks in andere talen, er toch een boel mensen het een goed(e) implementatie/framework vinden.

Overigens wil ik mij volledig aansluiten bij de post van Prototype

offtopic:
Het ASP.NET MVC framework is momenteel te downloaden als CTP http://weblogs.asp.net/sc...ctp-preview-released.aspx

[ Voor 3% gewijzigd door Niek.NET op 04-01-2008 11:08 ]

[Verwijderd]

chuxiej schreef op woensdag 02 januari 2008 @ 11:43:
- hoe stabiel is mongrel_cluster (ik heb namelijk een paar keer gehad dat ik de server opnieuw moest starten omdat deze gecrashed was)
Het zou een grote ramp zijn als bv de server crashed.

mod_rails aka. Phusion Passenger is nu uitgekomen, deze restart automatisch als die crashed. En dit maakt het ook een stuk makkelijker om te deployen. Enige vereisten zijn Apache 2

[curry684]

Wolfboy schreef op donderdag 03 januari 2008 @ 19:18:
Het is belachelijk dat een taal dat soort dingen zo afhandeld, automatische type casting is prima maar de php oplossing slaat gewoon nergens op. PHP zou een stuk beter af zijn als ze de === operator als standaard hadden ingesteld en de == als eventuele extra operator.

Wie heeft ooit bedacht dat als je een int vergelijkt met een string dat die string dan direct automatisch gecast moet worden naar een int? En als dat wel automatisch moet, doe het dan _alleen_ als de string ook een getal bevat. Als ik een stukje tekst zonder enige getallen er in vergelijk met een getal dan is het gewoon onlogisch als het opeens als getal vergeleken wordt.

Sorry hoor maar nu sta je echt complete onzin uit te kramen. Wat je hier grondig, en ik bedoel echt grondig fout ziet is dat jouw mening een feit zou zijn en daarmee een globaal waardeoordeel kan vellen ergens over. Dat jij nog nooit een mooie Ford hebt gezien maakt nog niet iedere Ford lelijk. Smaken en toepassingen verschillen.

PHP is een weak typed late bound language, by design en by choice. De automatische consequentie van deze keuze, die de taal toegankelijk en overzichtelijk houdt ook voor de mindere programmeergoden op deze planeet en veel code bespaart in triviale situaties, is dat er bepaalde implicit conversions gaan plaatsvinden die voor puristen onprettig zijn, maar die nu eenmaal onvermijdbaar zijn door de hele opzet. Dus ja, als $a = '123abc', $b = 123 en $c = '123' geldt dat $a == $b en $b == $c maar $a != $c. Is dat stom? Nee, binnen een weak typed late bound omgeving is dat 'working as advertised'. Verder niets.

Jij hebt blijkbaar een sterke voorkeur voor strong typed talen als C++ en C#. Dat mag, dat heb ik zelf persoonlijk ook, maar ik zal het nooit als reden aanvoeren waarom PHP een stomme belachelijke taal is. Daar kan ik (helaas) wel 1000 betere redenen voor bedenken die wel hout snijden en niet puur een bevestiging van grondslag en bestaansrecht van PHP zijn.

Als je PHP gefundeerd een 'belachelijke taal' wil noemen begin dan over het functioneren van destructors, over het gebrek aan constructor overloading, over de mogelijkheid om base constructors te negeren waardoor je semi-finished instances kunt genereren, over native session logic die pas draait zodra alle globals zijn geflushed, over het gebrek aan method of operator overloading, over het feit dat het tot v5.3 heeft moeten duren voor er zoiets basics als namespaces in kwamen, over de onmogelijkheid om native types te gebruiken bij type hinting, of een van de tig andere redenen. Maar niet over fundamentele keuzes die PHP een toegankelijke unieke taal en omgeving maken in plaats van just-another-C++-but-now-for-websites.

edit:
fu** anders zie ik even niet dat m'n voorganger een half jaar oud topic heeft gekickt

[Wolfboy]

curry684 schreef op woensdag 04 juni 2008 @ 01:28:
[...]

PHP is een weak typed late bound language, by design en by choice. De automatische consequentie van deze keuze, die de taal toegankelijk en overzichtelijk houdt ook voor de mindere programmeergoden op deze planeet en veel code bespaart in triviale situaties, is dat er bepaalde implicit conversions gaan plaatsvinden die voor puristen onprettig zijn, maar die nu eenmaal onvermijdbaar zijn door de hele opzet. Dus ja, als $a = '123abc', $b = 123 en $c = '123' geldt dat $a == $b en $b == $c maar $a != $c. Is dat stom? Nee, binnen een weak typed late bound omgeving is dat 'working as advertised'. Verder niets.

Waarom zou het 'normaal' zijn? Voor deze problemen zijn imho veel betere oplossingen te bedenken, dat $b == $c zou moeten gelden is evident voor een taal als php. Maar dat $a == $b geldt is niet logisch, als '123abc' zou evalueren naar 123, waar zou '123abc456' dan naar moeten evalueren? Of 'abc123'? Dat is m.i. _niet_ duidelijk.

Ik zie overigens geen reden om te reageren op de rest van je post, laat het maar weten indien je dit wel wenst.

offtopic:
Nu het topic toch weer levend is reageer ik ook maar

[curry684]

Wolfboy schreef op woensdag 04 juni 2008 @ 02:36:
[...]
Waarom zou het 'normaal' zijn? Voor deze problemen zijn imho veel betere oplossingen te bedenken, dat $b == $c zou moeten gelden is evident voor een taal als php. Maar dat $a == $b geldt is niet logisch, als '123abc' zou evalueren naar 123, waar zou '123abc456' dan naar moeten evalueren? Of 'abc123'? Dat is m.i. _niet_ duidelijk.

Lullig, want perfect bedocumenteerd.

Een onontkenbaar nadeel van weak typing is dat je bepaalde implicit conversions goed moet documenteren. Gelukkig hebben ze dat voor de meest voor de hand liggende twijfelaars goed gedaan

[Wolfboy]

Lullig

Sinds wanneer moet documentatie het gebrek aan logica goedpraten? PHP is volgens veel mensen de meest toegankelijke taal voor beginners, en wat is (naar mijn ervaring) nou juist _de_ methode van veel beginners? Geen documentatie lezen maar gewoon proberen en vragen als iets niet duidelijk is, is het dan geen beter idee om een taal zo logisch mogelijk te laten werken zodat er minder vragen gesteld worden?

Documentatie moet m.i. geen benodigdheid zijn, geweldig als het er is, heel fijn als je eventjes iets op wil zoeken, maar als ik de documentatie _nodig_ heb omdat het niet duidelijk/logisch werkt dan vind is het m.i. niet duidelijk genoeg.

[BCC]

Kanarie schreef op vrijdag 04 januari 2008 @ 02:41:
[...]
Ja, Rails is qua performance stukken beter dan een paar maanden terug ("Twitter doesn't scale" geldt niet meer), maar er is nog wel een verbeterslag te maken.

Rubunius draait nu ook rails (gepresenteerd op Rails conf Portland)! Dus er zijn nu 4 goede ruby interpreters: ironruby.net, jruby(java), ruby en rubinius.

Rubinius is een slot-in voor ruby gaat ook weer een heleboel snelheidswinst geven! De hoeveelheid rails programmeurs die gezocht worden was ook belachelijk op railsconf.

http://flickr.com/photos/viniciusteles/2538507982/

Ik blijf voorlopig nog lekker railen in NL

Over de discussie hierboven: beide talen hebben hun sterke en zwakke punten. Php is makkelijk mee te beginnen, maar groeit vaak uit tot een on-onderhoudbaar monster. Ruby zelf vind ik makkelijker dan PHP, maar Rails is weer een tikkeltje ingewikkelder.

In de praktijk zie ik echter dan ror applicaties hier als paddestoelen de lucht in schieten en daarna stabiel blijven draaien in productieomgevingen met veel minder ellende dan php applicaties. Gezien de vraag naar Ror programmeurs wereldwijd, lijkt mij dat meer mensen deze trend zien.

De discussie dat php of ruby logischer zou zijn dan de ander is hetzelfde als of een banaan intuitiever zou zijn om te eten dan een appel: Daar kom je niet uit

[ Voor 33% gewijzigd door BCC op 04-06-2008 07:05 ]

[Kanarie]

BCC schreef op woensdag 04 juni 2008 @ 07:01:
[...]

Rubunius draait nu ook rails (gepresenteerd op Rails conf Portland)! Dus er zijn nu 4 goede ruby interpreters: ironruby.net, jruby(java), ruby en rubinius.

Rubinius is een slot-in voor ruby gaat ook weer een heleboel snelheidswinst geven! De hoeveelheid rails programmeurs die gezocht worden was ook belachelijk op railsconf

....

Voorlopig is Rubinius nog behoorlijk traag. Dat Rubinius nu Rails draait is meer een proof of concept. Ook IronRuby is nog lang niet af.

De fatsoenlijke opties zijn wat mij betreft:
Mongrel familie (Mongrel, Thin, Ebb)
FastCGI
mod_rails
JRuby

[curry684]

Wolfboy schreef op woensdag 04 juni 2008 @ 03:07:
Lullig

Lullig dat je het onduidelijk vind, want het is documented behaviour en je had het dus kunnen weten

Sinds wanneer moet documentatie het gebrek aan logica goedpraten?

Hoe logisch is het om in C/C++ == te gebruiken voor comparisons? In oudere talen als COBOL was dat gewoon een single =. Die operator was volstrekt onlogisch geweest, je had wellicht gedacht dat het een dubbele assign was, als je het goede gedrag niet ergens in documentatie had gelezen.

PHP is volgens veel mensen de meest toegankelijke taal voor beginners, en wat is (naar mijn ervaring) nou juist _de_ methode van veel beginners? Geen documentatie lezen maar gewoon proberen en vragen als iets niet duidelijk is, is het dan geen beter idee om een taal zo logisch mogelijk te laten werken zodat er minder vragen gesteld worden?

Programmeertalen zijn niet logisch voor mensen die nooit geprogrammeerd hebben. Mensen die de taal leren moeten lezen wat een string is en hoe ze die moeten noteren voor ze hem kunnen gebruiken. En lo and behold, op dezelfde pagina staat uitgelegd hoe implicit conversions van strings werken. Wederom val je in de fout dat jij reeds voorkennis had en dus die pagina hebt overgeslagen bij je PHP-learning efforts. Dat is jouw fout, niet die van PHP.

Documentatie moet m.i. geen benodigdheid zijn, geweldig als het er is, heel fijn als je eventjes iets op wil zoeken, maar als ik de documentatie _nodig_ heb omdat het niet duidelijk/logisch werkt dan vind is het m.i. niet duidelijk genoeg.

Wederom, geen enkele programmeerteel functioneert of schrijft duidelijk of logisch als je niet de moeite leert om te leren hoe hij werkt. Dat geldt voor C, voor C#, voor C++, en voor PHP. Als jij (net als ik) uit een C/C++ achtergrond komt sta je heel vaak te vloeken op PHP's onhebbelijkheden en vreemde dingen. Maar dat is de fout van onze achtergrond, niet die van PHP.

[YopY]

@ vreemd gedrag bij int / string vergelijkingen: Waarom zou je uberhaupt integers met strings vergelijken als je je niet bewust bent van de mogelijke quirks die daarbij optreden? Sterker nog, als je uit een strong-typed taal komt, zou je zoiets niet eens proberen, simpelweg omdat het in strong typed languages niet eens mogelijk is.

[Janoz]

curry684 schreef op woensdag 04 juni 2008 @ 10:29:
Hoe logisch is het om in C/C++ == te gebruiken voor comparisons? In oudere talen als COBOL was dat gewoon een single =. Die operator was volstrekt onlogisch geweest, je had wellicht gedacht dat het een dubbele assign was, als je het goede gedrag niet ergens in documentatie had gelezen.

Misschien lijkt deze opmerking van Curry wat onzinnig, maar als je puur wiskundig kijkt is de = het teken voor een vergelijking en niet voor een toekenning. Voor de toekenning is in de wiskunde niet echt een teken en eigenlijk zou juist voor die operatie een ander teken moeten komen. Deze keuze is bijvoorbeeld in pascal gemaakt. Hierbij is het teken voor een vergelijking gewoon een = maar wordt voor een toekenning := gebruikt. Eigenlijk is de keuze van Pascal dus veel logischer en voor de hand liggender. (Het is ook niet vreemd wanneer je bedenkt dat het doel van Pascal was om een zo makkelijk mogelijk te leren taal te zijn)

Geneuzel in de marge? Ik denk het niet. Kijk maar eens naar problemen die mensen hebben die net begonnen zijn met programmeren. Wat heel vaak fout gaat is dat mensen de = meer als een binding operator zien. Ze zetten ergens a=b neer. Doen wat operaties en vinden het vervolgens vreemd dat a==b niet meer geldt.

[ Voor 8% gewijzigd door Janoz op 04-06-2008 10:55 ]

[Wolfboy]

curry684 schreef op woensdag 04 juni 2008 @ 10:29:
Lullig dat je het onduidelijk vind, want het is documented behaviour en je had het dus kunnen weten

Correct me if I'm wrong... maar heb je niet ook zoiets als intuitieve interfaces? Systemen die dermate logisch werken dat documentatie een toevoeging in plaats van een verplichting is?

Hoe logisch is het om in C/C++ == te gebruiken voor comparisons? In oudere talen als COBOL was dat gewoon een single =. Die operator was volstrekt onlogisch geweest, je had wellicht gedacht dat het een dubbele assign was, als je het goede gedrag niet ergens in documentatie had gelezen.

Waar heb ik beweerd dat _alles_ altijd logisch kan en zal zijn? Mijn punt is alleen dat als het logischer kan, doe het dan. Je hebt helemaal gelijk dat ==, != en dergelijke operatoren niet logisch zijn, maar het gedrag is in ieder geval consistenter dan het type casting systeem van PHP.

Programmeertalen zijn niet logisch voor mensen die nooit geprogrammeerd hebben. Mensen die de taal leren moeten lezen wat een string is en hoe ze die moeten noteren voor ze hem kunnen gebruiken. En lo and behold, op dezelfde pagina staat uitgelegd hoe implicit conversions van strings werken. Wederom val je in de fout dat jij reeds voorkennis had en dus die pagina hebt overgeslagen bij je PHP-learning efforts. Dat is jouw fout, niet die van PHP.

Misschien moeten we eens een onderzoekje uitvoeren wat non-programmeurs verwachten dat er gebeurd zodra je zo'n stukje tekst zou omzetten naar een getal. Wat denk jij dat de resultaten zijn?

Wederom, geen enkele programmeerteel functioneert of schrijft duidelijk of logisch als je niet de moeite leert om te leren hoe hij werkt.

Er zijn imho wel een aantal talen die dermate eenvoudig te lezen zijn dat ook niet programmeurs ze nagenoeg direct kunnen lezen, al is dat weer een andere discussie.

Als jij (net als ik) uit een C/C++ achtergrond komt sta je heel vaak te vloeken op PHP's onhebbelijkheden en vreemde dingen. Maar dat is de fout van onze achtergrond, niet die van PHP.

Dat klopt, er zijn zeker belangrijkere en betere punten om over te klagen bij PHP en mijn achtergrond zal me zeker beletten om een volledig objectieve beoordeling te maken.

[Wolfboy]

Janoz schreef op woensdag 04 juni 2008 @ 10:53:
Misschien lijkt deze opmerking van Curry wat onzinnig, maar als je puur wiskundig kijkt is de = het teken voor een vergelijking en niet voor een toekenning. Voor de toekenning is in de wiskunde niet echt een teken en eigenlijk zou juist voor die operatie een ander teken moeten komen. Deze keuze is bijvoorbeeld in pascal gemaakt. Hierbij is het teken voor een vergelijking gewoon een = maar wordt voor een toekenning := gebruikt. Eigenlijk is de keuze van Pascal dus veel logischer en voor de hand liggender. (Het is ook niet vreemd wanneer je bedenkt dat het doel van Pascal was om een zo makkelijk mogelijk te leren taal te zijn)

Geneuzel in de marge? Ik denk het niet. Kijk maar eens naar problemen die mensen hebben die net begonnen zijn met programmeren. Wat heel vaak fout gaat is dat mensen de = meer als een binding operator zien. Ze zetten ergens a=b neer. Doen wat operaties en vinden het vervolgens vreemd dat a==b niet meer geldt.

In de wiskunde is het = teken de gelijkheidsoperator, alles wat links staat is dus gelijk aan wat rechts staat. Is dat (in een andere vorm) niet precies hetzelfde wat in de programmeertalen gebeurd? Als ik zeg a = 10 dan staat er wiskundig dus dat a gelijk is aan 10. Wat dat betreft lijkt het mij een prima teken.

Al is er in de wiskunde wel een beter teken hiervoor, het := (en ≡ ook) zijn de definitie tekens in de wiskunde, waarmee het teken wel correct zou zijn. Al hebben deze tekens helaas het nadeel dat ze of niet op een standaard toetsenbord zitten of een extra teken vereisen.

[RayNbow]

Wolfboy schreef op woensdag 04 juni 2008 @ 15:10:
[...]
In de wiskunde is het = teken de gelijkheidsoperator, alles wat links staat is dus gelijk aan wat rechts staat. Is dat (in een andere vorm) niet precies hetzelfde wat in de programmeertalen gebeurd? Als ik zeg a = 10 dan staat er wiskundig dus dat a gelijk is aan 10. Wat dat betreft lijkt het mij een prima teken.

Tijd voor Erlang en single assignments?

C:\>erl
Eshell V5.6  (abort with ^G)
1> Z=3.   % Z is nu gebonden aan 3
3
2> Y=2.   % Y is nu gebonden aan 2
2
3> Z=Y+1. % Dit matcht.
3
4> Z=Y.   % Geen match. :)
** exception error: no match of right hand side value 2

Pic related:

[Janoz]

Wolfboy schreef op woensdag 04 juni 2008 @ 15:10:
[...]
In de wiskunde is het = teken de gelijkheidsoperator, alles wat links staat is dus gelijk aan wat rechts staat. Is dat (in een andere vorm) niet precies hetzelfde wat in de programmeertalen gebeurd? Als ik zeg a = 10 dan staat er wiskundig dus dat a gelijk is aan 10. Wat dat betreft lijkt het mij een prima teken.

Nee, dat komt overeen met waarvoor we == gebruiken in C-like talen. In die talen staat a = 10 niet voor "a is 10", maar voor "a wordt 10".

Al is er in de wiskunde wel een beter teken hiervoor, het := (en ≡ ook) zijn de definitie tekens in de wiskunde, waarmee het teken wel correct zou zijn. Al hebben deze tekens helaas het nadeel dat ze of niet op een standaard toetsenbord zitten of een extra teken vereisen.

Lees gewoon even mijn hele bericht. Vooral het stuk over pascal........

[Wolfboy]

Janoz schreef op woensdag 04 juni 2008 @ 16:09:
Nee, dat komt overeen met waarvoor we == gebruiken in C-like talen. In die talen staat a = 10 niet voor "a is 10", maar voor "a wordt 10".

Correct, echter is na het uitvoeren het resultaat dat a gelijk is aan 10, wat mijn punt was.

Als ik in een wiskundige formule a = 10 heb staan, dan weet iedereen dat a gelijk is aan 10, a hoeft niet per definitie hetzelfde te zijn (10 = 5 + 5 is uiteraard ook waar) maar het is wel duidelijk aan welke voorwaarde deze zou moeten voldoen.

Lees gewoon even mijn hele bericht. Vooral het stuk over pascal........

Dat heb ik gelezen, en daar beweer je ook dat er in de wiskunde geen teken voor is wat m.i. wel het geval is, het teken dat Pascal ook gebruikt ja. Toegegeven, mijn bericht was nogal onduidelijk verwoord, excuses.

[RayNbow]

Janoz schreef op woensdag 04 juni 2008 @ 10:53:
Kijk maar eens naar problemen die mensen hebben die net begonnen zijn met programmeren. Wat heel vaak fout gaat is dat mensen de = meer als een binding operator zien. Ze zetten ergens a=b neer. Doen wat operaties en vinden het vervolgens vreemd dat a==b niet meer geldt.

Mijn gevoel zegt ook dat destructive updates vaak de oorzaak zijn van bepaalde bugs.

Joe Armstrong denkt er in ieder geval hetzelfde over. De volgende fragmenten komen uit z'n boek Programming Erlang - Software for a Concurrent World.

Single Assignment Is Like Algebra
When I went to school, my math teacher said, "If there's an X in several different parts in the same equation, then all the Xs mean the same thing." That's how we can solve equations: if we know that X+Y=10 and X-Y=2, then X will be 6 and Y will be 4 in both equations.

But when I learned my first programming language, we were shown stuff like this:

    X = X + 1

Everyone protested, saying "you can't do that!" But the teacher said we were wrong, and we had to unlearn what we learned in math class. X isn't a math variable: it's like a pigeon hole/little box...

In Erlang, variables are just like they are in math. When you associate a value with a variable, you're making an assertion--a statement of fact. This variable has that value. And that's that.

Why Does Single Assignment Make My Programs Better?
[...]
In Erlang, variable values cannot be changed after they have been set. This simplifies debugging. To understand why this is true, we must ask ourselves what an error is and how an error makes itself known.

One rather common way that you discover that your program is incorrect is that a variable has an unexpected value. If this is the case, then you have to discover exactly the point in your program where the variable acquired the incorrect value. If this variable changed values many times and at many different points in your program, then finding out exactly which of these changes was incorrect can be extremely difficult.

In Erlang there is no such problem. A variable can be set only once and thereafter never changed. So once we know which variable is incorrect, we can immediately infer the place in the program where the variable became bound, and this must be where the error occured.

[...]

[roy-t]

Janoz schreef op woensdag 04 juni 2008 @ 10:53:
[...]

Misschien lijkt deze opmerking van Curry wat onzinnig, maar als je puur wiskundig kijkt is de = het teken voor een vergelijking en niet voor een toekenning. Voor de toekenning is in de wiskunde niet echt een teken en eigenlijk zou juist voor die operatie een ander teken moeten komen. Deze keuze is bijvoorbeeld in pascal gemaakt. Hierbij is het teken voor een vergelijking gewoon een = maar wordt voor een toekenning := gebruikt.

Misschien interessant om te weten, maar bij mijn wiskunde lessen op de RUG wordt standaard := gebruikt als wordt (toekenning). Of dit komt door pascal of dat hier een fundamenteler iets achter zit weet ik niet, wat ik wel weet is dat als je schreeft het verschil tussen = en == nogal onduidelijk is. := is dan erg duidelijk. Ik vind het zelf jammer dat C#/Java e.d.= gebruiken ipv := maar aan de andere kant scheelt dat wel veel typ werk.