3 ms·

I see two problems with this line of argument. One is that specializations are useful and are often more prevalent in practical use. Examples: 1. Just because

I see two problems with this line of argument. One is that specializations are useful and are often more prevalent in practical use. Examples: 1. Just because a while loop subsumes the functionality of a for loop doesn't make the for loop useless. 2. Algebraic data types are technically subsumed by inheritance and predicate dispatch [1]. That doesn't make ADTs useless, because often you don't want to lug the extra baggage of the more powerful model around with you, especially for simple use cases. The other problem is that "more general" is in the eye of the beholder. For example, to a Smalltalk programmer, most use cases for monads look pretty primitive, as they're limited to user-defined control flow on a sequence of operations, nothing more complicated; they'd be implemented in Smalltalk as operations on arrays of blocks. Keep in mind that Smalltalk doesn't even have if statements in the language proper: `ifTrue:` and friends are methods of the Boolean class. Similar things apply to other control structures, such as `whileTrue:`, not to mention that plenty of data types offer their own control structures. And the continuation monad in the article looks a lot less impressive compared to Seaside [2], one of the original continuation-based webservers. (I'll also add that the reason for `.then(..)` or `async/await` is often that the underlying languages do not support continuations, not that they model the non-existent continuations imperfectly.) [1] See "Predicate Dispatch: A Unified Theory of Dispatch" by Michael Ernst, Craig Kaplan, and Craig Chambers, https://homes.cs.washington.edu/~mernst/pubs/dispatching-ecoop98.pdf https://homes.cs.washington.edu/~mernst/pubs/dispatching-eco... [2] http://seaside.st/about/examples/counter http://seaside.st/about/examples/counter

lmm 9y ago
> 1. Just because a while loop subsumes the functionality of a for loop doesn't make the for loop useless. 2. Algebraic data types are technically subsumed by inheritance and predicate dispatch [1]. That doesn't make ADTs useless, because often you don't want to lug the extra baggage of the more powerful model around with you, especially for simple use cases. I think here you're assuming that a feature that allows more possibilities to be expressed subsumes one that doesn't, and I would disagree; being able to clearly restrict the possibilities is important too. As an exaggerated example, replacing all the language builtins with a single builtin that took a parameter to say which builtin it was wouldn't be an improvement. (At the same time being able to talk about different builtins in a uniform way - e.g. being able to use a builtin function as a value - is a useful generalisation - I see monads as more like this). > to a Smalltalk programmer, most use cases for monads look pretty primitive, as they're limited to user-defined control flow on a sequence of operations, nothing more complicated; they'd be implemented in Smalltalk as operations on arrays of blocks. 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. > Keep in mind that Smalltalk doesn't even have if statements in the language proper: `ifTrue:` and friends are methods of the Boolean class. Similar things apply to other control structures, such as `whileTrue:`, not to mention that plenty of data types offer their own control structures. 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.
- rbehrends 9y ago
  > 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.
    - 9y ago

lmm 9y ago

> 1. Just because a while loop subsumes the functionality of a for loop doesn't make the for loop useless. 2. Algebraic data types are technically subsumed by inheritance and predicate dispatch [1]. That doesn't make ADTs useless, because often you don't want to lug the extra baggage of the more powerful model around with you, especially for simple use cases. I think here you're assuming that a feature that allows more possibilities to be expressed subsumes one that doesn't, and I would disagree; being able to clearly restrict the possibilities is important too. As an exaggerated example, replacing all the language builtins with a single builtin that took a parameter to say which builtin it was wouldn't be an improvement. (At the same time being able to talk about different builtins in a uniform way - e.g. being able to use a builtin function as a value - is a useful generalisation - I see monads as more like this). > to a Smalltalk programmer, most use cases for monads look pretty primitive, as they're limited to user-defined control flow on a sequence of operations, nothing more complicated; they'd be implemented in Smalltalk as operations on arrays of blocks. 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. > Keep in mind that Smalltalk doesn't even have if statements in the language proper: `ifTrue:` and friends are methods of the Boolean class. Similar things apply to other control structures, such as `whileTrue:`, not to mention that plenty of data types offer their own control structures. 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.

rbehrends 9y ago
> 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.
  - 9y ago