Скотт Мейерс — один из самых известных и признанных экспертов по C++, автор серии книг «Эффективное использование C++», которые читал почти каждый профессиональный разработчик на C++ и которые оказали заметное влияние на всю экосистему и качество использование языка.
Лично я стал почти его фанатом ещё студентом, когда в начале 2000-х читал статьи Скотта, лежащие в основе его книг (сами книги на тот момент в России ещё не были переведены, а на английские с Амазона у меня, как бедного студента, денег не было).
Поэтому, когда он некоторое время назад приехал в Яндекс, чтобы провести тренинг для наших разработчиков, я не мог не воспользоваться этим шансом, чтобы поговорить с ним. Разговор получился о том, каким он видит будущее C++ и программирования вообще, как отличаются разработчики в разных странах и в разных индустриях, и о нём самом.
Назовите два или три самых важных изменения в C++11/14
Если говорить о том, с чем большинство программистов сталкиваются ежедневно, то это auto для объявления переменных, а также, вероятно, лямбда-выражения. Это два самых заметных изменения.
Лично я считаю наиболее фундаментальным улучшением поддержку параллелизма, которой в С++ не было вовсе. Эта фича не так бросается в глаза программистам, разве что создателям компиляторов. Но если говорить о воздействии на людей в общем, то, весьма вероятно, что именно эта фича окажет максимальное влияние. Очевидно, что семантика переноса также крайне важна, но с этой точки зрения параллелизм кажется чуточку более существенным.
А какие два изменения были самыми спорными или вредными?
Пара вещей приходит в голову. Обе основаны на идеях, которые я считаю вполне разумными. Но потом возникает вопрос, а правильно ли они применялись? Первое — это то, что обычно называют универсальной инициализацией. Ее идея заключалась в том, что у нас будет единый синтаксис для инициализации всего подряд. Достигнуть этого не удалась, так как в некоторых случаях была неопределенность, были ситуации, в которых нельзя использовать списковую инициализацию, нужно использовать другую форму. То есть, похоже, были некоторые разногласия относительно того, следовало ли эту фичу имплементировать именно так.
На ум приходят еще async и futures. На самом деле, это прекрасная идея. Просто говоришь, что хочешь запустить что-нибудь асинхронно, и думать об этом уже не нужно. Но в том, что касается спецификаций поведения фьючерсов, выходящих из async, было сделано много интересного. Внутри комитета было много споров, нужно ли это исправлять или чем-то заменить. Как мне кажется, есть все шансы, что начиная с С++17 будут внедряться новые функции, призванные заменить эту.
Комитет по стандартизации достаточно эффективно выполняет свою работу?
Первое, что я хотел бы сказать о Комитете по стандартизации (а я в нем не состою, это нужно обозначить сразу), — перед ними стоит очень непростая задача. Материал требует чрезвычайно глубоких технических знаний. Я испытываю огромное уважение к тем, кто в этом комитете состоит. Работа, которую они делают, очень непроста, даже мелочи требуют огромных усилий.
С другой стороны, иногда становится очевидно, что разработкой языка занимается комитет, а не один человек или небольшая группа с четким представлением о том, в какую сторону должен развиваться язык. И это действительно заметно. Например, есть три способа определения выравнивания, при этом стандартная библиотека весьма скудна.
В целом, комитет, по-моему, вполне справляется со своей работой. Мне бы, конечно, хотелось, чтобы они делали некоторые вещи иначе. А они, возможно, хотели бы, чтобы я каким-то образом вошел в состав комитета, принял участие в работе. Вот такое у меня отношение к комитету.
Возможно, было бы лучше, если бы был один человек, который отвечает за ключевые решения?
На мой взгляд, комитет — это вполне разумный способ собрать вместе сразу несколько сторон. Откровенно говоря, я не уверен, что Бьерн вообще хотел бы стать тем, кто принимает все решения. Преимущество такого человека в том, что у него есть четкое видение, которое можно имплементировать. В C++ никто не взял на себя эту роль, и я не знаю человека, который мог бы это сделать.
Тут есть небольшая разница по сравнению с множеством других языков: так как C++ работает на огромном количестве платформ, приходится иметь дело с огромным количеством операционных систем, с множеством производителей компиляторов. Не так уж много языков, под которые есть четыре основных компилятора, работающих на разных платформах. Не стоит забывать и про широкий спектр применений. Особенно если начинаешь задумываться о том, какое влияние C++ оказал на встраиваемые системы. Там это действительно важный язык, а взгляды на мир у ребят из этой индустрии во многих случаях достаточно сильно отличаются от привычных.
В целом, было бы неплохо, чтобы, как я уже говорил, у одного человека было четкое видение, которое он мог бы транслировать. Но вряд ли такое возможно для C++.
Есть ли шанс, что в какой-то версии С++ не будет обратной совместимости, как было с некоторыми другими языками?
Думаю, вероятность того, что будет принято решение, ломающее обратную совместимость, практически равна нулю. Мне кажется, одна из самых сильных сторон C++ как раз в отличной обратной совместимости. Написаны миллиарды строк кода, что-то из этого появилось 20–25 лет назад. Решение не сохранять привнесенное другими было бы слишком сложным шагом для сообщества. Так что я не верю, что это когда-нибудь произойдет.
C++ часто критикуют за слишком краткую и абстрактную, почти спартанскую стандартную библиотеку. Нет такого разнообразия, как в некоторых современных языках. Вы считаете такой подход правильным?
Я уверен, все согласятся, что стандартная библиотека слишком мала и требует расширения. По-видимому, так сложилось исторически, из-за того что люди слишком сильно концентрировались на языке. Они считали, что, как только удастся создать подходящий язык, можно будет создавать отличные библиотеки. И мы ждем этих библиотек уже 20 лет. На самом деле такие библиотеки есть, в том числе очень неплохие. Просто их не так много, как хотелось бы. Одна из причин такого сильного отличия C++ от, например, Java или C#, заключается в отсутствии корпоративного спонсора, стоящего за языком. Дело в кроссплатформенности. Все, что у нас есть, — это добровольцы, которые создают библиотеки и выкладывают их в общий доступ. Этим занималось и занимается достаточно много людей, просто все это немного рассеивается.
Комитет по стандартизации сейчас стал гораздо пристальнее к этому приглядываться. Сейчас, как мне представляется, разные люди прилагают согласованные усилия, пытаясь 1) разрабатывать больше библиотек; 2) собрать существующие в разрозненном виде библиотеки (такие как Boost, библиотеки Microsoft, Facebook, Adobe) под единой устраивающей всех лицензией в каком-то одном месте, где все могли бы их найти. На реализацию этих проектов затрачивается все больше усилий. Но нет никаких сомнений, что стандартная библиотека слишком мала и предлагает гораздо меньше функций, чем хотелось бы.
Авторы STL считали, что стандартная библиотека должна быть маленькой и атомарной. Это одна из причин того, что в ней нет некоторых базовых для нашего времени вещей. Что вы думаете об этом?
Я уверен, что стандартная библиотека должна быть больше, что она должна предоставлять базовую функциональность. На дворе 2014 год, а в стандартной библиотеке нет концепции выведения чего-либо на экран. Там нет понятия графики — это просто смешно. Нет понятия интернета, нет понятия URL, URI. По этой причине там по большому счету нет понятия файловой системы. Как мне кажется, в этой роли стандартная библиотека была бы весьма полезна. Кстати, есть еще пара мест, где стандартизация могла бы активно работать на устранение именно этих проблем. Я имею в виду, что есть общая потребность, с которой столкнется множество разработчиков. Просто пройдет еще немало времени, пока все это придет к стандартной форме и всем будет понятно, как оно работает.
Нужен ли С++ единый репозиторий, и появится ли он когда-нибудь?
Это определенно будет удобно. Я не знаю, произойдет ли это когда-нибудь, в какой форме будет реализовано. Но это вполне соответствует идее сближения с людьми, у которых уже есть готовые библиотеки. Потом можно будет сказать: окей, отлично, теперь мы знаем, где лежат все библиотеки. И если мы сможем объединить их под какой-нибудь поддерживаемой всеми лицензией, то сможем складывать в одном месте, где все их увидят, смогут искать по ним и т. п. Так что, на мой взгляд, фундамент для этого уже закладывается, но произойдет ли это? Поживем — увидим.
Есть много людей, которым приходится использовать C++ не смотря на то, что они его не любят. Как вы считаете, по каким принципам должен выбираться язык для больших проектов?
Пожалуй, я сначала отвечу на последний вопрос. Это забавно, ведь десять лет назад все так и говорили: вот пройдет десяток лет и все перейдут на управляемые языки. И они действительно очень важны, но пользуются ими далеко не все. Мне кажется, C++ по-прежнему останется крайне важным языком в продакшене. Просто потому, что основная цель тут — добиться от машины максимальной производительности. Если для вас это важно, то главными конкурентами все так же остаются C и C++. А C++ просто чуть более выразительный язык. Следует оговориться, что я не C-разработчик и никогда им на самом деле не был. Но если бы я им был, то одного упоминания деструкторов хватило бы для того, чтобы я задумался о переходе на C++. Просто ради возможности компилировать и получать деструкторы. Конечно, это лишь малая толика.
Возвращаясь к вашему вопросу о выборе между языками: по мне, это решение должно приниматься менеджерами или старшими инженерами. Нужно принимать во внимание, какие цели вы ставите, какова цель ПО, какие сотрудники есть в вашем распоряжении, какая инфраструктура уже выстроена. И все эти вещи нужно пытаться оптимизировать одновременно. Я не даю никаких советов на этот счет, моя работа — понимать C++ и помогать разработчикам эффективнее его использовать. Рассказывать людям о том, стоит ли им применять C++, в мои задачи не входит.
Плохо ли, что C++ редко используется на мобильных устройствах? Все они по-прежнему работают на управляемых языках: Java — на Android, Objective-C и Swift — на iOS. Не пора ли более активно применять C++ в этой области?
Я не очень пристально слежу за мобильным рынком. Насколько я понимаю, когда появился Android, всем объявили: окей, теперь всем следует писать на Java. А потом сказали: ну, теперь есть бэкдор, благодаря которому можно писать на C++. И то же самое с Objective-C. А потом — снова бэкдор, через который можно пользоваться C++. Так что, мне кажется, возможность использовать нативные языки — это потребность разработчиков, пишущих под мобильные платформы. И если посмотреть с этой точки зрения, количество программ на C++ под мобильные платформы не так уж мало.
Разработчики настаивают на этом. Кроме того, мне кажется, огромная часть мобильного кода, в частности костяк фронтенда, теперь работает в облаках. Если говорить о мобильных сервисах, нужно принимать во внимание и то, что крутится у них на серверах, обслуживает эти мобильные устройства. А позиции C++ определенно очень сильны на серверных фермах — там, где пытаются добиться максимальной прибыли от имеющихся серверов. Так что C++, скорее всего, по-прежнему будет использоваться в серверах, а не в мобильных устройствах. Но серьезной причины, по которой его нельзя было бы использовать и там, нет.
Сегодня вы один из самых знаменитых экспертов по C++. Как вы начали программировать на этом языке?
В некотором смысле выбор был сделан без меня. Я начал программировать очень давно, в 1972 году. Моим первым языком был Basic, в 1972 году он был достаточно распространен. Но в 1985 году я поступил в аспирантуру, чтобы получить PhD по информатике. В обязанности аспиранта входило участие в некоторых курсах в качестве ассистента преподавателя. Естественно, я был ассистентом на курсе разработки ПО. Профессор, который вел этот курс, сказал, что хочет использовать какой-нибудь нормальный язык программирования. И он выбрал C++, а мне через пару лет пришлось его выучить. Так что я не выбирал C++, я просто работал на курсе, где C++ был основным языком. Вот так я и стал на нем программировать.
Но все же вы предпочли связать свою жизнь именно с этим языком.
Честно говоря, это была случайность. Сначала я выучил C++, а потом мне поступило предложение от компании, которой требовался курс по C++ для обучения корпоративных клиентов. Это было интересное предложение. Я был аспирантом, работы было много, а денег — не очень. А они просто сказали: давай ты запишешь все то, что уже знаешь, а мы тебе за это заплатим кучу денег. Я ответил, что это звучит очень привлекательно. Так я и стал заниматься C++. Потом я начал вести занятия, написал свою первую книгу Effective C++, оказавшуюся достаточно популярной. Забавно: когда году в 1991-м жена спросила, долго ли я буду этим заниматься, я ответил, что это же язык программирования, они обычно живут не так уж долго, ну максимум лет пять. Прошло 25 лет, а мы по-прежнему этим занимаемся. Такая вот случайность.
Как вы перешли от статей к книгам? Есть ли разница между созданием статей и созданием книги?
Отличий несколько. Во-первых, по своей природе книга охватывает более обширный материал, во-вторых, нужно иметь более общее видение проблемы, которую вы собираетесь решить. И наконец, нужно больше пространства, в котором вы будете действовать. С другой стороны, если у вас скромный замысел, то и книгу писать не нужно, достаточно статьи. Так что все зависит от того, много ли вы хотите сказать. Кроме того, когда вы пишете статью в журнал, вам нужно лишь ненадолго удержать внимание читателя. Для этого есть разные техники: вы можете провоцировать читателя, вызывать у него желание спорить. Это как если бы вы разговорились с человеком, стоящим рядом с вами в очереди в супермаркете. Это короткий разговор, и тут вам доступен совсем небольшой набор приемов. Книга подразумевает более длительный контакт с читателем. Я бы уподобил это беседе с соседом в самолете. Едва ли вы захотели бы сидеть рядом с тем, кто вам противоречит, спорит с вами и провоцирует на протяжении шестичасового полета. Мне даже пришлось переписать мою вторую книгу — я почувствовал, что она слишком похожа на журнальную статью. Прочитав пятьдесят страниц такого, начинаешь сходить с ума, ненавидеть того, кто все это написал. Так что мне в голову приходят именно две вещи: больший охват и тон рассказа.
Есть ли разница между аудиториями в разных городах? Какие типы аудиторий вам встречались?
Культурные различия между разными странами заметны. Где-то совершенно не боятся спорить с докладчиком, задавать вопросы. Я встречал такое в США, Англии, Германии. Там люди не стесняются сказать: постойте, тут какая-то ошибка. И приходится приводить доводы, обоснования. В других странах люди стараются не создавать проблем, не хотят вас как-то обидеть. К слову, по моему опыту, через это тоже можно прорваться, если пытаться активно вовлекать людей. Особенно легко это удается, если вы проводите с ними больше двух-трех дней — к вам привыкают. На мои выступления слушатели чаще всего приходят по собственному желанию. Когда до них удается достучаться, оказывается, что они очень умны и мысли у них интересные. Так что я не вижу особых различий между разработчиками в том, как они думают, воспринимают материал, задают вопросы. Я очень рад, что, куда бы я ни приехал, общаться мне приходится с очень умными людьми, работающими с действительно интересными задачами. Пытаться успевать за ними — это для меня одновременно вызов и удовольствие.
А вы сами пишете сейчас код?
Нет, не очень много. Я много лет назад решил, что я не разработчик. Я когда-то разрабатывал ПО, написал много кода, когда учился в аспирантуре. Раньше я стыдился этого: рассказывать всем о программировании, хотя сам уже не практикую. Но это уже не моя работа. Мне кажется, что задача разработчиков — производить продукт. Для этого необходимо овладеть инструментами, API и в итоге сделать что-то продуктивное. Они слишком заняты, чтобы отслеживать все, что происходит в мире разработки и C++. А вот моя задача — как раз следить за всем, что происходит, а потом превращать это в статьи, книги, выступления, чтобы разработчики могли воспринять все это в относительно короткий срок. Так что я больше не разработчик, я не уделяю программированию много времени, но я перестал этого стесняться. Я решил, что моя работа тоже вполне имеет смысл.
Источник: http://habrahabr.ru/company/yandex/blog/241601/
Лично я стал почти его фанатом ещё студентом, когда в начале 2000-х читал статьи Скотта, лежащие в основе его книг (сами книги на тот момент в России ещё не были переведены, а на английские с Амазона у меня, как бедного студента, денег не было).
Поэтому, когда он некоторое время назад приехал в Яндекс, чтобы провести тренинг для наших разработчиков, я не мог не воспользоваться этим шансом, чтобы поговорить с ним. Разговор получился о том, каким он видит будущее C++ и программирования вообще, как отличаются разработчики в разных странах и в разных индустриях, и о нём самом.
Назовите два или три самых важных изменения в C++11/14
Если говорить о том, с чем большинство программистов сталкиваются ежедневно, то это auto для объявления переменных, а также, вероятно, лямбда-выражения. Это два самых заметных изменения.
Лично я считаю наиболее фундаментальным улучшением поддержку параллелизма, которой в С++ не было вовсе. Эта фича не так бросается в глаза программистам, разве что создателям компиляторов. Но если говорить о воздействии на людей в общем, то, весьма вероятно, что именно эта фича окажет максимальное влияние. Очевидно, что семантика переноса также крайне важна, но с этой точки зрения параллелизм кажется чуточку более существенным.
А какие два изменения были самыми спорными или вредными?
Пара вещей приходит в голову. Обе основаны на идеях, которые я считаю вполне разумными. Но потом возникает вопрос, а правильно ли они применялись? Первое — это то, что обычно называют универсальной инициализацией. Ее идея заключалась в том, что у нас будет единый синтаксис для инициализации всего подряд. Достигнуть этого не удалась, так как в некоторых случаях была неопределенность, были ситуации, в которых нельзя использовать списковую инициализацию, нужно использовать другую форму. То есть, похоже, были некоторые разногласия относительно того, следовало ли эту фичу имплементировать именно так.
На ум приходят еще async и futures. На самом деле, это прекрасная идея. Просто говоришь, что хочешь запустить что-нибудь асинхронно, и думать об этом уже не нужно. Но в том, что касается спецификаций поведения фьючерсов, выходящих из async, было сделано много интересного. Внутри комитета было много споров, нужно ли это исправлять или чем-то заменить. Как мне кажется, есть все шансы, что начиная с С++17 будут внедряться новые функции, призванные заменить эту.
Комитет по стандартизации достаточно эффективно выполняет свою работу?
Первое, что я хотел бы сказать о Комитете по стандартизации (а я в нем не состою, это нужно обозначить сразу), — перед ними стоит очень непростая задача. Материал требует чрезвычайно глубоких технических знаний. Я испытываю огромное уважение к тем, кто в этом комитете состоит. Работа, которую они делают, очень непроста, даже мелочи требуют огромных усилий.
С другой стороны, иногда становится очевидно, что разработкой языка занимается комитет, а не один человек или небольшая группа с четким представлением о том, в какую сторону должен развиваться язык. И это действительно заметно. Например, есть три способа определения выравнивания, при этом стандартная библиотека весьма скудна.
В целом, комитет, по-моему, вполне справляется со своей работой. Мне бы, конечно, хотелось, чтобы они делали некоторые вещи иначе. А они, возможно, хотели бы, чтобы я каким-то образом вошел в состав комитета, принял участие в работе. Вот такое у меня отношение к комитету.
Возможно, было бы лучше, если бы был один человек, который отвечает за ключевые решения?
На мой взгляд, комитет — это вполне разумный способ собрать вместе сразу несколько сторон. Откровенно говоря, я не уверен, что Бьерн вообще хотел бы стать тем, кто принимает все решения. Преимущество такого человека в том, что у него есть четкое видение, которое можно имплементировать. В C++ никто не взял на себя эту роль, и я не знаю человека, который мог бы это сделать.
Тут есть небольшая разница по сравнению с множеством других языков: так как C++ работает на огромном количестве платформ, приходится иметь дело с огромным количеством операционных систем, с множеством производителей компиляторов. Не так уж много языков, под которые есть четыре основных компилятора, работающих на разных платформах. Не стоит забывать и про широкий спектр применений. Особенно если начинаешь задумываться о том, какое влияние C++ оказал на встраиваемые системы. Там это действительно важный язык, а взгляды на мир у ребят из этой индустрии во многих случаях достаточно сильно отличаются от привычных.
В целом, было бы неплохо, чтобы, как я уже говорил, у одного человека было четкое видение, которое он мог бы транслировать. Но вряд ли такое возможно для C++.
Есть ли шанс, что в какой-то версии С++ не будет обратной совместимости, как было с некоторыми другими языками?
Думаю, вероятность того, что будет принято решение, ломающее обратную совместимость, практически равна нулю. Мне кажется, одна из самых сильных сторон C++ как раз в отличной обратной совместимости. Написаны миллиарды строк кода, что-то из этого появилось 20–25 лет назад. Решение не сохранять привнесенное другими было бы слишком сложным шагом для сообщества. Так что я не верю, что это когда-нибудь произойдет.
C++ часто критикуют за слишком краткую и абстрактную, почти спартанскую стандартную библиотеку. Нет такого разнообразия, как в некоторых современных языках. Вы считаете такой подход правильным?
Я уверен, все согласятся, что стандартная библиотека слишком мала и требует расширения. По-видимому, так сложилось исторически, из-за того что люди слишком сильно концентрировались на языке. Они считали, что, как только удастся создать подходящий язык, можно будет создавать отличные библиотеки. И мы ждем этих библиотек уже 20 лет. На самом деле такие библиотеки есть, в том числе очень неплохие. Просто их не так много, как хотелось бы. Одна из причин такого сильного отличия C++ от, например, Java или C#, заключается в отсутствии корпоративного спонсора, стоящего за языком. Дело в кроссплатформенности. Все, что у нас есть, — это добровольцы, которые создают библиотеки и выкладывают их в общий доступ. Этим занималось и занимается достаточно много людей, просто все это немного рассеивается.
Комитет по стандартизации сейчас стал гораздо пристальнее к этому приглядываться. Сейчас, как мне представляется, разные люди прилагают согласованные усилия, пытаясь 1) разрабатывать больше библиотек; 2) собрать существующие в разрозненном виде библиотеки (такие как Boost, библиотеки Microsoft, Facebook, Adobe) под единой устраивающей всех лицензией в каком-то одном месте, где все могли бы их найти. На реализацию этих проектов затрачивается все больше усилий. Но нет никаких сомнений, что стандартная библиотека слишком мала и предлагает гораздо меньше функций, чем хотелось бы.
Авторы STL считали, что стандартная библиотека должна быть маленькой и атомарной. Это одна из причин того, что в ней нет некоторых базовых для нашего времени вещей. Что вы думаете об этом?
Я уверен, что стандартная библиотека должна быть больше, что она должна предоставлять базовую функциональность. На дворе 2014 год, а в стандартной библиотеке нет концепции выведения чего-либо на экран. Там нет понятия графики — это просто смешно. Нет понятия интернета, нет понятия URL, URI. По этой причине там по большому счету нет понятия файловой системы. Как мне кажется, в этой роли стандартная библиотека была бы весьма полезна. Кстати, есть еще пара мест, где стандартизация могла бы активно работать на устранение именно этих проблем. Я имею в виду, что есть общая потребность, с которой столкнется множество разработчиков. Просто пройдет еще немало времени, пока все это придет к стандартной форме и всем будет понятно, как оно работает.
Нужен ли С++ единый репозиторий, и появится ли он когда-нибудь?
Это определенно будет удобно. Я не знаю, произойдет ли это когда-нибудь, в какой форме будет реализовано. Но это вполне соответствует идее сближения с людьми, у которых уже есть готовые библиотеки. Потом можно будет сказать: окей, отлично, теперь мы знаем, где лежат все библиотеки. И если мы сможем объединить их под какой-нибудь поддерживаемой всеми лицензией, то сможем складывать в одном месте, где все их увидят, смогут искать по ним и т. п. Так что, на мой взгляд, фундамент для этого уже закладывается, но произойдет ли это? Поживем — увидим.
Есть много людей, которым приходится использовать C++ не смотря на то, что они его не любят. Как вы считаете, по каким принципам должен выбираться язык для больших проектов?
Пожалуй, я сначала отвечу на последний вопрос. Это забавно, ведь десять лет назад все так и говорили: вот пройдет десяток лет и все перейдут на управляемые языки. И они действительно очень важны, но пользуются ими далеко не все. Мне кажется, C++ по-прежнему останется крайне важным языком в продакшене. Просто потому, что основная цель тут — добиться от машины максимальной производительности. Если для вас это важно, то главными конкурентами все так же остаются C и C++. А C++ просто чуть более выразительный язык. Следует оговориться, что я не C-разработчик и никогда им на самом деле не был. Но если бы я им был, то одного упоминания деструкторов хватило бы для того, чтобы я задумался о переходе на C++. Просто ради возможности компилировать и получать деструкторы. Конечно, это лишь малая толика.
Возвращаясь к вашему вопросу о выборе между языками: по мне, это решение должно приниматься менеджерами или старшими инженерами. Нужно принимать во внимание, какие цели вы ставите, какова цель ПО, какие сотрудники есть в вашем распоряжении, какая инфраструктура уже выстроена. И все эти вещи нужно пытаться оптимизировать одновременно. Я не даю никаких советов на этот счет, моя работа — понимать C++ и помогать разработчикам эффективнее его использовать. Рассказывать людям о том, стоит ли им применять C++, в мои задачи не входит.
Плохо ли, что C++ редко используется на мобильных устройствах? Все они по-прежнему работают на управляемых языках: Java — на Android, Objective-C и Swift — на iOS. Не пора ли более активно применять C++ в этой области?
Я не очень пристально слежу за мобильным рынком. Насколько я понимаю, когда появился Android, всем объявили: окей, теперь всем следует писать на Java. А потом сказали: ну, теперь есть бэкдор, благодаря которому можно писать на C++. И то же самое с Objective-C. А потом — снова бэкдор, через который можно пользоваться C++. Так что, мне кажется, возможность использовать нативные языки — это потребность разработчиков, пишущих под мобильные платформы. И если посмотреть с этой точки зрения, количество программ на C++ под мобильные платформы не так уж мало.
Разработчики настаивают на этом. Кроме того, мне кажется, огромная часть мобильного кода, в частности костяк фронтенда, теперь работает в облаках. Если говорить о мобильных сервисах, нужно принимать во внимание и то, что крутится у них на серверах, обслуживает эти мобильные устройства. А позиции C++ определенно очень сильны на серверных фермах — там, где пытаются добиться максимальной прибыли от имеющихся серверов. Так что C++, скорее всего, по-прежнему будет использоваться в серверах, а не в мобильных устройствах. Но серьезной причины, по которой его нельзя было бы использовать и там, нет.
Сегодня вы один из самых знаменитых экспертов по C++. Как вы начали программировать на этом языке?
В некотором смысле выбор был сделан без меня. Я начал программировать очень давно, в 1972 году. Моим первым языком был Basic, в 1972 году он был достаточно распространен. Но в 1985 году я поступил в аспирантуру, чтобы получить PhD по информатике. В обязанности аспиранта входило участие в некоторых курсах в качестве ассистента преподавателя. Естественно, я был ассистентом на курсе разработки ПО. Профессор, который вел этот курс, сказал, что хочет использовать какой-нибудь нормальный язык программирования. И он выбрал C++, а мне через пару лет пришлось его выучить. Так что я не выбирал C++, я просто работал на курсе, где C++ был основным языком. Вот так я и стал на нем программировать.
Но все же вы предпочли связать свою жизнь именно с этим языком.
Честно говоря, это была случайность. Сначала я выучил C++, а потом мне поступило предложение от компании, которой требовался курс по C++ для обучения корпоративных клиентов. Это было интересное предложение. Я был аспирантом, работы было много, а денег — не очень. А они просто сказали: давай ты запишешь все то, что уже знаешь, а мы тебе за это заплатим кучу денег. Я ответил, что это звучит очень привлекательно. Так я и стал заниматься C++. Потом я начал вести занятия, написал свою первую книгу Effective C++, оказавшуюся достаточно популярной. Забавно: когда году в 1991-м жена спросила, долго ли я буду этим заниматься, я ответил, что это же язык программирования, они обычно живут не так уж долго, ну максимум лет пять. Прошло 25 лет, а мы по-прежнему этим занимаемся. Такая вот случайность.
Как вы перешли от статей к книгам? Есть ли разница между созданием статей и созданием книги?
Отличий несколько. Во-первых, по своей природе книга охватывает более обширный материал, во-вторых, нужно иметь более общее видение проблемы, которую вы собираетесь решить. И наконец, нужно больше пространства, в котором вы будете действовать. С другой стороны, если у вас скромный замысел, то и книгу писать не нужно, достаточно статьи. Так что все зависит от того, много ли вы хотите сказать. Кроме того, когда вы пишете статью в журнал, вам нужно лишь ненадолго удержать внимание читателя. Для этого есть разные техники: вы можете провоцировать читателя, вызывать у него желание спорить. Это как если бы вы разговорились с человеком, стоящим рядом с вами в очереди в супермаркете. Это короткий разговор, и тут вам доступен совсем небольшой набор приемов. Книга подразумевает более длительный контакт с читателем. Я бы уподобил это беседе с соседом в самолете. Едва ли вы захотели бы сидеть рядом с тем, кто вам противоречит, спорит с вами и провоцирует на протяжении шестичасового полета. Мне даже пришлось переписать мою вторую книгу — я почувствовал, что она слишком похожа на журнальную статью. Прочитав пятьдесят страниц такого, начинаешь сходить с ума, ненавидеть того, кто все это написал. Так что мне в голову приходят именно две вещи: больший охват и тон рассказа.
Есть ли разница между аудиториями в разных городах? Какие типы аудиторий вам встречались?
Культурные различия между разными странами заметны. Где-то совершенно не боятся спорить с докладчиком, задавать вопросы. Я встречал такое в США, Англии, Германии. Там люди не стесняются сказать: постойте, тут какая-то ошибка. И приходится приводить доводы, обоснования. В других странах люди стараются не создавать проблем, не хотят вас как-то обидеть. К слову, по моему опыту, через это тоже можно прорваться, если пытаться активно вовлекать людей. Особенно легко это удается, если вы проводите с ними больше двух-трех дней — к вам привыкают. На мои выступления слушатели чаще всего приходят по собственному желанию. Когда до них удается достучаться, оказывается, что они очень умны и мысли у них интересные. Так что я не вижу особых различий между разработчиками в том, как они думают, воспринимают материал, задают вопросы. Я очень рад, что, куда бы я ни приехал, общаться мне приходится с очень умными людьми, работающими с действительно интересными задачами. Пытаться успевать за ними — это для меня одновременно вызов и удовольствие.
А вы сами пишете сейчас код?
Нет, не очень много. Я много лет назад решил, что я не разработчик. Я когда-то разрабатывал ПО, написал много кода, когда учился в аспирантуре. Раньше я стыдился этого: рассказывать всем о программировании, хотя сам уже не практикую. Но это уже не моя работа. Мне кажется, что задача разработчиков — производить продукт. Для этого необходимо овладеть инструментами, API и в итоге сделать что-то продуктивное. Они слишком заняты, чтобы отслеживать все, что происходит в мире разработки и C++. А вот моя задача — как раз следить за всем, что происходит, а потом превращать это в статьи, книги, выступления, чтобы разработчики могли воспринять все это в относительно короткий срок. Так что я больше не разработчик, я не уделяю программированию много времени, но я перестал этого стесняться. Я решил, что моя работа тоже вполне имеет смысл.
Источник: http://habrahabr.ru/company/yandex/blog/241601/
