Vlákno názorů k článku Projekt Mori aneb perzistentní datové struktury pro JavaScript od Kolemjdoucí - Zase další cargo cult s immutable v JS...

V tý tabulce je ovšem chyba - anebo má ta knihovna blblou implementaci.
Pokud je u vektoru pro
O(count) = O(1) a
O(nth) = O(logN)
(btv o jaký logaritmus je u složitosti jedno, takže nevím, proč se tam uvádí), pak není důvod, proč by měla být
O(last) = O(N)

Je to implementovany blbe, protoze je to funkce pro sekvence:

(def
^{:arglists '([coll])
:doc "Return the last item in coll, in linear time"
:added "1.0"
:static true}
last (fn ^:static last [s]
(if (next s)
(recur (next s))
(first s))))

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.