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

• Название: The Programmers Stone (Программистский камень)
• Автор: Alan Carter
• Жанр: Прочая околокомпьтерная литература

Попытка разобраться и понять, как программировать эффективно. С точки зрения авторов, проблема создания эффективных программ скрыта в способе мышления человека при решении задач. Людям свойственны две стратегии мышления — «паковка» (packing) и «отображение» (mapping). Стать хорошим программистом можно лишь освоив «отображение».

© Википедия

---

Principia. Три закона движения НьютонаТраектории в гравитации (включая движения вверх/вниз)Движение в среде с трениемГидростатикаМаятникиДвижение в жидкостях

Red Books. Энергия/Время и расстояние/ГравитацияДвижение/Три закона Ньютона/Движение вверх/внизМаятникиГидростатика и движение жидкости.

Advanced Level Physics. Три закона НьютонаМаятникиГидростатикаГравитацияЭнергия

Что отличает Advanced Level Physics — механика в ней увеличивает сложность уравнений в системе Хевисайда, в то время как в двух других работах намерения иные.

Ньютон начинает со своих трех законов, в то время как Фейнман вводит энергию раньше и оставляет три закона на потом. Но как только они определили некоторые термины, с которыми работают, оба гения начинают говорить нам о пространстве, где все всегда в движении, а затем заполняют картину. Они делают это задолго до обсуждения маятников, которые математически более просты, но являются специальным случаем по сравнению с планетами на орбитах.

Advanced Level Physics рассматривает маятники до гравитации и рассуждает о гидростатике, которую оба гения рассматривают гораздо позже, до того как вообще упоминается гравитация; к этому времени, как мы предполагаем, студенты уже научились очень эффективно выполнять вычисления, но их мысленная модель мироздания полна ссылок с неясными связями между ними.

Хотя это может показаться неудобным с точки зрения математики (хотя текст Ньютона, казалось бы, не зависит от математической интерпретации, но у Фейнмана мы должны принять ее во внимание), оба гения хотят перенести идею о всеобщем движении как можно ближе к началу.

Возможно ли изучить физику ошибочным путем и закончить изучение, умея выполнять вычисления, касающиеся происходящего в пространстве, но по-прежнему с ограниченным и запутанным взглядом на это происходящее?

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

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

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

Мы начнем с того, что оказываем вам любезность предположением вашей разумности. Представим, что вы изучаете синхронные процессы совместного использования ресурсов. Как хороший картостроитель, вы изучаете литературу, и размышляете над тем, что сказали другие. Вы также пытаетесь экспериментировать сами. Очень скоро вы начинаете видеть глубокие инвариантные структуры, как удачные, так и неудачные. Вы приходите к заключению, что ситуация потенциального тупика (deadlock) — это потенциальный тупик, не важно, замаскирован ли он сложностью. Вы также можете распознать потенциальный динамический тупик (livelock), когда с ним сталкиваетесь.

Для тех читателей, которые еще не пытались это изучить, мы советуем сделать это, поскольку слишком много часов работы программиста теряются именно на таких вещах, но кратенько расскажем о тупике и бесконечном цикле. Тупик (deadlock) возникает, когда два (или больше) процесса останавливаются во взаимном ожидании друг друга. Например, один процесс может захватить в исключительное пользование базу данных заказчиков, а другой захватывает в исключительное пользование базу данных о складе. Затем каждый процесс пытается получить в исключительное пользование базу, которой у него нет. Ни один из запросов не может быть удовлетворен, поскольку другой процесс уже получил запрошенное исключительное пользование. Поэтому менеджер базы данных оставляет оба запроса в подвешенном состоянии, оба процесса засыпают до момента, когда запрос сможет быть удовлетворен. Конечно же, этого никогда не произойдет, поскольку ни один из спящих процессов не освободит базу данных, которой он уже владеет, и спать им вечно. Самый простой способ избежать такой ситуации в реальных проектах — сделать это случайно, и это не особенно мудро. Слово customer после сортировки по алфавиту стоит перед словом stock, поэтому при массовой закупке напитков стоит обратиться сначала к базе данных склада до обращения к базе данных заказчиков, даже если это означает, что возникают ситуации, где только один уже имеет доступ к базе данных склада, и поэтому приходится освобождать склад, запрашивать заказчика, запрашивать склад. Это стоит делать и пусть так и будет, либо доступ будет предоставляться одновременно либо некоторый другой нужный процесс будет попадать туда и циклы будут хорошо использоваться.

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

Итак, теперь вы знаете о динамическом тупике. По горькому опыту вы узнали динамический тупик, и вы распознаете потенциальный динамический тупик, когда с ним столкнетесь. Теперь представьте, что вы собираетесь встретиться с другом. Вы не уверены, в каком из двух баров вы хотите встретиться, поскольку всегда один оживленный, в то время как другой похож на морг, и вы никогда не можете сказать как все будет на этот раз. Вы не знаете, в какой из них пойдете сначала. Эти два бара находятся в разных концах квартала. Конечно, вы знаете о динамических тупиках. Вы же не собираетесь, как бегающий по планете Земля мохнатый зверек [18], впадать в динамический тупик, накручивая с товарищем круги между этими двумя барами в поисках друг друга. Когда придет время назначать встречу, вы — тот, кто скажет: «А если ты захочешь проверить другой бар, погуляй по берегу реки у квартала, так что я увижу тебя, если попаду в ту же ситуацию!»

Это вы. Это вы человек такого типа. Человек, с которым вы собираетесь встретиться, уже восхищен вашим воображением и заботливостью, и одобряет этот план.

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

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

Теперь эта стратегия, точно так же как динамический тупик, является частью вас. Когда вы видите, что составляющие проблемы где-то повторяются, а составляющие вашей стратегии можно с очевидностью применить хоть сейчас, вы можете поклясться страшной клятвой «Это именно так!» и не сможете объяснить почему. Поэтому когда вы впоследствии излагаете свое элегантное, компактное понимание на языке программирования и заставляете его работать, то какого размера копия малой частички вас обеспечивает работу корпоративной сети 24 часа в сутки?

Это глубокий вопрос, и его не так просто понять. Чтобы увидеть, в чем тут суть, почитайте фантастическую повесть Марвина Мински и Гарри Гаррисона «Выбор по Тьюрингу» (The Turing Option by Marvin Minsky and Harry Harrison).

Для обладающих традиционным философским складом мышления мы в этой связи можем привести дополнительные наблюдения. Обычно сущность, такую как абстракция Платона «двойственность», нельзя увидеть непосредственно, а только как проявление: как двух собак, две ноги или два глаза. Обычно считается, что сущность обнаруживается некоторым образом в проявлениях, поскольку абстракция двойственности остается даже тогда, когда перед нами нет пары чего-либо. Проявление обычно, если завуалированно (covertly — в том смысле слова, как его использует Спенсер-Браун), выглядит как результат сущности.

Теперь посмотрим, что происходит при написании простейшей программы. Треугольник творчества, включающий в себя динамику проблемы, семантику системы и желание, определенно является проявлением, поскольку располагается в голове программиста, который должен действительно и физически существовать. Однако треугольник творчества остается в виде своего продукта, «вилки» («Хода Конем»), которая есть сущность построения карты (взаимосвязей) от динамики проблемы к семантике системы. «Вилка» («Ход конем»), которая есть сущность, в этом случае является образом треугольника творчества (и происходит из него), который есть проявление. Можно ли эту смену на противоположное обычно принимаемого направления онтологического приоритета соединить со странным путем, которым микросхема ПЗУ (ROM chip) получает специфицескую порцию отрицательной энтропии, побывав в наших руках?