Lisp *

В своей прошлой статье Пишем 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. Однако несмотря на достоинства и распространенность таких широко известных инструментов меня не оставляла навязчивая идея поиска более гибкого и изящного средства.

(Иллюстрации к статье А.П. Ершова «Программирование — вторая грамотность»)

Стив Джобс не написал ни строчки кода, Билл Гейтс — написал. Пол Грэм — первоклассный программист, Питер Тиль — юрист по образованию, сооснователь PayPal и владелец Palantir (написал ли он что-нибудь?), а Илон Маск в детстве написал свою игру и успешно её продал.

Никита truesnow из #tceh сказал мне, что на курсе «Врубаемся в Ruby» они научат программировать любого человека, даже с нуля. Я спросил его: «А с гуманитарием справитесь?» И мы задумались, были ли случаи, когда «гуманитарий» выучил язык программирования?

На ум сразу пришел бомж-программист, но после успеха с его приложением он предпочёл остаться «дзен-монахом». Есть ли еще примеры? Вдохновляющий пример, что научиться кодить может каждый — слепой программист. Когда я прочитал статью на Хабре «Смотря на код с закрытыми глазами», то понял, что нет преград, кроме собственных отмазок.

А у меня для вас есть три истории из моей жизни. Просто три истории.

История первая — ламер

Слово «ламер» я прочитал в «Компьютерре». Там давалось такое определение: «Ламер — отнюдь не безграмотный человек, не умеющий (как бы это помягче выразиться?) программировать». Окрылённый истиной я побежал и рассказал об этом друзьям-одноклассникам, но они предпочли поиграть в футбол, вместо того чтобы освоить суперспособности. Забавно, что потом все они зарабатывали программированием деньги, а я нет. Через неделю я записался в краевую станцию юных техников (КСЮТ), где был кружок по программированию. Там для новичков давали qbasic. А боги прогали на C.

Не бойтесь совершенства. Вам его не достичь!

                                           Сальвадор Дали

Взгляв в прошлое

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

Более основательное знакомство с Emacs Lisp и общение с откликнувшимися сведущими людьми (respect2: Иван Алексеев aka Yurii Sapfot) укрепило в мысли, что более правильное решение следует искать в направлении оверлеев. Так появилась версия №2 которую я и предлагаю уважаемым читателям.

To follow the path:
look to the master,
follow the master,
walk with the master,
see through the master,
become the master.

«Лучший способ писать — это переписывать» Пол Грэм, «The Age of the Essay»

Преред курсом Сергея Абдульманова ( milfgard) я взял для себя квест — структурировать все статьи Грэма. Пол не только крутой программист и инвестор — он мастер лаконичного письма. Если milfgard назвал свой курс для контент-менеджеров "Буквы, которые стреляют в голову", то Пол Грэм стреляет из «по глазам» (кто играл в Fallout 2 тот поймет).

А еще мне захотелось освоить Lisp. Чисто так, чтобы мозг поразвивать, потому что крутые люди — Грэм, Кей и Рэймонд, Моррис — говорят хором: «Учите Lisp».

На данный момент Пол Грэм написал (по крайней мере, я нашел) 167 эссе. Из них на русский переведены 69.74(+10). Если читать по 1 статье в день (что очень хороший результат, потому что я после одной статьи хожу задумчивый неделю — голова кипит как после отличного мастер-класса, а иногда и как после двухдневного интенсива), то процесс займет полгода.

Под катом — список всех статей со ссылками на оригинал и с переводом (если он есть). Подборка живая (так что, как обычно, добавляйте в избранное, потом прочитаете) и будет дополняться по мере обнаружения свежака. Еще вы найдете переведенную на 8/15 книгу «Хакеры и художники» и 4/25 перевода книги «On Lisp». Так же я приведу свою подборку топ-5 статей Пола Грэма, с которых я бы рекомендовал начать знакомство с этим автором.

После нашего последнего интервью с Brian McKenna для This is not a Monad tutorial мы взяли интервью у Nenad Rakocevic, создателя языка программирования Red.

С моей субъективной точки зрения Red и Rebol довольно странные создания! Но не поймите меня неправильно, это не значит ничего плохого. Например, я не знаю многих высокоуровневых языков с такими возможностями как встраиваемые DSL для стандартного низкоуровневого программирования или имеющего 50 встроенных типов. Вам следует попробовать его, вы найдете много интересных идеи в программировании на Red.

Пишите мне на твиттер @unbalancedparen свои комментарии или предложения по интервью для This is not a Monad tutorial. Оставайтесь с нами!



Расскажите нам немного о появлении Red. Для чего он был создан?

От переводчика:
Мне часто доводилось слышать, что в Common Lisp библиотеки из 80ых, и других вобще нет, а множество его пользователей представляет собой 3.5 профессоров, работающих над искусственным интеллектом в катакомбах DARPA и не имеющих даже близкого представления о повседневных задач рядового программиста. Данная статья хорошо показывает, что хоть вы и можете наткнуться на старые библиотеки, но использовать стоит лишь современные аналоги, что существующие библиотеки развиваются и постоянно появляются новые.

Автор этой статьи, Fernando Borretti, является активным контрибьютором в экосистему Common Lisp'а, автор более 30 библиотек, большинство из которых предназначены для веб-разработки.

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

К чему эти прыжки?

                 Остап Бендер

Вступление

Вообще-то я хотел написать небольшую заметку «о некоторых особенностях работы с макросами в Clojure». Но попутно решил наконец более основательно ознакомиться с Emacs.

Я конечно не совсем ровестник Lisp, однако знакомы мы вот уже… дцать лет и потенциал этого замечательного языка (даже скорее философии) вполне себе представляю и в теории и на практике. Было дело писал и свои реализации (скорее для лучшего понимания механизмов работы интерпретатора Lisp нежели для практического использования). Однако, Emacs практически не использовал т.к. в стародавние времена достаточно плотной работы с Lisp вполне обходился встроенным редактором моей версии (muLisp, редактор конечно же тоже был написан на нём самом). Потом приходилось работать с «более другими» инструментами, а последние годы и вовсе в иной сфере. Сейчас вот появилось немного времени «для души»…

Собственно «погружение» в Emacs прошло вполне комфортно — хотя я (почему-то всё ещё) и не юниксоид, но к консольным командам и вообще работе с клавиатурой отношусь с пониманием. Настройка управления и джентльменского набора «плагинов» также не вызвала проблем. С прикручиванием SBCL, Clojure и Scala пришлось немного повозиться, но всему виной было несоответствие версий и/или их (версий) врождённые проблемы.

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