Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beautiful JavaScript – Functional JavaScript

feederio.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Beautiful JavaScript – Functional JavaScript

#41

Post by ced_vdb »

crooked-v wrote: post #40
LeanderK wrote: post #29

Earlier quoted context omitted.

Disclaimer: CS-Student who is interested in FP-languages but is yet not really experienced in this topic. I am also a bit drunk. i think the problem is that js is not really designed for this kind of usage. If you look at this from the point pf view of an compiler FP is way easier to modify and optimize to improve performance. There are many factors but i believe the most important factor of future FP-base optimising…

Take a look at asm.js. It's a subset of JS that uses de facto type annotations to let the JIT compiler get tremendous performance gains compared to normal JS - benchmarks put it at something like 1/2 the speed of raw C. The problem, of course, is that (among other complications) you need to generate it from something that's completely strictly typed in order to do that in the first place, so most asm.js-compatble cod…

What about typing added on top of javascript for that purpose. Like typescript.

Re: Beautiful JavaScript – Functional JavaScript

#42

Post by Isobit »

mikekchar wrote: post #33
dahart wrote: post #27

Like a lot of people, I'm drawn to the idea of functional programming, and I enjoy using the functional building blocks in JavaScript. What I struggle with is performance, and I bump into it all the time. The difference between overwriting an array with a for loop and using map() is roughly an order of magnitude. I use map() and other functional primitives whenever I can, with anything small and with any code that do…

Holy crap! I just had to check this and you are completely correct. map() is 10x slower in Chromium than overwriting an array. Interestingly, writing my own map operation in JS (by creating a new array and mutating it) was only 20% slower than mutating the original array. So something is very, very, very wrong with Array.map() on Chromium... Then I checked it on Firefox. My hand-rolled map function is 3 times slower…

Mind sharing the code you were testing this with? I have actually seen map perform better than for loops in Chrome in some cases (see https://www.measurethat.net/Benchmarks/Show/1096/0/map-vs-fo...).

Re: Beautiful JavaScript – Functional JavaScript

#43

Post by smallnamespace »

Touche wrote: post #34
jw- wrote: post #24

"So, is JavaScript a truly functional programming language? The short answer is no. Without support for tail-call optimization, pattern matching, immutable data struc- tures, and other fundamental elements of functional programming, JavaScript is not what is traditionally considered a truly functional language." Time again I'm always surprised by how people over look type systems when talking about functional languag…

People don't overlook it, it's not a fundamental property of functional programming.

But by that metric, you could call assembly a functional programming language and not be incorrect either.

There's a core set of features that FP languages implement so that people can be productive, and rich and expressive types certainly seems a key component.

Re: Beautiful JavaScript – Functional JavaScript

#44

Post by crooked-v »

ced_vdb wrote: post #41
crooked-v wrote: post #40

Earlier quoted context omitted.

Take a look at asm.js. It's a subset of JS that uses de facto type annotations to let the JIT compiler get tremendous performance gains compared to normal JS - benchmarks put it at something like 1/2 the speed of raw C. The problem, of course, is that (among other complications) you need to generate it from something that's completely strictly typed in order to do that in the first place, so most asm.js-compatble cod…

What about typing added on top of javascript for that purpose. Like typescript.

Typescript doesn't go far enough yet for asm.js code. It would need much more fine-grained types, like specific kinds of numbers instead of a single 'number' type.

Re: Beautiful JavaScript – Functional JavaScript

#45

Post by mudbutt »

agumonkey wrote: post #30
dahart wrote: post #27

Like a lot of people, I'm drawn to the idea of functional programming, and I enjoy using the functional building blocks in JavaScript. What I struggle with is performance, and I bump into it all the time. The difference between overwriting an array with a for loop and using map() is roughly an order of magnitude. I use map() and other functional primitives whenever I can, with anything small and with any code that do…

I believe lots of people used FP to write short and correct programs; then they profile and tweak the bits that needs it. Also, are you using javascript native .map method ? IIRC libraries like lodash or ramda, through use of reducers, have vastly faster idiomatic FP performance. Mostly because they avoid successive array allocation.

Sorry for being an idiot, but when you reducers you don't mean the native .reduce do you?

Re: Beautiful JavaScript – Functional JavaScript

#46

Post by baron816 »

catnaroek wrote: post #26
baron816 wrote: post #16

Earlier quoted context omitted.

Just exposing people to a few basic patterns from functional programming will 1) encourage them to learn a real functional programming and 2) help them write better code. Learning Haskell or Clojure or something is a big task, especially if you're doing it just because you're curious what all this functional programming is about. Everyone understand JavaScript, so being exposed to functional programming there is not…

> Everyone understand JavaScript, so being exposed to functional programming there is not a big deal. (GHC) Haskell and Clojure are pretty big languages, so it's not surprising that learning them requires a lot of effort, but are you seriously suggesting that learning JavaScript (all quirks included) is easier than learning Scheme or Standard ML (all quirks included)? I've honestly tried to learn JavaScript (in depth…

JavaScript has a lot of really weird/bad aspects to it no doubt, but you kind of have to ignore those parts and keep it simple. I actively avoid using "this" and it makes it so much simpler. There are four cases when "this" won't be what you expect, and the only common one is when it's in a callback, so it's not a huge deal, but I think the language is great when you just avoid it and all its other shitty parts.

Re: Beautiful JavaScript – Functional JavaScript

#47

Post by mikekchar »

Isobit wrote: post #42
mikekchar wrote: post #33

Earlier quoted context omitted.

Holy crap! I just had to check this and you are completely correct. map() is 10x slower in Chromium than overwriting an array. Interestingly, writing my own map operation in JS (by creating a new array and mutating it) was only 20% slower than mutating the original array. So something is very, very, very wrong with Array.map() on Chromium... Then I checked it on Firefox. My hand-rolled map function is 3 times slower…

Mind sharing the code you were testing this with? I have actually seen map perform better than for loops in Chrome in some cases (see https://www.measurethat.net/Benchmarks/Show/1096/0/map-vs-fo... ).

It's very trivial (this is the bulk of it -- not showing everything to spare people from jumping over a huge message):

  var f = function f(num) {
    return num + 5;
  }

  var immutable = function immutable(arr) {
    return arr.map(f);
  }

  var mutating = function mutating(arr) {
    var i = 0;
    var l = arr.length;

    for(; i
In my actual code, arr is a array of ascending numbers from 1 to 10,000 (different sized array each set of calls). I rebuild it before each call to immutable and mutating. I then run each of those functions, one after another 10,000 times. The intent is to make sure that there are no strange optimisations with a constant array and to even out the impact of the GC by interleaving the calls.

Unfortunately I tried to go to the link that you provided, but it just timed out :-(

Ah... it showed up. Hard to say what's going on there. I can't see the source code of how the benchmark works. But I do notice that you aren't returning the values. It is entirely possible that the code is being optimised out. I recommend returning the array. I also added up the elements of the array and checked that each implementation added up to the same number, just to make sure that the operation was actually performed.

Re: Beautiful JavaScript – Functional JavaScript

#48

Post by baron816 »

wyager wrote: post #17
baron816 wrote: post #16

Earlier quoted context omitted.

Just exposing people to a few basic patterns from functional programming will 1) encourage them to learn a real functional programming and 2) help them write better code. Learning Haskell or Clojure or something is a big task, especially if you're doing it just because you're curious what all this functional programming is about. Everyone understand JavaScript, so being exposed to functional programming there is not…

Or, alternatively, they just say "Hmm, this functional programming stuff doesn't seem very interesting or useful at all. Totally overhyped. Well, back to working with Blub." "Functional" JavaScript is better than regular JavaScript in the same way that bloodletting is better than homeopathy; not much. Perhaps you've fallen into the same trap I'm talking about; do you think you're reaping any significant benefit from…

One way or another, we're stuck with JS, so we have to use it and hopefully use it in the best way possible. There are genuinely good aspects to it and if you know what you're doing, you can write in a way that's easy for others to read and understand. Including certain functional patterns is part of that, and avoiding stuff that JS is terrible at, like "this", is another.

Re: Beautiful JavaScript – Functional JavaScript

#49

Post by k__ »

pitaj wrote: post #19
tmerr wrote: post #13

Earlier quoted context omitted.

Sure statically typed functional languages are enjoying a lot of success right now, but there are still plenty of LISPs in the playing field like Clojure that can't be discounted as parlor tricks. You might disagree with them philosophically, but it doesn't change the fact they're being used in production. What bothers me more about JS as a functional language is the lack of tail call optimization. While it's in the…

It will be, and has been implemented in some browsers. The only hiccups were regarding the behavior of stack traces with TCO.

Aren't the going to ditch proper tail calls because of the stack traces?

Last thing I saw was something like "continue return" as opt in for TCO

Re: Beautiful JavaScript – Functional JavaScript

#50

Post by agumonkey »

mudbutt wrote: post #45
agumonkey wrote: post #30

Earlier quoted context omitted.

I believe lots of people used FP to write short and correct programs; then they profile and tweak the bits that needs it. Also, are you using javascript native .map method ? IIRC libraries like lodash or ramda, through use of reducers, have vastly faster idiomatic FP performance. Mostly because they avoid successive array allocation.

Sorry for being an idiot, but when you reducers you don't mean the native .reduce do you?

I'm not even sure it's reducers or transducers. It's mostly a type of functions, not the Array.reduce method. These function don't operate directly, they're meant to be recomposed later by the library. You can [].map(f).map(g).filter(h) and the system will "merge" f, g and h as a one step function that iterate once over the original data and without multiple array allocation. That's my partial understanding, there might be other subtleties.
Post reply on HN