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

31–40 of 59 posts

Re: Beautiful JavaScript – Functional JavaScript

#31

Post by bbcbasic »

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…

I agree. Reading YDKJS book helped. The trick is to realise "this" is like another argument to the function.

It varies by context, and will be set to the created object if new is used, set to global otherwise. You can also use the call function I think to set to something specific.

Anyway none of it really makes any deep sense to me, just a load of arbitrary features and traps.

FP like Haskell have a deep structure based in theory and maths, so although harder to make sense of initially, one you get it you don't forget it.

Re: Beautiful JavaScript – Functional JavaScript

#32

Post by bbcbasic »

wyager wrote: post #12

My concern with all these "functional javascript" posts is that people might (understandably) leave with the false impression that this is what functional programming looks like in general. It's like if you tried to get someone into cars by having them drive a Hyundai i10. Regardless of whether you think JavaScript qualifies as a "functional language" just because it supports higher-order functions, the fact of the m…

Upvoted because I think this is so spot on. Technically any language that lets you pass functions and capture variables is functional, but you ain't going to learn the beauty of FP from JS.

Re: Beautiful JavaScript – Functional JavaScript

#33

Post by mikekchar »

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 than the mutating version and the map() version is 1 or 2 orders of magnitude faster than the mutating version (as you would expect it to be).

So there is something wrong with Chromium, I think... Caveat: First thing in the morning on boxing day, back of the envelope style hacking. Having someone else verify my results would be nice ;-) Otherwise take it with a grain of salt...

Edit: The built in profiler was giving me strange results on Firefox, so I used the Gecko Profiler extension and it gave me something more reasonable: map() is about 50% slower than mutating the array and my handrolled map is about 20% slower than mutating the array. So that's a bit more consistent with Chromium's results.

Re: Beautiful JavaScript – Functional JavaScript

#34

Post by Touche »

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.

Re: Beautiful JavaScript – Functional JavaScript

#35

Post by [deleted] »

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…

[deleted]

Re: Beautiful JavaScript – Functional JavaScript

#36

Post by seanmcdirmid »

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…

Don't tell the Lisp people that. Plenty about functional programming has been explored without static typing.

Re: Beautiful JavaScript – Functional JavaScript

#37

Post by zdragnar »

wyager wrote: post #12

My concern with all these "functional javascript" posts is that people might (understandably) leave with the false impression that this is what functional programming looks like in general. It's like if you tried to get someone into cars by having them drive a Hyundai i10. Regardless of whether you think JavaScript qualifies as a "functional language" just because it supports higher-order functions, the fact of the m…

You can easily get runtime ADTs from libraries like tcomb and folktale. While you lose out on some tooling, you gain advantages such as ad-hoc types and boundary checking (I.e. Ajax responses), as well as metadata (in the case of tcomb) for things like automated form generation and validation.

Re: Beautiful JavaScript – Functional JavaScript

#38

Post by eiriklv »

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…

What kind of applications are you building?

Re: Beautiful JavaScript – Functional JavaScript

#39

Post by groovy2shoes »

LeanderK wrote: post #29
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…

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…

> i always wondered what a really, really god JIT-compiler would look like.

Take a look at LuaJIT, then.

Also, I feel like it's worth mentioning that Haskell, OCaml, and Standard ML all have high-quality compilers available that can generate some pretty performant code. You won't get C speed out of them (at least not with idiomatic code), but you can wind up with executables that beat Java or C# perhaps, and easily beat the likes of Python, Ruby, Perl, JavaScript, ....

Re: Beautiful JavaScript – Functional JavaScript

#40

Post by crooked-v »

LeanderK wrote: post #29
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…

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 code is actually just generated anyway based on C or a similar language.

Post reply on HN