Which is mostly what used to be, 10 years ago. Closures, map, fold, etc. Before Haskell and Clojure like immutability and extra trimmings became fashionable...

In 1995 or even 2000 era LISP discussions you rarely if ever see those other concerns about FP that hipster functional programmers bring forward today.

(I guess it's also something that was helped by Moore's Law style speed development slowing down and the advancements in multicores...)

Quite right, back on those days FP was Smalltalk (yes really), Scheme, Common Lisp, Emacs Lisp, Caml Light (no OCaml yet), Standard ML and Miranda (no Haskell yet).

Which like you mention is where I point those hipsters to.

Then again, all new generations think they know best.

FP doesn't even have a definition (though pure-FP does, but it, too, can be a bit ambiguous and depends on how you define effects). FP is mostly accepted to be those patterns practiced by people in the FP community. I heard someone deeply involved with FP say, "FP is more a community than a well-defined programming style".

Language evolves; "FP" today means something different from what it meant 10 years ago. There's no need for dismissiveness in either direction.

I agree. One thing that is sorely missing, for example, is a way to define recursive values.

In Scala, to express a recursive parser combinator:

val e = p | e

You can't define such a thing in Kotlin. Atleast, this was the case the last time I looked at it.

Wow can you really write

    val e = p | e

in Scala? How does that work with eager evaluation?

It's not eager. The | combinator takes lazy parameters (called pass-by-name in scala). So it essentially gets translated to:

val e = operator_pipe(() => p, () => e)

Note that the operator_pipe() itself returns a function, which gets assigned as a value to `e`. So there is lots of implicit laziness.

(disclaimer: I think Kotlin is cool)

And non-lazy map/reduce/filter. Which I almost see as a deal-breaker.

Kotlin does have lazy map/reduce/filter: those are available through the Sequence interface.

It's very limited. Many of the functions you use when operating with collections also return lists, not sequences.

Sequence has much the same extensions available on it as other collections.

I did a tutorial a week or so ago (it's not online yet, unfortunately) on FP in Kotlin. We wrote a little app to do IntelliSense style autocompletion on an n-gram model. The core code was purely functional and used lazyness as well.

I suspect "does Kotlin support FP" is one of those questions that's doomed to turn into a no-true-scotsman thing: whatever support is available will be considered insufficient by true FP fans :-) But it's good enough to let you write code in a typical functional style in many cases, with little cost.

It's not that hard to implement your own stream abstraction.