Статьи автора: Gecko

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

Когда люди спрашивают что-то вроде: “Почему 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 можно писать удивительные штуки – почему никто этого не делает?