3 ms·
good default behavior and how it nudges programmers to favor predictable and composable solutions Agree. Mark Seeman calls these the "Functional pits of succe
by kirse 6y ago
good default behavior and how it nudges programmers to favor predictable and composable solutions
Agree. Mark Seeman calls these the "Functional pits of success"
https://www.youtube.com/watch?v=US8QG9I1XW0 https://www.youtube.com/watch?v=US8QG9I1XW0
I think the toughest thing about F# is that it doesn't offer as many Google-able easy solutions, so I'm stuck using it for utility and client libs at work. Trying to get a whole team onboard is a non-starter. It takes a good 6-12 months to adjust the mindset and most people are just looking to come into work, find their tough questions on StackOverflow and head out for the day.
- thelazydogsback 6y agoReactoring and reuse is a bit of a pain compared to functors or typical OO code in C#, etc., esp. moving from idiomatic F# to to more performant code, when this is needed. For example, I may use a List at first, as it's natural to start with and offers niceties with [H|T] pattern matching or List.filter() somewhere, then if I decide to use a .Net List (ResizeArray) or Array or Set instead, I'm screwed. The pattern matching needs to either change syntax or go away, and all the List.Foo() calls need to change to Array.Foo's or whatever -- or I have to use Seq.Foo() everywhere to get extensibility even I don't want to pay for lazy evaluation. Long time F# fan here! -- but still some sore points.