26 ms·

Thank god. I've felt like we've been getting closer to breaching the peak of the hype curve for what I'd probably call 'monadic pure functional programming' i.e

Thank god. I've felt like we've been getting closer to breaching the peak of the hype curve for what I'd probably call 'monadic pure functional programming' i.e. Haskell, Scalaz, etc. It'll have its hardcore advocates forever, of course, but I think we might be finally getting to the point where people realise 'wait this sure is an absurd amount of complexity to represent some fairly simple functions, surely there must be a better way?'.

danharaj 9y ago
The majority of internet conversations about monads never get past the most shallow introduction. The most important feature of monads is that they can be composed via monad transformers. A la carte languages and algebraic effects are nice, but monad composition is more powerful. Also, as someone in the Haskell industry, I think you're wrong about trends. The last 5 or so years have been an accelerating trend of Haskell adoption. Of course it is still dwarfed by most other languages, but the number of multi-million dollar contracts I've seen executed in Haskell has been multiplying.
- bojo 9y ago
  As a relatively tiny data point, I've introduced Haskell at a small telecom doing $350M/yr in revenue. This kind of environment screams "Enterprise", but as it turns out the vast majority of problems that need solved can be done quite gracefully with Haskell.
  - alphaalpha101 9y ago
    Yeah at the end of the day it's just another programming language, and you can really get things done in any programming language.
    - lmm 9y ago
      It's an incremental improvement on what's gone before, sure, but it does offer a bunch of genuinely useful facilities that a lot of programming languages just don't have. I'd never want to go back to a language that was missing HKT, missing libraries of generic operations on monads, missing libraries of generic operations on recursive datastructures via fixed points, or missing safe derivation of operations on structured data via typeclass derivation or similar.
      - goldenkey 9y ago
        You want Mathematica then..
      - alphaalpha101 9y ago
        I never ever want to use a language with those features again. HKT are completely unnecessary. No code ever wants or needs HKT. They're pure wankery. Libraries of generic operations on recursive data structures via fixed points? Come on. This is why Go doesn't have generics. They don't want this crap infecting their language. Typeclass derivation? Typeclasses are a terribly designed language feature that is inferior to ML modules in every way.
        dang 9y ago
        Could you please keep programming language flamewars off HN? We're trying to avoid the destruction that befalls places that host these.
- alphaalpha101 9y ago
  The most important feature of monads definitely isn't composition, because they don't compose well at all. Monad composition is the worst feature, by far, because it doesn't exist. >Also, as someone in the Haskell industry, I think you're wrong about trends. The last 5 or so years have been an accelerating trend of Haskell adoption. Of course it is still dwarfed by most other languages, but the number of multi-million dollar contracts I've seen executed in Haskell has been multiplying. That's my point: that's the hype cycle, and it's now peaking as people realise what a lot of effort it is to actually use monads in reality with the awful complexity of monad transformer stacks and such.
  - kreetx 9y ago
    Can you clarify what do you mean by they don't compose at all? It feels like you've had some tough experiences with monads (monad transformers), and I agree, they are hard to get into.
    - lambdas 9y ago
      Sometimes two monads composed don't form another monad. Unlike Functors and Applicatives. Simple example, if you have a list containing functions ([Reader r a]) it forms an Applicative fine as they compose. However you can't satisfy the conditions needed to form a Monad.
      - danharaj 9y ago
        You can compose monads whenever you have a distributive law for them. Usually there's an obvious one. In your example there's a distributive law that uses the same parameter for every function, this allows you to compose the monads. When there's several possible distributive laws or none, that's important. It means that either the interactions between the two effects are subtle and need to be further specified or they are completely incompatible. Algebraic effects can only handle effects that trivially commute. So monad composition is a finer, thus more expressive operation.
        9y ago
Karrot_Kream 9y ago
The benefit of working with typeclasses has always been the ability to see and abstract out patterns that occur through Functors, Applicatives, Monoids, et al. I think ML is much more hyped up than monadic pure functional programming.
- alphaalpha101 9y ago
  >The benefit of working with typeclasses has always been the ability to see and abstract out patterns that occur through Functors, Applicatives, Monoids, et al. Which leads to code that needs to be puzzled out, rather than code that flows naturally. 'What does [arbitrary-monad-operationM_] mean for SomeMonadTransformerStack again???' is all too common in my experience. I really think that's false abstraction, like an 'object' superclass in OO languages.
  - aninhumer 9y ago
    There aren't that many different compositions, and they're mostly just variants of map and fold for different contexts. And once you learn them, it's a lot easier to see what code using them does at a glance, rather than reading the corresponding for loop to work out what it does, and whether it has any side effects.
    - alphaalpha101 9y ago
      I disagree. It's a lot harder to see what code using them does at a glance, because the names are meaningless. 'forM' means what, exactly? Nothing. It means nothing until you apply it to a particular monad. It's trivial to read a loop, because it's right there. It's trivial to tell if it has any effects, because they're notated right there as algebraic effects.
      - deleted 9y ago
        [deleted]
      - aninhumer 9y ago
        >'forM' means what, exactly? Nothing. It means nothing until you apply it to a particular monad. It means you're mapping over something and collecting the results. Yes you need a little more information to understand exactly what you're mapping over or what "collect" means in this context, but this is still more information that `for` gives you without reading more. Although I find in practice it's usually fairly obvious what `forM` means in context, because you're likely writing a lot of code working with the same monads. >they're notated right there as algebraic effects. I'm not sure what you mean by this. Unless you're using some kind of advanced imperative language with effect types, they're not "right there", you have to infer them from the code. Whereas with Haskell you usually have a type signature which tells you what the effects are.
naasking 9y ago
Haven't you heard? Monads are old-school, algebraic effects are the future! ;-)
tathougies 9y ago
I don't understand this comment, almost every compiler and language in existence uses monads for computation. Monadic sequencing is the foundation of almost every CPU. Most languages are utterly dependent on them. Haskell and other pure languages let you compute values independent of the monad its computed in, which is very useful. Of course, this is all conceptual, eventually everything is translated to underlying CPU monad and its implicit join.
- julian_1 9y ago
  Why join rather than bind?
- Veedrac 9y ago
  > Monadic sequencing is the foundation of almost every CPU. What on earth are you modelling a CPU as? What thing a CPU does corresponds to join?
- alphaalpha101 9y ago
  I'll point out again that this is very reminiscent of the OOP fad and "everything is an object". "Everything is a monad" is similar. "It's all just the CPU monad" is just.. inane. It's like saying 'C functions are pure functions that implicitly take and return the world'. Maybe? But at that point 'pure' has lost all of its information content.

danharaj 9y ago

The majority of internet conversations about monads never get past the most shallow introduction. The most important feature of monads is that they can be composed via monad transformers. A la carte languages and algebraic effects are nice, but monad composition is more powerful. Also, as someone in the Haskell industry, I think you're wrong about trends. The last 5 or so years have been an accelerating trend of Haskell adoption. Of course it is still dwarfed by most other languages, but the number of multi-million dollar contracts I've seen executed in Haskell has been multiplying.

bojo 9y ago
As a relatively tiny data point, I've introduced Haskell at a small telecom doing $350M/yr in revenue. This kind of environment screams "Enterprise", but as it turns out the vast majority of problems that need solved can be done quite gracefully with Haskell.
- alphaalpha101 9y ago
  Yeah at the end of the day it's just another programming language, and you can really get things done in any programming language.
  - lmm 9y ago
    It's an incremental improvement on what's gone before, sure, but it does offer a bunch of genuinely useful facilities that a lot of programming languages just don't have. I'd never want to go back to a language that was missing HKT, missing libraries of generic operations on monads, missing libraries of generic operations on recursive datastructures via fixed points, or missing safe derivation of operations on structured data via typeclass derivation or similar.
    - goldenkey 9y ago
      You want Mathematica then..
    - alphaalpha101 9y ago
      I never ever want to use a language with those features again. HKT are completely unnecessary. No code ever wants or needs HKT. They're pure wankery. Libraries of generic operations on recursive data structures via fixed points? Come on. This is why Go doesn't have generics. They don't want this crap infecting their language. Typeclass derivation? Typeclasses are a terribly designed language feature that is inferior to ML modules in every way.
      - dang 9y ago
        Could you please keep programming language flamewars off HN? We're trying to avoid the destruction that befalls places that host these.
alphaalpha101 9y ago
The most important feature of monads definitely isn't composition, because they don't compose well at all. Monad composition is the worst feature, by far, because it doesn't exist. >Also, as someone in the Haskell industry, I think you're wrong about trends. The last 5 or so years have been an accelerating trend of Haskell adoption. Of course it is still dwarfed by most other languages, but the number of multi-million dollar contracts I've seen executed in Haskell has been multiplying. That's my point: that's the hype cycle, and it's now peaking as people realise what a lot of effort it is to actually use monads in reality with the awful complexity of monad transformer stacks and such.
- kreetx 9y ago
  Can you clarify what do you mean by they don't compose at all? It feels like you've had some tough experiences with monads (monad transformers), and I agree, they are hard to get into.
  - lambdas 9y ago
    Sometimes two monads composed don't form another monad. Unlike Functors and Applicatives. Simple example, if you have a list containing functions ([Reader r a]) it forms an Applicative fine as they compose. However you can't satisfy the conditions needed to form a Monad.
    - danharaj 9y ago
      You can compose monads whenever you have a distributive law for them. Usually there's an obvious one. In your example there's a distributive law that uses the same parameter for every function, this allows you to compose the monads. When there's several possible distributive laws or none, that's important. It means that either the interactions between the two effects are subtle and need to be further specified or they are completely incompatible. Algebraic effects can only handle effects that trivially commute. So monad composition is a finer, thus more expressive operation.
      - 9y ago

Karrot_Kream 9y ago

The benefit of working with typeclasses has always been the ability to see and abstract out patterns that occur through Functors, Applicatives, Monoids, et al. I think ML is much more hyped up than monadic pure functional programming.

alphaalpha101 9y ago
>The benefit of working with typeclasses has always been the ability to see and abstract out patterns that occur through Functors, Applicatives, Monoids, et al. Which leads to code that needs to be puzzled out, rather than code that flows naturally. 'What does [arbitrary-monad-operationM_] mean for SomeMonadTransformerStack again???' is all too common in my experience. I really think that's false abstraction, like an 'object' superclass in OO languages.
- aninhumer 9y ago
  There aren't that many different compositions, and they're mostly just variants of map and fold for different contexts. And once you learn them, it's a lot easier to see what code using them does at a glance, rather than reading the corresponding for loop to work out what it does, and whether it has any side effects.
  - alphaalpha101 9y ago
    I disagree. It's a lot harder to see what code using them does at a glance, because the names are meaningless. 'forM' means what, exactly? Nothing. It means nothing until you apply it to a particular monad. It's trivial to read a loop, because it's right there. It's trivial to tell if it has any effects, because they're notated right there as algebraic effects.
    - deleted 9y ago
      [deleted]
    - aninhumer 9y ago
      >'forM' means what, exactly? Nothing. It means nothing until you apply it to a particular monad. It means you're mapping over something and collecting the results. Yes you need a little more information to understand exactly what you're mapping over or what "collect" means in this context, but this is still more information that `for` gives you without reading more. Although I find in practice it's usually fairly obvious what `forM` means in context, because you're likely writing a lot of code working with the same monads. >they're notated right there as algebraic effects. I'm not sure what you mean by this. Unless you're using some kind of advanced imperative language with effect types, they're not "right there", you have to infer them from the code. Whereas with Haskell you usually have a type signature which tells you what the effects are.

naasking 9y ago

Haven't you heard? Monads are old-school, algebraic effects are the future! ;-)

tathougies 9y ago

I don't understand this comment, almost every compiler and language in existence uses monads for computation. Monadic sequencing is the foundation of almost every CPU. Most languages are utterly dependent on them. Haskell and other pure languages let you compute values independent of the monad its computed in, which is very useful. Of course, this is all conceptual, eventually everything is translated to underlying CPU monad and its implicit join.

julian_1 9y ago
Why join rather than bind?
Veedrac 9y ago
> Monadic sequencing is the foundation of almost every CPU. What on earth are you modelling a CPU as? What thing a CPU does corresponds to join?
alphaalpha101 9y ago
I'll point out again that this is very reminiscent of the OOP fad and "everything is an object". "Everything is a monad" is similar. "It's all just the CPU monad" is just.. inane. It's like saying 'C functions are pure functions that implicitly take and return the world'. Maybe? But at that point 'pure' has lost all of its information content.