Re[9]: Что лучше делать на Nemerle вместо C# - Nemerle

D>В чем C# уступает (если, конечно, уступает) Nemerle? Что можно сделать Nemerle легче, чем на C#?

Тут вопрос стоит ставить иначе. А есть ли что-то вообще что можно сделать на C# так чтобы было лучше чем в Nemerle

1) Любая сложная логика. То что на C# выражается кучами вложенных if/else — на Nemerle занимает в разы меньше места и читается нагляднее. См match
2) Многопоточность. После того как привыкнешь писать в immutable стиле и накидаешь основные примитивы макросами — C# вообще отдыхает. У нас к концу проекта основных примитивов многопоточности набралось штук наверное 20. В C# — lock в зубы, и остальное выписывай ручками в кренделя try/finally.
3) Всё что может дать аспектно-ориентированное программирование — на Nemerle и проще сделать, и возможностей будет больше, и проще расширять.
4) Задачи требующие своего DSL.
5) Логгирование, замеры времени, особенно если проект в релизе, его как в C# не делай, всегда фигня будет получаться

6) Задачи, которые на C# принято считать требующими кодогенераторов или отдельных программ. У нас например в процессе компиляции макрос лезет по сети и вытягивает оттуда JavaScript, а потом лезет по всему проекту, и в нужных местах корректирует код (не какие-то генерённые файлы обновляет, а разбирает и корректирует писанный людьми код), в соответствии с тем JavaScript. Чтобы такое повторить на C# — убиться надо.
7) Даже самые простые вещи об которые спотыкается C#. Вот сделай мне чтобы прога при старте выводила дату/время компиляции и машину на которой билдилась, без посторонних приблуд и отдельных прог

или там чек-сумму ключевых исходников посчитай
8) Форматирование строк, нам приходилось переключаться между обоими, так после Nemerle форматируешь строки в C# и плачешь, плачешь...
9) Поддержка прямо в языке XML, или JSON, или любого другого формата.
10) Возможность поддержать кучу разных видов сериализации одним макросом, и при этом не написать ни строчки рукопашного кода (нам реально надо было).
11) Генерировать что-то по коду проекта в процессе компиляции. Например javascript или базу данных. В C# БД генерировать умеет только наверное DevExpress XPO, и то через рефлексию и по рабочей программе а не во время компиляции. И со всякими ограничениями. В Nemerle можно в генерированную БД из бакапа например тестовые данные сразу вытягивать, если билд тестовый.
12) Статическая верификация кода. Например можно разрешить вызов каких-то методов только из под правильного lock'a. Или наоборот запретить вызов из под lock'a например методов которые заведомо долго работают.
13) В C# есть только typeof. Больше ничего нет и не будет, потому что Эрик Липперт. В Nemerle можно и memberof, и propertyof, и чё угодно. Реально это надо когда например пишешь такой код throw ArgumentOutOfRangeException(arg(имя_аргумента)); или там биндинг на какое-то поле делаешь. В C# только строчки "имя_аргумента" для этих целей. Которые может какой Resharper и проверяет в простых случаях, а может и нет.
14) Вывод типов. В C# его нет, поэтому даже сложно как-то объяснить насколько проще пишется когда он есть.
15) Код реально лучше и удобнее с фичами вроде локальных функций, объявления переменных внутри пропертей (и соответствено недоступных другому коду), всяких макросов автогенерации вроде [Record], и т.п.
16) Собственные операторы. В C# кроме нескольких захардкоженных ничё нельзя. В Nemerle хоть #@$! объяви, если он для тебя имеет смысл, то пользуй и радуйся.
17) То что любой из вышеперечисленных, а также любой из фич которые я не знаю/забыл можно не пользоваться вовсе. И писать как раньше писал на C#

18) Если припрёт то можно даже множественно наследование слепить. Нам на проекте не понадобилось, но как proof-of-concept чего-то накидали пока изучали тему макросов.

D>Есть ли такие задачи, для которых алгоритм на Nemerle будет работать быстрее, чем на C#?
Оба языка на .NET, так что их быстродействие очень близко. В среднем, по слухам, код генерируемый на C# чуть быстрее.
1) Абсолютное большинство задач требующих рефлексию, описанные на Nemerle будут работать лучше и быстрее — например сериализация обычная и XML, соответственно и работа с сетью если используется сериализация, и т.п.
2) В качестве общего развития почитай про проект NUDA — там код Nemerle в процессе компиляции преобразуется в код расчёта на GPU. Если алгоритм критичен по скорости — ты можешь повторить этот же трюк, но транслировать Nemerle в тот же C++ например, причём штатными средствами самого Nemerle.
3) Регулярные выражения. В C# они тормозные, в Nemerle их реально сделать быстрыми если надо. Кроме того в Nemerle есть regex match, для быстрого биндинга вхождений.

Тем не менее в Nemerle есть и некоторые неудобства.
1) Скорость компиляции. Мы решали этот вопрос тупым апгрейдом всего железа. Никто не возражал

2) Интеграция с Visual Studio иногда отваливалась. В частности автокомплит пропадал. Решалось либо перезапуском, либо закрывали все окна и открывали снова. Как повезёт.
3) Проекты где используется WinForms/WPF/другие студийные дизайнеры. Поддержка дизайнеров хронически хромает. В основном потому что работа этих студийных дизайнров нифига не документирована, и по-видимому никогда не будет документирована, да ещё и индусописана (сам в них лазил). Пока лучше делать фронт-энд на C#, логику на Nemerle. Если в терминах MVC/MVVM то Nemerle идеален для Model.
4) Поддержка Linq, в C# Linq заинлайнен, сразу from и запрос. В Nemerle он мощнее, но приходится писать linq <# from .... #>. В Nemerle 2 исправят. Хотя имхо могли бы грязным хаком исправить и пораньше

5) Информирование об ошибках. Иногда читая ошибку теряешься. Это от того что можно комбинировать самые неожиданные вещи, и компилятор встретив что-то не то, тем не менее находит в этом какой-то смысл

Например путаешь параметры местами, а компилятор может тебя заподозрить в попытке заиспользовать ковариантность.
6) То что некоторые фишки о которых и не подозреваешь, можно узнать только потусовавшись на форуме или случайно заметив в сорцах компилятора.

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

_>7) Даже самые простые вещи об которые спотыкается C#. Вот сделай мне чтобы прога при старте выводила дату/время компиляции
Есть в метаданных сборки

_>>7) Даже самые простые вещи об которые спотыкается C#. Вот сделай мне чтобы прога при старте выводила дату/время компиляции
А>Есть в метаданных сборки
Дата время есть. Проще всего из AssemblyInfo вытащить, можно из PE, наверняка есть и другие места. Но ты обрезал цитату рановато — там ещё было про имя билд-машины и чек-суммы ключевых исходников

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

_>2) Многопоточность. После того как привыкнешь писать в immutable стиле и накидаешь основные примитивы макросами — C# вообще отдыхает. У нас к концу проекта основных примитивов многопоточности набралось штук наверное 20. В C# — lock в зубы, и остальное выписывай ручками в кренделя try/finally.

RX не годится ?

_>4) Задачи требующие своего DSL.

Покажи пример, пожалуйста.

_>5) Логгирование, замеры времени, особенно если проект в релизе, его как в C# не делай, всегда фигня будет получаться

Это инструментирование в рантайме или что ты имел ввиду ?

_>6) Задачи, которые на C# принято считать требующими кодогенераторов или отдельных программ. У нас например в процессе компиляции макрос лезет по сети и вытягивает оттуда JavaScript, а потом лезет по всему проекту, и в нужных местах корректирует код (не какие-то генерённые файлы обновляет, а разбирает и корректирует писанный людьми код), в соответствии с тем JavaScript. Чтобы такое повторить на C# — убиться надо.

А что за задачу вы решали таким образом ?

_>7) Даже самые простые вещи об которые спотыкается C#. Вот сделай мне чтобы прога при старте выводила дату/время компиляции и машину на которой билдилась, без посторонних приблуд и отдельных прог

или там чек-сумму ключевых исходников посчитай

В TFS это делается достаточно просто

Не пойму, зачем это надо не в релизной версии.

_>11) Генерировать что-то по коду проекта в процессе компиляции. Например javascript или базу данных. В C# БД генерировать умеет только наверное DevExpress XPO, и то через рефлексию и по рабочей программе а не во время компиляции. И со всякими ограничениями. В Nemerle можно в генерированную БД из бакапа например тестовые данные сразу вытягивать, если билд тестовый.

tt чем не подходит ?

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

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

D>>Есть ли такие задачи, для которых алгоритм на Nemerle будет работать быстрее, чем на C#?

C>Вряд ли. Но вполне возможно, что на Немерле можно намного проще и быстрее написать более эффективный алгоритм, чем на C#. Например, я хотел реализовать алгоритм

Это я и имел ввиду. Покажи, пожалуйств, код.

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

C>>Вряд ли. Но вполне возможно, что на Немерле можно намного проще и быстрее написать более эффективный алгоритм, чем на C#. Например, я хотел реализовать алгоритм

D>Это я и имел ввиду. Покажи, пожалуйств, код.

Посмотри на генератор парсеров PEG. Его алгоритмы эффективно более никто не реализовал, ибо нет удобных инструментов по анализу и генерации кода. Делать это на C#/Java/C++ никто в здравом уме даже не возьмется. Можно посмотреть на Antlr, сравнить количество приседаний для создания парсера на нем и быстродействие.

Посмотри примеры computatition expressions. Попробуй написать подобный код на C# до пятой версии, даже с rx это выглядит достаточно печально.

Посмотри на любой linq провайдер на C#, там Содом и Гоморра. Большинство их алгоритмов на nemerle могут быть сделаны гораздо понятнее и выразительнее.

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

_>Дата время есть. Проще всего из AssemblyInfo вытащить, можно из PE, наверняка есть и другие места. Но ты обрезал цитату рановато — там ещё было про имя билд-машины и чек-суммы ключевых исходников

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

Сколько времени у вас уходит на один релилз ? Я про "сбилженный человеком который лично всё два раза проверит, прежде чем собирать и отсылать".

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

D>>Есть ли такие задачи, для которых алгоритм на Nemerle будет работать быстрее, чем на C#?
_>Оба языка на .NET, так что их быстродействие очень близко. В среднем, по слухам, код генерируемый на C# чуть быстрее.

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

_>4) Поддержка Linq, в C# Linq заинлайнен, сразу from и запрос. В Nemerle он мощнее, но приходится писать linq <# from .... #>. В Nemerle 2 исправят. Хотя имхо могли бы грязным хаком исправить и пораньше

В принципе у меня появились мысли о том как исправить это и в 1.х. Для этого парсить нужно с помощью PEG-а. Если найдутся добровольцы, готов изложить идею подробно.

_>6) То что некоторые фишки о которых и не подозреваешь, можно узнать только потусовавшись на форуме или случайно заметив в сорцах компилятора.

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

VD>В принципе у меня появились мысли о том как исправить это и в 1.х. Для этого парсить нужно с помощью PEG-а. Если найдутся добровольцы, готов изложить идею подробно.
Да но при этом придётся же разломать и Lexer/ScanLexer, а также перелопатить пол подсветки синтаксиса, да?

I>Сколько времени у вас уходит на один релилз ? Я про "сбилженный человеком который лично всё два раза проверит, прежде чем собирать и отсылать".
Где-то неделя.

Тут бесполезно к чему-то цепляться. Есть проекты где цена ошибки стремится к стоимости времени её фикса. Например сайты-визитки. Там хоть пол-проекта разломай а клиенту зарелись билд который вообще от другого проекта — ну будет разговор вида "Чё там такое, вообще какая хрень! Посмотрите!" и всё. Там разработчики сами релизят то что у них на винчестере лежало, и это правильное решение. Есть проекты где цена ошибки немного повыше, например сутки простоя какой-нить большой команды из-за того что кто-то сломал всё совсем уже могут выйти очень дорого. Там внедряют всякие более-менее автоматические средства, те-же ночные тесты, и прочие. Разделяют на модули так чтобы лом чего-то одного не приводил к полной остановке всего, и это тоже правильное решение.

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

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

VD>>В принципе у меня появились мысли о том как исправить это и в 1.х. Для этого парсить нужно с помощью PEG-а. Если найдутся добровольцы, готов изложить идею подробно.
_>Да но при этом придётся же разломать и Lexer/ScanLexer, а также перелопатить пол подсветки синтаксиса, да?

С подсветкой все будет по прежнему фигово. Но ломать ничего не придется. Идея в общем-то очень проста. Мы описываем макрос linq как лексерный (принимающий лексему — Token, а не PExpr). Далее, вместо того чтобы пытаться разобраться с лексемой мы тупо берем ее местоположение в файле, вынимаем код соответствующий ему и парсим его PegGrammor-ом. Те места которые должны соответствовать немерловым подвыражениям мы "вырезаем" как строки и скарливаем эти строки штатному парсеру немерла (можно даже выковырять под-лексемы).

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

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

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

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

VD>С подсветкой все будет по прежнему фигово. Но ломать ничего не придется. Идея в общем-то очень проста. Мы описываем макрос linq как лексерный (принимающий лексему — Token, а не PExpr). Далее, вместо того чтобы пытаться разобраться с лексемой мы тупо берем ее местоположение в файле, вынимаем код соответствующий ему и парсим его PegGrammor-ом. Те места которые должны соответствовать немерловым подвыражениям мы "вырезаем" как строки и скарливаем эти строки штатному парсеру немерла (можно даже выковырять под-лексемы).

Идея хорошая, а что парсер считает лексемой?

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

VD>С подсветкой все будет по прежнему фигово. Но ломать ничего не придется. Идея в общем-то очень проста. Мы описываем макрос linq как лексерный (принимающий лексему — Token, а не PExpr). Далее, вместо того чтобы пытаться разобраться с лексемой мы тупо берем ее местоположение в файле, вынимаем код соответствующий ему и парсим его PegGrammor-ом. Те места которые должны соответствовать немерловым подвыражениям мы "вырезаем" как строки и скарливаем эти строки штатному парсеру немерла (можно даже выковырять под-лексемы).

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

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

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

как только эта самая расширяемость заработает )

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

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

Z>как только эта самая расширяемость заработает )

Ой. А она еще не работает? Пичалька. Я разочарован, как раз собирался в одном проекте это дело попробовать. Придется пока остаться с самописным packrat-ом на сишарпе.

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

_>>2) Многопоточность. После того как привыкнешь писать в immutable стиле и накидаешь основные примитивы макросами — C# вообще отдыхает. У нас к концу проекта основных примитивов многопоточности набралось штук наверное 20. В C# — lock в зубы, и остальное выписывай ручками в кренделя try/finally.

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>А что за задачу вы решали таким образом ?
Связь с монструозной прогой на стороне клиента.

_>>7) Даже самые простые вещи об которые спотыкается C#. Вот сделай мне чтобы прога при старте выводила дату/время компиляции и машину на которой билдилась, без посторонних приблуд и отдельных прог

или там чек-сумму ключевых исходников посчитай
I>В TFS это делается достаточно просто

Не пойму, зачем это надо не в релизной версии.
Написал почему здесь.

_>>11) Генерировать что-то по коду проекта в процессе компиляции. Например javascript или базу данных. В C# БД генерировать умеет только наверное DevExpress XPO, и то через рефлексию и по рабочей программе а не во время компиляции. И со всякими ограничениями. В Nemerle можно в генерированную БД из бакапа например тестовые данные сразу вытягивать, если билд тестовый.

I>tt чем не подходит ?
Ну если сравнивать Nemerle и C#, то получается что эта внешняя тулза не C#. Да ещё самого убогого типа — т.е. тупо склейка строк по шаблону. Что там клеится и как проверяет программист глазками. Компилятор проверяет только синтаксическую корректность. Конечно когда ты связан по рукам и ногам ограничениями языка, в ход идёт всё. Вот пока не было linq — по всему миру люди клеили SQL ручками, бывало склеивали криво, что-то валилось, лезли назад и чинили. С linq проблема склейки ушла, и теперь гордые шарписты смотрят свысока на всех остальных. А сами втихую точно также склеивают C#-сорцы, вызывают пре-билд и пост-билд хреновины, и т.п. Но эти все убогости возникают от того что задачи решать хочется, а средств для их решения в C# нет.

Вот наглядный пример — реальный вопрос, от одного из наиболее продвинуты тут людей. Сравни полученное решение на C# / T4 и решение на Nemerle. Закономерное впечатление топикстартера:

Мдя, я предполагал, что будет короче и понятней, но не настолько же! Шикарно и спасибо

И это одна обычная задача. Два экрана на C# и один на Nemerle. Нужно ли говорить что на большом проекте разница уже не просто заметна, но начинает реально влиять не только на сроки, но и на реализуемость фич вообще?

Здравствуйте, 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# / T4 и решение на Nemerle. Закономерное впечатление топикстартера:
_>

Мдя, я предполагал, что будет короче и понятней, но не настолько же! Шикарно и спасибо

Да, сильно.

_>И это одна обычная задача. Два экрана на C# и один на Nemerle. Нужно ли говорить что на большом проекте разница уже не просто заметна, но начинает реально влиять не только на сроки, но и на реализуемость фич вообще?

Сильно спорно. По моему разумению основное время уходит на всякие косяки и нестыковки технологий. Скажем ORM сильно чаще является узким местом, нежели язык C#. Или тот же WCF.

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

_>Тут бесполезно к чему-то цепляться. Есть проекты где цена ошибки стремится к стоимости времени её фикса. Например сайты-визитки. Там хоть пол-проекта разломай а клиенту зарелись билд который вообще от другого проекта — ну будет разговор вида "Чё там такое, вообще какая хрень! Посмотрите!" и всё. Там разработчики сами релизят то что у них на винчестере лежало, и это правильное решение.

Вы что, CVS используете или VSS какой

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

А> А не разумнее ли будет сам штатный парсер на 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, Вы писали:

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

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

Здравствуйте, 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>Офтоп: Блин! Написал много букв, но из-за гребоанного Хрома все потерял. Был какой-то кратковременный глюк сети и Хром тупо угробил все посланное мной! Хоть обратно к Фаерфокусу возвращайся

.

Lazarus всегда спасает.

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

I>>>RX не годится ?

VD>>Если бы он годился бы для всех случаев, то в MS не стали бы в срочном порядке "изобретать" async/await и прикручивать его к C#.

I>

I>Хорошо, что не все немерлесты растеряли способности к адекватным объяснениям.

Что неадекватного ты усмотрел? Это же не я бегаю по форумам C# в темах где упоминается async/await спрашиваю: "Зачем МС делает async/await? Чем RX не годится?".

I>>>tt чем не подходит ?

VD>>Под "tt" ты T4 — генератор текста, имеешь в виду?
VD>>Тем же чем RX. Не является удовлетворительным решением для многих случаев.

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

Тебе примеры нужны? Ну, так формулируй вопросы корректно. Примеров много. Вот недавно тебе дали ссылку на разницу между решением на T4 и макросах. Но это чисто количественная разница.

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

Но ты никогда ничего не поймешь пока не попробуешь Немерл в деле.

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

>>сравнивать какой-нить BMW X5 с Ford T. Тоже конечно машина, но вот ездить на ней как-то не очень удобно

I>Неужели на Немерле нельзя написать более толковый генератор тавтологий ?

А где здесь тавтология?

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

I>>"сутки простоя какой-нить большой команды из-за того что кто-то сломал всё совсем уже могут выйти очень дорого"

I>>"Там разработчики сами релизят то что у них на винчестере лежало"

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

VD>И где же в приведенных цитатах хоть упоминание CVS или VSS?

VD>Сдается мне, что данная догадка высосана из пальца.

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

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

I>>Основное время уходит на всякие активности которые не автоматизируются. Например тфс не умеет перезапускать сам себя и продолжать билд.

VD>Так выкинь ТФС.

Ты про энтерпрайз когда нибудь слышал ?

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

I>>Хорошо, что не все немерлесты растеряли способности к адекватным объяснениям.

VD>Что неадекватного ты усмотрел? Это же не я бегаю по форумам C# в темах где упоминается async/await спрашиваю: "Зачем МС делает async/await? Чем RX не годится?".

Твой ответ как в анекдоте "Где мы находимся ? На воздушном шаре" и потому однозначный неадекват.

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

VD>Тебе примеры нужны? Ну, так формулируй вопросы корректно. Примеров много.

hi_octane почему то смог объяснить без лозунгов, вот ведь незадача, да ?

VD>Главное преимущество макросов заключается в том, что они работают во время компиляции и могут взаимодействовать с компилятором. Это позволяет узнать детали кода, и даже (при необходимости) изменить его.

"дважды два — четыре !" т.е. снова неадекват

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

Я сюда и пришел за задачами, а не за твоими лозунгами.

I>>Неужели на Немерле нельзя написать более толковый генератор тавтологий ?

VD>А где здесь тавтология?

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

P.S. hi_octane своими сообщениями про применения Немерла целиком полностью компенсирует твой неадекват.

P.P.S. Сделай отдолжение — не пиши мне ничего в ответ, хотя бы в этой теме ?

I>Вы что, CVS используете или VSS какой

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

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

_>Я наверное неясно выразился. Тем опусом я хотел подчеркнуть лишь то что принятый у нас подход, при котором от момента коммита, до момента когда клиент запускает у себя обновлённую версию проходит неделя, обоснован экономически. И одна из составляющих этого обоснования — это очень большая цена одной ошибки. Другие подходы которые я там перечислил — у нас не используются вовсе, но в других условиях они вполне оправданы. Используемая система контроля версий — второстепенна.

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

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

VD>>Так выкинь ТФС.

I>Ты про энтерпрайз когда нибудь слышал ?

Ага. А ты слышал, что есть люди что живут вообще без продуктов от MS?

Ентерпроайз не ентерпрайз — без разрицы. Если у вас нет сборки продукта в один клик, то вы уже накосячили. Если вам мешает ТФС, то выкиньте его на фиг. Есть много других решений.

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

I>Сдаётся мне, что при грамотном VCS и тд нет необходимости релизить то, что лежит на локальном венике, нет простоев из за того, что ктото чтото сломал.

Тебе надо чаще придерживать то что тебе сдаётся. У людей ведь может быть куча предпосылок для своих решений. Лучше ведь спросить, а не домысливать.

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

I>>Сдаётся мне, что при грамотном VCS и тд нет необходимости релизить то, что лежит на локальном венике, нет простоев из за того, что ктото чтото сломал.

VD>Тебе надо чаще придерживать то что тебе сдаётся. У людей ведь может быть куча предпосылок для своих решений. Лучше ведь спросить, а не домысливать.

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

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

I>>Ты про энтерпрайз когда нибудь слышал ?

VD>Ага. А ты слышал, что есть люди что живут вообще без продуктов от MS?

Ты не уходи от темы, про энтерпрайз слышал ?

VD>Ентерпроайз не ентерпрайз — без разрицы.

Есть разница и очень большая.

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

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

I>Ну это уже понятнее. Так а что входит то в эту неделю ? Ты хоть приблизительно скажи, я с целью для себя интересуюсь, а не потроллить.
Просмотр (code review) всего закоммиченного кода, тесты у нас на симуляторе, тесты у заказчика на реальном потоке данных, с логгированием "виртуальных" ответов (реальные ответы делает текущая система). Потом анализ тех отчётов по быстродействию, которые прога собрала пока была у заказчика, ну и в заключении официальная писанина — "выложили версию такую-то, по таким-то тестам всё ок, по таким-то ок, параметры такие-то в утверждённых пределах, о чём репорты приложены, и т.п.". Что можно распаралелено, но, например, review и тесты оказалось лучше не параллелить. И самое страшное — если хоть один косяк прошёл за ревью и вылез на каких-то тестах, то всё сначала

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

_>Просмотр (code review) всего закоммиченного кода, тесты у нас на симуляторе, тесты у заказчика на реальном потоке данных, с логгированием "виртуальных" ответов (реальные ответы делает текущая система). Потом анализ тех отчётов по быстродействию, которые прога собрала пока была у заказчика, ну и в заключении официальная писанина — "выложили версию такую-то, по таким-то тестам всё ок, по таким-то ок, параметры такие-то в утверждённых пределах, о чём репорты приложены, и т.п.". Что можно распаралелено, но, например, review и тесты оказалось лучше не параллелить. И самое страшное — если хоть один косяк прошёл за ревью и вылез на каких-то тестах, то всё сначала

Ужас! Вы на оборону работаете или на космос?

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

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

Надо сесть и сделать. Это всегда сложно

.

Вообще-то там уже не совсем PEG получается. Там для разбора операторов еще TDOP (ака Pratt) должен быть прикручен. Чтобы можно было операторы декларировать удобнее (с приоритетами и левой рекурсией).

_>>>>6) Задачи, которые на C# принято считать требующими кодогенераторов или отдельных программ. У нас например в процессе компиляции макрос лезет по сети и вытягивает оттуда JavaScript, а потом лезет по всему проекту, и в нужных местах корректирует код (не какие-то генерённые файлы обновляет, а разбирает и корректирует писанный людьми код), в соответствии с тем JavaScript. Чтобы такое повторить на C# — убиться надо.
I>>>А что за задачу вы решали таким образом ?
_>>Связь с монструозной прогой на стороне клиента.

I>Шота мне кажется вы изобрели уже давно известную технологию

Какого характера изменения что вносятся скриптом ? Почему нельзя это заменить на инжекцию депенденсов ?
Примерно такая последовательность:
1) Объявляются интерфейсы, прикручиваются к классам
2) В классах создаются методы которых нет
3) Подставляются реализации в те методы которые уже есть, но делают throw NotImplementedException, оставляются реализации методов которые есть и делают что-то реальное.
4) В самом последнем проходе, те методы которые остались throw NotImplemented, например потому что ни в JavaScript ни в коде реализации для них не оказалось, намеренно превращаются в ошибки компиляции, чтобы ни один NotImplemented не попал случайно в релиз.
Здесь и ниже по ветке есть ещё немного, и кроме того, я уверен, хороший программист всегда найдёт способ выкрутиться. До нас эту же работу делали ацки сильные хлопцы на C++, и эту же задачу решали. #define'o'кодинг там у них был ацкий, или может ещё что, главное работало. Но на Nemerle это получилось красиво, и как-то легко.

I>Сильно спорно. По моему разумению основное время уходит на всякие косяки и нестыковки технологий. Скажем ORM сильно чаще является узким местом, нежели язык C#. Или тот же WCF.
Согласен. Но из этого логично следует что чем больше гибкость у языка, тем меньше времени ты тратишь на стыковку нестыкуемого. ORM вообще возникли как переходник между ограничениями языков программирования и ограничениями баз данных. И основная фишка за счёт которой они упрощают C#-код — это как раз IL-эмиттинг, postsharp-ление, либо текстовая кодогенерация. Совпадение или таки нехватка возможностей языка?

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

I>>Ну это уже понятнее. Так а что входит то в эту неделю ? Ты хоть приблизительно скажи, я с целью для себя интересуюсь, а не потроллить.
_>Просмотр (code review) всего закоммиченного кода, тесты у нас на симуляторе, тесты у заказчика на реальном потоке данных, с логгированием "виртуальных" ответов (реальные ответы делает текущая система). Потом анализ тех отчётов по быстродействию, которые прога собрала пока была у заказчика, ну и в заключении официальная писанина — "выложили версию такую-то, по таким-то тестам всё ок, по таким-то ок, параметры такие-то в утверждённых пределах, о чём репорты приложены, и т.п.". Что можно распаралелено, но, например, review и тесты оказалось лучше не параллелить. И самое страшное — если хоть один косяк прошёл за ревью и вылез на каких-то тестах, то всё сначала

Спасибо. Я только не понял, почему вы эту процедуру называете релизом

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

_>4) В самом последнем проходе, те методы которые остались throw NotImplemented, например потому что ни в JavaScript ни в коде реализации для них не оказалось, намеренно превращаются в ошибки компиляции, чтобы ни один NotImplemented не попал случайно в релиз.
_>Здесь и ниже по ветке есть ещё немного, и кроме того, я уверен, хороший программист всегда найдёт способ выкрутиться. До нас эту же работу делали ацки сильные хлопцы на C++, и эту же задачу решали. #define'o'кодинг там у них был ацкий, или может ещё что, главное работало. Но на Nemerle это получилось красиво, и как-то легко.

Это гораздо понятнее, нежели "BMW X5 vs Ford T"

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

VD>Кроме того есть специальный вид макросов — лексерные макросы. Им вместо PExpr в качестве параметра (единственоно) передается подветка дерева теокено. Такие макросы могут сами отпарсить дерево токенов, а стало быть разбирать синтаксис сильно отличающийся от синтаксиса немерла. Единственно ограничение синтаксис должен удовлетворять правилам свертки токенов.

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

macro @from(token : VToken)
{
  // parsing token ...
}

// using
def x = from Lorem() ipsum + 42 dolor % 3 sit {"bla bla"} amet, consectetur adipisicing elit;

def y = 1;

Как лексер понимает где кончается токен?

Извини, что назвал его парсером, после пега о лексере не думаю вообще.

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

VD>Ужас! Вы на оборону работаете или на космос?

Судя по написанному, они вполне могут работать на оператора сотовой связи, если что

VD>Ужас! Вы на оборону работаете или на космос?

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

I>Спасибо. Я только не понял, почему вы эту процедуру называете релизом

Э
Как-то исторически сложилось, что пока все эти этапы не пройдены, считается что рабочей новой версии нет. Не "rebuild all" же релизом считать. А как правильно?

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

VD>Вообще-то там уже не совсем PEG получается. Там для разбора операторов еще TDOP (ака Pratt) должен быть прикручен. Чтобы можно было операторы декларировать удобнее (с приоритетами и левой рекурсией).

Вот что бывает, если packrat-а бояться. С packrat-ом левую рекурсию легче легкого было бы сделать, да еще и в общем виде.

Ну да ладно, посмотрю на досуге, как расширение к Peg прикрутить. Все равно должно быть достаточно просто.

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

Посмотрел-покопал, вроде как реализуемо. Но это же всё потеряет смысл когда начнётся переход на Peg+Packratt, так? А переход всё не начинается потому что сходу его не наколбасить даже Wolfhound'у. Может тогда утвердить синтаксис нового парсера, и сделать медленный и простой, но с точками расширения и быстро. А когда придёт Wolfhound и принесёт быстрый парсер — просто заменить.

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

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

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

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

Z>

Z>macro @from(token : VToken)
Z>{
Z>  // parsing token ...
Z>}
Z>// using
Z>def x = from Lorem() ipsum + 42 dolor % 3 sit {"bla bla"} amet, consectetur adipisicing elit;

Z>def y = 1;
Z>

VToken — это какая-то фигня. Должен быть Token.

Z>Как лексер понимает где кончается токен?

Производится свертка по скобкам и ";". К сожалению это означает, что использовать круглые скобки для обрамения реализованного таким образом линка будет невозможно. Например, такое выражение не прокатит:

(from x in xs where x > 2 order by x desc, y asc select x)

в то время как так:

from x in xs where x > 2 order by x desc, y asc select x

или так:

{from x in xs where x > 2 order by x desc, y asc select x}

выйдет.

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

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

Короче, вот так может выглядеть макрос:

using Nemerle.Compiler;
using System.Diagnostics;

namespace Nemerle.Linq.Syntax
{
  public macro @from(query : Token)
    syntax ("from", query)
  {
    assert2(false);
    def queryText = query.ToString();
    Message.Hint($<#"$queryText"#>);
    <[ $(queryText : string) ]>
  }
}

а так его применение:

using System.Console;
using Nemerle.Linq.Syntax;

def text = from x in xs where x > 2 order by x desc, y asc select (x, y);
WriteLine(text);

Данная "реализация" тупо выводит текст и локешон. Вот только с локейшоном проблема. Он задается криво. Но я это сейчас поправлю.

I>Похоже, что тебе есть чего показать более сильное, нежели калькулятор. Я даже готов для этого заинсталировать Немерле

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

А как вопросы будут — спрашивай. Тут если вопрос по делу — подсказывают ещё лучше чем на хвалёных англоязычных форумах.

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

VD>>Ентерпроайз не ентерпрайз — без разрицы.
I>Есть разница и очень большая.

Какая?

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

А> Вот что бывает, если packrat-а бояться. С packrat-ом левую рекурсию легче легкого было бы сделать, да еще и в общем виде.

Пакрата бояться в лес не ходить. Левую рекурсию он не поддерживает. И сам по себе он на практике не применим в следствии дичайших тормозов. Потому его и выбросили после первых тестов. Если ктому-то хочется поиграться в игрушки и сделать реализацию которая будет пригодна для неспешного использования в не критичных к скорости местах, то флаг ему в руки. Мы же херной не занимаемся. У нас четкий ценз для алгорита — он должен быть применим для построения парсеров реальных ЯП. И его должно быть можно использовать в IDE.

А> Ну да ладно, посмотрю на досуге, как расширение к Peg прикрутить. Все равно должно быть достаточно просто.

Pratt (TDOP) это очень не сложный алгоритм. Плюс он еще позволяет оперировать на более высоком уровне — использовать приоритеты операторов. Победа левой рекурсии — это всего лишь приятный побочный эффект. Вольфхаунд придумал как объединить алгоритмы рекурсивного спуска с откатами (используемого для разбора PEG) и Pratt. На словах все выглядит очень красиво. Осталось дождаться когда эта красота будет реализована. Вот только этот процесс явно затягивается

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

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

_>Посмотрел-покопал, вроде как реализуемо. Но это же всё потеряет смысл когда начнётся переход на Peg+Packratt, так?

PEG+Pratt. Pratt — это TDOP (Top Down Operator Precedence). Да и не совсем PEG там получается. Вольфхаунд предлагает вместо приоритетного выбора использовать перебор всех вариантов и выбор правила которое смогло съесть максимум входной строки и не обломаться.

Но, таки — да. Реализация о которой я говорил пойдет в помойку.

_>А переход всё не начинается потому что сходу его не наколбасить даже Wolfhound'у. Может тогда утвердить синтаксис нового парсера, и сделать медленный и простой, но с точками расширения и быстро. А когда придёт Wolfhound и принесёт быстрый парсер — просто заменить.

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

У меня сейчас работа есть. Нужно пилить интеграцию с VS 2010. Хардкейс тоже занят. Он переводит Н1 на сменняемые беэкэнды.

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

_>Посмотрел-покопал, вроде как реализуемо. Но это же всё потеряет смысл когда начнётся переход на Peg+Packratt, так? А переход всё не начинается потому что сходу его не наколбасить даже Wolfhound'у. Может тогда утвердить синтаксис нового парсера, и сделать медленный и простой, но с точками расширения и быстро. А когда придёт Wolfhound и принесёт быстрый парсер — просто заменить.

А потом Н2 — это долгая история. Мы еще довольно долго не увидим конечный результат. Так что Н1 пока что имеет смысл развивать.

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

_>В первой Матрице были такие хорошие слова "знать путь и идти по нему это совсем разные вещи". Вот поставь Nemerle, прочти статьи Влада, презентацию посмотри, выбери из всего что я писал то что тебе больше понравилось и начинай писать именно то, что тебе самому надо.

Вот и в тебе заговорил ВладД2

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

Т.е. меня интересует именно легаси код Немерла взрослого проекта, а не компилятора/демки/куркулятора. Интересует с целью выяснить, во что превращается проект через год-два скажем.

Наверняка у тебя в проекте есть куча классов общего назначения, которые делают чтото полезное и правятся месяцами а то и годами, правильно ? Вот на них и интересно взглянуть. Желательно без макросов и что бы PM проявился по-взрослому.

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

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

VD>>>Ентерпроайз не ентерпрайз — без разрицы.
I>>Есть разница и очень большая.

IT>Какая?

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

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

По этой причине очень странно слышать "А ты слышал, что есть люди что живут вообще без продуктов от MS?" при чем от человека, который пользует офис, вижлу, винду, .Net и прочую дрянь от того же Микрософта.

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

VD>PEG+Pratt. Pratt — это TDOP (Top Down Operator Precedence). Да и не совсем PEG там получается. Вольфхаунд предлагает вместо приоритетного выбора использовать перебор всех вариантов и выбор правила которое смогло съесть максимум входной строки и не обломаться.

А нельзя ли вместо Pratt заюзать другое слово ? А то сильно созвучно с Prat

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

VD>Производится свертка по скобкам и ";". К сожалению это означает, что использовать круглые скобки для обрамения реализованного таким образом линка будет невозможно. Например, такое выражение не прокатит:
VD>

VD>(from x in xs where x > 2 order by x desc, y asc select x)
VD>

Потестил, как раз это нормально прокатывает.

VD>в то время как так:
VD>

VD>from x in xs where x > 2 order by x desc, y asc select x
VD>

VD>или так:
VD>

VD>{from x in xs where x > 2 order by x desc, y asc select x}
VD>

VD>выйдет.

И это тоже.

И даже это:

    def t = (from x in [1, 2, 3] 
            select 
            {
              def a = 42;
              x + a
            }).Split(' ');

Но вот тут фейл:

    def t = (from x in [1, 2, 3] 
            let b = {
              def a = 42;
              x + a
            } // токен кончается здесь
            select b).Split(' ');

В expression tree его перевести, видимо, не получится, но для IEnumerable оно выглядит вполне логично.

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

I>А нельзя ли вместо Pratt заюзать другое слово ? А то сильно созвучно с Prat
Нельзя. Ибо автора завут: Vaughan Pratt
http://en.wikipedia.org/wiki/Pratt_parser

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

VD>Пакрата бояться в лес не ходить. Левую рекурсию он не поддерживает.

Чо, правда? http://www.cs.ucla.edu/~todd/research/pepm08.html

VD> И сам по себе он на практике не применим в следствии дичайших тормозов.

Откуда там тормоза? Память жрет, да, ну так на кой надо жрать больше чем на один top level declaration?

VD> Мы же херной не занимаемся. У нас четкий ценз для алгорита — он должен быть применим для построения парсеров реальных ЯП. И его должно быть можно использовать в IDE.

Ну и что не так с Packrat?

Здравствуйте, <Аноним>, Вы писали:

А> Чо, правда? http://www.cs.ucla.edu/~todd/research/pepm08.html
Это уже давно прочитано.
Только это уже не пакрат, а его расширение.
И толку от этой поддержки весьма не много.
Ибо чуть менее чем все случаи возникновения левой рекурсии это описание операторов. А им одной левой рекурсии маловато. Им еще ассоциативность с приоритетами подавай. А тут уже рулит Pratt со страшной силой.

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

А>Память жрет, да, ну так на кой надо жрать больше чем на один top level declaration?
Если запоминать не все, то это уже не пакрат.
Кстати в моем парсере есть запоминание последнего применения правила.
Но пакратом это его не делает. Ибо линейное время разбора не гарантирует.

А> Ну и что не так с Packrat?
Тормоза и дикий жор памяти.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

I>>В энтерпрайзе свобода выбора технических решений как правило сильно ограничена. Мне лично, например, нравится Mercurial, а не TFS. Но все наши проекты за малым исключением на TFS и я точно знаю что Меркуриала в обозримом будущем точно не будет.

Z>То, что все будет на TFS решил какой-то человек. Если подойти к нему и внятно объяснить преимущества mercurial и если эти преимущества действительно есть и если этот человек радеет за дело, а не за то, чтобы его поменьше тревожили, тогда все будет.

Господи, ну и представление

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

А если если подразделения А, Б и Ц которые по разным причинам сопротивляются, то снова нужно убедить и их. А у них, например, взгляд будет отличный от твоего — ну, скажем, они будут ратовать за Git или за SVN.

В итоге будет тупо или холивар или волокита или просто отфутболят, если ты пойдешь напрямик к главному боссу. А может быть и похуже — против тебя тупо могут замутить интригу. Просто потому что переход на Mercurial уменьшает бюджет одной из команд.

Z>Если хоть одно условие не выполняется — меркуриала не будет. Только энтерпрайз тут ни при чем.

Ага-ага

Такой наивняк что я даже не знаю что и сказать.

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

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

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

VD>>PEG+Pratt. Pratt — это TDOP (Top Down Operator Precedence). Да и не совсем PEG там получается. Вольфхаунд предлагает вместо приоритетного выбора использовать перебор всех вариантов и выбор правила которое смогло съесть максимум входной строки и не обломаться.

I>А нельзя ли вместо Pratt заюзать другое слово ? А то сильно созвучно с Prat

Это имя автора алгоритма. Алгоритм называется Top Down Operator Precedence (TDOP).

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

WH>Ибо чуть менее чем все случаи возникновения левой рекурсии это описание операторов.

Так уж и операторов?

А фигня вида namespace.class.method(bebebe)[index].method(...).method(...)?

WH> А им одной левой рекурсии маловато. Им еще ассоциативность с приоритетами подавай.

Ну с такой чушью даже банальный recursive descent на ура справляется.

WH> А тут уже рулит Pratt со страшной силой.

Уболтали. Пойду на Пратта смотреть внимательнее.

А>> Откуда там тормоза?
WH>От того что запоминание требует вычислительных ресурсов и обращий к памяти, а это уже пошли промахи кеша и тому подобные радости.

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

А>>Память жрет, да, ну так на кой надо жрать больше чем на один top level declaration?
WH>Если запоминать не все, то это уже не пакрат.

Почему не пакрат? Очень даже пакрат, только ленивый. Сожрали top level declaration, GC все запомненное и прибрал, а парсер лениво дальше хреначит, до следующего declaration.

А>> Ну и что не так с Packrat?
WH>Тормоза и дикий жор памяти.

На практике особых проблем не наблюдается.

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

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

I>>А нельзя ли вместо Pratt заюзать другое слово ? А то сильно созвучно с Prat
WH>Нельзя. Ибо автора завут: Vaughan Pratt
WH>http://en.wikipedia.org/wiki/Pratt_parser

Можно. Например Vaughan.

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

VD>>Пакрата бояться в лес не ходить. Левую рекурсию он не поддерживает.

А> Чо, правда? http://www.cs.ucla.edu/~todd/research/pepm08.html

Правда. То на что ты дал ссылку — это не Пакрат. Если ты почитаешь эту работу, то поймешь, что от простоты пакрата там камня на камне не остается. Остаются только минусы.

VD>> И сам по себе он на практике не применим в следствии дичайших тормозов.

А> Откуда там тормоза? Память жрет, да, ну так на кой надо жрать больше чем на один top level declaration?

От туда. Чтобы жрать память тоже надо время. Это очередной бесплатный сыр.
Единственный способ оптимизации Пакрата который дает реальный выигрышь — это устранение мемоицации (сокращение).
Об этом уже куча работ понаписана. И в реальных проектах та же фигня. Кури работу по Rats!

VD>> Мы же херной не занимаемся. У нас четкий ценз для алгорита — он должен быть применим для построения парсеров реальных ЯП. И его должно быть можно использовать в IDE.

А> Ну и что не так с Packrat?

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

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

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

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

VD>Правда. То на что ты дал ссылку — это не Пакрат. Если ты почитаешь эту работу, то поймешь, что от простоты пакрата там камня на камне не остается. Остаются только минусы.

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

VD>От туда. Чтобы жрать память тоже надо время. Это очередной бесплатный сыр.
VD>Единственный способ оптимизации Пакрата который дает реальный выигрышь — это устранение мемоицации (сокращение).

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

VD>Об этом уже куча работ понаписана. И в реальных проектах та же фигня. Кури работу по Rats!

Rats! слаб, там и половины возможных оптимизаций нет.

VD>Алгоритм подразумевающий тотальную мемоизацию.

Не обязательно. Достаточно только составные термы запоминать.

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

Не обязательно. Можно легко генерить монолитный код (что я и делаю).

VD>Это здорово с точки зрения расширяемости, но фигово с точки зрения оптимизации.

Одно другому не мешает.

VD>Самое прикольное, что использование TDOP дает не только бесплатное избавление от левой рекурсии, но и такие приятные плюшки как: а) декларативное объявление приоритетов операторов, б) ускорение разбора, в) внятный механизм расширяемости.

Уже понял, что надо на это смотреть внимательнее, спасибо.

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

Боюсь, что это очень зря.

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

А> Так уж и операторов?
А> А фигня вида namespace.class.method(bebebe)[index].method(...).method(...)?

А это и есть операторы. Инфиксный оператор "." (или точнее мебер-эксес). Оператор вызов функции или индексера — вполне себе постфиксные операторы.

WH>> А им одной левой рекурсии маловато. Им еще ассоциативность с приоритетами подавай.

А> Ну с такой чушью даже банальный recursive descent на ура справляется.

А Пратт и есть банальный рекурсивный парсер. Ты его название то хорошо прочел?
Top Down Operator Precedence

Пакрат — это тоже TopDown-парсер. Вот только Pratt (TDOP) специализированный алгоритм для разбора именно операторов с приоритетами. За счет приоритетов он и левую рекурсию щелкает как орешки.

При этом TDOP — это очень простой алгоритм.

WH>> А тут уже рулит Pratt со страшной силой.

А> Уболтали. Пойду на Пратта смотреть внимательнее.

Давно поря. Тем более, что это ну очень простой алгоритм.

А>>> Откуда там тормоза?
WH>>От того что запоминание требует вычислительных ресурсов и обращий к памяти, а это уже пошли промахи кеша и тому подобные радости.

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

Какая к черту семантика? Как алгоритм может семантику предоставлять?
Семантика она может быть у формата — PEG-а. Ну, так она воспроизводится 1 в 1.

А>>>Память жрет, да, ну так на кой надо жрать больше чем на один top level declaration?
WH>>Если запоминать не все, то это уже не пакрат.

А> Почему не пакрат?

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

А>Очень даже пакрат, только ленивый. Сожрали top level declaration, GC все запомненное и прибрал, а парсер лениво дальше хреначит, до следующего declaration.

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

К тому же твой алгоритм никак не пакрат, так как он просто встанет или дико замедлится если в не топ-декларэшон у тебя окажутся какие-то не лево-факторизованные правила. Экспонента есть экспонента. Ее не обойти без предсказания или мемоизации.

А>>> Ну и что не так с Packrat?
WH>>Тормоза и дикий жор памяти.
А> На практике особых проблем не наблюдается.

У тебя явно невнятная практика. Да и пакрата у тебя тоже нет, по твоим же словам.

Здравствуйте, <Аноним>, Вы писали:

А> Так уж и операторов?
А> А фигня вида namespace.class.method(bebebe)[index].method(...).method(...)?
Точка это инфиксный оператор. () и [] суффиксные.
Точке нужна ассоциативность с приоритетами. () и [] нужны только приоритеты.

А> Ну с такой чушью даже банальный recursive descent на ура справляется.
Горой мутного кода и только с приоритетами.
С ассоциативностью не справляется.
Приходится химичить руками.

А> Семантика все равно гораздо больше радостей предоставляет, рядом с этим тормоза парсера несущественны.
Ошибаешься.
Особенно в свете поддержки интелисенса. Это когда парсить нужно на каждое нажатие клавиши пользователем.

А> На практике особых проблем не наблюдается.
Я не знаю что у тебя там за практика но мои и не только мои измерения показывают что мемоизация тормозит.
Самые сильные оптимизации в парсере Rats! занимаются убиванием мемоизации...

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

I>Кто тебе сказал что у нас чего то нет ?

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

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

VD>Это имя автора алгоритма. Алгоритм называется Top Down Operator Precedence (TDOP).

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

P.S. Чел, который дал имя Nemerle вероятно прочитал только одну книгуУрсулы Ле Гуин. Прочитай он все, наверняка дал бы другое имя. Как корабль назовете, как говорится. Если Немерле повторит путь своего героя, то мелькнёт на арене всего разок, по крупному и про него забудут уже к началу второй книги, а их целых 4 !

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

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

VD>Ты. Ты же сам сказал, что у вас при сборке периодически приходится ТФС ручками снимать, так как он что-то там блокирует.

Глюки ТФС и сборка в один клик это разные вещи. ТФС иногда глючит только в одной из конфигураций

ВПН, отваливающиеся тесты, релизноты занимают куда больше времени.

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

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

I>Вот и в тебе заговорил ВладД2

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

Ви так говорите, что можно подумать, что ВладД2 — это что-то плохое! (с)

I>Т.е. меня интересует именно легаси код Немерла взрослого проекта, а не компилятора/демки/куркулятора. Интересует с целью выяснить, во что превращается проект через год-два скажем.

I>Наверняка у тебя в проекте есть куча классов общего назначения, которые делают чтото полезное и правятся месяцами а то и годами, правильно ? Вот на них и интересно взглянуть. Желательно без макросов и что бы PM проявился по-взрослому.

I>Например проекты на С++ после смены состава команды часто скатываются в какую то вакханалию в коде. С питоном например такого не происходит. Мне важно знать, что будет с Немерле.

То во что превращается проект зависит не от языка, от людей его поддерживающих.

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

I>В энтерпрайзе свобода выбора технических решений как правило сильно ограничена. Мне лично, например, нравится Mercurial, а не TFS. Но все наши проекты за малым исключением на TFS и я точно знаю что Меркуриала в обозримом будущем точно не будет.

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

Чушь. Это зависит не от энтерпрайза, а от элементарной забюракратизованности конторы и/или ссыкливости энтерпрайз манагеров. А энтерпрайз сюда как опровдание приплели сами же бюрократы и их пособники.

ЗЫ. Если что, я сам работаю в большом-большом энтерпрайзе, человек на тыши три одних только дотнетчиков. Тем не менееи у нас в команде с успехом используется git, так что не надо.

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

I>В энтерпрайзе свобода выбора технических решений как правило сильно ограничена. Мне лично, например, нравится Mercurial, а не TFS. Но все наши проекты за малым исключением на TFS и я точно знаю что Меркуриала в обозримом будущем точно не будет.

Вы сами кузнецы вашего горя. И этерпрайз тут не причем. Вот у IT тоже энтерпрайз (крупнейший банк в штатах), но они таки рассматривают применение git-а.

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

I>По этой причине очень странно слышать "А ты слышал, что есть люди что живут вообще без продуктов от MS?" при чем от человека, который пользует офис, вижлу, винду, .Net и прочую дрянь от того же Микрософта.

Человек не пеняет на энтерпрайзы. Если у МС нет приличного решения проблемы, то берет другое, приличное. Только и всего.
Офис, вижлу, винду и .Net удовлетворяют потребностям. А вот C# перестал. Вот человек и нашел другой язык. Даже пришлось взяться за его разработку.

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

I>Можно. Например Vaughan.

Ой, не надо. Я это даже произнести то не могу

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

I>>Наверняка у тебя в проекте есть куча классов общего назначения, которые делают чтото полезное и правятся месяцами а то и годами, правильно ? Вот на них и интересно взглянуть. Желательно без макросов и что бы PM проявился по-взрослому.

I>>Например проекты на С++ после смены состава команды часто скатываются в какую то вакханалию в коде. С питоном например такого не происходит. Мне важно знать, что будет с Немерле.

VD>То во что превращается проект зависит не от языка, от людей его поддерживающих.

То есть, в с++ вдруг появится рефакторинг, быстрая сборка, толковые исключения, лямбды и паттерн матчинг ? Вот так чудеса.

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

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

I>Глюки ТФС и сборка в один клик это разные вещи.

Это как, если надо что-то руками снимать?

I>ТФС иногда глючит только в одной из конфигураций

ВПН, отваливающиеся тесты, релизноты занимают куда больше времени.

Ню-ню. Я бы еще понял, если бы ТФС-у заменя не было. Но, блин, есть Гит, есть Меркури. Они ведь в разы удобнее, быстрее и надежнее.

Ладно. Тешти себя "релизнотами".

I>Шас ты вероятно скажешь, что релизноты у тебя генерятся автоматом, впн никогда не падает, а тесты всегда зелёные, правильно ? Ну может добавишь, что все это благодаря немерлу

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

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

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

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

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

IT>Чушь. Это зависит не от энтерпрайза, а от элементарной забюракратизованности конторы и/или ссыкливости энтерпрайз манагеров. А энтерпрайз сюда как опровдание приплели сами же бюрократы и их пособники.

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

IT>ЗЫ. Если что, я сам работаю в большом-большом энтерпрайзе, человек на тыши три одних только дотнетчиков. Тем не менееи у нас в команде с успехом используется git, так что не надо.

А не ты ли рассказывал, что нельзя ничего протащить толкового, вроде Немерле ? Опаньки !

Проекты вы сами делаете или вместе с другим N-коммандами ? Переведи все три тыщи дотнетчиков на Git, поговорим про CVS и ТФС, идёт ?

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

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

I>>Можно. Например Vaughan.

VD>Ой, не надо. Я это даже произнести то не могу

.

Произносится как Ван.

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

I>>В энтерпрайзе свобода выбора технических решений как правило сильно ограничена. Мне лично, например, нравится Mercurial, а не TFS. Но все наши проекты за малым исключением на TFS и я точно знаю что Меркуриала в обозримом будущем точно не будет.

VD>Вы сами кузнецы вашего горя. И этерпрайз тут не причем. Вот у IT тоже энтерпрайз (крупнейший банк в штатах), но они таки рассматривают применение git-а.

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

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

I>>По этой причине очень странно слышать "А ты слышал, что есть люди что живут вообще без продуктов от MS?" при чем от человека, который пользует офис, вижлу, винду, .Net и прочую дрянь от того же Микрософта.

VD>Человек не пеняет на энтерпрайзы. Если у МС нет приличного решения проблемы, то берет другое, приличное. Только и всего.
VD>Офис, вижлу, винду и .Net удовлетворяют потребностям. А вот C# перестал. Вот человек и нашел другой язык. Даже пришлось взяться за его разработку.

Для 10 человек это очень просто. А вот для 10 команд это совсем не просто, наверняка найдутся сторонники и противники разных версий. Многим нарпример Git не нравится

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

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

I>То есть, в с++ вдруг появится рефакторинг,
Штука полезная но не критичная.

I>быстрая сборка,
Разбей проект на кучу маленьких dll/so/или что там под той платформой под которую ты пишешь.

I>толковые исключения,
Исключения как исключения. В чем проблема?

I>лямбды и паттерн матчинг ? Вот так чудеса.
Можно и без них писать.
Кода получается конечно больше но это не повод превращать его в говнокод.

I>У меня как то все проще — если вдруг приходится лезть в С++, то ничего из перечисленного я там не обнаруживаю и код тухнет со страшной силой.
А у меня не тухнет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

I>>Глюки ТФС и сборка в один клик это разные вещи.

VD>Это как, если надо что-то руками снимать?

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

I>>ТФС иногда глючит только в одной из конфигураций

ВПН, отваливающиеся тесты, релизноты занимают куда больше времени.

VD>Ню-ню. Я бы еще понял, если бы ТФС-у заменя не было. Но, блин, есть Гит, есть Меркури. Они ведь в разы удобнее, быстрее и надежнее.

Зато у ТФС абслютно адская интеграция в вижлу. Ничего подобного у гита и меркури нет и вскорости не предвидится.

VD>Ну, тесты у меня дейсвительно всегда зеленые. Не зеленые не комитястся.

То есть, зелёные, но не зелёные ? Или ты тяжелые тесты против деплоймента на каждый коммит запускаешь ?

>Перед комитом всегда проходит полная сборка с тестированием.

А тесты против деплоймента куда деть ?

VD>Кстати, сейчас думаем и над тем как релиз-ноты автоматизированно формировать. Оно тоже очень даже полезно.

Возню с трекером все равно не отменить. А это времени больше релизноты подготовить.

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

Качество организации напрямую зависит от количества людей вовлеченных в процесс. Многие конторы даже планку в 30 человек переступить не могут. А когда счет идёт на тысячи крайне странно утверждать что все де легко.

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

А> Я делал реализацию этого алгоритма. Поверх банального пакрата. Всей разницы — надо уметь правильно распознавать рекурсию, и подставлять нужную макру вызова.

Иди почитай про TDOP. Когда ты это сделаешь, ты поймешь, что зря потратил время на этот убогий алгоритм. Дает он мало (приоритеты и ассоциативность не обеспечивает), кода в нем много, скорость отвратная (оптимизаций то нет, а мемоизация полная). Так ради чего на него смотреть?

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

А вот с TDOP мы с ним сразу сошлись на том, что вот это то что нужно. Просто, шустро, расширяемо, решает действительно нужные задачи (разруливает приоритеты и ассоциативность операторов).

Короче, вот здесь все описано довольно детально. Это, к сожалению, до сих пор не реализовано. Вольфхаунд все обещаниями кормит. Но идею понять и оценить можно и с описания.

А>Одна макра простая, вторая чуть посложнее. Код генерится почти одинаковый.

Макра, ленивость... Что у тебя за язык то? Лисп что ли?

VD>>От туда. Чтобы жрать память тоже надо время. Это очередной бесплатный сыр.
VD>>Единственный способ оптимизации Пакрата который дает реальный выигрышь — это устранение мемоицации (сокращение).

А> До того, как я сделал оптимизацию операции выбора по первому символу (простые термы не мемоизируются) было до 300 проходов по одному символу. Теперь — максимум 3. Скорость работы увеличилась пропорционально. Так что полно там возможностей для оптимизации.

Это все мелкие оптимизации. От экспоненты в грамматике они не защитят. У нас тоже подобных оптимизаций штук 5-6. Только они все (каждая) дают процентов по 5-10 и не изменяют алгоритмическую сложность парсера. А вот мемоизация изменяет. Тотальная дает O(n), но при этом убивает на прочь всю производительность. Выходом явилась мемоизация для последнего разбора правила.

VD>>Об этом уже куча работ понаписана. И в реальных проектах та же фигня. Кури работу по Rats!
А> Rats! слаб, там и половины возможных оптимизаций нет.

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

VD>>Алгоритм подразумевающий тотальную мемоизацию.

А> Не обязательно. Достаточно только составные термы запоминать.

Если нет тотальной мемоизации, то нет Пакрата. И нет гарантий линейной сложности.
Сколько раз еще надо это повторить?

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

А> Не обязательно. Можно легко генерить монолитный код (что я и делаю).

Нет смысла. Преимущества теряются. Потом что значит монолитный код?

VD>>Это здорово с точки зрения расширяемости, но фигово с точки зрения оптимизации.

А> Одно другому не мешает.

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

VD>>Самое прикольное, что использование TDOP дает не только бесплатное избавление от левой рекурсии, но и такие приятные плюшки как: а) декларативное объявление приоритетов операторов, б) ускорение разбора, в) внятный механизм расширяемости.

А> Уже понял, что надо на это смотреть внимательнее, спасибо.

Ну, так а что споришь то?

Пойми, мы уже этот путь прошли и бесплатно делимся опытом.

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

А> Боюсь, что это очень зря.

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

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

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

I>Энтерпрайз как правило забюрократизирован.

Как правило, это отговорки. До моего текущего интерпрайза мне довелось поработать в интерпрайзе Banc of America Securities и IBM. И там и там тоже всё решалось командой.

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

Что такое направление в контексте энтерпрайза я не знаю.

IT>>ЗЫ. Если что, я сам работаю в большом-большом энтерпрайзе, человек на тыши три одних только дотнетчиков. Тем не менееи у нас в команде с успехом используется git, так что не надо.
I>А не ты ли рассказывал, что нельзя ничего протащить толкового, вроде Немерле ? Опаньки !

Протащить можно всё в виде исходных кодов. Для исходников процедура сильно упрощена, если это open source. Например, тот же Git Extensions мы протащили как раз в виде исходников, опробовали и сейчас будем работать над полным дистрибутивам.

I>Проекты вы сами делаете или вместе с другим N-коммандами ? Переведи все три тыщи дотнетчиков на Git, поговорим про CVS и ТФС, идёт ?

Я выше написал, что мы над этим работаем.

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

I>P.S. Чел, который дал имя Nemerle вероятно прочитал только одну книгуУрсулы Ле Гуин. Прочитай он все, наверняка дал бы другое имя.

Вот только не надо мозговедения, плиз.

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

I>>Энтерпрайз как правило забюрократизирован.

IT>Как правило, это отговорки. До моего текущего интерпрайза мне довелось поработать в интерпрайзе Banc of America Securities и IBM. И там и там тоже всё решалось командой.

То есть, команда решает, как будут работать другие, такие же команды ?

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

IT>Что такое направление в контексте энтерпрайза я не знаю.

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

I>>А не ты ли рассказывал, что нельзя ничего протащить толкового, вроде Немерле ? Опаньки !

IT>Протащить можно всё в виде исходных кодов. Для исходников процедура сильно упрощена, если это open source. Например, тот же Git Extensions мы протащили как раз в виде исходников, опробовали и сейчас будем работать над полным дистрибутивам.

А немерле ?

I>>Проекты вы сами делаете или вместе с другим N-коммандами ? Переведи все три тыщи дотнетчиков на Git, поговорим про CVS и ТФС, идёт ?

IT>Я выше написал, что мы над этим работаем.

Отпиши, как всех дотнетчиков переведёте на Git. Будет интересно узнать сколько времени ушло.

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

I>>То есть, в с++ вдруг появится рефакторинг,
WH>Штука полезная но не критичная.

Для легаси кода — крайне критичная.

I>>быстрая сборка,
WH>Разбей проект на кучу маленьких dll/so/или что там под той платформой под которую ты пишешь.

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

А вот в С++ надо приседать вокруг этой скорости и угадывать изменение требований на большой срок вперёд.

I>>толковые исключения,
WH>Исключения как исключения. В чем проблема?

Целая куча ограничений и finally надо эмулировать.

I>>лямбды и паттерн матчинг ? Вот так чудеса.
WH>Можно и без них писать.

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

WH>Кода получается конечно больше но это не повод превращать его в говнокод.

Расскажи это людям которые пишут на С++. Беда в том, что С++ не даёт толком никаких средств для приведения кода в порядок, ни прямых, ни косвенных.

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

I>>У меня как то все проще — если вдруг приходится лезть в С++, то ничего из перечисленного я там не обнаруживаю и код тухнет со страшной силой.
WH>А у меня не тухнет.

Вероятно, ты один над ним и работаешь. Я пока не видел ни одного легаси проекта на С++, где менялись разработчики и был бы более-менее качественный код.

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

I>Для легаси кода — крайне критичная.
Я как бэ на С++ не один год писал.

I>А вот в С++ надо приседать вокруг этой скорости и угадывать изменение требований на большой срок вперёд.
Понятно. Писать на С++ не умеешь.

I>Целая куча ограничений и
Каких?

I>finally надо эмулировать.
Зачем?
В С++ есть гораздо более правильный способ очищать ресурсы.
Деструктор называется.

I>Расскажи это людям которые пишут на С++. Беда в том, что С++ не даёт толком никаких средств для приведения кода в порядок, ни прямых, ни косвенных.
Я сам очень много кода на С++ написал.
А те люди которые превращают код в говно превратят его в говно на любом языке.

I>Вероятно, ты один над ним и работаешь. Я пока не видел ни одного легаси проекта на С++, где менялись разработчики и был бы более-менее качественный код.
А я видел.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

I>>Для легаси кода — крайне критичная.
WH>Я как бэ на С++ не один год писал.

Понятно. Писать на С++ не умеешь.

I>>А вот в С++ надо приседать вокруг этой скорости и угадывать изменение требований на большой срок вперёд.
WH>Понятно. Писать на С++ не умеешь.

См выше.

I>>Целая куча ограничений и
WH>Каких?

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

I>>finally надо эмулировать.
WH>Зачем?

Ты что, никогда не пользовал исключения SEH, что тебе такое объяснять надо ?

WH>В С++ есть гораздо более правильный способ очищать ресурсы.
WH>Деструктор называется.

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

Ты точно писал на С++ ? А то я уже начинаю сомневаться

I>>Расскажи это людям которые пишут на С++. Беда в том, что С++ не даёт толком никаких средств для приведения кода в порядок, ни прямых, ни косвенных.
WH>Я сам очень много кода на С++ написал.

Я и говорю — ты один работал, ну или близко к этому

WH>А те люди которые превращают код в говно превратят его в говно на любом языке.

Код всегда превращается в говно, если его не чистить, не причесывать и тд и тд.

В С++ нет ровным счетом ничего, что облегчит эту работу.

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

WH>>В С++ есть гораздо более правильный способ очищать ресурсы.
WH>>Деструктор называется.
I>Ну да, круто — на пустом месте создавать класс только для того что бы ресурсы освободить.
I>Ты точно писал на С++ ? А то я уже начинаю сомневаться

Разговаривать с тобой больше не о чем.
С++ ты не знаешь совершенно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

WH>>>Деструктор называется.
I>>Ну да, круто — на пустом месте создавать класс только для того что бы ресурсы освободить.
I>>Ты точно писал на С++ ? А то я уже начинаю сомневаться

WH>Разговаривать с тобой больше не о чем.
WH>С++ ты не знаешь совершенно.

Ты похоже не только не знаешь, но даже и не понимаешь, ради чего ЯВУ и нужны, насмотря на то что есть С++.

В отсутствие лямбд, finally и прочей дряни, нужно приседать с макросами, функторами и вводить непотребство в код исключительно из за "возможностей" С++.

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

Z>>То, что все будет на TFS решил какой-то человек. Если подойти к нему и внятно объяснить преимущества mercurial и если эти преимущества действительно есть и если этот человек радеет за дело, а не за то, чтобы его поменьше тревожили, тогда все будет.

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

И? Как это противоречит моим словам? Ежу понятно, что джуниора без репутации он слушать не будет. Что друга индуса, которому давно доверяет, будет слушать больше. Принцип не меняется, если ты сможешь его убедить — меркуриал будет.

Ты в чем меня убедить пытаешься? Что у тебя в организации полная задница? Что в твоем энтерпрайзе меркуриал/немерл продвинуть не получится? Мне как-то до лампочки, Java ваш лучший выбор.

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

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

I>Ты похоже не только не знаешь, но даже и не понимаешь, ради чего ЯВУ и нужны, насмотря на то что есть С++.

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

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

А в отсутствии nemerle надо изобретать T4, постшарп, приседать с визиторами и загрязнять код многоэтажными типами. Неужели ты не видишь, что ты сам выбрал какую-то границу фич в языке и пытаешься тут доказать, что твоя граница единственно верная?

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

IT>>Как правило, это отговорки. До моего текущего интерпрайза мне довелось поработать в интерпрайзе Banc of America Securities и IBM. И там и там тоже всё решалось командой.
I>То есть, команда решает, как будут работать другие, такие же команды ?

Такая команда есть в моей текущей конторе. Результат от навязывания ей своих решений другим оказался моло эффективным.

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

Быть очень просто — люди должны между собой договориться.

IT>>Протащить можно всё в виде исходных кодов. Для исходников процедура сильно упрощена, если это open source. Например, тот же Git Extensions мы протащили как раз в виде исходников, опробовали и сейчас будем работать над полным дистрибутивам.
I>А немерле ?

А немерле только что вышел в релизе.

IT>>Я выше написал, что мы над этим работаем.
I>Отпиши, как всех дотнетчиков переведёте на Git. Будет интересно узнать сколько времени ушло.

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

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

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

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

Это полностью опровергают твою идею "То, что все будет на TFS решил какой-то человек. Если подойти к нему ..."

Представь, что ктото хочет не Git, а Bazaar, а или Mercurial, и тоже идёт к этому человеку. А потом ктото еще чего то захочет и тоже пойдет к этому боссу. Подумай головой — если одного похода к человеку достаточно, то это VCS может менять кто угодно, когда угодно и это будет тупо вакханалия.
Думаешь этот главный босс каждый раз будет выслушивать и каждый раз принимать решения о переходе на другой VCS

Вобщем ты уже понял — в тебе говорит русский менталитет, эдакая надежда на доброго царя или волшебника в голубом вертолёте.

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

На всякий повторю еще раз — не сходить и поговорить, а работать, работать, работать, работать...

Z>Ты в чем меня убедить пытаешься? Что у тебя в организации полная задница? Что в твоем энтерпрайзе меркуриал/немерл продвинуть не получится? Мне как-то до лампочки, Java ваш лучший выбор.

Да, похоже, это патология. Стоит рассказать реальный случай, как тебе мерещится что это мой случай

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

Ты решил в энтерпрайзе все такие белые и пушистые. В _любой_ организации где больше примерно 200 человек начинается бюрократия и интриги. В _любой_.

Если непонятно, то еще раз — в _любой_.

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

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

На примере "То, что все будет на TFS решил какой-то человек. Если подойти к нему ..."

Вот пришел ты, поговорил, и может оказаться, что чей то бюджет/перспективы уменьшатся из за перехода на Git. Ты думаешь все тупо поднимут лапки и будут смотреть на переход на Git ?

На всякий — в _любой_.

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

I>>Ты похоже не только не знаешь, но даже и не понимаешь, ради чего ЯВУ и нужны, насмотря на то что есть С++.

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

Я об чем и говорю

И я хочу проверить ограничения Nemerle изучив легаси-код.

hi_octate утверждает, что нужен рефакторинг. А это значит есть большой шанс что код требует бОльших усилий.

Я при всем желани самостоятельно не смогу написать легаси-код среднего по стране качества

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

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

Z>А в отсутствии nemerle надо изобретать T4, постшарп, приседать с визиторами и загрязнять код многоэтажными типами.

Не в отсутствие немерле, а благодаря языку,
1 уровня которого недостаточно для решаемых задач
2 входной уровень выше имеющегося контингента на рынке труда.

Сравни разницу со своими словами и моими.

>Неужели ты не видишь, что ты сам выбрал какую-то границу фич в языке и пытаешься тут доказать, что твоя граница единственно верная?

Я все время говорю про мейнстрим, а не про написание компиляторов "языка средней сложности" @ один из немерлистов

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

IT>>>Как правило, это отговорки. До моего текущего интерпрайза мне довелось поработать в интерпрайзе Banc of America Securities и IBM. И там и там тоже всё решалось командой.
I>>То есть, команда решает, как будут работать другие, такие же команды ?

IT>Такая команда есть в моей текущей конторе. Результат от навязывания ей своих решений другим оказался моло эффективным.

Ну этого и стоило ожидать

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

IT>Быть очень просто — люди должны между собой договориться.

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

I>>А немерле ?

IT>А немерле только что вышел в релизе.

Годится

Это, кстати, не мешало немерлистам записать в ретрограды и неофобы всех, кто не попробовал Немерле за 5 лет до релиза(и не мешает).

IT>>>Я выше написал, что мы над этим работаем.
I>>Отпиши, как всех дотнетчиков переведёте на Git. Будет интересно узнать сколько времени ушло.

IT>Всех мы переводить никуда не собираемся. Не старушки, чтобы их через дорогу переводить. Каждый сам решает, что ему нужнее и целесообразнее использовать.

Ну хотя бы основную массу или значительный процент.

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

IT>>Быть очень просто — люди должны между собой договориться.

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

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

IT>>А немерле только что вышел в релизе.
I>Годится

Это, кстати, не мешало немерлистам записать в ретрограды и неофобы всех, кто не попробовал Немерле за 5 лет до релиза(и не мешает).

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

IT>>Всех мы переводить никуда не собираемся. Не старушки, чтобы их через дорогу переводить. Каждый сам решает, что ему нужнее и целесообразнее использовать.
I>Ну хотя бы основную массу или значительный процент.

Ещё раз — каждый решает сам. В нашей конторе полно как сильных команд, так и откровенных болотцев. В болотца мне лезть нет никакого интереса, а адекватные ребята сами в состоянии принимать решения.

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

I>Код всегда превращается в говно, если его не чистить, не причесывать и тд и тд.
I>В С++ нет ровным счетом ничего, что облегчит эту работу.

Согласен с обоими утверждениями. Только вот причесывать код можно вручную. И если ты выбрал С++, то надо делать это. Иначе судьба кода предрешена.

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

I>Это полностью опровергают твою идею "То, что все будет на TFS решил какой-то человек. Если подойти к нему ..."

I>Представь, что ктото хочет не Git, а Bazaar, а или Mercurial, и тоже идёт к этому человеку. А потом ктото еще чего то захочет и тоже пойдет к этому боссу. Подумай головой — если одного похода к человеку достаточно, то это VCS может менять кто угодно, когда угодно и это будет тупо вакханалия.
I>Думаешь этот главный босс каждый раз будет выслушивать и каждый раз принимать решения о переходе на другой VCS

I>Вобщем ты уже понял — в тебе говорит русский менталитет, эдакая надежда на доброго царя или волшебника в голубом вертолёте.

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

I>Очевидно, в энтерпрайзе это не пройдет. И здесь, что бы сменить VCS не только у себя на проекте нужно работать, работать, работать, работать... Ну, ты понял

И энтерпрайз ты снова приплел зря. Работать надо, кто спорит?

I>На всякий повторю еще раз — не сходить и поговорить, а работать, работать, работать, работать...

Поговорить и убедить. Если статуса не хватает, то работать, работать, работать, работать и в результате убедить.

Z>>Ты в чем меня убедить пытаешься? Что у тебя в организации полная задница? Что в твоем энтерпрайзе меркуриал/немерл продвинуть не получится? Мне как-то до лампочки, Java ваш лучший выбор.

I>Да, похоже, это патология. Стоит рассказать реальный случай, как тебе мерещится что это мой случай

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

У тебя одни реальные случаи, у других другие. Ты с большим апломбом выдаешь свой неудачный опыт за всеобщую картину мира. Я работал в больших организациях и прекрасно знаю какой там серпентарий. Знаю и то, что в них есть отделы с нормальными начальниками которые сами определяют как и с чем работает их отдел. Если не хватает их прямых полномочий — идут к своему начальству и доказывают, что меркуриал нужен.

I>Ты решил в энтерпрайзе все такие белые и пушистые. В _любой_ организации где больше примерно 200 человек начинается бюрократия и интриги. В _любой_.

Приписать оппоненту бред и уверенно опровергнуть. У тебя это уже не первый раз.

I>Выглядит это например так — есть люди, которые хотят сдать проект, есть люди которые хотят заработать денег, есть люди которые хотят избежать проблем и рисков, а есть люди, которые хотят занять должность.

I>Соответсвенно, решение проводится с учетом этим факторов. А поскольку энтерпрайз это как правило крупные организации, то всего и везде нужно согласовывать интересы разных игроков.

I>На примере "То, что все будет на TFS решил какой-то человек. Если подойти к нему ..."

I>Вот пришел ты, поговорил, и может оказаться, что чей то бюджет/перспективы уменьшатся из за перехода на Git. Ты думаешь все тупо поднимут лапки и будут смотреть на переход на Git ?

Ты решил всех разрабов на всех проектах против их воли перевести на гит? Удачи.

Энтерпрайз, энтерпрайз... Не надо ссать против ветра.

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

I>>Код всегда превращается в говно, если его не чистить, не причесывать и тд и тд.
I>>В С++ нет ровным счетом ничего, что облегчит эту работу.

VD>Согласен с обоими утверждениями. Только вот причесывать код можно вручную. И если ты выбрал С++, то надо делать это. Иначе судьба кода предрешена.

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

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

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

Лямбды не имеют отношения к качеству кода. Они имеют отношение к его выразительности. Иметь качественный код можно даже на ассемблере. Зависит это только от людей.

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

ЗЫ

Кстати, очень характерно, что когда ты смотрешь на С++ с высоты знания C#, то отчетливо видишь большую C#. Но когда ты смотришь на C#, то ты не в силах заметить, что C# более низкоуровневый по сравнению с Nemerle. А меж тем это так. Это парадокс который меня просили тут не озвучивать. Но ты четко его подтверждаешь. Попробуй подумать над тем почему C#-код можно преобразовывать в Nemerle 1 в 1, т.е. без потери читабельности и качества кода, а Nemerle-код в C# без потери читабельности и качества кода преобразовать невозможно. Это обсуждается вот в этой теме.

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

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

VD>Лямбды не имеют отношения к качеству кода. Они имеют отношение к его выразительности. Иметь качественный код можно даже на ассемблере. Зависит это только от людей.

Качественный == выразительный && удовлетворяющий требованиям.

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

Каша как то сильнее всего влияет на производительность. Вот в соседнем форуме некто привел пример http://public.fotki.com/fotodoma/2/trycatch.html

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

Наверняка ты или Ziaw через пару тройку сообщений скажете что это мой код

VD>ЗЫ

VD>Кстати, очень характерно, что когда ты смотрешь на С++ с высоты знания C#, то отчетливо видишь большую C#. Но когда ты смотришь на C#, то ты не в силах заметить, что C# более низкоуровневый по сравнению с Nemerle. А меж тем это так.

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

>Это парадокс который меня просили тут не озвучивать. Но ты четко его подтверждаешь. Попробуй подумать над тем почему C#-код можно преобразовывать в Nemerle 1 в 1, т.е. без потери читабельности и качества кода, а Nemerle-код в C# без потери читабельности и качества кода преобразовать невозможно.

см выше.

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

I>>Вобщем ты уже понял — в тебе говорит русский менталитет, эдакая надежда на доброго царя или волшебника в голубом вертолёте.

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

Уже оказывается надо иметь и авторитет, а начиналось то всё просто

I>>Очевидно, в энтерпрайзе это не пройдет. И здесь, что бы сменить VCS не только у себя на проекте нужно работать, работать, работать, работать... Ну, ты понял

Z>И энтерпрайз ты снова приплел зря. Работать надо, кто спорит?

Ну ты ж сказал, что надо просто пойти да поговорить.

I>>На всякий повторю еще раз — не сходить и поговорить, а работать, работать, работать, работать...

Z>Поговорить и убедить. Если статуса не хватает, то работать, работать, работать, работать и в результате убедить.

О, уже статус нужен. Т.е. задача стала "пойти поговорить"+"авторитет"+"статус"

I>>Да, похоже, это патология. Стоит рассказать реальный случай, как тебе мерещится что это мой случай

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

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

Скажи честно, если я рассказываю про аварию, тебе кажется, что это меня задавило машиной и я умер ?

>Я работал в больших организациях и прекрасно знаю какой там серпентарий.

Значит "пойти поговорить"+"авторитет"+"статус"+"опыт работы в серпентарии"

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

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

Значит "пойти поговорить"+"авторитет"+"статус"+"опыт работы в серпентарии"+"должность"+"убедить посредника"

I>>Ты решил в энтерпрайзе все такие белые и пушистые. В _любой_ организации где больше примерно 200 человек начинается бюрократия и интриги. В _любой_.

Z>Приписать оппоненту бред и уверенно опровергнуть. У тебя это уже не первый раз.

Cуди сам:
"пойти поговорить" vs "пойти поговорить"+"авторитет"+"статус"+"опыт работы в серпентарии"+"должность"+"убедить посредника"

и левая и правая части с твоих слов.

I>>Вот пришел ты, поговорил, и может оказаться, что чей то бюджет/перспективы уменьшатся из за перехода на Git. Ты думаешь все тупо поднимут лапки и будут смотреть на переход на Git ?
Z>Ты решил всех разрабов на всех проектах против их воли перевести на гит? Удачи.

И кто сейчас бред выдаёт ?

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

Z>Энтерпрайз, энтерпрайз... Не надо ссать против ветра.

Ну так не ссы, кто ж тебя заставляет то ?

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

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

I>Каша как то сильнее всего влияет на производительность. Вот в соседнем форуме некто привел пример http://public.fotki.com/fotodoma/2/trycatch.html

I>Покажи внятно, как и за счет чего можно повысить производительность человека, которому надо внести изменения в такой код.
Это говнокод обыкновенный.
Причем тут С++ не ясно.

I>Наверняка ты или Ziaw через пару тройку сообщений скажете что это мой код

Это твой код!
Доволен?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

I>>Покажи внятно, как и за счет чего можно повысить производительность человека, которому надо внести изменения в такой код.
WH>Это говнокод обыкновенный.
WH>Причем тут С++ не ясно.

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

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

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

Посему совсем неудивительно видеть такие простыни на в коде на С++.

I>>Наверняка ты или Ziaw через пару тройку сообщений скажете что это мой код

WH>Это твой код!
WH>Доволен?

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

I>Скажи честно, если я рассказываю про аварию, тебе кажется, что это меня задавило машиной и я умер ?

Ок, ответь плиз:
а) ты про свою организацию рассказываешь.
б) ты про свою организацию рассказываешь и пытаешься доказать, что везде так.
в) в твоей организации все ок, но во всем другом энтерпрайзе адъ и трэшъ, заставляют использовать неудобный TFS, когда люди обосновано хотят меркуриал.

I>"пойти поговорить" vs "пойти поговорить"+"авторитет"+"статус"+"опыт работы в серпентарии"+"должность"+"убедить посредника"

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

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

I>И кто сейчас бред выдаёт ?

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

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

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

Что из этого следует? Следует то, что в энтерпрайзе есть люди, которые могут "пойти и внятно объяснить", а есть те, которым не хватает "авторитет"+"статус"+"опыт работы в серпентарии"+"должность"+"убедить посредника". Опять же, проблема не в энтерпразей.

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

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

I>>Скажи честно, если я рассказываю про аварию, тебе кажется, что это меня задавило машиной и я умер ?

Z>Ок, ответь плиз:
Z>а) ты про свою организацию рассказываешь.

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

Z>б) ты про свою организацию рассказываешь и пытаешься доказать, что везде так.

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

Z>в) в твоей организации все ок, но во всем другом энтерпрайзе адъ и трэшъ, заставляют использовать неудобный TFS, когда люди обосновано хотят меркуриал.

Не все в порядке, но бывает всякое. Тут как на форуме — раз ты склонен мерять всех по себе, то не стоит удивляться, что часто так и действуешь

Главное не злоупотреблять этим

I>>"пойти поговорить" vs "пойти поговорить"+"авторитет"+"статус"+"опыт работы в серпентарии"+"должность"+"убедить посредника"

Z>Не искажай цитаты: "пойти и внятно объяснить". Так вот это то, что надо сделать. При некоторых условиях, которые я привел там же, это скорее всего приведет к желаемому результату.

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

Z>"авторитет"+"статус"+"опыт работы в серпентарии"+"должность"+"убедить посредника" это детали, которые тебе придется применять для достижения цели.

Эти детали никакие не детали, а собственн полезная информация, ровно то, что отделяет энтерпрайз от неэнтерпрайза.

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

Дьявол он как говорится в деталях.

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

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

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

Один из — означает что есть и другие, тоже важные игроки.

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

Z>Что из этого следует? Следует то, что в энтерпрайзе есть люди, которые могут "пойти и внятно объяснить", а есть те, которым не хватает "авторитет"+"статус"+"опыт работы в серпентарии"+"должность"+"убедить посредника". Опять же, проблема не в энтерпразей.

Проблема изначально не в энтерпрайзе, а в людях. В энтерпрайзе она всего лишь проявляется во всей красе.

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

	От:	Darooma
	Дата:	22.05.11 19:35
	Оценка:

	От:	Ka3a4oK
	Дата:	22.05.11 19:56
	Оценка:

	От:	alvas
	Дата:	22.05.11 20:14
	Оценка:

	От:	catbert
	Дата:	22.05.11 21:28
	Оценка:	3 (1)

	От:	hi_octane
	Дата:	22.05.11 21:34
	Оценка:	202 (14) +3

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	22.05.11 22:30
Оценка:

От:	VladD2	www.nemerle.org
Дата:	23.05.11 09:53
Оценка:

От:	_nn_	www.nemerleweb.com
Дата:	23.05.11 17:13
Оценка:	18 (1) +1

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	24.05.11 07:50
Оценка:

От:	IT	linq2db.com
Дата:	24.05.11 19:13
Оценка:	+1