Здравствуйте, hi_octane, Вы писали:
I>>RX не годится ? _>Ну когда мы заканчивали проект — Rx ещё не было Но даже если б и был — непредсказуемо тормозявый он. Причём его тормозявость — практически утверждена официально. А у нас жажда скорости прописана в ТЗ.
Годная отмазка
_>>>4) Задачи требующие своего DSL. I>>Покажи пример, пожалуйста. _>У клиента скрипт, скрипт он корректирует сам как ему захочется. Там по большей части Nemerle код, но формулы описаны чистой математикой, вроде SUM x * p1 * q1 DIV MAX x >= SUM y + a DISTINCT y = SUM b. И это не вызовы функций, эту запись мы вытягиваем как есть из исходника, немного правим, подставляем вместо параметров матрицы и скармливаем решателю вроде матлаба.
Годится
_>>>5) Логгирование, замеры времени, особенно если проект в релизе, его как в C# не делай, всегда фигня будет получаться I>>Это инструментирование в рантайме или что ты имел ввиду ? _>Да. Есть требование для некоторых функций уложиться в сколько сказали миллисекунд или здохнуть. Эдакий soft realtime. На этих функциях стоят аттрибутики, которые на самом деле макросы, которые перефигачивают код так, что если в релизе функция не вложилась в заданное число миллисекунд — сразу всю ситуацию в лог а прогу остановить. А если уложилась но подобралась к 90%, то просто в лог все операции с временами, для анализа. И чудо, у нас без профайлера (потому что его к реальной работающей проге просто не подключишь) с первых релизов есть гистограммы средней и пиковой нагрузки, и всё без замусоривания кода ручками, впихивания Stopwatch в try и Log в finally.
Сильно !
_>>>6) Задачи, которые на C# принято считать требующими кодогенераторов или отдельных программ. У нас например в процессе компиляции макрос лезет по сети и вытягивает оттуда JavaScript, а потом лезет по всему проекту, и в нужных местах корректирует код (не какие-то генерённые файлы обновляет, а разбирает и корректирует писанный людьми код), в соответствии с тем JavaScript. Чтобы такое повторить на C# — убиться надо. I>>А что за задачу вы решали таким образом ? _>Связь с монструозной прогой на стороне клиента.
Шота мне кажется вы изобрели уже давно известную технологию Какого характера изменения что вносятся скриптом ? Почему нельзя это заменить на инжекцию депенденсов ?
_>Вот наглядный пример — реальный вопрос
Мдя, я предполагал, что будет короче и понятней, но не настолько же! Шикарно и спасибо
Да, сильно.
_>И это одна обычная задача. Два экрана на C# и один на Nemerle. Нужно ли говорить что на большом проекте разница уже не просто заметна, но начинает реально влиять не только на сроки, но и на реализуемость фич вообще?
Сильно спорно. По моему разумению основное время уходит на всякие косяки и нестыковки технологий. Скажем ORM сильно чаще является узким местом, нежели язык C#. Или тот же WCF.
Здравствуйте, hi_octane, Вы писали:
_>Тут бесполезно к чему-то цепляться. Есть проекты где цена ошибки стремится к стоимости времени её фикса. Например сайты-визитки. Там хоть пол-проекта разломай а клиенту зарелись билд который вообще от другого проекта — ну будет разговор вида "Чё там такое, вообще какая хрень! Посмотрите!" и всё. Там разработчики сами релизят то что у них на винчестере лежало, и это правильное решение.
Здравствуйте, Аноним, Вы писали:
А> А не разумнее ли будет сам штатный парсер на PEG переписать? Тогда и макросы проще станут, учитывая врожденную расширяемость PEG-ов.
В Н2 так и задумывается. Только вот это приведет к большому количеству изменений, так что сделать это эволюционным путем не удастся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Darooma, Вы писали:
D>В чем C# уступает (если, конечно, уступает) Nemerle? Что можно сделать Nemerle легче, чем на C#? D>Есть ли такие задачи, для которых алгоритм на Nemerle будет работать быстрее, чем на C#?
Отвечу в обратном порядке. Технически на C# всегда можно написать код который будет соответствовать по скорости скорости аналогичного кода на Nemerle. Это проистекает из того факта, что оба языка генерируют приблизительно похожий IL и оба примерно равны по уровню. Иногда на C# можно даже добиться более высокой скорости, так как в нем есть unsafe и goto. Но это скорее чисто гипотетическое преимущество.
С другой стороны Nemerle позволяет брать интеллектом. Часто код получается медленее не из-за того, что используемый язык не позволяет написать его быстрее, а потому, что код работающий быстрее сложнее писать и поддерживать, так как за абстракции приходится платить.
Так вот Nemerle позволяет решать задачи методом DSL-изации. Мы можем описать весьма декларативное описание задачи и сгенерировать реализацию на макросах. Так вот код генерируемый макросами может плевать на абстракции и делать весьма сомнительные (в случае если этот код пишется вручную) оптимизации и использовать весьма низкоуровневую технику. Это позволяет получать очень высокую скорость исполнения конечного кода и при этом не только не только не жертвовать абстракциями, но наоборот повышать уровень абстракции и декларативность решения. Отличный примером является макрос PegGrammar, который описывает грамматику в полностью декларативной манере, более удобен чем большинство генераторов парсеров, но при этом способен генерировать весьма производительный код обгоняющий многие рукописные парсеры.
D>В чем C# уступает (если, конечно, уступает) Nemerle? Что можно сделать Nemerle легче, чем на C#?
В уровне предоставляемых абстракций. На Nemerle можно писать более высокоуровневый код. Этому способствуют две вещи.
1. В язык встроены возможности отсутствующие в C#. Самой заметной возможностью несомненно является наличие в Nemerle вариантных типов (алгебраических типов данных) и сопоставления с образцом. Но кроме этого есть куча более мелких полезняшек, многие из которых сделаны с помощью макросов.
2. Nemerle поддерживает макросы. Макросы позволяют решать проблемы с применением DSL-ей и собственного расширения зыка новыми конструкциями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
_>>Тут бесполезно к чему-то цепляться. Есть проекты где цена ошибки стремится к стоимости времени её фикса. Например сайты-визитки. Там хоть пол-проекта разломай а клиенту зарелись билд который вообще от другого проекта — ну будет разговор вида "Чё там такое, вообще какая хрень! Посмотрите!" и всё. Там разработчики сами релизят то что у них на винчестере лежало, и это правильное решение.
I>Вы что, CVS используете или VSS какой
Можно узнать, с чего сделан такой вывод?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
_>>2) Многопоточность. После того как привыкнешь писать в immutable стиле и накидаешь основные примитивы макросами — C# вообще отдыхает. У нас к концу проекта основных примитивов многопоточности набралось штук наверное 20. В C# — lock в зубы, и остальное выписывай ручками в кренделя try/finally.
I>RX не годится ?
Если бы он годился бы для всех случаев, то в MS не стали бы в срочном порядке "изобретать" async/await и прикручивать его к C#.
_>>11) Генерировать что-то по коду проекта в процессе компиляции. Например javascript или базу данных. В C# БД генерировать умеет только наверное DevExpress XPO, и то через рефлексию и по рабочей программе а не во время компиляции. И со всякими ограничениями. В Nemerle можно в генерированную БД из бакапа например тестовые данные сразу вытягивать, если билд тестовый.
I>tt чем не подходит ?
Под "tt" ты T4 — генератор текста, имеешь в виду?
Тем же чем RX. Не является удовлетворительным решением для многих случаев.
Сравнивать макросы с текстовым генератором — это все равно что сравнивать какой-нить BMW X5 с Ford T. Тоже конечно машина, но вот ездить на ней как-то не очень удобно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
_>>>Тут бесполезно к чему-то цепляться. Есть проекты где цена ошибки стремится к стоимости времени её фикса. Например сайты-визитки. Там хоть пол-проекта разломай а клиенту зарелись билд который вообще от другого проекта — ну будет разговор вида "Чё там такое, вообще какая хрень! Посмотрите!" и всё. Там разработчики сами релизят то что у них на винчестере лежало, и это правильное решение.
I>>Вы что, CVS используете или VSS какой
VD>Можно узнать, с чего сделан такой вывод?
"сутки простоя какой-нить большой команды из-за того что кто-то сломал всё совсем уже могут выйти очень дорого"
"Там разработчики сами релизят то что у них на винчестере лежало"
Не ясно, на что уходит неделя, если обычно релиз выкатывается за пару часов с документацией и прочей дрянью
Здравствуйте, VladD2, Вы писали:
I>>RX не годится ?
VD>Если бы он годился бы для всех случаев, то в MS не стали бы в срочном порядке "изобретать" async/await и прикручивать его к C#.
Хорошо, что не все немерлесты растеряли способности к адекватным объяснениям.
I>>tt чем не подходит ?
VD>Под "tt" ты T4 — генератор текста, имеешь в виду? VD>Тем же чем RX. Не является удовлетворительным решением для многих случаев.
Такой ответ я и сам могу придумать. Меня интересуют конкретные подробности, а не очередной лозунг.
>сравнивать какой-нить BMW X5 с Ford T. Тоже конечно машина, но вот ездить на ней как-то не очень удобно
Неужели на Немерле нельзя написать более толковый генератор тавтологий ?
Здравствуйте, Ikemefula, Вы писали:
VD>>Под "tt" ты T4 — генератор текста, имеешь в виду? VD>>Тем же чем RX. Не является удовлетворительным решением для многих случаев. I>Такой ответ я и сам могу придумать. Меня интересуют конкретные подробности, а не очередной лозунг.
Конкретные подробности проистекают из того факта, что T4 — это precompile time генерация кода, а макросы compile time. Разницу нужно объяснять?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
I>>Не ясно, на что уходит неделя, если обычно релиз выкатывается за пару часов с документацией и прочей дрянью
IT>Не ясно, на что уходит пару часов, если обычно релиз выкатывается за пару минут нажатием одной кнопки
Основное время уходит на всякие активности которые не автоматизируются. Например тфс не умеет перезапускать сам себя и продолжать билд. Баги в трекере нужно просматривать. Тесты могут выявить минорные баги, которые нужно просто добавить в релизноты и тд и тд. Тесты могут дать сбой и тогда нужно подфиксить, смерджить и тд. Впн может отвалиться во время теста. Как правило, на все это уходит в среднем два часа. Если всё идеально — то минуты. Потому мне сильно интересно, на что уходит неделя.
Здравствуйте, Ikemefula, Вы писали:
_>>И это одна обычная задача. Два экрана на C# и один на Nemerle. Нужно ли говорить что на большом проекте разница уже не просто заметна, но начинает реально влиять не только на сроки, но и на реализуемость фич вообще?
I>Сильно спорно. По моему разумению основное время уходит на всякие косяки и нестыковки технологий. Скажем ORM сильно чаще является узким местом, нежели язык C#. Или тот же WCF.
Если рассматривать голый N, так в нем кроме match вообще ничего нет. Архитектура у него такая. Просто на добавление наворотов, которые появляются в других языках тратится значительно меньше времени. Тот же async/await, code contrats, computation expression. В общем предложи-найди фичу, которая есть в других языках — тебе бойцы ее быстро прикрутят.
Здравствуйте, IT, Вы писали:
VD>>>Под "tt" ты T4 — генератор текста, имеешь в виду? VD>>>Тем же чем RX. Не является удовлетворительным решением для многих случаев. I>>Такой ответ я и сам могу придумать. Меня интересуют конкретные подробности, а не очередной лозунг.
IT>Конкретные подробности проистекают из того факта, что T4 — это precompile time генерация кода, а макросы compile time. Разницу нужно объяснять?
Конечно. Желательно на конкретной задаче. Калькулятор оставь Владу
Здравствуйте, alvas, Вы писали:
I>>Сильно спорно. По моему разумению основное время уходит на всякие косяки и нестыковки технологий. Скажем ORM сильно чаще является узким местом, нежели язык C#. Или тот же WCF.
A>Если рассматривать голый N, так в нем кроме match вообще ничего нет. Архитектура у него такая. Просто на добавление наворотов, которые появляются в других языках тратится значительно меньше времени. Тот же async/await, code contrats, computation expression. В общем предложи-найди фичу, которая есть в других языках — тебе бойцы ее быстро прикрутят.
Немерле не избавит тебя от необходимости вникать в EF, WCF, WPF и тд.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, alvas, Вы писали:
I>>>Сильно спорно. По моему разумению основное время уходит на всякие косяки и нестыковки технологий. Скажем ORM сильно чаще является узким местом, нежели язык C#. Или тот же WCF.
A>>Если рассматривать голый N, так в нем кроме match вообще ничего нет. Архитектура у него такая. Просто на добавление наворотов, которые появляются в других языках тратится значительно меньше времени. Тот же async/await, code contrats, computation expression. В общем предложи-найди фичу, которая есть в других языках — тебе бойцы ее быстро прикрутят.
I>Немерле не избавит тебя от необходимости вникать в EF, WCF, WPF и тд.
А разве это кто-то утверждал?
ЗЫ. Смотри тему топика.
Хорошо процитирую "Что лучше делать на Nemerle вместо C#"
Здравствуйте, Ziaw, Вы писали:
VD>>С подсветкой все будет по прежнему фигово. Но ломать ничего не придется. Идея в общем-то очень проста. Мы описываем макрос linq как лексерный (принимающий лексему — Token, а не PExpr). Далее, вместо того чтобы пытаться разобраться с лексемой мы тупо берем ее местоположение в файле, вынимаем код соответствующий ему и парсим его PegGrammor-ом. Те места которые должны соответствовать немерловым подвыражениям мы "вырезаем" как строки и скарливаем эти строки штатному парсеру немерла (можно даже выковырять под-лексемы).
Z>Идея хорошая, а что парсер считает лексемой?
Офтоп: Блин! Написал много букв, но из-за гребоанного Хрома все потерял. Был какой-то кратковременный глюк сети и Хром тупо угробил все посланное мной! Хоть обратно к Фаерфокусу возвращайся .
Короче, вкратце. Вопрос я твой как всегда не понял, так что вкратце о том как работает парсер немерла:
* Сначала запускается лексер который в ленивом режиме (что важно) преобразует текст в лексемы (токены).
* Далее запускается препарсер. Он преобразует последовательность токенов в дерево токенов свернутое по скобкам. Боре подробно о свертке можно прочитать здесь. Кроме того препарсер распознает конструкции using с namespace и загружает/выгружает открываемые using-ами синтаксические расширения. Из синтаксических расширений считываются ключевые слова.
Так как лексер ленивый, он использует считанные пре-парсером ключевые слова, что приводит к тому, что дерево токенов содержим именно их, а не какие-то там идентификаторы.
Парсер уже работает с деревом текено созданным препарсером.
Кроме того есть специальный вид макросов — лексерные макросы. Им вместо PExpr в качестве параметра (единственоно) передается подветка дерева теокено. Такие макросы могут сами отпарсить дерево токенов, а стало быть разбирать синтаксис сильно отличающийся от синтаксиса немерла. Единственно ограничение синтаксис должен удовлетворять правилам свертки токенов.
Например, PegGrammar использует лексерный макрос grammar который передает свой параметры в неизменном виде макросу PegGrammar. Далее разбор грамматики ПЕГ-а производится вручную.
Проблема в том, что разбирать токены вручную — это не простая задача. Но эту задачу можно упростить если взять текст соотвествющий этому дереву токенов и распарсить его PegGrammar-ом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>>>Вы что, CVS используете или VSS какой
VD>>Можно узнать, с чего сделан такой вывод?
I>"сутки простоя какой-нить большой команды из-за того что кто-то сломал всё совсем уже могут выйти очень дорого"
I>"Там разработчики сами релизят то что у них на винчестере лежало"
I>Не ясно, на что уходит неделя, если обычно релиз выкатывается за пару часов с документацией и прочей дрянью
И где же в приведенных цитатах хоть упоминание CVS или VSS?
Сдается мне, что данная догадка высосана из пальца.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Основное время уходит на всякие активности которые не автоматизируются. Например тфс не умеет перезапускать сам себя и продолжать билд.
Так выкинь ТФС.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Офтоп: Блин! Написал много букв, но из-за гребоанного Хрома все потерял. Был какой-то кратковременный глюк сети и Хром тупо угробил все посланное мной! Хоть обратно к Фаерфокусу возвращайся .
Но даже если б и был — непредсказуемо тормозявый он. Причём его тормозявость — практически утверждена официально. А у нас жажда скорости прописана в ТЗ.
Если нам не помогут, то мы тоже никого не пощадим.
.
