56 лучших цитат и высказываний Бьярна Страуструпа

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

Лично я с нетерпением жду лучших инструментов для анализа исходного кода C++.

С ростом важности стандартов для объектов системного уровня, таких как COM и CORBA, особенно важно, чтобы привязки C++ к ним были чистыми, хорошо документированными и простыми в использовании.

Ясно, что я отвергаю мнение о том, что есть один способ, подходящий для всех и для каждой проблемы.

Стандартная библиотека избавляет программистов от необходимости изобретать велосипед.

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

В конце концов, C++ также не идеально подходит для целей дизайна Java.

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

Однако, когда Java продвигается как единственный язык программирования, его недостатки и ограничения становятся серьезными.

Таким образом, стандартная библиотека будет служить и инструментом, и учителем.

Я нахожу языки, которые поддерживают только одно ограничение парадигмы программирования.

Конечно, не каждая хорошая программа является объектно-ориентированной, и не каждая объектно-ориентированная программа хороша.

Я бы поощрял непатентованные стандарты для инструментов и библиотек.

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

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

Эта эволюция может поставить под угрозу заявление Java о том, что она проще, чем C++, но я предполагаю, что эти усилия сделают Java лучшим языком, чем он есть сегодня.

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

Первый закон информатики: любая проблема решается еще одним косвенным путем.

Никто не должен называть себя профессионалом, если он знает только один язык.

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

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

Предложение Тома [Каргила] с дополнительной идеей: Сторонники новых возможностей [C++] должны быть обязаны пожертвовать почку. Это, как указал Джим [Уолдо], заставило бы людей хорошенько подумать, прежде чем предлагать, и даже люди без всякого здравого смысла предложили бы самое большее два расширения.

Некоторое программное обеспечение на самом деле довольно хорошее по любым стандартам. Вспомните марсоходы, Google и проект «Геном человека». Вот это качественное программное обеспечение!

Слишком много менеджеров и руководителей пытаются свести программирование к низкоуровневой конвейерной деятельности. Это неэффективно, расточительно, затратно в долгосрочной перспективе и негуманно по отношению к программистам.

Java не зависит от платформы; это платформа

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

C позволяет легко выстрелить себе в ногу; С++ усложняет задачу, но когда вы это сделаете, вам снесет всю ногу.

Доказательство по аналогии — мошенничество.

Самая фундаментальная проблема в разработке программного обеспечения — сложность. Есть только один основной способ справиться со сложностью: разделяй и властвуй.

Любой, кто приходит к вам и говорит, что у него идеальный язык, либо наивен, либо продажник.

Я нахожу языки, которые поддерживают только одну парадигму программирования, ограничивающую

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

Мне нравится проводить исследования, которые оказывают влияние. Если бы я пошел в компанию, чтобы заработать то, что они называют «настоящими деньгами», я бы просто попытался заставить систему работать как можно быстрее, чтобы уложиться в сроки продукта и услуги.

Как тестировать?» — это вопрос, на который нельзя ответить в общем. «Когда тестировать?», однако, имеет общий ответ: как можно раньше и как можно чаще.

Если вы думаете, что это просто, то вы неправильно поняли проблему.

В организации, которая относится к своим программистам как к идиотам, вскоре появятся программисты, которые хотят и могут вести себя только как идиоты.

Когда все сделано хорошо, программное обеспечение невидимо.

Легко добиться прощения за свою неправоту; быть правым — это то, что доставляет вам настоящие неприятности.

[Корпоративное программирование] часто доводится до такой степени, что человек полностью погружается в корпоративную «культуру», не имея возможности проявить уникальные таланты и навыки. Корпоративная практика может быть прямо враждебной по отношению к людям с исключительными навыками и инициативой в технических вопросах. Считаю такое управление техническими людьми жестоким и расточительным.

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

Я предполагаю, что достаточно квалифицированный человек сможет сделать все, что явно не запрещено аппаратным обеспечением.

Дизайн и программирование — это человеческая деятельность; забудь об этом и все пропало.

Я твердо убежден, что все успешные языки вырастают, а не просто разрабатываются исходя из первых принципов.

Любое многословное и утомительное решение чревато ошибками, потому что программистам становится скучно.

На языках, признанных «плохими», было написано больше хорошего кода, чем на языках, объявленных «замечательными», — и намного больше.

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

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

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

C++ — мой любимый язык со сборщиком мусора, потому что он генерирует очень мало мусора.

Непроверенная программа не работает.

Деструкторы виртуальных базовых классов выполняются в порядке, обратном их появлению, при обходе в глубину слева направо ориентированного ациклического графа базовых классов.

Связь между языком, на котором мы думаем/программируем, и проблемами и решениями, которые мы можем вообразить, очень тесна. По этой причине ограничение возможностей языка с целью устранения ошибок программиста в лучшем случае опасно.

«Устаревший код» часто отличается от предлагаемой альтернативы тем, что действительно работает и масштабируется.

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

Большинство программистов через десять лет будем мы, и мы не станем намного умнее.

Всегда думайте о том, как следует использовать фрагмент кода: хорошие интерфейсы — это основа хорошего кода. Вы можете спрятать весь умный и грязный код за хорошим интерфейсом, если вам действительно нужен такой код.