Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: balkovic 01. 11. 2025, 12:18:09
-
V diskusii pod jedným Tišníkovým článkom zaznelo niečo na spôsob, že prečo sa vlastne rieši python, keď tu už veľmi dlho máme lisp. Potom som tam napísal, že lebo funkcionálne programovanie a rekurzia, preto sa ujal python a nie lisp... A Tišník niečo na spôsob, že imperatívne programovanie je v lispe bežné a na školách sa práve tými rekurziami odradzujú študenti.
Ok, tak som si pozrel lisp-y. Existujú celkom slušné implementácie už aj Pre MS-DOS, čo by teoreticky bariéru pre vstup znižovalo. Sú moderné dialekty a runtimy Scheme/Racket (Racket má dokonca aj typovanú verziu) a potom máme SBCL, čo je slušná implementácia common lispu. Vedel by som si toto predstaviť aj v biznis prostredí.
Killer aplikácie poznám akurát Emacs, Maxima a hru Abuse, potom už nič :)
Otázka znie takto, že prečo sa to vlastne tak málo používa, keď lisp má za sebou dlhú históriu a je to veľmi schopný jazyk/rodina jazykov?
-
<troling>
Lisp sa pouziva hlavne na trolenie v IT forach.
</troling>
-
Uživatelé bývají vyděšeni z množství závorek, i když jich bývá méně než v podobném programu napsaném v jiném jazyce.
Zajímavou a rychlou implementací je GNU rep, který se hodí jako generátor čehokoli, třeba webstránek nebo skriptů v jiných jazycích. Dnes se věnuji spíš XML a XSLT, ale podobné aplikace jsem dělal i v Lispu, který je o něco stručnější. XML je zase lepší na provázání s okolním světem a lépe pracuje se znakovými sadami.
Lisp je prostě starší jazyk a je z části nahrazen moderními jazyky. Poslední slovo však ještě neřekl, měl by ho umět každý programátor.
-
Ok, tak som si pozrel lisp-y. Existujú celkom slušné implementácie už aj Pre MS-DOS, čo by teoreticky bariéru pre vstup znižovalo. Sú moderné dialekty a runtimy Scheme/Racket (Racket má dokonca aj typovanú verziu) a potom máme SBCL, čo je slušná implementácia common lispu. Vedel by som si toto predstaviť aj v biznis prostredí.
Killer aplikácie poznám akurát Emacs, Maxima a hru Abuse, potom už nič :)
Short answer: Tak si to po sobě přečtěte. Máte před sebou někoho, kdo by si to rád někdy až se bude nudit vyzkoušel, máte cca. večer k tomu, aby si zkusil nějakou kravinu při které ho to chytne tak, že v tom bude pokračovat, a napíšete to takhle, že to odradí i assemblerem odkojené mazáky. :)
Ne vážně, zkuste napsat (nebo dát link, určitě existuje) nějaký stručný článek s motivací, proč by to člověk zkusit měl. Třeba ten zmíněný Python, i když má miliardy problémů (ne jazyk jako takový, ale ekosystém kolem a zpětná nekompatibilita z něj dělá naprosté peklo), tak by se dalo říct, že se stal prostředkem lepení binárních kusů kódu, které něco dělají v jednom z nejslibnějších oborů současnosti, takže přes vytrvalé nadávání se hodí se s ním seznámit.
-
Není to taková sláva, jak se někteří tváří. Nepřináší nic moc navíc, jen problémy.
-
Není to taková sláva, jak se někteří tváří. Nepřináší nic moc navíc, jen problémy.
Problémy s Lispem nebo s Pythonem? Jaké problémy?
-
Není to taková sláva, jak se někteří tváří. Nepřináší nic moc navíc, jen problémy.
Problémy s Lispem nebo s Pythonem? Jaké problémy?
Nevlídná syntaxe, horší infrastruktura, méně knihoven. Tu první otázku nechám bez odpovědi, bylo by to nedůstojné řešit.
-
Otázka znie takto, že prečo sa to vlastne tak málo používa, keď lisp má za sebou dlhú históriu a je to veľmi schopný jazyk/rodina jazykov?
Oblíbenost a rozšířenost technologií nemá nic společného s tím, jak jsou schopné nebo s kvalitou.
Zrovna třeba Python je dosti složitý jazyk a stejně se doporučuje jako jazyk na začátek nebo jako jednoduchý jazyk. Tzn., že to, co lidé tvrdí nebo domnívají se, nemusí být pravda.
Jeden z problémů Lispu bylo IMO to, že špičkové implementace byly často komerční - jako třeba Allegro.
-
Short answer: Tak si to po sobě přečtěte. Máte před sebou někoho, kdo by si to rád někdy až se bude nudit vyzkoušel, máte cca. večer k tomu, aby si zkusil nějakou kravinu při které ho to chytne tak, že v tom bude pokračovat, a napíšete to takhle, že to odradí i assemblerem odkojené mazáky. :)
Ne vážně, zkuste napsat (nebo dát link, určitě existuje) nějaký stručný článek s motivací, proč by to člověk zkusit měl. Třeba ten zmíněný Python, i když má miliardy problémů (ne jazyk jako takový, ale ekosystém kolem a zpětná nekompatibilita z něj dělá naprosté peklo), tak by se dalo říct, že se stal prostředkem lepení binárních kusů kódu, které něco dělají v jednom z nejslibnějších oborů současnosti, takže přes vytrvalé nadávání se hodí se s ním seznámit.
Nebolo ani mojim cieľom niekho motivovať k používaniu lisp-u. Ani v ňom neviem programovať. Jediné že som si dal vyrobiť pár demonštračných príkladov v Chatgpt a tie boli až podozrivo dobre pochopitelné.
Štandardná cesta k učeniu sa programovania je taká, že ponúkneš začiatočníkom nejakú zaujímavú blbostičku a na tej vysvetľuješ koncepty. Napríklad animácia panáčika, rotujúca kocka atď. Lisp uznám, že keď otvorím knihu tak začnú štruktúrovaným programovaním, alebo rekurziou ... Ako sú to dôležité veci, ale 6 ročnému mne by to nepredali.
-
Jeden z problémů Lispu bylo IMO to, že špičkové implementace byly často komerční - jako třeba Allegro.
To je dobrý dôvod.
-
Není to taková sláva, jak se někteří tváří. Nepřináší nic moc navíc, jen problémy.
Problémy s Lispem nebo s Pythonem? Jaké problémy?
Nevlídná syntaxe, horší infrastruktura, méně knihoven. Tu první otázku nechám bez odpovědi, bylo by to nedůstojné řešit.
Tak pokud ti Python nevyhovuje, používej jiný jazyk. Je jich dost.
O nevlídnosti syntaxe Lispu se nedá mluvit. Je totiž až směšně jednoduchá, jednodušší to snad už nejde. Knihovny jsou, ale programátor si zpravidla navrhne svůj jazyk nad Lispem, ve kterém si pak napíše zbytek aplikace. Pokud nevíš, co je CAR a CDR, tak asi netušíš, o čem je řeč.
-
Jeden z problémů Lispu bylo IMO to, že špičkové implementace byly často komerční - jako třeba Allegro.
To je dobrý dôvod.
To byl dobrý důvod. Dnes je částečně freeware.
-
Tady byl zase nekdo liny....
That’s a great question — and one that has puzzled programmers for decades! Lisp (especially Common Lisp and Scheme) is a powerful and influential language, yet it’s remained niche. The reasons are mostly historical, cultural, and practical rather than technical.
Here’s a breakdown of why Lisp isn’t more popular today:
1. Syntax that’s too unusual
Lisp’s prefix notation and heavy parentheses are very different from the C-like syntax that dominates programming (C, Java, Python, JavaScript, etc.).
This makes Lisp look “weird” or “old-fashioned” to newcomers, even though its syntax is actually simple and uniform.
Example:
(mapcar #'(lambda (x) (* x x)) '(1 2 3 4))
looks strange compared to:
[x*x for x in [1,2,3,4]]
2. Tooling and ecosystem
Modern developers expect polished IDEs, package managers, documentation, and big standard libraries.
Lisp’s ecosystem is fragmented (Common Lisp, Scheme, Clojure, Racket, etc.) and lacks a unified “standard library culture.”
By contrast, Python, JavaScript, and Java have massive, well-maintained ecosystems.
3. Fragmentation
Lisp isn’t one language but a family: Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, etc.
Each has different semantics, tooling, and communities. This fragmentation makes it harder for a single Lisp dialect to dominate.
4. Industry momentum
Lisp had an early boom (AI research in the 1970s–80s), but the AI winter and collapse of Lisp machines in the 1980s killed its commercial momentum.
By the 1990s, C, C++, and Java were already entrenched in universities and industry, and Lisp was relegated to academia and enthusiasts.
5. Metaprogramming is overkill for most developers
Lisp’s greatest strength is its macro system and homoiconicity (code = data). But many developers don’t need or understand the power of macros.
For everyday scripting, web dev, or data analysis, Python and JavaScript are “good enough” and simpler to learn.
6. It did win in spirit
Even if Lisp isn’t widely used, its ideas permeate modern languages:
Garbage collection → Java, Python
REPLs → Python, Ruby, Clojure
First-class functions, lambdas → pretty much everywhere
Functional programming → mainstream now (via JavaScript, Scala, etc.)
Macros influenced Rust and Julia.
So, Lisp lost the popularity contest but won the intellectual war.
It’s like Latin: not spoken much anymore, but its DNA runs through everything.
-
Pokiaľ ide o učenie sa, už som to tu niekoľkokrát vylepil:
How to Design Programs na https://htdp.org/
Sú tam síce použité špeciálne jazyky na vyučovanie, ale ich základom je Racket.
-
By the 1990s, C, C++, and Java were already entrenched in universities and industry, and Lisp was relegated to academia and enthusiasts.
Co to je za větu? Java byla na univerzitách a Lisp v akademii? Není to to samé?
Each has different semantics, tooling, and communities. This fragmentation makes it harder for a single Lisp dialect to dominate.
Ale to je stejné i u ostatních C-like jazyků. Jaký je rozdíl?
Modern developers expect polished IDEs, package managers, documentation, and big standard libraries.
Hodně nových jazyků má malou standardní knihovnu. Třeba Rust tam nemá ani generátor náhodných čísel. JavaScript podobně.
A co chybí v IDE u lispovských jazyků?
-
Tady byl zase nekdo liny....
That’s a great question — and one that has puzzled programmers for decades! Lisp (especially Common Lisp and Scheme....
Kebyže chcem odpoveď od ChatGPT, tak sa spýtam ChatGPT.
-
...
Fakt je problém nespamovat s ChatGPT?
-
Tady byl zase nekdo liny...
Když už si něco necháš generovat v AI, tak proč zrovna v angličtině? Ta je tvým rodným jazykem?
-
Tady byl zase nekdo liny....
That’s a great question — and one that has puzzled programmers for decades! Lisp (especially Common Lisp and Scheme....
Kebyže chcem odpoveď od ChatGPT, tak sa spýtam ChatGPT.
Pochybuju, ze se tu dovis nejaky jiny duvod..
-
Tady byl zase nekdo liny...
Když už si něco necháš generovat v AI, tak proč zrovna v angličtině? Ta je tvým rodným jazykem?
Protoze o Lispu bude 99% textu v AJ, takze LLM bude davat lepsi odpovedi v AJ predpokladam.
-
Tady byl zase nekdo liny...
Když už si něco necháš generovat v AI, tak proč zrovna v angličtině? Ta je tvým rodným jazykem?
Protoze o Lispu bude 99% textu v AJ, takze LLM bude davat lepsi odpovedi v AJ predpokladam.
Tak zkus za tu jeho anglickou odpověď napsat slovo "česky" a výsledky porovnej.
-
Protoze o Lispu bude 99% textu v AJ, takze LLM bude davat lepsi odpovedi v AJ predpokladam.
Nevím, školy nemám, jen mě něco říká, že LLM a jejich jádro transformery, jsou takovým pokračováním NMT na steroidech, takže použitý jazyk bude mít vliv na to, jak moc dobře, špatně nebo kostrbatě ten model odpoví, ale ne na samotný obsah té odpovědi...
-
Není to taková sláva, jak se někteří tváří. Nepřináší nic moc navíc, jen problémy.
Problémy s Lispem nebo s Pythonem? Jaké problémy?
Nevlídná syntaxe, horší infrastruktura, méně knihoven. Tu první otázku nechám bez odpovědi, bylo by to nedůstojné řešit.
Tak pokud ti Python nevyhovuje, používej jiný jazyk. Je jich dost.
O nevlídnosti syntaxe Lispu se nedá mluvit. Je totiž až směšně jednoduchá, jednodušší to snad už nejde. Knihovny jsou, ale programátor si zpravidla navrhne svůj jazyk nad Lispem, ve kterém si pak napíše zbytek aplikace. Pokud nevíš, co je CAR a CDR, tak asi netušíš, o čem je řeč.
Ne, Kite, myslel jsem Lisp a domníval jsem se, že trollíš. Python je populární, takže tyhle věci má dobře. Lisp jsem zažil na škole, s Common Lispem i Scheme jsem se snažil sžít a nešlo nám to. Stejně tak v době, kdy jsem začínal s Linuxem, objevil jsem v distribuci Perl a Python (verze 1.5 nebo kolik). Z Perlu jsem se osypal, Python byl divný (pro člověka, který v té době drtil C a C++), ale cestu jsem si k němu našel. Programování je osobní věc a Lisp je a zůstane jazykem menšiny, zatímco Python je většinově akceptovatelný.
-
U Lispů z hlediska syntaxe zvítězila jednoduchost na použitelností. To kdysi možná nijak drastický rozdíl nebyl, ale dnes mi to přijde výrazné.
A pak jistě nepomohlo, že i ten mentální model je přinejmenším exotičtější, pokud ne těžší na uchopení, takže je těžší se do toho dostat. Tohle se naopak časem trochu mírní, protože funkcionální uvažování se přece jen trochu rozšiřuje postupně.
S Pythonem bych nesrovnával, to je prostě úplně jiné.
-
Tu je slavny komiks a tri policka su venovane aj LISPu a nieje to happyend :-)
https://toggl.com/blog/save-princess-8-programming-languages
-
Tu je slavny komiks a tri policka su venovane aj LISPu a nieje to happyend :-)
https://toggl.com/blog/save-princess-8-programming-languages
Je smutné, když ostatní programátoři vidí na Lispu jen ty závorky.
-
Většina lidí má blíže k procedurálně-imperativnímu myšlení. LISP sice je multiparadigmatický, ale jeho funkcionální jádro se nezapře a tímto způsobem navržené algoritmy v něm co do elegance vynikají.
Z historického hlediska pak trpěl tím, že byl jednak rozdroben na spoustu dialektů (podobně jako FORTRAN či BASIC), jednak tím, že je to tradičně interpretovaný jazyk, takže jeho praktická použitelnost byla omezená. Neexistenci free-verze bych jako problém neviděl - jednak to není pravda, jednak napsat si vlastní interpret LISPu k osahání konceptu je v C záležitost doslova na dvě hodiny, prakticky poměrně dobře použitelný interpret pak během pár odpolední.
-
... trpěl tím, ... že je to tradičně interpretovaný jazyk, takže jeho praktická použitelnost byla omezená.
To platí jen částečně, protože program je po spuštění průběžně kompilován a následně spuštěn. Tedy rekurze jsou kompilovány pouze jednou. Samozřejmě u maker je to trochu jiné. Lisp je tedy částečně kompilován a částečně interpretován.
-
... trpěl tím, ... že je to tradičně interpretovaný jazyk, takže jeho praktická použitelnost byla omezená.
To platí jen částečně, protože program je po spuštění průběžně kompilován a následně spuštěn. Tedy rekurze jsou kompilovány pouze jednou. Samozřejmě u maker je to trochu jiné. Lisp je tedy částečně kompilován a částečně interpretován.
To je otázka konkrétní implementace. Spousta z nich jsou čisté interprety - pro mnohá nasazení je to plně dostačující.
-
... trpěl tím, ... že je to tradičně interpretovaný jazyk, takže jeho praktická použitelnost byla omezená.
To platí jen částečně, protože program je po spuštění průběžně kompilován a následně spuštěn. Tedy rekurze jsou kompilovány pouze jednou. Samozřejmě u maker je to trochu jiné. Lisp je tedy částečně kompilován a částečně interpretován.
Len doplním predrečníka.
V rámci malého výskumu lispov som sa aj pozeral ako to je. Niektoré lispy sú vyslovene kompilované AOT. Niektoré sa kompilujú on the fly do bytecode a ten sa potom interpretuje, niektoré sa on the fly kompilujú do natívneho kódu. A niektoré sú interpretované. Samozrejme u niektorých je to podľa používateľskej konfigurácie.
Koniec kultúrneho okienka.
-
Lisp, tedy common lisp, je stale dobre pouzitelny jazyk ktery v nekterych aspektech nema moc alternativ - vymena kodu za behu se zachovanim dat, prirozene datove struktury schopne uchovavat slozite grafove struktury nebo xml s moznosti modifikaci beznymi funkcemi jazyka a mnoho dalsich. Je to vhodne hlavne pro nejaky vyzkum nebo slozitou analyzu, a neni to ani pomale. Zapis prirozene ukazuje kompilatoru/interpretu jak by se mohl vypocet paralelizovat coz by mohlo ladit se soucasnym vyvojem hardwaru - moc jader, casto nevyuzitych.
O slozitosti zapisu bych nemluvil, treba zapis lambda funkci v c++ to hodne prekonal.
Jako c slouzil lisp jako primarni jazyk, takze komunikace s ostatnimi jazyky nic moc. To ale muzeme rict treba i o jave.
-
Jako c slouzil lisp jako primarni jazyk, takze komunikace s ostatnimi jazyky nic moc. To ale muzeme rict treba i o jave.
Říct můžete, ale asi to nebude moc pravda.
https://www.graalvm.org/java/
https://www.graalvm.org/python/
Dokonce se někdo pokoušel i o Lisp integraci https://github.com/bridje/bridje
https://babashka.org/ využívá graalvm k vytvoření binárek.
Zajímavé je i co se děje kolem WASM.
Myslím, že Lisp je populární. Ne jako jazyk, ale jak všechny ostatní jazyky v poslední době inspiruje. Jsem zvědavý jak to dopadne. Začít používat lambdy a přitom mít jazyk s podporou a kulturou mutable first datových struktur je v dnešní době, kdy potřebujeme co nejvíc kodu pouštět paralelně, hodně odvážné.
-
Lisp, tedy common lisp, je stale dobre pouzitelny jazyk ktery v nekterych aspektech nema moc alternativ - vymena kodu za behu se zachovanim dat, prirozene datove struktury schopne uchovavat slozite grafove struktury nebo xml s moznosti modifikaci beznymi funkcemi jazyka a mnoho dalsich. Je to vhodne hlavne pro nejaky vyzkum nebo slozitou analyzu, a neni to ani pomale.
Jsou to skutečně věci, které jsou v praxi těžce nahraditelné? Nebo je to spíš taková ta obecná představa typu "Lisp je jazyk vhodný pro umělou inteligenci"?
Zapis prirozene ukazuje kompilatoru/interpretu jak by se mohl vypocet paralelizovat coz by mohlo ladit se soucasnym vyvojem hardwaru - moc jader, casto nevyuzitych.
Tohle je podle mě úplná nepravda. Pokud napíšu sekvenční algoritmus v Lispu, žádný zápis mi nepomůže. Když budu psát paralelizovatelný kód v libovolném jazyce, kompilátor má šanci se s tím vypořádat úplně stejně.
-
Lisp ma neco co u ostatnich jazyku postradam, ale dokud jsem nevedel, ze to jde, tak mi to nechybelo.
A to je myslim duvod proc neni tak oblibeny. Ta zdanliva uchylnost jazyka je vic nez dost vykoupena tim co prinasi, ale clovek se k tomu musi prokousat a ne kazdy najde dost duvodu a sily to udelat.
A ted jak to vim tak mi to vsude jinde hrozne chybi. (Hedonicka progrese?)
Zkusim ukazku gifem... kazda ta "=>" znamena, ze jsem si vyhodnotil dany vyraz... vytvoril databazi... udelal tabulku..
Dokonce je na radku 30 videt, ze si muzu vyhodnotit vyraz uvnitr jineho vyrazu.
Vzdycky kdyz vidim jak nekdo pouziva postmana nebo pgadmin pri vyvoji webservis nebo repositories tak uplne citim jak starnu...
-
Ukažte mi bashscript, který v prostředí Termuxu s Lispem dokáže vytvořit ten samý výstup, gif s grafem sinusoidy:
pkg install python matplotlib numpy -y
python <<'PYCODE'
import numpy as np
import matplotlib.pyplot as plt
x = np.linspace(0, 2*np.pi, 500)
y = np.sin(x)
plt.plot(x, y)
plt.axis('off')
plt.savefig('sine.gif', format='gif')
PYCODE
Pak si povíme, proč Python je úspěšný a Lisp ne.
-
Ukažte mi bashscript
Něco jako:
pkg install racket -y
racket -e '(require plot) (plot-file (function sin (- pi) pi #:label "y = sin(x)") #:out-file "sine.png" #:out-kind '"'"'png")'
convert sine.png sine.gif
-
pkg install racket -y
racket -e '(require plot) (plot-file (function sin (- pi) pi #:label "y = sin(x)") #:out-file "sine.png" #:out-kind '"'"'png")'
convert sine.png sine.gif
Díky, že jsi ukázal, proč je Python populární a Lisp (Scheme) není.
-
Lisp, tedy common lisp, je stale dobre pouzitelny jazyk ktery v nekterych aspektech nema moc alternativ - vymena kodu za behu se zachovanim dat, prirozene datove struktury schopne uchovavat slozite grafove struktury nebo xml s moznosti modifikaci beznymi funkcemi jazyka a mnoho dalsich. Je to vhodne hlavne pro nejaky vyzkum nebo slozitou analyzu, a neni to ani pomale.
Jsou to skutečně věci, které jsou v praxi těžce nahraditelné? Nebo je to spíš taková ta obecná představa typu "Lisp je jazyk vhodný pro umělou inteligenci"?
Zapis prirozene ukazuje kompilatoru/interpretu jak by se mohl vypocet paralelizovat coz by mohlo ladit se soucasnym vyvojem hardwaru - moc jader, casto nevyuzitych.
Tohle je podle mě úplná nepravda. Pokud napíšu sekvenční algoritmus v Lispu, žádný zápis mi nepomůže. Když budu psát paralelizovatelný kód v libovolném jazyce, kompilátor má šanci se s tím vypořádat úplně stejně.
Samozrejme, se sekvencnim algoritmem to nepomuze ale to nezavisle poradi vyhodnocovani zanorenych vyrazu je primo navod. Podobne od pocatku jsou tam konstrukce jako aplikuj na vsechny prvky seznamu nejakou operaci misto casto zavislem prochazeni pres cyklus.
Rekl bych ze je to jazyk vhodny pro zapis grafovych struktur a efektivne s nimi pracovat, coz je vhodne pro matematiku a odvozene vedy. Vetsinou jde rychle zmenit implementaci kdyz zmenim nazor a chci to udelat jinak. Moznost neopakovat dlouhy vypocet a menit jen kod za nim ktery snim pracuje je velmi cenna - hlavne kdyz nemate udelanou predtim udelanou serializaci.
Lisp se da urcite nahradit ale vetsinou za cenu vetsi prace, a clovek marne hleda ekvivalentni silu. Moderni jazyky se zameruji jinym smerem.
-
Samozrejme, se sekvencnim algoritmem to nepomuze ale to nezavisle poradi vyhodnocovani zanorenych vyrazu je primo navod. Podobne od pocatku jsou tam konstrukce jako aplikuj na vsechny prvky seznamu nejakou operaci misto casto zavislem prochazeni pres cyklus.
Věci typu map/reduce jsou dnes úplně běžné ve spoustě jazyků. Stejně jako jiné techniky z FP (líné vyhodnocování atd.). Problém paralelizace vidím právě v tom, že to dnes musí být programátor, který tuší, jak se má mezi jádra práce rozdělit a kdy je paralelizace - třeba díky zvýšené režii - už moc.
Rekl bych ze je to jazyk vhodny pro zapis grafovych struktur a efektivne s nimi pracovat, coz je vhodne pro matematiku a odvozene vedy.
Tohle zpochybnit neumím, ale zajímal by mě příklad.
Rekl bych ze je to jazyk vhodny pro zapis grafovych struktur a efektivne s nimi pracovat, coz je vhodne pro matematiku a odvozene vedy. Vetsinou jde rychle zmenit implementaci kdyz zmenim nazor a chci to udelat jinak. Moznost neopakovat dlouhy vypocet a menit jen kod za nim ktery snim pracuje je velmi cenna - hlavne kdyz nemate udelanou predtim udelanou serializaci.
Jenže serializace je dnes laciná. Jak z pohledu implementace, tak z pohledu kapacity a rychlosti záznamových médií. V Pythonu je na to třeba pickle/unpickle, často stačí jednoduchý JSON. Uložit si mezivýpočet je dnes zcela minimální problém.
Lisp se da urcite nahradit ale vetsinou za cenu vetsi prace, a clovek marne hleda ekvivalentni silu. Moderni jazyky se zameruji jinym smerem.
"Moderní jazyky" problémy, které řešil kdysi Lisp, buďto vyřešily podobně jako on (převzaly principy z Lispu a dalších jazyků, zejména funkcionálních) nebo jinak. Máme (hygienická) makra, máme pluginy (s nástupem WebAssembly je lze v pohodě kompilovat za běhu a bezpečně), máme dynamické jazyky, které umí udělat reload modulu. Máme serializaci. Já úplně chápu, že Lisp byl v lecčems první, dodnes asi může lidi inspirovat a v něčem můžebýt šikovnější. Ale stojí ten opruz za to?
-
"Moderní jazyky" problémy, které řešil kdysi Lisp, buďto vyřešily podobně jako on (převzaly principy z Lispu a dalších jazyků, zejména funkcionálních) nebo jinak. Máme (hygienická) makra, máme pluginy (s nástupem WebAssembly je lze v pohodě kompilovat za běhu a bezpečně), máme dynamické jazyky, které umí udělat reload modulu. Máme serializaci. Já úplně chápu, že Lisp byl v lecčems první, dodnes asi může lidi inspirovat a v něčem můžebýt šikovnější. Ale stojí ten opruz za to?
Přijde mi, že hodně věcí máme pořád jen na půl. Např. PyTorch v podstatě simuluje multimetody - musí je simulovat, protože C++ ani Python je nemají. Zatímco třeba CLOS nebo Julia ano, takže implementace něčeho podobného tam je jednodušší.
Nebo makra. Některé jazyky je mají, ale jejich schopnosti jsou různě omezené. Např. někde nemůžete makrem vygenerovat case uvnitř switche. Nebo nejde mít nehygienická makra, i když by se zrovna hodila.
Nebo globální proměnné. Někeré Lispy mají dynamic binding, což je o dost lepší.
Nebo zkuste v nějakém jazyce změnit to, jak se program vyhodnocuje. Např. tam vložit nedeterminismus - oproti lispovským jazykům to jde dost těžko.
-
Presne, ja ten opruz ma spis v tech nelispovskych jazycich u kterych je to velice casto o kompromisu.
I ta serializace neni uplne jednoducha, lisp ma vse nativne.
-
pkg install racket -y
racket -e '(require plot) (plot-file (function sin (- pi) pi #:label "y = sin(x)") #:out-file "sine.png" #:out-kind '"'"'png")'
convert sine.png sine.gif
Díky, že jsi ukázal, proč je Python populární a Lisp (Scheme) není.
~ $ bash test.sh
Testing the available mirrors:
[*] (1) https://packages.termux.dev/apt/termux-main: ok
Picking mirror: (0) /data/data/com.termux/files/usr/etc/termux/mirrors/europe/packages.termux.dev
Get:1 https://packages.termux.dev/apt/termux-main stable InRelease [14.0 kB]
Get:2 https://packages.termux.dev/apt/termux-main stable/main aarch64 Packages [538 kB]
Fetched 552 kB in 2s (357 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
367 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
rust-std-aarch64-linux-android zziplib
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
racket
0 upgraded, 1 newly installed, 0 to remove and 367 not upgraded.
Need to get 5656 kB of archives.
After this operation, 34.1 MB of additional disk space will be used.
Get:1 https://packages.termux.dev/apt/termux-main stable/main aarch64 racket aarch64 8.18 [5656 kB]
Fetched 5656 kB in 4s (1391 kB/s)
Selecting previously unselected package racket.
(Reading database ... 59252 files and directories currently installed.)
Preparing to unpack .../racket_8.18_aarch64.deb ...
Unpacking racket (8.18) ...
Setting up racket (8.18) ...
string::10: collection not found
for module path: plot
collection: "plot"
in collection directories:
/data/data/com.termux/files/home/.local/share/racket/8.18/collects
/data/data/com.termux/files/usr/share/racket/collects
/data/data/com.termux/files/usr/share/racket/pkgs/base
/data/data/com.termux/files/usr/share/racket/pkgs/racket-lib
location...:
string::10
context...:
show-collection-err
perform-require!
for-loop
loop
expand-capturing-lifts
temp98_0
temp71_0
compile
temp65_0
WARNING: The convert command is deprecated in IMv7, use "magick" instead of "convert" or "magick convert"
convert: unable to open image 'sine.png': No such file or directory @ error/blob.c/OpenBlob/3596.
convert: no images defined `sine.gif' @ error/deprecate.c/ConvertImageCommand/3368.
-
string::10: collection not found
for module path: plot
collection: "plot"
Pardon, je třeba ještě nainstalovat plot:
pkg install racket -y
raco pkg install --skip-installed --auto plot
racket -e '(require plot) (plot-file (function sin 0 (* 2 pi) #:label "y = sin(x)") "sine.png")'
convert sine.png sine.gif
-
Teraz som sa s lispom hral viac. Odhliadnuc od ostatných problémov, ktoré sú veľmi subjektívne, som narazil na toto:
SBCL:
- Skvele sa hodí na písanie rôznych CRUD webservisov, proste toto je skvele podporované
- Algoritmizuje sa v tom fajn, je ozaj cítiť, že je to multiparadigmový jazyk
- Písať v tom čokoľvek interaktívne je neskutočná bolesť, Quicklisp (package manager SBCL) má zastaralé balíčky a povedzme úloha vykreslenia štvorcového "Terča", je strašne zložitá. Už len to, že mám wayland a nie Xorg, spôsobuje problémy.
Racket:
- Skvelý na interaktívne úlohy
- Jazyk má veľa možností, ktoré som ešte nepreskúmal
- Je otravne pomalý.
Guile/Elips - Sú špecifické lispy pre mimozemšťanov.
Väčšina problémov je dosť malicherných, ale tá malá komunita je na nich dosť badať. Zastaralé balíčky, horšia podpora. Z toho plynúca bariéra pre vstup, z toho plynúca malá komunita. Ak by som bol pedagóg, tak dialekt lispu nezvolím, lebo podstatný čas by sa riešili problémy s kompatibilitou a nie náplň predmetu. Možno tak Hy, ale to sa mi zdá byť len inak zapísaný python.
Ak by som bol milionár (Eurový), tak prachy vrazím do SBCL, ten sa mi páči najviac.
-
A co clojure?
-
A co clojure?
Vyskúšam, ale ako java programátorovi mi príjde málo lákavé. Tiež sa tam asi budú riešiť jar-ká gradly, maveny. Funkčné to bude, len sa človek upíše ako český žandár. Ale keďže Tišník zrovna o clojure robil dlhý seriál, minimálne si to pozriem.
-
Ale uznávam, že vykresliť môj terč zo štvorcov bolo v clojure+swing smiešne jednoduché.
-
A co clojure?
Vyskúšam, ale ako java programátorovi mi príjde málo lákavé. Tiež sa tam asi budú riešiť jar-ká gradly, maveny. Funkčné to bude, len sa človek upíše ako český žandár. Ale keďže Tišník zrovna o clojure robil dlhý seriál, minimálne si to pozriem.
clojure ma svuj tooling... https://clojure.org/guides/deps_and_cli
Ja pouzivam nejradsi https://leiningen.org/ (https://leiningen.org/). Mam v nem nejaky templates pro svoje projektiky.
Cekal bych prave, ze javista se znalosti lispu by mel clojure milovat...
Java me dost dlouho zivila, ale posledni roky jsem vzdycky upel kdyz jsem na to musel sahnout, protoze sem videl jak krasne jednoduche by to bylo v clojure..