Vlákno názorů k článku Common Lisp: žralok mezi programovacími jazyky od Pavel Křivánek - Na Common Lispu jsem měl vždy problém pochopit...

Na Common Lispu jsem měl vždy problém pochopit jednu podstatnou věc. Jedná se rozsáhlý, standardizovaný, velmi rychlý, průmyslově orientovaný, stabilní, dobře promyšlený, extrémně mocný, moderní a rozšířitelný jazyk. Proč se, sakra, nepoužívá tolik, jak by si zasloužil?

Viděl jsem na toto téma hodně diskusí, ale nemohu říct, že by mi jejich závěry přišly opravdu relevantní. Většinou to skončí u toho, že svádí programátora k překomplikovaně obecnému řešení místo toho, aby se soustředili prostě na vyřešení daného problému. Argumenty se závorkovým peklem není moc věrohodný, když algolovské jazyky jich mají obvykle stejné množství s výjimkou věcí, co řeší speciálními operátory.

Takže, prosím, zkuste odpovědět. Proč nepoužíváte Common Lisp? Já jej osobně nepoužívám, protože místo něj používám Smalltalk, ale vy ostatní omluvu nemáte ;-)

Common Lisp je jeden z mnoha programovacích jazyků, takže "správná" otázka by mohla znít, proč bychom měli používat zrovna tenhle. No ale OK, moje zkušenosti:

Když jsem se snažil si s CL hrát, byl prvotní problém právě v té mnohosti implementací, kterou zmiňuje autor článku. Mám používat CMUCL, nebo SBCL? Případně jiný?

Další problém byl ekosystém - knihovny a jak s nimi pracovat. Byly nějaké nástroje pro řešení závislostí, ale nedalo se to srovnat s "moderními" systémy typu npm a cargo a myslím, že ani s cabal/hackage.

Další problém byl v tom, že CL je jazyk, který umožňuje dělat všechno tisíci způsoby. Mně tohle nevyhovuje, z podobných důvodů mi nesedl Perl nebo C++. Prostě dávám přednost jazykům, které jdou cestou "ortogonality" a "idiomatičnosti", tzn. najít pokud možno nejvhodnější postup a držet se ho, pokud není zásadní důvod to udělat jinak.

Závorky jsou problém (pro mě), jelikož u jazyků, které mají (), [] i {}, se já osobně podstatně lépe vyznám v kódu. Možná to někdo má jinak, o tom se nemá smysl přít.

Takže, abych to shrnul - preferuju jazyky s "návodnou syntaxí", které mají kvalitní ekosystém, mně vyhovující komunitu, "one preferred way" pro konkrétní problém a jednu referenční implementaci, na kterou se komunita soustředí a rozvíjí ji. Common Lisp nemá ani jedno z toho.

Jen zareaguju na ekosystém + knihovny. V Common Lispu se totiž správa knihoven neprovádí na příkazovém řádku (typu pip install ...), ale přímo z REPLu - což ovšem znamená, že se mění spuštěná image Lispu. Tedy ještě jinak - můžu mít 100 běžících REPLů/image, každý s jinou sadou knihoven (takže se neřeší virtuání prostředí a další narovnáváky na ohýbáky).

Navíc je repositář knihoven v CL hodně podobný repositářím Linuxových dister - prostě cokoli se nainstaluje z daného obrazu, bude spolu kompatibilní. Ten repositář se buildí každou chvíli. A zase je to něco, co souvisí se stabilitou CL a jeho ekosystému.

To bych asi potřeboval nějak přiblížit, těžko se mi to představuje. Dělám větší aplikaci, potřebuju tam dát závislosti na knihovnách, knihovny se vyvíjejí. To znamená, že chci/potřebuju mít (já nevím) knihovnu pro AES ve verzi 3.x, knihovnu pro generátory pseudonáhodných čísel verze 2.x atd.

Uvolním to jako FOSS program, zveřejním na GitHubu, co má uživatel udělat, aby se mu to celé nainstalovalo a spustilo? Bude muset řešit nějaké REPL image a distribuce? V Rustu udělám cargo install MySuperApp a mám to tam. Případně udělám checkout z repozitáře, pustím instalaci z toho checkoutu a všechno by mělo jet. Je to podobné i v tom Common Lispu?

14. 4. 2022, 10:49 editováno autorem komentáře

Teď to hodně zjednoduším (a dá se to ohnout, ale popravdě to asi nikdo nedělá).

1. knihovny se až tak nevyvíjejí, že by něco rozbíjely, a když už, tak se mění i jejich závislosti a tranzitivní závoslosti (tedy celý strom)

2. v quicklispu se to (zjednodušuji) řeší tak, že se vydávají snapshoty knihoven, které se buildí spolu *

3. dá se vracet v čase dozadu na libovolný snapshot (http://blog.quicklisp.org/2011/08/going-back-in-dist-time.html), ale prostě CL ekosystém je trošku jiný - věci jsou stabilní (v řádu let, i desítek let), takže to (IMHO) zase tak moc potřeba není.

* To není nic nového, má to prakticky každý jazyk, který má "battery included". Například v Pythonu 3.8 se asi dá nějak vrátit k implementaci řekněme Deque z verze 3.6, ale asi se dost věcí rozbije. Nemluvě o snaze vrátit nějakou knihovnu v Java stdlib například (zase, dá se znásilnit classloader, ale to si koleduje o problémy).

Mnohost implementací snad nemůže být zásadní problém. Po každý úspěšnější jazyk, který má jednu standardní implementaci, se brzy objeví další alternativní implementace (viz třeba Python). Kdo by preferoval vendor lock-in? Pro některá nasazení můžete chtít implementaci s komerční podporou.

Dělání věcí tisíci způsoby je spíše kulturní problém než problém jazyka. Třeba zmíněný Smalltalk je také velice tvárný metajazyk, ale o něco víc zaměřený na kulturu nástrojů, takže se programátoři většinou vyhýbají větším zběsilostem, protože by se o možnost používat tyto nástroje nad svým programem ochudili nebo si dokonce znefunkčnili vývojové prostředí.

Hm, tak konkrétně pro Python sice existuje dost alternativních implementací (IronPython, Jython, samozřejmě PyPy, RustPython, Stackless...), ale stejně se pořád bere, že CPython je "ten" Python. Vendor lock-in ve světě OSS snad nehrozí.

Jinak, co se týče "kultury jazyka", tak ano, dá se nastavit v rámci třeba firmy nebo týmu. Ale některé jazyky (a jejich komunity) tu "hravost" berou jako plus, mě to tak moc nebere (v praktické aplikaci).

CL používám jako první volbu tak kde něco řeším (třeba jednorázově) sám, ale jsou chvíle kdy si to rozmyslím, a umím si představit že někoho to otráví už při prvním setkání:

Do té doby než vznikl quicklisp byly knihovny a závislosti problém, s tím souhlas s předchozí reakcí. Teď je mnohem jednodušší knihovny získat, ale pořád - pokud chci něco specifického tak si to často musím dopsat sám (za poslední půlrok třeba alpn v ssl, nebo api na secret service). Pozitivní je že to většinou je na hranici triviality, ale některé věci bych asi psát nechtěl.

Doteď je opruz nasadit CL kód tam kde jsou jiné jazyky podporovány out of the box - Heroku se dalo, ale třeba Azure funkce bych se musel namáhat.

A taky se dvakrát rozmyslím než použiji CL řešení tam kde čekám že to bude za měsíc debuggovat někdo jiný (protože lidi).

A zatímco IDE v emacs (slynk, sly) jsou prvotřídní, tak si nejsem jistý jaký je komfort programování mimo emacs. Já jsem kvůli tomu na emacs před lety přešel, ale ne kažý chce.

Jinak díky autoru za článek, i když spousty oblastí se mohl jen dotknout. Snad jen možná není úplně vždy vidět co je vlastnost Common Lispu jako standardu, a co je sbcl specifické (třeba tvorba binárky - a mimochodem pod "překladem do nativního kódu" jsem čekal spíš výstup disassemble té faktorial funkce).

"Doteď je opruz nasadit CL kód tam kde jsou jiné jazyky podporovány out of the box"

Sice nedělám s Common Lispem, ale s jazyky, které se taky překládají do spustitelného kódu a tahají si s sebou celý runtime (Go, ale vlastně i Rust). A zrovna toto je naopak řešení, které se hodí do světa Dockeru a Kubernetes. Prostě vezmu nějakej minimální systém, ať již Alpine (to nepoužíváme) nebo ten RHtí minimal image a do toho se hodí další layer s binárkou aplikace. Nic dalšího, bo konfigurace jde přes env. var.

Neřešíme tedy, jaká verze Pythonu nebo kdovíčeho v tom imagi je, všechno aplikačně-specifické je v té jediné binárce.

To s tou binárkou je dobrý nápad. Vrátím se k tomu u části s datovými typy, to je IMHO hodně dobrá vlastnost CL.

Takže bude díl o Lispu+assembleru, tím odradíme zbytek čtenářů :-p

Moje subjektivní hodnocení/volba - ano v IT se dost často skočí na "jednoduchém" vyřešení problému (třeba volbou v té době populárnějšího jazyka nebo řekněme operačního systému, který má pěkná vokýnka, ale jinak je to děs a hrůza), aby se nakonec řešily narovnáváky na ohýbáky, když se zjistí limity (nebo někdo jiný řekne, že jsou tam limity a donutí vás ke změně).

Simple != Easy

Jinak v profesní praxi jsme skončili u Go, protože mj. je pro daný obor dobře postaveno a navíc na to dokážu sehnat vývojáře. A když ne, tak už jsme přeučili pár Pythonistů, a to rychle. Být to v US, tak by možná i šel Common Lisp (tam má přece jen větší zastoupení na univerzitách), ale tady moc ne (mám lidi ze Španělska, Itálie, ČR/SR, UA, takže to není jen čístě ČR podivnost).

A jasně, je to jazyk s jedinou cestou, jak psát, žádné velké rozlety se nedají čekat.

Trošku OT: zrovna včera jsem se musel smát tomu, že někdo vymyslel další jazyk na zápis konfigurace (cue) s podtextem "Escape YAML hell". Takže jsme tady měli vývoj XML -> XML s ohýbáky typu podmínky a proměnné (Ant) -> JSON -> YAML -> YAML s ohýbáky typu podmínky a proměnné (v řetězcových hodnotách!) -> Cue. Kdo zůstal u s-výrazů (já používám EDN), tak toto fakt neřeší prakticky celej profesní život.

Také mi jsou v tomto kontextu nejsympatičtějši s-výrazy.

Má omluva je, že místo něj používám Typescript :-D

V tom vašem výčtu chybí dvě velmi důležité vlastnosti, které spolu volně souvisí:

1) Statické typy. Zrychlují vývoj tím, že odchytávají chyby už ve fázi kompilace, respektive s IDE už ve fázi psaní, umožňují napovídání v IDE (další zrychlení vývoje). Dělat větši refaktoring bez podpory typování musí být peklíčko. Atd.

2) Čitelnost. Pro projekty ve více lidech, případně (netriviální) takové, kdy se k programu vracíte po delší době opět kritická vlastnost. Samozřejmě jako člověk, který v LISPu nikdy pořádně nedělal mohu být zaujatý, ale ta výtka zaznívá hodně často, takže na ní něco bude. Jednak k tomu IMO moc nepřispívá prefixová notace. A pak ty závorky. Když si vezmu jednoduchý příklad z tutoriálu LISPu:

(defun fib (n)
"Return the nth Fibonacci number."
(if (< n 2)
n
(+ (fib (- n 1))
(fib (- n 2)))))


Třeba v Typescriptu by to bylo nějak takhle:

// Return the nth Fibonacci number
const fib = (n: number) => n < 2 ? n : fib(n - 1) + fib(n - 2)


TS verze obsahuje troje (jednoduché) závorky. LISP jich má celkem devatero a navic dosahuje až pětinásobného vnoření (sic!)

Plus s jazyky jako / přístupem LISPu mám tu zkušenost, že jejich zápis je poměrně elegantní, dokud člověk implementuje něco, co je "čisté matematické" řešení. Jenže reálná zadání mají "chlupy", různé specialitky, zvláštní případy, takže kód se komplikuje, není zdaleka tak elegantní a tam jsou pak tyhle jazyky naopak méně čitelné. "Klasické algolské" jazyky jsou v těchhle případech tak nějak přímočařejší a tedy ve výsledku čitelnější. (Ale tohle těžko to nějak objektivně dokazovat, je to můj subjektivní dojem.)

Je to hodně OT, ale je fakt řešení Fibonacciho posloupnosti korektní nad typem "number"?

Jinak nejelegantnější řešení Fib. posloupnosti je přes pattern matching (vůbec většina if-ů je násilné použití techniky určené na něco jiného).

Common Lisp má také volitelné statické typování jako TypeScript.

Příklad s Fibbonacciho posloupností je jeden z těch, které používají hodně infixových operátorů, což pro běžný kód není typické (a tam, kde je to problém, se dá použít makro umožňující zápis infixovou notaci). Netvrdím, že Common Lisp je jazyk s nejčitelnějším zápisem (i když hodně záleží na zvyku), ale udělal zde ústupky, které mu umožňují věci jinde nemyslitelné. Dobře faktorizovaný kód bude čitelný vždy.

Jak moc pokročilé to statické typování je? Vím o tom, že šlo deklarovat primitivní typy (32-bitový int apod.), ale umí to dejme tomu v rozsahu aktuálních možností typových anotací v Pythonu?

Pokud vím, CL preferuje pro složitější věci dynamické typové kontroly, jejichž zápis definuje standard jazyka. Jak moc je dokáží využívat současné nástroje pro statickou analýzu, nevím.

Zkuste v Typescriptu s nativnim typem number (a nejakou efektivnejsi implementaci fib) spocitat fib(1000). V Common Lispu aspon dostanete spravny vysledek.

Hlavni featura (Common) Lispu jsou makra, prace s kodem jako s daty. Na takovem malem prikladu se toho moc nepredvede.

Pro zajimavost v Clojure jde (efektivne) fibonaciho posloupnost spocitat takto.

(def fibs (lazy-cat [0 1] (map +' fibs (rest fibs))))

(nth fibs 1000)

14. 4. 2022, 10:39 editováno autorem komentáře

1) Ne peklíčko, ale peklo jako kráva. Kdo někdy něco psal v Node.js, tak ví (pokud se z toho nezbláznil).

2) Subjektivně bych řekl, že ani ten Lisp, ani TS nejsou moc čitelné. Osobně mi vyhovuje styl jazyků jako ML, Haskell nebo PureScript (asi to je pattern matchingem).

Pretoze po nom nie je dopyt a vyvojovy ekosystem je maly. Ale je velka skoda, CLOS a defgeneric su velmi uzitocne koncepty. Nezaoberal som sa s nim dost dlho na to aby som dokazal povedat ci zatvorky su alebo nie su problem, nikdy mi nestihli vadit, ale trochu to vyvolavalo zvlastne pocity. Takisto z makier sa vie zatocit hlava, ale ako vravim, neviem ci sa to da skusenostami prekonat alebo ci vacsina programatorov je na dostatocnej urovni aby to zvladla. Podobne som to mal aj s Haskellom, na ten som nemal ani dostatocnu motivaciu.

Podobná makra jsou v Rustu a Julii, myslím, že většina je zvládne.

Haskell má pověst akademického jazyka, ale koho zajímá FP, může zkusit třeba Purescript.

Navíc PureScript dělá dokonce i pár věci lépe než Haskell :D

Co třeba? Já ho nijak zvlášť podrobně neznám, tak se rád dozvím něco nového.

Pharo nebo Squeak?

Pharo