Лисп - это мудрый и эксцентричный дядя (настолко эксцентричный что редко покидает свой замок в Трансильвании), который живет в своем мире и мыслит иногда настолько нестандартно, что тебе приходится выбросить из головы не только "все чему учили в школе", но и "best practices" индустрии.
В отличии от Rust он не пытается тебя ограничивать "как бы чего не вышло", в отличии от С++ - не бьет по рукам кувалдой, вместо этого он просто позволяет творческому процесу не создавать проблем - тебе не нужен Rc<RefCell<T>> потому что в языке уже есть быстрый GC, но если ты хочешь - ты можешь придумать что-нибудь свое - и это будет удобно сосуществовать с тем что уже придумано до тебя - без необходимости переписывать мир, потому что в Lisp типизируются не переменные а значения. И это позволяет лепить прототип так как ты захочешь, а перед релизом вдруг обнаружить что он написан на каком-то своем диалекте Лиспа, который включает все необходимое для конкретной этой игры. И если ты вдруг хочешь большей строгости - то твой дядя поможет написать тебе минимальный компилятор этого [твоего суб-диалекта] с разнообразными проверками статическими и динамическими.
Но будем честными, если тебя покусал этот твой дядя, то разработка игр становится уже куда менее интересной чем разработка новых Lisp-ов..
Ну статья написана достаточно полно и подробно - хороший обзор языка с рассмотрением важных сторон. Но: фич меньше чем в лиспе:
numerical tower нет,
поддержки Unicode на уровне языка нет,
куски идеологии раста с изменяемыми и неизменяемыми переменными есть, при этом отражены в синтаксисе, и ради этого использован символ @
лишние виды скобок (наследие кложуры) нарушают гомоиконность, интересно как там макросы с этим нарушением справляются
кложуровские идиомы с кортежами, таблицами и векторами (двух видов) - прибиты к синтаксису (хотя в общем случае было бы достаточно списка, в в частном ради производительности можно было бы использовать стандартные идиомы доступа, которые еще и обобщаются. Т.е. можно было бы использовать общие функции для вектора и списка и делать конкретизацию только ради тюнинга производительности или даже автоматически, опираясь на тип.
вектор отождествлен с массивом, при этом многомерных массивов нет, так что налицо другое толкование термина "массив" (это не те дроиды, которых вы ищете)
nil отделен от пустого списка и от false (что приводит к более многословной обработке особых ситуаций), но имеет право на жизнь
символы есть (но автор ссылается на руби, а не на лисп, из которого руби их унаследовал, это забавно), при этом они интернируются, но отсутстует пакетная механика, затененение и явное управление символами и их видимостью в пакете.
вариадические аргументы функции есть, взято из питона, но нет куда более мощной концепции lambda-list, при этом у автора уже начинают заканчиваться спецсимволы, уже используется даже точка с запятой, могу себе представить сколько времени ушло на отладку парсера и насколько сложным он стал..
Есть файберы, прибиты к языку, хотя в лиспе они могут быть реализованы как библиотеки
Непонятно состояние и интеропом (есть FFI?)
Проверка на равенство изолирует нас от важных деталей
Видно что автор дал себе труд разобраться PLT и лиспах, думаю для него это хорошее упражнение по реализации языка. Думаю некоторые недостатки связаны с тем, что тяжелые в реализации вещи он постарался обойти, чтобы не делать скучную работу. Влияние "современных" языков к сожалению типично для подобных упражнений, т.к. из-за синдрома утенка мы можем часто видеть "кложуру с ароматом раст", но реже видим "лисп с ароматом эрланг" - до более нетривиальных идей тяжелее доходить, а поупражняться в создании языков хочется уже сразу
Cпасибо за интересную статью, но мне кажется она была бы более полной (и более хабра-тортовой) если бы в ней было рассмотрение схемы и методов которые используются для выполнения задач игры на выбранной элементной базе. Тогда бы она была бы не только исторически-обзорной, но информационно-обучающей, а значит еще более полезной.
Ну и от себя хотелось бы узнать, какие именно усилия предпринимал Хигинботэм и на что сумел повлиять
Не потому что "по другому сложно". Просто это один из удобных путей, на котором многие делают акцент, потому что в сравнении с другими языками это новое и необычное. Классическая разработка через файлы вполне типична в лиспах
Лисп - это мудрый и эксцентричный дядя (настолко эксцентричный что редко покидает свой замок в Трансильвании), который живет в своем мире и мыслит иногда настолько нестандартно, что тебе приходится выбросить из головы не только "все чему учили в школе", но и "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" :)
Откуда такие интересные знания?
Хотел бы прочитать про архитектурные отличия openVMS и ее влияние на другие операционные системы (а также влияние концепций других ОС на нее)
использую эту связку для всего. Не понимаю как без нее жил
Хотел бы попробовать, но нет версии для Linux. Насколько сложно было бы сделать такую программу кроссплатформенной?