Продолжения на генераторах сделать нельзя по построению -- генератор не захватывает продолжение за пределами генератора. Так что они строго менее выразительные, чем монады. Вопрос на этом можно закрыть.

Человек то ли не понимает, что такое монады, то ли намеренно вводит публику в заблуждение. С теоретической точки зрения монады как раз и описывают машинный код (протаскивают состояние машины через цепочку инструкций). Их изначально в семантику для этого и ввели. Потому что с чисто функциональной точки зрения машинный код - это нонсенс, а денотационная семантика чисто функциональна. Вот эту проблему несоответствия и решили монадами/комонадами.

Абстракции не ломаются, просто одна монада трансформируется в другую.

На практике, с математической (логической) точки зрения, мы всегда работаем в монадах. Монады повсеместны там, где есть хотя бы переменные. Превращение колец в кольца многочленов - это тоже монады.

Самый ли это удобный способ выражения программ? Не знаю. Спорный вопрос. Вот в Lisp-ах мы всегда неявно живём в монаде списков, явно нигде монады не упоминаются, и это позволяет матрицы транспонировать через (apply map list M), и это круто.

Может, явный синтаксис для монад и не нужен, но знать про них и уметь с ними работать - навык полезный.

Протаскивают состояние машины через цепочку инструкций - это не монада. Операций bind и pure в явном виде там нет. Переопределить их и просто так запустить код в другой монаде не представляется возможным, за исключением компиляции из языка, где эти монады имеются. Да и сама компиляция будет не слишком тривиальна, если хочется получить эффективный код.

Там есть явный bind - граница между двумя инструкциями. И есть яный pure - это оформление кода в виде вызывемой подпрограммы. Учите матчасть, как бы. Дело всё именно в логике и математике, а не каких-то персональных хотелках. Людям нужен был формализм для описания семантики ассемблера в функциональном стиле, они его и вывели. Понятно, что могут быть и другие стили. Но если мы хотим какого-то алгебраического математического описания на языке функций, монады возникают естественно. Только об этом речь.

Проблема тут только в том, что в математике у нас основной язык - это язык функций. ООП в математике нет, поэтому его и не втащил никто в денотационную семантику. А функции есть, поэтому из них всё и построено (в том числе и ООП).

Особенность подхода, и только. Это ж не религия, а просто полезный инструмент.

Почему не может?

Нет этого полезного инструмента во многих языках. В том числе и в ассемблере

Я вам о математике, а Вы мне о байтиках. Ну, ладно. Не хотите пользоваться - не пользуйтесь :) Не понятно только, зачем отговаривать тех, кто пользуется?

По построению. Генераторы так устроены. 😊

В машинном коде есть только регистры, память и инструкции

Железо вообще не про какие монады не слышало. Да и о порядке вычисления имеет своё представление.

Железо много о чем не слышало, но это не мешает разработчикам использовать концепты :/

Более того. Даже функций (в императивном смысле, да и в функциональном тоже) как отдельной абстракции как таковых в машинном коде нет.