3 ms·

"It is not a language that is “more mathematical” or “for math” or “about math”. " I disagree, Haskell (and other functional languages) are a lot more similar

"It is not a language that is “more mathematical” or “for math” or “about math”. " I disagree, Haskell (and other functional languages) are a lot more similar to traditional maths than other languages.

spopejoy 12y ago
Hmm ... Pedagogically, I wonder if Haskell suffers from this emphasis on math. For instance, I couldn't figure out State monad for the life of me, and in general how monadic calls could maintain a context "in the background". Explanations like "it's easy just follow the Kleisli arrows" weren't helping. Finally I did the exercise of manually "inlining" every >>=, 'get' and 'modify' call in a trivial example of a StateT function calling another StateT function. And then I got it. Truckloads of closures/continuations, constant calls to re-create the monad with new information. Function calls with functions as arguments that close over the previous calling function's state. A lot of this was specific to how StateT + Identity unwrapped; I'm sure inlining other monads would reveal different things, and unwrapping IO is impossible in GHC :). My point is, math has been a great source of Haskell's incredible expressivity, but the pedagogical focus on math threatens to mask it's greatest triumph in Haskell: making all of that boilerplate code go away with incredible precision and elegance. When you rip it open and see what >>= or 'do ... get ... modify' is doing, you feel the power. I feel like the article suggests this, too: The only thing you need category theory for is to take great categorical and mathematical concepts from the world and import them back to programming, and translate them along the way so that others don’t need to make the same journey you did. At least for advanced programmers from other worlds, they need to see the guts to appreciate how amazing this stuff is.
- codygman 12y ago
  Seeing lots of those monads unwrapped and the lambdas that they get turned into can be especially helpful for those of us (including me) that have an imperative/OOP background.
fbernier 12y ago
I think what followed this quote made quite a good job at explaining what exactly he meant with this statement: That people tend to have a limited view of math as calculus only.
- titanomachy 12y ago
  One thing that I think is true (and maybe this is what Ono-Sendai meant) is that compared to many languages, Haskell's syntax is relatively close to the notation used by mathematicians. And notation can strongly influence the way we think about things. I was introduced to programming before abstract algebra, and when I took my first algebra class the comparison to Haskell was inevitable. Actually it turned out to be quite helpful: strongly-typed functional programming can be a good supplement to learning algebra.
  - Ono-Sendai 12y ago
    Well, for example, Haskell obviously makes heavy use of functions, which are from maths. Procedures, on the other hand, aren't. In maths, you often write something like let x = ... An imperative language statement like x = x + 1; isn't something you see in maths, that is not a valid equation.
    - agos 12y ago
      it's very similar to Recurrence Equations, minus the time indication (the absence of which is the cause for a number of bugs).

spopejoy 12y ago

Hmm ... Pedagogically, I wonder if Haskell suffers from this emphasis on math. For instance, I couldn't figure out State monad for the life of me, and in general how monadic calls could maintain a context "in the background". Explanations like "it's easy just follow the Kleisli arrows" weren't helping. Finally I did the exercise of manually "inlining" every >>=, 'get' and 'modify' call in a trivial example of a StateT function calling another StateT function. And then I got it. Truckloads of closures/continuations, constant calls to re-create the monad with new information. Function calls with functions as arguments that close over the previous calling function's state. A lot of this was specific to how StateT + Identity unwrapped; I'm sure inlining other monads would reveal different things, and unwrapping IO is impossible in GHC :). My point is, math has been a great source of Haskell's incredible expressivity, but the pedagogical focus on math threatens to mask it's greatest triumph in Haskell: making all of that boilerplate code go away with incredible precision and elegance. When you rip it open and see what >>= or 'do ... get ... modify' is doing, you feel the power. I feel like the article suggests this, too: The only thing you need category theory for is to take great categorical and mathematical concepts from the world and import them back to programming, and translate them along the way so that others don’t need to make the same journey you did. At least for advanced programmers from other worlds, they need to see the guts to appreciate how amazing this stuff is.

codygman 12y ago
Seeing lots of those monads unwrapped and the lambdas that they get turned into can be especially helpful for those of us (including me) that have an imperative/OOP background.

fbernier 12y ago

I think what followed this quote made quite a good job at explaining what exactly he meant with this statement: That people tend to have a limited view of math as calculus only.

titanomachy 12y ago
One thing that I think is true (and maybe this is what Ono-Sendai meant) is that compared to many languages, Haskell's syntax is relatively close to the notation used by mathematicians. And notation can strongly influence the way we think about things. I was introduced to programming before abstract algebra, and when I took my first algebra class the comparison to Haskell was inevitable. Actually it turned out to be quite helpful: strongly-typed functional programming can be a good supplement to learning algebra.
- Ono-Sendai 12y ago
  Well, for example, Haskell obviously makes heavy use of functions, which are from maths. Procedures, on the other hand, aren't. In maths, you often write something like let x = ... An imperative language statement like x = x + 1; isn't something you see in maths, that is not a valid equation.
  - agos 12y ago
    it's very similar to Recurrence Equations, minus the time indication (the absence of which is the cause for a number of bugs).