Lisp *

Всем привет!

Я сделал перевод и набил субтитры на отличный доклад Рича Хикки — Hammock Driven Development (Разработка через гамак). Впервые на русском языке.

Доклад впервые был представлен в 2010 году на первой конференции Clojure Conj.

Вот есть JavaScript — прекрасная вещь. И прекрасная она на мой взгляд по большей части потому, что дебаггер и отладочные инструменты встроены в каждый Браузер. Без дебаггера и инспектора DOM-дерева было гораздо тяжелее что-либо разрабатывать на JavaScript.

Вот я и решил запилить свой Lisp, но с хорошим дебаггером. Взял маленький, простенький littlelisp и отрефакторил его на 99%. Заточил под пошаговое выполнение и создал свою IDE, простую но работающую.

В итоге получилось следующее.

Всем привет!

Я сделал перевод и набил субтитры на знаменитый доклад Рича Хикки — Simple Made Easy (Простое сделать лёгким). Впервые на русском языке.

Доклад впервые был представлен в 2011 году на конференции Strange Loop.

Научно-практическая конференция Scheme and Functional Programming Workshop 2020 открывает подачу заявок на доклады.

Scheme and Functional Programming Workshop — это ежегодное мероприятие, научно-практическая конференция, на которой собираются специалисты про языкам программирования, эстетически или технологически отвечающим основным принципам, заложенным в Алгоритмическим Языке Scheme: минимализму, сохраняющему универсальность, и тщательному проектированию, обеспечивающему гибкий дизайн.

От докладчиков ожидаются статьи о передовых научных результатах, а также отчёты о практических достижениях, как в инженерной, так и в образовательной сферах, а также развёрнутые предложения по рассмотрению идей сверх-ранней стадии или переосмыслению старых подходов. Приветствуются и поощряются работы, имеющие отношение к любым языкам, входящим в семейство Scheme: от чистых подмножеств RnRS, до «вариаций на тему Схемы», таких как Racket, других диалектов Lisp, включая Closure, Emacs Lisp, Common Lisp, и иных функциональных языков, поддерживающих замыкания и/или макросы (или имеющих таковую поддержку в средствах расширения языка, например, библиотеках). Примерами подобных могут являться Dylan, ECMAScript, Hop, Lua, Scala, Rust и ещё множество других. Общая элегантность работы и релевантность заявленной тебе будут являться более важным критерием оценки, нежели отдельные элементы синтаксиса, в котором реализованы примеры.

Наиболее интересующие темы включают (но не исчерпываются):

Язык Bel написан на языке Bel.


В 1960 году Джон МкКарти описал Lisp — новый тип языка программирования. Я говорю «новый тип» потому что Lisp представлял собой не просто новый язык, но новый способ описания языков.

Чтобы определить Lisp, он начал с малого набора операторов, своего рода аксиом, которые затем использовал для написания интерпретатора для самого языка.

Он не ставил целью описать язык программирования в обычном смысле — язык, используемый, чтобы указывать компьютеру, что ему делать. В его работе 1960 года Lisp понимался как формальная модель вычисления сродни Машине Тюринга. МакКарти не задумывался об ее использовании на компьютерах, пока это не предложил Стив Рассел, его дипломник.

В Lisp 1960 года не было возможностей, обычных для языков программирования. Например, там не было чисел, ошибок или ввода/вывода. Поэтому людям, использовавшим Lisp как основу для языков, используемых для программирования компьютеров, приходилось добавлять эти возможности самим. И они делали это за счет отказа от аксиоматичного подхода.

Привет, Хабр! Предлагаю вашему вниманию перевод статьи «Pragmatic Functional Programming» автора Robert C. Martin (Uncle Bob).

Переход к функциональному программированию всерьез развился только около десяти лет назад. Мы видим, что такие языки, как Scala, Clojure и F# привлекают внимание. На самом деле это был большой шаг в программировании: “О, круто, новый язык!” — энтузиазм… Видимо там было что-то особенное — ну или это мы так думали.  

Закон Мура гласит нам, что скорость компьютеров будет удваиваться каждые 18 месяцев. Данный закон действовал с 1960-х до 2000 годов. Затем он прекратился. Частота достигла 3 ГГц, а затем и вовсе поднялась на плато. Мы достигли скорости света! Сигналы не могут распространяться по поверхности чипа достаточно быстро, чтобы обеспечить более высокие скорости. 

Это привело к тому, что инженеры оборудования изменили свою стратегию. В попытках увеличить пропускную способность, они добавили больше процессоров (ядер). А чтобы освободить место для этих ядер, они удалили большую часть оборудования для кэширования и конвейеризации из чипов. Из-за этого процессоры стали намного медленнее, чем раньше; однако их стало больше. В итоге увеличилась пропускная способность. 

Руководящая философия

1. Языки программирования для людей

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

"Величайший из когда-либо созданных языков программирования"
— Alan Kay, «on Lisp»

Когда Маккарти разработал Lisp в конце 1950-х, он радикально отличался от существующих языков, самым главным из которых был Fortran.

What Remains — это повествовательная игра-адвенчура для 8-битной видеоигровой консоли NES, выпущенная в марте 2019 года как бесплатный ROM, запускаемый в эмуляторе. Она создавалась небольшой командой Iodine Dynamics на протяжении двух лет с перерывами. В настоящий момент игра находится на этапе реализации в «железе»: мы создаём из переработанных деталей ограниченный набор картриджей.


В игре есть 6 уровней, на которых игрок ходит по нескольким сценам с картами с прокруткой в четырёх направлениях, общается с NPC, собирает улики, знакомится их миром, играет в мини-игры и решает простые головоломки. Я был главным инженером проекта, поэтому столкнулся со множеством трудностей при реализации видения команды. Учитывая серьёзные ограничения оборудования NES, достаточно сложно создавать для неё любую игру, не говоря уже о проекте с таким количеством контента, как в What Remains. Только благодаря созданным полезным подсистемам, позволяющим скрыть эту сложность и управлять ею, мы смогли работать как одна команда и завершить игру.


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

Очень рад объявить о завершении моего первого компилятора для языка программирования! Malcc — это инкрементальный AOT-компилятор Lisp, написанный на C.

Вкратце расскажу о его многолетней разработке и что я узнал в процессе. Альтернативное название статьи: «Как написать компилятор за десять лет или меньше».

(В конце есть TL;DR, если вас не волнует предыстория).

Это продолжение статьи «Зачем Racket? Зачем Lisp?», которую я написал примерно через год после того, как открыл для себя Racket. Будучи новичком, я не мог понять дифирамбов, которые со всех сторон сыпались в адрес Lisp. Я не знал, что и думать. Как понимать, что Lisp в конце концов вызовет «глубокое просветление». Окей, как скажешь, бро.

У меня был простой вопрос: какая польза? В прошлой статье я попытался ответить на него и обобщил причины, почему кто-то захочет изучить Lisp или, в частности, Racket.

Я составил список из девяти особенностей языка, наиболее ценных для меня как новичка в Racket. Например, особенность № 5 — «создание новых языков программирования». Этот метод также называется языково-ориентированным программированием, или ЯОП.

Операционные системы (ОС) — обширная тема. На протяжении десятилетий здесь доминировал один подход: Unix. Действительно, большинство современных систем, включая большинство дистрибутивов GNU/Linux, *BSD и macOS, придерживаются архитектуры Unix. (Windows нет, но там почти ничего интересного по этой теме).

В 2000 году Роб Пайк выступил с докладом о том, почему исследования системного ПО не релеванты. Из-за пессимизма или пренебрежения к сообществу он, кажется, полностью проигнорировал жалобы, собранные многими Unix-пользователями в книге The Unix-Haters Handbook (1994). Книга умышленно саркастична, однако указывает на некоторые критические проблемы систем Unix — и они не решены до сих пор.

В 2006 году Элко Доситра опубликовал диссертацию «Полностью функциональная модель развёртывания программного обеспечения», где описан функциональный менеджер пакетов Nix. В 2008 году автор опубликовал NixOS: полностью функциональный дистрибутив Linux. В то время как NixOS повторно использует много свободного ПО для Unix-систем, она настолько отходит от дизайна и философии Unix, что вряд ли её можно назвать «системой Unix».

Злые языки утверждают, что функциональные языки программирования — «языки для написания факториалов». Чаще всего так определяют язык Haskell, мы же начнем с того функционального языка, который сильно повлиял и на Haskell, и на подмножество средств для функционального программирования многих других языков — язык Scheme. По-крайней мере, map и for-each, filter и reduce, а так же apply и eval пришли в наши любимые языки программирования если не именно из Scheme, то в том числе и оттуда.

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

У меня получилось 10 вариантов записи определений функций, которые можно свести к 3 основным способам вычисления: традиционному линейно-рекурсивному вычислительному процессу, итерации, генерации последовательности чисел с последующей сверткой умножением. Предлагаю рассмотреть эти варианты подробнее. Попутно мы рассмотрим: оптимизацию хвостовой рекурсии, функции высших порядков и метапрограммирование, отложенные вычисления, бесконечные списки, мемоизацию, способ создать статическую переменную в Scheme и гигиенические макросы.

Открыто голосование по содержанию второй (из восьми) бета-редакции алгоритмического языка Scheme R7RS-large (Tangerine Edition), а также сбор предложений по третьей бета-редакции (Orange Edition).

Некоторое время назад (года три) решил почитать учебник по Лиспу. Без всякой конкретной цели, просто ради общего развития и возможности шокировать собеседников экзотикой (один раз кажется, даже получилось).

Но при ближайшем рассмотрении Лисп оказался действительно мощным, гибким и как, ни странно, полезным в «быту». Все мелкие задачи автоматизации быстро перекочевали в скрипты на Лиспе, а так же появились возможности для автоматизации более сложной.

Здесь стоить отметить, что под «возможностью автоматизации» я подразумеваю ситуацию, когда суммарное время на написание и отладку программы меньше, чем время, затрачиваемое на решение той же задачи вручную.

Пол Грэм написал не одну статью и даже книгу о преимуществах Лиспа. На момент написания этой статьи Lisp занимает 33-е место в рейтинге TOIBE (в три раза мертвее мёртвого Delphi). Возникает вопрос: почему язык так мало распространён если он так удобен? Приблизительно два года использования дали несколько намёков на причины.

Предыдущая статья

Ошибки, Ошибки, Ошибки…

Хорошая программа должна быть защищена от ошибок пользователя. Это совершенно бесспорно. Ошибки нужно обрабатывать, а еще лучше – предупреждать (профилактика всегда лучше лечения!). Высший пилотаж – так выстроить диалог с пользователем, чтобы последний просто не мог совершить ошибку.

Предыдущая статья

Реализуем оператор присвоения

А теперь научим транслятор обрабатывать оператор присвоения. И здесь перед нами встает классическая задача – обеспечить вычисление алгебраической формулы, заданной в привычной для нас со школьных лет записи. Если бы мы делали интерпретатор, то нам бы понадобилось вычислять значение формулы. В нашем же случае вычислять (во время выполнения) будет ядро Лиспа. А нам нужно всего лишь преобразовать формулу из привычной нам записи в лисповскую.
Привычная нам запись называется “инфиксной нотацией” (знак операции располагается между операндами). В Лиспе знак операции располагается перед операндами (такая запись называется “префиксной нотацией”). Таким образом, наша задача состоит в преобразовании инфиксной формы в префиксную.

Решать эту задачу можно разными путями…

Давайте попробуем написать на Лиспе… транслятор простого императивного языка. Нет-нет, я не ошибся – именно транслятор. Транслировать он будет в Лисп-код. А дальше этот код может быть выполнен Лисп-системой.

Здесь бесценную услугу нам окажет то обстоятельство, что в Лиспе нет барьера между кодом и данными (это редкое свойство некоторых языков программирования называется “гомоиконность”). Но и изобразительные возможности Лиспа тоже сыграют не последнюю роль.

В качестве реализации я буду использовать HomeLisp. Желающие смогут адаптировать этот проект под Common Lisp. Скажу сразу – применительно к рассматриваемой задаче существенная разница между Common Lisp и HomeLisp состоит только в обработке строк и файлов.

Скачать портабельную версию HomeLisp можно по ссылке. На этом же сайте расположена и документация. Желающие могут копировать код из статьи и сразу проверять работоспособность.

Предлагаемая вашему вниманию тема послужила основой для моей мастерской на знаменитой Новосибирской ЛШЮП-2018. С результатами мастерской можно ознакомиться здесь. А далее я излагаю свой подход. Предполагаю, что читатель знаком с языком Лисп.

Приступаем

Начнем с “простого императивного языка”, который мы будем транслировать в Лисп.
Язык будет обрабатывать только числовые данные. Код на этом языке состоит из функций (процедур, возвращающих значения). Среди этих функций одна должна называться main. Именно с этой функции начинается выполнение кода. Хотя зачем так себя связывать? Пишем функции на императивном языке, они транслируются в Лисп и могут использоваться вместе с лисповскими функциями. Но не будем забегать вперед...

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

Понять, как это выглядит, можно посмотрев какой-нибудь ролик на youtube, где демонстрируется интерактивная разработка на Common Lisp.

Файлы меню nanoCAD имеют расширение .cfg и структуру, отличающуюся от структуры меню (*.mnu, *.cui, *.cuix) других САПР. В версии 8.5 появилась поддержка макросов, которые могут содержать несколько команд и параметров, а также LISP-выражения.