Внимание! Прочитайте, пожалуйста, текст в правой колонке (внизу).
Внимание! Прочитайте, пожалуйста, текст в правой колонке (внизу). Внимание! Прочитайте, пожалуйста, текст в правой колонке (внизу). Homepage Карта сайта Версия для печати

Джентльменский набор Web-разработчика   Ларри Уолл о Perl6   Наблы Система Orphus
 

1. Ларри Уолл: Откровение Первое. Добро, Зло и Смута

[29 декабря 2001 г.]

  То, что сделал Ладен с Уолл-стрит, сравнимо с тем, что Уолл сделал с синтаксисом Perl 5.
Дмитрий Мельник

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

В этой статье рассматривается ни что иное, как дизайн Perl 6. Более точно, начатки этого дизайна, потому что процесс совершенствования, конечно же, продолжится и после того, как я выскажусь на этот счет. Я не всеведущ, несмотря на то, что молва привыкла утверждать обратное. Роль бога, пожалуй, слишком уж велика для меня. И все же кто-то должен выполнять его обязанности, так что я попробую как-нибудь выкрутиться. Да, и я ожидаю от вас всех, что вы поможете мне создавать историю. Каждый из вас может внести свою лепту в общее дело.

Если вы посмотрите на историю Perl 6 с этой необычной точки зрения, вы поймете, почему статья названа «Добро, Зло и Смута». Работа над RFC в минувшем году велась весьма бурно. Мозговой штурм — вообще дело заведомо немирное и весьма провокационное (отсюда и смута). Нет, все на удивление осталось в рамках приличий, но вот предложения по этим RFC были какими угодно, только не логически согласованными. Честно говоря, и сами документы RFC стали затрагивать практически все темы, но местами ситуация напоминает решето: оно на 90% состоит из дырок, но, тем не менее, зовется все же решетом, а не дырой. Есть противоречивые RFC, а есть и «заглушки», для которых документы еще не созданы. Многие документы выдвигают настоящие проблемы, однако уходят в сторону, когда дело доходит до их решения. Некоторые RFC подобны беспомощному доктору: ставят диагнозы, однако даже и не пытаются лечить.

Чайник 

RFC (Request for Comments, можно перевести как «комментарии и требования») — это небольшие документы, описывающие те или иные моменты в спецификациях программ, протоколов и т. д.
Здесь и далее примечания — мои [dk].

Я также открыл Первый закон Ларри о Реорганизации языков: «Все ждут наставлений свыше».

Это была часть о Смуте. Теперь о Зле. Оно заключается в том, что я наивно надеялся взять все RFC и разработать по ним структуру языка за две недели. Я уже начал думать, что смогу классифицировать все RFC примерно поровну на три категории, относящиеся, соответственно, к Добру, Злу и Смуте. Ха, не тут-то было! Вдруг выяснилось, что львиная часть документов принадлежит категории Смуты по простой причине: RFC Добра часто в чем-то ошибочны, а RFC Зла нередко выявляли проблему и просили немного о ней подумать, хотя предложенный ход мысли был совершенно неверным.

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

Но теперь мы наконец-то подходим к Добру (я надеюсь). После длительного и серьезного обдумывания отдельных документов RFC мои мозги вскипели. Не зная, как начать думать о них как о совокупности, до меня вдруг дошло, что наиболее удобный ход мысли как раз совпадает с порядком глав в моей книге (ее еще называют «Camel Book»). То есть, оказалось, что такой порядок глав как раз и минимизирует «забегания вперед» при описании Perl, так что обсуждение Perl 6 почти в той же самой последовательности будет минимизировать число вопросов, которые мне необходимо решить раньше, чем я их решу. Уф!..

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

Мы поговорим здесь о следующих RFC:

RFC  PSA  Title
---  ---  -----
 16  bdb  Не нужно принуждать пользователя по 
          умолчанию использовать warning и strict.
 26  ccb  Именованные операторы и функции.
 28  acc  Perl должен остаться самим собой.
 73  adb  Все встроенные функции Perl должны 
          возвращать объекты.
141  abr  Это последнее глобальное изменение языка.

Чайник 

Как видно, количество RFC о Perl 6 очень велико — более 300. Вам не обязательно читать их все: по-моему, достаточно и статей Лари Уолла на эту тему (одну из них вы сейчас видите перед собой). При желании можно ознакомиться с документами, ссылки на которые имеются в каждом подзаголовке. Впрочем, на всякий случай привожу адрес, где можно найти полный список RFC: http://dev.perl.org/rfc/.

Колонка PSA обозначает «Problem, Solution, Acceptance» (Проблема, Решение, Одобрена ли). Проблемы и степени их разрешенности «проградуированы» по шкале от a до f, и очень часто мы можем видеть, что величина проблемы больше, чем степень ее разрешенности. Мера «одобрения» решения может обозначаться одной из следующих букв:
  • a — чистосердечно одобрено;
  • b — одобрено с несколькими «но»;
  • c — принято с серьезными предостережениями;
  • r — решение отклонено (Rejected).

Иногда я могу добавить сюда также d, что означает «Отложена» («Deferred»), если я действительно думаю, что еще рано что-то решать.

RFC 141: это последнее глобальное изменение языка

Я по-настоящему был склонен принять этот RFC, однако потом все же решил его отклонить «за недостаточностью улик». В апокалиптической литературе число 7 означает завершенность, в то время как 6 — синоним несовершенства. Наверное, мы не остановимся, пока не дойдем до версии номер 2*PI, как советует RFC, но более вероятно, что это произойдет в версии 6.6.6, которая будет еще более несчастливой.

Так что Perl 7 будет последним улучшением Perl. Фактически, Perl 7 окажется столь законченным, что он будет нуждаться целиком в глобальной перестройке. Итак, Perl 6 — просто прототип для Perl 7.

И хотя, положа руку на сердце, я согласен с настроением 141-го RFC, я отклоняю его, потому что вся эта нумерология чересчур зрелищна. Я хочу, чтобы Perl был языком, который мог бы продолжать развиваться, лучше удовлетворяя потребности людей, нуждающихся в нем. И цифры тут ни при чем.

Я бы хотел немного осветить некоторые моменты, которые можно выловить из совокупности RFC при их внимательном прочтении. Первое: Perl будет поддерживать несколько синтаксисов, отображенных на одну семантическую модель. Второе: эта модель будет мультиплатформенной, то есть реализованной на нескольких платформах.

Множественный синтаксис звучит довольно сердито, однако он действительно необходим на этом этапе эволюции языка. Некоторое время мы уже имеем мультисинтаксис в Perl 5; каждый раз, когда вы используете прагмы или модули, вы изменяете язык под себя. Конечно, до тех пор, пока в фиксированной (обычно верхней) части модуля не описано явно, какую версию языка вы собираетесь использовать, такая схема будет порождать проблемы.

Действительно показательный пример, как поддержка множественного синтаксиса помогает развитию языка, — это сам процесс перехода с Perl 5 на Perl 6. См. обсуждение RFC 16 дальше.

Множество поддерживаемых платформ — необходимое условие существования языка в этом мире. Реализация Perl 6 не будет ограничена платформами, для которых возможно программировать на Си. Perl можно будет запускать и на других типах виртуальных машин, например, с поддержкой Java или C#.

RFC 28: Perl должен остаться самим собой

Послушайте мою голубую мечту: людям, которым нравится Perl 5, понравится и Perl 6. Иными словами, я надеюсь, что Perl будет продолжать являться универсальным инструментом для всех людей, ведь эта концепция — один из краеугольных камней Perl.

Когда я обдумывал смысл этого RFC, я обнаружил в нем несколько значительных подводных камней. Я считал, что нечего бояться наступления ситуации, когда некоторые программистские парадигмы войдут в противоречие с новым дизайном языка. Этого просто не может случиться. Та часть, которая делает Perl языком Perl, умышленно построена на смеси разных парадигм, учитывающей каждую из них. Можно сказать, что Perl не собирается навязывать вам никаких догм.

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

Например, можно сильно упростить жизнь, если мы сможем собраться с духом и отказаться наконец от рокового различия между выражениями вида @foo[] и $foo[]. Конечно, в этом случае мы потеряем возможность получения срезов, но, мне кажется, она может быть заменена каким-нибудь другим механизмом получше. Трактуя @foo как нечто, что в скалярном контексте возвращает ссылку на массив, мы можем заставить контекст всегда быть именно ссылочным, что среди прочего исправит абсурдный синтаксис текущей версии Perl, по которому $foo[] и $foo->[] означают разные вещи. Об этом мы будем много рассуждать во Втором Откровении, когда начнем «анатомировать» идею RFC 9.

RFC 28: не нужно принуждать пользователя по умолчанию использовать warnings и strict.

Я в нерешительности, какую же сторону принять в споре: включать в настройки Perl по умолчанию эти директивы, или же нет. Оба варианта имеют свои преимущества. И, если вы вчитаетесь в дискуссию этого RFC, там снова и снова с яростью повторяются сильные аргументы «за» и «против». Особенно развернулись споры вокруг недостатков программ, использующих strict, однако заглавие RFC занимает нейтральную позицию, поэтому оно и обсуждается в этой статье.

Я буду говорить о директиве strict (use strict) и предупреждениях (use warnings или ключ -w), а также о принуждении к чему-либо вообще, однако сначала я хотел бы оговориться насчет общих вопросов дизайна языка. По-моему, RFC (и те, против кого оно выступает) — хороший пример, почему некоторые создатели языков, как и я, вынуждены выступать в роли судей, хотя они и правы и неправы одновременно. Многие RFC занимают одностороннюю позицию и упорно отстаивают ее, но пасуют, когда дело доходит до выявления компромиссных частей проблемы. Конечно, для RFC верно, что он должен рассматривать только один вопрос и не пытаться описать все на свете (на то он и RFC). Однако, так как все эти документы были написаны людьми, у которых в голове «засел» стереотип Perl 5, они не могут идти на компромисс, даже когда рассуждают о конкретных вопросах Perl 6.

Мне кажется, очень важен вопрос, можно ли будет автоматически переводить код Perl 5 на Perl 6. Например, Perl часто используется для создания коротких «однострочных» скриптов прямо в командной строке (их еще иногда называют «заклинаниями»). Не существует по-настоящему удобного способа переводить на Perl 6 такие «заклинания», так что предложение всегда по умолчанию включать режим strict и ввести новый ключ командной строки, означающий «no strict», не подходит.

Очень близко тут стоит вопрос, как Perl сможет определить, что его случайно «накормили» кодом для Perl 5, а не для Perl 6. Будет плохо вставлять в рабочий код семантическое «клеймо», свидетельствующее о новой семантике. Ответ, я надеюсь, в том, что это такая ситуация будет невозможной по определению. Таким образом, по умолчанию Perl 6 должен ожидать именно кода пятой версии, пока его не переключат в другой режим. Как это сделать?.. Достаточно ввести в язык новые ключевые слова, которых нет в Perl 5, и которые будут однозначно свидетельствовать о начале кода Perl 6.

Как известно, у любой задачи есть правильное и неправильное решение. Так и тут. Меня, например, очень раздражает, как фирма DEC «расширила» язык BASIC/PLUS, чтобы он поддерживал длинные имена переменных. Они заставили программистов, использующих такие переменные, вставлять в программы первой командой ключевое слово EXTENDED. С той поры и по сей день каждая программа на BASIC/PLUS начинается со слова EXTENDED. Я точно не знаю, причислить это к Злу или Смуте, но уж точно не к Добру.

Одно из решений — изменить что-то такое, что встречается в любой программе. Если вы сходите на прогулку в CPAN и посмотрите на все исходные коды модулей, которые там хранятся, что вы увидите?.. Конечно же, директиву указания пакета, package. Вот этим-то мы и воспользуемся.

По cему я объявляю, что директива package в верхней части файла на 100% точно свидетельствует о том, что дальше идет код на Perl 5. Если же вы хотите написать модуль или класс с использованием нового синтаксиса Perl 6, вы всегда используете слова module или class. Я еще точно не знаю, каким именно будет синтаксис описания модулей и классов, зато абсолютно уверен, что при этом будут создаваться новые глобальные области видимости, по аналогии с тем, как это происходит сейчас при использовании пакетов.

Таким образом, проблемы теперь могут быть решены одним махом — простым объявлением, что все классы и модули будут по умолчанию создаваться с включенными директивами warnings и strict. Но следует помнить, что в главной программе (а также в «заклинаниях») используется синтаксис Perl 5, а значит, они запускаются с выключенным режимом strict. Мы все еще обсуждаем, как же Perl будет различать пятую и шестую версию в главной программе (может быть, с помощью прагмы «use 6.0»?), и должна ли основная программа по умолчанию интерпретироваться в режиме strict (я думаю, нет). Но уже сейчас видно: инструкторы курсов по Perl смогут с чистой душой грозиться покарать ученика, который забыл поместить «module Main» в свою программу, потому вместе с этим он забыл включить предупреждения и strict.

Другой вариант решения проблемы вытекает из метода использования глобальных настроек — например, для сайта или проекта. Люди обычно страстно желают, чтобы файлы, используемые в их программах, находились и загружались из нужного места автоматически, однако лично я этому горячо сопротивляюсь, потому что подобная «свобода» делает программы плохо переносимыми. И непонятно, какая конкретно часть программы не переносима — может быть, самая малость?.. С другой стороны, если все конкретные «непереносимости» известны, они не являются таким уж большим злом, так что у нашего гипотетического инструктора нет причин не требовать, чтобы программы начинались с чего-нибудь вроде «use Policy;».

И опять мы сталкиваемся с тем, что подобные рассуждения затрагивают довольно глубокие «слои» дизайна языка. В самом деле, есть проблема: написать такой модуль Policy на Perl 5 очень сложно — получится не обычный модуль, а скорее пcевдо-модуль, ведь он пытается включить для вызвавшего контекста режимы «use strict» и «use warnings», но «обычный» модуль не может этого сделать! Так что одна из вещей, которую нам придется включить в Perl 6, — это возможность писать мета-модули. Их вызовы будут выглядеть обычно, как и при использовании привычной директиве use, но модуль должен иметь право что-то «переключить» в Perl на благо пользователя, для проекта или сайта. (Что бы ни говорили, это все-таки шаткая концепция).

Так что, соглашусь я или нет с этим RFC, зависит от того, как понимать фразу «по умолчанию». Я буду понимать ее, как мне удобнее. Вот вам и контекстная чувствительность в работе...

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

RFC 73: все встроенные функции Perl должны возвращать объекты

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

Мне кажется, что здесь поможет лучший механизм поддержки абстрактных типов данных, которые представлены, например, структурами Си. Действительно, не получается легко перевести такие структуры (например, struct tm) на язык хэшей. Иными словами, было бы гораздо проще работать, если бы структуры поддерживались самим языком Perl напрямую. Мы можем их сделать похожими на объекты, чтобы доступ к полям осуществлялся через методы, как будто это «настоящие» объекты. Скорее всего, это будет требовать определенных накладных расходов, главный из которых — затраты на управление памятью для структур, что отнимает довольно много времени, даже несмотря на оптимизации.

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

print scalar localtime;
будет продолжать работать без всяких изменений, хотя функция localtime и возвращает объект в скалярном контексте.

RFC 26: именованные операторы и функции.

А вот и еще один RFC, который обсуждается тут только потому, что его больше негде обсуждать.

Мне этот RFC показался необычным, потому что в его секции «abstract» предлагается нечто более радикальное, чем описывается в разделе «description». Если не принимать в расчет секции «abstract», в общем-то, я согласен с документом. Ведь это особенность Perl 5, что мы отличаем операторы от функций в основном по виду, как операторы вызываются, а не по тому, как они определяются. Один момент, в который RFC может внести ясность, это то, что Perl 5 различает два типа именованых операторов: унарные и списковые. Они сильно различаются, потому что имеют различные приоритеты. Мы будем обсуждать приоритеты в Третьем Откровении, но, мне кажется, мы должны объединить эти два вида операторов. (Чтобы раздразнить ваше любопытство, я скажу, что можно упростить таблицу приоритетов Perl с 24 уровней до 18 за счет разрыва «совместимости» с Си в отношении малоупотребимых операторов. Но об этом позже.)

Теперь вы видите, почему моя работа несколько больше, чем просто критика и одобрение отдельных документов RFC?.. Осталось очень много вещей, которые упущены в этих документах. Мы должны решить, где в этом воздушном шаре Perl пассажиры, а где балласт, который необходимо сбросить за борт (только бы не перепутать!). Мы должны максимально сгладить переход от Perl 5 к Perl 6, чтобы предотвратить ситуации, когда люди отказываются от шестой версии языка, потому что просто не могут к нему привыкнуть. Мы должны смотреть на проблемы очень пристально, пока не сделаем их совершенно прозрачными, не заглянем в то, что стоит за всем этим. И тогда мы сможем сохранить простоту Perl для тех, кто собирается его использовать для наискорейшего выполнения своей работы.

А пока приготовьтесь услышать мелодию Откровения Второго, где мы настроим звучание переменных, подготовим сценарии, отрепетируем контексты Perl, — в общем, создадим лексическую сцену для продолжения спектакля.

 
Рекламный блок
   

На странице:
    1. Ларри Уолл: Откровение Первое. Добро, Зло и Смута
     RFC 141: это последнее глобальное изменение языка
     RFC 28: Perl должен остаться самим собой
     RFC 28: не нужно принуждать пользователя по умолчанию использовать warnings и strict.
     RFC 73: все встроенные функции Perl должны возвращать объекты
     RFC 26: именованные операторы и функции.

Важное объявление:
    автор категорически против копирования и распространения в Интернете всех статей «Куроводства» с возрастом, меньшим 6 месяцев. Печальный опыт «расползания» чрезвычайно устаревших ошибочных версий статьи про Apache действительно объясняет такое решение.

Орфография на «Куроводстве»:
    если вы заметили орфографическую, стилистическую или другую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter. Выделенный текст будет немедленно отослан вебмастеру, а Вы даже ничего и не заметите — настолько быстро все произойдет.

На заметку:
    если вы уже вскипели насчет дизайна этой страницы, то присмотритесь повнимательнее к названию, почитайте FAQ, сходите по лебедевским местам, как это уже предлагалось выше. Можно ли считать пародию плагиатом? Надеюсь, что нет.

Параметры этой страницы
   
GZip

Ссылки от спонсоров
    Краска для волос-определиться с цветом


Ларри Уолл (перевод dk) | 29 декабря 2001 г. ©1999-2016 | Генеральный спонсор: Хостинг «Джино» | Контакт Вернуться к оглавлению