Здравствуйте, FR, Вы писали:
FR>Давай ты не будешь мне рассказывать про игры. FR>По твоему отладка, трассировка и тестирование не часть разработки? FR>В играх кстати это очень существенная часть.
Ты намеренно подменяешь понятия. Мы говорили о разработке софта с помощью РЕЛП-а. Консоли в играх не РЕПЛ. То что и там, и там есть консоль не значит, что они тождественны и одно можено приводить в качестве доказательства другого.
Ты говорил что? Что в игры встраиваются РЕПЛ-ы. Это беспардонное вранье. И ты это знаешь. И у тебя хватает наглости заниматься софистикой оправдывая свои слова. В общем, извини, но мне игры в аратора не интересны. Ты сюда поупражняться ходишь. А я лучше займусь чем-нибудь полезным.
FR>Ты хоть раз Смаллтолк запускал?
Да и не раз.
FR>Я хоть только и баловался, но сразу же залез в том же Dolphin в Tools/Workspace который представляет собой repl в чистом виде. В других смаллталках он тоже обязательно присутствует.
Это не репл. Это как раз IDE в функции которой входит в том числе и замена кода на лету.
FR>В смаллтолке нет конечно, там есть образ который без проблем меняется на ходу. Зато в питоне есть модули и REPL позволяет их перезагружать, в итоге получаем тоже самое.
Ну, дык Питон и тормозит как черт знает что. Какова архитектура, таков и результат.
Чем более динамиченый язык, тем проще в нем менять что-то на лету, но тем он тормознее и ненадежнее. Две стороны одной медали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Ты намеренно подменяешь понятия. Мы говорили о разработке софта с помощью РЕЛП-а. Консоли в играх не РЕПЛ. То что и там, и там есть консоль не значит, что они тождественны и одно можено приводить в качестве доказательства другого.
Во первых я сказал как "Как упрощенный пример", во вторых в некоторые игры именно встраивается нормальная питоновская консоль, для разработческой версии.
VD>Ты говорил что? Что в игры встраиваются РЕПЛ-ы. Это беспардонное вранье. И ты это знаешь. И у тебя хватает наглости заниматься софистикой оправдывая свои слова. В общем, извини, но мне игры в аратора не интересны. Ты сюда поупражняться ходишь. А я лучше займусь чем-нибудь полезным.
Угу а то что я сам встраивал тот же PyCrust в игру это мне приснилось. Нет Влад телепат из тебя очень паршивый. Насчет заняться чем то полезным ты прав, у нас почему-то почти всегда ругань получается
FR>>Ты хоть раз Смаллтолк запускал?
VD>Да и не раз.
Не похоже.
VD>Это не репл. Это как раз IDE в функции которой входит в том числе и замена кода на лету.
Это репл органично встроенный в IDE
FR>>В смаллтолке нет конечно, там есть образ который без проблем меняется на ходу. Зато в питоне есть модули и REPL позволяет их перезагружать, в итоге получаем тоже самое.
VD>Ну, дык Питон и тормозит как черт знает что. Какова архитектура, таков и результат.
Здравствуйте, VladD2, Вы писали:
IT>>Писать уже так много и так быстро не надо, нужно больше разбираться в том что сделано, править, рефакторить, добавлять новые фичи, впихивать невпихуемое и т.д.
VD>А что рефактроить без среды проще что ли?
Сложнее.
VD>А разбираться в коде?
Тоже сложно.
VD>Чем круче джип, тем дольше бежать за трактором (с)
Чем дальше в лес, тем жирнее партизаны (c)
VD>Я как раз уверен в обратно. На этапе когда кода уже очень много среда становится если не важнее языка, то по крайней мере ее значимость резко возрастает.
Это потому, что ты смотришь на возможности IDE через призму возможностей, которые нужны лично тебе. А крутые среды на этом не останавливаются. Давно ли ты, например, генерировал типизированные датасеты? Или мапил в редакторе модель данных на объектную модель приложения? Или рисовал в редакторе интерфейс, а среда писала за тебя код? Это всё признаки "крутой" среды и многие ими пользуются чуть ли не чаще, чем пишут код.
VD>Потом на поздних этапах цели проекта могут измениться. Хороший пример тот же немерловый компилятор. Его писали как компилятор командной строки. Причем с целью как можно быстрее получить что-то работающее. Когда компилятор был почти в бэте вдруг выяснилось, что для создания IDE компилятор нужно было писать совсем иначе. Многое нужно делать более детально, а много вообще по другому. Лично ты надорвал пуп когда попытался этот проект отрефакторить. Списав все на кривые руки предшественников ты предложил его переписать с нуля. А я вот мучился изучая проект и рефакторя все это дело вручную. Была бы IDE способная поднять этот проект и автоматизировать рефакториг, я бы давно закончил.
Ты путаешь рефакторинг кода и рефакторинг дизайна. Рефакторинг, который я обычно использую в студии или с помощью Решарпера — это переименование методов, выделение методов, изменения сигнатуры, удаление мусора из кода и прочие мелочи. Это всего лишь автоматизация тупой работы. Повторяю — тупой. Раньше на это уходило от нескольких минут до нескольких часов, сейчас ровно полсекунды. Но это никогда лично для меня не было стопором или чем-то, от чего можно надорвать пуп. Как раз наоборот, делая что-то тупое, отдыхаешь от перегрева мозга, а напрягая извилины отдыхаешь от тупой работы. Такого рефакторинга я и в компиляторе с интеграцией достаточно поделал.
Ты же здесь говоришь о рефакторинге дизайна, а без переписывания всего компилятора это невозможно в принципе. Да ты и сам это уже понял. И была бы у тебя IDE с возможностями даже решарпера, от переписывания всего тебя бы это не спасло никак.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
VD>>Я как раз уверен в обратно. На этапе когда кода уже очень много среда становится если не важнее языка, то по крайней мере ее значимость резко возрастает.
IT>Это потому, что ты смотришь на возможности IDE через призму возможностей, которые нужны лично тебе.
Ну, дык. Я и не агитировал за разные генераторы кода подвешенные на запись файла.
IT>А крутые среды на этом не останавливаются. Давно ли ты, например, генерировал типизированные датасеты?
Давно. И это было несомненно удобнее нежели работать с ХМЛ-ем и БД средствами которые предоставлялись в C# 2.0.
Для 3-его и Немерла такие костыли не нужны. Я с этим и не спорил. Я говорил об IDE, как о средстве работы с проектом.
IT>Или мапил в редакторе модель данных на объектную модель приложения?
Никогда этим не занимался. Но это не важно.
IT>Или рисовал в редакторе интерфейс, а среда писала за тебя код?
И сейчас постараюсь так сделать. Более того для рисования форм выберу C#, а не Немерл просто потому, что там это сделано качественно.
IT> Это всё признаки "крутой" среды и многие ими пользуются чуть ли не чаще, чем пишут код.
В случае форм — это оправдано. Я не вижу преимуществ в нудном долблении кода рисующего кнопки на экране и не вижу смысла делать 10 итераций только ради того, чтобы добиться приемлемого размещения кнопок на форме.
Понятно, что для многих задач рисование GUI — это пренебрежимо малая задача, но есть задачи где GUI много, а кода мало.
Так вот, я не рассматриваю IDE именно как средство работы с кодом. Но дизайнеры тоже не считаю лишней фигней. Другое дело кода дизайнеры закрывают дыры в языке. Это действительно прискорбно.
Но к чему все это?
IT>Ты путаешь рефакторинг кода и рефакторинг дизайна.
Я ничего не путаю. Но чтобы менять дизайн, нужно тупо менять код.
IT>Рефакторинг, который я обычно использую в студии или с помощью Решарпера — это переименование методов, выделение методов, изменения сигнатуры, удаление мусора из кода и прочие мелочи. Это всего лишь автоматизация тупой работы.
Ага. Но сложная работа складывается из многих итераций тупой. А ее приходится делать вручную. И вместо пары часов на серьезное изменение у меня уходит неделя.
IT>Повторяю — тупой. Раньше на это уходило от нескольких минут до нескольких часов, сейчас ровно полсекунды.
Все зависит от запущенности случая. У меня уходили дни! А могли бы уходить минуты.
IT>Но это никогда лично для меня не было стопором или чем-то, от чего можно надорвать пуп. Как раз наоборот, делая что-то тупое, отдыхаешь от перегрева мозга, а напрягая извилины отдыхаешь от тупой работы. Такого рефакторинга я и в компиляторе с интеграцией достаточно поделал.
Вот фиг там. При некотором объеме даже механическая (казалось бы) задача начинает становиться трудной и перегревающей мозг.
IT>Ты же здесь говоришь о рефакторинге дизайна, а без переписывания всего компилятора это невозможно в принципе.
Возможно, но не в условиях когда для переименования поля нужно потратить день.
IT>Да ты и сам это уже понял. И была бы у тебя IDE с возможностями даже решарпера, от переписывания всего тебя бы это не спасло никак.
Нет. Уверен, что при наличии такой IDE я бы сделал код таким как хочу. Меня сейчас останавливает от этого только объем работ и их трудоемкость.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В случае форм — это оправдано.
Для GUI форм да и только потому, что там layout пиксельный. Но для веба и XAML редакторы тоже есть, но генерируют такой код, что лучше бы не генерировали совсем.
VD>Так вот, я не рассматриваю IDE именно как средство работы с кодом. Но дизайнеры тоже не считаю лишней фигней. Другое дело кода дизайнеры закрывают дыры в языке. Это действительно прискорбно.
VD>Но к чему все это?
К тому, что мы начали с того, что важнее IDE или язык и ты сам только что сказал, что IDE (как минимум дизайнеры) часто закрывают дыры в языке.
IT>>Ты путаешь рефакторинг кода и рефакторинг дизайна.
VD>Я ничего не путаю. Но чтобы менять дизайн, нужно тупо менять код.
Путаешь. Давай, например, сравним рефакторинг кода, заключающийся в переименовании метода и рефакторинг кода по устранению статических переменных и переносу их в контекст вызовов. И то и другое рефакторинг. Только один есть тупая работа, а другой может потребовать редизайна приложения и с этим не справится никакой решарпер и пр, которые и метод иногда толком выделить не могут.
VD>Ага. Но сложная работа складывается из многих итераций тупой. А ее приходится делать вручную. И вместо пары часов на серьезное изменение у меня уходит неделя.
Из многих итераций тупой работы складывается только сложная тупая работа. Больше ничего. С помощью тупого переименования методов статика в контекст не перенесётся никак.
IT>>Повторяю — тупой. Раньше на это уходило от нескольких минут до нескольких часов, сейчас ровно полсекунды.
VD>Все зависит от запущенности случая. У меня уходили дни! А могли бы уходить минуты.
Дни? На переименование методов?
IT>>Ты же здесь говоришь о рефакторинге дизайна, а без переписывания всего компилятора это невозможно в принципе.
VD>Возможно, но не в условиях когда для переименования поля нужно потратить день.
Для переименования поля не нужно тратить день. День можно потратить для изменения логики работы с этим полем, это да. Но никакой рефакторинг за тебя это всё равно не сделает.
VD>Нет. Уверен, что при наличии такой IDE я бы сделал код таким как хочу. Меня сейчас останавливает от этого только объем работ и их трудоемкость.
Объём каких работ? Влад, вот давай эксперимент, в следующий раз, когда ты потратишь день на какую-нибудь мелочь, ты расскажешь нам как-бы ты это делал с помощью автоматических средств рефакторинга. OK?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, thesz, Вы писали:
T>>Или, всё же, умнее тебя и лучше программируют. А ты просто завидуешь и пытаешься развести их "на слабо".
VD>Ну, я бы мог сделать смелые предположения и намекнуть тебе на них, но лучше буду операться на факты. А факты у нас очень печальные. Те кто считает себя умнее других не пишет кода который можно было бы с чем-то сравнить.
Здравствуйте, vshabanov, Вы писали:
V>Так и пользуются, в основном логами. И, очень редко, отладчиком. Утверждать, что без него вообще никак работать нельзя, не стоит. Более того, его надо применять, только тогда, когда он действительно нужен. А это бывает редко. Во всех остальных случая он тормозит разработку.
Странные вы люди. Я ной раз дописываю код (меняю его) прямо в отладочной сесси. Вот буквально сейчас...
Сижу переписываю код генерации fake-исходников для эмуляции GOTO когда реальных исходников нет или неизвесно где они лежат.
Какие задачи передо мной стоят?
1. Найти место которое нужно изменить.
2. Подумать как это лучше сделать.
3. Изменить.
4. Протестировать.
5. Если нужно перейти к пункту 2.
Код писал не я. Я только знаю одну входную точку. Что я делаю?
1. Ставлю точку прерывания в это место.
2. Запускаю IDE под отладчиком и выполняю GOTO на тип из системной сборки.
3. Срабатывает прерывание.
4. Брожу по коду и ищу нужное место... О! Нашел.
5. Анализирую это место. Ага! Вижу что не так!
6. Думаю как изменить. Вот тут может потребоваться пойти попить чай, а то и вообще свалить домой и подумать. Но на этот раз все очевидно.
7. Меняю код. При этом у меня работает автодополнение при вооде и в отладчике я вижу реальные типы переменных (язык, таки, поддерживает динамический полиморфизм).
8. Срубаю отладку и жму F5.
9. Пробую переход. О! Работает как надо.
Итак. Я не занимался отладкой как таковой. Мои изменения заработали с первого раза. Но я использовал отладчик и IDE для облегчения свой задачи.
И это не единичный случай. Для меня это тоже самое, что для вас РПЕЛ. Только, пожалуй, мощнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VladD2, Вы писали:
IT>Правы все... или не правы все ... кому как угодно. IT>Процесс разработки софта штука многостадийная и слобопредсказуемая в начале разработки. Выбор языка попроще, но среды покруче даёт быстрый старт проекту и получение удовлетворительного первоначального результата, т.к. логики пока не много, сложность кода легко контролируется даже при использовании языка попроще и во многом компенсируется возможностями среды.
"Не рекомендую. Съедят." (C) Понедельник начинается в субботу
IT>В общем, либо быстрый старт в начале и плохопахнущая куча кода в конце, либо недовольство начальства из-за срывов развития проекта на начальной стадии и травля анекдотов в курилке или в кафешке (вместо того, чтобы заниматься ловлей глюков как все нормальные люди) на завершающей.
Это всё теории.
Моя практика показывает обратное.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, IT, Вы писали:
IT>К тому, что мы начали с того, что важнее IDE или язык и ты сам только что сказал, что IDE (как минимум дизайнеры) часто закрывают дыры в языке.
Не как "минимум", а "только".
IT>Путаешь. Давай, например, сравним рефакторинг кода, заключающийся в переименовании метода и рефакторинг кода по устранению статических переменных и переносу их в контекст вызовов. И то и другое рефакторинг. Только один есть тупая работа, а другой может потребовать редизайна приложения и с этим не справится никакой решарпер и пр, которые и метод иногда толком выделить не могут.
Я не путаю. Чтобы перенести статики мне один фиг понадобятся более простые рефакторинги.
IT>Из многих итераций тупой работы складывается только сложная тупая работа. Больше ничего. С помощью тупого переименования методов статика в контекст не перенесётся никак.
Нет. И не тупая тоже. Статика конечно не перенесется, но нужные для этого преобразования типов и функций можно автоматизировать.
IT>Дни? На переименование методов?
Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное. Плюс сюда накладывается проблема бутсрипа когда просто переименование не прокатывает и 3 минуты на компиляцию.
IT>Для переименования поля не нужно тратить день.
Это реальный факт.
IT>День можно потратить для изменения логики работы с этим полем, это да. Но никакой рефакторинг за тебя это всё равно не сделает.
Нет. Для тупого переименования поля. Никакой логики не менялось. Я уже даже думал писать в компиляторе заплатку которая будет принуждать его генерировать список вхождений переменной. Еще раз повторюсь, что проблема осложнялась бутстрипингом. Два чася я тупо правил переменные по подсказкам компилятора, а потом оказывалось, что просто переименовать ее нельзя, так как она используется в макросе и квази-цитировании. Далее делалась другая попытка на которую тоже уходило два часа тупой работы. Через 8-10 часов я таки победим эту проблему введя fake-поле с тем же именем и поменяв код генерации квази-цитирования. Если бы мне нашли все вхождения (и не явные) этой переменной, то я бы справился бы за час, а то и за 15 минут.
IT>Объём каких работ? Влад, вот давай эксперимент, в следующий раз, когда ты потратишь день на какую-нибудь мелочь, ты расскажешь нам как-бы ты это делал с помощью автоматических средств рефакторинга. OK?
Могу описать тебе задачу и посмеяться над тем как ты будешь ее решать. В прочем я уже дал подсказку которая может сэкономит пол дня.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, thesz, Вы писали:
VD>>Ну, я бы мог сделать смелые предположения и намекнуть тебе на них, но лучше буду операться на факты. А факты у нас очень печальные. Те кто считает себя умнее других не пишет кода который можно было бы с чем-то сравнить.
T>http://thesz.mskhug.ru/svn
50 файлов общим объемом 266 килобайт хаскелевского кода.
Объем проекта ниже среднего.
Что он хоть делает?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, thesz, Вы писали:
VD>>>Ну, я бы мог сделать смелые предположения и намекнуть тебе на них, но лучше буду операться на факты. А факты у нас очень печальные. Те кто считает себя умнее других не пишет кода который можно было бы с чем-то сравнить.
T>>http://thesz.mskhug.ru/svn
VD>50 файлов общим объемом 266 килобайт хаскелевского кода. VD>Объем проекта ниже среднего.
VD>Что он хоть делает?
Модель процессора на основе потока данных.
Три типа разборщиков на монадах.
Разбор Фортрана. Fourier-Motzkin elimination.
Встроенный в Хаскель HDL.
Что-то ещё.
Твой репозиторий где?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
IT>>Дни? На переименование методов?
VD>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное.
Вот именно поэтому я и утверждаю, что экспортировать конструкторы — не след. (Это к нашей с thesz вялой дискуссии).
Здравствуйте, MigMit, Вы писали:
VD>>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное.
MM>Вот именно поэтому я и утверждаю, что экспортировать конструкторы — не след. (Это к нашей с thesz вялой дискуссии).
Причем здесь конструкторы?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Во-первых, сложные рефакторинки тоже автоматизируются. Рефакторинг — это улучшение (или переработка) кода без изменения его функциональности.
Угу, только вот найди мне рефакторинг: «перераспределить обязанности между классами и один из них, возможно, выкинь»
VD>Во-вторых, внесение фич — это огромная ошибка. Сам грешен иногда поддаюсь искушению совместить эти процессы, но понимаю, что делаю плохо. Стимулом к тому как раз является то, что нет хороших средств рефакторинга. А когда делаешь что-то руками то творчество бьет в мозг. Автоматизированный же рефакторинг позволяет рефакторить код большими "транзакциями". Тут уже точно не получится поддаться на искушение.
Ну тут, видимо, опять вопрос в терминологии. Рефакторинг делается перед внесением фичи чтобы облегчить этот процесс. И основной стимул, тут не отсутствие средств (хотя что бы вы знали про vim, sed и awk ), а то что просто переписывание кода — это переливание из пустого в порожнее, т.к. код в итоге будет иметь «идеальную» архитектуру, а заказчик 0 новых функции и столько же багов. Мало того, потом окажется, что архитектура то не идеально и т.п. Основная цель рефаторингов изменить код так, чтоб его было проще менять под текущие и ближайшие цели, т.е. где-то добавить гибкости, где то убавить овердизайна. Ну и что касается твоего поинта: «большие рефакторинги состоят из кучи маленьких», — да, состоят, но по моему опыту занимают они не много времени ( может я их просто не замечаю благодаря «убогим» vim, sed, awk ).
ЗЫ Просьба комментарии в скобочках считать шуткой, с долей правды.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, thesz, Вы писали:
T>Это всё теории. T>Моя практика показывает обратное.
По всей видимости вы вместе со твоей практикой вещи просто уникальные. Вымирающий вид. Любой краеведческий музей через десять лет выделит для вас не то что полку, целый стеллаж!
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, MigMit, Вы писали:
VD>>>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное.
MM>>Вот именно поэтому я и утверждаю, что экспортировать конструкторы — не след. (Это к нашей с thesz вялой дискуссии).
VD>Причем здесь конструкторы?
При том самом. Если внутреняя структура типа видна вне модуля, в котором он определён — пиши пропало, потом нужно будет лазить по исходникам с лупой.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, thesz, Вы писали:
T>>Это всё теории. T>>Моя практика показывает обратное.
IT>По всей видимости вы вместе со твоей практикой вещи просто уникальные. Вымирающий вид. Любой краеведческий музей через десять лет выделит для вас не то что полку, целый стеллаж!
Наоборот.
Мы племя младое, незнакомое!
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, MigMit, Вы писали:
MM>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, MigMit, Вы писали:
VD>>>>Поля. Проблема в том, что место где оно встречается море (десятки тысяч мест) и имя перегруженное.
MM>>>Вот именно поэтому я и утверждаю, что экспортировать конструкторы — не след. (Это к нашей с thesz вялой дискуссии).
VD>>Причем здесь конструкторы?
MM>При том самом. Если внутреняя структура типа видна вне модуля, в котором он определён — пиши пропало, потом нужно будет лазить по исходникам с лупой.
Это идеал, к которому надо вяло стремиться, но достигать не обязательно.
Конструктор — та же функция, и я не вижу причин, по которым я могу экспортировать функцию и не могу конструктор.
То, что конструктор участвует в сравнении с образцом, ничего не меняет. Всё равно мне как-то придётся делать выбор. Хоть pattern guards, хоть view, хоть предикатами.
Только жизнь себе усложню.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
MM>>При том самом. Если внутреняя структура типа видна вне модуля, в котором он определён — пиши пропало, потом нужно будет лазить по исходникам с лупой.
T>Конструктор — та же функция, и я не вижу причин, по которым я могу экспортировать функцию и не могу конструктор.
Ну, блин...
Вот у тебя в одном модуле написано
module A where
data Level = Level Int
raiseLevel :: Level -> Int -> Int
raiseLevel (Level x) y = x+y
А в другом
module B where
import A
defaultLevel = Level 0
Внезапно ты обнаружил, что тип нужно сделать более общим:
module A where
data Level = Level (Int -> Int)
raiseLevel :: Level -> Int -> Int
raiseLevel (Level f) = f
Ищи его теперь в модуле B.
Если же у тебя был экспортирован не конструктор, а смартконструктор
module A (Level, level, raiseLevel) where
data Level = Level Int
level :: Int -> Level
level = Level
то потом всё будет проще:
module A (Level, level, generalLevel, raiseLevel) where
data Level = Level (Int -> Int)
level :: Int -> Level
level n = Level (n +)
generalLevel :: (Int -> Int) -> Level
generalLevel = Level
И в B ничего менять не надо.
T>Только жизнь себе усложню.
Как обычно — немного усложнишь поначалу, зато облегчишь потом.
Если нам не помогут, то мы тоже никого не пощадим.
... кому как угодно.
