Prečo nie je Lisp populárnejší?

[Jan Gregor]

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.

[Reklama]

[Zdenek Henek]

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é.

[Ink]

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ě.

[listoper]

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...

[qelurg]

Ukažte mi bashscript, který v prostředí Termuxu  s Lispem dokáže vytvořit ten samý výstup, gif s grafem sinusoidy:

Kód: [Vybrat]

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.

[Reklama]

[Radek Miček]

Ukažte mi bashscript

Něco jako:

Kód: [Vybrat]

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


[Ink]

Kód: [Vybrat]

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í.

[Jan Gregor]

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.

[Ink]

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?

[Radek Miček]

"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.

[Jan Gregor]

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.

[qelurg]

Kód: [Vybrat]

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í.

Kód: [Vybrat]

~ $ 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.


[Radek Miček]

Kód: [Vybrat]

string::10: collection not found
  for module path: plot
  collection: "plot"


Pardon, je třeba ještě nainstalovat plot:

Kód: [Vybrat]

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


[balkovic]

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.

[listoper]

A co clojure?