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


DG>>>т.к. и тот и другой — хочет select/where заменить на свою конструкцию.

Z>>Не будет макрос распараллеливания работать с select where, а будет с Select(this IEnumerable src, ..), это не проблема.

DG>так и linq2sql работает с Select(this IEnumerable src, ...)

Нет, linq2sql работает с Select(this IQuerable src, ...)

Z>>Нет, этот конфликт просто от незнания простых приемов работы с макросами.

DG>bla-bla.. я самый умный, все остальные тупее меня...

сорри, если обидел, не хотел.

Z>>Никто не будет делать распараллеливание linq2sql просто потому, что это а) это не паралелится так просто, ибо одна транзакция не параллелится, б) все что нужно сервер распаралелит гороаздо лучше, его для этого и писали.

DG>опять считаешь других тупее тебя... либо сам не понимаешь о чем идет речь.

Объясни популярно. Какой смысл автоматом параллелить вызовы к БД.

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

DG>

DG>parallel
DG>(
DG>  var managers = db.Managers.Where(manager=>manager.IsTopManager).ToArray();
DG>  var cars = db.Cars.Where(car=>car.IsFree).ToArray();
DG>  return НазначитьМашиныДляМенеджеров(managers, cars);
DG>)
DG>

DG>зы
DG>вместо parallel здесь также можно применить замену синхронных запросов на асинхронные, объедиение запросов и т.д.

Не будет работать вообще, тут одно соединение и одна транзакция.

Z>Нет, linq2sql работает с Select(this IQuerable src, ...)

зачем нужен IQueryable при наличии макроса раскрывающего код linq2sql? лишняя сущность какая-то..

Z>Объясни популярно. Какой смысл автоматом параллелить вызовы к БД.

есть такое слово "чтобы быстро работало"

Z>Не будет работать вообще, тут одно соединение и одна транзакция.

зависит от условий задачи — требуется или нет единая транзакция.
допустим не требуется

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

Z>>Нет, linq2sql работает с Select(this IQuerable src, ...)

DG>зачем нужен IQueryable при наличии макроса раскрывающего код linq2sql? лишняя сущность какая-то..

обоснуй мысль у тебя какая-то не очивидная

Z>>Объясни популярно. Какой смысл автоматом параллелить вызовы к БД.

DG>есть такое слово "чтобы быстро работало"

быстро но неправильно?

Z>>Не будет работать вообще, тут одно соединение и одна транзакция.

DG>зависит от условий задачи — требуется или нет единая транзакция.
DG>допустим не требуется

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

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


VD>Если вывод возможен, то в этих местах он уже не динамический, а статический. И конечно же все что относится к статике для него не чуждно. А там где невозможен, то для него справедливо все что говорится о динамике (в том числе и жопа с IDE).

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

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


VD>Не путай тюринг-полноту и полноту возможностей. Это совсем разные вещи. Скажем С++ и его шаблоны тюринг-полны. Но С++ может читать файлы, а его шаблоны — нет.

Ну так и шаблоны C++ и CTF D тоже весьма разные вещи. В D CTF позволяют писать на подмножестве самого языка а не на птичьем диалекте языка шаблонов. Да и файлы читать и разбирать во время компиляции вполне возможно.

FR>>Ну и конечно вынужденно функционально чистый.

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

Для D именно вынужденный.

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

FR>>Традиционно для окамла

VD>А можно не уходить от ответа? Мне правда интересно.

Для всего языка есть грубо полтора IDE из них одно полноценное OcaIDE в нем внутри используются Camlp4 и даже
вроде есть возможность подкрутить анализатор под свое расширение, но я не ковырял.

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

Z>Справедливости ради надо отметить, что кода у Влада меньше, а возможностей больше. Кроме встраивания xml в произвольное место (как умеет и htcaml), в немеловом варианте есть if и foreach, позволяющие вставлять тег по условию или множить его в цикле.

Ну кода практически одинаково:

N:\dev\repo\nemerle\snippets\Nemerle.Xml\Nemerle.Xml.Macro

nemerle: files = 7  lines = 789  size = 28 kb. (28876 bytes)

N:\dev\repo\htcaml\pa_lib

ocaml: files = 10  lines = 845  size = 27 kb. (27969 bytes)

Ну и парсятся немного разные вещи, XML и XHTML.

Вместо foreach там $list доступ к списку и возможность использовать ФВП типа map fold и т. п.

let process tweets =
    let html = <:html<
      <html>
        <head>
          <link rel="stylesheet" type="text/css" href="style.css"/>
        </head>
        <body>
          My collection of tweets :
          $list:List.map html_of_tweet tweets$
        </body>
      </html>
    >> in
    let chan = open_out "tweets.html" in
    output_string chan (Html.to_string html);
    close_out chan

Ну и foreach при желании прикрутить много кода не нужно, например http://www.ocaml-tutorial.org/camlp4_3.10/foreach_tutorial
(сейчас у меня сайт не доступен можно тут посмотреть)

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

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

Это не ерунда. Когда ты используешь хэш-таблицы, ты точь-в-точь имитируешь семантику тех же джаваскриптовых объектов. Пример с ХМЛ или базой простой чуть более сложный, а суть-то там одна — речь идет о данных, структуру которых мы не может гарантировать в компайлтайме.

Z>Не работает это все для быстрого прототипирования. В РОР я пишу миграцию с количеством строк равным нужному мне количеству атрибутов и через пару секунд могу работать со вновь созданным в базе объектом. А ты что рекламируешь? Создай таблицу, создай 4(!!!) хранимки которые будут что-то там контролировать, создай тесты на эти хранимки, которые будут контроллировать сами хранимки

Какие 4 хранимки? У нас что, конкурс передергивания?
Миграции ваши — это хорошо, конечно, но это решение, которое строго идет в коробке с самим ДАЛ-ом. Если нужно следовать другим процедурам миграции, то весь ДАЛ становится бесполезным практически полностью.

Z>и работай потом с этими хранимками через GetReader, ибо динамика и нет разницы какой DAL юзать. При всем этом тотальном контроле у тебя это все все равно остается динамикой, которая вечно разваливается, т.к. контроллируется тестами вместо компилятора.

Я тебе через DataReader работать не предлагал. Но с точки зрения надежности и статического контроля это решение мало чем отличается от вашего типизированного ДАЛа.

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

Обоснуй, какие тут могут быть проблемы безопасности.

Z>Чего с чем? Процедур со схемой? Или процедур с кодом? Ты внес еще один слой возможного рассинхрона и тут же счастливо отрапортовал, что рассинхрона не будет, потому, что есть протестированый спец слой который это гарантирует.

О чем ты вообще? Ты никогда хранимые процедуры не писал? Я привел их в пример того, для чего разумно писать тесты. Хранимые процедуры я тебе писать не предлагаю.

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

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

Z>Вобщем сделать из статики динамику действительно не так сложно, достаточно побольше хранимок, рефлекшена и работы с xml по строковым константам.

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

Z>Только это никакого отношения к теме не имеет, я говорю про перенос достоинств динамики в статику, а ты переносишь недостатки.

И что? Он состоялся этот перенос? Если состоялся — то зачем о нем говорить, все должно быть видно, нет?

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

Z>Извини, но это ерунда. Реляционки это в большинстве задач никакая не динамика, как и xml приходящий от известного сервиса. Нету там динамики, там все должно быть в том состоянии на которое рассчитан код, либо корректная работа программы не может быть гарантирована. Все это спокойно контролирует система типов. Просто не надо ей мешать.
Совершенно верно. Вся могучесть реляционной алгебры как раз и состоит в довольно-таки жёсткой системе типов.
Просто традиционно эта система типов плохо ложилась на существующие ЯП. В RA большинство операций порождают новый "тип" прямо по месту, а в традиционной статике ты должен нудно описывать типы заранее.
Отсюда и миф про динамику в SQL. Linq фактически демонстрирует статичность RA.
RDBMS не более динамична, чем любая программа — точно так же я могу пойти в исходники на C#, и поменять определение некоторого типа. И вот тут как раз статика внезапно заруливает со страшной силой: в самом скучном случае за считанные секунды компилятор оббегает весь мой код, и проверяет выражения с использованием изменившегося типа. Если он находит где-то расхождения, он говорит мне об этом сразу же, а не через месяц эксплуатации. В более интересном случае у меня есть рефакторинг, который автоматически исправляет выражения, построенные с участием типа.

Точно так же я могу поменять схему типов в DLL, загружаемой динамически. Это полный аналог подсовывания базы данных, в которой схема отличается от той, для которой я писал код. Почему-то при этом никому в голову не приходит утверждать, что DLL — это динамика, и статическая типизация для них подходит плохо.

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

WH>Это очевидный бред для любого кто имел дело например с макросом PegGrammar и любым внешним генератором парсеров.
WH>Или вот например http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.Xml/Test/Main.n
WH>Попробуй повторить внешним ДСЛ.

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

"Тру" путь от МС — это именно делать через внешний ДСЛ, через билд-провайдеры и коде дом, что, конечно, создает нехреновый оверхед при разработке, но зато получается решение, которое работает не только в Немерле. А от макросов Немерле на Шарпе мало толку, нет?

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

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

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

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

Нужные нам для работы структуры можем, иначе как мы с ними работаем? Пример про хештаблицы вообще не понял, ты их используешь их для хранения данных? Часто?

ВВ>Какие 4 хранимки? У нас что, конкурс передергивания?

Ты объяснял, что для DAL нужны CRUD хранимки, а теперь я передергиваю?

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

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

ВВ>Я тебе через DataReader работать не предлагал. Но с точки зрения надежности и статического контроля это решение мало чем отличается от вашего типизированного ДАЛа.

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

ВВ>Обоснуй, какие тут могут быть проблемы безопасности.

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

ВВ>О чем ты вообще? Ты никогда хранимые процедуры не писал? Я привел их в пример того, для чего разумно писать тесты. Хранимые процедуры я тебе писать не предлагаю.

Ты так и не привел ни одного внятного сценария полезности хранимок и тестов на них.

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

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

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

Писькомерство? Поддамся на провокацию, мне не жалко, самый большой проект у меня примерно 1300 рабочих серверов на 1-30 рабочих мест связанных офалайновой репликацией и один центральный с веб интрефейсом. Таблиц чуть более 300. Раскидано это все на территории размером в несколько Франций. Админов почти нет. Работает более 7 лет. При ее создании и поддержке я понял, что любые тесты это костыли, которые не только помогают, но и мешают. Чем меньше их требуется, тем лучше проекту. И любой лишний код тоже сильно мешает, его поддерживать надо. А лишний слой абстракции, при развитии, мешает как собаке пятая нога.

Доставай свой, не стесняйся.

Z>>Вобщем сделать из статики динамику действительно не так сложно, достаточно побольше хранимок, рефлекшена и работы с xml по строковым константам.

ВВ>Не, не, не товарищ, ты определись. Выше ты говорил, что работа с хмл — это не динамика.

Если правильно подойте — не динамика, но сделать динамикой несложно, приложив немного усилий и строковых констант. Любую статику можно сделать динамикой при помощи Dictionary<string, object>() и методов Dictionary<string, object> MyCoolDynamicMethod(params Dictionary<string, object>[] args).

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

Ну да, мосье любитель разложить граблей.

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

На то и философия, чтобы поговорить, устал?

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

WH>Покажи мне рефакторинг уровня немерла для динамически типизированного языка.
WH>JetBrains PyCharm "IDE" для питона в плане рефакторинга сливает немерлу.

"Уровня Немерла" — это какой? Чтобы переименование работало? Если в динамически-типизированном языке нет понятия "мутабельных переменных", то переименования в том объеме, в котором оно работает, скажем, в студии, сделать в принципе не так сложно.

ВВ>>"Доступ к компилятору" — это не только АПИ, но еще и возможность влиять на развитие языка. Были бы вы просто группой поддержки, отвечающей за интеграцию, когда поляки бы занимались развитием языка без всяких оглядок на студию, сдается мне, накушались бы вы по полной. Это ты вот не видишь будущее языка без ИДЕ, поэтому и фичи рассматриваются в контексте интеграции — без этого жизнь бы медом не казалось.
WH>Повторю еще раз: Мелкософт режет фичи для C# на основании "трудно поддержить в IDE".

И что? А причем тут "Мелкософт"? Или они у вас пример для подражания? Можешь мне объяснить следственную цепочку, по которой от обсуждения "Немерла и интеграции в студию" мы перешли к C# и его интеграции?

ВВ>>Вывод типов как раз серьезно усложняет задачу создания полноценной ИДЕ. Фактически приходится выводить типы на уровне интеграции. Возможность при этом задействовать сервисы компилятора есть далеко не у всех языков.
WH>Их нет только у тех то об этом не задумывался.

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

WH>Немерле не поддерживает рекурсивные типы. И что?
WH>Думаешь большая проблема их поддержать?

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

ВВ>>Я повторю — да, в динамике интеллисенс будет работать не всегда. Но там, где он не будет работать, в статике код вообще не будет работать.
WH>И правильно. Нефиг код с ошибками пытаться выполнять.

Код на Pure (см. выше) — это не ошибочный код. Но он в Немерле не работает.

ВВ>>Для начала надо бы язык закончить. И таки да, у меня не ДжаваСкрипт и не Питон, мне типы выводить гораздо проще.
WH>А из-за чего тебе типы выводить проще?
WH>Может из-за того что у тебя метапрограммирования нет?

МП есть, как в любой динамике. Макросов нет.
Выводить проще потому что динамическая только типизация, люкап имен статический, скоп лексический, переменные иммутабельные, большинство структур данных иммутабельны.
На фоне ДжаваСкрипта, в котором есть даже поддержка динамического скопа и динамично просто все, что вообще может быть динамично, задача как бы сильно проще. А в ДжаваСкрипте еще prototype OOP через делегацию, возможность менять прототипы в рантайме — да это просто ад для тайп-чекера.
У меня система типов упрощает вывод. Скажем, если у меня есть функция вида:

let sum x y = x + y

То я могу вывести ее тип без deferral-a. Хотя оператор "+", конечно же, полиморфен. Просто тип — это по сути набор поддерживаемых операций. Соответственно, данная функция имеет тип Num->Num.
Такой вот код с т.з. семантики тоже полностью валиден и выведется:

let sum x y = (x + y) :: (y + x)

Типом функции будет Num->(Num,Cons). Конечно, в языке нет типов, который поддерживают (Num,Cons) — будем выдавать ошибку тайп чекера при вызове, все просто.

ВВ>>И с чем ты не согласен? Руби — медленный интерпретатор. Динамически-типизированный язык может быть и компилируемым. И разница в скорости будет весьма заметной.
WH>Компиляция динамике нихрена не помогает.
WH>Не смотря на всю свою круть V8 тормоз и жрет память тоннами на ровном месте.
WH>Ибо ему приходится на лету классы объектов менять и на каждый чих новый тип создавать.

Тормоз по сравнению с чем? Жрет память по сравнению с чем? По сравнению с Руби он просто летает. По сравнению с ПХП память не жрет вообще.
Я думаю, для меня в 80% случаев, если не больше, производительность V8 полностью устроила бы.

Причем — это ДжаваСкрипт. Очень сложный язык. Практически не поддающийся статическому анализу. *Слишком* динамический даже на мой вкус.

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

FR>Ну кода практически одинаково:

Хм, верно, видимо понятный код кажется меньше

FR>Вместо foreach там $list доступ к списку и возможность использовать ФВП типа map fold и т. п.

Я видел, в немерловом варианте это тоже есть.

FR>Ну и foreach при желании прикрутить много кода не нужно, например http://www.ocaml-tutorial.org/camlp4_3.10/foreach_tutorial
FR>(сейчас у меня сайт не доступен можно тут посмотреть)

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

Z>Нужные нам для работы структуры можем, иначе как мы с ними работаем? Пример про хештаблицы вообще не понял, ты их используешь их для хранения данных? Часто?

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

А в случае с ХМЛ-ем. Что я на самом-то деле хочу получить? Ну с чем бы я работал в идеальном мире? У меня была бы некая, скажем, коллекция объектов, т.е. экземпляры моих классов, все строго-типизированно, проверяется компилятором и т.п. и пр. Вместог этого я получают некий текст. В лучшем случае у меня есть некая ХМЛ схема, с помощью которой я могу этот "текст" проверить. А что есть эта проверка на самом-то деле? Рантайм тайп-чек не иначе. Вот вам и динамическая типизация.

ВВ>>Какие 4 хранимки? У нас что, конкурс передергивания?
Z>Ты объяснял, что для DAL нужны CRUD хранимки, а теперь я передергиваю?

Где я тебе такое объяснял? "Хранимки" — это что, матерное слово теперь? Их упоминание в приличном обществе вызывает волну негатива? Хранимки — пример того, что можно тестировать в regression testing-е. Нет хранимок — тестируются методы ДАЛ, линк там, whatever.

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

Хм, а если сам отмигрировать с ДЕВа на ТЕСТ, то как себя ДАЛ будет чувствовать? База другая, схема (формально) другая. Или валидация модели не делается?

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

Точки фейла те же, только в других местах — нет гарантии, что есть поля с заданным именем, нет гарантии, что тип полей совпадает с тем, который я хочу и пр. Так с моделью то же самое — поменялось что-то в БД, поломалась модель. В моем случае — поломался сам код. Ну если тут и есть разница, то уже очень незначительная.

ВВ>>Обоснуй, какие тут могут быть проблемы безопасности.
Z>Ну ты же всю логику на клиента засунуть пытаешься, у сервера будет очень богатый интерфейс доступа к данным, гарантировать в этой системе безопасность станет сложнее. Например тип атрибутов которые можно изменить при вызове PUT /myobject зачастую зависит от сценария использования, тебе придется генерировать апи для каждого сценария и сервер перестанет быть таким тонким либо ты поимеешь проблемы с безопасностью.

Веб-сервисы писал? Вот здесь ровно то же самое и никаких проблем с секьюрностью нет. АПИ сервера кстати куда компактнее, чем в случае обычного приложения. Ведь в обычном веб приложении у тебя каждая страница — это по сути как метод АПИ, куча точек входа.
Единственная реальная проблема — с УРЛ. Но иногда это даже скорее плюс, а не проблема. Ну и возможности языка, недостаток библиотек.

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

Сценарий использования чего? Хранимок? Тестов? Я тебя уже сказал — тесты нужны для regression-а. Ты думаешь, один раз сгенерил, сегодня работает и завтра будет? Нет, сегодня работает, завтра не работает. Тесты позволяют с этим бороться.

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

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

Вовсе нет. Я даже свой доставать не буду (Хотя у меня длиннее, конечно )

Z>Поддамся на провокацию, мне не жалко, самый большой проект у меня примерно 1300 рабочих серверов на 1-30 рабочих мест связанных офалайновой репликацией и один центральный с веб интрефейсом. Таблиц чуть более 300. Раскидано это все на территории размером в несколько Франций. Админов почти нет. Работает более 7 лет. При ее создании и поддержке я понял, что любые тесты это костыли, которые не только помогают, но и мешают. Чем меньше их требуется, тем лучше проекту. И любой лишний код тоже сильно мешает, его поддерживать надо. А лишний слой абстракции, при развитии, мешает как собаке пятая нога.

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

Z>>>Вобщем сделать из статики динамику действительно не так сложно, достаточно побольше хранимок, рефлекшена и работы с xml по строковым константам.
ВВ>>Не, не, не товарищ, ты определись. Выше ты говорил, что работа с хмл — это не динамика.
Z>Если правильно подойте — не динамика, но сделать динамикой несложно, приложив немного усилий и строковых констант. Любую статику можно сделать динамикой при помощи Dictionary<string, object>() и методов Dictionary<string, object> MyCoolDynamicMethod(params Dictionary<string, object>[] args).

Правильно — это как? ХМЛ так или иначе приходит к тебе в рантайме, и именно в рантайме тебе надо проверить, что присланный ХМЛ соответствует контракту. Что бы ты ни делал, ты от этого не уйдешь.

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

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

Z>>>Только это никакого отношения к теме не имеет, я говорю про перенос достоинств динамики в статику, а ты переносишь недостатки.
ВВ>>И что? Он состоялся этот перенос? Если состоялся — то зачем о нем говорить, все должно быть видно, нет?
Z>На то и философия, чтобы поговорить, устал?

Так о чем поговорить-то? Тема неизбежно сводится к "статика вс. динамика".

DG>>зачем нужен IQueryable при наличии макроса раскрывающего код linq2sql? лишняя сущность какая-то..

Z>обоснуй мысль у тебя какая-то не очивидная

iqueryable был введен только для того, чтобы методы сами "понимали" — им необходимо выполняться или склеиваться.
а также чтобы отметить, что where и т.д. принимают expression, а не делегат.


но
1) макрос и так уже принимает expression(ast)
2)если же замена идем внешним кодом, то такая пометка лишняя. и даже вредная, т.к. требуется писать два разных кода — один для IQueryable, а другой — для IEnumerable

например, непонятно зачем необходимо писать два варианта следующей функции, когда достаточно одного:

IEnumerable<Manager> TopManagers(this IEnumerable<Manager> managers)
{
  return managers.Where(manager=>manager.IsTopManager);
}

эта функция успешно может применяться и для работы с внутренним хранением, и при linq2sql.


Z>>>Объясни популярно. Какой смысл автоматом параллелить вызовы к БД.

DG>>есть такое слово "чтобы быстро работало"

Z>быстро но неправильно?

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


Z>>>Не будет работать вообще, тут одно соединение и одна транзакция.

DG>>зависит от условий задачи — требуется или нет единая транзакция.
DG>>допустим не требуется

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

ты даже не спросил какого-то типа db, а до сих пор талдычишь про одно соединение.

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

DG>эта функция успешно может применяться и для работы с внутренним хранением, и при linq2sql.

Вот только применяться она будет на клиенте, а та, что с IQuerable вероятнее всего уйдет в запрос к базе. Очень странно, что такие вещи приходится разжевывать. Зато в языке с макросами ты сможешь написать только одну и не дублировать код.

Впрочем мы ушли от темы, два разных макроса не будут биться над разбором линка, они будут применяться на уже разобраный linq превращенный во вполне стандартный method chain. В котором методы работы с базой и методы работы в памяти будут отличаться сигнатурой.

Z>>>>Не будет работать вообще, тут одно соединение и одна транзакция.

DG>>>зависит от условий задачи — требуется или нет единая транзакция.
DG>>>допустим не требуется

DG>ты даже не спросил какого-то типа db, а до сих пор талдычишь про одно соединение.

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

Макросы тут при чем, скажи на милость? Если ты это распаралелишь без макросов, эта проблема исчезнет?

Вот гипотетический код в который будет преобразован вызов твое гипотетического макроса, если ты его руками напишешь, тебе легче станет?

def (managers, cars) = Parrallel.Run(
      () => db.Managers.Where(manager=>manager.IsTopManager).ToArray(), 
      () => db.Cars.Where(car=>car.IsFree).ToArray()
);

НазначитьМашиныДляМенеджеров(managers, cars);

p.s. кстати, computation expressions делают именно подобное распараллеливание, причем более сложные примеры руками в код ты так просто не переведешь. например запустить еще один поток обрабатывющий managers после того, как их достали из базы, не дожидаясь доставания cars.

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

странно что нужно разжевывать, что функция с IEnumerable тоже может уйти как запрос к базе (и никаких проблем с этим нет)
мы до сих говорим про МП или про что-то другое?


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

Z>Макросы тут при чем, скажи на милость? Если ты это распаралелишь без макросов, эта проблема исчезнет?

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

и жаль, что вы эту проблему не видете, и не понимаете.

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

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

Z>>Нужные нам для работы структуры можем, иначе как мы с ними работаем? Пример про хештаблицы вообще не понял, ты их используешь их для хранения данных? Часто?

ВВ>Напрямую — нет. Но в "загримированном под статическую типизацию" виде — да, бывает. Вот, к примеру, работаешь с объектом через транспарент прокси — выглядит "типизрованно", но по сути — та же хэш-таблица.
Всё строго наоборот. Это не гримирование, а одно из двух:
1. Способ провести границу между статикой и динамикой. При проносе через эту границу динамика исчезает, позволяя нам в "чистой зоне" пользоваться всеми преимуществами статики. Пример: обратно Linq. В нём у нас есть риск расхождения таблиц с классами. Но как только мы пронесли Data row внутрь приложения, всё остальное становится статическим. Нам гарантирована типобезопасность всех производных запросов. Что гораздо, гораздо, гораздо лучше чем держать в "динамике" (то есть с неизвестными типами) вообще все запросы, а не только определения таблиц. Почему лучше — понятно? Поясняю: при, скажем, переименовании поля в таблице я могу нарваться на проблемы синхронности в Linq, точно так же, как и в динамике. Но в Linq я иду в исходник, переименовываю поле там, и автоматический рефакторинг гарантированно меняет мне это поле согласованно везде, где бы я к нему ни обращался. И неважно, использую ли я таблицу или некий запрос, построенный на её основе — всё автоматически останется согласованным. Даже если у меня нет теста на каждый из from Person where Age > _age select Name.

2. Способ "разгримировать" статику, которая была обёрнута в динамику. Ну, как пример — обратно, DLL. Информации о типах в DLL нету. Но это не означает, что я могу вызывать CreateFile с произвольными аргументами. Более стандартный пример: сериализация/десериализация. В теории, XML — чистая динамика. На практике, на обоих концах XML-based транспорта часто сидят статически типизированные инфраструктуры, которые обмениваются статически типизированными данными.
Или вот, те же куки. Кто мне их пишет? Да я сам же и пишу. Они были исходно статически типизированы, и мне естественно удобнее потреблять их обратно в статически же типизированном виде. У меня не стоит задачи прочитать произвольную куку, запиханную в веб сервер.

Во многих задачах "динамика" — это способ уйти от ответственности. Как, к примеру, проконтролировать в веб приложении корректность внутренних ссылок? Ответ динамики — "тестируйте, лемминги". Ответ статики — "давайте сделаем генератор внутренних ссылок, построенный на метаданных. Тогда статическая проверка позволит нам гарантировать отсутствие ссылок, которые не удастся потом обработать".
Двадцать лет задача считалась неразрешимой — и вдруг оп-ля! Как только мы начали искать способ ввести статическую типизацию в и так хорошо типизированные URL-и, как всё решилось в мгновение ока.

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

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

Хм. Простой тест: а type providers покрывают await/async?

Я, на всякий случай, напомню историю: изначально R#, а затем Nemerle, появились как ответ на вопрос "можно ли получить язык для дотнета, в котороом для реализации фич C# версии X+1 не надо переписывать компилятор"?
Как то: можно ли обойтись без встраивания foreach, using, lock? Без встраивания yield return? Без встраивания from, select, where, orderby? Без встраивания dynamic?

Основной бенефит даже не в том, чтобы не трогать компилятор — с точки зрения пользователя нет разницы, откуда взялся async.
Бенефит в том, чтобы одна команда могла заниматься dynamic, а другая команда параллельно и независимо могла заниматься async. Это позволяет масштабировать скорость разработки языка.

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

ВВ>"Уровня Немерла" — это какой? Чтобы переименование работало? Если в динамически-типизированном языке нет понятия "мутабельных переменных",

Тогда это не язык, а никому не нужная игрушка. Даже в хаскеле их аналог есть.