Hacker News Reader

Comment by gameswithgo | Hacker News Reader

I also value F# for reasons that have very little to do with functional programming. I like the sum types, I like the generics, I like the syntax, but when I make things with it I do not get very functional, in fact I find the more aggressively functional approaches to be extremely confusing to reason about. Where functions take in partially applied functions and so on, it is very hard to read. Maybe thats fundamentally true, maybe it is just me, I don't know.

View on HN

> Maybe thats fundamentally true, maybe it is just me, I don't know.

I think the ergonomics of a high degree of functional programming haven't panned out to be real crowd pleasers just yet, so you're not alone in thinking that.

I mean, `List.map` is often used in a partially applied manner and, used in conjunction with the pipe operator, results in, imho, readable code:

[1;2;3;4] |> List.map ((*) 2) |> List.reduce (+)

what would the equivalent code without partial application look like here?

Also, this is another pet peeve about 'functional style' F#, the use of actual Linked Lists, which is a huge performance pitfall to accept on modern hardware.

And also that F# Seq are not well optimized.

F# Seqs are .NET IEnumerables, which is to say they are iterators. They're lazy, and you can do things with them that you can't do with "strict" collections. In some ways they are faster than strict collections, in others they are slower. If you plan to be iterating over a Seq multiple times, you should probably turn it into a list or array first, just like in C#.

That example without pipes is

  List.reduce (+) (List.map ((*) 2) [1;2;3;4])

Linked lists are common in any functional programming language, the performance is bad but that only matters if you're writing something performance-critical. Otherwise, the ergonomics dominate: lists are very easy to work with.

I know what Seq is. C# IEnumerables already have more overhead than iterators in C++/Rust due to historical reasons that can't easily be unwound now, and F# Seq adds a bit more on top, it isn't horrible it is just too bad.

The ergonomics of LinkedLists really aren't any different than could be achieved with an array backed List, it just isn't done. I realize part of that is because it facilities immutable data structures, but they are often used when that isn't happening.

F# adds no overhead compared to IEnumerable<T> for comparable processing. Seq is a type alias, which is a compile time construct. Generating them is different as there are more ways to do that in F#.

> The ergonomics of LinkedLists really aren't any different than could be achieved with an array backed List, it just isn't done. I realize part of that is because it facilities immutable data structures, but they are often used when that isn't happening.

It still isn't as simple in implementation as a linked list, but they really shouldn't be used except as immutable data structures. That's the only reason I use them.

Phillip mentions this below but F#'s Seq does not add overhead to IEnumerable, it is exactly the same as IEnumerable.

I'm curious about what you see as the unavoidable overhead in IEnumerables, though.

Reply on news.ycombinator.com