4 ms·

I'm surprised that you think FP requires mastering category theory. Au contraire. It's perfectly possible (and indeed easier for programmers) to understand the

I'm surprised that you think FP requires mastering category theory. Au contraire. It's perfectly possible (and indeed easier for programmers) to understand the abstractions that Haskell and Scala pioneer (higher-kinded types, and things like type-classes as well as monads which are basically enabled by HKTs) without category theory. It is true that monads were discovered via category theory, but in retrospect programmers could have discovered them -- after all they are (simplifying a bit) merely a way of generalising composition. Scala and ML-variants like Ocaml, F#, Reason.js are perfectly good imperative languages. They don't force you to go purely functional. I always recommend that my students (whose first language is Java) start by treating Scala as a "nicer Java", and then slowly explore Scala's more powerful features. Indeed, I'd argue that Scala and the aforementioned ML-variants are (slightly) better general-purpose imperative languages than the Javas, Pythons, PHPs and Javascripts of this world, because they are more consistent, they have types/type-inference, and their statefulness fully supports higher-order state and powerful modularisation without restriction, not to mention pattern matching. Being able to use functional idioms without compromise if and when desired (including, but not restricted to, pure functional programming) is another benefit of Scala and ML-variants.

seanmcdirmid 9y ago
Monads existed before their connection to category theory was discovered (by Wadler and company), they just didn’t have an elegant way of describing or naming but. them, and definitely the connection allowed them to push them more. The biggest problem of very functional code on the web is simply debugging it. So much control flow is buried in compositions that there isn’t much to grab on in terms of break points or variable inspection. Pure languages exacerbate this problem by making state more difficult to dig out and pin down at run-time.
- bitL 9y ago
  Exactly. Debugging is one of the biggest problems with FP, and when you hear some prolific Haskell hackers talking about no longer being capable of understanding code they produced 10 years ago at the peak of their mental performance, it's difficult to commit to it exclusively.
  - naasking 9y ago
    > Debugging is one of the biggest problems with FP I don't see why that's a problem with FP and not just the lack of tooling in most FP languages. Debugging in F# via Visual Studio is a breeze, and OCaml's time travelling debugger looks pretty good.
    - bitL 9y ago
      I guess if you start using nth-order functional compositions and everything is a recursion, it's super difficult to figure out what is going on from e.g. stack traces or just simple log statements. And often FP programs are more-less solutions to "puzzles" and to understand the solution you need to keep that "puzzle" on mind. Now what are you doing if you have multiple levels of "puzzles" at the same time and you need to connect two separate subsystems via some deep-level information exchange, given there are no mutable variables/singletons for you? I am sure anyone taking FP seriously hits this kind of problems regularly and they often take long time to come up with satisfactory pure implementations.
      - pka 9y ago
        Just a clarification for anybody else who might be reading this: there absolutely are mutable variables in pure fp languages like Haskell, you just have to explicitly ask for them (and reflect that fact in the type), i.e: do x <- newIORef 0 writeIORef x 2 print =<< readIORef x will print 2. In fact, I'd argue that many times writing programs with mutable state is actually easier in Haskell/etc, especially when it comes to concurrency where something like software transactional memory [0] is invaluable (and more or less practically unusable in other ecosystems), if it fits your constraints. [0] https://en.wikipedia.org/wiki/Software_transactional_memory https://en.wikipedia.org/wiki/Software_transactional_memory
    - seanmcdirmid 9y ago
      For F#, is it a debugger designed for F# or just good integration with VS’s .net debugger? If the latter, I should mention that the problem remains even when using C# if your code gets too functional (e.g. getting rid of some LINQ for debuggability is a common trade off).
- mafribe 9y ago
  I'm not a historian. It's certainly true that monads or monad-like things where discovered independently in many context. This isn't even surprising, given how natural, and trivial in a sense monads are. But the systematics realisation of the concept and its wide applicability comes from algebra and the efforts to recover algebra categorically. Let me quote from Wadler's [1]: The notion of monad comes from category theory [...] It first arose in the area of homological algebra, but later was recognised (due to the work of Kleisli and of Eilenberg and Moore) to have much wider applications. Its importance emerged slowly: in early days, it was not even given a proper name, but called simply a "standard construction" or a "triple" [...] Eugenio Moggi proposed that monads provide a useful structuring tool for denotational semantics [...] He showed how lambda calculus could be given call-by-value and call-by-name semantics in an arbitrary monad, and how monads could encapsulate a wide variety of programming language features such as state, exception handling, and continuations. Independent of Moggi, but at about the same time, Michael Spivey proposed that monads provide a useful structuring tool for exception handling in pure functional languages, and demonstrated this thesis with an elegant program for term rewriting [...]. He showed how monads could treat exceptions [...] and non-deterministic choice [...] in a common framework. [1] P. Wadler, The essence of functional programming.
bitL 9y ago
Yeah, I like the balanced approach - I'd love to use whatever programming mode that is available to me when I see fit, whether it is imperative mode, functional mode, self-modyfing mode, GOTO/JMP-mode, everything-is-a-modifiable-object mode, Deep Learning-assisted mode etc. I just don't like when somebody forces on me "the one right way", which was the feeling I got from the parent post.

seanmcdirmid 9y ago

Monads existed before their connection to category theory was discovered (by Wadler and company), they just didn’t have an elegant way of describing or naming but. them, and definitely the connection allowed them to push them more. The biggest problem of very functional code on the web is simply debugging it. So much control flow is buried in compositions that there isn’t much to grab on in terms of break points or variable inspection. Pure languages exacerbate this problem by making state more difficult to dig out and pin down at run-time.

bitL 9y ago
Exactly. Debugging is one of the biggest problems with FP, and when you hear some prolific Haskell hackers talking about no longer being capable of understanding code they produced 10 years ago at the peak of their mental performance, it's difficult to commit to it exclusively.
- naasking 9y ago
  > Debugging is one of the biggest problems with FP I don't see why that's a problem with FP and not just the lack of tooling in most FP languages. Debugging in F# via Visual Studio is a breeze, and OCaml's time travelling debugger looks pretty good.
  - bitL 9y ago
    I guess if you start using nth-order functional compositions and everything is a recursion, it's super difficult to figure out what is going on from e.g. stack traces or just simple log statements. And often FP programs are more-less solutions to "puzzles" and to understand the solution you need to keep that "puzzle" on mind. Now what are you doing if you have multiple levels of "puzzles" at the same time and you need to connect two separate subsystems via some deep-level information exchange, given there are no mutable variables/singletons for you? I am sure anyone taking FP seriously hits this kind of problems regularly and they often take long time to come up with satisfactory pure implementations.
    - pka 9y ago
      Just a clarification for anybody else who might be reading this: there absolutely are mutable variables in pure fp languages like Haskell, you just have to explicitly ask for them (and reflect that fact in the type), i.e: do x <- newIORef 0 writeIORef x 2 print =<< readIORef x will print 2. In fact, I'd argue that many times writing programs with mutable state is actually easier in Haskell/etc, especially when it comes to concurrency where something like software transactional memory [0] is invaluable (and more or less practically unusable in other ecosystems), if it fits your constraints. [0] https://en.wikipedia.org/wiki/Software_transactional_memory https://en.wikipedia.org/wiki/Software_transactional_memory
  - seanmcdirmid 9y ago
    For F#, is it a debugger designed for F# or just good integration with VS’s .net debugger? If the latter, I should mention that the problem remains even when using C# if your code gets too functional (e.g. getting rid of some LINQ for debuggability is a common trade off).
mafribe 9y ago
I'm not a historian. It's certainly true that monads or monad-like things where discovered independently in many context. This isn't even surprising, given how natural, and trivial in a sense monads are. But the systematics realisation of the concept and its wide applicability comes from algebra and the efforts to recover algebra categorically. Let me quote from Wadler's [1]: The notion of monad comes from category theory [...] It first arose in the area of homological algebra, but later was recognised (due to the work of Kleisli and of Eilenberg and Moore) to have much wider applications. Its importance emerged slowly: in early days, it was not even given a proper name, but called simply a "standard construction" or a "triple" [...] Eugenio Moggi proposed that monads provide a useful structuring tool for denotational semantics [...] He showed how lambda calculus could be given call-by-value and call-by-name semantics in an arbitrary monad, and how monads could encapsulate a wide variety of programming language features such as state, exception handling, and continuations. Independent of Moggi, but at about the same time, Michael Spivey proposed that monads provide a useful structuring tool for exception handling in pure functional languages, and demonstrated this thesis with an elegant program for term rewriting [...]. He showed how monads could treat exceptions [...] and non-deterministic choice [...] in a common framework. [1] P. Wadler, The essence of functional programming.

bitL 9y ago

Yeah, I like the balanced approach - I'd love to use whatever programming mode that is available to me when I see fit, whether it is imperative mode, functional mode, self-modyfing mode, GOTO/JMP-mode, everything-is-a-modifiable-object mode, Deep Learning-assisted mode etc. I just don't like when somebody forces on me "the one right way", which was the feeling I got from the parent post.