Názory k článku Úpravy Emacsu s Emacs Lisp: základní konstrukce jazyka

Úžasné, díky. Tohle musím ve volné chvilce důkladně nastudovat.

Vimař mě přesvědčil, abych dal přednost Emacsu. Nenapadá mě, jakou větší poklonu bych mohl složit. (Jasně, mohl jsem dát přednost Vimu, ale spíš ne :)) Potlesk!

IMHO žádné velké, i když to ve škole takto pořád učí :-D Pokud uděláš referenčně transparentní funkci s cyklem uvnitř, tak to asi není nic proti ničemu. Navíc funkce s TCO je vlastně jen jinak zapsaná smyčka :-)

Nám to ve škole vysvětlili tak, že používáme LISP (Xlisp) jen jako náhradu za lambda kalkul, takže možná odtud to vychází?

zkusím to ještě uvést na správnou míru.
My se učili LISP asi půl semestru a bylo tam zhruba toto:

setq, cond, car, cdr, cons, defun, apply, atom, list, null (ty poslední tři jsou ale predikáty): tedy například žádné lokální proměnné, tudíž ani nebyla diskuze o oblasti viditelnosti :-)

A z toho se stavěly školní projektíčky typu otočení seznamu, průchod stromem in/pre/post order atd. Člověk potom přišel do praxe a dostal se k CL a čuměl, co to vlastně všechno umí (například makra, miliardy variant smyček přes makra, map atd.)

Koukám píšeš z redhatu, mluvíš o VUTBr?

Ano :)

Na UPOLu mají zajímavější předměty s LISPem, konkrétně s CL:

http://www.inf.upol.cz/lide/michal-krupka/vyuka/programovani-v-common-lispu
http://www.inf.upol.cz/lide/michal-krupka/vyuka/paradigmata-programovani-2

Nevím jak dnes, ale kdysi se na CL učilo i OOP. Takový pohled na objekty z jiné perspektivy

Doslechl jsem se,z e pry ted i predmety, ktere byly ve Scheme, prechazeji na CLisp.

http://vychodil.inf.upol.cz/courses/cs1pp/

myslíš obecně nebo v kontextu snah o plně funkcionální přístup?

Pri reseni problemu je rekurze casto prirozenejsi reseni - problem jde rozdelit na jednoduchy a mensi problem (faktorial je typicky trivialni pripad).
Prevod na cyklus je krok navic a ne vzdy krok trivialni

Při řešení problému je rekurze občas přirozenější řešení. Často je to ale řešení velmi nepřirozené.

Aniž bych chtěl vyvolat flame, rád bych věděl, v čem jsou editory Emacs, nebo Vim pro uživatele takovým přínosem. Čas od času si zkusím třeba Neovim, ale nijak zvlášť mě nenadchne, pro editaci textu použiju raději Atom/VS Code, Geany, nebo mi v terminálu stačí nano.

naprosto geniální systém klávesových zkratek, kterej mám v krvi už mnoho let + ta možnost to bez problémů rozjet v terminálu.

Ale každý má na výběr a mnohdy úplně rozdílné požadavky, takže pokud ti stačí nano, nic proti tomu.

To je asi podobná otázka, jako na co auto, když kůň taky jede.

Nano používám jen na jednoduchou editaci textu, pokud není k dispozici nic než terminál, nechci ho srovnávat s dvojkou Emacs/Vim.

Někdo nano, někdo pico!

Přínos Vimu je pekelná rychlost editace jen za použití klávesnice a ohromná knihovna balíčků.
Emacs je něco jako Vim, jen je mnohem (neomezeně) rozšiřitelnější. Emacs si přizpůsobíš přesně tak, jak potřebuješ a s tím jde ruku v ruce pohodlnost a rychlost editace kódu.
Jak Vim tak i Emacs umí to samé co velké IDE zaměřené na ten který jazyk plus vše už zmíněné. To jsou důvodu proč jsou tyto editory přínosem.
Jako příklad rozšiřitelnosti Emacsu je možné uvést modul evil který implementuje celí Vim. A nebo webový browser eww.

Pokud budete někdy trochu víc dělat v terminálu a na vzdálených serverech, tak nakonec k něčemu rozumnému dokonvergujete.

Nano, pico nebo joe - to jsou takové notepady mezi terminálovejma editorama.

Příště prosím zmínit makro LOOP z cl-lib. Elisp je známý svou malou sadou iteračních nástrojů, emulace common lispu je v takovou chvíli nutnost.
Dále prosím, nikdy v elispu nepoužívejte rekurzi když to není nezbytně nutné. Volání funkcí je v elispu relativně drahé, takže je lepší použít standardní formou iterace.

ah se divam, ze je to zmineno tady https://www.root.cz/clanky/upravy-emacsu-a-tvorba-novych-modulu-s-vyuzitim-emacs-lispu/#k04

Pro gll - to makro je hodne dobre, napriklad umi http://cl-cookbook.sourceforge.net/loop.html

Jestli si dobre pamatuju, zminuje ho i Paul Graham v On Lisp (doporucuju!, akorat asi neni k dispozici HTML verze, takze nemuzu odkazovat)

Hezky jste se mlhavou formulací u let-u vyhnul detailu, který by vedl k výkladu o proměnné lexical-binding :)

if, and a or, umí víc než se zdá a než je v článku:
(or nil 1 2) => 1, (and 1 2 3) => 3, (if cond do else-1 else-2) je validní (poslední je rozdíl i proti třeba Common Lispu).

Teď koukám že příklad na (and (> x 0) "kladne")) tam je, ale reagoval jsem hlavne na "Jedna z těchto konstant je vždy výsledkem všech booleovských operací"