Principia. Три закона движения НьютонаТраектории в гравитации (включая движения вверх/вниз)Движение в среде с трениемГидростатикаМаятникиДвижение в жидкостях
Red Books. Энергия/Время и расстояние/ГравитацияДвижение/Три закона Ньютона/Движение вверх/внизМаятникиГидростатика и движение жидкости.
Advanced Level Physics. Три закона НьютонаМаятникиГидростатикаГравитацияЭнергия
Что отличает Advanced Level Physics -- механика в ней увеличивает сложность уравнений в системе Хевисайда, в то время как в двух других работах намерения иные.
Ньютон начинает со своих трех законов, в то время как Фейнман вводит энергию раньше и оставляет три закона на потом. Но как только они определили некоторые термины, с которыми работают, оба гения начинают говорить нам о пространстве, где все всегда в движении, а затем заполняют картину. Они делают это задолго до обсуждения маятников, которые математически более просты, но являются специальным случаем по сравнению с планетами на орбитах.
Advanced Level Physics рассматривает маятники до гравитации и рассуждает о гидростатике, которую оба гения рассматривают гораздо позже, до того как вообще упоминается гравитация; к этому времени, как мы предполагаем, студенты уже научились очень эффективно выполнять вычисления, но их мысленная модель мироздания полна ссылок с неясными связями между ними.
Хотя это может показаться неудобным с точки зрения математики (хотя текст Ньютона, казалось бы, не зависит от математической интерпретации, но у Фейнмана мы должны принять ее во внимание), оба гения хотят перенести идею о всеобщем движении как можно ближе к началу.
Возможно ли изучить физику ошибочным путем и закончить изучение, умея выполнять вычисления, касающиеся происходящего в пространстве, но по-прежнему с ограниченным и запутанным взглядом на это происходящее?
В The Quantum Self Данах Зохар (Danah Zohar) рассмативает некоторые вопросы, имеющие отношение к природе сознания. Одна идея из науки о сознании предполагает, что феномен сознания возникает из сложных взаимосвязей между вещами, которые сами по себе не являются сознательными. Возникает вопрос, а каким может быть самое маленькое сознание? Может ли электрон, летая вокруг и делая эти волново-корпускулярные штучки, быть маленьким кусочком сознания?
Мы поставили вопрос Зохар не для того, чтобы прямо на него ответить, но чтобы попытаться подойти к нему с другой стороны. И, как и со всеми этими "Забавными Вещами", мы стремимся не предоставить информацию, а просто продемонстрировать, насколько тесно каждодневная работа программиста реально приближается к высочайшему искусству и глубочайшему волшебству.
Мы начнем с того, что оказываем вам любезность предположением вашей разумности. Представим, что вы изучаете синхронные процессы совместного использования ресурсов. Как хороший картостроитель, вы изучаете литературу, и размышляете над тем, что сказали другие. Вы также пытаетесь экспериментировать сами. Очень скоро вы начинаете видеть глубокие инвариантные структуры, как удачные, так и неудачные. Вы приходите к заключению, что ситуация потенциального тупика (deadlock) -- это потенциальный тупик, не важно, замаскирован ли он сложностью. Вы также можете распознать потенциальный динамический тупик (livelock), когда с ним сталкиваетесь.
Для тех читателей, которые еще не пытались это изучить, мы советуем сделать это, поскольку слишком много часов работы программиста теряются именно на таких вещах, но кратенько расскажем о тупике и бесконечном цикле. Тупик (deadlock) возникает, когда два (или больше) процесса останавливаются во взаимном ожидании друг друга. Например, один процесс может захватить в исключительное пользование базу данных заказчиков, а другой захватывает в исключительное пользование базу данных о складе. Затем каждый процесс пытается получить в исключительное пользование базу, которой у него нет. Ни один из запросов не может быть удовлетворен, поскольку другой процесс уже получил запрошенное исключительное пользование. Поэтому менеджер базы данных оставляет оба запроса в подвешенном состоянии, оба процесса засыпают до момента, когда запрос сможет быть удовлетворен. Конечно же, этого никогда не произойдет, поскольку ни один из спящих процессов не освободит базу данных, которой он уже владеет, и спать им вечно. Самый простой способ избежать такой ситуации в реальных проектах -- сделать это случайно, и это не особенно мудро. Слово customer после сортировки по алфавиту стоит перед словом stock, поэтому при массовой закупке напитков стоит обратиться сначала к базе данных склада до обращения к базе данных заказчиков, даже если это означает, что возникают ситуации, где только один уже имеет доступ к базе данных склада, и поэтому приходится освобождать склад, запрашивать заказчика, запрашивать склад. Это стоит делать и пусть так и будет, либо доступ будет предоставляться одновременно либо некоторый другой нужный процесс будет попадать туда и циклы будут хорошо использоваться.