Комментарии 30
Оно не нужно и осложнено почти на каждом слое. Лучшее, что я могу это поздравить кого-то это за быстрое и простое решение проблемы учитывая то говно что они поставляют.Пожалуй, у Райана получилась воистину эпичная реализация тезиса «Не можешь бороться — возглавь».
Это эволюция. Страшный код живет, потому что имеет "сильные гены". Никто же не говорит "вас должно тошнить от утконосов" =)
приходится иметь дело с DBus, /usr/lib, Boost, ioctls, SMF, сигналами, volatile переменнымии, прототипным наследованием, _C99_FEATURES_, dpkg и autoconf.
Нытьё какое-то.
DBus, Boost, SMF, dpkg, autoconf, _C99FEATURES — это можно просто взять и не использовать, автора кто-то заставляет что ли?
/usr/lib, сигналы, volatile-переменные — не ясно в чём с ними сложность
прототипное наследование — я не ослышался? Создатель NodeJS считает JS говном?
прототипное наследование — я не ослышался? Создатель NodeJS считает JS говном?
Да не, не думаю. Помоему он писал статью когда уже всё бесило)
Скорее всего не стоит за конкретные названия цепляться, автор в целом негодует от сложноти. В чём я с ним солидарен. Но в IT редко когда было по-другому)
Плохо получается просто взять и не использовать, если вообще собираешься использовать софт для универсальных устройстви не прибегать на каждый чих к услугам мальчиков по вызову.
(На правах графомании.)
Перелез из Си++ в JS, когда появилась Нода (клиент-серверными делами занимался), а до этого даже сам пытался соорудить что-то подобное — на базе IActiveScripting реализовал на MSVC++ хост для исполнения скриптов, когда запарился лично компилировать и деплоить каждое изменение в договорах с контрагентами в платёжной системе, в которой и серверная, и клиентская часть работали на этом велосипеде. «Платформа» предоставляла скриптам функции для рисования кнопки, комбобокса, текстового инпута, функции записи/чтения в БД и записи/чтения сокета, автоматически с клиентским сертом подключаемого к серверу, всё остальное предоставлялось «без усилий», благодаря new ActiveXObject, что обеспечивало доступ к принтеру чеков и сканеру штрихкодов, например, или к эксельным актам сверки, присылаемых контрагентами на почту :). Отныне код стал данными, автоматом рассылаемыми от сервера всем клиентам при изменении («непрерывная интеграция» тогда выглядела для меня как автоапдейт средствами самого приложения, а сервера никому не приходило в голову называть облаками :)).
Примерно подобными эмоциями я тогда «бомбил», продираясь через оверинженернутые (для моих скромных потребностей) спецификации COM/ActiveX, казалось бы убегая от сложности оверинженернутого Си++. Потом пытался «окросплотформить» свою «платформу», переписав на GCC/MinGW с интеграцией Squirrel Language (который практически Lua, только с более симпатичным на мой вкус си-подобным синтаксисом), не осилил надёжных кроссплатформенных методов для доступа к сканеру/принтеру (без DLL от производителя), к эксельным листам, ну и окончательно понял, что закопался в написании уже собственной операционной системы, преодолевая какие-то искусственные проблемы, а не в разработке ценностей для клиентов/операторов системы. Нода тогда показалась придуманной лично для меня :).
Теперь вот и Нода выросла во что-то такое, что пугает уже самого автора (теперь он свалил на Го, пока Го, видимо, не настолько популярен, чтобы начинать бессистемно жиреть под запросами кровавого энтерпрайза :)). Но это всё, конечно, неизбежно. Нужно принять, что программируют люди не только для красоты, иногда им ещё приходится работать (в коллективе очень разных людей). Кроме сочувствия тут ничем не поможешь :). И стандарты выдумываются не столько для удобства программистов, сколько из соображений контроля рынка. И, я уверен, что Гослинг и сам это всё понимает, и подобные статьи — они не для аналитики, имхо, а для профессиональной солидарности, мол, жиза, братан. :)
Перелез из Си++ в JS, когда появилась Нода (клиент-серверными делами занимался), а до этого даже сам пытался соорудить что-то подобное — на базе IActiveScripting реализовал на MSVC++ хост для исполнения скриптов, когда запарился лично компилировать и деплоить каждое изменение в договорах с контрагентами в платёжной системе, в которой и серверная, и клиентская часть работали на этом велосипеде. «Платформа» предоставляла скриптам функции для рисования кнопки, комбобокса, текстового инпута, функции записи/чтения в БД и записи/чтения сокета, автоматически с клиентским сертом подключаемого к серверу, всё остальное предоставлялось «без усилий», благодаря new ActiveXObject, что обеспечивало доступ к принтеру чеков и сканеру штрихкодов, например, или к эксельным актам сверки, присылаемых контрагентами на почту :). Отныне код стал данными, автоматом рассылаемыми от сервера всем клиентам при изменении («непрерывная интеграция» тогда выглядела для меня как автоапдейт средствами самого приложения, а сервера никому не приходило в голову называть облаками :)).
Примерно подобными эмоциями я тогда «бомбил», продираясь через оверинженернутые (для моих скромных потребностей) спецификации COM/ActiveX, казалось бы убегая от сложности оверинженернутого Си++. Потом пытался «окросплотформить» свою «платформу», переписав на GCC/MinGW с интеграцией Squirrel Language (который практически Lua, только с более симпатичным на мой вкус си-подобным синтаксисом), не осилил надёжных кроссплатформенных методов для доступа к сканеру/принтеру (без DLL от производителя), к эксельным листам, ну и окончательно понял, что закопался в написании уже собственной операционной системы, преодолевая какие-то искусственные проблемы, а не в разработке ценностей для клиентов/операторов системы. Нода тогда показалась придуманной лично для меня :).
Теперь вот и Нода выросла во что-то такое, что пугает уже самого автора (теперь он свалил на Го, пока Го, видимо, не настолько популярен, чтобы начинать бессистемно жиреть под запросами кровавого энтерпрайза :)). Но это всё, конечно, неизбежно. Нужно принять, что программируют люди не только для красоты, иногда им ещё приходится работать (в коллективе очень разных людей). Кроме сочувствия тут ничем не поможешь :). И стандарты выдумываются не столько для удобства программистов, сколько из соображений контроля рынка. И, я уверен, что Гослинг и сам это всё понимает, и подобные статьи — они не для аналитики, имхо, а для профессиональной солидарности, мол, жиза, братан. :)
В точку. Странно такое говорить программисту, но — эта статья о чувствах)
В какой-то момент все мы оверинжинерим, но, учитывая, то что творил там Райн, это ещё мало мата было, имхо))
Просто в очередной раз мужик напоминает зачем мы это делаем.
В какой-то момент все мы оверинжинерим, но, учитывая, то что творил там Райн, это ещё мало мата было, имхо))
Просто в очередной раз мужик напоминает зачем мы это делаем.
(Не очень понимаю, почему Райн у меня превратился в Гослинга, это у меня программирования :))
сдаётся мне потому, что www.film.ru/person/rayan-gosling )))
А мне думается, что весь этот кавардак растёт из незрелости ОС. ПО факту все эти слои призваны «дореализовывать удобный АПИ к железу». А этим должна заниматься ОС.
Как пример красивой реализации — Plan9, где каждая программа «отдаётся» через файловый интерфейс, где для того, чтобы вывести в окно текст — нужно просто записать этот текст в файловый дескриптор окна. Программы могут работать друг с другом без прослойки в виде человека и через простой интерфейс.
К примеру, чтобы обратиться с ПК к камере на телефоне — это сейчас архи-сложная задача. Потому что нет нормальной единой архитектуры. А в случае Plan9 — не важно где расположено устройство — ты работаешь с ним, как буд-то оно локальное — всё через файловый интерфейс. В результате снимается огромный пласт ненужной сложности.
Или другой пример — веб. Что нужно пользователю? По факту запустить удалённую программу «видео-просмотр-youtube» или «новостная-программа-habr». Которая от клиента берёт ввод, а отдаёт ему вывод. Всё просто, но… Но мы соорудили виртуальную машину (браузер), разорвали код посередине (визуализация с частями кода — js — в виртуальной машине, а хранение данных и их обработка — на сервере — бд+php). И всё это как-то дёргается через ajax. И чтобы хоть как-то с этой сложностью и неудобством (изначальным) работать — наворачиваются всякие NodeJs, Yii2 и т.п. фреймвёрки, которые вроде как упрощают, но как только нужно что-то посложнее — тонешь в их дополнительной сложности.
Возьмём стек сетевых протоколов — сертификаты, tcp, udp, http, https, ftp, smtp и ещё куча великов, программист должен всё это обрабатывать, думать о безопасности, об авторизации и т.д. и т.п.
А ведь это могла делать ОС… Через единый протокол связи (в Plan9 — 9P), который берёт авторизацию и транспортные задачи на себя, как часть ОС, а программист просто работает с файлами.
Но почему-то современная ИТ ещё недозрела до этой красивой и достаточной простоты. Нужно скорее писать, реализовывать новые революции, которые хоронят старых монстров и порождают новых, которым суждено тоже скоро погибнуть. И всё бы ничего, но эти монстры тратят наше время, которые мы могли бы тратить на создание полезных вещей, которые бы просто работали и не требовали их переписывать раз за разом.
Как пример красивой реализации — Plan9, где каждая программа «отдаётся» через файловый интерфейс, где для того, чтобы вывести в окно текст — нужно просто записать этот текст в файловый дескриптор окна. Программы могут работать друг с другом без прослойки в виде человека и через простой интерфейс.
К примеру, чтобы обратиться с ПК к камере на телефоне — это сейчас архи-сложная задача. Потому что нет нормальной единой архитектуры. А в случае Plan9 — не важно где расположено устройство — ты работаешь с ним, как буд-то оно локальное — всё через файловый интерфейс. В результате снимается огромный пласт ненужной сложности.
Или другой пример — веб. Что нужно пользователю? По факту запустить удалённую программу «видео-просмотр-youtube» или «новостная-программа-habr». Которая от клиента берёт ввод, а отдаёт ему вывод. Всё просто, но… Но мы соорудили виртуальную машину (браузер), разорвали код посередине (визуализация с частями кода — js — в виртуальной машине, а хранение данных и их обработка — на сервере — бд+php). И всё это как-то дёргается через ajax. И чтобы хоть как-то с этой сложностью и неудобством (изначальным) работать — наворачиваются всякие NodeJs, Yii2 и т.п. фреймвёрки, которые вроде как упрощают, но как только нужно что-то посложнее — тонешь в их дополнительной сложности.
Возьмём стек сетевых протоколов — сертификаты, tcp, udp, http, https, ftp, smtp и ещё куча великов, программист должен всё это обрабатывать, думать о безопасности, об авторизации и т.д. и т.п.
А ведь это могла делать ОС… Через единый протокол связи (в Plan9 — 9P), который берёт авторизацию и транспортные задачи на себя, как часть ОС, а программист просто работает с файлами.
Но почему-то современная ИТ ещё недозрела до этой красивой и достаточной простоты. Нужно скорее писать, реализовывать новые революции, которые хоронят старых монстров и порождают новых, которым суждено тоже скоро погибнуть. И всё бы ничего, но эти монстры тратят наше время, которые мы могли бы тратить на создание полезных вещей, которые бы просто работали и не требовали их переписывать раз за разом.
Одна вещь, которая имеет значение в разработке ПО это что чувствует пользовательСказал человек, поощряющий разработку на JavaScript'е.
Yeah, 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
НЛО прилетело и опубликовало эту надпись здесь
Недавно тоже пытался разобраться в том упрощают все-таки абстракции жизнь или усложняют. Пришел обратно к широко известной цитате Девида Уилера «Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности» В данном контексте интересно замечание Джоела Спольски в его статье про «дырявые абстракции»:
Все эти уровни сокрытия деталей делают вещи сложнее, требуя все более специализированных кадров, хотя и увеличивают производственные мощности. Это не значит, что нам нужно двигаться назад, от интегрированности к дискретности. Но это и не значит, что нужно слепо верить в то, что дополнительный уровень интегрированности устранит какую-то ни было сложность в системе. Более интегрированные системы, они ведь и более хрупкие. Чем больше слоев, каждый из которых может дать сбой, тем больше вероятности, что вся система на выходе даст сбой.
И никакое «нормально делай — нормально будет» тут не поможет. Касательно именно программных продуктов, вспоминается цитата Ларри Уолла: «три главных добродетели программиста: лень, нетерпение и самомнение». Вот они, основные причины, которые приводят к сложности программном обеспечении. Ведь каждый, конечно, думает, что ну уж он-то бы сделал куда лучше. Ага.
Ну и бизнес конечно добавляет, требуя наращивания производственных мощностей и снижения затрат. Вот и получается, что мы делаем более сложные продукты в более короткие сроки. Только слишком часто страдает качество, а еще чаще востребованность продукта на рынке. Слишком часто «инновации» в потребительском секторе вращаются вокруг интеграции.
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.— … парадоксальным образом, несмотря на то, что нам становятся доступны все более мощные инструменты разработки, с лучшими абстракциями, стать искусным разработчиком становится все труднее и труднее
Все эти уровни сокрытия деталей делают вещи сложнее, требуя все более специализированных кадров, хотя и увеличивают производственные мощности. Это не значит, что нам нужно двигаться назад, от интегрированности к дискретности. Но это и не значит, что нужно слепо верить в то, что дополнительный уровень интегрированности устранит какую-то ни было сложность в системе. Более интегрированные системы, они ведь и более хрупкие. Чем больше слоев, каждый из которых может дать сбой, тем больше вероятности, что вся система на выходе даст сбой.
И никакое «нормально делай — нормально будет» тут не поможет. Касательно именно программных продуктов, вспоминается цитата Ларри Уолла: «три главных добродетели программиста: лень, нетерпение и самомнение». Вот они, основные причины, которые приводят к сложности программном обеспечении. Ведь каждый, конечно, думает, что ну уж он-то бы сделал куда лучше. Ага.
Ну и бизнес конечно добавляет, требуя наращивания производственных мощностей и снижения затрат. Вот и получается, что мы делаем более сложные продукты в более короткие сроки. Только слишком часто страдает качество, а еще чаще востребованность продукта на рынке. Слишком часто «инновации» в потребительском секторе вращаются вокруг интеграции.
Интересно, сколько дней автор продержался бы на оракловской галере? Так как раз много времени на рефлексию, пока тесты бегают :-}
Статью следовало бы закончить знаменитым манифестом («пиши код, #$%ть!»)
Теперь ты должен знать не только $LD_LIBRARY_PATH, чтобы заставить систему работать, но ещё и $NODE_PATH — знай, это моих рук дело, это мое добавление сложности!
Каждый хочет быть столпом Вселенной
Никого не волнует объектная модель glib. Одна вещь, которая имеет значение в разработке ПО это что чувствует пользователь
Какой-то популизм, ей богу. Конечно, пользователя не волнует объектная модель glib, его волнует чтобы програмка быстро бегала и сайтик открывался. А чтобы это произошло — какого-то программиста должна волновать объектная модель glib. Не волнует — ну, переходите в пользователи и наслаждайтесь результатами работы других, а деньги зарабатывайте, работая дворником.
На недавнем девгаме Джонатан Блоу (автор Braid) рассказывал про усложняющиеся системы. Выводы весьма неутешительные.
Проблема сложности ПО рождается всеголишь… сложностью пользователя.
Причём, "пользователь" — не обязательно тот, кто "тыкает мышью в веб-страничку".
"Кодеры" — тоже пользователи.
Пользователи языков программирования, всевозможных инструментов создания программ.
Чем больше "слоёв пользователей" между железкой (процессором, машиной) и "конечным пользователем", тем больше "слоёв абстракций" в программе. Ведь, каждому "пользователю" нужно, чтобы именно его задача решалась как можно проще и надёжнее, даже если эта задача — всеголишь написать программу, решающую задачу другого пользователя.
Плюс множество разных аспектов использования одного и того же "конечного продукта".
Одним нужно, чтобы его можно было просто и удобноего модифицировать и обслуживать, другим нужно "удобно заказывать пицу", третьим удобно собирать информацию о покупателях пицы, и получать платежи, четвёртых волнует вообще только конечная прибыль.
И часто требования противоречат друг другу.
Вот потому и "сложность" — потому, что люди (отношения между людьми) — "слишком сложные"
Мне чем-то напомнило Закон Конвея
«создавая системы мы проектируем их так, что связи в этой системе воспроизводят связи между участниками этих систем».
А следствием из этого, вполне напрашивается озвученый Вами вывод:
organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizationsЕсли немного ее перефразировать, то получается, что,
«создавая системы мы проектируем их так, что связи в этой системе воспроизводят связи между участниками этих систем».
А следствием из этого, вполне напрашивается озвученый Вами вывод:
Вот потому и «сложность» — потому, что люди (отношения между людьми) — «слишком сложные»Т.е усложнение взаимодействия между людьми ведет к усложнению систем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Я ненавижу почти всё ПО