3 ms·
That would highly depend on if you're writing performance-sensitive code, and I doubt most JS would be greatly affected by these paradigms.
by k3n 14y ago
That would highly depend on if you're writing performance-sensitive code, and I doubt most JS would be greatly affected by these paradigms.
- MBlume 14y agolack of TCO doesn't mean it's a little slow, lack of TCO means that naive use of classic functional patterns blows the stack for big lists/structures/arguments.
- fogus 14y agoBy "classic functional patterns" you mean recursion. There are other ways to implement functions that are "classically functional" using techniques other than recursion, that do not blow the stack. I'll talk about each and their tradeoffs.
- MBlume 14y agoI did also say "naive use" =) Looking forward to the book.
- gngeal 14y agoIt's not just recursion, it's calls in general, I guess. (There are other ways of being space-inefficient in functional programs, see the odd versus even streams issue in Scheme.) Are you going to mention tail calls in ES6 in your book, BTW?
- fogus 14y agoSorry for the late response. I will not cover ES6 tail calls very much at all except to mention the possibility for inclusion.
- k3n 14y agoRight, but is this a concern for most JS? I realize that JS is becoming more popular for various tasks -- not always relating to the web -- but still, I kind of doubt that 99% of the JS out there is going to run up against these types of problems. Perhaps something like Uglify.js or similar might, but then again, if you're implementing a parser (or any other static code analyzer/tool) then you're probably going to avoid most libs to start with.