Введение

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 клеток. Эта игра очень простая (и нравится детям). При правильной игре, белые всегда побеждают.

Давайте напишем Clojure-библиотеку для работы с реляционными БД. Заодно потренируемся в написании макросов, попробуем использовать протоколы и мультиметоды. Ведь нету лучшего способа узнать язык, нежели что-то на нем написать. Ну… или почитать, как написал кто-то другой.

Эта книга французского профессора Кристиана Кеннека об интерпретаторах Лиспа и Scheme довольно хорошо известна в англоязычном мире. Даже пару раз проскакивала на Хабре. Но в русскоязычном сообществе Scheme чаще всего ассоциируется со «Структурой и интерпретацией компьютерных программ» (aka SICP). Это хороший учебник для новичков, где целых две главы посвящены реализации используемого языка, однако в нём не рассматривается реализация довольно интересных и важных для Лиспа вещей вроде макросов, продолжений, динамических вычислений.

Однажды «Lisp in Small Pieces» попался мне в руки, и через несколько десятков страниц я осознал, что подобному бриллианту негоже пропадать в безвестности. А так как лучший способ получить больше адептов в секту популяризовать иностранную книгу — это перевести её на родной язык целевой аудитории, то этим я и занялся вместо того, чтобы нормально читать. Наконец, перевод, вёрстка и вычитка были завершены; результаты усилий представляются вашему вниманию.

Внутри читателя ожидают:

• более 37000 скобок!
• разбор по косточкам семантики всех конструкций Scheme, а также его родственников;
• в том числе разбор его денотационной семантики — формального математического описания языка в терминах лямбда-исчисления;
• 11 интерпретаторов и 2 компилятора (в машинный код описываемой там же VM и транслятор в код на Си);
• объяснение сути рекурсии, замыканий и окружений, продолжений и стека вызовов, реализации макросов и метаязыков, а также чуть рефлексии и самомодифицирующегося кода;
• множество экскурсов в историю Лиспа и причины принятых решений в дизайне языка;
• собственная CLOS-подобная объектная система автора (и её реализация, разумеется);
• время от времени возникающее чувство: «Да это же X из языка Y»;
• список литературы по теме на 230 наименований.

В общем, отличный учебник по основам реализации языков программирования, с которым стоит ознакомиться не только любителям скобочек.

На этих выходных прошёл Clojure Cup — 48 часовый хакатон на Clojure. Это будет относительно длинный пост про то, как он проходил в нашей команде, с техническими деталями и прочим. Ну, и в конце поста, куда уж без этого, расскажем совсем немного о нашем проекте. А те, кому лень читать, могу сразу перейти на CodeNotes и даже проголосовать за нас на странице Clojure Cup.

Рич Хикки произноситит классные, дающие пищу для размышления выступления. Считается, почти всем, если не поголовно, программистам надо их услышать и увидеть. Если вы не интересуетесь Clojure, лучше смотреть с конца.

• Are We There Yet? – 2009 -размышления о том, правилен ли текущий подход к реализации ООП. Обсуждается много вопросов о проектировании Clojure.

Привет, Хабр!

В некоторых статьях я замечал, что авторы обещали рассказать про историю Lisp машин, но так и не рассказали. Возможно, эта короткая статья будет интересна любителям истории IT.

Да, на свете было мало машин с аппаратной поддержкой лямбда исчисления — около 7000 штук в мире по состоянию на 1988 год. А сейчас гораздо меньше, конечно же. На самом деле Лисп машины сыграли довольно сильную роль в истории информационных технологий. Благодаря этим странным компьютерам мир получил такие технологии, как лазерная печать и многооконный GUI.

Думаю многим фотографам приходилось чистить отснятые фотографии от пылинок на матрице. Не имея полного Photoshop-a или LightRoom-a быстро обработать большое количество фотографий крайне трудно.
Но у нас есть Gimp и желание написать к нему скрипт.
На Хабре уже было не мало статей про возможность написания скриптов в Gimp.
Вот самый подробные обзор самого языка Script-fu и возможности написания на нём расширений к Gimp
Вот тут статья про пакетную обработку.
По идее, прочитав 2 эти статьи, можно сделать что угодно. Но вот только при решении обозначенной в заголовке проблемы, я столкнулся с многими нюансам, на преодоление которых ушло не мало времени, и которые мало где описаны. Даже в англоязычных Tutorial-ах и Help-ах. О них и пойдёт речь.

В этой статье я хочу рассказать про edn. edn — формат данных, появившийся из языка clojure. Он похож на JSON, но предоставляет некоторые возможности, отсутствующие в JSON. Особенности edn описаны далее. Пример для затравки:

{:name "edn"
 :implementations #{"clojure" "java" "ruby" "python" "c" "javascript" "haskell" "erlang"}
 :related "clojure"
 :encoding :UTF-8}

Читатели предыдущей статьи Радикальный подход к разработке приложений могли справедливо заметить, что статья слишком теоретическая. Поэтому спешу восстановить баланс добра и зла теории и практики.

Эта статья раскрывает лишь верхушку айсберга под названием picoLisp. За бортом остались интересные моменты, касающиеся внутренностей базы данных, организация распределенной БД, отладка, функциональный I/O, объектная модель с множественным наследованием, PicoLisp Prolog…

Я всё-таки надеюсь, что отечественные программисты присмотрятся к этому мощному инструменту.

Осторожно, под катом много текста и скобок!

От переводчика: В 2007 году, в поисках веб-движка я наткнулся на очень интересный и необычный диалект лиспа. И после прочтения нескольких статей я был очарован его принципами. Поскольку моя основная работа далека от веб-программирования, то профессионально я его не использую, но время от времени возвращаюсь к нему и понемногу «штурмую».

За всё время знакомства с этим языком он практически нигде не мелькает, и на русском языке информации о нем почти нет. Попробуем восполнить этот пробел. Несмотря на то, что оригинал статьи датируется 2006-ым годом, тема вполне актуальна.
Большое спасибо за помощь в переводе Надежде Захаровой и замечательному сайту Notabenoid.

Что такое хороший язык программирования? Какими качествами и характеристиками он должен обладать? Ответ дать сложно. Вот одно из возможных определений: хороший ЯП должен хорошо решать возложенные на него задачи. Ведь ЯП — лишь инструмент в руках программиста. А инструмент обязан помогать нам в работе. В конце концов, это же и есть причина его создания. Разные ЯП стараются решать разные проблемы (с переменным успехом). Цель, которая ставилась при проектировании Clojure — сделать написанные нами программы простыми. И, как следствие, ускорить их создание, тестирование. А главное, уменьшить время на их понимание, изменение и сопровождение.

Язык Clojure отличается очень тесной интеграцией с Java. Прямое использование Java-библиотеки в приложении на Clojure — дело совершенно простое и обыденное. Обратная интеграция несколько сложнее. В этой статье указаны некоторые варианты интеграции кода на Clojure в Java-приложение.

Введение

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

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