следующая тема »

Сайт Равенны

• Сайт Равенны
• Лаборатория ХС
• Архив Новайсе
• Архив Школы Волшебства
• Техномагия ХС
• Масины теоремы
• журнал Остров Сновидений

[Использование материалов данного форума (тем паче в коммерческих изданиях) без разрешения администрации этого ресурса будет являться нарушением авторских прав и подлежит уголовному наказанию согласно российскому законодательству.Для тех, кто не преследует таких подленьких целей: цитируйте на здоровье, но только на отдельной странице и указывайте при этом ссылку на этот сайт. Не надо вырывать из контекста фразы и сопровождать их своими некомпетентными суждениями. Оформляйте их отдельно, а лучше попытайтесь достигнуть чего-то подобного на личном опыте.Вниманию хитрожопиков, клонов и псеводохакеров, ваша песенка спета!]

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

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

Вниманию хитрожопиков, клонов и псеводохакеров, ваша песенка спета!

Намерение дня еще копится и формируется ...

[Masja]

Наверное, кто-то из вас знает Винчи. Я уговорила его написать книгу о магии Земли. Недавно он дал мне почитать первую главу, и у нас возник спор. В процессе дискуссии я поняла, насколько далека от мира программистов, и насколько их мир интересен.

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

Итак, начальные условия. Прикиньте, что текст программы - это мир, созданные из отдельных частей (шаров восприятия), они связаны транзитами, у которых будут точки входа и  источники ссылок.

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

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

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

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

[Masja]

Ligth

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

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

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

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

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

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

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

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


nick

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

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

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

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

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

Ligth

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

[Masja]

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

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

[nick]

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

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

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

Можно обратить внимание, кстати, на несколько интересных моментов:

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

Masja, если я тебя правильно понял, в жизненном цикле классов, по крайней мере в случае языка Java, есть сходное понятие. В случае Java класс как сущность состоит на самом деле из трех сущностей:

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

В этом случае, как мне кажется, "класс" соответствует этой самой степени экзальтации. Хотя может быть этому понятию соответствует не сам класс, а состояние класса, и состояние экземпляров класса.

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

Если подключить концепцию многопоточности - то под потоком модно представить отдельного человека. Что здесь интересно, что поток - понятие виртуальное. На самом деле физических потоков - столько сколько процессоров (не больше). А "логические" потоки формирует операционная система, выполняя их инструкции последовательно на одном процессоре. Есть над чем подумать

[red_warg]

Никого не хочу огорчать, но почему за основу взята фон Неймовская архитектура?
(т.к. знаю что есть и другие, но фоннеймовский вариант был более прост для того чтобы сделать ЭВМ в середине 20 века, сейчас же наблюдается тенденция к уходу от классичекой схемы)
Я согласен что теперешний комп может в некотором роде может отражать строения вселенной, но не буквально же.

[nick]

И вот еще интересный момент. Чтобы программа не была "вещью в себе", операционная система предоставляет ей API - интерфейс доступа к ресурсам операционной системы (набор специальных методов и/или классов). В то же время самой операционной системе и программам, запущенным в ней, доступны методы работы с "железом" - специальные регистры процессора, прерывания устройств и т.д. Причем операционная система имеет доступ к большему количеству таких методов (здесь я не совсем уверен, так что будет хорошо если кто-нибудь меня поправит).

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

red_warg, а почему, кстати, не буквально?

[red_warg]

Потому что, мир работает по-другому.

[nick]

А в чем принципиальная разница? Мне сравнение с компьютерной программой кажется вполне логичным.

[lfxor]

Некоторые особенности исполнения программ.
Рассмотрим программу, вычисляющую S из входных переменных a, b, e и f:
01  c = a+b
02  d = a-b
03  R = c*d
04  a = R*e
05  b = R*f
06 S = R+a+b
Программа простая. Ее особенность в том, что команды 01 и 02 могут исполняться в любом порядке или одновременно. На современных процессорах это так и произойдет - порядок исполнения будет определяться готовностью вычислительных устройств, а при надлежащем их количестве команды будут выполнены одновременно. Это же касается и команд 04 и 05. А команды 03 и 06 - "узловые" в том смысле, что исполняться одновременно с ними не может ни одна другая.
Мы привыкли думать о программах как о последовательных, но на деле нарушается либо порядок исполнения команд, либо некоторые исполняются параллельно. Это осуществляется таким образом, чтобы результат получался одним и тем же, т.е. с точки зрения программы система ведет себя так, будто команды исполняются последовательно.
Более общий вид программы следующий: есть набор т.н. А-блоков, которые представляют собой операцию (ассемблерную команду). С каждым А-блоком могут быть связаны входные переменные и выходные. Операция вычисляет выходные из входных. А-блоки могут срабатывать не в произвольном порядке, а только тогда, когда готовы все входные переменные. Срабатывание А-блоков может происходить одновременно.
Множество готовых к исполнению А-блоков по мере исполнения то увеличивается, то уменьшается. В "узловой" точке, например, будет только один А-блок.

Теперь вернемся к обычному представлению.
Вернемся во времена DOS'а. Программа могла состоять из ассемблерных команд и вызовов к операционной системе. Если программа получала управление, то могла сделать все что угодно. Операционная система служила для обеспечения различных сервисов - работа с файлами, строками и т.п. Все это можно сделать и напрямую с помощью ассемблерных команд.
Теперь все чуть чуть иначе - есть защищенный режим работы процессора и программа, получив управление, работает уже не напрямую, а "в песочнице" - может обращаться только с определенными адресами в памяти, не может напрямую обращаться к диску и т.п. - теперь она может только отправлять запросы операционке, которая делает это за него, а заодно и проверяет, дозволено ли ему это делать. В "прямом" владении остаются только безобидные процессорные команды вроде арифметических операций.
Вторая степень защиты - в ООП: методы не могут быть вызваны, если они protected или private. То же касается и атрибутов объекта. Некоторые системные функции окружения сами вызывают определенные методы объектов, например по таймеру. Можно сказать, что вызовом методов управляет система, и управление среди методов может передаваться в рамках дозволенных вызовов.
Интересный момент - эти рамки определяет компилятор! То есть, в конечном счете код преобразовывается в обычные ассемблерные команды и вызовы ОС. Если в этот момент код подменить, то можно безо всяких ограничений вызывать защищенные методы и использовать чужие закрытые переменные.

[nick]

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

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

[Ligth]

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

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

Значит можно, задав нужный массив параметров и начальных значений себя и системы, получить нужное состояние системы в целом, и/или её частей(нас самих в том числе).

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

[red_warg]

Иногда сам удивляюсь как тормозить умею, после разговора с nick вдруг почуствовал, что-то знакомое в этой тематике и наконец вспомнил, как оказалось за день до этого на одном из форумов возникла тема оч. сильно перекликающаяся с этой, где вместо нормального разговора по теме ,люди полезли в другую степь, что мне и непонравилось там. Пишу в оффлайне и без книг, так что необезсудьте.

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

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

По-делу, мну считает, что при работе с реальностью, программой нужно считать сами данные и их структуру, причем сама такая "программа" является и оперативкой, и процессором, т.е. представляет собой отдельный вычислительный комплекс. Как так получается? да не знаю я, пока. Если посмотреть, то к такой программе вполне можно применить и функциональное и объектно-ориентированное программирование и много еще других вкусностей.

Вот вчера озадачил nick меня многопроцессорностью, типа вселенского суперкомпьтера. Дело в том, что, например, если двум процессорам одновременно нужно записать информацию в одну и туже ячейку памяти, то возникает вопрос: кто прав? А вот если инфа сама является и хранителем информации и процессором такой вопрос просто не возникнет (я понимаю, что представить такое сложно, но тут ничего не поделаешь).

Насчет языков высокого уровня (ЯВУ) и языков низкого уровня (ЯНУ). Вспомним ПМ (никто не будет спорить что это ЯВУ), пасьянс работает независимо от тайнига, толи 10 мин(ЯНУ), толи 1 день(ЯВУ), хотя тут могут возникнут споры у меня самого здесь есть вопросы. Конечно существуют законы Орла и можно сказать что они написаны на ЯНУ, то тут скорее строение архитектуры.

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

[Ligth]

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

[nick]

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

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

Я вот о чем задумался - какое место в такой структуре занимает деятельная часть человека? Ведь программа жестко следует своей логике, у нее нет осознания, а человек может сам принимать решения и действовать. Или не может? Не могу ответить однозначно...

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

[Masja]

Парни, это все гуд. Но прикиньте, что программист, написавший программу игры чисто для прикола пожелал пообщаться с геймерами. Допустим, в игре "Сакред" среди предметов магии можно было обнаружить разбитый "плэйстешн-6" или письма программеров. И еще прикиньте, что программистам, писавшим проги для нашей реальности, тоже могла прийти в бошку такая же идея.

Давайте я уж расскажу о своем споре с Винчи. Он пишет книгу о магии Земли. И он назвал ее "Геомантией Винчи". Я дала ему по чайнику и говорю, мол мантика - это по греческий "прорицание". Зачем ограничивать магию земли этим термином? Слово за слово. И он рассказал мне о древнем искусстве прорицания будущих событий с помощью птиц - обычно петушков. Маги рисовали на земле круг, по периметру расставлялись буквы, на каждую букву ложилось зернышно. Затем выпускали петушка и записывали буквы, с которых он склевывал зерна.

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

И теперь вопрос: а можно ли написать программу, которая фиксировала бы некие элементы обращений процессора к обычным программам компьютера, затем наделяла эти обращения буквенной кодировкой и затем выдавала на экран текст сообщения?