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

V>Макросы в конечном итоге это просто подмена текста. Что там и на что подменяется компилятор проверять не обязан.

Это примитивные, убогие сишные макросы, которые в C++ перетащили для совместимости, заранее объявив абсолютным злом, и постеснявшись хоть как-то улучшить.

V>А шаблоны это генератор типов, когда заранее известно, что работаем с конструкциями типов.

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

V>Я не углублялся в теорию компиляторов, но суть отказа от макросов при компиляции в оптимизации, которую проводит компилятор переводя конструкции языка в машинный код. Твоя же мысль звучит как давайте создадим более продвинутый генератор, который позволит учитывать ещё больше. Но где гарантия, что к примеру у тебя получится создать что-то лучше, а не те же шаблоны C++ только с перламутровыми пуговицами.

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

V>Альтернатива это берёшь те же шаблоны C++ и создаёшь на их основе свои библиотеки алгоритмов.

Ну, это не намного удобнее, чем делать на макросах в их существущем виде. Пока все просто и ортогонально, оно выглядит изящно и логично, но с ростом сложности библиотеки сложность записи растет очень быстро, и довольно скоро превращается в уродливую мешанину, половину которой составляют костыли.

V>Один программист видит вот так и пишет код вот так. А другой видит по другому и у него другой алгоритм и другие названия.

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

V>если тебе всё ещё нравится стиль Си, а макросы о которых мы говорим это именно они

Мне не нравится ни "стиль Си", ни "стиль C++" в их крайних вариантах. И то, и другое одинаково убого и уродливо, разве что последний позволяет больше спрятать под капотом до того момента, как капот сорвет давлением изнутри. А вот имей язык возможность определять макросы более широко, и порождать из них программный код более гибко — глядишь, и macro hell бы удалось изжить, и template hell вместо него не нажить.

V>хотя они поддерживаются в C++ ими можно уже не пользоваться, так попробуй сделать на них что-нибудь адекватное.

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

V>люди подсели на фреймворки и прочие чужие библиотеки алгоритмов, а всё потому, что написать что-то своё долго, сложно и дорого.

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