Морис Херлихи — обладатель целых двух премий Дейкстры. Первая — за работу по «Wait-Free Synchronization» (Brown University) и вторая, более свежая, — «Transactional Memory: Architectural Support for Lock-Free Data Structures» (Virginia Tech University). Премию Дейкстры дают за работы, значимость и влияние которых были заметны на протяжении не менее десяти лет и, очевидно, Морис — один из самых известных специалистов в области. На данный момент он работает профессором в Брауновском университете и имеет множество достижений на целый абзац длиной. Сейчас он занимается исследованиями блокчейна в контексте классических распределенных вычислений.  Ранее Морис уже приезжал в Россию на SPTCC (видеозапись) и cделал отличную встречу сообщества Java-разработчиков JUG.ru в Питере (видеозапись). Этот хабрапост  — большое интервью с Морисом Херлихи. В нем обсуждаются следующие темы: Виталий Аксенов — на данный момент, пост-док в IST Austria и сотрудник кафедры «Компьютерные Технологии» Университета ИТМО. Занимается исследованиями в области теории и практики конкурентных структур данных. До работы в IST, он получил PhD в Университете Париж Дидро и в Университете ИТМО под руководством профессора Петра Кузнецова. Алексей Федоров — продюсер в JUG Ru Group, российской компании, которая занимается организацией конференций для разработчиков. Алексей участвовал в подготовке более чем 50 конференций, а в его резюме есть всё что угодно, начиная от позиции инженера-разработчика в Oracle (JCK, Java Platform Group), и заканчивая позицией деврела в компании Одноклассники. Владимир Ситников — инженер в компании Netcracker. Десять лет работает над производительностью и масштабируемостью NetCracker OS — ПО, используемого операторами связи для автоматизации процессов управления сетью и сетевым оборудованием. Увлекается вопросами производительности Java и Oracle Database. Автор более десятка улучшений производительности в официальном PostgreSQL JDBC-драйвере. Алексей: Морис, вы очень долго работали в академической среде и первый вопрос заключается во взаимодействии между академической и индустриальной сферами. Не могли бы вы рассказать, как изменились взаимодействия между ними за последнее время? Что было 20-30 лет назад и что происходит сейчас?  Морис: Я всегда старался тесно сотрудничать с коммерческими компаниями, потому что у них есть интересные задачи. Они, как правило, не очень заинтересованы ни в публикации полученных результатах, ни в подробных объяснениях своих проблем мировой общественности. Они лишь заинтересованы в решении этих проблем. Я некоторое время работал в таких компаниях. Я провел пять лет, работая полный рабочий день в исследовательской лаборатории в Digital Equipment Corporation, которая раньше была крупной компьютерной компанией. Я работал один день в неделю в Sun, в Microsoft, в Oracle, немного работал в Facebook. Сейчас я собираюсь отправиться в творческий отпуск (sabbatical leave, профессору в американском университете разрешается где-то раз в шесть лет брать такой отпуск на год) и поработать в Algorand, это такая криптовалютная компания в Бостоне. Работать в тесной связи с компаниями всегда было приятно, потому что именно так вы узнаете о новых и интересных вещах. Вы можете быть вообще первым или вторым человеком, опубликовавшим статью на выбранную тему, вместо того, чтобы заниматься постепенным улучшением решений задач, над которыми и так работают все остальные. Алексей: Можете подробнее рассказать, как это происходит? Морис: Конечно. Знаете, когда я работал в корпорации Digital Equipment Corporation, я и Эллиот Мосс, мы изобрели транзакционную память. Это был очень плодотворный период, когда все начали интересоваться информационными технологиями. Параллелизмом в том числе, хотя многоядерные системы еще не существовали. Во времена Sun и Oracle я много работал над параллельными структурами данных. В Facebook я занимался их блокчейн-проектом, о котором я не могу говорить, но надеюсь, он скоро станет публичным. В следующем году, в Algorand, я буду работать в исследовательской группе, изучая смарт-контракты. Алексей: В последние несколько лет блокчейн стал очень популярной темой. Поможет ли это вашим исследованиям? Возможно, облегчит получение грантов или даст доступ к ресурсам компаний, работающим в индустрии? Морис: Я уже получил небольшой грант от Ethereum Foundation. Популярность блокчейна очень полезна для того, чтобы вдохновлять студентов на работу в этой области. Они очень интересуются этим и рады принять участие, но иногда не понимают, что исследования, заманчиво звучащие снаружи, оказывается, включают действительно тяжелую работу. Тем не менее, я очень рад использовать всю эту мистику вокруг блокчейна, это помогает привлекать студентов.  Но это еще не всё. Я нахожусь в консультативном совете нескольких блокчейн-стартапов. Некоторые из них могут преуспеть, некоторые из них, возможно, нет, но всегда очень интересно видеть их идеи, изучать их и консультировать людей. Самое захватывающее – когда вы предупреждаете людей не делать что-то. Многое вначале кажется хорошей идеей, но так ли это на самом деле? Виталий: Кое-кто думает, что за блокчейном и его алгоритмами будущее. А другие люди говорят, что это просто очередной пузырь. Можете поделиться своим мнением на этот счёт? Морис: Многое из того, что происходит в мире блокчейнов работает неправильно, что-то просто мошенничество, многое переоценено. Тем не менее, я думаю, что для этих исследований есть солидная научная база. Тот факт, что мир блокчейнов полон идеологических разногласий, показывает уровень волнения и преданности делу. С другой стороны, это не особо выгодно для научных исследований. Сейчас, если вы публикуете статью в которой говорится про недостатки конкретного алгоритма, полученная реакция не всегда является в полной мере научной. Зачастую люди выплескивают свои эмоции. Думаю, что подобный ажиотаж в этой области кое-кому может показаться привлекательным, но в конце концов, тут есть и реальные научные и инженерные вопросы, которыми только предстоит заняться. Здесь много Computer Science. Виталий: То есть, вы пытаетесь заложить фундамент для исследований блокчейна, верно? Морис: Я пытаюсь заложить фундамент для твердой, научно и математически обоснованной дисциплины. И отчасти проблема в том, что приходится иногда противоречить некоторым излишне резким позициям других людей, игнорировать их. Иногда люди спрашивают, почему я работаю в области, в которой заинтересованы только террористы и наркоторговцы. Такая реакция столь же бессмысленна, как и поведение последователей, слепо повторяющих твои слова. Думаю, что истина где-то посередине. Блокчейн ещё окажет глубокое влияние на общество и мировую экономику. Но, вероятно, это произойдет не благодаря современным технологиям. Современные технологии будут развиваться и то, что в будущем будет называться блокчейном, станет очень важным. Может быть, оно даже не будет выглядеть как современные блокчейны, это открытый вопрос. Если люди будут изобретать новые технологии, они будут продолжать называть это блокчейном. Я имею в виду, точно так же, как сегодняшний Fortran не имеет никакого отношения к языку Fortran из 1960-х годов, но все продолжают называть это Fortran. То же самое для UNIX. То, что называется «блокчейн», ещё сделает свою революцию. Но я сомневаюсь, что этот новый блокчейн станет похож на то, что всем так нравится использовать сегодня. Алексей: Привела ли популярность блокчейна к новым результатам с научной точки зрения? Больше взаимодействия, больше студентов, больше компаний в области. Есть ли уже какие-то результаты этого роста популярности? Морис: Я заинтересовался этим, когда кто-то вручил мне официальную листовку компании, которая только что собрала довольно много денег. В ней писали о задаче византийских генералов, с которой я более чем знаком. Написанное в листовке было явно технически неверно. Люди, которые всё это написали, не очень понимали лежащую за проблемой модель… и все же эта компания собрала много денег. Впоследствии компания незаметно подменила эту листовку куда более правильным вариантом – и я не скажу, как называлась эта компания. Они все еще существуют и дела у них идут очень хорошо. Этот случай убедил меня, что, во-первых, блокчейн – это просто форма распределенных вычислений. Во-вторых, порог входа (по крайней тогда, года четыре назад) был довольно низким. Люди, работающие в этой области, были очень энергичными и умными, но научных работ не читали. Они пытались переизобрести известные вещи и сделали это неправильно. Сегодня драма поуменьшилась. Алексей: Это очень интересно, потому что несколько лет назад у нас была другая тенденция. Это немного похоже на фронтенд-разработку, когда разработчики браузерных интерфейсов переизобретали целые технологии, которые к тому времени уже были популярны в бэкенде: системы сборки, непрерывную интеграцию и всё в таком духе.  Морис: Согласен. Но это неудивительно, ведь по-настоящему прорывные идеи всегда приходят извне сложившегося сообщества. Признанные исследователи, особенно авторитеты в академической среде, вряд ли сделают что-то действительно прорывное. Легко написать для следующей конференции доклад про то, как вы немного улучшили результаты своих прошлых работ. Сходите на конференцию, соберитесь с друзьями, поговорите о всём том же самом. А люди, врывающиеся с прорывными идеями, почти всегда приходят извне. Они не знают правил, не знают языка, но тем не менее… Если же вы внутри сложившегося сообщества, советую обращать внимание на новые вещи, на что-то, что не укладывается в общую картину. В некотором смысле, можно предпринять попытку объединить внешние, более подвижные разработки с методами, которые мы уже понимаем. В качестве первого шага, попробуйте создать научную базу, а потом измените ее так, чтобы ее можно было применять к новым прорывным идеям. Думаю, что блокчейн отлично подходит на роль свежей прорывной идеи. Алексей: Как думаете, почему так происходит? Потому что у людей «снаружи» нет каких-то специфических барьеров, присущих сообществу? Морис: Тут прослеживается какая-то схема. Если почитаете историю импрессионистов в живописи и искусстве вообще, то в своё время известные художники отвергали импрессионизм. Они говорили, что это какое-то ребячество. Поколение спустя, этот ранее отвергнутый вид искусства стал стандартом. Что я вижу в своей области: изобретатели блокчейна не были заинтересованы во власти, в накручивании публикаций и индекса цитируемости, они просто хотели сделать что-то хорошее. И вот, они сели и начали это делать. Им не хватало определенной технической глубины, но это поправимо. Куда сложнее придумать новые творческие идеи, чем исправлять и усиливать недостаточно зрелые. Благодаря этим изобретателям мне теперь есть чем заняться! Алексей: Это похоже на различие между стартапами и легаси-проектами. По наследству нам переходит множество ограничений мышления, барьеров, специальных требований, и так далее. Морис: Хорошая аналогия – распределенные вычисления. Подумайте о блокчейне как если бы он был стартапом, а распределенные вычисления – крупной устоявшейся компанией. Распределенные вычисления находятся в процессе покупки и слияния с блокчейном. Виталий: У нас ещё множество вопросов! Мы изучали вашу биографию и наткнулись на любопытный факт о вашей докторской степени. Да, это было давным-давно, но тема, кажется, важная. Вы получили PhD под руководством самой Барбары Лисков! Барбара очень известна в сообществе разработчиков языков программирования, и вообще очень известная личность. Логично, что ваши исследования были в области языков программирования. Как же вы перешли на параллельные вычисления? Почему вы решили сменить тему? Морис: В то время Барбара и ее группа как раз посматривали на распределенные вычисления, это было очень новой идеей. Были и те, кто говорил, что распределенные вычисления – чепуха, общение компьютеров между собой бессмысленно. Один из вопросов, рассматриваемых в распределенных вычислениях, отличающий их от централизованных вычислений, – отказоустойчивость. После длительных исследований мы решили, что в языке программирования для распределенных вычислений нужно иметь что-то вроде атомарных транзакций, потому что никогда нельзя быть уверенным в успешности удаленного вызова. Как только у вас появились транзакции, возникает проблема управления параллелизмом. Потом было много работы по получению высокопараллельных транзакционных структур данных. Затем, когда я получил высшее образование, я пошел в Карнеги-Меллон и начал искать тему для работы. Мне пришло в голову, что вычисления перешли от отдельных компьютеров к сетям компьютеров. Естественным продолжением прогресса стали бы мультипроцессоры – слово «многоядерный» тогда ещё не существовало. Я подумал: каков эквивалент атомарным транзакциям для многоядерной системы? Точно не обычные транзакции, потому что они слишком большие и тяжелые. И вот так я пришел к идее линеаризуемости и именно так я придумал всю wait-free синхронизацию. Это была попытка ответить на вопрос, что же является аналогом атомарных транзакций для многопроцессорной системы с общей памятью. На первый взгляд, эта работа может выглядеть совсем по-другому, но на самом деле это продолжение всё той же темы. Виталий: Вы упомянули, что в то время было совсем немного многоядерных компьютеров, так? Морис: Их просто не было. Было несколько так называемых симметричных мультипроцессоров, которые в основном были подключены к одной и той же шине. Это не очень хорошо работало, потому что каждый раз, когда новая компания создавала нечто подобное, Intel выпускала один-единственный процессор, который превосходил мультипроцессор. Алексей: Не значит ли это, что в те давние времена, это было скорее теоретическое исследование? Морис: Это было не теоретическое, а скорее умозрительное исследование. Всё это было не про работу с множеством теорем, скорее, мы выдвигали гипотезы о несуществующей на тот момент архитектуре. Именно для этого и нужны исследования! Ни одна компания не проделала бы подобного, всё это было чем-то из далёкого будущего. На самом деле, так было до 2004 года, когда появились реальные многоядерные процессоры. Из-за того, что процессоры перегреваются, можно сделать процессор ещё меньше, но нельзя сделать быстрее. Из-за этого произошёл переход на многоядерные архитектуры. И тогда это означало, что внезапно появилось применение для всех концепций, которые мы разработали в прошлом. Алексей: Как вы думаете, почему многоядерные процессоры появились только в двухтысячных? Так почему так поздно? Морис: Это связано с аппаратными ограничениями. Intel, AMD и другие компании очень хороши в повышении скорости процессора. Когда в какой-то момент процессоры стали достаточно маленькими и они больше не могли увеличивать тактовую частоту, потому что процессоры начали бы сгорать. Можно сделать их меньше, но никак не быстрее. Что в их силах – вместо очень маленького процессора, уместить восемь, шестнадцать или тридцать два процессора в тот же объем корпуса, где раньше помещался только один. Теперь у вас многопоточность и быстрая коммуникация между ними, потому что они совместно используют кэши. Но вы не можете заставить их работать быстрее – есть вполне конкретное ограничение скорости. Их продолжают понемногу улучшать, но уже не настолько сильно. На пути улучшений встали законы физики. Алексей: Звучит очень разумно. С новыми многоядерными процессорами пришли новые проблемы. Ожидали ли вы и ваши коллеги этих проблем? Быть может, вы изучали их заранее? В теоретических исследованиях зачастую не очень легко предсказывать такие вещи. Когда проблемы всё же случились – насколько они соответствовали вашим ожиданиям и ожиданиям ваших коллег? Или же они были совершенно новыми, и вы с коллегами должны были тратить много времени на решение проблем по мере их появления? Виталий: Добавлю к вопросу Алексея: правильно ли вы спрогнозировали архитектуру процессоров, пока занимались теорией? Морис: Не все 100%. Но я думаю, что мы с коллегами хорошо поработали, прогнозируя многоядерность с общей памятью. Думаю, мы правильно предсказали сложности в разработке параллельных структуры данных, работающих без блокировок. Такие структуры данных были важны для многих приложений, хоть и не для всех, но зачастую вам действительно нужна структура данных без блокировки. Когда мы изобретали их, многие утверждали, что это чепуха, что и с блокировками все отлично работает. Мы достаточно хорошо предвидели, что появятся готовые решения для многих проблем программирования и проблем структур данных. Существовали и более сложные проблемы, такие как NUMA – неравномерный доступ к памяти. На самом деле, они даже не рассматривались до изобретения многоядерных процессоров, поскольку были слишком специфичны. Исследовательское сообщество работало над вопросами, которые были в целом предсказуемы. Некоторым аппаратным проблемам, связанным с конкретными архитектурами, пришлось подождать своего часа – собственно, появления этих архитектур. Например, никто особо не работал над структурами данных, специфичными для GPU, потому что GPU тогда не существовало. Несмотря на то, большая работа была проделана над SIMD, эти алгоритмы были готовы к применению сразу же, как появилось подходящее железо. Тем не менее, предвидеть всё невозможно. Алексей: Если я правильно понимаю, NUMA является своего рода компромиссом между стоимостью, производительностью и некоторыми другими вещами. Есть идеи, почему NUMA появилась так поздно? Морис: Думаю, что NUMA существует благодаря проблемам с железом, использующимся для производства памяти: чем дальше находятся компоненты, тем медленнее к ним доступ. С другой стороны, вторая ценность этой абстракции – равномерность памяти. Поэтому одной из характеристик параллельных вычислений является то, что все абстракции слегка сломаны. Если бы доступ был идеально равномерным, вся память была бы равноудалённой, но это экономически, а может даже и физически невозможно. Поэтому возникает этот конфликт. Если вы пишете свою программу так, как если бы память была равномерной, то скорее всего, она будет корректной. В том смысле, что она не будет выдавать неправильных ответов. Но и производительность у неё звёзд с неба не схватит. Точно так же, если вы пишете спинлоки без понимания иерархии кэшей, сама-то блокировка будет корректной, но о производительности можно забыть. В каком-то смысле, вы должны писать программы, живущие поверх очень простой абстракции, но вы должны перехитрить людей, которые эту абстракцию вам предоставили: вы обязаны знать, что под абстракцией лежит некая иерархия памяти, что есть шина между вами и этой памятью, и так далее. Таким образом, существует некий конфликт между полезными поодиночке абстракциями, что приводит нас к очень конкретным и прагматичным проблемам. Виталий: Что насчёт будущего? Можно ли вы предсказать, как процессоры будут развиваться дальше? Есть идея, что одним из ответов является транзакционная память. Вероятно, у вас есть что-то ещё в запасе. Морис: Впереди есть пара основных проблем. Одна из них заключается в том, что когерентная память – замечательная абстракция, но она начинает ломаться в специальных случаях. Так, например, NUMA является живым примером чего-то, где можно продолжать притворяться, что существует равномерная память. На самом деле – нет, производительность заставит вас заплакать. В какой-то момент архитекторам придется отказаться от идеи об единой архитектуре памяти, нельзя притворяться вечно. Понадобятся новые модели программирования, достаточно простые в использовании и достаточно мощные, чтобы нижележащее оборудование было эффективным. Это очень сложный компромисс, ведь если вы покажете программистам ту архитектуру, которая на самом деле используется в железе, они сойдут с ума. Это слишком сложно и не переносимо. Если же вы представите слишком простой интерфейс, то производительность будет плохой. Таким образом, потребуется достигнуть множество очень непростых компромиссов, необходимых для обеспечения полезных моделей программирования, применимых к действительно большим многоядерным процессорам. Я не уверен, что кто-то кроме узкого специалиста способен программировать на 2000-ядерном компьютере. И если вы не делаете очень специализированные или научные вычисления, криптографию или что-то такое – все еще совершенно не ясно, как это правильно делать.  Другим подобным направлением являются специализированные архитектуры. Графические ускорители существуют уже давно, но уже стали своего рода классическим примером того, как можно взять специализированный тип вычислений и запустить их на выделенном чипе. Это добавляет свои собственные проблемы: как вы общаетесь с таким устройством, как вы его программируете. Я недавно работал над задачами в области near memory computing. Вы берете небольшой процессор и приклеиваете его к огромному куску памяти, так что память работает на скорости L1-кэша, а затем происходит связь с устройством вроде TPU – процессор занимается загрузкой новых задач в ваше ядро памяти. Разработка структур данных и протоколов связи для такого рода вещей – еще один интересный пример. Таким образом, специализированные процессоры и аппаратное обеспечение будут подвергаться улучшениям в течение достаточно долгого времени. Алексей: Что насчет энергонезависимой памяти (non-volatile memory)? Морис: О, это еще один отличный пример! NVM очень сильно изменит наш взгляд на такие вещи, как, например, структуры данных. Энергонезависимая память, в некотором смысле, обещает действительно всё ускорить. Но она не сделает жизнь проще, потому что большинство процессоров, кэши и регистры все еще энергозависимы. Когда вы начинаете работу после сбоя, ваше состояние и состояние вашей памяти не будет в точности теми же, что были до сбоя. Я очень благодарен людям, занимающимся NVM – долгое время исследователям будет чем заняться, пытаясь выяснить условия корректности. Вычисления корректны, если они могут пережить сбой, в котором потерялось содержимое кэшей и регистров, но основная память осталась неизменной. Владимир: Что вы думаете о дилемме «компиляторы против процессоров» с точки зрения набора команд? Объясню для тех, кто не в теме: если мы перейдем к неравномерной памяти или чему-то подобному, мы могли бы применить очень простой набор команд и попросить компилятор сгенерировать сложный код, способный использовать открывшиеся преимущества. Или мы можем пойти другим путем: реализовать сложные инструкции и попросить процессор переупорядочить инструкции и проводить с ними другие манипуляции. Что вы думаете об этом? Морис: У меня действительно нет ответа на этот вопрос. Эта дискуссия продолжается в течение четырех десятилетий. Было время, когда между сокращенным набором команд и сложным набором команд велись гражданские войны. Какое-то время выигрывали RISC-овые люди, но потом Intel перестроили свои движки так, чтобы внутри использовался сокращенный набор инструкций, а наружу экспортировался полный. Наверное, это та тема, в которой каждое новое поколение должно найти собственные компромиссы и принять собственные решения. Очень трудно предсказать, какая из этих вещей окажется лучше. Поэтому любое предсказание, которое я сделаю, будет верным в течение определенного времени, а потом какое-то время снова станет ложным, а затем снова верным. Алексей: Насколько вообще для отрасли обычной является такая ситуация, что некоторые идеи выигрывают в течение нескольких десятилетий и проигрывают в следующих? Есть ли другие примеры таких периодических перемен? Морис: В теме распределенных вычислений есть люди, которые верят в разделяемую память и люди, которые верят в обмен сообщениями. Изначально в распределенных вычислениях параллельные вычисления означают передачу сообщений. Потом кто-то обнаружил, что с разделяемой памятью программировать куда проще. Противоположная сторона заявила, что разделяемая память – штука слишком сложная, потому что там нужны блокировки и тому подобное, потому стоит перейти на языки, где ничего кроме передачи сообщений просто не существует. Кто-то посмотрел, что из этого вышло и говорит: «ого, эта реализация обмена сообщениями выглядят очень похоже на разделяемую память, потому что вы создаете много-много этих маленьких модулей, они отправляют сообщения друг другу, и все они взаимоблокируются, – давайте лучше сделаем базу данных с разделяемой памятью!». Всё это повторяется снова и снова, и невозможно сказать, что одна из сторон однозначно права. Одна из сторон всегда будет доминировать, потому что, как только одна из них почти побеждает, люди снова и снова изобретают способы улучшить противоположную. Алексей: Это очень интересно. Например, когда мы пишем код, неважно на каком языке программирования, обычно приходится создавать абстракции вроде ячеек, которые можно читать и писать. Но на самом-то деле, на каком-то физическом уровне это может выглядеть как отправка сообщения по аппаратной шине между разными компьютерами и другими устройствами. Получается, происходит работа сразу на обоих уровнях абстракции. Морис: Абсолютно верно, что разделяемая память построена на передаче сообщений – шины, кэши и так далее. Но с использованием передачи сообщений трудно писать программы, поэтому железо намеренно лжёт, притворяясь, что у вас есть какая-то равномерная память. Так вам будет проще писать простые корректные программы, пока производительность не начнет падать. Тогда вы скажете: похоже, настала пора подружиться с кэшем. И вот тогда вы начинаете беспокоиться о местонахождении кэша, и дальше пошло-поехало. В некотором смысле вы взламываете абстракцию: вы знаете, это не просто плоская равномерная память и собираетесь воспользоваться этими знаниями для написания программ, дружественных к кэшу. Это то, что придётся делать в реальных задачах. Этот конфликт между милой простой приятной абстракцией, которую вам выдали, и ужасающе сложной реализацией нижележащего железа – это то, где каждый пойдет на собственный компромисс. У меня есть книга о мультипроцессорах и синхронизации, и в один прекрасный момент я собирался написать главу о структурах данных в java.util.concurrent. Если вы посмотрите на них, на вещи вроде списков с пропусками – это изумительные произведения искусства. (Примечание редакции: тем, кто знаком с языком Java, стоит хоть раз взглянуть на реализацию ConcurrentSkipListMap, по ссылкам можно посмотреть на API и иcходный код). Но с моей точки зрения, было бы безответственно показывать их студентам, ведь такая структура данных своего рода парень в цирке, бегущий по канату над медвежьей ямой. Если вы измените хоть одну маленькую деталь, рухнет вся конструкция. Этот код очень быстрый и элегантный лишь потому, что он идеально написан, но малейшее изменение приведет к полному провалу. Если я поставлю этот код в пример студентам, они сразу скажут: я тоже могу так делать! И тогда какой-нибудь самолет упадет или ядерный реактор взорвется, и я буду виноват в том, что не вовремя предоставил им слишком много информации. Алексей: Когда я был чуть моложе, то много раз я пытался изучать исходный код Дага Ли, например, java.util.concurrent, ведь это открытый исходный код, его очень легко найти и попытаться понять, что там происходит. Выходило не очень: зачастую, совершенно неясно, почему Даг решил что-то сделать именно таким образом, когда все остальные делают по-другому. Как вы объясняете своим студентам такие вещи? Если ли особый правильный способ описывать конкретные детали хардкорного алгоритма, например? Как вам это удается? Морис: У преподавателей рисунка есть клише, которое они вспоминают первым делом: если вы хотите рисовать, как Пикассо, нужно сперва научиться рисовать простые реалистичные картинки, и лишь когда вы знаете правила можно начинать их нарушать. Если сразу начать с нарушения правил, получится беспорядок. Сперва я учу студентов как писать простой корректный код, не беспокоясь о производительности. Я говорю: тут прячутся сложные проблемы синхронизации, поэтому не беспокойтесь о кэшах, не беспокойтесь о моделях памяти, просто убедитесь, что всё правильно работает. Это уже достаточно сложно: современное программирование непросто само по себе, особенно для новых студентов. И вот когда у них появляется интуиция о том, как писать правильные программы, я говорю: посмотрите на эти две реализации спинлока: одна очень медленная, а вторая – тоже не очень, но уже получше. Тем не менее, математически эти два алгоритма совпадают. На самом деле, один из них использует локальность кэша. Один из них крутится на локально кэшированных данных, а другой многократно совершает операции, идущие через шину. Нельзя написать эффективный код, если вы не понимаете его сути, не знаете, как нарушить абстракцию и посмотреть на нижележащую структуру. Но вы не сможете сразу начать так делать. Есть люди, которые начинают делать так сразу и верят в собственную гениальность, обычно это плохо заканчивается, потому что они не понимают принципов. Никто не рисует как Пикассо и не пишет программы как Даг Ли, только что поступив в университет, в первую же неделю. Требуются годы, чтобы достичь такого уровня знаний. Алексей: Получается, вы разделяете проблему на две части: первая – корректность, вторая – производительность? Морис: Именно. Причём, именно в таком порядке. Часть проблемы заключается в том, что новые студенты не понимают, что достичь корректности сложно. Они с первого взгляда говорят: это, очевидно, корректно, осталось только ускорить. Поэтому иногда я рассказываю им об изначально некорректном алгоритме, как если бы он был корректным. Алексей: Чтобы просто проверить, смогут ли они почувствовать подвох? Морис: Я всегда предупреждаю заранее, что иногда буду предлагать неправильные алгоритмы. Не стоит обманывать людей. Я предлагаю им скептически относиться к информации. Если я что-то рассказываю и говорю: «смотрите, это очевидно правильно» — это сигнал, что где-то тебя пытаются обмануть, и следует начать задавать вопросы. Далее я стараюсь поддержать студентов, чтобы они не переставали задавать вопросы, и затем подсказываю: «что произойдет, если мы оставим все как есть?». И они сразу видят ошибку. Но убедить студентов, что им нужно побеспокоиться о корректности, куда сложнее, чем кажется на первый взгляд. Многие из этих студентов приходят с опытом программирования в старших классах, кто-то успел устроиться на работу и занимался программированием там, и все они полны уверенности в себе. Это что-то армейское: приходится вначале переломить их настрой, чтобы убедить терпеливо подходить к решению возникающих проблем. Или может это как у буддистских монахов: вначале они учатся рассуждать о корректности и как только они осознают способы рассуждений о корректности, им разрешается перейти на следующий уровень и начать беспокоиться о производительности. Алексей: То есть, иногда вы показываете студентам нерабочие примеры, благодаря чему получаете обратную связь, показывающую, понимают ли они суть проблемы, могут ли найти неправильный код и неправильный результат. Ну и как, студенты обычно радуют или огорчают? Морис: Почти всегда студенты в конце концов находят ошибку. Если они ищут слишком медленно, я задаю наводящие вопросы, и тут важно понять, что если их никогда не обманывать – они начнут бездумно воспринимать твои слова как истину в конечной инстанции. Потом им станет скучно и они начнут засыпать, читая Facebook на ноутбуке прямо во время занятия. Но когда вы заранее сообщаете, что их попытаются обмануть, и они будут выглядеть глупо, если не почувствуют подвоха, они становятся куда более бдительными. Это хорошо в разных смыслах. Хочется, чтобы студенты не только ставили под сомнение свое понимание вопроса, но ещё и ставили под сомнение авторитет преподавателя. Идея в том, чтобы студент мог в любое время поднять руку и сказать: думаю, то, что вы сейчас сказали – неверно. Это важный инструмент обучения. Я не хочу, чтобы кто-то из студентов сидел и молча про себя думал: всё это кажется полным бредом, но поднять руку слишком страшно, да и вообще, он же профессор, значит всё, что он говорит – истина. Поэтому, если заранее предупредить, что не всё рассказанное обязательно является правдой, у них появляется стимул уделять больше внимания материалу. Я явным образом проговариваю, что поднимать руку и задавать вопросы – это нормально. Ваш вопрос может прозвучать глупо или наивно, но зачастую именно так появляются самые хорошие вопросы. Алексей: Очень интересно. Обычно у людей есть своего рода психологический барьер, не позволяющий задавать вопросу профессору. Особенно если в комнате много людей, и все боятся, что обсуждение твоего глупого вопроса отнимет время у всех этих людей. Есть ли какие-нибудь хитрости, как с этим справиться? Морис: Я часто останавливаюсь и задаю классические вопросы. Будет ли правильным какое-то утверждение, или как бы они решили обсуждаемую проблему. Это ключевое действие, особенно в начале занятия, когда люди стесняются сказать даже самую малость. Вы задаете вопрос студентам и дальше ничего не говорите. Наступает тишина, все немного напрягаются, напряжение растёт, потом вдруг кто-то не выдерживает, срывается и говорит ответ. Так вы разворачиваете ситуацию: продолжать молчать становится сложнее и неудобней, чем ответить! Это стандартный педагогический трюк. Каждый учитель в мире должен знать, как такое сделать. Алексей: Теперь у нас есть отличное название для этого интервью: «проще ответить, чем продолжать молчать». Виталий: Давайте я ещё спрошу. Вы работаете над топологическими доказательствами. Как вы вообще в это ввязались, ведь распределённые вычисления и топология – вообще разные вещи! Морис: Там есть скрытая взаимосвязь. Когда я был студентом и учился математике, я изучал чистую математику. У меня не было реального интереса к компьютерам, пока обучение не подошло к концу, и я обнаружил себя перед насущной необходимостью искать работу. Ещё студентом я изучал алгебраическую топологию. Много лет спустя, работая над задачей под названием «k-Set Agreement Problem», для моделирования проблемы я использовал графы и, как тогда казалось, нашёл решение. Надо было просто сесть и обойти граф. Попытаться найти на этом графе подходящий ответ. Но мой алгоритм не сработал: оказалось, что он вечно будет бегать по кругу. К сожалению, всё это нельзя было объяснить формальным языком теории графов – тем, который знают все специалисты в области информатики. А потом я вспомнил, что много лет назад, ещё на занятиях по топологии мы использовали понятие «симплициальный комплекс», являющееся обобщением графов на более высокие размерности. Тогда я задался вопросом: что будет, если переформулировать проблему в терминах симплициальных комплексов? Это стало ключевым моментом. При использовании более мощного формализма, проблема внезапно становится намного проще. Люди долго боролись с ней, используя графы, но так и не смогли ничего. Да и сейчас не могут – правильным ответом оказался не алгоритм, а доказательство невозможности решения задачи. То есть, такой алгоритм просто не существует. Но каждое доказательство невозможности основано либо на симплициальных комплексах, либо на вещах, которые люди притворились не считать симплициальными комплексами. От того, что ты назвал нечто новым именем, своей сущности оно не теряет. Виталий: Получается, вам просто повезло? Морис: Кроме удачи, это ещё и готовность. Имеется в виду, вы не должны забывать «бесполезные» вещи, изученные ранее. Чем больше бесполезных вещей вы узнаете, тем больше идей вы сможете извлечь, столкнувшись с новой проблемой. Такой интуитивный паттерн-матчинг важен, потому что… Давайте так, это цепочка: вначале я обнаружил, что графы не совсем работают или совсем не работают, это напомнило что-то из событий восьмилетней давности и студенческие годы, когда мы изучали все эти симплициальные комплексы. В свою очередь это позволило найти мой старый учебник по топологии и загрузить его назад в голову. Но если бы не те старые знания, я никогда бы не продвинулся в решении изначальной проблемы. Алексей: Вы сказали пару слов о своей книге. Наверное, это не самая страшная тайна, что вы написали самую известную в мире книгу по многопоточности, «The Art of Multiprocessor Programming». Ей уже около 11 лет и с тех времён вышел только  revised reprint. Будет ли второе издание? Морис: Это хорошо, что вы спросили! Будет совсем скоро, месяца через три или около того. Есть еще два автора, мы добавили намного больше материала, улучшили раздел про fork/join-параллелизм, написали раздел про MapReduce, добавили много нового и выбросили ненужное – то, что в момент написания первого издания было очень интересно, а сегодня уже нет. Получилась очень серьёзно переработанная книга. Алексей: Всё уже сделано, осталось только выпустить? Морис: Пару глав все еще нужно дорабатывать. Наш издатель (думаю, он нас уже ненавидит) все еще старается донести, что нам стоит работать быстрее. Мы сильно отстали от графика. Теоретически, мы могли бы сделать эту книгу на пару лет раньше. Алексей: Есть ли шансы заполучить новую версию книги перед Рождеством? Морис: Это и есть наша цель! Но я предсказывал победу так много раз, что никто мне больше не верит. Вам, наверное, тоже не стоит особо мне доверять в этом вопросе. Алексей: В любом случае, это фантастическая новость. Первое издание книги мне очень понравилось. Можно сказать, я фанат. Морис: Надеюсь, и новое издание окажется достойно вашего горячего энтузиазма, спасибо! Виталий: Следующий вопрос про транзакционную память. Насколько я понял, вы – пионер в этой области, вы изобрели ее в то время, когда никто и не задумывался над такими вещами. Почему вы решили перейти в эту область? Почему транзакции показались вам важными? Думали ли вы, что когда-нибудь их воплотят в железе? Морис: Я знал о транзакциях со времен исследований в аспирантуре. Виталий: Да, но это другие транзакции! Морис: Я работал с Эллиоттом Моссом над неблокирующей сборкой мусора. Наша проблема была в том, что нам хотелось атомарно изменять несколько слов в памяти и тогда алгоритмы стали бы очень простыми, и по крайней мере, некоторые из них стали бы эффективней. Используя compare-and-swap для load-link/store-conditional, предоставляемый параллельной архитектурой, сделать что-то можно, но это очень неэффективно и уродливо, потому что вам пришлось бы заниматься уровнями косвенности. Я хочу изменить слова памяти и мне нужно переключаться, потому что я могу изменить только один указатель, поэтому указывать им нужно на какую-то структуру, похожую на каталог. Мы говорили о том, как замечательно было бы, если бы мы могли так поменять железо, чтобы оно смогло делать одновременную запись. Кажется, это заметил Эллиот: если посмотреть на протоколы когерентности кэша, они уже предоставляют большую часть необходимой функциональности. В оптимистичной транзакции, протокол когерентности кэша заметит наличие конфликта синхронизации и кэш cтанет недействительным. Что будет, если  спекулятивно запустить транзакцию на своем кэше и использовать механизмы протокола когерентности для обнаружения конфликтов? Спекулятивную аппаратную архитектуру спроектировать было легко. Так мы и написали ту самую первую публикацию про транзакционную память. В то же время, компания, в которой я работал, Digital Equipment Corporation, создавала новый 64-разрядный процессор под названием Alpha. И вот я пошел и сделал презентацию для группы разработчиков Alpha про нашу замечательную транзакционную память и они спросили: какой дополнительный доход получит наша компания, если мы всё это добавим прямо в процессор? И у меня не было абсолютно никакого ответа на это, потому что я – технолог, я не специалист по маркетингу. Мне действительно нечего было ответить. Они не очень впечатлились тем, что я ничего не знаю. Виталий: Миллиарды! Просто говорите «миллиарды»! Морис: Да, это я и должен был сказать. Теперь, в эпоху стартапов и всего такого, я знаю, как написать бизнес-план. Что можно немного соврать о размере потенциальной прибыли. Но в те дни это казалось наивным, поэтому я просто сказал: «не знаю». Если вы посмотрите на историю публикации про транзакционную память, то заметите, что через год появилось несколько ссылок на нее, а затем около десяти лет никто вообще не цитировал эту статью. Цитаты появились примерно в 2004 году, когда появилась настоящая многоядерность. Когда люди открыли для себя, что написание параллельного кода может приносить деньги, начались новые исследования. Рави Раджвар написал статью, в некотором роде познакомившую мейнстрим с понятием транзакционной памяти. (Примечание редакции: у статьи есть вторая версия, выпущенная в 2010 году и свободно доступная в виде PDF). Внезапно люди осознали как именно все это можно использовать, как можно ускорять традиционные алгоритмы с блокировками. Хороший пример чего-то, что в прошлом казалось лишь интересной академической проблемой. И да, если бы вы в те времена спросили меня, считаю ли я, что всё это окажется важным в будущем, я бы сказал: конечно, но когда именно – непонятно. Может быть, лет через 50? На практике это оказалось всего десятилетие. Очень приятно, когда ты что-то делаешь, и всего через десять лет люди это замечают. Виталий: Если говорить о новых исследованиях, что бы вы посоветовали читателям — распределённые вычисления или многоядерность и почему?  Морис: В наши дни легко получить многоядерный процессор, но сложнее настроить настоящую распределенную систему. Я начал работать над ними, потому что хотел сделать что-то, отличающееся от моей кандидатской диссертации. Это совет, который я всегда даю новичкам: не пишите продолжение диссертации – попробуйте идти в новом направлении. А ещё, многопоточность – это просто. Я могу проводить эксперименты над собственным форком, запущенном на ноутбуке, не вставая с кровати. Но если бы я вдруг хотел создать настоящую распределенную систему, пришлось провернуть бы большую работу, привлечь студентов, и так далее. Я человек ленивый и предпочел бы работать над многоядерностью. Эксперименты над многоядерными системами тоже делать проще, чем над распределенными, потому что даже в глупой распределенной системе есть слишком много факторов, которые необходимо контролировать. Виталий: Чем вы сами сейчас занимаетесь, исследуете блокчейн? На какие статьи стоит обратить внимание в первую очередь? Морис: Недавно появилась очень хорошая статья, которую я написал вместе со своим студентом, Викрамом Сарафом, специально для выступления на конференции Tokenomcs в Париже три недели назад. Это статья о полезных на практике распределенных системах, в которой мы предлагаем сделать Ethereum многопоточным. Сейчас смарт-контракты (код, запускающийся на блокчейне) выполняются последовательно. Мы ещё раньше написали статью, в которой говорилось о способе использовать спекулятивные транзакции для ускорения процесса. Мы взяли много идей из программной транзакционной памяти и сказали, что если вы сделаете эти идеи частью виртуальной машины Etherium, тогда всё заработает быстрее. Но для этого необходимо, чтобы в контрактах не было конфликтов по данным. А потом мы предположили, что в реальной жизни таких конфликтов действительно нет. Но у нас не было возможности это выяснить. Затем нам пришло в голову, что у нас на руках почти десять лет истории реальных контрактов, поэтому мы выгрузили блокчейн Etherium и задались вопросом: что бы произошло, если бы эти исторические записи выполнялись параллельно? Мы обнаружили существенный прирост скорости. В первые дни жизни Etherium скорость повысилась очень сильно, но сегодня всё несколько сложнее, потому что контрактов стало меньше и выше стала вероятность конфликтов по данным, требующим сериализации. Но всё это – экспериментальная работа с реальными историческими данными. Что приятно в блокчейне — он помнит всё и навсегда, поэтому можно вернуться в прошлое и изучить, что произошло бы, если бы мы использовали для запуска кода другие алгоритмы. Как людям там, в прошлом, пришлась бы по вкусу наша новая идея. Такие исследования делать куда проще и приятнее, ведь есть штука, которая за всем следит и всё записывает. Это уже что-то, больше похожее на социологию, чем на разработку алгоритмов. Виталий: Время последнего теоретического вопроса! Есть ощущение, что подвижки в области конкурентных структур данных сокращаются каждый год? Как вы думаете, мы подошли к плато в нашем понимании структур данных или будут какие-то серьезные улучшения? Может, существуют какие-то хитрые идеи, которые могут полностью изменить все? Морис: Возможно, мы достигли плато в структурах данных для традиционных архитектур. Но структуры данных для новых архитектур все еще очень перспективная область. Если вы хотите создавать структуры данных, скажем, для аппаратных ускорителей, то структуры данных для GPU сильно отличаются от структур данных для CPU. Когда вы разрабатываете структуры данных для блокчейнов, нужно хешировать кусочки данных и потом укладывать во что-то вроде дерева Меркле, для предотвращения подделок. В этой области в последнее время наблюдается всплеск активности, многие делают очень хорошую работу. Но я думаю, случится так, что новые архитектуры и новые приложения приведут к новым структурам данных. Старые приложения и традиционная архитектура – возможно, там уже не так много пространства для исследований. Но если вы сойдете с проторенной дорожки, и посмотрите за край, вы увидите сумасшедшие вещи, которые мейнстрим не воспринимает всерьез – вот где все захватывающие вещи и происходят на самом деле. Виталий: Поэтому, чтобы быть очень известным исследователем, я должен был изобрести свою собственную архитектуру :-) Морис: Можно «украсть» чужую новую архитектуру – кажется, это намного проще! Виталий: Не могли бы вы подробней рассказать о Брауновском Университете, в котором вы работаете? Про него в контексте информационных технологий известно не так уж много. Меньше, чем о MIT, например. Морис: Брауновский Университет – один из старейших университетов в Соединенных Штатах. Я думаю, что только Гарвард немного старше. Браун является частью так называемой Лиги плюща, которая представляет собой собрание восьми старейших университетов. Гарвард, Браун, Корнелл, Йель, Колумбия, Дартмут, Пенсильвания, Принстон. Это своего рода старый, маленький и немного аристократический университет. Основное внимание уделяется гуманитарному образованию. Он не пытается быть похожим на MIT, MIT очень специализированный и технический. Браун – отличное место для изучения русской литературы или классического греческого языка, и конечно же, Computer Science. Он сосредоточен на всестороннем образовании. Большинство наших студентов уходят в Facebook, Apple, Google – поэтому, думаю, у наших студентов нет проблем устроиться и в индустрии. Я пошел работать в Браун, потому что до этого работал Digital Equipment Corporation в Бостоне. Это была компания, которая изобрела много интересного, но отрицала важность персональных компьютеров. Компания с непростой судьбой, основатели которой  однажды были когда-то молодыми революционерами, они ничему не научились и ничего не забыли, и поэтому они превратились из революционеров в реакционеров в течение примерно десятка лет. Они любили шутить, что персональным компьютерам место в гараже – в заброшенном гараже, конечно. Вполне очевидно, что они оказались уничтожены более гибкими компаниями. Когда стало ясно, что у компании проблемы, я позвонил своему другу из Брауна, который находится примерно в часе езды от Бостона. Я не хотел уезжать из Бостона в то время, ведь в других университетах было не так много вакансий. Это было время, когда в области Computer Science не было настолько много вакансий, как сейчас. А у Брауна была вакансия, мне не нужно было переезжать из своего дома, не нужно было перевозить семью, да и мне очень нравится жить в Бостоне! Так я и принял решение пойти в Браун. Мне понравилось. Студенты замечательные, поэтому я никогда даже не пытался уйти куда-то еще. На творческом отпуске я работал в Microsoft в течение года, на год уходил в Technion в Хайфе, сейчас буду в Algorand. У меня везде много коллег и поэтому физическое расположение наших учебных классов не так уж важно. А вот самое главное – студенты, они здесь самые лучшие. Я никогда не пытался уйти куда-нибудь еще, потому что вполне счастлив и здесь. Тем не менее, несмотря на известность Брауна в Соединенных Штатах, он удивительно неизвестен за рубежом. Как видите, сейчас я делаю все возможное, чтобы исправить это положение вещей. Виталий: Хорошо, следующий вопрос о Digital Equipment. Вы были там исследователем. В чем разница между работой в R&D-отделе крупной компании и работой в университете? Каковы преимущества и недостатки? Морис: За двадцать лет я успел поработать в Microsoft, тесно взаимодействовал с сотрудниками Sun Microsystems, Oracle, Facebook, а теперь и Algorand. На основании этого всего хочу сказать, что возможно проводить первоклассные исследования и в компаниях, и в университете. Важные различие в том, что в компании вы работаете с коллегами. Если у меня вдруг появилась идея несуществующего пока проекта, я должен убедить равных себе коллег, что это хорошая идея. Если же я в Брауне, то можно сказать своим студентам: давайте работать над антигравитацией! Они либо уйдут к кому-то другому, либо возьмутся за проект. Да, мне нужно будет найти финансирование, мне нужно будет написать заявку на грант и так далее. В любом случае, всегда найдётся множество студентов, и вы сможете в одностороннем порядке принимать решения. Но в университете вы, скорее всего, не будете работать с людьми вашего уровня. В мире промышленных исследований вначале придется убеждать всех, что за ваш проект стоить браться. Я не могу никому ничего приказать. И оба эти способа работы ценны, ведь если вы работаете над чем-то действительно сумасшедшим и ваших коллег трудно убедить, легче убедить аспирантов – особенно если вы же им и платите. Если вы работаете над чем-то, что требует большого опыта и глубокой экспертизы, то вам нужны коллеги, которые смогут сказать «нет, так случилось, что я понимаю в этой области и твоя идея плохая, ничего не выйдет». Это очень полезно с точки зрения траты времени. А еще, если в промышленных лабораториях вы тратите кучу времени на написание отчетов, то в университете вы тратите это время на то, чтобы найти деньги. Если я хочу, чтобы студенты смогли куда-то съездить, я должен найти на это деньги в каком-то другом месте. И чем более важное у вас положение в университете, тем больше времени приходится проводить, собирая деньги. Так что, теперь вы знаете, кем я работаю – профессиональным нищим! Как один из тех монахов, которые ходят с тарелкой для пожертвований. В общем, эти два вида деятельности дополняют друг друга. Вот почему я стараюсь жить и прочно стоять на ногах в обоих мирах. Виталий: Кажется, убедить компанию сложнее, чем убедить других ученых. Морис: Сложнее, и намного. Причем, в разных областях по-разному: кто-то проводит полномасштабные исследования, а кто-то сфокусирован на своей теме. Если я пошел бы в Microsoft или Facebook и сказал: давайте сделаем антигравитацию, они вряд ли бы это оценили. Но если бы я сказал в точности то же самое своим аспирантам, они скорее всего взялись бы за работу мгновенно, хотя проблемы теперь были бы уже у меня – ведь нужно найти на это деньги. Но пока вы хотите делать нечто, соответствующее целям компании, такая компания может быть очень хорошим местом для проведения исследований. Виталий: Мои вопросы подходят к концу, поэтому давайте поговорим немного про предстоящее путешествие в Россию. Морис: Да, я с нетерпением жду возвращения в Петербург. Алексей: Для меня большая честь, что вы с нами в этом году. Вы уже второй раз в Питере, верно? Морис: Уже третий! Алексей: Понял, но на SPTDC – точно второй. В прошлый раз школа называлась SPTCC, сейчас мы изменили одну букву (C на D, Concurrent на Distributed), чтобы подчеркнуть, что направлений, касающихся именно распределенных вычислений, в этом году стало больше. Можете сказать пару слов о ваших докладах на Школе и конференции Hydra? Морис: На Школе я хочу рассказать об основах работы блокчейна и что с ним вообще можно делать. Хочется показать, что блокчейны очень похожи на знакомое нам многопоточное программирование, но со своими нюансами, и эти различия важно понимать. Если вы допустите ошибку в обычном веб-приложении – это просто неприятно. Если вы напишете забагованный код в финансовом приложении, кто-нибудь точно украдет все ваши деньги. Это совершенно разный уровень ответственности и последствий. Я немного поговорю о proof-of-work, о смарт-контрактах, о транзакциях между разными блокчейнами. Рядом со мной будут работать другие спикеры, которым тоже есть что сказать про блокчейн, и мы договорились скоординироваться между собой, чтобы наши истории хорошо стыковались. А вот для инженерного доклада я хочу рассказать понятное широкой аудитории объяснение, почему не стоит верить всему, что вы слышите про блокчейны, почему блокчейны – это отличная область, как она стыкуется с другими известными идеями, и почему нам стоит смело смотреть в будущее. Алексей: В дополнение хочу сказать, что проходить это будет не в формате митапа или пользовательской группы, как это было два года назад. Мы решили сделать рядом со школой небольшую конференцию. Причина в том, что после общения с Петром Кузнецовым мы осознали, что школа ограничена всего лишь сотней, может быть 120 людьми. При этом есть очень много инженеров, которые хотят с вами пообщаться, побывать на докладах, и вообще интересуются темой. Ради этого мы создали новую конференцию под названием Hydra. Кстати, есть идеи, почему именно Гидра? Морис: Потому что на ней будет семь спикеров? И им можно отрезать головы, и на их месте вырастут новые спикеры? Алексей: Отличная идея для выращивания новых спикеров. Но на самом деле, тут есть история. Помните легенду об Одиссее, там где он должен был проплыть между Сциллой и Харибдой? Гидра – это нечто вроде Харибды. История в том, что как-то раз я выступал на конференции и рассказывал про многопоточность. На этой конференции было всего два трека. В начале доклада я сказал слушателям в зале, что у них теперь есть выбор между Сциллой и Харибдой. Моим тотемным животным стала Харибда, потому что у Харибды множество голов, а у меня тема – многопоточность. Так и появляются названия конференций. В любом случае, у нас закончились и вопросы и время. Так что, спасибо, друзья, за отличное интервью, и встретимся на школе SPTDC и конференции Hydra 2019! Деврел Axiom JDK, продюсер в Failover Bar