Угораздило меня встрять в обсуждение новости о "финансировании" исправления багов в DMD со стороны Facebook-а. Написал там довольно большой пост. Подумал, что и в блоге его текст будет уместен, поэтому решил скопипастить сюда.
Но, для начала, небольшое пояснение, дабы читателю было понятно, что с языком D я был знаком довольно плотно. Дело было где-то в районе 2005-2007 годов. В Интервэйле тогда было написано несколько важных систем на C++ и SObjectizer, но большинство опытных разработчиков, с которыми мы начинали, к тому времени уже перешло на Java. И нужно было что-то делать с теми системами, за которые продолжал отвечать я. Было понятно, что самый надежный способ подбирать себе правильных людей -- это брать совсем еще зеленых ребят. Студентов или вчерашних студентов. И учить их по ходу работы.
У такого подхода есть куча преимуществ. Но вот в случае с C++ есть серьезная проблема. На C++ хорошо вести разработку небольшой командой опытных программистов, когда каждый из них понимает, как следует писать на плюсах, чтобы получалось и просто, и быстро, и надежно. А вот запускать студентов в ответственный плюсовый код -- это чревато.
Поэтому в 2006-2007 годах я самым серьезным образом искал альтернативу C++. План был такой: находится язык, который был бы достаточно выразителен, чтобы на нем можно было писать серьезные вещи. Который был бы достаточно быстр, чтобы на нем можно было реализовывать нагруженные приложения. Который был бы достаточно безопасен, чтобы на нем могли писать продакшен код даже не самые опытные разработчики. Ну и еще это должен был быть кросс-платформенный язык (нужна была отличная поддержка Windows и Linux как минимум). Будь такой язык найден, на него бы мы портировали SObjectizer и несколько наших базовых библиотек. А потом бы стали делать новые модули к нашим системам уже на этом языке. Попутно, в течении нескольких лет, переписывая старый C++ный код.
В этом поиске я пересмотрел несколько языков (чему в свое время была посвящен небольшой раздел моей страницы на narod.ru). И первым в этом списке оказался язык D.
D представлялся наиболее подходящим кандидатом. Я наблюдал за его развитием года с 2001-го. А в 2006 следил за ним уже очень плотно, регулярно скачивал новые версии компилятора. Даже делал небольшие вспомогательные утилиты на D, а не на Ruby, если от них требовалась высокая скорость работы. Если мне не изменяет память, то к середине 2006 стало понятно, что D готов к релизу в качестве первой официальной версии. И разговоры об этом стали вестись все активнее и активнее. И, наконец, в январе 2007-го появилась официальная версия D 1.000. В последовавшие несколько месяцев в D1 исправлялись ошибки и была добавлена одна новая фича -- текстовые mixin-ы. И хотя фича была действительно полезной, все равно складывалось ощущение, что в разработке D ничего не изменилось: как переделывали авторы свой язык не особо заботясь о пользователях, так и продолжали переделывать. В таких условиях делать серьезный переход на D я не спешил. И не зря. В конце весны 2007 было заявлено о начале работ над D2, новой версией D, которая будет очень сильно отличаться от D1. При этом декларировалось, что разработка D2 займет 2-3 года.
Вот тогда я поставил на D крест окончательно. Авторы его просто убили в тот момент. С одной стороны, нельзя было заявлять, что через 2-3 года появится совсем другой D и тот код, который мы напишем на D1 за это время, нужно будет серьезно переделывать. С другой стороны, для D не было нормального инструментария. И анонс работ над D2 означал, что этот инструментарий для D1 не появится вообще. Вообщем, было понятно, что смысла делать что-то на D1 нет. Нужно ждать D2, но вот сколько придется ждать -- неизвестно. Напомню, что дело было в 2007-м, сейчас заканчивается 2013-й, а официального релиза D2 так и не состоялось.
Ну а теперь, когда я обозначил контекст собственного отношения к D, можно процитировать мой LOR-овский пост (курсивом приведен текст моего собеседника yetanother):
Вы вот 7 лет назад бросили его, а язык за это время не только не умер, но стал еще намного лучше - это уже далеко не D1.
Уж простите мне назидательный тон, но давайте я поясню несколько вещей, которые, как мне кажется, вы либо не понимаете, либо не придаете им значения.
Итак, в середине 2006 года пошли серьезные разговоры о том, что D1 готов к релизу и пора этот релиз делать, а все дальнейшие улучшения оставить на потом. На тот момент ситуация с C++ была аховая. Не так давно был зафиксирован стандарт C++03, но компиляторов, его полностью поддерживающих не было (возможно, таковым был comeau c++, но это был редкий зверь, которого живьем мало кто видел). Работы над C++0x шли не ахти, остряки даже шутили, что x — это шестнадцатирична цифра, не десятичная, и оказались правы. В этот момент D1 был однозначно намного-намного лучше C++. Да еще был представлен в виде единственного компилятора на всех платформах, а не как в C++, где у каждого компилятора (или его версии) были свои заморочки. Да и с либами у C++ было не так уж и хорошо. Qt была всего под двумя лицензиями (коммерческой и GPL), Boost был еще не таким большим (того же Asio, по-моему, в нем не было тогда). Из бесплатных больших библиотек были разве что ACE и wxWindows.
А что было вокруг? Вокруг была Java, которая уже забрала на себя весь server-side, а так же отжирала кросс-платформенные вещи у C/C++. Популярность получал Python, начинался феномен Ruby-On-Rails, заговорили об Erlang-е, зарождался hype вокруг функциональщины. Microsoft активно двигала .Net, пыталась всех на него пересадить и говорила об умирании native-разработки под Windows. Что будет с мобильными платформами после смерти PalmOS, непонятным состоянием WinCE и феноменальным успехом iOS на iPhone мало кто понимал.
Т.е. С++ был в неважном состоянии, со всех сторон его теснили, его будущее выглядело мрачным. Тогда как D много лучше и мог появиться здесь и сейчас.
Но даже при этом всем было понятно, что сам по себе язык D не так уж и полезен. К нему нужен стабильный качественный компилятор, отлаженная run-time библиотека с быстрым и надежным сборщиком мусора, нужны хорошие инструменты (IDE, профайлеры, отладчики, статические и динамические анализаторы) + большие околосистемные и околоприкладные библиотеки. Ничего этого тогда не было. Можно было бы рискнуть вложиться в язык в надежде, что все это появится. А для этого следовало разработку языка заморозить на несколько лет, переключившись на разработку всего вышеперечисленного.
Что же сейчас?
C++11 давно принят, реализован в GCC и clang, более-менее нормальная его поддержка есть даже в MSVC++. Более того, C++14 не только на грани принятия, но и вполне себе поддержан в тех же GCC и clang. При этом C++11 делает даже D2 не таким привлекательным, как это было c C++03 и D1 в 2006-м. При этом тот же Boost очень серьезно разросся, Qt есть под LGPL. Microsoft опять заговорила о важности native-кода и активно развивает MSVC++. Мобильные платформы стали серьезной нишей, в которой C++ может использоваться для кросс-платформенной разработки как ресурсоемких частей приложений, так и всего приложения целиком, включая GUI (не случайно Qt сейчас активно портируют под Android и iOS). При этом для C++ есть и IDE, и отладчики, и профайлеры, и статические анализаторы, и куча библиотек, и толпы разработчиков, и огромное количество литературы/ресурсов. Google вон Go выкатил, который так же нативный, со сборкой мусора и очень быстрой компиляцией. Причем Go зафиксирован и совместимость с Go 1.0 ломать не спешат.
Что-то из этого появилось у D за прошедшие 7 лет? Нет. Сам язык куда-то продвинулся, возможно. Но начинать на нем что-то серьезное, зная текущую ситуацию с инструментарием и прошлое этого языка? Может для каких-то задач это и оправдано. Например, для чисто вычислительных. Помнится, в списках рассылок D был некто Don Clugston, который рассказывал как он такими вещами занимался. Тут да, тут кроме языка и эффективного кодогенератора особо ничего не нужно. Но как только появится что-то вроде работы с СУБД, с криптографией, с какими-нибудь сторонними библиотеками (плюсовыми, например), со стандартами вроде CORBA или SOAP, тогда что делать?
И, прошу заметить, я пока противопоставлял D только C++. Если противопоставить его той же Java (или платформе JVM для которой кроме Java есть Scala, Ceylon, Clojure и скоро появится Kotlin), то получится не менее печально для D, т.к. его инфраструктура и комьюнити не идет ни в какое сравнение с миром JVM.
Из реальных проектов посмотрите vibe.d - более чем реальный. И тот же sociomantic в продакшене использует D1.
И опять неправильный посыл. Что толку мне на них смотреть? Для продвижения языка нужны материалы вроде хорошо написанных success stories. Вроде того, что была вот такая проблема, мы пытались ее решить так и так, в итоге решили на D вот так вот. И это хорошо потому что бла-бла-бла, но есть некоторые вещи вроде бла-бла-бла и т.д. и т.п.
Если тот же vibe.d настолько хорош, то пусть кто-то из D-комьюнити возьмет на себя труд показать, чем он лучше, скажем Wt. Или Boost.Asio. Или HttpServer из POCO. Или HTTP-сервер из примеров ACE. А то ведь можно подумать, что vibe.d хорош потому, что это единственный web-фреймворк для D.
Ну и в заключение задержу читателей еще ненадолго. Мое скептическое отношение к D не означает, что я не оставляю для D никакой надежды на расцвет в будущем. В конце-концов, в язык действительно заложено довольно много всего интересного и полезного. Но не могу не обозначить, как минимум, несколько проблем, связанных с популяризацией языка D в настоящее время.
Проблема первая. Для чего нужен этот язык? В 2006 было однозначно понятно, что D -- это C++ killer. Сейчас я бы так не сказал. C++11 закрывает множество реальных проблем языка C++ и делает использование C++ намного проще и безопаснее, чем во времена C++03. При этом C++никам не нужно переучиваться и переписывать свой старый код. При этом язык C++ вышел на поступательное движение вперед и можно ожидать, что обновления языка будут происходить каждые 3-4 года, а бумажный стандарт будет подкрепляться выходом качественных компиляторов. А посему я не вижу ниши для D. Где нужна производительность, будут C/C++. Где не так нужна -- Java/Scala/Ceylon/Gosu и C#. Ну и куча скриптовых языков до кучи. Ну и не забудем про Go от Google ;)
Проблема вторая. Андрей Александреску. Да, я считаю, что это проблема D-сообщества. Он привлекает внимание к языку за счет своей известности. Но что у него за известность? Он сделал что-то серьезное, как Фредерик Брукс? Да, он автор нескольких знаковых книг по C++. Но знаковость самой знаменитой из них, "Modern C++ Design" с непонятным знаком :) Не случайно сейчас довольно часто используются уничижительные термины "укушенный Александреску" и "шаблоны в стиле Александреску". Здорово, что такой известный в программерских кругах человек занимается популяризацией языка. Плохо, на мой взгляд, что он имеет серьезное влияние на развитие языка. Как по мне, так D2 начали делать именно с подачи Александреску. Что язык и погубило в 2007-м.
Проблема третья. Способы продвижения языка. Сейчас приверженцы D поступают точно так же, как когда-то я и еще несколько человек на LOR-е и RSDN-е. Т.е. делают анонсы релизов компилятора DMD, репостят новости о появление какой-то фичи в языке или о каком-то событии вокруг языка. На мой взгляд, такой подход был уместен тогда. Сейчас же это не работает, а лишь продолжает создавать D репутацию долгостроя, который до релиза никогда не дойдет. В настоящее время нужны success stories, хорошие, подробные, основанные на реальных разработках и результатах. Только такие истории смогут переубедить скептиков вроде меня. Да и вообще любого, кто заинтересуется историей языка D и увидит, что за 14 (четырнадцать!) лет разработки язык так и не смог достичь сколько-нибудь стабильного состояния.
Ну и еще одно лирическое отступление. Вооруженный теорией Адизеса я теперь вижу, что проектом D заправляют люди с ярковыраженной составляющей E (предприниматели). Эти люди всегда устремлены в будущее, они не могут остановиться на какой-то одной стадии развития продукта, а стараются сразу же пойти дальше, добавить в продукт еще и еще нового и полезного. Руководители типа E сосредоточены на стратегии, тактика и ближайшие результаты их не интересуют. Такой проект обречен. Выход состоит в том, чтобы передать власть на проекте человеку с выраженной составляющей P (исполнитель). Этот руководитель сосредоточиться лишь на тактических целях и доведет проект до релиза. Но такого в проекте D, очевидно, нет :)
Комментариев нет:
Отправить комментарий