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

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

Здесь обсуждается не это. Хочешь в очередной раз свести все к своему любимому флейму "макросы вс. мир"? Это если у Вульфхаунда не получится превратить все в филиал срача "Динамика вс. Статика".
Не об этом речь. Тема другая. Удобство конечного решения.

И да, мне *как пользователю* неважно, насколько сильно страдал разработчик при разработке фреймворка.

VD>Тебе не кажется, что если фрэймвор делается на базе более подходящего решения, то и результат получается лучше?

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

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

ВВ>Это если у Вульфхаунда не получится превратить все в филиал срача "Динамика вс. Статика".
Так это вы опять орете "динамика это круто" и что характерно опять абсолютно голословно.

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

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


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

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

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

Из других вариантов — pyjamas и Lift (правда в последнем скорее обёртки к JS+AJAX+Comet)

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

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

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

Ты с ним так же говоришь на разных языках. Это представитель религии Хаскеля (даже не ФП, а его радикального крыла ).

Причем в данном случае уже ты сам вне контекста, так как явно не знаком с Хаскелем и его прибамбасами.

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

Вот только они в своих рассуждениях забывают упоминать детали. А детали все портят...
1. Даже выразителности Хаскеля зачастую недостаточно чтобы записывать ДСЛ-и именно в том виде в котором его видя программисты. В итоге в ход идут ужимки. Вместо символов "/" в грамматике начинают использоваться супер-пупер конструкции вида "<@>" и т.п.
2. Красивый и легко расширяемый код в большинстве случаев — это медленный код. А быстрый код — это не очень красивый код. Например, красивые выкрутася на хаскеле зачастую связаны с применением ленивости (отложенного вычисления). Но те же ленивые списки частенько очень сильно замедляют код. Скажем для представление строк в хаскеле по умолчанию применяются ленивые списки, но это очень медленно. По этому там же придумали бинарные строки, которые, как я понимаю, являются массивами символов. Но вот уже с ними работать не так здорово.
3. Хаскель хорош когда речь идет о написании вычислительного кода. Но для проектирования больших симстем в нем нет ничего акромя возможности вручную эммулировать паттерн "Абстрактный Тип Данных". Соответственно и все выкрутасы с кодом и ДСЛ-ями обычно ограничиваются тем что мы называем уровнем метода.

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

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

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

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

Во! Еще один. Буквально недавно тоже самое заявлял автор D.
Это видимо общая черта людей — придумывать себе пугалки вместо того чтобы просто попробовать то о чем рассуждаешь.

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

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

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

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

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

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

Ну, вот давай сравним "хороший" доступ по конечному результату. Авторы Спирита работают над проектом уже много лет. А мы с Вольфхаундом заткнули Спирит за пол года ненапряжной рабты. Причем заткнули по всем параметрам. Наш парсер: быстр, выдает четкие и понятные сообщения об ошибках, использует более продвинутые алгоритмы, имеет чистую и понятную грамматику, интегрируется с IDE (показывает сообщения об ошибках по месту, обеспечивает навигацию). При этом код нашего рашения в несколько раз меньше и проще.

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

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

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

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

Хороший ответ на вопрос! Что и следовало ожидать. Слив засчитан!

VD>А что за макросы ты написал чтобы выражать такие суждения?

из крупных:
генерация js
linq2sql
linq2xpath
преобразование кода в cps
склеивание множества запросов к базе в единый запрос

зы
но это не немерлье.

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

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

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

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

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

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

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

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

Какой? Liftweb? А что там было не так, я уже не помню обсуждение?
Потом, это же нелогично — найти пример, где не используются возможности DSL-строения на Scala и предлагать его как опровержение возможности построения DSL-ей на нём. Посмотри squeryl, например. Вообще проще по задачам смотреть. Как задачи решаются с помощью макросов, как без. Есть хорошие примеры?

L>>Во-вторых — препроцессоры тоже разные бывают. С удобными разборщиками типа haskell-src-exts или с помощью camlp4 можно очень удобно работать.
Z>Ну не может лишнее звено добавлять удобство. Как ни крути. Я не знаю, зачем там препроцессоры, расскажи плиз.

А что такое макросы в Nemerle — они же тоже только в компайл-тайме работают?
Препроцессор обсуждать не хочется. По сути у него с макросом одна беда — используем там, где язык недостаточно выразителен сам по себе. Я их привёл как пример того, что есть тулзы не менее удобные, чем макросы. Например при использовании haskell-src-exts будет тот же паттерн-матчинг по разбору и перелопачиванию AST (с учётом типов и всего, что в AST лежит), что и в макросах Nemerle. Подключение — указание в директиве в исходнике.

Z>Да тут простор фантазии, Допустим все методы ISession.Commit(), или все методы помеченные атрибутом TransactionScope(); Или все методы, внутри которых есть вызов любого метода ISession. Ни один PostSharp не даст таких возможностей. Да что методы, pointcut оборачивающий все секции lock {} для того же логгирования или профилирования.

Как я и писал, это всё можно решить правильным дизайном на языке более высокого уровня. Использование AOP вместо улучшения дизайна — это использование подпорок, IMHO. Бывает по разному, но из моего опыта — AOP обычно вынужденная мера. Главная проблема AOP — ухудшение понимания кода. Мы не знаем, что сюда ещё вклинилось, нужно смотреть пойнткаты.

ISession.Commit — наследование не интерфейсов, а миксинов.
lock в некоторых языках это не конструкция, а first-class функция, уровень, на котором в одном месте нужно смешивать и lock и логирование — определённо выше, чем уровень самого lock — он, скорее всего будет обёрнут.
Ну и т.д. — например. вместо атрибутов можно использовать систему типов. Которые уже приведут к требуемому поведению (см. монад трансформеры).

Z>>>Я оговорился, не IoC в общем смысле, а DI как механизм для него. Достигается например применением AOP ко всем конструкторам в коде.
L>>Т.е.? Зачем такие сложности? Что мы от этого выигрываем?
Z>От DI? Или от избавления явного обращения к контейнеру?

От использования макросов для DI.

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

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

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

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

ВВ>Про меньшее количество движений — это совсем неочевидно. Как компилятор может контролировать то, что известно только в рантайме?

А как тесты у тебя это контролируют?

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

Кто мешает отловить экзепшен и сказать, что пришла фигня? Чем тут динамика поможет? Точно так же свалится в рантайме, если не делать проверок.

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

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

Z>>Это что за задача с маленьким сервером и огромным клиентом?
ВВ>Это не задача, это один из вариантов решения.

Еще раз, что за задача, в которой сервер настолько прост, а гуи к нему настолько сложен, что такая разница в коде?

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

ВВ>Только "там" — это где? На сервере? Как у тебя так получается? Как можно писать приложения с богатым клиентским слоем, вроде того Гмейла, и не формировать HTML на джаваскрипте?

Бррр... Ты цитату не оттуда взял, это относилось к схеме бд и коду DAL.

ВВ>Да дело даже не в этом, пусть ДжаваСкрипт HTML вообще никак не генерит. Он что, с ним и не работает? Контрол задизеблить надо — сабмит форму или ее часть на сервер?

Я теряю полет мысли, честно.

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

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

Зачем проверять консистентность модели которая впрямую отображает БД и зачем нужны процедуры которые делают CRUD? При этом их еще и тестировать надо? В каком сценарии нам эти процедуры и тесты полезны будут?

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

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

Не так, Ли.

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

Не уж то так хочется выглядеть глупо? Ты бы сравнил интеграцию для Nemerle с интеграцией для F#-а. Уверяю тебе ждет очень серьезный разрыв шаблона, так как первая сильно превосходит вторую. А тайп-провайдыры они пока что планируются только F#. Немерл их, понятное дело, тоже сможет поддерживать так как для этого достаточно будет написать только макрос-прокладку. А вот в шарпе ты их не увидишь еще очень долго.

Не находишь, что получается глупейшее сравнение студии со студией?

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

Нигде если Вы программируете на Блабе (с) Пол Грехем.

Ты лучше другое спроси. Кто такоей Ziaw и почему он вдруг стал говорить о макросах. Это очень интересный вопрос. Дело в том, что совсем недавно он был в твоем же лагере и в споре со мной выдвигал примерно такие же доводы, что и ты. Только в отличии от тебя он не поленился и попробовал то что обсуждал. И — о чудо — вопросы снялись сами собой.

Кэр>Никто тут не проектирует язык, ибо это почти всегда очень и очень непросто по сравнению с оригинальной задачей.

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

Кэр>Это сложно задизайнить, это сложно отладить, это сложно поддерживать.

Все зависит от размера языка, мощности применяемых для этого "инструментов" и опыта разработчика. Скажем XML-литералы я написал за несколько дней. Ziaw недавно за несколько часов написал парсер для JSON. Так что твои рассуждения расходятся с реалиями окружающего тебя мира.

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

Совсем не давно не было даже небольшой толпы. Сейчас уже есть небольшая толпа (по твоим же оценкам). Она же не из воздуха взялась? Это все люди которые услышали эти крики и подумали — "Хм может они все же не врут? Надо попробовать...". А те кто в серьезе попробовали эту траву (и при этом действительно доросли до столь мощного инструмента) из скептика очень быстро превращаются в сторонников. Стоит только написать один полезный макрос (по сложнее), как скепсис выветривается.
Так что "кричим" мы не в пустоту. Просто у тех с кем мы часто спорим есть железный аргумент — "сам я Пастернака не читал, но как и весь Советский народ осуждаю его...". Но среди серых масс все же есть ряд людей способных думать и оценивать самостоятельно. Из них и прирастает эта "толпа".

Кэр>Никто не будет в здравом уме дизайнить язык для своего текущего проекта и текущих задач.

Уже "дизайнят". Ты отстал от жизи. Просто есть огромные толпы посредственных программистов не способных вообще ни на что кроме тупого говнокодерства. Но есть и другие люди. Есть те кто использует Немерл, Лисп, Хасель, Эрланг, Руби, Питон... В этих коммюнике создание языков для решения задачи явление вполне обойденные. Так же есть люди которые используют внешние генераторы кода и другие не очень продуктивные подход, но все же более позволяющие решать задачи путем ДСЛ-естроения.

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

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

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

Кэр>В общем, есть много объективных причин (еще со времен Лиспа), почему кастомный синтаксис в прикладных задачах используется очень редко.

Можно на два вопроса ответить?

Когда кончились времена Лисп-а?

И сколько проектов ты написал на Лисп-е?

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

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

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

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

ВВ>Я о другом. Скажем, linq2Sql, использующий "внешний" генератор кода, не менее удобен в использовании, чем аналогичное решение с макросами. Здесь же, мне показалось, не о крутости макросов идет речь, а об удобстве веб-фреймворка.

Вот не надо. Бредовее тула я еще не видел. Единственный нормальный способ обновить сгенеренный код — убить все классы и перетащить снова все нужные объекты базы из окна сервера. При этом если ты в проперти гриде делал какие-то правки, они исчезнут.

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

FR>Ну хорошие шаблоны очень близки по возможностям к макросам. Например D'шные вполне позволяют "анализировать компилируемый код" http://www.digitalmars.com/d/2.0/traits.html http://www.digitalmars.com/d/2.0/phobos/std_traits.html

Я только что влез в тему где дишники обсуждали возможности расширения своих "хороших" шаблонов. Точнее шаблоны их вообще мало пригодны для многих вещей. Так что речь шла о их "стринг миксинах". Вот погляди. Только у дишников все странно. В том числе и интерфейс их конфы. Так что всех сообщений почему-то не видно. Может есть какие-то другие интерфейсы?

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

ВВ>>Про меньшее количество движений — это совсем неочевидно. Как компилятор может контролировать то, что известно только в рантайме?
Z>А как тесты у тебя это контролируют?

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

ВВ>>Если, скажем, у меня задача читать ХМЛ, который приходит из внешнего источника — то это динамика. И если ты макросом сгенеришь красивый и как бы статически типизированный код для чтения этого ХМЛ-я — то это все равно будет динамика. Просто выглядящая как статика. И если вместо ХМЛ-я придет фигня, то все свалится в рантайме.
Z>Кто мешает отловить экзепшен и сказать, что пришла фигня? Чем тут динамика поможет? Точно так же свалится в рантайме, если не делать проверок.

Динамика ничем не поможет. Сам сценарий изначально — это динамика. Чтение ХМЛ через XmlReader — это динамика. Работа с базой — это динамика. Динамика — это просто данность. Тут другой вопрос — чем в данном случае поможет статика?

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

Да ну, не так страшен черт. Что вы так боитесь этих тестов-то? Меняются готовые тесты вообще довольно редко. Чаще пишутся новые. Сделал фичу — парочку-другую тестов для нее. Это уже до автоматизма доходит. Времени всего ничего. Зато доходит чуть ли не до 100% coverage.

Z>>>Это что за задача с маленьким сервером и огромным клиентом?
ВВ>>Это не задача, это один из вариантов решения.
Z>Еще раз, что за задача, в которой сервер настолько прост, а гуи к нему настолько сложен, что такая разница в коде?

Причем тут ГУИ? Я говорю — вся логика пишется на клиенте. *Вся логика*. Кроме той, которую просто чисто физически нельзя писать на клиенте. Практически любое приложение можно так написать.

Z>>>Это потому, что у тебя есть код и там и там, естественно ты его можешь и там и там править. У меня код только там, разъезжаться в таком случае просто нечему.
ВВ>>Только "там" — это где? На сервере? Как у тебя так получается? Как можно писать приложения с богатым клиентским слоем, вроде того Гмейла, и не формировать HTML на джаваскрипте?
Z>Бррр... Ты цитату не оттуда взял, это относилось к схеме бд и коду DAL.

Тогда я уже не понимаю. У меня ДАЛ-а на клиенте тоже нет, откуда бы он там взялся.

Z>>>Давай пример юнит теста и сценария в котором этот юнит тест нам будет полезен. Я не представляю о чем ты говоришь.
ВВ>>А что непонятно-то Простые изолированные тесты, которые в первую очередь проверяют консистентность модели. Ну или корректность работы процедур, если они имеются. Скажем, один тест проверяет все процедуры для работы с конкретной сущностью — вставил, прочитал, сверил результаты, удалил.
Z>Зачем проверять консистентность модели которая впрямую отображает БД и зачем нужны процедуры которые делают CRUD?

Чтобы убедиться в том, что нет рассинхрона.

Z>При этом их еще и тестировать надо? В каком сценарии нам эти процедуры и тесты полезны будут?

В основном regression testing. Собственно, один из основных смыслов юнит-тестов.

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

ВВ>>Я о другом. Скажем, linq2Sql, использующий "внешний" генератор кода, не менее удобен в использовании, чем аналогичное решение с макросами. Здесь же, мне показалось, не о крутости макросов идет речь, а об удобстве веб-фреймворка.
Z>Вот не надо. Бредовее тула я еще не видел. Единственный нормальный способ обновить сгенеренный код — убить все классы и перетащить снова все нужные объекты базы из окна сервера. При этом если ты в проперти гриде делал какие-то правки, они исчезнут.

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

Ну в принципе это проблема linq2Sql. Никто им не мешал нормальное обновление сделать.

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

VD>Трепачи они всегда были находками для шпионов. Пока что ваш любимый супер-пупер язык всех времен и народов — Хаскель, глухо сливает в выразительности и производительности "недостаточно выразительному язык".

Производительность — это твой бзик, я знаю, устал уже об этом с тобой говорить. Помню как ты радовался, когда Nemerle на несколько процентов обогнал Haskell. Определённо рвёт, о да, даже спорить не хочу.

Но про выразительность то ты как можешь говорить? Ты же Хаскеля не знаешь, сам таких людей называл Блабами — я слышал!

VD>Хаскелю уже где-то лет двадцать, да? Но вот язык которому без году неделя делает его в области тех же парсеров как котенка, хотя казалось бы это та область на которой Хаскель пиарят последние лет 10.

Чиво? Где это язык, которому... делает Haskell в области парсеров? И нет, парсеры — далеко не самое важное в Haskell, просто идея парсер комбинаторов пошла оттуда. А про Alex, Happy, autoparsec и прочую кучу библиотек и тулзов парсинга ты просто не в курсе.

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

Где логика? Или это просто твоё решение — вот когда хаскель будет..., тогда я и буду слушать lomeo! Если так — то на что ты вообще отвечаешь, не выслушав меня?

VD>Ваша хваленая ленивость сразу же выбрасывается за борт когда речь заходит о скорости выполнения.

А так как производительность зависит только от очень небольших участков, то выбрасывается она только там. Всё остальное смело использует все преимущества ленивости. Откуда следует, что ленивость по умолчанию в Haskell выбрана не зря. Ни один из пользователей Haskell это не подвергает сомнению. А вот человек, не пользовавший его пытается судить. Знаешь какова цена мнению дилетанта?

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

Haskell не идельный язык — и вообще "avoid success at all costs" его лозунг. Но большинство проблем, о которых Nemerle даже не подозревает (и так и не будет подозревать, а будет совать свои макросы во все щели) в Haskell успешно решены. Там где Haskell невыразителен можно использовать макросы, никто не мешает — есть же TH. И, кстати, используют, вспоминая в свою очередь, например, о более generic языках. А вот там, где Haskell достаточно выразителен, Nemerle по прежнему придётся совать свои макросы. И какому из языков не хватает выразительности?