Re[18]: Веб и динамика? Веб и статика+метапрограммирование. - Философия программирования

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

DG>позиционировалось, что немерле МП-задачи позволит решать за пару копеек.

Кстати — это очередная лож. МП позволят решать сложные задачи. Даже задачи которые не решаются традиционными методами. Но я никогда не говорил, что МП — это просто. Если бы это было так, то мы имели бы совсем другой уровень разработки ПО, на сегодня.

Я утверждал, только лишь, что использование макросов уровня макросов немерла значительно упрощает использование МП. Кроме того оно снимает многие проблемы использования делая использование готовых МП-решений прикладными программистами очень простым. Но использовать мета-код != писать мета-код.

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

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

Немерл 1.0 уже рвет все конкурирующие технологии как Тузик грелку. А, надеюсь, Немерл 2.0 будет еще мощнее, и при этом, проще в использовании.

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

VD>Без макросов правда, но зато пример демонстрирует комбинаторные возможности немерла. Думаю, не ты один не понимаешь, что подобное возможно. Так что будет хорошим примером для новичков. Да и C#-щикам полезным будет. На шарпе конечно не так лаконично получится, но на нем этот код так же можно повторить.

мой сотрудник это сделал за 2 часа на C#
что я считаю верхом расточительности для задачи такого плана

DG>>преобразование фильтрующего-выражение из текстовой формы в код, это копеечная задача.
DG>>и это именно МП: есть программа в текстовом виде, есть программа в виде C# — одну программу надо преобразовать в другую.

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

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

DG>>при чем проблема, что основные временные затраты уходят на борьбу с кодом:
DG>>то, что order-by выражется четырьмя методами.

VD>Ты недавно утверждал, что задача вообще не решается средствами линка.

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

а вот и точная цитата

DG>.net-ный linq очень плохо помогает при условных запросах.

что более чем верно.
потому что преобразование из текстового представления в текстовый sql — делается за 20 минут, а не за 2 часа.

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

DG>стоило тогда еще сделать группы or/and

Твой формат этого не позволяет. Да и делать там особо не чего. Пару строк подправить придется.
Но я тебе и так, по расчетам gandjustas, за сегодня на 1000 баксов кода наколотил.
Я на тебя работать не нанимался.
Плати и я тебе сделаю полноценное решение. Могу даже автоматическую генерацию (на макросах) этого дела для произвольно заданного типа тебе налабать. Берусь все это сделать за пару дней и ту же 1000 баксов (как gandjustas). Демпинг!

VD>>Интересно как ты теперь будешь выкручиваться? Просто сделаешь вид, что не заметил ответ или найдешь фатальный недостаток?

DG>тем, что я считаю, что это должно делаться за 10 минут

Ну, так являются твои слова о том, что "linq очень плохо помогает при условных запросах" ошибочными?
А слова — "даже изменение порядка сортировки делается очень геморройно"? Не уж то 13 строк кода помещенные в метод — это такой нестерпимый геморрой?

DG>по крайней мере псевдокод под эту задачу пишется минуты за 3

Я тебе и написал прототип решения за 10 минут. А за 3 минуты ты даже это сообщение не напишешь. Это очередной треп с твоей стороны.

ЗЫ

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

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

      using (var db = new StatDataContext(Settings.Current.ConnectionString))
      {
        db.ObjectTrackingEnabled = false;

        var stopwatch = new System.Diagnostics.Stopwatch();
        stopwatch.Start();
        var board1 = db.Boards.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c1-ac72-433408000000"));
        Console.WriteLine(stopwatch.Elapsed);

        stopwatch.Reset();
        stopwatch.Start();
        var board4 = db.Boards.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c1-ac73-433408000000"));
        Console.WriteLine(stopwatch.Elapsed);

        stopwatch.Reset();
        stopwatch.Start();
        var thread1 = db.Threads.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c1-ac73-433408000000"));
        Console.WriteLine(stopwatch.Elapsed);

        stopwatch.Reset();
        stopwatch.Start();
        var thread2 = db.Threads.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c2-ac73-433408000000"));
        Console.WriteLine(stopwatch.Elapsed);

        stopwatch.Reset();
        stopwatch.Start();
        var thread4 = db.Documents.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c1-ac73-433408000000"));
        Console.WriteLine(stopwatch.Elapsed);

        stopwatch.Reset();
        stopwatch.Start();
        var thread5 = db.Documents.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c2-ac73-433408000000"));
        Console.WriteLine(stopwatch.Elapsed);

      }

00:00:00.0507296
00:00:00.0030784
00:00:00.0234894
00:00:00.0029796
00:00:00.0293127
00:00:00.0026732

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

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

с преобразованием синхронного кода в cps никакой проблемы нет.
идея решения даже в вики про cps написана.

развернутое описание как синхронный код отображается в cps я показывал в диалоге с Sinclair-ем в одной из соседних веток
http://www.rsdn.ru/forum/philosophy/4006735.flat.aspx

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

зы
C#-ные yield-ы — это кстати преобразование синхронного кода в примитивный cps

VD> А слова — "даже изменение порядка сортировки делается очень геморройно"? Не уж то 13 строк кода помещенные в метод — это такой нестерпимый геморрой?

конечно. чем хороши 13 строк, если тоже самое при улучшенном яп можно сделать за полстроки?

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

G>>

G>>var prop = Expression.Property(p, name)
G>>

DG>в общем виде — лучше PropertyOrField

DG>>>преобразовать строку в значение типа данного поля,
G>>Одна строка
G>>

G>>var value = Expression.Constant(Convert.ChangeType(s, p.Type));
G>>

DG>


DG>      foreach (var pair in new[] 
DG>      {
DG>       //основные типы используемые при хранении данных
DG>        new {type = typeof(string), value = "x"},
DG>        new {type = typeof(int), value = "123"},
DG>        new {type = typeof(double), value = "12.34"},
DG>        new {type = typeof(double), value = "12,34"},
DG>        new {type = typeof(bool), value = "true"},
DG>        new {type= typeof(DateTime), value = "12.10.2010"},
DG>        new {type = typeof(Guid), value = Guid.NewGuid().ToString()},
DG>        new {type = typeof(TimeSpan), value = "12:11"}
DG>      })
DG>      {
DG>        try
DG>        {
DG>          Console.WriteLine(Convert.ChangeType(pair.value, pair.type));
DG>        }
DG>        catch (Exception exc)
DG>        {
DG>          Console.WriteLine("error");
DG>        }
DG>      }

DG>

DG>

DG>x
DG>123
DG>error
DG>12,34
DG>True
DG>12.10.2010 0:00:00
DG>error
DG>error
DG>

Вместо Convert.ChangeType будет еще один лукап с методами конвертирования.

G>>В итоге 5 строк кода + лукап таблица + 4-5 строк для инициализации.

DG>в реальности там ближе к строкам 100, если поддержать все нюансы.
DG>но согласен, решение будет именно таким.
Это много? Два часа работы если с нуля писать.

DG>но есть следующие моменты:
DG>1. сгенерить текстовый sql заняло бы меньше кода
Linq позволяет генерить запросы многими другими способами, руками рукопашной генерацией sql такого не сделаешь. Я уверен что тае в твоем приложении, из которого пример, linq для запросов к базе применяется гораздо шире, чем ты тут описал.

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

DG>3. большой разрыв между обычным кодом, и кодом генеренным. достаточно сложно переходить от одного к другому и обратно, использовать совместно и т.д.
Это ты что имеешь ввиду? Обычно ручное собирание expression прячется внутри функций, которые потом типизировано вызываются и отдают типизированный результат.

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

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

DG>с преобразованием синхронного кода в cps никакой проблемы нет.
DG>идея решения даже в вики про cps написана.

DG>развернутое описание как синхронный код отображается в cps я показывал в диалоге с Sinclair-ем в одной из соседних веток
DG>http://www.rsdn.ru/forum/philosophy/4006735.flat.aspx

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

DG>зы
DG>C#-ные yield-ы — это кстати преобразование синхронного кода в примитивный cps

Это очевидно. Я этот момент для себя открыл довольно давно. От этого факта, до автоматического распараллеливания как до луны пешком.

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

DG>

DG>00:00:00.0507296
DG>00:00:00.0030784
DG>00:00:00.0234894
DG>00:00:00.0029796
DG>00:00:00.0293127
DG>00:00:00.0026732

Вот это совсем другое дело.

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

Четко видно, что linq (а может быть и RDBMS тоже) тратит время на компиляцию запроса. В первом вызове, вероятно, дополнительное время отжирается на загрузку метаданных.

Никаких проблем с 20 запросами в секунду нет, хотя ты писал:

.net-ный linq очень плохо помогает при условных запросах.
когда конечный запрос собирается из кусочков на основе ввода пользователя (например, по каким полям фильтровать и сортировать)

зы
еще у нескомпилированного linq на каждый запрос куда-то уходит ровно 50мс, соответственно больше 20 запросов в секунду не сделать.

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

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

VD>Справидливости ради надо заметить, что есть ряд завсегдатых РСДН-а которые ни при каких условиях не признают свою неправоту. Я раньше тоже таким был, но понял, что это глупо. Если доводы оппонента корректы и они ломают твою логику, значит у тебя не верные посылки. И их нужно менять. Иначе можно верить в разные мифы.

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

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

Z>Это очевидно. Я этот момент для себя открыл довольно давно. От этого факта, до автоматического распараллеливания как до луны пешком.

что самое интересное — утверждение про автоматическое распараллеливание ты сам придумал
я этого не говорил.

зы
вернее, говорил, но совсем по другому поводу.

G> Это много? Два часа работы если с нуля писать.

много

одним из индикаторов выразительности языка является:
кол-во требуемых для изменения бит(символов) в коде на кол-во измененных бит информации в исходной постановке задачи.

см. пример ниже

DG>>3. большой разрыв между обычным кодом, и кодом генеренным. достаточно сложно переходить от одного к другому и обратно, использовать совместно и т.д.
G>Это ты что имеешь ввиду? Обычно ручное собирание expression прячется внутри функций, которые потом типизировано вызываются и отдают типизированный результат.

был исходный сложный запрос

var items = db.Items.Join(..).Where(pair.Item.Name == name && bla-bla || bla-bla-bla).ToArray();

дальше в ТЗ добавилось изменение:
пользователь может указать, что сравнение может быть не полное, а по начальному совпадению (starts)
и вот теперь чтобы встроить условную замену '==' на 'starts' — необходимо достаточно много перелопатить.

а в идеале это хотелось записать как:

var op = bla-bla ? == : starts;
var items = db.Items.Join(..).Where(pair.Item.Name op name && bla-bla || bla-bla-bla).ToArray();

с привлечением может доп. синтаксиса, но смысл именно такой.

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

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

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

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

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

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

А та, да, согласен.

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

G>> Это много? Два часа работы если с нуля писать.
DG>много
Это переиспользуемый код. Достаточно будет поменять лукапные таблицы для другой задачи.

DG>одним из индикаторов выразительности языка является:
DG>кол-во требуемых для изменения бит(символов) в коде на кол-во измененных бит информации в исходной постановке задачи.
DG>см. пример ниже

DG>>>3. большой разрыв между обычным кодом, и кодом генеренным. достаточно сложно переходить от одного к другому и обратно, использовать совместно и т.д.
G>>Это ты что имеешь ввиду? Обычно ручное собирание expression прячется внутри функций, которые потом типизировано вызываются и отдают типизированный результат.

DG>был исходный сложный запрос
DG>

DG>var items = db.Items.Join(..).Where(pair.Item.Name == name && bla-bla || bla-bla-bla).ToArray();
DG>

DG>дальше в ТЗ добавилось изменение:
DG>пользователь может указать, что сравнение может быть не полное, а по начальному совпадению (starts)
DG>и вот теперь чтобы встроить условную замену '==' на 'starts' — необходимо достаточно много перелопатить.

DG>а в идеале это хотелось записать как:
DG>

DG>var op = bla-bla ? == : starts;
DG>var items = db.Items.Join(..).Where(pair.Item.Name op name && bla-bla || bla-bla-bla).ToArray();
DG>

DG>с привлечением может доп. синтаксиса, но смысл именно такой.

http://gandjustas.blogspot.com/2010/06/expression-tree.html
Теперь переделывать не надо будет ничего. И никакого дополнительного синтаксиса, пара вызовов функций и все.

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

DG>тем, что я считаю, что это должно делаться за 10 минут
DG>по крайней мере псевдокод под эту задачу пишется минуты за 3

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

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

DG>конечно. чем хороши 13 строк, если тоже самое при улучшенном яп можно сделать за полстроки?

Приведи свое решение, сравним.

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

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

DG>

DG>      using (var db = new StatDataContext(Settings.Current.ConnectionString))
DG>      {
DG>        db.ObjectTrackingEnabled = false;

DG>        var stopwatch = new System.Diagnostics.Stopwatch();
DG>        stopwatch.Start();
DG>        var board1 = db.Boards.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c1-ac72-433408000000"));
DG>        Console.WriteLine(stopwatch.Elapsed);

DG>        stopwatch.Reset();
DG>        stopwatch.Start();
DG>        var board4 = db.Boards.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c1-ac73-433408000000"));
DG>        Console.WriteLine(stopwatch.Elapsed);

DG>        stopwatch.Reset();
DG>        stopwatch.Start();
DG>        var thread1 = db.Threads.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c1-ac73-433408000000"));
DG>        Console.WriteLine(stopwatch.Elapsed);

DG>        stopwatch.Reset();
DG>        stopwatch.Start();
DG>        var thread2 = db.Threads.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c2-ac73-433408000000"));
DG>        Console.WriteLine(stopwatch.Elapsed);

DG>        stopwatch.Reset();
DG>        stopwatch.Start();
DG>        var thread4 = db.Documents.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c1-ac73-433408000000"));
DG>        Console.WriteLine(stopwatch.Elapsed);

DG>        stopwatch.Reset();
DG>        stopwatch.Start();
DG>        var thread5 = db.Documents.FirstOrDefault(_board => _board.Id == new Guid("8a8d7480-af2b-46c2-ac73-433408000000"));
DG>        Console.WriteLine(stopwatch.Elapsed);

DG>      }
DG>

DG>

DG>00:00:00.0507296
DG>00:00:00.0030784
DG>00:00:00.0234894
DG>00:00:00.0029796
DG>00:00:00.0293127
DG>00:00:00.0026732

DG>четко видно, что первый вызов одного вида долгий, а последующий такой же (хотя и с другим id) быстрый.
А приложи-ка к этому trace с SQL Server. Ты меряешь время выполнения всего запроса, без учета компиляции запроса на SQL Server, считывания данных с диска итп.

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	24.12.10 20:48
Оценка:

От:	VladD2	www.nemerle.org
Дата:	24.12.10 20:50
Оценка:

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	24.12.10 21:29
Оценка:	-1

От:	VladD2	www.nemerle.org
Дата:	24.12.10 21:29
Оценка:

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	24.12.10 22:06
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	25.12.10 01:48
Оценка: