Журнал «Компьютерра» - Журнал «Компьютерра» N 8 от 27 февраля 2007 года (Компьютерра - 676) Страница 11

Если смотреть на голую идею программы-как-текста и программирования-как-творчества, отвлекаясь от того печального факта, что «все это надо как-то превратить в машинные коды», то можно прийти к нескольким разным ментальным моделям разной степени абстрактности. Любая из них имеет право на жизнь и, будучи воспринятой, зачастую «открывает новые горизонты восприятия». Неудивительно, что языков программирования, исходящих из таких вот «абстрактных моделей» и оттого совсем не похожих и друг на друга, и на линейку Fortran-C-Java, — вагон и маленькая тележка.

Появление таких языков часто порождает целые новые течения в «программировании-как-искусстве» — соратников, ненавистников, эпигонов и экспериментаторов; но до поры до времени эти течения оставались далеки от «широких масс». Дальше мы пройдемся с широкой сетью по самым заметным из них.

Так много дурацких скобок [Lot of silly parenthesis — «куча глупых скобок» — старинная шуточная расшифровка названия языка Lisp]

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

Глобальность идеи и легкость реализации Лиспа способствовало образованию многочисленного сообщества «фанатов», использовавших любимый язык где ни попадя. В качестве внутреннего макроязыка разновидности Lisp встроены в Emacs и AutoCAD; одно из первых серьезных веб-приложений (viaweb) было написано на нем. За сорок лет споры о деталях и особенностях, практичности и чистоте привели к появлению бесчисленного множества диалектов, главные — Scheme (более изящный, используется в основном в учебе [До недавнего времени знаменитый курс MIT «Структура и интерпретация компьютерных программ» использовал именно Scheme. Месяц назад Scheme вроде бы заменили на Python. Times, they are changing]) и Common Lisp (в каком-то смысле более практичный, но и менее стройный), есть и «более экстремистские», вроде маленького-практичного newLISP или сверх-концептуально-чистого Qi.

Бывает так: сначала ты «снаружи», вокруг все очень обычное, очень знакомое и скучное. А потом мимо проносится Белый Кролик, при часах и при жилете. Дальше известно что: погоня, несколько минут свободного падения вниз по кроличьей норе — и ты уже «внутри», а из привычного и знакомого остался только ты сам, да и это ненадолго. Такие переживания — когда за поворотом вдруг распахивается целый новый мир — составляют если не смысл жизни, то что-то вроде того.

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

Потом случилось так, что я сменил место жительства, а с ним и работу. Там, где я оказался, Smalltalk — не просто инструмент, а жизненная позиция, и даже предмет поклонения. Несколько недель у меня ушло на преодоление собственных предрассудков. Я считал, что сборка мусора несовместима с гарантированными временными характеристиками, что полиморфные вызовы медленны — а тут у меня на глазах ядро авиационного тренажера бодро крутило цикл расчетов сорок раз в секунду.

Труднее всего оказалось воспринять отсутствие границы между инструментами и разрабатываемой программой. «А вдруг, — рассуждал я, — создаваемая программа сделает что-нибудь не так? Ведь тогда рухнет не только она, но и среда разработки!» На практике все оказалось не так страшно. В частности, все изменения пишутся в специальный журнал (change file), откуда в случае аварии виртуальной машины легко восстанавливаются.

Постепенно я стал понимать, что отсутствие границы между инструментом и созидаемым объектом — это чуть ли не главное, что есть в Смолтоке. Вокруг места, где не проходит эта граница, концентрируются вещи, составляющие дух и душу Smalltalk-системы.

Написание кода в отладчике — не эффектный кунштюк, а удобный и практичный способ программировать, когда можно вживую пообщаться с каждым из участвующих в приостановленном вычислении объектов, а не вспоминать мучительно, как называется нужный метод и что именно он возвращает. Возможность затачивать Инспектор под конкретные типы объектов — не просто полезная особенность, а путь к иному способу думать о графическом интерфейсе, когда каждый объект системы способен говорить с человеком на специфическом диалекте единого визуального языка (первоначальное понимание роли графического интерфейса, которое можно проследить в Smalltalk-76 и в Fabrik, было именно таким; теперь мы возвращаемся к сходным взглядам на новом витке спирали в таких средах, как Morphic и Oberon/Bluebottle).

Самое же главное в Смолтоке — это то, что через него программисты необратимо меняются к лучшему. Можно потом писать хоть на ассемблере, хоть на VBA, но это будут уже другой ассемблер и другой VBA. Знание Смолтока необходимо для глубины восприятия. Необходимо, но, конечно, не достаточно, потому что остаются еще Haskell и Erlang, OCaml и Oz, и Scheme, и еще много других путей вниз по кроличьей норе, прямиком в Страну Чудес.

Борис Беркгаут, компания «Транзас» (Санкт-Петербург), отдел ПО авиационных тренажеров

Академическое стремление иметь математически стройные средства программирования (к которым были бы применимы математические же методы проверки, доказательства, порождения и вывода) привели к созданию концепции декларативного программирования — идеологически стройного описания программы, которое «выполняется» неким умным компилятором-"думателем" [С термином есть некоторая путаница. Языки описания чего-либо, не являющиеся полноценными «языками программирования» (например, HTML/XML), также называют декларативными]. Разновидности (существенно разные): функциональное программирование — программа описывается как математическая функция, зависящая от других математических функций, затем вычисляется; логическое программирование — задается набор предикатов-утверждений, затем результат выводится из этих предикатов; программирование в ограничениях (constraint programming) — задаются только ограничения на результат, а компилятор вычисляет все результаты, удовлетворяющие этим ограничениям.

Из вышеперечисленных разновидностей лишь функциональное программирование воплотилось в широкую семью языков (языки-потомки «первого функционального» ML, максимально «идеологически чистый» Haskell, странный REFAL, практичный Erlang и другие [Lisp и его потомки постфактум тоже считаются функциональными]) и собрало широкое сообщество «функциональщиков». Сегодня термин «функциональное программирование» определяет как изначальную концепцию (программа-как-вычисление-функции), так и более широкий набор концепций (часть из них не являются обязательным свойством функциональных языков, но возникли именно в этой среде): функции как данные, анонимные функции, продолжения (continuations), сопоставление с образцом (pattern matching) и т. п.

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

Включение «привычных» средств в язык делает его ближе и привычнее простому пользователю, но не выразительнее. Выразительнее языка, чем Haskell, я не встречал. До недавних пор у Хаскелла была стратегия «avoid success at all costs», а Тони Хоар печально говорил: «I fear that Haskell is doomed to succeed»; это язык, созданный geek’ами от Computer Science для geek’ов. И поэтому я, при всей любви к Хаскеллу, не могу переключиться на него полностью — без понимания теоретических основ CS я буду знать язык более чем посредственно. Сколько бы популяризаторы ни говорили, что для работы с Хаскеллом не нужны глубокие познания в математике, следует понимать, что потенциал языка будет использован далеко не полностью; дизайн языка и его библиотеки пропитан теорией категорий и универсальной алгеброй.

Глеб Алексеев,

компаниЯ Zoral (Киев)

Одним из критериев оценки языка для меня является лаконичность кода. Haskell — невероятно выразительный и элегантный язык. Дистанция между спецификацией задачи и ее реализацией сильно сокращена. Функции высшего порядка, частичное применение, алгебраические типы данных и сравнение с образцом позволяют писать декларации удивительно близко к оригиналу. Помимо этого вы получаете кучу бонусов, делающих жизнь приятной, — ленивость, строгая типизация без обязательной аннотации типов, полиморфизм. Помню восторг, который я испытал, увидев, что программа после первой же компиляции работала без ошибок. Это было невероятно! Позже я слышал похожие признания от других. TANSTAAFL [ «There Ain’t No Such Thing As A Free Lunch», то есть «Ничего не бывает бесплатно». — В.Ш.]. Для того чтобы начать писать на Haskell, приходится много учиться. Чересчур «другой» язык. Много нового. Совершенно иные подходы к обыденным вещам. Это одна из причин его сравнительно низкой распространенности. К сожалению, вряд ли здесь что-нибудь изменится.