Журнал «Компьютерра» № 8 от 27 февраля 2007 года
Шрифт:
Вспомним, откуда в принципе растут ноги у структурной, императивной парадигмы: из «естественного» воплощения архитектуры компьютера. Но уже в рамках одного компьютера и одного пользователя сегодняшняя архитектура подразумевает множество «частностей», вроде распараллеливания, многопроцессорных систем, многоуровневых кэшей или, в случае карманных ПК, отсутствия деления на оперативную и постоянную память. То есть языки с моделью «последовательные инструкции, изменяющие ячейки памяти» уже не вполне «соответствуют». Что уж тут говорить о веб— и вообще сетевых приложениях, для которых «один процессор, один поток ввода/вывода, одна память» — вообще малозначимая абстракция.
То есть императивная модель уже нужна больше программисту, нежели компьютеру. Но ведь и программисты изменяются. Повышение темпа прогресса и вообще
Вот и посмотрим, что из этого получается. Начнем все же с веба.
Культура использования «скриптовых языков» («языков сценариев») характерна для мира Unix и смежных миров, где пользователь операционной системы по определению немножко программист. Эта культура подразумевает написание повседневных программ для автоматизации простых действий; немалая часть пишется прямо в командной строке и нигде не сохраняется; другие пишутся единожды, тестируются и впоследствии выполняются многократно, входя в состав «багажа» пользователя. Для скриптовой культуры характерно беззаботное отношение к структуре программы, ее скорости и даже логичности, при крайне заботливом отношении к лаконичности и выразительности.
Культура скриптов-сценариев получила мощной толчок с появлением веба и первых веб-приложений. Тогдашняя формулировка веб-приложения — «нечто, получающее несколько параметров и формирующее по ним (текстовую) веб-страничку» — идеальное описание именно скрипта; неудивительно, что самый популярный к тому времени скриптовый язык для обработки строк — Perl — стал и самым популярным языком веб-программирования. Некоторое время «быть веб-программистом» означало «знать HTML, JavaScript и — Perl» (вскоре к этому набору добавился PHP). Веб-программирование как деятельность доступная и популярная, с одной стороны, способствовало широкому распространению «скриптового» подхода, а с другой — изменило концепцию самих скриптов: усложнение веб-приложений, возрастание их объема и используемых ресурсов (сеть, БД, графика и пр.) привело к повышению внимания к логичности и понятности скрипта, к его стандартной библиотеке и т. п.
Так Perl проторил дорогу Python’у — языку, который смешал скриптовый и структурный подходы к написанию программ [При желании в истории «скриптов для веба» можно найти аналогии с начальной историей языков программирования: Perl/Fortran, доказавшие, что это возможно и нужно, PHP/Cobol как «временное помутнение сознания, когда еще никто не знал, как правильно», и Python/Algol, внесшие стройность и логичность. Есть, конечно, и множество отличий]. Лаконичные и логичные, легко читаемые программы на Питоне способствовали его широчайшему распространению, поскольку это легкий язык интеграции всего (Google и NASA), встраиваемый в крупные пакеты (от программы 3D-моделирования Blender до игры Civilization IV), язык для преподавания (см. в предыдущей статье о MIT) и, естественно, язык для веба. Успех Питона открыл дорогу другим «стройным скриптам»: легкой Lua — во встраиваемые скрипты, и Ruby — во все остальные области. В каковых «всех областях» вскоре вспыхнула supernova фреймворка для веб-разработки Ruby on Rails. «Руби на Рельсах» со всеми своими последователями, критиками, отрицателями и фанатами — уже сам совершенно отдельный крупный тренд.
Важно здесь, что культура скриптов («скриптовая парадигма») подразумевает допустимость и даже обязательность разных «ухищрений» для удобства программиста. И это именно та «дырка», через которую в широкие массы пошли необычные идеи. То есть в большой степени это вопрос «подачи»: если функция-как-значение — это не «новая парадигма с серьезной теоретической базой, своей терминологией и новым синтаксисом», а «фишечка такая, чтобы удобней» — то элементы функционального подхода в Питоне оказываются вполне естественными и понятными. А поглощение
То же самое — с концепциями «программа — это данные, изменяемые в любой момент» (здравствуй, Lisp) и «все в программе суть объекты, обменивающиеся сообщениями» (здравствуй, Smalltalk). Время программиста и его fun — главная ценность; ради этих «высоких идеалов» можно и идейные столпы пошатать.
Забавно, что в этом стремительном выходе скриптов на передний план главное назначение «языка сценариев» — написание одноразовых программ сомнительного качества — как-то потерялось. Что породило забавные казусы «самоопределения» — тем паче, что и другие типично скриптовые свойства (вроде интерпретируемости) многим сегодняшним «скриптам» несвойственны (Python, как Java, компилируется в байт-код и выполняется на виртуальной машине; виртуальные машины для Perl и Ruby сейчас разрабатываются соответствующими сообществами и находятся в районе «альфа» и «бета» версий).
Очередная «дырка в заборе» мэйнстрима — как ни странно, 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) и использующихся в основном для обкатки идей, которые впоследствии войдут (или не войдут) в основной язык].