Klątwa Lisp – FSU-University.com

This is the translation. The original web-page (oryginalna strona): http://winestockwebdesign.com/Essays/Lisp_Curse.html

AUTOR: RUDOLF WINESTOCK

Aktualizować w dniu 6 października 2017 r NB: Proszę przestać składania to Hacker wiadomość! Spójrz na haker Aktualności wyników wyszukiwania dla tego eseju. Sprawdź wiadomości do pierwszego wpisu: Chodźcie, wszyscy! Załóżmy pokonać martwego konia jeszcze raz! Jeśli chcesz zarobić Hacker Wiadomosci e-cred, a następnie spróbuj składania Wiecznego Główna rama, zamiast.

Ten tekst jest kolejną próbą pogodzenia moc Lisp języka programowania z niezdolności Lisp społeczności odtworzenia ich pre-AI zimowe osiągnięć. Bez wątpienia Lisp był wpływowym źródłem pomysłów nawet w czasie odwrotu. Fakt ten oraz błyskotliwość różnych architektur Lisp Machine i obecny renesans Lisp po ponad dekadzie na pustkowiu pokazują, że partyzanci Lisp muszą mieć jakieś uzasadnienie dla swojego zadowolenia z siebie. Niemniej jednak nie byli w stanie przełożyć mocy Lisp na ruch o przytłaczającym pędzie.

W tym eseju twierdzę, że ekspresyjna moc Lispa jest w rzeczywistości przyczyną jego braku rozmachu.

Moc Lisp jest jego największym wrogiem.

Oto eksperyment myślowy, aby to udowodnić: weź dwa języki programowania, z których żaden nie jest zorientowany obiektowo. Twoim zadaniem, jeśli zdecydujesz się to zaakceptować, jest uczynienie ich obiektowymi, utrzymanie ich wstecznej kompatybilności z oryginalnymi językami, modulo niektóre przypadki krawędzi. Wstawienie dowolnej pary języków programowania do tego eksperymentu myślowego pokaże, że w niektórych językach jest to łatwiejsze niż w innych. Właśnie o to chodzi w eksperymencie myślowym. Oto trywialny przykład: Intercal i Pascal.

Teraz uczyń ten eksperyment myślowy interesującym: Wyobraź sobie dodanie orientacji obiektowej do języków programowania C i Scheme. Uczynienie Schematu obiektowym jest drugim zadaniem domowym. Z drugiej strony dodanie orientacji obiektowej do C wymaga programowania Bjarne Stroustrup.

Konsekwencje tej rozbieżności w potrzebnych talentach i wysiłku powodują Klątwa Lisp:

Lisp jest tak potężny, że problemy, które są problemami technicznymi w innych językach programowania, są problemami społecznymi w Lisp.

Ponownie rozważmy przypadek programu. Ponieważ uczynienie Scheme obiektowym jest tak łatwe, wielu hakerów Scheme to zrobiło. Co więcej, wielu indywidualnych hakerów Scheme to zrobiło. W latach dziewięćdziesiątych doprowadziło to do powstania prawdziwej listy magazynowej dla pakietów obiektowych dla tego języka. Paradoks wyboru, sam, gwarantuje, że żaden z nich nie stać się standardem. Teraz, gdy niektóre implementacje schematu mają własne obiekty do orientacji obiektowej, nie jest tak źle. Niemniej jednak fakt, że wiele z tych pakietów było dziełem samotnych osób, doprowadził do problemów, o których Olin Shivers pisał podczas dokumentowania powłoki systemu, scsh.

Programy napisane przez indywidualnych hakerów mają tendencję do podążania za modelem. Programy te rozwiążą problem samego hakera, niekoniecznie zajmując się pokrewnymi częściami problemu, co uczyniłoby program bardziej przydatnym dla innych. Co więcej, program z pewnością będzie działał na własnej konfiguracji tego samotnego hakera, ale może nie być przenośny do innych implementacji Scheme lub do tej samej implementacji Scheme na innych platformach. Może brakować dokumentacji. Będąc zasadniczo projektem realizowanym w hojnym czasie wolnym hakera, program może ucierpieć, gdyby hakerów na niego wpłynęły rzeczywiste obowiązki. Jak zauważył Olin Shivers, oznacza to, że projekty one-man-band zazwyczaj rozwiązują osiemdziesiąt procent problemu.

Esej dr Mark Tarver, w dwubiegunowego Lisp Programista ma trafny opis tego zjawiska. Pisze tych Lone Wolf Lisp hakerów i ich

…niezdolność do prawidłowego wykończenia. Wyrażenie „wyrzucenie na bok” jest absolutnie stworzone dla BBM i pochodzi od społeczności Lisp. Lisp pozwala tak łatwo odrzucić rzeczy i łatwo jest to uznać za coś oczywistego. Widziałem to 10 lat temu, kiedy szukam GUI do mojej Lisp. Nie ma problemu, było 9 różnych ofert. Problem polegał na tym, że żaden z 9 nie został odpowiednio udokumentowany i żaden nie był wolny od błędów. Zasadniczo każda osoba wdrożyła własne rozwiązanie i działało dla niego, więc było dobrze. To jest postawa BBM; to działa dla mnie i rozumiem to. Jest to także wynik niepotrzebnego lub chęci czyjejś pomocy, aby coś zrobić.

Jeszcze raz rozważmy język programowania C w tym eksperymencie myślowym. Ze względu na trudność zorientowania obiektowego na C, tylko dwie poważne próby rozwiązania problemu przyniosły jakiekolwiek efekty: C++ i Objective-C. Objective-C jest najbardziej popularny na Macintosh, podczas gdy C++ rządzi wszędzie indziej. Oznacza to, że na daną platformę pytanie, na które obiektowe rozszerzenie C ma być używane, zostało już ostatecznie rozstrzygnięte. Oznacza to, że obiekty zorientowane obiektowo dla tych języków zostały udokumentowane, że zintegrowane środowiska programistyczne są tego świadome, biblioteki bibliotek są z nimi kompatybilne i tak dalej.

Esej dr. Marka Tarvera na temat dwubiegunowej Lispers ma na myśli:

Teraz natomiast podejście do C/C++ jest zupełnie inne. Tak cholernie trudno jest zrobić coś za pomocą pincety i kleju, że wszystko, co zrobisz, będzie prawdziwym osiągnięciem. Chcesz to udokumentować. Możesz także potrzebować pomocy w każdym znaczącym projekcie C; więc możesz być towarzyski i współpracować z innymi. Musisz tylko gdzieś się dostać.

A wszystko to z punktu widzenia pracodawcy jest atrakcyjne. Dziesięć osób, które komunikują się, dokumentują rzeczy poprawnie i współpracują, są lepsze niż jeden BBM hakujący Lisp, którego można zastąpić innym BBM (jeśli można go znaleźć) w mało prawdopodobnym przypadku, że w pewnym momencie upadnie, nie będąc restartowalny.

Dlatego ci, którzy już znają C, nie pytają „Jakiego systemu obiektowego powinienem się nauczyć?” Zamiast tego używają C++ lub Objective-C w zależności od tego, czego używają ich koledzy, a następnie przechodzą do „Jak korzystać z funkcji obiektowej X?” Odpowiedź: „Googuj, a znajdziesz.”

Prawdziwi hakerzy od dawna wiedzą, że programowanie obiektowe nie jest panaceum, jak twierdzą jego zwolennicy. Prawdziwi hakerzy przeszli do bardziej zaawansowanych koncepcji, takich jak niezmienne struktury danych, wnioskowanie o typach, leniwa ocena, monady, strzałki, dopasowywanie wzorców, programowanie oparte na ograniczeniach i tak dalej. Prawdziwi hakerzy od pewnego czasu wiedzieli również, że C i C++ nie są odpowiednie dla większości programów, które nie muszą wykonywać arbitralnych bibułek. Niemniej jednak Klątwa Lisp nadal obowiązuje.

Niektórzy zadowoleni z siebie miłośnicy Lisp przeprowadzili ankietę na temat obecnych upraw języków akademickich (Haskell, Ocaml, et cetera) i stwierdzili, że chcą, mówiąc, że dowolna ich funkcja jest już obecna w Lisp lub może być łatwo zaimplementowana – i ulepszona – za pomocą Lisp makra. Prawdopodobnie mają rację.

Szkoda hakerów Lisp.

Dr Mark Tarver – dwukrotnie cytowany powyżej – pisał dialektem Lisp nazywa Qi. Jest to mniej niż dziesięć tysięcy linii makr uruchomionych na szczycie clisp. Implementuje większość unikalnych cech Haskell i SML. W niektórych aspektach, Qi przewyższa je. Na przykład, typ silnika wnioskowania Qi jest Turinga kompletne. W świecie, gdzie potrzebne są zespoły utalentowanych naukowców napisać Haskell, jeden człowiek, dr Tarver napisał Qi wszystko przez jego Samotny.

Przeczytaj ten akapit jeszcze raz i dokonaj ekstrapolacji.

Ćwiczenie dla czytelnika: Wyobraźmy sobie, że silna rywalizacja między Haskell i rozwija Common Lisp. Co się potem dzieje?

Odpowiedź: Uruchamia się Klątwa Lisp. Co drugi lub trzeci poważny haker Lisp rzuci własną implementację leniwej oceny, czystości funkcjonalnej, strzałek, dopasowania wzorców, wnioskowania typu i innych. Większość tych projektów będzie operacjami samotnych wilków. W ten sposób będą miały osiemdziesiąt procent funkcji potrzebnych większości ludzi (w każdym przypadku inny osiemdziesiąt procent). Będą słabo udokumentowane. Nie będą przenośne w systemach Lisp. Niektórzy okażą wielką obietnicę, zanim zostaną porzuceni, a opiekun projektu pójdzie zapłacić rachunki. Kilku pokona Haskella w tym lub innym wymiarze (znowu w każdym przypadku inny), ale ich akceptację będą utrudniać wojny płomieniowe na grupie use.comp.lang.lisp.

Endgame: Kolekcja losowej stare czasy LISP hakera makr doda się do nieudokumentowanych, nieprzenośne, bug jeździł realizację 80% Haskell ponieważ Lisp jest mocniejszy niż Haskell.

Morał z tej historii jest to, że efekty wtórne i trzeciorzędne znaczenie. Technologia nie tylko wpływa na to, co możemy zrobić w odniesieniu do problemów technologicznych, ale także wpływa na nasze zachowania społeczne. To zachowanie społeczne może zapętlić się i wpłynąć na pierwotne rozważane problemy technologiczne.

Lisp jest boleśnie wymownym przykładem tej lekcji. Lisp jest tak potężny, że pobudza indywidualną niezależność do poziomu krwawego umysłu. Ta niezależność przyniosła zadziwiająco dobre innowacje, jak w czasach maszyn Lisp. Ta sama niezależność utrudnia również starania ożywienia dawnych systemów „wypaczania”. Zaden projekt „Lisp OS” nie zgromadził masy krytycznej od czasu upadku symbolika i LMI.

Jednym z efektów tych działań drugorzędowych i trzeciorzędowych jest to, że nawet jeśli Lisp jest językiem najbardziej wyraziste kiedykolwiek tak, że teoretycznie jest to niemożliwe, aby język bardziej wyrazisty, Lisp będzie jeszcze wiele nauczyć od innych języków programowania. Chłopaki Smalltalk nauczył wszystkich – łącznie Lisp hakerów – to i owo na temat programowania obiektowego. Czysty język programowania, a Mozart/Oz kombi może mieć kilka niespodzianek własnych.

Klątwa Lisp nie zaprzecza maksymę Stanislav Datskovskiy: Pracodawcy wiele chętniej, że pracownicy być zamiennym, zamiast maksymalnie wydajne. Zbyt prawdziwe. Czy z wielkim trudem ktoś zdoła znaleźć miejsce w klasie menedżerskiej. Ostatnie linie jego eseju są jednak problematyczne. To znaczy:

Jeśli chodzi o świat „wolnego oprogramowania”, chętnie sprzeciwia się dogmatom przemysłowym w retoryce, ale wcale nie w praktyce. Żadna koncepcja odrzucona przez piekielne farmy kostek nigdy nie zyskała prawdziwej trakcji wśród mas amatorów.

W przypisie, że oferuje Linux jako przykład tego niechęć do wykonywania różnych pomysłów. Aby mieć pewność, że ma rację, jeśli chodzi o systemy operacyjne (najwyższy komentarz, w szczególności, jest irytująco rozwarty). Nie ma punktu, jeśli chodzi o języki programowania. Python i Ruby pod wpływem Lisp. Wielu fanów wyrazić szacunek dla Lisp, a niektóre z ich interesie spotęgowało Lisp renesans. Z pewnym sprawiedliwości, JavaScript został opisany jako „program w odzieży C za” pomimo pochodzące z tych piekieł gospodarskich sześcian.

Niemniej jednak, pomimo tych wpływów, zarówno w świecie korporacyjnym, jak i open source, Lisp wciąż ma tylko ułamek udziału umysłu dewelopera, który przyciąga obecna popularność zaawansowanych języków skryptowych. Zamknięty umysł MBA nie może być jedynym wyjaśnieniem tego. Klątwa Lisp ma więcej mocy wyjaśniającej.

Bezpłatne środowiska programistyczne dostępne dla Lisp są kolejnym przykładem klątwy Lisp.

To żenujące zwrócić na to uwagę, ale to musi być zrobione. Zapomnij o Lisp Maszynie; my nie mamy nawet systemy rozwoju, które pasują do tego, co przeciętny Smalltalk haker bierze za pewnik („Zawsze czułem, Lisp jest przełożonym język Smalltalk i jest przełożonym środowisko.” – Ramon Leon). Chyba płacą tysiące dolarów, Lisp hakerzy nadal tkwi z Emacsa.

James Gosling, autor pierwszych Emacs, które biegły na Uniksie, słusznie zauważył, że Emacs zasadniczo nie uległ zmianie od ponad dwudziestu lat. To dlatego, że opiekunowie Emacs nadal warstw kod szczycie konstrukcji, która została rozliczona z powrotem, gdy Emacs był projekt grad-student MIT AI Lab, czyli gdy rozwój Emacs nadal są pośrednio finansowane przez dług publiczny. Slashdotter mogą sprzeciwić że Emacs jest już dość zdolny i może nic zrobić, że każde inne środowisko programistyczne może zrobić, tylko lepiej. Ci, którzy korzystali Lisp maszyny powiedzieć inaczej.

Dlaczego więc hakerzy Lisp nie postawili facetów Smalltalk na swoim miejscu? Dlaczego nie stworzą darmowego systemu programistycznego, który przypomina niektóre utracone chwały LispM, nawet jeśli nie są w stanie odtworzyć kolejnego LispM?

Powodem, dla którego tak się nie dzieje, jest klątwa Lisp. Duża liczba hakerów Lisp musiałaby ze sobą współpracować. Przyjrzeć się bliżej: Duża liczba tego rodzaju ludzi, którzy stają się Lisp hakerów będą musiały współpracować ze sobą. I musieliby współpracować ze sobą przy projekcie, który od samego początku nie był dany. I nie byłoby żadnej zewnętrznej dyscypliny, takiej jak venture capital lub inny mistrz korporacyjny, aby utrzymać ich na drodze.

Każdy projekt ma tarcia między członkami, nieporozumienia, konflikty o styl i filozofię. Tym problemom społecznym przeciwdziała fakt, że żaden duży projekt nie może zostać zrealizowany inaczej. „Wszyscy musimy się trzymać razem, albo wszyscy będziemy wisieć osobno.” Ale ekspresja Lisp sprawia, że ta siła wyrównawcza jest znacznie słabsza; zawsze można rozpocząć własny projekt. Dlatego hakerzy indywidualni decydują, że kłopoty nie są tego warte. Więc albo wychodzą z projektu, albo nie dołączają do projektu na początku. To jest Klątwa Lisp.

Można nawet włamać Emacs, aby uzyskać coś, co jest wystarczająco dobre. Tak więc, Klątwa Lisp jest sojusznikiem Gorsze jest lepsze.

Ekspresyjna moc Lisp ma wady. Nie ma czegoś takiego jak darmowy przekąska.