3 ms·

> Sure - this is how control flow tends to work in monad-oriented languages too, with constructs like ifM . I don't see a conflict between this style and what I

> Sure - this is how control flow tends to work in monad-oriented languages too, with constructs like ifM . I don't see a conflict between this style and what I see as the good aspects of Smalltalk at all; rather I see this style as a way to get those aspects while having type safety as well. The point here is not that Smalltalk is better or worse; the point is that Smalltalk's approach can be seen as more general. In other words, it's a matter of perspective as to what is considered to be a sufficient amount of generality. Types are orthogonal to that (see Strongtalk). Edit: To clarify something: > The Free monad is essentially that (it's a type-aligned sequence of things that look like Kleisli arrows, which is pretty much the type-safe equivalent of an array of blocks), and it's well-known that you can emulate any monad that way (specific concrete monadic types are nice to have as well though, for the cases where you do want to talk about that specific type). If you're saying that monads are something banal rather than something complex and impressive then I completely agree. Partly that (I've said before that I much prefer the F# terminology of "computation expressions" to get the purpose across), but my larger point is that this would be considered to be a very specific and limited application to a Smalltalk programmer. Again, it's not about Smalltalk being better or worse, it's about "can be generalized" as a matter of perspective.

lmm 9y ago
> The point here is not that Smalltalk is better or worse; the point is that Smalltalk's approach can be seen as more general. In other words, it's a matter of perspective as to what is considered to be a sufficient amount of generality. How so? What's the generality that's missing here? Again, completely permissive doesn't necessarily mean more general. > Partly that (I've said before that I much prefer the F# terminology of "computation expressions" to get the purpose across), but my larger point is that this would be considered to be a very specific and limited application to a Smalltalk programmer. Sure; again, this is true from the functional/monad-oriented perspective too. Monads are a synecdoche because they happen to come up quite often, but they're really just one reusable construction among many, and certainly admit a couple of useful generalisations.
- rbehrends 9y ago
  > How so? What's the generality that's missing here? Again, completely permissive doesn't necessarily mean more general. Monads – or rather, what Haskell and Scala use monads for, to distinguish that from the category theory concept – are primarily about "enriched" function composition (yes, I know that I'm simplifying here). That is useful, but also very limiting when the logic with which you want to glue pieces of code together does not fit that schema. A lot of the usefulness of monads also depends on the language supporting the syntactic sugar ("do" in Haskell or "for" in Scala) to make the resulting code readable. > Monads are a synecdoche because they happen to come up quite often, but they're really just one reusable construction among many, and certainly admit a couple of useful generalisations. I'd argue that monads are an artifact of pure functional programming (or attempts to approximate pure functional programming in impure languages). As soon as you have mutable local state and closures, virtually all use cases of monads for programming (not counting actual category theory applications) disappear. Note that I'm saying mutable local state. The arguments against mutable global state do not really apply to local state. Thus, for those other languages, most of the practical need for monads disappears and monads really become a more limited way of expressing higher-order program logic.
  - lmm 9y ago
    > Monads – or rather, what Haskell and Scala use monads for, to distinguish that from the category theory concept – are primarily about "enriched" function composition (yes, I know that I'm simplifying here). That is useful, but also very limiting when the logic with which you want to glue pieces of code together does not fit that schema What kind of logic might that be? You keep saying there's a generalisation but you keep not showing what it actually is. > A lot of the usefulness of monads also depends on the language supporting the syntactic sugar ("do" in Haskell or "for" in Scala) to make the resulting code readable. Up to a point. I've done some work with (free) applicatives lately, which have no direct language support, but it turns out you can get a lot of the value anyway. > I'd argue that monads are an artifact of pure functional programming (or attempts to approximate pure functional programming in impure languages). As soon as you have mutable local state and closures, virtually all use cases of monads for programming (not counting actual category theory applications) disappear. I find them useful for any kind of cross-cutting concern - all the AOP examples. Audit logs, database transactions, validation, authorization, that kind of thing. To solve these things with something state-like that state has to be pseudo-global and has most of the problems of global state; to solve them with closures you need a way to compose closures at which point you're most of the way to monads.

lmm 9y ago

> The point here is not that Smalltalk is better or worse; the point is that Smalltalk's approach can be seen as more general. In other words, it's a matter of perspective as to what is considered to be a sufficient amount of generality. How so? What's the generality that's missing here? Again, completely permissive doesn't necessarily mean more general. > Partly that (I've said before that I much prefer the F# terminology of "computation expressions" to get the purpose across), but my larger point is that this would be considered to be a very specific and limited application to a Smalltalk programmer. Sure; again, this is true from the functional/monad-oriented perspective too. Monads are a synecdoche because they happen to come up quite often, but they're really just one reusable construction among many, and certainly admit a couple of useful generalisations.

rbehrends 9y ago
> How so? What's the generality that's missing here? Again, completely permissive doesn't necessarily mean more general. Monads – or rather, what Haskell and Scala use monads for, to distinguish that from the category theory concept – are primarily about "enriched" function composition (yes, I know that I'm simplifying here). That is useful, but also very limiting when the logic with which you want to glue pieces of code together does not fit that schema. A lot of the usefulness of monads also depends on the language supporting the syntactic sugar ("do" in Haskell or "for" in Scala) to make the resulting code readable. > Monads are a synecdoche because they happen to come up quite often, but they're really just one reusable construction among many, and certainly admit a couple of useful generalisations. I'd argue that monads are an artifact of pure functional programming (or attempts to approximate pure functional programming in impure languages). As soon as you have mutable local state and closures, virtually all use cases of monads for programming (not counting actual category theory applications) disappear. Note that I'm saying mutable local state. The arguments against mutable global state do not really apply to local state. Thus, for those other languages, most of the practical need for monads disappears and monads really become a more limited way of expressing higher-order program logic.
- lmm 9y ago
  > Monads – or rather, what Haskell and Scala use monads for, to distinguish that from the category theory concept – are primarily about "enriched" function composition (yes, I know that I'm simplifying here). That is useful, but also very limiting when the logic with which you want to glue pieces of code together does not fit that schema What kind of logic might that be? You keep saying there's a generalisation but you keep not showing what it actually is. > A lot of the usefulness of monads also depends on the language supporting the syntactic sugar ("do" in Haskell or "for" in Scala) to make the resulting code readable. Up to a point. I've done some work with (free) applicatives lately, which have no direct language support, but it turns out you can get a lot of the value anyway. > I'd argue that monads are an artifact of pure functional programming (or attempts to approximate pure functional programming in impure languages). As soon as you have mutable local state and closures, virtually all use cases of monads for programming (not counting actual category theory applications) disappear. I find them useful for any kind of cross-cutting concern - all the AOP examples. Audit logs, database transactions, validation, authorization, that kind of thing. To solve these things with something state-like that state has to be pseudo-global and has most of the problems of global state; to solve them with closures you need a way to compose closures at which point you're most of the way to monads.