3 ms·
For me one of the biggest hurdles is using immutable data structures all the time. In the real world you want to add to a list or change a map's value. Typicall
by lz400 9y ago
For me one of the biggest hurdles is using immutable data structures all the time. In the real world you want to add to a list or change a map's value. Typically functional programming languages use linked lists to make h::t efficient but if you need performance characteristics of arrays and good performance/low GC you are going to have a lot impedance mismatch with the typical functional programming patterns based on built in lists.
- eyelidlessness 9y ago> In the real world you want to add to a list or change a map's value. Having spent a good amount of time doing production FP, and then taking what I learned into imperative work, I rarely find myself doing this. In the real world, what we usually want is the result of adding to a list or changing a value in a map. But also in the real world, we rarely want to consider whether we've affected other things that supplied that list or map (which they generally would prefer we did not do). > Typically functional programming languages use linked lists to make h::t efficient but if you need performance characteristics of arrays and good performance/low GC you are going to have a lot impedance mismatch with the typical functional programming patterns based on built in lists. I can't speak for the wide variety of FP languages out there, but it sounds like you've been exposed to languages with a poor set of data structures. Clojure, for example, provides a wealth of great immutable/persistent data structures that provide the semantics you'd want and perform really well.
- lz400 9y agoI've done a bit of functional programming too and don't get me wrong, I love the FP cultural victory of Java/C# etc. getting immensely useful functions like map, reduce, filter, lambdas and higher order functions. But if you are going to use purely immutable data structures you're going to make trade offs. In the kind of work that I do generating excess garbage or using extra memory can be unacceptable so I think I'd struggle with that but I can still apply a good % of FP principles with mutable structures of course. If you read introductory functional programming material, you will agree they are full of h::t style pattern matching and default list types in ocaml, haskell and scala are simple linked lists (I sadly haven't tried Clojure yet). I'm open to the possibility of advanced patterns with other data structures overcoming some of these problems that I'm not very familiar with but that's what I mean with impedance mismatch, you will need to step away a bit from the clean elegant patterns of "everything is recursion+pattern matching on lists" of typical FP teaching.
- gizmo686 9y agoAnd if you do any serious functional programming, you will quickly learn that using these lists as a data structure is almost always a mistake. A mistake that happens to be encouraged by the language, but that is largely a historic wart of languages that are decades old at this point.
- lz400 9y agoSure, agreed, but even if you use more sophisticated immutable structures you either accept the performance/memory trade offs or you have to fall back on mutable structures.
- tome 9y agoBut that's quite a different claim from your original one!
- lz400 9y agoMaybe it helps if I explain better. I find it difficult to use immutable structures if I want certain performance characteristics. It's possible I need more training in certain techniques, but I think that's why I find it difficult, the default data structures and introductory literature seems to be too naive. And in the end, no matter what I use, there will be certain trade offs for purely immutable structures, and some stuff I just think it's easier to think about in mutable terms.
- tome 9y agoOK, that's a reasonable position. It is easy to read your original claim as "All real world programming requires mutable values", and that is certainly not a reasonable position.
- tome 9y ago> In the real world you want to add to a list or change a map's value Do you? I don't. I've written loads and loads of production code that never did this. I know it never did it because I wrote it in Haskell and never used an IORef or STRef!
- lz400 9y agoI do. I'm not saying it's not possible to reach that state. Just that there are many things I tend to find easier to think about in mutable terms. And when trying to implement immutable equivalents there are also trade offs. I don't start from the point of view that functional programming is superior and everything should be done in terms of lambda calculus and purely functional data structures. I also don't deny that is good for some, maybe many use cases.
- tome 9y agoIt's fair enough if those are your needs but I think your comment would be better expressed as "For the sorts of programming I do I want to add to a list or change a map's value". Otherwise you give uninformed people the impression that Haskell cannot be used for "real world" programming. It can be and it is.
- lz400 9y agoOk you are right, now that I read what I wrote it could be interpreted that way and it wasn't my intention at all. I know Haskell can be used for real world programming because I own a book called "real world haskell" :) I was abusing the expression to put forward a case in which I believe the mutable thinking comes across as more natural (imo).
- tome 9y agoFair enough. Language is rather ambiguous!