Lisp *

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

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

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, видна часть его кода. Кому интересны подробности — прошу под кат.

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

Я постараюсь докопаться до первоисточников IT-технологий, разобраться, как мыслили и какие концепции были в головах у первопроходцев, о чем они мечтали, каким видели мир будущего. Для чего задумывались «компьютер», «сеть», «гипертекст», «усилители интеллекта», «система коллективного решения задач», какой смысл они вкладывали в эти понятия, какими инструментами хотели добиться результата.

Надеюсь, что эти материалы послужат вдохновением для тех, кто задается вопросом, как перейти «от Нуля к Единице» (создать что-то, чего раньше и в помине не было). Хочется, чтобы IT и «программирование» перестали быть просто «кодингом ради бабла», и напомнить, что они задумывались как рычаг, чтобы изменить методы ведения войны образование, способ совместной деятельности, мышления и коммуникации, как попытка решить мировые проблемы и ответить на вызовы, вставшие перед человечеством. Как-то так.

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

• — приведу алгоритм,
• — расскажу, как его интерпретирует «Автор»,
• — покажу, во что он превращается,
• — немного расскажу про автоматическое самообучение и ИИ,
• — посмеюсь над собой.

SDL2 — отличная библиотека, но туториалов по ней не очень много.
Common Lisp — отличный язык, но статей по нему катастрофически мало.
Думаю этого вполне достаточно, для того чтобы написать этот цикл статей.

Почему я выбрал общелисп? Что ж, на вкус и цвет как говорится.
Впрочем, причины есть:

Все что нужно знать для того чтобы быстро и грамотно настроить Emacs.

Продолжаем перевод эссе и книги Пола Грэма «Хакеры и Художники».

«Мы гонялись за С++ программистами. Нам удалось перетащить их целую кучу на полпути к Lisp.»
Гай Стил, соавтор Java спецификации.

Оригинал — Revenge of the Nerds, Май 2002
За перевод спасибо Щёкотовой Яне.

Начало: Пол Грэм: «Месть ботанов», часть 1
Продолжение: Пол Грэм: «Месть ботанов», часть 2

Часть третья

Центростремительные силы

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

Продолжаем перевод эссе и книги Пола Грэма «Хакеры и Художники».

«Мы гонялись за С++ программистами. Нам удалось перетащить их целую кучу на полпути к Lisp.»
Гай Стил, соавтор Java спецификации.

Оригинал — Revenge of the Nerds, Май 2002
и What Made Lisp Different, декабрь 2001
За перевод спасибо Щёкотовой Яне.

Начало: Пол Грэм: «Месть ботанов», часть 1

Часть вторая

Чем отличается Lisp

Когда Lisp был впервые разработан, он воплощал в себе 9 новых принципов. Сегодня некоторые из них мы воспринимаем как само собой разумеющееся, другие можно увидеть только в более продвинутых языках, а два все еще остаются прерогативой Lisp. Эти 9 принципов перечислены ниже в порядке их применения в основном IT-течении.

Пол Грэм, Design and Research, January 2003

«Хакеры и Художники», глава 15
Проектирование и Исследование
За перевод спасибо knagaev

(Эта статья в своей основе содержит программный доклад на NEPLS осенью 2002 года)

Приезжающих в Америку часто застаёт врасплох манера американцев начинать разговор с вопроса «Чем вы занимаетесь?» Я никогда не любил этот вопрос. Я очень редко слышал достойный ответ на него. Но сейчас думаю, что решил эту проблему. Теперь, если кто-нибудь спрашивает чем я занимаюсь, я смотрю ему прямо в глаза и говорю «Я проектирую новый диалект Lisp.» Этот ответ я рекомендую всем, кто не любит когда интересуются что они делают. Разговор тут же свернёт на другие темы.

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

Различия между проектированием и исследованием похожи на противопоставление нового и хорошего. Архитектурное решение не должно быть новым, но должно быть качественным. Результаты исследования не обязательно должны быть правильными, но обязаны обладать новизной. Думаю, что эти два пути сходятся на вершине: лучший дизайн превосходит своих предшественников на основе использования новых идей, а лучшее исследование решает задачи, которые не столько новые, сколько на самом деле заслуживающие решения. Так что, в конечном счёте, мы стремимся к одному, просто двигаемся с разных сторон.

Друзья, сегодня я хочу поделиться с вами реализацией идеи по созданию модульной, переносимой и масштабируемой конфигурации для вашего любимого текстового редактора, опробованную в деле за многие месяцы на самых различных сочетаниях железа и ПО: Emacs Config.

Продолжаем перевод эссе и книги Пола Грэма «Хакеры и Художники».
Оригинал — Revenge of the Nerds
(кто хочет присоединиться к переводу — пишите в личку)

За перевод спасибо Щёкотовой Яне.
Май 2002

«Мы гонялись за С++ программистами. Нам удалось перетащить их целую кучу на полпути к Lisp.»
Гай Стил, соавтор Java спецификации.

В бизнесе программного обеспечения идет вечная борьба между вооруженными до зубов знаниями учеными, и другой, не менее грозной силой, начальниками, в арсенале которых одно сплошное невежество (* в оригинале pointy-haired boss – персонаж серии комиксов «Дилберт» Скота Адамса, отличается необразованностью и полнейшим отсутствием базовых знаний области, которой он управляет). Все ведь знают, что это за зверь такой? Полагаю, большинство людей в мире технологий не только распознают этого карикатурного персонажа, но и знакомы с реальным человеком из своей фирмы, с которого этот образ срисован.

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

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

Уверен, что вы перестанете играть в «мясо», ибо то, что я вам сейчас расскажу, покажется вам очень интересным, хотя бы потому, что многих специальных терминов вы не поймёте.
Ярослав Гашек

Часть 1 Введение в Scheme
Часть 2 Углубление в Scheme
Часть 3 Практика IronScheme

Практика

Теперь создадим несколько приложений, которые уже ближе к реальной жизни, чем примеры из предыдущей статьи. Философские вопросы и основы разработки мы рассмотрели в предыдущих статьях, поэтому эта будет состоять преимущественно из кода.

Если единственный инструмент, которым вы располагаете, это молоток, то множество различных предметов покажутся вам гвоздями.
Марк Твен

Часть 1 Введение в Scheme
Часть 2 Углубление в Scheme
Часть 3 Практика IronScheme

Знакомимся ближе

Настало время изучить основные конструкции языка Scheme. Самый лучший способ научиться использовать новый язык это начать на нем писать. Начнем постепенное погружение с разбора самых базовых элементов языка.

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

Часть 1 Введение в Scheme
Часть 2 Углубление в Scheme
Часть 3 Практика IronScheme

Введение

В практике программирования часто возникает потребность в написании небольших скриптов для автоматизации различных административных процессов, тестирования и мониторинга. Так же не редко появляется необходимость встроить какой-либо интерпретатор в приложение или просто создать прототип для проверки идеи. Для этих целей можно использовать различные популярные инструменты JavaScript, Python, Lua, Bash, BAT, PHP и много чего еще. А еще бывает потребность хранить структурированные данные в файлах или передавать по сети, когда речь идет о текстовых форматах обычно используются XML, JSON, CSV, даже KV. Однако несмотря на достоинства и распространенность таких широко известных инструментов меня не оставляла навязчивая идея поиска более гибкого и изящного средства.