Názory k článku Common Lisp: žralok mezi programovacími jazyky

Skvely clanek, zajimave tema.

Na muj vkus Common Lisp trochu naduziva makra.

Mate subjektivni nazor na Common Lisp vs Clojure ciste jako jazyk, bez ohledu na JVM?

Za me, nejpouzitelnejsi Lisp je asi Clojurscript, diky soucasne popularite Javascriptu. Nelze cekat vznik ciste lispovskeho ekosystemu knihoven velikosti srovnatelneho s mainstreamovymi jazyky, interop s jinymi jazyky je dobra cesta.

Takto - skalni CLisperi casto rikaji, ze Clojure ma "moc syntaxe". Me se na Clojure libi ten funcionalni pristup, jenze zase to nekdy vede k divnemu kodu (nekde mam par ukazek, ktere jsem nedokazal rozumne vyresit ciste funkcionalni cestou). Ale Richuv pristup k jazyku je konzistentni, akorat s nim uplne nesouhlasim s temi "VM jsou OS budoucnosti".

Za me by byl idealni jazyk jako Clojure (pekne konzistentni knihovny, sekvence, line vyhodnocovani by default, go bloky), ale tak rychle startujici jako CL, vcetne moznosti buildu binarek (tedy neco jako Bahashka, vlastne Bahashka + vlastni skript se k tomu dost blizi). Ale to je jak pises - problem neexistujiciho ekosystemu.

PS: zrovna CL makro Loop bych v Clojure bral, stavajici loop-recur je sice pouzitelne, ale okolo toho moc kodu navic :)

“nekde mam par ukazek, ktere jsem nedokazal rozumne vyresit ciste funkcionalni cestou”

To by mne docela zajímalo.

Jinak mně osobně se líbí přístup Idrisu, je sice funkcionální, ale umožňuje procedurální zápis (shodou náhod přes “do”, ale na rozdíl od Haskellu se nejedná o Kleisliho kompozici, skládání je mnohem volnější, a tedy procedurálnější). Ve spojení se “syntax extensions” ideální pro převážně funkcionální kód bez nepříjemných teoretických omezení.

Najdu. Jedno je z privatniho kodu, druhe potom transformace z AsciiDocu na DocBook. To druhe je nakonec funkcionalni, ale strasne hnusny. Jsem si myslel, ze to bude nejaky jednoduchy rekurzivni sestup, ale nakonec to mam plny ruznych corner casu (ma vlastne AsciiDoc gramatiku? :)

Něco jako gramatiku má :)

Obecne "in-place" algoritmy v cistem Clojure implementovat nejdou. Vetsinou to nevadi, jde vyuzit interop s javou/javascriptem.

Pokud maji knihovny a jazyk pouzivat stejny GC, jinak nez pres interop s vyssim jazykem nebo VM to asi nejde.

Co je Bahashka? Googlil som, ale nic som nenasiel.

ja to nasel primo tady na rootu (ale google nepouzivam, spis Duck duck go)

https://www.root.cz/clanky/babashka-interpret-clojure-urceny-pro-rychle-spousteni-utilit-z-prikazoveho-radku/

Babashka

https://github.com/babashka/babashka

Babashka is a native Clojure interpreter for scripting with fast startup. Its main goal is to leverage Clojure in places where you would be using bash otherwise.

Špatně to píšeš, je to ba-bash-ka.

16. 4. 2022, 07:11 editováno autorem komentáře

Babashka, omlouvám se za chibku.

Pred par dny vysel ClojureDart, sice je to v plenkach, ale binarku jsem z toho udelal a pomaly to neni. Pokud s tim kluci neprestanou, tak by to za par let mohl bejt hodne relevantni jazyk - kterej splnuje nektery zmineny predpoklady.

Pekne, diky za info

Tady je k tomu shrnutí a odkazy: https://www.infoworld.com/article/3657759/clojure-meets-dart-in-clojuredart.html

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

Články od Pavla Tišnovského jsou parádní a rád se vždy dozvím něco nového. Ale teď mne někteří (možná i mnozí) ostatní čtenáři ukamenují díky mému dotazu do pléna.
A dotaz je to prostý: k čemu je jazyk Lisp dobrý? Respektive, používá to vůbec někdo? Podívám li se do tabulky používaných programovacích jazyků třeba zde https://statisticstimes.com/tech/top-computer-languages.php tak nevím, prostě žádný Lisp tam nevidím :)

Různé jiné jazyky jeho dialekty používají pod pokličkou, třeba Idris má backend pro Racket, Chez a Gambit. Lisp měl také velký vliv na návrh jiných jazyků včetně některých nejmladších (Rust, Julia). Přímo se používá ve výuce, ale spíše v Americe, v Evropě šel vývoj jinudy.

"Přímo se používá ve výuce, ale spíše v Americe, v Evropě šel vývoj jinudy."

jj to je docela zajimavej rozdil. Tady se trosku preslapovalo na miste "diky" Pascalu, mam pocit. A funcko vubec se moc nevyucovalo, mozna ted je nekde Haskell, ale asi minoritne.

Haskell se celou dobu drží ve Spojeném království, jinak asi moc ne. Ale Francouzi mají zase “svůj” OCaml a jako kuriozitu zmíním jeden obskurní jazyk (nevím, jak se jmenuje, možná ani nemá jméno) z Krakova založený na čudné (nefregovské) logice Romana Suszky (rodák z Těšínska), který vymyslel specifický logický systém pro formalizaci Wittgensteinova traktátu, načež mu v tom divní lidé začali psát programy (podobně jako když Martin-Löf vymyslel formální systém pro popis konstr. matematiky a informatici z toho k jeho nelibosti vyrobili Agdu a Coq). Ostatně i Lisp vzniknul jako čistě teoretický popis matematických funkcí a McCarthy valil bulvy (“you're confusing theory with practice, this eval is intended for reading, not for computing”), když Russell napsal interpret.

Statistiky asi neber tak vazne, treba v Tiobe indexu je, dokonce kupodivu pred Fortranem a tesne za Rustem a Kotlinem (tolik k tomu, jak brat tu statistiku vazne).

Jenze to nic moc neznamena, protoze ta statistika neni odvozovana od toho, co kdo pouziva a kolik z toho vytezi $, ale spis na zaklade dotazu a google analytics. Tj. hodne se tam vysplhalo PHP nebo VB, ale asi to uplne moc nerika o realnem nasazeni v porovnani treba s tim, co vsechno pohani Fortran.

Za me je dobry kvuli tomu, ze jsem si na lispu/scheme konecne uvedomil, jak veci funguji. Je tam blizko k AST a semantice, taky homoikonicita dost pomaha k pochopeni cinnosti interpretru i prekladacu (ale v praxi pouzivame jine jazyky ;)

“jsem si na lispu/scheme konecne uvedomil, jak veci funguji. Je tam blizko k AST a semantice, taky homoikonicita dost pomaha”

Toto také vidím jako velkou výhodu.

Jednou za námi přišel známý a k pobavení všech znalých olbřímnosti tohoto úkolu sdělil, že má čtrnáct dní na to, aby se naučil Common Lisp + CLOS, protože začal pracovat v týmu, který ho používá. Jednalo se o systém z oblasti superpočítačů.

CL svoje přednosti ukáže nejvíce v oblastech, které se zabývají věcmi začínající prefixem meta- (přičemž mohou být stále silně praktické). Navíc, jeho alespoň pasivní znalost je nutná k pochopení některých důležitých aspektů programování (např. The Art of Metaobject Protocol).

Pokud se ho člověk detailně naučí, tak ho v ostatních jazycích asi máloco kdy překvapí (krom záliby mainstreamu v masochismu).

> Pokud se ho člověk detailně naučí, tak ho v ostatních jazycích asi máloco kdy překvapí (krom záliby mainstreamu v masochismu).

Není tohle zastaralý mýtus? Mně přijde, že v APL/J/K, Haskellu a jiných jazycích je dost konceptů, které okolo CL ani nešly. Silný typový systém jsme koneckonců nakousli a to zrovna asi taky nebude "reinvented Lisp" a o masochismu bych taky nemluvil.

To je dobrá poznámka. Lisp vycházel z netypovaného lambda kalkulu. Ve většině moderních jazyků je vidět souběh FP a silných typových systémů (paradoxně polymorfní lambda kalkulus je “backporting” myšlenek z CS).

Já myslím že to mýtus není. Ale těžko se to asi dokazuje. Přidám třeba zajímavé projekty co jedou na CL.
- https://www.grammarly.com/blog/engineering/running-lisp-in-production/
- https://www.youtube.com/watch?v=mbdXeRBbgDM

Já furt proč mi je jméno Steele tak povědomé, a on to jen jeden z návrhářů Fortressu.

Az doteraz som si myslel, ze ten Fortress mal byt nejakym revolucnym vylepsenim Fortranu. Ale ked na to pozeram teraz, tak Fortran vs Fortress mi pripada ako Pascal vs Ada, alebo Java vs Scala. Myslim, ze sa netreba divit, preco sa ten jazyk dalej nevyvijal - asi by sa nenaslo moc ludi, ktori by v tom chceli programovat.

Fortress přišel s několika revolučními vlastnostmi, které následně adoptovaly jiné jazyky, hlavně Julia a Rust.

Mam takovy dotaz, na tenhle clanek jsem narazil nahodou, marne hledam na netu a nechce se mi cely cist ..... respektive nechce se mi cist cely sto-dilny serial. Ale jak ctu takove veci jako Rust, Julia nebo Lisp ..... nutne cloveku vytane na mysl, proboha proc? K cemu? K cemu by neco takoveho mohlo byt dobre? Co se tim programuje? Kde je nejake realne nasazeni a vyuziti?
Priznam se, ze v dobe, kdy mame fakticke etalony v podobe nejpozivanejsich a univerzalnich prakticky na vsechno typu C#/JAVA jinymi slovy s C++ syntaxi, hardcore na opravdu low-level jako C nebo "detske" jazyky idealni pro zavedeni si extremne spatnych programovacich navyku jako treba Python a pak specialni typu SQL ..... ale k cemu je proboha jako LISP?:o) Jako da se v LISPu naprogramovat nejaka aplikace? Kde bezi? Jakoze nejaka elektrarna nebo co? Delaji se v tom specialni firmwary? To dost pochybuju. Unika mi jejich vyznam, krom historicke zminky. A neberte to ironicky, vzhledem k tomu, ze jsem tu nasel desitky (mozna stovky) velmi revrubnych clanku o LISPu, Rustu, Julia a patrne dalsich "podivnostech", tak me fakt zajima, jestli je autor masochista, ze pise o desitky let mrtvych vecech nebo to fakt k necemu je.

Asi je to častá otázka, i když netuším proč. Poslední pokus o odpověď co jsem potkal viz https://lisp-journey.gitlab.io/who/ a odkazane linky.

A co jsem párkrát viděl je prototyp v Lispu, a po finalizaci produktu přepis do "mainstreamového" jazyka (Reddit -> python a pod.)

..pretože napr. na takom Forthe (alebo teda Lispe) viete docela pekne pochopit ako funguju prekladače a všetky tie veci okolo toho. Ak s tym človek začne, nevie s tým prestať. V praxi take vedomosti nemusíte "využiť", ale rozhodne Vas to pozdvihne

“Ak s tym človek začne, nevie s tým prestať.”

Přesně tak.

Prectete si diskuzi, ta otazka tu padla.

Julia a Rust jsou vice nez zive a na vzestupu.

Rust a Julia jsou "podivnosti" a "desitky let mrtve veci"? Tak to jo

Proto se ptam.

Z pohledu vývoje jazyků jsou podivnosti spíše Java a C#.

Předpokládám, že si Lojza dělal nějakou podivnou legraci.

Sranda musí být :)

Ja mam porad za to, ze si tu nekdo dela srandu ze me. Koukam na nabidky prace, hledam projekty a nic ...... tak nekdo uvedte NEJAKY PRIKLAD!

Vzhladom k rozsirenosti tychto jazykov je jasne ze trafili velmi dobre a presne potreby ktore existovali a existuju pre dost velky typ aplikacii.

Ja furt nevim, jestli se jedna o nejakou promyslenou legraci a delate si ze me srandu. Jako beznym hledanim veci jako LISP, CLOJURE atd. jsem v IT nenasel JEDINOU pozici. Nejenom, ze nikoho neznam, ale nikdy jsem ani neslysel o cloveku, co by v tom programoval. Takze kvantifikace "dost velky typ aplikaci" me opravdu na prdel neposadi ..... ptal jsem se JAKE?

Ano, většinu, ovšem šlo o potřeby z doby před 25 lety.

LISP konkrétně nepoužívám, protože vyžaduju statické typování.

Ve všech svých projektech používám tyto jazyky:
Rust pro všechno svého, co má běžet zajímavě rychle (dříve jsem používal Haskell, ještě dříve C++).
Lua v případě nějakých dynamických podivností, ale postupně to opouštím.
PHP, Javascript na web, protože low-end hosting.
C#/Java/Python/PHP - když v tom má klient nějakou legacy věc (prostě práce pro peníze).

Proč nepoužívám C#/Java jako hlavní jazyky? Protože jsou blbé. Nedostatečný typový systém, ukecaná konzervativní syntaxe, runtime (studenej start). Když bych vážně uvažoval nad JVM, tak bych zkusil Kotlin, nebo Scalu, protože přidávají moderní vlastnosti v podobě lepších typů a syntaxe (zvláště ta Scala).

C++ nepoužívám, protože to v porovnání s Rustem je už zbytečné/neeko­nomické trápení. Přináší tolik zásadních výhod, že C++ je pro mě prostě mrtvá záležitost.

Tak ja hlavne C# (.NET), protoze ma obrovskou podporu, obrovsky framework (mozna nejvetsi), prijemne IDE, bezi bez nejakych zavislosti, rychly fakticky jako C++ (proto treba vyslovene nemam rad obskurnosti s JVM). A hlavne oproti C++ je "bezpecny", clovek nemusi resit resourcy atd. No, pak jeste trochu Python, protoze se ve firme pouziva, ale Python povazuju za novodoby mor, lidem akorat vnucuje spatne navyky a navic je to jazyk zcela na dve veci, pomaly jak cyp, protoze interpretovany, dynamicky typovany, coz je asi uplne nejvetsi zlo, co mohl kdy kdo vymyslet. Mel smysl tak pred 15ti lety, kdyz nebyl .NET Core a clovek potreboval neco v linuxu a nechtelo se mu votravovat s C++.

Nevim co beres jak nedostatecny typovy system:) Jak uz jsem psal, C# se (bohuzel) dost poperluje, takze tam jde delat vsechno (viz LINQ, coz povazuju za zrudnost) celkem jakoze jednoduse, vicevlaknove veci velice snadno, OOP, proste co si clovek vzpomene. Ale hlavne jazyk je tak silny jako komunita/framework .... pokud ma slaby framework, tak je to konecna. Pokud nema treba klienta pro DB a podobne, tak to muze byt skvely jazyk, ale ......

> Nevim co beres jak nedostatecny typovy system:) Jak uz jsem psal, C# ...

Buďme konkrétní.
1/ Chtěl bych vytvořit Enum, který má tři položky OK, Fail, FailWith(string). V Rustu, Haskellu, a dalších jazycích to je samozřejmost.
2/ Chtěl bych vytvořit funkci, která přijme hodnotu třídy Foo a nepřipustí Null. Jsem ochoten zkousnout, že mi to hodí runtime výjimku. (Snad v .NET 8) Nepřeložitelnost by samozřejmě bylo lepší (v jiných jazycích běžná věc).
3/ Chtěl bych, aby když udělám Enum, a dám tam switch, tak mě to upozornilo, že jsem nepoužil všechny varianty (v jiných jazycích běžná věc).
4/ Chtěl bych, aby když udělám metodu, která přijímá Potomka : Předka, tak dostala přednost před metodou, která přijímá Předka.
5/ Chtěl bych, aby u moderního jazyka se nepoužívali ve všech knihovnách a FW anemické objekty jako default a dokonce pro to byla syntaxe.
6/ Chtěl bych, aby to nešlo přeložit, když se změní signatura třídy knihovny, kterou používá knihovna, kterou používám.
A tak dále.
Tohle jsou takové ty trivialitky, které považuji za samozřejmost, a které C# deklasuje.

Samozřejmě beru, že kolegové v MS udělali s .NET ohromný kus práce. Je za tím ohromná komunita a vůbec. Nic to nemění na mém závěru, že je to bastl, který umí spoustu cinkrlátek, ale zásadní (typové) featury to nemá. Prostě zaspal dobu a můžou si s Go podat ruce.

Pises o enumu jako o necem posvatnem nebo mi prijde, ze nevis k cemu je enum. Jestli jsem to ad1) pochopil spravne, tak bys snad enumem chtel predavat nejakou hodnotu? Proto ten string v zavorce? Nebo to chapu spatne? Od toho snad neni enum ne? Ad2), od toho jsou nullable a non-nullable typy ne? Ad3), jako kam chces cpat jakysi switch? A pokud to chapu spravne, tak jen chyba programatora na kterou mozna upozorni compiler, pokud to nekdo povazoval za nutne, ale urcite ne jako warning, mozna jako tip/suggestion, kterych jsou po napsani par radku kodu, vzdycky tak desitky, aspon u me:o)
Ad4) to je snad dano jasne danymi OOP pravidly a pokud to chces nahodou jinak, tak to udelas jinak, nechapu problem.
Ad5) netusim o cem je rec. Ad6) opet zalezitost co potrebujes, tak pokud mas knihovnu a nedefinujes presne verzi, tak proc by to nemelo jit prelozit? To je naopak zadana vlastnost ne? A pokud ji zmenis, nemas ji podepsanou nebo nezmenis cislo verze, tak to prece nesouvisi s jazykem, ani nicim jinym. To je asi jako nadavat na textovy editor, protoze jiny proces mu muze smazat editovany soubor ...... je to proste vlastnost a pokud tomu chces predejit, tak to musis proste zaridit.

Jake spatne navyky Python "vnucuje"?

Hele, C# je pro spoustu použití "good enough"; pokud jsi spokojený, budiž Ti to přáno. Spousta lidí si totéž myslí o C, C++ nebo třeba i Pythonu. Smiř se s tím.

Ano, ostatně každý jazyk má svou vlastní hranici, do které je ještě “good enough”.

Zde autor - masochista :)

Jako vývojář, který profesně (tedy za peníze) už vystřídal přibližně deset programovacích jazyků (viz * a **) si víc a víc myslím, že nakonec hlavní důvod "proč LISP" velmi pěkně shrnul Thomas Kuhn:

Paradigm in science not only affects the way you look at the world but it affects the way you can look at the world.

K tomu je vhodné jen dodat, že LISP (tedy i Common Lisp) je nejenom multiparadigmatický jazyk, ale navíc se mnoho (většina?) paradigmat nejprve vyzkoušela právě v Lispu (důvody - homoikonicita, makra, manipulace s AST).

* pracoval jsem i v Clojure, to byla asi nejlepší zkušenost vůbec. Už jen kvůli komunitě okolo Clojure - naprostá většina těch lidí byla/je daleko přede mnou, takže člověk nezakrněl

** mnoho míst okolo Clojure/Lispu se nenabízí přes Linked In, resp. někdy nabízí, ale cesta k nim je krkolomnější... to je na delší povídání a toto vlákno se pro to vůbec nehodí