Очень интересное решение, спасибо, я думал о разработке чего-то подобного, рад что теперь можно адаптировать этот подход. Интересно, работает ли внутри емакса, который внутри termux сложные штуки такие как emacs-jabber или erc или этот подход годится только для org-заметок?
Возможно, вы сейчас имеете дело с куда более качественными компонентами, а избыточность схемы была нужна для компенсации температурного дрейфа характеристик
Хотя в последнем утверждении я может погорячился, иначе не было бы статей https://habr.com/ru/articles/767342/ "Геймдев на Lisp. Часть 1: ECS и металингвистическая абстракция"
Лисп - это мудрый и эксцентричный дядя (настолко эксцентричный что редко покидает свой замок в Трансильвании), который живет в своем мире и мыслит иногда настолько нестандартно, что тебе приходится выбросить из головы не только "все чему учили в школе", но и "best practices" индустрии.
В отличии от Rust он не пытается тебя ограничивать "как бы чего не вышло", в отличии от С++ - не бьет по рукам кувалдой, вместо этого он просто позволяет творческому процесу не создавать проблем - тебе не нужен Rc<RefCell<T>> потому что в языке уже есть быстрый GC, но если ты хочешь - ты можешь придумать что-нибудь свое - и это будет удобно сосуществовать с тем что уже придумано до тебя - без необходимости переписывать мир, потому что в Lisp типизируются не переменные а значения. И это позволяет лепить прототип так как ты захочешь, а перед релизом вдруг обнаружить что он написан на каком-то своем диалекте Лиспа, который включает все необходимое для конкретной этой игры. И если ты вдруг хочешь большей строгости - то твой дядя поможет написать тебе минимальный компилятор этого [твоего суб-диалекта] с разнообразными проверками статическими и динамическими.
Но будем честными, если тебя покусал этот твой дядя, то разработка игр становится уже куда менее интересной чем разработка новых Lisp-ов..
Ну статья написана достаточно полно и подробно - хороший обзор языка с рассмотрением важных сторон. Но: фич меньше чем в лиспе:
numerical tower нет,
поддержки Unicode на уровне языка нет,
куски идеологии раста с изменяемыми и неизменяемыми переменными есть, при этом отражены в синтаксисе, и ради этого использован символ @
лишние виды скобок (наследие кложуры) нарушают гомоиконность, интересно как там макросы с этим нарушением справляются
кложуровские идиомы с кортежами, таблицами и векторами (двух видов) - прибиты к синтаксису (хотя в общем случае было бы достаточно списка, в в частном ради производительности можно было бы использовать стандартные идиомы доступа, которые еще и обобщаются. Т.е. можно было бы использовать общие функции для вектора и списка и делать конкретизацию только ради тюнинга производительности или даже автоматически, опираясь на тип.
вектор отождествлен с массивом, при этом многомерных массивов нет, так что налицо другое толкование термина "массив" (это не те дроиды, которых вы ищете)
nil отделен от пустого списка и от false (что приводит к более многословной обработке особых ситуаций), но имеет право на жизнь
символы есть (но автор ссылается на руби, а не на лисп, из которого руби их унаследовал, это забавно), при этом они интернируются, но отсутстует пакетная механика, затененение и явное управление символами и их видимостью в пакете.
вариадические аргументы функции есть, взято из питона, но нет куда более мощной концепции lambda-list, при этом у автора уже начинают заканчиваться спецсимволы, уже используется даже точка с запятой, могу себе представить сколько времени ушло на отладку парсера и насколько сложным он стал..
Есть файберы, прибиты к языку, хотя в лиспе они могут быть реализованы как библиотеки
Непонятно состояние и интеропом (есть FFI?)
Проверка на равенство изолирует нас от важных деталей
Видно что автор дал себе труд разобраться PLT и лиспах, думаю для него это хорошее упражнение по реализации языка. Думаю некоторые недостатки связаны с тем, что тяжелые в реализации вещи он постарался обойти, чтобы не делать скучную работу. Влияние "современных" языков к сожалению типично для подобных упражнений, т.к. из-за синдрома утенка мы можем часто видеть "кложуру с ароматом раст", но реже видим "лисп с ароматом эрланг" - до более нетривиальных идей тяжелее доходить, а поупражняться в создании языков хочется уже сразу
Cпасибо за интересную статью, но мне кажется она была бы более полной (и более хабра-тортовой) если бы в ней было рассмотрение схемы и методов которые используются для выполнения задач игры на выбранной элементной базе. Тогда бы она была бы не только исторически-обзорной, но информационно-обучающей, а значит еще более полезной.
Ну и от себя хотелось бы узнать, какие именно усилия предпринимал Хигинботэм и на что сумел повлиять
Не потому что "по другому сложно". Просто это один из удобных путей, на котором многие делают акцент, потому что в сравнении с другими языками это новое и необычное. Классическая разработка через файлы вполне типична в лиспах
Очень интересное решение, спасибо, я думал о разработке чего-то подобного, рад что теперь можно адаптировать этот подход. Интересно, работает ли внутри емакса, который внутри termux сложные штуки такие как emacs-jabber или erc или этот подход годится только для org-заметок?
Возможно, вы сейчас имеете дело с куда более качественными компонентами, а избыточность схемы была нужна для компенсации температурного дрейфа характеристик
О, я бы не отказался от ссылок на гайд по обоим асмам..
Хотя в последнем утверждении я может погорячился, иначе не было бы статей https://habr.com/ru/articles/767342/ "Геймдев на Lisp. Часть 1: ECS и металингвистическая абстракция"
Лисп - это мудрый и эксцентричный дядя (настолко эксцентричный что редко покидает свой замок в Трансильвании), который живет в своем мире и мыслит иногда настолько нестандартно, что тебе приходится выбросить из головы не только "все чему учили в школе", но и "best practices" индустрии.
В отличии от Rust он не пытается тебя ограничивать "как бы чего не вышло", в отличии от С++ - не бьет по рукам кувалдой, вместо этого он просто позволяет творческому процесу не создавать проблем - тебе не нужен Rc<RefCell<T>> потому что в языке уже есть быстрый GC, но если ты хочешь - ты можешь придумать что-нибудь свое - и это будет удобно сосуществовать с тем что уже придумано до тебя - без необходимости переписывать мир, потому что в Lisp типизируются не переменные а значения. И это позволяет лепить прототип так как ты захочешь, а перед релизом вдруг обнаружить что он написан на каком-то своем диалекте Лиспа, который включает все необходимое для конкретной этой игры. И если ты вдруг хочешь большей строгости - то твой дядя поможет написать тебе минимальный компилятор этого [твоего суб-диалекта] с разнообразными проверками статическими и динамическими.
Но будем честными, если тебя покусал этот твой дядя, то разработка игр становится уже куда менее интересной чем разработка новых Lisp-ов..
"То ли нужно менять слуховой аппарат, то ли менять окрестность..." (c) БГ
Мне кажется надо идти на собесы к тем кто спрашивает по сикп и книге дракона - у них и денег больше и работать интереснее
Потому что сишное ABI - это лучший интероп на сегодняшний день
Реквестирую хорошее руководство
Почему не раз в полгода тогда? Это будет в 6 раз эффективнее!
Меня тоже очень интересует этот вопрос (аккордовая печать в Linux). Подпишусь здесь
Очень полезно, спасибо!
А есть ли такое для ARM ?
Ну статья написана достаточно полно и подробно - хороший обзор языка с рассмотрением важных сторон. Но: фич меньше чем в лиспе:
numerical tower нет,
поддержки Unicode на уровне языка нет,
куски идеологии раста с изменяемыми и неизменяемыми переменными есть, при этом отражены в синтаксисе, и ради этого использован символ @
лишние виды скобок (наследие кложуры) нарушают гомоиконность, интересно как там макросы с этим нарушением справляются
кложуровские идиомы с кортежами, таблицами и векторами (двух видов) - прибиты к синтаксису (хотя в общем случае было бы достаточно списка, в в частном ради производительности можно было бы использовать стандартные идиомы доступа, которые еще и обобщаются. Т.е. можно было бы использовать общие функции для вектора и списка и делать конкретизацию только ради тюнинга производительности или даже автоматически, опираясь на тип.
вектор отождествлен с массивом, при этом многомерных массивов нет, так что налицо другое толкование термина "массив" (это не те дроиды, которых вы ищете)
nil отделен от пустого списка и от false (что приводит к более многословной обработке особых ситуаций), но имеет право на жизнь
символы есть (но автор ссылается на руби, а не на лисп, из которого руби их унаследовал, это забавно), при этом они интернируются, но отсутстует пакетная механика, затененение и явное управление символами и их видимостью в пакете.
вариадические аргументы функции есть, взято из питона, но нет куда более мощной концепции lambda-list, при этом у автора уже начинают заканчиваться спецсимволы, уже используется даже точка с запятой, могу себе представить сколько времени ушло на отладку парсера и насколько сложным он стал..
Есть файберы, прибиты к языку, хотя в лиспе они могут быть реализованы как библиотеки
Непонятно состояние и интеропом (есть FFI?)
Проверка на равенство изолирует нас от важных деталей
Видно что автор дал себе труд разобраться PLT и лиспах, думаю для него это хорошее упражнение по реализации языка. Думаю некоторые недостатки связаны с тем, что тяжелые в реализации вещи он постарался обойти, чтобы не делать скучную работу. Влияние "современных" языков к сожалению типично для подобных упражнений, т.к. из-за синдрома утенка мы можем часто видеть "кложуру с ароматом раст", но реже видим "лисп с ароматом эрланг" - до более нетривиальных идей тяжелее доходить, а поупражняться в создании языков хочется уже сразу
надо добавлять плашку сарказм
Cпасибо за интересную статью, но мне кажется она была бы более полной (и более хабра-тортовой) если бы в ней было рассмотрение схемы и методов которые используются для выполнения задач игры на выбранной элементной базе. Тогда бы она была бы не только исторически-обзорной, но информационно-обучающей, а значит еще более полезной.
Ну и от себя хотелось бы узнать, какие именно усилия предпринимал Хигинботэм и на что сумел повлиять
А какие отличия?
Не потому что "по другому сложно". Просто это один из удобных путей, на котором многие делают акцент, потому что в сравнении с другими языками это новое и необычное. Классическая разработка через файлы вполне типична в лиспах
Как именно им пользоваться (арбитражем)?
Еще более полезны все эти функции при работе в режиме org для сортировки таблиц. Полностью заменяет эксель например
Я бы в гитхаб-репо добавил список совместимых с проектом телефонов, чисто для того чтобы было проще искать
Отличная статья! Сразу захотелось найти такой телефон и поэкспериментировать с ним. Следующая статья должна быть "получаем доступ к GPIO" :)