Показаны сообщения с ярлыком Цитаты. Показать все сообщения
Показаны сообщения с ярлыком Цитаты. Показать все сообщения

воскресенье, 7 февраля 2016 г.

О человеческом оптимизме

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

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

--------

Психологи доказали: мы ошибочно полагаем, что в будущем нас ждет больше свободного времени, нежели сегодня. Эту проделку разума удачно подловили два профессора маркетинга. Их заинтриговало, что потребители здорово промахивались в предсказаниях того, как часто они будут использовать спортивные снаряды: в 90 процентов случаев предметы были обречены пылиться в подвалах. Ученым стало любопытно, о чем люди думали, когда обещали, что найдут применение этим гантелям и тренажерам для пресса. Они представляли будущее похожим на настоящее, полным важных дел, лишней информации, повседневной усталости? Или они воображали иную реальность?

вторник, 6 апреля 2010 г.

Новости Цитатника

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

Стив Макконнелл. Совершенный код

Как сказал Дэвид Грайс, подход к программированию не должен определяться используемыми инструментами. В связи с этим он проводит различие между программированием на языке (programming in language) и программирование с использованием языка (programming into language). Разработчики, программирующие "на" языке, ограничивают свое мышление конструкциями, непосредственно поддерживаемым языком. Если предоставляемые языком средства примитивны, мысли программистов будут столь же примитивными.
Разработчики, программирующие "с использованием" языка, сначала решают, какие мысли они хотят выразить, после чего определяют, как выразить их при помощи конкретного языка.
Глава 4.3 Волны развития технологий

Цитаты: Часть 1

Дж. Ханк Рейнвотера “Как пасти котов. Наставление для программистов, руководящих другими программистами”

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

Чем лучше вы знаете людей, которыми вам предстоит руководить, тем выше шансы на успех.
Глава 1. Как привыкнуть к роли руководителя

Не стоит забывать, что любой руководитель должен оценивать свои успехи исключительно по тому, насколько эффективно работают его подчиненные.
Глава 1. Слава, почет и деньги

Цитаты: Часть 1

Джоэл Спольски. "Джоэл о программировании"
Продвижение хороших кодеров выдвижением их на другие должности, где требуется писать на человеческом языке, а не на С++, служит классической иллюстрацией принципа Питера: люди продвигаются по службе, пока не достигнут своего уровня некомпетентности.
Глава 7. Как принимать на работу менеджера программы?

Идея рекламы состоит в том, чтобы врать и не быть пойманным.
Глава 37. Второе письмо о стратегии: что сначала - курица или яйцо.

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

Цитаты: Часть 2, Часть 3, Секреты айсберга, Справочник бойца по проведению собеседования

Скотт Мейерс. Эффективное использование С++

Сорок лет назад код, изобилующий операторами goto, считался вполне приемлемым. Теперь же мы стараемся писать структурированные программы. Двадцать лет назад глобальные данные ни у кого не вызывали возражений. Теперь мы стремимся данные инкапсулировать. Десять лет назад написание функций без учета влияния исключений было нормой. А сейчас мы боремся за достижение безопасности относительно исключений.
Времена меняются. Мы живем. Мы учимся.

Правило 29. Стремитесь, чтобы программа была безопасна относительно исключений

Цитаты

Гради Буч. Объектно-ориентированный анализ и проектирование

Абстракция и икапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством.
Глава 2.1 Инкапсуляция

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

Сокрытие информации - понятие относительное: то, что спрятано на одном уровне абстракции, обнаруживается на другом уровне.
Глава 2.1 Инкапсуляция

Деление программы на модули бессистемным образом иногда гораздо хуже, чем отсутствие модульности вообще.
Глава 2.1 Модульность

Цитаты: Часть 3. Объектная модель. Основные определения, Часть 4

Эдвард Йордон. Путь камикадзе

Неразумное поведение корпораций заключается в том, что они делают одно и то же снова и снова, каждый раз ожидая различных результатов.
Глава 1

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

Для проведения переговоров нелишними будут такие вопросы, как «обанкротится ли организация, если система будет готова не к 1-му сентября, а к 5-му?» или «все хотят, чтобы работа была сделана хорошо, быстро и дешево. Все знают, что реально можно выполнить только два требования из трех. Какие именно два для вас важнее?»
Глава 3.2 Допустимые компромиссы

Цитаты: Часть 1, Часть 2

Алан Шаллоуей и Джеймс Р. Тротт. Шаблоны проектирования

Шаблоны позволяют нам видеть лес за деревьями, поскольку помогают поднять уровень мышления.
Глава 5. Зачем нужно изучать шаблоны проектирования

Наличие возможности реализовать что-либо вовсе не означает, что это обязательно должно быть выполнено.
Глава 13. Принцип проектирования от контекста

Цитаты: Часть 3, Несколько слов о работе с заказчиком

вторник, 8 декабря 2009 г.

О цитате “Преждевременная оптимизация – корень всех зол”

Многие специалисты компьютерной области знают (ну, или хотя бы слышали) следующее высказывание:

Преждевременная оптимизация - корень всех зол в программировании

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

Существует как минимум три разновидности этой фразы, которая встречается в различных трудах Дональда Кнута.

Первый вариант:
Преждевременная оптимизация - корень всех зол в программировании
Оригинал:
Premature optimization is the root of all evil
Источник:
1974 год, лекция, посвященная вручению премии Тьюринга, Computer Programming as an Art, Communications of the ACM, Volume 17, Issue 12, Dec. 1974 (see p.671)).
Полная версия оригинала:
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

Второй вариант:
Нам следует забывать о небольшой эффективности, например, в 97% случаев: преждевременная оптимизация - корень всех зол. Хотя мы не должны отказываться от своих возможностей в этих критических 3%
Оригинал:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3.
Источник:
1974 год, статья Structured Programming with go to Statements, ACM Computing Surveys, Vol 6, No. 4, Dec. 1974 (see p.268)  (эта статья является критикой статьи Эдсгера Дейкстры Go To Sta­te­ment Con­si­de­red Harm­ful).

Третий вариант:
Я также знал, но забыл афоризм Хоара о том, что преждевременная оптимизация — корень всех зол в программировании
Оригинал:
But I also knew, and forgot, Hoare’s dictum that premature optimization is the root of all evil in programming.
Источник:
1989 год, статья The Errors of Tex, Software—Practice & Experience, Volume 19, Issue 7 (July 1989), pp. 607–685, а также в книге Literate Programming (p. 276)

Все три варианта появились в трудах Дональда Кнута, но судя по третьей цитате складывается впечатление, что изначальным автором фразы был другой знаменитый ученый в области компьютерной науки Тони Хоар (C.A.R. Hoare), также лауреат премии Тьюринга, автор быстрой сортировки, Логики Хоара и много чего другого.

С момента выхода в свет The Errors of Tex, прошло уже два десятка лет, но до сих пор нигде не удается найти информацию, подтверждающую слова Кнута о том, что автором этой фразы является именно Хоар. Более того, сам Хоар в 2004 году в личной переписке с Hans Genwits написал о том, что он НЕ является автором этой цитаты (оригинал здесь):

Dear Hans,
I’m sorry I have no reco­llec­tion how this quo­ta­tion came about.? I might have attri­bu­ted it to Eds­ger Dijkstra.
I think it would be fair for you assume it is com­mon cul­ture or folklore.
Tony.

На самом деле не так и важно, кто является автором этого высказывания, Дональд Кнут, Эдсгер Дейкстра, Тони Хоар, или кто-то не столь именитый в области компьютерных наук. Важно то, что эта фраза стала известной именно благодаря Дональду Кнуту.

Ну и последнее, помните, Дональд Кнут говорил о 97%, а не о 100%;)

четверг, 2 июля 2009 г.

Немного о книге Джеймса Коплиена "Программирование на C++. Классика CS"

Я эту книгу читал уже несколько лет назад, поэтому речь не идет о полноценной рецензии, просто недавно я достал ее с полки, полистал и решил выписать некоторые интересные цитаты, а в месте с ними и свои мысли об этой книге. Первое, что приходит в голову, когда узнаешь, как эта книга называется в оригинале - это что-то вроде: "сколько же выпили переводчики, чтобы оригинальное название, которое звучит "Advanced C++ Programming Styles and Idioms" перевести как "Программирование на С++"? Хорошо хоть о С++ не забыли, а то можно было бы перевести просто как "Программисту" или еще что-то в этом роде.
На самом деле, книга не просто о С++, в ней речь как раз и идет продвинутых идиомах языка, о которых позднее будут писать Саттер и Мейерс, что с учетом даты выхода оригинального издания (это сентябрь 1991 года!) выглядит просто потрясающе. В книге описываются шаблоны проектирования (хотя используется термин "идиома", потому что термина "шаблоны проектирования" в то время еще не было, книга вышла за 3 года до выхода знаменитой книги Банды Четырех).
В книге приводится отличное определения принципа замещения Лисков (см. ниже в этом посте) и определения таких отношений между классами и объектами, как "IS-A", "HAS-A", "USES-A" и другие. Конечно, многие темы уже не столь актуальны сегодня. О многих проблемах гораздо лучше писали те же Саттер и Мейерс, но сам факт, это отличная книга, которая помогла бы множеству разработчиков ... лет эдак 10 назад. Но даже в момент выхода русскоязычного издания в 2005 году она оставалась весьма полезной и актуальной.
Теперь, собственно, к цитатам.
Не сказать, чтобы их было слишком много, но они весьма интересны и познакомиться с ними будет полезно любому разработчику, не зависимо от языка программирования или специализации.
Синтаксис языка до определенной степени формирует наше восприятие, но простое описание синтаксиса в "руководстве пользователя" станет всего лишь отправной точкой. Структура наших программ (а следовательно, и тех систем, которые мы строим) в основном определяется стилем и идиомами, используемыми для выражения архитектурных концепций.
Стиль отличает истинное мастерство от простой удачи. Эффективный стиль воспитания ребенка, программирования и вообще всего на свете строится на основе личного опыта или опыта других. Программист, который умеет правильно связывать возможности языка программирования с потребностями приложения, пишет превосходные программы. Но чтобы выйти на этот уровень, необходимо от правил и механического запоминания перейти к идиомам и стилю, а в конечном счете - к концептуальным и структурным абстракциям.
Предисловие. Изучение языка программирования

Изучение языка программирования имеет много общего с изучением естественного языка. Знание базового синтаксиса позволяет программисту писать простые процедуры и строить из них нетривиальные программы - подобно тому, как человек со словарным запасом в несколько тысяч иностранных слов способен написать нетривиальный рассказ. Но настоящее мастерство - совсем другое дело. Рассказ может быть нетривиальным, но от этого он не станет читаться "на одном дыхании", подчеркивая свободу владения языком его автора. Изучение синтаксиса и базовой семантики языка сродни 13-часовым курсам немецкого для начинающих: после прохождения таких курсов вы сможете заказать колбаски в ресторане, но для работы в Германии журналистом или поэтом их наверняка окажется недостаточно. Различие кроется в идиоматике языка.
Предисловие. Изучение языка программирования
 
В программировании, как и в естественных языках, пригодность и выразительность языковых конструкций базируется на важных идиомах. Хорошие идиомы упрощают работу прикладного программиста, подобно тому как идиомы любого языка обогащают общение. Программные идиомы являются "выражениями" семантики программирования, пригодными для многократного использования в том же смысле, в котором классы служат для многократного использования архитектурных решений и кода. В программировании, как и в естественных языках, пригодность и выразительность языковых конструкций базируется на важных идиомах. Хорошие идиомы упрощают работу прикладного программиста, подобно тому как идиомы любого языка обогащают наше общение. Программные идиомы являются "выражениями" семантики программирования, пригодными для многократного использования в том же смысле, в котором классы служат для многократного использования архитектурных решений и кода.
Предисловие. Изучение языка программирования
 
Как сказал Страуструп, хорошие навыки программирования и проектирования являются результатом личного вкуса, проницательности и опыта.
Глава 1. Проектирование и язык
 
Принцип замещения Барбары Лисков: ...если для каждого объекта o1 типа S существует объект o2 типа T такой, что для всех программ P, определенных в контексте T, поведение P не изменяется при замене o1 на o2, то S является базовым типом для T.
Глава 6. Случайное наследование – омонимы в мире типов

понедельник, 29 июня 2009 г.

Цитаты из книги Джона Роббинса "Отладка приложений для Microsoft .Net"

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

Об ошибках

Ошибки - это мрак. Точка. Ошибки - вот из-за чего вы вкалываете на безнадежными проектами с давно просроченными сроками сдачи, просиживаете у компьютера ночи на пролет и ссоритесь с вечно ворчащими коллегами. Ошибки действительно могут превратить вашу жизнь в кошмар, если достаточное их количество обнаружится в вашем программном обеспечении. Клиенты могут прекратить использовать ваш продукт, а вы можете потерять работу.
 
Ошибки - это серьезно! Очень часто люди, работающий в нашей индустрии, представляют себе ошибки просто как досадные мелочи. Сильнее заблуждаться невозможно. Любой разработчик расскажет вам о проектах с немыслимым количеством ошибок и даже о компаниях, загнувшихся оттого, что их продукт содержал столько ошибок, что был непригоден. Когда я писал первое издание этой книги, NASA потеряла космический зонд, направленный на Марс, из-за ошибок, допущенных на этапе формулировки требований и проектирования ПО.
 
Пока я писал второе издание на солдат американского спецназа упала бомба, направленная на другую цель. Причиной была программная ошибка, возникшая при смене источника питания в системе наведения. За неделю до того, как я написал это введение к третьему изданию, корпорация Microsoft выпустила пакет исправлений для пакета исправлений, который ранее создал огромную уязвимость, связанную с переполнением буфера в Microsoft Internet Explorer 6.
 
Хотя к программным ошибкам уже начинают относится с бОльшим уважением, нам еще очень далеко до появления культуры разработки, в которой к ошибкам будут относиться чрезвычайно серьезно, а не как к незначительным проблемам, иногда возникающим в процессе разработки. Ошибки – это круто! Они помогают залезть в самую глубину и понять, как работают вещи. Мы все попали в этот бизнес, потому что нам нравится учиться, выслеживание ошибок – неотъемлемая часть обучения… Ведь так здорово бывает найти и исправить ошибку! Конечно же, самые хорошие ошибки – это те, которые обнаруживаются до того, как заказчик увидит ваш продукт. Таким образом, вы должны успевать сделать свою работу и найти ошибки до того, как это сделают ваши заказчики. Видеть, как заказчики обнаруживают ошибки, - это совершенно не круто.
 

Об отладке

Отладка - это очень захватывающая тема, независимо от того, какой язык вы используете и на какой платформе работаете. Это единственный этап процесса разработки программного обеспечения, на котором инженеры пинают свои компьютеры, орут на них и даже разбивают их об стену. Для обычно сдержанной замкнутой группы такой накал эмоций представляет собой что-то невероятное. Также отладка является тем этапом процесса разработки ПО, который чаще всего в нашем сознании связывается с "ночными бдениями". Мне еще не встречался инженер, который бы позвонил домой, чтобы сказать: "Дорогая, я не могу прийти домой, потому что мы так веселимся, составляя UML-диаграммы, что хотим посвятить этому развлечению всю ночь!" Однако многие из знакомых инженеров имели опыт жалобных звонков домой в стиле: "Дорогая, я не могу прийти домой, потому что наткнулся на чудовищную ошибку в программе".
 

О сроках

Всем нам приходилось бывать участниками команд разработчиков, для которых «менеджмент» устанавливал сроки выполнения, определенные при помощи толкования карт Таро или, если это было слишком дорого, путем метания дротиков в календарь. Хотя нам хотелось бы верить, что менеджеры несут ответственность за большинство нереалистичных графиков работы, чаще всего это все же не их вина. Обычно основой графика работы становится оценка, даваемая инженерами, и иногда они недооценивают время, которое им может понадобиться для разработки надежного продукта. Инженеры – забавные люди. Они интроверты, но практически всегда большие оптимисты. Получая техническое задание, они до глубины костей верят, что могут с легкостью заставить компьютеры встать и танцевать. Если менеджер зайдет к ним и скажет, что в приложение необходимо добавить блок преобразования XML, средний инженер ответит: «Без проблем, босс! Дайте мне три дня». Конечно же этот инженер может даже не знать, как правильно пишется «XML», но он уверен, что за три дня справится с чем угодно.
 

Об анализе рисков

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

О дальновидности руководителей

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

Кошки и отладка

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

Разное

Помните, что отладчик – это всего лишь инструмент, как например, отвертка. Он делает только то, что вы приказываете ему делать. Настоящий отладчик находится у вас в голове.
 
Было бы здорово, если бы за ошибки в коде можно было винить барабашек, но необходимо принять и смириться с фактом, что именно вы и ваши коллеги населяете код ошибками. (Если вы читаете эту книгу, то основная вина ложится, конечно же, на ваших коллег.)
 
«Если отладка – это процесс устранения ошибок, то программирование должно быть процессом их порождения»
Эдсгер Дейкстра
 
Кодируй так, как будто человек, поддерживающий твой код, - буйный психопат, знающий, где ты живешь.
 
Многие разработчики жалуются, что пользователи совершенно не хотят тратить время на то, чтобы хоть что-то узнать о компьютерах. Я всегда парирую: «Не могу поверить, как много разработчиков практически ничего не знают о своих средах разработки».

суббота, 25 апреля 2009 г.

О выборе языка программирования

Данное сообщение навеяно очередной "войной" на rsdn.ru о выборе между С++ и C#.  

Мне кажется, что языки, используемые нами для выражения своих идей, становятся частью нас самих, поэтому, если вы знаете только один язык, может показаться, будто сторонники других языков представляют опасность лично для вас. Мне представляется, что выход из этой ситуации – освоение других языков. Сомневаюсь, что можно быть профессионалом в области ПО и знать лишь один язык программирования. Может быть и экономическая причина: фундаментальные знания выходят за границы языка программирования в отличие от многих практических навыков. Поэтому, если я знаю только язык X и его наборы инструментов, а вы являетесь сторонником языка Y и его наборов инструментов, вы представляете угрозу для источника моего заработка. И вновь решение, как мне кажется, - в знании нескольких языков и наборов инструментов (а также твердое понимание фундаментальных концепций).
Интервью++: Бьерн Страуструп об эволюции языков  

Портфелем знаний мы предпочитаем называть все факты, известные программистам об информатике, области приложений, в которых они работают, и накопленный ими опыт. Управление портфелем знаний очень похоже на управление финансовыми портфелем. Предложения по поддержке портфеля знаний:
- Учите (как минимум) по одному языку программирования каждый год.  
- Читайте по одной технической книге ежеквартально.   
- Читайте книги, не относящиеся к технической литературе.  
- Экспериментируйте с различными операционными средами.
Важно продолжать инвестирование. Как только вы почувствуете, что освоили новый язык или фрагмент технологии, двигайтесь дальше. Изучайте другой. Неважно, будете ли вы когда-либо использовать одну из этих технологий в проекте или даже не упомянете о них в своем резюме. Процесс обучения расширит ваше мышление, открывая вас для новых возможностей и новых путей в творчестве. "Перекрестное опыление" идей важно; попытайтесь применить выученные уроки к проекту, над которым вы работаете в настоящее время. Даже если в вашем проекте не используется некая технология, вы наверняка сможете позаимствовать некоторые идеи.
Эндрю Хант и Дэвид Томас. Программист-прагматик. Путь от подмастерья к мастеру  

Как сказал Дэвид Грайс (Gries) подход к программированию не должен определяться используемыми инструментами. В связи с этим он проводит различие между программированием на языке (programming in lanuage) и программирование с использованием языка (programming into language). 
Разработчики, программирующие «на» языке, ограничивают свое мышление конструкциями, непосредственно поддерживаемых языком. Если предоставляемые языком средства примитивны, мысли программистов будут столь же примитивными. Разработчики, программирующие «с использованием» языка, сначала решают, какие мысли они хотят выразить, после чего определяют, как выразить их при помощи конкретного языка.
Стив Макконнелл. Совершенный код.

Я привел три цитаты, каждая из которых говорит о второстепенной роли языка программирования в жизни разработчика. Причем автор одной из них имеет непосредственное отношение к одному из языков программирования!
Конечно же, я не придерживаюсь мысли, что язык программирования не играет никакой роли. Нет, это не так.
Я не считаю, что не нужно углублять свои знания в конкретном языке или технологии; не считаю, что нужно выбросить книги Герба Саттера и Андея Александреску, Джошуа Блоха и Билла Вагнера, и не зачитываться этюдами nikov-а на rsdn-е. Все это очень полезно. Но польза не только в том, что эти знания вы можете использовать сейчас на текущем проекте с текущим языком и технологией, а в том, что эти знания позволят перейти вам на следующий уровень своего развития и решать более сложные задачи в следующих проектах, уже на совершенно других языках программирования и совершенно других технологиях.

Продолжая рассуждение о языках программирования в жизни разработчика, достаточно вспомнить, что пишет Брукс и Буч о сложности программных систем:  
Эйнштейн неоднократно утверждал, что природа должна иметь простые объяснения, поскольку Богу не свойственны капризность и произвол. У программиста нет такого утешения: сложность, с которой он должен справиться, лежит в самой природе системы. а затем: Сложность программного обеспечения – отнюдь не случайное его свойство. Сложность вызывается четырьмя основными причинами: сложностью реальной предметной области, из которой исходит заказ на разработку; турдностью управления процессом разработки; необходимостью обеспечить достаточную гибкость программы; неудовлетворительными способами описания поведения больших дискретных систем.

Как вы можете заметить, не один из этих пунктов не содержит фразы: «сложность программного обеспечения обусловлена неверным выбором языка программирования». Кроме того, вам будет довольно сложно найти цитату авторитетного автора, который бы сказал что-то вроде этого: «Изучение языка программирования А – это ваш путь к успеху. Благодаря ему уже через полгода его изучения вас ждет почет и уважение в среде разработчиков по всему миру, вы будете президентом корпорации и будете ездить на Bentley, а вот если ваш выбор остановится на языке программирования Б – вас ждет позор, забвение и жизнь на помойке».

На закуску, хочется привести еще одну цитату Ханта и Томаса:  
Программирование – это прикладное искусство. Простейший его смысл заключается в следующем: заставить компьютер делать то, что вам нужно (или то, что нужно пользователю, работающему с вашей программой). Программист – он и слушатель, он и советник, он и переводчик и даже диктатор. Вы пытаетесь ухватить суть не совсем ясных требований и найти такой способ их выражения, что только машина сможет оценить их по достоинству. Вы пытаетесь задокументировать работу так, чтобы она была понятна другим, спроектировать ее так, чтобы другие могли на нее положиться. Кроме того, вы пытаетесь сделать все это вопреки безжалостному ходу стрелки часов, отсчитывающих время, отпущенное на проект. Каждый день вы совершаете по маленькому чуду. Это непростая работа.
Многие предлагают вам помощь. Фирмы-поставщики инструментальных средств настойчиво говорят о чудесах, которые творят их программы. Мудрецы от методологии заверяют в том, что их средства гарантируют результаты. Каждый считает свой язык программирования лучшим из лучших, а операционную систему – панацеей. Разумеется, эти утверждения неверны. Простых ответов не существует. Не существует такого понятия, как наилучшее решение, будь то инструментальное средство, язык или операционная система. Существует лишь некие системы, которые являются более приемлемыми при конкретном стечении обстоятельств. И в этот момент на сцену выходит прагматизм. 
Стоит избегать обряда венчания с конкретной технологией, но при этом необходимо обладать подготовкой и опытом, настолько обширными, что это позволит выбрать верные решения в конкретных ситуациях. Ваша подготовка происходит из понимания основных принципов информатики, а опыт основывается на разнообразных практических проектах. Теория и практика сочетаются, придавая вам силу.

P.S. Если вы хотите стать хорошим программистом, то нужно решать сложные задачи в интересном коллективе. При этом язык программирования играет лишь второстепенную роль.