ECLM 2008

  • ECLM 2008 w Amsterdamie: 16 godzin w jedną stronę pociągiem, 8 godzinnych wystąpień, 96 miłośników lispa z 17 krajów, 3 przedstawicieli naszego kraju: Maciek (of CL-Librarian fame), Daniel (of Poliqarp fame), oraz niżej podpisany.
  • Nie piszę dokładnego sprawozdania: już ubiegł mnie Daniel. Ograniczę się do kilku luźnych uwag.
    • Wystąpienie Stefana Richtera z freiheit.com technologies gmbh (Hamburg, Niemcy), Using Common Lisp for large Internet systems to był najprawdziwszy HUD (pozytywny, pro-lispowy odpowiednik FUD. O ile uwagi odnoszące się do architektury umożliwiającej tworzenie skalowalnych serwisów internetowych były ciekawe i sensowne, o tyle już podawanie Weblocksów jako przykładu frameworku sieciowego, który ma się łatwo skalować jest nieporozumieniem.
      • Webclocksy, choć strasznie fajne, opierają się na kontynuacjach (zaimplementowanych w cl-cont) i domknięciach. Dopóki nie będzie dobrej (czyli taniej i szybkiej) metody serializacji i deserializacji domknięć i kontynuacji, dopóty Weblocksy będą ograniczone do jednego obrazu lispowego. Choć oczywiście można kombinować (sticky sessions i takie tam), skalowanie Weblocksów nie wydaje się trywialne.
      • Z drugiej strony, chciałoby się, aby jak najwięcej tego HUD-u dotarło do głównego nurtu IT. Z tego, że Stefan podaje kiepskie przykłady nie wynika przecież, że Common Lisp per se źle się skaluje. Stefan ma spore doświadczenie jeśli chodzi o duże aplikacje internetowe: freiheit.com robiła m.in. księgarnie internetowe libri.de i buch.de, więc jego sympatia wobec Common Lispa powinna stanowić pewien argument dla firmy rozważającej jego użycie. (Przemilczałbym, że freiheit.com większość swoich projektów pisze póki co… w Javie, gdyby mnie sumienie potem nie gryzło.)
    • Bardzo ciekawie mówił Juan José García-Ripoll, autor ECL. Mimo słówka embedded w nazwie, ECL jest pełnoprawną, zgodną ze standardem implementacją Common Lispa.
      • Kompilacja do C i łatwiejsze korzystanie z bibliotek napisanych w tym języku to jest coś. Szczególnie w świecie, który zdaje się nieszczególnie przychylny aplikacjom czysto lispowym.
      • Wyjątkowo interesującym projektem jest XEmacs z osadzonym ECL-em. W pierwszej fazie pozwoliłoby to pisać dla niego rozszerzenia nie tylko w Emacs Lispie, ale również w Common Lispie. W drugiej fazie Emacs Lisp mógłby zostać przez Common Lisp całkowicie zastąpiony. Czy nie wydaje się to Wam piękne? Emacs, nie dość, że CL-owy, to jeszcze z rozszerzeniami kompilowanymi do kodu maszynowego! (Osobiście wolę Emacsa od XEmacsa, ale w takiej sytuacji nie zastanawiałbym się długo nad przesiadką.)
      • Juan wydawał się dość mocno zasmucony niewielkim zainteresowaniem ECL ze strony użytkowników. Cóż, prawda jest taka, że ECL nie należy do bestyjek łatwych w obsłudze (nieraz już sama instalacja przysparza kłopotów). Jednak warto się ECL-em zainteresować. Odnoszę wrażenie, że Juan tak się ucieszy z objawów zainteresowania projektem w postaci zgłoszonych problemów, że będzie je bardzo szybko poprawiał, a ECL stanie się łatwiejszy w obsłudze. Daniel zgłosił mu problem z kompilacją jeszcze na kolacji…
    • Bardzo podnoszą na duchu dwie lispowe sucess stories.
      • InspireData, czyli narzędzie dla szkół średnich do wizualizacji danych, doskonale się sprzedaje i robi naprawdę świetne wrażenie. Choć raczej nie należę do grupy docelowej produktu, sądzę, że w niektórych sytuacjach skorzystanie z niego byłoby nie bez pożytku.
      • Norweski House Designer służy z powodzeniem tamtejszym architektom do walki z uporczywymi błędami, powtarzającą się pracą i zmieniającymi się regulacjami prawnymi (w końcu to Skandynawia). Architekt dostarcza programowi szkic budynku, a program już zadba o ilość i rozmieszczenie kontaktów, okna, czy po mieszkaniu da się poruszać na wózku inwalidzkim, itp.
        • Co ciekawe, decyzję o użyciu Common Lispa przeforsował w latach dziewięćdziesiątych zarząd firmy, mimo zdecydowanego oporu programistów (!). Pozostałością po owym pierwszym buntowniczym zespole są użycia 'yes i 'no zamiast t i nil, pozostawione w niektórych miejscach kodu z powodów sentymentalnych. A może jako memento?
    • Trochę zawiodło mnie wystąpienie Kenny’ego Tiltona. Owszem, było śmieszne (na całe szczęście, ponieważ poprzednie wystąpienie było niestety nudne jak diabli), choć z powodu dygresji (dość zabawnych) nie zdążył powiedzieć zbyt dużo o właściwym temacie prezentacji, czyli o Cells.
  • Konferencje na temat niezbyt popularnych języków programowania to nie tylko wystąpienia: to także możliwość poznania środowiska. Pod tym względem ECLM2008 nie zawiodło. Można było pogadać z Edim Weitzem, Danem Weinrebem (założycielem Symbolics), Marco Baringerem (nb. nie spodziewajcie się sensownej dokumentacji do UCW w najbliższym czasie)... A także poznać chorwackich hackerów Lispa, lub hackerów Dylana.
  • Konwencję pisania w punktach bezczelnie zgapiłem od netto. Choć przed netto już tak pisał Wittgenstein (ale on bloga nie prowadził).
  • Na koniec metauwaga: pogłoski o śmierci tego bloga są mocno przedwczesne (choć niewątpliwie uzasadnione). W najbliższym czasie postaram się poświęcać mu trochę więcej uwagi.

Komentarze do notki ECLM 2008

  1. coldpeer powiedział(a):

    Co do CL w XEmacsie to muszę powiedzieć, że mnie zaciekawiłeś tym

  2. nablaone powiedział(a):

    IMHO, z ECL+Emacs będzie ten sam problem co z climacsem, nie będzie mocy aby przepisać te wszystkie biblioteki na CL.

  3. Ryszard Szopa powiedział(a):

    Właśnie dlatego mądry jest pomysł, aby w pierwszej fazie był dostępny zarówno interpreter elispa, jak i ECL. To by pozwoliło pisać nowe aplikacje w CL, nie rezygnując z całej tej masy kodu już dostępnego w tej chwili. Sądzę, że sporo ludzi chętnie by pisało w cl (nie bez powodu popularny jest (require 'cl)).

  4. Ryszard Szopa powiedział(a):

    Poza tym, w przeciwieństwie do climacsa, XEmacs zdaje się przynajmniej działać :P

  5. jwr powiedział(a):

    Nie rozumiem dlaczego uważasz, że Weblocks się nie będzie skalować. Całą właśnie zaletą weblocks jest to, że kontynuacje są ograniczone i nikt nigdy nie planował ich serializować ani przechowywać dłużej, niż jest to niezbędne. To pierwszy lispowy framework z tak sensownym podejściem.

    Co do ograniczenia do jednego obrazu — oczywiście, ale też nie widzę czemu to jest problem. I tak z reguły pojedynczą sesję użytkownika dowiązuje się do jednego serwera, load-balancing robiony jest między sesjami.

  6. Ryszard Szopa powiedział(a):

    A co z akcjami? Skutki uboczne akcji nie muszą być ograniczone do sesji (ZTCP dowolna lambda może być akcją), ale siłą rzeczy nie są w stanie oddziaływać poza obraz lispowy. Wyobrażam sobie dość upiorne błędy typu akcja która wpływa na wszystkie i tylko te sesje, które się znajdują na tym samym serwerze. Oczywiście, da się temu zapobiec dbając o to, aby akcje miały skutki albo lokalne dla sesji albo w bazie danych… Poza tym, w scenariuszu pesymistycznym może być tak, że dużo „cięższych” sesji ląduje nam w jednym obrazie, a my nijak nie potrafimy tego rozłożyć. Oczywiście, być może moje obawy wynikają z tego, że Weblocks pozwala bardzo łatwo robić rzeczy, które w innych frameworkach (myślę o Pylonsach i Django, bo w nich coś więcej robiłem)byłyby bardzo trudne, więc jest więcej okazji, aby strzelić sobie w stopę.

    Poza tym, z prezentacji Stefana Richtera wynikało, że sticky sessions są tą gorszą metodą load balancingu, którą należy zastąpić memcached i innymi fajnymi rzeczami (stąd się nb. wziął pomysł aby serializować kontynuacje), a Weblocks było podane jako przykład frameworku, który się doskonale nadaje do tych fajnych metod. Co moim skromnym zdaniem nie jest prawdą.

    By zreasumować moje stanowisko:

    • Nie twierdzę, że Weblocksy w ogóle nie skalują, lecz że nie skalują wedle metod proponowanych przez Stefana Richtera.
    • Skalowanie Weblocksów, przynajmniej od pewnego momentu (SR mówił o aplikacjach na miliony użytkowników) wciąż nie wydaje mi się trywialne.

    (Oczywiście, fajnie by było, gdyby slajdy z prezentacji były gdzieś udostępnione i można się było do nich wygodnie odnosić... Próbowałem poprosić o to Stefana w komentarzu na jego blogu, ale niestety nie potrafię przejść obrazka antyspamowego.:/)

  7. jwr powiedział(a):

    Zgadzam się, że dowolny framework oparty na kontynuacjach nie będzie pasował do memcached. Wcale jednak nie uważam memcached za sensowne rozwiązanie :-)

    Co do skalowania weblocks, może warto spojrzeć ogólniej na problem skalowania aplikacji WWW. W dowolnej aplikacji, która wyrośnie poza jeden image lispowy musi istnieć coś współdzielonego: RDBMS, serwer(y) backendowe — coś gdzie mieszka współdzielony stan. Jeśli już mamy to coś, to po pierwsze, problem dowiązywania sesji do konkretnych frontendow staje się mało istotny (bo zawsze sesje się jakoś rozłożą), a po drugie, tak czy siak nie możemy traktować kontynuacji jako jedynego narzędzia do zarządzania stanem aplikacji (takie podejście było w UCW i nijak się nie skaluje).

    Kontynuacje w weblocks używane są do zarządzania przepływem kontroli w pojedynczej sesji — do tego nadają się świetnie i niespecjalnie moim zdaniem ma to związek z wydajnością.

    Oczywiście skalowanie do milionów użytkowników nigdy nie jest trywialne :-)

  8. Nathell powiedział(a):

    a UCW właśnie zmartwychwstało – przyszedł Drew Crampsie i powiedział, że chce się nim zająć :)

  9. reverse phone powiedział(a):

    I really like your wp web template, wherever do you find it through?

Dodaj komentarz: