И из-за этого не стоит пытаться объяснять функтор на интерфейсах без ХКТ

смотрите как можно

Функтор можно объяснить вообще без введения интерфейса. Мол если ваш тип реализует операцию мап с определенными законами, то для этого типа есть функтор. Это знание необязательно оформлять в виде интерфейса или тайпкласса. В конце концов люди типы в голове держат, почему бы это не держать

-19

Monads simply aren't important to .NET programmers. Without even knowing monads exist you can still build the LINQ framework. More importantly, it wouldn't look any different. It doesn't matter if you think in terms of monads (Haskell), expression tree rewriting (Lisp), set-based operations (SQL), or using map/reduce to create new types (Ruby, Python), the end result is going to be the same.

In fact, I would go so far as to say that monads are downright useless to .NET developers. Every time I see a library for .NET based on monads, it is invariably both more verbose and less comprehensible than straight C# or VB code. The reason is simple, languages like C# and VB are built on much, much more powerful building blocks than languages like Haskell.

Haskell in particular needs to use monads for everything because that is all they have. The same goes for macros in Lisp or dynamic typing in JavaScript. When you have a one-trick pony, that trick has to be pretty damn good.

Я и так знаю, что не выйдет. И я попытался объяснить) Но блин - Option - это монада, Future - это монада, и HKT для их использования не нужны

Это неуважение к участникам дискуссии.
Воздержитесь от таких комментариев.

Да, и для их использования так же не нужны интерфейсы

А че, future это монада ?

да

Законы?

смотря какая

Хкт нужно для абстракции от конкретной монады

Да. Но нужна ли абстракция от конкретной монады?

Скаловая, не Твитер

Судя по вашей же статье, нужна, раз вы сделали интерфейс

Зависит от того, шо в неё класть

Но это плохой пример манадки

Оххх чего бы я точно не хотел, так это стать автором очередного карго-культа.