ну не знаю, может стоит профессию поменять :-)

а ежели не вызвал?
-----
Почитай, хоть на ознакомительном уровне, документацию к NUnit\JUnit
и посмотри примеры.
что тогда?
-----
Тогда тебя уволят. Ибо сначала делается проектирование, потом пишутся
тесты, и только потом делается и тестируется код...

З.Ы. Ответь себе на простой вопрос - Какой код является правильным? - отчень многие
вопросы отпадут.

Преймущество С++ перед Java, Python и иже с ними это скорость. Если скорость не важна, то выбирать нужно тот язык, реализация на котором проще для данной задачи. В противном случае, использование любых конструкций, снижающих скорость выполнения программы, не приветствуется. В частности, виртуальных функции в С++.

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

это спорный и далеко не однозначный вопрос

Если скорость важна, то обычно покупают больше железа. А выбирать нужно тот язык который знаешь.
Всё ИМХО

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

Это однозначный вопрос. Чем "ближе" я к железу, тем больше у меня возможностей для оптимизации.

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

а сколько человек способны реализовать все или хотя бы большинство возможностей оптимизации, т.е. обладают опытом и знаниями для этого?
Сейчас ты это сформулировал как "возможность" и тут ты конечно прав, возможностей больше. Но разработка на языке высокого уровня позволяет достичь результата (и поддерживать готовый продукт) с меньшими затратами ресурсов. Если рассматривать только скорость работы готовой программы то это сферический конь в вакууме.

Такой подход имеет место быть везде

Т.е. плюсы - это наиболее качественное из имеющихся?

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

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

это скорость.
------
Скорость это количество процессоров в кластере.
А писать надо на том, на чем будет проще и понятнее.

В чём заключается результат? Что такое "рабочая программа"?
Если вас устраивает расчёт стоимотси опциона за 1день тогда программа делающая это за 12часов - рабочая. Но если у меня есть программа делающая это за 6 часов, то вы понимаете, кто получит прибыль ;-), которая к слову не идёт ни в какое сравнение с расходами.

Качество программы должно расти, а не только количество железа :-) Иначе бы на 8корах был бы занят только 1 :-)

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

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

кстати, OCaml вполне себе доганяет C++ по скорости, при этом получается куча полезных вещей типа статической проверки типов и т.п. на гугл видео есть рассказ 'Caml Trading', ну и у lionet.livejournal.com есть описания производительности окамла как замены С++

Чем "ближе" я к железу, тем больше у меня возможностей для оптимизации.
------
Чем ближе ты к железу, тем меньше у тебя возможностей для оптимизации.
Просто потому, что объем низкоуровневого кода "несколько" больше и "за
деревьями леса не видно"... выиграешь в оптимизации трех команд пару нансек
и потеряешь на чем-то глобальном пару милисек...
но и качественный.
-----
Чтобы код был качественным, ты должен видеть и понимать его целиком.
На низком уровне возможность это сделать теряется.
вычислительно сложных задач
-----
Хммм... году этак в... ну да ладно об годах... В распоряжении прогера были
СМ-3, какие-то килобайты памяти, немножко мебагайт диска и транслятор с
Фортрана. Задача была не сложная - что-то из трассировки многослойных
печатных плат... Единственная проблема - размерность задачи. Она явно не
соответствовала возможностям системы - памяти не хватало.
Если кто-то возмется сейчас за день написать подсистему кеширования для
подобной задачи и справится за день - Я его буду уважать... но оценил бы
полную задачку, учитывая то железо и язык, в пару-тройку недель...
Тем не мение мужичек, которому пришлось писать код, справился с задачей
на 5-ть... и всего за день.

вопрос только на сколько это используется на практике?
------
Тут всего два варианта.
Первый - это используется - проект живет и если он имеет смысл - развивается.
Второй - это не используется - проект развивается до некоторого уровня и затем помирает.
Третьего варианта нет.
От проектменеджеров конечно зависит "многое", но они ограничены тем что знают и что
документировано...

Согласен. Поэтому не ассемблер или машинный код ;-)

Здесь я имею ввиду качественный по скорости, а не по поддержке. Ещё раз, если нужна скорость, то иногда приходится немного жертвовать дизайном. Если скорость не нужна - то и с++ часто не нужен.

В С++ есть возможности для мета-программирования. То, что какой-то компилятор для OCalm может сделать быстрый код, который работает быстрее кода, сгенерированного каким-то компилятором для с++ я согласен.