Hacker News Reader

Comment by noelwelsh | Hacker News Reader

> Now that (nearly) every mainstream language has lambda expressions, there are very few patterns in functional programming that cannot be replicated in mainstream languages

I don't think this is true. Algebraic data types and exhaustive pattern matching, which implies a type system, are the things I use most in my adventures in functional programming. Mainstream languages (for some definition of mainstream) don't yet have these features.

The original post doesn't mention pure FP. I don't think purity is that interesting when you can have a type system that can reason about mutation (i.e. linear or affine types, similar to Rust.)

View on HN

It's also a matter of performance. Functional non-mutating patterns in JavaScript and Python can be substantially, sometimes catastrophically, less performant than the procedural/imperative mutating equivalents. All functional programming languages that I know of which have decent performance rely on an optimizing compiler to some extent, and/or core data structures that have been optimized for immutability.

Python bogs down where there is excess use of the dynamic aspects, e.g., a large list comprehension.

Go with a generator, and watch that list be more kind to the resources.

> Python bogs down where there is excess use of the dynamic aspects, e.g., a large list comprehension. Go with a generator, and watch that list be more kind to the resources.

This is a micro-optimization and it's not always true. Generators usually use less memory, but list comprehensions can actually be faster because the memory gets allocated all at once and the loop is performed internally inside the interpreter, instead of the generator possibly being consumed as a slow top-level loop.

I was talking about examples like making a copy of a list/dict/object instead of replacing elements in-place, or using a stack of map/filter operations instead of a single-pass for-loop with dynamic programming.

Fair point, especially in the case of network-bound or disk-IO intensive work.

Python supports generator comprehensions too!

The thing that really irks me is that the generator pattern doesn't have to be an OO-first feature. Observable streams[1] work with the same basic foundation and those are awesome for FP. It's really frustrating that standard libraries are so eager to adopt generators without taking that last step into supporting functional stream consumption.

[1]: https://reactivex.io/

> Functional non-mutating patterns in JavaScript and Python can be substantially, sometimes catastrophically, less performant than the procedural/imperative mutating equivalents

What portion of this is due to the fact that you're using a functional pattern on an imperative language? For example, none of those attempts can take advantage of any underlying purely functional data structures (see: Erlang/OTP/Elixir, or Clojure)

Case in point: Tail Call Optimization has been part of the JS spec since ES6, but remains completely unimplemented in all mainstream browsers/engines besides Safari[1]. For all but the most predictable inputs, you're pretty much forced to use loops due to potential overflows in situations where recursion might otherwise be preferable.

More fuel for the pyre: async Iterables cannot be consumed as a piped stream. You must use the for await construct, which is a shame considering the FP niceties that the Array type already provides for more traditional lists. Once again, one is forced by the API to use an imperative construct unless they specifically want to invite trouble by converting it into an Array (... and potentially choking in the process)

[1]: https://kangax.github.io/compat-table/es6/

In practice I feel like recursion isn't actually used that much in functional languages. Most things can be expressed as maps, flatmaps, folds, etc

It depends on the domain. For example, recursion can be extremely useful when processing a tree of data.

Kotlin and Java now have sealed classes/interfaces, which can provide exhaustive pattern matching and as far as I can tell can be used to model any ADT.

EDIT: In fact, both languages are now listed as having ADTs on the Wikipedia page: https://en.m.wikipedia.org/wiki/Algebraic_data_type

Also, TypeScript's union types can express ADTs, and Rust's enums. I don't think it will be very long before the rest of the mainstream languages catch up.

Agreed, but that's why I hedged with "some definition of mainstream". I don't think Kotlin or Rust are mainstream yet, most Java places are still on Java 8 or 11, and ADTs in Typescript are a PITA.

I wouldn’t be surprised if there would be more people on Java 19 than on Haskell, for what it’s worth.

ADT's in TypeScript aren't as nice as in a language that supports them natively in many respects, but "PITA" is really overselling it. We use them pervasively at my shop. In fact, the ability to synthesize them without naming them (because TypeScript is structurally-typed instead of nominally) sometimes makes them even more convenient than in most FP languages (OCaml excepted) - the ability to, say, return an ad-hoc ADT from a lambda without giving it some meaningless name like "HelperFunctionResult" can occasionally be really handy.

ADT's and exhaustive pattern matching are in Rust. The way you wrote your comment makes it clear that you know that, but might as well make it explicit.

IMO, people come to Rust because of memory safety, but they stay because of ADT's and similar features.

Algebraic data types and exhaustive pattern matching Are a core part of Rust.

Rust, but practically no other mainstream or OO/imperative style language

Swift, kotlin, Java

also Scala, which I'd take over Java any day

Ada might be getting pattern matching soon too:

https://github.com/AdaCore/ada-spark-rfcs/blob/master/protot...

There is no proper pattern matching / destructuring in either Java or Kotlin.

There is a discussion about it in Kotlin, see https://youtrack.jetbrains.com/issue/KT-186/Support-pattern-...

Rust has ADTs and it has exhaustive pattern matching AND it's not functional. It's arguably mainstream now.

Haskell doesn't have exhaustive pattern matching it just gives you a warning.

> Haskell doesn't have exhaustive pattern matching it just gives you a warning.

It can have exhaustive pattern matching if you use `-Werror`.

That's frequently the default in an industrial Haskell setting.

I wish that non-exhaustive patterns would be an error by default though.

Reply on news.ycombinator.com