новости
статьи
.мнение

интервью с Дамианом Конвеем

Конференция O’Reilly по программному обеспечению с открытым кодом, OSCON, столь же славится умными беседами в кулуарах и за обедами, сколько и семинарами, заседаниями и программными выступлениями. Терри Камерленго пригласил на ненавязчивую беседу Дамиана Конвея, автора «Perl Best Practices» и «Perl Hacks», чтобы узнать о его мыслях касательно самых разных тем, начиная с подробностей про Perl 6 и заканчивая тем, что, по его мнению, важно для следующего поколения ученых в области компьютерных наук.

Дамиан Конвей: Я частный консультант. Езжу по всему свету, где бы ни были мои клиенты; в основном — в Европу и Северную Америку. Я преподаю Perl, Vim, проведение докладов — практически что угодно. А большую часть года я нахожусь в Австралии, как видно по моему акценту. И я работаю дома, удаленно. Я много занимался проектом Perl 6 и пишу на подобные темы, так что удаленная работа — это удобно.

Терри: А еще вы читаете лекции в университете?

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

Терри: Расскажите про свое образование. Что вы изучали и какие получили ученые степени?

Дамиан: У меня пара ученых степеней: бакалавра, а затем и кандидата в компьютерных науках. Что до степени кандидата, я занимался компьютерной графикой еще до того, как появилось аппаратное обеспечение, позволяющее делать все очень просто. И, как это бывает с кандидатской работой, больше я никогда ничего не делал в области графики; это приводит в изнеможение, какая бы тема у вас ни была. Потом основная моя проблема была в том, что я занимался исследованиями сразу где-то в восьми разных направлениях. Так что я не гонюсь за достижениями в академической карьере, она не составляет основные заслуги. Но, раз уж вы упомянули, то перечислю: дизайн пользовательских интерфейсов, дизайн языков программирования, моделирование в молекулярной биологии, и так далее.

Терри: А что вы думаете о быстрой трехмерной отрисовке при помощи изоосветителей?

Дамиан: Боже мой! Нет! Нет! Неужели снова?! Это была тема моей кандидатской. Метод отрисовки относительно простых фигур, но еще до того, как появилось аппаратное обеспечение, позволяющее делать это с какой-то мыслимой скоростью. Идея такова. Сейчас, когда люди что-то изображают, они изображают поверхность: делят ее на очень маленькие многоугольники и очень аккуратно их отрисовывают. Но когда еще было затратно отрисовать и отдельный многоугольник, я предложил другой подход... Ну, если можно математически рассчитать контуры яркости на поверхности, то все, что нужно — это отрисовать каждый из контуров фиксированным цветом сплошной линией; и, конечно, отрисовка линий была тогда гораздо менее затратна, чем закраска областей; так что нужно просто отрисовать все эти линии, и они образуют гладкую поверхность.

Терри: Да, здорово.

Дамиан: Это довольно круто и могло пригодиться, но закон Мура меня нагнал, и вычислительные мощности стали такими серьезными, что больше не потребовалось проводить оптимизацию такого рода.

Терри: Как интересно. Еще вы говорили, что делали какую-то работу по визуализации в биологии.

Дамиан: Да.

Терри: Что за работа?

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

Терри: Так это протеиновые каналы?

Дамиан: Нет, это буквально маленькие трубочки. Мы не могли практически определить их точную структуру, потому что технологии того времени не позволяли их достаточно хорошо проанализировать. Так что мы выбрали другой подход. Раз есть три господствующие теории о том, какая у них форма, то, если мы смоделируем каждую из трех теорий, поведение составляющих протеинов в каждой из теорий, а затем процесс электронной микроскопии, которая тогда использовалась, то мы получим все искусственные микроснимки, и, если какой-нибудь будет похож на настоящие микроснимки, то это будет очевидным подтверждением одной из теорий. Если у вас есть теория и точная модель, дающая что-то совершенно не похожее на настоящее изображение, то, скорее всего, с теорией что-то не так. На это опиралась кандидатская. Это было очень интересно и, вы знаете, я очень мало разбираюсь в биологии, но было очень приятно помочь делу тем, в чем я разбираюсь: визуализацией, моделированием и расчетами.

Терри: Это очень интересно. Отвлечемся от этой темы и поговорим о немного другой. Вы работаете лектором. Кто-то сказал, что использование Java как языка для обучения студентов в области компьютерных наук снижает качество образования. Может, Java — не лучший язык для этого. Многие люди считают, что нужно использовать что-то вроде C++ или Perl, или C. Что вы думаете на этот счет?

Дамиан: Я не разделяю точку зрения, что, так как Java относительно удалена от середины спектра, то она не подходит в качестве первого языка программирования. Для многих людей, получивших очень-очень хорошие знания в компьютерной области, первым языком был Lisp, удаленный от середины насколько только возможно. Когда я учился... вернемся в каменный век... нам тоже преподавали обе стороны спектра. Нам преподавали Pascal как первый язык программирования, который, опять же, является очень абстрактным языком, но в то же время нам преподавали микропрограммирование. Нам рассказывали про ассемблер, еще более низкоуровневое микропрограммирование, а еще уровнем ниже мы занимались аппаратным обеспечением. В те времена компьютерные науки действительно изучали сборку компьютеров из электронных приборов. Думаю, что проблема с преподаванием Java как первого, а часто и единственного языка программирования, касается того, что преподается, будто существует единственный инструмент, молоток, и вы должны все вокруг принимать за гвоздь. Сейчас я наблюдаю во многих учебных программах недостаток разнообразия, недостаток в изучении разных подходов к расчетам, разных способов решения задач, разных архитектур, разных языковых парадигм, разных моделей мышления — вот это я считаю большой проблемой. Я не против, если вы первым делом будете преподавать Java. Иногда я удивляюсь, не слишком ли Java сложен для первоначального изучения, ведь он требует понимания сразу всех концепций.

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

Терри: Но вы не можете этого допустить.

Дамиан: Да нет, по моему опыту всего десять лет назад пятьдесят процентов наших молодых людей приходили вообще без опыта программирования. Они слушали курс, потому что считалось, что это будет хорошим карьерным путем, либо они были заинтересованы, но у них не было никакой возможности. Так что меня беспокоит не то, какой язык первым делом изучается, а то, какова разнообразность, в какую систему вписано изучаемое. Я всегда привожу пример бананов. Проблема с продающимися бананами в том, что их не выращивают из семян. Ну, бананы известны тем, что в них нет семян, и проблема в том, что они практически все размножаются вегетативным путем. Они почти не способны к размножению семенами, и вы получаете новые банановые растения, деля существующие, что ограничивает их генетическое разнообразие, которое обычно возрастает при мутациях — это все одно и то же растение, один и тот же геном. Так что когда на листья нападает какой-нибудь грибок, то, если он затрагивает один банан, то он затрагивает и все остальные. И, если хотите, можно упростить метафору: та же проблема с господством на всем рынке Microsoft и операционной системой Windows. Вот почему у нас так много проблем с вирусами: если вирус затронет один компьютер, то скорее всего затронет все остальные.

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

Терри: ...чтобы заставить его выполнять то, что требуется?

Дамиан: Такое происходит с Java. Так что моя проблема в том, что я хочу, чтобы вы преподавали мне десяток языков программирования за три года обучения, чтобы по выпуску я понимал функциональное программирование, я понимал декларативное программирование, я понимал ограничительное программирование, процедурное, объектно-ориентированное, аспектно-ориентированное, и прочие парадигмы. Для этого нужен какой-то практический опыт.

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

Дамиан: Нет. Такова моя идея. Если бы была одна такая книга, то просто оттого, что это «одна такая книга», это не было бы правильным ответом. Это все равно что спросить: «Можете ли порекомендовать одну из политических партий?» Нет. Вся суть существования политических партий в том, чтобы они были разные, чтобы у нас было разнообразие, богатство выбора.

Терри: Хорошо. Давайте перейдем к Perl и поговорим немного о нем. Во-первых, хотелось бы знать, когда нам ждать Perl 6?

Дамиан: Ох, опять этот вопрос. Когда у меня спрашивают, я всегда говорю: «К Рождеству».

Терри: Да. Это превосходно.

Дамиан: Но я предусмотрительно не говорю, к какому Рождеству.

Терри: Сейчас июль, так что к...

Дамиан: Да-да, к какому-то Рождеству.

Терри: Хорошо.

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

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

Терри: Хорошо. Сейчас 2008-й, так что когда-то в 2009-м?

Дамиан: Ну, я не хотел бы уточнять год, так что если люди читают это в 2015-м, они скажут: «О! В следующем году выйдет!»

Терри: Вот вас называли сподвижником Ларри Уолла. Что это означает?

Дамиан: Гм...

Терри: Какую роль вы играете в Perl?

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

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

Терри: Прекрасно. Не могли бы вы объяснить разницу между Rakudo и Pugs? Я правильно это произнес? «Ракудо»?

Дамиан: «Ракудо», да. Мы все, наверное, говорим неправильно, без японского произношения, и я точно не буду это коверкать.

Perl 5 был практически знаменит тем, что имел одну-единственную реализацию, и это была слабая сторона в каком-то смысле, по части нехватки генетического разнообразия, о котором я говорил ранее, но одновременно это было гигантское преимущество, потому как если что-то работает в одном месте, то почти гарантированно будет работать где-либо еще. В Perl 6 мы немного меняем такой подход. Мы говорим, что хотим иметь несколько реализаций, если это возможно, и все, что соответствует спецификации, может называть себя Perl 6. Так, самую первую реализацию начала и сильно продвинула Одри Танг, удивительно талантливый программист на Perl. Она живет в Тайване. Первая реализация была написана на Haskell и была очень сложным и полным воплощением прототипа Perl 6. Этот проект как-то застрял, после того как Одри сменила проекты и интересы, а долгосрочной целью всегда было создание реализации для работы на виртуальной машине Parrot.

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

Но вот краткий вариант «Ракудо» означает «рай», и мы подумали: да, это довольно высокая цель, которой мы хотели бы достичь. Так и назвали. На деле, это просто реализация Perl 6, которая работает под виртуальной машиной Parrot. Так, с практической стороны различие в том, что Rakudo сейчас очень-очень мощно развивается, продвигается и меняется. Pugs сейчас практически стоит на месте. На деле он вообще не меняется. Они почти сравнимы по объему реализованного из Perl 6, но у них есть и различия. Так как Rakudo запускается из-под Parrot, то после компиляции он работает очень быстро, ведь Parrot — очень быстрая виртуальная машина. Но мы еще не оптимизировали ее внешний слой, чтобы все быстро компилировалось. С другой стороны, Pugs компилирует очень быстро, но из-за того, что интерпретируется на Haskell, который в свою очередь тоже интерпретируется, он работает сравнительно медленно.

Терри: Интересно. Есть ли планы перенести другие языки на виртуальную машину Parrot?

Дамиан: Это одна из определяющих характеристик. Одним из основных требований, которые мы выдвигали для Parrot, — это чтобы она подходила практически для любого динамического языка. Это и есть виртуальная машина, нацеленная на динамические языки. Другие крупные виртуальные машины — JVM, .NET framework — в основном нацелены на языки, которые типизированы статически. Было успешно продемонстрировано, что на них можно легко реализовать динамически типизированные языки вроде J-Python, Jython, но в действительности они не заточены под это. Вот среда исполнения Python заточена и существует; не могу перечислить все, но есть куча языков, для которых у нас сейчас есть прототипы реализаций. И, конечно, располагая общей внутренней средой выполнения — очень высокоуровневой и абстрактной средой выполнения — мы рассчитываем, что получим более качественное взаимодействие между этими языками, так что вы можете взять, допустим, библиотеку Java, которую хотите использовать в Perl 6, и просто работать с ней. И с объектами, которые выдаются библиотекой Java, можно обращаться, как с объектами Perl 6, без ограничений на их семантику.

Терри: Ого, это привлекательно.

Дамиан: Это очень волнующая штука.

Терри: Знаете, это как собаки, спящие вместе с кошками.

Дамиан: Ага, это вроде знака приближающегося конца света.

Терри: Можете немного рассказать про динамическую типизацию в Perl 5?

Дамиан: Конечно. Идея динамической типизации в том, что переменные — это просто контейнеры, общие контейнеры; ну вы приходите в магазин ящиков и покупаете ящик. Вам не нужно ходить в магазин за ящиком, в котором можно хранить только джемперы, или ящиком, в котором можно хранить только документы, или вроде того. Вы приходите и покупаете ящик, и, разумеется, то, что вы в него положите, определяет тип ящика: это ящик для свитеров или ящик для документов, или ящик для старья, или ящик для мусора. Так работают динамические языки. В динамических языках по типу различаются значения, как и в статических языках, но когда вы помещаете значение определенного типа в переменную, эта переменная принимает тем или иным образом ограничения для этого значения, и все, что теперь можно сделать с этой переменной — это то, что можно сделать с данным типом значения. Но если вы извлекаете значение из ящика и помещаете в него значение другого типа, то ящик меняется и ведет себя по-другому. Это оказывается очень мощным, потому что это вроде позднего связывания, так что вы не должны принимать решения статически, во время компиляции, и порой натыкаться на плохие решения. И во многих отношениях, когда мы говорим, допустим, об объектно-ориентированном подходе, кажется, что лучше, когда у вас есть такая возможность позднего связывания, и когда вы откладываете решения до тех пор, пока на деле не получите объект, вызовите для него метод, и он сделает что-нибудь.

Теперь в объектно-ориентированных языках, которые преимущественно статически типизированы — тут я имею в виду, допустим, C++ и в какой-то мере Java — вы можете очень просто порождать ошибки, связанные со статическим типом переменной, в которую вы помещаете динамическое значение совместимого, но не идентичного типа, и это может привести к очень странным вещам. В динамических языках все определяется динамически. Когда вы делаете что-то, тогда вы и смотрите на тип, тогда и решаете, можно это делать или нельзя. Хотя здесь есть преимущества в меньшей подверженности несоответствиям на стадии компиляции, есть недостаток в том, что вы склоняетесь к получению сообщений об ошибках во время выполнения, а не во время компиляции, и это придает гораздо больше значения хорошему тестированию.

Терри: Хорошо. Так вы вводите в Perl 6 статическую типизацию?

Дамиан: Да.

Терри: И зачем вы это делаете? Были какие-то возражения? Какова мотивировка?

Дамиан: Причина тут...

Терри: И сохраните ли вы динамическую типизацию?

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

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

Так, мы считаем, что типизация в Perl 6 — статическая с умолчаниями, так что вы не должны указывать тип для переменной, но если не укажете, то по умолчанию она будет иметь универсальный тип, который, опять же, скаляр, массив или хеш. Но можете сказать: «нет, я хочу более конкретно указать, что это не просто скаляр, а скаляр, который может хранить только числа». Так что, если нужно, то вот оно. Если не нужно, то это не будет стоять у вас на пути.

Терри: Превосходно. Это замечательно. Что до способов передачи параметров в Perl 6, там есть позиционная, передача по именам и какое-то «заглатывание». Самое главное, что за «заглатывание»?

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

Всем нам знакомы позиционные параметры. Они как бы говорят: «Смотрите, первый аргумент должен быть именем, второй — должностью, а третий — регистрационным номером». И это прекрасно работает с именем, должностью и регистрационным номером, потому что это тот порядок, в котором вы их укажете в любом случае. Большинство языков на деле предоставляют только позиционные списки параметров или аргументы. Тут есть проблема: это прекрасно работает, когда у вас один-два, или, может, три параметра, но некоторые процедуры требуют для работы около восьми-десяти или пятнадцати, такие они настраиваемые. И когда у вас восемь параметров, как вы запомните их порядок? Ответ: никак. Нужно возвращаться и смотреть их всякий раз, когда нужно использовать. Так что другой способ передачи параметров — это сказать: «Тут я собираюсь передать восемь аргументов, но я хочу дать каждому из них имя. Я собираюсь пометить каждый из них и, если имеется метка, то порядок не имеет значения, потому что можно взглянуть на метку и сказать: «О, так это — имя, это — должность, а это — регистрационный номер».

Эта передача параметров по именам не очень хорошо поддерживается в большинстве языков и, конечно, не на уровне компилятора. Большинство людей передадут словарь или хеш, или ассоциативный массив, который включает имена и прочее, но тогда нет проверки на типы или на здравый смысл. Ее нужно обеспечивать своими силами.

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

Теперь проблема в том, что имеется другая вещь, которую нужно сделать при передаче параметров. Многие процедуры имеют фиксированное число параметров, обычно один-два, которые говорят, что нужно сделать, а потом обычно следует произвольное число параметров, которые составляют данные, с которыми нужно что-то сделать. Простой пример — это операция map или apply, когда вы указываете: «вот небольшая функция, которую я хочу применить к каждому из последующих значений», и следует список значений; значение может быть одно, либо их может быть сто тысяч. Конечно, не хотелось бы определять для этого сто тысяч именованных параметров. Нужно что-то такое, что, располагая только первым параметром, вберет остальные в один массив. Это и есть «заглатывающий параметр». Он заглатывает все оставшиеся аргументы и представляет их в одном контейнере, который потом можно обработать подходящим образом.

Терри: Интересно. Это же ярко выраженная функциональная возможность Perl, да?

Дамиан: Да, и в Perl 6 мы добавляем более продвинутую поддержку функционального программирования.

Терри: Так, пока поддерживаются map и apply. Будет ли что-то еще?

Дамиан: Самое важное введение — reduce.

Терри: reduce?

Дамиан: И без этого вы действительно не сможете довести до конца функциональный подход к операциям над списками, потому что вы никогда не сможете сократить список до одного нужного значения. Но большинство дополнительных возможностей, которые требовались, не были во многом встроенными функциями, если не считать тех сложных способов указания параметров, а также возможности существования нескольких процедур с одним именем, но разными списками параметров, чтобы не нужно было рассматривать каждый возможный вызов и применять условные конструкции. В функциональных языках, большинстве из них, предлагаются три разных версии функции head: одна, если получает пустой список, просто возвращает пустой список; другая, если получает одно значение, возвращает его обратно; третья, если получает список, то возвращает первый элемент; потом уже head применяется к оставшимся. Мы планируем поддерживать это и в Perl 6.

Терри: Сигилы. Можете рассказать о том, что это такое, правильно ли я это произнес, и будут ли они убраны из Perl 6?

Дамиан: Никогда не могу сказать, правильно ли кто-нибудь из Северной Америки произносит какое-то слово, потому что мне кажется, что вы вообще ничего не произносите правильно. Я называю это сигилами, и сигилы — такие помехи, которые встречаются перед именами переменных в Perl. Ну, эта идея не изобретена в Perl. Если вы используете какую-либо командную оболочку, то вы знаете, что переменные окружения начинаются со знака доллара. В Perl любая скалярная переменная начинается со знака доллара; если это массив, то он должен начинаться со знака @; если словарь или хеш, то он начинается со знака процента. И все это позволяет иметь одновременно скаляр и массив с одним идентификатором, но для разных целей. В Perl это было с самых ранних времен, и с этим всегда была проблема. Проблема была в том, что это как формы слов в грамматике: если у меня есть массив, то я записываю перед его именем @, и это примерно то же, что сказать: «эти вещи». Но когда нужно сказать об одной из них, вы говорите: «эта вещь», вы не можете сказать «эти вещь». Так, в Perl 5, что вы делали, чтобы сослаться на один элемент массива, так это меняли сигил. Вы меняли его с символа @, который означает «эти», на символ доллара, который означает «этот». И тогда вы добавляете квадратные скобки, чтобы указать, какой нужен индекс. С лингвистической точки зрения это очень остроумная идея, и она дает возможность ввести тонкие различия в поведении. Но на деле выходит, что девяносто процентов программирующего населения просто не может понять такую идею. И это не оттого, что они тупые. Просто это не их естественный ход мысли. Естественный ход мысли в отношении сигилов такой: если тут доллар, то это скаляр; если массив, то должен быть знак @; если тут знак процента, то это должен быть хеш. И проблема смены сигила для другого использования слова в том, что это сбивает людей с толку, особенно англоговорящих — нам это не очень хорошо дается.

В других языках гораздо сильнее проявляется смена формы, когда меняется то, как используется слово, не то что в английском. Таким образом, мы обнаружили, что множество пользователей просто не могут иметь дело с «Ой! Вы должны изменить сигил, даже если это та же самая переменная». Так что в Perl 6 мы это поменяли, там помехи перед именем переменной всегда остаются одинаковыми. Если это массив, то он сохраняет знак @ вне зависимости от того, что вы с ним делаете: просматриваете значения, выбираете составной список или что еще. Это было очень важным изменением в Perl 6. Оно должно стать испытанием для опытных программистов на Perl 5, но, если вы к этому привяжетесь, то никогда не вернетесь обратно. Это гораздо лучше.

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

Дамиан: Пожалуй, мой совет, если я хочу быть последовательным, повторит уже сказанное: хорошо углубляться в программирование, быть глубоко талантливым в одной или двух областях, но куда важнее быть разносторонним. Более важно иметь хотя бы общее понимание большого числа приемов решения задач, большого числа стилей программирования, большого числа языков программирования и просто быть знакомым со множеством различных алгоритмических подходов к задачам, потому что это приумножает ваши навыки. Это дает возможность в определенной ситуации, в решающий момент, когда некогда самостоятельно придумывать умный подход, прибегнуть к чему-то имеющемуся. Вы говорите: «Ага, если бы мы использовали для этого Haskell, то мы бы просто решили задачу. Как это можно приспособить к имеющейся ситуации?» Не обязательно использовать для решения Haskell, но можно ли использовать подход в том же духе? Я думаю, это очень важно. Чтобы быть хорошим программистом, нужно быть разносторонним программистом. И другой совет, который я хочу дать, состоит в том, что для того, чтобы быть хорошим программистом, нужно действительно программировать. И это мало кто делает. Знаете, мы проходим обучение, начинаем изучать все эти вещи, постоянно делаем упражнения, проверочные задания и тому подобные вещи. А потом вы заканчиваете учиться и начинаете ходить на совещания, заниматься проектированием и прочими вещами, вы перестаете
программировать. И если вы получили повышение, то вас буквально повысили от возможности каким-либо образом заниматься программированием, и я считаю это проблемой. Если хотите быть по-настоящему хорошим игроком в теннис, то вы будете каждый день практиковаться. Если вы хотите быть великим мастером единоборств, то вы будете каждый день посещать додзё. Если вы хотите быть превосходным программистом, то будете каждый день программировать, даже если это придется делать в личное время. Как только вы освободились, вы — программист. Даже если освободились в 11 часов вечера или в 3 утра, хоть какую-то часть времени нужно потратить на программирование, потому что стоит только запустить, и как программист вы начинаете умирать.

Терри: Прекрасно. Это был Дамиан Конвей. Большое спасибо.

Дамиан: Спасибо.

Интервью взял Терри Камерленго (Terry Camerlengo); оператор — Макс Хабиби (Max Habibi); редактор — Томас Харриган (Thomas Harrigan); продюсер — Катрин Баррет (Kathryn Barret), O’Reilly; перевод Алексея Бешенова, http://beshenov.ru.

Интервью взято летом 2008 года и опубликовано на сайте O’Reilly (http://fyi.oreilly.com/2008/08/the-mind-of-damian-conway-scie.html), там же доступна видеоверсия.



обсудить статью
© сетевые решения
.
.