Главная » Хабрахабр » [Перевод] Бьёрн Страуструп: Проблема с программированием

[Перевод] Бьёрн Страуструп: Проблема с программированием

image

Статья 2006 года.

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

В 1980-х и 90-х годах Бьёрн Страуструп разработал и внедрил язык программирования C ++, который популяризировал объектно-ориентированное программирование и повлиял на многие другие языки программирования, включая Java.

Многие из систем и приложений эры ПК и интернета были написаны на C ++. C ++ остается архетипическим «высокоуровневым» компьютерным языком (то есть языком, который сохраняет особенности естественного, человеческого языка), и он по-прежнему используется миллионами программистов. Несмотря на это, язык остается спорным, во многом потому что его, как известно, трудно изучать и использовать, а также потому, что дизайн Страуструпа позволяет разработчикам допускать серьезные ошибки программирования в интересах сохранения их свободы.

Страуструп, на протяжении многих лет работающий в AT & T Bell Labs, теперь является профессором компьютерных наук на факультете инженерии в Техасском университете A&M, недалеко от Хьюстона.

Технологический обзор: почему большая часть программного обеспечения настолько плоха?

Подумайте о Mars Rovers, Google и проекте “Геном человека”. Бьёрн Страуструп: Некоторые программы на самом деле довольно хороши по любым стандартам. Пятнадцать лет назад большинство людей, и в частности большинство экспертов, сказали бы, что каждый из этих примеров невозможен. Это качественное программное обеспечение! Структура ужасающая, и программисты явно не задумывались над правильностью, алгоритмами, структурами данных или ремонтопригодностью. Наша технологическая цивилизация зависит от программного обеспечения, поэтому, если бы программное обеспечение было бы в действительности таким же плохим, как и его наихудшая репутация, большинство из нас уже были бы мертвы.
С другой стороны, просмотр «типичных» фрагментов кода может заставить меня плакать. Большинство людей на самом деле не читают код; они просто видят, что Internet Explorer «тормозит».

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

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

Технологический обзор: Как мы можем исправить беспорядок, в котором мы находимся?

Вознаграждайте правильные, надежные и безопасные системы. Бьёрн Страуструп: Теоретически ответ прост: получше обучите наших разработчиков программного обеспечения, используйте более подходящие методы проектирования и используйте гибкий дизайн, мысля в долгосрочной перспективе. Наказывайте за неряшливость.

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

С другой стороны, продолжать действовать наобум дорого, опасно и удручающе. Мы не можем просто остановить мир на десятилетие, пока мы перепрограммируем все, начиная от наших кофе-машин и заканчивая нашими финансовыми системами. Они должны прийти на широкий фронт; лишь одного изменения недостаточно. Необходимы значительные улучшения, и они могут появиться только постепенно.

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

Bell Labs захотели использовать язык, который несколько действительно умных людей будут использовать для написания кода, работающего на таких компьютерах, как Electronic Switching Systems (ESS), которые были не очень быстрыми. Технологический обзор: Идея, лежащая в основе C ++, заключалась в том, что программисты будут работать более активно в обмен на более эффективный код. Означает ли это, что это сводит на нет всю суть C ++? Сегодня очень много быстрых компьютеров и много разработчиков программного обеспечения.

Bell Labs была домом для невероятного спектра интересных проектов, охватывающих все масштабы и использующих практически все виды компьютеров и операционных систем. Бьёрн Страуструп: C ++ не был разработан специально для больших коммутационных аппаратов, он был разработан для огромного спектра приложений. Но да, среднестатистический программист Bell Labs был значительно более способным в сравнении с мнением большинства людей о «среднестатистическом программисте», а надежность и производительность (в этом порядке) считались значительно более важными, чем в большинстве других мест.

Разработчики программного обеспечения нейтрализуют поразительную производительность современного компьютерного оборудования, добавляя избыточные (программные) абстракции слой за слоем. Производительность по-прежнему остается проблемой во многих приложениях, которые меня интересуют: быстрота реагирования интерфейсов, время запуска и закрытия приложений. Похоже, что мы столкнулись с ограничениями линейного ускорения для аппаратного обеспечения, но во многих случаях мы могли выиграть пару порядков величин у программного обеспечения.

Тем не менее, решение заключается не в том, чтобы упростить до абсурда языки программирования, а в том, чтобы использовать различные языки программирования и обучать больше экспертов. Тем не менее, C ++ действительно стал слишком «дружелюбным по отношению к экспертам» в то время как уровень эффективного формального образования среднестатистического разработчика программного обеспечения снизился. Этим экспертам нужно использовать какие-то языки, а C ++ — один из этих языков.

Технологический обзор: В ретроспективе, при проектировании C ++, не было ли ваше решение обменять эффективность программного обеспечения, его безопасность и надежность на производительность кода во время выполнения, фундаментальной ошибкой?

Я хочу элегантный и эффективный код. Бьёрн Страуструп: Ну, я не думаю, что я сделал такой обмен. Эти дихотомии (между эффективностью и правильностью, эффективностью и временем программиста, эффективностью по сравнению с высоким уровнем и т. Иногда я это понимаю. д.) являются фиктивными.

Затем я хотел, чтобы C ++ был хорошим языком для разработки инструментов. То, что я действительно делал, — это разработал C ++, как прежде всего язык системного программирования: я хотел иметь возможность писать драйверы устройств, встроенные системы и другой код, который должен был использовать непосредственно. Мое мнение заключалось в том, что для создания более высокого уровня, для создания полных приложений вам сначала нужно было покупать, строить или заимствовать библиотеки, предоставляющие соответствующие абстракции. Это требовало гибкости и производительности, а также способности выразить элегантные интерфейсы. Часто, когда у людей возникают проблемы с C ++, реальная проблема заключается в том, что у них нет соответствующих библиотек или они не могут найти доступные библиотеки.

Другие языки пытались более непосредственно поддерживать приложения высокого уровня.

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

Почему этот язык настолько успешен? Технологический обзор: Как вы объясняете тот факт, что C ++ широко критикуется и многими программистами, но в то же время очень широко используется?

Бьёрн Страуструп: Ответ прост: есть только два вида языков: те, на которые жалуются все, и те, которые никто не использует.

Цель языка программирования — помочь создать хорошие системы, где «хорошее» можно определить разными способами. Есть более полезные системы, разработанные на языках, которые считаются ужасными, чем на языках, которые хвалили за то, что они красивы — и многое другое. Эстетика имеет значение, но в первую очередь язык должен быть полезен; он должен позволить программистам этого мира выражать реалистичные идеи лаконично и недорого. Мое краткое определение: что-то правильное, поддерживаемое и достаточно быстрое.

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

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

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

Это шутка? Технологический обзор: В “Дизайне и эволюции C ++” вы утверждаете, что Кьеркегор оказал влияние на вашу концепцию языка.

Многие размышления о разработке программного обеспечения сосредоточены на группе, команде, компании. Бьёрн Страуструп: Возможно немного претенциозное заявление, но не шутка. Корпоративная практика может быть враждебной по отношению к людям с исключительными навыками и инициативой по техническим вопросам. Это часто делается до такой степени, что человек полностью погружен в корпоративную «культуру» без выхода для уникальных талантов и навыков. Кьеркегор был сильным сторонником индивидуума против «толпы» и серьезно поднял вопрос важности эстетики и этического поведения. Я считаю такое управление технарями жестоким и расточительным. Тем не менее, я не особенно люблю религиозную философию Кьеркегора. Я не мог указать на конкретную особенность языка и сказать: «Видите, есть влияние философа девятнадцатого века», но он является одним из корней моего нежелания устранять «уровень экспертного уровня», отменять «злоупотребление» и ограничивать возможности поддержки только тех приложений, которые, как я знаю, будут полезными.

Технологический обзор: О чем вы жалеете больше всего?

Ну, конечно, я мечтаю о том, что я мог бы сделать по-другому и лучше, но серьезно, кто я такой, чтобы переоткрыть, скажем, винтаж Бьёрна 1984 года? Бьёрн Страуструп: Ни о чем не жалею! C ++ используется для создания многих систем, которые улучшают нашу жизнь, и это оказало значительное положительное влияние на более поздние языки и системы. Возможно, он был менее опытным, чем я, но он был не менее умным, вероятно, умнее, и он лучше понимал слова 1984 года, чем я. Это то, чем можно гордиться.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Тесное знакомство с электромеханическим сортировщиком перфокарт (экскурс в начало XX века)

VolKarev сегодня в 17:56 Старое железо, История IT Однако электромеханика сортировщика намного более элегантна и проста: весь его интеллект держится на одном датчике и на одном электромагните. Поняв, как работать с электромеханическим сортировщиком перфокарт (с точки зрения обычного пользователя), и ...

[Из песочницы] Занимательный пролог

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