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

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

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

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

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

Короче, вот здесь

Автор(ы): Чистяков Владислав Юрьевич
Дата: 07.06.2011
Макрос PegGrammar – это макрос Nemerle, позволяющий добавлять в приложения парсеры, описываемые в нотации PEG.

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

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

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

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

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

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

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

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

См выше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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# без потери читабельности и качества кода преобразовать невозможно. Это обсуждается вот в этой теме

Автор: Димчанский
Дата: 25.05.11

.