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

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

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

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

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

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

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

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

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

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