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

Лайт, предлагает интересную аналогию объектоного программирования, как проекции нашего восприятия мира, и асемблера - как прямого видения.

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

Текст программы, как реальный мир. Сюжеты игрыи ее прохождение - как проявленный мир в нашем исполнении. А чем тогда будут различные связи, методы и т.д.? Давайте подключайтесь. Если вы поддержите этот проект, я дам вам ключ к созданию программы для предсказаний вашей судьбы. Прикиньте, компьютерная программа, которая будет относительно точно предсказывать конкретные будущие события вашей жизни, планеты, мира, хе-хе-хе! Винчи - это гений!

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

Ligth

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

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

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

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

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

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

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

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

nick

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

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

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

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

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

Ligth

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

Masja

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

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

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

nick

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

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

базовая низкоуровневая программа, управляющая железом (BIOS), которую, кстати, можно переписать программно

базовое "низкоуровневое программное поле" (операционная система, сторонние программы, интегрированные в операционную систему на низком уровне), в котором выполняются другие программы, и к которому выполняющаяся программа имеет лимитированный доступ

собственно код отдельной программы со своей логикой

электрический ток!

пользователь, как некий начальный импульс к запуску всего процесса и к запуску отдельный программ (могут быть разные пользователи)

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