10 ms·

Functional Programming in a Dysfunctional World

93 points by GarethX 11y ago

vezzy-fnord 11y ago
Virtually all of the concepts that the author listed are completely orthogonal to functional programming, and moreover FP is equivocated with statically typed FP.
- chc 11y ago
  It seems pretty obvious from context that the author is discussing Haskell's flavor of functional programming in particular. It's somewhat lazy phrasing, but it doesn't seem unclear to me if you read more than the headline (and if you didn't read more than the headline, you wouldn't know he was talking about something more specific anyway).
- nickpsecurity 11y ago
  What's the best resources you would recommend for someone to really wrap their head around functional programming, foundations and practical use?
  - yogthos 11y ago
    I hear people find my Clojure Distilled guide helpful for understanding the general concepts https://yogthos.github.io/ClojureDistilled.html https://yogthos.github.io/ClojureDistilled.html
    - nickpsecurity 11y ago
      Thanks for the link. Not quite what I'm looking for but I'll keep it for when I try Clojure.
  - pdpi 11y ago
    Learn You a Haskell For Great Good is a great introduction, if you're willing to just pretend you know nothing of programming for a little while.
    - nickpsecurity 11y ago
      I was uncertain at first if I was reading a book title lol. Haskell is usually a tough learning experience. I'll keep the link and check it out. Might need to learn it anyway given the seL4 and lots of Galois's work (eg Ivory language) is using Haskell. Figure it's better to start with it than Ocaml given that Haskell doesn't give an imperative programmer many outs. Gotta learn the concepts or leave haha. "if you're willing to just pretend you know nothing of programming for a little while." Always good advice for learning a new paradigm. I learned this when smart people taught me how to learn a foreign language. They said learn the concepts fresh, do no mental translations, and immerse yourself where you're forced to solve problems in that language. It's how we learn the native one's so why not new ones.
      - codygman 11y ago
        > Haskell doesn't give an imperative programmer many outs. What do you mean? Check these out: http://www.haskellforall.com/2012/01/haskell-for-c-programmers-for-loops.html http://www.haskellforall.com/2012/01/haskell-for-c-programme... http://www.haskellforall.com/2013/05/program-imperatively-using-haskell.html http://www.haskellforall.com/2013/05/program-imperatively-us...
        nickpsecurity 11y ago
        Closer, but not quite. One commenter there pointed out that you still need foundational stuff to really get it. Otherwise, you're just seeing templates without really understanding what they mean. That's kind of what I meant. Nothing wrong with it, necessarily. I'm just saying people learning it say there's not many shortcuts around learning it.
        pdpi 11y ago
        That's a good thing in my book. It takes you longer to get productive, of course, but, when you DO get there, you're on much more solid footing
pdpi 11y ago
"A nice side effect (hmm) of immutability is you end up with pure functions." No, immutability doesn't magically give you purity. E.g. Rust gives you immutability by default, yet you don't need anything to be mutable to get IO.
- teacup50 11y ago
  IO is by-definition mutation.
kstenerud 11y ago
The Virtus issue is simply an example of bad design. When you add magic that can't be guaranteed by the language, you're eventually going to run into problems. Just look at Hibernate. As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry. And advanced type systems are not unique to functional languages. I'm also not clear on why the example testing code is better. It doesn't look much different from what I'd write in any language (excepting boilerplate). So yeah, correctness and testability. It's available in most languages. Also, what's up with all the single-letter variable names?
- donjigweed 11y ago
  << As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry. All of the FP languages I'm familiar with provide easy access to mutable collections.
- sbergot 11y ago
  > a language with no mutable types If we are talking about haskell, mutability is absolutely an option when it is the only way to write fast code. This is exactly what is done here: http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-ways-are-the-best/ http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-... > And advanced type systems are not unique to functional languages. "Advanced type system" does not really mean much. A bit like the weak/strong static typing distinction. However there are still significant differences between the c#/java/scala family and the haskell one. The fact that objects are not nullable by default and the absence of subtyping are considered as two big advantages for many people. > Also, what's up with all the single-letter variable names? when the code is abstract and the scope of a variable is less than three lines, it can be ok to use one letter for its name.
- the_af 11y ago
  > As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry. There are always escape hatches for when you absolutely need mutability. > And advanced type systems are not unique to functional languages. True. It's just that a lot of progress (but not all, of course) in advanced type systems is pioneered by languages which are often described as functional. > So yeah, correctness and testability. It's available in most languages. Correctness and testability are properties of the software, not the language. As such, of course you can achieve them with your favorite one. But some languages provide better tools to achieve some degree of correctness and testability which would require a greater effort with other languages. > Also, what's up with all the single-letter variable names? This is standard practice in many functional languages. Whenever the abstractness goes up (or the "more general" something is), the identifiers become shorter, since the name itself "means less". Hence why you see code that does something to every x in some kind of container xs; what would you gain with longer identifiers, except maybe misleading the reader?
agentultra 11y ago
The idea that "memory doesn't matter" and "we're mostly waiting on the network anyway" seems like red herring. It's not a "micro-optimization" to think of your data first. A program is a sequence of transformations on a stream of data. Figure out what your data is and how you want to transform it and your program will become evident. FP is a fine tool for programmers to have but you still have to think about the data regardless. If you don't realize how the allocator works in your VM you might end up fragmenting your pools and over-allocating virtual memory for a simple process. For some applications that might matter.
- nudpiedo 11y ago
  I found it correct: what the says is that we should focus first on the actual bottlenecks before we worry about other optimizations; not that we should just look to another side. If your bottle neck is in that point (copy of data structures) then there are functional data structures as well. And if still your performance is so critical in that point you can use a mutable data structure which is thread safe, and separate data from code in the rest of your code having still a big chunk of functional code where it is easy to reason about.
  - agentultra 11y ago
    I am referring to data-oriented design[0], not optimization: thinking about your data, access patterns, and transformations is not a premature optimization in the Knuth-ian sense. It's just plain, old engineering. It's not incorrect per-se, just misleading in my opinion. [0]http://dataorienteddesign.com/site.php http://dataorienteddesign.com/site.php
- nickpsecurity 11y ago
  I agree that it's foolish to ignore memory issues. We've had horrific performance and scaling in much software that did that. Anyone thinking otherwise can feel free to disable their processor or app cache to see how unimportant memory concerns are. ;) Any HLL should give performance-concerned designers a clear, mental model of the performance aspects of their code. C and C++ programmers, for instance, understand the costs of their abstractions, how to code in a cache-efficient way, and so on. I read on the old LISP web sites and mailing lists where they similarly could estimate the cost of certain constructions and had tricks to squeeze out extra performance that they hid behind macros, etc. So, I'm sure these other functional languages can do something similar.
wcummings 11y ago
> you have to be wary of using Java and .NET types which are still prone to NPEs Java8 optionals are a maybe monad http://stackoverflow.com/a/19932439/4658666 http://stackoverflow.com/a/19932439/4658666
- quchen 11y ago
  I think your post only takes non-null values into account, which is what OP seems to talk about. What would this code do? Optional<Int> foo = null; foo.flatMap(x -> Optional.of(x)); Obeying the Monad laws would mean getting null as a result, via `m.flatMap(x -> Optional.of(x)) = m` for all m (or `m >>= pure = m` if you prefer Haskell syntax).
  - deleted 11y ago
    [deleted]
rdtsc 11y ago
> Did you ever attempt to get to the bottom of an intermittent error that was driving you insane, only to discover much later that a private variable wasn’t synchronized properly? Have you ever spent hours stepping through the lifecycle of an object, going through many different components spread out across the codebase and wished that you had spent all that time solving new problems instead? I see 3 issues here. 1) Most people haven't dealt with those issues enough. There are complex programs but there are also many simple program as well. And unless one deals with hard to debug concurrency / pointer / mutable state errors they will not appreciate immutability. They might pay lip service to it, because it is cool, but they will not appreciate it enough to start rewriting their codebase in it. That is a bit like fault tolerance, unless they have been woken up at 3am because their main larger server process segfaulted and had to debug, they will not think about isolated units of failure, about supervision, durable peristent snapshots/checkpoints, monitoring etc. They of course will say that "fault tollerance is good" but it is good in an abstract, general way. 2) Those that dealt with these issue might accept the state (pun indended) of affairs and never realize there is another way of doing things. I mean they just accept that you have to have locks and mutable state and mutexes and dangling pointers and then spend months debugging hard to track concurrency errors at 3am. That is just how software development works and it is as good as it gets. 3) People realize there is something better, they know about, read about, played with it. But they don't have enough energy, political power, or time do fix it.
- golergka 11y ago
  > Most people haven't dealt with those issues enough This really surprises me. Surely, most programmers have experience with big and complex codebases with a lot bugs coming from mutable state, no?
  - rdtsc 11y ago
    For 1) I meant that there are lot of utilities, micrservices, small web backends, scripts, and hopefully, applications that have already been split into isolated components that can fail and restart separately (in other words someone did the work already). So if one starts dealing with those in their careers they just might never have a compeling reason to look at Haskell, F#, Erlang, OCaml and such. Also note that quite often one way to deal with large mutable state is to simply shove it in database. Usually good databases just make it explicit what happens to shared state.
z3t4 11y ago
If your program has state, it doesn't matter if it's mutable or immutable state, you will still run into the same problems when working with concurrency. You either have to use locks, make sure functions are executed in the right order, or the preferred way: designate/central state. So functions vs object orientated is mostly a matter of preference. One advantage with functional programming though, is that it will be much easier so serialize the state.
- JBiserkov 11y ago
  I respectfully disagree. I also encourage you to take a look at http://clojure.org/state http://clojure.org/state
- codygman 11y ago
  > If your program has state, it doesn't matter if it's mutable or immutable state, you will still run into the same problems when working with concurrency. You either have to use locks, make sure functions are executed in the right order, or the preferred way: designate/central state. What about using STM: https://www.fpcomplete.com/school/advanced-haskell/beautiful-concurrency/1-introduction https://www.fpcomplete.com/school/advanced-haskell/beautiful...

93 points by GarethX 11y ago

Virtually all of the concepts that the author listed are completely orthogonal to functional programming, and moreover FP is equivocated with statically typed FP.

chc 11y ago
It seems pretty obvious from context that the author is discussing Haskell's flavor of functional programming in particular. It's somewhat lazy phrasing, but it doesn't seem unclear to me if you read more than the headline (and if you didn't read more than the headline, you wouldn't know he was talking about something more specific anyway).
nickpsecurity 11y ago
What's the best resources you would recommend for someone to really wrap their head around functional programming, foundations and practical use?
- yogthos 11y ago
  I hear people find my Clojure Distilled guide helpful for understanding the general concepts https://yogthos.github.io/ClojureDistilled.html https://yogthos.github.io/ClojureDistilled.html
  - nickpsecurity 11y ago
    Thanks for the link. Not quite what I'm looking for but I'll keep it for when I try Clojure.
- pdpi 11y ago
  Learn You a Haskell For Great Good is a great introduction, if you're willing to just pretend you know nothing of programming for a little while.
  - nickpsecurity 11y ago
    I was uncertain at first if I was reading a book title lol. Haskell is usually a tough learning experience. I'll keep the link and check it out. Might need to learn it anyway given the seL4 and lots of Galois's work (eg Ivory language) is using Haskell. Figure it's better to start with it than Ocaml given that Haskell doesn't give an imperative programmer many outs. Gotta learn the concepts or leave haha. "if you're willing to just pretend you know nothing of programming for a little while." Always good advice for learning a new paradigm. I learned this when smart people taught me how to learn a foreign language. They said learn the concepts fresh, do no mental translations, and immerse yourself where you're forced to solve problems in that language. It's how we learn the native one's so why not new ones.
    - codygman 11y ago
      > Haskell doesn't give an imperative programmer many outs. What do you mean? Check these out: http://www.haskellforall.com/2012/01/haskell-for-c-programmers-for-loops.html http://www.haskellforall.com/2012/01/haskell-for-c-programme... http://www.haskellforall.com/2013/05/program-imperatively-using-haskell.html http://www.haskellforall.com/2013/05/program-imperatively-us...
      - nickpsecurity 11y ago
        Closer, but not quite. One commenter there pointed out that you still need foundational stuff to really get it. Otherwise, you're just seeing templates without really understanding what they mean. That's kind of what I meant. Nothing wrong with it, necessarily. I'm just saying people learning it say there's not many shortcuts around learning it.
        pdpi 11y ago
        That's a good thing in my book. It takes you longer to get productive, of course, but, when you DO get there, you're on much more solid footing

pdpi 11y ago

"A nice side effect (hmm) of immutability is you end up with pure functions." No, immutability doesn't magically give you purity. E.g. Rust gives you immutability by default, yet you don't need anything to be mutable to get IO.

teacup50 11y ago
IO is by-definition mutation.

kstenerud 11y ago

The Virtus issue is simply an example of bad design. When you add magic that can't be guaranteed by the language, you're eventually going to run into problems. Just look at Hibernate. As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry. And advanced type systems are not unique to functional languages. I'm also not clear on why the example testing code is better. It doesn't look much different from what I'd write in any language (excepting boilerplate). So yeah, correctness and testability. It's available in most languages. Also, what's up with all the single-letter variable names?

donjigweed 11y ago
<< As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry. All of the FP languages I'm familiar with provide easy access to mutable collections.
sbergot 11y ago
> a language with no mutable types If we are talking about haskell, mutability is absolutely an option when it is the only way to write fast code. This is exactly what is done here: http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-ways-are-the-best/ http://www.serpentine.com/blog/2015/05/13/sometimes-the-old-... > And advanced type systems are not unique to functional languages. "Advanced type system" does not really mean much. A bit like the weak/strong static typing distinction. However there are still significant differences between the c#/java/scala family and the haskell one. The fact that objects are not nullable by default and the absence of subtyping are considered as two big advantages for many people. > Also, what's up with all the single-letter variable names? when the code is abstract and the scope of a variable is less than three lines, it can be ok to use one letter for its name.
the_af 11y ago
> As far as performance goes, once you commit to a language with no mutable types, you have no recourse once you discover a bottleneck due to immutability. That's a big worry. There are always escape hatches for when you absolutely need mutability. > And advanced type systems are not unique to functional languages. True. It's just that a lot of progress (but not all, of course) in advanced type systems is pioneered by languages which are often described as functional. > So yeah, correctness and testability. It's available in most languages. Correctness and testability are properties of the software, not the language. As such, of course you can achieve them with your favorite one. But some languages provide better tools to achieve some degree of correctness and testability which would require a greater effort with other languages. > Also, what's up with all the single-letter variable names? This is standard practice in many functional languages. Whenever the abstractness goes up (or the "more general" something is), the identifiers become shorter, since the name itself "means less". Hence why you see code that does something to every x in some kind of container xs; what would you gain with longer identifiers, except maybe misleading the reader?

agentultra 11y ago

The idea that "memory doesn't matter" and "we're mostly waiting on the network anyway" seems like red herring. It's not a "micro-optimization" to think of your data first. A program is a sequence of transformations on a stream of data. Figure out what your data is and how you want to transform it and your program will become evident. FP is a fine tool for programmers to have but you still have to think about the data regardless. If you don't realize how the allocator works in your VM you might end up fragmenting your pools and over-allocating virtual memory for a simple process. For some applications that might matter.

nudpiedo 11y ago
I found it correct: what the says is that we should focus first on the actual bottlenecks before we worry about other optimizations; not that we should just look to another side. If your bottle neck is in that point (copy of data structures) then there are functional data structures as well. And if still your performance is so critical in that point you can use a mutable data structure which is thread safe, and separate data from code in the rest of your code having still a big chunk of functional code where it is easy to reason about.
- agentultra 11y ago
  I am referring to data-oriented design[0], not optimization: thinking about your data, access patterns, and transformations is not a premature optimization in the Knuth-ian sense. It's just plain, old engineering. It's not incorrect per-se, just misleading in my opinion. [0]http://dataorienteddesign.com/site.php http://dataorienteddesign.com/site.php
nickpsecurity 11y ago
I agree that it's foolish to ignore memory issues. We've had horrific performance and scaling in much software that did that. Anyone thinking otherwise can feel free to disable their processor or app cache to see how unimportant memory concerns are. ;) Any HLL should give performance-concerned designers a clear, mental model of the performance aspects of their code. C and C++ programmers, for instance, understand the costs of their abstractions, how to code in a cache-efficient way, and so on. I read on the old LISP web sites and mailing lists where they similarly could estimate the cost of certain constructions and had tricks to squeeze out extra performance that they hid behind macros, etc. So, I'm sure these other functional languages can do something similar.

wcummings 11y ago

> you have to be wary of using Java and .NET types which are still prone to NPEs Java8 optionals are a maybe monad http://stackoverflow.com/a/19932439/4658666 http://stackoverflow.com/a/19932439/4658666

quchen 11y ago
I think your post only takes non-null values into account, which is what OP seems to talk about. What would this code do? Optional<Int> foo = null; foo.flatMap(x -> Optional.of(x)); Obeying the Monad laws would mean getting null as a result, via `m.flatMap(x -> Optional.of(x)) = m` for all m (or `m >>= pure = m` if you prefer Haskell syntax).
- deleted 11y ago
  [deleted]

rdtsc 11y ago

> Did you ever attempt to get to the bottom of an intermittent error that was driving you insane, only to discover much later that a private variable wasn’t synchronized properly? Have you ever spent hours stepping through the lifecycle of an object, going through many different components spread out across the codebase and wished that you had spent all that time solving new problems instead? I see 3 issues here. 1) Most people haven't dealt with those issues enough. There are complex programs but there are also many simple program as well. And unless one deals with hard to debug concurrency / pointer / mutable state errors they will not appreciate immutability. They might pay lip service to it, because it is cool, but they will not appreciate it enough to start rewriting their codebase in it. That is a bit like fault tolerance, unless they have been woken up at 3am because their main larger server process segfaulted and had to debug, they will not think about isolated units of failure, about supervision, durable peristent snapshots/checkpoints, monitoring etc. They of course will say that "fault tollerance is good" but it is good in an abstract, general way. 2) Those that dealt with these issue might accept the state (pun indended) of affairs and never realize there is another way of doing things. I mean they just accept that you have to have locks and mutable state and mutexes and dangling pointers and then spend months debugging hard to track concurrency errors at 3am. That is just how software development works and it is as good as it gets. 3) People realize there is something better, they know about, read about, played with it. But they don't have enough energy, political power, or time do fix it.

golergka 11y ago
> Most people haven't dealt with those issues enough This really surprises me. Surely, most programmers have experience with big and complex codebases with a lot bugs coming from mutable state, no?
- rdtsc 11y ago
  For 1) I meant that there are lot of utilities, micrservices, small web backends, scripts, and hopefully, applications that have already been split into isolated components that can fail and restart separately (in other words someone did the work already). So if one starts dealing with those in their careers they just might never have a compeling reason to look at Haskell, F#, Erlang, OCaml and such. Also note that quite often one way to deal with large mutable state is to simply shove it in database. Usually good databases just make it explicit what happens to shared state.

z3t4 11y ago

If your program has state, it doesn't matter if it's mutable or immutable state, you will still run into the same problems when working with concurrency. You either have to use locks, make sure functions are executed in the right order, or the preferred way: designate/central state. So functions vs object orientated is mostly a matter of preference. One advantage with functional programming though, is that it will be much easier so serialize the state.

JBiserkov 11y ago
I respectfully disagree. I also encourage you to take a look at http://clojure.org/state http://clojure.org/state
codygman 11y ago
> If your program has state, it doesn't matter if it's mutable or immutable state, you will still run into the same problems when working with concurrency. You either have to use locks, make sure functions are executed in the right order, or the preferred way: designate/central state. What about using STM: https://www.fpcomplete.com/school/advanced-haskell/beautiful-concurrency/1-introduction https://www.fpcomplete.com/school/advanced-haskell/beautiful...