ailev.ru

Обсуждение

В архиве: 9 комментариев.

Читать и комментировать в ЖЖ ↗

svv · 11 мая 2010

Комментарий

In a concatenative programming language, things are evaluated by composing several functions which all operate on a single piece of data, passed from function to function. Сразу вызывает ассоциации с point-free style, где тоже акцент на том, чтобы сперва написать длинную формулу, композицию функций -- а потом один раз применить ко входным данным. Вместо того чтобы явно расписывать передачу результатов/параметров в промежуточных вызовах функций. В вики про это почему-то ни слова; зато про это пишут в первом же PDF: This form of purity and the non-existence of variables relates them closely to function-level programming as defined in (Backus, 1978) and the point-free style of functional programming (Gibbons, 1999). Т.е. такая работа с higher-order functions это не то чтобы уникальная вещь для concatenative languages -- оно и в обычных функциональных языках применяется (мы-то и в Java умудряемся ФП протаскивать по возможности, но это уже на грани разумного :)). Но слишком сложные конструкции таким образом писать несколько боязно -- запутанно выходит. Может быть, именно из-за того, что языки на этом не специализируются.

Имя не сохранено · 11 мая 2010

Комментарий

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

Ответ на комментарий

Имя не сохранено · 11 мая 2010

Комментарий

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

Ответ на комментарий

Анатолий Левенчук · 11 мая 2010

Комментарий

Я еще вчера писал ровно об этом point-free в комменте http://ailev.livejournal.com/833513.html?thread=7794921 Но мне в "традиционных языках" это point-free не показалось почему-то -- к тому же оно глубоко перпендикулярно в них получается языковой ориентации, т.е. нацеленности на DSL и служит для другого.

Ответ на комментарий

Имя не сохранено · 23 мая 2010

Комментарий

Forth и Factor все же мало подходят для прямого сравнения. Конечно, если мы пытаемся выбрать некий инструмент для последующего использования, можно выбирать между Factor-ом, Smalltalk-ом и прочими "интересными идеями". Но для меня уход от чистого Форта означает уход от состояния, в котором стратегии программирования и создания DSL еще могут выбираться. Потому что дальше будет "программирование на языке Славы Пестова"...

Анатолий Левенчук · 26 мая 2010

Комментарий

Я над этим вопросом часто думаю: по большому счету, важен не столько "базовый язык" (Форт, Джава или даже Модула-3), сколько библиотеки/словари построенные с использованием этого языка. Тебе дается либо 25 ключевых слов, и ты строишь свою собственную языковую империю (как на Форте "классическом"), либо как на Факторе те же 25 немного других слов и к ним впридачу в разных словарях еще 2500 слов, заботливо написанных до тебя/для тебя в качестве примера и назидания -- и шаг враво-влево уже чреват, ибо это весьма иерархическая конструкция и начальных 25 слов в ней не видно, а зависимости витиеваты. Мы обсуждали это недавно с Мишей Донским (буквально за несколько месяцев до его смерти) -- и он тоже указал, что самое правильное было бы маленькой команде развивать свой язык из тех самых 25 ключевых слов: тогда эта команда довольно легко могла бы управлять СВОИМ кодом, а не ЧУЖИМ. Но это дорогой подход: требует для примерно 8 человек годовой задержки в выдаче реальных результатов, при этом наверняка будет несколько архитектурных фальшстартов. Ежели осваивать чужие словари (библиотеки, DSL -- имен тут много, суть одна), то старт быстрый, но владение чужим кодом не "до дна из 25 слов" много хуже, поэтому результаты будут пушистые: все эти библиотеки в итоге все равно в как-то переписанном/дублированном виде появятся в коде. Так что проблема не в Факторе, в котором есть компактное ядро, а в прилагающихся словарях...

Ответ на комментарий

ext_5229142 · 15 ноября 2019

Комментарий

Думаю, самый правильный подход -- создание гомоиконичной языковой среды поверх mainstream языка типа Python, Java (Android), C# (бизнес-софт и пром.автоматизация), С++, и т.п. Работа в режиме симбионта решает все проблемы: все нужные и ненужные библиотеки уже есть, имеем бесшовную интеграцию с любой программно-аппаратной системой по щелчку пальцев, и при этом можем отобразить эту систему в удобную себе среду и парадигму программирования. Runtime языка-хозяина сразу обеспечивает все нужные фишки типа автоматического управления памятью, не надо ничего изобретать, и месяцами и годами вычищать глюки низкого уровня.

ext_5229142 · 15 ноября 2019

Комментарий

Как пример: https://github.com/ponyatov/metaL/blob/master/metaL.py Берем Форт за общую идею, выкидываем все низкоуровневые заморочки, в качестве базового представления программ -- направленный граф на указателях. Базовый объект по факту содержит в себе форт-машину: словарь, стек, и примитивные операции. Наследуем пару десятков классов, Frame>Active>VM уже явно и полностью представляет Форт, со словарем, компиляцией и поиском. Frame>Active>Cmd обертывает функции на Python. Язык полностью объектный -- один объект на стеке, никаких addr count строк, адресация памяти по именам а не невменяемым численным адресам, которые затирают все подряд. И заодно имеем полную батарею всех существующих Python-библиотек.

Ответ на комментарий

66george · 10 декабря 2019

Комментарий

Посоветуйте, пожалуйста, какой конкатенативный язык мне поучить для развлечения. В каком состоянии Factor, не появилось ли что-то лучшее?