Оценка людей полезности и продуманности архитектуры софта

Недавно один знакомый вбросил фразу что типа "vi редактор архитектурно
был непродуман" (в отличии от Emacs или (возможно) Vim). Мол что-то
расширить в vi нельзя, а в Emacs/Vim, в которых есть встроенный язык и
редактор строящийся прямо на нём (про Vim я бы тут поспорил на самом деле).
Фраза и эта мысль меня задела тем, что это как-то не очень честно
обвинять в том, что вообще не предполагалось и каких задач не ставилось.
Вообще обижаться тут не на что само собой -- просто у людей есть
принципиально разный взгляд на мир и вещи в нём.

С одной стороны: есть конкретная текущая задача, которую нужно
выполнить. Это можно сделать быстро и качественно, но решение возможно
совершенно не впишется в чуть изменённые условия/требования
использования в будущем. Можно подумать о расширяемости и гибкости, что
возможно в будущем может помочь. С другой стороны: проектированием и
придумыванием можно заниматься хоть 100% времени, так и не начав делать
работу или так и не предоставляя законченного готового варианта, хорошо
решающего задачу. Как всегда, нужна золотая середина.

Я бы на месте Билла Джоя поперхнулся от заявления об архитектуре vi. Ему
надо в кратчайшие сроки написать удобный и достаточно функциональный
редактор. Не годами пилить какой-нибудь Emacs, а за неделю сделать
редактор (говорят что именно за это время он и был написан) чтобы дальше
заниматься исключительно BSD ОС. Причём редактор достаточно маленький
(говорят, 100-1000 раз меньший по размеру чем Emacs) и не требовательный
к ресурсам. С этой задачей Джой справился так хорошо, что, по сути, до
сих пор именно как редактор всё равно vi(m) с его модальностью мощнее.
Насколько по разному могут смотреть на мир люди из одной отрасли! А ведь
рядом всегда сможет найтись человек который скажет что любая
BSD/whatever это полный непродуманный fail, ибо где тонны прибыли
которые можно грести лопатой?

Но вот GNU/Linux экосистема для меня выглядит в целом именно как
экосистема framework-ов и конструкторов. Почему то на ум первым делом
приходит eBPF, который в теории (ну и по функциональности уже заложенной
в ядре) может больше чем DTrace... но *готовых* решений дотягивающих
хотя бы до DTrace уровня так и нет. Сколько всего придумано касательно
изоляции процессов, но ничего настолько удобного и простого типа Jails
(или Solaris Zones/Containers), говорят, до сих пор так и не было.

Ну и желание постоянно всё делать на будущее, на расширяемость это
запросто ведёт и к такому недугу как "ООП головного мозга". Когда
простейшие вещи в коде превращаются в адовый ад для понимания и
поддержке. Я реально встречал код на PHP где на 200 строк кода, не
считая комментариев, делается GET значения из Redis.

Rust, было время, каждую неделю всё так сильно менял в языке что
буквально hello world бы не собирался. До сих пор в README регулярно
встречаю упоминания что нужна такая и только такая версия Rust для
работы такого то софта. Изначально в Rust был даже garbage collector,
потом не стало. Для меня это пример того, как люди просто пилят и
придумывают ради пиления и придумывания -- без какой-либо цели или
вообще понимания что они хотят.

Тогда как в Go почти 15 лет прошло с момента предложения внедрения
generic-ов до его одобрения. Сейчас вот, программируя на Си, не могу не
удивляться огромному количеству продуманных (сверх продуманных) мелочей
по сравнению с Си. Вчера обнаружил что в Си нельзя делать "a, b = c, d;",
что оказалось дико неудобно и уродует код временными переменными.
Собственно сам Go то это результат трудов ещё с начала 90-х, кучки
хакеров.

OpenSSL своими EVP предполагает простую и лёгкую расширяемость за счёт
нечто похожего на интерфейсы. Идея может быть и хорошая, но по факту
внутри OpenSSL всё равно сплошные сплошные "if algo == ..." исключения,
равномерно распределённые по всему коду. Впечатление что изначально
хотели и планировали как лучше, а потом плюнули на всё и просто лишь бы
как, хоть бы как, но сделать задачу, пускай и не красиво. Наверное
худший из вариантов (среди "всё на коленке, да побыстрее, здесь и
сейчас" и "надо годами подумать, классическим waterfall, только потом
начинать"). Тогда как в Go, другая крайность касательно криптографии и
TLS реализации: никакой расширяемости со стороны библиотеки. И
действительно -- так ли она нужна? Может лучше сделать что-то
*существенно* более простым, экономить годы проектирования, но
удовлетворить 99% пользователей ПО, чем тратить кучу ресурсов ради
оставшихся (для них проще сделать fork или отдельное ПО), и крайне редко
что не испортив в целом всё остальное (как минимум, сложностью).

Хех, чисто случайно сейчас увидел новость
https://lenta.ru/news/2021/02/12/svetlakov_badcomedian/
(про BadComedian ничего не знаю, какие фильмы обсуждаются не знаю, но
наверное комедийные, раз Светлаков), где Светлаков верно заметил что:
    Этот фильм едет на Канны или это хорошее развлекательное кино,
    создающее настроение на праздник?
Ибо тоже не раз слышал критику фильмов, как будто они ориентировались на
Канны(-like). А простая лёгкая комедия тоже нужна. У неё другая задача.
И оценки нужны к ней отдельные.

Или мне этот же знакомый говорил что PyDERASN плохо спроектирован, ибо
он не предусматривает потоковую обработку данных (сейчас это не совсем
так, но только недавно появилось). Мудро конечно просто проигнорировать,
а не оправдываться. Но меня удивляет что человек с опытом продолжает
делать такие оценки (+оценка архитектуры vi). PyDERASN писался так: за
две недели отпуска успеть полностью его сделать и перевести на него
проекты. Если не успеть -- всё насмарку, ибо по вечерам такой проект я
бы не мог пилить, ибо нужно много чего в голове держать и помнить и
поэтому нужно наброситься и растерзать проблему до конца. Если не
перевести проекты, то варианта держать параллельно что-то на pyasn1, а
что-то на pyderasn -- не вариант. Можно PyDERASN вообще было бы не
делать -- но тогда для Python банально просто отсутствовала бы *строгая*
и удобная (с нужным функционалом) DER библиотека. И получается, что или
продолжать бы жить без качественной строгой удобной библиотеки с
некоторыми нужными возможностями без костылей (типа .offset), ибо из-за
проектирования на разработку бы не хватило бы времени (а бизнес не
требует наличия таких библиотек и не стал бы оплачивать время на её
разработку), либо иметь такую, но в которой нет возможности потоковой
обработки... которая до сих пор никому не нужна на практике в решаемых
на работе задачах (ибо размеры данных небольшие и всё всегда в памяти
легко уместится).

Кто-то бы мог заявлять что GoVPN, NNCP, goredo, whatever -- непродуманны
ибо не запустятся, или содержат что-то *принципиально* не совместимое,
на Windows. Я скорее задумаюсь о вопросе возможности их работы на Plan9,
чем о мобильных устройствах и проприетарных системах.

И до сих пор я не знаю по каким критерием меня оценивал один бывший
коллега, заявляя что я вообще вредил. У меня в голове на весах есть
только одно: либо полностью не сделанная задача (для бизнеса -- тоже
вариант, не фатальный, терпимая потеря прибыли), либо сделанная как это
только возможно хорошо в те сжатые сроки (с 8 до 19 фигача и фигача не
останавливаясь, с перерывом только на обед). Я бы мог вообще отказаться
её выполнять -- никто не заставлял. Даже сделанные коммиты -- вообще
никуда не надо бы было вливать или с чем-то мёржить, ибо они актуальны
только для конкретной инсталляции.

Но похоже тут настолько разное мировоззрение у людей и разные подходы,
что состыковаться не получится, компромиссов не найти. Как категорически
разные взгляды в религии, политике, истории и подобном могут быть
непреодолимым барьером. Но если разумные люди на работе не поднимают и
останавливают подобные темы (ибо какое они имеют отношение к работе?
могут только навредить, но не улучшить отношения), то когда встретятся
два человека, один из которых считает что hello world нужно писать как
"master programmer" (bc48396c84d164d4b892a5f833cc738683c22049), а
другой... иначе, то я не знаю как тут можно им будет работать сообща.