Физика автомобиля на D

Давно мечтал написать собственный автосимулятор, хотя бы простенький. Насколько я знаю, на D ничего подобного никто еще не делал, и вот вам proof-of-concept: с использованием dmech можно реализовать вполне сносную физику автомобиля с моделированием колес и подвески на основе лучей (raycast car).

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

Демка использует модифицированную версию dmech, а также Dagon в качестве графического движка (опять-таки с модификациями, которые совсем скоро войдут в основной репозиторий – к примеру, реализованы тени и шейдерный бэкенд для материалов). Все зависимости включены в архив, кроме dlib 0.11.1. Прилагается сборка для Windows. Можете использовать демку в своих проектах (код доступен под лицензией Boost).

Скачать (9,65 Мб)

Текущий статус и планы по проекту Dagon

Ненадолго получив доступ к Windows-машине, я наконец-то собрал под ней Dagon. К сожалению, большую часть времени сейчас мне приходится работать под старым железом, поэтому работа над движком продвигается медленнее, чем хотелось бы. Надеюсь, что этим летом у меня будет возможность довести его до ума и продолжить работу над Atrium. В первую очередь, планирую написать шейдерный бэкенд для системы материалов и загрузчик файлов формата DGL. Также будет поддержка FXAA, SSAO, CSM, DoF, Motion Blur.

Демки Dagon переместились в отдельный репозиторий: https://github.com/gecko0307/dagon-demo. Теперь это всего одно приложение, включающее несколько сцен и меню для переключения между ними. Появилась новая демка с реализацией системы частиц, которая, надеюсь, скоро станет частью движка. Система включает очень быстрый отрисовщик биллбордов для частиц, поддерживает стандартные векторные поля (аттрактор, дефлектор, “черная дыра”, вихрь) и позволяет добавлять новые.

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

Прошло семь лет с тех пор, как я опубликовал свою первую статью о языке 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, конвертируя в нужный тип. Без дополнительных проверок это небезопасно, но если вы знаете, что делаете – очень полезно.