I think a lot of people are missing the point of the article. People are complaining about the complexity of the function or similar, which is basically brushing off that some problem domains just are complex.
Putting this into context, the author is demonstrating a function from his effect system library called Polysemy[0], which is a both complex concept and a complex problem to solve.
To achieve this with his library, some complicated plumbing is necessary, and one of those functions happen to be `hoistStateIntoStateT`. The author's point is then summarised perfectly by:
> Gee, that’s complicated! I must be really smart to have written such a function, right?
> Wrong! I just have a trick!
The author shows how you can, when posed with just knowing the type you want to achieve, more or less generate/infer the implementation from that.
This is a common situation when stitching functions or parts of your program together, where you have an `A` and want to transform it into a `B`, given the functions you have available.
> The author shows how you can, when posed with just knowing the type you want to achieve, more or less generate/infer the implementation from that.
All this means is that, with a robust enough type system, determining the correct type is exactly as complex as determining the correct implementation.
In some cases, in some languages, expressing the solution in the language of types may be more intuitive than and help guide the language of implementation, but, because they are essentially encoding each other, that's not only as subjective as any question of what is intuitive must be, but also an artifact of the particular type language and implementation language. In a different implementation language, the problem may be as (or more!) intuitive as it is in the type language in use.
Putting this into context, the author is demonstrating a function from his effect system library called Polysemy[0], which is a both complex concept and a complex problem to solve.
To achieve this with his library, some complicated plumbing is necessary, and one of those functions happen to be `hoistStateIntoStateT`. The author's point is then summarised perfectly by:
> Gee, that’s complicated! I must be really smart to have written such a function, right? > Wrong! I just have a trick!
The author shows how you can, when posed with just knowing the type you want to achieve, more or less generate/infer the implementation from that.
This is a common situation when stitching functions or parts of your program together, where you have an `A` and want to transform it into a `B`, given the functions you have available.
[0] https://github.com/polysemy-research/polysemy