Илья Ермаков писал(а):
Какая разница, компилятор человеку всё равно нужен. Клюкнет один раз по коммандеру. Или программа сама при запуске сгенерирует и подгрузит модуль. В динамической системе проблема надумана. Разделение между средствами времени компиляции и времени выполнения - старая штука, неудобно. Лучше я сам решу, какой из модулей что генерирует, компилирует и подгружает.
Во-первых, неудобно. Вам кроме исходных текстов придётся распространять скомпилированную утилиту, которая будет всё это проверять (в вашем примере - собственно БлекБокс со встроенным "загрузчиком").
А что, если у вас нету этой готовой утилиты для целевой платформы, а есть только компилятор? Вполне реальная ситуация, не так ли?
Если вы считаете, что проверка параметров системы не нужна при компиляции, попробуйте собрать любую сишную программу под Linux. Скорее всего, вам придётся выполнить три комманды:
Код:
./configure
make
make install
То есть сначала вам
с помощью скрипта придётся сконфигурировать будущую программу, а затем уже компилировать. Если У вас есть возможность совместить эти две стадии, причём обычная, штатная возможность языка, не является ли это плюсом? Не, можно и с configure/make, кто ж помешает Блаб-программисту, только вам для создания дистрибутива своей программы придётся не только свой основной язык знать, но и ещё один, скриптовый для целевой платформы. Причём для разных платформ скрипты тоже придётся писать разные.
Это было всё ещё "во-первых", а во-вторых, что вы будете делать, если нужно заменять некоторые параметры
внутри текста программы? Я же не зря вспомнил про условную компиляцию в С++. Например, вам нужно написать библиотеку, вызывающую функции операционной системы, но в зависимости от того, Linux это или Windows, функции, естественно, будут отличаться. Без условной компиляции вы не то, чтобы свалить при выполнении программы, вы даже собрать её не сможете. И не надо тут говорить о грамотном проектировании и необходимости вынесения всех системозависимых функций в отдельный модуль - такая возможность может и не представиться или оказаться крайне неудобной.
Илья Ермаков писал(а):
Вы с Латехом, кстати, работали? ... (а тонкостей там, уж поверьте, возникает дофига..).
Увы, не довелось. Тонкостей много в Латексе? Возможно, вам виднее. В Лиспе никаких тонкостей нет - всё прозрачно до безобразия. Насчёт Nemerle не знаю, но судя по тому, что они даже статическую проверку типов в макросы ввели, думаю, там с этим тоже всё ок.
Илья Ермаков писал(а):
По конкретному примеру - частая проектная ошибка: делать процедуру Open&... Открытие конкретного файла, закрытие и т.п. - дело верхнего уровня, "скриптовой логики", так сказать.
Верхнего, не верхнего - всё равно где-то это делать надо. Ну не нравятся вам файлы, возьмите потоки, сокеты или те же базы данных (вы же не станете управлять открытием/закрытием сессии с верхнего уровня приложения, так ведь?). Вы ищете обходные пути, оправдания, причины, почему так делать нельзя, вместо того, чтобы предложить решение проблемы на заданном языке.
Илья Ермаков писал(а):
Обычно неявный механизм тяготеет к тому, чтобы становиться избыточно сложным. Потому, что для незаметности существования ему необходимо выполнять принятие решений. Чтобы принимать решения, ему нужно иметь кучу опций. Ну и т.п.
Вы конкретный пример приведите. Я вот предложил два широко распространённых макроса - time и with-open-file. У первого никаких параметров, у второго - имя файла и направление в/в. И их хоть где применяй, хоть как комбинируй, сложность каждого макроса в отдельности останется константной, а всех вместе - линейнозависимой от их количества. Такой же, как и при использовании функций, только гораздо меньше, потому что строк кода гораздо меньше, а программисту проще писать и читать получившуюся программу.
И заметьте, ничего неявного в этих макросах нет: можно подумать сложно догадаться, что скрывается за макросом time.
Евгений Темиргалеев писал(а):
Если писать методом бездумного последовательного клепания, а то эти макросы позволяют сократить размер тела процедуры и избежать лишней писанины и совсем не заботиться о грамотном построении программы. Механизм от клепальщиков и для клепальщиков.
То же самое - когда найдёте конкретный пример "безграмотной писанины для клепальщиков", тогда будет о чём поговорить. Пока что вы просто кидаетесь красивыми словами и ведетё себя как типичный Блаб-программист. И если уж Пол Грехем вас не переубедил, то мне и подавно это не удастся.
Цитата:
Впрочем, из этого утверждения редко делается вывод. Программисты старше определенного возраста редко меняют язык по своей воле. Они будут считать достаточно хорошим тот язык, к которому привыкли.
Евгений Темиргалеев писал(а):
Процедуру можно передать как параметр (процедурный тип). Общий контекст можно передать через параметр-ссылку типа запись. В общем случае ANYREC. Но не припомню, чтобы это очень часто приходилось делать.
Естественно не часто, потому что это жутко неудобно - сначала вынести все нужные функции в отдельную процедуру, потом создать RECORD, и только после этого передать всё это в функцию. А в Лиспе я просто дописываю одну строчку вверх, и всё. Язык формирует способ нашего мышления (с).
В общем, мне кажется, я привёл достаточно примеров, чтобы хотя бы заинтересовать вас в изучении макросов как концепции. Если вы всё ещё считаете, что у вас не бывает повторяющихся шаблонных кусков кода, или вам не нужна возможность совершать произвольные действия во-время компиляции, значит и дальше этот разговор ни к чему не приведёт, а спорить о пустом для меня же дороже.