Even then, I think we all understand that the OP isn't trying to be strictly pure and is simply trying to explain the concepts in a manner that those used to imperative development can easily digest.
2. No product types. You can emulate those, but it's awkward.
3. No recursion over lists. You can emulate this, but it's awkward.
4. It's difficult to write code that is efficient, yet is side-effects free. Good luck with prepending an element to a list.
About emulation, you can emulate closures on Turing machine, though it doesn't make Turing machine a functional language. Lack of the aspect is simply lack of the aspect.
And no, JS doesn't explicitly prevent functional programming (or rather, some aspects of it). It does so implicitly.
> OP isn't trying to be strictly pure and is simply trying to explain the concepts in a manner that those used to imperative development can easily digest.
It's like trying to show how to do OOP in C. It's a different paradigm than the primary of the host language, so any educational aspect will be severly diluted, to the point of being useless to anybody who doesn't already know functional programming.
Actually, I'd think that would be a super valuable to a C developer. Learning to implement OOP patterns in C would provide practical patterns that can help architect C software. For non-C developers, it'd also provide fundamentals of how OOP actually works. C developers have been implementing OOP patterns since well before C++ existed.
There's lots of resources, and practical examples of this. GObject provides an object system used by both Gnome and GTK. Check out "Object-Oriented Programming With ANSI-C" for a book on the subject.
It's similar with functional programming. Figuring out folds, pattern matching and monads is probably easiest in haskell or Ocaml/F#. The decision to apply those techniques in other languages without native support then becomes a judgement about the benefit.
Says who? I've taught OOP, as a concept, to people using C. It's incredibly obvious when you see it written--once you've implemented inheritance through structural composition, it's strikingly easy to reason about how traditionally OO languages handle their object models.
(This is basically what GTK does!)
Otherwise, OOP is just this black box that has "you know, classes and objects and stuff".
Similarly: you can build a simple LISP in Javascript. You can write an event loop in C. You can implement Hindley-Milner type inference in Python. These are all great exercises in understanding exactly what these components of different programming languages do :)
2. Would probably make more sense if it were a statically typed language. Don't most dynamically typed FPL need to emulate this?
3. Got an example of it being awkward that isn't helped with ES2015?
4. (item, list) => [item].concat(list)
Pretty much how I learned OOP:
http://www.amazon.com/Class-Construction-Object-Oriented-Programming-Fundamentals/dp/0136301045
What do you mean by no recursion over lists? I mean, sure, lists aren't a core data type in JS (JS arrays aren't lists), so list operations aren't either, is that it?
Do you mean sum types?