Здравствуйте, Константин Л., Вы писали:
КЛ>есть, и этому спектру предлагают асиливать замыкания, правила overload resolution, контр/ковариантность. А вот атрибут навесить, который по сути макра, это сложно.
Не знаю. Может и сложно. Зависит что эта макра делает. С макросами имеет смысл возится, если оно привносит что то принципиально новое, недостижимое обычными фреймворками.
AVK>>В данном конкретном пункте я рассматриваю исключительно визарды, чтобы не смешивать мух и котлеты.
КЛ>А в немереле генерация кода за счет использования квазицитирования и декларативности должна писаться еще проще.
Проще чего?
КЛ> CodeDom по сравнению с ней — мамонт
Он то тут при чем? Студийные визарды это обычно просто кусок статического текста с 1-2 подстановками. Не надо там никакого rocket science.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Константин Л., Вы писали:
КЛ>>есть, и этому спектру предлагают асиливать замыкания, правила overload resolution, контр/ковариантность. А вот атрибут навесить, который по сути макра, это сложно.
AVK>Не знаю. Может и сложно. Зависит что эта макра делает. С макросами имеет смысл возится, если оно привносит что то принципиально новое, недостижимое обычными фреймворками.
ок, твоя точка зрения понятна
AVK>>>В данном конкретном пункте я рассматриваю исключительно визарды, чтобы не смешивать мух и котлеты.
КЛ>>А в немереле генерация кода за счет использования квазицитирования и декларативности должна писаться еще проще.
AVK>Проще чего?
КЛ>> CodeDom по сравнению с ней — мамонт
AVK>Он то тут при чем? Студийные визарды это обычно просто кусок статического текста с 1-2 подстановками. Не надо там никакого rocket science.
Здравствуйте, alvas, Вы писали:
A>>>Что подразумевается под словами "в моих задачах"?
AVK>>Хм, по моему это вполне по русски. Подразумевается, что речь идет о тех задачах, с которыми сталкивался и сталкиваюсь именно я, и на глобальные обобщения на всю софтописательную индустрию и тенденции ее развития я не претендую. Что именно непонятно?
A>>>Я правильно понял?
AVK>>Странный вопрос. Не знаю я, как ты понял.
A>И вот как дальше обсуждать? Иду лесом...
Так как я не телепат , то буду рассматривать "в моих задачах" как "к промышленному программированию в составе команд с размером > 3 человек и состоящих не исключительно из топа разрабочиков"
Про
1. Design_by_contract прикручивается на раз. И иже с ним...
2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично.
3. "MPS, DSL Tools, Oslo" — еще один нужный (модный) ЯП, а может лучше "швейцарский нож"? Майкрософт всунула SQL в C#, так почему нельзя всунуть Oslo в Nemerle?
4. По поводу кодогенерации. Я считаю что МП в Nemerle не конкурирует с ней, а дополняет.
5. Если смотреть на МП в Nemerle как слишком БОЛЬШУЮ вещь, которую программерам лучше не давать — имеет слабую аргументацию. Уже вроде давно как доказан вред goto, но он есть в большинстве языков, в том числе и в недавно родившихся...
Контра
Если коротко — это отсутствие ECMA стандарта. Если есть желание обсудить — распишу более подробно и по пунктам.
Здравствуйте, AndrewVK, Вы писали:
AVK>Дисклеймер:
Не являясь топ-разработчиком, со своей колокольни всё же попробую возразить
AVK>Итак, сабж. AVK>1) На практике я наблюдаю, что даже новые стандартные фичи языка используются очень и очень неспешно и с неохотой. Даже итераторы, которые еще в 2004 году появились, у многих вызывают изумление.
У нас на проекте используеться практика code review (причем ревью не менеджера, которым у нас является SCRUM-мастер, а другого программиста, желательно не junior). Думаю, после нескольких неудачных ревью, разработчик всё же переписал бы используя новые стандартные фичи (с). AVK> Исходя из этого, я считаю, что серьезные изменения в самом языке, заточенные под конкретный проект, в промышленном программировании в большинстве случаев неприемлемы. И только в очень больших платформах, там где сейчас применяются собственные языки программирования, внесение изменений в язык на уровне платформы может быть оправдано.
Не могу судить. У нас (проект на Java, > 1 000 000 строк) таких изменений нет (да и откуда им взяться на Java-то?). Помогло бы? помешало бы? — хз, посему скип.
AVK>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования.
Не совсем согласен с выделенным. Точнее так, в вашем случае, это конечно так, но DSL бывают разные. Например DSL в Ruby on Rails (да и в Ruby-based DSL'ях вообще) ориентирован на увеличение читабельности и компактности кода, предназначен для программистов. Т.е. ограничивать не обязательно, можно лишь предоставить более удобные инструменты и разработчики сами себя ограничат
AVK>3) Следующая сфера применения кодогенерации (язык не поворачивается назвать это метапрограммированием) — визарды в средах разработки, которые генерируют первоначальный код. Не очень представляю, как тут может помочь Немерле, да и использование специального языка тут явно перебор.
+1, хотя использование DSL может быть (а может и не быть) более удобным чем визард
AVK>4) Генерация кода на основе DSL. Пример такого применения — DSL Tools. Вот здесь, в принципе, отчасти использование Немерле оправдано. Но есть тут одна засада. Дело в том, что разработка кодогенератора (любого, в том числе и по AST, с применением квазицитирования, паттерн-матчинга и алгебраических типов данных) нередко значительно сложнее, нежели написание генерируемого кода. И при поддержке, далеко не факт, что правка кодогенератора проще, чем модификация рукопашного кода при помощи современных средств рефакторинга.
Не знаю правильно ли понял.. Например, если взять веб-сервисы и кодогенерацию по WSDL — удобнее сгенерировать код и потом править, чем использовать макрос Nemerle, который генерит классы во время компиляции и поменять что-то под собственные нужды довольно сложно. Я правильно описал проблему? Тогда +1.
<< RSDN@Home 1.2.0 alpha 4 rev. 1128>>
Сейчас играет silent
Здравствуйте, Gajdalager, Вы писали:
G>У нас на проекте используеться практика code review (причем ревью не менеджера, которым у нас является SCRUM-мастер, а другого программиста, желательно не junior). Думаю, после нескольких неудачных ревью, разработчик всё же переписал бы используя новые стандартные фичи (с).
Не очень понимаю, какая здесь связь. Да, научить можно чему угодно кучей разных методик. Но ни одна из них не позволяет это сделать бесплатно.
G>Не совсем согласен с выделенным. Точнее так, в вашем случае, это конечно так, но DSL бывают разные.
Я в курсе. Но в том случае, когда DSL это слегка видоимзененный основной язык — см. п.1.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
Здравствуйте, alvas, Вы писали:
A>Про
A>1. Design_by_contract прикручивается на раз. И иже с ним... A>2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично. A>3. "MPS, DSL Tools, Oslo" — еще один нужный (модный) ЯП, а может лучше "швейцарский нож"? Майкрософт всунула SQL в C#, так почему нельзя всунуть Oslo в Nemerle? A>4. По поводу кодогенерации. Я считаю что МП в Nemerle не конкурирует с ней, а дополняет. A>5. Если смотреть на МП в Nemerle как слишком БОЛЬШУЮ вещь, которую программерам лучше не давать — имеет слабую аргументацию. Уже вроде давно как доказан вред goto, но он есть в большинстве языков, в том числе и в недавно родившихся...
На все эти вопросы мой ответ содержится в корневом сообщении.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>На все эти вопросы мой ответ содержится в корневом сообщении.
Серьезно?
Процитируй, плиз, кусок своего сообщения который давал бы ответ хотя бы на этот вопрос: A>>2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gajdalager, Вы писали:
G>Не знаю правильно ли понял.. Например, если взять веб-сервисы и кодогенерацию по WSDL — удобнее сгенерировать код и потом править, чем использовать макрос Nemerle, который генерит классы во время компиляции и поменять что-то под собственные нужды довольно сложно. Я правильно описал проблему? Тогда +1.
Правка сдегерированного кода — это пожалуй самое плохое что можно придумать. Ведь когда код будет перегенерирован все правки придется вносить занова. А ведь это может произойти тогда когда детали будут забыты, что приведет к серьезнешим проблемам и тормозам в развитии проекта.
Макрос же — это настраиваемая программа генерации кода написанная на высокоуровневом расширении очень высокоуровневого языка. Научить его генерировать код так как надо тебе не сложно. Править при этом ничего не придется. Если появляется задача изменить генерируемый код, то достаточно будет чуть-чуть поменять логику (например, добавить нужный параметр макросу).
Так что этот пример — большой минус, а не плюс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Можно даже не спрашивать. Черт всегда скрывается в деталях. Так что расписывай. Тебе многие спасибо скажут.
1. Нужен road map. Если он есть — можно ссылку?
2. Команде Nemerle придется ВСЕГДА гнаться за Майкрософт. Огонь и движение
Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия для того чтобы они могли двигаться вперёд, а вы нет.
Пример — необходимость реализации поддержки Linq в Nemerle.
На очереди dynamic, ...
Я так понял тут уж ничего не поделаешь.
3. ECMA стандарт даст гарантию невозможности ламающих изменений языка в мажорных версиях. Даже у Майкрософт если код считают устаревшим — помечают атрибутом [obsolete], но это ворнинги — код скомпилится без проблем. Обратная совместимость это наше все.
4. Больше информировать комьюнити что происходит в Команде Nemerle.
ЗЫ. Я так понял что не получилось у грандов выбить гранты — так разместите "Donate" на сайт и к вам потянутся люди.
Здравствуйте, VladD2, Вы писали:
VD>Правка сдегерированного кода — это пожалуй самое плохое что можно придумать. Ведь когда код будет перегенерирован все правки придется вносить занова.
Это если не удалось хорошо распилить код при помощи partial классов.
VD>А ведь это может произойти тогда когда детали будут забыты, что приведет к серьезнешим проблемам и тормозам в развитии проекта. VD>Макрос же — это настраиваемая программа генерации кода написанная на высокоуровневом расширении очень высокоуровневого языка. Научить его генерировать код так как надо тебе не сложно. Править при этом ничего не придется. Если появляется задача изменить генерируемый код, то достаточно будет чуть-чуть поменять логику (например, добавить нужный параметр макросу).
Вот тут (см. выделенное) есть некоторые сомнения. В том смысле, что если у тебя возникает т.н. one-off ситуация, то есть что-то там нужно подшаманить ровно в одном месте, то это проще всего подшаманить ровно в этом одном месте. Подшаманивание генератора рискует дать труднопредсказуемые эффекты в других местах, где поведение уже отлажено.
Я не могу сходу придумать реалистичный пример, но нутром чую, что за ними дело таки не станет — только начни реальное применение. И AVK ровно об этом говорит. Генерировать код — нетривиальная задача.
Вот есть, допустим, автоматический генератор SQL запросов по некоторой модели.
И вот оказывается, допустим, что в одном из запросов тебе вынь да полож потребовалось, допустим, обратиться не к таблице, а к параметризованному view. Обучать генерилку поддерживать параметризованные view — дорого; это окупится только если таких view у тебя применяется много. В исключительном случае тебе проще будет руками поправить сгенерированный запрос.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
VD>>Правка сдегерированного кода — это пожалуй самое плохое что можно придумать. Ведь когда код будет перегенерирован все правки придется вносить занова. S>Это если не удалось хорошо распилить код при помощи partial классов.
Я считаю что оба подхода взаимодополняющие. Пример — генерация кода по схеме и linq. В первом случае генерится исходник, во втором — двоичный код. Это же не означает что нужно отказываться от первого или от второго.
S>И вот оказывается, допустим, что в одном из запросов тебе вынь да полож потребовалось, допустим, обратиться не к таблице, а к параметризованному view. Обучать генерилку поддерживать параметризованные view — дорого; это окупится только если таких view у тебя применяется много. В исключительном случае тебе проще будет руками поправить сгенерированный запрос.
Но с другой стороны возможен компромиссный вариант, когда мы делаем незначительное изменение генератора (например, всего лишь добавляем вызов partial метода) и получаем тем самым возможность сделать ручное изменение, которое не пропадёт после повторной генерации исходников.
Здравствуйте, prVovik, Вы писали:
V>Но с другой стороны возможен компромиссный вариант, когда мы делаем незначительное изменение генератора (например, всего лишь добавляем вызов partial метода) и получаем тем самым возможность сделать ручное изменение, которое не пропадёт после повторной генерации исходников.
Речь о том, что это не всегда возможно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования. И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.
+1, в этом есть смысл
Всё остальное — просто ни о чем. Резонёрство сплошное.
Здравствуйте, Andrei F., Вы писали:
AF>Всё остальное — просто ни о чем. Резонёрство сплошное.
То, что ты чего то не понял, или просто никогда не сталкивался с подобными проблемами, еще не означает, что этих проблем не существует или они незначительны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>То, что ты чего то не понял, или просто никогда не сталкивался с подобными проблемами, еще не означает, что этих проблем не существует или они незначительны.
, то буду рассматривать "в моих задачах" как "к промышленному программированию в составе команд с размером > 3 человек и состоящих не исключительно из топа разрабочиков"
