Oni ten zmatek v pojmenovani rozsiruji lidi od Javy napriklad :-) Tam jeste navic maji "unmodifiable" jako slabsi odvar od "immutable", ale ja to chapu, oni teprve ted objevuji veci, ktere FP ma radu desetileti.
Immutable je proste immutable v puvodnim smyslu toho slova (prikladem jsou Stringy v Jave, nebo prave kolekce z Mori). Persistent znamena, ze sice kolekce pod ni je immutable, ale API umoznuje "pridavani" nebo "ubirani" prvku, tyto operace ovsem ve skutecnosti pouziji structural sharing (nebo v nejhorsim pripade deep kopii), ovsem vzdy vraci z pohledu programatora referenci na novou strukturu, ta stara zustane zachovana a v pohode ji napriklad mohou pouzivat dalsi vlakna atd.
Ony to jsou normální poziční argumenty, takto (jen s čárkou) vynechávat nejdou. Funguje to v případě range() zhruba takto:
range() - nekonečná sekvence začínající nulou, krok=1
range(10) - sekvence prvků 0 1 2 3 4 5 6 7 8 9
range(0,10,1) - dtto
range(1,10) - sekvence prvků 1 2 3 4 5 6 7 8 9
range(1,10,1) - dtto
range(1, 10, 2) - sekvence prvků 1 3 5 7 9
range(10, 1, -2) - sekvence prvků 10 8 6 4 2
pro vytvoření nekonečné sekvence konstant (třeba té desítky) slouží funkce repeat:
mori.repeat(10)
Zaklad logaritmu jsem tam dal z toho duvodu, ze to neni 'klasicky' logaritmus dvou jako u binarnich stromu. Tam jde v praxi skutecne o logaritmickou slozitost, kdezto pri zakladu 32 v podstate o slozitost konstanti ;) protoze pocet zanoreni je pro libovolnou vytvoritelnou strukturu velmi nizky, minimalne v JS, kde je index omezen na 2^32-1.
Na tom není ale nic špatného, podle všeho tady s námi JavaScript bude dlouho, takže je IMHO dobré, že se do něj dostávají i další prvky s FP (základ už JS má, to je podle mě jedna z jeho nejlepších vlastností :-).
Jinak tam nejde jen o seznamy, ty jsou základem už LISPu, ale hlavně o vektory a mapy, jejichž implementace je skutečně vymazlená...
No třeba já semtam (řekněme 5% zdrojáků) musím pracovat s JS a tak je pro mě Mori docela dobré řešení, protože další tooly dělám hlavně v Clojure (+ něco málo Javy).
Ad druhý bod: ano, to je v současných řešeních JS pravda, dokonce se z toho dělá přednost :-) (no u browserů to JE přednost, u node.js to _obchází_ přes workery). Ale obecně: jak ClojureScript tak i Mori jsou připraveny na multithreading, stačí jediná implementace JS enginu s touto podporou a může se to ihned začít používat.
Stavet na javascriptu dalsi jazyky =)))) skoro jsem spadnul ze zidle, vzdycky si vzpomenu na prednasky z destroyallsoftware
https://www.destroyallsoftware.com/talks/wat a tohle stoji urcite taky za to https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
imho
CoffeeScript se sice fajn, ale co následující kód:
fce=()->
for x in p:
console.log(x)
Při volání funkce se vytvoří nové pole, při průchodu se do něj vloží postupně všechny prvky z p a pak se pole vrátí. Což JavaScriptu trvá opravdu dlouho. Obvzlášť pokud je to třeba metoda, která vykresluje všechny objekty na Canvas,a je volána často.
Neviem ci musi. Fakt je ten, ze Javascript v sucasnosti udava trend v programovani UI prostrednictvom mnohych frameworkov pretoze sa v nom UI robi jednoduchsie nez len v HTML/CSS a PHP (napriklad) a trochu lezie aj do serverov cez node.js. Moze sa to nepacit vela ludom, ale nic to nemeni na tom, ze je to tak a ze to tak skoro neutichne.
Ma Mori nejakou zasadni vyhodu oproti immutable.js (https://facebook.github.io/immutable-js/)?
Autori pisou toto, ale druhy bod jsem (jeste) neoveroval:
Differences from Immutable.js
* A functional API, data structures do not have public methods
* Faster, ClojureScript data structures have been subjected to more real world usage and continuous benchmarking for nearly 4 years
* Larger, gzipped the base Mori module is about 6K larger than Immutable.js
Ale docela tomu verim, ze v ClojureScriptu maji implementaci vychytanou.