В общем, да, у меня давно витает идея о новом языке. И, коль не влом, прошу обсудить, высказать ИМХИ, идеи и прочее.
Концепция языка заключается в том, что программа строится не на функциях, а на объектах, управляющих потоками данных и на самих потоках. Основной фунциональный элемент языка — объект. Объект — это черный ящик, имеющий некоторый набор входных и выходных потоков, состояния и команды. К потокам могут быть соединены другие объекты своими соответсвующими потоками (к выходному — входной, соотв., к входному — выходной). Состояния — это свойства объекта, доступные извне только для чтения и изменяемые только командами самого объекта, след. только самим объектом. Команды подобны методам, но с некоторыми ограничениями, которые я опишу чуть позже.
Все остальное закрыто для доступа извне, что обеспечивает хорошую модульность программ на этом языке.
Объекты имеют внутри себя такие же закрытые объекты — они образуют цепочку, связанную потоками, которая проходит от входных потоков объекта-контейнера, до его выходных потоков. Данные меняются проходя по этой цепочке.
Объекты могут наследоваться. В этом случае, потомок может дополнять родителя: добавлять новые потоки, новые состояния и новые команды; а так же модифицировать работу родителя, изменяя связи между внутренними объектами, переписывая команды родительского объекта и изменяя состояния родительского объекта в своих командах.
(над этим ограничением я все еще думаю, оправдано оно или нет Объекты не могут передаваться вместе с данными, на них нельзя получить ссылки и, разумеется, нельзя получить объект по ссылке (на самом деле и то, и другое возможно — для совместимости с существующим ПО, но со значительными ограничениями). Потому, что объекты — это не данные, это функциональные элементы. А в этом языке используется особый подход к данным. Если так уж нужно сконструировать объект из данных, то можно описать структуру данных, описывающую требуемый объект, и добавить в объект-контейнер возможность добавления внутрь себя объектов, собранных по этой структуре.
Да, кстати, объекты могут меняться практически полностью во время выполнения. Они могут создавать внутренние объекты, создавать новые связи потоков, удалять связи и объекты. К тому же количество потоков обоих направлений у объектов не ограничено — существуют неименованные потоки, в которые тоже можно пересылать данные. Главное, чтобы объект имел возможность прочесть эти данные из неименованных потоков.
Можно сказать, что объекты — это нечто среднее между функциями императивных и функциональных языков программирования одновременно. Входные потоки — это параметры, выходные потоки — это результаты выполнения, а внутренние объекты — это вызовы других функций. Однако, это утверждение не совсем верно. Объекты этого языка отличаются от функций тем, что они умны. Они подобны агентам в агентном программировании, только деятельность этих агентов направлена на оптимизацию вычислений в процессе выполнений и алгоритм строится автоматически. Объекты, при изменении связей в процессе выполнения, "прощупывают" потоки и определяют, в каких из потоков данные уходят в никуда и ни на что не влияют. Такие потоки "обрубаются" вплоть до того места, где эти данные могут повлиять на ход выполнения программы. Это возможно, во-первых, потому, что объекты очень закрыты и составить карту взаимосвязей будет не слишком сложно, а во-вторых, накладываемые языком ограничения упрощают формирование внутренних связей в этой карте. Так, данные могут быть либо переданы дальше по цепочке, либо вызвать команду. Команда (т.к. она ограничена в своих возможностях) может либо изменить состояние объекта или связи потоков между объектами, либо послать данные на вход одному из внутренних объектов, либо послать данные на выходной поток описывающего ее объекта, либо ничего не делать. Если команда меняет состояние, значит ее обрезать нельзя. Если посылает данные, то можно проверить куда и к чему это приводит. Опять же, если где-то что-то меняется — значит нужная вещь, обрезать нельзя, а если уходит в никуда — можно резать.
Дело в том, что у каждого объекта помимо описанных им самим потоков есть неявно добавляемые потоки: для отладки, сервисных сообщений и много других. Не все из них нужны в процессе работы. К примеру, в релизе не нужны отладочные данные и весь процесс их вычисления. Так вот, оптимизатор автоматом отключит не только сами отладочные потоки, но и все, что с ними связано и что больше нигде не используется. Таким образом, если где-то для отладки будет генерироваться строка, то она будет генерироваться ТОЛЬКО во время отладки.
Здесь раскрывается интересная языковая фишка — программа может менять свой функционал в зависимости от окружения. Если окружению не требуется некая фишка, которой обладает программа, то на нее и не будет тратиться производительность.
Еще одна фишка языка — поточность и потокобезопасность. Потокобезобасность осуществляется за счет закрытости объектов. Изменить состояние объекта может только сам объект — это во-первых. Команды, посылаемые извне, выполняются объектом только когда объект не обрабатывает никаких данных (если объект обрабатывает к.л. данные, то команда будет помещена в стэк и выполнена только когда объект завершит либо прервет обработку данных) — это во-вторых. Впрочем, на самом деле, потокобезопасность и вообще вся работа с потоками здесь осуществляется не программистом, а самой программой.
Следующая фишка — необычайные возможности самомодификации программ. Как я писал выше, объекты могут создавать внутренние объекты, удалять их, создавать и удалять связи потоков между ними... А теперь вспомним, что я говорил про эти объеткы? Что они на практике подобны функциям в других языках. Т.е. имеем функцию, которая может в ходе своего выполнения либо по команде извне перестроиться и тем самым повлиять на ход своей работы в течение этого и последующих вызовов. При этом, все ненужные связи, которые выбрасывают данные "в никуда", автоматически пропускаются в процессе работы, так что программа не будет вычислять все, чтобы передать только то, что нужно. Она сразу вычисляет только то, что нужно.
Еще фишка в том, что отладочная информация может быть представлена для конкретного объекта в виде последовательности посылок данных и вызываемых команд. И ее можно перестроить в.. ролик. Каждый кадр — это один шаг по цепочке пересылок данных. Ролик, который программист сможет просмотреть, чтобы понять, в какой момент какой объект выдал не то, что должен был, заглянуть "внутрь" этого объекта и посмотреть его ролик, чтобы найти, что не так в нем и так далее до источника ошибки.
Наконец, сама особенность языка по сути порождает, не побоюсь этого сказать, новую парадигму. Программа — это уже не последовательность действий, а объект со входными и выходными потоками. Это, конечно, будет софистикой, но я скажу: в классических языках цель программы — поскорее дойти до точки выхода. Она всегда стремится выйти, только дурацкий алгоритм обычно постоянно возвращает ее на прежнюю точку, по кругу. А цель программы на этом языке — обработать данные, программа стремится не выйти, а выдать результирующие данные, чтобы затем ждать новой порции данных. Нет, конечно же в этих программах тоже будет точка выхода, они не будут висеть в памяти. Да и в исключительных ситуациях (кстати, исключения здесь тоже передаются через потоки в виде данных; можно подключиться к этим потокам, чтобы ловить исключения и обрабатывать их) программа не просто повиснет в памяти, а хотя бы покончит с собой в печали великой, чтоб другим не мешать. По этой новой парадигме программы описываются не с точки зрения алгоритма, а с точки зрения обработки данных — что имеем на входе и что должны получить на выходе. Команды и состояния здесь — надстройка, все то, что по самой своей сути не является данными и должно быть отделено от них. Именно это отделение позволит значительно уменьшить количество ошибок (и добавить совсем новые, другого рода и природы, чтобы жизнь не была скучна)). Цель такого подхода — создание идеальных программ: с понятным кодом и организацией (ведь здесь недопустимы сложные и глубокие взаимосвязи между объектами, т.к. объекты закрыты), автоматически оптимизируемые, быстрые, надежные, легко отлаживаемые, гибкие и масштабируемые, _______________ (вписать нужное).
Собственно, будущее программирование за этим языком, я гарантирую! Дело за малым: реализовать его...
Но не все так печально — у меня есть некоторые наброски, синтаксис, идеи по реализации и в данный момент я пытаюсь наскоблить время на создание модели языка в каком-нибудь другом языке, для проверки самой парадигмы. Но времени явно не хватает.
А пока жду ваших лучей ненависти) И в тайне надеюсь на то, что кто-то выскажет конструктивные мысли и кого я смогу посвятить в детали реализации.
Здравствуйте, 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>А данные, почему-то не объекты.
О, вы меня понимаете)))
ЗЫ бозе мій, ну раз такая рокировка понятий вызывает жеский анальный разрыв шаблонов, то боюсь этот язык будет сложно понять. Но, так и быть, я изменю название понятия "объект" на какое-нибудь другое. Функтор? Вроде по смыслу подходит.
Здравствуйте, dotneter, Вы писали:
D> А можно основную идею в трех словах? Какие проблемы и каким образом решаются?
Ах, вкусный вопрос. Только я здесь провалюсь. Ну не мастер слова я. Не умею я так просто рассказывать такие сложные вещи.
Ну, вот примерно мой ответ:
Кодоэффективность разграничением и ограничением.
Если не считать "и" словом и не придираться к первому слову, то уложился)
Разграничение данных и обрабатывающих их элементов, отделение процесса обработки данных от изменения состояния самой системы, разделение функций данных и состояний: данные проходят по потокам и в конечном счете "теряются", а состояния остаются внутри объекта все время его жизни.
Ограничение доступа к объекту уменьшает путаницу внутри программы, упрощает ее логику; ограничение возможностей команд позволяет предусмотреть результат работы этой команды.
T>>Ваше описание понимается с трудом (в основном, потому что "объектный объект посылает объект, принимает объект, в поток объекта, объект, объект поток"). Но из того что понятно, Erlang/OTP это именно ваши объекты.
A>Ну, извольте, все вполне ясно. Объектов там не больше, чем нужно.
Забавно. Вам говорят, что непонятно, а вы говорите что понятно. Бесспорно, вы свои идеи понимаете лучше других, это нормально.
Вот вам история.
Я постепенно начинаю понимать слова, которых не понимал раньше. Например, говорили мне, читай книжки. И не только чтобы что-то узнать, а чтобы расширять лексикон. А я думал, что у меня и так нормальный лексикон и книжки не читал. И вот проходит 10 лет, я замечаю, что чем больше читаешь из разных источников, тем проще понять других и проще что-то объяснить. Казалось бы, пиршество очевидности. А раньше не понимал. Это я к тому, что очень полезно знать схожие идеи и понятия называются в других областях, в данном случае, в других языках программирования. Помогает выражать свои мысли.
В вашем описании две проблемы. Первая, это всё-таки слишком много слов "объект" и "поток". В основном, потому что вы сосредоточились на описании нескольких отдельных понятий и механизмов, на их взаимосвязи, вместо того чтобы описать цельную картину, с чего всё начинается, чем заканчивается, какие задачи решаются. Ваше описание было бы гораздо более уместо для детального рассмотрения каких-то вопросов, после "введения". Вторая проблема: неудачные фоны для сравнений. Примеры:
Хороший фон для сравнений это либо абстрактные понятия из математики и computer science, либо сравнения с другими языками.
P.S.: Я отлично понимаю ваш интерес, сам с удовольствием занимался теоретическими изысканиями в языках даже во время отпуска на море. Проблемы реализации спускают с небес на землю. Начните с формального описания синтаксиса и напишите парсер. Удачи вам.
Здравствуйте, Aberro, Вы писали:
A>...Цель такого подхода — создание идеальных программ:... Дело за малым: реализовать его...
Ты мил человек для начала хотя бы привел бы примеры кода (гипотетического). А то пока что это все больно смахивает на какие-то нана-васюки. Даже не ясно на какие задачи это все рассчитано.
A>Но не все так печально — у меня есть некоторые наброски, синтаксис, идеи по реализации и в данный момент я пытаюсь наскоблить время на создание модели языка в каком-нибудь другом языке, для проверки самой парадигмы. Но времени явно не хватает.
А что же ты хочешь? Создать язык, реализовать его компилятор и т.п. — это не простая задача.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
A>>На нем тоже нет. Вообще, можете закидать меня тухлыми помидорами, ибо я очередной амбициозный новичок, с опытом программирования менее пяти лет (ну, ладно, чуть-чуть более пяти; но если вычесть времена, когда я страдал фигней и ничего не писал, то точно выйдет менее пяти, честно-честно). Однако, насколько я могу судить по описанию языка, опять не то.
L>По твоему описанию — именно то.
Я бы сказал — это сумбурное описание модели акторов, которая в том числе используется и в Эрланге.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты мил человек для начала хотя бы привел бы примеры кода (гипотетического). А то пока что это все больно смахивает на какие-то нана-васюки. Даже не ясно на какие задачи это все рассчитано.
В производстве.
VD>А что же ты хочешь? Создать язык, реализовать его компилятор и т.п. — это не простая задача.
Спасибо, Кэп! Вы открыли мне глаза! Пойду расскажу это всему миру!
Здравствуйте, Aberro, Вы писали:
VD>>А что же ты хочешь? Создать язык, реализовать его компилятор и т.п. — это не простая задача. A>Спасибо, Кэп! Вы открыли мне глаза! Пойду расскажу это всему миру!
Многие считают это плевым делом. В прочем, если ты еще не создал ни одного своего языка или не работал над чужими, то уверяю тебя, что когда ты попытаешся сделать это ты поймешь, что глаза у тебя были и правда закрыты.
Кроме самого языка и его компилятора (интерпретатора) на сегодня нужно сделать еще очень многое. Нужна IDE, библиотеки, описание (лучше не одно) и много, много, много, много, много, много, много, много времени (сил и денег) на продвижение своего языка. И даже при наличии всего этого а поставлю 99 против 1 на то, что язык твой не выстрелит. Но пробовать надо! Иначе ничего нового не родится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Aberro, Вы писали:
A>Здравствуйте, batu, Вы писали:
B>>А данные, почему-то не объекты.
A>О, вы меня понимаете))) A>ЗЫ бозе мій, ну раз такая рокировка понятий вызывает жеский анальный разрыв шаблонов, то боюсь этот язык будет сложно понять. Но, так и быть, я изменю название понятия "объект" на какое-нибудь другое. Функтор? Вроде по смыслу подходит.
Если честно, то я ничего не понял. Синтаксиса не видел. Что такое объекты не понял, потоки-события тоже. Самоизменяющиеся инструкции или команды или функторы...в душе я против самоизменяющихся.. Но не вижу за что мозгу зацепиться.Не понимаю я тебя...
Мне кажется, твои идеи (возможно, я не совсем правильно тебя понял — под вечер твои в целом неструктурированные посты тяжело воспринимаются) можно выразить в уже существующем языке:
— как можно более декларативном
— поддерживающим многопоточность
— и синхронизацию/обмен данными в форме каналов
— и ленивость
— ...
— и профит
Из языков разряда "слышал звон" вспоминается oz, обвешанный (вероятно) релевантными фичами по самые гланды.
Из языков "а давайте впихнем сюда еще и Х, вин же" можно вспомнить clojure и haskell — они сами по себе достаточно выразительные, чтобы твой язык (инфа 99%) можно было реализовать внутри них в виде dsl (первый фломастер). Плюс поверх тамошних потоков и stm (насчет clojure терзают сомнения, правда) можно при желании реализовать разные (в своей степени извращенности) формы параллельного программирования (второй фломастер). В итоге имеем два фломастера, которыми можно раскрасить вообще все.
PS. Еще не совсем в тему вроде бы (но все же) впомнился Id (и его потомок pH), про который я как-то читал две винрарные статьи: тыц и тыц. Возможно, тебе будет интересно.
Здравствуйте, Aberro, Вы писали: T>>Erlang A>нет
Кстати, думаю, часть твоих идей можно и поверх эрланга реализовать. Инкапсуляция состояния есть, обмен сообщениями есть. Можно попробовать навернуть свой behavior.
Здравствуйте, Mr.Cat, Вы писали:
MC>PS. Еще не совсем в тему вроде бы (но все же) впомнился Id (и его потомок pH), про который я как-то читал две винрарные статьи: тыц и тыц. Возможно, тебе будет интересно.
Добра тебе, ано.. в смысле, mr. Cat, за ссылки; почитаю как время будет.
MC>Из языков "а давайте впихнем сюда еще и Х, вин же" можно вспомнить clojure и haskell
Нет, мой язык напротив стремится избавиться от лишних фич, оставив основное. Потому как чем больше возможностей у языка, тем больше возможностей ошибиться, запутаться, запутать программу, тем сложнее написание компилятора, тем меньше его эффективность и т.д. и т.п. Не катит. Да и на этом поприще после пёрла и цпп уже делать нечего.
Собственно, по итогам сего скромного обсуждения, я пересмотрел многие идеи своего языка... точнее, перечеркнул нафиг большУю часть задуманного, выбрал путь и решил делать сначала.
Дао этого языка в том, что он исконно и истинно многопоточный. Как в плане потоков вычисления, так и в плане потоков данных. В нем программируется не последовательность действий, а цепочка элементов, по которой направляется поток. Звучит... непонятно, да.. Точнее, не понятно, что в этом вообще особенного? Но чуть попозжа, когда перестрою синтаксис под новые идеи, отвечу. Точнее, раз уж твоя моя не понимать, покажу на примерах кода.
Пока могу наконец-то выложить краткое описание преимуществ языка перед другими современными:
— Полная автоматизация работы с потоками.
— Генерация быстрого и эффективного машинного кода.
— Простота написания самомодифицирующихся программ (об этой фиче чуть ниже пару слов добавлю..)
— Не знаю, как обозвать эту фичу, но выявил такое: коль код во время компиляции может обрубать неиспользуемые ветки, то это значит, что можно создавать компоненты, навешанные стольким количеством фич, сколько позволяет время, фантазия и способности автора компонента. При этом при использовании этого компонента в других программах в результате компиляции останутся только те из фич, которые используются, остальные не будут скомпилированы и значит не будут жрать никаких ресурсов.
По поводу самомодифицирующихся программ: я сию фишку желаю весьма страстно потому, что сама идея языка, работающего с потоками данных, была придумана из идеи написания системы управления искуственными нейронными сетями. И у меня есть мысли о том, как можно использовать этот язык для написания принципиально новой ОС.. пардон, ИИ. Ведь что такое нейросеть? Сеть из нейронов (не поверите), по которым проходят данные, грубо говоря. Там так же есть отдельные участки, соединенные с другими лишь небольшим количеством "каналов" (иже синапсов) и тем самым отделяющиеся от других участков. Так вот, самые сложные (настолько сложные, что они практически нигде не используются) искусственные нейронные сети обладают возможностью создавать новые нейроны и связи. Такая фича есть и в человеческом мозгу. И поэтому я хочу видеть ее в языке. Как знать, может быть он станет языком создания ИИ, мои амбиции это позволяют) Как она будет реализована, опять же, покажу на примерах. Прошу не удалять пока трэд, в течение нескольких дней я вернусь.
Спасибо за внимание, окончен семинар)
A>По поводу самомодифицирующихся программ: я сию фишку желаю весьма страстно потому, что сама идея языка, работающего с потоками данных, была придумана из идеи написания системы управления искуственными нейронными сетями. И у меня есть мысли о том, как можно использовать этот язык для написания принципиально новой ОС.. пардон, ИИ. Ведь что такое нейросеть? Сеть из нейронов (не поверите), по которым проходят данные, грубо говоря. Там так же есть отдельные участки, соединенные с другими лишь небольшим количеством "каналов" (иже синапсов) и тем самым отделяющиеся от других участков. Так вот, самые сложные (настолько сложные, что они практически нигде не используются) искусственные нейронные сети обладают возможностью создавать новые нейроны и связи. Такая фича есть и в человеческом мозгу. И поэтому я хочу видеть ее в языке. Как знать, может быть он станет языком создания ИИ, мои амбиции это позволяют) Как она будет реализована, опять же, покажу на примерах. Прошу не удалять пока трэд, в течение нескольких дней я вернусь. A>Спасибо за внимание, окончен семинар)
Где можно почитать про самые сложные нейронные сети, которые практически нигде не используются?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Aberro, Вы писали:
A>>Спасибо за внимание, окончен семинар)
L>Ты туториал-то по эрлангу почитай, не упорствуй.
Здравствуйте, Temoto, Вы писали:
T>Где можно почитать про самые сложные нейронные сети, которые практически нигде не используются?
Сорри, не помню, давно это было. В процессе раздумий над архитектурой искал, какими они вообще могут быть, чтобы охватить по-возможности все варианты использования.
Окститесь, демоны... Вы хоть пробегитесь глазами по всему тому, что здесь накидали. На то, чтобы все это прочитать, жизни не хватит. А как только дочитаешь, оно еще и устареет.
По поводу велосипедов — так ведь все уже давно придумано и коль так смотреть, то все поголовно занимаются изобретением велосипедов. Так давайте ничего не делать до тех пор, пока не узнаем, что написал каждый программист, когда-либо живший на этом свете! Правда здорово?)
Ок, я читаю то, что вы тут кидаете. И уж простите, но мой поток обработки данных от сетчатки обладает довольно скромными пределами. Так что если вдруг какой добрый самаритянин возжелает потратить свое время и помочь мне, то пусть указывает на основные абзацы в статье, или прямо скажет, что именно НЕ будет изобретением велосипеда.
Впрочем, догадываюсь, что всем по ней.
Здравствуйте, Aberro, Вы писали:
A> Окститесь, демоны... Вы хоть пробегитесь глазами по всему тому, что здесь накидали. На то, чтобы все это прочитать, жизни не хватит. А как только дочитаешь, оно еще и устареет.
Туториал по erlаng-у читается за пару вечеров.
A>По поводу велосипедов — так ведь все уже давно придумано и коль так смотреть, то все поголовно занимаются изобретением велосипедов. Так давайте ничего не делать до тех пор, пока не узнаем, что написал каждый программист, когда-либо живший на этом свете! Правда здорово?)
Отличный аргумент в пользу того, чтобы никогда и ничему не учиться. Только для профессии программиста — это не очень полезный скил.
Здравствуйте, Aberro, Вы писали:
A> Окститесь, демоны... Вы хоть пробегитесь глазами по всему тому, что здесь накидали. На то, чтобы все это прочитать, жизни не хватит. А как только дочитаешь, оно еще и устареет. A>По поводу велосипедов — так ведь все уже давно придумано и коль так смотреть, то все поголовно занимаются изобретением велосипедов. Так давайте ничего не делать до тех пор, пока не узнаем, что написал каждый программист, когда-либо живший на этом свете! Правда здорово?)
Если хочешь разобраться в вопросе — читай. Если хочешь написать свой велосипед — не читай.
Я почти такую же шнягу "изобрел" в 2000-м, когда столкнулся с SDK Maya. Думал, что открыл Америку. Ну да у меня тогда инета небыло.
Здравствуйте, Lloyd, Вы писали:
L>Туториал по erlаng-у читается за пару вечеров. L>Отличный аргумент в пользу того, чтобы никогда и ничему не учиться. Только для профессии программиста — это не очень полезный скил.
Вы издеваетесь? Осталось еще всем остальным здесь написать за сколько можно прочитать выложенные ими ссылки и я сожгу свою клавиатуру и пойду работать на завод, стоять у станка и больше никогда не использовать моск.
А про "аргумент" — уж извольте, это перебор. Я ж не говорю, что каждому совсем не надо ничего читать и все писать самому, с нуля. Я какбэ намекал, что изобретая велосипед (а изобретать что-либо иное просто невозможно, потому как все уже изобретено) зачастую можно придумать уникальную комплекцию фич, которая сможет найти свою нишу, так что ничего зазорного нет в том, чтобы с видом первооткрывателя придумать и реализовать то, что уже давно сделано, но немного не так, как у тебя.
Здравствуйте, Aberro, Вы писали:
L>>Туториал по erlаng-у читается за пару вечеров. L>>Отличный аргумент в пользу того, чтобы никогда и ничему не учиться. Только для профессии программиста — это не очень полезный скил.
A> Вы издеваетесь? Осталось еще всем остальным здесь написать за сколько можно прочитать выложенные ими ссылки и я сожгу свою клавиатуру и пойду работать на завод, стоять у станка и больше никогда не использовать моск.
Вы считаете, что пара вечеров — это много?
A>А про "аргумент" — уж извольте, это перебор. Я ж не говорю, что каждому совсем не надо ничего читать и все писать самому, с нуля. Я какбэ намекал, что изобретая велосипед (а изобретать что-либо иное просто невозможно, потому как все уже изобретено)
Это не так.
A>зачастую можно придумать уникальную комплекцию фич, которая сможет найти свою нишу, так что ничего зазорного нет в том, чтобы с видом первооткрывателя придумать и реализовать то, что уже давно сделано, но немного не так, как у тебя.
L>>Туториал по erlаng-у читается за пару вечеров. L>>Отличный аргумент в пользу того, чтобы никогда и ничему не учиться. Только для профессии программиста — это не очень полезный скил.
A> Вы издеваетесь? Осталось еще всем остальным здесь написать за сколько можно прочитать выложенные ими ссылки и я сожгу свою клавиатуру и пойду работать на завод, стоять у станка и больше никогда не использовать моск. A>А про "аргумент" — уж извольте, это перебор. Я ж не говорю, что каждому совсем не надо ничего читать и все писать самому, с нуля. Я какбэ намекал, что изобретая велосипед (а изобретать что-либо иное просто невозможно, потому как все уже изобретено) зачастую можно придумать уникальную комплекцию фич, которая сможет найти свою нишу, так что ничего зазорного нет в том, чтобы с видом первооткрывателя придумать и реализовать то, что уже давно сделано, но немного не так, как у тебя.
Это не зазорно, просто якобы потратив время (на чтение опыта других людей), на самом деле вы сэкономите себе время не наступая на их ошибки.
А вот если каждый будет изобретать свой велосипед, не изучая чужой опыт, то мы (человечество в целом) так дальше велосипеда никуда и не сдвинемся.
Здравствуйте, Aberro, Вы писали:
A>А про "аргумент" — уж извольте, это перебор. Я ж не говорю, что каждому совсем не надо ничего читать и все писать самому, с нуля. Я какбэ намекал, что изобретая велосипед (а изобретать что-либо иное просто невозможно, потому как все уже изобретено) зачастую можно придумать уникальную комплекцию фич
как всё запущено. ты можешь изобрести новый сотовый телефон? нет, слишком много технологий задействовано. вот так же и с ЯП — для того чтобы хоть попытаться что-то сделать, нужно очень много знать существующих и разбираться в теории. ну а для того чтобы сделать что-то стоящее — надо быть ещё и гением
Здравствуйте, Aberro, Вы писали: A>А как только дочитаешь, оно еще и устареет.
Неа.
Думаю, когда ты и свои идеи причешешь и структурируешь, окажется, что (за исключением, естественно, определенного процента новизны) им лет 20-30.
Здравствуйте, Aberro, Вы писали:
A> Окститесь, демоны... Вы хоть пробегитесь глазами по всему тому, что здесь накидали. На то, чтобы все это прочитать, жизни не хватит. А как только дочитаешь, оно еще и устареет.
База не устареет. Даже более если ее знаешь большая часть новых технологий превращается в "новые", зрение очень сильно проясняет
L>>Туториал по erlаng-у читается за пару вечеров. L>>Отличный аргумент в пользу того, чтобы никогда и ничему не учиться. Только для профессии программиста — это не очень полезный скил.
A>Я какбэ намекал, что изобретая велосипед (а изобретать что-либо иное просто невозможно, потому как все уже изобретено) зачастую можно придумать уникальную комплекцию фич,
Для того, чтобы придумать уникальную «комплекцию» фич, надо знать, какие «комплекции» уже были до этого. Случайно или ВНЕЗАПНО этот набор фич не появится.
Ту не даром говорили про Erlang и про DSL'и в Clojure, Haskell'е, Ruby — эти языки уже реализуют те самые фичи, что тебе хочется реализовать в «новом» языке.
Окститесь, демоны... Вы хоть пробегитесь глазами по всему тому, что здесь накидали. На то, чтобы все это прочитать, жизни не хватит. А как только дочитаешь, оно еще и устареет. 
Вы издеваетесь? Осталось еще всем остальным здесь написать за сколько можно прочитать выложенные ими ссылки и я сожгу свою клавиатуру и пойду работать на завод, стоять у станка и больше никогда не использовать моск. 
