Share
Det är dags; Kö på temaet "Going the Distance" från Rocky. I den röda ringen: Envato utvecklare extraordinaire, Ryan Allen, som byggde den ursprungliga FlashDen med sina kalla, blotta händer. I det blå hörnet: Michael Wales, en välkänd medlem i PHP och CodeIgniter communities. Slaget? PHP vs Ruby. Bekämpa!
Det måste noteras att denna typ av debatter är rent för skoj och utbildningsändamål. Det finns tillfällen då du väljer PHP för ett projekt, och det finns tillfällen då du väljer Ruby. Målet med denna serie är dock att lära på vilket sätt och när att göra dessa typer av beslut. Snarare än "ditt språk suger", är dessa debatter menade att skissera Varför du kanske, i vissa situationer, väljer den ena över den andra.
Ryan Allen är en webbsoftware och systemingenjör som har arbetat för Envato sedan för alltid. Han byggde och stödde de tidiga versionerna av Envato Marketplaces i Ruby on Rails, och ser nu efter Tuts + -systemen, bland annat.
Michael Wales är en webbutvecklare för amerikanska myndigheter, och är en aktiv bidragsyter till PHP och CodeIgniter communities.
Ryan: PHP var ett av de första programmeringsspråk jag arbetade med (bortsett från ActionScript och lite kortfattat Visual Basic). Jag började bygga saker med PHP år 2001. Jag arbetade ganska exklusivt med det som ett verktyg för backend fram till slutet av 2005, när Ruby (och Rails) tog sin plats.
Michael: PHP var min introduktion till webutvecklingsvärlden 1999, så jag skulle vilja säga att jag har en ganska solid förståelse för sin position inom vår bransch, dess historia och den riktning som den ligger i. Ruby, som många andra, fick mitt öga med utgivandet av Rails och framgången för 37signals. Jag har en ganska solid förståelse för Ruby, som ett skriptspråk i mina systemadministrationsuppgifter (Capistrano) samt några personliga och roliga projekt (Gosu-spelutvecklingsbiblioteket och Rails). Jag skäms över att erkänna att jag inte är så bekant med Rails senaste versioner och det är definitivt på min lista över saker att återfatta mig med.
Michael: Tyvärr kan jag inte ge ett definitivt svar på detta - åtminstone inte som du förväntar dig, eftersom PHP och Ruby är två helt olika djur. PHP är en sammanslagning av språk och webbramar i ett paket, medan Ruby är ett programmeringsspråk med många ramar tillgängliga.
Om ditt fokus är webbutveckling och det är allt du verkligen vill fokusera på just nu, skulle jag definitivt rekommendera dig att lära dig PHP först.
Så om ditt fokus är webbutveckling och det är allt du verkligen vill fokusera på just nu skulle jag definitivt rekommendera dig att lära dig PHP först av ett antal anledningar:
Som utvecklare med 12 års erfarenhet uppskattar jag genvägarna. Rails leder till vår bransch; men det är bara för att jag förstår vad som faktiskt pågår bakom kulisserna.
Om du vill bli utvecklare (webbutvecklare, systemadministratörsskript, spelutvecklare, API-utvecklare) som förstår låga nivåer av datavetenskapskoncept, objektorienterad programmering och i allmänhet utvecklar dina kritiska tänkande färdigheter - det säger sig självklart, börja med Ruby, det är ett verkligt programmeringsspråk (kom ihåg, PHP är en webbram förklädd som ett språk).
Ur ett webbutvecklareperspektiv tror jag att det här också är en av Rubys (och Pythons, BTW) nedgångar - är det verkligen ingen mellannivå? inkörsport. Du förstår antingen HTTP-protokollet, med förmågan att skriva din egen stack, topp-till-botten eller gå med en av "magical", håll din hand för att skapa en CRUD-systemram?.
Det här är verkligen det område där PHP lyser. Om du går utöver gränserna för CRUD behöver du inte ha en extrem förståelse för hur en HTTP-server fungerar för att göra dina drömmar verklighet.
Ryan: Om jag skulle lära mig någon programmering från början, föredrog jag att lära dem Ruby (problem med att skapa miljöer åt sidan - men det blir lättare). Ett vanligt sätt att starta någon (efter kanske variabler och skriva ut dem) är att förklara arrays med, till exempel, en lista på köpslistor, ta den här biten av PHP:
Accentsconagua
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); för ($ i = 0; $ i < count($shopping_list); $i++) echo $shopping_list[$i]; När jag lärde mig PHP, lärde jag mig att använda för loopar (som jag var i ActionScript), när en mer kortfattad och mindre felbenägen förekomstslinga redan fanns (som det också gjorde i ActionScript). Jag var tvungen att lära mig allt om denna $ i = 0 sak, det här testet och denna inkrementor sak. Det var allt så förvirrande! Antalet gånger jag har skruvat upp för loopar är otalbart (ingen ordsprog är avsedd). Här är vad samma sak skulle se ut i Ruby:
shopping_list = ['Milk', 'Cheese', 'Hovercraft'] shopping_list.each do | shopping_item | sätter shopping_item slutet
Det finns mycket mindre syntax där, och iteratorer är enligt min mening mycket lättare att förstå och arbeta med. Men för fullständighetens skull, här är PHP-exemplet men med förhand:
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); foreach ($ shopping_list som $ shopping_item) echo $ shopping_item; Tja, det är inte illa faktiskt! Jag tror att du bara bör använda för slingor att räkna till 10 och saker som det, foreach är så mycket lättare att läsa och undervisa och så mycket svårare att skruva upp. Och iteratorer är ännu bättre, så jag skulle gå med Ruby.
Ryan: Försäljningsplatsen för mig (2005) var Rails-ramen. Jag hade försökt min hand på webbutveckling med Python men att jag var oerfaren Jag hade lite svårt, inte veta vad jag ska göra eller var att se (men jag lyckades bygga några saker, så ta det!), Men jag ville verkligen använd Python dagligen eftersom jag kände att det hade en bättre och mer avsiktlig design och jag gillade syntaxen. Och eftersom ormar är svalare än elefanter.
ActiveRecord var bara så fantastiskt!
Jag har aldrig arbetat med något annat än ADODB i PHP och försökte och misslyckades med att göra en ORM många gånger (jag hade ingen aning om hur en ORM var men jag visste att jag ville ha något som på något sätt kartlade klasser till databastabeller) när jag först såg ActiveRecord Det var som om alla mina kristuskomster hade kommit på en gång.
Jag visste relationsdatabaser ganska bra men var sjuk att skriva samma SQL om och om igen. ActiveRecord var bara så fantastisk! Och Ruby var nära nog att Python Jag var glad som Larry (vem han är) för att ha en ram jag kunde få upptagen och börja bygga saker. Så för mig var det kärlek till ett bibliotek och en kärlek till syntaxen.
Numera har vi massor av fantastiska rubybibliotek, skrivna av begåvade individer, bibliotek som Sinatra (en lätt webram), Nokogiri (en HTML / XML-parser), Sequel (ett högdatabibliotek), RSpec (ett automatiserat testbibliotek). Alla dessa bibliotek kan installeras som RubyGems som jag tyckte mycket enklare och användarvänligt att arbeta med än PHP: s PEAR-system.
Gemenskapen är fortfarande ganska levande, även några år i, och företag anställer Ruby-utvecklare som varmkakor. Ruby 1.9 är uppenbarligen nästan lika snabb som PHP nu också, så det finns många försäljningsställen!
Ruby 1.9 är uppenbarligen nästan lika snabb som PHP nu också, så det finns många försäljningsställen!
Michael: Jag tror att det här bara är en naturlig utveckling av utvecklare (från webbutveckling för att söka övergripande kunskaper om OOP-språk och en övergripande datateknikutbildning) i allmänhet - jag vet att det var rutten jag tog.
Jag tror att den största nedgången till denna dag är praxisen att plocka ett språk och hålla sig till det till döden. Det är inte hur den verkliga världen fungerar.
Jag anser mig själv som en utvecklare? - Språket är därför en tvetydig kvalifikation som varumärke av tv till en Best Buy-säljare. Det finns fall där jag väljer PHP (om det finns en extremt kort tidslinje - utanför CRUD, det är det språk jag är mest känd i), det finns andra där jag väljer Ruby (distribuering via Capistrano eller grundläggande CRUD med Rails) och , ännu längre, Python - som jag föredrar för Serveradministrationens uppgifter och analysering av olika filer.
Michael: Jag tror att utvecklare ofta kan fånga sig i den nya hotnessen, gammal busted? dille. Därför ligger mitt team alltid innan vi börjar ett projekt, vi lägger ut kraven (i både användarvillkor och utvecklarvillkor - vilket är två väldigt olika saker) och vi pratar ut med mycket lilla språk / rampreferenser i åtanke . I förra veckan analyserade vi några GBs meddelandebloggar med Perl. I veckan byggde vi en applikation vars primära vy var en ExtJS GridPanel (eftersom vi har utökat CodeIgniter-kärnfiler som hanterar alla situationer ExtJS kasta hos oss med 3-rader kod).
Det handlar om hur mycket tid vi har och hur kan vi producera den bästa produkten i den tidsramen?
Ryan: Absolut, vissa människor (själv medföljer) vänjer mig att utforma saker på ett visst sätt att de inte vill återuppläras och förändra alla sina vanliga intäkter. När du är produktiv med någonting, varför skulle du bry dig om att ändra den?
En annan tankegång är de fler språk och verktyg du har erfarenhet, du kan kombinera de bästa teknikerna och idéerna oavsett vilken miljö du arbetar med (de säger det här om att lära LISP, men jag har inte lärt mig det ännu ).
Unga programmerare hoppar på de glänsande nya sakerna, men när du blir äldre och mer mogen, vill du arbeta med små verktyg som är enkla och robusta. Om du inte använder alla funktioner och alla bibliotek som finns tillgängliga i Ruby kan du bli enkelt och robust utan för mycket besvär.
Ett ord: underhåll.
Ryan: Ja, ett ord: underhåll. Programvaruprojekt har en benägenhet att kräva modifikationer över tiden, och den ursprungliga författaren av programmet kommer inte alltid att vara den person som gör ändringarna. Låt oss säga att hypotetiskt teleporter är uppfunna och det finns en världsomspännande Ruby-konferens och varje enskild kan Ruby-utvecklare i världen går (teleporter rock!). Låt oss nu också säga att jorden hypotetiskt är Middle Earth, och Smaug draken är ganska irriterad om den här hela Ruby-saken (drakar föredrar Python, du ser) och bestämmer dig för att besöka och slänga alla utvecklarna otroligt. Nu finns det inga erfarna Ruby-utvecklare kvar i världen, oh kära! Nu har du det här problemet med att inte ha en pool av Ruby-utvecklare tillgängliga för att arbeta med dina projekt. Vad ska vi göra Gandalf?
När jag väljer verktyg tänker jag ofta på vem som kommer att behöva behålla projektet om jag träffas av en buss (eller krasch min motorcykel, vilket är mer sannolikt).
Jag skulle verkligen inte skriva någonting i Haskell eller LISP eller till och med F # eftersom vi skulle ha svårt att anställa någon som kunde eller skulle arbeta med det. Tillgänglighet av talang och befintlig talang i ett företag påverkar sålunda mitt beslut.
Det finns en annan situation där jag skulle överväga språket, och det skulle vara om jag sålde en produkt, säg en anpassad CMS-försäljning på Code Canyon. Jag skulle inte skriva det i Ruby eftersom råvara webbhotell inte stödjer det generellt. Medan PHP är ganska lätt tillgängligt överallt och webbdesigners och mindre erfarna programmörer är lite bekanta med det.
Det finns en annan situation där jag skulle överväga språket, och det skulle vara om jag sålde en produkt, säg en anpassad CMS-försäljning på Code Canyon. Jag skulle inte skriva det i Ruby eftersom råvara webbhotell inte stödjer det generellt. Medan PHP är ganska lätt tillgängligt överallt och webbdesigners och mindre erfarna programmörer är lite bekanta med det.
Michael: Se mina svar för # 3 / # 4.
Michael: Personligen skulle jag rekommendera Django-ramverket för Python. Det var utformat med det här ändamålet i åtanke: möjligheten att få utvecklarna att arbeta med datamodellering och visa data på skärmen så snabbt som möjligt, med lättanvända taggar för designers att presentera data på ett vackert sätt, medan utvecklarna fortsätter att arbeta med affärsreglerna i en samtidig cykel.
Ryan: Om du har erfarenhet att kasta ihop HTML och CSS och ladda upp dem med FTP, så rekommenderar jag antagligen PHP, eftersom det har låga hinder för tillträde eftersom du redan är bekant med sin metafor (Wrap your code in .php förlängning! Borta går du!). Men om du började programmera seriöst, skulle jag föreslå att du förgrenar dig och tittar på andra saker (som Ruby) för att bredda dina horisonter.
När sakerna går fel kommer din brist på kunskap att komma tillbaka och bita dig.
Ofta ser jag PHP-programmerare som arbetar med relationsdatabaser och har väldigt lite förståelse för hur de fungerar. Så egentligen kan du få saker gjorda utan en djup förståelse för den teknik du jobbar med (du använder sällan PHP allt på egen hand), men när sakerna går fel kommer din brist på kunskap att komma tillbaka och bita dig. Hur mycket tid måste du investera i att lära sig dessa saker? Kan du gå till någon för hjälp om du fastnar? Lär dig PHP så att du kan få jobba med det, eller bara för skojs skull? Valet är en ganska öppen fråga, beroende på vad dina mål är.
När det gäller terminaler är de kort sagt AWESOME. Jag använder dem hela tiden. Ja, de har en inlärningskurva (men vad gör det inte?). När du väl har tagit hand om dem och börjar skriva egna egna program kan du inte fortsätta utan dem. För att vara rättvis hittade jag inte Kommandotolken i Windows väldigt användbar, men när jag bytte till en Mac och hade tillgång till alla Nix kul under huven har det blivit ganska produktivt.
Ruby har hype, vibrancy och sex appeal.
Ryan: Jag skulle säga något Ruby har för tillfället att PHP inte är hype, vibrancy och sex appeal. Ruby är otvetydigt sexig. Kvinnor älskar det. Män vill vara som det. Godzilla räddar det. Jag föreslår att jag hoppas över till en Ruby User Group och du hittar en varierad grupp människor som bara älskar att koda, älskar att göra saker och teknik i allmänhet. När jag började träffa människor i det lokala Ruby-samhället var det Första gången i mitt liv kände jag att jag var med mitt folk.? Jag trodde ärligt att jag var den enda programmeraren på planeten som bryr sig om sitt arbete fram tills dess. Det var väldigt uppfriskande och jag har lärt mig mycket sedan dess, mestadels från de människor jag har träffat genom dessa grupper.
Det här är en hemlighet: om PHP släppte en officiell uppdatering med en alternativ syntax (mer Ruby / Python-liknande) och paketerade det befintliga standardbiblioteket i stil med de populära Ruby-biblioteken (och gjorde det konsekvent) och hade bakåtkompatibilitet och förmåga att integrera med arvskoden, skulle det vara en mördare produkt. Berätta inte för någon jag sa det.
Michael: Enkelt att distribuera, en graciös introduktion till de lägre begreppen webbutveckling och över ett sekel dokumentation och goda bästa metoder.
Michael: Återigen - enkel implementering, en graciös introduktion till de lägre nivåerna av webbutveckling och över ett sekel dokumentation och goda bästa metoder.
Men allvarligt - på grund av det låga hinderet för inmatning med PHP kan det vara svårt att urskilja skillnaden mellan någon som faktiskt vet vad de pratar om och någon på samma kompetensnivå som dig som hade en extra domän för en blogg. Plus, på grund av PHPs stora anställningstid, finns det mycket innehåll där ute - och inte allt är bra.
Detta är inte ett unikt problem med PHP - en snabb titt på W3Schools.com kommer att förstöra drömmarna om någon förespråkare av xHTML, JavaScript, CSS eller PHP.
PHP devs lider av? Inte uppfunnit här syndrom.?
Det kan vara väldigt lätt att hitta vad du tror på att vara en auktoritativ resurs (som kan vara omodern eller helt enkelt fel) och följa med vad de är undervisning när du lär dig ett språk. du. Detta är något som PHP-samhället behöver bli bättre på - sprida? sätt att utföra vissa uppgifter. Jag ska erkänna - Ruby community har fördelen här, Rick Olson löst autentisering för alla när han släppte Restful-Authentication plugin. J
PHP-utvecklare, för deras första år, lider av? Inte uppfunnit här syndrom? - som jag inte tror är en dålig sak (tills de börjar sälja det eller vidarebefordra det till andra). Jag tror att tanken bakom en ny utvecklare, som upplever PHP för första gången, är att de verkligen vill förstå exakt vad som händer - och PHP gör ett perfekt jobb med att ge dem tillräckligt rep att hänga sig? - avslöjande nog att lära sig, men du kommer förmodligen att skada dig själv. Och för att inte rabatt Ricks plugin (vilket är ett fantastiskt autentiseringssystem) är Rails-utvecklare villiga att anta att den här killen har rätt och fortsätter på vägen.
PHP blev oerhört populärt eftersom det var på rätt ställe vid rätt tidpunkt.
Ryan: Jag skulle säga att PHP blev oerhört populärt eftersom det var på rätt ställe vid rätt tidpunkt. Alternativen för utveckling av serversidan tillbaka på dagen krävde en hel del programmeringskunskap, men många som aldrig tänkt på sig själva som programmerare kastade redan saker tillsammans med HTML och CSS. Efter samma installationsmetafor och en grundläggande förståelse för hur man sätter webbplatser tillsammans kan du göra måttligt användbara program och kasta dem upp på en billig delad webbhotell. Eller du kan ladda ner en som någon annan gjorde och tweak upp lite eftersom HTML och kod var blandade ihop.
En annan sak som hjälpte PHP tillsammans var den boom som gillar cPanel-produkten och värdleverantörerna med vit märkning webbhotell. Varje man och hans hund kan bli en webbhotell till låg kostnad och utan teknisk kunskap. Varje man och hans hund ville ha en webbplats och billig värd. PHP och MySQL var lagerstandard på dessa gemensamma inställningar, och de var överallt (och fortfarande är).
Det bästa gör inte alltid "vinna", många människor är fortfarande irriterade över att SmallTalk förlorade Java, men de människor jag har träffat (seriösa programveteraner) som var där när det hände, säger att de känner sig riktigt hemma i Ruby!
Ryan: Det här är inte så bra, men jag säger att den gemensamma kritiken av PHP är ganska giltig och beror på hur språket? utformades (eller snarare inte utformad). PHP föddes ur ett antal CGI-skript som den ursprungliga författaren skrev i C (eller var det Perl?), Och det vanliga fallet varför PHP gick som det gjorde var så? Jag kunde ha en C-programmeringsskrivare för webb på bara några dagar?.
Jag minns inte någonsin att jag frågar en C-programmerare att göra mig en webbapplikation!
Ruby å andra sidan var utformad för att ta det bästa från ett antal språk för att skapa något som var en glädje att arbeta med, det har tagit ledtrådar från Smalltalk, Perl, LISP och andra, och det visar.
En stor skillnad mellan PHP och Ruby för mig var att Ruby uppmuntrar dig att arbeta med sina grundläggande datatyper som Hashes och Arrays där jag aldrig hittade dem naturligt i PHP. Antalet gånger jag var tvungen att leta upp ordningsgraden för String and Arrays i PHP är en överraskning.
Antalet gånger jag inte kunde komma ihåg om den här eller den här funktionen hade understreck eller inte var lika irriterande. Jag använde Zend IDE så jag behövde inte komma ihåg men jag tyckte inte om IDE. Det kände som om du var fördömd om du gjorde och fördömde om du inte gjorde det. Det finns ingen konsistens i PHP: s standardbibliotek och det är frustrerande som en rasande björn i en telefonlåda. I Ruby spenderar jag sällan tid i dokumentation för vanliga datatyper eftersom de gemensamma interaktionerna är så lätta att komma ihåg.
När du börjar använda funktioner i Ruby's Enumerable-modulen kommer du att undra hur du någonsin levt utan det, rosa svär!
Michael: Jag tycker att det här är en återspegling av det lågtrafikerade inträdet och PHP-utvecklarens arvfärdighet att verkligen förstå vad som händer. Jag hade läst / studerat hundratals vitpapper, bloggar, artiklar om autentiseringssystem - men det var inte förrän jag byggde min egen som jag verkligen kände som om jag visste vad som händer. Jag tror att nya PHP-utvecklare är angelägna att dela med sig av vad de har gjort med resten av världen och slår ofta in för att göra det, eftersom de inte följde bästa praxis eller beprövade säkerhetsmönster.
Michael: Jag tror att både PHP och Ruby har allvarliga problem i sin dokumentation - och av helt motsatta skäl.
PHP har massor av dokumentation tack vare dess anställningstid - du kan hitta svaret på någon fråga med en snabb Google-sökning och det kommer att fungera. Är det den bästa lösningen? Kanske kanske inte?
Rails har växit så snabbt, att jag ens har svårt att hålla upp.
Ruby har stor dokumentation, men i verkligheten verkar detta vara en ram vs. ramfråga, så vi antar Rails. Rails har växit så snabbt, att jag ens har svårt att hålla upp. Rails API-dokumentation är stor; men när det gäller dokumentation från tredje part (böcker, bloggartiklar, StackOverflow-svar) - de är alla outdated och medan du följer med den här informationen är det väldigt svårt att felsöka problemet och fixa det.
I det avseendet tror jag att PHP har fördelen eftersom de enskilda ramarna (CodeIgniter, FuelPHP, Kohana, CakePHP, etc) kan mildra denna effekt till viss del - om du använder en av dessa ramar är det enkelt att hitta det slutgiltiga svaret för vad du letar efter.
Ryan: När jag använde PHP satsades mycket på hur grymt kommentarerna i PHP.net-dokumentationen var. Filosofin tycktes vara att "skriva dokumentationen en gång och låt folk lägga till sina två cent". Problemet med detta är att kommentarer läggs ut i skickningsordning vilket innebär att de goda inte filtrerar till toppen och alla insikter som delas i dem har inte arbetat med i dokumentationen i tid (eller alls).
Så mycket av det gemensamma API ingår i PHP-kärnan, vilket inte ändras så ofta, så jag tror att en wiki-lösning skulle vara mer lämplig. På så sätt kan samhället ändra den officiella dokumentationen, föreslå ändringar, föreslå exempel, integrera godet från kommentarerna till vad folk ser först. Det skulle vara användbart (särskilt för en nybörjare).
Java-kurser lär ut människor om polymorfismen först och tittar på vad de gör - design med klasshierarkier som en första snitt! Det gör mig galen!
I Ruby finns många av de vanliga biblioteken på GitHub, där människor kan lägga fram små förändringar och förbättringar som rullar in i vad som vanligtvis är en vanlig frisläppningscykel. Dokumentationen är uppkopplad i kod med RDoc (som liknar PHPDoc), och när du installerar en pärla genererar det dokumentation på ditt lokala system. För mycket av mitt arbete ska jag antingen läsa kärndokumentation på rubydoc.info eller lokalt på min maskin, eller om någon av dem misslyckas i bibliotekets källkod själv.
Vi har hört Ryan och Mikaels tankar, och du har verkligen dina egna åsikter. Fortsätt debatten i kommentarerna!
