Как стать автором
Обновить

Комментарии 29

Было бы здорово убрать статью в черновики, ознакомиться вот с этим руководством, и переоформить её в соответствии с рекомендациями. Читать тяжело.
Но все языки программирования имеют одинаковый недостаток – они не могут рассматривать алгоритмы, как данные. Программы не могут учиться, по тому, что они не имеют доступа к самим себе.

Эти два тезиса, очевидно, ошибочны.
Матерь Б-жья, вот это шиза.

А вы точно осваивали все известные ныне языки программирования? А то у вас язык си-подобный, файлы TXT, AST-деревом и не пахнет, плюс всякие там rozpad.

Я тут кстати только что на Ruby получил доступ к исходному коду исполняемого скрипта и распарсил его, получив AST. Дальше я могу его изменить, собрать заново и запустить, причем безо всякого rozpad'а. Что я делаю не так?
Любой алгоритм можно представить (преобразовать) в дерево вложенных условий и циклов.
Я вам больше скажу. Любой алгоритм можно преобразовать в поток инструкций с условными переходами. Компиляторы именно этим и занимаются. Но я подозреваю, что у вас нет алгоритма такого преобразования.
Перед запуском каждая функция проходит путь: текст -> дерево -> схема алгоритма. Последняя исполняется интерпретатором. А потом проходит обратный путь преобразований. Так, что изменения в схеме, будут видны в тексте программы.
Lisp передаёт вам привет.
Сходство проявляется только в том, что они оба интерпретаторы. К тому же Лисп язык низкого уровня.
К тому же Лисп язык низкого уровня.

Серьезно? И как вы это определяете?
((1 2 +) 4 *) <==> (1+2)*4 неудобно :) а в больших программах просто не читабельно.
На уровень языка неудобство/нечитабельность никак не влияют. И да, неудобство — это вопрос вашей непривычки, а читабельность нарабывается построением символов более высокого уровня.

PS То, что вы написали, кстати, не лисп.
Лисп настолько низкого уровня, что ему требовалась специальная ЭВМ для запуска в своё время, ага…

К сожалению, это всё очень похоже на «альтернативную теорию электромагнитизма» или «альтернативную теорию гравитации» и тп.
Вы, видимо, плохо искали. Иначе обязательно наткнулись бы на lisp, который реализует принцип программа как данные. При этом, некоторыми он считается достаточно шизоидным. Так что выполняются оба ваших условия.
На самом деле даже на Си никто, как я понимаю, не мешает хранить текст файлов на диске, менять их и вызывать компиляцию из командной строки некоторых из файлов. Придумывать для этого целый свой язык вообще не обязательно. На других языках, даже на Java/C# и т.п. легко генерить классы на лету. Так что проблема изменения исходного кода это самая простая из проблем.
Здесь я видимо должен уточнить. Интерпретатор позволяет алгоритму вмешиваться в себя, прямо в процессе работы.
И ничего перекомпилировать ненужно. Алгоритмы могут анализировать себя как схему алгоритма а не как текст/код программы.
Идея само-модифицирующихся программ далеко не нова, но очень интересна по своей сути.
Статья у вас никудышная, но это вовсе не значит, что ваши идеи бесперспективны и их стоит забросить.
Не обращайте внимание на минусы и продолжайте работать в этом направлении.
Рано или поздно вы обязательно достигните успеха.
Не совсем согласен.
Да, работа хорошая и перспективная. Но. На критику обращать внимание обязательно нужно.
В данном случае прислушаться к советам изучить Лисп.
Из всей статьи мне понравился оператор if(#), который выполняет обе ветви вычисления. В этом есть что-то от квантовой неопределенности. Если сосредоточиться на этой функции и разработать удобный синтаксис для таких дуальных вычислений, может что-то и получится интересное.
Оператор хорош, да, но такую конструкцию вполне легко организовать и на имеющихся ЯП. Хотя, язык с такой штукой «из коробки» — весьма интересно. =)
Да еще с параллельным выполнением таких ветвей, и еще lazy execution всей этой лапши до момента «измерения состояния системы»
Насколько я понял из текста, параллельное исполнение у автора реализовано. Насчет ленивости… это круто, конечно, и если все равновероятно, то даже вроде бы понятно, как реализовать. Но если хочтся управлять вероятностью получить систему в определенном состоянии, то видимо все равно необходимо будет выполнить все ветви.
Насколько я слышал, такое по-умолчанию происходит в большинстве видеокарт для гомогенности исполнения кернелов в рамках одного варпа (ссылка по теме).
В Си и Unix это реализовано ещё с бородатых 70-х годов в виде функции fork().
Не сечешь ты, брат
Крутой язык.
Взглянул в исходный код, это сказка. Ребята, не судите строго человека, дайте ему продолжить.
monstr0518 постарайтесь проверить хотя бы грамматические ошибки в посте, и, конечно, пожалуйста, продолжайте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории