Share
Det er på tide; kø på temaet "Going the Distance" fra Rocky. I den røde ringen: Envato utvikler ekstraordinær, Ryan Allen, som bygget den opprinnelige FlashDen med sine kalde, bare hender. I det blå hjørnet: Michael Wales, et velkjent medlem i PHP og CodeIgniter-fellesskapene. Kampen? PHP vs Ruby. Slåss!
Det må bemerkes at denne typen debatter er rent for moro og utdanningsformål. Det er tider når du velger PHP for et prosjekt, og det er tider når du velger Ruby. Målet med denne serien er imidlertid å lære hvordan og når å gjøre slike beslutninger. I stedet for "ditt språk suger", er disse debattene ment å skissere Hvorfor du kan i enkelte situasjoner velge den ene over den andre.
Ryan Allen er en webprogramvare og systemingeniør som har jobbet for Envato siden for alltid. Han bygget og støttet de tidlige versjonene av Envato-markedsplassene i Ruby on Rails, og ser nå etter Tuts + -systemene, blant annet.
Michael Wales er en webutvikler for amerikanske regjeringsorganer, og er en aktiv bidragsyter til PHP og CodeIgniter-fellesskapene.
Ryan: PHP var et av de første programmeringsspråkene jeg jobbet med (bortsett fra ActionScript og noen veldig korte Visual Basic). Jeg begynte å bygge ting med PHP i 2001. Jeg jobbet ganske utelukkende med det som en backend-verktøy til slutten av 2005, da Ruby (og Rails) tok sin plass.
Michael: PHP var min introduksjon til verden av webutvikling, i 1999 - så jeg vil gjerne si at jeg har en ganske solid forståelse av sin posisjon i vår bransje, dens historie og den retningen den er ledet i. Ruby, som mange andre, fikk øye med utgivelsen av Rails og suksessen til 37signals. Jeg har en ganske solid forståelse av Ruby, som et skriptspråk i systemadministrasjonstjenestene (Capistrano), samt noen personlige og morsomme prosjekter (Gosu-spillutviklingsbiblioteket og Rails). Jeg skammer meg for å innrømme at jeg ikke er så kjent med Rails 'siste versjoner, og det er definitivt på min liste over ting å reacquaint meg selv med.
Michael: Dessverre kan jeg ikke gi et definitivt svar på dette - i hvert fall ikke som du forventer, siden PHP og Ruby er to helt forskjellige dyr. PHP er en sammensmelting av språk og web-rammeverk i en pakke, mens Ruby er et programmeringsspråk med mange rammer tilgjengelig.
Hvis fokuset ditt er webutvikling, og det er alt du virkelig ønsket å fokusere på akkurat nå, vil jeg definitivt anbefale deg å lære PHP først.
Så hvis fokuset ditt er webutvikling, og det er alt du virkelig ønsket å fokusere på akkurat nå, vil jeg definitivt anbefale deg å lære PHP først av flere grunner:
Som utvikler med 12 års erfaring, setter jeg pris på snarveiene Rails bringer til vår bransje; men det er bare fordi jeg forstår hva som faktisk foregår bak kulissene.
Hvis du vil bli en utvikler (Web Developer, System Administration scripting, Game Developer, API Developer) som forstår lavt nivå Computer Science konsepter, objektorientert programmering og generelt fremme dine kritiske tenkning ferdigheter - det sier seg selv, start med Ruby, det er et aktuelt programmeringsspråk (husk, PHP er et nettramme forklart som et språk).
Fra et webutviklerperspektiv tror jeg at dette også er en av Ruby's (og Python's, BTW) downfalls - er det egentlig ikke noe? Midt-nivå? inngangspunkt. Du forstår heller HTTP-protokollen, med muligheten til å skrive din egen stabel, topp til bunn, eller du går med en av de "magiske", hold hånden din for å lage en CRUD-system rammeverk?.
Dette er virkelig det området hvor PHP skinner. Hvis du går utover grensene til CRUD, trenger du ikke å ha en ekstrem forståelse av hvordan en HTTP-server virker for å gjøre drømmene dine til virkelighet.
Ryan: Hvis jeg skulle lære noen programmering fra bunnen av, vil jeg helst lære dem Ruby (problemer med å sette opp miljøer til side - selv om dette blir enklere). En vanlig måte å starte noen av (etter kanskje variabler og skrive ut dem) er å forklare arrays med, for eksempel en handleliste eksempel, ta denne delen av PHP:
Accentsconagua
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); for ($ i = 0; $ i < count($shopping_list); $i++) echo $shopping_list[$i]; Da jeg lærte PHP, ble jeg lært å bruke for looper (som jeg var i ActionScript), da det allerede eksisterte en mer kortfattet og mindre feilgjennomtrengende forløpsløype (som det også gjorde i ActionScript). Jeg måtte lære alt om denne $ i = 0-tingen, denne testingen og denne økende ting. Det var så forvirrende! Antall ganger jeg har skrudd opp for sløyfer, er ukjent (ingen ordspill ment). Her er hvordan det samme ville se ut i Ruby:
shopping_list = ['Milk', 'Cheese', 'Hovercraft'] shopping_list.each do | shopping_item | setter shopping_item slutt
Det er mye mindre syntaks der, og iteratorer er i tankene mine, mye lettere å forstå og jobbe med. Men for fullstendighet skyld, her er PHP-eksemplet, men med en forkant:
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); foreach ($ shopping_list som $ shopping_item) echo $ shopping_item; Vel, det er ikke ille faktisk! Jeg regner med at du bare burde bruke løkker til å telle til 10 og ting som det, foreach er så mye lettere å lese og lære og så mye vanskeligere å skru opp. Og iteratorer er enda bedre, så jeg ville gå med Ruby.
Ryan: Salgspunktet for meg (i 2005) var Rails-rammeverket. Jeg hadde prøvd hånden min på webutvikling med Python, men å være uerfaren, jeg hadde litt vanskelig tid uten å vite hva jeg skal gjøre eller hvor jeg skal se (men jeg klarte å bygge noen ting, så ta det!), Men jeg ville virkelig bruk Python dag for dag fordi jeg følte det hadde en bedre, mer bevisst design og jeg likte syntaksen. Og fordi slanger er kulere enn elefanter.
ActiveRecord var bare så fantastisk!
Har aldri jobbet med noe annet enn ADODB i PHP, og prøvde og feilet på å lage en ORM mange ganger (jeg ante ikke hva en ORM var, men jeg visste at jeg ønsket noe som på en eller annen måte mappede klasser til databasetabeller), da jeg først så ActiveRecord Det var som alle mine kristne var kommet på en gang.
Jeg kjente relasjonsdatabaser ganske bra, men var lei av å skrive den samme SQL om og om igjen. ActiveRecord var bare, bare så fantastisk! Og Ruby var nær nok til Python Jeg var glad som Larry (den han er) for å ha et rammeverk jeg kunne bli opptatt av og begynne å bygge ting. Så for meg var det kjærlighet til et bibliotek og en kjærlighet til syntaksen.
I dag har vi massevis av fantastiske Ruby-biblioteker skrevet av talentfulle individer, biblioteker som Sinatra (et lettvektsramme), Nokogiri (en HTML / XML-parser), Sequel (et høyt databasebibliotek), RSpec (et automatisert testbibliotek). Alle disse bibliotekene kan installeres som RubyGems som jeg fant mye enklere og brukervennlig å jobbe med enn PHPs PEAR-system.
Samfunnet er fortsatt ganske levende, selv noen få år i, og selskaper ansetter Ruby-utviklere som hotcakes. Ruby 1.9 er tilsynelatende nesten like fort som PHP nå også, så det er mange salgspoeng!
Ruby 1.9 er tilsynelatende nesten like fort som PHP nå også, så det er mange salgspoeng!
Michael: Jeg tror dette er bare en naturlig utvikling av utviklere (fra Web Development til å søke overordnet kunnskap om OOP-språk og en overordnet Computer Science-utdanning) generelt - jeg vet at det var ruten jeg tok.
Jeg tror den største nedgangen, til denne dagen, er praksis for å plukke et språk og holde seg til det til døden. Det er ikke slik den virkelige verden virker.
Jeg betrakter meg selv som en? Utvikler? - Språket er derfor en tvetydig kvalifikasjon som merkenavnet til en Best Buy-selger. Det er tilfeller der jeg velger PHP (hvis det er en ekstrem kort tidslinje - utenfor CRUD, er det språket jeg er mest kjent med), det er andre der jeg velger Ruby (distribusjon via Capistrano eller grunnleggende CRUD med Rails) og , enda lenger, Python - som jeg foretrekker for serveradministrasjonsoppgaver og analyse av ulike filer.
Michael: Jeg tror utviklere kan veldig ofte bli fanget opp i den "nye hotnessen, gamle busted? mani. Dette er grunnen til at teamet mitt alltid setter seg ned før vi starter et prosjekt, vi legger ut kravene (i både brukerbetingelser og utviklervilkår - som er to svært forskjellige ting) og vi snakker det ut, med svært lite språk / rammeinnstillinger i tankene . I forrige uke analyserte vi noen GBs meldingslogger med Perl, denne uken bygde vi et program hvis primære visning var en ExtJS GridPanel (fordi vi har utvidede CodeIgniter kjernefiler som håndterer enhver situasjon ExtJS kaster hos oss med 3 linjer med kode).
Det handler om hvor mye tid vi har og hvordan kan vi produsere det beste produktet i den tidsrammen?
Ryan: Absolutt, noen mennesker (selv inkludert) blir vant til å designe ting på en bestemt måte at de ikke vil lære om og endre alle sine hardt opptjente vaner. Når du er produktiv med noe, hvorfor ville du bry deg om å endre den?
En annen tankegang er de flere språkene og verktøyene du har erfaring, du kan kombinere de beste teknikkene og ideene uansett hvilket miljø du jobber med (de sier dette om å lære LISP, men jeg har ikke lært det ennå ).
Unge programmerere hopper på de skinnende nye tingene, men etter hvert som du blir eldre og mer moden, vil du arbeide med små, enkle og robuste verktøy. Hvis du ikke bruker alle funksjonene og hvert bibliotek tilgjengelig for Ruby, kan du få enkel og robust uten for mye trøbbel.
Ett ord: vedlikehold.
Ryan: Ja, ett ord: vedlikehold. Programvareprosjekter har en tendens til å kreve endringer over tid, og den opprinnelige forfatteren av programmet kommer ikke alltid til å være den personen som gjør endringene. La oss si at hypotetisk teleporter er oppfunnet, og det er en verdensomspennende Ruby-konferanse, og hver eneste kan Ruby-utvikler i verden går (teleporter rock!). La oss også si at jorden hypotetisk er Middle Earth, og Smaug draken er ganske irritert over hele denne Ruby-tingen (drager foretrekker Python, du ser) og bestemmer deg for å besøke og slå alle utviklerne ut av tross. Nå er det ingen erfarne Ruby-utviklere igjen i verden, oh kjære! Nå har du dette problemet med å ikke ha et basseng av Ruby-utviklere tilgjengelig for arbeid på dine prosjekter. Hva skal vi gjøre Gandalf?
Når jeg velger verktøy, tenker jeg ofte på hvem som skal vedlikeholde prosjektet hvis jeg blir rammet av en buss (eller krasj min motorsykkel, noe som er mer sannsynlig).
Jeg ville absolutt ikke skrive noe i Haskell eller LISP eller F # fordi vi hadde det vanskelig å ansette noen som kunne eller ville jobbe med den. Tilgjengelighet av talent og eksisterende talent i et selskap påvirker så meget min beslutning.
Det er en annen situasjon der jeg ville vurdere språket, og det ville være hvis jeg solgte et produkt, si, et egendefinert CMS-salg på Code Canyon. Jeg ville ikke skrive det i Ruby fordi råvare web hosting ikke generelt støtter det. Mens PHP er ganske lett tilgjengelig overalt, og webdesignere og mindre erfarne programmører er litt kjent med det.
Det er en annen situasjon der jeg ville vurdere språket, og det ville være hvis jeg solgte et produkt, si, et egendefinert CMS-salg på Code Canyon. Jeg ville ikke skrive det i Ruby fordi råvare web hosting ikke generelt støtter det. Mens PHP er ganske lett tilgjengelig overalt, og webdesignere og mindre erfarne programmører er litt kjent med det.
Michael: Se svarene mine for # 3 / # 4.
Michael: Personlig vil jeg anbefale Django-rammeverket for Python. Det ble designet med dette formålet i tankene: Evnen til å få utviklerne til å jobbe med datamodellering og vise data på skjermen så raskt som mulig, med enkle å bruke tagger for designere å presentere dataene på en vakker måte, mens utviklerne fortsetter å jobbe med forretningsreglene i en samtidig syklus.
Ryan: Hvis du har erfaring med å kaste sammen HTML og CSS og laste opp disse med FTP, vil jeg sannsynligvis anbefale PHP, da det har lave inngangsbarrierer fordi du allerede er kjent med sin metafor (pakk inn koden din i .php forlengelse! Vekk du går!). Men hvis du begynte å ta programmering seriøst, vil jeg foreslå forgrening og se på andre ting (for eksempel Ruby) for å utvide horisonter.
Når ting går galt, vil din mangel på kunnskap komme tilbake og bite deg.
Ofte ser jeg PHP-programmerere som arbeider med relasjonsdatabaser og har svært lite forståelse av hvordan de fungerer. Så virkelig kan du få ting gjort uten en dyp forståelse av teknologiene du jobber med (du bruker sjelden PHP alt på egenhånd), men når ting går galt, vil din mangel på kunnskap komme tilbake og bite deg. Hvor mye tid må du investere i å lære disse tingene? Kan du gå til noen for hjelp hvis du sitter fast? Lærer du PHP, slik at du kan få jobb med det, eller bare for moro skyld? Valg er et forholdsvis åpent spørsmål, avhengig av hva målene dine er.
Når det gjelder terminaler, er de kort sagt AWESOME. Jeg bruker dem hele tiden. Ja, de har en læringskurve (men hva gjør det ikke?). Når du får et håndtak på dem og begynner å skrive dine egne små programmer, kan du ikke fortsette uten dem. For å være rettferdig fant jeg ikke kommandoprompt i Windows veldig nyttig, men når jeg byttet til en Mac og hadde tilgang til alle Nix morsomhet under hetten, har den blitt ganske produktiv.
Ruby har hype, livsstil og sex appeal.
Ryan: Jeg vil si noe Ruby har for tiden at PHP ikke er hype, vibrancy og sex appeal. Ruby er utvilsomt sexy. Kvinner elsker det. Menn vil være som det. Godzilla frykter det. Jeg vil foreslå å hoppe til en Ruby User Group, og du vil finne en mangfoldig gruppe mennesker som bare elsker å kode, elsker å lage ting og teknologi generelt. Da jeg begynte å møte mennesker i det lokale Ruby-samfunnet, var det Første gang i mitt liv følte jeg at jeg var med mitt folk.? Jeg trodde ærlig at jeg var den eneste programmereren på planeten som brydde seg om sitt arbeid frem til da. Det var veldig forfriskende og jeg har lært mye siden da, hovedsakelig fra de menneskene jeg har møtt gjennom disse gruppene.
Her er en hemmelighet: Hvis PHP utgitt en offisiell oppdatering med en alternativ syntaks (mer Ruby / Python som), og pakket det eksisterende standardbiblioteket i stilen til de populære Ruby-bibliotekene (og gjorde det konsistent), og hadde bakoverkompatibilitet og evne til å integrere med arvskoden, ville det være et morderprodukt. Ikke fortell noen jeg sa det.
Michael: Enkel implementering, en grasiøs introduksjon til de lavere konseptene for webutvikling og over et århundre dokumentasjon og gode og gode metoder.
Michael: Igjen - enkel utplassering, en grasiøs introduksjon til de lavere konseptene av webutvikling og over et århundre dokumentasjon og prøvde og sanne beste praksis.
Men alvorlig - på grunn av den lave barrieren for oppføring med PHP kan det være vanskelig å skille forskjellen mellom noen som faktisk vet hva de snakker om og noen på samme ferdighetsnivå som deg som hadde et ekstra domene for en blogg. Pluss, på grunn av PHPs store senioritet, er det mye innhold der ute - og ikke alt er bra.
Dette er ikke et unikt problem med PHP - en rask titt på W3Schools.com vil ødelegge drømmene til noen som helst proponent av xHTML, JavaScript, CSS eller PHP.
PHP devs lider av? Ikke oppfunnet her syndrom.?
Det kan være veldig enkelt, når du lærer språk, å finne det du mener er en autoritativ ressurs (som kan være utdatert eller bare feil) og følge med med hva de er? Undervisning? du. Dette er noe PHP-fellesskapet trenger å få mye bedre på - å spre "riktig"? måte å utføre visse oppgaver på. Jeg innrømmer at Ruby-samfunnet har fordelen her, Rick Olson løste autentisering for alle når han løste Restful-Authentication plugin. J
PHP utviklere, for de første par årene, lider av? Ikke oppfunnet her syndrom? - som jeg ikke tror er en dårlig ting (til de begynner å selge det eller overføre det til andre). Jeg tror tankene bak en ny utvikler, som opplever PHP for første gang, er at de virkelig vil forstå akkurat hva som skjer - og PHP gjør en perfekt jobb med å gi dem nok tau til å henge seg? - avslørende nok til å lære, men du sannsynligvis kommer til å skade deg selv. Mens, og ikke for å diskutere Ricks plugin (som er et kjempebra autentiseringssystem), er Rails-utviklere villige til å anta at denne fyren har det riktig og fortsetter på vei.
PHP ble enormt populært fordi det var på rett sted til rett tid.
Ryan: Jeg vil si PHP ble enormt populært fordi det var på rett sted til rett tid. Alternativene for server side utvikling tilbake i dag krevde en del programmeringskunnskap, men mange mennesker som aldri trodde seg selv som programmerere, kaste allerede ting sammen med HTML og CSS. Etter samme distribusjonsmetafor og en grunnleggende forståelse av hvordan du legger sammen nettsteder kan du lage moderat nyttige programmer og kaste dem opp på en billig delt webverten. Eller du kan laste ned en som noen andre laget og justere den litt fordi HTML og koden ble blandet sammen.
En annen ting som hjalp PHP sammen var bommen av likes som cPanel-produktet og hosting-leverandørene, hvite merking web hosting. Hver mann og hunden hans kunne bli en webverten til lav pris og uten teknisk kunnskap. Hver mann og hunden hans ønsket et nettsted og billig hosting. PHP og MySQL var aksjestandard på disse delte oppsettene, og de var overalt (og fortsatt er).
Det beste gjør ikke alltid "vinn", men mange mennesker er fortsatt irritert over at SmallTalk mistet Java, selv om menneskene jeg har møtt (seriøse programvareveteraner) som var der da dette skjedde, sier de føler seg ganske hjemme i Ruby!
Ryan: Dette er ikke veldig bra, men jeg vil si at felles kritikk av PHP er ganske gyldig og skyldes måten? Språket? ble designet (eller heller ikke utformet). PHP ble født ut av en rekke CGI-skript som den opprinnelige forfatteren skrev i C (eller var det Perl?), Og det vanlige tilfellet av hvorfor PHP gikk slik det gjorde var så? Jeg kunne ha en C-programmeringsskript for Internett på bare noen få dager?.
Jeg husker aldri å spørre en C-programmør for å gjøre meg en webapplikasjon!
Ruby derimot ble designet for å ta det beste fra en rekke språk for å skape noe som var en glede å jobbe med, det har tatt tegn fra Smalltalk, Perl, LISP og andre, og det viser.
En veldig stor forskjell mellom PHP og Ruby for meg var at Ruby oppfordrer deg til å jobbe med sine grunnleggende datatyper som Hashes og Arrays, der jeg aldri fant dem naturlige i PHP. Antall ganger jeg måtte se opp på rekkefølgen av argumenter for String and Arrays i PHP, er det noe å skryte av.
Antall ganger jeg ikke kunne huske om denne eller den funksjonen hadde understreker eller ikke, var like irriterende. Jeg brukte Zend IDE, så jeg måtte ikke huske, men jeg likte ikke IDE. Det føltes som om du var forbannet hvis du gjorde det og forbannet hvis du ikke gjorde det. Det er ingen sammenheng i PHPs standardbibliotek, og det er frustrerende som en rasende bjørn i en telefonboks. I Ruby bruker jeg sjelden tid på dokumentasjon for vanlige datatyper fordi de vanlige samspillet er så lett å huske.
Når du begynner å bruke funksjoner i Ruby's Enumerable-modulen, vil du lure på hvordan du noen gang har bodd uten den, rosa sverd!
Michael: Jeg tror dette er en refleksjon av barriere for oppføring og arv nysgjerrighet PHP utviklere å virkelig forstå hva som skjer. Jeg hadde lest / studert hundrevis av hvite papirer, blogger, artikler om autentiseringssystemer - men det var ikke før jeg bygget min egen som jeg virkelig følte som om jeg visste hva som foregikk. Jeg tror at nye PHP-utviklere er ivrige etter å dele det de har gjort med resten av verden, og blir ofte slått for å gjøre det, fordi de ikke fulgte best praksis eller bevist sikkerhetsmønstre.
Michael: Jeg tror både PHP og Ruby har alvorlige problemer i dokumentasjonen deres - og for helt motsatte grunner.
PHP har tonnevis av dokumentasjon, takket være senioritet - du kan finne svaret på et spørsmål med et raskt Google-søk, og det kommer til å fungere. Er det den beste løsningen? Kanskje, kanskje ikke?
Rails har vokst så raskt, at selv jeg har det vanskelig å holde opp.
Ruby har stor dokumentasjon, men i virkeligheten ser dette ut til å være et rammeverk mot rammeproblem, så vi antar Rails. Rails har vokst så raskt, at selv jeg har det vanskelig å holde opp. Rails API dokumentasjon er flott; men når det kommer til dokumentasjon fra tredjepart (bøker, blogartikler, StackOverflow-svar) - de er alle utdaterte, og mens du følger med denne informasjonen, er det veldig vanskelig å feilsøke problemet og fikse det.
I dette henseende tror jeg PHP har fordelen som de enkelte rammeverkene (CodeIgniter, FuelPHP, Kohana, CakePHP, etc) kan redusere denne effekten til en viss grad. Hvis du bruker en av disse rammene, er det enkelt å finne det endelige svaret for det du leter etter.
Ryan: Da jeg brukte PHP, ble det lagt stor vekt på hvor fantastisk kommentarene i PHP.net-dokumentasjonen var. Filosofien syntes å være å "skrive dokumentasjonen en gang, og la folk legge til sine to cent". Problemet med dette er at kommentarer legges ut i rekkefølge med innlegg, noe som betyr at de gode ikke filtrerer seg til toppen, og eventuelle innsikt som deles i dem, ble ikke arbeidet inn i dokumentasjonen i tide (eller i det hele tatt).
Så mye av den felles API er inkludert i PHP-kjernen, som ikke endrer det ofte, så jeg tror en wiki-løsning ville være mer hensiktsmessig. På den måten kan samfunnet endre den offisielle dokumentasjonen, foreslå endringer, foreslå eksempler, integrere det gode fra kommentarene til hva folk ser først. Det ville være nyttig (spesielt til en nybegynner).
Java-kurs lærer folk om polymorfisme først og ser på hva de gjør - design med klasshierarkier som en første kutt! Det gjør meg gal!
I Ruby er mange av de brukte bibliotene på GitHub, der folk kan sende små endringer og forbedringer som blir rullet inn i det som vanligvis er en vanlig utgivelses syklus. Dokumentasjon er koblet sammen i kode ved hjelp av RDoc (som ligner på PHPDoc), og når du installerer en perle genererer det dokumentasjon på ditt lokale system. For mye av arbeidet mitt, vil jeg enten lese kjerne dokumentasjon på rubydoc.info, eller lokalt på min maskin, eller hvis noen av dem mislykkes i bibliotekets kildekode selv.
Vi har hørt Ryan og Mikaels tanker, og du har absolutt dine egne synspunkter. Fortsett debatten i kommentarene!
