3 ms·

First, you probably don't need to read academic articles to learn about functional programming. There's really nothing magical or complicated with functional pr

First, you probably don't need to read academic articles to learn about functional programming. There's really nothing magical or complicated with functional programming. For instance, Scheme or OCaml are routinely used as beginner programming languages in schools around the world. You can start with the basic concepts and eventually build your way up to more abstract constructs when you realize you need them. But even there, you don't need to know the academic terminology (or if you do, it'll make more sense when you get familiar with the language). I frequently use monads and functors, yet I don't know much about category theory (and the little I know doesn't make me a better programmer).

centimeter 7y ago
Not sure about Scheme, but OCaml's type system is not powerful/expressive enough that (to use the given example) abstracting over type constructors is likely to ever come up. (No HKTs in OCaml.) Also, OCaml uses a naming scheme for certain things that I haven't seen used elsewhere - e.g. what OCaml calls a "Functor" is a parameterized module, not closely related to Functors in other languages that use that abstraction. I suspect this is a result of the French/English language divide in the initial development of OCaml vs all other major functional languages.
- jolux 7y ago
  OCaml functors come from Standard ML, which predates Haskell. And you can definitely use them to implement HKTs — they are comparable in expressiveness to single-parameter typeclasses.
  - centimeter 7y ago
    I use OCaml at work ~every day, and HKTs (to the extent they can be expressed at all, using HOMs) are so unwieldy that I have never run across them in production code. In Haskell, they are both easy and routine. So I’m approximating this with “no HKTs in OCaml”.
    - jolux 7y ago
      HKTs indeed aren't a common pattern in OCaml, but first-class modules and similar patterns are common enough in Core. Your statement was that the type system was not powerful enough to express them at all. Whether or not it's practical is a bit different :) You also said that their use of "functor" was probably the result of being French vs English, when I pointed out that in fact it came from Standard ML, which is a British design. Moreover, the creators of Haskell originally built typeclasses as an extension to Standard ML (1980s), and Functor was added in the same version of Haskell that Monad was (1.3, roughly 1998). The connection between ML functors (specifically the interface/signature) and typeclasses in Haskell is relatively clear, if you understand how they both work. I don't disagree that typeclasses are more general, but modules have their appeal as well. I'm pretty excited to see where Backpack ends up in Haskell, personally.
      - deleted 7y ago
        [deleted]
      - centimeter 7y ago
        I definitely sufficiently hedged my original claim: > OCaml's type system is not powerful/expressive enough that (to use the given example) abstracting over type constructors is likely to ever come up. And I stand by that. It’s not likely to ever come up, even if it’s possible to kludge it. You’re right about the name though - it seems like the anomalous use of “functor” predates francophone intervention.
        jolux 7y ago
        It's weird to call it anomalous ML came first in the programming sphere. What you said is that it's not powerful or expressive enough, but my impression was that they were both expressible in terms of System Fω, an understanding I would like to correct if it's wrong.
        centimeter 7y ago
        > It's weird to call it anomalous ML came first in the programming sphere. Eilenberg and Lane introduced functors (in the sense more or less used by Haskell) in the 40s. > my impression was that they were both expressible in terms of System Fω This is not correct anymore - Fω is insufficient to describe GADTs. You need coercions and equality constraints as well. It's also approximately as useful a claim as "the languages are equally powerful because they're both Turing complete". I'm referring to practicability, not theoretical possibility (and I've clarified as much several times now).
Barrin92 7y ago
I'd go a step further and say trying to learn all the convoluted language and terminology actually does very little to understand the benefits of functional programming in the real world and it should best be avoided. It's, in my opinion, better to just grab a functional language, built some software with it, and learn about the benefits and disadvantages of functional languages by interacting with them.

centimeter 7y ago

Not sure about Scheme, but OCaml's type system is not powerful/expressive enough that (to use the given example) abstracting over type constructors is likely to ever come up. (No HKTs in OCaml.) Also, OCaml uses a naming scheme for certain things that I haven't seen used elsewhere - e.g. what OCaml calls a "Functor" is a parameterized module, not closely related to Functors in other languages that use that abstraction. I suspect this is a result of the French/English language divide in the initial development of OCaml vs all other major functional languages.

jolux 7y ago
OCaml functors come from Standard ML, which predates Haskell. And you can definitely use them to implement HKTs — they are comparable in expressiveness to single-parameter typeclasses.
- centimeter 7y ago
  I use OCaml at work ~every day, and HKTs (to the extent they can be expressed at all, using HOMs) are so unwieldy that I have never run across them in production code. In Haskell, they are both easy and routine. So I’m approximating this with “no HKTs in OCaml”.
  - jolux 7y ago
    HKTs indeed aren't a common pattern in OCaml, but first-class modules and similar patterns are common enough in Core. Your statement was that the type system was not powerful enough to express them at all. Whether or not it's practical is a bit different :) You also said that their use of "functor" was probably the result of being French vs English, when I pointed out that in fact it came from Standard ML, which is a British design. Moreover, the creators of Haskell originally built typeclasses as an extension to Standard ML (1980s), and Functor was added in the same version of Haskell that Monad was (1.3, roughly 1998). The connection between ML functors (specifically the interface/signature) and typeclasses in Haskell is relatively clear, if you understand how they both work. I don't disagree that typeclasses are more general, but modules have their appeal as well. I'm pretty excited to see where Backpack ends up in Haskell, personally.
    - deleted 7y ago
      [deleted]
    - centimeter 7y ago
      I definitely sufficiently hedged my original claim: > OCaml's type system is not powerful/expressive enough that (to use the given example) abstracting over type constructors is likely to ever come up. And I stand by that. It’s not likely to ever come up, even if it’s possible to kludge it. You’re right about the name though - it seems like the anomalous use of “functor” predates francophone intervention.
      - jolux 7y ago
        It's weird to call it anomalous ML came first in the programming sphere. What you said is that it's not powerful or expressive enough, but my impression was that they were both expressible in terms of System Fω, an understanding I would like to correct if it's wrong.
        centimeter 7y ago
        > It's weird to call it anomalous ML came first in the programming sphere. Eilenberg and Lane introduced functors (in the sense more or less used by Haskell) in the 40s. > my impression was that they were both expressible in terms of System Fω This is not correct anymore - Fω is insufficient to describe GADTs. You need coercions and equality constraints as well. It's also approximately as useful a claim as "the languages are equally powerful because they're both Turing complete". I'm referring to practicability, not theoretical possibility (and I've clarified as much several times now).

Barrin92 7y ago

I'd go a step further and say trying to learn all the convoluted language and terminology actually does very little to understand the benefits of functional programming in the real world and it should best be avoided. It's, in my opinion, better to just grab a functional language, built some software with it, and learn about the benefits and disadvantages of functional languages by interacting with them.