***АЛЕКСАНДР***
Простите за безумное количество опечаток :-( Браузер — похоже буквы глотает. А я не стал вычитывать. Если что-то непонятно — поясню. Мне стыдно. В следующий раз — буду вычитывать.
Я когда был на конференции в Казани — где собственно я и познакомился с Всеволодом — уровень некоторых вопросов — МЕНЯ ПОРАЗИЛ. Хотелось встать и сказать — «ребята! коллеги! друзья мои! ну ОТКРОЙТЕ исходный код библиотек и ПОЧИТАЙТЕ! а потом ТОЛЬКО — задавайте вопросы».
И я МНОГО спорил с Максом и не принимал его подход когда-то.
Пока он не показал мне «кодогенрацию». Причём — РЕАЛЬНО. «В байтах» (как пишет Джоэл).
И тогда — я ПОВЕРИЛ Максу — и не жалею.
Появилось именно «логарифмирование» сложности «и быстрое изменение масштаба». Сегодня я программирую UseCase'ы, а завтра — «абстрактные контейнеры». Между ними — ПРОПАСТЬ. Но она мне — НЕ МЕШАЕТ.
«Проблемы» управления БОЛЬШИМ объёмом кода — у нас — реально БЫЛИ. И я не знал — что делать. И эти проблемы — «испарились» — когда я стал рисовать UML-диаграммы. И более того эти диаграммы сейчас читают ДРУГИЕ люди.
P.S. Можно «пинок» Embarcadero? Это наверное особенно «пикантно» смотрится из по аккаунта Всеволода Леонова :-) Я МНОГО пишу о недостатках Embarcadero ;-) Но — ПОКА — не услышан. Так что — не думайте, что это «теория заговора». Мы с Всеволодом — СОТРУДНИЧАЕМ в данной стать. Но! ПОТОМУ, что тема интересная и ВАЖНАЯ. Я лично на неё лет 8-мь жизни потратил. Но это не значит, что Леонов «купил нас» и мы «пиарим» Embarcadero. Или «мы купили» Гарант. И Леонов пиарит его. Нет. Просто — тема интересная. И наши интересы в ней — сошлись. Просто хочется людям рассказать о том, на чем мы давно работаем. А Леонов — это дело — хорошо организовал. И задал ПРАВИЛЬНЫЕ вопросы. Спасибо ему. Но многие вопросы — остались без ответов… Поверьте мне. Если тема интересная — будем продолжать.
Я лично — УВЕРЕН, что тема не только ИНТЕРЕСНАЯ, но и ПРАВИЛЬНАЯ.
P.P.S. Главное слово — «сборочный чертёж».
P.P.P.S. Если кто-то решит меня «потроллить» — пишите уж сразу в «личку». Я уже давно — «вакцинирован». В перепалки — я — не вступаю. Работаю над собой. Отвечаю на КОНКРЕТНЫЕ вопросы.
это из РЕАЛЬНОГО проекта, но опять же — не реальные «картинки» и «код». А их перерисовка.
Поймите правильно — мы работаем в КОММЕРЧЕСКОЙ организации. За зарплату.
Интервью — согласовывалось. Но это не значит, что мы можем в комментариях наносить ущерб работодателю.
Делиться ИДЕЯМИ — ПОЖАЛУЙСТА. Идеи — они во много голов приходят. КОНКРЕТНЫЕ реализации — ТОЛЬКО с согласия РАБОТОДАТЕЛЯ. Может быть Макс — как руководитель — что-то другое может сказать.
И если Макс — даст добро — постараюсь объяснить «на пальцах» — как картинки превращаются в код. Если не даст — не обижайтесь. Имеет право. Это реально его идея.
*** МАКСИМ ***
ну почему же «идиота», на мой взгляд идиоты скорее те (ни кого не хочу обидеть) кто об этом хотя бы не мечтает, вещь в общем-то очевидная: попытаться автоматизировать рутинные процессы
***МАКСИМ***
Вы не совсем правильно поняли, ну или мы не точно выразились. У нас 100% генерация моделей. Те нет моделей (диаграмм) которые бы рисовались просто так, все они генерируют из себя код или какие-либо другие артефакты. Но сам код конечно не на 100% генерируется. Бизнес логика (именно бизнес логика) пишется руками, ее на модели не просто нарисовать, ну или точнее мы пока не реализовали это (идеи есть), но все равно 100% генерируемого кода не будет, да это и не нужно. Генерируется все что подается какой-то структуриизации, укладвается в какой-то шаблон, пусть даже очень сложный (и чем сложнее, тем как правило выше КПД от его использования). А остальное быстрее, проще и гибче руками написать.
Отвечая на вопрос: система контроля версий выглядит стандартно, под ее управлением находятся прежде всего артефакты получаемые после генерации — те код. Но сами файлы модели тоже под ее управлением. Но по сути именно как бинарные (хотя на самом деле они не бинарные, но такого уродского формата, что смерджить их практически не возможно). Это тоже одна из причин почему хочется свой инструмент — что бы файлы модели были «истинно» текстовыми.
***МАКСИМ***
ну мы чужую софтину даже в части рисования сильно кастомизировали, сильно-сильно. Она вообще уже на себя изначальную ни с какого угла не похожа, если честно. Но и этого мало, поэтому и пишем что очень хочется совсем свое написать, уже с учетом всего опыта, заточенное на максимально быстрое создание моделей и генерацию.
***МАКСИМ***
да, я уже коллегам высказал предположение, что должного интереса статья не вызывает именно потому что «много букв» и мало картинок и кода. Даже именно кода. Потому что просто картинки это тоже не интересно. Интересно увидеть как они в код превращаются, «как» и в «какой», и в какое его количество. А вообще прочитайте, там где-то в районе середины как раз про практику, хоть и в виде «много букв». Но… в картинках с кодом, тоже надо будет рассказать. тут я с Вами полностью согласен.
> Ведь UML я так понимаю был создан для того, чтобы Упрощать понимание проектов, а не усложнять их?
именно, но для нас лично даже это уже второстепенно (хотя по прежнему важно), а на первом месте — генерируемый код, как не странно ))
*** МАКСИМ ***
В смысле «мы» ;)
по не до конца понятным мне причинам, руководство просило не раскрывать конкретный инструментарий. Поэтому вынужден отвечать намеками, надеюсь простите. Инструментарий ровно тот, что был на дискете в 97-м году )) Он конечно подрос в размере за последующие годы, но функционально почти не изменился (по крайне мере в той части которая нам нужна). Но, выше в статье, я уже говорил, что для нас это просто рисовалка, все «ценное» (для нас) находится не в ней а в генераторе. А генератор самописный. Если его прицепить к визио — то можно и в визио рисовать. А можно и не рисовать, можно «писать» модель, но это уже на будущее.
Кстати, «водопадную» модель реально нужно обсуждать.
У меня было есть достаточно опыта: работа на гос. структуры по гос. контракту.
Есть «классическое» ТЗ, которое бьется на этапы. Нет, вам вполне позволят написать первым этапом (1-2-3-4 месяца) что угодно. Хоть «сбор и анализ требований», хоть «UML-моделирование», хоть «подготовка первого спринта». Но второй этап уже не должен содержать того, что уже упоминалось в первом этапе. Куратор проекта со стороны заказчика вас будет курировать по ТЗ (которое, опять же — вы сами себе написали, но в жанре «водопадного ТЗ»). Выходов из такой ситуации несколько:
— сказать, что заказчик = дурак, требует невозможного, так программисты не работают и уйти с гордо поднятой головой (пустыми карманами);
— прогнуться под заказчика, сказав — «ок, водопад? будет тебе Ниагара»!!!
— проевангелировать заказчика, скажем, «аджайлом», оставить ТЗ в качестве формальности, но работать «гибко».
Я попробовал второй и третий пункт. Надо сказать, второй ВСЕГДА лучше для такого рода проектов. Третий пункт был весел в течение всего срока работы над проектом, но «приёмка» это вам не «куратор». Лучше или хуже — роли не играет. Надо «как положено».
Так что «водопад» не есть «зло», а «аджайл» не есть добро. А друг тебе тот, кто деньги платит.
Опять же — «кобол» не равно «водопад». «Водопад» не значит «устарел». Водопад означает «комфортные условия взаимодействия „заказчик-исполнитель“ -да! иногда в ущерб качеству/количеству функционала, потенциально-возможному.
Ну и на закуску бойкому молодняку (который, Максим, и дискет в руках не держал — удачная шутка? а?).
Альтернативы „водопадной“ модели были предложены отнюдь не айтишниками. Очень многое из того, что айтишники считают „своим“ и гордятся этим, придумано „не ими“. Очень смешно, когда молодые „переоткрывают азбучные для классического инженера идеи“. Ну или воюют с „водопадами“, а также артефактами в виде „ветряных мельниц“ типа ТЗ.
ТЗ — это большое БЛАГО для программиста. „Водопад“ — возможность творчески работать, не загоняя себя в угол.
Обсудим? Только с Коболом у меня не очень :)
*** МАКСИМ ***
А от «нас» было совсем не интересно? ;) Честно говоря, мы ожидали, что вопросов по существу будет «больше». Или прав Барух, и это все как «Кобол с водопадом»? Или может мы просто не достаточно внятно про метамоделирвание и шаблонную кодогенерацию рассказали?
*** МАКСИМ ***
ой, чудно как из под чужого аккаунта писать… :) Здравствуйте!
Барух, Кобол это старый, громоздкий язык поражающий своей избыточностью (на первый взгляд), модель «водопада» часто используется как синоним отсталости и каменного века ИТ (не совсем впрочем заслуженно, но это не так важно), правильно ли я понял Вас, что своим предложением Вы намекаете, что и тема этой статьи настолько же устарела и ни кому не интересна? :) Если НЕТ, то тогда поясните про Кобол ;), если ДА, то почему Вы все же так считаете? Спрашиваю, потому что подозреваю что Вы ее не прочли (это не наезд, разумеется) и до сути не добрались, ну или, знаете что-то чего не знаем мы с Александром, и тогда вдвойне было бы интересно это от Вас услышать.
Заранее, спасибо!
А: Я считаю надо в следующий раз с адептами Кобола обсудить waterfall model.
В: Ну зачем так по-детски реагировать? Если кроме «сам дурак» нечего сказать, лучше промолчать.
А: В реплике не содержится никакого оскорбления для адептов Кобола
В: Вы вместо того, чтобы неоднократно писать одно и то же, даже когда оно не подходит, попробуйте писать разное, в зависимости от ситуации.
А: Я что-то делаю не так?
В: Я же написал — «вы что-то делаете не так».
Предлагаю Вам всё-таки поверить психологам. Для Вашего удобства обезличу обе стороны Вашего «я» и редуцирую лишние слова.
Статья про UML
А: Я считаю надо в следующий раз с адептами Кобола обсудить waterfall model.
В: Ну зачем так по-детски реагировать? Если кроме «сам дурак» нечего сказать, лучше промолчать.
А: В реплике не содержится никакого оскорбления для адептов Кобола
В: Вы вместо того, чтобы неоднократно писать одно и то же, даже когда оно не подходит, попробуйте писать разное, в зависимости от ситуации.
Хотя, конечно, Психологию достаточно сложно считать «точной» наукой, некоторые прикладные теории достаточно хорошо работают.
Давайте, Вы мне еще что-нибудь поотвечаете, а мы продолжим эксперимент. Тут главное не волноваться. Представьте, что Вы возлежите на кушетке в удобной позе, я сижу за столом, заваленным книгами по психологии.
Писал об этом неоднократно: «отзеркаливание». Когда идёт комментарий «вне контектса», то человек разговаривает сам с собой. Тут я — зеркало. А Вы — разговариваете сами с собой. Давайте изучим:
Статья про UML
— Я считаю надо в следующий раз с адептами Кобола обсудить waterfall model.
— Ну зачем так по-детски реагировать? Если кроме «сам дурак» нечего сказать, лучше промолчать.
Феномен в том, что получается вполне осмысленный диалог, который человек ведёт внутри себя со своей совестью.
Советую всем, кто пишет участвует в полемике (любой) обязательно проверять её на «внутренние диалоги». В разговорной речи это сложно заметить, но именно в форме комментариев это выглядит очень наглядно.
«Или «мы купили» Гарант. И Леонов пиарит его» => «Или „мы купили“ Леонова». И он пиарит Гарант" — так читать.
Мысли — быстрее пальцев работали.
Друзья! Никто «никого» не «купил». Просто хотелось рассказать про UML И его ПРАКТИЧЕСКОЕ применение. Потому, что считаем эту тему — перспективной.
Но! Не ФАКТ, что мы «ВСЁ ДОДУМАЛИ». Нет! НЕ додумали. Ещё есть — над чем думать. Собственно потому и публикуем.
Простите за безумное количество опечаток :-( Браузер — похоже буквы глотает. А я не стал вычитывать. Если что-то непонятно — поясню. Мне стыдно. В следующий раз — буду вычитывать.
«Мне и так хорошо кодируется»
— я кстати — тоже из категории таких «хардкорных» программистов. Я считаю КОД — первоосновой.
А «документацию» — я считаю «глупостью» (передёргиваю конечно). Но! Вот почитайте — «крик души» — 18delphi.blogspot.ru/search/label/%D1%87%D0%B8%D1%82%D0%B0%D0%B9%D1%82%D0%B5%20%D0%B8%D1%81%D1%85%D0%BE%D0%B4%D0%BD%D1%8B%D0%B9%20%D0%BA%D0%BE%D0%B4
Я когда был на конференции в Казани — где собственно я и познакомился с Всеволодом — уровень некоторых вопросов — МЕНЯ ПОРАЗИЛ. Хотелось встать и сказать — «ребята! коллеги! друзья мои! ну ОТКРОЙТЕ исходный код библиотек и ПОЧИТАЙТЕ! а потом ТОЛЬКО — задавайте вопросы».
И я МНОГО спорил с Максом и не принимал его подход когда-то.
Пока он не показал мне «кодогенрацию». Причём — РЕАЛЬНО. «В байтах» (как пишет Джоэл).
И тогда — я ПОВЕРИЛ Максу — и не жалею.
Появилось именно «логарифмирование» сложности «и быстрое изменение масштаба». Сегодня я программирую UseCase'ы, а завтра — «абстрактные контейнеры». Между ними — ПРОПАСТЬ. Но она мне — НЕ МЕШАЕТ.
«Проблемы» управления БОЛЬШИМ объёмом кода — у нас — реально БЫЛИ. И я не знал — что делать. И эти проблемы — «испарились» — когда я стал рисовать UML-диаграммы. И более того эти диаграммы сейчас читают ДРУГИЕ люди.
P.S. Можно «пинок» Embarcadero? Это наверное особенно «пикантно» смотрится из по аккаунта Всеволода Леонова :-) Я МНОГО пишу о недостатках Embarcadero ;-) Но — ПОКА — не услышан. Так что — не думайте, что это «теория заговора». Мы с Всеволодом — СОТРУДНИЧАЕМ в данной стать. Но! ПОТОМУ, что тема интересная и ВАЖНАЯ. Я лично на неё лет 8-мь жизни потратил. Но это не значит, что Леонов «купил нас» и мы «пиарим» Embarcadero. Или «мы купили» Гарант. И Леонов пиарит его. Нет. Просто — тема интересная. И наши интересы в ней — сошлись. Просто хочется людям рассказать о том, на чем мы давно работаем. А Леонов — это дело — хорошо организовал. И задал ПРАВИЛЬНЫЕ вопросы. Спасибо ему. Но многие вопросы — остались без ответов… Поверьте мне. Если тема интересная — будем продолжать.
Я лично — УВЕРЕН, что тема не только ИНТЕРЕСНАЯ, но и ПРАВИЛЬНАЯ.
P.P.S. Главное слово — «сборочный чертёж».
P.P.P.S. Если кто-то решит меня «потроллить» — пишите уж сразу в «личку». Я уже давно — «вакцинирован». В перепалки — я — не вступаю. Работаю над собой. Отвечаю на КОНКРЕТНЫЕ вопросы.
Опять не удержусь… Дополню ещё…
Да! Практически ВСЕ UML редакторы умеют сохранять в нечто xml-подобное. И казалось бы — проблем с «мерджем» быть не должно.
Но! Они смешивают «данные» и «представление». Они пишут например координаты объектов БЕЗ учёта DPI, а цвета — БЕЗ учёта палитры.
И получается, что один разработчик что-то сделал. Второй за ним «это» что-то потрогал. На ДРУГОМ мониторе. И получили — КОЛОССАЛЬНУЮ разницу.
Практически во всех UML-редакторах, что я видел. В этом — ОСНОВНАЯ проблема.
Решение её — НА ПОВЕРХНОСТИ. Я так понимаю — тут все -УМНЫЕ люди — понимают о чём я.
На не-микро-уровне. А на уровне GUI вот:
18delphi.blogspot.ru/2013/04/uml_22.html
это из РЕАЛЬНОГО проекта, но опять же — не реальные «картинки» и «код». А их перерисовка.
Поймите правильно — мы работаем в КОММЕРЧЕСКОЙ организации. За зарплату.
Интервью — согласовывалось. Но это не значит, что мы можем в комментариях наносить ущерб работодателю.
Делиться ИДЕЯМИ — ПОЖАЛУЙСТА. Идеи — они во много голов приходят. КОНКРЕТНЫЕ реализации — ТОЛЬКО с согласия РАБОТОДАТЕЛЯ. Может быть Макс — как руководитель — что-то другое может сказать.
И если Макс — даст добро — постараюсь объяснить «на пальцах» — как картинки превращаются в код. Если не даст — не обижайтесь. Имеет право. Это реально его идея.
«что бы файлы модели были «истинно» текстовыми.»
не удержусь… дополню…
развязать — «данные» и «представление». Ну в общем — «классическая» задача.
Есть «дерево сущностей» и есть «представление их на диаграммах». Понятно о чём я?
Пример «картинок» и «код» например — тут:
18delphi.blogspot.ru/2013/07/2.html
Это не «из нашей реальной жизни». И микро-пример. Я его — СПЕЦИАЛЬНО отдельно рисовал. Потому, что реальные вещи раскрывать — мы права не имеем.
Но — надеюсь, что для начала вам понравится. Если будут конкретные вопросы — нарисую ещё.
ну почему же «идиота», на мой взгляд идиоты скорее те (ни кого не хочу обидеть) кто об этом хотя бы не мечтает, вещь в общем-то очевидная: попытаться автоматизировать рутинные процессы
Вы не совсем правильно поняли, ну или мы не точно выразились. У нас 100% генерация моделей. Те нет моделей (диаграмм) которые бы рисовались просто так, все они генерируют из себя код или какие-либо другие артефакты. Но сам код конечно не на 100% генерируется. Бизнес логика (именно бизнес логика) пишется руками, ее на модели не просто нарисовать, ну или точнее мы пока не реализовали это (идеи есть), но все равно 100% генерируемого кода не будет, да это и не нужно. Генерируется все что подается какой-то структуриизации, укладвается в какой-то шаблон, пусть даже очень сложный (и чем сложнее, тем как правило выше КПД от его использования). А остальное быстрее, проще и гибче руками написать.
Отвечая на вопрос: система контроля версий выглядит стандартно, под ее управлением находятся прежде всего артефакты получаемые после генерации — те код. Но сами файлы модели тоже под ее управлением. Но по сути именно как бинарные (хотя на самом деле они не бинарные, но такого уродского формата, что смерджить их практически не возможно). Это тоже одна из причин почему хочется свой инструмент — что бы файлы модели были «истинно» текстовыми.
ну мы чужую софтину даже в части рисования сильно кастомизировали, сильно-сильно. Она вообще уже на себя изначальную ни с какого угла не похожа, если честно. Но и этого мало, поэтому и пишем что очень хочется совсем свое написать, уже с учетом всего опыта, заточенное на максимально быстрое создание моделей и генерацию.
да, я уже коллегам высказал предположение, что должного интереса статья не вызывает именно потому что «много букв» и мало картинок и кода. Даже именно кода. Потому что просто картинки это тоже не интересно. Интересно увидеть как они в код превращаются, «как» и в «какой», и в какое его количество. А вообще прочитайте, там где-то в районе середины как раз про практику, хоть и в виде «много букв». Но… в картинках с кодом, тоже надо будет рассказать. тут я с Вами полностью согласен.
> Ведь UML я так понимаю был создан для того, чтобы Упрощать понимание проектов, а не усложнять их?
именно, но для нас лично даже это уже второстепенно (хотя по прежнему важно), а на первом месте — генерируемый код, как не странно ))
В смысле «мы» ;)
по не до конца понятным мне причинам, руководство просило не раскрывать конкретный инструментарий. Поэтому вынужден отвечать намеками, надеюсь простите. Инструментарий ровно тот, что был на дискете в 97-м году )) Он конечно подрос в размере за последующие годы, но функционально почти не изменился (по крайне мере в той части которая нам нужна). Но, выше в статье, я уже говорил, что для нас это просто рисовалка, все «ценное» (для нас) находится не в ней а в генераторе. А генератор самописный. Если его прицепить к визио — то можно и в визио рисовать. А можно и не рисовать, можно «писать» модель, но это уже на будущее.
У меня было есть достаточно опыта: работа на гос. структуры по гос. контракту.
Есть «классическое» ТЗ, которое бьется на этапы. Нет, вам вполне позволят написать первым этапом (1-2-3-4 месяца) что угодно. Хоть «сбор и анализ требований», хоть «UML-моделирование», хоть «подготовка первого спринта». Но второй этап уже не должен содержать того, что уже упоминалось в первом этапе. Куратор проекта со стороны заказчика вас будет курировать по ТЗ (которое, опять же — вы сами себе написали, но в жанре «водопадного ТЗ»). Выходов из такой ситуации несколько:
— сказать, что заказчик = дурак, требует невозможного, так программисты не работают и уйти с гордо поднятой головой (пустыми карманами);
— прогнуться под заказчика, сказав — «ок, водопад? будет тебе Ниагара»!!!
— проевангелировать заказчика, скажем, «аджайлом», оставить ТЗ в качестве формальности, но работать «гибко».
Я попробовал второй и третий пункт. Надо сказать, второй ВСЕГДА лучше для такого рода проектов. Третий пункт был весел в течение всего срока работы над проектом, но «приёмка» это вам не «куратор». Лучше или хуже — роли не играет. Надо «как положено».
Так что «водопад» не есть «зло», а «аджайл» не есть добро. А друг тебе тот, кто деньги платит.
Опять же — «кобол» не равно «водопад». «Водопад» не значит «устарел». Водопад означает «комфортные условия взаимодействия „заказчик-исполнитель“ -да! иногда в ущерб качеству/количеству функционала, потенциально-возможному.
Ну и на закуску бойкому молодняку (который, Максим, и дискет в руках не держал — удачная шутка? а?).
Альтернативы „водопадной“ модели были предложены отнюдь не айтишниками. Очень многое из того, что айтишники считают „своим“ и гордятся этим, придумано „не ими“. Очень смешно, когда молодые „переоткрывают азбучные для классического инженера идеи“. Ну или воюют с „водопадами“, а также артефактами в виде „ветряных мельниц“ типа ТЗ.
ТЗ — это большое БЛАГО для программиста. „Водопад“ — возможность творчески работать, не загоняя себя в угол.
Обсудим? Только с Коболом у меня не очень :)
А от «нас» было совсем не интересно? ;) Честно говоря, мы ожидали, что вопросов по существу будет «больше». Или прав Барух, и это все как «Кобол с водопадом»? Или может мы просто не достаточно внятно про метамоделирвание и шаблонную кодогенерацию рассказали?
ой, чудно как из под чужого аккаунта писать… :) Здравствуйте!
Барух, Кобол это старый, громоздкий язык поражающий своей избыточностью (на первый взгляд), модель «водопада» часто используется как синоним отсталости и каменного века ИТ (не совсем впрочем заслуженно, но это не так важно), правильно ли я понял Вас, что своим предложением Вы намекаете, что и тема этой статьи настолько же устарела и ни кому не интересна? :) Если НЕТ, то тогда поясните про Кобол ;), если ДА, то почему Вы все же так считаете? Спрашиваю, потому что подозреваю что Вы ее не прочли (это не наезд, разумеется) и до сути не добрались, ну или, знаете что-то чего не знаем мы с Александром, и тогда вдвойне было бы интересно это от Вас услышать.
Заранее, спасибо!
В: Ну зачем так по-детски реагировать? Если кроме «сам дурак» нечего сказать, лучше промолчать.
А: В реплике не содержится никакого оскорбления для адептов Кобола
В: Вы вместо того, чтобы неоднократно писать одно и то же, даже когда оно не подходит, попробуйте писать разное, в зависимости от ситуации.
А: Я что-то делаю не так?
В: Я же написал — «вы что-то делаете не так».
Статья про UML
А: Я считаю надо в следующий раз с адептами Кобола обсудить waterfall model.
В: Ну зачем так по-детски реагировать? Если кроме «сам дурак» нечего сказать, лучше промолчать.
А: В реплике не содержится никакого оскорбления для адептов Кобола
В: Вы вместо того, чтобы неоднократно писать одно и то же, даже когда оно не подходит, попробуйте писать разное, в зависимости от ситуации.
Хотя, конечно, Психологию достаточно сложно считать «точной» наукой, некоторые прикладные теории достаточно хорошо работают.
Давайте, Вы мне еще что-нибудь поотвечаете, а мы продолжим эксперимент. Тут главное не волноваться. Представьте, что Вы возлежите на кушетке в удобной позе, я сижу за столом, заваленным книгами по психологии.
Статья про UML
— Я считаю надо в следующий раз с адептами Кобола обсудить waterfall model.
— Ну зачем так по-детски реагировать? Если кроме «сам дурак» нечего сказать, лучше промолчать.
Феномен в том, что получается вполне осмысленный диалог, который человек ведёт внутри себя со своей совестью.
Советую всем, кто пишет участвует в полемике (любой) обязательно проверять её на «внутренние диалоги». В разговорной речи это сложно заметить, но именно в форме комментариев это выглядит очень наглядно.