Acest eseu este o alta incercare de a reconcilia puterea limbajului de programare Lisp cu incapacitatea comunitatii Lisp de a reproduce realizarile lor pre-AI. Fara indoiala, Lisp a fost o sursa de idei influenta chiar si in timpul perioadei de retragere. Acest fapt, plus stralucirea diferitelor arhitecturi ale Lisp Machine si actuala renastere Lisp dupa mai mult de un deceniu in salbaticie demonstreaza ca partizanii Lisp trebuie sa aiba o justificare pentru blandetea lor. Cu toate acestea, ei nu au reusit sa traduca puterea lui Lisp intr-o miscare cu un impuls puternic.
In acest eseu, susin ca puterea expresiva a lui Lisp este, de fapt, o cauza a lipsei de impuls.

.

Puterea lui Lisp este propriul sau dusman.
    Iata un experiment gandit pentru a demonstra acest lucru: Luati doua limbi de programare, dintre care nici una nu este orientata pe obiecte. Misiunea ta, daca alegi sa o accepti, este de a le face orientate pe obiecte, pastrandu-le inapoi compatibile cu limbile originale, modulare in unele cazuri de margine. Introducerea oricarei perechi de limbi de programare in acest experiment de gandire va arata ca acest lucru este mai usor cu unele limbi decat cu altele. Acesta este punctul experimentului de gandire. Iata un exemplu trivial: Intercal si Pascal.
    Acum face acest experiment de gandire interesant: Imaginati-va adaugarea orientarii obiectului la limbile de programare C si Scheme. Efectuarea schemei orientate pe obiecte este o sarcina de acasa pentru alti studenti. Pe de alta parte, adaugarea orientarii obiectului in C necesita programarea lui Bjarne in Stroustrup.
    Consecințele acestei divergente in talentul si efortul necesar provoaca blestemul Lisp:
Lisp este atat de puternic incat problemele care sunt probleme tehnice in alte limbi de programare sunt probleme sociale in Lisp.
                                        __________________________________________
    Luati din nou in considerare cazul Schemei. Deoarece schema orientata pe obiecte este atat de usoara, multi hackeri ai programului au facut-o deja. Mai mult, multi hackeri ai schemei individuale au facut acest lucru. In anii 1990, acest lucru a condus la o lista reala de inventariere a pachetelor orientate pe obiecte pentru limba. Paradoxul alegerii, singur, garanta ca nici unul dintre ele nu ar deveni standard. Acum ca unele implementari ale schemei au propriile facilitati de orientare a obiectelor, nu este aaa de rau. Cu toate acestea, faptul ca multe dintre aceste pachete au fost lucrarile indivizilor singuri au condus la probleme pe care Olin Shivers le-a scris in documentarea Schemei Shell, scsh
    Programele scrise de hackeri individuali tind sa urmeze modelul de zgarietura. Aceste programe vor rezolva problema pe care hacker-ul insusi o are fara a manipula neaparat parti conexe ale problemei, ceea ce ar face programul mai util pentru ceilalti. Mai mult decat atat, programul este sigur ca va lucra la configurarea proprie a acelui hacker, dar nu poate fi portabil pentru alte implementari ale Schemei sau pentru aceeasi implementare a Schemei pe alte platforme. Documentatia poate fi lipsita. Fiind in esenta un proiect realizat in timpul liber copios al hackerilor, programul este susceptibil de a suferi daca responsabilitatile legate de viata reala ar trebui sa intre in hacker. Asa cum a remarcat Olin Shivers, acest lucru inseamnă ca aceste proiecte cu o singura persoana tind sa solutioneze optzeci la suta din aceasta problema.
    Eseul Dr. Mark Tarver, Programatorul bipolar Lisp, are o descriere apreciabila a acestui fenomen. El scrie despre acesti hackeri lupi singuratici Lisp si a lor
 
    ... incapacitate de a termina lucrurile in mod corespunzator. Expresia "design-ul aruncat" este absolut facuta pentru BBM si vine de la comunitatea Lisp. Lisp va permite doar sa dezactivati lucrurile atat de usor si este usor sa luati acest lucru ca atare. Am vazut asta acum 10 ani cand am cautat un GUI la Lisp. Nici o problema, au existat 9 oferte diferite. Problema a fost ca niciunul dintre cele 9 nu a fost documentat in mod corespunzator si nici unul nu a fost lipsit de bug-uri. Practic, fiecare persoana si-a implementat propria solutie si a lucrat pentru el, aaa ca a fost bine. Aceasta este o atitudine BBM; Functionează pentru mine si inteleg. Este, de asemenea, produsul de a nu mai avea nevoie sau de a avea nevoie de ajutorul altcuiva pentru a face ceva.

    Inca o data, ia in considerare limba de programare C in acel experiment de gandire. Datorita dificultatii de a face C orientate pe obiect, doar doua incercări grave la problema au facut orice tractiune: C + + si Obiectiv-C. Obiectivul C este cel mai popular pe Macintosh, in timp ce C ++ ruleaza oriunde altundeva. Aceasta inseamna ca, pentru o anumita platforma, intrebarea cu privire la extinderea orientata spre obiect a C a fost deja definitiv raspunsa. Aceasta inseamna ca facilitatile orientate spre obiecte pentru aceste limbi au fost documentate, ca mediile de dezvoltare integrate sunt constiente de ele, ca bibliotecile de coduri sunt compatibile cu acestea si asa mai departe.
    Eseul Dr. Mark Tarver despre Lisperii bipolari face ca punctul:

    Acum, in contrast, abordarea C / C ++ este destul de diferita. Este atat de greu sa faci ceva cu pensete si adezivi incat orice lucru important pe care îl faci va fi o adevarata realizare. Vreti sa o documentati. De asemenea, aveti nevoie de ajutor in orice proiect C de dimensiuni semnificative; Astfel incat sunteti susceptibile de a fi sociale si de a lucra cu altii. Trebuie doar sa ajungi undeva.

    Si toate acestea, din punctul de vedere al unui angajator, sunt atractive. Zece persoane care comunica, documenteaza lucrurile in mod corespunzator si lucreaza impreuna sunt de preferat fata de un BBM care hackuieste Lisp care poate fi inlocuit numai de un alt BBM (dacă il puteți gasi) in cazul putin probabil ca el va merge intr-o anumita perioada fara a fi reincarcabil.

    Prin urmare, cei care deja cunosc C nu intreaba "Ce sistem obiect trebuie sa invat?" In schimb, utilizeaza C ++ sau Obiectiv-C in functie de ce folosesc colegii lor, apoi treceti la "Cum utilizez caracteristica orientata pe obiecte X?" Raspundeti: "Gaseste-l si veti gasi."

    Hackerii adevarati, bineinteles, au stiut de mult ca programarea orientata pe obiect nu este panaceul pe care partizanii l-au revendicat. Hackerii advarati s-au mutat la concepte mai avansate, cum ar fi structuri de date imutabile, inferente de tip, evaluari lenese, monade, sageti, potrivirea modelului, programarea bazata pe constrangeri si aaa mai departe. Hackerii Adevarati au cunoscut, de asemenea, pentru un timp, ca C si C ++ nu sunt potrivite pentru majoritatea programelor care nu trebuie sa faca arbitrar. Cu toate acestea, blestemul Lisp ramane in continuare.
    Unii dintre cei mai indrazneti iubitori de Lisp au discutat despre recolta curenta a limbilor academice (Haskell, Ocaml, etc) si le-au gasit dorind, spunand ca orice caracteristica a lor este deja prezenta in Lisp sau poate fi usor implementata cu Macro-uri. Probabil ca au dreptate.
    Pacat de hackerii Lisp.
                                __________________________________________
    Dr. Mark Tarver - de doua ori citat mai sus - a scris un dialect din Lisp numit Qi. Sunt mai putin de zece mii de linii de macrocomenzi care ruleaza la Clisp. Acesta implementeaza cele mai multe caracteristici unice ale Haskell si OCaml. In unele privinte, Qi le depaseste. De exemplu, motorul de inferenta de tip Qi este Turing complet. Intr-o lume in care au fost necesare echipe de cadre didactice talentati pentru a scrie Haskell, un singur om, dr. Tarver a scris Qi de unul singur.
    Cititi acest paragraf din nou si extrapolati-l.
                                __________________________________________
   Exercitiu pentru cititor: Imaginati-va ca exista o puternica rivalitate intre Haskell si Common Lisp. Ce se intampla in continuare?
    Raspuns: Blestemul Lisp incepe. Fiecare hacker serios Lisp va face propria sa implementare a evaluarii lenese, a puritatii functionale, a sagetilor, a potrivirii tiparelor, a tipului de inferente si a restului. Cele mai multe dintre aceste proiecte vor fi operațiuni singuratice. Astfel, vor avea optzeci la suta din trasaturile pe care majoritatea oamenilor au nevoie (cate optzeci de procente diferite in fiecare caz). Ele vor fi prost documentate. Nu vor fi portabile in sistemele Lisp. Unii vor arata o mare promisiune inainte de a fi abandonati, in timp ce managerul de proiect merge sa-si plateasca facturile. Mai multe vor bate Haskell de-a lungul acestei sau acelei dimensiuni (din nou, una diferita in fiecare caz), dar acceptarea lor va fi impiedicata de razboaiele cu flacara pe grupul Lisp dupa Usenet.
    Sfarsitul jocului: o colectie de macrocomenzi ale Lack hacker ale timpului vechi va adauga pana la o implementare nedocumentata, incompatibila, de 80% din Haskell, deoarece Lisp este mai puternic decat Haskell.
                                        __________________________________________
    Moralul acestei povestiri este ca efectele secundare si tertiare conteaza. Tehnologia afecteaza nu numai ceea ce putem face in privinta aspectelor tehnologice, ci afecteaza si comportamentul nostru social. Acest comportament social poate reversa si afecta problemele tehnologice initiale in discutie.
    Lisp este un exemplar dureros de elocvent al acestei lectii. Lisp este atat de puternic incat incurajeaza independenta individuala pana la punctul de vedere al sangelui. Aceasta independenta a produs inovatie uimitor de buna ca in zilele Lisp. Aceeasi independenta impiedica, de asemenea, eforturile de revigorare a sistemelor vechi de "Lisp in jos"; Niciun proiect "Lisp OS" nu a adunat o masa critica de la decesul Symbolics si LMI.
    Un rezultat al acestor efecte secundare si tertiare este ca, chiar daca Lisp este cel mai expresiv limbaj vreodata, astfel incat este teoretic imposibil sa se faca un limbaj mai expresiv, Lispersii vor mai avea lucruri de invatat din alte limbi de programare. Baietii de la Smalltalk i-au invatat pe toti - inclusiv pe hackerii Lisp - un lucru sau doua despre programarea orientata pe obiecte. Limba de programare curata si combinatia Mozart / Oz pot avea cateva surprize de-ale lor.
                                       __________________________________________
    Blestemul Lisp nu contrazice maximul lui Stanislav Datskovskiy: Angajatorii prefera mai mult ca muncitorii sa fie inlocuiți, nu sa maximizeze productivitatea. Prea adevarat. Cu mare dificultate, cineva se ocupa de venalitatea clasei manageriale. Cu toate acestea, ultimele randuri ale eseului sau sunt problematice. Pentru a intelege:

    In ceea ce priveste lumea "software-ului liber", ea se opune cu fermitate dogmelor industriale in retorica, dar deloc in practica. Nici un concept evitat de iadul fermei de cuburi nu a castigat vreodata o adevarata forta de tractiune printre masele de amatori.

    Intr-o nota de subsol, el ofera Linux ca exemplu de această lipsa de dorinta de a urmari diferite idei. Desigur, el are un punct cand vine vorba de sistemele de operare (cel mai important comentariu, in special, este infuriat in mod obositor). El nu are nici un punct cand vine vorba de limbajele de programare. Python si Ruby au fost influentate de Lisp. Multi dintre fani isi exprima respectul fata de Lisp si unii din interesul lor au marit renasterea Lisp. Cu o anumita justitie, JavaScript a fost descris ca fiind "Schema in imbracamintea lui C", in ciuda faptului ca a provenit din acele iad-uri de casa.
    Cu toate acestea, in ciuda acestei influentei, atat in lumea corporativa, cat si in lumea open source, Lisp are inca o parte din partea dezvoltatorului care a atras recolta actuala de limbi avansate de scripting. Inchiderea mintii MBA nu poate fi singura explicatie pentru acest lucru. Blestemul Lisp are o putere explicativa mai mare.
                                __________________________________________
    Mediile gratuite de dezvoltare disponibile pentru Lisp exemplifica in continuare blestemul Lisp.
    Este jenant sa arati acest lucru, dar trebuie facut. Uita de masina Lisp; Nici macar nu avem sisteme de dezvoltare care sa se potriveasca cu ceea ce hacker-ul Smalltalk-ului are nevoie ("intotdeauna am simtit ca Lisp este limba superioara si Smalltalk este mediul superior" - Ramon Leon). Daca nu platesc mii de dolari, hackerii Lisp sunt inca blocati de Emacs.
    James Gosling, autorul primelor Emacs care ruleaza pe Unix, a subliniat in mod corect ca Emacs nu sa schimbat fundamental in mai mult de douazeci de ani. Acest lucru se datoreaza faptului ca administratorii Emacs sunt in continuare un cod de stratificare deasupra unui design care a fost rezolvat atunci cand Emacs a fost un proiect grad-student la laboratorul MIT AI, adica atunci cand dezvoltarea Emacs era incă finantata indirect de datoria natională. Un Slashdotter poate obiecta ca Emacs este deja destul de capabil si poate face orice poate face orice alt mediu de dezvoltare, doar mai bine. Cei care au folosit calculatoare Lisp spun altfel.
    Deci, de ce hackerii Lisp nu au pus tipii lui Smalltalk in locul lor? De ce nu fac un sistem de dezvoltare liber care sa va aduca aminte de unele dintre gloriile pierdute ale LispM, chiar daca nu pot reproduce un alt LispM?
    Motivul pentru care acest lucru nu se intâmpla este din cauza blestemului Lisp. Un numar mare de hackeri Lisp ar trebui sa coopereze intre ei. Uita-te mai indeaproape: Numarul mare de oameni care devin hackeri Lisp ar trebui sa coopereze intre ei. Si ar fi trebuit sa coopereze unul cu celalalt pe un design care nu era inca dat de la inceput. Si nu ar exista nici o disciplina externa, cum ar fi un capitalist de risc sau alt maestru corporativ, pentru a le mentine pe drumul cel bun.
    Fiecare proiect are frictiune intre membri, dezacorduri, conflicte asupra stilului si filosofiei. Aceste probleme sociale sunt contra-actionate de faptul ca nici un proiect mare nu poate fi realizat altfel. "Trebuie sa ramanem impreuna sau toti vom ramane separati". Dar expresivitatea Lisp face ca aceasta forta de compensare sa fie mult mai slaba; Se poate incepe intotdeauna propriul proiect. Astfel, hackerii individuali decid ca problema nu merita. Deci, fie parasesc proiectul, fie nu se alatura proiectului. Acesta este blestemul Lisp.

    S-ar putea chiar sa-l hackuiti pe Emacs pentru a obtine ceva suficient de bun. Astfel, blestemul Lisp este aliatul rau este mai bun.
    Puterea expresiva a lui Lisp are dezavantaje. Nu exista asa ceva precum un pranz gratuit.
                                __________________________________________

© Rudolf Winestock, Toate drepturile Rezervate
Acest eseu a fost publicat Vineri, Aprilie 15, 2011.