В Grammarly основа нашего бизнеса — центральный языковой движок — написан на Common Lisp. Сейчас движок обрабатывает более чем тысячу предложений в секунду, масштабируется горизонтально и надежно служит нам в продакшене почти 3 года.

Мы заметили, что почти нет постов о развертывании Lisp софта в современной облачной инфраструктуре, поэтому мы решили, что поделиться нашим опытом будет хорошей идеей. Рантайм и среда программирования Lisp'а предоставляют несколько уникальных, немного непривычных, возможностей для поддержки продакшн систем (для нетерпеливых — они описаны в последней части).

Wut Lisp?!!

Вопреки распространенному мнению, Lisp это невероятно практичный язык для создания продакшн систем. Вобще говоря, вокруг нас много Lisp-систем: когда вы ищите авиа-билет на Hipmunk или едете в метро в Лондоне, используются Lisp-программы.

Доброго времени суток, уважаемый читатель!
Перед каждым новичком в мире языка программирования Common Lisp
возникает проблема выбора среды разработки — Integrated Development Environment (далее, IDE).

Существует большое количество IDE для Common Lisp. Перечислим некоторые, самые распространенные, из них:

• LispWorks IDE (commercial, crossplatform)
• Allegro Common Lisp (commercial, crossplatform)
• LispIDE (open source, Windows 2K/XP/Vista/7)
• Lispbox (open source, crossplatform)
• Emacs + Slime (open source, crossplatform)

В данной статье я подробно расскажу как установить и настроить кроссплатформенную среду разработки для Common Lisp, как скачивать и устанавливать дополнительные библиотеки при помощи quicklisp — менеджера пакетов Common Lisp. Будет много полезных ссылок на ресурсы и материалы по языку.
Речь пойдет о связке GNU Emacs & Slime.
Если Вас интересует Common Lisp, Вам нужна кроссплатформенная, мощная, интерактивная Common Lisp IDE с блэкджеком и дамами дебаггером и дизассемблером (внезапно!), то, прошу под кат…

Типичный любитель λ-исчисления.

Однажды, бороздя просторы интернета, я наткнулся на новость о лиспоподобном, встраиваемом языке программирования Shen. Раньше у них на главной странице висел пример кода на Лиспе. В примере авторы описывают абстрактную коллекцию и функции работы с ними.

Так уж совпало, что я являюсь тайным почитателем функционального программирования, а значит, в некоторой степени, лямбда-исчисления, которое состоит почти полностью из абстракций. Захотелось мне написать что-то максимально абстрактное и, что бы усложнить себе задачу, я решил, что встроенные типы данных это для слабых прикладников, а реализовать все нужно непременно в терминах кодирования Чёрча.

С лямбда исчислением я был знаком очень поверхностно, так как почти всегда статьи об этом разделе математики состоят полностью из формул, которые никак не попробовать на практике не представляется возможным. Поэтому пришла идея разобраться с ним на практике, и возможно привлечь на темную сторону силы адептов машины Тьюринга ООП.

Если вас не пугает Lisp, много лямбд и y-combinator (не тот, который с новостями),

Многопоточность в Clojure выведена на новый уровень развития, поскольку там реализованы транзакции изменений памяти STM (The software transactional memory system). В качестве демонстрации Рич Хикки (божественный автор Clojure) и Дэвид Миллер (человек, который написал реализацию Clojure под .Net) предлагают программу «ants», которая моделирует муравейник. Каждый муравей там живет в отдельном потоке. Муравьи бегают по клеткам общего поля, собирают еду, носят ее в муравейник и не конфликтуют друг с другом.

Результат своих упражнений с этой программой я и хочу вынести на общее обозрение. Надеюсь, статья будет полезна тем, кто начинает знакомиться с Clojure на платформе .Net.

27 февраля состоялся очередной Python Meetup. В этот раз мы обсуждали:

• Hy — диалект, который позволяет Lisp-разработчикам использовать библиотеки Python, а Python’истам найти решение для некоторых проблем языка, например, отсутствия скобочек.
• Toga — библиотека построения интерфейсов на Python, которая с первого взгляда выглядит как простой и универсальный инструмент, но на деле имеет ряд недоработок.

Во время Lightning Talk участники делились опытом экспорта .doc-файлов и идеями использования AST для трансляции Python в Ruby, JavaScript, C++ и др.

Если вы получаете удовольствие от программирования, то, наверняка, перманентно находитесь в состоянии поиска лучших инструментов, лучших идей, лучших решений. И знаете, конечной остановкой лично для меня стал Emacs. А точнее — его сборка под названием ErgoEmacs. Под катом будет попытка логического и последовательного рассказа об использовании данного текстового редактора в контексте знакомства с ним впервые в жизни (не вдаваясь в сильную конкретику, а скорее стараясь уловить общую идею); идеологическая пропаганда (емакса вообще и лиспа в частности); небольшая критика последней из статей на Хабре по данной тематике, а также небольшое философское заключение. Если вы хотите расширить свой кругозор, прошу под кат.

Доброго времени суток, Читатель!

В данной статье хочу подробно рассказать про настройку текстового редактора GNU Emacs.

Операционная система GNU Emacs — программируемый текстовый редактор для программистов, написанный на программируемом языке программирования.

Для расширения Emacs используется диалект языка Lisp — Emacs Lisp.

В последнее время определенную известность получили transducers — новая фишка из еще не вышедшей Clojure 1.7. На момент написания статьи актуальна Сlojure 1.7-alpha5, но уже успело появиться изрядное количество портов трансдьюсеров на разнообразные языки: Python, Ruby, JavaScript, PHP, Java, C++, Lua, Erlang. И… это немного обескураживает. Ведь довольно давно (еще в Clojure 1.5) добавили библиотеку reducers.Так вот про редьюсеры никто особо не говорил,никуда ничего не портировал, хотя, вроде как, делают они схожие вещи… Или нет?

Давайте разберемся, для чего нам в Clojure понадобились все эти reducers & transducers (они нам правда нужны?), как они работают, как их использовать… И выясним наконец, не пора ли выкидывать reducers на свалку.

От переводчика:
Продолжаем восполнять недостаток информации на русском языке об интереснейшем диалекте Lisp. Предыдущая статья: Разработка веб-приложений в PicoLisp
Домашняя страничка проекта: http://picolisp.com

Несколько недель назад моя жена попросила небольшое приложение — онлайновую базу данных для адресов и контактных данных членов семьи, родственников, друзей и так далее.

Как правило, в PicoLisp база данных содержит объекты различных классов. Для их обработки в GUI должна быть возможность для поиска, создания и удаления объектов, редактирования их свойств.

Наследование, при кажущейся простоте, часто приводит к сложным, сопротивляющимся изменениям структурам. Иерархии классов растут как самый настоящий лес.
Целью наследование является привязка кода (набора методов) к минимальному набору свойств сущности (как правило — объекта), которые он обеспечивает и которые ему требуются. Это упрощает повторное использование, тестирование и анализ кода. Но наборы свойств со временем становятся очень большими, начинают пересекаться нетривиальным образом. И в структуре классов появляются миксины и прочее множественное наследование.
Внести изменения в глубине иерархии становится проблематично, приходится думать заранее о «внедрении зависимостей», разрабатывать и использовать сложные инструменты рефакторинга.

Возможно ли всего этого избежать? Стоит попытаться — пусть методы будут привязаны к множеству характерных свойств объекта (тегов), а иерархия наследования выстраивается автоматически по вложенности этих множеств.

Пусть мы разрабатывает иерархию для игровых персонажей. Часть кода будет общая для всех персонажей — она привязана к пустому набору свойств. Код, отвечающий за их отображение будет представлен в виде вариантов для OpenGL и DirectX разных версий. Что-то будет зависеть от расы персонажа, что-то от наличия и вида магических способностей и тп. Теги персонажа первичны. Они перечисляются явно, а не наследуются. А реализация наследуется в зависимости от набора тегов (по вложенности). Таким образом умение стрелять из ПЗРК не окажется у кенгуру, потому что его унаследовали от пехотинца.

Идея такого подхода была предложена Дмитрием Кимом. Автор не стал ее воплощать в код, я попробую исправить это упущение.
Реализация такого подхода на Clojure, как обычно, на github.

Введение

Несколько дней назад я открыл для себя замечательный ЯП Clojure — один из современных диалектов Lisp, особенностью которого является хорошая реализация средств многопоточности, компиляция в байткод jvm, соответственно возможность использования java — библиотек, jit-компиляция и т.д. Про Clojure можно почитать например тут. Но в этой статье речь пойдёт о метапрограммировании. Lisp устроен таким образом, что данные и код в нём — одно и то же. Объявления функций, макросов, вызовы функций, развёртывание макросов — в Lisp это всё просто списки, возможно вложенные друг в друга.

(defn square [foo] (* foo foo))
(defmacro show-it [foo] `(println ~foo))

Такое единство кода и данных предоставляет мощные возможности для метапрограммирования — код который пишет код, который пишет код, который пишет код и т.д. — это самое обычное дело для программирования на Lisp. В compile-time нам полностью доступен весь функционал языка, мы можем вызывать функции, развёртывать макросы, возможно рекурсивно. Например, если мы определим вот такой макрос:

(пятница)
Всё началось с того, что я прочитал у Станислава Лема в романе «Мир на Земле» (1985), что в будущем общение на языке будет заменено общением при помощи пиктограмм. Мне показалось это довольно пророческим в связи с возрастающим интересом к различным смайликам и другим видам более крупных картинок и я подумал: а что если программировать при помощи emoji? Поискав в сети я убедился, что мысль такая уже приходила в головы людей и воплотилась в проект https://github.com/wheresaddie/Emojinal
но этот проект меня не впечатлил, во-первых язык не обладает полнотой и вообще подход автора как попытка заменить часть операторов при помощи emoji показалась не сильно интересной.

Введение

Common Lisp, а точнее, его объектная система, CLOS, предоставляет пользователю языка совершенно замечательный механизм, а именно, метаобъектный протокол.

К сожалению, очень часто этот компонент языка незаслуженно остается без должного внимания, и в данной статье я постараюсь это несколько компенсировать.

Вообще, что такое метаобъектный протокол? Очевидно, это слой объектной системы, который, судя по названию, каким-либо образом оперирует над ней самой, и управляет ей.

Для чего он нужен? На самом деле, в зависимости от языка и объектной системы, список применений может быть практически безграничен. Это как добавление коду декларативности(аннотации в Java и аттрибуты в C#), так и разнообразная генерация кода и классов в рантайме(здесь можно вспомнить разнообразные persistance и ORM фреймворки), так и многое другое.

С моей лично точки зрения, лучше всего метаобъектные протоколы себя зарекомендовали со стороны закрепления паттернов проектирования на уровне объектной системы. Такие паттерны, как, скажем, синглтон, которые в языках без достаточно развитого ООП приходится снова и снова реализовывать методом copy-n-paste, в моем любимом Common Lisp создаются буквально из пары десятков строчек кода и переиспользуются в дальнейшем исключительно указанием метакласса^[1].

Тем не менее, в нижеследующем тексте я хочу сосредоточиться на кое-чем более интересном, а именно — на изменении правил работы самой объектной системы, самих ее основ. Именно добавление возможностей подобного изменения и было ключевой целью разработчиков метаобъектного протокола для Common Lisp.

Итак, дальнейший текст будет посвящен созданию прототипной объектной системы, подобной JavaScript, в Common Lisp, с использованием метаобъектного протокола и интеграцией ее в CLOS. Полный код проекта доступен на github^[2].

Интерпретатор Lisp на python в одну строчку? Слишком скучно.

Японский программист, инженер Google Shinichiro Hamaji написал его на sed. Sed — потоковый текстовый редактор, представляющий из себя простой язык программирования. В нем нет переменных, есть только примитив GOTO и выполняющие ветвление функциональные возможности; тем не менее он обладает полнотой по Тьюрингу.

Реализация занимает всего 600 строчек.

Выглядит это примерно так:

Читая главу «Двоичные деревья» из книги Джона Монгана Programming Interviews Exposed я задумался о том, как чаще всего рекурсию объясняют начинающим программистам: через сортировку, обход двоичного дерева, построение последовательности Фибоначчи и т.д. Неужели нельзя найти пример поинтереснее? Из закоулков сознания вырвался Лисп, который по своей природе неотделим от понятия рекурсии. Более того, небольшой интерпретатор Лиспа — отличный пример для исследования рекурсии.

Каким же будет минимальный интерпретатор Лиспа, написанный на Питоне? К моему удивлению, решение уложилось в семь строк! Свою роль в этом сыграла как выразительность Питона, так и красота и незамысловатость Лиспа.

Сегодня я завершаю цикл статей, рассказывающих о возможностях языка ZRF, используемого для разработки игр в Zillions of Games. Поскольку я намеренно двигался от простого к сложному, логично предположить, что сегодняшняя игра (в плане реализации) будет сложнее всех предыдущих. Это действительно так. Дело в том, что ZRF ни в коем случае нельзя отнести к универсальным языкам программирования. Он предназначен для описания игр похожих на Шахматы. Чем более «шахматоподобна» игра, тем более очевидно её описание (если, конечно, не обращать внимание на описание правил таких хитрых ходов как рокировка или взятие на проходе). Описание такой игры может быть довольно большим по объему (в этом случае может помочь PreZRF, о котором я писал ранее), но довольно тривиальным по содержанию.

Все меняется когда приходится делать что-то на Шахматы совсем не (или не совсем) похожее. Создание таких приложений как Game of Life или Mine Finder является серьезным вызовом, в случае использования чистого ZRF, без каких либо расширений. Сегодня я постараюсь показать с какими сложностями может быть связана подобная разработка.

Сегодня я хочу продолжить рассказ о возможностях языка описания игр ZRF, используемого Zillions of Games. В предыдущих статьях цикла я показал как описываются ходы фигур, но есть еще одна важная разновидность хода, оставшаяся не рассмотренной. Помимо перемещения фигур по доске (возможно со взятием фигур противника), игрок (если ему это разрешено), может добавлять новые фигуры на поле. Эта разновидность хода называется сбросом (drops).
Кроме того, в сегодняшней статье, я расскажу о том, как в ZoG осуществляется генерация случайных ходов. Этот функционал необходим, например, при реализации игр, использующих броски игровых костей, для выполнения ходов, таких как Ludo или Chaturanga.

В качестве примера, я предлагаю, взяв за основу классические Шахматы, реализовать игру по мотивам одной из миссий сюжетной кампании Battle vs Chess. Большинство миссий в кампании играются по измененным правилам. Миссии различаются по сложности, в некоторых, для победы, достаточно провести одну из пешек в ферзи, в других — поставить мат за ограниченное число ходов. Я предлагаю рассмотреть четвертую миссию кампании Хаоса под названием «Точка невозврата».

         Но мы говорим: здесь в этой пещере на краю света, дварфы и тролли заключили мир, чтобы рука об руку пройти под дланью Смерти.

         И мы говорим: враг наш не Тролль и не Дварф, а злоба, клевета, трусость, сосуды омерзения, те, кто творят зло под личиной добра. Вот с кем мы сражались сегодня, но упрямство глупцов вечно и скажут… что это ложь

                                                                        сэр Терри Праттчетт

В предыдущей статье, я рассказывал об оригинальной настольной игре, разработанной Тревором Трураном, по мотивам произведений знаменитого английского писателя Терри Пратчетта. В 2005 году, Труран разработал новую игру, использующую тот же набор фигур, на той же доске. Название этой игры — "Koom Valley Thud" и, сегодня, я постараюсь ее реализовать, попутно рассказав о тех возможностях языка ZRF, о которых не успел рассказать ранее.

Напомню, что ZRF — это язык описания игровых правил (напоминающий Lisp), используемый Zillions of Games. Несмотря на то, что в нём имеются определенные сложные моменты, в целом, он довольно прост и может быть освоен любым человеком, даже очень далеким от программирования. Главным достоинством игрового ядра ZoG является его универсальность. Описав правила мы, фактически сразу, получаем новую игру. Хотя AI ZoG уступает специализированным игровым движкам, играет он, на удивление, сильно. К сожалению, бесплатная демонстрационная версия приложения позволяет запускать лишь ограниченный набор игр и не позволяет загружать ZRF-описания собственной разработки.

Бац…

…с этим звуком тяжелая дубинка соприкоснулась с чьей то головой. Тело дернулось и завалилось назад. Дело было сделано, никем неуслышанное, неувиденное: идеальный конец, идеальное решение, идеальная история.

Но, как говорят гномы, за любой бедой стоит тролль.

                                                                   сэр Терри Праттчетт

Thud! Разумеется, я не мог пройти мимо этой игры. Не только потому, что мне очень нравятся произведения Терри Пратчета, но, главным образом, по той причине, что игра эта ни на что не похожа. Начнем с того, что играется она на восьмиугольной доске. Гномы сражаются с троллями (и последних существенно меньше). Как тролли могут победить, пребывая в меньшинстве? Очень просто — за один ход тролль может снять с доски несколько гномов. А гномам, даже действуя сообща, чтобы снять с доски одного тролля приходится попотеть.

Настольная игра, по произведению Пратчетта, была разработана в 2002 году Тревором Трураном и выпущена в продажу. С того самого момента, как я узнал про эту игру, мне очень хотелось в нее сыграть. Я долго и безуспешно искал ее компьютерную реализацию, но все, что я нашел, это рассуждения о том, что игра эта слишком сложная, чтобы компьютер мог в нее играть. Теперь, у меня есть возможность проверить это утверждение.

В предыдущей статье я рассказывал об уникальном, на мой взгляд, проекте Zillions of Games. Как я и обещал, я начинаю небольшой цикл учебных статей по описанию возможностей декларативного языка, предназначенного для разработки новых (и описания уже существующих) игр, в рамках этого проекта.

Для того чтобы не загромождать изложение излишними (на этом этапе) подробностями, я выбрал для реализации очень простую игру. Я играл в нее в детстве. Она называется «Волки и Козленок». Правила следующие: Волки (черные фигуры) — ходят на одну клетку по диагонали, только вперед. Козленок (белая фигура) — также ходит на одну клетку по диагонали, но в любую сторону. Задача белых — пройти на любую из четырех клеток своего цвета последней горизонтали. Задача черных — лишить белых возможности хода.

Поскольку на стандартной шахматной доске 8x8 черные побеждают элементарно, используем для игры доску 9x9 клеток. Эта игра очень простая (и нравится детям). При правильной игре, белые всегда побеждают.