Vlákno názorů k článku Úpravy Emacsu s Emacs Lisp: základní konstrukce jazyka od gll - jaké jsou praktické a teoretické důvody pro preferování...

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