Хакеры сновидений - Архив 1-6

Ligth

Думаю лучше и перспективнее всё описывать с точки зрения объекто-ориентированного программирования (инкапусяция ,полиморфизм, наследование):

То есть вокруг имеем множество объектов, обладающих заключенными в них свойствами(атрибутами), и действиями(взаимодействиями), и соответсвенно связями через методы.

Атрибуты в хорошем коде недоступны пользователю, но он может их получить через методы объекта, причем методы тоже имеют область доступа(личные(private), защищенные(protected, только для наследников) и public(для всех)).

Тогда мир будет представлен программой в лучшем случае являющейся методом некоего класса(объекта), в которой определы объекты, их атрибуты и методы, точками взаимодействия между ними будут методы объектов и точки вызова/возврата из главного метода.

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

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

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

С уважением, Ligth

nick

Тут, как мне кажется, все зависит от определений понятий.

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

Тоесть, как мне кажется, "сущностью" связи между методами будет сумма текущего состояния данных в процессоре, инструкций, опять же загруженных в процессор, и архитектуры процессора. А "представлением" связи будет переход потока исполнения после соответствующего "решения" процесора.

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

Можно еще рассмотреть модель классов, где функции объединены в сущности более высокого уровня - классы. Здесь суть исполнения кода останется такой-же, но на уровне логики, которая в конце концов будет преобразована в те же инструкции процессора, добавятся процессы инициализации типов классов и их экземпляров перед вызовом собственно методов. Тоесть в некоторых случаях добавятся вызовы как бы скрытых методов инициализации высокоуровневой сущности, после которых будут вызваны собственно те методы, которые вызывались. Хотя для процессора никаких скрытых методов не будет, они будут скрытыми с точки зрения программиста.

Ligth

если смотреть с точки зрения кода, если программа записана на одном листе, то действительно, местом взаимодействия будут точки вызова функции/возврата из функций. В таком коде каждая строчка будет некоторой функцией, командой. Такой код есть машинный код. Или я не понимаю чего-то.

Masja

Nick, мне понравилась твоя фраза:

"сущностью" связи между методами будет сумма текущего состояния данных в процессоре, инструкций, опять же загруженных в процессор, и архитектуры процессора.

В магии это называется степень экзальтации, а в электричестве - проводимостью

nick

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

железо с определеной архитектурой