Всем привет. Это мой пятый подход к этой платформе. Четыре предыдущих закончились баном аккаунта. Вероятно, этот закончится так же. И, знаете, в этом есть определенная ирония. Системы, созданные для обмена знаниями, иногда так боятся нарушить свой хрупкий баланс, что начинают работать как брандмауэр, блокирующий любой незнакомый IP‑адрес с нестандартным «пакетом» идей.
Но эта статья — не жалоба. Это анализ. Инженерный разбор феномена, с которым сталкивается любой, кто пытается создать что‑то действительно новое, а не просто очередную копию существующего. Это о том, как сообщества, созданные для продвижения технологий, начинают душить инновации в зародыше. И о том, как, черт возьми, продолжать строить свой звездолет, когда все вокруг кричат, что он никогда не взлетит.
Анатомия отторжения: "Низкий технический уровень" как универсальное оружие
Давайте начнем с самого распространенного аргумента, который я вижу в комментариях и в причинах минусов к моим статьям: «низкий технический уровень материала». Это fascinatin'g. Увлекательно. Потому что это идеальный пример того, как субъективная оценка, основанная на привычке, маскируется под объективный технический критерий.
Что такое «высокий технический уровень» в понимании среднего комментатора?
Соответствие шаблону: Статья должна быть похожа на другие «успешные» статьи. Она должна использовать общепринятую терминологию, ссылаться на известные технологии (желательно, написанные на C++ или Rust), и решать проблему, которую сообщество уже признало «важной».
Глубина в известном: Глубокий разбор уже существующего и понятного алгоритма или фреймворка — это высокий уровень. Создание чего‑то нового с нуля и объяснение его философии — это, зачастую, «низкий уровень», потому что оно не вписывается в существующую систему координат.
Сообщество, как любая сложная система, вырабатывает иммунный ответ. Идеи, которые не похожи на то, что уже циркулирует в системе, воспринимаются как чужеродные тела. И система пытается их уничтожить. «Низкий технический уровень» — это антитела, которые вырабатывает этот коллективный организм.
Ирония в том, что статьи, которые проходят этот фильтр, часто не несут никакой новой технической ценности. Они могут быть пересказом документации или компиляцией известных фактов. Но они «похожи» на правильные статьи. Они нравятся. AsmX G3 не похож. Он написан на Nodejs/TypeScript для разработки компилятора, что для многих уже звучит как ересь. Он предлагает свой синтаксис. Он решает проблемы не так, как принято. Поэтому он — идеальная мишень.
Системный порок: Когда сообщество оптимизирует не то, что нужно
Диванные критики, которые никогда ничего не создали, но точно знают, как надо, — это лишь симптом. Настоящая проблема глубже. Она в самой системе оценки.
В теории, системы кармы и рейтингов должны отсеивать мусор и продвигать качество. На практике они создают эхо‑камеру и наказывают за риск. Они поощряют конформизм. Написать безопасную, «правильную» статью — это гарантированный способ получить плюсы. Предложить радикально новую, спорную идею — почти гарантированный способ уйти в минус.
Система оптимизирует под «общественное одобрение», а не под «инновационную ценность». И это ловушка. Это путь к застою, к бесконечному пережевыванию одного и того же. Общество, которое не любит «неправильных», которое требует соответствия образцу, не способно к прорывам. Оно может только улучшать существующее. Оно не может создать новое.
Интересно, если бы системы работали так всегда, дошли бы мы когда‑нибудь до электромобилей и многоразовых ракет? Или так и продолжали бы оптимизировать конные повозки?
Изгой как функция системы
В любой системе есть понятие «выброса» (outlier). Это точка данных, которая сильно отличается от остальных. В статистике такие точки часто отбрасывают, чтобы они не «портили» общую картину. В человеческом обществе изгои — это и есть такие «выбросы». Они не вписываются в общую кривую распределения.
Я стал таким изгоем. Мой подход к разработке, мой выбор инструментов, мой стиль изложения — все это делает меня «выбросом» для системы Хабра. И система, следуя своей внутренней логике, пытается меня «отбросить», чтобы не нарушать гомеостаз.
Но вот в чем парадокс: в науке и инженерии именно «выбросы» часто указывают на самые интересные явления. На аномалию, которая может привести к новому открытию. На ошибку в самой модели, а не в данных. Отбрасывая изгоев, сообщество не очищает себя. Оно лишает себя возможности увидеть что‑то за пределами своего текущего понимания.
Они не понимают, что право на творчество — это не привилегия, которую выдает сообщество. Это фундаментальное право. Лишать кого‑то этого права через манипуляции рейтингом — это не критика. Это цензура, осуществляемая руками толпы. И самое печальное, что эта толпа часто состоит из тех, кто сам ничего не создал, но узурпировал право судить создателей.
Инженерный ответ: Как строить в агрессивной среде
Итак что делать, когда ты оказался в роли такого «изгоя»? Когда система предвзята, а любой твой шаг встречается с волной негатива? Жаловаться — бесполезно. Нужно менять подход. Вот принципы, по которым я строю AsmX G3:
Фокус на первых принципах, а не на аналогах. Я не задаю вопрос «Как сделать компилятор, похожий на GCC?». Я спрашиваю: «Что такое компилятор по своей сути? Какую задачу он должен решать? Как это сделать максимально эффективно, используя доступные сегодня инструменты?». Ответ на этот вопрос привел меня к Nodejs/TypeScript, к двум режимам парсера и к собственной реализации всего конвейера.
Код — главный аргумент. Можно сколько угодно спорить о «техническом уровне» статьи. Можно поставить ей минус. Но нельзя поставить минус рабочему ELF‑файлу, который скомпилирован моим инструментом и запущен на реальном железе. В конечном счете, единственный критерий истины в инженерии — это работающий продукт. Поэтому я трачу время не на споры, а на код.
Итерация и открытость. Проект открыт. Каждое изменение, каждая строчка кода видна в репозитории. Я не скрываю недоработки. Я открыто говорю о них, как в предыдущей статье о проблеме с переопределением переменных в
.rodataили о будущем системных вызовов. Это лучший ответ критикам: пока вы говорите, я — делаю.Антихрупкость. Система, которая становится сильнее от атак. Каждая попытка найти недостаток, каждый едкий комментарий — это бесплатное тестирование. Это стресс‑тест не только для кода, но и для меня как инженера. Этот негатив заставляет меня делать продукт еще более надежным, еще более продуманным, чтобы не оставить ни единого шанса для критики по существу.
Свобода слова и модерация
И последнее. Если эта статья будет удалена модераторами по формальному признаку, это лишь подтвердит мой главный тезис. Что система защищает не свободу творчества и обмена идеями, а собственное спокойствие и соответствие шаблонам. Свобода слова — это не право говорить то, что всем нравится. Это право говорить то, что неудобно. То, что заставляет задуматься.
Я не прошу плюсов. Я прошу честной оценки. Не меня, а идей, которые я здесь изложил. Потому что завтра на моем месте может оказаться другой разработчик с еще более безумной идеей. И от того, как мы встретим его сегодня, зависит, увидим ли мы это «завтра».