Здравствуйте, so5team, Вы писали:

ЕМ>>Каковы исходные предпосылки этой принципиальности?

S>Чтобы называть вещи своими именами.

Какими еще "своими"?

Вот термин "процессор" много лет определялся, как сочетание АЛУ и УУ, не имеющее ни памяти, ни интерфейсов со внешними устройствами. Потом постепенно привыкли к тому, что в процессор может входить и кэш-память, а теперь у Ryzen непосредственно из кристалла идут сразу линии PCIe, SATA и USB.

S>Если в терминологии возникает слишком много вольностей, например, кто-то обзывает паттерн проектирования "Facade" как "Bridge", то это ведет лишь к запутыванию.

Какая путаница возникает, когда микросхемы Ryzen называют "процессорами"? Какие негативные последствия она создает? Как нам нужно их называть, чтобы избежать путаницы? Какие позитивные последствия это повлечет?

S>Это точно так же, как если бы я сперва заявлял бы, что разрабатываю программы в функциональном стиле, а потом бы показал код в котором классы, наследование, виртуальные методы, мутабельное состояние в объектах и вот это вот все.

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

Сколько сумеете найти серьезных работ по ЯВУ, в которых "макропрограммирование" противопоставляется "метапрограммированию", а не является его частным случаем? Желательно более общего характера, чем на основе макросов C и шаблонов C++, а также языков, достаточно прямо унаследовавших это разделение. Желательно, чтоб авторы были знакомы с реализациями 60-х, а не ограничивали горизонт началом-серединой 80-х, как это нынче принято.