Názory k článku Propojení světa LISPu se světem JavaScriptu s využitím transpřeklada­če Wisp

Drobná poznámka. Operátor === v js netestuje umístění v paměti. Funguje uplně stejně jako == až na to že typ argumentů se musí rovnat, operator == dělá konverze.

A jenom na okraj, to že wisp nepodporuje immutable struktury ho dělá úplně k hovnu.Clojure je postavené na immutable strukturách takže není tento překladač kompatibilní s ostatnim kodem... A v JS není problem udělat immutable strukturu ...

jj === je něco jako equals v LISPu.

Btw jak dokážeš zaručit skutečnou immutabilitu v JS? Ani v Javě to vůbec není jednoduché, tak by mě to skutečně zajímalo. Jestli je to jen konvence nebo skutečně neměnitelná struktura (u stringů atd. to je jasný).

Teda, už sem čekal že se na mne sjede hejt, že wisp není clojure ale clojure-like jazyk který má sloužit k výuce a tím pádem je moje kritika bullshit, což bohužel, když se na to zpětně dívám je.

Ale ne, fajn :)

Immutabilita je vždy konvence, nemá vůbec nic do činění s běhovou platformou. I takový Haskell běží na x86 (a ARM a bůhvíčem ...) která bez problému paměť mění, no a za to že Haskell ji většinou měnit nemůže může konvence kterou jazyk vynucuje, nikoli ASM do kterého se překládá. A úplně stejně je to i s JS v tomto případě, akorát JS hraje tu roli ASM. Je to prostě na jazyku, nedovolit měnit paměť, platformě je to jedno.

Ajo takže pokud je JS chápán jako "assembler", tak to potom jo. To asi klidně půjdou odsimulovat i lazy vyhodnocení atd., což ostatně asi nějak dělá clojurescript. Ovšem musí se zaručit, že ten program nebude mít přístup o tu jednu úroveň níž.

příkladem je můj oblíbený Clojure - ten kvůli Java-interop není čistě funkcionální (není i kvůli atomům atd.), protože si klidně vytvořím jakýkoli mutable objekt Javy, což je sice prasárna, ale jde to.

I kdyby Clojure neumožňovalo používat přímo komponenty Javy, byl by to stejně nečistý jazyk protože by umožňoval dělat IO ve funkcích

A ještě jedna poznámka. Pro autora. Lambdy nejsou vůbec nic speciálního a funkcionálního. Často mají lidé tendenci říkat, že jazyk je funkcionální když má lambdy, ale to je mýlka. Jazyk je funkcionální pouze tehdy když každá jedna funkce je referenčně transparentní. Nic víc a nic míň. Termín "pure functional" vznikl pro to, že lidé jak dementi označují nálepkou funkcionální jazyk úplně každý jazyk v kterým jsou lambdy a v STD knihovně funkce jako map, fold či filtr ... upřímně řečeno, podle této definice je funkcionální úplně každý jazyk dneška ...

Články se mi ale jinak líbí, takže za mne super. To jen aby si autor nemyslel že v jeho článcích si dávaji lišky dobrou noc ...

To AFAIK definuješ *čistě funkcionální* jazyk a ten kromě speciálních případů (regexpy, diesel) pro praktické použití neexistuje :-) I ten Haskell, aby byl použitelný v praxi, musí imperativní chování schovávat do monád, potom se může tvářit funkcionálně.

Eeee né tak docela, jsou tady cesty jak takový jazyk vytvořit, jedna z cest je reaktivita (hybrid FP a reaktivity)

Třeba jazyk Elm, ale je dost nedodělanej, spíš hračka

Jinak +1 za schopnost vidět že Haskell není "pure" :) To se jen tak nevidí, plno lidí buď Haskell zahodí s tím že ho nechápe, výrazně menší hlouček lidí se dokáže sám zhypnotizovat natolik že jim začne čistota Haskellu připadat logická a o mnoho menší hlouček, který skutečně chápe o co go, ví že žádná magie pod kapotou není a prostě to vedlejší efekty dělá ...

Ale tak to je jasné, že někde ta imperativní část musí být schována :-) Pokud Haskell dokáže vypsat na stdout tyto dva řádky přesně v tomto pořadí:
Hello
World
tak prostě musí "serializovat" a provést to imperativně + nějakou funkcionálně "nečistou" funkcí (tedy spíš procedurou :--)

Mohl bys něco napsat o prvním LISPu? Já jsem se už párkrát pokoušel pouštět do "vykopávek" ale je to težký, přetěžký...