Компьютерра - Журнал «Компьютерра» № 8 от 27 февраля 2007 года

То же самое — с концепциями «программа — это данные, изменяемые в любой момент» (здравствуй, Lisp) и «все в программе суть объекты, обменивающиеся сообщениями» (здравствуй, Smalltalk). Время программиста и его fun — главная ценность; ради этих «высоких идеалов» можно и идейные столпы пошатать.

Забавно, что в этом стремительном выходе скриптов на передний план главное назначение «языка сценариев» — написание одноразовых программ сомнительного качества — как-то потерялось. Что породило забавные казусы «самоопределения» — тем паче, что и другие типично скриптовые свойства (вроде интерпретируемости) многим сегодняшним «скриптам» несвойственны (Python, как Java, компилируется в байт-код и выполняется на виртуальной машине; виртуальные машины для Perl и Ruby сейчас разрабатываются соответствующими сообществами и находятся в районе «альфа» и «бета» версий).

Цитата

Д. Хеймер Ханссен,

создатель ruby on rails

Очередная «дырка в заборе» мэйнстрима — как ни странно, Microsoft. Шаткое положении как-бы-лидера — только и успевай крутиться, и Джаву надо переджавить, и с поднимающими голову скриптами совладать, и Гуглу настучать, и Виндов побольше продать — поневоле вынуждает к инновационности и нос-по-ветру. Отсюда — появление во второй версии C# анонимных делегатов (они же — переменные-функции) и связанных с этим элементов функционального программирования; отсюда же — подъязык LINQ, вводящий в C# 3.0 декларативную нотацию, подобную SQL.

Но важнее даже не это, а принципиальная изначальная многоязычность .Net’а и, соответственно, поощряемые и приветствуемые попытки существующие языки на микрософтовскую платформу портировать и новые, невиданные, создать. Эффект симбиоза ново-старых языковых идей и платформы промышленного качества понятен: для платформы выгода в том, что даются новые инструменты программистам и «импортируется» сообщество соответствующего языка; для самого языка становятся доступными богатые библиотеки .Net’а (особенно актуально для языков с привкусом «академичности», зачастую страдающих от отсутствия элементарных библиотек для индустриальных задач) и — огромное количество готовых пользователей [Все эти выкладки в большой степени относятся и к платформе Java. Понятно, что изначально платформа была «одноязычной», но сейчас (не в последнюю очередь — в результате «гонки платформ» с Microsoft) Sun уделяет много внимания развитию и поддержке других языков на своей платформе].

Одной из целей .Net’а было облегчение интеграции кода на разных языках, а значит, многоязычные проекты на этой платформе более распространены, и теоретически можно основную часть проекта оставить на C#, алгоритмически сложную часть написать на каком-нибудь Haskell.Net или F# (ML-подобный язык), а разные быстрые тесты и служебные задачи, требующие «быстрого и грязного» кода, решать, к примеру, на IronPython.

Понятно, что чем дальше отстоит портируемый язык от традиционных, тем сложнее его бесшовная интеграция с другими языками платформы. Отсюда — некоторые интересные проекты, которые революционные (для мэйнстрима) идеи скрещивают с естественной объектной моделью и привычным синтаксисом платформ Java/.Net. Таких проектов уже немало: к примеру, для .Net’а — питонообразный Boo и многоконцептуальный Nemerle, совмещающий традиционный ОО-подход с функциональными возможностями и выводом типов в духе ML и синтаксическими макросами вроде Lisp’овых [Из не-Lisp’образных языков Nemerle, кажется, единственный, предоставляющий средства такого уровня]; для Java — объектно-функциональный гибрид Scala и Ruby-подобный Groovy [Это не считая экспериментальных языков, являющихся расширениями-надмножествами C# и Java (C-omega, Pizza/PJ) и использующихся в основном для обкатки идей, которые впоследствии войдут (или не войдут) в основной язык].

О широкой известности и применимости таких языков говорить рано, но кое-какие предположения об их судьбе сделать можно.

Языки рода Boo и Groovy, чьи авторы стоят на позициях «скриптовых» (в смысле лаконичности программ и богатого набора «фенечек»), на позицию «скриптов в рамках платформы» как раз и метят. Их роль — быть «клеем» между компонентами, инструментом для «условно одноразовых» программ (тестов для отладки компонентов на «серьезных» языках) и вообще инструментом для «гибких» подходов. В этом контексте их будущее видится относительно безоблачным, как и будущее «портированных» IronPython/Jython, JRuby/RubyCLR.