Очередной новый язык хD
От: Aberro  
Дата: 13.07.10 14:07
Оценка: :)
В общем, да, у меня давно витает идея о новом языке. И, коль не влом, прошу обсудить, высказать ИМХИ, идеи и прочее.
Концепция языка заключается в том, что программа строится не на функциях, а на объектах, управляющих потоками данных и на самих потоках. Основной фунциональный элемент языка — объект. Объект — это черный ящик, имеющий некоторый набор входных и выходных потоков, состояния и команды. К потокам могут быть соединены другие объекты своими соответсвующими потоками (к выходному — входной, соотв., к входному — выходной). Состояния — это свойства объекта, доступные извне только для чтения и изменяемые только командами самого объекта, след. только самим объектом. Команды подобны методам, но с некоторыми ограничениями, которые я опишу чуть позже.
Все остальное закрыто для доступа извне, что обеспечивает хорошую модульность программ на этом языке.
Объекты имеют внутри себя такие же закрытые объекты — они образуют цепочку, связанную потоками, которая проходит от входных потоков объекта-контейнера, до его выходных потоков. Данные меняются проходя по этой цепочке.
Объекты могут наследоваться. В этом случае, потомок может дополнять родителя: добавлять новые потоки, новые состояния и новые команды; а так же модифицировать работу родителя, изменяя связи между внутренними объектами, переписывая команды родительского объекта и изменяя состояния родительского объекта в своих командах.
(над этим ограничением я все еще думаю, оправдано оно или нет Объекты не могут передаваться вместе с данными, на них нельзя получить ссылки и, разумеется, нельзя получить объект по ссылке (на самом деле и то, и другое возможно — для совместимости с существующим ПО, но со значительными ограничениями). Потому, что объекты — это не данные, это функциональные элементы. А в этом языке используется особый подход к данным. Если так уж нужно сконструировать объект из данных, то можно описать структуру данных, описывающую требуемый объект, и добавить в объект-контейнер возможность добавления внутрь себя объектов, собранных по этой структуре.
Да, кстати, объекты могут меняться практически полностью во время выполнения. Они могут создавать внутренние объекты, создавать новые связи потоков, удалять связи и объекты. К тому же количество потоков обоих направлений у объектов не ограничено — существуют неименованные потоки, в которые тоже можно пересылать данные. Главное, чтобы объект имел возможность прочесть эти данные из неименованных потоков.
Можно сказать, что объекты — это нечто среднее между функциями императивных и функциональных языков программирования одновременно. Входные потоки — это параметры, выходные потоки — это результаты выполнения, а внутренние объекты — это вызовы других функций. Однако, это утверждение не совсем верно. Объекты этого языка отличаются от функций тем, что они умны. Они подобны агентам в агентном программировании, только деятельность этих агентов направлена на оптимизацию вычислений в процессе выполнений и алгоритм строится автоматически. Объекты, при изменении связей в процессе выполнения, "прощупывают" потоки и определяют, в каких из потоков данные уходят в никуда и ни на что не влияют. Такие потоки "обрубаются" вплоть до того места, где эти данные могут повлиять на ход выполнения программы. Это возможно, во-первых, потому, что объекты очень закрыты и составить карту взаимосвязей будет не слишком сложно, а во-вторых, накладываемые языком ограничения упрощают формирование внутренних связей в этой карте. Так, данные могут быть либо переданы дальше по цепочке, либо вызвать команду. Команда (т.к. она ограничена в своих возможностях) может либо изменить состояние объекта или связи потоков между объектами, либо послать данные на вход одному из внутренних объектов, либо послать данные на выходной поток описывающего ее объекта, либо ничего не делать. Если команда меняет состояние, значит ее обрезать нельзя. Если посылает данные, то можно проверить куда и к чему это приводит. Опять же, если где-то что-то меняется — значит нужная вещь, обрезать нельзя, а если уходит в никуда — можно резать.
Дело в том, что у каждого объекта помимо описанных им самим потоков есть неявно добавляемые потоки: для отладки, сервисных сообщений и много других. Не все из них нужны в процессе работы. К примеру, в релизе не нужны отладочные данные и весь процесс их вычисления. Так вот, оптимизатор автоматом отключит не только сами отладочные потоки, но и все, что с ними связано и что больше нигде не используется. Таким образом, если где-то для отладки будет генерироваться строка, то она будет генерироваться ТОЛЬКО во время отладки.
Здесь раскрывается интересная языковая фишка — программа может менять свой функционал в зависимости от окружения. Если окружению не требуется некая фишка, которой обладает программа, то на нее и не будет тратиться производительность.
Еще одна фишка языка — поточность и потокобезопасность. Потокобезобасность осуществляется за счет закрытости объектов. Изменить состояние объекта может только сам объект — это во-первых. Команды, посылаемые извне, выполняются объектом только когда объект не обрабатывает никаких данных (если объект обрабатывает к.л. данные, то команда будет помещена в стэк и выполнена только когда объект завершит либо прервет обработку данных) — это во-вторых. Впрочем, на самом деле, потокобезопасность и вообще вся работа с потоками здесь осуществляется не программистом, а самой программой.
Следующая фишка — необычайные возможности самомодификации программ. Как я писал выше, объекты могут создавать внутренние объекты, удалять их, создавать и удалять связи потоков между ними... А теперь вспомним, что я говорил про эти объеткы? Что они на практике подобны функциям в других языках. Т.е. имеем функцию, которая может в ходе своего выполнения либо по команде извне перестроиться и тем самым повлиять на ход своей работы в течение этого и последующих вызовов. При этом, все ненужные связи, которые выбрасывают данные "в никуда", автоматически пропускаются в процессе работы, так что программа не будет вычислять все, чтобы передать только то, что нужно. Она сразу вычисляет только то, что нужно.
Еще фишка в том, что отладочная информация может быть представлена для конкретного объекта в виде последовательности посылок данных и вызываемых команд. И ее можно перестроить в.. ролик. Каждый кадр — это один шаг по цепочке пересылок данных. Ролик, который программист сможет просмотреть, чтобы понять, в какой момент какой объект выдал не то, что должен был, заглянуть "внутрь" этого объекта и посмотреть его ролик, чтобы найти, что не так в нем и так далее до источника ошибки.
Наконец, сама особенность языка по сути порождает, не побоюсь этого сказать, новую парадигму. Программа — это уже не последовательность действий, а объект со входными и выходными потоками. Это, конечно, будет софистикой, но я скажу: в классических языках цель программы — поскорее дойти до точки выхода. Она всегда стремится выйти, только дурацкий алгоритм обычно постоянно возвращает ее на прежнюю точку, по кругу. А цель программы на этом языке — обработать данные, программа стремится не выйти, а выдать результирующие данные, чтобы затем ждать новой порции данных. Нет, конечно же в этих программах тоже будет точка выхода, они не будут висеть в памяти. Да и в исключительных ситуациях (кстати, исключения здесь тоже передаются через потоки в виде данных; можно подключиться к этим потокам, чтобы ловить исключения и обрабатывать их) программа не просто повиснет в памяти, а хотя бы покончит с собой в печали великой, чтоб другим не мешать. По этой новой парадигме программы описываются не с точки зрения алгоритма, а с точки зрения обработки данных — что имеем на входе и что должны получить на выходе. Команды и состояния здесь — надстройка, все то, что по самой своей сути не является данными и должно быть отделено от них. Именно это отделение позволит значительно уменьшить количество ошибок (и добавить совсем новые, другого рода и природы, чтобы жизнь не была скучна)). Цель такого подхода — создание идеальных программ: с понятным кодом и организацией (ведь здесь недопустимы сложные и глубокие взаимосвязи между объектами, т.к. объекты закрыты), автоматически оптимизируемые, быстрые, надежные, легко отлаживаемые, гибкие и масштабируемые, _______________ (вписать нужное).
Собственно, будущее программирование за этим языком, я гарантирую! Дело за малым: реализовать его...
Но не все так печально — у меня есть некоторые наброски, синтаксис, идеи по реализации и в данный момент я пытаюсь наскоблить время на создание модели языка в каком-нибудь другом языке, для проверки самой парадигмы. Но времени явно не хватает.
А пока жду ваших лучей ненависти) И в тайне надеюсь на то, что кто-то выскажет конструктивные мысли и кого я смогу посвятить в детали реализации.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.