Share
È tempo; in coda il tema "Andando lontano" da Rocky. Nel ring rosso: lo sviluppatore straordinario Envato, Ryan Allen, che ha costruito l'originale FlashDen con le sue fredde mani nude. Nell'angolo blu: Michael Wales, un membro ben noto nelle comunità PHP e CodeIgniter. La battaglia? PHP vs. Ruby. Combattimento!
Va notato che questi tipi di dibattiti sono puramente per scopi educativi e divertenti. Ci sono momenti in cui scegli PHP per un progetto, e ci sono momenti in cui sceglieresti Ruby. L'obiettivo di questa serie, tuttavia, è imparare Come e quando prendere questo tipo di decisioni. Piuttosto che "la tua lingua fa schifo", questi dibattiti hanno lo scopo di delineare perché potresti, in certe situazioni, sceglierne uno sull'altro.
Ryan Allen è un software web e ingegnere di sistemi che lavora per Envato da sempre. Ha costruito e supportato le prime versioni di Envato Marketplaces in Ruby on Rails e ora si occupa dei sistemi Tuts +, tra le altre cose.
Michael Wales è uno sviluppatore web per agenzie governative degli Stati Uniti e contribuisce attivamente alle comunità PHP e CodeIgniter.
Ryan: PHP è stato uno dei primi linguaggi di programmazione con cui ho lavorato (oltre a ActionScript e alcuni brevissimi Visual Basic). Ho iniziato a costruire cose con PHP nel 2001. Ho lavorato quasi esclusivamente con esso come strumento di back-end fino alla fine del 2005, quando Ruby (e Rails) ha preso il suo posto.
Michael: PHP è stata la mia introduzione al mondo dello sviluppo web, nel 1999 - quindi mi piacerebbe dire che ho una comprensione abbastanza solida della sua posizione nel nostro settore, nella sua storia e nella direzione in cui è diretta. Ruby, come molti altri, ha catturato la mia attenzione con il rilascio di Rails e il successo di 37signals. Ho una conoscenza abbastanza solida di Ruby, come linguaggio di scripting nei miei compiti di amministrazione di sistema (Capistrano) così come alcuni progetti personali e divertenti (la libreria di sviluppo del gioco Gosu e Rails). Mi vergogno di ammettere che non ho familiarità con le ultime versioni di Rails ed è sicuramente sulla mia lista di cose per riacquistarmi.
Michael: Sfortunatamente, non posso dare una risposta definitiva a questo - almeno non come ti aspetti, dato che PHP e Ruby sono due animali completamente diversi. PHP è un amalgama di lingua e framework web in un unico pacchetto, mentre Ruby è un linguaggio di programmazione con numerosi framework disponibili.
Se il tuo obiettivo è lo sviluppo web e questo è tutto ciò su cui volevi davvero concentrarti ora, ti consiglierei sicuramente di imparare PHP in primo luogo.
Quindi, se il tuo obiettivo è lo sviluppo web e questo è tutto ciò su cui volevi davvero concentrarti adesso, ti consiglierei sicuramente di imparare PHP in primo luogo per una serie di motivi:
Come sviluppatore con 12 anni di esperienza, apprezzo le scorciatoie che Rails porta nel nostro settore; ma, è solo perché capisco cosa sta succedendo dietro le quinte.
Se vuoi diventare uno sviluppatore (sviluppatore web, script di amministrazione del sistema, sviluppatore di giochi, sviluppatore API) che comprende concetti di basso livello di informatica, programmazione orientata agli oggetti e, in generale, migliora le tue capacità di pensiero critico - è ovvio, inizia con Ruby, è un vero linguaggio di programmazione (ricorda, PHP è una struttura web camuffata come una lingua).
Dal punto di vista di un Web Developer, penso che questo sia anche uno dei cali di Ruby (e di Python, BTW) - è che non ce n'è davvero? Di livello medio? punto d'entrata. O comprendi il protocollo HTTP, con la possibilità di scrivere il tuo stack, dall'alto verso il basso, o vai con uno dei "magici", tieni la mano per creare un framework di sistema CRUD?.
Questa è davvero l'area in cui splende PHP. Se stai oltrepassando i confini di CRUD, non hai bisogno di avere una comprensione estrema di come un server HTTP funzioni per rendere i tuoi sogni realtà.
Ryan: Se dovessi insegnare a qualcuno a programmare da zero, preferirei insegnare loro Ruby (problemi a mettere da parte gli ambienti - anche se questo è sempre più facile). Un modo comune per far partire qualcuno (dopo forse le variabili e stamparle) è di spiegare gli array con, ad esempio, un esempio di lista della spesa, prendi questo bit di PHP:
Accentsconagua
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); per ($ i = 0; $ i < count($shopping_list); $i++) echo $shopping_list[$i]; Quando ho imparato PHP, mi è stato insegnato ad usare i loop (come in ActionScript), quando esisteva già un ciclo foreach più succinto e meno soggetto a errori (come anche in ActionScript). Ho dovuto imparare tutto su questa cosa $ i = 0, questa cosa test e questa cosa incrementale. Era tutto così confuso! Il numero di volte in cui ho incasinato i loop non è numerabile (non è previsto il gioco di parole). Ecco come sarebbe la stessa cosa in Ruby:
shopping_list = ['Milk', 'Cheese', 'Hovercraft'] shopping_list.each do | shopping_item | mette fine shopping_item
C'è molta meno sintassi lì, e gli iteratori sono nella mia mente, molto più facili da capire e da lavorare. Ma per completezza, ecco l'esempio di PHP ma con un foreach:
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); foreach ($ shopping_list come $ shopping_item) echo $ shopping_item; Bene, non è poi così male! Immagino che dovresti usare solo i loop per contare fino a 10 e cose del genere, perché foreach è molto più facile da leggere e insegnare e molto più difficile da rovinare. E gli iteratori sono ancora meglio, quindi andrei con Ruby.
Ryan: Il punto vendita per me (nel 2005) era il framework Rails. Avevo provato la mia mano nello sviluppo web con Python ma essendo inesperto ho avuto un po 'di difficoltà, non sapendo cosa fare o dove guardare (ma sono riuscito a costruire alcune cose, quindi prendilo!), Ma volevo davvero usa Python giorno per giorno perché sentivo che aveva un design migliore, più deliberato e mi piaceva la sintassi. E perché i serpenti sono più freschi degli elefanti.
ActiveRecord era semplicemente fantastico!
Non avendo mai lavorato con PHP oltre ad ADODB, e provando e fallendo nel creare un ORM molte volte (non avevo idea di cosa fosse un ORM ma sapevo di volere qualcosa che mappasse in qualche modo le classi alle tabelle del database), quando ho visto ActiveRecord per la prima volta era come se tutti i miei Natale fossero venuti subito.
Conoscevo i database relazionali piuttosto bene, ma ero stanco di scrivere sempre lo stesso SQL. ActiveRecord è stato semplicemente fantastico! E Ruby era abbastanza vicino a Python. Ero felice che Larry (chiunque fosse lui) avesse una struttura che potevo darmi da fare e iniziare a costruire cose. Quindi per me è stato l'amore per una biblioteca e l'amore per la sintassi.
Oggigiorno abbiamo un mucchio di incredibili librerie Ruby scritte da persone di talento, librerie come Sinatra (un leggero framework web), Nokogiri (un parser HTML / XML), Sequel (una libreria di database di alto livello), RSpec (una libreria di test automatizzata). Tutte queste librerie sono installabili come RubyGems che ho trovato molto più facile e user friendly con il sistema PEAR di PHP.
La community è ancora abbastanza vivace, anche da qualche anno, e le aziende stanno assumendo sviluppatori di Ruby come hotcakes. Ruby 1.9 è ora quasi altrettanto veloce di PHP, quindi ci sono molti punti di forza!
Ruby 1.9 è ora quasi altrettanto veloce di PHP, quindi ci sono molti punti di forza!
Michael: Penso che questa sia solo una naturale evoluzione degli sviluppatori (dallo sviluppo Web alla ricerca di una conoscenza generale dei linguaggi OOP e di una generale educazione informatica) in generale - so che è stata la strada che ho intrapreso.
Penso che la più grande rovina, fino ad oggi, è la pratica di scegliere una lingua e attenersi ad essa fino alla morte. Non è così che funziona il mondo reale.
Mi considero uno? Sviluppatore? - quindi, il linguaggio è una qualifica ambigua come marchio della televisione a un venditore Best Buy. Ci sono casi in cui seleziono PHP (se c'è una timeline estremamente breve - al di fuori di CRUD, è la lingua in cui sono più familiare), ce ne sono altri in cui seleziono Ruby (distribuzione tramite Capistrano o CRUD di base con Rails) e , ancora di più, Python - che preferisco per le attività di amministrazione del server e l'analisi di vari file.
Michael: Penso che gli sviluppatori possano molto spesso rimanere intrappolati nella "nuova hotness", vecchia sballata? mania. Questo è il motivo per cui il mio team si siede sempre prima di iniziare un progetto, definiamo i requisiti (sia in termini di termini utente che di sviluppo - che sono due cose molto diverse) e ne parliamo, con pochissime preferenze di linguaggio / framework in mente . La scorsa settimana abbiamo analizzato alcuni GB di registri di messaggistica con Perl, questa settimana abbiamo creato un'applicazione la cui vista principale era un ExtJS GridPanel (perché abbiamo esteso i file core CodeIgniter che gestiscono qualsiasi situazione che ExtJS ci lancia con 3 righe di codice).
È tutto su quanto tempo abbiamo e come possiamo produrre il miglior prodotto in quel lasso di tempo?
Ryan: Assolutamente, alcune persone (me compreso) si abituano a progettare le cose in un certo modo che non vogliono reimparare e cambiare tutte le loro abitudini faticosamente guadagnate. Una volta che sei produttivo con qualcosa, perché dovresti preoccuparti di cambiarlo?
Un'altra scuola di pensiero è che più lingue e strumenti hai esperienza, sarai in grado di combinare le migliori tecniche e idee indipendentemente dall'ambiente in cui lavori (dicono questo sull'apprendimento di LISP, ma non l'ho ancora imparato ).
I giovani programmatori salteranno sulle cose nuove e brillanti, ma man mano che si invecchia e si matura, si vuole lavorare con piccoli strumenti semplici e robusti. Se non usi tutte le funzionalità e tutte le librerie disponibili in Ruby, puoi diventare semplice e robusto senza troppi problemi.
Una sola parola: manutenzione.
Ryan: Sì, una parola: manutenzione. I progetti software hanno la tendenza a richiedere modifiche nel tempo e l'autore originale del programma non sarà sempre la persona che sta apportando le modifiche. Diciamo ipoteticamente che i teletrasporti sono stati inventati e che esiste una conferenza mondiale su Ruby e che ogni singolo sviluppatore di Ruby in grado di farlo nel mondo (teletrasporta rock!). Ora diciamo che la Terra è ipoteticamente la Terra di mezzo, e Smaug il drago è piuttosto infastidito da tutta questa faccenda di Ruby (i draghi preferiscono Python, vedi) e decide di fare una visita e ingannare tutti gli sviluppatori per dispetto. Ora non ci sono sviluppatori di Ruby esperti lasciati nel mondo, oh caro! Ora hai questo problema di non avere a disposizione un pool di sviluppatori di Ruby per lavorare sui tuoi progetti. Cosa faremo Gandalf?
Quando scelgo gli strumenti, penso spesso a chi dovrà mantenere il progetto se vengo colpito da un autobus (o si blocca la mia moto, che è più probabile).
Di certo non scriverò nulla in Haskell o LISP o persino in F #, perché avremmo difficoltà a ingaggiare qualcuno che potesse o lavorasse su di esso. La disponibilità di talenti e talenti esistenti in un'azienda influenzano molto la mia decisione.
C'è un'altra situazione in cui prenderei in considerazione la lingua, e lo sarebbe se stessi vendendo un prodotto, ad esempio un CMS personalizzato che vende su Code Canyon. Non lo scriverei in Ruby perché il web hosting delle materie prime in genere non lo supporta. Mentre PHP è praticamente disponibile ovunque, i web designer e i programmatori meno esperti hanno una certa familiarità con esso.
C'è un'altra situazione in cui prenderei in considerazione la lingua, e lo sarebbe se stessi vendendo un prodotto, ad esempio un CMS personalizzato che vende su Code Canyon. Non lo scriverei in Ruby perché il web hosting delle materie prime in genere non lo supporta. Mentre PHP è praticamente disponibile ovunque, i web designer e i programmatori meno esperti hanno una certa familiarità con esso.
Michael: Vedi le mie risposte per # 3 / # 4.
Michael: Personalmente, consiglierei il framework Django per Python. È stato progettato con questo scopo in mente: la capacità di far lavorare gli sviluppatori sulla modellazione dei dati e visualizzare i dati sullo schermo il più rapidamente possibile, con tag facili da usare per i progettisti per presentare i dati in modo bello, mentre gli sviluppatori continuano lavorare sulle regole aziendali in un ciclo concorrente.
Ryan: Se hai esperienza nel mettere insieme HTML e CSS e caricarli con FTP, allora probabilmente consiglierei PHP, poiché ha delle barriere molto basse perché hai già familiarità con la sua metafora (avvolgi il tuo codice in .php estensione! Away you go!). Ma se hai iniziato a prendere sul serio la programmazione, ti suggerirei di ramificarti e di dare un'occhiata ad altre cose (come Ruby) per ampliare i tuoi orizzonti.
Quando le cose vanno male, la tua mancanza di conoscenza ritorna e morde.
Spesso vedo programmatori PHP che lavorano con database relazionali e che hanno ben poca comprensione di come funzionano. Quindi puoi davvero fare tutto senza una profonda conoscenza delle tecnologie con le quali stai lavorando (raramente usi PHP tutto da solo), ma quando le cose vanno male, la tua mancanza di conoscenza tornerà e morderà. Quanto tempo devi investire per imparare queste cose? Puoi andare da qualcuno per chiedere aiuto se rimani bloccato? Stai imparando PHP in modo da poter lavorare con esso, o solo per divertimento? La scelta è una domanda abbastanza aperta a seconda di quali sono i tuoi obiettivi.
Per quanto riguarda i terminali, sono, in breve, IMPRESSIONANTE. Li uso sempre. Sì, hanno una curva di apprendimento (ma cosa no?). Una volta che riesci a gestirli e iniziare a scrivere i tuoi piccoli programmi, non puoi continuare senza di loro. Per essere onesti, non ho trovato molto utile il prompt dei comandi di Windows, ma una volta passato a un Mac e ho avuto accesso a tutto il * nix divertimento sotto il cofano, è diventato piuttosto produttivo.
Ruby ha hype, vibrancy e sex appeal.
Ryan: Direi che attualmente Ruby ha che PHP non è hype, vivacità e sex appeal. Ruby è inequivocabilmente sexy. Le donne lo adorano Gli uomini vogliono essere come loro. Godzilla lo teme. Ti suggerirei di passare da un gruppo di utenti Ruby e troverai un gruppo eterogeneo di persone che amano semplicemente codificare, amare creare cose e la tecnologia in generale. Quando ho iniziato a incontrare persone nella comunità locale di Ruby, lo è stato la prima volta nella mia vita mi sentivo come se fossi con? la mia gente.? Onestamente pensavo di essere stato l'unico programmatore del pianeta a preoccuparsi del loro lavoro fino ad allora. È stato molto piacevole e da allora ho imparato molto, soprattutto dalle persone che ho incontrato attraverso questi gruppi.
Ecco un segreto: se PHP ha rilasciato un aggiornamento ufficiale con una sintassi alternativa (più simile a Ruby / Python) e ha avvolto la libreria standard esistente nello stile delle famose librerie Ruby (e reso coerente), e aveva compatibilità e capacità di retrocessione integrarsi con il codice legacy, sarebbe un prodotto killer. Non dirlo a nessuno che l'ho detto.
Michael: Facilità di implementazione, un'introduzione aggraziata ai concetti di livello inferiore dello sviluppo Web e oltre un secolo di documentazione e best practice provate e vere.
Michael: Ancora una volta: facilità di implementazione, un'introduzione aggraziata ai concetti di livello inferiore dello sviluppo Web e oltre un secolo di documentazione e best practice comprovate e vere.
Ma seriamente - a causa della bassa barriera all'entrata con PHP, può essere difficile distinguere la differenza tra qualcuno che sa veramente di cosa sta parlando e qualcuno con lo stesso livello di abilità di chi aveva un dominio di riserva per un blog. Inoltre, a causa dell'elevata anzianità di PHP, ci sono molti contenuti là fuori - e non tutto è buono.
Questo non è un problema unico di PHP: un rapido sguardo a W3Schools.com rovinerà i sogni di qualsiasi sostenitore di xHTML, JavaScript, CSS o PHP.
Gli sviluppatori di PHP soffrono di? Non inventata qui la sindrome.?
Può essere molto facile, quando stai imparando una lingua, trovare ciò che ritieni essere una risorsa autorevole (che potrebbe essere obsoleta o semplicemente sbagliata) e seguire insieme ciò che sono? tu. Questo è qualcosa che la comunità di PHP ha bisogno di ottenere molto meglio - diffondendo il? Giusto? modo per svolgere determinati compiti. Devo ammettere che la comunità di Ruby ha il vantaggio qui, Rick Olson ha risolto l'autenticazione per tutti quando ha rilasciato il plugin Restful-Authentication. J
Gli sviluppatori PHP, per i loro primi anni, soffrono di? Non inventata qui la sindrome? - che non credo sia una brutta cosa (fino a quando non iniziano a venderlo o a distribuirlo ad altri). Penso che la mentalità dietro a un nuovo sviluppatore, che sperimenta PHP per la prima volta, è che vogliono veramente capire esattamente cosa sta succedendo - e PHP fa un lavoro perfetto - dando loro abbastanza corda da impiccarsi? - rivelando abbastanza da imparare, ma probabilmente ti farai del male. Considerando che, e per non scartare il plug-in di Rick (che è un fantastico sistema di autenticazione), gli sviluppatori di Rails sono disposti ad assumere che questo ragazzo abbia capito bene e continuare sulla loro strada.
PHP è diventato immensamente popolare perché era nel posto giusto al momento giusto.
Ryan: Direi che PHP è diventato immensamente popolare perché era nel posto giusto al momento giusto. Le alternative per lo sviluppo del lato server nel corso della giornata richiedevano una discreta quantità di conoscenze di programmazione, eppure molte persone che non avevano mai pensato a se stesse come programmatori stavano già lanciando le cose con HTML e CSS. Seguendo la stessa metafora di implementazione e una conoscenza di base su come mettere insieme i siti Web, potresti creare programmi moderatamente utili e pubblicarli su un host web condiviso poco costoso. Oppure puoi scaricare quello che ha fatto qualcun altro e modificarlo un po 'perché l'HTML e il codice sono stati tutti mescolati insieme.
Un'altra cosa che ha aiutato PHP è stato il boom di prodotti come il cPanel e hosting provider di hosting di white label. Ogni uomo e il suo cane potrebbero diventare un host web a basso costo e senza alcuna conoscenza tecnica. Ogni uomo e il suo cane volevano un sito web e un hosting economico. PHP e MySQL erano standard di serie su questi set up condivisi, ed erano ovunque (e lo sono ancora).
Il meglio non sempre "vince", molte persone sono ancora seccate dal fatto che SmallTalk abbia perso Java, anche se le persone che ho incontrato (i veterani del software serio) che erano in giro quando sono accadute, dicono che si sentono a loro agio in Ruby!
Ryan: Questo non è molto bello, ma direi che le critiche comuni a PHP sono abbastanza valide e sono dovute al modo in cui? è stato progettato (o meglio, non progettato). PHP è nato da un certo numero di script CGI che l'autore originale ha scritto in C (o era Perl?), E il caso comune del perché PHP è andato così è stato? Potrei avere un programmatore C che scrive script per il web in solo un paio di giorni?.
Non ricordo mai di aver chiesto a un programmatore C di farmi un'applicazione web!
Ruby d'altra parte è stato progettato per prendere il meglio da un certo numero di lingue per creare qualcosa che fosse una gioia con cui lavorare, ha preso spunto da Smalltalk, Perl, LISP e altri, e mostra.
Una grande differenza tra PHP e Ruby per me è che Ruby ti incoraggia a lavorare con i loro tipi di dati di base come Hash e Array dove non li ho mai trovati naturali in PHP. Il numero di volte in cui ho dovuto cercare l'ordine degli argomenti per String e Array in PHP è incredibile.
Il numero di volte in cui non riuscivo a ricordare se questa o quella funzione avesse sottolineato o meno era ugualmente fastidioso. Ho usato Zend IDE quindi non ho dovuto ricordare ma l'IDE non mi è piaciuto. Sembrava che tu fossi dannato se lo facessi e dannato se non lo facessi. Non c'è coerenza nella libreria standard di PHP ed è frustrante come un orso infuriato in una cabina telefonica. In Ruby, raramente spendo del tempo nella documentazione per tipi di dati comuni perché le interazioni comuni sono così facili da ricordare.
Una volta che inizi a utilizzare le funzionalità nel modulo Enumerable di Ruby, ti chiedi come mai hai vissuto senza di essa, mignolo giurano!
Michael: Penso che questo sia un riflesso della bassa barriera all'ingresso e l'eredita curiosità degli sviluppatori PHP di capire veramente cosa sta succedendo. Avevo letto / studiato centinaia di white paper, blog, articoli sui sistemi di autenticazione, ma non è stato fino a quando non ho costruito il mio che mi sono sentito davvero come se sapessi cosa stava succedendo. Credo che i nuovi sviluppatori PHP siano desiderosi di condividere ciò che hanno fatto con il resto del mondo e sono spesso sbattuti per averlo fatto, perché non hanno seguito le migliori pratiche o modelli di sicurezza comprovati.
Michael: Penso che sia PHP che Ruby abbiano seri problemi nella loro documentazione e per ragioni completamente opposte.
PHP ha tonnellate di documentazione, grazie alla sua anzianità - puoi trovare la risposta a qualsiasi domanda con una rapida ricerca su Google e funzionerà. È la soluzione migliore? Forse sì forse no?
Rails è cresciuto così rapidamente, che anche io ho difficoltà a tenere il passo.
Ruby ha una grande documentazione, ma in realtà questa sembra essere una domanda quadro-quadro, quindi assumeremo Rails. Rails è cresciuto così rapidamente, che anche io ho difficoltà a tenere il passo. La documentazione dell'API di Rails è eccezionale; ma quando si tratta di documentazione di terze parti (libri, articoli di blog, risposte StackOverflow) - sono tutti obsoleti e mentre si segue questa informazione è molto difficile eseguire il debug del problema e risolverlo.
In questo senso, credo che PHP abbia il vantaggio in quanto i singoli framework (CodeIgniter, FuelPHP, Kohana, CakePHP, ecc.) Possono mitigare questo effetto in una certa misura - se si utilizza uno di questi framework è semplice trovare la risposta definitiva per quello che stai cercando.
Ryan: Quando stavo usando PHP, è stata posta molta enfasi su quanto fossero fantastici i commenti nella documentazione di PHP.net. La filosofia sembrava essere quella di "scrivere la documentazione una volta e lasciare che le persone aggiungano i loro due centesimi". Il problema con questo è che i commenti sono disposti in ordine di pubblicazione, il che significa che quelli buoni non filtrano verso l'alto e qualsiasi informazione condivisa in essi non è stata elaborata nella documentazione in modo tempestivo (o affatto).
Gran parte dell'API comune è inclusa nel core PHP, che non cambia così spesso, quindi penso che una soluzione wiki sarebbe più appropriata. In questo modo la comunità potrebbe modificare la documentazione ufficiale, suggerire modifiche, suggerire esempi, integrare il bene dei commenti in ciò che le persone vedono per primo. Sarebbe utile (specialmente per un principiante).
I corsi di Java insegnano per primi le persone sul polimorfismo e guardano a ciò che fanno: progettare le gerarchie di classi come se fossero un primo taglio! Mi fa impazzire!
In Ruby, molte delle librerie comunemente usate sono su GitHub, dove le persone possono inviare piccole modifiche e miglioramenti che vengono inseriti in un ciclo di rilascio regolare. La documentazione è accoppiato in codice usando RDoc (che è simile a PHPDoc), e quando si installa una gemma si genera documentazione sul sistema locale. Per gran parte del mio lavoro, leggerò la documentazione di base su rubydoc.info, o localmente sulla mia macchina, o se qualcuno di questi fallisce il codice sorgente delle librerie stesse.
Abbiamo sentito i pensieri di Ryan e Michael, e tu sicuramente hai le tue opinioni. Continua il dibattito nei commenti!
