В данной статье попробуем рассмотреть варианты некорректной полемики, которая, увы, часто встречается на Хабр и иных площадках.
Абсолютизирование описанного подхода
Известно, что любой способ, доведённый до абсолюта становится глупостью.
Например чрезмерное применение ООП приводит к нечитаемому коду. Полный отказ от ООП и переход к чисто функциональному коду тоже снижает читаемость.
Истина всегда где-то посередине.
Но когда Вы захотите сообщить кому-то о том, как успешно Вы применили какой-то способ, будьте готовы к тому что найдётся оппонент который попробует применять этот способ абсолютно везде.
Я как-то написал статью об использовании именованных событий и ко мне пришёл комментатор и заявил:
Полная лажа!Я заменил в своём коде все функции на именованные события. Получился ад из идентификаторов через который крайне сложно было продираться! После этого я вернулся на старый добрый React!
Что делать?
- Не включаться в спор.
- Однократно прокомментировать что не стоит перебарщивать с инструментом.
Терминологическое забалтывание
Не секрет что во многих случаях границу между терминами провести сложно. Часто два разных термина означают одно и то же и наоборот. Зависит от контекста и границы употребимости.
Например Вы о чём-то рассказываете. О проблеме X
:
Рассмотрим проблемуX
, которая проявляется, например, в случаяхA
,B
,C
иD
. Проблема состоит в том-то и том-то. Решать её можно так-то и так-то.
Обязательно найдётся комментатор, который скажет:
Полная лажа!У Вас терминD
применён неправильно! На самом деле надо говоритьD-штрих
. ТерминD
ввёл такой-тоФ.И.О
в таком-то году. А терминD-штрих
другойФ.И.О
в другом году.
Почему-то года и Ф.И.О оказываются важны.
Вы ему отвечаете:
В рамках данной статьи не особо важноD
это илиD-штрих
, поскольку здесь речь о проблемеX
.D
тут — пример иD-штрих
может быть таким же примером. В данном контексте разницы нет: проблемаX
присутствует и вD
и вD-штрих
.
Сразу появляется ещё один участник. Заявляет:
Это неD-штрих
, этоE
!
Начинается спор о терминах, который может длиться бесконечно. Особая мякотка: если спустя пару дней споров появится ещё участник, на каком-то этапе спора возвращающий к термину D
:
Нет, это неE
, этоD
!
В итоге пост собрал 100+ коментариев о терминах D
, D-штрих
, E
и годах рождения тех кто ввёл термины. Но проблему X
не обсудили.
У меня был как-то комментарий о проблемах использования глобальных (или статических) переменных.
В нём приводился пример с синглтоном. Синглтон в примере был реализован с использованием глобальной переменной.
Синглтон — объект, инстанцирующийся в системе лишь однажды. Однократное инстанцирование можно гарантировать несколькими способами:
- Сам класс это как-то гарантирует (обычно ссылаясь на глобальную/статическую переменную).
- Это делается вне класса — в момент инстанцирования (в этом случае теоретически может быть создано несколько объектов данного класса, но если место инстанцирования увязывается например с глобальной переменной, то можно считать что мы создали синглтон).
Я выбрал второй вариант.
Сразу нашёлся персонаж, который воскликнул:
Полная лажа!Это не синглтон, это мемоизация!
Я ответил:
Это синглтон, который в данном примере реализован при помощи мемоизации.
И вот я включился в эту игру. О проблеме глобальных/статических переменных забыли.
Что делать?
- Не включаться в спор (если реально хотим обсуждать именно то о чём писали в статье).
- Тщательно выверять термины в статье. Если что-то может иметь два названия — приводим их оба.
- Мягко возвращать аудиторию к обсуждаемой проблеме. Напоминать о ней.
Это не серебряная пуля!
Любое решение имеет границы в которых работает хорошо, и за пределами которого работает плохо — требуется другое решение.
Допустим Вы обсуждаете какой-то способ решения какого-то спектра проблем.
Обязательно найдётся человек, который придёт и скажет:
Полная лажа!Я попробовал Вашей лопатой забивать гвозди в стену, получается плохо. Руки только поранил! Вернусь к старому молотку.
Что делать?
Не включаться в спор. Просто игнорируем комментарий.
Гиперболизация проблем
Вы описываете способ как упростить написание кода в какой-то парадигме. Обязательно найдётся человек который будет искать примеры/варианты, которые являются контрпримерами и будет гиперболизировать их.
Его комментарии можно свести к такому (только он его прямо не говорит):
Раз из 100 случаев мы улучшаем всего 99, а целый один у нас остаётся не улучшенным, то Ваше предложение — полная лажа.
Как правило при этом предлагает другое решение, от которого Вы как раз предлагаете отказаться в своей статье.
Что делать?
- Признавать наличие проблемы.
- Пытаться привести больше примеров, когда Ваш подход лучше.
Игнорирование проблем
Противоположность предыдущему варианту.
Скопипастить код 23 раза? Пфф какая мелочь! Установи себе правильный IDE, где это делается одной кнопкой, и не надо тут статьи писать!
Что делать?
Игнорировать такие комментарии.
Quiensabe
Пытаясь сочинить абсолютно корректный комментарий я пришел к излишней сложности выражения мнения в ходе дискуссии (в обсуждении научных вопросов этот термин корректнее, так как полемика более свойственна художественным вопросам), так что, предложенное решение далеко от идеала — налицо экспоненциальный рост проблем в понимании смысла, а также убеждении участников дискуссии придерживаться заданных правил, так что единственный шанс продолжать общение — игнорировать изложенный подход :)
rsync Автор
поставил плюс в карму!
спасибо!
Quiensabe
Спасибо!)
Это как своеобразный намек на еще один вариант: «перевод в шутку» :)
rsync Автор
Перевод в шутку
(предложено Quiensabe) Ещё один метод увести от обсуждения статьи/коментария.
Делается это так. Приходит оппонент и пишет потрясающий текст вроде бы и связанный с темой, но так же и далёкий от неё. Главным качеством текста является хорошая шутка или интересная история.
Читатели отвлекаются на шутку и… забывают о Вашей статье/комментарии.
что делать?
как-то так :)
rsync Автор
А если серьёзно, статью написал — чтоб давать на неё ссылки оппонентам.
как-то так
Deosis
То, что вы описали называется одним словом — демагогия.
Ещё больше можно почитать тут