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

M>>>чтоб воздействие пойнткатов было явно отмечено (аннотациями, а не регэкспами имён функций и полей) — станет нормальным инструментом.
C>>Эээ.. AspectJ это уже давно умеет. В Spring'е и EJB3 это вообще везде используется.
M>"Давно" не получится. Аннотации в яве появились считай что вчера
JDK5 вышла в 2004 году. Уже три года скоро будет.

M>Собственно, именно AspectJ и аннотации я и имел в виду. Просто когда я 6 лет назад работал в AspectJ — аннотаций и в помине не было, и я им говорил, что "надо добавить пользовательские модификаторы/метки, иначе это хак чистой воды".
Лично помню, что прикручивал атрибуты из JavaDoc'а к AspectJ в 2003 году. Так что при желании все было.

M>На что мне ответили, что нихрена я не понимаю в крутизне AspectJ. Поэтому у меня очень специфическое отношение к AspectJ вообще, и интеллекту его создателя в частности. Когда они с Чарльзом Симони сделали фирму для продвижения Intentional Programming — я подумал "ну вот, наконец AOP будут применять в качестве определения операций, а не запутывания кода, и станет нормальной технологией". А потом Gregor ушёл из IP — я понял, что он полный даун, вместе с его AspectJ.
Аспекты замечательно использовать для некоторых вещей — PojoCache из JBoss, например. Ну или классические logger'ы и security.

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

бейсик. неужели ты не играл в donkey?

K>Самый дальний родственник нынешнего Template Haskell и Nemerle — это, наверное, MetaML — а по нему и статей старее 1998-го года нет. Мне, как физику, совершенно непонятно, как могут плоды исследования 1998-го года быть опробированы в 1970-м.

препроцессор pl/1 имел синтаксис, аналогичный самому pl/1

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

C>Какие проблемы с reflection'ом, что у него такие "вытекающие последтсвия"?

Тормоза.

C>Для таблицы в 100x100 (а больше — уже будем на лимиты браузера натыкаться) нужно всего порядка 10000 рефлективных вызовов. Это даже упоминания не стоит. Не говоря уж о возможности оптимизации рефлексии через динамически формируемые классы-аксессоры.

10000 нужно ещё умножать на фактор, зависящий от количества посетителей.

IT>>Во-вторых, несмотря на то, что вся информация о запросе у нас доступна в компайл-тайм, мы получим генерацию SQL в райн-тайм, опять же со всеми вытекающими последствиями.
C>Кэшируем подготовленные запросы.

И возвращаемся к тому, от чего так старательно уходили. Видел запрос в 3 строчки? Вот это наша цель. Понятное дело, что сделать можно всё, что угодно. Но зачем тогда всё это? Зачем нужен линк, если можно обойтись и без него?

C>Эээ... А кэшировать на уровне провайдера нельзя?

MS SQL?

IT>>В-шестых. Предположим, что ко всему прочему в моём приложении используется система ограничения доступа к контенту. При использовании линк я вынужне буду добавлять фильтрацию контента к каждому запросу. Вопрос, справятся ли с этим обезъянки.
C>А на уровне провайдера нельзя?

Какого провайдера?

C>Hibernate решает, например, все твои проблемы (что характерно, без макросов). При этом для NHibernate будет LINQ-интерфейс.

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

C>Хотя мне LINQ не нравится по другим причинам, но он не оправдание макросам.

Хибернейт мне тоже не нравится по многим причинам, поэтому я даже не хочу о нём в этом топике говорить.

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

C>>Какие проблемы с reflection'ом, что у него такие "вытекающие последтсвия"?
IT>Тормоза.
Premature optimization... — ну ты дальше сам знаешь.

C>>Для таблицы в 100x100 (а больше — уже будем на лимиты браузера натыкаться) нужно всего порядка 10000 рефлективных вызовов. Это даже упоминания не стоит. Не говоря уж о возможности оптимизации рефлексии через динамически формируемые классы-аксессоры.
IT>10000 нужно ещё умножать на фактор, зависящий от количества посетителей.
Для 100 запросов в секунду — будет всего миллион рефлексий. Кроме того, оптимизатор рефлексии вообще сведет оверхед к минимуму (по моим тестам в Java, генерируемые accessor'ы примерно в 10 раз быстрее стандартной рефлексии, которая примерно в 200 раз медленнее прямого вызова).

IT>>>Во-вторых, несмотря на то, что вся информация о запросе у нас доступна в компайл-тайм, мы получим генерацию SQL в райн-тайм, опять же со всеми вытекающими последствиями.
C>>Кэшируем подготовленные запросы.
IT>И возвращаемся к тому, от чего так старательно уходили. Видел запрос в 3 строчки? Вот это наша цель. Понятное дело, что сделать можно всё, что угодно. Но зачем тогда всё это? Зачем нужен линк, если можно обойтись и без него?
Дык без проблем. Вот живой код:

List<Need> needs=(List<Need>)sess.createQuery("from Need f inner join fetch f.position"
    "where f.date > :date and f.status='OPEN'")
    .setDate("date",needDate).setCacheable(true).list();

(в строке запроса работает автокомплит, просмотр генерируемого SQL и т.п. — injected languages в IDEA, однако).

А дальше байнди этот список куда тебе угодно.

C>>Эээ... А кэшировать на уровне провайдера нельзя?
IT>MS SQL?
Ну не знаю, Hibernate держит свой кэш на любом провайдере. Есть обертка (C-JDBC), которая делает то же самое для любой базы.

IT>>>В-шестых. Предположим, что ко всему прочему в моём приложении используется система ограничения доступа к контенту. При использовании линк я вынужне буду добавлять фильтрацию контента к каждому запросу. Вопрос, справятся ли с этим обезъянки.
C>>А на уровне провайдера нельзя?
IT>Какого провайдера?
Провайдера данных, к которому обращается LINQ.

C>>Hibernate решает, например, все твои проблемы (что характерно, без макросов). При этом для NHibernate будет LINQ-интерфейс.
IT>Я тоже все такие проблемы решаю и без макросов и, что характерно, без хибернейта. Но хочется абсолютного совершенства, а не подпорок и затычек.
Так может стоит посмотреть? А то все твои проблемы — высосаны из пальца, что называется.

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

BZ>бейсик.

Basic — статически типизированный язык.

BZ>препроцессор pl/1 имел синтаксис, аналогичный самому pl/1

Ну так что? Ключевой момент то в том, что это был препроцессор. Даже очень крутой препроцессор вроде Camlp4 все равно не является макросистемой, ведь он не может получить информацию о типах — для статически типизированного языка это имеет значение.

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

IT>>10000 нужно ещё умножать на фактор, зависящий от количества посетителей.
C>Для 100 запросов в секунду — будет всего миллион рефлексий. Кроме того, оптимизатор рефлексии

Кто такой, почему не знаю?

C>вообще сведет оверхед к минимуму (по моим тестам в Java, генерируемые accessor'ы примерно в 10 раз быстрее стандартной рефлексии, которая примерно в 200 раз медленнее прямого вызова).

По моим тестам, генерируемые аксессоры всего лишь в 3-4 раза быстрее рефлекшина, чего достаточно, чтобы кастомер на глаз замечал задержку.

C>Дык без проблем. Вот живой код:
C>

C>List<Need> needs=(List<Need>)sess.createQuery("from Need f inner join fetch f.position"
C>    "where f.date > :date and f.status='OPEN'")
C>    .setDate("date",needDate).setCacheable(true).list();
C>

C>(в строке запроса работает автокомплит, просмотр генерируемого SQL и т.п. — injected languages в IDEA, однако).

Допустим, так получилось, что я переименовал одно поле. Как отреагирует твой ынхибернейт:

List<Need> needs=(List<Need>)sess.createQuery("from Need f inner join fetch f.position"
    "where f.date > :date and f.statuus='OPEN'")
    .setDate("date",needDate).setCacheable(true).list();

C>Ну не знаю, Hibernate держит свой кэш на любом провайдере.

Видишь ли в чём дело. Машина не должна думать, машина должна ездить. Я не люблю когда машина додумывает за меня куда мне нужно ехать.

C>Так может стоит посмотреть? А то все твои проблемы — высосаны из пальца, что называется.

Боюсь, что из пальца как раз высосан твой ынхибернейт. Извини, но этот пост не о монстриках, этот пост о макросах, задача которых убрать из кода тексуальщину и заменить её на проверяемую компилятором декларативность.

Здравствуйте, IT, Вы писали:
IT>Какие именно последствия? Ты можешь однозначно, не в терминах "базовый уровень", "изменение граммитики" и прочей лабуды ответить на этот вопрос? Боюсь что нет. И никто не может, потому что опыта такого пока ни у кого нет. Точнее у некоторых он есть, причем положительный, но их здесь всё равно слушать никто не будет.
Ну почему же. Я вот очень внимательно слушаю.
Пока что мое мнение таково: это, конечно же, rather big gun, но фишка именно в том, что если ты пошел валить слона, то лучше иметь big gun, чем обходиться без него.
Я видел страшные вещи, которые люди ухитряются творить безо всякой помощи макросов. Если сильно хочется, могу привести парочку вполне реалистичных ужастиков про свойства, события и прочие, ставшие вполне привычными нам вещи.

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

Так что, имхо, пусть макросы немерле остаются в качестве last resort для случая, когда мы таки увидим очевидно хороший случай для их применения.

З.Ы. Я вот в свое время раз наверное десять прочитал главу про манипуляторы потоков ввода-вывода у Страуструпа, прежде чем понял, как это работает. Внутри у них достаточно сложное сочетание сразу нескольких механизмов языка. А в эизни народ с опытом в два дня пишет cout << "Hello" << endl; совершенно не стесняясь. А ведь перегрузка операторов есмь Страшное Зло, сравнимое с Убойной Силой Макросов. Особенно если мы сильно меняем семантику оригинального оператора. Ведь это же ужас, что такое, когда результат (cout << 1) не совпадает ни с (cout * 2), ни с (cout + cout)! Можно голову сломать, если таким кодом будет пестреть приложение!

З.З.Ы. Что характерно, я не знаю других случаев, в которых бы применяли templates и перегрузку операторов столь безбашенно и столь успешно. Так что в целом можно считать потоки тем самым счастливым исключением, ради которого вообще стоило разрешать перегрузку операторов << // >>. Такого же я ожидаю от Nemerle: будет выделено несколько удачных случаев применения макросов, которые станут стандартом де-факто; в типичном проекте будут применяться все эти стандартные макросы плюс парочка макросов "от местного архитектора", без которых, в общем-то, можно было и обойтись, остальной код будет достаточно консервативным.

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

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

EC>>Я правильно понимаю, что для того, чтобы понять что делает макрос нужно довольно подробно представлять как устроено AST,

IT>Зависит от сложности макроса. Наример, для написания такого макроса много знать не надо:

IT>

IT>macro repeatmacro (times, body)
IT>syntax ("repeat", "(", times, ")", body)
IT>{
IT>  <[ for (mutable t = $times; t > 0; --t) $body ]>
IT>}
IT>

и ради этого есть макросы? Это для меня откровение!

EC>>какие есть фазы компиляции, как AST может трансформироваться на каждой из них?

IT>Для написания более сложных вещей желательно иметь полное представление.

Для изучения которого нужно потратить полгода.

EC>>Т.е. при применении макроса с моим кодом может произойти практически любая трансформация?

IT>Практически любая.

EC>>Если так, то именно это людей и настораживает.

IT>Пока я услышал только две версии, которые настораживают людей:

IT>- обезъянкам будет трудно;

само собой, ведь другие обезьянки такого нахреначат...

IT>- неадекватные девелоперы накосячат.

и обезьянки уволятся

EC>>Потому как я применяя yield return точно знаю, что сделает компилятор и как это всё локализовано.

IT>Тогда как ты можешь использовать библиотечные классы и их методы, если ты не знаешь точно, что они делают?

IT>Вообще, есть одна простая мысль, которую я уже неоднократно высказывал.

IT>Сложность/качество/функциональность/добавить-по-вкусу программного обеспечения не может превышать более чем на порядок сложности/качества/функциональности/дабавить-по-вкусу инструмента, на котором оно разработано.

гениально, сэр.

[]

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

IT>>>10000 нужно ещё умножать на фактор, зависящий от количества посетителей.
C>>Для 100 запросов в секунду — будет всего миллион рефлексий. Кроме того, оптимизатор рефлексии
IT>Кто такой, почему не знаю?
Например, здесь: http://andersnoras.com/blogs/anoras/archive/2007/06/13/blazing-fast-reflection.aspx и http://andersnoras.com/blogs/anoras/archive/2007/06/14/blazing-fast-reflection-for-java.aspx

Assigning the values of the Customer class shown to the left to the same instance one million times takes about a minute on my laptop using pure refleciton. Using bytecode enhanced reflection it takes a mere ~175 milliseconds to do the same thing. So maybe reflection isn't that slow after all?

C>>вообще сведет оверхед к минимуму (по моим тестам в Java, генерируемые accessor'ы примерно в 10 раз быстрее стандартной рефлексии, которая примерно в 200 раз медленнее прямого вызова).
IT>По моим тестам, генерируемые аксессоры всего лишь в 3-4 раза быстрее рефлекшина, чего достаточно, чтобы кастомер на глаз замечал задержку.
Тормозилло... У нас чистым reflection'ом байндятся таблицы в тысячи элементов в Swing'овом GUI. Ничего не тормозит, все довольны.

C>>

C>>List<Need> needs=(List<Need>)sess.createQuery("from Need f inner join fetch f.position"
C>>    "where f.date > :date and f.status='OPEN'")
C>>    .setDate("date",needDate).setCacheable(true).list();
C>>

C>>(в строке запроса работает автокомплит, просмотр генерируемого SQL и т.п. — injected languages в IDEA, однако).
IT>Допустим, так получилось, что я переименовал одно поле. Как отреагирует твой ынхибернейт:
В IDEA запрос будет подчеркнут красной линией, как содержащий ошибку. Инспекция на билд-сервере TeamCity начнет писать разработчикам грозные письма. И т.п.

C>>Ну не знаю, Hibernate держит свой кэш на любом провайдере.
IT>Видишь ли в чём дело. Машина не должна думать, машина должна ездить. Я не люблю когда машина додумывает за меня куда мне нужно ехать.
Так ведь едет же

C>>Так может стоит посмотреть? А то все твои проблемы — высосаны из пальца, что называется.
IT>Боюсь, что из пальца как раз высосан твой ынхибернейт. Извини, но этот пост не о монстриках, этот пост о макросах, задача которых убрать из кода тексуальщину и заменить её на проверяемую компилятором декларативность.
Эта текстуальность замечательно проверяется современными IDE и не создает проблем в 99% случаев.

Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.

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

IT>>За год я не написал ни одного макроса. Ещё раз повторить?
FR>Подтверждаешь основную мысль оппонентов, что для хорошего достаточно гибкого языка макросы особо и не нужны.

Не обязательно. Макросами, которые написали другие он точно пользовался.

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

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

IT>>>За год я не написал ни одного макроса. Ещё раз повторить?
FR>>Подтверждаешь основную мысль оппонентов, что для хорошего достаточно гибкого языка макросы особо и не нужны.

K>Не обязательно. Макросами, которые написали другие он точно пользовался.

Мне правильно кажется что в немерле вообще очень затруднительно не пользоватся макросами?

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

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

BZ>>бейсик.

K>Basic — статически типизированный язык.

Лисп, смалталк, питон и руби тоже.

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

K>Честно говоря, принимая во внимание лисповский синтаксис и общую идеологию code is data is code, я вообще с трудом представляю, зачем в LISP нужно (квази)цитирование, как я его понимаю. И термин этот вместе с LISP вообще очень редко встречается. Но я не поленился и поискал статьи по этой теме на CiteSeer. Да, статьи по квазицитированию в LISP есть. Самая старая, что я нашел — 1999 года.

Если эта статья -- Alan Bawden. Quasiquotation in Lisp, то поглядите там раздел History.

В двух словах. Сам термин квазицитирование придуман в 40-х Квином (W.V.O.Quine) -- тем самым логиком, по имени которого называют программы, выводящие свой собственный код. В пралиспе МакКарти (60-е) квазицитирования не было (видимо, он тоже не понимал зачем оно нужно в лиспе). Развитие ИИ в 60-70х, опыт работы с S-expressions привели к тому, что многие лисп-системы поимели новые техники -- в статье говорится о ПМ над S-expr (видимо аналог схемовского syntax-rules) и template instantiation — в общем уже близко в quote/unquote. Наиболее близким аналогом квазицитирования в те годы была нотация языка Conniver (кстати — один из разработчиков — Сусман). Там даже сплайсинг (,@) был. Это у нас 1972 год. Сам Bawden подрубился в 1977 году. Он заявляет, что тогда уже квазицитирование было. В конце 80х оно появилось в стандартах CL и Scheme.

Хотя к предмету спора это и имеет мало отношения.

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

C>>Я точно знаю, что квазицитирование в нем точно использовалось.

K>Честно говоря, принимая во внимание лисповский синтаксис и общую идеологию code is data is code, я вообще с трудом представляю, зачем в LISP нужно (квази)цитирование, как я его понимаю. И термин этот вместе с LISP вообще очень редко встречается. Но я не поленился и поискал статьи по этой теме на CiteSeer. Да, статьи по квазицитированию в LISP есть. Самая старая, что я нашел — 1999 года.

Самая известная в этой области работа Алана Баудена здесь. В свое время она мне очень помогла и действительно проливает хоть какой-то свет на этот загадочный термин квази-цитирование

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

K>>Не обязательно. Макросами, которые написали другие он точно пользовался.
FR>Мне правильно кажется что в немерле вообще очень затруднительно не пользоватся макросами?

Слово "затруднительно" не имеет объективного значения. Я думаю, что на Nemerle можно писать, не пользуясь макросами. Но зачем?

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

K>>Basic — статически типизированный язык.
FR>Лисп, смалталк, питон и руби тоже.

Звучит феерично и психоделично, конечно. Жаль, что это просто недоразумение.
Я написал слово С Т А Т И Ч Е С К И.
И по буквам:
Станислав.
Тамара.
Алиса.
Теодор.
Инокентий.
Чебурашка.
Евгений.
Сергей.
Константин.
Иоанн.

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

S>Я за то, чтобы оружие все-таки было. И я таки за то, чтобы это оружие было как можно более умным, так что если я нечаянно буду целиться в своего, оно б заблокировало ствол. Потому что мало ли что.
S>И вот немерлевые макросы пока что выглядят достаточно
S>а) сложными для использования, так что новичок скорее всего вообще не сможет это снарядить
S>б) умными, так что новичок не сможет использовать готовый макрос неправильно — компилятор надает ему по рукам (ср. с макросами С/С++)
S>в) мощными, так что можно решать офигительно сложные задачи офигительно изящно

По моему ты только что описал макросы Немерле. Но я бы тут еще один пункт добавил:

г) нормальная возможность отладки макросов

В немерле с этим щас не очень хорошо.

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

K>>>Не обязательно. Макросами, которые написали другие он точно пользовался.
FR>>Мне правильно кажется что в немерле вообще очень затруднительно не пользоватся макросами?

K>Слово "затруднительно" не имеет объективного значения. Я думаю, что на Nemerle можно писать, не пользуясь макросами. Но зачем?

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

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

K>г) нормальная возможность отладки макросов

K>В немерле с этим щас не очень хорошо.

Зато в С элементарно
Скрипт, который будет выводить результат действия макроса, пишется за 3 минуты: вызов компилятора в режиме "только препроцессор" (в gcc это ключ -E), отсечение по какой-нть метке всякой ненужной фигни, которая придет с многочисленными include (проще всего через awk) и напускание какой-нть утилиты типа indent или astyle для приведения результата в читабельный вид.

Хотя это, конечно, смотря что понимать под отладкой макроса.
Если то, какой в результате текст он генерит — такого простого скрипта достаточно с головой.
Если надо — могу привести текст.

You will always get what you always got
  If you always do  what you always did

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

J>Зато в С элементарно
J>Скрипт, который будет выводить результат действия макроса, пишется за 3 минуты: вызов компилятора в режиме "только препроцессор" (в gcc это ключ -E), отсечение по какой-нть метке всякой ненужной фигни, которая придет с многочисленными include (проще всего через awk) и напускание какой-нть утилиты типа indent или astyle для приведения результата в читабельный вид.

J>Хотя это, конечно, смотря что понимать под отладкой макроса.
J>Если то, какой в результате текст он генерит — такого простого скрипта достаточно с головой.
J>Если надо — могу привести текст.

Нет, немного не то. То какой в результате текст генерится можно в студийной интеграции посмотреть простым наведением мышки на макрос. Я имел ввиду полноценную отладку, такую как если бы это был обычный код. Т.е. поставить в каком либо месте брейкпойнт, пройтись через F10-F11 по коду, смотреть какие значения переменных в данный момент, следить за калл стеком, условные брейкпойнты итд итп