Недавно создатель NodeJS Райн Дал открывал конференцию HolyJS в Питере. И я вспомнил, что у меня есть неопубликованный перевод с его блога и решил его опубликовать. Местами перевод довольно откровенный. Надеюсь, вам будет интересно. Дата выхода статьи — Октябрь 2011. Дата выхода NodeJS — 27 Мая 2009.
Оно не нужно и осложнено почти на каждом слое. Лучшее, что я могу, это поздравить кого-то это за быстрое и простое решение проблемы, учитывая то говно, что они поставляют. Единственное ПО, которое я люблю это то, которое я могу легко понять, и оно решает мои проблемы. Размер сложности, который я согласен терпеть, пропорционален размеру проблемы, которая должна быть решена.
За последний год, я думаю, я наконец-то пришел к пониманию идеалов Unix: файловые дескрипторы и процессы оркестрируются с помощью C. Это прекрасная идея. Но это не то с чем мы имеем дело. Сложность не подразумевалась. Наоборот мне приходится иметь дело с DBus, /usr/lib, Boost, ioctls, SMF, сигналами, volatile переменнымии, прототипным наследованием, _C99_FEATURES_, dpkg и autoconf.
Те из нас кто пишет софт поверх этих систем добавляет сложность. Теперь ты должен знать не только $LD_LIBRARY_PATH, чтобы заставить систему работать, но ещё и $NODE_PATH — знай, это моих рук дело, это мое добавление сложности! Пользователи — те кто хотят видеть веб-страницу — им вообще пофиг. Им всё равно как мы организуем /usr, всё равно как работают zombie-процессы, всё равно как работает дополнение команд в bash, всё равно как zlib слинкован с Node статически или динамически. Наступит момент, когда накопленная сложность наших существующих систем будет больше, чем сложность создания новой. Когда этот момент настанет всё это дерьмо пойдет в мусорку. Мы сможем смыть boost и glib и autoconf в туалет и никогда не вспоминать о них.
Те из вас, кто до сих пор получает удовольствие от изучения деталей, скажем, языка программирования — например, те кто с удовольствием могут наизусь сказать является ли NaN равным null или нет — то вы даже не понимаете насколько это херово. Если вы думаете, что было бы мило выровнять все знаки равно в вашем коде, если вы тратите время настраивая ваш оконный менеджер или редактор, если вставляете проверку unicode меток в тест ранере, если вы добавляете ненужные иерархии в ваших папках с кодом, если вы делаете хоть что-то кроме того, что решаете проблему — то вы не понимаете насколько всё херово. Никого не волнует объектная модель glib.
Одна вещь, которая имеет значение в разработке ПО это что чувствует пользователь (experience of the user).
Комментарии (30)
alexesDev
30.05.2019 21:15+3Это эволюция. Страшный код живет, потому что имеет "сильные гены". Никто же не говорит "вас должно тошнить от утконосов" =)
slonopotamus
30.05.2019 21:25+1приходится иметь дело с DBus, /usr/lib, Boost, ioctls, SMF, сигналами, volatile переменнымии, прототипным наследованием, _C99_FEATURES_, dpkg и autoconf.
Нытьё какое-то.
DBus, Boost, SMF, dpkg, autoconf, _C99FEATURES — это можно просто взять и не использовать, автора кто-то заставляет что ли?
/usr/lib, сигналы, volatile-переменные — не ясно в чём с ними сложность
прототипное наследование — я не ослышался? Создатель NodeJS считает JS говном?
BedwaRe Автор
30.05.2019 21:43прототипное наследование — я не ослышался? Создатель NodeJS считает JS говном?
Да не, не думаю. Помоему он писал статью когда уже всё бесило)
Скорее всего не стоит за конкретные названия цепляться, автор в целом негодует от сложноти. В чём я с ним солидарен. Но в IT редко когда было по-другому)BedwaRe Автор
30.05.2019 21:45Да не, не думаю. Помоему он писал статью когда уже всё бесило)
О чем говорит обилие мата в оригинальной статье)
VolCh
31.05.2019 08:57Плохо получается просто взять и не использовать, если вообще собираешься использовать софт для универсальных устройстви не прибегать на каждый чих к услугам мальчиков по вызову.
napa3um
30.05.2019 22:05+3(На правах графомании.)
Перелез из Си++ в JS, когда появилась Нода (клиент-серверными делами занимался), а до этого даже сам пытался соорудить что-то подобное — на базе IActiveScripting реализовал на MSVC++ хост для исполнения скриптов, когда запарился лично компилировать и деплоить каждое изменение в договорах с контрагентами в платёжной системе, в которой и серверная, и клиентская часть работали на этом велосипеде. «Платформа» предоставляла скриптам функции для рисования кнопки, комбобокса, текстового инпута, функции записи/чтения в БД и записи/чтения сокета, автоматически с клиентским сертом подключаемого к серверу, всё остальное предоставлялось «без усилий», благодаря new ActiveXObject, что обеспечивало доступ к принтеру чеков и сканеру штрихкодов, например, или к эксельным актам сверки, присылаемых контрагентами на почту :). Отныне код стал данными, автоматом рассылаемыми от сервера всем клиентам при изменении («непрерывная интеграция» тогда выглядела для меня как автоапдейт средствами самого приложения, а сервера никому не приходило в голову называть облаками :)).
Примерно подобными эмоциями я тогда «бомбил», продираясь через оверинженернутые (для моих скромных потребностей) спецификации COM/ActiveX, казалось бы убегая от сложности оверинженернутого Си++. Потом пытался «окросплотформить» свою «платформу», переписав на GCC/MinGW с интеграцией Squirrel Language (который практически Lua, только с более симпатичным на мой вкус си-подобным синтаксисом), не осилил надёжных кроссплатформенных методов для доступа к сканеру/принтеру (без DLL от производителя), к эксельным листам, ну и окончательно понял, что закопался в написании уже собственной операционной системы, преодолевая какие-то искусственные проблемы, а не в разработке ценностей для клиентов/операторов системы. Нода тогда показалась придуманной лично для меня :).
Теперь вот и Нода выросла во что-то такое, что пугает уже самого автора (теперь он свалил на Го, пока Го, видимо, не настолько популярен, чтобы начинать бессистемно жиреть под запросами кровавого энтерпрайза :)). Но это всё, конечно, неизбежно. Нужно принять, что программируют люди не только для красоты, иногда им ещё приходится работать (в коллективе очень разных людей). Кроме сочувствия тут ничем не поможешь :). И стандарты выдумываются не столько для удобства программистов, сколько из соображений контроля рынка. И, я уверен, что Гослинг и сам это всё понимает, и подобные статьи — они не для аналитики, имхо, а для профессиональной солидарности, мол, жиза, братан. :)BedwaRe Автор
30.05.2019 22:49В точку. Странно такое говорить программисту, но — эта статья о чувствах)
В какой-то момент все мы оверинжинерим, но, учитывая, то что творил там Райн, это ещё мало мата было, имхо))
Просто в очередной раз мужик напоминает зачем мы это делаем.
napa3um
30.05.2019 23:31(Не очень понимаю, почему Райн у меня превратился в Гослинга, это у меня программирования :))
progserega
02.06.2019 16:11А мне думается, что весь этот кавардак растёт из незрелости ОС. ПО факту все эти слои призваны «дореализовывать удобный АПИ к железу». А этим должна заниматься ОС.
Как пример красивой реализации — Plan9, где каждая программа «отдаётся» через файловый интерфейс, где для того, чтобы вывести в окно текст — нужно просто записать этот текст в файловый дескриптор окна. Программы могут работать друг с другом без прослойки в виде человека и через простой интерфейс.
К примеру, чтобы обратиться с ПК к камере на телефоне — это сейчас архи-сложная задача. Потому что нет нормальной единой архитектуры. А в случае Plan9 — не важно где расположено устройство — ты работаешь с ним, как буд-то оно локальное — всё через файловый интерфейс. В результате снимается огромный пласт ненужной сложности.
Или другой пример — веб. Что нужно пользователю? По факту запустить удалённую программу «видео-просмотр-youtube» или «новостная-программа-habr». Которая от клиента берёт ввод, а отдаёт ему вывод. Всё просто, но… Но мы соорудили виртуальную машину (браузер), разорвали код посередине (визуализация с частями кода — js — в виртуальной машине, а хранение данных и их обработка — на сервере — бд+php). И всё это как-то дёргается через ajax. И чтобы хоть как-то с этой сложностью и неудобством (изначальным) работать — наворачиваются всякие NodeJs, Yii2 и т.п. фреймвёрки, которые вроде как упрощают, но как только нужно что-то посложнее — тонешь в их дополнительной сложности.
Возьмём стек сетевых протоколов — сертификаты, tcp, udp, http, https, ftp, smtp и ещё куча великов, программист должен всё это обрабатывать, думать о безопасности, об авторизации и т.д. и т.п.
А ведь это могла делать ОС… Через единый протокол связи (в Plan9 — 9P), который берёт авторизацию и транспортные задачи на себя, как часть ОС, а программист просто работает с файлами.
Но почему-то современная ИТ ещё недозрела до этой красивой и достаточной простоты. Нужно скорее писать, реализовывать новые революции, которые хоронят старых монстров и порождают новых, которым суждено тоже скоро погибнуть. И всё бы ничего, но эти монстры тратят наше время, которые мы могли бы тратить на создание полезных вещей, которые бы просто работали и не требовали их переписывать раз за разом.
picul
30.05.2019 22:56+2Одна вещь, которая имеет значение в разработке ПО это что чувствует пользователь
Сказал человек, поощряющий разработку на JavaScript'е.napa3um
30.05.2019 23:06но ещё и $NODE_PATH — знай, это моих рук дело, это мое добавление сложности!
Он ненавидит и Ноду и не рекомендует ей пользоваться (зовёт всех на Го, но не в этой статье :)). Автор не питает иллюзий о своей исключительности в этой тьюринговой трясине :).picul
30.05.2019 23:24+1зовёт всех на Го
Разумный человек позовет не на JavaScript и не на Go, а на LLVM.napa3um
30.05.2019 23:33Разумному человеку вряд ли вообще что-то кроме Лиспа нужно :).
0xd34df00d
31.05.2019 01:22Типизация не помешает. Так что хаскель, пусть и с его слабой системой типов.
DexterHD
30.05.2019 23:24-1Yeah, I think it’s… for a particular class of application, which is like, if you’re building a server, I can’t imagine using anything other than Go. © Ryan Dahl
vlreshet
31.05.2019 00:15Одна вещь, которая имеет значение в разработке ПО это что чувствует пользователь (experience of the user).
Ага, пока технический долг не накопится до состояния «любая новая фича требует полтора года работы». И тогда-то и приходит понимание что не зря %DEVELOPER_NAME% предлагал вот там и вот тут навернуть немного абстракции.
lxsmkv
31.05.2019 05:29Недавно тоже пытался разобраться в том упрощают все-таки абстракции жизнь или усложняют. Пришел обратно к широко известной цитате Девида Уилера «Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности» В данном контексте интересно замечание Джоела Спольски в его статье про «дырявые абстракции»:
And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.
— … парадоксальным образом, несмотря на то, что нам становятся доступны все более мощные инструменты разработки, с лучшими абстракциями, стать искусным разработчиком становится все труднее и труднее
Все эти уровни сокрытия деталей делают вещи сложнее, требуя все более специализированных кадров, хотя и увеличивают производственные мощности. Это не значит, что нам нужно двигаться назад, от интегрированности к дискретности. Но это и не значит, что нужно слепо верить в то, что дополнительный уровень интегрированности устранит какую-то ни было сложность в системе. Более интегрированные системы, они ведь и более хрупкие. Чем больше слоев, каждый из которых может дать сбой, тем больше вероятности, что вся система на выходе даст сбой.
И никакое «нормально делай — нормально будет» тут не поможет. Касательно именно программных продуктов, вспоминается цитата Ларри Уолла: «три главных добродетели программиста: лень, нетерпение и самомнение». Вот они, основные причины, которые приводят к сложности программном обеспечении. Ведь каждый, конечно, думает, что ну уж он-то бы сделал куда лучше. Ага.
Ну и бизнес конечно добавляет, требуя наращивания производственных мощностей и снижения затрат. Вот и получается, что мы делаем более сложные продукты в более короткие сроки. Только слишком часто страдает качество, а еще чаще востребованность продукта на рынке. Слишком часто «инновации» в потребительском секторе вращаются вокруг интеграции.vlreshet
31.05.2019 10:44Разумеется, всегда нужно помнить о таком зле как «over engineering», не всегда слои абстракции могут всё порешать.
romangoward
31.05.2019 04:15Интересно, сколько дней автор продержался бы на оракловской галере? Так как раз много времени на рефлексию, пока тесты бегают :-}
saipr
31.05.2019 10:21Теперь ты должен знать не только $LD_LIBRARY_PATH, чтобы заставить систему работать, но ещё и $NODE_PATH — знай, это моих рук дело, это мое добавление сложности!
Каждый хочет быть столпом Вселенной
tangro
31.05.2019 11:39Никого не волнует объектная модель glib. Одна вещь, которая имеет значение в разработке ПО это что чувствует пользователь
Какой-то популизм, ей богу. Конечно, пользователя не волнует объектная модель glib, его волнует чтобы програмка быстро бегала и сайтик открывался. А чтобы это произошло — какого-то программиста должна волновать объектная модель glib. Не волнует — ну, переходите в пользователи и наслаждайтесь результатами работы других, а деньги зарабатывайте, работая дворником.napa3um
02.06.2019 23:34Это не популизм, это прагматизм и напоминание исходной миссии писателя ПО. Даже если мы делаем удобно программисту, то измерять это нужно размером надбавочной стоимости, создаваемой этим программистом для конечных пользователей. Иначе смысла в этом удобстве нет совершенно никакого.
Suvitruf
31.05.2019 14:55+1На недавнем девгаме Джонатан Блоу (автор Braid) рассказывал про усложняющиеся системы. Выводы весьма неутешительные.
lxsmkv
31.05.2019 20:43+1Вот это видеоpop70
31.05.2019 19:41+3Проблема сложности ПО рождается всеголишь… сложностью пользователя.
Причём, "пользователь" — не обязательно тот, кто "тыкает мышью в веб-страничку".
"Кодеры" — тоже пользователи.
Пользователи языков программирования, всевозможных инструментов создания программ.
Чем больше "слоёв пользователей" между железкой (процессором, машиной) и "конечным пользователем", тем больше "слоёв абстракций" в программе. Ведь, каждому "пользователю" нужно, чтобы именно его задача решалась как можно проще и надёжнее, даже если эта задача — всеголишь написать программу, решающую задачу другого пользователя.
Плюс множество разных аспектов использования одного и того же "конечного продукта".
Одним нужно, чтобы его можно было просто и удобноего модифицировать и обслуживать, другим нужно "удобно заказывать пицу", третьим удобно собирать информацию о покупателях пицы, и получать платежи, четвёртых волнует вообще только конечная прибыль.
И часто требования противоречат друг другу.
Вот потому и "сложность" — потому, что люди (отношения между людьми) — "слишком сложные"lxsmkv
31.05.2019 23:29Мне чем-то напомнило Закон Конвея
organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations
Если немного ее перефразировать, то получается, что,
«создавая системы мы проектируем их так, что связи в этой системе воспроизводят связи между участниками этих систем».
А следствием из этого, вполне напрашивается озвученый Вами вывод:
Вот потому и «сложность» — потому, что люди (отношения между людьми) — «слишком сложные»
Т.е усложнение взаимодействия между людьми ведет к усложнению систем.pop70
01.06.2019 04:28+1Т.е усложнение взаимодействия между людьми ведет к усложнению систем.
Угу. И наоборот. Это называется диалектика (логика развития).
И когда "я ненавижу почти всё ПО", тогда это означает, что что-то не так в отношениях людей — создана среда, в которой этому "пользователю" плохо и некомфортно.
Andrusha