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

_>И как в лог созданный этим супер-методом попадут имя и входные параметры метода? Да хоть бы имя файла и номер строки в сорце? Через жутко тормозные стэк-фреймы?

имя и параметры через Expression можно передать. Для чего тебе номер строки ? Вы что там, простыни пишете как в старом добром C ? Допустим, с логированием все понятно, мне вот тоже не хватает _LINE_ или _FUNCTION_. Если не писать простыни, то получится чтото вроде

public void RemoteCall()
{
   Call(p => webService.Call(s), calling:()=>RemoteCall(s));
}

Прикинь, как круто ?

>Классически предлагают ещё пару вариантов, где последним идёт передача в супер-метод анонимного типа, с вытягиванием значений рефлексией. И все приседания ради того чтобы ограничения C# обойти, для одного лишь логгирования. И это для простецкой задачи которую на пальцах объяснить можно самому последнему джуниору, а сколько ещё задач посложнее...

Покажи что посложнее.

_>Самое главное что я хотел этим примером донести — что страхи перед DSL, это ерунда.

Интересно, а почему тогда приходят на собеседование уже не джуниоры, но имеющие проблемы с такой простой вещью как query comprehension ? Казалось бы, DSL нечего бояться, но результат на собеседованиях как то не в пользу даже простых конструкций вроде yield, не говоря о DSL вроде query comprehension

_>>И как в лог созданный этим супер-методом попадут имя и входные параметры метода? Да хоть бы имя файла и номер строки в сорце? Через жутко тормозные стэк-фреймы?
I>имя и параметры через Expression можно передать.
Ага, поштучно. Когда 30 методов и хотя-бы пара параметров, хоть раз где-нить да ошибутся.

I>Для чего тебе номер строки ? Вы что там, простыни пишете как в старом добром C ?
Есть такие страшные люди — математики. Они один файл открывают и в нём неделю пишут метод. Потом открывают второй, обзывают партиал классом, и пишут дальше... И это я не шутку шучу. В итоге ужас ситуации начинаешь осознавать, когда номер строки и номер ревизии важны, что б потом найти где ж оно так... а им всё нипочём, даже тормоза интеллисенса на больших файлах.

I> Прикинь, как круто ?
Круто оно да, но чувствуешь себя после таких вывертов словно на костылях на сноуборд полез

I>Покажи что посложнее.
Зачем сложнее, когда даже простые вещи на C# нормально не сделать? Например примитивы синхронизации readlock/writelock

Автор: hi_octane
Дата: 01.11.10

. Опять-таки — тупо использовать любой джуниор сможет. Более того, можно компилятор заставить ещё и ошибку компиляции кидать при попытке обращения без лока к методу который лока требует. Нам правда не надобилось, но джуниоры они же разные бывают.

I>Интересно, а почему тогда приходят на собеседование уже не джуниоры, но имеющие проблемы с такой простой вещью как query comprehension ? Казалось бы, DSL нечего бояться, но результат на собеседованиях как то не в пользу даже простых конструкций вроде yield, не говоря о DSL вроде query comprehension
Ты описываешь драматизм ситуации так, словно всё пропало и C#3 не нужен. Ко мне тоже всякие люди на собеседования попадают, но лучше я ещё недельку подожду, чем потом буду человеку жизнь усложнять а себе нервы портить...

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

_>Зачем сложнее, когда даже простые вещи на C# нормально не сделать? Например примитивы синхронизации readlock/writelock

Автор: hi_octane
Дата: 01.11.10

. Опять-таки — тупо использовать любой джуниор сможет. Более того, можно компилятор заставить ещё и ошибку компиляции кидать при попытке обращения без лока к методу который лока требует. Нам правда не надобилось, но джуниоры они же разные бывают.

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

_>Ты описываешь драматизм ситуации так, словно всё пропало и C#3 не нужен.

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

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

Хорошего дотнетчика уже месяц ищем

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

R>>Давай так. Выделим тезис и приведём аргументы, а то неохота время терять, я не понимаю, что ты хочешь доказать.
R>>Тебе объяснить выгоды метапрограммирования? Как я понял ты утверждаешь что оно не нужно, в частности потому, что тебе не найти людей и вообще это очень сложно.

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

О, вы хотите известных банальностей? Щас сотворим.

Итак, индифферентно к используемым парадигмам, "идеальный" подход к разработке выглядит примерно так:

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

Любые модели строятся на абстракциях, то бишь допущениях той или иной степени подробности.

Абстракции обычно декомпозируют до достижения приемлемого (обозримого) уровня сложности. Идеальный вариант, когда абстракции удается описать предельно близко "по размерам" к понятиям предметной области. В этом случае уровень абстрагирования будет близок к уровню моделирования. (Т.е. сможем обойтись без ненужных прикладных слоев абстракции)

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

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

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

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

Вполне потянет на мейнстрим, не надо даже намного более высокого уровня программистов. Ведь есть же разделение труда, макросописателей должно быть на порядок-другой меньше, чем макросопотребителей. Учитывая, что в современном мейнстриме наибольший объем информации создает не столько сам язык, сколько его окружение/библиотеки и т.д., можно смело эти синтаксисы и DSL-и относить к такой же библиотечной части. Переварят. Даже понравится.

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

VD>Ну, это ты гонишь по полной программе. Почти все коммерческие компиляторы и средства рефакторинга имеют рукописные парсеры.
VD>Дело в том, что 99% генераторов парсеров не обеспечивают надлежащего качества. Скажем сделать парсер C# силами АНТЛР можно, но велика вероятность получить тормоз. А силами ley-я или Coco/R-а сделать его без приседаний (рукописного кода) вообще нельзя (LALR(1)/LL(1) не позволяет).

А можно пруфлинк на это дело? Или хотя бы список компиляторов, в которых используется рукописные парсеры

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

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

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

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

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

I>>Значит Немерле так и останется упражнением для мозга.

VD>Поживем, увидим.

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

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

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

Спасибо К.О.

V>Ваши предложения?
V>Скажу как плюсовик со стажем, что даже такая "мелочь" как перегруз операторов очень облегчает жизнь. Еще посахарить не помешает.

То есть Немерли таки ориентирован на самый что ни есть мейнстрим ?

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

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

Типичный девелопер в этом мейнстриме с горем пополам C# осваивает, и то не в курсе yield, имеет проблемы с лямбдам и linq может только по книге рецептов а рекурсия для него это нечто страшное.

И вот этого девелопера ты хочешь посадить 1. за немерле 2. использовать макросы

Вопрос нумер один — за счет каких чудес этот типичный девелопер освоит немерле лучше, чем C# ?

Вопрос нумер два — за счет чего ожидается профит, если linq это уже выше понимания этого типичного девелопера ?

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

I>Типичный девелопер в этом мейнстриме с горем пополам C# осваивает, и то не в курсе yield, имеет проблемы с лямбдам и linq может только по книге рецептов а рекурсия для него это нечто страшное.

Это нетипичный девелопер. В Питере мне не встречался дотнетчик, который с легкостью бы не пользовался линком. Я преподавал на третьем курсе C# и F#. К концу семестра дети без проблем осваивали линк, дженерики, методы расширения и т.д. Многие из них в качестве языка для написания итоговой лабы выбирали F# и использовали в ней на полную катушку функциональный стиль. И это после всего лишь 3,5 месяцев лекций по 2 часа в неделю.

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

Здравствуйте, Anton V. Kolotaev, Вы писали:

I>>Типичный девелопер в этом мейнстриме с горем пополам C# осваивает, и то не в курсе yield, имеет проблемы с лямбдам и linq может только по книге рецептов а рекурсия для него это нечто страшное.

AVK>Это нетипичный девелопер. В Питере мне не встречался дотнетчик, который с легкостью бы не пользовался линком.

Известно, вся Россия это Москва и Питер Но вообще говоря я не из России.

AVK>Так что может быть стоит предлагать более конкурентоспособную зарплату и типичный программист изменит свое лицо?

Ага, дать три московских ЗП и вместе с этой ЗП 9 из 10 программистам вольётся знание функциональщины.

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

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

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

_>

_>[WebServiceCall] //<- вот этот аттрибутик
_>public RemoteCall(s : string) : string
_>{
_>  webService.Call(s);
_>}

_>//превращал минмализм который выше во что-то с логгированием и таймингом вида:
_>public RemoteCall(s : string) : string
_>{
_>  def ms = SharedTimer.Milliseconds;

_>  try
_>  {
_>    def result = webService.Call(s);
    
_>    def elapsed = SharedTimer.Milliseconds - ms;
_>    when(elapsed > 5)
_>      Log("RemoteCall($s) тупил $elapsed мс.");

_>    result;
_>  }
_>  catch
_>  {
_>    ex is Exception => { Log("RemoteCall($s) обломался с ошибкой $ex за $(SharedTimer.Milliseconds - ms) мс."); throw; }
_>  }
_>}

_>

_>И получалось что людям надо писать только вызов вебсервиса, а этот вызов уже сам в try/catch обернётся и залоггируется если надо. Причём параметры вызова подставит без ошибок. Ну и что сложнее использовать, и где можно больше ошибок нахреначить? А главное — потом макрос можно допилить один раз и все методы по-новому работать будут, а рукопашный код в 30 местах заколдобишься что допиливать, что потом проверять.

Ух ты, макросы, это, оказывается, круто!

time tm = ...
timer action onOk onError = ...

webServiceCall s action = time $ timer action onOk onError where
    onOk tm = when (tm > 0.005) $
        putStrLn $ s ++ " тупил " ++ show (floor $ 1000 * tm) ++ " мс."
    onError e tm = putStrLn $ s ++ " обломался с " ++ show e ++ " за " ++ show (floor $ 1000 * tm) ++ " мс."

remoteCall s = webServiceCall ("RemoteCall(" ++ s ++ ")") (callWebService s)

test = remoteCall "blabla"

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

AVK>>Это нетипичный девелопер. В Питере мне не встречался дотнетчик, который с легкостью бы не пользовался линком.

I>Известно, вся Россия это Москва и Питер Но вообще говоря я не из России.

Ok. Тогда резюме следующее: Немерл остается для Питера и Москвы, VB — для остальной России (утрирую, но суть ясна: если в глухой деревушке нет немерлистов, это еще не значит, что он сможет сгодиться где-то еще). Вообще последнее время довольно регулярно выплывают вакансии на F# и Scala в Лондоне и Штатах.

AVK>>Так что может быть стоит предлагать более конкурентоспособную зарплату и типичный программист изменит свое лицо?

I>Ага, дать три московских ЗП и вместе с этой ЗП 9 из 10 программистам вольётся знание функциональщины.

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

Здравствуйте, Anton V. Kolotaev, Вы писали:

AVK>Ok. Тогда резюме следующее: Немерл остается для Питера и Москвы, VB — для остальной России (утрирую, но суть ясна: если в глухой деревушке нет немерлистов, это еще не значит, что он сможет сгодиться где-то еще). Вообще последнее время довольно регулярно выплывают вакансии на F# и Scala в Лондоне и Штатах.

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

AVK>>>Так что может быть стоит предлагать более конкурентоспособную зарплату и типичный программист изменит свое лицо?
I>>Ага, дать три московских ЗП и вместе с этой ЗП 9 из 10 программистам вольётся знание функциональщины.

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

Для _единичных_ проектов так и делается, спасибо К.О.

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

I>Т.е. мейнстрим резко ограничился Москвой и Питером, т.е. городами где с кадрами никогда никаких проблем не возникает.

Если мы понимаем под мейнстримом то, на чем пишет большинство, а большинство — оно в Москве и в Питере (возможно, еще в нескольких городах), то — да.

У меня нет цифр по России, но во Франции число программистов в Парижском регионе и вне него составляет примерно 10/1, так что во Франции мейнстрим можно смело ограничивать Парижским регионом.

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

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

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

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

VD>>Ну, это ты гонишь по полной программе. Почти все коммерческие компиляторы и средства рефакторинга имеют рукописные парсеры.
VD>>Дело в том, что 99% генераторов парсеров не обеспечивают надлежащего качества. Скажем сделать парсер C# силами АНТЛР можно, но велика вероятность получить тормоз. А силами ley-я или Coco/R-а сделать его без приседаний (рукописного кода) вообще нельзя (LALR(1)/LL(1) не позволяет).

AD>А можно пруфлинк на это дело?

На какое из них?

AD>Или хотя бы список компиляторов, в которых используется рукописные парсеры

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

Если интересно можешь найти любую грамматику C#-а к Coco/R-у и поглядель сколько там приседаний вручную делается. Размер программных заглядываний вперед приближается к размеру грамматики.

С АНТЛР-ом дела обстаят лучше, так как есть синтаксические предикаты. Но он тормоз.

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

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

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

Вот почитай для общего развития http://www.rsdn.ru/forum/flame.comp/4159696.aspx

Автор: vdimas
Дата: 16.02.11

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

VD>На какое из них?

На вот эти:
VD> ...Почти все коммерческие компиляторы и средства рефакторинга имеют рукописные парсеры...
VD> ... 99% генераторов парсеров не обеспечивают надлежащего качества ...

Честно говоря, не верится

Хотя... Мне тут по аське разжевали эту тему. Похоже, что это действительно так

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

AD>На вот эти:
VD>> ...Почти все коммерческие компиляторы и средства рефакторинга имеют рукописные парсеры...
VD>> ... 99% генераторов парсеров не обеспечивают надлежащего качества ...

AD>Честно говоря, не верится

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

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