Автор: Виктор Шепелев

После двух полновесных тарелок как бы истории («как бы» - потому что большинство описанных языков используются и в наше время) перейдем-таки к десерту - изменению мира, современным трендам и прочим взглядам в будущее. Только прикинем для начала, откуда это будущее (активное перемешивание старых структурных идей и нестандартных идей модернизма) берется.

За многие годы развития и усложнения традиционные языки отдалились от компьютера; да и сами компьютеры и их производительность стали несколько абстрактным понятием. Автоматическая сборка мусора, которая во времена Lisp была недостатком (по сравнению с ручным управлением памятью), во времена Java и C# стала достоинством, повышающим степень абстракции и надежность программ и обеспечивающим истинную компонентность [Я говорю не о неких мистических «объективных фактах», а о восприятии «средним индустриальным программистом»]. Множество возражений из серии «концептуально хороший язык, но производительность его навсегда ниже допустимого» постепенно отступило.

Вспомним, откуда в принципе растут ноги у структурной, императивной парадигмы: из «естественного» воплощения архитектуры компьютера. Но уже в рамках одного компьютера и одного пользователя сегодняшняя архитектура подразумевает множество «частностей», вроде распараллеливания, многопроцессорных систем, многоуровневых кэшей или, в случае карманных ПК, отсутствия деления на оперативную и постоянную память. То есть языки с моделью «последовательные инструкции, изменяющие ячейки памяти» уже не вполне «соответствуют». Что уж тут говорить о веб- и вообще сетевых приложениях, для которых «один процессор, один поток ввода/вывода, одна память» - вообще малозначимая абстракция.

То есть императивная модель уже нужна больше программисту, нежели компьютеру. Но ведь и программисты изменяются. Повышение темпа прогресса и вообще темпа жизни приводит к тому, что даже самый средненький программист или средненькая программная контора успевает перепробовать столько языков и технологий, что принять новые идеи становится куда проще [Сюда можно приплести еще культуру блоггеров-пропагандистов, способных заинтересовать своих читателей чем угодно. Например, описываемый ниже Ruby своим «подъемом» за пределами Японии очень обязан нескольким уважаемым в программистской публицистике личностям].

Вот и посмотрим, что из этого получается. Начнем все же с веба.

Цитата

Если бы я был умнее чем есть, Ruby мог бы быть намного проще, не потеряв выразительности.

Юкихиро Мацумото

Культура использования «скриптовых языков» («языков сценариев») характерна для мира 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. «Руби на Рельсах» со всеми своими последователями, критиками, отрицателями и фанатами - уже сам совершенно отдельный крупный тренд.

Важно здесь, что культура скриптов («скриптовая парадигма») подразумевает допустимость и даже обязательность разных «ухищрений» для удобства программиста. И это именно та «дырка», через которую в широкие массы пошли необычные идеи. То есть в большой степени это вопрос «подачи»: если функция-как-значение - это не «новая парадигма с серьезной теоретической базой, своей терминологией и новым синтаксисом», а «фишечка такая, чтобы удобней» - то элементы функционального подхода в Питоне оказываются вполне естественными и понятными. А поглощение и использование этой «фишечки», естественно, порождает какие-то вопросы (все-таки идея «новая»), на которые (сюрприз, сюрприз!) могут дать ответы те самые «оторванные от жизни теоретики», занимающиеся функциональным программированием (ах, вот как это называется!) уже лет сорок. И вот пожалуйста: замыкания, продолжения, ленивые вычисления - более или менее прижившиеся элементы «обычных скриптов».