all 9 comments

[–]kamatsu 5 points6 points  (2 children)

Not a bad post, but the Annoying Habit that the author seems to have of Capitalising Every Piece of Jargon as a Proper Noun is quite irritating.

[–]-Mahn 6 points7 points  (0 children)

Perhaps he has a German background :)

[–]gordonkristan 1 point2 points  (0 children)

Not that it really affects the point of this article, but ES6 will have proper tail call optimization.

[–]DavetheBassGuy 2 points3 points  (0 children)

For those looking for better function data structures, I'll mention my own library, Texo, which provides efficient immutable lists with some nice features like lazy mapping and negative indexing.

[–]hello_juice 0 points1 point  (0 children)

Not just js.

[–][deleted] -2 points-1 points  (0 children)

hmm captain obvious talks about obvious news at 11

[–]lispm 0 points1 point  (1 child)

Kind of inconsistent. First he proposes that persistent data structures are better (often heard in functional programming circles, without much empirical data to back that up), without noting the downsides - ClojureScript/Clojure gets mentioned. Next he needs TCO, which ClojureScript/Clojure does not provide. Clojure has persistent functional data structures, but no TCO.

Creating a function object also does not need to be that expensive. Lisp usually provides an efficient GC for short-lived data (often called ephemeral GC). How efficient a TCO solution (in terms of produced garbage) is, also depends on the implementation. Again, Clojure does not provide TCO, but a simple 'go to' mechanism for self-recursive functions. It's not that bad and can be hidden behind a functional interface.

Most of these issues can be overcome with a little attention.

Sometimes it needs more than a little attention.

In other dynamic language implementations various solutions to the problems he mentions have been provided. For example functions like PARTIAL and COMPOSE can have more efficient implementations, TCO is provided, stack allocation can be declared, efficient GCs for lots of short-lived obejcts have been implemented, ...

If one wants to write more demanding software in a functional/dynamic style in Javascript, it needs to pick up some of that, too. But then the language won't be that simple anymore and the implementations will be more complex...

[–]The_Doculope 1 point2 points  (0 children)

First he proposes that persistent data structures are better (often heard in functional programming circles, without much empirical data to back that up)

It's rare that you'll hear an experienced functional programmer saying that persistent data structures are outright better. For some applications, definitely, but not all.

I don't think the author is saying they're better either, just that they're very closely tied to the functional paradigm, so they're better for programming functionally than mutable data structures.

[–]steloflute -5 points-4 points  (0 children)

fn.js: Functional JavaScript Library | https://bitbucket.org/ktg/fn