Lisp *

1. Что такое Hy

Hy — диалект Лиспа, который встроен в питон.

Благодаря тому, что Hy трансформирует свой Лиспоподобный код в Абстрактное Синтаксическое Дерево (AST) питона, с помощью Hy весь прекрасный мир питона — на кончиках пальцев и в форме Лиспа.

Объединяем Websockets, Lisp и функциональное программирование. Но как?

Некоторое время назад я написал интерпретатор лиспоподобного языка, который назвал Liscript. Опубликовал несколько статей на Хабре, посвященных особенностям реализации ядра, TCO, GUI, REPL-ботов и т.п. Недавно добавил web-интерфейс REPL-у (ссылка в конце статьи).

При чем здесь поцелуи и экскаваторы? Думаю, большинству известны такие аббревиатуры, как KISS (keep it simple stupid — делай это проще, дурачок), YAGNI (You ain't gonna need it — Вам это не понадобится), а также высказывания людей разной степени великости про архитектурных астронавтов, «все должно быть сделано так просто, насколько возможно, но не проще», и т.п.

Допустим, перед вами стоит задача — выкопать яму. Какие есть варианты решения? Взять лопату и выкопать самому — дешево и сердито, но долго и возможно неоптимально (зависит от вашего уровня владения лопатой и размеров ямы). Отдать на аутсорс таджикам (не будем рассматривать здесь этот вариант, хотя я должен был его упомянуть). Взять экскаватор — быстро и эффективно, но затратно: бензин/аренда, плюс не факт, что он проедет в вашу садовую калитку, значит надо сносить/восстанавливать забор и т.д. Также, необходимо определиться с моделью (порой из 100500 вариантов), а если вы будете управлять им самостоятельно, надо разобраться во всех его рычагах и педалях.

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

В общем, про выбор инструментов под задачи, и конкретные (подозреваю, что спорные) решения, которые я выбирал в процессе реализации проекта, под катом.

Для запуска программ, приведённых в статье, можно использовать DrRacket. Для начала рассмотрим связь конечного автомата и игрового процесса. Объект управления в игре можно представить в виде конечного автомата. Рассмотрим программу, моделирующую светофор. Этот пример был описан в предыдущей статье.

Переходом в другое устойчивое состояние является переключение сигнала светофора. Диаграмму состояний можно изобразить в следующем виде.

Следующая статья о том, как писать игры на Scheme

Учебник HtDP (How to Design Programs), посвящен программированию на языке Scheme в среде drRacket.
drRacket можно скачать с сайта.
Вводная часть учебника содержит описание функции empty-scene, предназначенной для работы с изображениями. Например, эта программа создает пустую сцену

#lang racket  
(require 2htdp/image)      ;библиотека для работы с изображениями 
(empty-scene 100 60)     ;сцена (канвас) размером 100х60 

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

+ 1 2 3
=> 6

все интуитивно понятно, вопросов не возникает. Рассказываю про булевские значения, привожу пример:

< 1 2
=> true

тоже все понятно. И тут вопрос из зала: «а если 3 аргумента передать, как будет вычисляться?» Я решаю, что это хороший повод выпендриться умными терминами, и отвечаю: «точно так же — как свертка по моноиду» :) И тут же поправляясь — «хотя операция сравнения не является моноидом», пишу пример:

< 1 2 3
=> true
< 1 2 3 4 1 2
=> false

Все так же интуитивно понятно, вопросов не возникает и продолжаем дальше (благоразумно оставляя без рассмотрения вычисления примитивных операций на одном аргументе и вообще при отсутствии оных, а также вычитание/деление и прочие немоноидальные операции :)). Успешно миновав в докладе подобных камней, через некоторое время я подумал — а можно ли как-то изловчиться, и все-таки сделать операцию сравнения моноидом (в каком-либо смысле)? И мне кажется, мне это удалось. Заинтересовавшихся темой прошу под кат.

Предлагаю читателям "Хабрахабра" перевод (возможно лучшей) статьи Kyle Kingsbury, a.k.a "Aphyr".

Давным-давно, на Шпицбергене, когда ты была юной ведьмочкой всего сорока трех лет, мама взяла в свои ладони твои еще не покрытые шрамами руки, и сказала:

Видрун, зачатая от морских ветров в верхушках елей,
Видрун, зелень моих ветвей, радость и ноша моих дней,
Видрун, всех вдохновенней и умней, да станет мудрость нашего клана твоей:
Никогда не читай Hacker News

Выход восьмой версии платформы nanoCAD Plus стал, на мой взгляд, самым крупным и масштабным обновлением за всю историю ее существования. Появилось множество новых возможностей, были доработаны и переосмыслены уже реализованные функции, учтены пожелания и замечания активных пользователей. Одно из важных изменений восьмой версии – это переработанные настройки пользовательского интерфейса (НПИ). О них и пойдет речь в этой статье, – а именно о том, как создать в nanoCAD кнопку и привязать к ней LISP-приложение. Создавать нашу кнопку мы будем в nanoCAD Plus 8.1, но метод работает и в других приложениях на базе восьмой версии.

Автор статьи — Джеймс Лонг, один из создателей Firefox Developer Tools

Несколько человек на React Conf спросили у меня совета, как программировать лучше. По какой-то причине люди видят во мне продвинутого программиста, к советам которого стоит прислушаться. Я подумал, стоит записать «ментальную модель» того, как я подходил к программированию на протяжении всех лет.

Некоторая информация: мне 32 года и 10 лет твёрдого опыта. Наверное, только в последние пару лет я приобрёл уверенность в том, что делаю. Но даже теперь я продолжаю сомневаться в себе. Дело в том, что это чувство никогда не уходит, так что старайтесь не обращать на него внимания, продолжайте хаки и накапливайте опыт.

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

Некоторое время назад, вдохновившись прочтением SICP, я написал пару своих реализаций интерпретаторов лиспоподобного языка со строгой семантикой, добавил десктопный GUI, консольный интерфейс, написал на нем Тетрис и много чего еще, и опубликовал пару статей на Хабр об этом.

Недавно я добавил возможность широкой аудитории познакомиться с данным языком — написал REPL-ботов для следующих мессенжеров: IRC, Telegram, Slack, Gitter. Боты располагаются на специально созданных для них каналах, но в большинстве случаев их можно добавлять/приглашать на другие каналы и вести с ними личную переписку. Такой формат позволяет проводить текстовые онлайн-доклады на тему основ функционального программирования, сопровождая их демонстрацией интерпретатора в реальном времени.

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

Вступление

С возрастом моя работоспособность не становится выше. Теперь я не могу сидеть по 6 часов не вставая: спина, шея, глаза — все это начинает рано или поздно болеть.

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

Всё больше набирает популярность паттерн использования каналов при создании
многопоточных приложений. Идея не нова, ее дизайн заложен ещё в далёком 1978 году
в виде CSP.Наиболее известная реализация сейчас повсеместно используется в Golang.

Мы же в статье рассмотрим реализацию CSP в core.async для Clojure, если интересно, добро пожаловать под кат.

Луна убывает, такое бывает… ©Земфира

Гейзенбагом называют ту разновидность программных глюков, которая возникает не пойми откуда, не поддается отладке и обнаружению. Словом, ведет себя как тот самый Неуловимый Джо или кроковский кот из недавнего поста. Мне по работе приходилось сталкиваться с такими и про себя я называл это эффектом квантовой механики до тех пор, пока не узнал, что близкое по смыслу название уже давно придумали. Бывает, посылаешь заказчику отладочный бинарник, который всего лишь записывает в журнал больше событий вокруг предполагаемого источника проблемы и после этого проблема исчезает!

heisenbug /hi:'zen-buhg/ n.
A bug that disappears or alters its behavior when one attempts to probe or isolate it.

Предлагаю вашему вниманию свою небольшую познавательную коллекцию квантовых эффектов в программировании.

Эпизод I, OpenOffice не печатает во вторник

Историю этого замечательного багрепорта можно почитать на Ubuntu Launchpad, а я вкратце изложу суть для тех, кому не сподручно читать по ссылке. В системной утилите file был баг из-за которого, файлы содержащие в 4-м байте Tue определялись как Erlang JAM. Дефект присутствовал в версиях file 4.21 и 4.24 и был вызван ошибкой в magic файле.

Если вы никогда не слышали про Алана Кэя, то как минимум слышали его знаменитые цитаты. Например, это высказывание 1971 года:

The best way to predict the future is to invent it.
Лучший способ предсказать будущее это изобрести его.

У Алана очень яркая карьера в информатике. Он получил Премию Киото и Премию Тьюринга за работу над парадигмой объектно-ориентированного программирования. Он был одним из первопроходцев в области персональных компьютеров и графического интерфейса, он разработал Smalltalk — один из первых самых влиятельных языков программирования всех времен.

У нас в Хекслете, особенно в чате, постоянно поднимается вопрос «что такое ООП» и «что имел ввиду Алан Кэй на самом деле». В этой заметке собраны интересные цитаты Алана о состоянии современной разработки, ООП и языке Лисп.

Если вы не слышали о call/cc, то вам определённо стоит познакомиться с этим мощным инструментом! Поговорим о продолжении (call/cc), простой, но трудно понимаемой конструкции, обладающей огромной силой в правильных руках. Реализуем с их помощью механизм yield/next/for… in, аналогичный таковому в Python. Обернём внутренности с помощью макроса — ещё одного интересного механизма Scheme.

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

Сейчас Пол Грэм учит правительства и университеты как создавать стартап-хабы, а а вот раньше… он провел замечательную аналогию между высококлассными программистами и художниками.

За 13 лет глава, одноименная с названием книги, затерялась в сети. Для удобства, хочу опубликовать ее, собранную по кусочкам из различных архивов.

Перевод Анастасии Грызуновой, Яны Щекотовой. Приведение текста в порядок — CaptainCrocus.

Оригинал — Hackers and Painters (May 2003)


Закончив аспирантуру по computer science, я пошел на художественный факультет изучать живопись. Многие удивились, что компьютерщик вдруг заинтересовался живописью. Эти люди, видимо, считали, что хакерство и художество — очень разные занятия: хакерство — холодное, точное и методичное, а художество — яростное выражение некого первобытного порыва.

Оба представления неверны. У хакерства и художества масса общего. Из множества различных типов людей хакеры и художники — едва ли не самые похожие.

«Это началось как желание, стало приключением, а закончилось как уникальное дорожное путешествие.»
— к/ф «Трасса 60»



Пол Грэм написал книгу «Hackers and Painters» (оригинал в PDF на английском) когда еще был больше программистом, чем инвестором. С тех пор некоторые моменты устарели (да и arc не взлетел), но большинство мыслей остались актуальными (роль и место ботанов «хакеров» в современном мире, свободомыслие, критическое мышление, способность бросать вызов большим системам и пр). Лично я планирую перечитать всю книгу еще пару раз.

Спасибо Байраму Аннакову за «наводку» на Пола Грэма и Николаю Кононову, который подтвердил, что я на правильном пути.

Содержание

Глава 1 Why Nerds Are Unpopular — За что не любят ботанов.
Глава 2 Hackers and Painters — Хакеры и художники (Habr edition)
Глава 3 What You Can't Say — О чем вы не можете сказать.
Глава 4 Good Bad Attitude — Слово «хакер».
Глава 5 The Other Road Ahead — Другая дорога в будущее, Другая дорога в будущее, продолжение.
Глава 6 How to Make Wealth — Как стать богатым.
Глава 7 Mind the Gap — Осторожно, разрыв.
Глава 8 A Plan for Spam — План для спама.
Глава 9 Taste for Makers — Вкус — созидателям.
Глава 10 Programming Languages Explained — Языки программирования «в разрезе».
Глава 11 The Hundred-Year Language — Языки программирования через сто лет.
Глава 12 Beating the Averages — Lisp: побеждая посредственность.
Глава 13 Revenge of the Nerds — Месть ботанов 1, 2, 3.
Глава 14 The Dream Language — Быть Популярным, часть 2.
Глава 15 Design and Research — Проектирование и исследование.

Под катом хронология переводов и благодарности.

«Для Viaweb мы часто делали три-пять версий в день.»
— Пол Грэм, разработчик, инвестор, эссеист.


Пол Грэм, Роберт Моррис и Тревор Блэквел в 1995

Очередная глава книги «Хакеры и художники» (которая уже почти полностью переведена на русский)

Другая дорога в будущее

Сентябрь 2001
Оригинал — The Other Road Ahead
(За перевод плюсик в карму knagaev)

(Эта статья объясняет почему многое в ПО следующего поколения может быть реализовано на серверной стороне, что это будет значить для программистов, и почему этот новый вид ПО будет хорошей возможностью для стартапов. Источниками статьи были диалоги в BBN Labs.)

Летом 1995-го я со своим другом Робертом Моррисом (Robert Morris) решили запустить стартап. PR-кампания перед IPO Netscape тогда шла полным ходом, и в прессе было полно разговоров об электронной коммерции. На тот момент в сети уже было порядка тридцати реальных электронных магазинов, и все они были сделаны вручную. Если в скором времени в сети должно было появиться множество онлайн-магазинов, была потребность в ПО для их разработки, и мы решили такое написать.

Сначала, где-то около недели мы думали, что это будет обычное приложение для ПК. Но потом у нас возникла идея разработать приложение, которое будет исполняться на нашем веб-сервере, с использованием браузера в роли пользовательского интерфейса. Мы попробовали переписать приложение для работы в Вебе, и стало понятно, что это правильное направление. Если мы писали наше ПО для исполнения на сервере, это было удобнее как для пользователей, так и для нас.

Оказалось, что это был отличный план. Теперь, как Yahoo Store, это ПО является самым популярным конструктором онлайн-магазинов, с ним работает порядка 14 тысяч пользователей.

В своей прошлой статье Пишем Lisp-интерпретатор на Java я кратко и тезисно рассказал про то, что написал пару интерпретаторов Lisp-подобного языка, который назвал Liscript — на Haskell и на Java. Ничего особо уникального и выдающегося в этом нет, но для меня это было приятным, интересным и познавательным времяпровождением. Среди прочих особенностей, я упомянул про реализацию TCO (tail call optimization) — оптимизацию интерпретатором хвостовых вызовов функций. Этот вопрос вызвал интерес отдельных участников сообщества, и поступило предложение детальнее раскрыть его в отдельной статье, что я и попытался сделать. Интересующихся прошу под кат.

Некоторое время назад мне захотелось написать свой небольшой интерпретируемый скриптовый язык, просто ради фана, не ставя перед собой каких-либо серьезных задач. Я тогда активно читал известную волшебную книгу SICP (Структура и интерпретация компьютерных программ), и мне захотелось реализовать описываемые в ней абстракции — функции как объекты первого класса, замыкания, макросы и т.п. Параллельно я интересовался языком Haskell, и решил совместить приятное с приятным, и написать интерпретатор языка на нем. В моем языке должна была быть строгая семантика с вызовом по значению и мутабельные переменные. Получившийся язык Lisp-семейства я в своем локальном окружении связал с именем Liscript, полная реализация которого уместилась в примерно 250 строк, включая парсер, ядро и консольный/файловый ввод-вывод. Этого более чем хватало, чтобы ради интереса решать любые задачки, какими обычно мучают студентов, которых угораздило изучать Lisp по учебной программе.

По прошествии времени мне захотелось сделать к интерпретатору кроссплатформенный GUI-интерфейс с перспективой портирования на Android, поэтому я реализовал второй вариант интерпретатора на Java, внешний вид которого вы можете видеть на картинке выше. Да, он поддерживает графический вывод и вообще interoperability с Java, и этот Тетрис написан на Liscript, видна часть его кода. Кому интересны подробности — прошу под кат.