Jak se na Python díváš z pohledu Clojure/ Lispů/ Scheme?
Zdá se mi to, nebo by hodně věcí, které popisuješ byly prostě nějaké makro nebo funkce? Jak se díváš na GIL z tohoto pohledu? Vidíš něco, co by se měly Clojure/ Lisp/ Scheme naučit od Pythonu, možná včetně toho, jak zaujmout masy?
tyjo Python se stále úspěšně tváří jako jazyk jednoduchý na naučení (ale už je tedy pěkně složitý), kdežto LISPy to mají naopak. LISP je skutečně triviální se naučit, jsou to jen nějaká dvě/tři pravidla, co a kdy se vyhodnocuje, potom je to rovná učící se křivka. Ale prostě ten první krok je moc vysoký pro mnoho lidí, navíc se to tváří akademicky pro někoho, co třeba začíná blikáním LEDkou na nějakém tom MCUčku.
Na lispu není problém syntaxe. Tam je problém funkcionální myšlení a rekurze, to dá dost zabrat. Předse jenom jsme imperativní bytosti. Dá se v lispu psát imperativně, ale to je fuj :)
Jak se to vezme. Tabulkový procesor je taky ze své podstaty funkcionální (neuvažujeme-li makra/skriptování), používají ho BFU a málo kdo si to uvědomuje. Na LISPu se mi právě líbí, že mě nenutí být čistě funkcionální. Že tam, kde to dává smysl, není dogmatický - např. loop, progn apod.
Tabulkový procesor je chroustač čísel, na to je to dobrý. Ale cokolyv algoritmizovat je tam bolest. BFU nemají radi tabulkové procesory, většinou jenom dopisují hodnoty do template.
Já k tomu ještě dodám, že většina lidí dělá s tabulkovým procesorem jenom proto, že netuší, že by to šlo dělat jinak a jsou na to zvyklí. Vždy se směji, když někdo požaduje vyexportovat nějaká data ze systému aby si to mohl u sebe naplnit do tabulky. Spoustu lidí vůbec nenapadne, že by to mohl už dělat ten systém a nějakou tabulku vůbec nepotřebují.
To zas naprosto souhlasím. Navíc by se dala parafrázovat letitá pravda - dej blbci funkci a vymyslí... excelovskou tabulku.
na jednu stranu jo, na stranu druhou pokud ten původní systém má naprosto d(divný) UI/UX nebo je pomalej, tak se nedivím. Já bych třeba VELMI ocenil oboustrannou komunikaci mezi Jirou a nějakým gsheetem nebo klidně i LO. A to je chyba toho původního systému.
(ostatně co děláme my vývojáři? oceňujeme komunikaci přes textové soubory a systémy, které to neumožňují můžou být považovány za nedotažené. Tabulky nejsou zas tak odlišné)
Prave naopak. Prvni co programuji je export dat do neceho tabulkoveho (napriklad *.csv) protoze nemuzu obsahnout vsechny moznosti co si uzivatel vymysli. Takto si to hodi do sveho excelu a delaji si s tim co potrebuji a mne daji pokoj.
Dělá si s tím co potřebují = použíjí SUM. My třeba máme největší problém, že většina dat z našeho systému nejsou vyloženě plochá, ale spíš strom. Jakmile ty uživatelé můsí něco groupovat a filtrovat, tak jsou v koncích. Ještě horší je to s požadavky na importy stromové struktury z CSV. Navíc většina naších uživatelů vezme ty CSV a importuje si ho k sobě do jiného systému, namísto toho aby použili JSON, tak potřebují CSV, protože co kdyby si to chtěl někdo otevřít v Excelu.
Ale cokolyv algoritmizovat je tam bolest
Tabuľkové procesory sa veľmi posunuli, Excel má lambdy, sú o tom kvantá videa, dobieha ho Calc, v aktuálnej verzii sú maticové funkcie, dá sa v tom slušne prototypovať, znalosť postupov z matlabu, numpy, APL je veľké plus.
A kolik lidí to umí používat? Většinou by na to byl mnohem vhodnější nástroj než tabulkový procesor a lidé co by to byli schopni používat v tabulkovém procesoru budou schopni použít i ten nástroj. Fakt nechápu tuhle obsesi všude cpát tabulkový procesor jako univerzální nástroj.
Vedia to používať tí, ktorí sa o to zaujímajú. Keď sú o tom videá na youtube, tak to znamená, že ich niekto robí a nerobí ich len tak pre nič za nič, ale preto, lebo má nejakých sledujúcich.
Neviem o akej obsesii hovoríte. Jednoducho ľudia chcú mať možnosť pracovať s dátami v prostredí, ktoré poznajú.
A potom, vy ste sa ešte nikdy nestretli s tým, že keď sa vyvíja softvér, tak ľudia nevedia, čo chcú? Pokiaľ ich dokážete doviesť k tomu, že to, čo chcú presne zistíte a dokážete im to predať ako produkt, tak vám v tom predsa nič nebráni.
Jasně na youtube jsou jenom kvalitní videa. Např. je tam spousta videí o Azure a tom jak je skvělý a přitom je to dost velká bída.
Já píši jenom o tom, že většina lidí používá Excel, protože nikdy nic jiného neviděli a vůbec nemají potuchu, že to by to šlo dělat jinak.
Je nepodstatné, či sú videá dobré alebo nie. Majú divákov a tí si preberú, či si pozreli niečo, čo je pre nich užitočné alebo nie. A prípadne sa to naučia. Je celkom pravdepodobné, že sa to deje.
Já píši jenom o tom, že většina lidí používá Excel, protože nikdy nic jiného neviděli a vůbec nemají potuchu, že to by to šlo dělat jinak.
Stále nechápem, prečo vás to trápi? Pokiaľ sú to vaši klienti, tak im to "inak" jednoducho predajte. Budete ale naozaj musieť zistiť, čo naozaj potrebujú. Oni sami to nevedia. Preto sa so svojimi dátami hrajú v Exceli.
No a pokiaľ to vaši klienti nie sú, tak sa zaoberáte niečím, čo nemôžete ovplyvniť. Prípadne si založte na youtube kanál, na ktorom im budete ukazovať, že Excel nie je cesta a v rámci platených služieb im budete vytvárať zákazkové riešenia bez Excelu.
Je nepodstatné, či sú videá dobré alebo nie. Majú divákov a tí si preberú, či si pozreli niečo, čo je pre nich užitočné alebo nie. A prípadne sa to naučia. Je celkom pravdepodobné, že sa to deje.
Tohle je fakt komické. Třeba na to koukájí jenom pro zasmátí. Já třeba taky koukám na různá videa jak se bourají domy a to přece vůbec neříká nic o tom, že bych domy demoloval.
Já naražím hlavně na lidi, pro které je hlavní nápní práce dostat tabulku a přeposlat dál, protože přece bez tabulky by to nešlo.
Tohle je fakt komické. Třeba na to koukájí jenom pro zasmátí. Já třeba taky koukám na různá videa jak se bourají domy a to přece vůbec neříká nic o tom, že bych domy demoloval.
Nie je skôr komické to, že pravdepodobne posudzujete svet podľa seba? Nenapadlo vás, že na tie isté videá sa pozerá aj niekto, kto domy demoluje, alebo by to rád robil, a hľadá ako to robí konkurencia, prípadne inšpiráciu?
Já naražím hlavně na lidi, pro které je hlavní nápní práce dostat tabulku a přeposlat dál, protože přece bez tabulky by to nešlo.
Točíme sa dookola. Poliaľ sú to vaši klienti, predajte im lepšie riešenie, pokiaľ to nie sú vaši klienti, tak vás to nemusí trápiť.
Komické je posuzovat, že se něco používá podle sledovanosti na youtube.
Celá diskuze s vámi začala jednoduchou otázkou, kolik lidí skutečně využívá pokročilé vlastnosti tabulkových procesorů? Do toho pořád motáte nějaké klienty. Mě je úplně jedno kdo co používá a vůbec mě to netrápí. Chtěl jsem jenom poukázat na to, že tu máme nějakou obsesi na spoustu problémů využívat tabulkový procesor, protože to podle lidí vypadá "profesionálně". Nic víc nic míň.
Komické je posuzovat, že se něco používá podle sledovanosti na youtube.
Takže podľa vás naozaj nie je možné, že niektoré videá sledujú aj tí, ktorých zaujíma ich obsah kvôli zlepšeniu svojej práce a to, o čom sa v nich dozvedia, používajú?
Celá diskuze s vámi začala jednoduchou otázkou, kolik lidí skutečně využívá pokročilé vlastnosti tabulkových procesorů?
A na tú ste hneď dostali odpoveď: tí, ktorí sa o to zaujímajú
. Pokročilé funkcie celkovo prácu značne uľahčujú. Takže používateľov to určite má.
Do toho pořád motáte nějaké klienty.
Písali ste: My třeba máme největší problém, že...
To naznačuje nejaký vzťah, veľmi často sa IT robí dodávateľským spôsobom, tak z toho klienti
. Celkovo platí, že pokiaľ vidíte niečo, čo je vyslovene nesprávne a ste o tom presvedčený, tak je možné, že ste našli obchodnú príležitosť a chcel som vás povzbudiť, aby ste ju využili. A to sa dá aj ak ste zamestnanec.
Mě je úplně jedno kdo co používá a vůbec mě to netrápí.
Keď o tom musíte písať ako o obsesii, tak to tak naozaj nevyzerá.
Chtěl jsem jenom poukázat na to, že tu máme nějakou obsesi na spoustu problémů využívat tabulkový procesor, protože to podle lidí vypadá "profesionálně". Nic víc nic míň.
To vám naozaj niekto povedal, že si myslia, že to vyzerá profesionálne? Možné dôvody prečo to robia, som už napísal vyššie.
Inak, nemyslím si, že má pre mňa zmysel v tejto diskusii ďalej pokračovať.
Navíc to spousta organizací používá tam, kde by se hodila databáze. Dokonce jsem se už několikrát setkal se situací, že ta data skutečně v databázi jsou, ale oni si je importují do obrovské tabulky (což má za následek za určité konstelace pád Excelu, ale oni už mají vypozorovaný postup, kdy se pravděpodobnost pádu sníží) a teprve v ní s nimi pracují. Marné je jakékoli vysvětlování, že jejich počínání postrádá smyslu, že si jen přidělávají práci - oni jsou na to takto zvyklí a přes to nejede vlak.
Navíc to spousta organizací používá tam, kde by se hodila databáze. Dokonce jsem se už několikrát setkal se situací, že ta data skutečně v databázi jsou, ale oni si je importují do obrovské tabulky (což má za následek za určité konstelace pád Excelu, ale oni už mají vypozorovaný postup, kdy se pravděpodobnost pádu sníží) a teprve v ní s nimi pracují. Marné je jakékoli vysvětlování, že jejich počínání postrádá smyslu, že si jen přidělávají práci - oni jsou na to takto zvyklí a přes to nejede vlak.
Vy to máte možno jednoduchšie, ako kolega vyššie - keď ste ich presviedčali, tak to vaši klienti sú...
Marné je jakékoli vysvětlování, že jejich počínání postrádá smyslu, že si jen přidělávají práci - oni jsou na to takto zvyklí a přes to nejede vlak.
... a sú v tom hneď dve dobré správy: Ak sa budete viac snažiť, je možné, že ich naozaj presvedčíte. Ale musí im to dávať ekonomický zmysel.
No a ak nie, tak skôr či neskôr vás budú potrebovať, by ste to po nich nejako upratali.
Ale je tu ešte jedna možnosť: Nemôže to byť tak, že jednoducho vedia lepšie, čo momentálne potrebujú, ako to viete vy?
Ale je tu ešte jedna možnosť: Nemôže to byť tak, že jednoducho vedia lepšie, čo momentálne potrebujú, ako to viete vy?
To si nemyslím, protože to nejsou ajťáci, ale BFU. A jejich problém, kterého si lidé od počítačů všimli už dávno, je ten, že oni nevědí, že se to dá dělat jinak, neumějí si to představit a nehodlají se to učit. Mají zažité stereotypy - ve všem vidí hřebík ten, kdo zná jenom kladivo. Když je člověk pozoruje, jak vyhledávají, filtrují nebo, nedej bože, vkládají nové položky přes označení mnoha tisíc řadkového bloku a cut&paste o řádek níž... A jiné podobné nesmyslnosti.
16. 10. 2025, 14:26 editováno autorem komentáře
To si nemyslím, protože to nejsou ajťáci, ale BFU.
Možno by stálo za to riešiť to s tými, ktorí to platia.
Aj tu si ale myslím, že by sme to mali ukončiť. Písať, že ľudia používajú nástroje AJ na to, na čo nie sú určené, je ako písať, že tráva je zelená. To všetci vieme a nikomu to nič neprinesie.
Zo skúseností v podobnej pozícií:
- tí ľudia o databáze vedia, ale nevedia k nej získať prístup. Či už z "bezpečnostných", organizačných, cross-organizačných alebo licenčných dôvodov, to je teraz jedno, ale jednoducho ho nedostanú. Maximálne čo dostanú je občasný export.
- vedia, že sú vhodnejšie nástroje ako excel, ale nemajú ich. Boli by vďační aj za blbý Access, ale ani ten nemajú (pretože nie je v balíčku, čo korporát kupuje na bežné stroje a výnimka je rovnako dlhý beh, ako priamy prístup k databáze). Radi by si nainštalovali lokálny postgres, ale nemôžu, lebo bezpečnosť/neschválené/apod. A tak ďalej.
Takže Excel používajú, lebo z dostupných nástrojov je to ten najvhodnejší nástroj na prežvýkanie dát.
no to je asi další problém, že když se někdo seznámí s LISPem někde na uni, tak je to v kontextu funkcionálního programování, začíná se rekurzí atd. Přitom LISP podporuje bez problémů i imperativní paradigma, takže rekurzi není nutný používat (třeba makro LOOP je v tomto dokonce před většinou imperativních jazyků).
Jako ano, teoreticky je možná lepší začít funkcionálním paradigmatem, ale to je jako s počítáním - napřed se naučíme počítat na prstech a dělit si tabulky čokolády a teprve o dost let později se to samé zopakuje, tentokrát s teorií množin (nebo jak se to dneska učí).
Ahoj Adame, tyjo to je těžký. Tady existuje ústní tradice, že Python je snadnej na naučení + dnes běží skoro všude (a to je skutečně dobrá reklama, zrovna teď tady zkoušíme nějakej . Tak možná tady se inspirovat?
Tak různé Lispy běží na prakticky všem a Clojure s dialekty se taky dost dotahuje. Jen Basilisp a Hylang jsou nakonec implementované nad Pythonem...
Spíš je otázka, jestli prostě nenapsat knížku typu Automate The Boring Stuff jen prostě s Lispem/ Clojure, např. Babashkou.
Zkrátka přijde mi, že různé tanečky kolem GILu, JITu atd. jsou na JVM a většině seriózních dialektů Lispu/ Scheme do velké míry vyřešené a výkonné a Python teď vynalézá kolo a duplikuje práci a v řadě ohledů asi s horším výsledkem. Možná se na to ale dívám trochu moc příkře.
Já mám Lisp/Scheme fakt rád, ale vážně si nedokážu představit, jak by se to mohlo stát masovou záležitostí. Spousta lidí prostě není schopná dělat věci jinak než imperativně a tím všechny předpoklady proč by měli lidi používat Lisp padají a proto taky jsou úspěšné jazyky jako Python. Není důležité aby byl jazyk nejlepší, ale aby byl použitelný a rozšířený.
Ne ty jazyky nevynalézají kolo oni se jednoduše posouvají. Úplně to samé dělá i Lisp akorát opačně.
15. 10. 2025, 09:15 editováno autorem komentáře
Kde se bere ta zkratka že LISP=funkcionální programování?
To vůbec není pravda, však LISP je použitelnej jako běžnej imperativní jazyk. Tečka-dvojice jsou měnitelné, seznamy jsou měnitelné, funkce mohou mít stav, existují LOOP makra.
Celej init soubor v Emacsu je jedna mutable-modify operace za druhou :)
Rozdíl mezi mainstreamem je vlastně jen v syntaxi.
přesně tak. Takže tady máme jazyky s podobnou sémantikou (můžou a nemusí být funkcionální) jen s jinou syntaxí. A zdá se, že to vyhrávají neLISPovské jazyky, protože jak píšeš, syntaxe dělá hodně - pokud se bavíme o mainstreamu. Já s LISPy problém nemám (hlavně Clojure je fajn), ale prostě už jen demografie mainstreamu je proti LISPům...
18. 10. 2025, 12:00 editováno autorem komentáře
... Clojure/ Lisp/ Scheme naučit od Pythonu, možná včetně toho, jak zaujmout masy?
Je nejaký dôvod prečo by Clojure/ Lisp/ Scheme mali zaujať masy? A inak, nestalo sa to už náhodou? Jednotlivé programovacie jazyky preberajú vlastnosti a schopnosti iných jazykov, funkcionálny prístup je už dlhý čas v značnej miere podporovaný aj v C++. Lambdy má už dokonca aj Excel. A existujú o tom kvantá videa pre obyčajných používateľov. To sa nestalo len tak, to niekto chcel, pretože v tom videl zmysel. A to sa mohlo stať iba ak niekto zaujal masy. To nemusí znamenať iba to, že masy prejdú na programovacie jazyky, ktoré boli v niečom prvé.
Je to hodně velká redukce říct, že programovací jazyky přebírají vlastnosti. Tak nějak z podstaty věci např. C++ nikdy nemůže zcela převzít v Lispu/ Clojure běžné funkce a celé přístupy, např. skutečný REPL.
Zdá se, že někoho napadlo, že atomy z Clojure by bylo docela fajn mít i v Pythonu:
https://github.com/maxcountryman/atomos
má s tím někdo zkušenosti?
Je to hodně velká redukce říct, že programovací jazyky přebírají vlastnosti.
Vo všetkom, o čom sa na týchto stránkach bavíme, je nejaká redukcia. Otázka je aká veľká.
Musím sa ale priznať, že keď som to písal, nenapadlo ma, že to niekto pochopí tak, že nejaký jazyk preberá úplne všetky vlastnosti nejakého iného jazyka.
Tak nějak z podstaty věci např. C++ nikdy nemůže zcela převzít v Lispu/ Clojure běžné funkce a celé přístupy, např. skutečný REPL.
Otázka je, či niekoho v C++ vôbec zaujíma úplné prevzatie REPL, zvlášť s ohľadom na to, že REPL v clojure stojí na dynamickej väzbe a na dynamických typoch. Aj jedno aj druhé je síce do určitej miery v C++ možné, ale väčšinou nevítané.
Ale aj tak sa niektorí snažia prevziať to, čo sa dá a čo má zmysel:
https://clang.llvm.org/docs/ClangRepl.html
Osobne si tipnem, že aj LLVM aj CERN vedia, čo robia.
Zdá se, že někoho napadlo, že atomy z Clojure by bylo docela fajn mít i v Pythonu
A nie je náhodou tiež prevzatie niečoho užitočného z jedného jazyka do druhého? Aj keď v tom pôvodnom je to na úrovni jazyka a v tom druhom na úrovni knižnice. A navyše aj v tom pôvodnom to stojí na vlastnostiach iného jazyka.
Ten atomos vypadá po pravdě dost strašně. Když knihovna nabízí "atomic int", tak bych čekal, že to bude atomické plus mínus na úrovni CMPXCHG instrukce, a ne, že to bude Pythoní int obalený Pythoním lockem - to si můžu napsat sám a nepotřebuju na to nějakou knihovnu.
Stejně tak ten "atom" vypadá dost divně - ono mi to do té funkce předá dict, ten já zmodifikuju (takže mi to asi musí předat deepcopy), a on pak udělá compare-and-set? Nebylo by lepší používat trochu víc immutable struktury?
Na druhou stranu, je to kinhovna, kde poslední commit je před 8 lety a nemá to ani release na githubu, tak od toho člověk nemůže čekat moc...
Btw atomy neznám, v čem se to vlastně liší od Javovské AtomicReference, že to musí mít podporu přímo na úrovni jazyka?
Řekl bych to jinak - to, co je dobré a o co byl obecně zájem, se přebírá dál. O závorkovou syntaxi Lispu (obecně, chápu, že menšina to má jinak) zájem není. Proto další a další pokusy popularizovat Lisp skončí stejným (relativním) neúspěchem, jako všechny předchozí. Zvlášť když ostatní jazyky mají ve všech relevantních ohledech stejné nebo srovnatelné možnosti jako Lisp a z té jeho unikátnosti zbyla vlastně jenom ta jeho závorková syntaxe a podivné "výhody" typu "kód jsou data" (což je v zásadě dnes už pravda pro lecjaký jazyk a nikdo to nepoužívá).
Tak to vypadá, že po letech jsme se prakticky nadobro zbavili GILu. Vlastně nogil už nabízel tuším Python 3.12, ale teď to vypadá jako oficialita. No tak sbohem, chybět moc nebudeš :)
(spíš je divný, že léta bylo tvrzeno, že prostě GIL v Pythonu být musí)
Ještě ne.
Zatím je to pouze možnost při překladu, protože to prý zpomaluje (již tak pomalý) Python o dalších jestli si pamatuji 25%. Takže ještě pár verzí a pak snad to konečně dotáhnout.
Jinak nikdy nebylo, že tam být musí. Jen že implementace na ní spoléhá - existovali alternativní implementace bez GILu. Problém byl, že přepsat celou širokou knihovnu, aby na něj nespoléhala a měla přitom rozumný výkon, bylo nemalý balík práce.
Podmínkou pro začlenění noGIL bylo, že výkon jednovláknového programu nesmí klesnout o víc než 15%. Realita je vesměs pod 10, nejhorší platforma je cca 12%.
Jinak Python zrychlil od verze 3.10 zhruba o 50% v průměru testů.
Default to zatím není a GIL rozhodně v dohledné době nezmizí. noGIL se použije jen v případě, že knihovny signalizují, že s ním umějí. Jinak GIL zůstane.
Z tohoto pohledu je docela zajímavé použití víc interpretrů, jako alternativa.
jj chystám se udělat nějaké benchmarky do příštího článku, včetně porovnání GIL a noGIL variant. Tak uvidíme (ale jak píšeš, Python se poslední roky dost dobře urychlil, dobrá práce).
>> Nenastala tedy taková patová situace, jako v případě Perlu 5 vs. Perl 6 (v současnosti Raku).
Tato poznámka mi přijde jako zbytečné kopnutí do Perlu/Raku. Python má nekompatibility, tak se podívejte kolek je změn v Perlu? Perl 6 (Raku) je od základů jiný jazyk a netají se tím a neznamená to, že by přestal být Perl 5 vyvíjený. Tak jaká patová situace?
No on je to v dnešní době docela jedno, jaká je situace v Perl. Z Perl se stala okrajová záležitost, která těží ze své historie. Moc lidí co by dnes začínali s Perl asi nebude.
no přesně to jsem měl na mysli; původní plán na vylepšení jazyka nakonec skončil tak, že jsou to dva jazyky (což je dnes reflektováno změnou názvu). Nic zlého tím nemyslím a asi to vlastně už dneska moc není relevantní.
Z jednoho jazyka na pokraji zájmu jsou dva jazyky na pokraji zájmu. Tohle byl úspěch, to nemohu říct.
Za mě za to nemůže Raku, že se o Perl 5 noví lidé moc nezajímají. Raku (Perl 6) jsem chápal jako snahu někam se posunout a být zase atraktivní pro další generace s tím, že na to staří psi postupně přejdou. Takhle udělali nový jazyk pro nikoho a dědkům zůstal Perl a vzpomínky na staré dobré devadesátky.