Компании Kodak и Exclaim запустили совместный сервис для печати «мобильных» фотографий. С любого Brew-совместимого телефона можно быстро скинуть фото на сайт KodakGallery.com, отредактировать и заказать отпечатки. О поддержке сервиса в США уже заявили Sprint и Verizon. Месяц пользования службой обойдется в 4 доллара. ТБ

Единый ключ, что правит всем

Автор: Киви Берд

В длинной и поучительной саге о преодолении AACS, системы защиты контента на видеодисках высокой четкости, открыта, похоже, новая интересная глава. Как показали последние результаты анализа, коллективно проводимого участниками веб-форума doom9.org, внешне грозная защита имеет не просто слабости, а вопиющие прорехи, наличие которых в сильной, вообще говоря, криптосхеме рационально объяснить пока никто не может. В частности, участник форума, скрывающийся под псевдонимом Arnezami, обнаружил, что в сложной и многоуровневой системе защиты дисков HD DVD имеется один ключ, processing key, который позволяет получать индивидуальные ключи названий (title keys), а значит, и доступ к зашифрованному контенту, для всех выпущенных на сегодняшний день дисков. Более того, вскоре выяснилось, что этот же самый ключ обработки подходит и для расшифровки всех фильмов на дисках Blu-ray… Единственное, что выяснить не удалось, так это по чьей инициативе столь вопиющая оплошность была заложена в конкретную реализацию AACS, запущенную на рынок.

Чтобы стала более или менее понятна суть открытия, рассмотрим некоторые детали управления ключами в криптосхеме AACS. Любому плееру — аппаратному или программному — для воспроизведения HD-видеодисков присваиваются секретные ключи устройства (device keys). Каждое устройство использует эти строго индивидуальные ключи для вычисления гораздо более многочисленной группы ключей обработки (processing key). В свою очередь, каждый видеофильм, защищенный AACS, зашифрован своим уникальным «ключом названия», и множество копий title key, зашифрованных разными ключами обработки, хранится в специальном разделе на оптодиске (HD DVD или Blu-ray). Чтобы воспроизвести такой диск, плеер определяет, какую из копий title key он может расшифровать, и использует свой ключ устройства для вычисления необходимого ключа обработки, а тот, в свою очередь, позволяет расшифровать ключ названия и получить доступ к контенту для воспроизведения.

Эти три типа ключей имеют разную ценность с точки зрения безопасности и противостояния вскрытию. Разумеется, атакующей стороне наиболее интересны и полезны ключи устройства. Если вы их знаете, то можете расшифровать любой диск, воспроизводимый плеером. Поэтому для защиты device keys предприняты максимальные меры безопасности и разработан хитрый механизм определения и блокирования скомпрометированных ключей такого рода. Ключи названий наименее полезны, поскольку каждый из них годится для расшифровки лишь единственного фильма. Ключи обработки занимают по ценности промежуточное положение, однако они нигде не хранятся — ни в плеере, ни на диске, — а вычисляются на одном из этапов подготовки фильма к воспроизведению. Поэтому их добыча атакующей стороной представлялась наиболее проблематичной, по крайней мере теоретически. На практике, однако, все оказалось иначе.

Ни одного ключа устройства на сегодняшний день, насколько известно, публично не скомпрометировано. До появления работы Arnezami все успешные случаи обхода защиты AACS так или иначе были связаны с отысканием ключа названия в оперативной памяти компьютера при воспроизведении фильма программным плеером (WinDVD). Понятно, что подобные атаки весьма замысловаты с технической точки зрения. А для человека, далекого от анализа дампов памяти, единственная возможность сделать резервную копию HD-диска сводилась к поиску в Сети уже вскрытого и опубликованного кем-то title key для данного фильма.

Но затем появился Arnezami, который придумал иной ход — анализировать не память, а канал обмена информацией между HD DVD-приводом и компьютером. Arnezami справедливо предположил, что в таком канале информационная избыточность намного меньше, чем в оперативной памяти, а значит, легче выявить и формируемые при обработке ключи. Чтобы длинная история стала покороче, Arnezami применил общедоступную программу-сниффер для анализа передач по USB-каналу (SniffUSB.exe) и действительно сумел выделить сгенерированный плеером processing key для имевшегося у него фильма (King Kong). Но главное — попутно, с помощью соратников по форуму, неожиданно выяснилось, что этот же ключ обработки подходит и для всех остальных фильмов, выпущенных на дисках HD DVD. А также и для всех проверенных фильмов на дисках Blu-ray. Что, вообще говоря, из спецификаций AACS следовать не должно.

Согласно этим спецификациям, каждый плеер имеет уникальный набор из нескольких сотен device keys, на основе которых может быть вычислено несколько миллиардов ключей обработки. В принципе, processing keys вполне могут совпадать для разных плееров, но при столь внушительном их числе каждый конкретный ключ обработки по законам теории вероятностей должен совпадать лишь у небольшой доли плееров по всему миру. А каждый конкретный фильм, в свою очередь, имеет на диске список идентификаторов тех ключей обработки, которые могут расшифровать контент, — то есть любого из перечисленных processing key достаточно для расшифровки title key и доступа к контенту.

По причинам, которых пока никто не понял, все выпущенные на рынок диски имеют один и тот же набор идентификаторов для 512 ключей обработки. Это и означает, что установленный Arnezami ключ подходит для расшифровки всех дисков.

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

ТЕМА НОМЕРА: История, порезанная тонкими ломтиками: Языки программирования. Вдоль и поперек

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

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

Если бы «язык программирования» был всего лишь инструментом, вроде столярного, то очевидно, что за столь долгий срок (история развития языков программирования, если считать, к примеру, от первого Fortran’а, насчитывает больше полувека) должны бы возникнуть какие-то устоявшиеся «формы инструментов на каждый день» — по одной-две для каждой задачи (молоток, пила, отвертка), и дальнейшее развитие было бы лишь непринципиальным осовремениванием этих инструментов (бензопила, электропила, отвертка с моторчиком).

Но программисты — люди странные. Как правило, язык программирования они воспринимают именно как язык — в первую очередь средство для мышления и выражения мыслей, а потом уже все остальное [Классическая работа на эту тему — «Notation as a Tool of Thought» («Нотация как способ мышления», 1979) — лекция, прочитанная автором языков APL и J Кеннетом Айверсоном при получении Тьюринговской премии]. Отсюда — великое множество языков, «языковые войны», любовь и ненависть, страх и отвращение…

И все же, несмотря на то что существуют тысячи [Если кому-то оценка «тысячи» покажется преувеличенной, порекомендуем ему посетить сайт «Энциклопедии языков программирования» http://hopl.murdoch.edu.au, где на момент написания статьи любовно каталогизированы 8512 языков программирования] языков программирования, и десятки, если не сотни из них активно использовались и используются для написания софта и обучения, — в любой период времени существует всего несколько (три-пять) языков «общеизвестных» и «используемых буквально всеми»; эту группу принято называть мэйнстримом, основным направлением и главной тенденцией индустрии. В разное время и в разных отраслях мэйнстримом считались (считаются) Fortran, C, C++, Java, C#, PHP…

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

В оппозиции к «классицистическим» языкам всегда находились языки программирования, авторы которых основывались на собственных концепциях, не желая ограничиваться «естественными для компьютера» условиями; зачастую (но не всегда) идеологическая стройность ставилась выше практичности и вообще применимости к реальным задачам. Такие, условно говоря, «модернистские» языки (Smalltalk, Lisp, Haskell, Prolog) выглядят непривычно для «традиционного» программиста, их изучение требует определенных усилий [Интересно, кстати, что существует довольно распространенное среди программистов мнение: «профессиональный программист легко и быстро освоит любой новый язык, потому что все языки, в общем-то, похожи». Как правило, к этому мнению склонны именно программисты «классицистической» школы, и в ее рамках оно действительно верно; в противоположность этому изучение совершенно незнакомого модернистского языка обычно требует немалых усилий и времени], но и значительно расширяет кругозор и заставляет изменить взгляд на программирование как таковое. «Модернистский» подход предлагает «взгляд на программирование с другой стороны» — который, как предполагается, дает программисту возможности совершенно иного уровня. Благодаря своей непривычности и концептуальной новизне, «модернистские» языки участвуют в «общем прогрессе индустрии» опосредованно: в мэйнстрим, как правило, проникают не сами языки, а их отдельные концепции и подходы.

Диффузия идей модернистских языков в программистское сообщество происходит с двух направлений — через постепенное изменение «классицистических» языков и через появление языков абсолютно новых, которые можно назвать постмодернистскими [Мы не станем дальше углубляться в искусствоведческую метафору: определения программистского рококо, романтизма, экспрессионизма, кубизма и абстракционизма оставим в качестве развлечения для читателя] (OCaml, Python, Ruby, Scala). «Постмодернистские» языки выходят за рамки стилей и парадигм, смешивая старые и новые идеи в разных пропорциях; зачастую жертвуют концептуальной целостностью ради выразительности и поливариантности возможностей. На уровне отдельных «фраз» многие из постмодернистских языков выглядят просто и понятно любому программисту, отчего их проникновение в мэйнстрим идет куда легче, чем у «более идейных» предшественников. А тем временем и сами мэйнстримовые языки стремительно впитывают новые идеи: подобно миру искусства, в мире программирования широкое наступление постмодернизма характеризуется смешением стилей и парадигм до их полной неразделимости.

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

И последнее. В соответствии с главным принципом киберпанка «будущее уже здесь, просто оно неравномерно распределено» — разные течения в программировании очень трудно разделить хронологически; первый модернистский язык программирования — Lisp — один из старейших (1958 год, из общеизвестных старше только Fortran), да и очевидно постмодернистский Perl скоро справит двадцатилетний юбилей. Поэтому деление языков программирования (и темы номера) на «классицизм», «модернизм» и «постмодернизм» происходит скорее «вдоль» истории, нежели «поперек».

С этим и начнем.

Генеральная линия: От Fortan до C#

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

Как уже было сказано, подавляющее большинство языков программирования из «настоящего мэйнстрима» ведут свою идеологическую родословную напрямую из машинного языка/ассемблера. Конечно, по этому пути они успели зайти далеко, но каждый следующий шаг был лишь логическим продолжением предыдущего.

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

Господствующая парадигма [Любим мы это слово. По большому счету, оно означает «подход», «модель построения программы или ее частей», «способ думать об архитектуре программы» — что-то в этом духе] — программирование императивное: программа — суть набор инструкций «сделай то, потом сделай это», результаты действий сохраняются и изменяются в именованных ячейках — «переменных». Отслеживая историю развития промышленного программирования, можно заметить, что все новые «победившие» языки развивали, а не опровергали эту парадигму.

Первым [Попытки «автоматизировать программирование» были и до Фортрана — «язык» A-0 для компьютера UNIVAC (1952), экспериментальный «транслятор формул», созданный в MIT (1954); но эти реализации показывали чудовищную неэффективность сгенерированного машинного кода, что породило стереотип «никакая автоматизация не сможет заменить человека-программиста, пишущего на ассемблере». Фортран этот стереотип разрушил] реально используемым высокоуровневым языком программирования стал Fortran [Имена ранних языков программирования, как правило, писались большими буквами (FORTRAN, COBOL, ALGOL, LISP…). Причина тут не в склонности к аббревиатурам (довольно вымученным, вроде FORmula TRANslator), а убогость тогдашних средств ввода/вывода, зачастую оснащенных только шрифтами с заглавными буквами. «Как правильно» писать название языка — иногда непонятно и самим авторам, пишут и так и эдак. Мы предпочли вариант, более симпатичный с типографской точки зрения (кроме случаев, когда название языка — явная аббревиатура: PL/I, PHP)] (первое описание — 1954, первая реализация — 1957). В немалой степени перво-Fortran — это «подсахаренный» ассемблер; но это был огромный шаг вперед, хотя бы в том смысле, что вычисление A+BхC можно было записать так, как понятно математику, а не как набор операций по загрузке значений в регистры и вычисления ответов в других регистрах.

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

Из первоязыков еще стоит упомянуть Cobol (1959), чудовищный как язык, но крайне успешный как платформа для создания бизнес-приложений. Что показательно.

Следующее десятилетие — эпоха экспериментов на ниве создания «самого лучшего языка». В широком использовании продолжают царствовать Fortran/Cobol, к ним добавляются языки класса «все-все-все-в-одном» PL/I и CPL [В этот же период созданы Lisp и Snobol, речь о которых — в следующей статье], тяжелые и для изучения, и для реализации. В районе 70-х происходит первая «большая чистка»: парк компьютеров растет лавинообразно, возникает необходимость в языках простых и практичных, которые легко выучить, легко реализовать под различные аппаратные платформы, легко писать и читать код; при этом возрастает количество «программ-ради-программ», не решающих некую бизнес-задачу, а облегчающие работу с самим компьютером.

Си вкупе с Unix; разномастные Бейсики как встраиваемые языки для первых домашних (и мелких недомашних) компьютеров; Pascal в Apple II/Apple III, чуть позже Паскали от фирмы Borland для простого написания программ под DOS, Windows — все это языки весьма простые [Basic, в частности, настолько прост, что даже структурного программирования в нем не было. Зато это давало возможность сделать крайне нетребовательную к ресурсам реализацию языка, что поспособствовало его распространению на «несерьезных» компьютерах. С ростом ресурсов этих компьютеров (и запросов программистов) структурность в Бейсике появилась (в середине 80-х)] и практичные; это, по большому счету, те языки, с которыми программирование стало действительно массовым занятием.

По мере расширения круга задач, решаемых на «простых» языках, количества повторно используемых библиотек и «времени жизни» этих библиотек стали возникать концепции более сложного структурирования кода. Самая популярная из них — объектно-ориентированное программирование; совмещение концепций «набора процедур и данных (модуля)» и «типа данных со сложной внутренней структурой» дало понятие «класса» и «объекта» [Большая часть концепций классического ООП была разработана в середине 60-х в рамках работы над языком Simula (Ole-Johan Dahl, Kristen Nygaard). Судьба его достаточно близка к судьбе Алгола: разработанные концепции были приняты и воплощены во многих успешных проектах, но сам язык использовался весьма ограниченно]. Мэйнстримовая разновидность ООП [О более радикальном наборе концепций с тем же названием — в следующей статье.9 Интересно, что другая разновидность «объектно-ориентированного C», известная под именем Objective C и зачастую воспринимаемая как забавный курьез, была языком вполне постмодернистским, смешавшим концепции классического C и модернистского Smalltalk. Распространение этого (и других «странных») языков исключительно в мире Apple весьма показательно] — естественное эволюционное развитие структурно-императивного подхода. Неудивительно, что и объектно-ориентированные языки, принятые «широкими массами», были естественным развитием все тех же C, Pascal, Basic — Visual Basic, C++ [Интересно, что другая разновидность «объектно-ориентированного C», известная под именем Objective C и зачастую воспринимаемая как забавный курьез, была языком вполне постмодернистским, смешавшим концепции классического C и модернистского Smalltalk. Распространение этого (и других «странных») языков исключительно в мире Apple весьма показательно], Object Pascal (позже Delphi).

Далее мэйнстримовая, структурная парадигма некоторое время дополнялась (например, шаблонами C++, позволяющими писать «обобщенные» классы и «обобщенные» алгоритмы). Но картина мира вновь начала меняться, что привело к очередной «большой чистке» языков и смене расклада, двадцать лет казавшегося незыблемым. По своей важности эти перемены близки к событиям, в результате которых Fortran, Cobol и PL/I сменились Cи, Бейсиком и Паскалем.

Причин тому было много, так что нельзя выделить одну, главную. Важнейшие, видимо, таковы: рост производительности железа, с одной стороны, и востребованности программистов (даже неквалифицированных) — с другой. Поскольку надежность софта становится важнее его быстродействия [В определенных, естественно, пределах. Тем не менее некогда одна из важнейших целей разработчиков C++ — «почти бесплатность (по производительности)» новых концепций — стала анахронизмом]; возникновение и популяризация компьютерных сетей «для всех» (в том числе и Интернета/веба), в результате чего «сетевое программирование» стало всеобщей деятельностью. С точки зрения пресловутых «парадигм» программирования важнейшая тенденция «нового времени» — компонентно-ориентированное программирование: независимые друг от друга компоненты могут быть написаны на разных языках, поставляться в скомпилированной форме, заменяться на лету, взаимодействие между ними должно быть легким, надежным и масштабируемым.

Попытки использования «компонентного» стиля без смены языка (COM/OLE, CORBA) выявили некоторые концептуальные трудности; собственно, попытка создать целостное решение этих трудностей и породила платформы Java и .Net [История Java, впрочем, довольно извилиста; в разное время у Sun было множество разных версий насчет «что это мы делаем и зачем оно надо». Тем не менее на сегодняшний день платформа Java — более или менее прямой конкурент и аналог .Net.]. Их свойства (богатая стандартная библиотека, автоматическое управление временем жизни объектов, наличие виртуальной машины и т. п.) — прямой ответ на те вызовы, которые бросает компонентность. Что же касается языков Java и C# [Заметим, что платформа .Net принципиально многоязычна; Java, изначально бывшая «платформой для одного языка», сегодня движется в том же направлении. Тем не менее мы-то здесь рассматриваем в первую очередь историю языков программирования], то их архитектура и дала мне основания назвать происшедшее «второй большой чисткой»: как в свое время C, эти языки стремились вобрать в себя все «хорошие идеи» своего времени, но вдобавок избавиться от наследственной сложности, неоднозначности и других проблем, свойственных C++/Delphi/Visual Basic. Первые версии обоих новых языков таки были проще предшественников, но дальнейшее развитие снова пошло по спирали накопления возможностей и впитывания концепций. Сегодняшний C# — сложный, лаконичный и мультиконцептуальный язык; Java — консервативнее в своем стремлении к простоте и однозначности, но постепенно подбирается к той же планке.

Заполняя пропуски: Концепции

Некоторые языки программирования, близкие «классицизму», но не попавшие в статью, весьма достойны упоминания — хотя бы совсем краткого.

Перечисленные языки — неотъемлемая часть истории развития средств написания программ; тем не менее всеобщая популярность обошла их стороной.

Линейка Pascal. Дело в том, что тот Паскаль, который стал популярным в руках фирмы Borland и который многие из нас учили в школе, от изначальной концептуально-чистой разработки Никлауса Вирта отличается довольно сильно, причем одни считают суть этого отличия «практичностью», другие — концептуальной грязью. Сам Вирт придерживается последнего мнения; будучи невысокого мнения о целостности и чистоте вообще всех широко используемых языков, Вирт и его ученики разработали несколько своих, «чистых и красивых» (Oberon, Modula, Zonnon).

Eiffel. Судьба Эйфелей и их создателя Бертрана Мейерса похожа на судьбу «настоящих Паскалей». Мейерс, как и Вирт, достаточно амбициозен в продвижении своих идей (в основном — об объектно-ориентированном программировании), называя их «единственно правильными»; распространен Eiffel нешироко, влияние его огромно.

Ada. Наконец, создатели самых разных языков программирования среди «вдохновляющих» называют язык Ada, разработанный в 80-х под руководством Пентагона. В каком-то смысле он был аналогом PL/I (не слишком удачная попытка собрать все возможные концепции в одном языке), но некоторые элементы Ada (в частности, ее система типов) оказали большое влияние на мышление авторов других языков.

Итоги: завтра была война

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

Заполняя пропуски: Реализации

Следует упомянуть и еще несколько языковых проектов, вполне классицистических, вполне успешных, но стоящих слегка на отшибе от «главного исторического вектора».

Во-первых, это юниксовский sh и его производные (bash, ksh, csh и далее со всеми остановками). Первые оболочки *nix-систем ведут свой род от Алгола; юниксовский подход к объединению маленьких самостоятельных утилит считается одним из первых примеров компонентно-ориентированного программирования. Среди отдаленных потомков sh — как постмодернистский Perl (о нем мы еще поговорим), так и безусловно классицистический Tcl (а о нем не будем).

Во-вторых, язык веб-программирования PHP — тоже вполне популярен и вполне классицистичен. Его часто называют среди наследников Perl, но от последнего PHP перенял в основном способ именования переменных и область применения; в остальном первые PHP — это почти чистый C (вплоть до имен библиотечных функций). Небывалый успех PHP — это успех не языка программирования (часто критикуемого за концептуальную уродливость), а успех утилиты для легкой разработки веб-приложений. Так и повелось.

Хроники чистого разума

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

Императивная парадигма программирования («сделай то; потом сделай это; если А, сделай Б») не только наиболее естественна для современного компьютера, но и легко воспринимается человеком: простые программы на языках вроде Паскаля без труда пишут и читают пятиклассники. Но такая «естественность» совершенно не значит, что императивный способ — единственно возможный.

Десятое [Других нет] правило Гринспуна

…включая сам Common Lisp.

Следствие Морриса

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

Если смотреть на голую идею программы-как-текста и программирования-как-творчества, отвлекаясь от того печального факта, что «все это надо как-то превратить в машинные коды», то можно прийти к нескольким разным ментальным моделям разной степени абстрактности. Любая из них имеет право на жизнь и, будучи воспринятой, зачастую «открывает новые горизонты восприятия». Неудивительно, что языков программирования, исходящих из таких вот «абстрактных моделей» и оттого совсем не похожих и друг на друга, и на линейку 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

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

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

Потом случилось так, что я сменил место жительства, а с ним и работу. Там, где я оказался, 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

Включение «привычных» средств в язык делает его ближе и привычнее простому пользователю, но не выразительнее. Выразительнее языка, чем 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, приходится много учиться. Чересчур «другой» язык. Много нового. Совершенно иные подходы к обыденным вещам. Это одна из причин его сравнительно низкой распространенности. К сожалению, вряд ли здесь что-нибудь изменится.

Дмитрий Антонюк, Paragon Software Group

Лучшее детям

Предыдущая глава

3

Следующая глава