Идеальный язык – это миф

Прошло семь лет с тех пор, как я опубликовал свою первую статью о языке D в журнале “FPS” (№12 за 2010 г.). Первоначальный восторг и энтузиазм за это время, конечно, поугас, но в целом мое отношение к языку не поменялось, я все еще остаюсь убежденным дишником – ничего лучше D я пока не вижу. Но я отнюдь не считаю D идеальным языком. За эти годы у меня накопилось много соображений по этому поводу, которыми сейчас и хочу поделиться.

Есть популярное мнение, что программисты СПО не должны распылять усилия на персональные проекты и разрабатывать только один, чтобы получился идеальный инструмент. Отчасти это мнение распространяется и на языки – кого-то раздражает “зоопарк” языков, среди которых, мол, нет однозначно лучшего. Так вот, идеальный язык программирования – это нонсенс, он не может существовать. По той простой причине, что языки – это инструменты, предназначенные для решения определенных задач. Немыслим такой инструмент, который решал бы все возможные задачи. Более того, по мере развития информационных технологий появляются новые задачи, для решения которых создаются новые инструменты. И это нормально, так было всегда. Чем больше языков, тем лучше – те, кто считает иначе, гонятся за иллюзией.
Можно выразить это через биологическую аналогию. Языки (и вообще все свободные программы) существуют в некоем подобии экосистемы, и к ним отчасти применимы законы естественного отбора. Выживают наиболее приспособленные – в данном случае, приспособленные к решению определенного набора задач. Схожие задачи объединяют языки в “ареалы обитания”, где они конкурируют друг с другом. Подобно живым организмам, языки в принципе не способны охватить все ареалы – нет существ, которые были бы одинаково хорошо приспособлены к жизни в пустыне, в тропиках, в арктических льдах и в океане.
Поэтому мне всегда казалась нелепой тенденция учить один-единственный язык, чтобы затем использовать его для любых целей. Если язык пригоден для решения вашей задачи – используйте, если нет – берите более подходящий.

Когда люди спрашивают что-то вроде: “Почему D непопулярен несмотря на то, что он такой идеальный?” – некорректна сама постановка вопроса. D – неидеальный язык. И C++ неидеальный, и Java, и Python, и все остальные. D спроектирован лучше, чем C++, Java или Python – но этот факт сам по себе не означает, что D решает все задачи однозначно лучше, чем C++, Java или Python.
Практическая ценность языка вообще мало коррелирует с его дизайнерскими достоинствами. D – очень красивый язык, вобравший в себя множество потрясающих архитектурных решений. На D можно писать образцово эффективный и читаемый код. Но это дизайнерское достоинство, которое сделало бы D идеальным языком только в идеальном мире, где нет необходимости линковаться с библиотеками на C++, взаимодействовать с морально устаревшими API типа Win32, писать клиентский код под браузеры, разрабатывать мобильные приложения под Android с его урезанным libc и отсутствием полной поддержки Posix. Список можно продолжать бесконечно: мир IT – это архитектурный хаос. Есть хорошо продуманные стандарты, ставшие популярными, но они теряются на фоне нагромождения разнородных поделок, “склеенных скотчем”, наспех написанных по принципу “лишь бы работало”.
Популярными становятся те инструменты, которые помогают уживаться со всем этим, не стремясь быть “вещью в себе”. Есть инструменты, безупречные с точки зрения дизайна, но совершенно бесполезные на практике – например, язык Haskell или ОС Plan 9. Это классические примеры “вещей в себе”, интересные лишь в эстетическом отношении. На практике никто не использует красивые языки и красивые операционные системы только из-за их красоты. В этом причина популярности Windows и C++. Никто не говорит, что они идеальны, но все ими пользуются – потому что они решают задачи большинства.

Но вернемся к D. Решает ли он какие-то задачи лучше, чем C++? Если да, то почему непопулярен? Это непростой вопрос, на который, наверное, нельзя ответить однозначно, но я попробую.
Я не раз сталкивался с необходимостью написать небольшую утилиту, эффективно выполняющую одну-единственную задачу. Например, сортировщик файлов, переименовывающий их в определенной последовательности. На D без дополнительных библиотек написать такое намного проще, чем на C++ без дополнительных библиотек. И работать оно будет значительно быстрее, чем, скажем, вариант на Python или Bash (и я бы еще поспорил, что проще – Bash или D).
D позволяет без особых телодвижений взять и реализовать с нуля любую идею – в этом его главная практическая ценность. Конечно, без библиотек это не всегда так просто, поэтому я и начал проект dlib – это, в первую очередь, именно библиотека для прототипирования. Суть в том, что D как язык располагает к быстрому воплощению идей, при этом предоставляя нужную производительность – с D не требуется переписывать прототип на язык с более низким уровнем абстракции, прототип с минимальными трудозатратами превращается в законченный продукт.
Может ли D конкурировать с C++ на вышеупомянутом хаотическом поприще? Да, но только при создании нового. Нет смысла писать на нем, если ваш код будет мешаниной из библиотечных вызовов, C-шных идиом и разных костылей типа toStringz. В таком случае вы просто усложните себе жизнь – намного проще использовать C++. D – это язык не для рутины, а для творчества. И в этом у него нет конкурентов.

Вопрос в том, насколько много программистов сейчас занимаются чистым творчеством. По моим впечатлениям, большинство pet-проектов на GitHub – это какие-то мелкие веб-приложения, разного рода “хеллоуворлды”, бессмысленные порты с одного языка на другой, какие-то врапперы и биндинги. Серьезные открытые проекты давно переросли стадию чьего-то хобби – творчеством там, конечно, и не пахнет. Даже на D чего-то нового и интересного не так уж много, и это меня искренне расстраивает. Был легендарный h3r3tic с его потрясающими программными растеризаторами и трассировщиками лучей времени компиляции. Была Higgs, JavaScript-машина с JIT-компиляцией. Был игровой движок Dash. Была пара-тройка мини-игр. И это, по большому счету, все. Сейчас репозиторий DUB забит какими-то унылыми библиотеками для веба, драйверами СУБД и реализациями малоизвестных протоколов. Скучно, ребята, скучно. На D можно писать удивительные штуки – почему никто этого не делает?

DMD полностью свободен!

Свершилось историческое событие: бэкенд DMD перелицензирован под лицензией Boost – это значит, что компилятор теперь полностью отвечает критериям свободного ПО по Столлману и OSI (то есть, разрешается создание производных работ и передача кода третьим лицам).

Долгое время бэкенд распространялся по несвободной лицензии, оставляя исключительное право на распространение кода за правообладателем (компанией Symantec) – для распространения кода лицензиатом требовалось получить явное разрешение, что формально делало бэкенд прориетарным при открытых исходниках. Данный нелицеприятный факт долгое время служил еще одной антирекламой D, и, хотя де-факто все игнорировали лицензию бэкенда и спокойно форкали DMD на Гитхабе, несвободная лицензия ограничивала возможность включения бинарников DMD в стандартные репозитории Linux-дистрибутивов. Наверное, в некоторой степени это и сделало язык менее популярным, чем Go, Rust и другие новинки последних лет (да, есть изначально свободные LDC и GDC, но они всегда отставали на несколько релизов, к тому же играет роль психологический фактор – к референсной реализации всегда больше доверия). Надеюсь, теперь ситуация начнет меняться, если еще не слишком поздно – из реальных, ненадуманных недостатков D остается только сборщик мусора.

Фокусы с Compound

Недавно столкнулся с интересной задачей: описанием класса, который инкапсулирует неизвестный заранее набор объектов. Типы этих объектов задаются через variadic template – то есть, шаблон с переменным количеством параметров. Статические массивы для этой задачи, ясное дело, не годятся, но тут идеально подошел Compound из dlib.core.compound. Это своеобразный “гибрид” кортежа и структуры – составной тип данных, который можно создавать в шаблонах. Ему можно передавать кортеж параметров variadic-шаблона, и это позволяет проделывать замечательные вещи.

class Collection(C...)
{
    protected Compound!C _components;

    this(C comps)
    {
        _components = comps;
    }
}

auto inc = new Collection!(int, char, bool)(10, 'a', false); 

Проблема с обычными кортежами (Tuple) в том, что их нельзя возвращать из функции. Но Compound – можно. Таким образом, для ридонли-доступа к _components мы можем объявить следующий метод:

auto components() @property
{
    return _components;
}

А еще мы можем заполнять Compound в цикле, читая значения, например, из массива:

this(int[] arr)
{
    foreach(i, T; C)
    {
        _components[i] = cast(T)arr[i];
    }
}

auto inc = new Collection!(int, char, bool)([5, 40, 0]);

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

Dagon

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

Те, кто следит за моей активностью на GitHub, могли заметить, что у меня появился новый репозиторий dagon – проект, который позиционируется как новая эволюционная ступень DGL. В процессе работы над Atrium я пришел к выводу, что в движке не хватает средств автоматизации некоторых рутинных задач. Например, управление памятью в типичном игровом приложении может быть почти полностью автоматизировано, поскольку выделение и высвобождение памяти происходит в специально задуманных паузах, таких как переключение между локациями (это не относится к играм с открытым миром с фоновой подгрузкой, но это уже специфический случай). Кроме того, в обсуждении на Reddit звучал вопрос, почему DGL не использует SDL2. Так родилась новая ветка движка, которую я решил сделать отдельным экспериментальным проектом.

На сегодняшний день Dagon включает следующие возможности:

  • Использование SDL2
  • Новая модель памяти на основе концепции владельца (owner), позаимствованной из Delphi
  • Модель образцов и компонентов (entity-component), позволяющая расширять функциональность объектов динамически, без наследования классов
  • Динамическая перезагрузка ресурсов при их модификации сторонним приложением без перезапуска игры
  • Поддержка форматов OBJ и IQM
  • Поддержка текстур PNG, JPG, TGA, BMP
  • Поддержка контейнера Box для ресурсов
  • Новая система материалов с разделением на фронтенд (набор параметров) и бэкенд (передатчик параметров графическому конвейеру – фиксированному или шейдерному, в зависимости от выбранной реализации бэкенда). Система позволяет использовать как стандартные материалы с известным набором параметров, так и создавать свои, специализированные
  • Некоторые компоненты, напрямую портированные из DGL – например, система событий, система освещения, рендеринг текста.
Как только будет дописана система материалов и поддержка формата DGL3, я начну портировать Atrium на новый движок.

Анимация в dlib

Меня внезапно осенило, как можно добавить в dlib.image поддержку анимации без существенного рефакторинга библиотеки. Классы анимированных изображений (SuperAnimatedImage) могут быть простым расширением базового класса SuperImage с возможностью хранить несколько кадров и переключаться между ними. Такие изображения полностью совместимы с любым кодом, работающим с SuperImage – чтению и записи через привычный интерфейс SuperImage подлежит срез данных, относящийся к текущему кадру.

Также естественным образом вводится класс-фабрика для создания анимированных изображений, и в результате стало возможным расширить декодер PNG до поддержки APNG:

AnimatedImageFactory imgFac = new AnimatedImageFactory;
auto res = loadPNG(openForInput("animation.apng"), imgFac);
if (res[0])
{
    SuperAnimatedImage animImg = cast(SuperAnimatedImage)res[0];
}