Интервью Скотта Мейерса о настоящем и будущем C++
Скотт Мейерс — один из самых известных и признанных экспертов по C++, автор серии книг «Эффективное использование C++», которые читал почти каждый профессиональный разработчик на C++ и которые оказали заметное влияние на всю экосистему и качество использование языка.Лично я стал почти его фанатом ещё студентом, когда в начале 2000-х читал статьи Скотта, лежащие в основе его книг (сами книги на тот момент в России ещё не были переведены, а на английские с Амазона у меня, как бедного студента, денег не было).
Поэтому, когда он некоторое время назад приехал в Яндекс, чтобы провести тренинг для наших разработчиков, я не мог не воспользоваться этим шансом, чтобы поговорить с ним. Разговор получился о том, каким он видит будущее C++ и программирования вообще, как отличаются разработчики в разных странах и в разных индустриях, и о нём самом.
[embedded content]
Оригинал для тех, кто предпочитает читать по-английски If you had to name one or two changes in the C++11/14 Standard that are the most important, which ones would you choose? I think that for most programmers, on a daily basis, it«s going to be auto for declaring variables and also, probably, lambda expressions. Those are the things that are most visible to people.
I think that, actually, more fundamental improvement is the support for concurrency, which didn«t exist at all in C++98. And that particular new feature is not terribly visible to programmers in a lot of ways, because it mostly affected compiler writers, but, in terms of the most widespread impact on people, it«s probably going to be the one that makes the most difference. Move semantics is obviously very important as well but I think the concurrency is a little more fundamental from that perspective.
Even though concurrency was implemented in libraries before?
Concurrency was implemented in libraries before, the problem was that the libraries didn«t have a foundation in the compiler that they could build on so there was never any guarantee that things were actually going to work. For example, there were optimisations compilers could perform that could have broken concurrent programs. And so now compiler writers know what they can do and what they cannot do and what they have to do. That makes it possible to build libraries that will reliably work.
The same question, but about the most controversial changes. Is there something that can have a negative effect?
A couple of things come to mind. Both of them based on ideas that I think are reasonable ideas. Then the question becomes — were they executed properly? One of them is what«s usually referred to as uniform initialisation. And the idea was that we would have a single syntax for initialising everything. And that particular promise has not been achieved because there«re some ambiguities in certain cases and there are situations where you can«t use brace initialisation when you have to use a different form. So I think there has been some controversy there about whether that should have been implemented in some particular way than it was.
And the other thing that comes to mind is sync and futures, which is a great idea. It simply says, «I wan to run this thing asynchronously», and you don«t have to think about it at all. But then they did some interesting things regarding specification of the behaviour of futures that come from async and there«s been a lot of controversy in the committee about whether they should change that or whether they should replace it. And it«s my impression that there is a pretty reasonable chance that starting in C++17 there will be some new features which will probably replace that.
So you«ve mentioned C++ Standards Committee. What do you think about it? Does it do a good job? Or is it too slow or conservative in some respect?
The first thing I am going to say about Standardisation Committee — and I«m not on the Standardisation Committee, I should clarify this — is that they have a very difficult job. The material is extremely technically demanding. So I have a tremendous amount of respect for the people on the Committee and for the work that they do, because it is not easy work. And even the simplest things require an enormous amount of effort.
Having said that, I think that it shows sometimes that this is definitely a committee that is designing a language. As opposed to a single person or a small group of people with a clear vision for where the language wants to go. And that shows up — for example, we have three different ways for specifying alignment, but we have a relatively impoverished Standard Library.
So I think that committee overall does a reasonable job. I wish that they did things in some ways a little bit differently, and I think that probably they wish in some ways that I was maybe a member of the committee trying to get those things done. So that«s my feeling about the Committee.
Do you think that if there were one person — I don«t know — Bjarne — or someone esle who would be making all of the decisions — like W3C — it would be better, or is the Committee a good compromise?
I think that Committee is a reasonable way to get a lot of parties together. To be honest, I don«t think that Bjarne has any kind of desire to be the person who makes all of the decisions. The advantage of a person who makes all of the decisions is that they can have a clear vision and then can really implement that clear vision. And there«s no one who plays that role in C++ and I don«t know of anybody who could play that role in C++.
It«s a little bit different from lots of other languages because it«s very crossplatform — so you«re dealing with lots and lots of different operating systems. Lots of compiler vendors. There is not a lot of other languages for which there would be, say, four major compilers that run on different platforms. And also, just a range of applications. Especially when you start thinking about the impact of C++ on embedded systems where it is quite an important programming language — they have really different views of the world in some cases.
So it would be nice if there were, like I said, a sort of a clear vision via a single person, but I don«t think that«s going to be happening in C++.
What would you most likely advise to be changed in the language if you had a chance to go back to 95? Were there any wrong decisions in the C++ history? What would you change in the language if you could?
I don«t have specific things I would change. One of the things I find problematic about the language is that it«s not terribly consistent and it has lots of special cases. This is something that is particularly important to me, because my job is to explain the language to other people. And it makes my job more complicated.
But I also think that if the language were more consistent and did not have quite as many special cases, then it would be easier for programmers to get their work done, because they would not be stumbling into problems from time to time.
Having said that, the language does a really good job of acting as a tool for professional developers to solve really difficult problems. So we have to view it as a very significant success. Clearly, the Committee has done a pretty good job of getting things right for a lot of programmers.
Is there any chance that some day a version of C++ with little or no backward compatibility will be released? Something similar to Python 3 or Perl 6, for example.
I think that the chance of any decision that would break backward compatibility is virtually zero. Because I think that one of the great strengths of C++ is that it does have tremendous backward compatibility. So there are billions of lines of code, some of it was written 20 or 25 years ago. And it would be a really significant departure for the community to decide that they don«t want to preserve peoples» investment. So I don«t ever expect that to happen.
C++ is sometimes criticised for being a very discrete and abstract, almost Spartan, Standard Library. It doesn«t have a variety that other modern languages have. Do you think this is the right approach?
I think everybody agrees that the Standard Library is too small and it needs to be a lot larger. I think that historically we got to where we are because people focused on the language and they said «once you have a suitable language then you can build great libraries». And we«ve been waiting 20 years for people to build great libraries and the thing is they have build great libraries — there are some really nice libraries out there.
There aren«t as many as we would like. One of the reasons for that is, unlike, for example, Java or C#, basically, there«s no corporate sponsor behind this language and it«s a crossplatform language. So you basically are looking for volunteers to put together libraries and then make them available for everybody else. And a fair number of people have done that but they«re just sort of spread around.
The Standardisation Committee now has started to taking a much more serious look at this, and so I think that there is a consorted effort to try to 1) get more libraries developed and 2) take the existing libraries in existing places like Boost, and at Microsoft, and at Facebook, and at Adobe and lots of other places and bring them together under a license that everybody can live with and put them in place where everybody can find them. There is a definite effort being expended to make that happen. But there«s no question that the Standard Libraries are much smaller and have fewer features than we would prefer.
Actually, two years ago I talked to Stepanov, the creator of the original standard library. He thinks that it should be small and atomic, and everything else should be in a different library, not in the language itself. Do you think that this should be the case?
I believe that the standard library should be larger. I think it should offer some really basic functionality. For example, it«s 2014. There is no concept in a standard library of putting anything on a screen anywhere. There is no concept of graphics. That«s silly. There is no concept of the Internet. There is no concept of the URL. There is no concept of the URI. For that matter, there is no concept really of a file system. This role, in my mind, obvious places a standard library would really be helpful. And, incidentally, there are also places where standardization can be actively working to address those particular issues. But I«m inclined to say that if there is a common need that many developers are going to have, there is just a lot of mileage to be gained by putting it in a standard form, so everybody knows how it works.
Many people are asking for some standard repository like in some other languages. What do you think about this? Is there a need for it and how soon the C++ community can make it possible?
It would certainly be convenient. Whether it«s going to ultimately take place and, if so, what form it«s going to take, I don«t know. But that would be consistent with this idea of going out to people that already have got the existing libraries. And then say, ok, great, now we know where all the libraries are, if we can unify them under some kind of a common acceptable license, now we can start putting them in one location, where everybody can look them up and search for them and things like that. So I think that the foundation is being laid for to make that possible, whether it would take place remains to be seen.
How far do you think this future is from now? A few years?
I«d say probably… I think, it«s going to be in a better situation probably next 2–3 years. But we, sort of, have to see. The thing is, there are a large number of libraries that address lots of different areas. This is really part of Standardization Committee. So it«s a matter now of finding a way to unify them, so people could go to a single location and look for them. If you look at two or three years ago, there was no single website where people could go for information about standard C++, and now there is, largely thanks to the work of the Committee. This is the place to go, so this is project he«s been working on. So I«m optimistic.
How do you think the decision should be made about what language to use? IDK, many people, Yandex may think that C++ is terrible, actually, but they«re still using it, and it«s the main language used in our development. And I«ve heard many people from Google saying the same thing. And still they are using C++. So how can we choose between, IDK, C++ and Java. Do you think that C++ still has a great future or will everybody be using managed languages in ten years?
Well, let me answer the last question first actually. It«s interesting, because ten years ago everybody was saying, in ten years everyone will be using managed languages. And managed languages are very important, but certainly it«s not the case that everybody is using them. So I don«t think that in ten years everyone will be using managed languages. I think that C++ is going to remain an extremely important language for production use. Simply because if your goal is to get the maximum of performance out of the machine. If that is what is most important to you. I think that even these days the primary competitors are C and C++. Those are pretty much your choices. And C++ is just a much more expressive language. I have to say that I«m not a C programmer. I’ve never really been a C programmer. But I think that just a simple notion of destructors is so unbelievably powerful, that as a C programmer I would consider moving to C++ just so I could compile and get destructors. And, obviously, there is a lot more? to it than that. In terms of your original question about choosing between various languages, you know, fundamentally, to me that«s a management or a higher level engineering decision. You have to take into account, what do we want to accomplish, what«s the goal of the software, who are the people that we have available, what existing infrastructure do we have. And you«re trying to optimize for a lot of things simultaneously. I don«t offer advice on that question, my job is to understand C++ and help engineers use it better. My job is not to try to tell people whether they should use it or should not use it.
Do you think that it«s bad for C++ that it«s rarely used on mobile devices? All these new things use managed languages. Java for Android, Objective C and Swift for iOS. What do you think about that and couldn«t C++ be used more efficiently for these applications.
I don«t follow mobile market that closely. It«s my understanding that the mobile platforms originally are set, OK, everything will be programmed only in Java. And they said, well, now we«re going to have a back door to let you program in C++. And then they said only Objective C. And then, OK, there is a backdoor, you can use C++. So I think there is a demand, on the part of the people programming those platforms, to have native languages. And, so from that perspective, I think actually the percentage of programs running C++ on mobile platforms has actually increased. Because developers are insisting on that. The other thing, though, is, I think, an awful lot of mobile stuff, essentially axis of front-end, took computation place in the cloud. And I think, if you«re thinking mobile, you must take into account what«s running on the servers which are servicing these mobile devices. And C++ is certainly very strong in server farms where you are trying to get the maximum possible dollars out of the servers that you have available. So, I think, it«s probably going to remain stronger in servers than in the mobile devices. But there certainly no reason it can«t be running on mobile devices.
Назовите два или три самых важных изменения в C++11/14
Если говорить о том, с чем большинство программистов сталкиваются ежедневно, то это автоматическое объявление переменных, а также, вероятно, лямбда-выражения. Это два самых заметных изменения.
Лично я считаю наиболее фундаментальным улучшением поддержку параллелизма, которой в С++ не было вовсе. Эта фича не так бросается в глаза программистам, разве что создателям компиляторов. Но если говорить о воздействии на людей в общем, то, весьма вероятно, что именно эта фича окажет максимальное влияние. Очевидно, что семантика переноса также крайне важна, но с этой точки зрения параллелизм кажется чуточку более существенным.
А какие два изменения были самыми спорными или вредными?
Пара вещей приходит в голову. Обе основаны на идеях, которые я считаю вполне разумными. Но потом возникает вопрос, а правильно ли они применялись? Первое — это то, что обычно называют универсальной инициализацией. Ее идея заключалась в том, что у нас будет единый синтаксис для инициализации всего подряд. Достигнуть этого не удалась, так как в некоторых случаях была неопределенность, были ситуации, в которых нельзя использовать списковую инициализацию, нужно использовать другую форму. То есть, похоже, были некоторые разногласия относительно того, следовало ли эту фичу имплементировать именно так.
На ум приходят еще 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++. А вот моя задача — как раз следить за всем, что происходит, а потом превращать это в статьи, книги, выступления, чтобы разработчики могли воспринять все это в относительно короткий срок. Так что я больше не разработчик, я не уделяю программированию много времени, но я перестал этого стесняться. Я решил, что моя работа тоже вполне имеет смысл.
