Geniepro писал(а):
Ну да, приходится дописывать "fun _ ->", ну так 8 символов дописать не так уж и трудно, зато не надо париться с закрывающими скобками...
Ну так да, собственно в данном случае всё сводится именно к 8 символам
Ну и к естесственности. Я имел ввиду, что если в языке есть два средства, обоими из которых можно выполнить задачу, то правильнее будет использовать то из них, которое более естественно для данной задачи. Вот для and, например, гораздо удобнее было бы использовать ленивую функцию, чтобы её можно было передать как аргумент, однако в Лиспе ленивость не встроенная, поэтому при передаче, например, в reduce, приходится делать так:
Код:
(lambda (x y) (and x y))
Гораздо интереснее использовать макросы там, где функция не прокатит. Например, мне бы очень хотелось иметь возможность написать макрос, повторяющий функциональность deriving'а при объявлении типов в Haskell:
Код:
data Week = Sunday | Monday | Tuesday | Wednesday | Thursday | Friday | Saturday deriving (Eq, Ord, Show)
(Помнится, в GHC собирались что-то с этим сделать, но получилось ли что-нибудь, не знаю).
Geniepro писал(а):
Разве Вы забыли, как R6RS расколол скимеров на три лагеря -- за новый стандарт (R6RS), за старый стандарт (R5RS), и за альтернативу новому стандарту (ER5RS)?
Забыл, каюсь. Но суть высказывания от этого не меняется: даже появление новых макросов не ведёт к лавинообразному увеличению сложности, напротив, благодаря единой форме они делают подавляющую часть конструкций однообразной, избавляя от необходимости соотносить новые фичи со всем списком старых. Базовые понятия то не изменяются, изменяется только способ их представления.
Илья Ермаков писал(а):
Теперь я поставлю задачу агитаторам за макросы. Хочу, чтобы макрос был не текстовым, а графическим. Прямо в программу вставлять визуальные схемы, по которым макропроцессор генерирует текст. Ваше решение? С Немерлями, Лиспами, чем угодно? Я в ББ - на раз.
То ли смеяться, то ли плакать. А попробуйте с помощью ББ фанарик сделать. А я вот с помощью паяльника легко.
Может всё-таки не будем мешать язык, пусть даже и с рантаймом, и конкретную программу? А то можно же и к автокадовцам сходить посмотреть на их визуальные схемы на их же АвтоЛиспе.
Вы рамки обсуждения то определите, а то у вас и язык, и компилятор, и фреймворк, и среда разработки, и ещё чёрт знает что. Я, вот, говорю про язык. И всё.
Algo писал(а):
Но считаю, что аналогия не корректная, рекурсия это действительно очень просто
Правда что ли? А по какому критерию вы меряли? Хотите по Колмогорову померяем сложность? А давайте, почему бы и нет. В качестве критерия возьмём длину описания, например. Вы во сколько слов сможете описать понятие рекурсии? Я понятие макросов в 2: "Макрос - это функция". Ну ладно, ответ не развёрнутый, можно трактовать как не полный, субъективный и бла бла бла. Обратимся на Википедию:
http://ru.wikipedia.org/wiki/%D0%9C%D0% ... 0%BE%D1%81http://ru.wikipedia.org/wiki/%D0%A0%D0% ... 0%B8%D1%8FМакрос - 10 слов, рекурсия - 36 слов (со всеми предлогами).
Ну да ладно, математическая сложность - это одно, а сложность для понимая - другое. Ну и как вы сможете объяснить не программисту, что такое рекурсия, когда её ни в природе, ни в человеческом обиходе вообще нет? Как по мне, так самое понятное объяснение рекурсии дано в анекдоте: "Чтобы понять рекурсию, нужно сначала понять рекурсию". (Хотя, строго говоря, следуя определению с Википедии, оно является неточным, т.к. не включает упоминания о необходимости описания конечных состояний объекта).
Если вы не владеете одним инструментом, это не значит, что он сложнее, чем другой, которым вы владеете.
Однако я не хотел бы спорить о сложности рекурсии и макросов, ибо оба понятия важны и обоими инструментами нужно уметь пользоваться.