Prepisovanie Reddit

Link: http://www.aaronsw.com/weblog/rewritingreddit

Preklady: Srpsko-Hrvatski

2012 Poznámka: Tento článok bol prvýkrát zverejnený v roku 2005. Po jeho uverejnení Django spustil projekt RemovingTheMagic, ktorý sa zaoberal niektorými mojimi kritikami (hoci osobne ho stále považujem za nepoužiteľný), web.py inšpiroval tornado.web a gae.webapp od spoločnosti FriendFeed a iní (aj keď stále preferujem web.py) a tento článok viedol k trvalému nárastu návštevnosti Redditu, ktorý ešte stále naozaj neprestáva rásť.

reddit maskot

Na stránkach reddit.com sme minulý týždeň prepísali stránku z Lispu na Python. Bolo to skoro v jednom víkende. (Zverejnenie: použili sme moju web.py knižnicu.) Ostatní vedeli, že Lisp (v ňom napísali celú stránku) a vedeli, že Python (prepísali celý svoj web) a napriek tomu sa rozhodli, že Python je pre tento projekt vhodnejší. Verzia programu Python mala menej kódu, ktorý bežal rýchlejšie a bol oveľa jednoduchší na čítanie a údržbu.

Myšlienka, že je niečo lepšie ako Lisp, je pre niektorých zrejme nepredstaviteľné, a to z komentárov na reddit blogu . Lispers sa namiesto toho rýchlo snažil nájsť skutočný dôvod za prepínačom.

Predpokladá sa, že to muselo byť božským zásahom, pretože “neexistuje žiadny iný dôvod na prechod k menejcennému jazyku.” Ďalšia predstava, že sa musí niečo stať ďalej: “Mohla by to byť … lež? Odhodiť konkurenciu? Nie je to tak, ako Paul Graham v jeho esejích nenaznačil túto taktiku … “Ďalšou zmenou:” Rozhodol som sa, že je to žart. “Iný navrhol, že autori jednoducho chcú viac” orezaných rohov, hackov a falošných remesiel “.

Boli to samozrejme extrémne prípady. Iní predpokladali, že musí existovať vonkajší tlak. “Buď knižnice alebo nájdenie nových programátorov.” Ďalšou záverom je, že “nejaký vc oblek si želá, aby bol programátor udržiavaný podľa Joe. Dúfam, že vám zaplatí milióny. “

Diskusná skupina Lisp comp.lang.lispbola znepokojená prepínaním, ktoré v súčasnosti plánuje napísať súťažiaceho, aby reddit v Lispu ukázal, ako správne sú alebo niečo také.

Spravodlivejšie tvrdenie, podľa toho, ako hovorí Lispov hodnota, spočíva v tom, že je schopný vytvoriť nové lingvistické konštrukcie a že pre niečo ako jednoduchú webovú aplikáciu to nie je potrebné, pretože stavby už boli postavené. Ale aj to nie je pravda. web.py bol postavený skoro od začiatku a používa najrôznejšie “nové lingvistické konštrukty” a – ešte lepšie – tieto konštrukcie majú syntax, ktorý s nimi súvisí a robí ich rozumne čitateľnými. Iste, Python nie je Perl 6, takže nemôžete pridať ľubovoľnú syntax, ale často môžete nájsť šikovný spôsob, ako to urobiť.


Python na druhej strane má svoje vlastné problémy. Najväčší je to, že má desiatky rámcov webových aplikácií, ale žiadny z nich nie je dobrý. Pythonisti si dobre uvedomujú prvú časť, ale zrejme nie druhú, pretože keď im poviem, že používam svoju vlastnú knižnicu, univerzálna odpoveď je “Nemyslím si, že Python potrebuje iný rámec webovej aplikácie”. Áno, Python potrebuje menej rámcov webových aplikácií. Ale potrebuje sa aj to, ktoré nezažíva.

Rámec, ktorý sa zdá byť najsľubnejší, je Django a naozaj sme sa na začiatku pokúsili o prepracovanie Redditu v ňom. Ako najskúsenejší programátor Pythonu som sa snažil pomôcť ostatným.

Django sa zdalo skvelé zvonku: pekná webová stránka, inteligentní a talentovaní vývojári a zdanlivý prebytok pekných funkcií. Vývojári a komunita sú veľmi nápomocní a reagujú na náplasti a návrhy. A všetky správne ciele sú zakotvené vo svojich filozofických dokumentoch a často kladených otázkach. Bohužiaľ sa však zdajú byť úplne neschopní žiť.

Zatiaľ čo Django tvrdí, že je “voľne spojený”, jeho používanie v podstate vyžaduje prispôsobenie vášho kódu do Djangovho svetonázoru. Django trvá na tom, aby sám vykonal váš kód, a to buď pomocou príkazového riadku, alebo špecializovaným obslužným programom serverov s príslušnými premennými prostredia a Pythonovou cestou. Keď spustíte projekt, Django štandardne vytvorí priečinky vnorené do štyroch úrovní hlboko pre váš kód a zatiaľ čo sa môžete pohybovať niektorými súbormi, mal som problém zistiť, ktoré z nich a ako.

Django filozofia hovorí: “Explicit je lepší než implicitný”, ale Django má všetky druhy mágie. Databázové modely, ktoré vytvoríte v jednom súbore, sa čarovne objavujú niekde inde hlboko vo vnútri modulu Django s iným názvom. Keď sa nazýva funkcia vášho modelu, pridali sa k nej variabilné priestory nové veci a odstránili staré. (Povedal som, že v súčasnej dobe pracujú na tom, aby obidva tieto vyriešili.)

Ďalším cieľom Django je “menej kód”, prinajmenšom pre vás. Ale Django je jednoducho plný kódu. Vnútri modulu django je 10 rôznych zložiek a vo vnútri každého z nich je niekoľko ďalších. V čase, keď ste skutočne vytvoriť stránky v Django tutoriálu ste importovali django.core.metadjango.models.pollsdjango.conf.urls.defaults.*django.utils.httpwrappers.HttpResponsedjango.core.extensions.render_to_response. Nie je jasné, ako by si to mal každý spomenúť, najmä preto, že sa zdá, že neexistujú žiadne usmerňujúce princípy toho, čo ide tam, kde a ako sa to nazýva. Tri z nich sa automaticky vkladajú do úvodných skriptov, ale stále si ich musíte zapamätať pre každú ďalšiu funkciu, ktorú chcete použiť.

Ale najdôležitejším problémom Django je to, že jeho vývojári sa zdajú byť neschopní navrhnúť slušné API. Sú to jednoznačne schopní programátori Pythonu – ich kód používa všetky bizarné triky. A oni sú jasne schopní písať kód, ktorý funguje – majú všetky druhy zaujímavých funkcií. Zdá sa, že tento kód nemôžu formovať do niečoho, čo môžu používať ďalší ľudia.

Ich API sú škaredé a pravidelne chýbajú kľúčové vlastnosti: API databázy vyrieši otázky pomocou počítania podčiarkov, ale nemá žiadnu špeciálnu syntax pre JOIN, šablónový systém vyžaduje štyri kučeravé pásy okolo každej premennej a nemôže robiť žiadny výpočet, API formulára vyžaduje 15 riadkov na spracovanie formulára a nemôže automaticky generovať šablónu.

Snažil som sa čo najlepšie opraviť veci – a komunita Django bola mimoriadne podporná – ale úloha mi jednoducho trpčila. Nemohol som to robiť len mentálne, nieto s časovými obmedzeniami, že musím skutočne stavať vlastnú aplikáciu pre vlastné spustenie.


A tak, Lisp a Django nájdený si ľahký, my sme vľavo s web.py . Rád by som povedal, že web.py sa naučil z týchto chýb a bol navrhnutý tak, aby sa im vyhýbal, ale pravdou je, že web.py bol napísaný už skôr ako toto všetko a podarilo sa im napriek tomu vyhnúť.

Spôsob, akým som napísal web.py, bol jednoduchý: predstavoval som, ako by mali veci fungovať, a potom som to urobil. Niekedy robia veci len prácu veľa kódu. Niekedy to trvá len trochu. Ale buď tak, táto skutočnosť je skrytá od užívateľa – oni jednoducho získajú ideálne rozhranie API.

Takže ako by mali veci fungovať? Prvou zásadou je, že kód by mal byť jasný a jednoduchý. Ak chcete odoslať určitý text, zavoláte web.output. Ak chcete získať vstupný formulár, zavoláte web.input. Nie je nič obzvlášť ťažko zapamätateľné.

Druhým princípom je, že web.py by mal zodpovedať vášmu kódu, nie opačne. Každá funkcia v web.py je úplne nezávislá, môžete použiť ktorúkoľvek z nich, ktorú chcete. Môžete dať svoje súbory všade, kde sa vám páči, a web.py bude šťastne nasledovať. Ak chcete, aby bol kus kódu spustený ako webová aplikácia, zavoláte web.run, nezadávate svoj kód na magické miesto, aby vás web.py mohol spustiť.

Tretím princípom je, že web.py by malo štandardne robiť správnu vec na webe. To znamená správne rozlišovať medzi GET a POST. To znamená jednoduché, kanonické adresy URL, na ktoré sa synonymá presmerujú. Znamená to čitateľný HTML so správnymi hlavičkami HTTP.

A to, pokiaľ ide o mňa, sú skoro všetky princípy, ktoré potrebujete. Zdá sa, že sú pre mňa celkom jednoduché a zrejmé, a dokonca som ochotný zaujať niektoré z nich, ale žiadny iný rámec webových aplikácií Pythonu sa dokonca ani neobjaví. (Ak viete o jednom, povedzte mi a budem šťastne odvolávať. Nechcem byť v tejto práci.) Do tej doby to vyzerá, že som nútený robiť to strašnú vec, ktorú by som radšej neurobil: uvoľnite do sveta ešte jeden rámec webovej aplikácie Pythonu.

Mali by ste ma sledovať na twitter tu .

6. decembra 2005