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

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

Ну запостил тему в форум "Флейм" и еще удивляешься, что тебя разводят на флейм. В первый раз что ли здесь

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

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

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

На новой БД по ходу разработки многое может меняться. Ты хочешь сказать, что *как правило* "статически-типизированный ДАЛ" работает корректно? Да, согласен. Так и есть. В противном случае никто бы не пользовался всяческими Линками. Но знаешь что интересно? Динамически-типизированный ДАЛ тоже *как правило* работает корректно.

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

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

есть конечно.

как минимум сейчас есть следующие ограничения:
во-первых, возможности шаблонов останавливаются на уровне классов.
на уровне полей/свойств/методов шаблоны уже не работают, не говоря уже про тела методов
во-вторых, шаблоны не предоставляют нормального способа для описания условий (операции над множествами, логические операции, операции над целыми числами и т.д.)
в-третьих, IDE — должна уметь наглядно показывать результат после применения (частичного применения) шаблонов.

зы
макросы плохи тем, что они могут сделать с кодом все что угодно, и соответственно макросы могут очень легко испортить код.
стыковка одного макроса с другим макросом — та еще по легкости задача.

для упрощения задач предсказания поведения, комбинирования, автоматической проверки валидности и т.д. обычно допускают лишь определенный набор изменений(инструментов) — но это ближе к шаблонам, чем к макросам.

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

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

у статики ниже себестоимость сопровождения.
как минимум не надо писать простые тесты на каждое изменение кода.

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

ВВ>>Причем тесты для ДАЛа я буду писать в обоих случаях — и тесты довольно банальные, вплоть до того, что их генерить можно. И эти тесты вообще нивелируют какую бы то ни было разницу в типизациях. Т.е., повторюсь, в этой области по фиг вообще — статика или динамика. Результат один.
DG>у статики ниже себестоимость сопровождения.
DG>как минимум не надо писать простые тесты на каждое изменение кода.

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

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

но одно дело сотня общих тестов на общую работу dal-а, которые при сопровождении почти не меняются.
другое дело тысяча тестов на то, что где-то в генераторе при сравнении не забыли числа сравнить как числа, а не как число со строкой, или что в одной из веток переменная инициализируется другим типом(забыли при внесении изменения поправить) и т.д.
вот такие опечатки — очень геморройно ловить тестами.

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

DG>но одно дело сотня общих тестов на общую работу dal-а, которые при сопровождении почти не меняются.
DG>другое дело тысяча тестов на то, что где-то в генераторе при сравнении не забыли числа сравнить как числа, а не как число со строкой, или что в одной из веток переменная инициализируется другим типом(забыли при внесении изменения поправить) и т.д.
DG>вот такие опечатки — очень геморройно ловить тестами.

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

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

Можно потроллить?

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

Нахождение чистых методов — pure type systems
Параллелить — автоматическое распараллеливание
Кэширование — ленивость, referential transparency, common subexpression elimination etc.

Z>Code contracts.

Например, зависимые типы. Хотя обычно хватает и GADT или type families.

Z>Пресловутый DSL в прекомпайл тайме такой геморой, что его никто не использует. Максимум — делают что-то типа fluent api и наслаждаются.

Ну, неправда же. Или не понимаю о чём речь.

Z>AOP без макросов делается либо с огромным оверхедом либо через bytecode instrumentation, что собственно является очень неудобным аналогом макросов.

Ой, тут как раз много чего можно сказать. Например, монад трансформеры. И вообще AOP не от хорошей жизни — либо язык недостаточно выразителен для описания advise-ов, либо программа так построена, что только AOP позволит впихнуть нвпихуемое. Всё таки separation of concerns должен по возможности достигаться с помощью правильного дизайна и удобного языка, а не с помощью внешних средств типа AOP.

Z>IoC на макрах тоже будет сильно юзабельнее.

Чем? Нужен пример, чтобы сравнить с тем, что можно делать без макросов.

Z>А вообще мы ушли от темы Мне вообще не интересно доказывать незаменимость макросов для статики. Незаменимых инструментов мало, есть те которые заменить дорого.

Недорого. Для чего я вижу полезно использование макросов — так это всяческая кодогенерация. Это явно говорит о том, что язык недостаточно выразителен в этой области. Т.к. из меньшего (несколько строк макроса) получаем большее (кучу кода на этом языке). Однако для этой цели можно пользоваться и другими средствами — внешние кодогенераторы, препроцессоры и т.д.

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

ВВ>Ну запостил тему в форум "Флейм" и еще удивляешься, что тебя разводят на флейм. В первый раз что ли здесь

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

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

Контекст навеян темой про руление динамики в вебе. Потому и выбран веб.

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

ВВ>На новой БД по ходу разработки многое может меняться. Ты хочешь сказать, что *как правило* "статически-типизированный ДАЛ" работает корректно? Да, согласен. Так и есть. В противном случае никто бы не пользовался всяческими Линками.

Ну так и DAL генерируется на момент компиляции системы, а не на момент начала разработки.

ВВ>Но знаешь что интересно? Динамически-типизированный ДАЛ тоже *как правило* работает корректно.

Т.е. если динамика лишается своих плюсов, от нее можно избавиться, так?

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

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

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

ВВ>>Сама тема, видимо, интересная, но обсуждение все же идет в контексте веб-фреймворка, и контекст на мой взгляд странный. Хотя бы потому что с точки зрения любого фреймворка важно не то, как это фреймворк *пишется*, а то, как он используется. И я не вижу кардинальной разницы в использовании фреймворка, построенного на кодогенерации, фреймворка на макросах и фреймворка на динамике.
Z>Контекст навеян темой про руление динамики в вебе. Потому и выбран веб.

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

ВВ>>Но знаешь что интересно? Динамически-типизированный ДАЛ тоже *как правило* работает корректно.
Z>Т.е. если динамика лишается своих плюсов, от нее можно избавиться, так?

Нет, скорее наоборот. Плюсов лишается статика Плюсы у динамики как были, так и остаются. Ты просто касаешься той области, которая динамична by design. И ее никак не исправить. Ну тебе, я понимаю, интересно, можно ли на статически-типизированном языке сделать все так же удобно, как на том же Руби. Ну я думаю можно REPL, кстати, тоже не проблема. Для REPL-a, кстати, нужна скорее не динамика, нужен интерпретатор — да и то многие языки даже без него обходятся.

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

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

ВВ>>Причем тесты для ДАЛа я буду писать в обоих случаях — и тесты довольно банальные, вплоть до того, что их генерить можно. И эти тесты вообще нивелируют какую бы то ни было разницу в типизациях. Т.е., повторюсь, в этой области по фиг вообще — статика или динамика. Результат один.
Z>Писать тесты на DAL занятие не только бесполезное, но и вредное. Нужна лишь гарантия, что DAL рассчитан на работу именно с этой схемой данных, остальное протестирует статика. Алгоритмические ошибки тестами выявить очень сложно.

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

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

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

DG>зы
DG>макросы плохи тем, что они могут сделать с кодом все что угодно, и соответственно макросы могут очень легко испортить код.
DG>стыковка одного макроса с другим макросом — та еще по легкости задача.

А сколько макросов Вы написали и отладили?

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

L>Недорого. Для чего я вижу полезно использование макросов — так это всяческая кодогенерация. Это явно говорит о том, что язык недостаточно выразителен в этой области. Т.к. из меньшего (несколько строк макроса) получаем большее (кучу кода на этом языке). Однако для этой цели можно пользоваться и другими средствами — внешние кодогенераторы, препроцессоры и т.д.

Типы тоже кодогенераторами и препроцессорами выводить? А ведь многие макросы занимаются именно этим — выводят типы выражений, которые трансформируются.

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

DG>зы
DG>макросы плохи тем, что они могут сделать с кодом все что угодно, и соответственно макросы могут очень легко испортить код.
DG>стыковка одного макроса с другим макросом — та еще по легкости задача.

Был у нас макрос — реализовывал LINQ в Nemerle. А также был другой макрос (ToExpression) — генерировал Expression tree линковский. Но когда они писались, у нас небыло макроса для генерирования анонимных классов и вместо классов в проекциях использовались кортежи. И вот однажды это макрос (аналог new { .... } ) был написан. Как вы думаете, сколько усилий было потрачено на стыковку linq и ToExpression с ним? — Нисколько. Все заработало само.

H>А сколько макросов Вы написали и отладили?

для начала ответьте где вам логику преподавали?

> Как вы думаете, сколько усилий было потрачено на стыковку linq и ToExpression с ним? — Нисколько. Все заработало само.

и где вас научили что результаты одиночного факта можно использовать для доказательства правильности всего класса утверждений?

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

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

H>Типы тоже кодогенераторами и препроцессорами выводить? А ведь многие макросы занимаются именно этим — выводят типы выражений, которые трансформируются.

Для кодогенерилки достаточно динамики, нафиг тут типы выводить?

По остальным пунктам, как я понимаю, замечаний нет?

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

H>>А сколько макросов Вы написали и отладили?

DG>для начала ответьте где вам логику преподавали?

Признаюсь, логику мне не преподавали.


>> Как вы думаете, сколько усилий было потрачено на стыковку linq и ToExpression с ним? — Нисколько. Все заработало само.

DG>и где вас научили что результаты одиночного факта можно использовать для доказательства правильности всего класса утверждений?

Результаты фактов (а также личный опыт) могут существенно сузить применимость утверждения.

DG>ps
DG>ты приводишь пример по стыковке не пересекающихся макросов.
DG>а серьезные проблемы начинаются с макросами, которые проводят изменения в одних и тех же точках.

Ну так нужны примеры Я не помню чтобы ктото пытался комбинировать несколько могучих макросов, которые выполняют немалую работу и генерируют/модифицируют много кода.

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

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

H>>Типы тоже кодогенераторами и препроцессорами выводить? А ведь многие макросы занимаются именно этим — выводят типы выражений, которые трансформируются.

L>Для кодогенерилки достаточно динамики, нафиг тут типы выводить?

foreach — макрос выводящий типы. Как его на кодогенераторах сделать?

L>По остальным пунктам, как я понимаю, замечаний нет?

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

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

L>Можно потроллить?

Все бы так конструктивно тролили

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

L>Нахождение чистых методов — pure type systems
L>Параллелить — автоматическое распараллеливание
L>Кэширование — ленивость, referential transparency, common subexpression elimination etc.

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

Z>>Пресловутый DSL в прекомпайл тайме такой геморой, что его никто не использует. Максимум — делают что-то типа fluent api и наслаждаются.

L>Ну, неправда же. Или не понимаю о чём речь.

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

Z>>AOP без макросов делается либо с огромным оверхедом либо через bytecode instrumentation, что собственно является очень неудобным аналогом макросов.

L>Ой, тут как раз много чего можно сказать. Например, монад трансформеры. И вообще AOP не от хорошей жизни — либо язык недостаточно выразителен для описания advise-ов, либо программа так построена, что только AOP позволит впихнуть нвпихуемое. Всё таки separation of concerns должен по возможности достигаться с помощью правильного дизайна и удобного языка, а не с помощью внешних средств типа AOP.

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

Z>>IoC на макрах тоже будет сильно юзабельнее.

L>Чем? Нужен пример, чтобы сравнить с тем, что можно делать без макросов.

Я оговорился, не IoC в общем смысле, а DI как механизм для него. Достигается например применением AOP ко всем конструкторам в коде.

L>Недорого. Для чего я вижу полезно использование макросов — так это всяческая кодогенерация. Это явно говорит о том, что язык недостаточно выразителен в этой области. Т.к. из меньшего (несколько строк макроса) получаем большее (кучу кода на этом языке). Однако для этой цели можно пользоваться и другими средствами — внешние кодогенераторы, препроцессоры и т.д.

Любой универсальный язык недостаточно выразителен в каждой специфической области. Но лично я всегда отбрасывал кодогенераторы как решение на самый крайний случай. А маросы не пугают нисколечко.

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

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

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

Z>>>Пресловутый DSL в прекомпайл тайме такой геморой, что его никто не использует. Максимум — делают что-то типа fluent api и наслаждаются.
L>>Ну, неправда же. Или не понимаю о чём речь.
Z>Речь о вставках своего синтаксиса в код который его не поддерживает и обработка препроцессором в прекомпайл. Например у оракла были механизмы позволяющие писать на SQL прямо в сишном коде. Иногда используют сторонние инструменты, но простенький DSL для своего проекта делают исчезающе редко.

А! Речь про eDSL? Если взять другие языки, то окажется, что с этим там всё в порядке — ruby, например. Или, чтобы было схоже с Nemerle — Scala. Язык не имеет макросов, но писать на нём DSL-и приятно.

Если всё таки важен синтаксис, то во-первых — почему? Наверное, захочу примеров — мы как-то с VladD2 обсуждали разницу описания грамматики в Parsec и EBNF. Вместо p* пишем many p, вместо a | b, пишем a <|> b. Конечно, можно переопределить *, | для того, чтобы синтаксис был схож, но даже если нет — отличия только в синтаксисе — насколько это важно? Гораздо важнее в eDSL ведь семантика, как мне кажется.

Во-вторых — препроцессоры тоже разные бывают. С удобными разборщиками типа haskell-src-exts или с помощью camlp4 можно очень удобно работать.

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

А вот примеры очень хочется. Для меня писать pointcut, который матчит по имени (!) то ещё убожество. Абстракция тут явно протекает.

Z>Я оговорился, не IoC в общем смысле, а DI как механизм для него. Достигается например применением AOP ко всем конструкторам в коде.

Т.е.? Зачем такие сложности? Что мы от этого выигрываем?

Z>Любой универсальный язык недостаточно выразителен в каждой специфической области.

Не так. "Любой универсальный язык недостаточно выразителен в какой-то специфической области" и применение макросов показывает в какой именно.

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

ВВ>Обоснуй, пожалуйста, чем генератор исходников менее удобен.

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

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

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

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

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

В вебе проявляются ее достоинства, краткость кода и минимальное количество движений для внесения изменений. А недостатки скрадываются, мы можем править любые баги очень быстро. Это не коробочная версия, в которой нашли багу после того, как она ушла к клиенту. И скорость в вебе не всегда критична, на десктопе лаги интерфейса дают негатив куда сильнее.

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

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

Это что за задача с маленьким сервером и огромным клиентом?

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

Это потому, что у тебя есть код и там и там, естественно ты его можешь и там и там править. У меня код только там, разъезжаться в таком случае просто нечему.

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

Давай пример юнит теста и сценария в котором этот юнит тест нам будет полезен. Я не представляю о чем ты говоришь.