
Beautiful JavaScript – Functional JavaScript - Chesco_
http://feederio.com/book/36/beautiful-javascript-functional-javascript
======
dahart
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 doesn't need to be fast - which is
admittedly most code. But performance matters often enough that I can't adopt
a single functional style even though I wish I could.

Will there be a time when going functional will be not just the fast way to
write code, but the way to write fast code? Are there efforts to create high
performance functional primitives that are easy to use and also outperform
their imperative alternatives? I've used numpy, for example, and I wouldn't
necessarily put it in the easy to use category. I'm hoping one day I can write
straightforward functional code and have it not be so much slower than
imperative code that I have to question which one I should use.

~~~
LeanderK
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 compiler is
rich type-info that makes many optimisation techniques possible or easier
(this is important) to implement. While it's kinda boring, just look at
haskell what possible there with rewrite rules. In a way it's possible to
write your own compiler optimisation for your library.

In JS it's way harder because JS is untyped and the type system is way, way
more complicated. Many of the hatches you use to optimise your program make it
harder for the compiler to optimize your program. And i know about JIT-
compiler, they are really complex beasts and the only way to tackle a language
like JS. Just look (again) at Haskell, i always wondered what a really, really
god JIT-compiler would look like. I would think that all the optimisation that
you get by just using some pragmas would be only "engineering" work and don't
require some fundamental breakthroughs. Especially if you consider the huge
amount of time that went into something like the JVM.

~~~
crooked-v
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.

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

~~~
crooked-v
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.

------
jw-
"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 languages. Really, much of that list is not
fundamental to FP, but always giving me an Int when you promise one matters.

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

~~~
smallnamespace
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.

------
simanyay
Author/editor of Beautiful JavaScript here. I'm very confused by this website.
It appears somebody took one chapter (Functional JavaScript) and re-published
it as a book.

If you want to purchase the complete book do it from the O'Reilly website or
from Amazon. All proceeds go to EFF.

------
k__
"Given that JavaScript’s author was recruited to do “Scheme in the browser,”"

Didn't he disclaim that multiple times?

~~~
erik14th
"As I’ve often said, and as others at Netscape can confirm, I was recruited to
Netscape with the promise of “doing Scheme” in the browser."[0]

I guess what you're confusing is that he disclaims that it is inspired mostly
on scheme:

"I still think of it as a quickie love-child of C and Self."[0]

[0][https://brendaneich.com/2008/04/popularity/](https://brendaneich.com/2008/04/popularity/)

~~~
lisivka
«I’m not proud, but I’m happy that I chose Scheme-ish first-class functions
and Self-ish (albeit singular) prototypes as the main ingredients. The Java
influences, especially y2k Date bugs but also the primitive vs. object
distinction (e.g., string vs. String), were unfortunate.»

So JS got ideas from Scheme, Self, and Java.

~~~
erik14th
That's what I meant by "mostly". Indeed it does have influence from scheme but
it is not "scheme in c clothing" as people have put it.

------
wyager
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
matter is that JS doesn't support 99% of the modern tools that actually make
functional programming useful and not just a parlor trick. JS is missing
everything from ADTs (possibly the single best thing to come out of early
functional languages) to a type system. There are a few bolt-on structural
type systems available (like Typescript), but they still don't get you even
close to the full power of modern functional languages.

~~~
baron816
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 a big deal.

And I love writing JavaScript with a bit of a functional lean to it. I think
it makes it much easier to reason about the code. Of course it's not purely
functional, but it's still better than if I wrote it the way many people do.

~~~
catnaroek
> 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, not just whipping something
together by gluing libraries foo, bar, qux), but several parts of its
semantics continue to baffle me. Like “this”.

~~~
baron816
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.

~~~
Roboprog
That's how I feel. It's an otherwise pretty good language saddled with a bunch
of misfeatures that the pointy-haired management wanted. (starting with the
name itself)

Ignoring this/prototype and just using literals and closures goes a long way
in simplifying JS, even if it's not as "performant" (formerly, "fast") at
firing off that REST call when the user clicks that button. I'm not in a
situation to use something like Node on the server, so I'd rather save my
development time than a few nanoseconds of the computer's. (managing load
times on web clients seems to be 95% of the bottlenecks for what I'm doing
lately)

------
dogismycopilot
Do we only get Chapter 14? It's nice, but it's only 8 pages.

------
z3t4
in es5 you can use defineproperty to lock and control get and set. In es6
theres tail call optimization.

linters and static analysis in JS is still young, but will complain about type
mixing and mutables.

------
z3t4
i love that you can require modules in node.JS functions. Having functions
that dont depend on outside variables makes programming so much faster and
easier. Being able to name functions also makes the code easy to understand
and debug.

