Share
Este timpul; cozi "Going the Distance" de la Rocky. În inelul roșu: extraordinarul dezvoltator Envato, Ryan Allen, care a construit originalul FlashDen cu mâinile goale goale. În colțul albastru: Michael Wales, un membru bine cunoscut în comunitățile PHP și CodeIgniter. Bătălia? PHP vs. Ruby. Luptă!
Trebuie remarcat faptul că aceste dezbateri sunt pur și simplu pentru scopuri distractive și educative. Există momente când veți alege PHP pentru un proiect, și există momente când veți opta pentru Ruby. Scopul acestei serii, totuși, este de a învăța Cum și cand să facă astfel de decizii. Mai degrabă decât "limbajul dvs. e de rahat", aceste dezbateri sunt menite să contureze De ce ați putea, în anumite situații, să alegeți una peste cealaltă.
Ryan Allen este un inginer de software și sisteme de web care lucrează pentru Envato de atunci pentru totdeauna. El a construit și a susținut versiunile inițiale ale piețelor Envato în Ruby on Rails și acum se ocupă de sistemele Tuts +, printre altele.
Michael Wales este un dezvoltator web pentru agențiile guvernamentale din SUA și este un contribuitor activ la comunitățile PHP și CodeIgniter.
Ryan: PHP a fost unul dintre primele limbi de programare cu care am lucrat (în afară de ActionScript și unele Visual Basic foarte scurte). Am inceput sa construiesc lucruri cu PHP in 2001. Am lucrat destul de exclusiv cu aceasta ca un instrument backend pana la sfarsitul anului 2005, cand Ruby (si Rails) si-a luat locul.
Michael: PHP a fost introducerea mea în lumea dezvoltării web, în 1999 - așa că aș vrea să spun că am o înțelegere destul de solidă a poziției sale în industria noastră, istoria ei și direcția în care se îndreaptă. Ruby, la fel ca mulți alții, mi-a prins ochii cu eliberarea lui Rails și succesul celor 37 de semne. Am o înțelegere destul de solidă a Ruby, ca limbă de scripting în atribuțiile mele de administrare a sistemului (Capistrano), precum și unele proiecte personale și distractive (biblioteca de dezvoltare a jocurilor Gosu și Rails). Mi-e rușine să recunosc că nu sunt la fel de familiarizat cu cele mai recente versiuni ale lui Rails și este cu siguranță pe lista mea de lucruri pentru a mă regăsi.
Michael: Din păcate, nu pot da un răspuns definitiv la acest lucru - cel puțin nu așa cum vă așteptați, deoarece PHP și Ruby sunt două animale complet diferite. PHP este o amalgamare a limbajului și a cadrului web într-un singur pachet, în timp ce Ruby este un limbaj de programare cu numeroase cadre disponibile.
Dacă vă îndreptați atenția spre dezvoltarea de web-uri și la asta ați vrut să vă concentrați chiar acum, cu siguranță vă sfătuiesc să învățați PHP mai întâi.
Deci, dacă vă concentrați pe dezvoltarea de web și asta este tot ce ați vrut să vă concentrați chiar acum, cu siguranță vă sfătuiesc să învățați PHP mai întâi din mai multe motive:
Ca dezvoltator cu o experiență de 12 ani, apreciez comenzile rapide pe care Rails le aduce industriei noastre; dar asta este doar pentru că înțeleg ce se întâmplă de fapt în spatele scenei.
Dacă doriți să deveniți dezvoltator (dezvoltator web, scripting pentru administrarea sistemului, dezvoltator de jocuri, dezvoltator de aplicații API), care înțelege concepte de nivel scăzut în domeniul informaticii, programare orientată pe obiecte și, în general, avansează abilitățile critice de gândire - începeți cu Ruby, este un limbaj de programare real (amintiți-vă că PHP este un cadru web deghizat ca limbă).
Din perspectiva unui Web Developer, cred că aceasta este și una dintre rupturile lui Ruby (și Python's, BTW) - este că nu există nici un nivel mediu? punct de intrare. Înțelegeți fie protocolul HTTP, fie abilitatea de a scrie propriul tău teanc, de sus în jos, fie de a merge cu unul dintre "magic", să ții mâna pentru a crea cadre de sistem CRUD?.
Aceasta este zona în care PHP strălucește. Dacă depășiți limitele CRUD, nu trebuie să aveți o înțelegere extremă a modului în care un server HTTP funcționează pentru a vă face visele o realitate.
Ryan: Dacă aș fi învățat pe cineva să programeze de la zero, aș prefera să-i învăț Ruby (probleme de instalare a mediilor deoparte - deși acest lucru devine mai ușor). O modalitate obișnuită de a începe cineva (după variabile și tipărirea acestora) este de a explica arrays cu, să zicem, un exemplu de listă de cumpărături, să luați acest bit de PHP:
Accentsconagua
$ shopping_list = array ("Lapte", "Brânză", "Hovercraft"); pentru ($ i = 0; $ i < count($shopping_list); $i++) echo $shopping_list[$i]; Când am învățat PHP, am fost învățat să folosesc buclele (așa cum am fost în ActionScript), când a existat deja o procedură mai curată și mai puțin susceptibilă de eroare (așa cum sa întâmplat și în ActionScript). Trebuia să aflu totul despre chestia asta $ i = 0, chestia asta de testare și acest lucru incrementor. A fost atât de confuz! Numărul de ori pe care l-am înșelat pentru bucle este nesemnificativ (nu este vorba de un joc de cuvinte). Iată ce ar arăta același lucru în Ruby:
shopping_list = ["Lapte", "Brânză", "Hovercraft"] shopping_list.each do | shopping_item | pune sfârșitul shopping_item
Există o sintaxă mult mai puțin acolo, iar iteratorii sunt în mintea mea, mult mai ușor de înțeles și de a lucra cu. Dar, din motive de exhaustivitate, iată exemplul PHP, dar cu o foreach:
$ shopping_list = array ("Lapte", "Brânză", "Hovercraft"); foreach ($ shopping_list ca $ shopping_item) echo $ shopping_item; Ei bine, asta nu este chiar rău! Cred că ar trebui să folosiți numai pentru buclele de numărat până la 10 și lucruri de genul acesta, foreach-ul este mult mai ușor de citit și de învățat și atât de greu de înșelat. Și iteratorii sunt chiar mai buni, așa că aș merge cu Ruby.
Ryan: Punctul de vânzare pentru mine (în 2005) a fost cadrul Rails. Mi-am încercat mâna la dezvoltarea web-ului cu Python, dar fără experiență am avut oarecum o perioadă dificilă, fără să știu ce să fac sau unde să mă uit (dar am reușit să construiesc câteva lucruri, deci ia-o!), Dar am vrut să Folosiți Python zilnic pentru că am simțit că are un design mai bun, mai deliberat și mi-a plăcut sintaxa. Și pentru că șerpii sunt mai răcoroși decât elefanții.
ActiveRecord a fost la fel de uimitor!
Nu am lucrat niciodată cu altceva dincolo de ADODB în PHP și încercând și nu reușind să fac un ORM de multe ori (nu aveam nici o idee despre ceea ce era un ORM, dar știam că vreau ceva care a cartografiat într-un fel clase la tabele de baze de date), când am văzut pentru prima oară ActiveRecord era ca și cum toate hainele mele au venit imediat.
Cunosc destul de bine bazele de date relaționale, dar a fost rău să scriu același SQL de mai multe ori. ActiveRecord a fost pur și simplu, atât de uimitor! Și Ruby a fost destul de aproape de Python. Mă bucur ca Larry (oricine este) să aibă un cadru pe care să-l pot ocupa și să încep să construiesc lucruri. Deci, pentru mine era dragostea unei biblioteci și o iubire a sintaxei.
În zilele noastre avem biblioteci uimitoare de biblioteci Ruby scrise de indivizi talentați, biblioteci cum ar fi Sinatra (un cadru Web ușor), Nokogiri (parser HTML / XML), Sequel (o bibliotecă de baze de date la nivel înalt), RSpec (o bibliotecă de testare automată). Toate aceste biblioteci sunt instalabile ca RubyGems pe care le-am găsit mult mai ușor și ușor de utilizat pentru a lucra cu sistemul de PEAR PHP.
Comunitatea este încă destul de vibrantă, chiar și câțiva ani, iar companiile recrutează dezvoltatori de Ruby, cum ar fi hotcakes. Ruby 1.9 este aparent aproape la fel de rapid ca și PHP acum, deci există multe puncte de vânzare!
Ruby 1.9 este aparent aproape la fel de rapid ca și PHP acum, deci există multe puncte de vânzare!
Michael: Cred că aceasta este doar o progresie naturală a dezvoltatorilor (de la Dezvoltarea Web la căutarea de cunoștințe generale despre limbile OOP și o educație generală în domeniul informaticii) în general - știu că a fost ruta pe care am luat-.
Cred că cea mai mare cădere, până în prezent, este practica de a alege o limbă și de a rămâne la moarte. Nu așa funcționează lumea reală.
Consider că sunt dezvoltator? - prin urmare, limba este o calificare ambiguă ca marcă de televiziune pentru un vânzător Best Buy. Există situații în care aleg PHP (dacă există o linie de timp extrem de scurtă - în afară de CRUD, este limba pe care o cunosc cel mai bine), există și altele în care aleg Ruby (implementare prin Capistrano sau CRUD de bază cu Rails) și , și mai mult, Python - pe care prefer să-l folosesc pentru administrarea de servere și parsarea diferitelor fișiere.
Michael: Cred că dezvoltatorii pot fi adesea prinși în "hotness-ul nou", bătut? manie. De aceea, echipa noastră se află întotdeauna înainte de a începe un proiect, am stabilit cerințele (atât în termenii utilizatorilor, cât și în termenii dezvoltatorilor - care sunt două lucruri extrem de diferite) și noi vorbim, cu foarte puține preferințe de limbă / cadru . Saptamana trecuta am analizat cateva GBs de jurnale de mesagerie cu Perl, in aceasta saptamana am construit o aplicatie a carei viziune primara a fost ExtJS GridPanel (pentru ca am extins fisierele Core CodeIgniter care se ocupa de orice situatie ExtJS ne arunca cu 3 linii de cod).
Este vorba despre cât timp avem și cum putem produce cel mai bun produs în acest interval de timp?
Ryan: Absolut, unii oameni (inclusiv eu) mă obișnuiesc să proiectez lucrurile într-un anumit mod încât nu vor să-și reînvețe și să-și schimbe toate obiceiurile greu câștigate. Odată ce ești productiv cu ceva, de ce ți-ar deranja schimbarea?
O altă școală de gândire este mai multe limbi și instrumente pe care le aveți experiență, veți putea să combinați cele mai bune tehnici și idei indiferent de mediul în care lucrați (spun acest lucru despre învățarea LISP, dar nu am învățat încă ).
Programatorii tineri vor sari pe strălucitoare lucruri noi, dar pe măsură ce îmbătrâniți și mai maturiți, doriți să lucrați cu instrumente mici care sunt simple și robuste. Dacă nu folosiți fiecare caracteristică și fiecare bibliotecă disponibilă în Ruby, puteți obține o simplă și robustă fără prea multe probleme.
Un cuvânt: întreținere.
Ryan: Da, un cuvânt: întreținere. Programele software au o tendință de a solicita modificări în timp, iar autorul original al programului nu este întotdeauna cel care face modificările. Să presupunem că teleporturile ipotetice sunt inventate și că există o conferință la nivel mondial Ruby și fiecare dezvoltator capabil de Ruby din lume se îndreaptă (teleports rock!). Acum să mai spunem că Pământul este, în mod ipotetic, Pământul din Orientul Mijlociu și că balaurul Smaug este destul de enervat de acest lucru Ruby (dragonii preferă Python, vezi tu) și decide să facă o vizită și să-i înfulece pe toți dezvoltatorii de la spite. Acum nu există dezvoltatori experimentați de Ruby rămași în lume, oh dragă! Acum aveți această problemă de a nu avea un grup de dezvoltatori Ruby disponibil pentru a lucra la proiectele dvs. Ce vom face Gandalf??
Când aleg instrumente, mă gândesc adesea cine va trebui să mențină proiectul dacă mă lovește de un autobuz (sau o prăbușesc motocicleta, care este mai probabil).
Cu siguranță nu aș scrie nimic în Haskell sau LISP sau chiar în F # pentru că ne-ar fi greu să angajăm pe cineva care ar putea sau ar putea lucra la ea. Disponibilitatea talentelor și a talentului existent într-o companie influențează foarte mult decizia mea.
Există o altă situație în care aș lua în considerare limba, și asta ar fi dacă aș vinde un produs, să spun, un CMS personalizat, care vinde în Cod Canyon. Nu l-aș scrie în Ruby, deoarece gazduirea de mărfuri nu suportă în general acest lucru. În timp ce PHP este destul de ușor accesibil pretutindeni și web designeri și programatori mai puțin experimentați sunt oarecum familiarizați cu acesta.
Există o altă situație în care aș lua în considerare limba, și asta ar fi dacă aș vinde un produs, să spun, un CMS personalizat, care vinde în Cod Canyon. Nu l-aș scrie în Ruby, deoarece gazduirea de mărfuri nu suportă în general acest lucru. În timp ce PHP este destul de ușor accesibil pretutindeni și web designeri și programatori mai puțin experimentați sunt oarecum familiarizați cu acesta.
Michael: Vedeți răspunsurile mele pentru # 3 / # 4.
Michael: Personal, aș recomanda cadrul Django pentru Python. Acesta a fost conceput în acest scop: abilitatea de a determina dezvoltatorii să lucreze la modelarea datelor și să afișeze datele pe ecran cât mai repede posibil, cu etichete ușor de utilizat pentru designeri pentru a prezenta aceste date într-o manieră frumoasă, în timp ce dezvoltatorii continuă să lucreze la regulile de afaceri într-un ciclu concurent.
Ryan: Dacă aveți experiență aruncând împreună HTML și CSS și încărcându-le cu FTP, atunci probabil aș recomanda PHP, deoarece are bariere scăzute la intrare deoarece deja sunteți familiarizați cu metafora (Wrap your code in .php extensie! Mergi departe!). Dar dacă ați început să luați în serios programarea, aș sugera să vă răzgândesc și să vă uitați în alte lucruri (cum ar fi Ruby) pentru a vă lărgi orizonturile.
Când lucrurile merg în neregulă, lipsa cunoașterii se va întoarce și te va mușca.
De multe ori văd că programatorii PHP lucrează cu baze de date relaționale și că nu înțeleg foarte bine cum funcționează. Deci, într-adevăr poți să faci lucruri fără o înțelegere profundă a tehnologiilor cu care lucrezi (rareori folosești PHP pe cont propriu), dar când lucrurile merg prost, lipsa cunoștințelor tale va reveni și te va mușca. Cât timp trebuie să investești în învățarea acestor lucruri? Poți să te duci la cineva pentru ajutor dacă te blochezi? Inveti PHP pentru a putea lucra cu el sau doar pentru distractie? Alegerea este o întrebare destul de deschisă, în funcție de obiectivele dvs..
În ceea ce privește terminalele, ei sunt, pe scurt, AWESOME. Eu le folosesc tot timpul. Da, au o curbă de învățare (dar ce nu?). Odată ce ați luat mâna pe ele și ați început să vă scrieți propriile programe mici, nu puteți continua fără ele. Pentru a fi corect, nu am găsit Promptul de comandă în Windows foarte util, dar odată ce am trecut pe un Mac și am avut acces la toate distracțiile * nix sub capota, a devenit destul de productiv.
Ruby are hype, vibrancy și sex appeal.
Ryan: Aș spune că ceva pe care Ruby îl are în prezent acest PHP nu este hype, vibrancy și sex appeal. Ruby este neechivoc de sexy. Femeile îl iubesc. Bărbații vor să fie așa. Godzilla se temea de asta. Mi-ar sugera să urc la un Grup de utilizatori Ruby și veți găsi un grup divers de oameni care tocmai iubesc să codeze, iubesc să facă lucruri și tehnologie în general. Când am început să întâlnesc oameni în comunitatea locală Ruby, a fost prima dată în viața mea m-am simțit ca și cum aș fi fost cu poporul meu.? Chiar credeam că sunt singurul programator de pe planetă care se ocupa de munca lor până atunci. A fost foarte răcoritoare și am învățat foarte mult de atunci, mai ales de la oamenii pe care i-am întâlnit prin aceste grupuri.
Iată un secret: dacă PHP a lansat o actualizare oficială cu o sintaxă alternativă (mai mult Ruby / Python similară) și a împachetat biblioteca standard existentă în stilul bibliotecilor populare Ruby (și a făcut-o consecventă) și a avut compatibilitate înapoi și capacitatea de a să se integreze cu codul vechi, ar fi un produs criminal. Nu spune nimănui că am spus asta.
Michael: Ușor de desfășurare, o introducere grațioasă la conceptele de nivel inferior ale dezvoltării web și peste un secol de documentare și cele mai bune practici încercate și adevărate.
Michael: Din nou - ușurința de desfășurare, o introducere grațioasă la conceptele de nivel inferior de dezvoltare web și peste un secol de documentare și cele mai bune practici încercate și adevărate.
Dar, serios - din cauza barierei scăzute la intrarea în PHP, poate fi dificil să discernem diferența dintre cineva care știe de fapt despre ce vorbește și cineva la același nivel de calificare ca și dvs. care avea un domeniu de rezervă pentru un blog. În plus, datorită vechimii vechi a PHP, există mult conținut acolo - și nu toate sunt bune.
Aceasta nu este o problemă unică a PHP-ului - o scurtă privire la W3Schools.com va ruina visele oricărui promotor al xHTML, JavaScript, CSS sau PHP.
Descendenții PHP suferă de sindromul "nu inventat aici".?
Poate fi foarte ușor, atunci când învățați o limbă, să găsiți ceea ce credeți că este o resursă autoritară (care ar putea fi depășită sau pur și simplu greșită) și să urmați împreună cu ce sunt? tu. Aceasta este ceva ce comunitatea PHP are nevoie să obțină mult mai bine la: - răspândirea dreptului? modalitate de a îndeplini anumite sarcini. Recunosc - comunitatea Ruby are avantajul aici, Rick Olson a rezolvat autentificarea pentru toată lumea când a lansat pluginul Restful-Authentication. J
Dezvoltatorii PHP, pentru primii lor ani, suferă de sindromul "nu inventat aici"? - pe care nu cred că este un lucru rău (până când vor începe să vândă acest lucru sau să îl treacă altora). Cred că mentalitatea din spatele unui nou dezvoltator, care se confruntă cu PHP pentru prima dată, este că ei doresc cu adevărat să înțeleagă exact ce se întâmplă - și PHP face o treabă perfectă, oferindu-le suficientă coardă pentru a se agăța? - dezvăluirea suficientă pentru a învăța, dar probabil că te vei răni singur. Întrucât, și nu pentru a reduce plugin-ul Rick (care este un sistem minunat de autentificare), dezvoltatorii Rails sunt dispuși să-și asume acest tip și au continuat pe drum.
PHP a devenit extrem de popular pentru că era în locul potrivit la momentul potrivit.
Ryan: Aș spune că PHP a devenit extrem de popular, deoarece era la locul potrivit la momentul potrivit. Alternativele pentru dezvoltarea serverului înapoi în timpul zilei necesitau o cantitate destulă de cunoștințe de programare, dar mulți oameni care nu s-au gândit niciodată ca programatori au aruncat deja lucruri împreună cu HTML și CSS. Urmând aceeași metaforă de implementare și o înțelegere de bază a modului de a pune împreună site-urile web, puteți face programe moderat utile și le puteți arunca într-o gazdă web comună ieftină. Sau puteți descărca unul pe care altcineva l-a făcut și-l tweak un pic, deoarece HTML și codul a fost amestecat în toate împreună.
Un alt lucru care a ajutat PHP de-a lungul timpului a fost boom-ul celor care îi plac, cum ar fi produsul cPanel și furnizorii de găzduire etichetare albă de web hosting. Fiecare om și câinele său ar putea deveni o gazdă web la un cost redus și fără cunoștințe tehnice. Fiecare om și câinele său doreau un site web și o găzduire ieftină. PHP și MySQL au fost stoc standard pe aceste setări comune, și au fost peste tot (și încă sunt).
Cel mai bun lucru nu este întotdeauna "câștigul", mulți oameni sunt încă deranjați de faptul că SmallTalk a pierdut din Java, deși oamenii pe care i-am întâlnit (veterani de software grave) care s-au întâlnit când sa întâmplat acest lucru, spun că se simt destul de acasă în Ruby!
Ryan: Acest lucru nu este foarte frumos, dar aș spune că criticile comune ale PHP sunt destul de valide și se datorează modului în care limba? a fost proiectat (sau, mai degrabă, nu a fost proiectat). PHP sa născut dintr-o serie de scripturi CGI pe care autorul original le-a scris în C (sau a fost Perl?), Și cazul comun pentru motivul pentru care PHP a mers așa cum a procedat așa? Aș putea avea un programator C scriind scripturi pentru web în doar câteva zile?.
Nu-mi amintesc vreodată să-i cer un programator C să-mi facă o aplicație web!
Ruby, pe de altă parte, a fost conceput pentru a obține cele mai bune rezultate dintr-un număr de limbi pentru a crea ceva cu care a fost o bucurie de a lucra, a luat repere de la Smalltalk, Perl, LISP și altele..
O diferență foarte mare între PHP și Ruby pentru mine a fost că Ruby vă încurajează să lucrați cu tipurile de date de bază precum Hashes și Arrays unde nu le-am găsit niciodată natural în PHP. De câte ori a trebuit să caut ordinea de argumente pentru String și Arrays în PHP este minunat.
De câte ori nu mi-am putut aminti dacă această sau acea funcție avea subliniere sau nu era la fel de enervantă. Am folosit Zend IDE, așa că nu trebuie să-mi amintesc, dar nu mi-a plăcut IDE-ul. S-a simțit ca și cum ai fi fost blestemată dacă ai făcut-o și naibii dacă nu ai făcut-o. Nu există coerență în biblioteca standard a PHP și este frustrant ca un urs înfuriat într-o cutie telefonică. În Ruby, rareori petrec timpul în documentația pentru tipuri de date comune, deoarece interacțiunile comune sunt atât de ușor de reținut.
Odată ce începeți să utilizați funcțiile în modulul Ruby's Enumerable, vă veți întreba cum ați trăit vreodată fără ea, pârghie!
Michael: Cred că aceasta este o reflectare a barierei scăzute la intrare și moștenirea curiozității dezvoltatorilor PHP pentru a înțelege cu adevărat ce se întâmplă. Am citit / studiat sute de cărți albe, bloguri, articole despre sistemele de autentificare - dar până când mi-am construit propria mea, am simțit cu adevărat ca și cum aș ști ce se întâmplă. Cred că noii dezvoltatori de PHP sunt dornici să împărtășească ceea ce au făcut cu restul lumii și sunt frecvent împușcați pentru că au făcut acest lucru, deoarece nu au urmat cele mai bune practici sau modele de securitate dovedite.
Michael: Cred că atât PHP cât și Ruby au probleme serioase în documentația lor - și din motive complet opuse.
PHP are tone de documentație, datorită vechimii sale - puteți găsi răspunsul la orice întrebare cu o căutare rapidă pe Google și va funcționa. Este cea mai bună soluție? Poate ca da, poate ca nu?
Rails a crescut atât de repede, încât chiar am greu să țin pasul.
Ruby are o documentație excelentă, dar în realitate acest lucru pare a fi o întrebare cadru vs. cadru, așa că îl vom asuma pe Rails. Rails a crescut atât de repede, încât chiar am greu să țin pasul. Rails documentația API este minunată; dar când vine vorba de o documentație terță (cărți, articole de blog, răspunsuri StackOverflow) - toate sunt depășite și în timp ce urmăriți împreună cu aceste informații, este foarte dificil să depanați problema și să o remediați.
În acest sens, cred că PHP are avantajul deoarece cadrele individuale (CodeIgniter, FuelPHP, Kohana, CakePHP etc.) pot atenua acest efect într-o oarecare măsură - dacă utilizați unul din aceste cadre, este simplu să găsiți răspunsul definitiv pentru ceea ce căutați.
Ryan: Când am folosit PHP, sa pus un accent foarte mare pe cât de minunat a fost comentariile din documentația PHP.net. Filozofia părea să fie "să scrie documentația o dată și să-i adauge pe cei doi cenți". Problema este că comentariile sunt prezentate în ordine de postare, ceea ce înseamnă că cele bune nu se filtrează în partea de sus și că orice informație împărtășită în ele nu a fost prelucrată în documentația în timp util (sau deloc).
Atât de mult API comun este inclus în nucleul PHP, care nu se schimbă adesea, deci cred că o soluție wiki ar fi mai potrivită. În acest fel, comunitatea ar putea modifica documentația oficială, sugera schimbări, sugerează exemple, integrează binele din comentariile în ceea ce privește oamenii în primul rând. Acest lucru ar fi util (mai ales pentru un începător).
Cursurile Java învață mai întâi oamenii despre polimorfism și privesc la ceea ce fac ei - design cu ierarhii de clasă ca o primă tăiere! Mă face nebun!
În Ruby, o mulțime de biblioteci utilizate în mod obișnuit sunt pe GitHub, unde oamenii pot prezenta mici schimbări și îmbunătățiri care se rostogolesc în ceea ce este, în general, un ciclu de eliberare regulat. Documentația este asociată codului folosind RDoc (care este similar cu PHPDoc), iar când instalați o bijuterie, aceasta generează documentația despre sistemul dvs. local. Pentru o mare parte din munca mea, voi citi fie documentația de bază pe rubydoc.info, fie local pe mașina mea, sau dacă oricare dintre aceștia nu reușește codul sursă al bibliotecilor.
Am auzit gândurile lui Ryan și Michael și, cu siguranță, aveți propriile opinii. Continuați dezbaterea în comentarii!
