[prog.flame] Пару слов к получению командой разработчиков Scala гранта в размере 2.3M Euros

Вчера на сайте языка программирования Scala появилась новость о том, что команда разработчиков Scala в EPFL получила грант в размере 2.3M евро сроком на 5 лет. Не абы на что, а на разработку новых подходов к упрощению параллельного программирования.

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

Итак, если пересказать вкратце то, что я понял, то разработчики Scala предлагают подход, который они называют “language virtualization”. За этим красивым названием скрывается довольно простая и совсем не новая (особенно для Ruby-разработчиков) вещь: средства для решения каких-то вычислительных задач следует оформлять в виде DSL-ей на языке Scala, которые затем посредством staged compilation будут преобразовываться уже к оптимизированному низкоуровневому коду.

Что такое staged compilation я лично себе представляю не очень четко. Но термин staging самим Мартином Одерски употреблялся уже давно, еще когда я брал у него мини-интервью (русский вариант). Тогда я попытался нарыть материалов на эту тему, но их было совсем мало и понял я вот что: процесс компиляции специальным образом разделяется на стадии. Результаты работы каждой стадии представляются в стандартизированном виде. А разработчикам предоставляются стандартизированные интерфейсы для написания своих компонентов, работающих на конкретной стадии компиляции. Например, после лексического и синтаксического анализа строится AST и это является результатом первой стадии компиляции. Можно написать свой компонент, который будет получать это AST, анализировать его и вносить в него свои изменения. После чего результирующий AST будет передан следующей стадии компиляции.

Примечание: под “стандартизированным” я здесь понимал стандартизацию в рамках конкретного языка и даже конкретного компилятора для него.

Т.е. грубо говоря, если вам нужна эффективная операция перемножения матриц, то вы можете написать некий DSL на Scala, который будет определять интерфейсы для матриц/векторов и будет содержать переопределенный оператор умножения. Затем вы напишете дополнительный компонент для транслятора Scala, который будет вычленять из исходного кода места использования вашего DSL и будет заменять его на какой-то высокоэффективный низкоуровневый код (кажем, с использованием специализированных процессоров). После чего вы можете распространять свою библиотеку и другим людям не придется заново повторять все это самостоятельно.

При этом, однако, Одерски и Ко уделяют особое внимание безопасности данного процесса. Поэтому они вряд ли дадут доступ напрямую к AST, а потребуют использовать исключительно языковые возможности Scala (может быть, даже за счет расширения языка). В частности, упоминаются такие механизмы, как finally tagless и polymorphic embedding.

Так что, вполне возможно, под staging-ом в Scala будет пониматься что-то вроде специализации C++ных шаблонов.

Повторюсь, что это я так понял предложения разработчиков Scala. Вполне возможно, что я понял не правильно. Поэтому отсылаю интересующихся к первоисточникам:

• сам текст новости с поверхностным изложением;
• небольшая PDF-ка с предложениями разработчиков (6 страниц текста и еще столько же страниц ссылок);
• совместная статья разработчиков Scala и команды из Стенфорда под названием Language Virtualization for Heterogeneous Parallel Computing;
• небольшая презентация (44 слайда) к вышеупомянутой совместной статье.

Теперь мои субъективные впечатления от этой новости.

Во-первых, есть серьезное недоумение. Мне казалось, что вычислительные задачи – это вотчина нативных языков, поскольку эффективность и близость к железу здесь должны находиться на первых местах. Не случайно же в данной области Fortran до сих пор жив и здоров, и не сильно-то его теснит тот же C++. А тут в качестве решения предлагается JVM! Java со своим hotspot-ом, может быть, и хороша на серверах для задачек, где львиную долю времени запросы к БД занимают. Но в числодробилках… Другое дело, если Scala будет использоваться только как host-язык и как язык для компилятора, а трансляция из Scala+DSL-и будет вестись куда-нибудь в Fortran/C++ или в машинный код.

Кстати, такой пример и приводится в статье – DSL под названием Liszt, из которого затем генерируется чистый C++, использующий MPI.

Но что-то я сильно сомневаюсь, что это будет сильно распространено. Хотя бы за счет того, что Scala далеко не единственный язык, который удобен для разработки embedded DSL. Так что основным результатом трансляции Scala-вских DSL-ей будет все-таки Scala и Java-байткод.

Во-вторых, интересно, как на все это дело будет смотреть Oracle. По мне, так Oracle заинтересован в продвижении Java и JVM только в Enterprise. Ну, может быть, еще и на мобильных платформах за счет лицензионных отчислений со специализированных реализаций JVM. Вычислительные задачи – это, вроде как, совсем не вотчина Oracle. А если Oracle не будет затачивать JVM для вычислительных задач (скажем, будет поддерживать очень ограниченный набор платформ для JVM), то какой смысл в вычислительных DSL-ях, если они генерируют в итоге всего лишь Java-байткод?

В-третьих, я вспоминаю лекции нашего университетского преподавателя Быховцева Виктора Емельяновича, читавшего у нас спецкурс по методам конечных элементов (МКЭ). Он рассказывал, что в 80-х годах разработчики вычислительных пакетов для МКЭ ориентировались на создание универсальных инструментов – каждый пакет стремился решать как можно больше задач. Для этого в пакетах были системы метаописаний из которых затем специальные трансляторы по заданным пользователям параметрам генерировали исходники на Fortran/Pascal/C, затем транслировали их в машинный код чтобы получить максимально эффективное конкретное решение. Но затем этот подход благополучно провалился из-за своей монстроузности и, как оказалось, не очень большой эффективности.

Так вот предложения разработчиков Scala сильно мне напоминают эту байку. Типа давайте создадим мега-мета-язык, на котором будут создаваться супер-пупер-DSL-и, которые будут транслироваться в мегаэффективные программы. Что, имхо, не должно сработать.

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

В-пятых, мне не верится в то, что разработчики Scala способны создать что-то промышленное. Ну ученные они, исследователи. Посему не могут создать практичный инструмент. Прототип – запросто, инструмент – нет. И в качестве иллюстрации своей мысли приведу сам язык Scala. Он ведь далеко не молод. Его первая версия появилась в 2003-м году. Т.е. этому языку уже семь лет, а его популярность… Разве что на форумах и в блогах. Тогда как достаточно посмотреть на широту использования тех же Perl, Python, PHP и даже Ruby через семь лет после их появления.

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

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

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