Live data from Hacker News

Functional Programming using JavaScript

scott.sauyet.com

81–88 of 88 posts

Re: Functional Programming using JavaScript

#81
The author is misrepresenting imperative code [0]. Instead of the 42 lines of code he thinks is imperative, but really is already functional-compatible, this is what I would write:

    var getIncompleteTaskSummariesForMember_imperative = function(memberName) {
        return fetchData().then(function(data) {
            var tasks = data.tasks;
            var results = [];
            for (var i = 0; i 
Still longer than the 10 lines of functional code, but a much more fair comparison.

[0]: http://scott.sauyet.com/Javascript/Talk/2014/01/FuncProgTalk...

Re: Functional Programming using JavaScript

#82

Intrestingly it seems that the functional version he proposed is much faster than the OO version. http://jsperf.com/oop-vs-ramda

Fixed for actually running the tests instead of just parsing: http://jsperf.com/oop-vs-ramda/3 TL;DR: Ramda is somewhat faster than OO one

Fixed for running a proper imperative version instead of the functional-oriented 'imperative' version of the original author:

http://jsperf.com/oop-vs-ramda/4

TL;DR: Imperative is faster than functional. Functional is shorter (33% slower in chromium, 83% slower in firefox), but might be more readable depending on your preferences.

Re: Functional Programming using JavaScript

#83
post #58

Earlier quoted context omitted.

I hate to be this guy, but learning FP techniques that aren't available in my day to day language isn't terribly exciting. I want to see a short term benefit, so JS or Java focused articles and books are golden for me.

The issue is that if you're going to be doing FP, you'll want to use a language in which it's not just possible , but natural and happens without an uphill battle. Similarly, if you're just trying to learn the concepts, you're going to have a lot of noise distracting you if you use a language like JS, etc in which FP concepts are quite unnatural to express.

Or, you want to use it in your day-to-day job where it might exist thousands upon thousands of lines of code in a not-so-FP language. I think just learning the concepts is great start. If you could rewrite your whole app, please do so. If not, see if you can write some parts with more FP style code. Like using LINQ in C# instead of rewriting everything to F#, or with Java 8 start using streams and other concepts.

Re: Functional Programming using JavaScript

#84
post #81

The author is misrepresenting imperative code [0]. Instead of the 42 lines of code he thinks is imperative, but really is already functional-compatible, this is what I would write: var getIncompleteTaskSummariesForMember_imperative = function(memberName) { return fetchData().then(function(data) { var tasks = data.tasks; var results = []; for (var i = 0; i Still longer than the 10 lines of functional code, but a much…

I was bothered by the presented functional implementation; it seemed to use a whole pile of library-specific functions to do the same things base JavaScript already does, just expressed slightly differently.

This would be the code I'd write for the same task, pure JS assuming that fetchData returns an ES6 Promise:

    var getIncompleteTaskSummariesForMember = function(memberName) {
        return fetchData().then(function(data) {
            return data.tasks
                .filter(function(task) {
                    return (task.member == memberName && !task.complete); })
                .map(function(task) {
                    return {
                      id: task.id,
                      dueDate: task.dueDate,
                      title: task.title,
                      priority: task.priority
                    }; })
                .sort(function(first, second) {
                    return first.dueDate - second.dueDate; });
        }, function(reason) { console.log(reason); });
    };
Now, does that count as functional? I'm not sure I really care, but it's certainly JavaScript-ish.

Re: Functional Programming using JavaScript

#85
post #82

Earlier quoted context omitted.

Fixed for actually running the tests instead of just parsing: http://jsperf.com/oop-vs-ramda/3 TL;DR: Ramda is somewhat faster than OO one

Fixed for running a proper imperative version instead of the functional-oriented 'imperative' version of the original author: http://jsperf.com/oop-vs-ramda/4 TL;DR: Imperative is faster than functional. Functional is shorter (33% slower in chromium, 83% slower in firefox), but might be more readable depending on your preferences.

Pardon me if I read it wrong, but you just removed the promises, didn't you?

Anyway, doing the same to the FP version yields almost equal speeds (Chromium):

http://jsperf.com/oop-vs-fp

Re: Functional Programming using JavaScript

#86
post #82

Earlier quoted context omitted.

Fixed for running a proper imperative version instead of the functional-oriented 'imperative' version of the original author: http://jsperf.com/oop-vs-ramda/4 TL;DR: Imperative is faster than functional. Functional is shorter (33% slower in chromium, 83% slower in firefox), but might be more readable depending on your preferences.

Pardon me if I read it wrong, but you just removed the promises, didn't you? Anyway, doing the same to the FP version yields almost equal speeds (Chromium): http://jsperf.com/oop-vs-fp

I removed all the useless promises, yes.

The one remaining is the one after fetchData, which looks like it could be async and make use of a promise.

It only yields equal speeds in chromium (good to know), although if you try in firefox, imperative is still 4 times faster.

Re: Functional Programming using JavaScript

#87

I believe this is the author of Ramda, yes? I can't find the talk, anybody got a link? (Ramda is pretty bad ass.) http://ramda.github.io/ramdocs/docs/

There is no video for this. I gave the talk several times to small groups, but never recorded it. Sorry. But you don't want to see my ugly mug, anyway.

Thanks for that! It was a nice introduction, I have a colleague who usually made my eyes glaze over when he started about FP, but now that I have seen it in an environment that I understand and use in my day to day job, a lot of "a-ha" moments occurred in rapid succession. I also liked the humorous bits. It's all pretty self-explanatory and well put, a little Googling will fill in any gaps an interested pupil might face.

Re: Functional Programming using JavaScript

#88
post #46

Earlier quoted context omitted.

There's no real distinction. If the slides were implemented as separate pages you would get a new entry in your history as you navigate through each of them. Back doesn't mean to go back to the previous domain; it means the previous page. You don't think the slides should be separate pages, but that would mean you couldn't link to them.

with replaceState, you get the best of both worlds - bookmarkable slides and no history foo.

Except you can accidentally exit the deck when you actually meant to just go to the previous slide.

I don't think this is better personally. I prefer the use of pushState and back button taking me to the previous slide.

If I really want to back all the way out of the slide deck I will notice after a couple of clicks I need to do something further to go 'all the way back' and right click the back button and click a 'non-slide-deck' selection from that menu.

Post reply on HN