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 ES6 spec, last I heard there was some question of whether it would actually be implemented for web browsers.

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

OK, so "Haskell > Scheme", or some such. Any specifics beyond "ADTs", which I assume means Abstract Data Types - interfaces/polymorphism.

If IDEs ever get good enough to do near complete type inference, including reading through partial function application, and perhaps an "extract/move function" refactoring that converts closures to parameters, most of the class/type bondage and discipline may look a bit like a waste in retrospect.

Having worked in both static and dynamic type systems since the 80s, I've developed a bit of a "cringe" mechanism at the repetitive code that usually comes out of "strongly" typed languages. "This time it's different", but it never seems to be :-(

> Any specifics beyond "ADTs", which I assume means Abstract Data Types

No, I meant algebraic data types, although interfaces/typeclasses are great as well.

> If IDEs ever get good enough to do near complete type inference, including reading through partial function application,

I don't use any IDEs, but Haskell does this. I imagine various Haskell plugins do as well.

> and perhaps an "extract/move function" refactoring that converts closures to parameters,

I'm not sure why you want this so much, but it does exist. I've done this exact thing with Idris's interactive UI.

> I've developed a bit of a "cringe" mechanism at the repetitive code that usually comes out of "strongly" typed languages.

If there is one phrase that I would use to describe Haskell, it's "zealously anti-repetitive". If the Haskell community sees you writing the same line of code twice, they'll swoop down and beat you over the head with a well-designed typeclass until you stop repeating yourself.

Thanks for the response. Alas, here in "fly-over country" (Sacramento), it's all Java and some Javascript (or .NET, if you've been naughty). There's scarcely any Scala, let alone Haskell work to get or see here.

So, my background tends to be that I'd much rather do JS than Java. The JetBrains IDE's actually do a pretty good job at analyzing JS, despite JS's assumed inferiority. One day Java the language/syntax will be dead, and I will recover from the trauma it has inflicted upon me the last 10 years or so :-)

Fortunately, BS-CS programs still taught other languages beside C -> C++ -> Java in the early 80s, so I at least got to learn some Common Lisp back then (among other things), though not Scheme. Consequently, I'd like to move on from 1960s tech (e.g. - Simula 67) to 70s tech (e.g. - Scheme). Never learned me a Haskell yet. I suppose I should since it's got interesting stuff like currying built into the language itself rather than duct-taped on the side.

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.

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 functional programming when you apply these sorts of practices to your JavaScript code?

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.

Clojure(Script) is easy to learn. Especially if you compare it to Haskell. The core of the language is quite simple but leaning standard libraries will take time. This is a good place to start http://clojurescriptkoans.com

> 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”.

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.

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.

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)

I didn't make any value judgments. Note the absence of the words “good” and “bad” in my previous comment.

Back on the original topic. What I said is that JavaScript is complex, not that it's bad. It may well be the case that JavaScript's complexity is essential for solving the problems it tries to solve. But you can't deny that the complexity exists. And you can't just wish existing language features out of existence, because the meaning of your code is given by what others can do with it.

In short: JavaScript probably has some simple subset. But, then, so does C++, famously.

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.

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.