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

Lisp привлекает своим минималистичным устройством: это самый простой язык с GC. В нем нет ничего наносного, никаких надуманных конструкций, служащих одной цели. Благодаря этому на нем можно реализовать любую парадигму, любое современное свойство других языков программирования. И даже гармонично объединять такие противоречащие друг другу концепции, как функциональный и императивный стили, динамическую и статическую типизации, ленивые вычисления и ООП.

Программируя на Лиспе, просто невозможно зайти в тупик: язык будет поддерживать тот стиль программирования, который вы сами для себя выберете или придумаете. Понятно, что такой подход требует от программиста самых свежих знаний для правильной и лаконичной реализации своих идей, но никто еще не жаловался на то, что ему приходится развиваться.

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

Роман Клюйков

Модернистская традиция в программировании не является ни редкой, ни бедной, ни вымирающей. Тем не менее ни один из вышеописанных языков массовым и общепринятым не стал; солидная их часть нередко используется для практической работы, но в узкоспецифических областях либо людьми, которым на соответствующем языке так удобно думать, что они готовы терпеть некоторые неудобства.

«Оторванность от реальности», свойственная «модернистским идеям», всегда мешала их выходу на «широкую публику» — как напрямую (непонятность), так и косвенно, через вопросы производительности («если язык программирования не естествен для архитектуры компьютера, то чего будет стоить их взаимодействие?»), взаимодействия («как использовать библиотеки на более традиционных языках, коих уже есть много и отказываться от них не хочется?»), наличия программистов («если язык немэйнстримовый, а нам понадобится еще один программист в команду, где мы его возьмем?») [Интересно, что мэйнстрим часто и с удовольствием принимает побочные продукты развития «модернизма» — как технологические решения, вроде сборщика мусора (Lisp и другие) и компиляции в байткод (Smalltalk), так и организационные (популярные понятия рефакторинга, экстремального программирования родились в сообществе Smalltalk)]. Здесь можно провести параллель с судьбой мэйнфреймов и прочих специализированных компьютеров: есть случаи, в которых «вроде бы все понимают», что случай сложный и нужно использовать специальные мощные решения, но «стоимость» этих решений (включая затраты по внедрению, подбору соответствующих специалистов, интеграции со «стандартными частями») такова, что «мы уж сделаем как обычно».

Но и у «как обычно» есть свои пределы. При попытке эти пределы раздвинуть (а она неизбежна, прогресс-то не удержать) немэйнстримовым странным идеям, как драгоценным винам, настанет свой черед. О чем далее.

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

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

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

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

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

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

Цитата

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

Культура использования «скриптовых языков» («языков сценариев») характерна для мира Unix и смежных миров, где пользователь операционной системы по определению немножко программист. Эта культура подразумевает написание повседневных программ для автоматизации простых действий; немалая часть пишется прямо в командной строке и нигде не сохраняется; другие пишутся единожды, тестируются и впоследствии выполняются многократно, входя в состав «багажа» пользователя. Для скриптовой культуры характерно беззаботное отношение к структуре программы, ее скорости и даже логичности, при крайне заботливом отношении к лаконичности и выразительности.