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..
-
...
Možno tak Hy, ale to sa mi zdá byť len inak zapísaný python.
...
Podla mna ma Hy velke vyhody, bez problemov sa nainstaluje a mas v nom vsetko to co v pythone - battery included. Syntax ma ako Clojure.
Napriklad Python kod uvedeny tu
je bez problemov mozne prepisat skoro 1:1 do Hy a funguje to:
(import numpy :as np)
(import matplotlib.pyplot :as plt)
(setv x (np.linspace 0 (* 2 np.pi) 500))
(setv y (np.sin x))
(plt.plot x y)
(plt.axis "off")
(plt.savefig "sine.jpg" :format "jpg")
-
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..
Javu používam len preto, lebo ma živí a znalosť lispu nemám :) Len som tak trocha viac zvedavý. (Milujem Rust, ale to je v tomto kontexte vedľajšie.)
Ale uznávam, že clojure by bola pre mňa asi cesta najmenšieho odporu.
-
Čistě náhodou chystám článek o Basilispu. To je vlastně Clojure pro Python a na to, že je to one man show, to funguje dost dobře. Stay tuned ;)
-
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.
Já začínal na všemožných basicách, ještě na atari, karel, další basic na PC, pak pascal, fortran, delphi, v té době jsem čuchl i k java a c, pak nějaký visualbasic, html, php, javascript, pak matlab, R, modelica a nakonec převážně python...
Všechno tohle jsou prostě normální, čitelný jazyky kde se dá jednoduše vidět struktura, rovnice, prostě aj ten vývoják je v tom víceméně vidět....
Ale ten lisp je proti tomu španělská vesnice, samá závorka, ty já nenávidím, alébrž mám v nich chyby snad nejčastějc - a to je používám u výpočtů a program píšu rozvláčně (nikoliv takový to pythonský úsporný závorkový psaní) a dost řádkuju, používám funkce, abych v tom měl přehled a stejně chyby dohledávám hodiny (ve výpočtech). Neumim si představit v lispu něco složitějšího dělat a krom toho pro lisp asi nebudou pokročilé knihovny fyzikálních vlastností látek :-)
-
Je smutné, když ostatní programátoři vidí na Lispu jen ty závorky.
Ale ten lisp je proti tomu španělská vesnice, samá závorka, ty já nenávidím, alébrž mám v nich chyby snad nejčastějc - a to je používám u výpočtů a program píšu rozvláčně (nikoliv takový to pythonský úsporný závorkový psaní) a dost řádkuju, používám funkce, abych v tom měl přehled a stejně chyby dohledávám hodiny (ve výpočtech). Neumim si představit v lispu něco složitějšího dělat a krom toho pro lisp asi nebudou pokročilé knihovny fyzikálních vlastností látek :-)
V Lispu se píší zejména krátké funkce na jeden až tři řádky. Není důvod dělat funkce dlouhé. V čem jsou napsány ty knihovny fyzikálních vlastností látek? Jsou to jen data nebo i funkce?
-
Ale ten lisp je proti tomu španělská vesnice, samá závorka, ty já nenávidím, alébrž mám v nich chyby snad nejčastějc - ...
Hele ono v takovém C nebo Javě je těch závorek skoro stejně jako v LISPu. Hlavně když to spočítáš jako "počet závorek na sémantickou konstrukci", tak je to céčko na tom mnohem hůř :-)
-
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?
Jo, ten komentář jsem psal já. Grammarly pokud vím taky používá SBCL. Jinak samozřejmě Clojure řada lidí považuje za dialekt Lispu, takže tam toho je taky dost. Hacker News na pozadí je dnes už taky v SBCL mimochodem.
-
Čistě náhodou chystám článek o Basilispu. To je vlastně Clojure pro Python a na to, že je to one man show, to funguje dost dobře. Stay tuned ;)
Tešíme sa, sme ako na ihlách.
-
Je smutné, když ostatní programátoři vidí na Lispu jen ty závorky.
Ale ten lisp je proti tomu španělská vesnice, samá závorka, ty já nenávidím, alébrž mám v nich chyby snad nejčastějc - a to je používám u výpočtů a program píšu rozvláčně (nikoliv takový to pythonský úsporný závorkový psaní) a dost řádkuju, používám funkce, abych v tom měl přehled a stejně chyby dohledávám hodiny (ve výpočtech). Neumim si představit v lispu něco složitějšího dělat a krom toho pro lisp asi nebudou pokročilé knihovny fyzikálních vlastností látek :-)
V Lispu se píší zejména krátké funkce na jeden až tři řádky. Není důvod dělat funkce dlouhé. V čem jsou napsány ty knihovny fyzikálních vlastností látek? Jsou to jen data nebo i funkce?
To hlavní co asi nejvíc potřebuju má desítky funkcí v několika .dlls, který se volaj možná i navzájem. Celý je to napsaný v bůchví čem, chodí mi jenom jako předkompilovaný dynamický knihovny pod woknama a oficiálníma wraperama. Zkoušel jsem to zkompilovat aby to bylo aspoň statický, ale nedokázal jsem ani uspokojit a spravně nakonfigurovat všechny pre-requisites, aby to korektně prošlo. Doma to dělat nemůžu, protože je to licencovaný. Alternativa existuje ale dost okoštěná.
Jinak typicky moje výpočty, třeba vzoreček nějakýho polynomu má aji v pythonu několik řádků, natož funkce ve který je těch polynomů, trochu odlišných, třeba několik mezi kterejma se přepíná podle situace... možná (asi, určitě) to píšu blbě, ale funguje mi to :-) a naštěstí nejsem placený od řádků kódu, ale od výsledků těch výpočtů :)
...Ale z těch závorek v lispu by mě fakt asi kleplo :)
-
Jinak typicky moje výpočty, třeba vzoreček nějakýho polynomu má aji v pythonu několik řádků, natož funkce ve který je těch polynomů, trochu odlišných, třeba několik mezi kterejma se přepíná podle situace... možná (asi, určitě) to píšu blbě, ale funguje mi to :-) a naštěstí nejsem placený od řádků kódu, ale od výsledků těch výpočtů :)
...Ale z těch závorek v lispu by mě fakt asi kleplo :)
Nekleplo, pre lisp existujú balíčky, ktoré umožňujú pre jednotlivé špecifické použitia vhodnejšiu syntax, alebo DSL, takže môžete používať operátory, ktoré sú medzi operandmi a nie pred nimi.
-
Jinak typicky moje výpočty, třeba vzoreček nějakýho polynomu má aji v pythonu několik řádků, natož funkce ve který je těch polynomů, trochu odlišných, třeba několik mezi kterejma se přepíná podle situace... možná (asi, určitě) to píšu blbě, ale funguje mi to :-) a naštěstí nejsem placený od řádků kódu, ale od výsledků těch výpočtů :)
...Ale z těch závorek v lispu by mě fakt asi kleplo :)
Nekleplo, pre lisp existujú balíčky, ktoré umožňujú pre jednotlivé špecifické použitia vhodnejšiu syntax, alebo DSL, takže môžete používať operátory, ktoré sú medzi operandmi a nie pred nimi.
Většina lispařů se od infixového zápisu distancuje, protože nepřináší žádné výhody, ale jen nevýhody.
-
Jinak typicky moje výpočty, třeba vzoreček nějakýho polynomu má aji v pythonu několik řádků, natož funkce ve který je těch polynomů, trochu odlišných, třeba několik mezi kterejma se přepíná podle situace... možná (asi, určitě) to píšu blbě, ale funguje mi to :-) a naštěstí nejsem placený od řádků kódu, ale od výsledků těch výpočtů :)
...Ale z těch závorek v lispu by mě fakt asi kleplo :)
Nekleplo, pre lisp existujú balíčky, ktoré umožňujú pre jednotlivé špecifické použitia vhodnejšiu syntax, alebo DSL, takže môžete používať operátory, ktoré sú medzi operandmi a nie pred nimi.
Většina lispařů se od infixového zápisu distancuje, protože nepřináší žádné výhody, ale jen nevýhody.
Ano, žádná precedence operátorů, yay! Když by se učila prefixová notace ve škole, tak zabedněným učitelům matiky a fyziky praskne žilka a normálně by se mohly děti učit něco užitečnějšího v tom samém čase. Normálně by lidi uměli sumu a ani o tom nevěděli! Takže vlastně vidíme, že se takovou zakomplektovanou prefixovou notaci v nějaký moment stejně učíme, jen už jsme se v tu chvíli peklili s tím neergonomickým zápisem mezi čísly.
Možná bychom byli i ve světě konkurenceschopnější, když by drtivá většina populace s maturitou na první dobrou věděla, k čemu je nejpoužívanější funkce Excelu a jak se používá, protože by ekvivalent znali od základky a přišel jim absolutně zřejmý. A opravdu je spousta lidí, kteří mají maturitu a úplně v pohodě v tom Excelu naklikávají buňku, +, další buňku, -, tamtu buňku a tak dál. Věci si pak píšou napřeskáčku i s nějakými barevnými a podtrženými popiskami.
-
Možná bychom byli i ve světě konkurenceschopnější, když by drtivá většina populace s maturitou na první dobrou věděla, k čemu je nejpoužívanější funkce Excelu a jak se používá, protože by ekvivalent znali od základky a přišel jim absolutně zřejmý. A opravdu je spousta lidí, kteří mají maturitu a úplně v pohodě v tom Excelu naklikávají buňku, +, další buňku, -, tamtu buňku a tak dál. Věci si pak píšou napřeskáčku i s nějakými barevnými a podtrženými popiskami.
Možná i tomu Excelu by prospělo, pokud by místo =SUM(A1; B6; C8) bylo (+ A1 B6 C8)
-
Jinak po značné časové investici jsem dohledal článek, který dost možná i jiným diskutujícím přerámuje pohled na Lisp: https://defmacro.org/ramblings/lisp.html Číst můžete klidně od "XML Reloaded" to předtím je beleterie, která se v podstatě opakuje v každé trochu hlubší diskuzi o Lispu, takže to už známe.
-
to je zvěrstvo:
set(+, -) // the value of '-' is a built in minus function
// so now symbol '+' equals to a minus function
+(5, 4) // since symbol '+' is equal to the minus function
// this results in 1
To je asi dobrý na obfuskace. Kodér vloží do programu desítky takovejch špeků výše, že když ho vyhoděj, nikdo se v tom pak nedokáže orientovat případně v tom jakkoliv smysluplně pokračovat...
... a by mě teda zajímalo jak se pak vrátí tomu + zase funkce součtu.... :)
-
Jinak po značné časové investici jsem dohledal článek, který dost možná i jiným diskutujícím přerámuje pohled na Lisp: https://defmacro.org/ramblings/lisp.html Číst můžete klidně od "XML Reloaded" to předtím je beleterie, která se v podstatě opakuje v každé trochu hlubší diskuzi o Lispu, takže to už známe.
Ten článek je docela zajímavý a připomněl mi, jak jsem data pro XML psal v Lispu. Většina běžných dat v XML lze vcelku jednoduše zapsat právě v Lispu s využitím stručnějšího zápisu. Kratšího než by byl JSON.
-
Možná i tomu Excelu by prospělo, pokud by místo =SUM(A1; B6; C8) bylo (+ A1 B6 C8)
Nevím, jestli si děláte srandu, ale tenhle zápis kromě toho, že je "divnej" narazí dost těžce už na mínus. To už fakt radši stack a RPN, jako u Forthu blahé paměti. :P
No a v případě nějaké realističtější rovnice, no schválně co prefixová notace udělá s něčím jako je tohle
https://www.symmetrymagazine.org/sites/default/files/styles/wide/public/images/standard/sml_two.png
vono to nejspíš dost znepřehlední už i něco jako tohle https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Ftse4.mm.bing.net%2Fth%2Fid%2FOIP.GioXWaYnJpwKT4qF60fGSwHaFj%3Fpid%3DApi&f=1&ipt=f6cbd1c18b236b96a16edc0802f628488c7375fa308a4cbdab60d4189465e844
-
No a v případě nějaké realističtější rovnice, no schválně co prefixová notace udělá s něčím jako je tohle
https://www.symmetrymagazine.org/sites/default/files/styles/wide/public/images/standard/sml_two.png
Fuj, aproximovat boha takhle po ranu
-
Ano, žádná precedence operátorů, yay! Když by se učila prefixová notace ve škole, tak zabedněným učitelům matiky a fyziky praskne žilka a normálně by se mohly děti učit něco užitečnějšího v tom samém čase. Normálně by lidi uměli sumu a ani o tom nevěděli! Takže vlastně vidíme, že se takovou zakomplektovanou prefixovou notaci v nějaký moment stejně učíme, jen už jsme se v tu chvíli peklili s tím neergonomickým zápisem mezi čísly.
"Uměli sumu"? To znamená co? Jako že by najednou zázrakem uměli třeba z fleku posunovat indexy, zjednodušovat vnořené sumy a tak?
"Neergonomický" (jestli je vůbec možné takový výraz v tomto kontextu použít), já bych řekl spíše těžkopádný, by byl právě ten prefixový zápis. Co je pohodlné pro počítač, bývá pro člověka dost nepohodlné - a naopak. Chtěl bych vás vidět, jak upravujete nějaký, i vcelku jednoduchý, prefixový výraz. Jak hned uvidíte výrazy, co se dají vytknout, zlomky, které se dají pokrátit...
-
"Uměli sumu"? To znamená co?
No nedá mi to si nerejpnout, že lidi, kteří tu sumu opravdu používají ve velkém se naopak oné prefixové notace hodně rychle (obvykle na úvodním kurzu v prváku) zase rychle zbavují, protože je jen k vzteku... https://en.wikipedia.org/wiki/Einstein_notation
-
Nejde o to se hádat o sumě, což je v podstatě notace obsahující index a nějakou smyčku v krkolomném zápisu vynalezeném v době, kdy o nějakých počítačích neměli ani tušení. Funkce +, -, *, / apod. můžou úplně v pohodě pracovat na seznamu prvků. A samozřejmě je dost rozdíl, jestli se bavíme tady ve fóru bez pareditu a bez rainbow parens, nebo v nějajém slušném editoru. To je asi jako porovnávat zápis takhle v textu s výstupem z LaTeXu.
A jinak v prefixové notaci se krátí úplně v pohodě, protože to děleno mám před a zápis si dám na řádky pod sebe úplně stejně jako s dlouhou vodorovnou čarou. Obecně ale netuším, proč bych to dělal, když to v pohodě upraví kde jaký CAS typu WolframAlpha a já můžu dělat zajímavější věci. A hlavně většina lidí sice umí krátit, ale už neumí vzoreček upravit pro minimalizaci odchylky z důvodu FP výpočtů, takže to stejně dáte do prográmku typu: https://herbie.uwplse.org/
Protože spočítat to je pro většinu věcí opakování práce, kterou udělali chytřejší dávno v minulém tisíciletí. Dnes je to o aplikaci vzorů, propojení zdánlivě nesouvisejících věcí pro vyšší přidanou hodnotu. Když vím, že pružiny můžu popsat diferenciálními rovnicemi, tak můžu dělat věrné pružinové animace na frontendu i když to všemi mastmi mazaní autoři garance zaměstnání jménem CSS nebyli schopni dát dohromady rovnou dobře a doteď se podobné funkce dělají napůl, bez kontroly stavu, bez navazování animací atd. No a hádejte v čem se ten systém, který to dělá v pohodě při 60 FPS programoval? Ano, v ClojureScriptu.
Vzhledem k tomu, kolik lidí potřebuje sčítat, odčítat, dělit, násobit a počítat procenta vs lidi co potřebují vyšší matematiku je možná lepší se zaměřit na tu první skupinu a podpořit je jednodušším přístupem a té druhé prostě otevřít obzory a nechat je si vyšlapat cestičky, které potřebují, protože ty stejně běžný učitel na typické škole spíše brzdí. Prostě když máte dítě ve třídě, které kvadratické a dost možná kubické rovnice zfleku vidí vs učitele, který se k nim složitě dopracovává, přestože dělá to samé třeba 20 let, tak uděláte nejlépe, když jen subtilně dodáváte materiály a výzvy + učíte třeba mezilidské kompetence, které typicky takový učitel ale taky nemá a to dítě s IQ 150+ by potřebovalo často jako prase drbání. Z hlediska matematiky takovému dítěti nemáte moc co dát. Já patřím k té první skupině normálních lidí, mám dost přátel, kteří patří spíš k té druhé skupině.
Proč všechno učíme tak, jako že to budeme dělat na tabuli a papíru do konce věků? Kancelářské práce jsou tabulkové procesory + možná databáze, to samé různí manažeři a finančníci. Inženýři třeba napíšou nějaký prográmek, zase soubor nebo databáze pro vstup. Spíš už je užitečné, pokud něco, mít nějakou intuici v hlavě. Jestli něco může takto vyjít, či ne. Trénovat odhad zkrátka. Ano, plochu obdélníku by asi lidi mohli spočítat s tesařskou tužkou na zdi, ale v praxi možná je užitečnější, když použijou výkres a laserový metr s odpovídající funkcí. Stejně jsme dnes v situaci, kdy od průměrného pracanta můžete chtít akorát vstup. Aritmetiku si radši dělejte někde jinde a i ten vstup radši různě validujte kontrolními součty. Můžete to rozporovat, můžeme se handrkovat, ale pozorování z praxe vyvrátit nemůžete. A než abych přicházel o peníze, tak těm těžařům dřeva udělám krásnou tabulku na ty rozměry které potřebují, zalaminuju, protože všechna ta práce se po jednom dni, kdy nařežou klády optimálně bohatě zaplatí a všichni budou spoko, protože budou prémie.
Ale jako klidně se tvařme, že se znalost matematiky ve společnosti zlepšuje, že se nám prodlužuje pozornostní křivka, že nemusíme přemýšlet nad a zkoušet nové přístupy. Pak se ale nedivme, že ti šikovnější pracují od nás pro někoho v zahraničí na dálku v lepším případě a nebo zcela odejdou jinam.
-
...
Takže navrhujete, abychom udělali a vyučovali matematiku pro blbce s tím, že ti ne-blbí si budou muset vymyslet vlastní syntaxi?
No, tohle už tu několikrát bylo, počínaje latinou ve středověku, kdy by Jan Hus nesouhlasil, Simplified English. Dokonce i Richard Feynman si vymyslel vlastní, výhodnější notaci, od které ale ve své velikosti dokázal velmi rychle pochopit, že se musí domluvit se zbytkem světa, takže se nakonec přizpůsobil? (a později se ujala slash notace, ale to je trochu jiná věc).
Rozepsal jste se hezky, plamenně, nicméně: Podobnou výukou v podstatě odstříhnete lidi od veškeré do dnes vzniklé literatury. Úžasné pro bety v Konci civilizace od Huxleyho, ale jinak naprosto mimo. Celý přechod byste musel čekat alespoň jednu generaci, která by tím byla zmatena ještě víc - génius se možná prokouše, zbytek bude plavat ještě 10x víc, protože přiznejme si, podobná notace vyhovuje pár autistickým nerdům (bez urážky), pro zbytek je to komplikace.
BTW ona se tam ta intuice v hlavě sama neobjeví, a dost intuitivních věcí vzniká na základě hlubšího pochopení těch "hrozných mechanických výpočtů, které nikdo nedělá". Tady vřele doporučuji pozornosti blog nějakého matematika, který si vyloženě "hraje" - jako třeba John Baez, to opravdu není práce "stroj tohle všechno za nás dělá a proto jsme, ani nevíme jak, přišli na tuhle úžasnou věc", ale "když si uvědomíme tyhle naprosto základní věci, a když opravdu látce rozumíme takže víme, co zanedbat a co ne, tak vlastně tenhle velmi komplikovaný výsledek je takhle triviální".
-
Mně to připadá podobné jako u zastánců zrušení diakritiky - "protože počítače". Počítač mi má práci zjednodušovat, a ne komplikovat. To už můžeme rovnou psát ve strojáku.
Takže pro účely úprav výrazu byste si ho vlastně stejně nejdřív přepsal do nějaké čitelnější, přehlednější formy... Mimochodem, já zrovna patřím k těm lidem, kteří se s LISPem čas od času potkali. A po C/C++ a různých assemblerech byl můj třetí nejpoužívanější jazyk Forth.
Zaměřovat se ve vzdělávacím procesu primárně na blbé není dobrý nápad. Nebo jim přizpůsobovat matematiku, jazyk... I přiblížení počítačů blbým byl podle mě především marketingový tah, ale dopad na civilizaci to má spíše zničující.
Přizpůsobení blbým činí jednoduché věci triviálními a složitější věci nemožnými.
-
Nejde o to se hádat o sumě, což je v podstatě notace obsahující index a nějakou smyčku v krkolomném zápisu vynalezeném v době, kdy o nějakých počítačích neměli ani tušení. Funkce +, -, *, / apod. můžou úplně v pohodě pracovat na seznamu prvků. A samozřejmě je dost rozdíl, jestli se bavíme tady ve fóru bez pareditu a bez rainbow parens, nebo v nějajém slušném editoru. To je asi jako porovnávat zápis takhle v textu s výstupem z LaTeXu.
A jinak v prefixové notaci se krátí úplně v pohodě, protože to děleno mám před a zápis si dám na řádky pod sebe úplně stejně jako s dlouhou vodorovnou čarou. Obecně ale netuším, proč bych to dělal, když to v pohodě upraví kde jaký CAS typu WolframAlpha a já můžu dělat zajímavější věci. A hlavně většina lidí sice umí krátit, ale už neumí vzoreček upravit pro minimalizaci odchylky z důvodu FP výpočtů, takže to stejně dáte do prográmku typu: https://herbie.uwplse.org/
Protože spočítat to je pro většinu věcí opakování práce, kterou udělali chytřejší dávno v minulém tisíciletí. Dnes je to o aplikaci vzorů, propojení zdánlivě nesouvisejících věcí pro vyšší přidanou hodnotu. Když vím, že pružiny můžu popsat diferenciálními rovnicemi, tak můžu dělat věrné pružinové animace na frontendu i když to všemi mastmi mazaní autoři garance zaměstnání jménem CSS nebyli schopni dát dohromady rovnou dobře a doteď se podobné funkce dělají napůl, bez kontroly stavu, bez navazování animací atd. No a hádejte v čem se ten systém, který to dělá v pohodě při 60 FPS programoval? Ano, v ClojureScriptu.
Vzhledem k tomu, kolik lidí potřebuje sčítat, odčítat, dělit, násobit a počítat procenta vs lidi co potřebují vyšší matematiku je možná lepší se zaměřit na tu první skupinu a podpořit je jednodušším přístupem a té druhé prostě otevřít obzory a nechat je si vyšlapat cestičky, které potřebují, protože ty stejně běžný učitel na typické škole spíše brzdí. Prostě když máte dítě ve třídě, které kvadratické a dost možná kubické rovnice zfleku vidí vs učitele, který se k nim složitě dopracovává, přestože dělá to samé třeba 20 let, tak uděláte nejlépe, když jen subtilně dodáváte materiály a výzvy + učíte třeba mezilidské kompetence, které typicky takový učitel ale taky nemá a to dítě s IQ 150+ by potřebovalo často jako prase drbání. Z hlediska matematiky takovému dítěti nemáte moc co dát. Já patřím k té první skupině normálních lidí, mám dost přátel, kteří patří spíš k té druhé skupině.
Proč všechno učíme tak, jako že to budeme dělat na tabuli a papíru do konce věků? Kancelářské práce jsou tabulkové procesory + možná databáze, to samé různí manažeři a finančníci. Inženýři třeba napíšou nějaký prográmek, zase soubor nebo databáze pro vstup. Spíš už je užitečné, pokud něco, mít nějakou intuici v hlavě. Jestli něco může takto vyjít, či ne. Trénovat odhad zkrátka. Ano, plochu obdélníku by asi lidi mohli spočítat s tesařskou tužkou na zdi, ale v praxi možná je užitečnější, když použijou výkres a laserový metr s odpovídající funkcí. Stejně jsme dnes v situaci, kdy od průměrného pracanta můžete chtít akorát vstup. Aritmetiku si radši dělejte někde jinde a i ten vstup radši různě validujte kontrolními součty. Můžete to rozporovat, můžeme se handrkovat, ale pozorování z praxe vyvrátit nemůžete. A než abych přicházel o peníze, tak těm těžařům dřeva udělám krásnou tabulku na ty rozměry které potřebují, zalaminuju, protože všechna ta práce se po jednom dni, kdy nařežou klády optimálně bohatě zaplatí a všichni budou spoko, protože budou prémie.
Ale jako klidně se tvařme, že se znalost matematiky ve společnosti zlepšuje, že se nám prodlužuje pozornostní křivka, že nemusíme přemýšlet nad a zkoušet nové přístupy. Pak se ale nedivme, že ti šikovnější pracují od nás pro někoho v zahraničí na dálku v lepším případě a nebo zcela odejdou jinam.
Clovek nema vubec mentalni kapacitu cist prefixove vyrazy. Uz jen takovyhle jednoduchy vyraz da praci. To, ze je to vyhodne pro pocitace je jina vec (lispovsky S-vyrazy).
Priklad:
^ * + 5 2 - 6 3 2
coz je
((5+2)*(6-3))^2
-
Clovek nema vubec mentalni kapacitu cist prefixove vyrazy. Uz jen takovyhle jednoduchy vyraz da praci. To, ze je to vyhodne pro pocitace je jina vec (lispovsky S-vyrazy).
Priklad:
^ * + 5 2 - 6 3 2
coz je
((5+2)*(6-3))^2
No ale kdyz si tu prefixovou notaci ozavorkuju tak jako v lispu tak uz se to cte dobre ne?
(^ ( * (+ 5 2) (- 6 3)) 2)
Navic... jak uz sem se snazil jednou ilustrovat... diky lispu mam to cteni dost usnadneny....
-
Clovek nema vubec mentalni kapacitu cist prefixove vyrazy. Uz jen takovyhle jednoduchy vyraz da praci. To, ze je to vyhodne pro pocitace je jina vec (lispovsky S-vyrazy).
Priklad:
^ * + 5 2 - 6 3 2
coz je
((5+2)*(6-3))^2
Dobrý postřeh. Samozřejmě jsem to hned zkusil. Překvapivě se mi to čte dobře, ani ty závorky nepotřebuju. Nejvíc mě trklo, že to vlastně krásně řeší váhání nad prioritami. A vzhledem k tomu, že se nepovažuji za úplně nejvíc geniálního, tak nevím, co si o tom teď mám myslet.
-
(^ ( * (+ 5 2) (- 6 3)) 2)
Navic... jak uz sem se snazil jednou ilustrovat... diky lispu mam to cteni dost usnadneny....
Ať si zkusí zapsat bez závorek (+ 1 2 3 4 5 6 7 8 9 10)
-
Clovek nema vubec mentalni kapacitu cist prefixove vyrazy. Uz jen takovyhle jednoduchy vyraz da praci. To, ze je to vyhodne pro pocitace je jina vec (lispovsky S-vyrazy).
Priklad:
^ * + 5 2 - 6 3 2
coz je
((5+2)*(6-3))^2
Dobrý postřeh. Samozřejmě jsem to hned zkusil. Překvapivě se mi to čte dobře, ani ty závorky nepotřebuju. Nejvíc mě trklo, že to vlastně krásně řeší váhání nad prioritami. A vzhledem k tomu, že se nepovažuji za úplně nejvíc geniálního, tak nevím, co si o tom teď mám myslet.
Ehm, já vím, že to tady bude znít trochu jako rouhání, ale mít sny ve strojovém kódu NENÍ normální. :D
-
Clovek nema vubec mentalni kapacitu cist prefixove vyrazy. Uz jen takovyhle jednoduchy vyraz da praci. To, ze je to vyhodne pro pocitace je jina vec (lispovsky S-vyrazy).
Priklad:
^ * + 5 2 - 6 3 2
coz je
((5+2)*(6-3))^2
Dobrý postřeh. Samozřejmě jsem to hned zkusil. Překvapivě se mi to čte dobře, ani ty závorky nepotřebuju. Nejvíc mě trklo, že to vlastně krásně řeší váhání nad prioritami. A vzhledem k tomu, že se nepovažuji za úplně nejvíc geniálního, tak nevím, co si o tom teď mám myslet.
To vám fakt nevěřím. :) Pro mě by bylo zajímavé sledovat zastánce praktického používání prefixové notace, jak to prakticky používá, tj. jak v tom počítá, upravuje výrazy, řeší rovnice...
Znovu opakuji, že významnou část své profesionální i hobby práce jsem dělal za použití pre- nebo postfixové notace (LISP, Forth, Assembler), ale je rozdíl počítat na papíře a jen výsledek zakódovat do počítače.
-
Clovek nema vubec mentalni kapacitu cist prefixove vyrazy. Uz jen takovyhle jednoduchy vyraz da praci. To, ze je to vyhodne pro pocitace je jina vec (lispovsky S-vyrazy).
Priklad:
^ * + 5 2 - 6 3 2
coz je
((5+2)*(6-3))^2
Dobrý postřeh. Samozřejmě jsem to hned zkusil. Překvapivě se mi to čte dobře, ani ty závorky nepotřebuju. Nejvíc mě trklo, že to vlastně krásně řeší váhání nad prioritami. A vzhledem k tomu, že se nepovažuji za úplně nejvíc geniálního, tak nevím, co si o tom teď mám myslet.
To vám fakt nevěřím. :) Pro mě by bylo zajímavé sledovat zastánce praktického používání prefixové notace, jak to prakticky používá, tj. jak v tom počítá, upravuje výrazy, řeší rovnice...
Znovu opakuji, že významnou část své profesionální i hobby práce jsem dělal za použití pre- nebo postfixové notace (LISP, Forth, Assembler), ale je rozdíl počítat na papíře a jen výsledek zakódovat do počítače.
Volání funkcí je v prefixové notaci. V matematice používáme i postfixovou notaci a nepřipadá nám to divné. Lisp udělal jen to, že vše sjednotil do prefixové notace, aby to bylo jednodušší.
-
No ale kdyz si tu prefixovou notaci ozavorkuju tak jako v lispu tak uz se to cte dobre ne?
(^ ( * (+ 5 2) (- 6 3)) 2)
Upřímně, vůbec, ale nějak bych takhle jednoduchý výraz zparsovat dal.
Ale dosaďte si tam cokoli složitějšího (třeba relativistické výpočny jsou známy tím, že se jen těžko vejdou na tabuli posluchárny, aby se v cílovém kroku většina termů vykrátila), veškerá přehlednost se naprosto ztrácí.
Asi jako v němčině, ich habe ....... deset řádků košaté rozvinuté věty ... gehabt, a člověk musí celou dobu držet plný kontext, aby se na konci dozvěděl, které sloveso tam je.
-
Clovek nema vubec mentalni kapacitu cist prefixove vyrazy. Uz jen takovyhle jednoduchy vyraz da praci. To, ze je to vyhodne pro pocitace je jina vec (lispovsky S-vyrazy).
Priklad:
^ * + 5 2 - 6 3 2
coz je
((5+2)*(6-3))^2
Dobrý postřeh. Samozřejmě jsem to hned zkusil. Překvapivě se mi to čte dobře, ani ty závorky nepotřebuju. Nejvíc mě trklo, že to vlastně krásně řeší váhání nad prioritami. A vzhledem k tomu, že se nepovažuji za úplně nejvíc geniálního, tak nevím, co si o tom teď mám myslet.
To vám fakt nevěřím. :)
Beru na vědomí.
A teď si vemte, že jsem se v té rovnici spletl. Protože jsem četl:
^ * + 5 2 - 6 3 2
jako (5 + 2) * (6 - (3 - 2)) ^ 2
A když jsem si tu chybu uvědomil, tak jsem zaujal postoj, že autor té prefixové rovnice to napsal blbě, protože samozřejmě očekávám, že operátor sežere všechny argumenty až po první operátor. Přišlo mi to jasné a pohodlné.
Co z toho vyvodíme?
Pro mě by bylo zajímavé sledovat zastánce praktického používání prefixové notace, jak to prakticky používá, tj. jak v tom počítá, upravuje výrazy, řeší rovnice...
To asi nejsem.
Třeba jsem ale pozoroval, že funkce jako konstrukt mám hodně pod kůží. Když jsem mé paní vysvětloval něco a používal formulace jako "no to máš jako funkci, že...", tak jsem se zarazil, že na mě blbě kouká. A na druhou stranu, řešit (složitější) matematické rovnice není věc, kterou bych dělal každý den. Možná ani jednou za rok ne.
Principielně proti infixové notaci nic nemám.
-
Ehm, já vím, že to tady bude znít trochu jako rouhání, ale mít sny ve strojovém kódu NENÍ normální. :D
Počítám v hlavě tak, že seskupuji objekty: trojůhelníky, čtverce, krychle, kvádry. Třeba desítka jsou dvě krychle a kvádr. Nevím, jestli je to normální, asi možná spíše ne :-)
-
Volání funkcí je v prefixové notaci. V matematice používáme i postfixovou notaci a nepřipadá nám to divné. Lisp udělal jen to, že vše sjednotil do prefixové notace, aby to bylo jednodušší.
Mno, a teď teda řekněte, proč v jazycích, které to umožňují, je taková scháňka po přeťěžování infixových oprátorů, pokud je prefix tak výhodnější.
Troufám si tvrdit, že většina programátorů radši napíše s1 + s2 + s3 nez CONCAT(s1, s2, s3), stejně tak Octonion a = b + c a ne Octonion a = ADD(b, c)
-
Troufám si tvrdit, že většina programátorů radši napíše s1 + s2 + s3 nez CONCAT(s1, s2, s3), stejně tak Octonion a = b + c a ne Octonion a = ADD(b, c)
Troufam si tvrdit, ze ne...
Aspon ne potom co jim nekdo da tech operandu 1000 (nebo proste n) a rekne jim ze to budou delat na 1000 (M) mistech v aplikaci.
Pak se vsichni zacnou schanet po (prefixove notovane) funkci... nebo si ji napisou...
A my si v lispu proste pouzijeme tu samou jako vzdycky pouzivame pro 2 nebo pro 3 "operandy" (divny tomu rikat operandy kdyz jsou to vlastne argumenty funkce)
-
Volání funkcí je v prefixové notaci. V matematice používáme i postfixovou notaci a nepřipadá nám to divné. Lisp udělal jen to, že vše sjednotil do prefixové notace, aby to bylo jednodušší.
Mno, a teď teda řekněte, proč v jazycích, které to umožňují, je taková scháňka po přeťěžování infixových oprátorů, pokud je prefix tak výhodnější.
Troufám si tvrdit, že většina programátorů radši napíše s1 + s2 + s3 nez CONCAT(s1, s2, s3), stejně tak Octonion a = b + c a ne Octonion a = ADD(b, c)
A nemůže to být prostě jen tím, že zvyk?
A opravdu je po tom taková scháňka?
Třeba v Haskellu je možné definovat naprosto zběsilé operátory, jako >>=, <$>, *>, >@>, které jsou automatikcy infixové. A autoři knihoven to všelijak používají, s větším či menším úspěchem stran čitelnosti. Ale neřekl bych, že by po tom byla jakože vysloveně poptávka. Spíše, když maj tu možnost, tak to použijou, protože se jim to víc líbí. A nebo třeba taky ne.
-
Ehm, já vím, že to tady bude znít trochu jako rouhání, ale mít sny ve strojovém kódu NENÍ normální. :D
Počítám v hlavě tak, že seskupuji objekty: trojůhelníky, čtverce, krychle, kvádry. Třeba desítka jsou dvě krychle a kvádr. Nevím, jestli je to normální, asi možná spíše ne :-)
Podle mě mít v hlavě blockout normální není. ale je to roztomilý ;D
-
Volání funkcí je v prefixové notaci. V matematice používáme i postfixovou notaci a nepřipadá nám to divné. Lisp udělal jen to, že vše sjednotil do prefixové notace, aby to bylo jednodušší.
Jednodušší to je, ale pro počítač, nikoli pro člověka. Nemám problém s převody mezi jednotlivými formami zápisu, stejně jako nemám problém převádět mezi sebou arabská a římská čísla. Ale provádět aritmetické operace v římských číslech bych nedával.
A my si v lispu proste pouzijeme tu samou jako vzdycky pouzivame pro 2 nebo pro 3 "operandy" (divny tomu rikat operandy kdyz jsou to vlastne argumenty funkce)
Tak třeba pro mě to žádná extra-podivná věc nebyla, když jsem se učil LISP, protože po BASICu byl mým druhým jazykem Assembler, který je ve většině případů taky prefixový, a zhruba současně s Pascalem jsem se učil Forth - takže postfix. Ale znova - jedna věc je pouhý zápis, druhá věc je aktivní používání a myšlení. Že dokážu i docela složitý výpočet napsat v Assembleru ještě neznamená, že bych chtěl upravovat výrazy v intencích ADD, MUL, DIV...
Beru na vědomí.
A teď si vemte, že jsem se v té rovnici spletl. Protože jsem četl:
^ * + 5 2 - 6 3 2
jako (5 + 2) * (6 - (3 - 2)) ^ 2
A když jsem si tu chybu uvědomil, tak jsem zaujal postoj, že autor té prefixové rovnice to napsal blbě, protože samozřejmě očekávám, že operátor sežere všechny argumenty až po první operátor. Přišlo mi to jasné a pohodlné.
Co z toho vyvodíme?.
Že buď budeme důsledně používat závorky jako v LISPu, nebo operátory s konstantním počtem operandů jako ve Forthu. ;)
-
A nemůže to být prostě jen tím, že zvyk?
Může, a patrně to tak bude. Ale zase, dostáváme se zpátky k tématu - proč je to tak málo rozšířené. Protože se to zvykem (potažmo to prvně muselo vyhovovat) jen menší části lidí. Částečně to mohou být osobní preference, částečně třída úloh...
Tím neříkám, že je to špatně, naopak. Špatně mi přijdou jen snahy vnucovat prefix notaci "prašivým civilistům" (viz 2-3 stránka cca).
-
Podle mě mít v hlavě blockout normální není. ale je to roztomilý ;D
Mě to teda normální připadne, a k tomu navíc i zajímavé. Asi tím dost odbíháme od tématu, ale zdánlivě triviální otázka, jak funguje mozek ostatních lidí je ve skutečnosti dost netriviální, a málokdo o tom tuší, že to ostatní mohou mít jinak.
Jen takových pár hintů (vše u zdravých lidí):
Máte "vnitřní hlas"? Jak přesně počítáte do deseti? Jakou metodou sčítáte/násobíte? Co (ne)vidíte ve tmě, když zavřete oči?
-
Volání funkcí je v prefixové notaci. V matematice používáme i postfixovou notaci a nepřipadá nám to divné. Lisp udělal jen to, že vše sjednotil do prefixové notace, aby to bylo jednodušší.
Mno, a teď teda řekněte, proč v jazycích, které to umožňují, je taková scháňka po přeťěžování infixových oprátorů, pokud je prefix tak výhodnější.
Troufám si tvrdit, že většina programátorů radši napíše s1 + s2 + s3 nez CONCAT(s1, s2, s3), stejně tak Octonion a = b + c a ne Octonion a = ADD(b, c)
Obávám se, že taková sháňka po přetěžování infixových operátorů nebude. Zkusil jsem si je v Pythonu a zjistil jsem, že se to hůř čte. Chápu + pro spojování řetězců, tam se to hodí a CONCAT(s1, s2, s3) mi také není moc sympatický, ale zápis (Octonion a (+ b c)) mi přřipadá docela hezký.
-
Znovu opakuji, že významnou část své profesionální i hobby práce jsem dělal za použití pre- nebo postfixové notace (LISP, Forth, Assembler), ale je rozdíl počítat na papíře a jen výsledek zakódovat do počítače.
Na HPčkách se postfix používá běžně a dělalo s tím několik generací účetních atd., bylo to dost populární (a navíc i ekonomičtější, míň keystroků)
-
Znovu opakuji, že významnou část své profesionální i hobby práce jsem dělal za použití pre- nebo postfixové notace (LISP, Forth, Assembler), ale je rozdíl počítat na papíře a jen výsledek zakódovat do počítače.
Na HPčkách se postfix používá běžně a dělalo s tím několik generací účetních atd., bylo to dost populární (a navíc i ekonomičtější, míň keystroků)
Tak ony i mnohé prefixové operace byly i na klasických kalkulačkách realizovány jako postfixové, což by na první pohled mohlo vypadat jako matoucí, ale nikomu z nás to nikterak nevadilo. Jenže to je něco jiného. Vezměte si nějakou sbírku úloh z matematiky, klidně pro střední školy, vyberte si nějaký příklad typu "zjednodušte následující výrazy", přepište si to do prefixové notace a pak to upravte, aniž byste si pomáhal infixem. Třeba by to pro hlavu nějakého autíka skutečně bylo přirozenější a pohodlnější. Ale pochybuji, že i pro normálního člověka. O úkolech typu "transformujte Laplaceův operátor do sférických souřadnic" ani nemluvě.
-
Znovu opakuji, že významnou část své profesionální i hobby práce jsem dělal za použití pre- nebo postfixové notace (LISP, Forth, Assembler), ale je rozdíl počítat na papíře a jen výsledek zakódovat do počítače.
Na HPčkách se postfix používá běžně a dělalo s tím několik generací účetních atd., bylo to dost populární (a navíc i ekonomičtější, míň keystroků)
Vzpomínám si, že ty účetní říkaly "dám to plusem", na kalkulačce zadaly číslo a pak "+". Když to bylo mínusem, tak na pásce to tisklo červeně.
-
Volání funkcí je v prefixové notaci. V matematice používáme i postfixovou notaci a nepřipadá nám to divné. Lisp udělal jen to, že vše sjednotil do prefixové notace, aby to bylo jednodušší.
Mno, a teď teda řekněte, proč v jazycích, které to umožňují, je taková scháňka po přeťěžování infixových oprátorů, pokud je prefix tak výhodnější.
Troufám si tvrdit, že většina programátorů radši napíše s1 + s2 + s3 nez CONCAT(s1, s2, s3), stejně tak Octonion a = b + c a ne Octonion a = ADD(b, c)
Za mě teda vítězí jednoznačně
CONCAT(s1, s2, s3)
Složité výrazy bych měl tendenci si rozepsat na více řádků a odsadit - s tím, že mi to stále přijde jako výstižnější zápis.