А просто надо использовать шапку:

(format nil "~{~A~^, ~}" (list 1 2 3 ))
"1, 2, 3"

Вуаля!

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

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

У меня плохие новости для верящих в данный маркетологический прогон.

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

Как ИИ на выдаче в поисковике паразитирует на том, что собирали и писали живые профессиональные люди на разных ресурсах, таким образом обкрадывая целые издательские дома, точно так же в изо и музыке ИИ тупо паразитирует на всем наследии творческого человечества. А оно — конечно.

Ведь вы не задумываетесь о том, что музыка имеет очень жесткие законы, в том числе физические и математические, и все они исследованы до последнего герца (440 Hz — нота «ля»).

Законы квинто-квартового круга, из которого не вырваться. Тон-тон, полутон, три тона-полутон. Кто учил, тот в курсе. Ведь наш гений не зря писал: «поверил алгеброй гармонию». Вариантов гармонических последовательностей настолько мало, что на самые популярные из них, скажем, в интервалах IV–I-II–V, написаны сотни произведений, начиная с «Канона ре мажор» Иоганна Пахельбеля до «Гимна Советского Союза» и Let it Be группы Beatles. Aerosmith с Green Day не упоминать. Четвертая-первая-вторая минор-пятая. Уныло до невозможности. Бесконечные G — D — Em — C. Но есть нюансы.

Мощный ИИ напишет вам еще тысячу песенок на IV–I-II–V. И он будет собирать мозаику из аранжировок, звучаний, обрывков мелодий, существующих записанных человеческих голосов, безусловно ограниченных тюремными законами гармонии, и создаст еще одну тонну мусора. Две тонны. То есть он делает то, что малоталантливые живые авторы делали все эти годы — строго в соответствии с законами музтеории и музпрактики, плюс мода, плюс конъюнктура, плюс жрать хочется. Просто ИИ может сделать это быстро и много.

Собственно — последнее «Евровидение» всё звучало, как продукт ИИ. Симпатичная, правильная полная бессмыслица.

Любой дурак сыграет в подворотне IV–I-II–V в той или иной тональности. Но только у Пола Маккартни получилась Let It Be. А у Александрова — «Союз нерушимый».

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

А у цифирок с душой напряженка.

А ведь живые люди уже переступили строгие законы квинто-квартового круга и создали новые — Венская школа с Шенбергом расправилась с законами, по которым писал Моцарт, и открыла врата Густаву Хольсту, а тот — Black Sabbath и так до полной деконструкции и мелодии, и гармонии, но тоже в новых, очень строгих рамках.

Всё уже написано и записано человечеством. А кого и это не устраивало — тот Карлхайнц Штокхаузен с Джоном Кейджем. Зато на них выросли все «Крафтверки» Германии и вся электронщина мира.

И на всем этом тоже вынужден паразитировать бездушный ИИ. Прекрасный пример — недавний хайп стопроцентной ИИ-группы Velvet Sundown на Spotify. Причем только человеку без ушей и без музыкальной памяти непонятно, что это ИИ.

Как отличить фальшивые надувные шарики? А они точно такие же, только не радуют.

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

Но потом начнется самое интересное: он, ИИ, переварит все то, что сделано людьми, а потом ему придется переваривать уже то, что создано ИИ.

И по всем природным законам — продукт пищеварения, еще раз переваренный, остается все той же субстанцией.

И поэтому так воняет за километр от «художественного творчества» ИИ. Он вынужден переваривать то, что уже придумано людьми за всю историю художественного творчества. А придумано человеком уже буквально всё, что можно изобразить при помощи материалов — осталась одна Марина Абрамович. Да и та скисла, старушка. Провокаторов и без нее хватает.

С каким-то дикарским восторгом в рамках строгого карго-культа неофиты от нейронок ходят буквально под себя, когда им удается получить смешную картинку Йоды в стиле ван Гога. Или «оживить» картину Васнецова. Да, печальный факт — люди знают обычно всего два-три имени и три-четыре стиля и в рамках своих знаний «творят» при помощи нейронок. Насытившись «приколами», начинают генерить портреты шестипалого себя «в стиле».

И это невозможно видеть глазами. Они кровоточат.

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

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

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

Придумано всё. Буквально.

Потому что у изобразительного искусства все те же строгие законы. Все цветовые закономерности исследованы до последнего пантона, все формы и антиформы уже создали Ван Дейк с Джексоном Поллоком (и сто тыщ авторов между ними). А искусство еще живо — хотя бы потому, что есть руки, голова и магия материала.

ИИ лишен рук, материала — красок, кистей или просто ведра для разливания пигмента по холсту, как у Поллока. А фактура, отражение света и даже запах краски — это все составляющие, без которых изображение становится репродукцией в журнале «Огонек».

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

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

Потому что все происходит быстро. Очень быстро. В гигантских объемах. И формальное развитие идет очень быстро. Только развиваться некуда.

Ну хорошо, посчитаете себя остроумным, напишете ИИ промпт: «Нарисуй заседание центробанка в стиле Мэн Рэя и Караваджо одновременно». Вау, как смело.

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

Потому что было уже всё. Стоило Малевичу намалевать черный квадрат, как обязательно найдется какой-нибудь Марк Ротко, который нарисует черных, красных и синих прямоугольников штук тридцать и будет продаваться за миллионы и висеть в музеях. Не потому, что публика — дура. А потому, что старик Ротко тоже вложил что-то в идиотский черный квадрат. Наверное, это называется «человеческая душа».

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

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

— А-а-а! — кричат они — Вышла новая версия Reve 1.0 — вы только посмотрите-посмотрите, вы еще быстрее сделаете видео со старухой и бегемотом и порвете видеоплатформы на миллионы просмотров!

— Или вот! — Новая эра создания видео и игры Genie — всего за 200 долларов подписки! О-о-о!

Причем с таким видом, как будто все приблуды внутри нейронки разработали они лично, а не анонимные индусы из Кремниевой долины. Как шаманы. Помните, как быстро появились «евангелисты» какого-нибудь «Клабхауса» или НФТ — и куда они все делись?

Так и здесь — восторг от того, что можно вспомнить самую тупую шутку и сгенерить на нее видео с участием модного реального актера из «Марвела». Эта мысль приводит публику в состояние исступления. И публика платит. Надеется порвать интернет и наконец стать хозяином востребованного контента.

Срочно бежим на VEO-3! И будет нам счастье и деньги. Завтра выйдет еще пять инструментов, которые для профессиональной работы пригодны так же, как айфон для свадебной фотографии. А со всех сторон несется — «промпт тебе напишет Чат ДжиПи-Ти — даже не надо думать самому, потом заваливаешь в Мидджорни, а потом в ВЕО ТРИ!».

Дерзай, вперед! Две старухи на самокате! Уморительно смешно! Естественно, стоит увеличить результат «творчества» хотя бы до размеров ноутбучного монитора, то качество картинки посыплется сразу — видно, что это все отвратный ИИ.

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

Это как со смартфонами — у всех есть камеры, кругом миллиарды камер, но когда что-нибудь случается — отовсюду нам показывают только мутные видео и бегущие ноги, и даже простые фотки — абсолютно нечитаемые. Даже неподвижный вулкан со столбом пламени внятно снять никто не может. Так и ИИ-видео — только для заработков единиц на очередном «тубе» или тиктоке, пока миллионы чайников платят за подписки на эти инструменты.

Революция отменяется. Без души ничего не работает.

Это Kensington Expert Mouse Trackball. Все в нем замечательно, но со временем появилась проблема — стал останавливаться курсор мыши. Крутишь шар, а мышка на экране не движется. Лечится перетыканием USB разъема.

Честно говоря, думал деградация электроники. При этом я трекбол регулярно чистил, разумеется, но только снаружи.

Естественно, что я такой был не один. На Reddit'е народ жалуется, производителю пишут, на Амазон возвращают.

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

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

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

И, о чудо!, устройство перестало терять курсор. Даже, кажется, быстрее работать стало!

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

Век живи, век учись...

Копия моей статьи 2018 года. В принципе, актуальности не потеряла.

О чем это вообще?

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

Сложности начинаются тогда, когда приходится отображать функциональный подход на императивный. Так, если есть необходимость организовать компиляцию из функционального языка в императивный, например ML в Java или JavaScript.

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

Что сложного то?

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

Перейдем к кошкам примеру.

Есть функция for():

// Flow9
for (init, predicate, fn) {
    if (predicate(init))
        for (fn(init), predicate, fn)
    else init
}

Транслятор переведет ее в Java или JavaScript один в один, никакой магии (приведен код на Javacript):

// JavaScript
function for__(init, predicate, fn) {
        if (predicate(init)) {
            return for__(fn(init), predicate, fn);
        } else {
            return init;
        }
    }
}

Она даже синтаксически будет выглядеть практически также.

Разумеется, на той же Java эту функцию вполне можно заменить обычным циклом. Но мы же в трансляторе это делаем, нам нужен автоматический перевод, верно?

Поэтому мы получим рекурсивный вызов. Ну и следом во время выполнения получим исчерпание стека вызовов.

Что делать? Спасите, помогите!

Чтобы исправить ситуацию и как-то заставить это работать, разработана техника, позволяющая экономить место в стеке вызовов или избавиться от рекурсивных вызовов вообще.

Мы модифицируем функции таким образом, чтобы изменить рекурсивный вызов на цикл. Это возможно, но, к сожалению, заменить можно не все рекурсивные вызовы. Так, чтобы вызов функции можно было заменить на итерацию цикла, нужно соблюсти несколько условий:

1. вызов функции должен быть последним в последовательности операций;
2. это должен быть именно рекурсивное обращение к функции, без каких-либо дополнительный операций (например, в вычислении факториала, куда уж без него! , выражение n*fac (n-1) нельзя автоматически заменить на циклический вызов);
3. вызов функции не может быть вложен в замыкание, т. е. в случае с for() конструкция for(..., \x->for()..., ...) не будет заменена на циклическую.

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

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

Есть масса способов это сделать, на просторах Интернета можно найти разные решения.

Я покажу два решения, которые успешно применяются в трансляторах.

Решение первое

Функция предварительно готовится с помощью вспомогательной операции:

// JavaScript
function TCO(fn, fn_name) {
    var top_args;
    window[fn_name] = function() {
        var result, old_top_args = top_args;
        top_args = arguments;
        while (top_args !== null) {
            var cur_args = top_args;
            top_args = null;
            result = fn.apply(null, cur_args);
        }
        top_args = old_top_args;
        return result;
    };
    window['tc_' + fn_name] = function() {
        top_args = arguments;
    };
}

TCO((init, predicate, fn) => {
    if (predicate(init)) {
        return tc_for__(fn(init), predicate, fn);
    } else {
        return init;
    }
}, 'for__');

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

Метод работает безупречно, правда медленно. Виной тому использование метода не самого быстрого метода fn.apply(). В Java используется рефлексия, которая тоже дает падение производительности.

Этих недостатков лишен второй метод.

Решение второе

Поскольку речь идет о внутренностях транслятора, мы многое знаем о модифицируемой функции. Создадим явный цикл и будем самостоятельно заниматься модификацией аргументов.

// JavaScript
function for__(init, predicate, fn) {
    T: while (true) {
        if (predicate(init)) {
            let $a_ = fn(init);
            let $b_ = predicate;
            let $c_ = fn;
            init = $a_;
            predicate = $b_;
            fn = $c_;
            continue T
        } else {
            return init;
        }
    }
}

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

Очевидную оптимизацию с неизменяемыми аргументами (см. $b_ = predicate;) оставлю пытливому читателю для самостоятельного изучения.

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

Неожиданная проблема

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

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

// Flow9
main() {
    recursiveFn(1,  \res -> println("Внешний вызов. Результат = " + int2str(res)));
}

recursiveFn(counter : int, onOK : (int) -> void) -> void {
        println("Шапка recursiveFn. Counter = " + int2str(counter));

        if (counter > 1) {
                println("Первая ветка recursiveFn. Counter = " + int2str(counter));
                onOK(counter)
        } else {
                println("Вторая ветка recursiveFn. Counter = " + int2str(counter));
                recursiveFn(counter + 1, \newCount -> {
                        println("Внутренний вызов. newCounter = " + int2str(newCount));
                        onOK(newCount);
                });
        }
}

Ключевой момент — вызов функции onOK после println("Внутренний вызов. newCounter = " + int2str(newCount)).

Если мы, что называется, в лоб, преобразуем функцию в JavaScript, результатом будет бесконечная рекурсия.

// JavaScript
function main() {
    return recursiveFn(1, ((res) => {
        return println(("Внешний вызов. Результат = " + int2str(res)));
    }));
}

function recursiveFn(counter, onOK) {
    T: while (true) {
        println(("Шапка recursiveFn. Counter = " + int2str(counter)));
        if ((counter > 1)) {
            println(("Первая ветка recursiveFn. Counter = " + int2str(counter)));
            return onOK(counter);
        } else {
            println(("Вторая ветка recursiveFn. Counter = " + int2str(counter)));

            let $a_ = ((counter + 1) | 0);
            let $b_ = ((newCount) => {
                println(("Внутренний вызов. newCounter = " + int2str(newCount)));
                return onOK(newCount);
            });
            counter = $a_;
            onOK = $b_;
            continue T
        }
    }
}

Неважно что будет стоять после строки println(("Внутренний вызов. newCounter = " + int2str(newCount))), onOK или $b_. Мы получим бесконечную рекурсию из-за того, что замыкание использует внешнее значение функционального параметра onOK.

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

// JavaScript
function main() {
    return recursiveFn(1, ((res) => {
        return println(("Внешний вызов. Результат = " + int2str(res)));
    }));
}

function recursiveFn(counter, onOK) {
    T: while (true) {
        println(("Шапка recursiveFn. Counter = " + int2str(counter)));
        if ((counter > 1)) {
            println(("Первая ветка recursiveFn. Counter = " + int2str(counter)));
            return onOK(counter);
        } else {
            println(("Вторая ветка recursiveFn. Counter = " + int2str(counter)));

            let $_ta = onOK;
            let $a_ = ((counter + 1) | 0);
            let $b_ = ((newCount) => {
                println(("Внутренний вызов. newCounter = " + int2str(newCount)));
                return $_ta(newCount);
            });
            counter = $a_;
            onOK = $b_;
            continue T
        }
    }
}

Внимание следует обратить на переменную $_ta, которая уже внутри замыкания используется вместо onOK.

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

Этот метод трансляции работает корректно и уже используется в боевых системах.

И что, вот так вот и работает?

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

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

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

Историческая справка

4 октября 1957 году Советский Союз запустил в космос первый искусственный спутник земли, а затем 3 ноября 1957 года — второй спутник. Это были события поистине планетарного масштаба! Победа советской научной и технической мысли, результат титанических усилий тысяч ученых и инженеров. Мы по праву гордимся этим достижением и по сей день.

У конкурирующей же стороны, американцев, еще не было своих спутников (появятся позже), они очень внимательно следили за советскими. Научное сообщество всего мира собирало данные о полете спутников, проводило расчеты и пыталось предсказывать траекторию движения, параллельно подстраивая расчетные методики. Помимо расчета положения спутника (расчета эфемерид и других данных полета), ученые проводили изучение ионосферы Земли, поскольку данные передатчиков, излучающих знаменитое «Бип! Бип!» были известны. На основе наблюдений и расчетов было сделано много научных открытий.

Занималась этим и Смитсоновская астрофизическая обсерватория, где работал Чарльз Мур, позднее ставший создателем языка Форт.

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

На странице 30 отчета (страница 175 в PDF) приведена статья «Predictions for Photographic Satellite Tracking Stations — APO Ephemeris 4» за авторством Чарльза Мура (физика-ассистента) и Дона Лаутмана (математика). В этой статье описывается программа Ephemeris 4 для компьютера IBM EDPM 704, предсказывающая положение спутника для использования следящими станциями.

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

Как позже сам Мур напишет в статье The Evolution of Forth, чтобы избежать постоянной перекомпиляции исходных текстов программы, он реализовал простой интерпретатор, читающий входные данные с карт. Это позволило компоновать уравнения для разных спутников без повторной компиляции.

Интерпретатор предоставлял несколько команд и концепций, перекочевавших в современные реализации Форта. Использовалась команда чтения «слов», разделенных пробелами, команда преобразования чисел из внешнего во внутреннее представление (по всей видимости имеется ввиду лексический разбор — прим. авт.), а также конструкт IF ... ELSE ....

Мур обнаружил, что свободное форматирование кода может быть и более эффективным (код меньше и производительнее), и более надежным в сравнении с распространенным в то время колоночным расположением кода на Фортране.

После завершения учебы Мур в работе использовал разные языки программирования: ALGOL, JOVIAL, PL/I, FORTRAN и всевозможные ассемблеры, не оставляя, тем не менее, идеи использования интерпретатора, который он «таскал с собой, буквально нося пачку перфокарт» (прямая цитата — прим. авт.)

Из языков программирования Мур заимствовал идеи в свой интерпретатор, реализуя с его помощью все более сложные программы. Так появились кросс-ассемблер, примитивный редактор и система управления исходниками. Кроме того, он создал программу для генерации анимированных 3D изображений и шахматную программу, а также игру Spacewar. В интерпретатор добавился стек значений, переменные, арифметические операции и операции сравнения, возможность задания процедур.

В это время появляется название FORTH. Оно отсылает к четвертому поколению компьютеров, как тогда называли маленькие компьютеры. Буквой U из слова FOURTH (четвертый) пришлось пожертвовать из-за того, что файловые системы того времени не позволяли использовать имена файлов длиной более 5 символов. Написание Forth (без капитализации) появилось значительно позже, опять же благодаря файловым системам, способным различать строчные и заглавные буквы.

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

Наконец, последней концепцией, дополнившей картину Форта стала идея отдельного «стека возвратов», упростившего использование данных и процедур, без необходимости балансировать стек до/после вызова процедуры.

Философия Мура

Для Мура Форт был личным ответом на разочарование от современного ему программного обеспечения, которое он называл «Вавилонской башней»:

The software provided with large computers supplies a hierarchy of languages: the assembler defines the language for describing the compiler and supervisor; the supervisor the language for job control; the compiler the language for application programs; the application program the language for its input. The user may not know, or know of, all these languages: but they are there. They stand between him and his computer, imposing their restrictions on what he can do and what it will cost.

And cost it does, for this vast hierarchy of languages requires a huge investment of man and machine time to produce, and an equally large effort to maintain. The cost of documenting these programs and of reading the documentation is enormous. And after all this effort the programs are still full of bugs, awkward to use and satisfying to no one.

Вольный перевод:

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

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

С религиозной настойчивостью Мур отстаивал принцип «Keep it simple!», считая его «Основополагающим принципом». Не без оснований он считал, что для многих задач Форта достаточно.

С этим можно спорить, но Мур был последователен в отстаивании своих принципов. Он реализовал Форт для 18 разных ЦПУ, писал весь требуемый инструментарий, включая кросс-ассемблеры, драйверы и т.д.

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

Важность Форта

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

Интерпретация

Код на Форте интерпретируется. Каждое «слово» на языке исполняется либо кодом внутри интерпретатора, либо комбинацией других «слов». Понимание этого механизма позволяет лучше разбираться в системах, которые используют подобные техники. Так, то, что сейчас называется intrinsic в виртуальных машинах или в других системах, где есть сколь-нибудь сложный рантайм, корнями уходят в том числе в Форт.

Стек значений

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

Словари

Структура, отображающая имя в какую-то другую сущность, сегодня, кажется, проникла во все языки программирования в том или ином виде, однако, в Форте она имеет особое значение. Словарь является более высокоуровневой сущностью, по сравнению со «словом». Он может быть наделен своей семантикой и в программе может быть разное количество словарей.

Простота реализации

Интерпретатор Форт можно реализовать за один-два вечера. Причем это будет полноценная реализация.

Современные реализации

Сегодня сам по себе Форт используется нечасто. Однако идеи этого языка и того, как он реализован используются очень много.

Так, PDF и PostScript — это прямые потомки языка Форт. Во FreeBSD с версии 3.1 до версии 12 в загрузчике использовался интерпретатор Forth (позже заменен на Lua). Уже упомянутые стековые виртуальные машины используют идеи Форта.

TON Blockchain внутри использует Форт-подобный язык и стековую машину.

Не могу не упомянуть российскую разработку — SP-Forth и разработку российского разработчика по рождению Славы Пестова Factor.

Надеюсь, эта информация поможет расширить ваш программный инструментарий!

Штриховка

Шаблон штриховки рисуем в defs части чертежа используя тег pattern.
Шаблон для штриховки металла (тип 0) под углом 45°.

<pattern id="hatch0_45" width="20" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025" x1="1" y1="20" x2="20" y2="1" />
    <line class="line-type-2_025" x1="0" y1="1" x2="1" y2="0" />
</pattern>

Многие заметят и зададут вопрос, зачем нарисовано две линии вместо одной с координатами x1="0" y1="20" x2="20" y2="0"?
Пример штриховки с одной линией в шаблоне

если внимательно присмотреться то увидим разрывы в линии штриховки.
Пример штриховки с двумя линиями в шаблоне

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

Фрагмент кода области заштрихованной типом металл под углом 45°.

<path d="M475,225 L475,325 L500,325 L500,225 Z" fill="url(#hatch0_45)"/>

Шаблон для штриховки металла (тип 0) под углом 30°:

<pattern id="hatch0_30" width="34" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025" x1="2" y1="20" x2="34" y2="1" />
    <line class="line-type-2_025" x1="-1" y1="2" x2="3" y2="-1" />
</pattern>

Примеры штриховки других материалов:

Шаблон для штриховки неметалла (тип 1) под углом 45°:

<pattern id="hatch1_45" width="34" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025 " x1="0" y1="20" x2="20" y2="0" />
    <line class="line-type-2_025 " x1="0" y1="0" x2="20" y2="20" />
</pattern>

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

<pattern id="hatch2_45" width="350" height="350" patternUnits="userSpaceOnUse">
    <circle class="line-type-2_025" cx="0" cy="0" r="180" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="200" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="220" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="240" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="260" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="280" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="300" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="320" fill="none"/>    
</pattern>

Шаблон для штриховки камня естественного (тип 3) под углом 45°

<pattern id="hatch3_45" width="20" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025 " x1="0" y1="20" x2="12" y2="8" />
</pattern>

Шаблон для штриховки керамики (тип 4) под углом 45°

<pattern id="hatch4_45" width="20" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025" x1="0" y1="16" x2="16" y2="0" />
    <line class="line-type-2_025" x1="4" y1="20" x2="20" y2="4" />
    <line class="line-type-2_025" x1="0" y1="4" x2="4" y2="0" />
    <line class="line-type-2_025" x1="16" y1="20" x2="20" y2="16" />
</pattern>

Шаблон для штриховки бетона (тип 5) под углом 45°

<pattern id="hatch5_45" width="20" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025" x1="0" y1="30" x2="6" y2="24" />
    <line class="line-type-2_025" x1="10" y1="20" x2="26" y2="4" />
</pattern>

Шаблон для штриховки стекла (тип 6) под углом 45°

<pattern id="hatch6_45" width="30" height="30" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025" x1="5" y1="15" x2="13" y2="7" />
    <line class="line-type-2_025" x1="5" y1="25" x2="25" y2="5" />
    <line class="line-type-2_025" x1="17" y1="23" x2="25" y2="15" />
</pattern>

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

<path class="line-type-2" d="M0,575L0,600 15,675 100,650 250,675 300,575z"/>
<path d="M0,575L0,600 15,675 100,650 250,675 300,575z" fill="url(#hatch0_45)"/>
<circle class="line-type-2" cx="150" cy="625" r="40"/>
<circle cx="150" cy="625" r="40" fill="white"/>

Область окружности накладывается на заштрихованную область.

Простые графические объекты

В CAD системах используются следующие простые графические объекты:

Точка (маркер)

Шаблон и стили отображения точки мы рисуем в defs части чертежа.

<marker id="Point0" viewBox="-10 -10 20 20" markerWidth="5" markerHeight="5">
  <path d="M-3,0 L0,-3 3,0 0,3 z" stroke="red" fill="none"/>
</marker>

Выводим точку в чертеже с помощью тега path. В свойстве stroke-width задаём обратный масштаб вида, если масштаб вида 1:4, то для точки указываем масштаб 4:1.

<path stroke-width="4" d="M50,35" marker-end="url(#Point0)"/>

Линия

В CSS файле описываем типы линий.

line, rect, circle, ellipse, path, text {
  vector-effect: non-scaling-stroke;
}
/* основная */
.line-type-1 {
  fill: none;
  stroke: blue;
  stroke-width: 2;
}
/* тонкая */
.line-type-2 {
  fill: none;
  stroke: black;
  stroke-width: .7;
}
/* осевая */
.line-type-3 {
  fill: none;
  stroke: red;
  stroke-width: .7;
  stroke-dasharray: 25, 4, 3, 4;
}
/* штриховая */
.line-type-4 {
  fill: none;
  stroke: black;
  stroke-width: .7;
  stroke-dasharray: 7, 4;
}
...

А в чертеже используем тег line с присваиванием ему класса типа линии.

<line class="line-type-1" x1="0" y1="0" x2="500" y2="0"/>

Для тега line задано свойство vector-effect с значением non-scaling-stroke. В любом заданном масштабе для вида линии будут отрисовываться с одинаковой толщиной.

Окружность

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег circle с присваиванием ему класса типа линии.

<circle class="line-type-1" cx="165" cy="25" r="125"/>

Эллипс

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег ellipse с присваиванием ему класса типа линии.

<ellipse class="line-type-3" cx="120" cy="280" rx="100" ry="50"/>

Дуга и дуга эллипса

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег path с присвоением ему класса типа линии. В свойстве d задаём параметры дуги.

<path class="line-type-2" d="M50,50 A140,140 0 0 1 200,350"/>	
<path class="line-type-3" d="M20,150 A20,40 0 0 1 130,50"/>

Прямоугольник

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег rect с присвоением ему класса типа линии.

<rect class="line-type-1" x="20" y="5" width="395" height="287"/>

Ломаная линия

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег polyline с присвоением ему класса типа линии.

<polyline class="line-type-7" points="20,250 50,250 60,300 80,120 120,140 200,180"/>

Кривая NURBS (сплайн)

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег path с присвоением ему класса типа линии.

<path class="line-type-2" d="M140,201.34 C144.696,186.7859 152.303,175.3664 162.822,167.0820
    C167.996,163.0066 174.363,158.9944 180.459,157.132
    C194.3626,152.8843 213.0561,157.132 225.5589,167.082
    C232.5067,172.6114 241.8569,177.1221 250,177.9937
    C263.3438,179.4220 275.9399,163.2633 290.0,160
    C299.5142,157.7918 310.4253,154.6301 319.5409,157.132
    C325.7604,158.8390 332.0035,163.0066 337.1780,167.082
    C347.6966,175.3664 353.3294,189.206 360,201.3405"/>

Это цикл статей, посвященных работе с SVG, размещенный на сайте http://v.sytnik.lviv.ua (ныне недоступный). Статьи мне показались очень информативными, поэтому захотелось их сохранить.

В интернете можно найти много разной информации о создании чертежей в формате SVG. Чаще предлагается какой-то редактор и экспорт из формата DXF в SVG. Просматривая код SVG сразу видно что там много лишнего. Созданный в одном редакторе файл SVG не всегда может корректно открыться в другом. Одно радует, что браузеры начали поддерживать SVG формат. Всюду пишут про недостатки использования SVG. А может надо придерживаться единых правил структуры файла для отображения чертежей?

Из экспериментов и тестов пришёл к таким правилам при создании чертёжа:

• использование объектной модели чертежа;
• используем только одну единицу измерения (та что по умолчанию в пикселях);
• условно принимаем — один пиксель равен одному миллиметру (для браузера будет в пикселях, а для нас в мм);
• масштаб описания элементов всегда 1:1;
• для отображения объектов в другом масштабе используем вложенный svg рисунок;
• для уникальных объектов задаём id а для характерных class;
• …

Объектная модель чертежа

Упрощенно чертёж можно описать в виде XML структуры.

<svg id="Detail1" ...>
    <defs id="defsCAD"> ... </defs>
    <svg id="Shtamp" name="Frame drawing" ... >
        ...
    </svg>
    <svg id="View1" ... >
        <g id="layer-0" name="System layer" ...>
            <line class="line-type-1" ... />
            <line class="line-type-1" ... />
            <circle class="line-type-1" ... />
            <path class="line-type-1" ... />
            <rect class="line-type-1" ... />
            <line class="line-type-2" ... />
            <line class="line-type-2" ... />
            <g class="dimL">
                <line class="line-type-2" ... />
                <line class="line-type-2" ... />
                <line class="line-type-2" ... />
                <text ... >...</text> 
            </g>
            ...
        </g>
        <g id="layer-1" name="Layer 1" ...>
            ...
        </g>
    </svg>
    <svg id="View2" ... >
        <line class="line-type-1" ... />
        ...
    </svg>
    <svg id="View3" ... > ... </svg>
</svg>

Тег svg

<svg> — тег используется для описания самого чертежа и встроенных видов, штампа и техтребований. Если необходимо использовать масштаб отличный от 1:1, то реализуется с помощью свойств тега.
Например масштаб 1:4

<svg id="View1"
     x="50"
     y="7"
     width="150"
     height="162"
     viewBox="-25 -200 600 648">

width="150" height="162" viewBox="…… 600 648" — соотношение величин задаёт масштаб отображения вида на листе.

Например масштаб 10:1

<svg id="View1" 
     x="50" 
     y="7" 
     width="150" 
     height="162" 
     viewBox="-0.6 -5 15 16.2">

Тег defs

<defs> — здесь описываем все примитивные повторяющиеся элементы. Замечена одна особенность при использовании SVG элемента marker — на него не действуют параметры масштаба из тега <svg>, что намного упрощает работу с масштабом. (При любом масштабе вида стрелки в размерах должны быть одинаковые). Но на линии в элемента marker не действует параметр свойства vector-effect: non-scaling-stroke;

Тег line

<line class=«atr1» …/> — в файле CSS описываем стили линий для графических примитивов. Жаль что в Internet Explorer для каждого масштаба необходимо указывать свой стиль линии (толщина линии и интервал пунктиров). Как правило в чертеже одновременно не используются все возможные масштабы и достаточно задать только для используемых масштабов.
Пример описания стилей линий для элементов line, circle, path, rect и др.:

line, rect, circle, ellipse, path, text {
  vector-effect: non-scaling-stroke;
}
/* main line */
.line-type-1 { fill: none; stroke: blue; stroke-width: 2;
}
/* hairline */
.line-type-2 { fill: none; stroke: black; stroke-width: .7;
}
/* axial */
.line-type-3 { fill: none; stroke: red; stroke-width: .7; stroke-dasharray: 25, 4, 3, 4;
}
/* dashed */
.line-type-4 { fill: none; stroke: black; stroke-width: .7; stroke-dasharray: 7, 4;
}
/* main line for the scale 0.25 */
.line-type-1_025 { fill: none; stroke: blue; stroke-width: 8;
}
/* hairline for the scale 0.25 */
.line-type-2_025 { stroke: black; stroke-width: 2.8;
}

Тег g

<g class="dimL">…</g> — элементы описывающие объекты как размер группируем.
Пример:

...
<defs id="defsCAD">
<!-- Draw arrows and tick marks -->
    <marker id="dimArrow-1" viewBox="-2 -12 29 24" markerWidth="44" markerHeight="36" orient="auto">
        <path class="line-type-2_025" stroke="black" d="M0,0 L20,-4 16,0 20,4 z M0,-10 L0,10 M0,0 L27,0"/>
    </marker>
    <marker id="dimArrow-2" viewBox="-27 -12 29 24" markerWidth="44" markerHeight="36" orient="auto">
        <path class="line-type-2_025" stroke="black" d="M0,0 L-20,-4 -16,0 -20,4 z M0,-10 L0,10 M0,0 L-27,0"/>
    </marker>
</defs>
...
    <g class="DimL">
        <line class="line-type-2" x1="190" y1="180" x2="190" y2="230"/>
        <line class="line-type-2" x1="310" y1="180" x2="310" y2="230"/>
        <line id="dim1" class="line-type-2" x1="190" y1="230" x2="310" y2="230" marker-start="url(#dimArrow-1)" marker-end="url(#dimArrow-2)"/>
        <text x="265" y="222" font-size="28" text-anchor="middle">120</text> 
    </g>
...

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

<svg id="Shtamp" type="1" x="0" y="0" width="420" height="297" viewBox="0 0 420 297">
    ...
    <rect class="line-type-2" x="1" y="1" width="418" height="295"/>
   ....
</svg>

Эту фразу приписывают Архимеду, так, во всяком случае, нам говорили в школе.

Иногда действительно требуется перевернуть мир, пусть и несколько в ином смысле.

Координатная система SVG

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

Вот только незадача, координата Y в нем идет не так, как принято в математике — привычная нам ось идет вверх, тогда как в SVG — вниз. Пробуем рисовать. Будем использовать библиотеку cl-svg.

В Quicklisp устаревшая версия, поэтому имеет смысл склонировать ее себе в ~/quicklisp/local-projects/ и выполнить (ql:register-local-projects).

Итак, делаем простейший файл, рисуем координатные оси, ну или их какое-то подобие.

(in-package #:svg)

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230)
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)
  
  (draw scene (:line :x1   0 :y1 -10 :x2   0 :y2 200))
  
  (draw scene (:line :x1 -10 :y1   0 :x2 200 :y2   0)))

Запускаем, получился файл coord.svg. Запускаем его и... ничего.

Правильно, потому что по стандарту линия не рисуется, если у нее не задано значение цвета пера (stroke). Кроме того, у нас не задано значение поля viewPort.

Корректный вариант такой (далее первую форму (in-package #:svg) опускаю):

(with-svg-to-file
    (scene 'svg-1.1-toplevel
	   :height 230
	   :width 230
	   :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (draw scene
      (:rect :x -20 :y -20 :height 230 :width 230)
      :fill "#EEEEEE" :stroke "none")
  
  (draw scene
      (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")
  
  (draw scene 
      (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green"))

Линии осей нарисованы зеленым цветом.

Для удобства восприятия добавлен прямоугольник под картинку.

Получилось что-то такое:

Как мы видим, ось Y растет вниз.

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

Попробуем другой метод.

Использование CSS

SVG позволяет использовать стилевую информацию. Этим мы и воспользуемся.

Добавим стиль, применяющий масштаб -1 к тегу <svg>:

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)
  
  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")
  
  (draw scene
      (:rect :x -20 :y -20 :height 230 :width 230)
      :fill "#EEEEEE" :stroke "none")
  
  (draw scene
      (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")
  
  (draw scene
      (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green"))

Идентификатор #toplevel создается внутри класса svg-1.1-toplevel.

Получилась замечательная картинка:

Прекрасно, давайте развивать решение. Добавим текста:

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")

  (draw scene
      (:rect :x -20 :y -20 :height 230 :width 230)
      :fill "#EEEEEE" :stroke "none")

  (draw scene
      (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")

  (draw scene
      (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green")

  (text scene (:x 20 :y 20) "Привет!"))

Ооочень интересно. Перевернут не только мир, но и текст.

Это забавно, но логично.

Хорошо, давайте теперь применим масштабирование и к тексту:

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")

  (style scene "svg#toplevel > text {transform: scaleY(-1);}")

  (draw scene
      (:rect :x -20 :y -20 :height 230 :width 230)
      :fill "#EEEEEE" :stroke "none")

  (draw scene
      (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")

  (draw scene
      (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green")

  (text scene (:x 20 :y 20) "Привет!"))

Текст перевернулся, но теперь он расположен непонятно где:

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

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

Обернем текст в группу и потом применим преобразование к тексту.

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")

  (style scene "svg#toplevel g > text {transform: scaleY(-1);}")

  (draw scene
      (:rect :x -20 :y -20 :height 230 :width 230)
      :fill "#EEEEEE" :stroke "none")

  (draw scene
      (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")

  (draw scene
      (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green")

  (make-group scene
      (:transform "translate(20, 20)")
    (text*  (:x 0 :y 0) "Привет!")))

Получилось то, что нужно!

Ключевым здесь являются вызовы

(style scene "svg#toplevel g > text {transform: scaleY(-1);}")

...

(make-group scene
      (:transform "translate(20, 20)")
    (text*  (:x 0 :y 0) "Привет!"))

У тега <g> нет своих координат x и y, но к нему можно применить преобразование transform(), и в нем задать нужное смещение. Кроме того, координаты x и y для текста можно не указывать, но библиотека cl-svg требует, чтобы они были указаны, поэтому вписываем.

Вложенные группы

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

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")

  (style scene "svg#toplevel g > text {transform: scaleY(-1);}")

  (make-group scene (:id "frame")
    (draw*
     (:rect :x -20 :y -20 :height 230 :width 230)
     :fill "#EEEEEE" :stroke "none"))

  (make-group scene (:id "axes")
    (draw*
     (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")
    (draw*
     (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green"))

  (let ((texts (make-group scene (:id "texts"))))
    (make-group texts (:transform "translate(20, 20)")
      (text*  (:x 0 :y 0) "Привет"))
    (make-group texts (:transform "translate(30, 40)")
      (text*  (:x 0 :y 0) "Мир"))
    (make-group texts (:transform "translate(30, 60) rotate(90)")
      (text*  (:x 0 :y 0) "SVG"))))

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

Параметры viewPort

Последнее замечание сделаю относительно значений параметра viewPort тега <svg>.

Я долго не мог понять, как им пользоваться, пока не придумал такое объяснение.

Окно просмотра характеризуется двумя парами значений. Первая — положение окна просмотра в мировых (или пользовательских) координатах. По сути это просто точка на пользовательском чертеже.

Вторая пара задает количество точек на пользовательском чертеже, которые мы видим в окно просмотра, соответственно по горизонтали и вертикали, но при этом само окно имеет размер, задаваемый параметрами ширины и высоты тега <svg>.

То есть, viewPort имеет фиксированный размер на экране или в браузере, а вот содержимое его подстраивается с учетом коэффициентов, получаемых соотношением размеров из окна просмотра и тега <svg>. Кому как, а мне так стало понятнее.

UPD:

В библиотеке подумали о том, что иногда можно опустить проверку параметров:

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")

  (style scene "svg#toplevel g > text {transform: scaleY(-1);}")

  (make-group scene (:id "frame")
    (draw*
     (:rect :x -20 :y -20 :height 230 :width 230)
     :fill "#EEEEEE" :stroke "none"))

  (make-group scene (:id "axes")
    (draw*
     (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")
    (draw*
     (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green"))

  (without-attribute-check 
    (let ((texts (make-group scene (:id "texts"))))
      (make-group texts (:transform "translate(20, 20)")
	(text* () "Привет"))
      (make-group texts (:transform "translate(30, 40)")
	(text*  () "Мир"))
      (make-group texts (:transform "translate(30, 60) rotate(90)")
	(text* () "SVG")))))

см. (without-attribute-check ... )

Когда в публичном пространстве появляется информация о новом языке программирования, поднимается волна неприятия. Негатива столько, что хоть святых выноси!

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

Однако можно подойти к вопросу рационально, и все-таки попробовать поискать ответ на вопрос, а зачем, собственно, создавать новый язык программирования?

Попробуем разобрать мотивы, подвигающие людей на такую работу.

Личный творческий порыв

Зачем люди пишут статьи (включая эту), картины, идут в горы, спускаются на дно океана, вышивают крестиком, вяжут рыболовные сети и режут из дерева?

Зачем вообще люди занимаются творчеством?

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

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

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

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

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

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

Академический интерес

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

Так, язык Brainfuck вырос из попытки создать Тьюринг-полный язык программирования, для которого можно создать минимально возможный компилятор. Первая версия компилятора для Amiga OS 2.0 занимала 240 байт, позднее размер удалось сократить и он стал занимать менее 200 байт.

Языки Agda, Coq, Idris разработаны для проведения исследований в области спецификаций и доказательств.

Многие исследовательские проекты, изначально написанные, скажем, на Haskell или OCaml, нередко перерастают в самостоятельные языки.

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

Поддержка предметной области

Перейдем к более приземленным материям.

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

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

В России таким примером служит язык 1С, разработанный для автоматизации задач бухгалтерского учета. Другие примеры подобного рода — AutoLISP для CAD, Asymptote для подготовки математических иллюстраций, G-Code для управления станками с ЧПУ и т.д.

Такие языки принято называть DSL (domain specific language) или по-русски — предметно-ориентированный язык.

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

Предоставление интерфейса к набору библиотек

При разработке большой программной библиотеки может возникнуть ситуация, когда сама по себе библиотека становится «предметной областью». Тогда можно создать язык программирования, построенный поверх этой библиотеки. Пример такого подхода — язык QMLиз библиотеки QT. И, хотя сам язык разрабатывался как средство разработки интерфейсов пользователя, построенный поверх QT, фактически из него можно вызывать почти всё (если не строго всё) содержимое библиотеки, в свою очередь написанной на C++.

Есть и другие примеры такого подхода. Так, к таким языкам можно отнести JavaScript, хотя он заметно шире, чем представлено в настоящем параграфе. Похожими свойствами обладает язык TISript из проекта Sciter (позже, впрочем, замененный на JavaScript).

Благодаря легкости встраивания и легкости синтаксиса, свойство «быть надстройкой над библиотекой» появляется при встраивании языка Lua или ECL (Embeddable Common Lisp) внутрь более крупного проекта.

Причины коммерческого характера

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

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

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

Безопасность

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

Отношения к лицензионным соглашениям в российском сегменте интернета часто вызывает улыбку, но с точки зрения бизнеса — вопрос серьезный.

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

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

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

Производительность

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

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

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

Укрупнение или сужение семантики

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

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

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

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

Бывают и примеры обратного преобразования, когда код из более низкоуровневого представления преобразуется в более высокоуровневое.

Имиджевые причины

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

Зачем я все это пишу?

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

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

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

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

Да, международное сотрудничество идет, пусть и в виде приема патчей в репозитории. Пока идет. Важно не упустить момент, когда станет поздно и окажется, что «станки для программистов» делать и некому, и незачем.

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

P.S. На КДПВ святой Георгий Победоносец, по преданию победивший дракона.

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