В общем, да, у меня давно витает идея о новом языке. И, коль не влом, прошу обсудить, высказать ИМХИ, идеи и прочее.
Концепция языка заключается в том, что программа строится не на функциях, а на объектах, управляющих потоками данных и на самих потоках. Основной фунциональный элемент языка — объект. Объект — это черный ящик, имеющий некоторый набор входных и выходных потоков, состояния и команды. К потокам могут быть соединены другие объекты своими соответсвующими потоками (к выходному — входной, соотв., к входному — выходной). Состояния — это свойства объекта, доступные извне только для чтения и изменяемые только командами самого объекта, след. только самим объектом. Команды подобны методам, но с некоторыми ограничениями, которые я опишу чуть позже.
Все остальное закрыто для доступа извне, что обеспечивает хорошую модульность программ на этом языке.
Объекты имеют внутри себя такие же закрытые объекты — они образуют цепочку, связанную потоками, которая проходит от входных потоков объекта-контейнера, до его выходных потоков. Данные меняются проходя по этой цепочке.
Объекты могут наследоваться. В этом случае, потомок может дополнять родителя: добавлять новые потоки, новые состояния и новые команды; а так же модифицировать работу родителя, изменяя связи между внутренними объектами, переписывая команды родительского объекта и изменяя состояния родительского объекта в своих командах.
(над этим ограничением я все еще думаю, оправдано оно или нет Объекты не могут передаваться вместе с данными, на них нельзя получить ссылки и, разумеется, нельзя получить объект по ссылке (на самом деле и то, и другое возможно — для совместимости с существующим ПО, но со значительными ограничениями). Потому, что объекты — это не данные, это функциональные элементы. А в этом языке используется особый подход к данным. Если так уж нужно сконструировать объект из данных, то можно описать структуру данных, описывающую требуемый объект, и добавить в объект-контейнер возможность добавления внутрь себя объектов, собранных по этой структуре.
Да, кстати, объекты могут меняться практически полностью во время выполнения. Они могут создавать внутренние объекты, создавать новые связи потоков, удалять связи и объекты. К тому же количество потоков обоих направлений у объектов не ограничено — существуют неименованные потоки, в которые тоже можно пересылать данные. Главное, чтобы объект имел возможность прочесть эти данные из неименованных потоков.
Можно сказать, что объекты — это нечто среднее между функциями императивных и функциональных языков программирования одновременно. Входные потоки — это параметры, выходные потоки — это результаты выполнения, а внутренние объекты — это вызовы других функций. Однако, это утверждение не совсем верно. Объекты этого языка отличаются от функций тем, что они умны. Они подобны агентам в агентном программировании, только деятельность этих агентов направлена на оптимизацию вычислений в процессе выполнений и алгоритм строится автоматически. Объекты, при изменении связей в процессе выполнения, "прощупывают" потоки и определяют, в каких из потоков данные уходят в никуда и ни на что не влияют. Такие потоки "обрубаются" вплоть до того места, где эти данные могут повлиять на ход выполнения программы. Это возможно, во-первых, потому, что объекты очень закрыты и составить карту взаимосвязей будет не слишком сложно, а во-вторых, накладываемые языком ограничения упрощают формирование внутренних связей в этой карте. Так, данные могут быть либо переданы дальше по цепочке, либо вызвать команду. Команда (т.к. она ограничена в своих возможностях) может либо изменить состояние объекта или связи потоков между объектами, либо послать данные на вход одному из внутренних объектов, либо послать данные на выходной поток описывающего ее объекта, либо ничего не делать. Если команда меняет состояние, значит ее обрезать нельзя. Если посылает данные, то можно проверить куда и к чему это приводит. Опять же, если где-то что-то меняется — значит нужная вещь, обрезать нельзя, а если уходит в никуда — можно резать.
Дело в том, что у каждого объекта помимо описанных им самим потоков есть неявно добавляемые потоки: для отладки, сервисных сообщений и много других. Не все из них нужны в процессе работы. К примеру, в релизе не нужны отладочные данные и весь процесс их вычисления. Так вот, оптимизатор автоматом отключит не только сами отладочные потоки, но и все, что с ними связано и что больше нигде не используется. Таким образом, если где-то для отладки будет генерироваться строка, то она будет генерироваться ТОЛЬКО во время отладки.
Здесь раскрывается интересная языковая фишка — программа может менять свой функционал в зависимости от окружения. Если окружению не требуется некая фишка, которой обладает программа, то на нее и не будет тратиться производительность.
Еще одна фишка языка — поточность и потокобезопасность. Потокобезобасность осуществляется за счет закрытости объектов. Изменить состояние объекта может только сам объект — это во-первых. Команды, посылаемые извне, выполняются объектом только когда объект не обрабатывает никаких данных (если объект обрабатывает к.л. данные, то команда будет помещена в стэк и выполнена только когда объект завершит либо прервет обработку данных) — это во-вторых. Впрочем, на самом деле, потокобезопасность и вообще вся работа с потоками здесь осуществляется не программистом, а самой программой.
Следующая фишка — необычайные возможности самомодификации программ. Как я писал выше, объекты могут создавать внутренние объекты, удалять их, создавать и удалять связи потоков между ними... А теперь вспомним, что я говорил про эти объеткы? Что они на практике подобны функциям в других языках. Т.е. имеем функцию, которая может в ходе своего выполнения либо по команде извне перестроиться и тем самым повлиять на ход своей работы в течение этого и последующих вызовов. При этом, все ненужные связи, которые выбрасывают данные "в никуда", автоматически пропускаются в процессе работы, так что программа не будет вычислять все, чтобы передать только то, что нужно. Она сразу вычисляет только то, что нужно.
Еще фишка в том, что отладочная информация может быть представлена для конкретного объекта в виде последовательности посылок данных и вызываемых команд. И ее можно перестроить в.. ролик. Каждый кадр — это один шаг по цепочке пересылок данных. Ролик, который программист сможет просмотреть, чтобы понять, в какой момент какой объект выдал не то, что должен был, заглянуть "внутрь" этого объекта и посмотреть его ролик, чтобы найти, что не так в нем и так далее до источника ошибки.
Наконец, сама особенность языка по сути порождает, не побоюсь этого сказать, новую парадигму. Программа — это уже не последовательность действий, а объект со входными и выходными потоками. Это, конечно, будет софистикой, но я скажу: в классических языках цель программы — поскорее дойти до точки выхода. Она всегда стремится выйти, только дурацкий алгоритм обычно постоянно возвращает ее на прежнюю точку, по кругу. А цель программы на этом языке — обработать данные, программа стремится не выйти, а выдать результирующие данные, чтобы затем ждать новой порции данных. Нет, конечно же в этих программах тоже будет точка выхода, они не будут висеть в памяти. Да и в исключительных ситуациях (кстати, исключения здесь тоже передаются через потоки в виде данных; можно подключиться к этим потокам, чтобы ловить исключения и обрабатывать их) программа не просто повиснет в памяти, а хотя бы покончит с собой в печали великой, чтоб другим не мешать. По этой новой парадигме программы описываются не с точки зрения алгоритма, а с точки зрения обработки данных — что имеем на входе и что должны получить на выходе. Команды и состояния здесь — надстройка, все то, что по самой своей сути не является данными и должно быть отделено от них. Именно это отделение позволит значительно уменьшить количество ошибок (и добавить совсем новые, другого рода и природы, чтобы жизнь не была скучна)). Цель такого подхода — создание идеальных программ: с понятным кодом и организацией (ведь здесь недопустимы сложные и глубокие взаимосвязи между объектами, т.к. объекты закрыты), автоматически оптимизируемые, быстрые, надежные, легко отлаживаемые, гибкие и масштабируемые, _______________ (вписать нужное).
Собственно, будущее программирование за этим языком, я гарантирую! Дело за малым: реализовать его...
Но не все так печально — у меня есть некоторые наброски, синтаксис, идеи по реализации и в данный момент я пытаюсь наскоблить время на создание модели языка в каком-нибудь другом языке, для проверки самой парадигмы. Но времени явно не хватает.
А пока жду ваших лучей ненависти) И в тайне надеюсь на то, что кто-то выскажет конструктивные мысли и кого я смогу посвятить в детали реализации.
Здравствуйте, Aberro, Вы писали:
A> В общем, да, у меня давно витает идея о новом языке. И, коль не влом, прошу обсудить, высказать ИМХИ, идеи и прочее. A>Концепция языка заключается в том, что программа строится не на функциях, а на объектах, управляющих потоками данных и на самих потоках. Основной фунциональный элемент языка — объект. Объект — это черный ящик, имеющий некоторый набор входных и выходных потоков, состояния и команды. К потокам могут быть соединены другие объекты своими соответсвующими потоками (к выходному — входной, соотв., к входному — выходной).
// описываем класс WordSplitter.class WordSplitter
// У него один входной поток, принимающий данные типа String, и один выходной поток, отправляющий данные типа String[]
String str -> String[] words
{
// никаких состояний или команд этот объект не имеет, так что сразу описываем основную функцию. Основная функция описывает связи между объектами.
{
// здесь создается четыре объекта и сразу же устанавливаются связи между ними. Создание нового объекта обозначается круглыми скобками,
// в этих же круглых скобках указывается то, что будет подано на вход созданному объекту.
// перед первыми скобками не написано ничего, значит, создаем анонима. Аноним не имеет типа и названия, а его основная функция описывается
// прямо в тексте, его входные и выходные потоки определяются по описанию.
// Этот аноним принимает один входной поток - из объекта типа if, названного isspace. Это то, что перед вторыми круглыми скобками.
// Когда указывается два идентефикатора, первый определяет тип, второй - имя.
// Третий объект - iter с именем ch. Он, получив на вход всего один объект данных типа массив, выдает на выходе этот массив в виде
// раздельных выходных сигналов. Иначе говоря, он посылает столько выходных сигналов, сколько объектов в массиве, поданном на вход.
// У него один явный выходной поток, который выдает собственно элементы массива. И у него есть неявный выходной поток: end, на который
// подается весь массив по окончании итерации.
// Еще, здесь создается объект типа ==, по сути - оператор сравнения.
// Оператору сравнения имеет два входа. Даем на первый то, что выдает итератор, на второй - константу.
// Итератору даем на вход то, что подается на вход самому объекту, т.е. поток с именем str.
// if имеет два входных потока - первый инициирующий, второй - поток булевых значений. Инициирующий поток нужен для связи объекта типа if
// со всей схемой. if подаст на выход какое-либо значение только когда на вход инициирующего потока и на поток булевых значений получит
// какие-либо данные. У него есть три выходных потока: true, false и output. На тру подается то, что было передано в инициирующий поток
// если на потоке булевых значений была истина, аналогично с фалсом. На оутпут подается вывод в любом случае.
// Вывод из потока true объекта типа if мы направляем в анонима и описываем в его основной функции вызов команды для объекта characc.
// Эта строка означает примерно следующее: начинаем перебирать все символы строки и сравнивать их с пробелом. Если пробел - даем команду
// объекту characc на вывод накопленных в нем символов.
(if isspace(iter ch(:str):, ==(ch:,' ')):true) { characc.push; };
// Вот здесь этот объект и создается. Аккумулятор - это объект, который собирает в себе поступившие ему на вход данные и не отправляет их
// до тех пор, пока не получит команду push. На выходе у него, разумеется, массив. Привязываем ко входу этого объекта вывод из
// вышеописанного объекта if, причем, вывод с потока false.
// Выражаясь более типичными языками, если символ не пробел, добавляем его в массив.
accumulator characc(isspace:false);
// Здесь все довольно просто: создаем анонима, который по окончании работы итератора даст команду аккумулятору wordacc на выдачу накопленных
// в нем значений.
(ch:end) { wordacc.push; };
// Здесь создаем связь выходного потока нашего объекта с аккумулятором wordacc, который собирает данные с потока true объекта if,
// который инициирующим потоком привязан к аккумулятору символов characc, а потоком условий привязан к объекту-оператору
// >, сравнивающему неявный поток аккумулятора characc с нулем.
:words = accumulator wordacc(if(characc:, >(characc:length,0)):true);
// Теперь подытожим. Итератор перечисляет все символы и подает их в условие и в оператор сравнения. Оператор сравнения посылает
// результаты сравнения в условие же. Условие по каналу false (символ не пробел) посылает символы на аккумулятор, а по каналу
// true посылает полученные им символы на аноним, который игнорит эти символы (нам же не нужны пробелы!) и дает команду аккумулятору
// сбросить накопленное. Накопленное сбрасывается в следующее условие, в котором проверяется количество накопленных символов;
// если оно не нулевое, то эти символы передаются в другой аккумулятор, который сбрасывает свою инфу тогда, когда итератор закончит
// перечисление. И сбрасывает он инфу в выходной поток нашего объекта
}
}
// эти скобки означают описание основного блока программы.
{
// создаем объект консоли, допустим, этот объект входит в стандартную библиотеку.
console con;
// подаем на входной канал write этого объекта константу. Константа срабатывает только один раз, поэтому вывод будет тоже только один.
con:write = "Enter string (or press ESC to exit):";
// в условии проверяем выходной поток консоли inputch. Допустим, по этому потоку подаются все символы на клавиатуре, которые
// нажал пользователь. Если этот символ равен элементу ESC перечисления chars, то подаем команду программе завершиться.
(if(con:inputch, ==(con:inputch,chars:ESC)):true) { .exit(0); };
// Подаем на вход объекту консоли то, что выдаст наш объект. Нашему объекту подаем на вход то, что выдаст консоль.
con:write = WordSplitter(con:read);
}
A> Собственно, будущее программирование за этим языком, я гарантирую! Дело за малым: реализовать его...
Это точно.
A> Но не все так печально — у меня есть некоторые наброски, синтаксис, идеи по реализации и в данный момент я пытаюсь наскоблить время на создание модели языка в каком-нибудь другом языке, для проверки самой парадигмы. Но времени явно не хватает. A> А пока жду ваших лучей ненависти) И в тайне надеюсь на то, что кто-то выскажет конструктивные мысли и кого я смогу посвятить в детали реализации.
Про потоки интересно, у меня тоже похожие мысли.
Про повёрнутость на слове "объект" — Smalltalk, Ruby.
Про идею в целом — переусложнённое описание Erlang. Писали на нём?
Здравствуйте, Temoto, Вы писали:
T>Про потоки интересно, у меня тоже похожие мысли.
Высказывайте, если не секрет фирмы) T>Про повёрнутость на слове "объект" — Smalltalk, Ruby.
Нет, увы мне, быдлу необразованному. Но немного знаком с ними. И таки нет, это не то, ни разу. Повторюсь, объекты здесь — это функциональные элементы, в которых из данных только состояния. А объекты данных в этом языке — структуры. Они тоже могут иметь методы, но область действия методов ограничена структурой. Методы могут менять свои структуры, создавать новые данные, принимать данные через параметры, но не могут вызывать методы других данных, т.к. это нарушило бы потокобезопасность (ведь структура, чей метод пытается вызвать другая структура, может обрабатываться в этот момент в другом потоке) и привело бы к слишком сложным связям. T>Про идею в целом — переусложнённое описание Erlang. Писали на нём?
На нем тоже нет. Вообще, можете закидать меня тухлыми помидорами, ибо я очередной амбициозный новичок, с опытом программирования менее пяти лет (ну, ладно, чуть-чуть более пяти; но если вычесть времена, когда я страдал фигней и ничего не писал, то точно выйдет менее пяти, честно-честно). Однако, насколько я могу судить по описанию языка, опять не то. Легкие процессы — это, конечно, хорошо, но... Здесь программист вообще не работает с потоками, вся эта грязная и неблагодарная работа оставлена на саму программу (в частности, менеджер объектов — ту функцию, которая делает объект умным) и компилятор. Когда объект посылает данные на два выходных потока, к каждому из которых привязаны "тяжелые" в плане вычислений объекты (а степень их тяжести можно определить по все той же карте взаимосвязей), вычисления разделяются на два потока. Если оба этих тяжелых объекта посылают данные в какой-то один объект — опять же, это все остается на фоне, данные будут помещены в стэк.
На низком уровне это будет выглядеть таким образом, что приложение будет создавать не множество мелких отдельных друг от друга потоков, а несколько, скорее всего по количеству процессоров, потоков между которыми будут распределяться отдельные задачи; что-то вроде дотнэтовских тасков.
Здравствуйте, Aberro, Вы писали:
A>На нем тоже нет. Вообще, можете закидать меня тухлыми помидорами, ибо я очередной амбициозный новичок, с опытом программирования менее пяти лет (ну, ладно, чуть-чуть более пяти; но если вычесть времена, когда я страдал фигней и ничего не писал, то точно выйдет менее пяти, честно-честно). Однако, насколько я могу судить по описанию языка, опять не то.
A>На низком уровне это будет выглядеть таким образом, что приложение будет создавать не множество мелких отдельных друг от друга потоков, а несколько, скорее всего по количеству процессоров, потоков между которыми будут распределяться отдельные задачи; что-то вроде дотнэтовских тасков.
Ах да, забыл уточнить, что благодаря поточной обработке данных здесь решаются многие проблемы параллельных вычислений. Если данные разделяются на две ветви, и в обеих они могут быть изменены, то лучше их дублировать. И это не есть плохо, потому как в конечном счете эти данные не коп(т)ятся в памяти, а стремятся выйти из приложения, так что они не будут слишком долго захламлять память. Если данные в обеих ветках точно не могут быть изменены (что снова решается картой взаимосвязей и менеджером объекта), то можно и не дублировать их.
По поводу карты — может показаться, что работа с ней уничтожит на корню все преимущества описанной мной оптимизации, но на деле полная карта совсем ни к чему: главное иметь карту тех участков программы, которые могут измениться в ходе работы. Остальная часть карты строится на этапе компиляции и применяется там, где нужно.
Последний абзац. Дальше по ветке ещё пример кода есть.
T>>Про идею в целом — переусложнённое описание Erlang. Писали на нём? A>На нем тоже нет. Вообще, можете закидать меня тухлыми помидорами, ибо я очередной амбициозный новичок, с опытом программирования менее пяти лет (ну, ладно, чуть-чуть более пяти; но если вычесть времена, когда я страдал фигней и ничего не писал, то точно выйдет менее пяти, честно-честно). Однако, насколько я могу судить по описанию языка, опять не то. Легкие процессы — это, конечно, хорошо, но... Здесь программист вообще не работает с потоками, вся эта грязная и неблагодарная работа оставлена на саму программу (в частности, менеджер объектов — ту функцию, которая делает объект умным) и компилятор. Когда объект посылает данные на два выходных потока, к каждому из которых привязаны "тяжелые" в плане вычислений объекты (а степень их тяжести можно определить по все той же карте взаимосвязей), вычисления разделяются на два потока. Если оба этих тяжелых объекта посылают данные в какой-то один объект — опять же, это все остается на фоне, данные будут помещены в стэк. A>На низком уровне это будет выглядеть таким образом, что приложение будет создавать не множество мелких отдельных друг от друга потоков, а несколько, скорее всего по количеству процессоров, потоков между которыми будут распределяться отдельные задачи; что-то вроде дотнэтовских тасков.
Ну "не писал, но не то", это несерьёзный разговор. Попробуйте, он учится за день.
Ваше описание понимается с трудом (в основном, потому что "объектный объект посылает объект, принимает объект, в поток объекта, объект, объект поток"). Но из того что понятно, Erlang/OTP это именно ваши объекты.
Здравствуйте, Temoto, Вы писали:
T>Ваше описание понимается с трудом (в основном, потому что "объектный объект посылает объект, принимает объект, в поток объекта, объект, объект поток"). Но из того что понятно, Erlang/OTP это именно ваши объекты.
Ну, извольте, все вполне ясно. Объектов там не больше, чем нужно.
Может, стоит уточнить терминологию?
Объект — функциональный элемент, черный ящик, в общем, про него уже достаточно сказано.
Поток в целом — это связь между выходным потоком одного объекта и входным другого.
Выходной поток — поток, принадлежащий какому-либо объекту и посылающий данные.
Входной поток — поток, принимающий данные.
Данные — собственно данные, информация, отдельно от методов ее обработки. Могут быть как простыми (числа, строки, булевы, символы, дата/время), так и составными (структуры).
Передача данных, таким образом, это посылка данных в количестве одна штука из выходного потока одного объекта во входной поток другого объекта.
Обработка данных — это процесс обработки, происходящий внутри одного объекта. Обычно это передача управления одному или нескольким внутренним объектам (в зависимости от того, как организованы связи и сколько потоков создано), но на самом низком уровне это непосредственно выполнение машинных команд. В результате обработки либо вызываются команды этого объекта, либо данные к.л. образом изменяются, либо они дублируются в памяти.
Команды — это... короче, считайте, что это события, только если команда вызвана не тем же объектом, в котором она описана, то обработка будет отложена. Команды меняют состояния объектов, связей между внутренними объектами и генерируют данные.
Здравствуйте, Mystic, Вы писали:
M>Имхо, не хватает выразительности. Читать такой код мне тяжеловато (много знаков препинания) и интуитивно непонятно
А вы читайте комментарии. Хотя самих знаков препинания достаточно, но их разнообразие совсем небольшое. Точка указывает на команду, двоеточие — на поток, круглые скобки создают объект. Фигурные скобки разделяют блоки с описанием.
Да и вообще-то это не алгоритм, это описание. Описание того, какие внутренние объекты создавать и как связать потоки между собой. Здесь любые две строчки можно поменять местами, учитывайте это.
Да и в этом примере я специально завернул одно в другое, чтобы получить минимум кода.
При желании, можно расписать все куда подробнее, но вышло бы раза в три больше кода.
Здравствуйте, Temoto, Вы писали:
T>>>Про потоки интересно, у меня тоже похожие мысли. A>>Высказывайте, если не секрет фирмы)
T>Пожалуй, ссылку приведу, не сочтите за лень. T>http://rsdn.ru/forum/philosophy/3743426.1.aspx
T>Последний абзац. Дальше по ветке ещё пример кода есть.
T>>>Про идею в целом — переусложнённое описание Erlang. Писали на нём? A>>На нем тоже нет. Вообще, можете закидать меня тухлыми помидорами, ибо я очередной амбициозный новичок, с опытом программирования менее пяти лет (ну, ладно, чуть-чуть более пяти; но если вычесть времена, когда я страдал фигней и ничего не писал, то точно выйдет менее пяти, честно-честно). Однако, насколько я могу судить по описанию языка, опять не то. Легкие процессы — это, конечно, хорошо, но... Здесь программист вообще не работает с потоками, вся эта грязная и неблагодарная работа оставлена на саму программу (в частности, менеджер объектов — ту функцию, которая делает объект умным) и компилятор. Когда объект посылает данные на два выходных потока, к каждому из которых привязаны "тяжелые" в плане вычислений объекты (а степень их тяжести можно определить по все той же карте взаимосвязей), вычисления разделяются на два потока. Если оба этих тяжелых объекта посылают данные в какой-то один объект — опять же, это все остается на фоне, данные будут помещены в стэк. A>>На низком уровне это будет выглядеть таким образом, что приложение будет создавать не множество мелких отдельных друг от друга потоков, а несколько, скорее всего по количеству процессоров, потоков между которыми будут распределяться отдельные задачи; что-то вроде дотнэтовских тасков.
T>Ну "не писал, но не то", это несерьёзный разговор. Попробуйте, он учится за день.
T>Ваше описание понимается с трудом (в основном, потому что "объектный объект посылает объект, принимает объект, в поток объекта, объект, объект поток"). Но из того что понятно, Erlang/OTP это именно ваши объекты.
Здравствуйте, batu, Вы писали:
B>А данные, почему-то не объекты.
О, вы меня понимаете)))
ЗЫ бозе мій, ну раз такая рокировка понятий вызывает жеский анальный разрыв шаблонов, то боюсь этот язык будет сложно понять. Но, так и быть, я изменю название понятия "объект" на какое-нибудь другое. Функтор? Вроде по смыслу подходит.
