Что: df28f008a00c0ce8bcad34dd693b174ca79ed520
Когда: 2021-02-12 16:25:20+03:00
Темы: c hate
Оценка людей полезности и продуманности архитектуры софта Недавно один знакомый вбросил фразу что типа "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 реализации: никакой расширяемости со стороны библиотеки. И действительно -- так ли она нужна? Может лучше сделать что-то
Сгенерирован: SGBlog 0.34.0