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

G>>Мы говорим конкретно о том что принципиально не решается типизировано без макросов. Имеется ввиду compile-time генерация и модификация кода, precompile-time не рассматриваем.

Z>Мне не нравится слово принципиально. Принципиально макросы заменяются аналогичными, но менее удобными инструментами: анализаторы кода, генераторы исходников, рантайм генерация кода и инструментирование байткода. Это все очень тяжелые пушки. Их используют когда уже деваться некуда.

Ты абсолютно прав, но ты ничего не докажешь тем, кто знаком только с "закатом солнца вручную", так как они мыслит другими категориями.

Проблема в том, что ты знаком со всеми подходами на практике, а твой оппонент только с частью на практике, а с частью в теории. А как известно в теории теория и практика одинаковы, но на практике то — нет.

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

Собственно и ты тоже был бы в этом лагере если бы некоторое время назад "с дуру" не освоил бы "другую сторону силы".

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

Z>>Макрос выполняется в компайл тайме, он может анализировать компилируемый код и изменять его, например сгенерировать нужные методы для вызова хранимки.

DG>по смыслу template-ы и generics делают тоже самое, но при этом они не являются макросами.
DG>т.е. по чему нужны именно макросы, а не навореченные template-ы?

Чтобы тебе было лучше понятна ошибка в твоей логике я приведу твои же утверждения но заменю объекты.

XXX> Самолеты используются для передвижения. Они быстро летают и с них видно большую площадь.

По смыслу тракторы и велосипеды делают тоже самое, но при этом они не являются самолетами.

Да, черт побери, есть подвид задач которые решаются и тем и тем, но вот макросы не тождественны шаблонам и тем более дженерикам. С помощью макросов можно сделать все что можно сделать с помощью шаблонов и джененриков. Более того, то что хорошо делается шаблонами и дженериками не стоит делать марами. Но многое что можно сделать макрами сделать шаблонами и дженериками невозможно. В частности выделенное в цитате Ziaw сделать дженериками или шаблонами невозможно. Кроме того в них нельзя анализировать внешние источники данных.

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

Z>Я бы переформулировал вопрос. Зачем жалкое подобие макросов type providers тому у кого есть полноценные макросы.

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

Следующие строки являются детекторами. Если при их прочтении вы почувствуете резкую боль в анальном отверстии, то прекратите чтение (с) Лурк .

Короче мы имеем дело с животными страхами противопоставленными поклонению гения Макйрософта. МС он же плохого не предложит. И раз МС не ходит некоторыми дорогами, значит они очень опасны.

Z>А вообще я уже устал офтопить, тема не является рекламой макросов. Мне не интересно обращать кого-то в немерле. Меня интересуют плюсы динамики которые недостижимы в статике с поддержкой метапрограммирования.

Ты не понял. Большинство людей будут ревностно бороться с тем, что они не понимают/не знают. Это человеческая природа. Вот это и раздражало меня в прошлом. Теперь правда смешит.

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

DG>динамик позволяет запустить код, который не полностью валидный (с точки зрения типизации)
DG>это полезно при внесении изменений (рефакторинге и т.д.)

Это особенно полезно для внесения и размножения багов.

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

Z>>>Типизированный вызов хранимки из БД, решается генераторами кода либо макросами.

Кэр>>Вполне возможно, что это решается через type providers о которых говорил Don Syme на PDC.

Кэр>>Это решение потенциально покрывает такой пласт проблем, что возникает большой вопрос — а зачем тогда нужны будут макросы.

Z>Я бы переформулировал вопрос. Зачем жалкое подобие макросов type providers тому у кого есть полноценные макросы.

Ну когда появятся type providers — мы и посмотрим, кому они нужны и кому нужны макры, не так ли?

Когда у вас пройдет шоколадно-конфетный период с макрами — вы увидите, что это всего лишь тул. Ничего более. И я с удовольствием заюзаю готовый проверенный тул, чем буду возиться с поделками второклассников в виде макров. Тем более, когда для работы с ними нормальной среды нет (сравнимой по качеству со студия+решарпер).

Z>Эти провайдеры для конкретной задачи реализуются одним человеком максимум за пару недель без привлечения Don Syme и хайпа на PDC.

А ну ну. Слышал я эти кухонные оценки "за пару недель". И не раз.

Z>А вообще я уже устал офтопить, тема не является рекламой макросов. Мне не интересно обращать кого-то в немерле. Меня интересуют плюсы динамики которые недостижимы в статике с поддержкой метапрограммирования.

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

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

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

Кэр>Когда у вас пройдет шоколадно-конфетный период с макрами — вы увидите, что это всего лишь тул. Ничего более. И я с удовольствием заюзаю готовый проверенный тул, чем буду возиться с поделками второклассников в виде макров. Тем более, когда для работы с ними нормальной среды нет (сравнимой по качеству со студия+решарпер).

Адекватные слова про тул почему-то перемешаны с насмешками над людьми сделавшими тул и людьми его использующими. А что, правда есть готовый проверенный тул решающий те же задачи? Да еще со средой сравнимой по качеству со студией + решарпер?

Кэр>А ну ну. Слышал я эти кухонные оценки "за пару недель". И не раз.

Кэр>Ну а вас спросили, где так нужны ваши макры, если вы почти на них жениться готовы. И я этот вопрос поддерживаю.

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

Язык проектировать так же просто, как проектировать иерархию объектов, даже проще, ошибки нагляднее. Ваши аргументы напомнили мне фанатов процедурного программирования с жаром доказывающих ненужность С++ тем, что классы не нужны, когда есть структуры. Кричащими о сложности автокомплишена в современнных IDE и о том, что С++ никем нормально не поддерживается. О том, что наследование и виртуальные вызовы на С используются от силы в 1% проектов и требуют огромных усилий по поддержке. О том, что код с этими вызовами на С ни черта не понимают люди только что пришедшие в проект и потому такой код бяка.

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

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

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

Кэр>>Когда у вас пройдет шоколадно-конфетный период с макрами — вы увидите, что это всего лишь тул. Ничего более. И я с удовольствием заюзаю готовый проверенный тул, чем буду возиться с поделками второклассников в виде макров. Тем более, когда для работы с ними нормальной среды нет (сравнимой по качеству со студия+решарпер).

Z>Адекватные слова про тул почему-то перемешаны с насмешками над людьми сделавшими тул и людьми его использующими. А что, правда есть готовый проверенный тул решающий те же задачи? Да еще со средой сравнимой по качеству со студией + решарпер?

Вы сами задали вопрос противопоставив type providers макросам. Я вам высказал свою точку зрения на тот момент, когда type providers появятся, и если они будут справлятся с этими задачами.

Кэр>>А ну ну. Слышал я эти кухонные оценки "за пару недель". И не раз.

Кэр>>Ну а вас спросили, где так нужны ваши макры, если вы почти на них жениться готовы. И я этот вопрос поддерживаю.

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

Z>Язык проектировать так же просто, как проектировать иерархию объектов, даже проще, ошибки нагляднее.

Ну конечно проще. Если не думать о конфликтах синтаксиса и ключевых слов/символов. Особенно о неявных, когда все компилируется, а понять что не работает можно только взвалив тонну генеренного кода на плечи. И если не думать о обратной совместимости со старым синтаксисом, который вообще не подразумевал особого расширения, а тут ВНЕЗАПНО пришлось расширить. И вместо того, чтобы напрямую решать прикладную задачу нужно тратить время на выдумывания синтаксических завихрений, чтобы и от нового синтаксиса глаз не вываливался и старый компилировался.

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

Z>Ваши аргументы напомнили мне фанатов процедурного программирования с жаром доказывающих ненужность С++ тем, что классы не нужны, когда есть структуры. Кричащими о сложности автокомплишена в современнных IDE и о том, что С++ никем нормально не поддерживается. О том, что наследование и виртуальные вызовы на С используются от силы в 1% проектов и требуют огромных усилий по поддержке. О том, что код с этими вызовами на С ни черта не понимают люди только что пришедшие в проект и потому такой код бяка.

Правильно. Доказательства по аналогии — это наш метод. Всегда создает такое приятное душевное равновесие. Окружающих убедить удается не всегда — но себя всегда пожалуйста.

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

Выдыхайте, то что я лапшу на ушах стараюсь не держать, не означает, что я считаю себя эталоном.

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

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

DG>динамик позволяет запустить код, который не полностью валидный (с точки зрения типизации)
DG>это полезно при внесении изменений (рефакторинге и т.д.)

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

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

Кэр>Вы сами задали вопрос противопоставив type providers макросам. Я вам высказал свою точку зрения на тот момент, когда type providers появятся, и если они будут справлятся с этими задачами.

Передергиваете, type providers макросам противопоставили вы

Автор: Кэр
Дата: 20.12.10

.

Z>>Язык проектировать так же просто, как проектировать иерархию объектов, даже проще, ошибки нагляднее.

Кэр>Ну конечно проще. Если не думать о конфликтах синтаксиса и ключевых слов/символов. Особенно о неявных, когда все компилируется, а понять что не работает можно только взвалив тонну генеренного кода на плечи. И если не думать о обратной совместимости со старым синтаксисом, который вообще не подразумевал особого расширения, а тут ВНЕЗАПНО пришлось расширить. И вместо того, чтобы напрямую решать прикладную задачу нужно тратить время на выдумывания синтаксических завихрений, чтобы и от нового синтаксиса глаз не вываливался и старый компилировался.

А что, можно проектировать иерархию классов не задумываясь об SRP, LSP и прочих P? Это такая простая задача не наделать конфликтов с этими не вполне формальными принципами? Что, там нет ситуаций, когда все компилируется, а для исправления ошибки нужен редизайн иерархии либо костыли в виде навешиваний нескольких параллельных иерархий визиторов?

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

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

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

Z>>Ваши аргументы напомнили мне фанатов процедурного программирования с жаром доказывающих ненужность С++ тем, что классы не нужны, когда есть структуры. Кричащими о сложности автокомплишена в современнных IDE и о том, что С++ никем нормально не поддерживается. О том, что наследование и виртуальные вызовы на С используются от силы в 1% проектов и требуют огромных усилий по поддержке. О том, что код с этими вызовами на С ни черта не понимают люди только что пришедшие в проект и потому такой код бяка.

Кэр>Правильно. Доказательства по аналогии — это наш метод. Всегда создает такое приятное душевное равновесие. Окружающих убедить удается не всегда — но себя всегда пожалуйста.

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

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

Кэр>Выдыхайте, то что я лапшу на ушах стараюсь не держать, не означает, что я считаю себя эталоном.

Перенос своего неприятия инструмента на всех именно это и означает.

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

Z>Мне не нравится слово принципиально. Принципиально макросы заменяются аналогичными, но менее удобными инструментами: анализаторы кода, генераторы исходников, рантайм генерация кода и инструментирование байткода. Это все очень тяжелые пушки. Их используют когда уже деваться некуда.

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

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

Z>Давайте рассмотрим, основные плюсы которые дает динамика в вебе тем же рельсам в по сравнению с asp.net mvc:
Z>

Z>
1. Возможность не описывать поля модели хранящейся в БД
   Z>
2. Возможность сформировать пачку данных и передать их во вьюху не заморачиваясь описанием их структуры
   Z>
3. Возможность нагенерировать удобных хелперных методов для каждого чиха пользуясь соглашениями об именовании.
   Z>
4. Делать красивые DSL заточенные для мелких задач.
   Z>

Z>Вероятно я что-то пропустил, думаю меня дополнят.

Я тебя читаю и вижу: что лучше MVC со статикой или MVC с динамикой. На MVC свет клином не сошелся. Да и работой с данными веб-разработка не исчерпывается. У тебя все выглядит как попытка создать идеальный MVC Но это, я бы сказал, нефиговое такое сужение темы.

Динамика в веб популярна прежде всего по историческим причинам. По большому счету конкретно для веб достаточно по фиг — динамика там на сервер-сайд или не динамика. Все равно в вебе по его специфике очень много динамики. В современном "веб 2.0" (или уже "веб 3.0"?) еще и очень много ДжаваСкрипта. А ДжаваСкрипт — весьма и весьма динамичный во всех смыслах этого слова язык.

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

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

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

ВВ>Обоснуй, пожалуйста, чем генератор исходников менее удобен. Причем не простой генератор исходников, а внешний визуальный DSL, который сериализуется в код. Основная аудитория Немерле — это все же не рубисты, а вендор дотнета как раз активно продвигает именно внешние DSL-и, на основе которых и работают всяческие Entity Framework и иже с ними.

Для каких-то случаев генератор исходников вероятно будет более удобен, но в общем случае вряд ли. Например тем, что при генерации мы ничего не знаем о коде который будет окружать генерируемый код. К примеру в нрельсах генерируются хелперы для типизированного указания экшенов, беря информацию о контроллерах и их экшенах из компилируемого кода. Хотя в Т4 вроде есть кое какие механизмы вытаскивания знаний студии о коде. Еще можно распарсить исходники, получить синтаксис, но для нормального анализа понадобится инструмент сравнимый по сложности с компилятором.

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

ВВ>а вендор дотнета как раз активно продвигает именно внешние DSL-и, на основе которых и работают всяческие Entity Framework.
После чего приходится создавать Code Only c fluent интерфейсом.

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

DG>по смыслу template-ы и generics делают тоже самое, но при этом они не являются макросами.

DG>т.е. по чему нужны именно макросы, а не навореченные template-ы?

Странный вопрос. А template есть еще куда наворачивать? Мне кажется он уже уперся в потолок сложности решений по такому принципу. Если тебе не нравится слово макросы, назови их навороченными template и используй только как навороченные template.

ВВ>Поэтому прикручивать макросы, который типизировано вызывают хранимку или как там у вас, это наверное очень интересно, но не шибко-то и нужно. Ибо их есть у нас. Пусть и без макросов, а несколько иначе. Но с т.з. использования — ничем не хуже. А вот тонны ДжаваСкрипта как были, так и остаются. Причем проблема даже не в ДжаваСкрипте как таковом, а в том, что код приходится писать на двух языках, на ДжаваСкрипте и серверном и, главное, то, что зачастую задачи одного и того же плана, приходится реализовывать как на сервере, так и на клиенте.

ВВ>И выстрелит на мой взгляд тот фреймворк, который полностью решит эту проблему — независимо от того, какая там типизация.

Ну, есть гугловский GWT, но не сказать, что он прямо-таки выстрелил

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

ВВ>Я тебя читаю и вижу: что лучше MVC со статикой или MVC с динамикой. На MVC свет клином не сошелся. Да и работой с данными веб-разработка не исчерпывается. У тебя все выглядит как попытка создать идеальный MVC Но это, я бы сказал, нефиговое такое сужение темы.

Я всего лишь рассмотрел плюсы динамики на примере двух самых популярных для своих платформ веб-фреймворков с разных сторон баррикады. Давай свои примеры, обсудим их.

ВВ>Динамика в веб популярна прежде всего по историческим причинам. По большому счету конкретно для веб достаточно по фиг — динамика там на сервер-сайд или не динамика. Все равно в вебе по его специфике очень много динамики. В современном "веб 2.0" (или уже "веб 3.0"?) еще и очень много ДжаваСкрипта. А ДжаваСкрипт — весьма и весьма динамичный во всех смыслах этого слова язык.

ВВ>Поэтому прикручивать макросы, который типизировано вызывают хранимку или как там у вас, это наверное очень интересно, но не шибко-то и нужно. Ибо их есть у нас. Пусть и без макросов, а несколько иначе. Но с т.з. использования — ничем не хуже.

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

ВВ>А вот тонны ДжаваСкрипта как были, так и остаются. Причем проблема даже не в ДжаваСкрипте как таковом, а в том, что код приходится писать на двух языках, на ДжаваСкрипте и серверном и, главное, то, что зачастую задачи одного и того же плана, приходится реализовывать как на сервере, так и на клиенте.

А проблема ли это? Я не видел ни одной подобной платформы на которой писать джаваскрипты было приятнее чем на джаваскрипте. Он вполне себе продуманный язык и слой абстракции над ним будет не только помогать, но и активно ограничивать.

ВВ>И выстрелит на мой взгляд тот фреймворк, который полностью решит эту проблему — независимо от того, какая там типизация.

Ну есть такой фреймворк, node.js называется. Вобщем-то выстрелил. Согласен, проблему кучи джаваскрипта в вебе, метапрограммирование решает плохо.

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

Z>Для каких-то случаев генератор исходников вероятно будет более удобен, но в общем случае вряд ли. Например тем, что при генерации мы ничего не знаем о коде который будет окружать генерируемый код. К примеру в нрельсах генерируются хелперы для типизированного указания экшенов, беря информацию о контроллерах и их экшенах из компилируемого кода. Хотя в Т4 вроде есть кое какие механизмы вытаскивания знаний студии о коде. Еще можно распарсить исходники, получить синтаксис, но для нормального анализа понадобится инструмент сравнимый по сложности с компилятором.

Тут, видимо, надо различать разные моменты:

— Удобство разработки самого DSL-я
— Удобство использования этого DSL-я
— Привычность того или иного механизма

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

Но это одна сторона медали. Другая — это DSLTools, BuildProviders в студии и пр.

И отсюда мы плавно переходим ко второму моменту, а именно — то, что итоговый результат и в случае внешнего DSL, и в случае с макросами по крайней мере одинаково удобен в плане использования. А визуальные DSL-и для многих даже удобнее макросов. А если мне *как пользователю* не видно разницы...

Иначе говоря, зачем убеждать кого-то, что макросы — это круто? Речь ведь не о макросах на самом деле, а о конкретном фреймворке. А применительно к конкретному фреймворку мне интересно прежде всего удобство использования этого фреймворка, а не то, насколько проще жилось его создателям, вы уж извините

Да и, кстати, при работе с данными статическая типизация не дает практически ничего. Статическая типизация хорошо работает лишь в том случае, когда "реальность" данная нам в компайл-тайме всегда совпадает с реальностью, данной в райнтайме. В случае с БД это, к сожалению, не так. Скомпилировался — не значит, что код корректный и что даже названия атрибутов правильные. И в этом плане тут опять же нет никакого противопоставления — можно делать ДАЛ на основе статически-типизированного языка, раз уж такой под рукой имеется, можно — на основе динамически-типизированного. Оба подхода примерно равные, с примерно равным количеством граблей — и преимуществ в данном случае статика не даст.

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

ВВ>>И выстрелит на мой взгляд тот фреймворк, который полностью решит эту проблему — независимо от того, какая там типизация.
M>Ну, есть гугловский GWT, но не сказать, что он прямо-таки выстрелил

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

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

ВВ>Иначе говоря, зачем убеждать кого-то, что макросы — это круто?

Так просят ведь.

ВВ>Речь ведь не о макросах на самом деле, а о конкретном фреймворке. А применительно к конкретному фреймворку мне интересно прежде всего удобство использования этого фреймворка, а не то, насколько проще жилось его создателям, вы уж извините

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

ВВ>Да и, кстати, при работе с данными статическая типизация не дает практически ничего. Статическая типизация хорошо работает лишь в том случае, когда "реальность" данная нам в компайл-тайме всегда совпадает с реальностью, данной в райнтайме. В случае с БД это, к сожалению, не так.

В случае с БД это сильно зависит от специфики задачи. Если специфика задачи требует постоянно изменения схемы бд, то и механизмы доступа к данным будут совсем другие. Это очень отдельный класс задач, на котором пасуют почти все ORM.

ВВ>Скомпилировался — не значит, что код корректный и что даже названия атрибутов правильные. И в этом плане тут опять же нет никакого противопоставления — можно делать ДАЛ на основе статически-типизированного языка, раз уж такой под рукой имеется, можно — на основе динамически-типизированного. Оба подхода примерно равные, с примерно равным количеством граблей — и преимуществ в данном случае статика не даст.

Если применять инструмент по назначению он дает гарантию. А можно подсунуть БД со схемой отличной от рантайма или поменять эту схему в рантайме. Вобщем один шар сломать один потерять можно, только зачем?

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

Z>А проблема ли это? Я не видел ни одной подобной платформы на которой писать джаваскрипты было приятнее чем на джаваскрипте. Он вполне себе продуманный язык и слой абстракции над ним будет не только помогать, но и активно ограничивать.

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

Например, одно полноценное и отработанное на практике решение этой проблемы — писать все на ДжаваСкрипте на клиенте Серверная часть при этом становится тонкой и занимается лишь тем, что возвращает на клиент данные в виде ХМЛ-я или Джейсона. Роль языка, на котором эта серверная часть пишется, как ты понимаешь, весьма серьезно падает.

Можно вытаскивать ДжаваСкрипт на сервер — это вот как раз случай node.js. Но тогда у нас вообще везде ДжаваСкрипт и становится непонятно, о чем тут вообще говорим-то

Еще одно решение — компилятор в ДжаваСкрипт. А вот тут возможности Немерла как раз очень пригодятся.

Других вариантов я не вижу