3 ms·

Oh, monads.. sooner or later they will be mentioned.) Actually it is a canonical example of abstraction for the sake of having an abstraction, which only increa

Oh, monads.. sooner or later they will be mentioned.) Actually it is a canonical example of abstraction for the sake of having an abstraction, which only increases confusion. Monads make no sense in a non-lazy language. http://karma-engineering.com/lab/wiki/Monads2 http://karma-engineering.com/lab/wiki/Monads2

mbrock 10y ago
That blog post is a mean-spirited rant and mostly lacking in substantial argument.
lliamander 10y ago
> Oh, monads.. sooner or later they will be mentioned. Yep, monads :). > Actually it is a canonical example of abstraction for the sake of having an abstraction, which only increases confusion. I intentionally brought them up with a concrete, real-world example where they were useful. > Monads make no sense in a non-lazy language. A more accurate statement might be "monads make no sense in a non-lazy evaluation context". There are plenty of cases when working in an otherwise strict language you will compose a series of computations over a lazy data-source. For example: you want to process a potentially large series of rows coming from a database without blowing through RAM. You can solve this problem on an ad-hoc basis, but as far as I understand it, the folks working on LINQ wanted to develop a declarative, readable, sql-like syntax for creating/composing such computations in a way that would work generically across data-sources. The question is, what is the pattern of operations and constraints that is common to all of the disparate data-sources that can be used in this way? The monadic functions + monadic laws is a precise (if arcane) description of those operations and constraints. Using monads is not the only way to structure computation in the context of lazy evaluation, but it is one that is relatively well understood and worked well with the goal of being "sql-like" because SQL queries can be modeled as monadic computations.

mbrock 10y ago

That blog post is a mean-spirited rant and mostly lacking in substantial argument.

lliamander 10y ago

> Oh, monads.. sooner or later they will be mentioned. Yep, monads :). > Actually it is a canonical example of abstraction for the sake of having an abstraction, which only increases confusion. I intentionally brought them up with a concrete, real-world example where they were useful. > Monads make no sense in a non-lazy language. A more accurate statement might be "monads make no sense in a non-lazy evaluation context". There are plenty of cases when working in an otherwise strict language you will compose a series of computations over a lazy data-source. For example: you want to process a potentially large series of rows coming from a database without blowing through RAM. You can solve this problem on an ad-hoc basis, but as far as I understand it, the folks working on LINQ wanted to develop a declarative, readable, sql-like syntax for creating/composing such computations in a way that would work generically across data-sources. The question is, what is the pattern of operations and constraints that is common to all of the disparate data-sources that can be used in this way? The monadic functions + monadic laws is a precise (if arcane) description of those operations and constraints. Using monads is not the only way to structure computation in the context of lazy evaluation, but it is one that is relatively well understood and worked well with the goal of being "sql-like" because SQL queries can be modeled as monadic computations.