var authorization = false
Вход Регистрация

Чему программисты могут научиться у экономистов: теоретическим принципам и моделированию

  • 09 декабря 2015 в 13:05
  • 0
  • 810
  • Kirill
или: О стереотипности современных программистов, отсутствии у них системного мышления и о том, почему это удручает

Между экономикой и компьютерной наукой есть некоторые сходства. Обе они сильно стремятся предположить, что открывалка есть [1, в конце документа]. Обе очень ограничены в плане воспроизводимости полученных результатов. Обе науки кажутся простыми для изучения с точки зрения простого обывателя. И обе они легко привлекают общественное внимание и обсуждаются в обществе.

Есть между ними и серьезное отличие: экономисты всерьез заняты изучением теоретических принципов, прежде всего, рассмотрением гипотез и аксиом. У программистов, а нередко и других специалистов в области компьютерных наук в принципе не существует никаких базовых гипотез. Экономика делится на множество школ, которые, в свою очередь, можно отнести к тому или иному направлению — неоклассическому, неортодоксальному или какому-либо другому. Таким образом, экономисты, как правило, оперируют некой “Великой теорией” (таким же образом можно было бы создать “Великую абстракцию”) и получают с ее помощью заключения, основанные на рабочих концепциях этой теории. Сравните Мински, Мизеса, Сраффа, Окисио и Фридмана. Одна только теория монетаризма имеет самые различные эндогенные и экзогенные интерпретации. В каждой из них, экономисты вводят новые, уникальные подразделы и делают различные выводы относительно роли финансовых регуляторов и влияния частного и государственного долга.

В то время как экономика и другие научные направления стремятся выстроить структуру знаний “снизу вверх”, в программировании все часто получается “сверху вниз”. При этом“сверху вниз” – слишком щедрое определение, ведь на самом деле программирование имеет больше общего с попытками пройтись вслепую по этажам съехавшего набок похожего на чистилище строения, обитатели которого терпят бесконечные перерождения в порочном круге сансары.

У программистов плохо получается предлагать и критиковать модели, и в этом их недостаток. Им также свойственно полное игнорирование истории. В противоположность им, экономисты зачастую слишком полагаются на исторические данные, что уже стало в свое время объектом Критики Лукаса. В результате ни те, ни другие не способны проанализировать примеры из практики, увидеть важнейшие достижения в своих сферах или понять, какие достижения можно назвать инновационными. Не способны они и на обобщение тех или иных наборов данных, потому что все это они заменили рабочими инструментами своей профессии. Экономист сможет критически проанализировать модель на основе соотношений между ее переменными, справедливости аксиом, определений и терминов, отклонений от других интерпретаций и других данных. Программист же совершенно не ведает о каких-либо общих теориях и ему не остается ничего другого, кроме как использовать поверхностные знания, основанные на собственном опыте и наблюдении за внешним интерфейсом архитектуры ПО, которым он пользуется. Немногие, например, способны отделить идею файла от файловой системы, отличить файловую систему от иерархической файловой системы или общее понятие файла от файла, который хранится на диске или ответить на вопрос, о том, как можно смоделировать файл с точки зрения одноуровневого хранилища. Почему мы вообще отдаем предпочтение файлам, а не другим структурам хранения данных, например, боксам? Подобные вопросы можно продолжать. Жестокая ирония состоит в том, что в науке, которая вращается вокруг многоуровневых абстракций, не имеющих ярко выраженных направлений, слишком многие программисты оказываются не в состоянии размышлять достаточно абстрактно, довольствуясь вместо этого моделями, предоставленными им той или иной системой.

Причина по которой программисты не умеют мыслить независимо от опыта и делать обобщения на основе принципов, кроется в том, что даже при выборе своей профессии они не руководствуются какими-то ни было принципами. Более того, многие из них считают наличие таких принципов чем-то недопустимым. Отсутствие каких-либо мер, изящества или строгости подается на всеобщее обозрение в форме философии, которая поощряет людей действовать в духе “move fast and break things”, где “move fast” означает заново изобретать поломанный велосипед, не занимаясь никакими исследованиями или инновациями. Другой популярный девиз предлагает “делать все, что считаешь нужным, лишь бы заработало”.

Все это подкрепляется глубоким субъективизмом и антиинтеллектуализмом, царящими в сфере современных технологий. Попробуйте покритиковать какое-нибудь программное обеспечение и вы обнаружите, что сделать это практически невозможно. Не по причине существования объективных препятствий, но потому, что большая часть аудитории, которая читает эту критику просто не разбирается в предмете и высмеивает добавление любой технической подробности как попытку критикующего намеренно все усложнить. Это большинство будет отвергать критику, ссылаясь на аргументы в духе “главное, что у все меня работает” и идиотские предрассудки вроде того, что в компьютерных науках не существует никаких истин или фактов, только различные, практически равные по значимости и почти одинаково приемлемые мнения. В таких условиях любая попытка критики становиться слишком хлопотной и теряет всякий смысл. Желание программистов искажать термины при помощи использования общеупотребительных выражений, таких, например, как “многозадачность”, “в реальном времени”, только усложняет ситуацию, порождая бесконечную путаницу в семантике, даже при условии, что значение тех или иных слов было оговорено заранее. Добавьте к этому культуру, которая боготворит “прагматизм” и демонизирует академический подход, уничтожая всякое желание быть в первую очередь в курсе терминологии, и вы получите катастрофические результаты.

Кстати, это преданность отношение к “прагматизму", словно это какое-то божество сложно объяснить. Как правило, получается, что прагматичным считается такое решение проблемы, которое лучше всего подтверждает подсознательную модель мышления программиста. Крайне редко программисты оказываются способны на осознанное ее воплощение или анализ других моделей. Незначительные детали преобладают над самым важным и все это — во имя прагматизма. К “академикам” при этом относятся как к снобам, которые, в своем гордом одиночестве, якобы, совершенно не ведают о проблемах индустрии. Прагматиков, впрочем, не смущает тот факт, что сами они завязли в попытках заново изобрести все то, что академики уже изобрели и усовершенствовали десятилетия тому назад и потому справедливо считают эти изобретения устаревшими. Что и говорить, немногие сегодня вообще настроены на чтение литературы.

Ситуация в индустрии такова, что программист начинает зарабатывать себе на жизнь работая с актуально в наше время подходов (придуманное еще в 60-х годах того века и основанное на классах ООП). Затем, пользуясь распространенными среди коллег инструментами (PHP, Apache, MySQL), дорастает в своем профессионализме до основных трендов той или иной специализации (DevOps, контейнеры, SPA, ES6). После этого он испытывает легкий “приступ неортодоксальности”, который, впрочем, не выходит за пределы эхокамеры той же самой индустрии (функциональное программирование в чистом виде, unikernel’ы). Так, на протяжении всей свой карьеры, он практически не соприкасается с настоящими инновациями, во всяком случае с теми, которые могли бы иметь широкое применение. Вместо этого, на программист будет тешить себя иллюзиями о том, что является пионером стремительно меняющейся и постоянно развивающейся технологической сферы, где инновации сметают все на своем пути, свергая с трона старые идеи. Подобных взглядов может придерживаться только человек, который редко выбирается за пределы пузыря современных технологий, верящий в то, что фреймворки, инструменты и методологии могут, перемешавшись вместе, образовать нечто инновационное.

Странно в этой ситуации то, что многие программисты, не без удовольствия, продолжают усугублять ситуацию путем массового продвижения необходимости “учиться кодить”. Обратите внимание, упор делается на слове “кодить”. Написание кода сегодня превратилось в черновую работу для всех, кто связан с компьютерной наукой и созданием программ. Понять алголоподобную систему обозначений под силу любому желающему и это не займет много времени. А вот понимание тонких аспектов разработки ПО и работы вычислительных систем требует самоотдачи также как и любая другая область знаний. И тем не менее законодатели, лоббисты, предприниматели, а также крутые и таинственные хакеры считают, что “кодинг — это современная грамота” и громко требуют как можно скорее сделать обучение ему обязательным для всей молодежи. Это требование основывается на ложном предположении о том, что изучение популярной на этой недели версии Алгола дарует студентам возможность вновь обрести понимание окружающего мира, где все вокруг определяется программным обеспечением. Очевидно, это не так, во всяком случае, не более чем изучение английского поможет вам стать лингвистом. Ложное чувство знания хуже чем незнание. Попытки заставить печально известную своей неэффективностью систему государственного образования обучать программированию, которое по обыкновению ошибочно смешивают с информатикой, закончатся плохо. В противовес утверждениям поборников такого подхода, есть предметы более важные для обывателя, живущего в 21 веке, нежели программирование. Два из них я могу назвать, это статистика и личная финансовая грамотность. В конечном счете установка на “обучение кодингу” только еще больше снижает ценность всей сферы компьютерных знаний, вырабатывая к ней такое отношение, будто ее конечная цель — штамповать исполняемый код. Эта установка также ведет молодежь к бессмысленным “крысиным бегам” в сфере разработки программного обеспечения.

Если говорить об упомянутых выше крысиных бегах, то одной из ощутимых сил, которая ведет к этой порочной практике, является культура стартапов. Хакер предприниматель и хакер в стиле MIT — два разных зверя. Предприниматель все пропускает через призму сравнения затраченных усилий и полученного результата. В итоге устойчивость к ошибкам и глубина проектирования превращаются в статьи расходов и подвергаются серьезному ограничению. Мы видим культуру, которая поощряет быстрые итерации вплоть до того, что изменения становятся неконтролируемыми. Это также культура, которая провозглашает важность создания минимально устойчивого продукта, где устойчивость придается большое значение. Стартапы всецело фокусируют свое внимание на веб-приложениях, с которыми будут работать пользователи, или на живущих в вебе многоуровневых SaaS приложениях, которые помогли распространению “хакатонов” и “буткемпов”. Нет, речь идет не об уважаемых мероприятиях вроде OpenBSD hackathon, но всего лишь о публичных мероприятиях с почти нескрываемой целью которых является банальный набор персонала.

Ускоренное развитие доступных облачных платформ сделало возможным появление движения DevOps, которое ставит множество благородных целей, но в реальности представляет собой не более чем эффектную формулировку. Это формулировка относится к системным администраторам, которые, подобно островитянам Меланезии строившим из пальм и соломы посадочные полосы в ожидании самолетов с грузом, что-то конструируют из набора прикладных программ и надеются что эти конструкции призовут каких-то духов и те решат их задачи. Они пользуются узкоспециализированными и негибкими программами, такими, как Puppet, Ansible, Capistrano, Fabric, Docker, Vagrant и рассматривают проблему только в рамках их терминологии. Ни о каких идеях или абстракциях речи не идет. Перед нами “сисадмины”, которые не знают свой стек. Большая часть программирования в таких случаях сводится к “склеиванию” воедино отдельных компонентов некоего черного ящика. Последствия такого подхода включают в себя застой в изучении используемых в системе ПО (rump kernels и MirageOS всего лишь исключения из этого правила), так как такие изыскания не генерируют прибыль, а также полный отказ от технического языка в лендингах, описывающих программные решения для разработчиков.

Вместо конкретных деталей, большинство предлагаемых DevOps продуктов представлены туманными и запутанными описаниями, которые пытаются создать в уме яркое впечатление о неизбежности решения вашей проблемы, стоит вам только попытаться воспользоваться ими. Это попытка заманить программиста, чтобы тот сразу и без раздумий погрузился в работу с ними. Конечно, ни о каком предварительном анализе не может быть и речи. Благодаря такому подходу, целые области для исследования упрощаются до незамысловатых мемов. Надежность превращается в статическую проверку типов, функциональное программирование, устранение переменных состояний — звучные и эффектные словосочетания на деле, увы, оказываются всего лишь профилактическими техниками, каких придумано еще немало.

Программисты и многие другие технари часто пренебрежительно отзываются о философии. Однако сделать себе одолжение и изучить ее будет полезно хотя бы программистам. Если философия в своих попытках ответить на вопрос доходит до нелепостей далеко, то программирование, по сравнению с ней, напротив, ищет ответы прямо под носом.

Что же означает все вышесказанное? Многие программисты усомнятся в том, что теоретические принципы вообще существуют. Я нахожу такое отношение наивным. Конечно же, они существуют и регулярное чтение предметной литературы все более проливает на них свет. Однако я должен признать, что используемые сегодня способы изучения компьютерных технологий несовместимы с компьютерной наукой как с областью знаний. Эта информация разбросана по FTP серверам или электронным каталогам университетов, докладам для конференций, журналам, платным ресурсам или просто утеряны.

Теперь о главном. Ключевым аспектом в познании является системное мышление и способность рассуждать априори, не привязываясь а конкретному опыту, делать выводы об архитектуре ПО, основываясь на его внутреннем устройстве, проникать в суть основных его недостатков и оценивать его целостно, а не по одному только поверхностному наблюдению за его внешним API. Это минимальные требования, которые необходимо взять на вооружение для того, чтобы обсуждения компьютерных программ на самом деле выглядели как подлинно научные дискуссии, основанные на прочном фундаменте теории, а не просто как словесная перепалка, юмор или клише, которые сегодня являются нормой. Необходимо также помнить о том, как абстрактные идеи связанные с используемым ПО могут привести не туда. Приведенный выше пример рассуждений о том, что такое “файл” — лишь один из многих подобных. Подвергайте сомнению абсолютно все, поэтому я и рекомендую изучать философию.

Как только мы увидим среди нас подлинных программных мыслителей, философов программирования, которые ведут дискуссии на основе теоретических моделей систем и способны соединить в обсуждении данные об архитектуре внутреннего механизма работы, знания о предыстории своей профессии, а также способны отделить объективные характеристики решаемой проблемы от особенностей предложенного для нее решения — вот тогда мы освободимся от сансары.

[1] Физик, химик и экономист оказались на необитаемом острове. Есть им нечего. Вдруг волны выбрасывают на берег банку консервированного супа. Физик говорит: «Давайте откроем банку острым камнем». Химик предлагает: «Лучше разожжем костер и нагреем банку». Экономист говорит: «Давайте лучше предположим, что у нас есть открывалка».

Источник: DnE Blog

Комментарии (0) RSS
Комментариев пока нет. Напишите первый.
Только зарегистрированные пользователи могут оставлять комментарии. Зарегистрируйтесь или войдите