5 ms·

I would suggest the following: - write all functions related to math/geometry/combinatorics in pure functional style, even better with accompanying mathematica

by bitL 11y ago

I would suggest the following: - write all functions related to math/geometry/combinatorics in pure functional style, even better with accompanying mathematical proofs to be sure they are principally sound (you won't avoid problems with floating numbers etc. that way) - think about using functional programming in parallel/distributed tasks if you can manage communication complexity directly (i.e. this is not handled to you by some opaque, un-debuggable monad) - write everything else in imperative style of your choice I/O is the elephant in the room of functional programming, monads are "imperative" hacks to make functional programming useful in any real-world-related way, and most monad tutorials will only confuse you about what they are actually.

visarga 11y ago
I found that as I was learning functional programming, I started changing the way I was writing code even in imperative mode. I was separating things better, programs became more semantic and there are many opportunities to use functional style, but I still think imperative code is faster and easier to write for small functions, up to 20-30 lines of code. Also, because it is so similar in a way, I learned a new appreciation for unix pipes and the shell syntax for composing programs. I will continue to learn FP just to upgrade my programming skills.
TazeTSchnitzel 11y ago
> monads are "imperative" hacks to make functional programming useful in any real-world-related way Monads are a quite clever solution to control IO: instead of allowing functions to directly perform IO, allow them to compose a sequence of IO operations and return them, such that you can compose a program which the runtime will then execute. They're not imperative: they represent programs in a purely functional way, and they don't let you opt out of any of the guarantees a purely functional language provides. And they're not a hack, they fit properly into the type system. Unlike "mostly functional" programming, use of monadic IO in a purely functional language will force you to cleanly separate IO and computation. Not only does this make a more maintainable program (no side effects everywhere), but you get nice bonuses, like lazy computation. > and most monad tutorials will only confuse you about what they are actually. Perhaps because many monad tutorials try to hide how they work, despite this really being quite simple.
- klibertp 11y ago
  > use of monadic IO in a purely functional language will force you to have `unsafePerformIO` in the language.
  - TazeTSchnitzel 11y ago
    GHC has `unsafePerformIO` in order to implement pure abstractions. It's an implementation detail, Haskell proper does not support it, and you wouldn't use it in your code.
    - deleted 11y ago
      [deleted]
    - klibertp 11y ago
      > and you wouldn't use it in your code Speak for yourself. I don't see any value in not using a tool when it's available and seems to do the job: http://science.raphael.poss.name/haskell-for-ocaml-programmers.html#print-debugging http://science.raphael.poss.name/haskell-for-ocaml-programme... Personally I don't believe in 100% pure FP, it's both a pain in the ass and doesn't really give you more than 85% FP already would. Actually, most of the FP world seems to agree: out of many Lisps, Scala, OCaml, SML, F#, Erlang/Elixir etc. only Haskell is that hell-bent on purity. Even things like PureScript are more pragmatic than Haskell in this regard. Here's a great talk on getting what's best from FP without also taking all the problems: http://www.infoq.com/presentations/functional-pros-cons http://www.infoq.com/presentations/functional-pros-cons
      - tome 11y ago
        > Even things like PureScript are more pragmatic than Haskell in this regard Interesting. In what way?
      - TazeTSchnitzel 11y ago
        > Personally I don't believe in 100% pure FP, it's both a pain in the ass and doesn't really give you more than 85% FP already would. How so? Having a pure language has some significant benefits, like laziness. Data structures as control flow is awesome.
dragonwriter 11y ago
Monad tutorials are a problem because they try to teach you to play football without first learning to walk. Progressive tutorials/introductions on the category theory constructs leading up to and including monads are better.
- polymatter 11y ago
  do you have any recommendations on such tutorials/introductions that teach category theory?
  - AdieuToLogic 11y ago
    I found this one quite approachable: https://hseeberger.wordpress.com/2010/11/25/introduction-to-category-theory-in-scala/ https://hseeberger.wordpress.com/2010/11/25/introduction-to-...
  - dragonwriter 11y ago
    For category theory constructs in a Haskell context, I think the Typeclassopedia [0] is the best thing I've found. [0] https://wiki.haskell.org/Typeclassopedia https://wiki.haskell.org/Typeclassopedia
  - thoth 11y ago
    Bartosz Milewski is writing a category theory tutorial, which is in progress: http://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/ http://bartoszmilewski.com/2014/10/28/category-theory-for-pr...
- bitL 11y ago
  The problem is that category theory is "elitist", i.e. most programmers aren't equipped to comprehend even the basics properly if they didn't study theoretical computer science, computability theory, recursion theory etc. or even philosophy :-(
  - marcosdumay 11y ago
    The problem is that 99.9% of the material about Category Theory in existence just forget to talk about two features of it: what is it useful for, and how it relates to mode widely known concepts, like functions. Haskell is accessible. Just ignore the monad tutorials.

by bitL 11y ago

visarga 11y ago

I found that as I was learning functional programming, I started changing the way I was writing code even in imperative mode. I was separating things better, programs became more semantic and there are many opportunities to use functional style, but I still think imperative code is faster and easier to write for small functions, up to 20-30 lines of code. Also, because it is so similar in a way, I learned a new appreciation for unix pipes and the shell syntax for composing programs. I will continue to learn FP just to upgrade my programming skills.

TazeTSchnitzel 11y ago

> monads are "imperative" hacks to make functional programming useful in any real-world-related way Monads are a quite clever solution to control IO: instead of allowing functions to directly perform IO, allow them to compose a sequence of IO operations and return them, such that you can compose a program which the runtime will then execute. They're not imperative: they represent programs in a purely functional way, and they don't let you opt out of any of the guarantees a purely functional language provides. And they're not a hack, they fit properly into the type system. Unlike "mostly functional" programming, use of monadic IO in a purely functional language will force you to cleanly separate IO and computation. Not only does this make a more maintainable program (no side effects everywhere), but you get nice bonuses, like lazy computation. > and most monad tutorials will only confuse you about what they are actually. Perhaps because many monad tutorials try to hide how they work, despite this really being quite simple.

klibertp 11y ago
> use of monadic IO in a purely functional language will force you to have `unsafePerformIO` in the language.
- TazeTSchnitzel 11y ago
  GHC has `unsafePerformIO` in order to implement pure abstractions. It's an implementation detail, Haskell proper does not support it, and you wouldn't use it in your code.
  - deleted 11y ago
    [deleted]
  - klibertp 11y ago
    > and you wouldn't use it in your code Speak for yourself. I don't see any value in not using a tool when it's available and seems to do the job: http://science.raphael.poss.name/haskell-for-ocaml-programmers.html#print-debugging http://science.raphael.poss.name/haskell-for-ocaml-programme... Personally I don't believe in 100% pure FP, it's both a pain in the ass and doesn't really give you more than 85% FP already would. Actually, most of the FP world seems to agree: out of many Lisps, Scala, OCaml, SML, F#, Erlang/Elixir etc. only Haskell is that hell-bent on purity. Even things like PureScript are more pragmatic than Haskell in this regard. Here's a great talk on getting what's best from FP without also taking all the problems: http://www.infoq.com/presentations/functional-pros-cons http://www.infoq.com/presentations/functional-pros-cons
    - tome 11y ago
      > Even things like PureScript are more pragmatic than Haskell in this regard Interesting. In what way?
    - TazeTSchnitzel 11y ago
      > Personally I don't believe in 100% pure FP, it's both a pain in the ass and doesn't really give you more than 85% FP already would. How so? Having a pure language has some significant benefits, like laziness. Data structures as control flow is awesome.

dragonwriter 11y ago

Monad tutorials are a problem because they try to teach you to play football without first learning to walk. Progressive tutorials/introductions on the category theory constructs leading up to and including monads are better.

polymatter 11y ago
do you have any recommendations on such tutorials/introductions that teach category theory?
- AdieuToLogic 11y ago
  I found this one quite approachable: https://hseeberger.wordpress.com/2010/11/25/introduction-to-category-theory-in-scala/ https://hseeberger.wordpress.com/2010/11/25/introduction-to-...
- dragonwriter 11y ago
  For category theory constructs in a Haskell context, I think the Typeclassopedia [0] is the best thing I've found. [0] https://wiki.haskell.org/Typeclassopedia https://wiki.haskell.org/Typeclassopedia
- thoth 11y ago
  Bartosz Milewski is writing a category theory tutorial, which is in progress: http://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/ http://bartoszmilewski.com/2014/10/28/category-theory-for-pr...
bitL 11y ago
The problem is that category theory is "elitist", i.e. most programmers aren't equipped to comprehend even the basics properly if they didn't study theoretical computer science, computability theory, recursion theory etc. or even philosophy :-(
- marcosdumay 11y ago
  The problem is that 99.9% of the material about Category Theory in existence just forget to talk about two features of it: what is it useful for, and how it relates to mode widely known concepts, like functions. Haskell is accessible. Just ignore the monad tutorials.