The Programmers' Stone (Программистский камень)

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

Личная ответственность и лидерство

      Картостроителям свойственно обмениваться и согласовывать свои мысленные модели. Тогда для увеличения взаимного знания они могут легко ссылаться на аспекты этих моделей нестрогим языком. Они также делают акцент на получении оптимального решения, им более комфортна модель совместной работы победитель/победитель, а не победитель/проигравший.
      Все эти факторы ведут к общей тенденции, которая возникает, когда картостроители собираются вместе поделиться проблемами и решениями и научить друг друга. Эта кооперативная тенденция -- важная часть хакерской культуры.
      Простой факт состоит в том, что методы картостроения, особенно картостроения в данной области, -- мощное искусство. То, что на формальных курсах мы быстро загружаем новые языки и обозначения в мозги программиста -- это только крем на торте. Реальное обучение происходит на работе, по мере того, как опытные люди показывают новичкам методы, которые они могут найти полезными. Потом новички сами оценивают, что использовать и как использовать, в свете состояния предмета, в который они вошли. Это один из способов быстро войти в курс дела и причина, по которой наша область так быстро эволюционирует.
      Мы можем работать с этим знанием и культивировать его, чтобы взять контроль над нашими собственными разработками, либо можем игнорировать его и играть в "перечни навыков" (skills summaries), перечисляющие языки программирования. Мы предполагаем, что разумный способ взять управление уже был найден как естественное следствие из проблем. Наша индустрия опутана формальными, но произвольными классификациями, но та, которую мы предлагаем, неформальна, но реальна, и она уже существует, нужно только открыто рассмотреть ее на рабочем месте.
      Традиционно, тех, кто начинает учиться навыкам ремесла, называют подмастерьями. Им с самого первого дня поручают реальную работу, но всегда под присмотром более опытного работника. Когда становится очевидным, что присмотр более не требуется, подмастерья признают квалифицированным работником, на которого можно положиться, что он хорошо сделает работу и сможет руководить подмастерьями, которые могут понадобиться ему в помощь.
      Многим компетентным работникам нравится работа ремесленника, использующего свои навыки, и они остаются ремесленниками на всю оставшуюся жизнь. Они предпочитают, чтобы другой человек, возможно с другим темпераментом, взял ответственность за успех проектов. Такой человек не может быть назначен номинально. У него может быть высокая квалификация, напор и знание природы профессии, а может и не быть. В то время, как мастерство разработчика может расти под руководством других, это новый мастер, который должен найти свой собственный голос. Следующие мысли направлены студентам, а не учителям. Чтобы стать признанным мастером, ремесленник должен создать образец искусства. В нем он демонстрирует свою способность создать качественный образец. В старые времена, когда работа была связана с материальными изделиями, этот образец был чем-то выдающимся, поскольку новый мастер хотел продемонстрировать уровень мастерства, и, вероятно, никогда больше не стал бы делать ничего столь же причудливого. Более поздние изделия были бы направлены на удовлетворение реальных потребностей, и поэтому более соответствовали бы своему назначению. Таким образом, образец мастера -- это на самом деле самый нижний уровень работы мастера, а не высший, как это можно было бы предположить из общих соображений. В наше время, образец мастера -- эта целая система, выведенная на плато качества, и единственное отличие состоит в том, что мы питаем отвращение к ненужным бантикам и бубенчикам (наворотам и примочкам). По-прежнему, образец мастера -- это самая первая система, а все последующие должны быть лучше, как это и происходит у всех хороших программистов, опыт которых мы всегда изучаем. Один из доводов в пользу того, что программистам легче учиться друг у друга, состоит в том, что мы одновременно и учителя и ученики, и очень быстро переходим из одного состояния в другое.
      Из этой модели мастерства проистекает ряд следствий. Во-первых, она максимально повышает одновременно проработанность и продуктивность. Управляющий проектом мастер должен гарантировать, что каждый член команды работает в пределах своей квалификации, но на самом пределе. Для компетентных программистов нет недостатка работы, поэтому поиск приложения своего мастерства не является проблемой. Это требует от работников приложения усилий, которые не только приносят непосредственные дивиденды, но также гарантируют, что ресурсы используются максимально эффективно, это как раз то, чего хотят добиться бухгалтеры, но чего не может быть в процедурной модели, скопированной с индустрии паковщиков, основанной на повторении. Нет двух похожих церквей, нет двух похожих систем.
      Другое соображение, о котором уже знают все программисты, но которое стоит повторить в обществе паковщиков с их победителями/проигравшими, заключается в том, что страх учиться на работе, который овладевает многими профессионалами, к нам не имеет никакого отношения. Мы стоим на пороге новой культурной эры. Оглядитесь и посмотрите, можете ли вы найти какое-нибудь способ сделать общество более интеллигентным. Вы когда-нибудь пытались купить лошадь? Еще долгое время не будет недостатка в работе для программистов, а когда будет, пусть все сделают роботы, а мы просто запрограммируем забавную графику, которая будет крутиться на наших карнавалах.

Фальшивая цель деквалификации

      Этот раздел явно остановится на том, что несколько раз упоминалось в этой работе, поскольку это составляет существенное отличие во взглядах картостроителей и паковщиков на рабочее место.
      Видение мира паковщиком неестественно -- ему приходится тренироваться быть ребенком вместо того, чтобы развивать естественные для детей способности познавать мир. Вероятно, это была самая дешевая форма минимального образования и максимальной организации с начала аграрной эры и до конца индустриальной. В это время люди выполняли повторяющиеся задачи в материальном мире.
      Видение мира картостроителем использует и развивает естественные человеческие мыслительные способности по исследованию идей и в информационную эру является для людей уникальным резервом.
      Программирование -- это деятельность картостроителей. Если мы на самом деле вынуждены снова и снова писать одну и ту же программу, какая-нибудь светлая голова разработает готовый продукт (COTS), и программист будет не нужен.
      Традиционный взгляд паковщика на любую работу состоит в том, что он предполагает, что это повторяющаяся лишенная смысла деятельность, и пытается найти способ, как сделать ее как можно проще, оптимизировать ее, и если не полностью автоматизировать, то снизить требования к квалификации, чтобы уменьшить затраты на работников.
      Утверждать, что стратегия паковщика, которая применима к тюкам сена, также применима и к любой другой работе, просто потому, что в нее вовлечено много людей -- значит останавливать движение от примитивной материальной экономики, когда человек -- это убогая замена лошади или паровой машины, или даже станка с программным управлением, к информационной экономике, когда черная работа менее необходима, чем понимание или творчество.
      Фильм "Субботний вечер и воскресное утро" ( Saturday Night and Sunday Morning) начинается с показа рабочего в механическом цехе, занятом массовым производством компонентов на станках. "Девятьсот девяносто восемь ... девятьсот девяносто, блин, девять ...", бормочет он. Безысходность в том, что на самом деле это замечательно отражает положение в наше время. В те времена менеджеры платили рабочим за произведенные детали, передавая рабочим реальную силу и инициативу оптимизировать. В контексте программного обеспечения, нам не следует пытаться контролировать каждый аспект ввода 1000 строк одного и того же кода каждый день, нам следует спросить, почему работник до сих пор не написал макрос.
      Концепция деквалификации буквально пронизывает наше общество, и это делает ее очень вредной. Одурманенное сознание может положить ее перед вами, но все аргументы в ее пользу фальшивые. Никогда не забывайте об этом.
      Держа в уме недопустимость деквалифицирующих программ, мы можем исследовать ряд мифов. Даже в сфере массового материального производства трудно сравнивать похожее с похожим. Например, мы можем сравнивать производство автомобилей за этот месяц и за прошлый месяц, и посмотреть в каком из них оно было лучше. А за прошлый год? Мы использовали тогда три разных вида блоков фар и предлагали пять окрасок. А десять лет назад? Каждый аспект технологии -- антиблокировка тормозов, система управления автомобилем, воздушные мешки, состав топлива -- все изменилось. Требуется настоящее озарение, чтобы просто рассказать, насколько мы богаче, чем предшественники! Академические попытки сравнения отношения заработной платы к цене за большой период времени скатываются к затратам на покупку кирпичей и хлеба, поскольку на протяжении многих столетий только эти вещи можно было всегда пойти и купить! Ну что мы можем поделать с поразительным экспоненциальным ростом "улучшения производительности", связанным с каждым новым "прорывом в технологии", который позволит вам набрать в штат проекта орангутангов и получать от них по 10 миллионов строк кода (10 MLOCS) в секунду. С чем на Земле можно сравнить этот рост? Нам приходится делать вывод о том, какие ужасные кучи мусора вываливают на нас в каждой статистически убогой работе.
      А что такое "дружественные пользователю метафоры", означающие, что орангутанги теперь могут делать все, что им нравится, не требуя квалификации? Мы предполагаем, что истинная ситуация заключается в том, что некоторые сегменты рынка эксплуатируют миф о том, что возможна деквалификация в управлении сложностью, и предлагают продукты, которые при поверхностном изучении в течение короткого времени на самом деле кажутся "простыми в использовании". Трагедия в том, что на самом деле пользователям приходится выполнять операции типа конфигурирования адресов IP, брандмауэров, дисков, сканнеров, принтеров, совместно используемых дисководов, бюджетов и т.д. В этом месте мы обнаруживаем, что вместо компьютера, не требующего никакой квалификации, поскольку он претендует на роль еще одного предмета мебели типа стола, у нас оказывается компьютер, к которому обычные навыки работы с компьютером не применимы, поскольку, в конце концов, столу не нужно иметь сконфигурированных бюджетов, поэтому при его использовании нет необходимости в навыках конфигурирования бюджета пользователя стола. Мы неожиданно обнаруживаем, что даже в привычных ситуациях, когда вдруг решили установить новый IP без перезагрузки всей машины, "шароварные" системы, не отказывающиеся от звания компьютеров, оказываются более дружественными пользователю, чем так называемые "дружественные пользователю" штуковины.

Пути к отступлению

      Как работающие в реальном коммерческом окружении профессиональные программисты, мы часто работаем в жестких временных рамках, так что мы не можем гарантировать достижения настоящего плато качества решения в пределах этих рамок. Важная часть персонального послойного процесса и неформальная часть плана управления проектом в достаточно зрелой организации состоит поэтому в определении и постоянном переопределении наших непредвиденно изменившихся планов.
      Наиболее общим случаем корректировки плана является, к сожалению, сокращение функциональности. Это редко бывает эффективным способом экономии времени, поскольку большая часть низкоуровневой функциональности обычно все равно нужна для поддержки работы ужатых слоев приложения, которые в любом случае должны быть дешевыми в реализации, если нижние уровни обеспечивают правильную специализацию прикладного уровня.
      Мы предполагаем, что более эффективен следующий подход:
      Во-первых, правильно разбейте на уровни. Выясните суть API каждого выявленного уровня.Во-вторых, примените совет Кена Томпсона (Ken Thompson), `Если сомневаетесь, применяйте грубую силу.' Определите раздутый, дорогой, неэффективный, тяжелый в реализации и ужасный способ обеспечения функциональности на каждом уровне. Не важно, что вся система в целом может просто не работать, если реализовать ее именно таким способом, поскольку этого не будет.В-третьих, обеспечьте достижение плато качества на каждом уровне. Пересматривайте время от времени свою незрелую методику и добавляйте в нее те хорошие части, которые у вас уже есть, а остальное заполняйте по возможности различными грубыми методами.В-четвертых, когда начнутся трудности, исходя из краткосрочных и среднесрочных потребностей заказчика и имеющегося времени сделайте на свой риск оптимальный выбор, какие части будут поставлены сырыми, а какие стоит сделать максимально хорошо.
      Этот подход имеет огромное преимущество, позволяющее делать наилучшие возможные в данный момент вещи. Вы не сможете сделать для вашего заказчика что-либо лучшее, чем это.
      Когда уровни могут быть реализованы вчерне, и если у вас уже есть фрагменты, которые вы написали для тестирования операционной системы и API специальных библиотек, то вы на самом деле в состоянии очень быстро создать сырую версию. Это дает каждому программисту общий набор тестовых заглушек, значительно уменьшающих риск из-за одновременного создания всех уровней.

Новички в команде

      Будьте внимательны к присоединяющимся к команде новым работникам. Как и во всей этой работе, мы не подразумеваем под этим сентиментальную болтовню ритуала "добро пожаловать к нашему шалашу": мы подразумеваем нечто более практичное.
      Команда обладает мысленной моделью работы. Посвятите в нее новичков. Убедитесь, что они понимают, что наступает Моделирование Ситуации и пригласите их. Объясните цель проекта, затем поясните весь используемый в проекте внешний (со стороны заказчика) и внутренний (мысленная модель) язык. Дайте обзор среды разработки, включающей инструменты, средства управления конфигурацией, компиляторы и т.д. Не заставляйте их спрашивать о каждой стадии.
      Никогда не совершайте ошибку, заботливо обеспечивая им стол, стул, рабочую станцию, но не предоставляя бюджет (account) и конкретного дела. Хуже всего, когда приходящий на новый проект становится похожим на лимон [в смысле киснет - С.К.], а каждая следующая минута кажется длиннее предыдущей.
      На BT (British Telekom) очень эффективно использовалась очень удачная практическая идея, которая состоит в представлении новичка официальному "назначаемому другу". Этот назначаемый друг -- равный ему по должности, кто уже давно работает в команде, и явно представляется как источник информации, которого "можно беспокоить" по поводу всего, что нужно узнать новичку. Одно из замечательных свойств этого подхода в том, что будучи равным, назначаемый друг будет знать правильные ответы на вопросы новичка. Бумага обычно лежит в коричневом шкафу, а листы A3 для больших диаграмм -- в зеленом ящике внизу.

Ричард Фейнман

      Для любого, кто желает принести на рабочее место силу картостроителя, будет очень полезным изучение жизни и работы физика Ричарда Фейнмана (Richard Feynman). Он рассказывал историю. Отец показал ему одну из певчих птиц (Spencers' Warbler -- певчая птица Спенсера). Ее название было придуманным. Затем отец привел ему названия этой птицы на многих других языках, и оказалось, что маленький Фейнман узнал не больше, чем в начале. Механически запомненные названия вещей ничего не значат. Только посмотрев на саму птицу, о ней можно будет сказать хоть что-то.
      Он был чрезвычайно честным и видел сквозь искусственную сложность, всегда настаивая на простоте и фактах. Посмотрите на его личную версию отчета о расследовании гибели "Челленджера" (The Challenger Report), которая приведена в его книге "Почему тебя беспокоит, что другие думают?" ( What Do You Care What Other People Think?)
      [ The Challenger Report -- речь идет о космическом корабле "Челленджер"; Фейнман участвовал в расследовании катастрофы и обнаружил причину аварии -- затвердевшую при минусовой температуре резину прокладок - прим. Viktor Zhumatiy ]
      У него был простой, веселый, любопытный стиль письма, полный маленьких зарисовок и вдохновения. Его методы прикалывания помпезности вызывают естественный смех.
      Недавно были опубликованы его "Лекции по вычислениям" ( Lectures on Computation), и их стоит почитать, как и все, что он писал, начиная с "Шести легких частей" ( Six Easy Pieces)до "Красных книг лекций" ( Red Book Lectures). Книги Джеймса Глейка "Гений" (James Gleick's Genius) и Джона Гриббена "Ричард Фейнман" (John Gribben's Richard Feynman) -- прекрасно написанные биографии.
      Добудьте эти книги и прочтите.

Джордж Спенсер-Браун

      "Законы формы" ( The Laws of Form) Джорджа Спенсера-Брауна (George Spencer-Brown) -- это небольшая книжка по математике с комментариями, которая, по мнению современных логиков, содержит форму "модальной логики" ('modal logic'), характеризуемую тем, что в ней есть правила логической системы, которые по-разному применяются в разных местах в манере, определяемой правилами самой логики.
      С точки зрения программиста, есть два аспекта этой книги, которые несомненно будут стимулировать мышление. В основном тексте автор показывает, как создать логику предиката только с одним символом, предлагая более глубокий, чем можно предположить, взгляд на "фундаментальные" логические и вычислительные операции типа NOT, OR, AND, XOR.
      Затем идут примечания, простые и глубокие, к которым возвращаешься вновь и вновь, часто сформированные с помощью методов логики предикатов с одним символом, которые можно рассматривать как простое разделение плоскости на две части таким образом, что они становятся двумя отдельными вещами, и при этом есть о чем сказать. Например, автор говорит
      На некоторой стадии во всей математике становятся явными шоры, которые оказываются на нас при следовании в течение некоторого времени правилу без осознания этого факта. Это можно описать как использование завуалированного соглашения. Существенный аспект развития математики состоит в развитии понимания того, что же мы делаем такого, что при этом тайное становится явным. Математика в этом аспекте психоделична.
      Или,
      При обнаружении доказательства мы должны совершать нечто более искусное, чем поиск. Мы должны посмотреть на уместность некоторого факта по отношению к утверждению, которое мы хотим доказать, с точки зрения общей картины и тех фактов, в справедливости которых мы уверены. Несмотря на то, что мы можем знать, как осуществлять поиск того, что мы не можем видеть, утонченность метода "нахождения" того, что мы уже можем видеть, может гораздо проще завершить наши усилия.
      Или,
      Любые великие открытия в математике и других дисциплинах, если уж они совершены, кажутся чрезвычайно простыми и очевидными, и делают всех, включая открывателя, глупцами, которые до сих пор не могли этого открыть. Слишком часто забывается, что древним символом источника зарождения мира является шут (дурак), и эта глупость, будучи божественным состоянием, не является обстоятельством, которым можно гордиться или осуждать его.
      К сожалению, мы находим, что сегодня системы образования настолько далеко отошли от этой простой истины, что учат нас гордиться тем, что мы знаем, и стыдиться невежества. Это порочно дважды. Это порочно не только потому, что гордость -- сама по себе смертный грех, но, кроме того, учить гордости за знания -- значит воздвигнуть эффективный барьер перед развитием того, что мы уже знаем, поскольку он делает стыдными попытки посмотреть по ту сторону стены, воздвигнутой собственным невежеством.
      Для любого человека, готового с уважением вступить в царство своего великого и всеобщего невежества, секреты бытия в конце концов раскроются, и они будут раскрываться в мере, соответствующей его свободе от естественного или внушенного стыда в его отношении к их раскрытию.
      Перед лицом сильного и действительно яростного социального давления на них, немногие люди готовы принять этот простой и благодарный путь к здравомыслию. И кто в обществе, где видный психиатр может заявлять, что, если бы был шанс, то подверг бы Ньютона электрошоковой терапии, может упрекать того, кто боится так делать?
      Чтобы постигнуть такую наипростейшую истину, которую знал и применял Ньютон, требуются годы размышлений. Не деятельности. Не доказательств. Не расчетов. Не упорного труда. Не чтения. Не разговоров. Не прикладывания усилий. Не думания. Просто удержания в мозгу того, что нужно знать. А еще те, кто смело идет этим путем к реальному открытию, не только не получают практически никакой поддержки в том как это делать, они активно подавляются и вынуждены хранить свое открытие в секрете, притворяясь, между тем, что они вовлечены в безумные заблуждения и соответствуют тем тупиковым взглядам, в которые окружающие не перестают верить.
      Какое великолепное описание так долго обсуждаемого нами коммуникационного барьера между картостроителями и паковщиками, и вряд ли кто скажет лучше! Наконец, вот видение силы картостроительной стратегии познания как продолжающей поиск в основе изучаемого явления еще более глубокой структуры, что обусловлено способом, которым мы выбираем, выполняя отдельное различение в пустоте,
      Мы обдумываем, полностью сконцентрировавшись на этом, форму отдельной конструкции ... основываясь на самом первом отличии. Суть результата нашего обдумывания -- как оно может появиться, в свете различных состояний ума, в которые мы себя вводим.
      Еще он говорит,
      Таким образом, мы не можем отбросить факт, что мир, который мы знаем, создан таким, чтобы видеть себя (и, таким образом, чтобы быть способным видеть).
      Богатство из максимальной простоты. Предел сокращения сложности и искусство использования треугольника творчества, чтобы поместить "вилку" (сделать "ход конем") нашего восприятия на правильный для наших целей уровень абстракции. Как программисты, мы работаем, и каждым своим действием доказываем это, в точно таком же творческом пространстве, как и большинство абстрактных математиков и поэтов. Помня слова Джорджа Спенсера-Брауна, взгляните на это стихотворение Лори Ли (Laurie Lee), и задайтесь вопросом, ваш код когда-нибудь рисовал структуру предметной области, делал все, что он должен был сделать, и выглядел ли при этом так же совершенно?
       Fish and Water
      A golden fish like a pint of wine
      Rolls the sea undergreen,
      Glassily balanced on the tide
      Only the skin between.
      Fish and water lean together,
      Separate and one,
      Till a fatal flash of the instant sun
      Lazily corkscrews down.
      Did fish and water drink each other?
      The reed leans there alone;
      As we, who once drank each other's breath,
      Have emptied the air, and gone.

Книга по физике как продукт культуры

      Нас регулярно приглашают посмотреть на мир определенным образом -- пользователи, которые верят, что они понимают свой мир, стиль и подходы гуру, наши собственные предубеждения. Мы постоянно стремимся увидеть мир таким, какой он есть, таким образом, что мы делаем его представления в наших системах как можно проще. Точно также как нужно (хотя бы раз) увидеть плато качества перед тем, как мы сможем его распознавать, поэтому приходится "ходить кругами вокруг Защитной Полосы и смотреть, сколько раз они зажигают огонь"; приходится подвергать сомнению предположительно целостную реальность, пока не появиться возможность узнать, в чем тут дело.
      Не может быть ничего более целостного, чем Уровень Физики: у любого, кто говорит, что это продукт культуры, общественное соглашение между циничными физиками, чтобы сделать мир непонятным для цивилизованных людей с гуманитарным образованием, определенно поехала крыша. Странная вещь, некоторые люди талантливо доказывают, что законы физики создаются физиками, а не открываются, и следует пресечь их попытки сделать законы другими!
      Настоящая трагедия этих глупых болтунов в том, что если бы им удалось хоть немного изучить физику, они смогли бы обнаружить, что хотя законы физики существовали задолго до изучавших их физиков и совершенно независимы от воззрений физиков, понимание пространства, которое мы рисуем исходя из этих законов, может, тем не менее, быть продуктом культуры.
      Чтобы пояснить это замечательное утверждение, нам нужно сослаться на трех физиков. Исаак Ньютон (Isaac Newton) открыл современную механику, и записал свои открытия в основном на латыни, а не в символическом виде, как мы это делаем сегодня. То, что было изобретено викторианцем Оливером Хевисайдом (Oliver Heavyside), и что мы обычно называем "ньютоновской" физикой, было бы ближе к действительности называть интерпретацией Хевисайдом физики Ньютона. Ричард Фейнман был физиком нашего времени, который попытался обобщить в Красных Книгах ( Red Books) то, что уже было известно, настолько элегантно, насколько он смог это сделать. Вещи становятся интереснее, когда мы сравниваем содержание в "Принципах" гениального Ньютона ( Principia), главы "Красных книг" Фейнмана, в том, что было известно Ньютону, и главы "Современной физики" ( Advanced Level Physics) Нелкона и Паркера (Nelkon and Parker) (стандартный британский учебник), тоже в пунктах, которые были известны Ньютону.
       Principia.Три закона движения НьютонаТраектории в гравитации (включая движения вверх/вниз)Движение в среде с трениемГидростатикаМаятникиДвижение в жидкостях
        Red Books.Энергия/Время и расстояние/ГравитацияДвижение/Три закона Ньютона/Движение вверх/внизМаятникиГидростатика и движение жидкости.
       Advanced Level Physics.Три закона НьютонаМаятникиГидростатикаГравитацияЭнергия
      Что отличает Advanced Level Physics-- механика в ней увеличивает сложность уравнений в системе Хевисайда, в то время как в двух других работах намерения иные.
      Ньютон начинает со своих трех законов, в то время как Фейнман вводит энергию раньше и оставляет три закона на потом. Но как только они определили некоторые термины, с которыми работают, оба гения начинают говорить нам о пространстве, где все всегда в движении, а затем заполняют картину. Они делают это задолго до обсуждения маятников, которые математически более просты, но являются специальным случаем по сравнению с планетами на орбитах.
       Advanced Level Physicsрассматривает маятники до гравитации и рассуждает о гидростатике, которую оба гения рассматривают гораздо позже, до того как вообще упоминается гравитация; к этому времени, как мы предполагаем, студенты уже научились очень эффективно выполнять вычисления, но их мысленная модель мироздания полна ссылок с неясными связями между ними.
      Хотя это может показаться неудобным с точки зрения математики (хотя текст Ньютона, казалось бы, не зависит от математической интерпретации, но у Фейнмана мы должны принять ее во внимание), оба гения хотят перенести идею о всеобщем движении как можно ближе к началу.
      Возможно ли изучить физику ошибочным путем и закончить изучение, умея выполнять вычисления, касающиеся происходящего в пространстве, но по-прежнему с ограниченным и запутанным взглядом на это происходящее?

Думают ли электроны?

      В The Quantum SelfДанах Зохар (Danah Zohar) рассмативает некоторые вопросы, имеющие отношение к природе сознания. Одна идея из науки о сознании предполагает, что феномен сознания возникает из сложных взаимосвязей между вещами, которые сами по себе не являются сознательными. Возникает вопрос, а каким может быть самое маленькое сознание? Может ли электрон, летая вокруг и делая эти волново-корпускулярные штучки, быть маленьким кусочком сознания?
      Мы поставили вопрос Зохар не для того, чтобы прямо на него ответить, но чтобы попытаться подойти к нему с другой стороны. И, как и со всеми этими "Забавными Вещами", мы стремимся не предоставить информацию, а просто продемонстрировать, насколько тесно каждодневная работа программиста реально приближается к высочайшему искусству и глубочайшему волшебству.
      Мы начнем с того, что оказываем вам любезность предположением вашей разумности. Представим, что вы изучаете синхронные процессы совместного использования ресурсов. Как хороший картостроитель, вы изучаете литературу, и размышляете над тем, что сказали другие. Вы также пытаетесь экспериментировать сами. Очень скоро вы начинаете видеть глубокие инвариантные структуры, как удачные, так и неудачные. Вы приходите к заключению, что ситуация потенциального тупика (deadlock) -- это потенциальный тупик, не важно, замаскирован ли он сложностью. Вы также можете распознать потенциальный динамический тупик (livelock), когда с ним сталкиваетесь.
      Для тех читателей, которые еще не пытались это изучить, мы советуем сделать это, поскольку слишком много часов работы программиста теряются именно на таких вещах, но кратенько расскажем о тупике и бесконечном цикле. Тупик (deadlock) возникает, когда два (или больше) процесса останавливаются во взаимном ожидании друг друга. Например, один процесс может захватить в исключительное пользование базу данных заказчиков, а другой захватывает в исключительное пользование базу данных о складе. Затем каждый процесс пытается получить в исключительное пользование базу, которой у него нет. Ни один из запросов не может быть удовлетворен, поскольку другой процесс уже получил запрошенное исключительное пользование. Поэтому менеджер базы данных оставляет оба запроса в подвешенном состоянии, оба процесса засыпают до момента, когда запрос сможет быть удовлетворен.