Чем выше уровень языка, тем больше он напичкан чужими либами решающими на первый взгляд рутинные задачи, но не забывайте что "дядя  Сем" написавший за вас рутину тоже мог наделать ошибки, которые в последствии по вылазят  в ваших проектах...
В данном случае С++ оптимальный вариант для тех, кто знает и понимает ПК изнутри (адресации, битность, разрядность, фрагментации и т.д.), и хочет по своему оптимизировать свое приложение...
Конечно никто не лишен ошибок и тут то на помощь таким людям, другие  - добрые люди написали  PVS-Studio, за что им низкий поклон...
Если же вас не интересует ПК изнутри, а просто хочется побыстрее изваять некую логику, то тогда лучше выбирать готовые  "ядра от дяди  Сема" - 5 строк = 3D анимация...     

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



Вот мне нужно рассчитать упругость крыла в конкретных условиях. Зачем мне понимание ПК изнутри? Я знаю аэродинамику и мне нужно решить задачу из конкретной области, зачем мне отвлекаться на архитектуру ПК? Оптимизировать нужно уже отлаженное приложение - про роль преждевременной оптимизации в современном мире мы все знаем.
Это имеет глубокий смысл, если я не заказчик решения задачи, а исполнитель - тогда да, сложность языка и трудности в подготовке достойных специалистов позволят обосновать бюджет.
На эту тему мне всегда вспоминаются военные АСУ - это жуткое воплощение полной противоположности понятию "интуитивно понятный интерфейс". Полное впечатление, что их создавали люди с другой планеты. Когда мне сказали, что в одном истребительно-авиационном полку начальник штаба наводил перехватчики в автоматизированном режиме и "лабал на нем как Ростропович на пианино" я был дико удивлен - вся работа в АСУ, что я видел до этого сводилась к банальному ежедневному контролю функционирования. Там невероятное количество кнопок и условных обозначений. Причем эти обозначения у меня вызывали четкую ассоциацию с китайскими иероглифами - примерно также я их и понимал. Эти АСУ тоже нужно долго изучать и потом специалист по ним ценится на вес золота. Но это же извращение!

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

А в целом инструмент выбирается исходя из задачи, конечно же.

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


  Почему вы думаете, что программисты на других языках не знают, что такое логические ошибки? Они что не также учились программированию? Кстати такая "космическая" ошибка была у меня в проекте на С++ и я очень долго искал ее. У меня было преобразование short->float->double->float->short . Тип данных short являлся аппаратным, а double использовался для математической обработки чтобы сохранить точность при возведении в квадрат. Аппаратура выдала значения вне рабочего диапазона и соответственно на преобразовании float->short получилась ошибка переполнения безо всяких исключений. 

  

а как же... скорость? :cry:

Всё-таки CLR и прочие жаба-машины не могут не влиять на скорость исполнения кода. 

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

Скорость? Очень часто она достигается _аппаратными_ средствами. Т.е. недостаток быстродействия какого-то языка можно компенсировать железом. А вот отсутствие библиотек и необходимость их написания с нуля и доведением до продакшена - ничем компенсировать нельзя. Так что (ИМХО) legacy код перевешивает быстродействие.

Согласен. Также полностью согласен с подходом, когда код обильно проверяется (ассертами или другими средствами языка) с целью как можно быстрее сломать его - именно для чтобы быстрее выявить все ошибки.

Двухколесные велосипеды - очень плохие велосипеды.
Я вот привых катацца на велосипеде с боковыми колёсиками, но однажды мне необходимо было поехать на 2-ух колёсном велосипеде.
Так я чуть голову не сломал.
Поэтому предлагаю:
Запретить всем ездить на 2-ух колёсных велосипедах.
Это очень опасно.
Например, если вы потеряете равновесие, то вас ничего не задержит от падения.
И в аварии вы будете попадать чаще.
Двухколесные велосипеды - зло!

Лучше всего использовать велосипеды с боковыми колёсиками.
Они вас защитят от любых авто-катастроф.
Еще лучще использовать "супер-надежные" трехколесные велосипеды с  прицепом.
На них вы точно никогда не опрокинетесь, и никогда не  попадете ни в какую аварию!

молодец! 
Но если так подумать, программеры занимаются тем, что автоматизирую деятельность третих лиц. И тут очень плохо, когда язык не позволяет автоматизировать деятельность себя (т.е. программера).
Впринципе все языки этими грешны, у всех есть проблемы.
Развиваемся потихоньку, спорить тут не о чем. У кого-то есть плюсы у когото минусы, потом другие языки перенимают что-то и все разививается и очень класно за этим наблюдать 
Сам я очень люблю C++, хотя щас уже год педалю на Java, но с удовольствием вернулся на C++, если б дали болльше денех.
Порог вхождения в C++ на много выше чем в ту же Java, поэтому для бизнеса это менее интересно. Надо много программеров, а не несколько супер классных.

АБСОЛЮТНО неверная аналогия.
Хотите кататься на двухколесном велосипеде? Пожалуйста! Катайтесь. В свободное от работы время. А на работе будьте любезны ездить на автомобиле. Да. вы там не выправите вилку, если в дерево стукнулись. Не сможете проехать там, где ездили на велосипеде. Даже правила дорожного движения соблюдать надо! И если столкнетесь с другим автомобилем ушибами не отделаетесь. Но это же совсем разные вещи по эффективности, правда? Да, вы не разберете автомобиль так же быстро, да, вы на нем будете просто наездником, но это же небо и земля! А иначе можно сделать сложный язык и посвящать в него только избранных и гордится тем что мы умные и знаем этот язык - а вы все плебеи. Интересное преимущество - уметь ездить на двухколесном велосипеде, когда вокруг столько возможностей доехать намного быстрее и проще.

  

Как всегда в таких вопросах, тема переросла в холивар. Так что пусть тут побудет. 

Нельзя, по крайней мере не на любом

Alexeis, юнит-тесты решают, а C++ юзают из-за меньшего (неявного) ран-тайм оверхеда (принцип нулевой стоимости) и вообще больших возможностей контроля поведения результирующего кода, чем в более высокоуровневых ЯП.

Добавлено через 1 минуту и 18 секунд

Так и представляю себе F22 с Blue Gene на борту... =)

Возможно это удивительно, но многие военные компьютеры и у нас и у них очень деревянные с точки зрения обычного обывателя. На том же Ф-22 стоят микроконтроллеры 90ых годов - и ничего, единственный в мире самолет 5-го поколения. Это я к тому, что выжимать все соки из железа далеко не всегда нужно. Когда ЭВМ только создавались и использовались в качестве числодробилок - это да, было актуально. А сейчас слишком много областей, где вычислительная мощность процессора превосходит потребности приложения. Тот же Питон не на ровном месте получил такую популярность, уже подумываю присмотреться к нему.

Это сообщение отредактировал(а) drug007 - 12.2.2013, 12:38

  Допустим у меня есть конечный автомат с 10ю входами. Каждый вход имеет 2^32 варианта значений. Известно, что есть всего 5-6 комбинаций входных значений, которые фейлят автомат. Итого имеем (2^32)^10 = 2^320 вариантов входного состояния. Для справки это число комбинаций с сотней десятичных нулей. Подскажите как мне юнит-тестами попасть на эти нужные 5-6 комбинаций входов. 

Alexeis, а юнит тесты обязаны всегда все варианты проверять?