Share
Het is tijd; wacht een wachtrij op het thema "Going the Distance" van Rocky. In de rode ring: Envato-ontwikkelaar extraordinaire, Ryan Allen, die de originele FlashDen met zijn koude, blote handen bouwde. In de blauwe hoek: Michael Wales, een bekend lid in de PHP- en CodeIgniter-community's. Het gevecht? PHP versus Ruby. Strijd!
Opgemerkt moet worden dat dit soort debatten puur voor de lol en educatieve doeleinden zijn. Er zijn momenten dat je PHP voor een project kiest, en er zijn momenten dat je voor Ruby zou kiezen. Het doel van deze serie is echter om te leren hoe en wanneer om dit soort beslissingen te nemen. In plaats van 'je taal zuigt', zijn deze debatten bedoeld om te schetsen waarom je zou in bepaalde situaties de ene boven de andere kunnen kiezen.
Ryan Allen is een websoftware en systeemingenieur die sinds jaar en dag voor Envato werkt. Hij bouwde en ondersteunde de vroege versies van de Envato Marketplaces in Ruby on Rails en zorgt nu voor de Tuts + -systemen, onder andere.
Michael Wales is een webontwikkelaar voor Amerikaanse overheidsinstanties en levert een actieve bijdrage aan de PHP- en CodeIgniter-community's.
Ryan: PHP was een van de eerste programmeertalen waarmee ik werkte (naast ActionScript en een paar heel korte Visual Basic). Ik ben in 2001 begonnen met het bouwen van dingen met PHP. Tot eind 2005, toen Ruby (en Rails) in de plaats kwamen, werkte ik er vrijwel exclusief mee als back-endtool..
Michael: PHP was mijn inleiding tot de wereld van webontwikkeling, in 1999 - dus ik zou willen zeggen dat ik een vrij goed begrip heb van zijn positie binnen onze sector, de geschiedenis en de richting waarin het wordt geleid. Ruby ving, net als vele anderen, de aandacht op de release van Rails en het succes van 37signals. Ik heb een vrij goed begrip van Ruby, als een scripttaal in mijn systeembeheerstaken (Capistrano), evenals enkele persoonlijke en leuke projecten (de Gosu-ontwikkelbibliotheek voor games en Rails). Ik schaam me om toe te geven dat ik niet zo bekend ben met Rails 'nieuwste versies en het staat zeker op mijn lijst van dingen om mezelf opnieuw te leren kennen.
Michael: Helaas kan ik hier geen definitief antwoord op geven - althans niet zoals je verwacht, want PHP en Ruby zijn twee totaal verschillende beesten. PHP is een samensmelting van taal en web framework in één pakket, terwijl Ruby een programmeertaal is met tal van frameworks beschikbaar.
Als je je op internetontwikkeling richt en dat is alles waar je je nu echt op wilde concentreren, zou ik je zeker aanraden om eerst PHP te leren.
Dus als je focus webontwikkeling is en dat is alles waar je je nu echt op wilde concentreren, zou ik je zeker aanraden om eerst PHP te leren voor een aantal redenen:
Als ontwikkelaar met 12 jaar ervaring, waardeer ik de snelkoppelingen die Rails ons bedrijf biedt; maar dat is alleen omdat ik begrijp wat er zich achter de schermen afspeelt.
Als u een ontwikkelaar wilt worden (Web Developer, System Administration scripting, Game Developer, API Developer) die low-level Computer Science-concepten begrijpt, object-georiënteerd programmeren en, in het algemeen, uw Critical Thinking-vaardigheden bevordert - het spreekt vanzelf, begin met Ruby, het is een echte programmeertaal (onthoud, PHP is een webraamwerk dat is vermomd als een taal).
Vanuit het perspectief van een webontwikkelaar denk ik dat dit ook een van de valkuilen van Ruby (en van Python, BTW) is - is dat er echt geen? Mid-level? ingangspunt. Je begrijpt het HTTP-protocol, met de mogelijkheid om je eigen stack te schrijven, van boven naar beneden, of je gaat met een van de? Magic, houd je hand vast om een CRUD-systeem te maken?.
Dit is echt het gebied waarin PHP schittert. Als u de grenzen van CRUD overschrijdt, hoeft u geen extreem begrip te hebben van hoe een HTTP-server werkt om uw dromen waar te maken.
Ryan: Als ik iemand zou leren programmeren vanuit het niets, zou ik ze liever Ruby leren (problemen met het opzetten van omgevingen - hoewel dit steeds gemakkelijker wordt). Een gebruikelijke manier om iemand uit te schakelen (na misschien variabelen en ze af te drukken) is om arrays uit te leggen met bijvoorbeeld een voorbeeld van een boodschappenlijst, dit stukje PHP te nemen:
Accentsconagua
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); voor ($ i = 0; $ i < count($shopping_list); $i++) echo $shopping_list[$i]; Toen ik PHP leerde, leerde ik om for-lussen te gebruiken (zoals ik in ActionScript was), toen er al een bondigere en minder foutgevoelige vooreach-lus bestond (zoals ook in ActionScript). Ik moest alles leren over dit $ i = 0 ding, dit test ding en dit incrementor ding. Het was allemaal zo verwarrend! Het aantal keren dat ik de lussen heb verpest is ontelbaar (geen woordspeling bedoeld). Dit is hoe hetzelfde eruit zou zien in Ruby:
shopping_list = ['Milk', 'Cheese', 'Hovercraft'] shopping_list.each do | shopping_item | zet shopping_item af
Er is veel minder syntaxis, en iterators zijn naar mijn mening een stuk eenvoudiger te begrijpen en te gebruiken. Maar voor de volledigheid, hier is het PHP-voorbeeld maar met een foreach:
$ shopping_list = array ('Milk', 'Cheese', 'Hovercraft'); foreach ($ shopping_list als $ shopping_item) echo $ shopping_item; Nou, dat is eigenlijk niet zo erg! Ik denk dat je alleen voor loops moet gebruiken om tot 10 te tellen en dat soort dingen, foreach is zo veel gemakkelijker te lezen en te onderwijzen en zo moeilijk om te verknoeien. En iterators zijn nog beter, dus ik zou met Ruby gaan.
Ryan: Het verkoopargument voor mij (in 2005) was het Rails-raamwerk. Ik had mijn hand op de ontwikkeling van het web met Python uitgeprobeerd, maar omdat ik onervaren was, had ik het een beetje moeilijk, niet wetend wat ik moest doen of waar ik moest kijken (maar ik heb toch wat dingen kunnen bouwen, dus neem dat mee!), Maar ik wilde heel graag gebruik Python van dag tot dag omdat ik vond dat het een beter, bewuster ontwerp had en dat ik de syntaxis leuk vond. En omdat slangen koeler zijn dan olifanten.
ActiveRecord was gewoon zo geweldig!
Ik heb nooit gewerkt met iets anders dan ADODB in PHP, en probeerde en faalde bij het maken van een ORM vele malen (ik had geen idee wat een ORM was maar ik wist dat ik iets wilde dat klassen toewijst aan databasetabellen), toen ik ActiveRecord voor het eerst zag het was alsof al mijn Christmases tegelijk waren gekomen.
Ik kende relationele databases redelijk goed, maar was het beu dezelfde SQL steeds opnieuw te schrijven. ActiveRecord was gewoon, zo geweldig! En Ruby was dicht genoeg bij Python. Ik was blij omdat Larry (wie hij ook is) een raamwerk had dat ik kon krijgen en dingen kon bouwen. Dus voor mij was het de liefde van een bibliotheek en een liefde voor de syntaxis.
Tegenwoordig hebben we enorm veel Ruby-bibliotheken geschreven door getalenteerde individuen, bibliotheken zoals Sinatra (een licht web framework), Nokogiri (een HTML / XML-parser), Sequel (een database van hoog niveau), RSpec (een geautomatiseerde testbibliotheek). Al deze bibliotheken zijn installeerbaar als RubyGems die ik veel eenvoudiger en gebruiksvriendelijker vond om mee te werken dan PHP's PEAR-systeem.
De community is nog steeds redelijk levendig, zelfs een paar jaar later, en bedrijven huren Ruby-ontwikkelaars in als hotcakes. Ruby 1.9 is nu ook bijna net zo snel als PHP, dus er zijn veel verkooppunten!
Ruby 1.9 is nu ook bijna net zo snel als PHP, dus er zijn veel verkooppunten!
Michael: Ik denk dat dit slechts een natuurlijke ontwikkeling is van ontwikkelaars (van Web Development tot algemene kennis van OOP-talen en een algemeen Computer Science-onderwijs) in het algemeen - ik weet dat het de route was die ik volgde.
Ik denk dat de grootste ondergang, tot op de dag van vandaag, de praktijk is om een taal te kiezen en deze tot de dood te houden. Dat is niet de manier waarop de echte wereld werkt.
Ik beschouw mezelf als een? Ontwikkelaar? - daarom is taal een dubbelzinnige kwalificatie als het merk van televisie voor een Best Buy-verkoper. Er zijn gevallen waarin ik PHP kies (als er een extreem korte tijdlijn is - buiten CRUD, is dit de taal waarin ik het meest vertrouwd ben), zijn er andere waarin ik Ruby kies (deployment via Capistrano of basis CRUD met Rails) en , nog meer, Python - wat ik prefereer voor Server Administration-taken en het parseren van verschillende bestanden.
Michael: Ik denk dat ontwikkelaars heel vaak verstrikt raken in de? Nieuwe hotness, oude busted? rage. Daarom gaat mijn team altijd zitten voordat we met een project beginnen, stellen we de vereisten op (zowel gebruikersvoorwaarden als ontwikkelaarsvoorwaarden - wat twee totaal verschillende dingen zijn) en we praten het uit, met heel weinig taal / kadervoorkeuren in het achterhoofd . Vorige week hebben we een paar GB messaging-logs met Perl geparseerd, deze week hebben we een applicatie gebouwd waarvan de primaire weergave een ExtJS GridPanel was (omdat we uitgebreide CodeIgniter-kernbestanden hebben die elke situatie afhandelen die ExtJS naar ons stuurt met 3-regels code).
Het draait allemaal om hoeveel tijd we hebben en hoe we het beste product in die tijd kunnen produceren?
Ryan: Absoluut, sommige mensen (inclusief ikzelf) wennen er aan om dingen op een bepaalde manier te ontwerpen, zodat ze niet al hun zuurverdiende gewoonten opnieuw willen leren en veranderen. Als je eenmaal ergens mee bezig bent, waarom zou je dan moeite doen om het te veranderen??
Een andere gedachte is dat hoe meer talen en hulpmiddelen je hebt, je de beste technieken en ideeën kunt combineren, ongeacht de omgeving waarin je werkt (ze zeggen dit over het leren van LISP, maar ik heb het nog niet geleerd ).
Jonge programmeurs springen op de glimmende nieuwe dingen, maar naarmate je ouder en volwassener wordt, wil je werken met kleine tools die eenvoudig en robuust zijn. Als u niet alle functies en alle beschikbare bibliotheken in Ruby gebruikt, kunt u zonder al te veel problemen eenvoudig en robuust worden.
Eén woord: onderhoud.
Ryan: Ja, één woord: onderhoud. Softwareprojecten hebben de neiging om in de loop van de tijd wijzigingen te vereisen, en de oorspronkelijke auteur van het programma zal niet altijd degene zijn die de wijzigingen aanbrengt. Laten we zeggen dat hypothetische telepoorten zijn uitgevonden en dat er een wereldwijde Ruby-conferentie is en dat elke betrouwbare Ruby-ontwikkelaar in de wereld op weg is (teleports rock!). Laten we nu ook zeggen dat de Aarde hypothetisch Midden-Aarde is, en Smaug de draak is nogal geërgerd over dit hele Ruby-ding (draken geven de voorkeur aan Python, zie je) en besluit een bezoek te brengen en alle ontwikkelaars op te tuigen uit wrok. Nu zijn er geen ervaren Ruby-ontwikkelaars meer in de wereld, oh lieverd! Nu heb je het probleem dat er geen pool van Ruby-ontwikkelaars beschikbaar is om aan je projecten te werken. Wat gaan we doen Gandalf?
Wanneer ik gereedschap kies, denk ik vaak aan wie het project zal moeten behouden als ik door een bus wordt geraakt (of mijn motor laat vallen, wat waarschijnlijker is).
Ik zou zeker niets in Haskell of LISP of zelfs F # schrijven, omdat we het moeilijk zouden hebben iemand aan te nemen die er aan zou kunnen of zou werken. Beschikbaarheid van talent en bestaand talent in een bedrijf heeft dan veel invloed op mijn beslissing.
Er is een andere situatie waarin ik de taal zou beschouwen, en dat zou het geval zijn als ik een product zou verkopen, laten we zeggen, een aangepast CMS dat op Code Canyon verkoopt. Ik zou het niet in Ruby schrijven omdat commodity-webhosting dit over het algemeen niet ondersteunt. Terwijl PHP vrijwel overal beschikbaar is en webontwerpers en minder ervaren programmeurs er enigszins vertrouwd mee zijn.
Er is een andere situatie waarin ik de taal zou beschouwen, en dat zou het geval zijn als ik een product zou verkopen, laten we zeggen, een aangepast CMS dat op Code Canyon verkoopt. Ik zou het niet in Ruby schrijven omdat commodity-webhosting dit over het algemeen niet ondersteunt. Terwijl PHP vrijwel overal beschikbaar is en webontwerpers en minder ervaren programmeurs er enigszins vertrouwd mee zijn.
Michael: Zie mijn antwoorden voor # 3 / # 4.
Michael: Persoonlijk zou ik het Django-framework voor Python aanbevelen. Het is ontworpen met dit doel voor ogen: de mogelijkheid om ontwikkelaars bezig te houden met datamodellering en gegevens zo snel mogelijk weer te geven op het scherm, met eenvoudig te gebruiken tags voor ontwerpers om die gegevens op een mooie manier te presenteren, terwijl de ontwikkelaars doorgaan om aan de bedrijfsregels te werken in een gelijktijdige cyclus.
Ryan: Als je ervaring hebt met het samengooien van HTML en CSS en het uploaden van deze met FTP, dan zou ik PHP waarschijnlijk aanbevelen, omdat het lage toetredingsdrempels heeft, omdat je al bekend bent met de metafoor (Wikkel je code in .php uitbreiding! Waar je ook gaat!). Maar als je het programmeren serieus begint te nemen, stel ik voor om vertakkingen te maken en andere dingen (zoals Ruby) te bekijken om je horizon te verbreden.
Als er iets misgaat, zal je gebrek aan kennis terugkomen en je bijten.
Vaak zie ik PHP-programmeurs werken met relationele databases en weinig begrip hebben van hoe ze werken. Je kunt dus echt dingen voor elkaar krijgen zonder een goed begrip van de technologieën waarmee je werkt (je gebruikt PHP zelden helemaal alleen), maar als er iets misgaat, zal je gebrek aan kennis terugkomen en je bijten. Hoeveel tijd moet je investeren om deze dingen te leren? Kun je iemand om hulp vragen als je vastloopt? Ben je PHP aan het leren, zodat je ermee aan de slag kunt, of gewoon voor de lol? Keuze is een tamelijk open vraag, afhankelijk van wat uw doelen zijn.
Met betrekking tot terminals zijn ze, kortom, GEWELDIG. Ik gebruik ze altijd. Ja, ze hebben een leercurve (maar wat niet?). Zodra je er grip op hebt en je eigen kleine programma's gaat schrijven, kun je niet verder zonder hen. Om eerlijk te zijn vond ik de opdrachtprompt in Windows niet erg nuttig, maar toen ik eenmaal op een Mac overschakelde en toegang had tot alle * nix-fun onder de motorkap, werd het nogal productief.
Ruby heeft een hype, levendigheid en sex-appeal.
Ryan: Ik zou zeggen dat Ruby op dit moment heeft dat PHP niet is hype, levendigheid en sex-appeal. Ruby is onmiskenbaar sexy. Vrouwen zijn er dol op. Mannen willen zo zijn. Godzilla is er bang voor. Ik raad je aan om mee te gaan naar een Ruby-gebruikersgroep en een gevarieerde groep mensen te vinden die graag coderen, graag dingen maken en technologie in het algemeen. Toen ik mensen in de lokale Ruby-gemeenschap ontmoette, was dat het geval de eerste keer in mijn leven voelde ik me alsof ik bij was? mijn mensen.? Ik dacht echt dat ik de enige programmeur op aarde was die tot dan toe om hun werk gaf. Het was heel verfrissend en ik heb sindsdien veel geleerd, vooral van de mensen die ik via deze groepen heb ontmoet.
Hier is een geheim: als PHP een officiële update uitbracht met een alternatieve syntaxis (meer Ruby / Python-achtig), en de bestaande standaardbibliotheek in de stijl van de populaire Ruby-bibliotheken omwikkelde (en consistent maakte), en achterwaartse compatibiliteit en het vermogen had om integreren met oude code, het zou een geweldig product zijn. Vertel niemand dat ik dat gezegd heb.
Michael: Eenvoudige implementatie, een sierlijke introductie tot de concepten op het lagere niveau van webontwikkeling en meer dan een eeuw aan documentatie en beproefde praktische tips.
Michael: Nogmaals: gemakkelijke implementatie, een sierlijke introductie tot de concepten op het lagere niveau van webontwikkeling en meer dan een eeuw aan documentatie en beproefde praktische tips.
Maar serieus - vanwege de laagdrempelige toegang tot PHP kan het moeilijk zijn om het verschil te zien tussen iemand die echt weet waar hij het over heeft en iemand met hetzelfde kwalificatieniveau als jij met een reservegebied voor een blog. Bovendien is er, vanwege de enorme anciënniteit van PHP, veel inhoud - en niet alles is goed.
Dit is geen uniek probleem van PHP's - een snelle blik op W3Schools.com zal de dromen van elke voorstander van xHTML, JavaScript, CSS of PHP verpesten.
PHP-ontwikkelaars hebben last van? Not invented here syndrome.?
Het kan heel gemakkelijk zijn om, als je een taal leert, te vinden wat je gelooft als een gezaghebbende bron (die misschien verouderd of gewoon fout is) en meegaan met wat ze zijn? Lesgeven? u. Dit is iets waar de PHP-gemeenschap veel beter in moet worden - het verspreiden van het? Toch? manier om bepaalde taken te volbrengen. Ik geef toe - de Ruby-community heeft hier het voordeel, Rick Olson lost authenticatie voor iedereen op toen hij de Restful-Authenticatie-plugin uitbracht. J
PHP-ontwikkelaars hebben de eerste paar jaar last van het syndroom van? Hier niet uitgevonden? - wat ik niet geloof is een slechte zaak (totdat ze beginnen te verkopen of door te geven aan anderen). Ik denk dat de mindset achter een nieuwe ontwikkelaar, die voor de eerste keer PHP ervaart, is dat ze echt precies willen weten wat er aan de hand is - en PHP doet het perfect, geeft ze genoeg touw om zichzelf op te hangen? - onthullend genoeg om te leren, maar je gaat jezelf waarschijnlijk pijn doen. Terwijl Rick's plug-in (een geweldig authenticatiesysteem) niet wordt afgeprijsd, zijn ontwikkelaars van Rails bereid om aan te nemen dat deze kerel het goed heeft gedaan en verder gaat op weg.
PHP werd immens populair omdat het op het juiste moment op de juiste plaats was.
Ryan: Ik zou zeggen dat PHP immens populair is geworden omdat het op het juiste moment op de juiste plaats was. De alternatieven voor ontwikkeling aan de serverkant hadden op de dag een behoorlijke hoeveelheid programmeerkennis nodig, maar veel mensen die zichzelf nooit als programmeurs beschouwden gooiden dingen al samen met HTML en CSS. Met dezelfde implementatiemetafoor en een basiskennis van hoe u websites kunt samenstellen, kunt u redelijk nuttige programma's maken en deze overgeven aan een goedkope gedeelde webhost. Of je zou er een kunnen downloaden die iemand anders heeft gemaakt en het een beetje aanpassen, omdat de HTML en code allemaal met elkaar zijn vermengd.
Een ander ding dat PHP hielp was de hausse van de likes zoals het cPanel-product en de hostingproviders met white-labelling webhosting. Elke man en zijn hond kan een webhost worden tegen lage kosten en zonder enige technische kennis. Elke man en zijn hond wilden een website en goedkope hosting. PHP en MySQL waren standaardvoorraad op deze gedeelde set-ups, en ze waren overal (en zijn nog steeds).
Het beste hoeft niet altijd te 'winnen', veel mensen zijn nog steeds geïrriteerd dat SmallTalk verloren is van Java, hoewel de mensen die ik heb ontmoet (serieuze software-veteranen) die erbij waren toen dit gebeurde, zeggen dat ze zich helemaal thuis voelen in Ruby!
Ryan: Dit is niet erg aardig, maar ik zou zeggen dat de veelgehoorde kritiek op PHP behoorlijk geldig is en te wijten is aan de manier waarop de? Taal? is ontworpen (of beter gezegd, niet ontworpen). PHP werd geboren uit een aantal CGI-scripts die de oorspronkelijke auteur in C schreef (of was het Perl?), En het algemene geval van waarom PHP ging zoals het was, was zo? Ik kon een C-programmeurscripts schrijven voor de internet in slechts een paar dagen?.
Ik herinner me nooit dat ik een C-programmeur heb gevraagd om van mij een webapplicatie te maken!
Ruby aan de andere kant was ontworpen om het beste uit een aantal talen te halen om iets te creëren dat een plezier was om mee te werken, het heeft aanwijzingen gekregen van Smalltalk, Perl, LISP en anderen, en het laat zien.
Een heel groot verschil tussen PHP en Ruby voor mij was dat Ruby je aanmoedigt om te werken met hun basistypen zoals Hashes en Arrays, waar ik ze nooit natuurlijk vond in PHP. Het aantal keren dat ik de volgorde van argumenten voor String en Arrays in PHP moest opzoeken is verbijsterend.
Het aantal keren dat ik me niet kon herinneren of deze of gene functie onderstreepingen had of niet, was even vervelend. Ik heb Zend IDE gebruikt, dus ik hoefde het niet te onthouden, maar ik vond de IDE niet leuk. Het voelde alsof je verdoemd was als je dat deed en verdoemd als je dat niet deed. Er is geen consistentie in de standaardbibliotheek van PHP en het is frustrerend als een woedende beer in een telefooncel. In Ruby besteed ik zelden tijd aan documentatie voor veelgebruikte gegevenstypen, omdat de gemeenschappelijke interacties zo gemakkelijk te onthouden zijn.
Zodra je functies in de Ruby's Enumerable-module begint te gebruiken, vraag je je af hoe je ooit zonder hebt geleefd, pinky swear!
Michael: Ik denk dat dit een weerspiegeling is van de lage toetredingsdrempel en de overerfgierigheid van PHP-ontwikkelaars om echt te begrijpen wat er gaande is. Ik had honderden white papers, blogs en artikelen over authenticatiesystemen gelezen / bestudeerd - maar pas toen ik mijn eigen versie bouwde, voelde ik echt dat ik wist wat er aan de hand was. Ik geloof dat nieuwe PHP-ontwikkelaars graag willen delen wat ze hebben gedaan met de rest van de wereld en dat ze vaak hard worden afgerekend omdat ze zich niet aan de beste werkwijzen of bewezen beveiligingspatronen hielden.
Michael: Ik denk dat zowel PHP als Ruby ernstige problemen hebben in hun documentatie - en om volledig tegenovergestelde redenen.
PHP heeft tonnen documentatie, dankzij zijn anciënniteit - je kunt het antwoord op elke vraag vinden met een snelle Google-zoekopdracht en het zal werken. Is het de beste oplossing? Misschien misschien niet?
Rails is zo snel gegroeid dat zelfs ik het moeilijk heb om bij te houden.
Ruby heeft geweldige documentatie, maar in werkelijkheid lijkt dit een raamwerk versus kadervraag te zijn, dus we gaan uit van Rails. Rails is zo snel gegroeid dat zelfs ik het moeilijk heb om bij te houden. Rails API-documentatie is geweldig; maar als het gaat om documentatie van derden (boeken, blogartikelen, StackOverflow-antwoorden) - ze zijn allemaal verouderd en terwijl ze deze informatie volgen, is het erg moeilijk om het probleem te debuggen en het te repareren.
In dit opzicht denk ik dat PHP het voordeel heeft omdat de individuele kaders (CodeIgniter, FuelPHP, Kohana, CakePHP, enz.) Dit effect tot op zekere hoogte kunnen beperken - als je een van deze frameworks gebruikt, is het eenvoudig om het definitieve antwoord te vinden voor wat je zoekt.
Ryan: Toen ik PHP gebruikte, werd er veel nadruk gelegd op hoe geweldig de opmerkingen in de PHP.net-documentatie waren. De filosofie leek te zijn om 'de documentatie één keer te schrijven en mensen hun twee cent toe te voegen'. Het probleem hiermee is dat opmerkingen worden opgemaakt in volgorde van plaatsing, wat betekent dat de goede niet naar de top filteren, en dat de inzichten die erin worden gedeeld niet tijdig in de documentatie werden verwerkt (of helemaal niet).
Zoveel van de algemene API is opgenomen in de PHP-kern, die niet zo vaak verandert, dus ik denk dat een wiki-oplossing meer geschikt zou zijn. Op die manier kan de community de officiële documentatie wijzigen, wijzigingen voorstellen, voorbeelden voorstellen, het goede van de opmerkingen integreren in wat mensen het eerst zien. Dat zou handig zijn (vooral voor een beginner).
Java-cursussen leren mensen eerst over polymorfisme en kijken naar wat ze doen - ontwerp met klassehiërarchieën als eerste snee! Het maakt mij gek!
In Ruby staan veel van de veelgebruikte bibliotheken op GitHub, waar mensen kleine veranderingen en verbeteringen kunnen voorleggen die worden opgerold in een in het algemeen reguliere release-cyclus. Documentatie is gekoppeld in code met behulp van RDoc (vergelijkbaar met PHPDoc) en wanneer u een juweel installeert, genereert het documentatie over uw lokale systeem. Voor een groot deel van mijn werk, zal ik of kerndocumentatie lezen op rubydoc.info, of lokaal op mijn computer, of als een van die faalt in de broncode van de bibliotheken zelf.
We hebben de gedachten van Ryan en Michael gehoord en je hebt zeker je eigen mening. Vervolg het debat in de comments!
