Lisp

За свою карьеру я успел поработать со множеством языков программирования. Писал flash-игры на ActionScript 3 и Android-игры на Java, сервера на Java, Scala и NodeJS (JavaScript), скрипты на Python, веб и мобильные приложения на React (JavaScript). И на каком бы языке я не писал, меня не покидало ощущение, что синтаксис этого языка слишком многословен, полон излишеств, шума и синтаксического бойлерплейта, мешающего пониманию написанного кода.

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

• Человекочитаемость - идеальный язык должен быть читабельным и легким для понимания человеком

• Лаконичность - код на идеальном языке программирования должен содержать как можно больше смысла на квадратный сантиметр экрана. Максимум семантики, минимум синтаксиса.

• Внутренняя непротиворечивость - синтаксические конструкции языка должны быть внутренне согласованы и хорошо сочетаемы

• Чистота и красота - язык должен выглядеть максимально чисто и эстетически красиво

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

Единственным параметром, которому не до конца соответствовал Lisp, был параметр чистоты и красоты. Уходящие за горизонт заборы из скобочек не нравились мне с точки зрения эстетики. И я нашел решение: чтобы уменьшить количество скобочек можно сделать значимой индентацию, как это сделано в Python.

Я продолжал заниматься своими экспериментами в приватном репозитории гитхаба, то забрасывая их, то снова к ним возвращаясь. А тем временем моим основным рабочим языком становился JavaScript.

Как я перестал бояться и полюбил JavaScript

Изначально я не любил JavaScript. Не потому что в нем было что-то не так, а просто потому что я подвергся влиянию популярного мнения, что JavaScript - это неполноценный язык для дурачков, а настоящие программисты пишут только на "тру" языках.

Незадолго до знакомства с JavaScript моим основным рабочим языком была Scala. Вот он-то мне казался по-настоящему крутым, ибо он был полон сверхсложной эквилибристки типов и даже для написания простейшего http-сервера на Scala требовался высший пилотаж.

Поэтому когда я открыл для себя NodeJS, я сначала не поверил, что можно писать так просто и лаконично. И чем дольше я знакомился с JavaScript, тем более гениально спроектированным и внутренне согласованным он мне казался. Система объектов и прототипов позволяет легко писать код в объектно-ориентированном стиле, а то, что в основе всего этого лежит функция, делает легким и приятным программирование в привычном мне функциональном стиле. А динамическая природа языка делает его фантастически гибким.

Кроме того в экосистеме JavaScript меня поразило обилие инструментов и хороших библиотек. В Scala в порядке вещей была ситуация, когда библиотека была написана для работы над PhD и заброшена после защиты диссертации. В Java библиотеки были в основном рабочими, но многие из них были абсолютно не дружелюбными - лежали не пойми где, не имели документации в нормальном виде, имели ужасный API и так далее. У каждого языка была своя ужасающая система сборки и управления зависимостями вроде maven, gradle или sbt.

В JavaScript же программисту доступен удобный пакетный-менеджер npm, полный прекрасно отлаженных библиотек с хорошей документацией, удобным API и дружелюбным коммьюнити. То, что кажется обыденностью в экосистеме JavaScript, в экосистемах других языков не является таковым: например, не во всех случаях является возможным понять что же делает какая-нибудь Ruby-библиотека по ее readme в гитхабе.

Отдельным преимуществом JavaScript является то, что сейчас его можно запустить где угодно. Для веб-приложений уже давно стандартом является React, на мобильных девайсах очень распространен React Native, на сервере бешено популярен NodeJS. JavaScript стал де-факто универсальным языком, на котором можно писать под что-угодно. Даже миллиарды микроволновок и утюгов, которые раньше были вотчиной Java, скоро все будут программироваться на JavaScript.

Но есть ли у JS какие-нибудь минусы?

Что не так с JavaScript

Я программирую на JavaScript, в основном, в чисто функциональном стиле. Я использую const, не мутирую объекты и массивы, использую чистые функции. Так что мой код выглядит примерно так:

const incrementNumbers = numbers => numbers.map(number => number + 1)const takeNumbersGreaterThan = threshold => numbers => numbers.filter(number => number > threshold)const func = (numbers, threshold) => {    const incrementedNumbers = incrementNumbers(numbers)    const filteredNumbers = takeNumbersGreaterThan(threshold)(incrementedNumbers)    return incrementedNumbers}

Не смотрите, что этот код является переусложенным и может быть написан в разы проще. Здесь я хочу продемонстрировать то, что если вы как и я пишите код на JavaScript в исключительно функциональном стиле, то кучу места на вашем экране занимает абсолютно ненужный вам синтаксический мусор вроде слова "const", когда все и так всегда константа, и фигурных скобочек, когда все и так разделено индентацией.

Собственно, именно эти недостатки и натолкнули меня на возвращение к проекту собственного языка программирования. Ну а из-за описанных мною ранее громадных преимуществ экосистемы именно JavaScript я сделал платформой для своего языка.

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

Порядок выполнения операций

Давайте начнем с азов. А именно порядка выполнения операций. Как я писал выше, основой синтаксиса для моего языка послужил Lisp, но чтобы сократить количество скобочек, я решил использовать индентацию.

Поэтому в моем языке выражение:

a (b c) (d e)

можно также записать как:

a  b c  d e

Ну а выражение:

a (b (c d))

может быть записано так:

a  b (c d)

или так:

a  b    c d

Присваивание

Самый базовый оператор в любом языке программирования - это оператор присваивания. В случае функциональных иммутабельных языков программирования правильнее было бы сказать не присваивание, а объявление константы.

В Una константа объявляется так:

= name "John"= number 1

Если мы хотим присвоить константе значение вычислений, то делаем так:

= z (calculate x y)

а можно обойтись и без скобок, этот оператор позволяет сделать так:

= z calculate x y

или так

= z calclulate  x  y

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

Арифметика, сравнения и логика

В Una вы можете пользоваться стандартными JavaScript операторами арифметики, сравнения и логики.

Арифметические операции выглядят так:

= a (+ 1 2)= b (- 2 1)= c (* 3 2)= d (/ 4 2)= e (% 5 2)

Все из них могут принимать множество параметров. Например:

= sum (+ 1 2 3 4 5)

А минус может принимать и один параметр, что является отрицанием числа:

= a (- 1)= b -1

Вот пример сложных арифметических расчетов:

= a +  * 2 4  / 9 3  + (* 3 2) (/ 4 2)  *    + 1 2    / 6 3

Конечно также вы можете использовать любые функции из стандартной библиотеки JS:

= randomNumber Math.random ()

Операторы сравнения имеют некоторые отличия от JavaScript. Давайте посмотрим:

= a (== 1 1)= b (~= 1 '1')= c (!= 1 '1')= d (!~= 1 '2')= e (> 2 1)= f (>= 2 1)= g (< 1 2)= h (<= 1 2)

Оператор == и != - это точное по типу сравнение, аналог === и !== в JavaScript. Для неточного по типу сравнения нужно применять ~= и !~=.

Логические операторы тоже немного отличаются:

= a (& true false)= b (| true false)= c (! true)= d !c

Как вы видите, вместо && используется &, а вместо || используется |.

Условные операторы

Тернарный условный оператор работает также как и в JavaScript:

= message  ? (> 2 1) "Greater" "Less"

А еще существует условный оператор с возвращением значения:

?! (== number 1) "One"

Он используется в функцях и других вычислимых блоках, чтобы вернуть значение по условию и соответствует следующему коду на JavaScript:

if (number === 1) return "One"

Коллекции

В Una есть две базовые коллекции: массивы и объекты.

Массив задается следующим образом:

= numbers :: 1 2 3 4 5

А объект задается так:

= user :  name 'John'  age 13  passport :    id 1    country 'USA'

В Una работают все трюки JavaScript.

Можно задать элемент массива или поле объекта готовой константой:

= a 1= numbers :: a 2 3= name 'John'= user :  name  age 13

Работает троеточие:

= threeNumbers :: 1 2 3= fiveNumbers :: ...threeNumbers 45= userFields :  name 'John'  age 13= user :  id 1  gender 'm'  isAlive true  ...userFields

Работает деконструкция:

= numbers :: 1 2 3= (:: one two three) numbersconsole.log one= user : (name 'John') (age 12)= (: name) userconsole.log name

А чтобы взять определенный элемент массива или значение определенного поля объекта используется точка:

= list :: 1 2 3= object : (a 1) (b 2)console.log (. list 0)console.log (. object 'a')

Также точка может быть использована, чтобы взять конкретное поле объекта таким образом:

= object : (a 1)console.log (.a object)

Этот синтаксис удобен для вызова функций, лежащих внутри объекта.

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

Стрелочная симметрия синхронных вычислений

Правая стрелка симметрии синхронных вычислений является функцией:

= sum -> (x y)  + x y= onePlusTwo -> ()  = one 1  = two 2  + one two

Последняя строчка функции всегда является возвращаемым значением. Данный код на JavaScript будет выглядить так:

const sum = (x, y) => x + yconst onePlusTwo = () => {  const one = 1  const two = 2  return one + two}

Для преждевременного прерывания выполнения функции можно использовать вышеупомянутый условный оператор:

= isSumGreaterThanFiveIfXisNotZero -> (x y)  ?! (== x 0) "X is zero"  = sum (+ x y)  ? (> sum 5)    "Greater"    "Less"

Левая стрелка симметрии синхронных вычислений является мнгновенно выполняемым блоком кода, также называемым Immediately Invoked Function Expression:

= result <-  = a 1  = b 2  + a b

Этот оператор можно использовать для чего-то вроде задания константы значением по каким-то условиям:

= result <-  ?! (== value 0) "Zero"  ?! (== value 1) "One"  ? (< value 10) "Less than ten" "More than ten"

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

= func -> number  ? (== number 0)    <-      console.log "Number is zero!"  + number 1

Стрелочная симметрия асинхронных вычислений

Правой стрелкой симметрии асинхронных вычислений является асинхронная функция:

= getUserPosts --> user  database.loadPosts user.postIds

Левой стрелкой симметрии асинхронных вычислений является await:

= checkIfUserIsAdmin --> userId  = user <-- (database.loadUser userId)  == user.role 'admin'

Стрелочная симметрия модулей

Правой стрелкой модульной симметрии является импорт:

=-> './index.css'=-> 'react' React=-> './validation' (: validateEmail)

Он превращается в import или в require в зависимости от соответствующей настройки компилятора.

Левой стрелкой модульной симметрии является экспорт.

Дефолтный - export default в JavaScript:

<-= a

Экспорт отдельной константы export const в JavaScript:

<-= = a 1

Экспорт нескольких констант - export {a, b} в JavaScript:

<-= ()  a  b

Вы можете импортировать любые JavaScript-модули в Una, и любые Una-модули в JavaScript. Все модули полностью совместимы друг с другом.

Стрелочная симметрия ошибок

Правой стрелкой симметрии ошибок является try-catch:

|->  <-    = getName null    getName ()  -> error    console.log error    'John'

В отличие от JavaScript в Una этот оператор является выражением, всегда возвращающим значение, а также этот оператор не имеет блока finally.

Если нужно исполнить асинхронный код, то соответствующие стрелки симметрии заменяются на асинхронные:

|->  <--    getNameAsync ()  --> error    console.log error    "John"

Левой стрелкой симметрии ошибок является выброс ошибки:

= addOneToNumber -> number  ?! (isNaN number)    <-| "number is not valid"  + number 1

Стрелочная симметрия чейнинга

Правая стрелка симметрии чейнинга подставляет выражение как последний параметр следующей за ним функции. Это нужно для удобной работы с такими библиотеками как ramda:

=-> 'ramda' R= electronics ::  :    title ' iPhone '    type 'phone'= phones |>  electronics  R.find    R.propEq 'type' 'phone'  R.prop 'title'  R.toUpper  R.trim

Левая стрелка симметрии чейнинга подставляет выражение как первый параметр следующей за ним функции. Это удобно для работу со стандартными методами массивов и lodash:

= sum <| (:: 1 2 3)  .map (-> x (+ x 1))  .filter (-> x (> x 2))  .reduce (-> (x y) (+ x y)) 0

Без чейнинга это выражение выглядело бы уродски:

= sum .reduce  .filter    .map (:: 1 2 3) (-> x (+ x 1))    -> x (> x 2)  -> (x y) (+ x y)  0

Интерполяция строк

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

= name 'John'= count 5= fruit 'apples'= text `  'Hello, ${0}' name  'I have ${0} ${1}'    count    fruitconsole.log text

Этот пример выведет:

Hello, JohnI have 5 apples

Так же вы можете провести интерполяцию строк по какой-либо функции - чтобы сделать это пришлите функцию первым параметром. Это очень часто используется например в styled-components:

= color 'red'= Container `  styled.div  'background-color: ${0};' color

React и React Native

Для написания веб-приложения на React или мобильного приложения на React Native вы не сможете использовать JSX. Вместо этого вы можете использовать функцию createElement, лежащую в основе React.

=-> './index.css'=-> 'react' React=-> 'react-dom' ReactDOM=-> './styles' S= (: (createElement e)) React= App -> ((: name))  = (:: count setCount) (React.useState 0)  e S.Container :    e S.Hello (: (color 'green')) 'Hello, '    e S.Name : name    e S.IncrementCount      : (onClick (-> () (setCount (+ count 1))))      'Press me'    e S.Count : countReactDOM.render  e App (: (name 'John'))  document.getElementById 'root'

Первым аргументом функция всегда принимает компонент, вторым объект с параметрами (для пустого объекта в Una вы можете использовать : ), а все последующие параметры - это chilldren.

Что еще предстоит сделать

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

• регулярные выражения

• возможность заинстансить класс (оператор new)

• комментарии в коде

• плагин для Visual Studio Code с подсветкой синтаксиса

• и многое другое...

Заключение

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

Спасибо за внимание!

TL;DR: Я написал и выложил на всеобщее обсуждение Scheme Request for Implementation 216. Он нацелен на то, чтобы одна из самых известных в мире учебных программ по Computer Science, Structure and Interpretation of Computer Programs, стала выполнимой в полном объёме не только на MIT/GNU Scheme, но и на других интерпретаторах и компиляторах, в частности, на вашем любимом. И если раньше запрос в багтрекер "сделайте, пожалуйста, поддержку SICP" звучал бы расплывчато, то после принятия данного SRFI, поддержка SICP должна стать намного более общепринятой.

Чтобы написать этот документ, я проработал SICP целиком (что потребовало более 700 рабочих часов и заслуживает отдельного поста), выделил части, до сих пор не вошедшие в стандарт, и сформулировал их в качестве двух документов, SRFI-203 (принят в сентябе 2020), и данного, SRFI-216, к которому я и приглашаю всех присоединиться.

За техническими деталями и подробностями, прошу под кат.

Что такое "Структура и Интерпретация Компьютерных Программ"? (Structure and Interpretation of Computer Programs)

Это одна из самых известных учебных программ по "общему программированию", ранее преподаваемая в Массачусеттском Технологическом Институте (MIT), в качестве вступительной, а ныне перенесённая на старшие курсы из-за гигантского объёма и глубины, которая, как считается более программисту не требуется. Курс проводит студента от однострочной программы, которая складывает два числа, до написания собственной реализации Scheme, включающей компилятор и интерпретатор. Первое издание книги, в которой изложена программа, было выпущено в 80е годы, второе вышло в 1996 году. В книге более 350 задач. Существует русский перевод. Книга была одной из первых, к которым стал прилагаться веб-сайт. (Который работает до сих пор.)

Чем она хороша?

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

Чем она не устраивает сейчас?

За исключением двух программных систем, (MIT/GNU Scheme и Racket, из которых только одна (MIT) является Scheme-системой в полном смысле этого слова) SICP непроходима на большинстве Схем, которые встречаются в живой природе. Представьте, что книжка, "Язык Си" позволяла бы вам выучить только Intel C.

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

Зачем проходить SICP на других Scheme-системах?

Одно из главных достоинств SICP -- это то, что он рассказывает, как построить "систему искусственного интеллекта" (в данном случае под ней понимается язык программирования высокого уровня) на практически любом Тьюринг-полном субстрате. Но тем более обидно осознавать, что проработать её в полной мере можно исключительно на двух программных системах, одна из которых не поддерживает Windows (MIT, по крайней мере, официально), а вторая вообще заявляет, что не является Scheme.

К тому же, основная сила Scheme в наши дни -- это не сила языка общего назначения ( программы общего назначения тоже получаются отличные, а компания Cisco до сих пор поддерживает собственный оптимизирующий интерпретатор), а возможность встраивания его как языка расширения в практически любой программный продукт, написанный на любом языке. Есть Схемы, работающие на JVM, CLR, Fortran, JavaScript. Схема является языком написания расширений расширения таких проектов как GNU Debugger, GNU GIMP и GNU Guix.

Для заинтересовавшегося программиста логичнее осваивать SICP на той Scheme, которая лучше всего встраивается в ту инфраструктуру, к которой он привык.

На реализацию этой цели и направлен данный SRFI.

Что же делать?

Поскольку автор сих строк всё-таки приобрёл (ложное) ощущение всемогущества, он решил поставить пару бетонных опор для того мостика, о котором говорилось несколькими абзацами выше. Конкретно это выразилось в написании документа Scheme Request For Implementation, под номером 216, в котором собран список требований, которым должен удовлетворять интерпретатор Scheme для того, чтобы на нём запускался полный набор примеров программного кода из SICP.

Конечно, сам факт наличия документа ещё ничего не гарантирует, необходимо, чтобы функционал был реализован в программных системах, однако документ сопровождается "возможной реализацией", которая работает как минимум на одной программной системе, отсутствующей в списке выше (Chibi-Scheme).

Что входит в SRFI-216?

Функционал, требуемый для прохождение SICP, но не общепринятый.

Случайные числа.

Предлагается функция (random x), которая генерирует случайное целое число меньше заданного. В связи с тем, что Схема спроектированна так, чтобы работать в том числе на CPU, не имеющих ни доступа к часам, ни источника энтропии, средства для работы со случайными числами не входят в стандарт R7RS-small. (Но будут входить в -large, вероятно.)

Доступ к дате и времени.

Предлагается функция (runtime), возвращающая значение текущего времени. По причинам, эквивалентным указанным выше, функционал для работы с датой также не входила в базовый стандарт в течение долгого времени, а когда был принят, имена функций не совпадали с таковыми из 1996 года.

Булевы значения.

В связи с тем, что Схема очень старый язык, работа с логическими выражениями была в разных реализациях осуществлена по-разному. Например, в каких-то реализациях символ #f, существует, а в каких-то нет. Также, во некоторых системах, по традиции LISP, пустой список также является "ложным" значением.

Для большей абстракции, таким образом, SICP нигде не использует ложное выражение само по себе, а пользуется переменными/константами true и false, которые гарантированно имеют, соответственно, верное значение, и ложное значение.

Эти две константы также реализуются в данном документе.

Многопоточное программирование.

Вопрос многопоточного программирования был крайне популярен в те годы, когда выпускался из института (десять лет назад), и хотя некоторый прогресс заметен, до сих пор нельзя сказать, что какая-то конкретная модель мультитрединга победила все остальные.

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

SICP, соответственно, требует существование двух примитивов, parallel-execute и test-and-set!, которые ровно эти две концепции и призваны прояснить.

Сама же по себе многопоточная модель Scheme сходна с таковой в Java.

Streams.

"Стримы" -- это бесконечные структуры данных, схожие с генераторами/итераторами в языке Python (или использовавшимся ранее xrange), только несравнимо более гибкие.

В принципе, они реализуемы в текущем стандарте, и не должны бы попадать в данный документ, однако, реализация базового примитива cons-stream, не может быть функцией, потому что не вычисляет свой второй аргумент. Про встроенные механизмы же синтаксического расширения SICP не говорит ничего.

Соответственно, эта структура также реализуется в данном proposal.

Что насчёт графики?

Работа с графикой не затрагивается в данном документе. Возможные примитивы опубликованы в SRFI-203.

Чем я могу помочь?

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

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

Расскажите своим друзьям, студентам и энтузиастам, о том, что учиться по SICP не обязательно должно быть процессом, полным боли.

Если вы преподаёте программирование, или функциональное программирование, или у вас есть знакомые преподаватели, предложите им взглянуть на предлагаемое расширение, их фидбек будет в высшей степени ценным.

Ну, и надо сказать, что я просто считаю Схему отличным языком. Пользуйтесь Схемой, это можно делать на громадном количестве платформ, включая Plan9, Android, WebAssembly, и встраивать в другие программы.

Как именно можно присоединиться к обсуждению, можно найти по ссылке: https://srfi.schemers.org/srfi-216/

Контакты

Если вам показался этот пост полезным, на мои заметки можно подписаться, или задонатить без подписки:

• WordPress https://lockywolf.wordpress.com

• Telegram http://t.me/unobvious

• Web 1.0 https://lockywolf.net

• PayPal https://paypal.me/independentresearch

• LiberaPay https://liberapay.com/independentresearch/donate

SICP

Structure and Interpretation of Computer Programs -- это один из самых известных учебников программирования в мире, на основе которого несколько десятков лет преподавался начальный курс программирования в MIT, а во многих унивеситетах, в том числе в Беркли, преподаётся до сих пор.

SICP использует Scheme в качестве основного (практически единственного) языка программирования. Тем не менее, нельзя сказать, что это учебник Scheme, потому что он выходит далеко за пределы того, что обычно входит в программу "изучения языка". Стоит только упомянуть, что в программу входят системы распространения ограничений, интерпретаторы языков программирования, симуляторы цифровых схем, а также симулятор целого процессорного модуля.

Большая часть тем, входящих в учебник, выполнимы на "стандартной" (в смысле, соответствующего последнему на текущий момент стандарту Revised^7 Report on Algorithmic Language Scheme) Scheme.

Особенные темы

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

Принятая по-умолчанию в учебнике реализация MIT/GNU-Scheme содержит необходимые примитивы, расширяющие базовый язык так, чтобы курс становился проходим.

За многие годы, прошедшие с момента выхода SICP, некоторые реализации Scheme также реализовали многие примитивы, требуемые для прохождения курса.

Однако, до текущего момента не существовало какого-либо нормативного документа, специфицирующего, каким именно требованиям должен удовлетворять интерпретатор, чтобы "поддерживать" прохождение курса.

SRFI

Scheme Requests for Implementation -- это community process, принятый в семействе языков Scheme. В некоторых аспектах он Java Community Process или Python Enhancement Proposals. Так или иначе, это главный инструмент обсуждения развития языкового семейства, а также главный инструмент обеспечения переносимости кода.

Написание SRFI показалось автору сей заметки естественным выбором для формализации требований к программным системам.

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

Функциональная геометрия

Основой главы, посвящённой графической подсистема компьютера, в SICP послужила статься Питера Хендерсона "Функциональная Геометрия". (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.137.1503, https://eprints.soton.ac.uk/257577/1/funcgeo2.pdf)

Знакомым с творчеством Морица Эшера это изображение может показаться смутно знакомым.

В основе техник функциольнальной геометрии лежат две идеи.

• Первая идея в том, что должен существовать некоторый языковой объект painter, который при активации должен рисовать в нужном месте холста (экрана) что-то заданное программистом. (В Scheme painter -- это функция.)

• Вторая идея в том, что нужен какой-то способ комбинировать painter'ы, получая новые painter'ы.

В КДПВ вынесена иллюстрация этого подхода.

Реализация

В предложенном SRFI не предоставленно исчерпывающей реализации метода функциональной геометрии. Однако, предложен субстрат, достаточный для того, чтобы активный студент мог сам реализовать подмножество функциональной геометрии, предложенной в SICP на любом интерпретаторе, поддерживающем SRFI-203 (результат работы автора сей заметки).

Полный текст предложения находится по ссылке:

https://srfi.schemers.org/srfi-203/srfi-203.html

Абстракт и технические детали можно найти здесь:

https://srfi.schemers.org/srfi-203/

SRFI находился на обсуждении два месяца, и за это время было предложено две реализации, для интерпретатора Chibi, и для интерпретатора Kawa.

Заключение

Автор сей заметки (он же автор SRFI) надеется, что предложенное им расширение языка будет позитивно воспринято сообществом. (Те, кто уже сейчас пользуются Scheme, могут предложить поставщикам своего интерпретатора включить это расширение в следующий выпуск.) Автор также надеется, что тем, кто начинает изучать Scheme, SICP или компьютерную графику, данное расширение также поможет сэкономить усилия, затрачиваемые на технические детали, и там самым освободить больше ресурсов для собственно обучения.

Подписка

Те, кому кажется целесообразным выполняемая работа, приглашаются задонатить по PayPal-ссылке. Также все желающие приглашаются подписаться на обновления.

• Telegram :: http://t.me/unobvious

• GitLab :: http://gitlab.com/lockywolf

• Twitter :: https://twitter.com/VANikishkin

• PayPal :: https://paypal.me/independentresearch

Разработка моего статически типизированного скриптового языка Umka вошла в ту стадию, когда потребовалась проверка языковых возможностей на более сложных примерах, чем скрипты в пару десятков строк. Для этого я решил реализовать на своём языке интерпретатор Lisp. На это меня вдохновил педагогический эксперимент Роба Пайка, одного из создателей языка Go. Недавно Пайк опубликовал маленький интерпретатор Lisp на Go. Особенно впечатлило замечание Пайка, что описание интерпретатора заключено на одной странице 13 древнего руководства по Lisp 1.5. Учитывая синтаксическое родство Umka и Go, было трудно не поддаться соблазну построить такой интерпретатор на Umka, но не буквальным переносом кода Пайка, а полностью заново, от основ. Надеюсь, знатоки Lisp и функциональных языков простят мне наивное изумление от соприкосновения с прекрасным.

На непосвящённых Lisp может произвести впечатление, близкое к шоку. Где граница между кодом и данными? Где циклы? Где стек? Единственной структурой данных является дерево. Оно же может представлять список. Оно же становится абстрактным синтаксическим деревом при разборе программы. Оно же заменяет собой стек при вычислении выражений. Любое дерево можно попытаться исполнить как код или использовать как данные. Вместо циклов рекурсия. В ядре языка нет даже арифметики. И тем не менее, это полный по Тьюрингу язык, который можно бесконечно расширять и посыпать синтаксическим сахаром.

Определение минимального интерпретатора Lisp действительно занимает меньше страницы. Конечно, с некоторой натяжкой: в нём используются функции, определённые на нескольких предыдущих страницах. Кажется, создатель Lisp Джон Маккарти из азарта старался превзойти сам себя в лаконизме и в итоге опубликовал микроруководство по Lisp, содержащее определение языка вместе с исходником интерпретатора в общей сложности две журнальные страницы. Правда, добавил в заголовок: "Not the whole truth".

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

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

((label fac (lambda (n) (cond ((eq n 0) 1) ((quote t) (mul n (fac (sub n 1))))))) 6)

В микроруководстве Маккарти этими средствами выражен весь интерпретатор Lisp, за исключением лексического и синтаксического разбора. В руководстве Lisp 1.5 на той самой странице 13 приведён почти такой же интерпретатор, но в более человекочитаемом псевдокоде. Его я и взял за основу своего маленького проекта. Потребовалось лишь добавить разбор текста программы, некое подобие REPL и импровизированную арифметику. Роб Пайк, видимо, поступил так же, но отказался от конструкции label в пользу defn, которая позволила ему не определять функцию заново всякий раз, когда требуется её вызвать. В ядре Lisp такой возможности не предусмотрено.

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

Желающим поиграть с моим интерпретатором и передать по эстафете вдохновение от Роба Пайка рекомендую взять папку с примерами из ветки master, а не из последнего выпуска.

Зрелый язык может использоваться немногими. Но он остаётся частью моей кодовой базы.

Как давнего пользователя (и активного сторонника) Scheme/Common Lisp/Racket, меня иногда спрашивают, почему я предпочитаю их. К счастью, я всегда возглавлял собственные инженерные организации, поэтому мне никогда не приходилось оправдывать это перед руководством. Но есть еще более важная аудитория - мои собственные коллеги-инженеры, которые никогда не имели удовольствия использовать эти языки. Хотя им не требуются оправдания, они все же спрашивают из интеллектуального любопытства, а иногда и из-за удивления, почему я не схожу с ума по поводу следующей крутой функции, которая будет в этом месяце добавлена в Python или Scala, или что бы там ни было в их вкусе.

Хотя фактическая разновидность используемого мной Lisp изменялась (Scheme, Common Lisp, Racket, Lisp-for-Erlang), ядро всегда оставалось неизменным: язык программирования, базирующийся на S-выражениях, динамически типизированный, в основном функциональный, с вызовом по значению и основанный на -исчислении.

Я начал серьёзно программировать в подростковом возрасте на BASIC на ZX Spectrum+, хотя раньше я пробовал писать (вручную) программы на Fortran. Это был определяющий период для меня, поскольку он по-настоящему определил мой карьерный путь. Я очень быстро подошел к пределу языка и пытался писать программы, которые выходили далеко за ограниченные возможности языка и его реализации. Я ненадолго перешел на Паскаль (Turbo Pascal в системе DOS), что некоторое время было забавно, пока я не открыл для себя C в Unix (Santa Cruz Operation Xenix!). Благодаря этому я получил степень бакалавра компьютерных наук, но мне всегда хотелось большей выразительности в моих программах.

Это было, когда я обнаружил функциональное программирование (спасибо IISc!) В Миранде (прекрасной матери уродливого Haskell), и это открыло мне глаза на стремление к красоте в моих программах. Моё представление о выразительности языка программирования стало очень стремительно развиваться. Моя концепция того, как должны выглядеть программы, теперь заключалась в краткости, элегантности и удобочитаемости.

Миранда была не очень быстрым языком, поэтому скорость выполнения была проблемой. Миранда также была статически типизированным языком с выводом типов в стиле Standard-ML. Вначале я был очарован системой типов. Однако со временем я стал её презирать. Хотя это помогло мне уловить несколько вещей во время компиляции, в основном это мешало (подробнее об этом позже).

Примерно через год после этого я закончил изучать языки программирования в Университете Индианы у Дэна Фридмана (известного как Маленький Лиспер / Маленький Схемер). Это было мое знакомство со Scheme и миром Lisp. Я наконец понял, что нашел идеальное средство для выражения своих программ. И ничего не изменилось за последние 25 лет.

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

Давайте разберёмся немного. Я сказал это несколькими абзацами выше:

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

Я собираюсь начать объяснять это - задом наперёд.

Язык, основанный на -исчислении.

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

Возможно, слово "интенсиональность" сбивает с толку. У математики есть два способа думать о функциях. Во-первых, как набор упорядоченных пар: (вход, выход). Хотя это представление - отличный способ доказать теоремы о функциях, оно совершенно бесполезно при кодировании. Это также известно как "экстенсиональный" взгляд на функции.

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

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

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

Языки программирования - это, конечно, практические инструменты, поэтому их ядро должно быть возможно более простым, чтобы соответствовать максимально широким целям. Вот почему я люблю Scheme (и мой нынешний любимый вариант, Racket - CS, как раз для тех, кто заботится о таких вещах). То, что он добавляет к основному -исчислению, - это минимум, необходимый для его использования. Даже когда эти дополнения следуют основным принципам -исчисления, есть несколько сюрпризов.

Это, конечно, означает, что рекурсия - это образ жизни. Если вы один из тех людей, для которых рекурсия никогда не имела смысла, или если вы все еще считаете, что рекурсия неэффективна, то самое время вернуться к ней. Scheme (и Racket) эффективно реализуют рекурсию в виде циклов везде, где это возможно. Более того, этого требует стандарт Scheme.

Эта фича, называемая оптимизацией хвостового вызова (или TCO - tail call optimization), существует уже несколько десятилетий. Это печальный комментарий о состоянии наших языков программирования о том, что ни один из современных языков не поддерживает. Это особенно проблема JVM, поскольку появляются новые языки, пытающиеся использовать JVM в качестве рантайм архитектуры. JVM не поддерживает TCO, и, следовательно, языки, построенные на основе JVM, должны преодолевать препятствия, чтобы обеспечить некоторое подобие иногда применимой TCO. Поэтому я всегда с большим подозрением смотрю на любой функциональный язык, основанный на JVM. По этой же причине я не стал поклонником Clojure.

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

Вызов по значению (Call-By-Value)

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

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

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

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

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

Scheme позволяет вам иметь явную ленивую оценку за счёт использования thunk-ов и мутаций, которые можно удобно абстрагировать, чтобы у вас был call-by-need, когда вам это нужно. Это подводит нас к следующему этапу.

В основном функциональный

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

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

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

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

Я упомянул монады выше, так что неплохо было бы немного поговорить о них, поскольку они являются чисто функциональным способом получения эффектов. Написав о них докторскую диссертацию, я думаю, что имею некоторое представление о них. Мне нравится элегантность и чистая красота оригинальной концепции монад Eugenio Moggi. Идея отделения вычисления от значения, производимого этим вычислением, а затем преобразование этого вычисления в тип, блестящая во всех смыслах этого слова. Это отличный способ математически понять семантику языков программирования.

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

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

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

Это подводит нас к следующему и, возможно, самому противоречивому мнению, которого я придерживаюсь.

Динамически типизированный

В современном мире много говорится о типизированных языках. TypeScript считается спасителем в мире JavaScript. Python и JavaScript осуждают за отсутствие статической типизации. Типы считаются важными для документации и коммуникации в крупных программных проектах. Инженерные менеджеры бросаются к ногам вывода типов, чтобы защититься от посредственных инженеров-программистов, создающих некачественный код.

Есть два типа статической типизации. Статическая типизация в старом стиле используется в C, C++, Java, Fortran, где типы используются компилятором для создания более эффективного кода. Средства проверки типов здесь очень ограничительны, но не претендуют на предоставление каких-либо гарантий помимо базовой проверки типов. Они, по крайней мере, "понимабельны".

Затем появился новый вид статической типизации, уходящий корнями в систему типов Хиндли-Милнера, который породил новое чудовище: вывод типов. Это создаёт иллюзию, что не все типы нужно объявлять. Если вы играете по правилам, вы получите не только преимущества статической типизации старого стиля, но и некоторые новые интересные вещи, такие как полиморфизм. Это взгляд тоже "понимабелен".

Но за последние пару десятилетий это приобрело новое значение: статическая типизация - это форма проверки ошибок во время компиляции, поэтому она поможет вам создавать более качественный код. Это как если бы статическая типизация - это волшебное средство доказательства теорем, которое проверит некоторые глубокие свойства вашей программы. Это то, что я называю чушью. У меня никогда не было средства проверки статического типа (независимо от того, насколько оно сложное), которое помогло бы мне предотвратить что-либо, кроме очевидной ошибки (которая в любом случае должна быть обнаружена при тестировании).

Однако то, что делают средства проверки статического типа, мешает мне. Всегда. Безошибочно. Как программист, я все время ношу в голове инварианты (причудливое название для свойств вещей в моей программе). Только один из этих инвариантов - это его тип. Иметь инструмент, который может проверить инвариант - это круто, когда вы впервые с ним сталкиваетесь (как я делал с Мирандой).

Но это тупой инструмент. Он может не так много. Итак, теперь у вас есть искусственные правила о том, как удовлетворить этот инструмент. А то, что я знаю, что делать совершенно нормально (и могу оправдать или даже формально доказать для моих вариантов использования), внезапно перестает работать. Итак, теперь я должен изменить свою программу, чтобы удовлетворить потребности ограниченного инструмента. Большинство людей вполне довольны этим компромиссом, и они постепенно меняют свое отношение к программному обеспечению, чтобы соответствовать его ограничениям.

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

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

Все программы (статически типизированные или другие) должны иметь дело с исключениями времени выполнения. Хорошо написанные программы сталкиваются с меньшим числом таких, плохо написанные - с большим. статические тайпчекеры перемещают некоторые программы из лагеря плохо написанных в лагерь с хорошо написанными. Что улучшает (и гарантирует) качество программного обеспечения, так это тщательное тестирование. Другого решения для поставки высококачественного программного обеспечения нет. Независимо от того, используете вы статическую типизацию или нет, это лишь незначительно влияет на качество вашего программного обеспечения. Даже этот эффект исчезает, когда у вас есть хорошо разработанные программы, написанные вдумчивыми программистами.

Другими словами, статическая типизация бессмысленна. Он, возможно, имеет некоторую документальную ценность, но не заменяет документацию по другим инвариантам. Например, ваш инвариант может заключаться в том, что вы ожидаете монотонно увеличивающийся массив чисел со средним значением такого-то и такого-то и такого-то стандартного отклонения. Лучшее, что вам может сделать любая проверка статического типа, - это array[float]. Остальная часть вашего инварианта должна быть выражена словами, описывающими функцию. Так зачем подвергать себя страданиям array[float]?

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

Но, как и все остальное, иногда нужно знать типы статически. Например, я много работаю с изображениями, и мне полезно знать, что они представляют собой array[byte], и у меня есть операции, которые будут работать с ними магически быстро. Scheme/Lisp/Racket - все они предоставляют способы сделать это, когда вам это нужно. В Scheme это зависит от реализации, но Racket поставляется с вариантом Typed Racket, который можно смешивать с динамически типизированным вариантом. Common Lisp позволяет объявлять типы в определённых контекстах, в первую очередь для компилятора, чтобы реализовать оптимизацию там, где это возможно.

Итак, опять же, Scheme/Lisp/Racket дают мне преимущества типов, когда они мне нужны, но не навязывают мне ограничения повсюду. Это лучшее из обоих миров.

Базирующийся на S-выражениях

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

Нет никаких инфиксных операций, никакого приоритета операторов, никакой ассоциативности, никаких ложных разделителей, никаких висячих else, ничего. Все функции являются префиксными, поэтому вместо того, чтобы говорить (a + b), вы должны сказать (+ a b), что дополнительно позволяет гибко сказать такие вещи, как (+ a b c). + - это просто имя функции, которую вы можете переопределить, если захотите.

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

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

Самым большим преимуществом этого синтаксиса является минимализм форм: вам не нужны ложные синтаксические конструкции для передачи концепций. Концепции полностью передаются с помощью имен функций или используемых синтаксических ключевых слов. Это производит странно компактный код. Не всегда компактный с точки зрения количества букв, но компактный с точки зрения количества понятий, которые необходимо учитывать при чтении кода.

Это еще даже не половина дела. Если ваши программы представляют собой деревья, вы можете писать программы для манипуляции этими деревьями. Лисперы (а также схемеры и, гхм, рэкетиры, т.е. Racketeers) называют эти вещи макросами или синтаксическими расширениями. Другими словами, вы можете расширить синтаксис своего языка, чтобы ввести новые абстракции.

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

Вывод

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

Вот почему я все еще использую Scheme/Racket/Lisp и, вероятно, буду использовать его до конца своей жизни. Использую ли я другие языки? Конечно, их много. Но никакой из них не сравнится с этим. Особенно новые. Похоже, что изобретение новых языков - это упражнение, через которое проходит каждое новое поколение плохо информированных инженеров-программистов, когда старые языки намного лучше, чем все, что они могли придумать даже во сне (я представляю вам Ruby, который, хотя номинально имеет свои корни в Лисп, напрашивается вопрос: почему вы просто не использовали сам Лисп).

Как и у всякого предубеждения, у моего тоже есть недостатки. Примерно 15 лет назад все сторонние SDK были написаны полностью на C/C ++, которые могли легко взаимодействовать с Lisp. Появление Java создало этому препятствие, поскольку JVM плохо взаимодействует со Scheme/Lisp/Racket. Это усложняло включение сторонних библиотек в мои программы без выполнения большого количества работы.

Ещё один недостаток заключается в том, что с появлением API в Интернете большинство вендоров выпускают библиотеки на распространённых в Интернете языках (Java, Ruby, Python, JavaScript, а в последнее время - Go и Rust), но никогда в Scheme/Lisp/Racket, если только это не вклад сообщества, которое также редко использует и C/C++. Это часто оставляет меня в положении, когда мне приходится самому создавать уровень API, что, конечно, не очень практично. Racket (мой нынешний фаворит) имеет довольно активное сообщество, которое вносит свой вклад в большие дела, но обычно оно немного отстает от времени, а когда дело доходит до новейших вещей, я часто остаюсь с тем что есть. Возможно, это основная причина, по которой я буду использовать Clojure в будущем, но это еще предстоит выяснить.

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

И, наконец, проблема производительности. Во-первых, давайте развеем распространённое заблуждение: Лисп не является интерпретируемым языком. Он не медленный, и все реализации имеют множество рычагов для настройки производительности большинства программ. В некоторых случаях программам может потребоваться помощь более быстрых языков, таких как C и C++, поскольку они ближе к оборудованию, но с более быстрым оборудованием даже эта разница становится несущественной. Эти языки являются прекрасным выбором для production-quality кода и, вероятно, более стабильны, чем большинство других вариантов, благодаря десятилетиям работы над ними.

Я признаю, что изучение Scheme/Lisp/Racket немного сложнее, чем изучение Python (но намного проще, чем изучение Java/JavaScript). Однако, если вы это сделаете, вы станете гораздо лучшим программистом и научитесь ценить красоту этих языков так, что ничего другого будет недостаточно.

Anurag Mendhekar (Tech Entrepreneur and Software Artist)

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

Позвольте мне начать с пары слов для тех кто не в курсе. Lisp - это семейство языков, включая Common Lisp, Emacs Lisp и несколько диалектов, которые сегодня используются лишь изредка. Иногда даже язык Scheme считается членом этого семейства. Считать ли это верным, зависит от того, каково ваше точное определение Lisp, но это является слишком сложным (и неинтересным) вопросом для этого эссе.

В основном я буду использовать Lisp для обозначения Common Lisp, а иногда, когда это удобно, также буду включать Emacs Lisp. Lisp существует уже давно, хотя он был значительно преобразован с момента своего изобретения (некоторые говорят, что он был открыт). Сегодня это современный, мультипарадигменный язык, который обладает, пожалуй, самыми сложными фичами из всех используемых языков общего назначения (объектная система CLOS, языковые макросы, специальные макросы чтения, система условий и рестартов и т. д.).

Первый вопрос, который часто задают: Если Lisp настолько хорош, почему он не популярен?. Люди, которые задают такой вопрос, обычно предполагают, что хороший подразумевает популярный, и поэтому ищут какую-то часть Lisp, которая НЕ является хорошей, что могло бы объяснить, почему он не популярен. Однако нет абсолютно никаких оснований предполагать, что хороший подразумевает популярный, поэтому вопрос действительно довольно наивный. Но вместо того, чтобы просто игнорировать этот вопрос в некоторых частях этого эссе, я на мгновение приму его за чистую монету и попытаюсь объяснить, почему Lisp не так популярен, как хотели бы некоторые его последователи.

Однако позвольте мне сделать небольшое замечание. Lisp не настолько непопулярный, как можно думать (и теперь для удобства я добавлю Emacs Lisp). В недавнем подсчете количества строк Lisp занял 4-е место по количеству строк исходного кода (SLOC) в дистрибутиве Debian GNU/Linux (Woody) после C, C++ и bash с примерно 4 миллионами SLOC (около 4%), опередив Perl, Python, ML, Fortran и т. д. Это довольно популярный язык, лишь несколько менее популярный, чем C и C++. Конечно, количество SLOC в Debian GNU/Linux - не единственный возможный показатель популярности, но это показатель, как и любой другой.

Недавно я увидел статью в comp.lang.lisp, в которой автор серьезно знал, что с Lisp должно быть что-то не так, потому что, если все будет хорошо, рынок обнаружит это, и Lisp начнет использоваться в программных проектах повсюду. Тот факт, что этого не произошло, доказал автору, что с Лиспом ДОЛЖНО быть что-то не так, даже если он не знал, что именно.

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

Возможно, в Lisp действительно что-то не так, потому что он, кажется, привлекает всевозможных психов, хотя, возможно, я просто не знаю, что это так и для других языков, или для любого другого человеческого артефакта. Обычно это проявляется в случае с Лиспом так: кто-то, плохо знакомый с Лиспом, впервые появляется в группе новостей comp.lang.lisp, дает очень умным и очень знающим людям урок о том, что они не поняли, почему Lisp непопулярен, и продолжает рассказывать им, как им следует изменить язык, чтобы исправить проблему (обычно, изменить синтаксис, чтобы избавиться от множества скобок), или просто сообщить им, что они сделали ошибку, и вместо этого следует использовать другой язык.

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

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

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

Я часто вижу очень показательную параллель, проводимую между Лиспом и хорошей скрипкой. Должны ли мы изменять скрипки, чтобы привлечь людей, которые привыкли играть на аккордеоне и не хотят учиться игре на скрипке, потому что это слишком сложно и слишком отличается от аккордеона? Конечно, нет! У скрипки есть свое место, и она становится прекрасным инструментом, когда играет тот, кто действительно владеет ею.

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

Некоторые люди думают, что с Лиспом что-то не так, потому что практически невозможно заставить программное обеспечение работать без изменений на всех платформах (комбинациях Лисп-систем и операционных систем), тогда как с чем-то вроде Python или Ruby это легко. Ясно же, что здесь с Лиспом что-то не так, верно?

Нет, на самом деле нет! Lisp - это не отдельная реализация, а ANSI-стандарт (теперь уже Common Lisp). Как и многие другие стандарты (например, ANSI-стандарт для языка программирования Си), он не содержит всего, что вам может понадобиться при написании приложений, например сокетов, синтаксических анализаторов XML, библиотек SQL и т. д. Вместо этого предоставляются отдельные библиотеки, которые в случае Lisp либо поставляются поставщиком коммерческой системы Lisp, либо бесплатно авторами свободных библиотек для других разработчиков. Таким образом, предполагаемая трудность состоит в том, чтобы написать приложение, которое могло бы работать со всеми этими, возможно, взаимно несовместимыми библиотеками. Разработчик, столкнувшийся с этой проблемой, обычно очень расстраивается, жалуется в comp.lang.lisp, что мы должны исправить стандарт ANSI Common Lisp как можно скорее, чтобы включить эти библиотеки.

Подождите секунду! Почему это не проблема для таких языков, как Python и Ruby, которые даже НЕ ИМЕЮТ стандарта ANSI? Почему люди не жалуются громко, что они даже не могут написать кросс-платформенный цикл или оператор присваивания на Python, потому что способ сделать это не стандартизирован? Ответ: потому что эти люди сравнивают яблоки и апельсины или, в данном случае, язык, определяемый (в основном) одной реализацией, и стандарт с несколькими реализациями. Вот как увидеть, насколько это сравнение абсурдно: если бы я написал новую реализацию Python, в которой не было бы сокетов, разве это внезапно ухудшило бы положение языка Python, в сравнении с тем, что было раньше? Конечно, нет! Точно так же люди, которые хотят использовать язык с единственной реализацией и тем самым рискуют, что язык может измениться в одночасье, что, возможно, сделает большую часть некоторых крупных инвестиций устаревшими, должны принять то же самое с Lisp и выбрать единственную реализацию. который работает во всех операционных системах. Это будет не хуже, чем у любого языка с одной реализацией.

Некоторые ВНУТРИ Lisp-сообщества думают, что Lisp не так популярен, как он того заслуживает, потому что в языке есть недостатки. Таким образом, предполагаемое решение проблемы состоит в создании лучшего диалекта Lisp. Откровенно говоря, если бы это было правдой, то ни у одного другого языка не было бы ни единого последователя, учитывая количество недостатков в других языках по сравнению с недостатками Common Lisp. Одной из типичных попыток создать лучший Lisp был Dylan (больше похожий на Scheme, чем на Lisp, на самом деле), который определяет синтаксис без скобок для Lisp-подобного языка, тем самым по существу лишая Lisp одного из его, пожалуй, величайших преимуществ, а именно почти однозначного соответствия между внешним синтаксисом и внутренним представлением кода, что является важной фичей для создания макросов. А Dylan не более популярен, чем Common Lisp.

В последнее время мы регулярно видим людей (обычно также в сообществе Lisp), у которых есть идеальное объяснение того, почему Lisp не так популярен, как он того заслуживает, а именно, что нет ни одной бесплатной реализации, которая работала бы во всех операционных системах и в которой были бы ВСЕ необходимые библиотеки, как в Python и Ruby для веб-программирования и т. д. (мы уже видели, что в стандарте ANSI Common Lisp их нет). Типичная статья одного из этих людей очень снисходительна. Недавно я видел фразы, похожие на Простите, ребята, но интерфейсы командной строки больше не подходят, в наши дни все основано на графическом интерфейсе, а у вас даже нет стандартной библиотеки графического интерфейса.

Общий тон, кажется, обвиняет некоторое вымышленное сообщество Lisp в том, что оно не понимает, что именно требуется Lisp с точки зрения библиотек, чтобы стать более популярным. Я согласен, что они правы, что на данный момент нет достаточно хороших библиотек для всех применений. Однако я серьезно сомневаюсь, что решение этой проблемы каким-либо образом повлияет на популярность Lisp. Хуже того, я не понимаю, кому адресованы эти статьи. Некоторые из них, без сомнения, предназначены только для того, чтобы автор отказался от Lisp в пользу более популярного языка, делая это с чистой совестью (это не моя вина, я должен был сделать это, потому что не смог получить нужные мне библиотеки. ). Все они определенно имеют негативный эффект (желаемый или нежелательный) на людей, которые могут рассматривать использование Lisp. Для людей, которые не знают Lisp и НЕ рассматривают возможность его использования, они определенно не имеют абсолютно никакого эффекта.

Большинство авторов этих статей, кажется, серьезно думают, что каким-то образом они будут серьезно восприняты участниками Lisp-сообщества, и что эти участники осознают свои ошибки и начнут предоставлять высококачественные библиотеки для веб-программирования и синтаксического анализа XML бесплатно и сразу. Я не думаю, что это случится. Чтобы понять, почему, мы можем (для этой цели) разделить членов "сообщества Lisp" на три типа людей:
- тех, кто уже тратит значительную энергию и время на написание таких библиотек,
- тех, кто не имеет возможности писать такие библиотеки. (из-за недостатка знаний, энергии или времени), и
- тех, у кого есть возможность сделать это, но они не делают этого.

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

Люди из второй категории не собираются вдруг начать писать нужные библиотеки.

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

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

Этот пост представляет собой перевод анонса Международной Научно-Прикладной конференции Scheme Workshop 2021.

Для тех, кто не ходит под кат:

• Тема конференции -- Lisp, Scheme, Emacs, и другие родственные языки, а также преподавание программирования.

• Приём и рецензирование докладов продлится до 26 июня.

• Сама конференция состоится 27 августа 2021 года, одновременно с Международной Конференцией по Функциональному Программированию.

• Допускаются как научные доклады, так и практические отчёты, и обзоры.

Перевод анонса. (Call for Papers)

Объявлена подача заявок на Международную Конференцию по Функциональному Программированию и Языку Scheme.

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

Конкретные темы включают (но не ограничиваются):

• Взаимодествие с разработчиком: среды разработки, отладка, тестирование и рефакторинг

• Реализация: интерпретаторы, компиляторы, инструменты, сборка мусора, профилирование и бенчмарки

• Средства расширения: макросы и их гигиена, доменно-специфичные языки, рефлекшен и то, как расширения влияют на взаимодействие системы с программистом

• Средства языковой выразительности: средства управления, модуляризация, свободный и параметрический полиморфизмы, типы, аспекты, модели владения, параллелизация, распределённые вычисления, недетерминированные вычисления, вероятностное программирование, и иные парадигмы программирования

• Интеграция: сборочный инструментарий, развётывание, взаимодействие с другими языками и системами

• Формальная семантика: теория, анализ и преобразования, частичное выполнение

• Человеческий фактор: прошлое, настоящее и будущее, история, эволюция и социология языка, его стандартов и диалектов

• Образование: подходы, отчёты и программы

• Приложения: промышленные приложения

• Искусство программирования: элегантные и педагогичные примеры применения Scheme

Даты:

• Финальная дата подачи докладов 26 июня 2021.

• Авторы будут уведомлены о прохождении рецензирования 12 июля 2021.

• Финальные версии докладов (после рецензирования), должны быть предоставлены 21 июля 2021.

• Конференция будет проводиться онлайн, 27 августа 2021.

Все даты указаны в часовом поясе (23:59 UTC-12) "в любой точке планеты".

Подача докладов

Доклады должны использовать формат acmart, подформат sigplan. Подача осуществляется в PDF, допускающем печать в чёрно-белом формате на бумаге US Letter. Шаблоны для Microsoft Word и LaTeX доступны по адресу:

http://www.sigplan.org/Resources/Author/

Этот формат согласуется с прочими ACM-конференциями, включая ICFP, которая проходит одновременно со Scheme Workshop. Рекомендуется при подаче заявки включить опцию "review", это позволят нумеровать строки автоматически и упрощает рецензирование.

Приветствуются любые виды докладов, включая традиционные статьи, технические отчёты, и блиц-доклады. Статьи и отчёты обычно занимают 10-24 страницы "нового" ACM SIGPLAN, свёрстанного в одну колонку. (Для сравнения, это примерно 5-12 страниц "старого", двухколоночного ACM SIGPLAN 9pt). Анонсы блиц-докладов ограничены в объёме 192 словами. На каждую статью и отчёт выделяется 25 минут, включая вопросы докладчику. На каждый блиц-доклад выделяется 5 минут, а также 5 минут на вопросы докладчику.

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

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

Труды конференции будут опубликованы в формате "Технический Отчёт" Северо-Восточного Университета (США, NorthEastern University), а также на сервере препринтов arXiv.org.

Презентация доклада на конференции не ставит себе целью заменить публикацию статьи (усовершенствованной редакции) в научном журнале или научной конференции более высокого уровня.

Процесс рецензирования

На конференции Scheme 2021 будет применяться метод lightweight-double-blind (облегчённого двойного слепого) рецензирования. Поданные доклады не должны включать имена авторов и учреждений, и должны ссылаться на иные работы в третьем лице. (То есть, не "мы используем наш предыдущий результат...", а "мы пользуемся результатами, опубликованными Х")

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

Форматирование

Статьи и отчёты должны использовать формат "acmart" с опцией "sigplan". Блиц-доклады могут быть поданы в формате обычного текста, либо как PDF-файл. Рекомендуется также использовать опции "anonymous" и "review", эти опции автоматически скрывают имя автора и включают нумерацию строк для упрощения рецензирования.

Ссылка на интерфейс подачи заявки

Будет опубликована ближе к дате подачи заявки